Чому SEO не працює: як перевірити рендеринг сторінок на сайті?

Практично всі сучасні вебсайти розробляються з орієнтацією на користувачів і на можливості рендерингу в браузерах. Зазвичай, браузери без проблем пораються навіть зі складними завданнями.

‍

Але якщо ми говоримо про органічний пошук, то тут усі пошукові системи ранжують вебсторінки, як HTML-документи. І у пошукових ботів, на відміну від сучасних браузерів, можливості обмежені. Якщо не потурбуватися про те, яким чином пошукові роботи бачать ваші сторінки, то можна програти в перегонах за топові позиції в органічному пошуку.

‍

Як перевірити рендеринг сайту та усунути помилки, які заважають ранжуванню, — розповідаємо далі.

Що таке рендеринг сторінок у SEO?

Рендеринг — це термін із веброзробки. Він позначає відмальовування коду вебдокумента в інтерактивну вебсторінку, яку ви фінально і бачите у своїх браузерах. Фактично рендеринг — це процес виконання всіх правил, прописаних у HTML-коді, JS-скриптах і CSS-стилях.

‍

Що відбувається в браузері під час відображення документа:

• Браузер отримує ресурси з сервера (HTML-код, CSS, JS, картинок);
• На основі отриманого HTML-коду, застосування правил із CSS і виконання JS формується DOM — Document Object Model;
• Завантажуються і розпізнаються стилі, формується CSSOM — CSS Object Model;
• На основі DOM і CSSOM формується render tree — набір об'єктів рендерингу. Render tree дублює структуру DOM, але сюди не потрапляють невидимі елементи (наприклад, або елементи зі стилем display:none;). Кожен рядок тексту представлений у дереві рендерингу як окремий renderer. А кожен об'єкт рендерингу містить відповідний йому об'єкт DOM (або блок тексту) і розрахований для цього об'єкта стиль. Простіше кажучи, render tree описує візуальне представлення DOM;
• Для кожного елемента render tree розраховується положення на сторінці — відбувається layout. Браузери використовують потоковий метод flow, за якого в більшості випадків достатньо одного проходу для розміщення всіх елементів (для таблиць проходів потрібно більше);
• Нарешті, відбувається відтворення всього вище перерахованого в браузері — painting.

‍

Механіка

Рендеринг, тобто відтворення сторінки в Google, починається після сканування, але до індексації. Механіка досить проста: краулер запитує сторінку і всі ресурси, необхідні для її відтворення.

‍

Далі дані передаються в Rendertron — headless chrome рішення для рендерингу сторінок, створене за допомогою Puppeteer. Там усі дані обробляються.

‍

Є два важливі чинники, які впливають на рендеринг:

1. Google намагається кешувати всі ресурси й не враховує правила HTTP-кешування. Це пов'язано з тим, що більшість вебмайстрів створюють їх бездумно, змушуючи користувачів постійно завантажувати один і той самий файл, хоча він не змінювався.
2. Google може не отримати всі додаткові ресурси, тому варто зменшити кількість запитів, необхідних для якісного відтворення сторінки.

‍

‍

Що стосується обробки JavaScript, то в Google прямо кажуть — для них важлива продуктивність, тому:

• обмежують споживання ресурсів процесора;
• можуть переривати виконання скриптів;
• і говорять про те, що надмірне споживання ресурсів ЦП негативно позначається на індексації.

Як перевірити рендеринг сторінок пошуковими роботами

Перший метод — Google Search Console

Цей інструмент допомагає вебмайстрам отримувати більше трафіку з органіки та дає розуміння, як пошукові системи сприймають контент сторінок.

‍

За будь-якою з адрес сайту, який є в індексі Google, можна переглянути прокрауленную сторінку:

Після кліка в правій частині екрана відкривається вікно, де відображається відрендеренний ботом HTML-код сторінки. Саме так пошуковий робот і обробив документ.

‍

Тут можна скопіювати HTML-код відрендеренної сторінки й вставити в будь-який з редакторів коду. А далі можна переглянути код на коректність, перевірити наявність усіх важливих семантичних елементів, розташування в DOM-дереві, мікророзмітку, внутрішні посилання та інше.

‍

Можна зберегти документ, як HTML і переглянути в будь-якому браузері візуально. Але надійніше — читати та перевіряти код, тому що сучасні браузери дуже розумні й часто можуть самі виправляти грубі помилки верстки та закривати теги.

