Практично всі сучасні вебсайти розробляються з орієнтацією на користувачів і на можливості рендерингу в браузерах. Зазвичай, браузери без проблем пораються навіть зі складними завданнями.
Але якщо ми говоримо про органічний пошук, то тут усі пошукові системи ранжують вебсторінки, як HTML-документи. І у пошукових ботів, на відміну від сучасних браузерів, можливості обмежені. Якщо не потурбуватися про те, яким чином пошукові роботи бачать ваші сторінки, то можна програти в перегонах за топові позиції в органічному пошуку.
Як перевірити рендеринг сайту та усунути помилки, які заважають ранжуванню, — розповідаємо далі.
Рендеринг — це термін із веброзробки. Він позначає відмальовування коду вебдокумента в інтерактивну вебсторінку, яку ви фінально і бачите у своїх браузерах. Фактично рендеринг — це процес виконання всіх правил, прописаних у HTML-коді, JS-скриптах і CSS-стилях.
Рендеринг, тобто відтворення сторінки в Google, починається після сканування, але до індексації. Механіка досить проста: краулер запитує сторінку і всі ресурси, необхідні для її відтворення.
Далі дані передаються в Rendertron — headless chrome рішення для рендерингу сторінок, створене за допомогою Puppeteer. Там усі дані обробляються.
Що стосується обробки JavaScript, то в Google прямо кажуть — для них важлива продуктивність, тому:
Цей інструмент допомагає вебмайстрам отримувати більше трафіку з органіки та дає розуміння, як пошукові системи сприймають контент сторінок.
За будь-якою з адрес сайту, який є в індексі Google, можна переглянути прокрауленную сторінку:
Після кліка в правій частині екрана відкривається вікно, де відображається відрендеренний ботом HTML-код сторінки. Саме так пошуковий робот і обробив документ.
Тут можна скопіювати HTML-код відрендеренної сторінки й вставити в будь-який з редакторів коду. А далі можна переглянути код на коректність, перевірити наявність усіх важливих семантичних елементів, розташування в DOM-дереві, мікророзмітку, внутрішні посилання та інше.
Можна зберегти документ, як HTML і переглянути в будь-якому браузері візуально. Але надійніше — читати та перевіряти код, тому що сучасні браузери дуже розумні й часто можуть самі виправляти грубі помилки верстки та закривати теги.
Цей метод необхідний, якщо ми хочемо порівняти рендеринг своїх сторінок і сторінок конкурента, перевірити, чи не віддають вони боту поліпшені сторінки з текстовим контентом, а користувачеві — більш функціональні версії.
Інструмент надсилає запит до сервера як нативні Google-боти. І відповідь, яку ви отримаєте, збігатиметься з відповіддю, що отримує пошуковий краулер.
Велика перевага інструменту — можливість вибрати тип пошукового бота між десктопом і мобайлом. Це корисно, коли на сайтах використовується метод оптимізації для мобільних пристроїв Dynamic Serving. Тобто, залежно від пристрою, який робить запит, сервер віддає різний HTML-код. Порівняння коду однієї сторінки між різними агентами може виявити, що, наприклад, десктоп отримує сторінки з текстом, а мобайл — без. Також на практиці ми стикалися з випадками, коли відрізнялася і мікророзмітка, яку отримували боти.
Після завершення тесту натискаємо View Tested Page. І отримуємо вікно з відрендеренним HTML-кодом сторінки, вже знайоме нам з інтерфейсу Google Search Console.
Це інструмент тестування адаптивності сторінок. На відміну від інструменту Rich Snippets Testing Tool, тут не можна вибрати бота, який робитиме звернення до сервера.
Знову натискаємо View Tested Page і потрапляємо в те саме вікно, що й у попередньому інструменті.
Чи можна бути впевненим, що сторінка рендериться пошуковим ботом саме так, як ми бачимо в інструментах? Якщо йдеться про Google Search Console — скоріше так, ніж ні. А якщо говорити про інші інструменти, зокрема Rich Snippets Testing Tools і Mobile-Friendly Test, — вони можуть не завжди віддавати коректну інформацію.
Річ у тім, що рендеринг — це динамічний процес. І результат, який ми отримуємо, — це результат конкретної відповіді на конкретний запит у конкретний момент часу. Чи збігається він із тим, що отримає пошуковий краулер під час запиту до того ж ресурсу в інший проміжок часу? Можливо, але не гарантовано.
Для прикладу ми порівняли код, який зберігається в Google Search Console, з отриманим відрендереним кодом тієї самої сторінки з:
У коді, отриманому з GSC Live Test, є відмінності у вигляді додавання слеша в кінці перед закриттям тегів. Але HTML, який зберігається в консолі, не містить таких слешів. Також Livetest не побачив скрипта googleads, який є в GSC-версії сторінки з індексу. Відрізняються і лапки. У версії з індексу вони виглядають так: ', а у версії з LiveTest ось так: ".
У коді GSC є пара несуттєвих відмінностей. Наприклад, присутність скрипта googleads, якого немає в коді з Rich Snippets, як і в коді з Livetest. Але більш істотних відмінностей не виявлено.
Mobile-Friendly Test зібрав усі відмінності двох попередніх тестів. У ньому немає скрипта, плюс перед закриттям тегів записуються слеші та підміняються лапки.
У движка Screaming Frog можливості з рендерингу сторінок кращі, ніж у Google - відмінності спостерігаються в цілих блоках. Наприклад, для Google-бота цей блок був display:none і порожній, а у відрендереної версії в Screaming Frog він же display:block із внутрішніми блоками, в яких є контент.
Насправді це малоймовірно. Але якщо такий форс-мажор і трапиться, у нас завжди залишається основний робочий інструмент — веб-браузер. Щоб перевірити, який HTML-документ отримав браузер, потрібно вибрати файл сторінки в dev-панелі у вкладці network. А далі у вкладці Preview буде видно візуальні відмінності між отриманою сторінкою і сторінкою після виконання всіх додаткових скриптів.
Але найцікавішою і пріоритетною для нас буде вкладка Response. Тут можна побачити та розібрати HTML-документ, який отримав браузер.
Стрілкою на скріншоті показана кнопка Beautifier, яка полегшить читання коду. Якщо на сайті немає окремого Server Side Rendering для бота, важливо, щоб у цьому документі ми бачили всі тематичні блоки та семантичні елементи. Тоді, незалежно від ресурсів рендерингу в пошукових роботів, можна бути впевненим, що бот точно отримав усе, що нам потрібно.
На практиці ми часто стикаємося з ситуаціями, коли фахівці з інхаус-команд не розуміють, чому сайт не росте. Річ у тім, що пошукові роботи просто не бачать більшої частини контенту на цих ресурсах, — що призводить до великих втрат у перегонах за топові позиції в пошуковій видачі. З цієї причини рекомендуємо використовувати для перевірки рендерингу сторінок свого ресурсу GSC, а для перевірки сторінок конкурентів — Rich Snippets Testing Tools.
У випадку з нашими клієнтами ми просто не допускаємо, щоб на їхньому сайті не був налаштований коректний рендеринг. Наприклад, коли ми почали роботу з FlyArystan, їхній ресурс містив усі мовні версії на одному URL і не рендерив їх окремо. Виправили це ще до релізу сайту. І всім рекомендуємо перевіряти це на ранніх етапах запуску.
Якщо ви тільки плануєте вихід в онлайн або хочете зрозуміти, чому сайт не росте — отримайте консультацію наших фахівців. У команди Promodo є експертиза в багатьох нішах, і для кожного бізнесу ми готові розробити індивідуальний план зростання з чіткими KPI.
Захочете отримати юзабіліті-аудит і персональні рекомендації для свого інтернет-магазину — напишіть нам.