Індексація сайту та технічне SEO: повний посібник зі сканування

2) Як Googlebot та мобільна індексація (mobile-first indexing) впливають на видимість сторінок

Хто такий Googlebot і що він реально бачить на сторінці

Googlebot – це основний пошуковий робот Google, який виконує crawling: заходить на URL, отримує відповідь сервера (HTTP status codes), завантажує HTML та пов'язані ресурси. Важливо розуміти практичну річ: Googlebot не "оцінює сайт як людина" з першого разу. Він діє поетапно: спочатку сканує, потім може виконати rendering (відмальовку), і тільки після цього приймає рішення про indexing — Додавання сторінки до індексу.

Від того, наскільки швидко та коректно Googlebot отримує доступ до критичних ресурсів (CSS/JS/зображення) та самого HTML, безпосередньо залежить індексація сайту. Якщо бот регулярно упирається в помилки 403/404, ланцюжки редиректів або блокування в Robots.txt, Ви отримуєте втрати по видимості навіть при хорошому контенті.

Ця думка особливо важлива для сайтів на сучасних фреймворках і для e-commerce, де значна частина контенту може динамічно підвантажуватися.

Mobile-first indexing: чому мобільна версія стала «головною»

Mobile-first indexing означає, що Google насамперед використовує мобільну версію сторінки для ранжування та індексації. Тобто робот орієнтується те що, що бачить (і може відрендерити) на мобільному представленні. Якщо мобільна версія урізана за текстом, приховує блоки, має інше меню чи неповну розмітку – ви самі знижуєте шанси на повноцінну індексацію та стабільні позиції.

Типова помилка: на робочому столі є контент і перелінковка, а на мобільному — «акордеони» без коректного малювання, скорочені описи або відсутні внутрішні посилання. Для Google це може виглядати як бідніша сторінка — і рішення щодо індексації сайту буде прийматися на основі саме цієї версії.

Як мобільна версія впливає на контент, посилання та crawl budget

Googlebot повинен ефективно витрачати ресурси обходу - це і є crawl budget. Мобільна версія, перевантажена скриптами, важкими зображеннями та зайвими параметричними URL-адресами, часто уповільнює сканування та підвищує ймовірність «недоходу» до важливих сторінок.

Перевірте, чи збігаються ключові елементи на мобільній та десктопній версії:

• текстові блоки (описи категорій, FAQ, характеристики товару);
• внутрішні посилання (на категорії, фільтри, бренди, товари);
• meta robots та директиви noindex/nofollow (Вони не повинні «випадково» відрізнятися);
• канонізація (Canonical URL) та редиректи, включаючи редирект 301 при зміні URL-адреси.

Якщо мобільна версія «легша» з погляду контенту та посилань, Googlebot отримує менше сигналів про структуру сайту — у результаті падає глибина обходу та погіршується індексація пріоритетних розділів.

Структуровані дані та JavaScript: тонкі місця rendering

Структуровані дані (schema.org) допомагають Google зрозуміти тип сторінки (товар, стаття, організація) та іноді впливають на розширені результати. Але при javascript seo розмітка часто вставляється через JS і може не встигати коректно відрендеруватися. Тоді Googlebot в індексі зберігає сторінку без потрібних сигналів — і ви втрачаєте не лише сніпети, а й передбачуваність індексації.

Практичне правило: критичний контент та розмітка мають бути доступні максимально «прямо» — або у вихідному HTML, або через надійний серверний рендеринг/пререндер.

Як перевіряти, що Googlebot бачить мобільну версію правильно

Для контролю використовуйте Google Search Console: у URL Inspection Tool дивіться, чи доступна сторінка, чи дозволено скануванняяка версія вибрана канонічної і чи є проблеми з обробкою. Додатково аналізуйте звіт Page Indexing report: він покаже, які URL-адреси потрапили в індекс, а які виключені, і з якої причини. Це найпряміший шлях керувати індексація сайту через дані, а чи не припущення.

3) Карта процесів: як сторінка потрапляє в індекс - від першого URL до потрапляння у видачу

Крок 1. Виявлення URL: звідки Google дізнається про сторінку

Будь-яка індексація сайту починається не з «додавання до індексу», а з виявлення URL. Google може дізнатися про сторінку з кількох джерел: внутрішні посилання, зовнішні посилання, файл Sitemap.xml, а також ручне надсилання на перевірку через Google Search Console (URL Inspection Tool). Якщо URL не виявлено, вона не буде ні просканована, ні проіндексована — навіть якщо сторінка ідеально оптимізована.

На практиці для українських проектів найчастіше працюють два «прискорювачі»: коректна структура внутрішньої перелінковки (категорії → підкатегорії → товари/статті) та актуальна Sitemap.xml без сміттєвих URL (параметрів, дублів, сторінок з редиректами).

Крок 2. Crawling: сканування та перевірка доступності сторінки

Після виявлення Googlebot переходить до crawling - Завантажує HTML і фіксує відповідь сервера. Тут критичні http status codes: 200 означає «ок», 301/302 – редирект, 404 – не знайдено, 401/403 – доступ закритий. Будь-який зайвий ланцюжок редиректів чи нестабільний сервер з'їдають crawl budget та уповільнюють проходження сайту.

На цьому етапі також враховуються обмеження доступу: Robots.txt може заборонити сканування розділів, а meta robots або заголовок x-robots-tag - Вплинути на подальше рішення про індексацію (наприклад, через noindex).

Крок 3. Rendering: як Google «намальовує» сторінку і що може піти не так

Далі Google може виконати rendering — відображення сторінки, включаючи JavaScript. Для сайтів на React/Vue/Next та для інтернет-магазинів з динамічними фільтрами це ключова ділянка: якщо контент, посилання або структуровані дані з'являються лише після складного завантаження, Googlebot може побачити неповну версію сторінки.

З урахуванням mobile-first indexing Малювання важливе саме для мобільної версії: якщо на мобільній приховані тексти, відсутні блоки перелінкування або інакше влаштовані елементи навігації, це впливає на підсумкове розуміння сторінки та її потенціал у пошуку.

Крок 4. Оцінка якості та «право на індекс»: чому проскановано ≠ проіндексовано

Навіть після успішного сканування Google вирішує, чи варто додавати сторінку до індексу. На рішення впливає якість контенту, унікальність, корисність, відсутність тонких сторінок, а також загальна логіка сайту. Звідси й часті статуси в Search Console на кшталт Crawled – currently not indexed: бот сторінку бачив, але вважав її недостатньо цінною або надто схожою на інші

Типовий тригер проблем - дублі сторінок: однакові товари в різних категоріях, параметри фільтра, сортування, трекінгові мітки. Без контролю дублів ви розмиваєте сигнали та ускладнюєте індексацію сайту.

Крок 5. Канонікалізація: як вибирається Canonical URL і що робити з дублями

Перед індексацією Google визначає, яку URL вважати основною. Canonical URL. Це особливо важливо, коли той самий контент доступний за кількома адресами. Ви можете підказати канонікал через тег canonical, але фінальне рішення залишається за Google - Звідси статус Google chose different canonical than user.

Якщо на сайті використовуються редиректи, важливо, щоб постійні переїзди сторінок оформлялися як редирект 301, а не ланцюжками 302/307. Інакше Google довше «переучуватиме» індекс і може тримати в системі старі адреси.

Крок 6. Індексація та оновлення: як працює переіндексація сторінки

Коли URL вибрано канонічним та проходить перевірки, відбувається indexing — сторінка потрапляє до індексу і потенційно може з'являтися у видачі. Але на цьому процес не закінчується: контент змінюється, ціни оновлюються, з'являються нові блоки і потрібна переіндексація сторінки.

Переіндексація зазвичай запускається природно (Googlebot знову приходить за посиланнями та Sitemap.xml), але для важливих URL можна прискорювати процес через Google Search Console: перевірка URL-адрес та запит на повторне сканування. Важливо: це не «кнопка гарантії», а сигнал, який працює найкраще, коли сайт технічно чистий, без блокувань, дублів та хаотичних змін.

4) Crawl budget: як розподіляється ліміт сканування і чому він важливий для SEO для бізнесу

Що таке crawl budget і чому без нього не буває стабільної індексації

Crawl budget - Це умовний «ліміт» сканування, який Googlebot готовий витратити ваш сайт за певний період. Це не один фіксований показник, а комбінація двох речей: скільки сторінок Google може просканувати без шкоди для вашого сервера та скільки сторінок Google вважає за потрібне сканувати, виходячи з цінності сайту та попиту.

Для SEO для бізнесу це критично: якщо у вас інтернет-магазин на десятки тисяч URL, то неправильний розподіл crawl budget призводить до того, що Googlebot витрачає ресурси на сміттєві сторінки, а комерційно важливі категорії та картки товарів оновлюються в індексі повільно. Підсумок падає керованість, а індексація сайту стає «випадковою».