Другий метод — якщо сайт не ваш і доступів до GSC немає

Цей метод необхідний, якщо ми хочемо порівняти рендеринг своїх сторінок і сторінок конкурента, перевірити, чи не віддають вони боту поліпшені сторінки з текстовим контентом, а користувачеві — більш функціональні версії.

Rich Snippets Testing Tool

Інструмент надсилає запит до сервера як нативні Google-боти. І відповідь, яку ви отримаєте, збігатиметься з відповіддю, що отримує пошуковий краулер.

Велика перевага інструменту — можливість вибрати тип пошукового бота між десктопом і мобайлом. Це корисно, коли на сайтах використовується метод оптимізації для мобільних пристроїв Dynamic Serving. Тобто, залежно від пристрою, який робить запит, сервер віддає різний HTML-код. Порівняння коду однієї сторінки між різними агентами може виявити, що, наприклад, десктоп отримує сторінки з текстом, а мобайл — без. Також на практиці ми стикалися з випадками, коли відрізнялася і мікророзмітка, яку отримували боти.

‍

Після завершення тесту натискаємо View Tested Page. І отримуємо вікно з відрендеренним HTML-кодом сторінки, вже знайоме нам з інтерфейсу Google Search Console.

Mobile-Friendly Test

Це інструмент тестування адаптивності сторінок. На відміну від інструменту Rich Snippets Testing Tool, тут не можна вибрати бота, який робитиме звернення до сервера.

Знову натискаємо View Tested Page і потрапляємо в те саме вікно, що й у попередньому інструменті.

На що звернути увагу під час перевірки коду?

Семантично важливі зони в контенті:

• назва сторінки в тезі title;
• описи сторінок у тегах meta;
• коректність посилань у тегах link;
• елементи мікророзмітки schema.org.

Візуально невідображувані, але важливі елементи верстки:

• заголовки документа в тегах h;
• текстові описи;
• кількість представлених елементів на сторінці (наприклад, карток товарів у лістингах);
• адреси зображень в атрибутах src тега img;
• коректність анкорів та адрес у посиланнях. 

Семантичні елементи верстки:

• теги article, section, nav, table та їхній вміст присутні;
• ці теги коректно розміщені в HTML-версії документа, яку проіндексував бот.

Порівняння відрендеренного коду з різних інструментів

Чи можна бути впевненим, що сторінка рендериться пошуковим ботом саме так, як ми бачимо в інструментах? Якщо йдеться про Google Search Console — скоріше так, ніж ні. А якщо говорити про інші інструменти, зокрема Rich Snippets Testing Tools і Mobile-Friendly Test, — вони можуть не завжди віддавати коректну інформацію.

Річ у тім, що рендеринг — це динамічний процес. І результат, який ми отримуємо, — це результат конкретної відповіді на конкретний запит у конкретний момент часу. Чи збігається він із тим, що отримає пошуковий краулер під час запиту до того ж ресурсу в інший проміжок часу? Можливо, але не гарантовано.

Для прикладу ми порівняли код, який зберігається в Google Search Console, з отриманим відрендереним кодом тієї самої сторінки з:

• GSC Live Test;
• Rich Snippets Testing Tool;
• Mobile-Friendly Test;
• Rendered Page Screaming Frog.

GSC vs GSC Live Test

У коді, отриманому з GSC Live Test, є відмінності у вигляді додавання слеша в кінці перед закриттям тегів. Але HTML, який зберігається в консолі, не містить таких слешів. Також Livetest не побачив скрипта googleads, який є в GSC-версії сторінки з індексу. Відрізняються і лапки. У версії з індексу вони виглядають так: ', а у версії з LiveTest ось так: ".

GSC vs Rich Snippets Testing Tool

У коді GSC є пара несуттєвих відмінностей. Наприклад, присутність скрипта googleads, якого немає в коді з Rich Snippets, як і в коді з Livetest. Але більш істотних відмінностей не виявлено.

GSC vs Mobile-Friendly Test

Mobile-Friendly Test зібрав усі відмінності двох попередніх тестів. У ньому немає скрипта, плюс перед закриттям тегів записуються слеші та підміняються лапки.

GSC vs Screaming Frog Rendered Page

У движка 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 і не рендерив їх окремо. Виправили це ще до релізу сайту. І всім рекомендуємо перевіряти це на ранніх етапах запуску.