Сторінки випали з індексу Google: де шукати причину

Відсутність сторінки у звичайній пошуковій видачі ще не доводить, що Google її не проіндексував. URL може бути в індексі, але не показуватися за вибраною фразою через недостатню релевантність, конкуренцію або налаштування пошуку. Тому діагностику починайте з конкретної адреси в Google Search Console, а не з повторного надсилання всього сайту.

Як з’ясувати, чи URL справді немає в індексі?

Перевірте адресу через інструмент «Перевірка URL» у Google Search Console та зіставте дані про відому Google версію з результатом поточного тесту.

Послідовність перевірки:

1. Введіть у Google запит `site:example.com/adresa-storinky` із повною адресою. Якщо результату немає, переходьте до Search Console: оператор `site:` не дає остаточного діагнозу.
2. Вставте ту саму URL без скорочень і змін до інструмента «Перевірка URL».
3. Перегляньте статус індексації, дату останнього сканування та відомості про canonical.
4. Запустіть перевірку опублікованої версії, щоб побачити, чи може Googlebot отримати сторінку зараз.
5. Зафіксуйте результат і лише після цього змінюйте сайт.

Успішна перевірка опублікованої URL підтверджує її поточну доступність, але не означає, що адресу вже додано до індексу. Інструмент показує два різні стани: відомості про версію, яку Google знає, і результат тестування сторінки в цей момент.

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

Якщо після редизайну або перенесення проблему мають URL одного шаблону, не перевіряйте їх як незалежні випадки. Спільною причиною можуть бути налаштування CMS, шаблонний canonical, глобальний `noindex` або серверне правило.

Які заборони можуть не пускати сторінку до індексу?

Перевірте robots.txt, метатег robots і заголовок X-Robots-Tag: ці механізми діють по-різному, але кожен може впливати на сканування чи індексацію.

Що переглянути перед змінами

• Відкрийте `example.com/robots.txt` та знайдіть правила `Disallow`, які охоплюють проблемний шлях.
• Перегляньте вихідний код і знайдіть `meta name="robots"`.
• Переконайтеся, що сторінка не має директиви `noindex`.
• Перевірте HTTP-заголовки через інструменти розробника або серверний аналізатор.
• Перегляньте загальні налаштування CMS.
• Окремо перевірте SEO-плагін: заборона може стосуватися лише записів, категорій, тегів чи архівів.

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

Не використовуйте robots.txt як гарантований спосіб видалення адреси з пошуку. Заблокована для сканування URL іноді може з’явитися без опису, якщо Google дізнався про неї з посилань. Щоб робот прочитав `noindex`, сторінка має бути доступною для сканування.

Після виправлення відкрийте URL без авторизації та повторіть поточний тест у Search Console. Якщо відвідувач і Googlebot отримують різний вміст, перевіряйте CDN, захисні механізми та серверні правила. За великої кількості суперечливих сигналів доречний аудит технічного стану сайту, а не серія випадкових правок.

Чи повертає сервер правильну відповідь?

Сторінка, яку потрібно індексувати, має стабільно повертати HTTP 200 і показувати основний вміст без входу в обліковий запис.

Перевірте URL у приватному режимі браузера, а потім перегляньте код відповіді та весь ланцюжок перенаправлень. Кінцева адреса не повинна повертати 404, 410, 5xx, вести по колу або знову переспрямовувати на початкову URL.

Окремо з’ясуйте, що бачить робот:

• чи не з’являється CAPTCHA замість сторінки;
• чи немає повідомлення про блокування;
• чи завантажуються заголовок, текст і посилання;
• чи доступний зміст без складного сценарію в браузері;
• чи не повертає сервер порожній шаблон із кодом 200.

Сам код 200 не підтверджує придатність сторінки до індексації. Сервер може показувати повідомлення «нічого не знайдено» для неіснуючого товару, але формально відповідати 200. Google може розпізнати таку сторінку як soft 404.