Ця цитата добре протверезить: завдання не «дати роботу нескінченний список URL», а підсвітити пріоритетні сторінки і прибрати зайве.

Як Google розподіляє ліміт: швидкість, важливість URL та помилки

На практиці crawl budget формується довкола трьох груп сигналів:

1) Швидкість та стабільність сервера. Якщо сайт відповідає повільно або періодично віддає 5xx, Googlebot знижує активність, щоб не перевантажувати ресурс. Це особливо помітно при пікових навантаженнях та поганій оптимізації кешування.

2) Важливість та «цінність» URL. Сторінки з хорошою внутрішньою посилальною підтримкою та зовнішніми посиланнями скануються частіше. Також впливає регулярність оновлень: розділи, що часто оновлюються. Googlebot намагається оминати активніше.

3) Помилки та безвиході. Сторінки з 404/410, «м'якими» помилками (Soft 404), заборонами 401/403, нескінченними параметрами та ланцюжками редиректів – це втрати бюджету без віддачі.

"Кожен зайвий редирект і кожен дубль - це мінус одна спроба Googlebot дійти до сторінки, яка приносить продаж."

Типові «пожирачі» crawl budget на сайтах бізнесу

Якщо ви бачите в Google Search Console статус на зразок Discovered – currently not indexed або довге оновлення асортименту у пошуку, часто причина у тому, що бюджет з'їдають «технічні клони» сторінок. Найчастіші сценарії:

• параметри фільтрів, сортувань, пагінації та трекінгові мітки, що створюють тисячі URL;
• дублі сторінок через кілька варіантів URL (зі слешем/без, http/https, www/без);
• ланцюжки редиректів та неправильні переїзди замість одного редирект 301;
• сторінки пошуку по сайту, «порожні» категорії та тонкі товарні картки;
• медіа-URL та технічні ендпоінти, випадково відкриті для обходу.

Усі ці елементи безпосередньо погіршують індексація сайту, тому що Googlebot витрачає час на низькопріоритетні сторінки замість «грошових».

Як зрозуміти, що crawl budget обмежує зростання: практичні ознаки

Є кілька характерних сигналів, що проблема не в контенті, а в скануванні:

— у звіті Page Indexing report зростає частка «Excluded», особливо з причин «Duplicate without user-selected canonical», «Page with redirect», «Blocked by robots.txt»;

— нові товари/сторінки довго не потрапляють до індексу, незважаючи на наявність у Sitemap.xml;

- Часті статуси Crawled – currently not indexed за великої кількості схожих сторінок;

— у логах сервера видно, що Googlebot регулярно ходить на параметричні URL-адреси, а важливі категорії відвідує рідко.

Як оптимізувати crawl budget та прискорити індексацію без хаосу

Робочий підхід — «стратегія, а не хаос»: зменшити кількість марних URL-адрес і посилити пріоритет важливих. На практиці це поєднання заходів: коректне налаштування Canonical URL для дублів, акуратне використання noindex (або x-robots-tag для файлів), закриття зайвих розділів у Robots.txt (тільки там, де не потрібен crawling), а також чиста структура внутрішніх посилань та актуальна Sitemap.xml.

Якщо все зроблено системно, Googlebot витрачає crawl budget на сторінки, які реально дають трафік, який конвертує - і індексація сайту стає передбачуваною та керованою.

5) Діагностика індексації через Google Search Console: звіти та базова логіка перевірки

Де в Search Console дивитися індексацію: базова карта розділів

Якщо вам потрібна керована індексація сайту, Google Search Console — це головне джерело правди: тут видно, що Google вважає, що індексується, що виключає, і з яких причин. Для діагностики індексації насамперед використовуйте два місця:

1) Page Indexing report (Звіт про індексування сторінок) — агрегує статуси по всіх URL-адресах і показує динаміку.

2) URL Inspection Tool - Точкова перевірка конкретної адреси: останній обхід Googlebot, канонікал, можливість сканування, результат індексації.

Додатково корисні: звіт з Sitemap.xml (подача та обробка картки сайту) та розділ «Налаштування сканування»/статистика сканування (якщо є у вашому обліковому записі) — для аналізу активності Googlebot.

Page Indexing report: як читати статуси та не плутати причини

У звіті про індексування логіка проста: Google ділить URL на проіндексовані та виключені (Excluded). Усередині виключених різні сценарії, і у кожного свій «рівень терміновості». Типові статуси, які найчастіше бачать власники сайтів в Україні:

- Crawled – currently not indexed (Проскановано, але не в індексі);

- Discovered – currently not indexed (Виявлено, але не проскановано);

- Duplicate без user-selected canonical (Дублікат без заданого canonical);

- Google chose different canonical than user (Google вибрав інший канонічний URL);

- Page with redirect (Сторінка - редірект);

- Blocked by robots.txt (заблоковано Robots.txt);

- Soft 404 (сторінка виглядає як "не знайдено", хоча віддає 200);

- 404, 401, 403 (не знайдено/немає авторизації/доступ заборонено).

Ключ: той самий симптом (ні в індексі) може бути викликаний різними факторами — від дублів до обмежень сканування.

Пріоритети виправлень: що робити спочатку, щоб прискорити зростання

Щоб не йти в хаос, сортуйте проблеми впливу на трафік та конверсії. Практична пріоритизація:

• Спочатку критичні помилки доступу: 401/403/404 на важливих сторінках, масові 5xx, неправильні редиректи (в т.ч. ланцюжки замість одного редирект 301).
• Далі – блокування сканування: перевірте Robots.txt та meta robots, щоб випадково не закрити категорії/картки товарів; окремо оцініть, де потрібен noindexа де він ламає видимість.
• Потім - дублі та канонікалізація: налаштування Canonical URL, усунення дублів сторінок, нормалізація параметрів
• Після — якість та «тонкі» сторінки: причини Crawled – currently not indexed часто вирішуються поліпшенням контенту та внутрішньої перелінковки.

Такий порядок зазвичай найшвидше покращує індексація сайту і розвантажує crawl budget.

URL Inspection Tool: точкова перевірка та швидкі гіпотези

Інструмент перевірки URL корисний, коли потрібно зрозуміти долю конкретної сторінки: чи бачить її Googlebot, чи дозволено сканування, яка обрана канонічна адреса, і чи є проблеми з рендерингом (актуально для javascript seo та mobile-first indexing).

Практичний сценарій: ви відкриваєте URL → дивіться «Сторінка в індексі Google?» → перевіряєте «Канонічний URL (користувач/Google)» → оцінюєте «Покриття» та «Сканування дозволено?». Якщо все ок, можна запросити переобхід (це допомагає для переіндексація сторінки після важливих правок).

Чек-лист «швидкої логіки» діагностики: 5 хвилин на URL

Щоб щоразу не винаходити процес, використовуйте коротку послідовність:

1) Чи є URL у Sitemap.xml і чи ведуть на нього внутрішні посилання?

2) Який статус у Page Indexing report і що саме написано через виняток?

3) Що показує URL Inspection Tool: доступність, last crawl, canonical, рендеринг?

4) Чи немає блокувань Robots.txt, meta robots, x-robots-tag, випадкового noindex?

5) Чи не є сторінка дублем чи редиректом (Page with redirect), чи немає Soft 404?

"Search Console не проводить індексацію - вона показує, де саме ваша логіка сайту розходиться з логікою Google."

З цією базовою логікою ви швидше переходите від «чому сторінка не індексується» до конкретного плану виправлень, що реально впливає на видимість та зростання органічного трафіку.

6) URL Inspection Tool: як правильно перевіряти конкретну сторінку та запускати переіндексацію

Навіщо потрібен URL Inspection Tool і коли він корисніший за звіти

URL Inspection Tool в Google Search Console - Це "лупа" для діагностики конкретного URL. Якщо Page Indexing report показує картину по сайту в цілому, то цей інструмент відповідає на прикладні питання: чи бачить Googlebot сторінку, чи можна її сканувати, яка версія вважається канонічною, як пройшли crawling і rendering, і чому сторінка потрапила чи не потрапила до індексу.

Для керованої індексація сайту URL Inspection Tool потрібен у трьох ситуаціях: ви опублікували нову важливу сторінку, ви внесли критичні редагування (контент/технічка), або ви бачите у звітах статус «не індексується» і хочете зрозуміти конкретну причину.

Покрокова перевірка URL: що дивитися насамперед

Алгоритм перевірки простий: вставляєте адресу у верхній рядок Search Console і чекаєте на результат. Далі йдіть за логікою зверху донизу:

1) Статус індексації. Інструмент покаже, чи знаходиться URL в індексі Google. Якщо ні - це ще не вирок, але сигнал, що потрібно розуміти причини.

2) Доступність та сканування. Перевірте блоки, пов'язані з доступом Googlebot: чи дозволено сканування, чи немає блокування Robots.txt, чи немає обмежень щодо авторизації (401) чи заборони (403).

