Свежие новости Seo-индустрии

Новости

Опасности неуместных сторонних скриптов

Опасности неуместных сторонних скриптов


Большинство тегов SEO, таких как title, canonical и т. Д., Принадлежат HTML HEAD, но если они помещены в BODY, Google и другие поисковые системы будут игнорировать их. Вот как это исправить.

Недавно я помогал одному из членов моей команды диагностировать новый сайт потенциальных клиентов, чтобы найти какие-то низко висящие плоды, чтобы поделиться с ними.

Когда я проверил их домашнюю страницу с помощью наших Расширение Chrome, Я обнаружил неуместный канонический тег. Мы добавили этот тип обнаружения давно, когда я впервые столкнулся с проблемой.

Вы можете спросить, что такое неуместный SEO-тег?

Большинство тегов SEO, таких как заголовок, мета-описание, канонический и т. Д., Относятся к HTML HEAD. Если они будут помещены в HTML BODY, Google и другие поисковые системы проигнорируют их.

Опасности неуместных сторонних скриптов

Если вы перейдете на вкладку Elements, вы найдете теги SEO внутри тега. Но эти теги должны быть в!

Почему происходит что-то подобное?

Опасности неуместных сторонних скриптов
Опасности неуместных сторонних скриптов

Если мы проверяем страницу с помощью VIEW SOURCE, канонический тег правильно размещается внутри HTML HEAD (строка 56, а находится в строке 139).

Что здесь происходит?!

Это проблема с Google Chrome?

Опасности неуместных сторонних скриптов

Канонический файл также помещается в ТЕЛО в Firefox.

Опасности неуместных сторонних скриптов

У нас такая же проблема с Internet Explorer.

Опасности неуместных сторонних скриптов

Edge не исключение.

У нас такая же проблема с другими браузерами.

Разбор HTML и подсветка синтаксиса

Почему каноническое изображение размещается правильно, когда мы проверяем ИСТОЧНИК ВИДА, а не когда мы проверяем его на вкладке Элементы?

Чтобы понять это, мне нужно представить пару концепций разработчика: лексический анализ и синтаксический анализ.

Когда мы загружаем исходную страницу с помощью ПРОСМОТРА ИСТОЧНИКА, браузер автоматически раскрашивает программные токены (HTML-теги, HTML-комментарии и т. Д.).

Для этого браузер выполняет базовый лексический анализ, чтобы разбить исходную страницу на токены HTML.

Эту задачу обычно выполняет лексер. Это простая и низкоуровневая задача.

Все компиляторы и интерпретаторы языков программирования используют лексер, который может разбивать исходный текст на языковые токены.

Когда мы загружаем исходную страницу с вкладкой «Элементы», браузер не только выделяет синтаксис, но и строит дерево DOM.

Чтобы построить дерево DOM, недостаточно знать HTML-теги и комментарии из обычного текста, вам также необходимо знать, когда тег открывается и закрывается, и их место в иерархии дерева.

Для этого синтаксического анализа требуется синтаксический анализатор.

Средству проверки орфографии английского языка необходимо провести аналогичный двухэтапный анализ написанного текста. Во-первых, ему нужно перевести текст в существительные, местоимения, наречия и т. Д. Затем ему необходимо применить правила грамматики, чтобы убедиться, что части речевых тегов находятся в правильном порядке.

Но почему теги SEO помещены в тело HTML?

Разбор HTML из Python

Я написал сценарий Python для выборки и анализа некоторых примеров страниц с ошибками, поиска канонических страниц в любом месте HTML и печати пути к DOM в том месте, где они были найдены.

После анализа той же страницы, которая показывает неуместные теги SEO в теле HTML, я обнаружил, что они правильно помещены в заголовок HTML.

Что нам не хватает?

Недействительные теги в заголовке HTML

Некоторые теги HTML действительны только в HTML BODY. Например, теги

и недопустимы в заголовке HTML.

Когда я внимательно посмотрел на HTML HEAD в нашем примере, я нашел скрипт с жестко запрограммированным . Это означает, что сценарий должен был быть помещен в, но пользователь неправильно поместил его в заголовок.

Возможно, инструкции были нечеткими, поставщик пропустил эту информацию или пользователь не знал, как это сделать в WordPress.

Я протестировал, переместив скрипт в BODY, но все же столкнулся с неуместной канонической проблемой.

После небольшого количества проб и ошибок я нашел другой сценарий, когда я переместил его в BODY, проблема исчезла.

Хотя во втором скрипте не было жестко закодированных недопустимых тегов, он, вероятно, записывал один или несколько в DOM.

Другими словами, он делал это динамически.

Но почему вставка недопустимых тегов заставляет браузер перемещать остальную часть HTML из заголовка в тело?

Устойчивость к ошибкам веб-браузера

Я создал несколько примеров HTML-файлов с описанными мною проблемами и загрузил их в Chrome, чтобы показать вам, что происходит.