Для видаленого товару рішення залежить від стану сторінки. Якщо товар тимчасово відсутній, але URL зберігає корисні характеристики, альтернативи й зрозуміле повідомлення про статус, адресу часто доцільно залишити. Якщо сторінка більше не має заміни та змісту, обирайте між 404, 410 або перенаправленням на справді релевантну сторінку. Не перенаправляйте всі видалені товари на головну автоматично.

Як зрозуміти, чи Google вибрав іншу canonical-адресу?

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

У Search Console знайдіть два поля: canonical, указаний користувачем, і canonical, вибраний Google. Потім відкрийте вихідний код. Тег `rel="canonical"` має вести на абсолютну доступну адресу з правильним протоколом, доменом і шляхом.

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

Перевірте типові джерела дублів:

• HTTP і HTTPS;
• адреси з `www` та без нього;
• URL зі слешем і без слеша;
• параметри сортування, фільтрації та відстеження;
• сторінки для друку;
• однаковий товар у кількох категоріях;
• тестовий домен або піддомен.

Основна версія має повертати 200, містити self-canonical та отримувати внутрішні посилання. Не спрямовуйте canonical усіх категорій, товарів чи послуг на головну: такий сигнал повідомляє, що окремі сторінки не мають самостійної версії.

Чи допомагають sitemap і внутрішні посилання знайти сторінку?

Так, вони допомагають Google виявляти URL і розуміти структуру сайту, але не гарантують індексацію.

У sitemap варто додавати канонічні сторінки, які повертають 200 і мають з’являтися в пошуку. Переконайтеся, що файл відкривається без авторизації, доданий до Search Console, містить основний протокол і домен та не включає адреси з `noindex`, перенаправленнями, помилками або службовими параметрами.

Якщо використовується `lastmod`, він має відображати суттєве оновлення сторінки. Автоматична зміна дати без зміни вмісту не додає URL цінності. Сам sitemap Google розглядає як підказку, а не як гарантію сканування чи включення до індексу.

Після карти сайту перевірте внутрішні переходи. Для кожної важливої сторінки дайте відповіді на три питання:

1. Чи можна перейти до неї звичайним HTML-посиланням?
2. Чи пояснює текст посилання зміст цільової сторінки?
3. Чи не захована URL глибоко в пагінації, фільтрах або ізольованому розділі?

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

Чи має сторінка окрему цінність для пошуку?

Сторінка має самостійно відповідати на конкретну потребу, а не повторювати сусідні URL із кількома зміненими словами.

Якщо технічних заборон немає, але Search Console показує «Проскановано — наразі не проіндексовано» або Google обирає іншу canonical-адресу, оцініть призначення та зміст URL:

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

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

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

Що робити після усунення знайденої причини?

Повторно протестуйте сторінку, запросіть індексацію для важливої одиничної URL та стежте за зміною статусу в Search Console.

Дотримуйтеся такої послідовності:

1. Зафіксуйте початковий статус і дату перевірки.
2. Усуньте підтверджену причину або пов’язаний набір помилок.
3. Перевірте HTTP-відповідь, robots, canonical і видимий вміст.
4. Запустіть тест опублікованої URL.
5. Надішліть запит на індексацію важливої сторінки.
6. Для масових змін оновіть sitemap і внутрішні посилання.
7. Після індексації перевірте покази за релевантними запитами.

Не надсилайте ту саму адресу багато разів: повторні запити не прискорюють сканування, а інструмент має обмеження використання. Також не кожне виключення потребує виправлення. Перенаправлення, дублікати з коректним canonical, службові фільтри та навмисно закриті розділи можуть мати правильний статус.

Мета перевірки — не домогтися індексації максимальної кількості адрес, а зробити доступними потрібні сторінки. Чек-лист не замінює діагностику ручних заходів, проблем безпеки, зламу, складних помилок JavaScript або серверного блокування Googlebot. WebManna Studio працює з Search Console, GA4, GTM, WordPress, WooCommerce, OpenCart і Laravel; більше про напрямки роботи можна переглянути на головній сторінці команди.