3) Останній обхід. Подивіться дату останнього сканування - це допомагає відрізнитиGoogle ще не дійшов» від «Google дійшов та виключив». Якщо обхід був давно, можливо, заважають швидкість сайту, помилки сервера або перекіс у crawl budget.

Канонічний URL: як зрозуміти, яку адресу вибрав Google

У URL Inspection Tool зазвичай відображаються два значення: Canonical URL, який ви вказали (user-declared canonical), і канонічний URL, вибраний Google (Google-selected canonical). Якщо вони збігаються - добре: сигнали консистентні. Якщо не збігаються — це часто наслідок дублів сторінок, параметрів URL, неузгодженої перелінковки або редиректів.

Наприклад, якщо ви вказали canonical на "чистий" URL, але внутрішні посилання масово ведуть на версію з параметрами, Google може вирішити, що параметрична версія важливіша. У підсумку у звітах з'являється Google chose different canonical than user», та індексація сайтуія сайту стає менш передбачуваною.

Перевірка рендерингу: де спливають проблеми JavaScript та mobile-first indexing

Якщо сайт використовує динамічне завантаження контенту, обов'язково оцінюйте результати rendering. Помилка багатьох проектів: HTML «порожній», а ключові блоки з'являються лише після JS - при цьому Googlebot може відобразити сторінку не так, як користувач, особливо в мобільному контексті (mobile-first indexing).

Практично це проявляється так: ви відкриваєте сторінку в браузері – все є; Google – бачить менше тексту, менше посилань, немає структурованих даних. Слідство - "Crawled - currently not indexed" або попадання в індекс з урізаними сигналами.

Як правильно запросити індексацію та переіндексацію сторінки

Кнопка «Запросити індексацію» – це спосіб надіслати сигнал Google про те, що URL варто перевіряти ще раз. Її застосовують як для нових сторінок, так і для переіндексація сторінки після змін. Але важливо: запит не скасовує техніку. Якщо стоїть noindex, конфліктує canonical, URL закритий Robots.txt або сторінка віддає редирект/помилку — запит не дасть стабільного результату.

Використовуйте запит індексації після:

• переїзду URL з коректним редирект 301 та оновлення внутрішньої перелінковки;
• виправлення дублів та налаштування Canonical URL;
• зняття випадкового noindex/x-robots-tag;
• суттєвого оновлення контенту на пріоритетній комерційній сторінці.

Для системного просування сайту логіка така: спочатку усуваємо причину виключення, потім ініціюємо перехід через URL Inspection Tool, і лише потім оцінюємо зміни в Page Indexing report (зазвичай із затримкою).

7) HTTP status codes: які коди заважають індексації та як виправляти (включаючи редирект 301)

Чому HTTP status codes безпосередньо впливають на індексацію

Для Googlebot будь-яка URL починається з відповіді сервера. HTTP status codes — це «перший сигнал», яким Google розуміє: сторінка існує, переїхала, тимчасово недоступна чи взагалі відсутня. Тому індексація сайту часто ламається не через контент, а через неправильні коди відповіді або їх хаотичне поєднання.

У Google Search Console це швидко проявляється статусами начебто Page with redirect, Soft 404, і навіть винятками по 404/5xx. І важливо: якщо робот регулярно зустрічає помилки, страждає не лише конкретна URL-адреса, а й розподіл crawl budget — Google обходитиме менше корисних сторінок.

Код 200 OK: коли все добре і коли це пастка

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

Але 200 може бути проблемою, якщо за фактом ви віддаєте «пустушку» або сторінку-заміну. Типовий приклад — коли віддалений товар показує шаблон «товар не знайдено», але сервер повертає 200. Google це часто перетворюється на Soft 404 (як би «404 за змістом»), і така сторінка або індексується, або з часом вилітає з індексу.

Практичне правило: якщо контент реально відсутній, краще чесний 404/410 або коректний. редирект 301 на релевантну заміну, ніж 200 із «нічого немає».

3xx редирект: як зробити переїзд правильним (редирект 301) і не втрачати видимість

Коди 3xx означають перенаправлення. Для SEO найчастіше потрібен редирект 301 - Постійний переїзд URL. Він допомагає Google перенести сигнали (посилання, історію, релевантність) на нову адресу та прискорює переіндексацію.

Помилки, які заважають індексації та «з'їдають» сканування:

• ланцюжки редиректів (A → B → C): збільшують час обходу, знижують можливість швидкого оновлення в індексі;
• редирект на нерелевантну сторінку (наприклад, віддалений товар → головна): підвищує ризик Soft 404 та втрати довіри до сигналів;
• масові тимчасові редиректи (302/307) там, де переїзд постійний: Google довше "сумнівається", яку версію індексувати.

Для бізнесу це особливо важливо при зміні структури каталогу, міграції на https, поєднанні доменів або зміні ЧПУ. Чим чистіша карта редиректів, тим стабільніша індексація сайту після змін.

4xx помилки: 404, 410, 401, 403 - що робити в кожному випадку

404 Not Found - Сторінка не знайдена. Це нормально для реально віддалених URL, але погано, якщо 404 з'являється на важливих посадкових сторінках через биті посилання або помилки в генерації URL.

410 Gone — сторінку видалено назавжди. Корисно, коли ви точно не плануєте повертати URL-адресу: Google зазвичай швидше виключає його з індексу.

401 Unauthorized і 403 Forbidden Googlebot не має доступу. Часто зустрічається при закритих стейджингах, неправильних правилах CDN/WAF або при блокуванні User-Agent. Якщо це бойові сторінки, індексації не буде.

Окрема категорія Soft 404: формально 200, але за змістом немає контенту. Вирішується або реальним наповненням сторінки (щоб вона була корисною), або правильним кодом 404/410/301 залежно від сценарію.

5xx помилки: чому «тимчасові» збої призводять до довгих проблем

Коди 5xx (наприклад, 500/502/503/504) означає серверну помилку. Навіть якщо вони плавають, Googlebot може знизити частоту обходу, а важливі сторінки будуть оновлюватися в індексі повільніше. Для e-commerce це болісно: ціни/наявність змінюються, а Google бачить застарілі дані.

Що робити: моніторити стабільність відповіді, перевіряти навантаження, логи сервера, роботу кеша, коректність проксі/CDN. Якщо потрібні роботи на сервері, використовуйте 503 з коректним відновленням (а не нескінченні 500) – це допомагає пошуку зрозуміти, що проблема є тимчасовою.

Коли коди відповіді вибудовані логічно, ви різко знижуєте частку виключених URL Search Console і робите індексація сайту Найбільш прогнозованою: необхідні сторінки швидше потрапляють в індекс, а сміття - не забирає crawl budget.

8) Robots.txt: як керувати скануванням та не блокувати важливі ресурси для rendering

Що таке Robots.txt і що він (не) робить для індексації

Robots.txt — це файл у корені домену, який визначає правила сканування (crawling) для роботів, включаючи Googlebot. Він відповідає на запитання: «Чи можна роботу заходити до цього розділу/URL?». Важливо: Robots.txt не є прямою директивою індексації. Тобто заборона на сканування не дорівнює noindex - Це різні механіки.

З точки зору індексації сайту це критично: якщо ви закрили URL у Robots.txt, Googlebot може не мати можливості завантажити сторінку та побачити теги canonical, meta robots, контент та внутрішні посилання. У результаті ви втрачаєте контроль над тим, яка версія сторінки стане основною і потрапить до індексу.

Disallow та Allow: базова логіка правил та часті помилки

У Robots.txt найчастіше використовують директиви Disallow (заборонити) та Allow (дозволити), зазвичай у зв'язці з User-agent. Логіка проста: спочатку ви визначаєте, для якого робота діють правила, а потім перераховуєте шляхи.

Типова помилка – надто широкі заборони. Наприклад, закрили «/catalog/» або «/product/» повністю, тому що хотіли сховати фільтри, і разом зі сміттєвими URL-адресами закрили комерційні сторінки, які повинні приносити органічний трафік.

Ще один ризик - "переускладнення" масками і конфлікт Allow / Disallow. У спірних випадках Google орієнтується на найбільш специфічне правило (довший шлях), але на практиці краще будувати Robots.txt так, щоб його легко було перевірити та підтримувати.

Robots.txt та rendering: чому не можна випадково блокувати CSS/JS

Сучасна індексація - це ланцюжок crawling → rendering → indexing. Якщо Robots.txt блокує ресурси, необхідні для малювання (CSS, JS, API-ендпоінти), Googlebot може не відрендерувати сторінку коректно. Особливо болісно це проявляється на сайтах з активним JavaScript (javascript seo) та при mobile-first indexing, де робот орієнтується на мобільний малюнок.

Що відбувається на практиці: сторінка доступна (200), але Google бачить «урізану» версію без меню, без контенту, без посилань. Далі у Search Console ви можете побачити погіршення індексації, зростання статусів Crawled – currently not indexed, проблеми з канонікалізацією або навіть опосередковані ознаки «Soft 404»

