Практично всі сучасні вебсайти розробляються з орієнтацією на користувачів і на можливості рендерингу в браузерах. Зазвичай, браузери без проблем пораються навіть зі складними завданнями.
Але якщо ми говоримо про органічний пошук, то тут усі пошукові системи ранжують вебсторінки, як 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. Там усі дані обробляються.
Є два важливі чинники, які впливають на рендеринг:
- Google намагається кешувати всі ресурси й не враховує правила HTTP-кешування. Це пов'язано з тим, що більшість вебмайстрів створюють їх бездумно, змушуючи користувачів постійно завантажувати один і той самий файл, хоча він не змінювався.
- 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 і не рендерив їх окремо. Виправили це ще до релізу сайту. І всім рекомендуємо перевіряти це на ранніх етапах запуску.
