Робот Google може читати JavaScript — якою повинна бути реакція SEO?

562

Від автора: традиційно пошукові системи читали і відображали тільки HTML-код веб-сайту. Це означало, що оптимізація коду HTML полягала в тому, на що орієнтувалися оптимізатори. Що це буде означати для пошукової оптимізації тепер, коли робот Googlebot може сканувати і індексувати JavaScript? Ми попросили кількох експертів з’ясувати це.

Щоб отримати ряд перспектив по темі читання роботом Google JavaScript, ми поставили нашим фахівцям наступні питання:

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

Які конкретні аспекти потрібно розглянути, якщо планується повторний запуск веб-сайту JavaScript?

Які зміни з точки зору ефективності та точності ви очікуєте від оновлень веб-рендеринга в Chrome?

І ось прийшли відповіді.

Martin Tauber. Керуючий партнер, Marketing Factory GmbH

З точки зору користувачів, веб-сайти на основі JavaScript надають великі можливості, тому що вони швидше і интерактивнее.

Однак Googlebot все ще відчуває труднощі з інтерпретацією JavaScript, і це означає, що розробка повинна бути надзвичайно чистою і проводитися у тісній співпраці з підрозділом SEO, щоб уникнути неприємних сюрпризів.

Dominik Wojcik. Керуючий директор, Trust Agents

Можливості полягають у тому, що тепер немає двох окремих світів програмування (наприклад, для екранованих фрагментів), дозволяючи зосередитися на чистому коді і чистої веб-середовищі. Поки розробники розглядають прогресивне вдосконалення і розвиток своїх веб-додатків відповідно, Google повинен відмінно справлятися з цим.

Однак є приховані проблеми. Яка структура використовується? Буде рендеринг на стороні клієнта і чи можливо реалізувати рендеринг на стороні сервера? Чи можна реалізувати изоморфный JavaScript? Є JavaScript реалізованим всередині або зовні? Як оптимізаторам, нам потрібно буде зробити неймовірну кількість тестів і спробувати різні речі, щоб Google індексував і зважував наші сторінки на свій розсуд.

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

Якщо Google остаточно переключиться на версію Chrome вище V49, тоді ми можемо використовувати безглавую Chrome у поєднанні з чимось на зразок Rendertron для створення тестових середовищ, які дозволять нам змоделювати налаштування, аналогічну налаштуванні Googlebot. Це допоможе краще зрозуміти, як і що може інтерпретувати Google і спростить SEO-оптимізацію.

Bartosz Goralwicz. Співзасновник і керівник відділу SEO, Elephate

На саміті Searchmetrics в листопаді 2017 року Bartosz Goralwicz з Elephate розповів про взаємини між роботом Googlebot і JavaScript:

Stephan Czysch. Засновник і керуючий директор,Trust Agents

Ми не хочемо, щоб пошукові системи (або агентства) чули, як люди кажуть: «до Речі, ми скоро переходимо на JavaScript. Чи є щось, про що ми повинні думати з точки зору SEO? Не повинні? Але було б здорово, якби можна було побіжно ознайомитися, перш ніж почати з понеділка нове життя з новим сайтом». Цей сценарій неминуче закінчиться повним хаосом. Bartosz [відео] надав чудовий погляд на тему JavaScript і SEO.

Крім того, щоб запитати, що може робити Google, оптимізатори повинні стежити, коли перезапускают веб-сайт, за тим, що бот може бачити, і встановлювати те, що відрізняється від старого веб-сайту. Нещодавно я переглядав сайт, на якому повна внутрішня система посилань був переплутаний після перезапуску JavaScript, тому що логіка посилань старого сайту не була перенесена. Були також проблеми з hreflang. Тому важливо працювати з контрольним списком бажаних функцій SEO». Крім того, ви повинні запитати, що для ваших цілей значить рендеринг JavaScript: яке обладнання він використовує для доступу до вашого сайту і як це вплине на час завантаження? Для отримання додаткової інформації по цій темі, рекомендую цю статтю Addy Osmani.

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

Навіть з покращеною здатністю сканувати JavaScript, Google віддає перевагу чистий HTML-вміст, тому що він споживає менше ресурсів. Питання полягає не в тому, чи може Google читати і відображати JS, а чи можете ви і хочете зняти частину роботи з Google. Якщо мій контент може бути прочитаний, він працює і швидко завантажується без JS, то для мене це все ж краще.

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

При повторному запуску сторінки переконайтеся, що контент, який ви хочете присвоїти, працює без JavaScript. Це включає не тільки основний зміст, але і навігаційні елементи. На багатьох сторінках немає меню, коли JS відключений. Має сенс не включати кожну окрему функцію, а задавати питання, дійсно функція необхідна для вашого бізнесу і вашої цільової аудиторії. Яким було б вплив, якщо б якась функція не спрацювала? А потім виконайте відповідні тести.

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

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

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

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

В основному, 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? Ви вже внесли зміни на свої веб-сайти? Чи може виявили що-небудь цікаве у своїх тестах?