“Закривши від Google CSS/JS, ви фактично просите його оцінювати сторінку із зав'язаними очима.”

Що зазвичай має сенс закривати від сканування, щоб заощаджувати crawl budget

Robots.txt – робочий інструмент для зниження «шуму» та економії crawl budgetАле закривати потрібно акуратно. Найчастіше логічно обмежувати сканування технічних розділів, які не повинні брати участь у пошуку та не несуть цінності:

• службові URL-адмінки, кошики, порівняння, особистого кабінету;
• внутрішній пошук сайту (якщо генерує нескінченні сторінки);
• параметричні URL, які створюють нескінченні комбінації фільтрів (на додаток до canonical/noindex, За ситуацією);
• тимчасові тестові директорії та staging (але краще закривати ще й паролем/401).

При цьому важливо пам'ятати: якщо ви повністю забороняєте crawling параметричних сторінок, Google не побачить їх canonical і може довше розрулювати дублі. Іноді для дублів вигідніше дозволити скануванняале заборонити індексацію через meta robots noindex (або x-robots-tag для не-HTML), щоб Google міг обробити сигнали.

Як тестувати Robots.txt і пов'язати редагування з індексацією

Будь-яку зміну Robots.txt робіть як технічний реліз: фіксуйте версію, перевіряйте правила та лише потім викочуйте. У Google Search Console використовуйте інструмент перевірки URL (URL Inspection Tool): він показує, чи дозволено сканування. Якщо важливі сторінки раптово стали "Blocked by robots.txt" - ви відразу побачите причину і зможете відкотитися.

Після правок контролюйте динаміку в Page Indexing report: чи зменшилася частка виключених URL через блокування, чи почала швидше оновлюватися індексація сайту, чи змінилися статуси по дублям і канонікалам. Такий прозорий підхід до просування перетворює Robots.txt з "файлу, який страшно чіпати" в керований важіль системного просування сайту.

9) Meta robots: noindex/nofollow - коли застосовувати і як не "поховати" розділи сайту

Що таке meta robots і чим він відрізняється від Robots.txt

Meta robots — це тег у HTML (зазвичай у <head>), який задає пошуковим системам правила обробки конкретної сторінки. Якщо Robots.txt керує тим, чи може Googlebot сканувати URL (crawling), то meta robots керує тим, чи може сторінка потрапляти до індексу (indexing) і як обробляти посилання сторінці.

Для керованої індексаціяація сайту важливо пам'ятати ключову залежність: щоб Google врахував директиву meta robots, він повинен мати можливість просканувати сторінку. Якщо URL заблоковано в Robots.txtробот може не побачити ваш noindex і буде діяти за своїми сигналами (наприклад, за зовнішніми посиланнями та даними з інших сторінок).

Noindex: коли закривати сторінку від індексації та як робити це безпечно

Noindex означає: "Не додавати цю сторінку до індексу". Це корисна директива для сторінок, які не повинні приносити органічний трафік або створюють дублі/сміття. Типові сценарії для бізнесу:

• службові сторінки: кошик, оформлення замовлення, особистий кабінет, сторінки подяки;
• внутрішній пошук по сайту та результати пошуку (часто генерують нескінченні комбінації);
• параметричні URL фільтрів та сортувань, якщо вони не є окремими посадочними;
• тестові/тимчасові сторінки, які повинні брати участь у видачі.

Важливо: якщо ви закриваєте фільтри через noindex, переконайтеся, що у вас є зрозуміла стратегія для основних сторінок категорій і посадкових під попит — інакше ви зріжете значну частину семантики.

Nofollow: як впливає на посилання і чому його легко застосувати неправильно

Nofollow — директива, яка каже: «Не використовувати посилання на сторінці як сигнал передачі ваги/обходу». Насправді Google Може трактувати нещодавно як підказку, а не абсолютну заборону, але в більшості випадків вона знижує цінність посилань для побудови внутрішньої структури.

Головний ризик: масово проставити nofollow на важливих розділах (категорії, фільтри, товарні зв'язки) і тим самим погіршити виявлення URL та розподіл crawl budget. Тоді Googlebot рідше доходить до глибоких сторінок, та індексаціяація сайту сайту сповільнюється, особливо у великих каталогах.

Таблиця рішень: noindex, nofollow, canonical - що вибрати в типових ситуаціях

Meta robots – не єдиний інструмент. Іноді правильніше використовувати Canonical URL, іноді - редирект, а іноді - залишити сторінку індексується і посилити її контентом. Нижче спрощена логіка вибору.

Часті помилки впровадження, які «ховають» розділи сайту

У проектах найчастіше зустрічаються не тонкі SEO-помилки, а прості, але дорогі:

- noindex на шаблоні: Директива випадково потрапляє на всі сторінки категорії або товарів після оновлення CMS/шаблону;

- Конфлікт сигналів: canonical вказує на одну URL, а meta robots стоїть noindex на іншому плюс ще є редиректи - Google вибирає свою логіку;

- Закриття сторінок від сканування в Robots.txt та спроба керувати індексацією через noindex (робот не бачить директиви);

— «лікуємо crawl budget» через nofollow на навігації, через що Googlebot гірше виявляє важливі URL-адреси.

Оптимальний підхід Web-Raketa – перевіряти зміни через Google Search Console (Page Indexing report та URL Inspection Tool), фіксувати шаблонні директиви та впроваджувати правила щодо сегментів. Тоді індексаціядексація сайту стає контрольованою: в індексі залишаються сторінки, які реально дають трафік, який конвертує.

10) X-Robots-Tag: контроль індексації лише на рівні заголовків сервера

Що таке X-Robots-Tag і навіщо він потрібний, якщо є meta robots

X-Robots-Tag — це HTTP-заголовок відповіді сервера, який передає пошуковим роботам директиви індексації та обробки посилань. По суті, це "meta robots, але на рівні заголовків", тому він працює не тільки для HTML-сторінок, але і для файлів, які не мають зручного <head>: PDF, зображення, документи, деякі типи вивантажень і т.д.

Для системного технічного SEO це важливий інструмент: ви можете керувати тим, як Googlebot та інші роботи обробляють ресурси, які часто потрапляють до індексу «випадково» — і тим самим покращувати індексація сайту, економити crawl budget та очищати видачу від нерелевантних файлів.

Де X-Robots-Tag застосовують найчастіше: PDF, зображення та не-HTML ресурси

Найчастіші кейси для бізнесу:

- PDF-каталоги, прайси, інструкції. Іноді вони корисні і повинні ранжуватися, але найчастіше це дубль інформації з сайту або «службовий» документ, який не повинен перетягувати видимість біля основної сторінки.

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

- фіди/вивантаження (XML/CSV), тестові файли, документи, що автогенеруються.

Якщо такі ресурси індексуються, ви можете побачити в Search Console дивні URL у звітах, зростання «сміттєвої» індексації та зниження якості представлення бренду у видачі.

Які директиви використовувати: noindex, nofollow та інші практичні варіанти

Найбільш поширені директиви для X-Robots-Tag:

• noindex — заборонити індексацію ресурсу (часто для PDF/зображень);
• nofollow - підказка не враховувати посилання всередині документа (актуально для PDF, де можуть бути зовнішні/внутрішні посилання);
• nosnippet - заборонити показувати сніпет/фрагменти (використовується точково);
• noarchive — не показувати копію кеші (рідко, але буває в корпоративних сценаріях).

Важливо пам'ятати про логіку: якщо ви закриваєте PDF через noindex, але цей PDF є єдиним джерелом інформації і на нього ведуть важливі посилання – ви можете втратити частину пошукового попиту. Тому рішення має бути бізнес-обґрунтованим: що має наводити трафік, який конвертує – файл чи HTML-сторінка?

"Директиви індексації - це не про "приховати", а про "сфокусувати видимість на тому, що приносить результат"."

Приклади заголовків та як їх перевіряти у відповіді сервера

Технічно X-Robots-Tag додається до HTTP-відповіді. Приклад логіки (у форматі заголовка): X-Robots-Tag: noindex , nofollow. Він повинен приходити разом із коректним кодом відповіді (зазвичай 200 або 304), інакше Googlebot може обробити сигнал непередбачувано.

Як перевірити, що заголовок реально віддається:

1) Через DevTools у браузері (Network → Headers) – зручно для точкової перевірки.

2) Через команду curl -I https://site.ua/file.pdf - Ви побачите набір заголовків відповіді.

3) Через URL Inspection Tool у Google Search Console – він допомагає зрозуміти, як Google бачить URL, але заголовки там не завжди відображаються повністю, тому краще поєднувати методи.

Типові помилки впровадження та як не зашкодити індексації сайту

Найчастіше проблеми виникають не через саму директиву, а через масштаб застосування:

- випадковий noindex на весь тип контенту (наприклад, закрили всі PDF, хоча частина їх повинна ранжуватися);

