Гэри Ильеш и Мартин Сплитт из Google в очередном выпуске подкаста Search Off the Record разобрали, как краулер Google обрабатывает HTML. Разговор вскрыл важные различия между тем, как браузер и Googlebot видят одну и ту же страницу.
Обсуждение затронуло три темы: подсказки ресурсов (resource hints), размещение метаданных и валидность HTML. Несколько пояснений Ильеша бросают вызов распространенным предположениям о том, какие технические изменения реально помогают поиску, а какие — нет.
Что действительно важно: метаданные должны быть в head
Сплитт привел пример, когда спецификационный скрипт в head вставлял iframe, что заставляло браузер "закрыть" head раньше времени. В результате теги hreflang оказывались в body, где системы Google их — справедливо — игнорировали.
Ильеш объяснил, почему Google здесь жестко соблюдает правила. Тег <meta name="robots">, согласно стандарту HTML, может находиться только в head. То же самое касается элемента <link rel="canonical">.
Он сказал:
"Я бы сказал, что очень опасно размещать link-элементы, несущие метаданные, в body".
Логика простая: если бы Google разрешил canonical-теги в body, появилась бы теоретическая возможность угнать каноническую страницу и удалить ее из результатов поиска, просто впрыснув разметку.
Это самый критичный вывод для SEO. Если ваши hreflang, canonical или meta robots работают не так, как ожидалось — первым делом проверьте, не оказались ли они в body после того, как браузер распарсил страницу. Тег, который выглядит правильно в исходном HTML, может оказаться не на том месте, если скрипт или iframe спровоцировали преждевременное закрытие head.
Что можно не проверять: подсказки ресурсов не помогают Googlebot
Функции для ускорения браузера вроде dns-prefetch, preload, prefetch и preconnect решают проблемы с задержками, которых у инфраструктуры Google просто нет.
Ильеш пояснил, что DNS-резолвинг Google не нуждается в подсказках, которые пытаются дать сайты:
"Это очень полезно, если у вас, скажем, плохой интернет — делать DNS Prefetching. В нашем случае нам это не нужно, потому что мы можем общаться очень быстро со всеми каскадными DNS-серверами".
Он добавил, что Google кэширует ресурсы страниц отдельно и не загружает их в реальном времени, как браузер. Это осознанное архитектурное решение, чтобы не создавать избыточную нагрузку на серверы сайтов.
Ильеш продолжил:
"То же самое с preload. Если мы работаем несинхронно, нам нет особой нужды слушать и смотреть на preload".
Ильеш и Сплитт подчеркнули: эти подсказки по-прежнему помогают пользователям. Более быстрая загрузка страниц улучшает удержание и конверсию. Разница в том, что эти изменения влияют на браузерный опыт, а не на краулинг или индексацию.
Что вообще не влияет на ранжирование: валидность HTML
Ильеш был прямолинеен насчет того, почему валидность HTML не может быть сигналом ранжирования. Валидность бинарна — она либо есть, либо нет, без промежуточных состояний. С таким метрикой трудно сделать что-то осмысленное.
Он объяснил:
"Очень трудно сказать, что что-то близко к валидному. И что тогда делать, когда что-то просто близко к валидному?"
Он привел пример: пропущенный закрывающий тег span делает HTML страницы технически невалидным, но, как выразился Ильеш, "для пользователя это ничего не изменит".
Сплитт согласился, заметив, что семантическая разметка вроде правильной иерархии заголовков и структурных элементов HTML5 тоже не несет значимого веса для поисковых систем, хотя полезна для доступности и пользовательского опыта.
Из трех обсуждавшихся пунктов критически важным для SEO является только расположение метаданных. Именно там, где Google требует их найти, а не там, куда они попадают из-за ошибок в коде. Подсказки ресурсов и идеальная валидация — вопросы производительности и качества кода для пользователей, но не сигналы для поискового робота.
План действий: как проверить свой сайт
- Проверьте исходный код. Откройте любую страницу, нажмите Ctrl+U и убедитесь, что ваши canonical, hreflang и meta robots находятся в секции <head>, а не в <body>.
- Протестируйте в инспекторе браузера. Откройте инструменты разработчика (F12), найдите свои критически важные теги и посмотрите, не перемещаются ли они из head в body после выполнения JavaScript.
- Аудит подсказок ресурсов. Пробегитесь по коду и найдите dns-prefetch, preconnect, preload. Оставьте их — они полезны для пользователей. Но знайте: на работу Googlebot'а они не влияют, и это нормально.
- Перестаньте гоняться за идеальной валидацией HTML. Проверяйте код на грубые ошибки, которые ломают верстку, но не тратьте часы на закрытие каждой мелочи. Это не поможет вам подняться в поиске.
Сплитт упомянул, что изначально темой выпуска должны были быть client hints, а обсуждение парсинга HTML было подготовкой к будущему эпизоду. Если этот эпизод выйдет, он может рассказать, как Googlebot обрабатывает новые заголовки Accept-CH и Sec-CH-UA, которые заменяют традиционные user agent строки.