Робот Google может читать JavaScript — какой должна быть реакция SEO?

Бот Google может читать JavaScript — какой должна быть реакция SEO?

От создателя: традиционно поисковые системы читали и показывали только HTML-код веб-сайта. Это означало, что оптимизация кода HTML заключалась в том, на что ориентировались оптимизаторы. Что это будет означать для поисковой оптимизации сейчас, когда робот Googlebot может также исследовать и индексировать JavaScript? Мы попросили нескольких профессионалов выяснить это.

Чтоб получить ряд перспектив по теме чтения роботом Гугл JavaScript, мы задали нашим специалистам последующие вопросы:

Google говорит, что Googlebot может исследовать веб-сайты, основанные на JavaScript — какие препядствия и возможности вы видите в этом для оптимизаторов?

Какие определенные аспекты нужно рассмотреть, если планируется повторный пуск веб-сайта JavaScript?

Какие конфигурации с точки зрения эффективности и точности вы ждете от обновления веб-рендеринга в Chrome?

И вот пришли ответы.

Martin Tauber. Управляющий партнер, Marketing Factory GmbH

С точки зрения юзеров, веб-сайты на основе JavaScript предоставляют огромные возможности, потому что они быстрее и интерактивнее.

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

Dominik Wojcik. Управляющий директор, Trust Agents

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

Но есть скрытые проблемы. Какая структура употребляется? Будет ли рендеринг на стороне клиента и может быть ли реализовать рендеринг на стороне сервера? Можно ли воплотить изоморфный JavaScript? Является ли JavaScript реализованным снутри или снаружи? Как оптимизаторам, нам необходимо будет сделать невероятное количество тестов и испытать разные вещи, чтобы Google индексировал и взвешивал наши странички по своему усмотрению.

Перед повторным пуском следует принять взвешенное решение насчёт структуры, которая будет употребляться. Следует учитывать способность к сканированию и производительности. В эталоне должна быть создана тестовая среда, которая позволит тестировать текущую разработку снаружи, если используется рендеринг на стороне клиента. Тем не наименее, я настоятельно рекомендую использовать также рендеринг на стороне сервера. Это хоть и оказывает влияние на производительность сервера, но всё же должно минимизировать опасности. Прежде всего, вам действительно нужно тестировать, тестировать и ещё раз тестировать, используя fetch & render, чтоб узнать, что находит, индексирует и сканирует Googlebot.

Если Гугл окончательно переключится на версию Chrome выше V49, тогда мы можем использовать безглавую Chrome в сочетании с кое-чем вроде Rendertron для создания тестовых сред, которые позволят нам смоделировать настройку, аналогичную настройке Googlebot. Это поможет лучше осознать, как и что может интерпретировать Гугл и упростит SEO-оптимизацию.

Bartosz Goralwicz. Соучредитель и управляющий отдела SEO, Elephate

На саммите Searchmetrics в ноябре 2017 года Bartosz Goralwicz из Elephate сказал о взаимоотношениях между роботом Googlebot и JavaScript:

Stephan Czysch. Основоположник и управляющий директор,Trust Agents

Мы не желаем, чтобы поисковые системы (или агентства) слышали, как люди молвят: «Кстати, мы скоро переходим на JavaScript. Есть ли что-то, о чём мы должны мыслить с точки зрения SEO? Не должны? Но было бы здорово, если бы можно было быстро ознакомиться, прежде чем начать с пн. новую жизнь с новым сайтом». Этот сценарий безизбежно закончится полным хаосом. Bartosz [в видео выше] предоставил превосходный взгляд на тему JavaScript и SEO.

Не считая того, чтобы спросить, что может делать Гугл, оптимизаторы должны следить, когда перезапускают сайт, за тем, что бот может созидать, и устанавливать то, что отличается от старенького веб-сайта. Недавно я просматривал сайт, на котором полная внутренняя система ссылок была спутана после перезапуска JavaScript, потому что логика ссылок старенького сайта не была перенесена. Были также препядствия с hreflang. Поэтому важно работать с контрольным перечнем желаемых «функций SEO». Кроме того, вы должны спросить, что для ваших целей означает рендеринг JavaScript: какое оборудование он употребляет для доступа к вашему сайту и как это воздействует на время загрузки? Для получения дополнительной инфы по этой теме, рекомендую эту статью Addy Osmani.