- конфлікт сигналів: файл закритий noindex, але на нього ведуть посилання з меню/карток товару як на ключовий ресурс;

- закриття ресурсів, потрібних для rendering: X-Robots-Tag зазвичай застосовують до файлів, але якщо помилково його отримують JS/CSS-ресурси, це може погіршити відмальовування і, як наслідок, індексація сайтуня сайту.

Оптимальний підхід: спочатку складіть список типів файлів та URL-патернів, визначте, що має індексуватися, потім впроваджуйте X-Robots-Tag точково та перевіряйте ефект у Page Indexing report. Так ви керуєте видимістю Google без зайвого шуму і зберігаєте контроль над зростанням органічного трафіку.

11) Sitemap.xml: як прискорити виявлення URL та покращити сканування та індексацію

Навіщо потрібен Sitemap.xml і як він впливає на crawling та indexing

Sitemap.xml — це мапа сайту у форматі XML, яка допомагає Googlebot швидше виявляти URL-адресу і розуміти структуру ресурсу. Важливо: sitemap не гарантує індексацію, але помітно підвищує ймовірність, що Google вчасно знайде нові або оновлені сторінки та розподілить сканування раціональніше.

Для проектів з великою кількістю сторінок (інтернет-магазини, каталоги послуг, медіа) це один із найпрактичніших важелів: коректний Sitemap.xml знижує хаос в обході, допомагає економити crawl budget та прискорює індексацію сайту там, де важлива швидкість оновлення (наявність товарів, ціни, нові статті).

Що включати в Sitemap.xml: тільки «канонічні» та індексовані URL

Головне правило: у Sitemap.xml мають бути URL, які ви дійсно хочете бачити в пошуку, і які віддають 200 OK, доступні для сканування та не закриті від індексації. Якщо ви додаєте до карти все поспіль, ви самі розмиваєте пріоритети і відправляєте Googlebot на обхід сміття.

Орієнтир для включення:

• сторінки з кодом 200 (не редиректи та не помилки);
• URL без noindex та без обмежень через x-robots-tag;
• основні версії сторінок, що збігаються з Canonical URL;
• посадкові, категорії, товари, статті, які реально мають приносити органічний трафік.

Чого краще уникати в sitemap: сторінки з параметрами фільтрів/сортувань (якщо це не окремі SEO-посадкові), дублі сторінок, URL з редирект 301, «Page with redirect», а також технічні розділи (кошик, обліковий запис, пошук по сайту).

Lastmod: як використовувати дату оновлення, щоб прискорити перехід

Тег lastmod — один із небагатьох елементів sitemap, який реально допомагає підказати пошуку, що сторінка змінилася. Але працює він тільки якщо:

— дата оновлюється чесно (при реальній зміні контенту),

- Формат коректний (зазвичай ISO 8601),

- Ви не проставляєте однаковий lastmod "сьогодні" на всі URL щодня.

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

Розділові карти сайту: як структурувати Sitemap.xml для великих проектів

Для інтернет-магазинів та сайтів з великою кількістю URL краще використовувати кілька sitemap та індекс-карту (sitemap index). Це дає дві переваги: простіше підтримувати порядок та легше діагностувати проблеми (по конкретній карті видно, що саме «не заходить»).

Практичний варіант розбиття:

- окрема картка для категорій,

- Окрема карта для товарів,

- окрема карта для блогу/контенту,

— окрема карта для регіональних/мовних версій (якщо застосовується).

Так ви перетворюєте Sitemap.xml із «файлу для галочки» в інструмент системного просування сайту.

Надсилання Sitemap.xml до Google Search Console та контроль обробки

Після створення карту потрібно відправити в Google Search Console (Розділ Sitemaps). Далі дивіться статус обробки: скільки URL прочитано, чи є помилки, і чи немає різкої розбіжності між «Надіслано» і «Проіндексовано». Якщо розбіжність велика, це привід перевірити якість URL: дублі, канонікалізацію, доступність для Googlebot, наявність noindex.

Паралельно зіставляйте дані з Page Indexing report: якщо з карти масово потрапляють до «Excluded» з причин «Duplicate without user-selected canonical» або «Crawled – currently not indexed», проблема не в sitemap як такому, а сигналах сторінки (контент/дублі/канонікал).

Якщо тримати карту сайту «чистою» та актуальною, ви отримуєте швидший шлях: виявлення → сканування → індексація, і зрештою — посилення видимості в Google без зайвого шуму.

12) Canonical URL: як Google вибирає основний URL і як уникнути втрати трафіку

Canonical URL простими словами: навіщо він потрібний для індексації

Canonical URL — це підказка Google, яку адресу вважати основною (канонічною) версією сторінки, якщо існує кілька URL-адрес з однаковим або дуже схожим контентом. Для e-commerce та сайтів послуг це звичайна історія: один товар доступний з різних категорій, з'являються параметри сортування/фільтрації, UTM-мітки, версії зі слішем та без тощо.

Canonical не «склеює» сторінки миттєво і не є жорсткою командою, але він допомагає Google розподіляти сигнали (внутрішні/зовнішні посилання, поведінкові та контентні фактори) на користь вибраної сторінки. У результаті індексація сайтуія сайту стає більш передбачуваною: в індексі залишається основна версія, а дублікати рідше потрапляють у видачу і не розмивають релевантність.

“Canonical – це спосіб сказати Google: "Ось сторінка, яку ми хочемо просувати", але Google все одно перевірить, наскільки ви послідовні.

Як Google вибирає канонікал насправді: сигнали важливіші за тег

Навіть якщо ви проставили canonical, Google може вибрати іншу URL-адресу. У Search Console це проявляється статусом Google chose different canonical than user. Зазвичай причина – конфлікт сигналів. Google дивиться на:

- внутрішні посилання (на якій URL ви частіше посилаєтеся з меню, категорій, хлібних крихт);

- Редиректи (куди веде редирект 301 і чи немає ланцюжків);

- Схожий/схожий контент (дублі сторінок);

- HTTP/HTTPS, www/без www, trailing slash;

- sitemap: які URL ви подаєте в Sitemap.xml;

- Доступність для Googlebot (якщо одна версія закрита Robots.txt або дає помилки, перевага може піти інший).

Тому canonical — це не магічна кнопка, а елемент системної стратегії: він працює, коли інші сигнали не суперечать.

Self-referencing canonical: чому «канонікал на себе» – це норма

Self-реferencing canonical - коли на сторінці canonical вказує на себе. Це хороша практика для більшості сторінок, що індексуються: ви фіксуєте «основну» версію URL і знижуєте ризик того, що Google вибере альтернативу (наприклад, із параметрами або іншою схемою URL).

Особливо корисно для сторінок, які можуть отримувати параметри з реклами/аналітики або мають «близнюки» через особливості CMS. Це підвищує контроль над тим, яка версія бере участь у ранжируванні, і знижує ймовірність розпорошення сигналів - важливий фактор для стабільної індексаціяація сайту.

Крос-доменні canonical: коли допустимо і які ризики для трафіку

Cross-domain canonical використовується, коли ви свідомо вказуєте канонічний URL на іншому домені. Приклад: компанія має основний сайт і окремий домен під вітрину/партнерський проект, але контент повинен ранжуватися тільки на головному домені.

Ризик очевидний: якщо ви помилково поставите крос-домен canonical, Ви можете "перевіддати" пошуковий трафік іншому домену або взагалі втратити видимість потрібного сайту. Тому застосовуйте його лише при чіткому розумінні архітектури, прав володіння доменами та мети: де має бути органічний попит.

Типові помилки з canonical, через які втрачається видимість в Google

Найчастіші проблеми, які ми бачимо на проектах:

• canonical вказує на URL з редиректом або 404 (Google ігнорує або вибирає інше);
• канонікалізація всіх сторінок пагінації на першу сторінку категорії (у результаті «ріжеться» довгий хвіст попиту);
• canonical розставлений, але Sitemap.xml лежать неканонічні URL — конфлікт сигналів;
• canonical не збігається із внутрішніми посиланнями (посилання веде на параметричну версію, canonical - на чисту);
• канонікалізація різних товарів/послуг на одну сторінку через шаблонну помилку.

Як перевірити canonical і пов'язати редагування з індексацією

Перевіряйте canonical точково через URL Inspection Tool (поля «User-declared canonical» та «Google-selected canonical») та в динаміці через Page Indexing report (статуси Duplicate без user-selected canonical і Google chose different canonical than user). Додатково зіставляйте з логікою сайту: які URL ви віддаєте 200, де стоять 301, які сторінки закриті noindex і які адреси потрапляють у Sitemap.xml.

Коли canonical, редиректи, внутрішні посилання та карта сайту працюють узгоджено, індексація сайту стає стабільною, а пошукові сигнали концентруються на сторінках, які дійсно повинні наводити трафік, який конвертує.

13) Дублі сторінок (duplicate pages): джерела, діагностика та стратегія усунення

Що таке дублі сторінок і чому вони «з'їдають» SEO-потенціал

Duplicate pages (дублі сторінок) — це ситуації, коли той самий або дуже схожий контент доступний по різних URL. Для Google це проблема вибору: яку сторінку індексувати, яку рахувати Canonical URL, куди «скласти» сигнали посилань та якості. Для бізнесу результат зазвичай неприємний: розмивається релевантність, падає керованість видачі, а індексаціядексація сайту стає нестабільною.

Побічний ефект дублів - перевитрата crawl budget. Googlebot витрачає час на обхід та обробку копій, замість частіше сканувати пріоритетні категорії, товари та посадкові під попит в Україні.

Основні джерела дублів: від параметрів до протоколів

Найчастіше дублі з'являються не «бо хтось так захотів», а через особливості CMS, фільтри та технічні налаштування. Типові джерела:

• параметри URL: фільтри, сортування, трекінг (utm, gclid), внутрішні параметри;
• пагінація: різні сторінки списку товарів можуть бути схожі за контентом;
• різні версії домену: www/non-www, http/https, зі слешем/без слеша;
• один товар у різних категоріях (різні «шляхи» та URL при однаковій картці);
• дублі за мовними/регіональними версіями, якщо неправильно настроєно версії сторінок.

У Google Search Console дублі часто спливають як Duplicate без user-selected canonical або Google chose different canonical than user. Це прямий сигнал: Google не розуміє, яку версію вважати основною або не довіряє вашим підказкам.

Як діагностувати дублі: комбінація GSC, логіки URL та вибіркової перевірки

Для швидкої діагностики використовуйте зв'язку:

1) Page Indexing report: дивіться обсяг виключених URL та причини, пов'язані з дублями, редиректами та канонікалами.

2) URL Inspection Tool: точково перевіряйте проблемні адреси - які канонікали заявлені та які вибрав Google.

3) Перевірка шаблонів URL: випишіть патерни параметрів, варіантів слеша, сторінок пагінації та оцініть, які з них реально потрібні в індексі.

4) Sitemap.xml: у карті мають бути лише канонічні URL. Якщо туди потрапляють дублі, ви самі посилюєте проблему.

Стратегія усунення: canonical, редирект 301, noindex - що вибрати

Єдиного «правильного» методу немає — вибір залежить від сценарію і того, чи має альтернативна URL-адреса існувати для користувача.

Canonical URL підходить, коли сторінки мають бути доступні, але в пошуку повинна ранжуватися одна версія (наприклад, UTM-мітки, сортування, один товар — різні шляхи). Важливо: canonical працює краще, коли внутрішнє перелінкування веде на канонічну версію.

Редирект 301 — найкращий варіант, коли альтернативна URL-адреса не потрібна і її можна назавжди замінити (наприклад, http → https, www → без www, старе ЧПУ → нове). Це прискорює очищення дублів та перенесення сигналів.

Noindex (meta robots або x-robots-tag) застосовуйте, коли URL потрібен користувачеві, але не повинен потрапляти до індексу (наприклад, внутрішній пошук, службові сторінки, частина фільтрів без цінності). Тут важливо не закрити від індексації те, що може давати трафік.

Параметри в Google Search Console та контроль результату

Для параметричних дублів корисно не лише «лікувати» слідства, а й обмежувати генерацію сміття на рівні сайту: упорядкувати фільтри, зробити SEO-посадкові за найчастішими комбінаціями, а решту — нормалізувати через canonical/noindex. У деяких випадках допомагають налаштування обробки параметрів Search Console (якщо доступні для вашого типу ресурсу), але спиратися варто насамперед на технічну архітектуру URL.

Після впровадження змін контролюйте ефект: чи зменшується частка дублів у Page Indexing report, чи збігаються вибрані канонікали в URL Inspection Tool, чи швидше оновлюється індексація сайту. Це є прозорий підхід до просування: виправлення → перевірка → закріплення результату.

14) JavaScript SEO: як rendering впливає на індексацію сторінок на SPA/SSR/CSR

Rendering в Google: чому JavaScript змінює правила індексації

JavaScript SEO починається з розуміння ланцюжка: Googlebot спочатку робить crawling (завантажує HTML), потім при необхідності виконує rendering (відмальовку з виконанням JS), і тільки потім приймає рішення про indexing. На класичних сайтах контент доступний відразу в HTML, а на SPA та додатках з активним JS ключові елементи (текст, посилання, картки товарів) можуть з'являтися лише після виконання скриптів.

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

"Google індексує не те, що ви бачите в браузері, а те, що він зміг відрендерити на своїй стороні."

SPA/CSR/SSR: у чому різниця і де вищі ризики для індексації

Ключова різниця - де з'являється підсумковий HTML з контентом:

CSR (Client-Side Rendering): сервер віддає мінімум HTML, а контент будується у браузері через JS. Це найризикованіший варіант для SEO, тому що Googlebot повинен виконати багато дій, щоб побачити сторінку «як користувач».

SSR (Server-Side Rendering): сервер відразу віддає готовий HTML із контентом, а JS «оживляє» інтерфейс. Зазвичай це надійніше для пошуку.

SPA — формат програми, яка може бути реалізована як CSR або SSR. Важлива не назва, а те, де генерується контент.

Для українських інтернет-магазинів та сервісів з динамічними фільтрами типова проблема CSR — коли Google бачить менше тексту та менше внутрішніх посилань, ніж користувач. Підсумок: гірше виявлення URL, більше статусів Crawled – currently not indexed, проблеми з канонікалізацією та перевитрата crawl budget.

Типові SEO-помилки JavaScript-сайтів, які б'ють по видимості

Помилки зазвичай повторюються з проекту до проекту:

• контент підвантажується тільки після дій користувача (кліки/скролл), а не під час завантаження;
• внутрішні посилання генеруються JS і відсутні у вихідному HTML;
• важливі ресурси (JS/CSS) блокуються Robots.txt, внаслідок чого rendering ламається;
• різні версії контенту для mobile/desktop у mobile-first indexing;
• canonical, meta robots (noindex) та структуровані дані додаються «пізно» і не потрапляють у відрендеровану версію стабільно.

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

Як перевіряти, що Googlebot реально відрендерив: інструменти у GSC

Базовий контроль здійснюється через Google Search Console:

- URL Inspection Tool: дивіться дату останнього обходу, доступність сканування, вибраний Canonical URL та індексаційний статус.

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

Додатково корисно порівнювати вихідний HTML (View Source) і DOM після виконання JS (Elements DevTools). Якщо вихідний код не має критичного контенту, ви залежите від успішного рендерингу на стороні Google.

Практичні рекомендації: як зробити JavaScript-дружелюбну індексацію

На рівні стратегії найкраще працює SSR або гібридний підхід (SSR + hydration) або пререндеринг для ключових SEO-сторінок (категорії, картки товарів, статті). Завдання - щоб Googlebot отримував максимум корисної інформації одразу, без складних сценаріїв виконання.

Технічні рекомендації, які найчастіше дають швидкий ефект:

— переконатись, що важливі посилання — це реальні <a href="/uk/1/">, а чи не обробники подій;

- не блокувати JS/CSS у Robots.txt, якщо вони потрібні для rendering;

- тримати канонікал та meta robots у серверній віддачі (або гарантовано в ранньому рендері);

- уникати «нескінченних» параметричних URL, які плодять дублі сторінок і роздмухують crawl budget;

- Після правок запускати переіндексація сторінки через URL Inspection Tool для пріоритетних URL і відстежувати динаміку в Page Indexing report.

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

15) Чому сторінка не індексується: чек-лист причин та як швидко локалізувати проблему

З чого почати: відокремлюємо «не знайдено» від «не захотіли індексувати»

Коли виникає питання «чому сторінка не індексується», важливо не ворожити, а швидко визначити, на якому етапі ламається ланцюжок crawling → rendering → indexing. Для цього використовуйте два джерела: Page Indexing report (масова картина) та URL Inspection Tool (точкова діагностика).

Перше, що потрібно зрозуміти: Googlebot може отримати сторінку взагалі? Якщо URL віддає 4xx/5xx або впирається в заборони, індексація сайту не розпочнеться в принципі. Якщо доступ є, але сторінка все одно виключена, значить проблема в сигналах якості/дублях/канонікалізації або в рендерингу (JavaScript SEO).

Блокування та заборони: Robots.txt, noindex, x-robots-tag

Це найчастіша і водночас найпростіша категорія причин — технічні «стоп-сигнали».

Robots.txt блокує crawling. У Search Console ви побачите Blocked by robots.txt. Важливо: якщо Googlebot не може сканувати URL-адресу, він може не побачити canonical і meta robots на сторінці, а значить ви втрачаєте керування сигналами.

Meta robots noindex забороняє indexing. Часта помилка - випадковий noindex у шаблоні (наприклад, після оновлення CMS), через який «падає» цілий розділ.