В первом примере я закомментировал открывающий тег BODY. Это удаляет его.

Опасности неуместных сторонних скриптов

Вы можете видеть, что Chrome добавил его автоматически.

Теперь посмотрим, что произойдет, если я добавлю

внутри HTML HEAD, что недопустимо.

Опасности неуместных сторонних скриптов

Вот тут и становится интересно. Chrome заранее закрыл HTML HEAD и поместил остальные элементы HEAD в тело, включая наш канонический тег и

.

Другими словами, Chrome предположил, что мы забыли открывающий тег!

Это должно прояснить, почему неуместные теги в HEAD могут привести к тому, что наши SEO-теги окажутся в BODY.

Теперь давайте посмотрим на наш второй случай, когда у нас нет жестко запрограммированного недопустимого тега, но сценарий может записывать его динамически.

Опасности неуместных сторонних скриптов

Здесь вы видите, что если сценарий записывает недопустимый тег в заголовок HTML, он заставит браузер закрыть его раньше, чем раньше. У нас точно такая же проблема!

Мы не видели проблемы с нашим парсером Python, потому что lxml (библиотека синтаксического анализа Python) не пытается исправить ошибки HTML.

Почему браузеры это делают?

Браузерам необходимо отображать страницы, в которых наш скрипт Python не должен делать. Если они попытаются выполнить рендеринг до исправления ошибок, страницы будут выглядеть полностью разбитыми.

В Интернете полно страниц, которые полностью сломались бы, если бы веб-браузеры не допускали ошибок.

Этот статья from HTML5Rocks обеспечивает увлекательный обзор веб-браузеров и помогает объяснить поведение, которое мы видим в наших примерах.

«Спецификация HTML5 действительно определяет некоторые из этих требований. (WebKit прекрасно резюмирует это в комментарии в начале класса парсера HTML.)

К сожалению, нам приходится обрабатывать многие HTML-документы, которые не имеют правильного формата, поэтому синтаксический анализатор должен быть терпимым к ошибкам.

Мы должны позаботиться, по крайней мере, о следующих состояниях ошибки:

Добавляемый элемент явно запрещен внутри некоторого внешнего тега. В этом случае мы должны закрыть все теги, вплоть до того, который запрещает элемент, и добавить его после.

Пожалуйста, прочтите статью полностью или, по крайней мере, обязательно прочтите хотя бы раздел «Устойчивость к ошибкам браузера», чтобы лучше понять контекст.

Как это исправить

К счастью, решить эту проблему на самом деле очень просто. У нас есть две альтернативы. Ленивый и порядочный.

Правильное решение – отследить сценарии, которые вставляют недопустимые теги HTML в заголовок, и перемещать их в тело HTML.

Самое ленивое и быстрое решение – переместить все теги SEO (и другие важные теги) перед любыми сторонними скриптами. Желательно сразу после открывающего тега.

Вы можете увидеть, как я это делаю, здесь.

Опасности неуместных сторонних скриптов

У нас все еще есть тот же недопустимый тег и скрипт в заголовке HTML, и теги SEO также находятся в заголовке.

Это общая проблема?

Я видел, как эта проблема возникает уже много лет, и Патрик Стокс также сообщил, что видел ту же проблему часто происходит на корпоративных сайтах.

Одно из самых больших заблуждений о техническом SEO состоит в том, что вы делаете это один раз, и все готово. Так было бы, если бы сайты не менялись, пользователи / разработчики не делали ошибок и / или поведение робота Google тоже не менялось.

На данный момент это не так.

Я выступал за то, чтобы технические специалисты по поисковой оптимизации изучали навыки разработчиков, и я надеюсь, что этот пример иллюстрирует растущую важность этого.

Если вам понравился этот совет, обязательно посетите мой SMX West сессия на Решение сложных проблем JavaScript и использование семантического HTML5 в следующем месяце. Среди прочего, я поделюсь передовыми исследованиями того, как Googlebot и Bingbot обрабатывают скрипты и проблемы с HTML, подобные тем, которые я упомянул здесь.


Мнения, выраженные в этой статье, принадлежат приглашенному автору и не обязательно Search Engine Land. Список штатных авторов здесь.


Об авторе

3 дня назад повесил кормушку, но птички ее еще не проиндексировали
    Похожие записи
    Новости

    Согласно новым неотредактированным подробностям Project Jedi, Google якобы создает рекламную монополию с Facebook, чтобы способствовать собственному обмену.

    Новости

    Рекламодатели приложений теперь могут использовать кампании для приложений для взаимодействия без использования ссылок на контент.

    Новости

    Новые розничные интеграции от Microsoft и Google к праздникам; Ежедневная сводка по пятницам

    Новости

    Навигация по изменению заголовка Google: развертывание, что происходит сейчас и что вы можете с этим сделать