Sebastian Adler. Консультант SEO, leap.de

Даже с усовершенствованной способностью сканировать JavaScript, Google предпочитает незапятнанный HTML-контент, потому что он потребляет меньше ресурсов. Вопрос заключается не в том, может ли Гугл читать и отображать JS, а сможете ли вы и хотите ли снять часть работы с Гугл. Если мой контент может быть прочитан, он работает и стремительно загружается без JS, то для меня это все же лучше.

Способность рендерить всегда зависит от технологии, стоящей за ней, и, как произнес Bartosz (уважаю его за все усилия, которые он вносит в свои эксперименты и исследования!), Вы должны на сто процентов понять эту технологию, если вы желаете использовать ее наилучшим образом, Огромная возможность тут заключается в минимизации рисков, предоставляя принципиальный контент как HTML и используя JS, только как он предназначен: для дополнительных функций. Если вы стопроцентно выполняете в JavaScript, самая большая трудность заключается в поиске ошибок.

При повторном запуске странички убедитесь, что контент, который вы желаете присвоить, работает без JavaScript. Это включает не только основное содержание, но и навигационные элементы. На многих страничках нет меню, когда JS отключен. Имеет смысл не включать каждую отдельную функцию, а задавать вопрос, вправду ли функция необходима для вашего бизнеса и вашей мотивированной аудитории. Каким было бы воздействие, если бы какая-то функция не сработала? А потом выполните соответствующие тесты.

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

Несколько вещей наверное будут обработаны быстрее или станут более незапятнанными. Но основная проблема остается прежней. Код с ошибкой (с точки зрения применяемого двигателя) не может быть интерпретирован. Нам необходимо выяснить, как двигатель интерпретирует наш код. Во время разработки это изменяет инструмент, который мы должны использовать для отладки. Но если у вас есть ваши самые принципиальные активы в качестве загружаемых файлов HTML (и т. д.), тогда вам не необходимо беспокоиться — вы можете сосредоточиться на правильной работе SEO.

Björn Beth. Директор по проф услугам, Searchmetrics

Мы должны различать сканирование и индексирование. Гугл может сканировать JavaScript, но для этого требуется еще больше ресурсов, чем при сканировании незапятнанного HTML. Для индексатора более проблематично показывать ссылки (URL-адреса), которые он получает от искателя, с помощью службы веб-рендеринга (WRS), аналогично Fetch & Render в Search Console. Для этого Гугл использует собственный браузер Chrome (версия 41). С помощью браузера он пробует создать Document Object Model (DOM) и интерпретировать страничку так же, как она будет отображаться в браузере. Это может привести к дилеммам, поскольку Google, например (как показано в тестах, выполняемых Distilled и Bartosz Goralewicz), не может совладать с проблемами в коде, или, если появляются другие большие проблемы при рендеринге, так что Гугл перестает отображать страницу через пять секунд.

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

До этого чем переходить с веб-сайта на базе HTML на фреймворк или библиотеку на базе JavaScript, вы должны убедиться, что включен посторонний рендеринг. Например, React поставляется с своим решением, которое называется renderToString. Он употребляет независимый от браузера DOM-интерфейс, который показывает JavaScript на сервере, создает DOM и посылает его боту. AngularJS использует Angular Universal. Это обосновывает клиенту, как важен предварительный визуализированный HTML. Потом клиент получает JavaScript, как требуется. Тем не наименее, вы можете работать с безголовым Chrome на сервере и отправлять за ранее обработанный HTML-код боту.

До этого всего, я ожидаю, что более резвым и эффективным будет рендеринг от Chrome 59, продвигающийся к производительности вровень с чистым HTML. Только тесты покажут, вправду ли это так.

Сканирование через mud: оценка здоровья вашего веб-сайта

Проанализируйте как HTML, так и JavaScript с оптимизацией структуры веб-сайта, включая JavaScript-сканер с помощью Searchmetrics! Ваши достоинства:

Сканирование всех соответствующих фреймворков JavaScript, включая Angular и React

Увеличение эффективности веб-сайта за счет приоритетного перечня технических проблем

Сравнение обходов с внедрением JavaScript и без него

А что думаешь ты?

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

Создатель: Lea Manthey

По материалам webformyself.com

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *