Сайт зник із Google після технічного збою: план відновлення індексації

Різке падіння або повне зникнення сайту з результатів Google після технічного збою не завжди означає втрату сторінок назавжди. Причиною може бути тимчасова недоступність сервера, неправильна конфігурація WordPress, помилки DNS, блокування сканування або зміни в базі даних. Важливо не починати навмання змінювати файли й налаштування: спершу зафіксуйте симптоми, створіть резервну копію та визначте, на якому етапі виникла проблема.

Як технічний збій впливає на індексацію

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

Найпоширеніші наслідки технічного збою:

• помилки 500, 502, 503 або тривалі тайм-аути;
• перенаправлення на сторінку технічних робіт, авторизації чи іншого домену;
• випадково встановлений атрибут noindex;
• заборона сканування в robots.txt;
• помилки HTTPS, DNS або налаштувань CDN;
• пошкодження таблиць бази даних чи файлів WordPress;
• зміна канонічних URL, структури посилань або адреси сайту;
• вірусний код, який показує пошуковим роботам небезпечний або некоректний вміст.

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

Перевірка кодів відповіді robots.txt і noindex

Почніть із перевірки доступності головної сторінки та кількох важливих URL у звичайному браузері й через інструменти діагностики HTTP. Для сторінок, які мають бути в Google, бажано отримувати код 200 OK. Коди 4xx вказують на проблеми з адресою або доступом, а 5xx — на збій сервера чи програмної частини сайту.

Окремо відкрийте файл https://ваш-домен.ua/robots.txt. Перевірте, чи немає надто широкого правила на кшталт:

User-agent: *
Disallow: /

Таке правило забороняє роботам сканувати весь сайт. Водночас важливо розуміти: robots.txt керує переважно обходом, але не є надійним способом видалення URL з індексу. Якщо сторінки вже відомі Google з інших джерел, вони іноді можуть відображатися без повного сканування.

Далі перевірте HTML-код сторінок і HTTP-заголовки. Небезпечними для індексації можуть бути:

• <meta name="robots" content="noindex">;
• заголовок X-Robots-Tag: noindex;
• канонічне посилання на іншу сторінку або домен;
• автоматичне перенаправлення на нерелевантну адресу;
• сторінка-заглушка з кодом 200 замість реального вмісту.

У WordPress також перевірте налаштування, які забороняють пошуковим системам індексувати сайт. Після технічних робіт така опція може залишитися увімкненою. Не забудьте перевірити налаштування SEO-плагіна, шаблону та окремих сторінок — заборона може бути встановлена не на весь сайт, а лише на частину URL.

Що подивитися в Google Search Console

У Google Search Console спочатку переконайтеся, що відкрито правильну властивість: потрібний домен, протокол https і варіант із або без www. Якщо сайт переносили або змінювали домен, старі й нові властивості можуть містити різні дані.

У звіті про індексацію перегляньте:

• кількість проіндексованих і виключених сторінок;
• помилки сервера та проблеми зі статусом URL;
• сторінки з позначкою «Проскановано — наразі не проіндексовано»;
• сторінки з позначкою «Виявлено — наразі не проіндексовано»;
• дублікати, проблеми з канонічними URL і перенаправленнями;
• помилки у файлі Sitemap.

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

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

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

Як прискорити повторний обхід важливих сторінок

Спочатку усуньте саму причину збою: відновіть стабільну роботу сервера, виправте DNS і HTTPS, приберіть помилковий noindex, налаштуйте robots.txt та перевірте коректність WordPress. Поки сайт періодично повертає помилки, повторні запити на індексацію не дадуть надійного результату.

Після технічної перевірки дійте послідовно:

1. Визначте перелік найважливіших сторінок, а не надсилайте на перевірку всі URL без розбору.
2. Переконайтеся, що сторінки доступні без авторизації, мають код 200, корисний вміст і правильний канонічний URL.
3. Перевірте внутрішню перелінковку: важливі сторінки мають бути доступними з меню, категорій або інших проіндексованих матеріалів.
4. Оновіть XML-карту сайту та надішліть її в Google Search Console.
5. Використайте функцію запиту на індексацію для пріоритетних сторінок після того, як вони успішно пройдуть перевірку URL.
6. Не змінюйте одночасно структуру адрес, текст, шаблон і десятки технічних параметрів — це ускладнить визначення причини подальших проблем.

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

Коли чекати повернення видимості

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

Оцінюйте не лише позиції, а й послідовність технічних сигналів: сторінки стабільно відкриваються, у Search Console зникають нові помилки, URL повторно скануються, зростають покази та кількість проіндексованих сторінок. Різкі зміни запитів, масове видалення URL або повторне редагування сайту без аналізу можуть відтермінувати відновлення.

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