X-Robots-Tag працює на рівні заголовків сервера і часто застосовується до PDF/файлів, але іноді помилково поширюється на HTML. Тоді сторінка може виглядати «нормально» візуально, але не потрапляти до індексу.

Відповіді сервера та редиректи: 4xx/5xx, Soft 404 та «Page with redirect»

Якщо URL віддає 404/410, він не буде індексуватися (що логічно). Якщо дає 401/403 — Googlebot не має доступу. Якщо регулярно спливають 5xx (500/502/503) — Google знижує активність обходу та може відкладати індексацію.

Окремо стоїть Soft 404: коли сервер повертає 200, але сторінка за змістом порожня (наприклад, товар знято з продажу, а шаблон показує нічого не знайдено). Це часто джерело винятків і втрат за індексація сайту.

Статус Page with redirect означає, що URL - редирект. У індекс зазвичай потрапляє кінцева сторінка, а чи не редирект. Якщо переїзд постійний – використовуйте редирект 301 і уникайте ланцюжків (A → B → C).

Канонікал та дублі: коли Google індексує «не ту» сторінку

Якщо canonical вказує на іншу URL, поточна сторінка може не індексуватися навмисно - тому що ви самі сказали Google вважати основною іншу версію. Проблема починається, коли canonical налаштований неправильно або конфліктує з іншими сигналами.

У Search Console це проявляється статусами Duplicate без user-selected canonical і Google chose different canonical than user. Часті причини: параметри URL, дублі сторінок (www/non-www, http/https), однакові товари за різними адресами, неузгоджена внутрішня перелінковка та «брудний» Sitemap.xml, де лежать неканонічні URL.

Недостатні сигнали: слабка перелінковка, crawl budget та якість контенту

Іноді заборон немає, сторінка віддає 200, але все одно висить як Discovered – currently not indexed або Crawled – currently not indexed. Це зазвичай про пріоритет та цінність.

Причини:

• Слабка внутрішня перелінковка: на сторінку майже не ведуть посилання, вона «глибоко» у структурі
• Перекіс crawl budget: сайт генерує занадто багато сміттєвих URL, і Googlebot рідше доходить до важливого.
• Якість: тонкий контент, тексти, що дублюються, сторінки без явної користі (особливо в категоріях і тегах).

Тут рішення частіше не «попросити індексацію», а посилити сторінку: додати унікальний значеннєвий блок, покращити структуру, підтягнути внутрішні посилання з релевантних розділів.

Rendering та JavaScript: коли Googlebot бачить «порожню» сторінку

Для SPA/CSR-сайтів найчастіша причина — проблеми rendering. Користувач бачить контент, а Googlebot після сканування фіксує мало тексту/посилань або бачить структуровані дані. Тоді індексація відкладається або виключається сторінка.

Перевірка: URL Inspection Tool → оцінка доступності, вибраного канонікала та рендерингу (скриншот/перегляд сторінки, якщо доступно). Якщо контент з'являється лише після складного JS, розгляньте SSR або пререндеринг для ключових URL-адрес.

16) Як прискорити індексацію сайту без хаосу: системна стратегія дій

Крок 1. Визначте «сторінки грошей» та «сторінки підтримки»: пріоритизація перед прискоренням

Пришвидшувати індексацію сайту має сенс лише тоді, коли ви розумієте, які URL дійсно мають приносити трафік, який конвертує. Для інтернет-магазину це зазвичай: ключові категорії, топові підкатегорії, товари-хіти, сторінки брендів, комерційні посадкові послуги. Для контентного проекту – статті, які закривають попит та ведуть до заявок.

Складіть список пріоритетів на 20/80: 20% сторінок, які потенційно дадуть 80% органічного ефекту. Це і буде коридор для ваших дій: саме ці URL ви прискорюєте, а не весь сайт поспіль.

Крок 2. Зміцніть внутрішнє перелінкування: щоб Googlebot швидше знаходив і частіше повертався

Найбільш недооцінений фактор індексації – внутрішня структура посилань. Googlebot виявляє URL у першу чергу через посилання, тому завдання просте: зробити так, щоб важливі сторінки були логічно вбудовані в навігацію та отримували достатню «вагу».

Практичні точки посилення:

• посилання з категорій на підкатегорії та важливі товари/добірки;
• блоки "схожі товари", "з цим купують", "популярне в категорії";
• хлібні крихти, які ведуть ієрархією;
• контентні посилання із статей на комерційні сторінки (і навпаки, якщо доречно).

Чим простіше Googlebot пройти від головної до потрібної URL за 2–4 кліки, тим вище шанс швидкої індексації та регулярної переіндексації сторінки.

Крок 3. Упорядкуйте Sitemap.xml: у карту — тільки канонічні та індексовані URL

Sitemap.xml – це прискорювач виявлення, але тільки якщо карта чиста. До неї повинні потрапляти URL зі статусом 200, без noindex і без конфліктів щодо Canonical URL. Не додавайте в sitemap сторінки з редиректами (включаючи редирект 301), дублі сторінок, параметричне сміття та технічні розділи.

Якщо сайт великий, розділіть карту: окремі sitemaps для категорій, товарів та контенту. Це спрощує контроль у Google Search Console і швидше виявляє сегменти, де індексаціяція сайту «просідає».

Крок 4. Заберіть причини виключення з індексу: працюємо за статусами Search Console

Далі робота за даними, а не за відчуттями. Відкривайте Page Indexing report та сортуйте причини виключення за бізнес-важливістю URL. Як правило, найшвидше дають ефект виправлення:

- Blocked by robots.txt на потрібних сторінках (перевірте Robots.txt);

- Page with redirect там, де має бути кінцевий URL (прибрати ланцюжки, залишити один 301);

- Soft 404 на картках/категоріях (або контент, або коректний 404/410/301);

- Duplicate без user-selected canonical і Google chose different canonical than user (налаштування canonical + узгодження внутрішніх посилань і sitemap);

- Crawled – currently not indexed (Часто сигнал, що сторінка слабка за якістю або занадто схожа на інші).

Крок 5. Оптимізуйте crawl budget: менше сміття більше уваги до важливого

Якщо сайт генерує тисячі URL-адрес з фільтрами/сортуванням, Googlebot витрачає crawl budget на обхід дублів та глухих кутів. В результаті важливі сторінки індексуються та оновлюються повільніше.

Системна оптимізація включає: скорочення дублів (canonical/301/noindex за ситуацією), контроль параметрів URL, чисту архітектуру посилань, усунення масових 4xx/5xx, і акуратні обмеження в Robots.txt тільки там, де ви дійсно захочете обмежити crawling (та не ламаєте rendering).

Крок 6. Точкові запити через URL Inspection Tool: фінальний «стусан» після правильних правок

Коли ви виправили першопричину, використовуйте URL Inspection Tool у Google Search Console для пріоритетних сторінок: перевірте канонікал, доступність сканування та результат, а потім натисніть «Запросити індексацію». Це корисно для нових посадкових, оновлених категорій, важливих товарів, а також для переіндексація сторінки після великих змін.

Не перетворюйте запити на рутину «на все підряд»: це не прискорювач, якщо сайт залишається в стані дублів, редірект-ланцюжків і слабкої перелінковки. Правильна стратегія спочатку порядок, потім прискорення. Так індексація сайту стає прогнозованим процесом, а чи не лотереєю.

17) Моніторинг та контроль: метрики, регулярні перевірки та тригери для переіндексації сторінки

Чому моніторинг важливіший за разові «переобходи»

Індексаціядексація сайту – це процес, а не подія. Навіть якщо сьогодні все виглядає ідеально, завтра ви викочуєте оновлення CMS, змінюєте шаблон, додаєте фільтри або підключаєте новий модуль - і в індексі з'являється шум: дублі, редиректи, помилки 404/403, статуси Crawled - currently not indexed. Тому завдання бізнесу — побудувати контроль, який ловить відхилення раніше, ніж вони перетворюються на просадку трафіку та продажу.

Практичний принцип Web-Raketa: "контроль за тригерами". Ми не дивимося звітів хаотично — ми відстежуємо кілька ключових метрик і реагуємо, коли вони виходять за межі норми.

Базові метрики: що відстежувати в Page Indexing report

Раз на тиждень (для великих магазинів частіше) відкривайте Page Indexing report в Google Search Console та фіксуйте динаміку:

- Кількість Indexed (проіндексовано) та тренд;

- Кількість Excluded (виключено) та тренд;

- Топ-3 причини виключення та їх зростання/падіння;

- Частка дублів: Duplicate без user-selected canonical і Google chose different canonical than user;

- Частка технічних проблем: Blocked by robots.txt, Page with redirect, Soft 404, 404/401/403.

Важливо дивитися як абсолютні цифри, а й структуру винятків. Наприклад, зростання «Page with redirect» часто означає, що в Sitemap.xml або внутрішній перелінковці з'явилися не кінцеві URL, а редиректи (включаючи ланцюжки замість одного редирект 301).

