Автор: Гленн Гейб (Glenn Gabe) – известный западный SEO-эксперт, глава агентства интернет-маркетинга G-Squared.
Google прошёл долгий путь к полноценному рендерингу JavaScript. И поскольку различные JS-фреймворки всё чаще используются для публикации контента, становится критически важным знать, может ли Google обработать весь контент на странице. Если по какой-то причине полный рендеринг невозможен, то какая-то часть содержимого сайта может остаться непроиндексированной. В самом худшем сценарии эта участь будет ожидать основной контент.
Как Google обрабатывает JavaScript
Google сканирует страницу и отправляет её в процессор для рендеринга. Статический HTML индексируется сразу, а обнаруженные ссылки передаются обратно в краулер. Процессор загружает страницу в Chrome (на текущий момент это версия 41) и визуализирует контент, включая то содержимое, которое публикуется через JavaScript. Полученная в результате страница затем индексируется, тогда как любые новые ссылки передаются обратно в краулер.
Таким образом, Google придерживается двухэтапного подхода к индексированию JavaScript-контента:
Помимо разбежностей в исходном и обработанном HTML, вы также можете обнаружить, что на странице отсутствуют важные директивы или же, что они были перемещены в новое место в коде. Так, метатеги robots могут сместиться на сотни строчек вниз и, в конечном итоге, оказаться не в хедере страницы, а в теле документа.
Именно поэтому владельцы сайтов и SEO-специалисты должны в обязательном порядке проверять страницы, чтобы убедиться, что весь важный контент обрабатывается должным образом.
Помогая сотням компаний, я не раз замечал, что некоторые из них не знают, как правильно проверить обработанный HTML. Они просто просматривали свои страницы в текущей версии Chrome или сканировали сайты (без включенного рендеринга JavaScript) и думали, что у них всё в порядке. К сожалению, такой подход оставляет место для ошибки. И, опять же, в самом худшем сценарии возможна ситуация, когда значительная часть контента сайта не будет индексироваться. Так что тестирование очень и очень важно.
В данной статье мы рассмотрим 6 способов, с помощью которых можно просмотреть обработанный HTML. Основной упор мы сделаем на инструменты Google, но также рассмотрим и другие доступные варианты, доступные на рынке.
1. Инструмент проверки URL в Google Search Console
В Search Console уже давно есть возможность просмотреть обработанную версию страницы с помощью инструмента «Сканер Google для сайтов» (в старой версии сервиса). Этот хороший способ, но недавно Google запустил новый – инструмент проверки URL.
Этот инструмент предоставляет информацию о состоянии URL на сайте, включая то, индексируются ли они; есть ли какие-либо недочёты, которые могут приводить к проблемам с индексацией; является ли URL каноническим; обработанный HTML и другие сведения.
Чтобы просмотреть обработанный HTML, нужно нажать на «View crawled page», после чего справа появятся три вкладки. Эти вкладки содержат HTML, которым Google располагает в процессе индексирования.
Это важно понимать, поскольку здесь может содержаться статический HTML или обработанный HTML, в зависимости от того, сколько времени потребуется для полной обработки.
Например, если страница была просканирована, но не визуализирована, то мы увидим статический HTML. Если же она уже подверглась рендерингу, то мы увидим обработанный HTML.
Я довольно быстро заметил этот нюанс, когда тестировал новый инструмент, и задал соответствующий вопрос сотрудникам Google Джону Мюллеру (John Mueller) и Мартину Сплиту (Martin Splitt). Я также спросил их об этом лично во время SEO-митапа в штаб-квартире Google в Нью-Йорке. И они подтвердили мои наблюдения.
Вторая вкладка содержит скриншот обработанной страницы (только при проверке «живых» URL через кнопку «Test live URL»). В идеальном мире скриншот должен соответствовать обработанной версии страницы. Но мы живём не в идеальном мире. Бывают случаи, когда скриншоты не всегда точно отображают визуализированную страницу. Поэтому важно проверять обработанный HTML-код, чтобы убедиться, что весь контент на месте (а не полагаться только на скриншот).
Что касается времени ожидания, то Мюллер объяснил, что это вполне нормально, поскольку реальная система рендеринга Google часто кеширует ресурсы и имеет более длительный тайм-аут. Так что об этом нужно помнить, используя инструмент проверки URL.
Наконец, третья вкладка содержит полезную информацию об URL, включая коды ответа сервера, ресурсы страницы, которые не могут быть загружены, а также консольные сообщения JavaScript (где можно просмотреть ошибки и предупреждения).
Важные примечания в отношении агента пользователя Googlebot
Когда инструмент проверки URL был впервые запущен, в нём можно было просматривать и десктопный рендер, и мобильный. Однако вскоре это изменилось и теперь инструмент позволяет просматривать обработанный HTML через агента пользователя, который соответствует текущему статусу индексирования.
Например, если сайт был переведён на mobile-first индексацию, то вы сможете просмотреть обработанный HTML и скриншоты страницы только через Googlebot for Smartphones. Если сайт пока не переведён на новый тип индексации, то вы будет видеть десктопный рендер.
Я лично просил вернуть функциональность двойного рендеринга обратно, и Джон Мюллер ответил, что передаст этот запрос команде разработки Search Console. Но никаких гарантий, что они это сделают, нет.
2. Инструмент проверки оптимизации для мобильных
Следующий метод просмотра обработанного HTML – это использовать инструмент проверки оптимизации для мобильных. Он обработает страницу, используя Googlebot for Smartphones, покажет скриншот визуализированной страницы и предоставит обработанный HTML-код.
Кроме того, он также покажет те ресурсы страницы, которые не загружаются должным образом, и консоль JavaScript с предупреждениями и ошибками (как и в инструменте проверки URL).
Примечание. Для работы с обработанным кодом его лучше скопировать в текстовый редактор, поскольку в самом инструменте это неудобно.
3. Проверка расширенных результатов
Из описаний предыдущих двух методов вы могли заметить одну общую тему: рендеры преимущественно сосредоточены на мобильных, а не десктоп-устройствах. Понятно, что сегодня мы живём в мобильном мире, и это должно быть в фокусе, но нам по-прежнему нужно проверять десктопные рендеры! Если сайт не переведён на mobile-first индексацию, то инструмент проверки URL будет использовать десктопный рендер.
Что же делать владельцу сайта?
Многие этого не знают, но вы также можете использовать инструмент проверки расширенных результатов (Rich Results Test), чтобы просмотреть обработанный HTML, основанный на Googlebot Desktop. В Google уже говорили об этом ранее, но многие SEO-специалисты по-прежнему не знают об этом способе.
После того, как вы проверили URL, вы можете просмотреть обработанный HTML, проблемы с загрузкой страницы и консоль JavaScript, которая содержит ошибки и предупреждения. И помните, это десктопный рендер, а не мобильный. Инструмент покажет вам, что user-agent, используемым для рендеринга, был Googlebot Desktop.
Теперь перейдём к тем инструментам, которые предлагают другие компании.
4. Краулеры
Методы, описанные выше, отлично подходят для проверки отдельных URL. Но что делать, если вам нужно проверить рендеринг в массовом порядке? Например, если ваш сайт содержит 10 тыс., 50 тыс. или 500 тыс. страниц, а вы хотите сверить статический и обработанный HTML? В данном случае оптимальный вариант – это использовать краулеры. Например, DeepCrawl, Screaming Frog или Sitebulb. Все они предоставляют возможность рендеринга JavaScript во время сканирования.
При настройке сканирования в DeepCrawl поставьте галочку на «Enable JavaScript-rendering».
В Screaming Frog используйте выпадающее меню на вкладке Rendering в разделе Spider Configuration.
Screaming Frog также позволяет просмотреть скриншот для каждой страницы, которую вы сканируете, и сравнить обработанный и статический HTML.
Sitebulb предлагает такую же функциональность, а также выделяет различия при сравнении.
5. Инструменты разработчика в Google Chrome
Иногда, проверяя страницу, нужно быстро просмотреть обработанный HTML – так, чтобы не запускать инструмент или сканирование сайта. Для этого можно использовать опцию Inspect elements в Chrome Dev Tools. Это быстрый способ проверить обработанный HTML-код страницы.
6. Плагин для Chrome
Наконец, для просмотра обработанного HTML можно также воспользоваться плагином View Rendered Source для Chrome. Этот плагин позволяет просматривать одновременно и статический и обработанный HTML. При этом он не только покажет обе версии кода, но и выделит различия между ними.
И несколько советов напоследок:
- Проверяйте обработанный HTML, чтобы убедиться, что основной контент корректно представлен в коде. Не полагайтесь на текущую версию Chrome, используйте специальные инструменты. При этом проверяйте и десктопный и мобильный рендеры.
- Проверьте важные директивы в метатегах robots. Эти теги могут сдвигаться на множество строчек вниз. Убедитесь, что с вашими директивами этого не произошло. Это может иметь огромное влияние на сайт с точки зрения SEO.
- Убедитесь, что атрибут rel=canonical корректно настроен в обработанном HTML. Убедитесь, что он вообще есть в коде!
- Проверьте структурированные данные. Убедитесь, что вся необходимая разметка на месте. Структурированные данные – это те элементы, которые часто упускают из виду.
- Проверьте навигацию и внутренние ссылки. Внутренние ссылки чрезвычайно важны, поскольку они помогают Google (и пользователям) находить дополнительный контент на сайте. Они также дают Google представление о том, что может находиться на другом конце ссылки.
- Если вы используете разные языковые версии и международный таргетинг, проверьте атрибуты hreflang. В моей практике были случаи, когда эти атрибуты полностью или частично отсутствовали в обработанном HTML-коде.
- Проверьте изображения. Просмотрите код изображений, альтернативный текст, атрибуты title и подписи.