Алерти та тригери: коли час «піднімати прапор»

Налаштуйте для команди прості умови, за яких ви починаєте розбір причин (в ідеалі фіксуєте в таск-трекері). Приклади робочих тригерів:

• зростання Excluded на 10-20% за тиждень без планових змін на сайті;
• різкий сплеск Blocked by robots.txt (часто після правок Robots.txt);
• поява масового Soft 404 (часто через шаблони «немає» чи порожніх категорій);
• зростання дублів та розбіжність канонікалів (після впровадження фільтрів/параметрів);
• збільшення 5xx та падіння активності Googlebot (сигнал проблем із сервером та crawl budget).

Ця логіка дає «відчуття контролю»: ви не чекаєте, поки впаде трафік, а запобігаєте падінню.

Логи сервера та краулінг: як зрозуміти, куди реально ходить Googlebot

Search Console показує наслідки, але не завжди пояснює поведінку Googlebot. Для глибокого контролю використовуйте логи сервера: які URL відвідує Googlebot, як часто, які коди відповіді отримує (200/301/404/5xx). Це особливо важливо для великих сайтів, де crawl budget обмежений.

Додатково корисний регулярний технічний краулінг (Screaming Frog або аналог): він допомагає побачити ланцюжки редиректів, биті посилання, дублі тайтлів/канонікалів, а також сторінки, які випадково отримали noindex або x-robots-tag.

Коли ініціювати переіндексацію сторінки: розумні сценарії

Переіндексація сторінки через URL Inspection Tool є сенс, коли ви зробили зміни, які реально повинні вплинути на видачу або виправляють блокування індексації. Типові сценарії:

- Зняли noindex / виправили x-robots-tag на важливій сторінці;

- Виправили неправильний Canonical URL або усунули дублі сторінок;

- полагодили доступність (прибрали 403/404, стабілізували 5xx);

— завершили переїзд URL та налаштували коректний редирект 301 + оновили внутрішні посилання та Sitemap.xml;

— суттєво оновили контент на сторінці, яка приносить ліди/продаж.

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

Регламент контролю: мінімальний процес, що дає стабільність

Щоб індексація сайту підтримувалася без хаосу, досить простого регламенту: щотижневий огляд Page Indexing report, щомісячна звірка Sitemap.xml (чи немає редиректів, дублів, закритих URL), і щоквартальний аудит логів/краулінг за ключовими сегментами. Такий процес дозволяє заздалегідь бачити ризики, економити час команди та утримувати стабільне зростання органічного трафіку.

18) FAQ: індексація сайту та сканування - часті питання власників сайтів в Україні

Скільки триває індексація нової сторінки Google і від чого це залежить?

Терміни сильно плавають: у невеликих сайтів нова сторінка може з'явитися в індексі за години чи дні, великі магазини — за дні чи тижні. На швидкість впливає те, як швидко Googlebot виявить URL (внутрішні посилання та Sitemap.xml), як часто він загалом сканує ваш сайт (crawl budget), чи немає технічних перешкод (Robots.txt, помилки 4xx/5xx, редиректи), а також наскільки сторінка виглядає корисною та недублюючою існуючий контент. Якщо в Search Console ви бачите Discovered – currently not indexed, значить URL знайдено, але ще не проскановано; Crawled – currently not indexed — проскановано, але Google поки що не додав його до індексу.

Чи допоможе Sitemap.xml прискорити індексацію сайту?

Так, але в правильному розумінні: Sitemap.xml прискорює виявлення URL та допомагає Google ефективніше розподіляти сканування. Він не гарантує, що сторінка буде в індексі. Якщо ви відправляєте в карту сторінки з noindex, редиректами (наприклад, після редирект 301), дублями або помилками, ви погіршуєте сигнал і витрачаєте crawl budget. Тому карта сайту повинна містити переважно канонічні URL-адреси зі статусом 200, а поле lastmod — оновлюватися тільки при реальних змінах.

Коли використовувати noindex і чим він відрізняється від Robots.txt?

Noindex (через meta robots або x-robots-tag) каже Google: "не індексувати сторінку", але при цьому робот може її сканувати і розуміти сигнали (canonical, посилання, контент). Robots.txt керує саме скануванням: він може заборонити crawling, і тоді Googlebot може не побачити директиви та вміст сторінки. Для власників сайтів в Україні типовий безпечний сценарій: службові сторінки (кошик, кабінет, внутрішній пошук) закривати noindex, а не Robots.txt, щоб зберегти коректну обробку посилань та канонікалізації. Robots.txt краще застосовувати для обмеження обходу технічних зон та «нескінченних» параметрів, але обережно, щоб не блокувати CSS/JS, потрібні для rendering.

Що робити з дублями сторінок і чому вони заважають зростанню?

Дублі сторінок розмивають сигнали та створюють конкуренцію всередині сайту: Google повинен вибрати, який URL вважати основним, а решта часто потрапляють у винятки як Duplicate без user-selected canonical або набувають статусу Google chose different canonical than user. Стратегія зазвичай комбінована: де URL не потрібний - ставимо редирект 301; де потрібен користувачеві, але не повинен ранжуватися - noindex; де це технічна альтернатива одного і того ж контенту (параметри, сортування, трекінг) - використовуємо Canonical URL і погоджуємо внутрішні посилання та Sitemap.xml так, щоб вони вели канонічну версію.

Як працює Canonical URL і чому Google іноді вибирає інший канонікал?

Canonical URL – це підказка, а не жорстка команда. Google порівнює ваш canonical з іншими сигналами: внутрішньою перелінковкою, редиректами, фактичним вмістом сторінок, доступністю для Googlebot і тим, які URL ви відправляєте в Sitemap.xml. Якщо сигнали суперечать один одному (наприклад, canonical вказує на чисту URL, але всі посилання ведуть на параметричний), Google може вибрати іншу основну адресу. Для стабільної індексація сайту важлива консистентність: єдина версія URL у посиланнях, карті сайту, редиректах та тегах canonical.

Чому Google ігнорує запит на індексацію/переіндексацію сторінки в URL Inspection Tool?

Запит через URL Inspection Tool - це сигнал "перевір сторінку", але він не скасовує правил індексування. Якщо URL стоїть noindex або x-robots-tag: noindex, якщо сторінка закрита Robots.txt, якщо вона є редиректом або віддає 404/403/5xx, якщо Google вважає її дублем або недостатньо цінною, запит не призведе до стійкого потрапляння в індекс. Іноді проблема у rendering: на JavaScript-сайтах Googlebot може не побачити контент у мобільній версії (mobile-first indexing), і тоді сторінка залишається поза індексом. Найкращий підхід: спочатку усунути причину виключення в Page Indexing report, потім ініціювати переіндексація сторінки та спостерігати зміни у звітах.

"Запит індексації - це прискорювач після виправлень, а не заміна технічного SEO".

19) Підсумок

Стабільна видимість у Google починається з розуміння простого ланцюжка: Googlebot повинен виявити URL, потім виконати crawling, при необхідності - rendering (особливо на JavaScript-сайтах і при mobile-first indexing), і лише після цього ухвалити рішення про indexing. Коли ці етапи плутають, бізнес зазвичай «лікує симптоми»: нескінченно натискає «Запитати індексацію», хоча проблема може бути у блокуванні Robots.txt, у помилках 4xx/5xx, у дублях чи тому, що контент не відмальовується для робота.

Контроль за індексаціяація сайту - це не магія, а узгодженість сигналів. Robots.txt повинен керувати скануванням, але не перекривати важливі розділи та ресурси CSS/JS, без яких ламається rendering. Meta robots з noindex допомагає прибирати з пошуку службові сторінки та сміттєві URL, а x-robots-tag дає той самий контроль на рівні заголовків сервера для PDF та інших не-HTML ресурсів. Sitemap.xml прискорює виявлення і підказує пріоритети, але працює тільки якщо в нього потрапляють канонічні URL-адреси зі статусом 200. Canonical URL склеює сигнали при дублях сторінок та допомагає Google вибрати основну версію, а редирект 301 коректно переносить сторінки під час переїздів та чистить індекс від застарілих адрес.

Важливо дивитися на індексацію як на систему: оптимізувати crawl budget, усувати «пожирачів» сканування (дублі, ланцюжки редиректів, Soft 404), зміцнювати внутрішню перелінковку та працювати за даними Google Search Console — через Page Indexing report та URL Inspection Tool. Тоді переіндексація сторінки стає логічним фінальним кроком після виправлення, а не спробою "продавити" Google.

У результаті технічне SEO перетворюється на прозорий підхід до просування: ви розумієте, які сторінки повинні приносити трафік, який конвертує, і створюєте умови, за яких Google швидко знаходить, коректно обробляє та стабільно тримає ці URL в індексі. Це і є основа системного просування сайту та довгострокового цифрового зростання бізнесу.