Помилки Google Search Console: що виправляти першим

Помилки Google Search Console — це повідомлення про те, що Google не зміг просканувати, проіндексувати, безпечно віддати або показати частину ваших сторінок так, як ви задумали. Вони з'являються в різних звітах: «Індексування сторінок», HTTPS, «Основні веб-показники» (Core Web Vitals), звіти про розширені результати, «Статистика сканування», «Заходи, вжиті вручну» та «Проблеми з безпекою». Серйозність у них дуже різна. Одні повністю прибирають сайт із пошуку, інші — звичайна поточна робота.

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

Які помилки Google Search Console найважливіші?

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

Орієнтовний порядок за серйозністю:

Вага помилки залежить і від того, які URL вона зачіпає. 404 на старій сторінці тегу, яку ви видалили навмисно, — нормально. 5xx на головній категорії товарів — ні.

Що означають ручні заходи та проблеми з безпекою?

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

Заходи, вжиті вручну

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

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

Щоб усунути ручний захід, відкрийте його опис і подивіться, яких сторінок він стосується, виправте кожну з них, переконайтеся, що Google має до них доступ, а потім натисніть «Надіслати запит на перевірку» (Request Review) і поясніть, що саме ви змінили. За словами Google, перевірка може тривати від кількох днів до кількох тижнів.

Проблеми з безпекою

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

Деталь, яку часто пропускають: Google пише, що виправлення лише частини сторінок не поверне сайт у пошук частково. Очистьте весь сайт, закрийте вразливість, через яку проник зловмисник, і тільки тоді надсилайте запит на перевірку.

Що означають помилки індексації сторінок?

Помилки індексації пояснюють, чому конкретного URL немає в індексі Google. Частина причин — справжні помилки: помилки сервера, помилково встановлені теги noindex, блокування потрібних сторінок у robots.txt. Інші описують сторінки, які виключено цілком слушно, як-от дублікати й переспрямування. Виправляти перші варто лише на URL, які ви справді хочете бачити в індексі.

У довідці про звіт «Індексування сторінок» Google перелічує всі причини. Ось вони, згруповані за тим, що з ними робити:

Двом статусам «наразі не проіндексовано» присвячено окремі посібники: Проскановано – наразі не проіндексовано і Виявлено – наразі не проіндексовано. Покроковий розбір кожної причини — у статті як виправити проблеми з індексацією сайту.

Чи завжди «не проіндексовано» — це проблема?

Ні. Документація Google прямо каже, що багато непроіндексованих сторінок виключено навмисно: дублікати, переспрямовані URL, сторінки, які ви заблокували або видалили. Сайт із 2000 проіндексованих сторінок і 5000 URL зі статусом «не проіндексовано» може бути цілком здоровим, якщо ці 5000 — комбінації фільтрів, старі переспрямування та канонізовані варіанти. Питання не в тому, наскільки велике число, а в тому, чи є в цьому списку бодай один URL, який має ранжуватися.

У звіті також є два попередження. «Проіндексовано, хоча заблоковано файлом robots.txt» означає, що Google проіндексував URL, який не зміг просканувати, — зазвичай тому, що на нього посилаються інші сторінки. Якщо ви хочете прибрати його з індексу, дозвольте сканування й додайте noindex. Сам лише robots.txt його не прибере (див. посібник із robots.txt для SEO). «Сторінку проіндексовано без вмісту» означає, що Google не зміг прочитати вміст сторінки — часто через клоакінг або формат, який Google не обробляє.

Що означають помилки стану хоста в статистиці сканування?

Проблеми зі станом хоста у звіті «Статистика сканування» означають, що Googlebot узагалі не міг нормально дістатися до сайту: через збої отримання robots.txt, збої DNS або збої з'єднання із сервером. Такі проблеми зачіпають одразу всі URL, тож недавній червоний статус тут важливіший майже за будь-яку помилку окремої сторінки.

Документація звіту «Статистика сканування» описує три категорії:

• Отримання robots.txt. Google потрібен або коректний файл robots.txt, або відповідь 404 на нього. Якщо запит повертає щось інше, наприклад 5xx чи тайм-аут, Google сповільнить або припинить сканування, доки не отримає прийнятну відповідь. Правило фаєрвола чи налаштування CDN, яке блокує /robots.txt для ботів, може непомітно заморозити сканування всього сайту.
• DNS. Ваш DNS-сервер не розпізнав ім'я хоста або не відповів. Перевірте реєстратора, NS-сервери та будь-яку недавню міграцію DNS.
• З'єднання із сервером. Сервер не відповів або надіслав неповну відповідь. Зазвичай причина — перевантаження, обмеження частоти запитів або захист від ботів, який сприймає Googlebot як атаку.

Кольори статусів допомагають розставити пріоритети. Червоний — недавні проблеми, які треба перевірити. Жовтий — проблеми, старші за тиждень. Зелений — суттєвих проблем немає.

Що означають помилки у звіті HTTPS?

Помилки у звіті HTTPS означають, що для частини сторінок Google проіндексував HTTP-версію замість HTTPS, а звіт пояснює чому. Типові причини — недійсний сертифікат, sitemap або canonical, що вказують на HTTP, а також HTTPS-адреси, які переспрямовують назад на HTTP або заблоковані в robots.txt.

Звіт HTTPS наводить такі причини:

1. HTTP-сторінку позначено тегом canonical: HTTP-сторінка вказує канонічною саму себе. Спрямуйте canonical на HTTPS.
2. HTTPS має недійсний сертифікат: зазвичай це стосується всього сайту. Поновіть або переналаштуйте сертифікат.
3. Sitemap вказує на HTTP: оновіть URL у sitemap на HTTPS.
4. HTTPS має переспрямування: HTTPS-адреса переспрямовує на HTTP. Розверніть переспрямування.
5. HTTPS-URL заблоковано в robots.txt: правило в robots.txt блокує HTTPS-версію.
6. HTTPS не оцінено: HTTPS-відповідника немає, Google обрав канонічною HTTP-версію або перевірці завадили інші помилки. Спершу виправте інші помилки.

Звіт доступний лише для ресурсів типу «Домен» і ресурсів із префіксом HTTPS-URL, а показує він приклади URL, а не повний список. Такі суперечливі сигнали часто мають ту саму першопричину, що й дубльований вміст, тож варто одночасно переглянути налаштування тегу canonical.

Що означають помилки Core Web Vitals і розширених результатів?

Статуси Core Web Vitals «Погано» або «Потребує покращення» означають, що реальні користувачі Chrome на групі URL стикалися з повільним завантаженням, повільною реакцією або зсувами макета. Помилки розширених результатів означають, що у структурованих даних є критична проблема, тож цей елемент не може з'явитися як розширений результат. Ні те, ні інше не заважає індексації сторінки.

Звіт «Основні веб-показники»

Звіт Core Web Vitals використовує польові дані з Chrome UX Report (CrUX). Він об'єднує схожі URL у групи й позначає кожну групу за її найгіршим показником:

Оскільки URL згруповано, один повільний шаблон (наприклад, усі статті блогу з важким головним зображенням) може одночасно відправити сотні URL у «Погано». Виправляйте шаблон, а не окремі сторінки. Після запуску перевірки Search Console відстежує групу 28 днів. Як саме виправляти, розповідає посібник із Core Web Vitals.

Звіти про статус розширених результатів

У звітах про статус розширених результатів елементи бувають дійсними або недійсними. Критичні проблеми («Чому елементи недійсні») роблять елемент непридатним для розширених результатів. Некритичні («Покращте вигляд елемента») на придатність не впливають. Відсутні обов'язкові властивості — критична проблема, тож виправляйте їх першими. Відсутні рекомендовані поля — необов'язкові.

Пам'ятайте, що деяких типів розширених результатів уже не існує. Google прибрав розширені результати HowTo у 2023 році, а FAQ — для всіх сайтів у травні 2026 року, тож додавання такої розмітки розширені сніпети не поверне.

Повідомлення щодо sitemap, як-от «Не вдалося отримати» чи «Помилка синтаксичного аналізу», детально розібрано в статті помилки XML sitemap.

У якому порядку виправляти помилки Search Console?

Рухайтеся від проблем усього сайту до проблем окремих сторінок і від сторінок, що приносять гроші, до решти. Перевірте ручні заходи й проблеми з безпекою, потім стан хоста, потім помилки індексації на важливих URL, далі HTTPS, а наостанок Core Web Vitals і структуровані дані. Коли виправлення вже на сайті, запускайте його перевірку в Search Console.

Практичний порядок дій:

1. Перевірте «Заходи, вжиті вручну» та «Проблеми з безпекою». Якщо в будь-якому з них є знахідка, зупиніться й займіться нею першою.
2. Відкрийте «Статистика сканування» → «Стан хоста». Виправте будь-який недавній червоний статус.
3. Відфільтруйте «Індексування сторінок» за sitemap. Оберіть у фільтрі надісланий sitemap, щоб бачити помилки на URL, які ви справді хочете проіндексувати, а не шум сканування.
4. Скористайтеся «Перевіркою URL-адреси» для кількох прикладів URL з кожної причини. Порівняйте перевірку live-версії з проіндексованою, щоб підтвердити причину.
5. Виправляйте на рівні шаблонів. Один noindex у шаблоні категорії або одне правило в robots.txt часто пояснюють тисячі URL.
6. Натисніть «Перевірити виправлення» (Validate fix). За словами Google, перевірка індексування сторінок зазвичай триває до двох тижнів. Відстеження Core Web Vitals триває 28 днів.

Search Console показує лише приклади уражених URL і лише для сторінок, які Google намагався просканувати. Сканування всього сайту краулером закриває ці прогалини: воно знаходить теги noindex, зламані переспрямування й заблоковані ресурси, що стоять за кожним повідомленням, ще до того, як про них повідомить Google. Якщо хочете, щоб таку перехресну перевірку зробили за вас, безкоштовний SEO-аудит від SEORecheck просканує ваші сторінки й позначить проблеми з індексованістю, robots.txt, переспрямуваннями, canonical, HTTPS і Core Web Vitals із прикладами URL. Як це виглядає, можна подивитися у зразку звіту.

Коли список довгий, розставляйте виправлення за впливом і трудомісткістю. Простий підхід до цього описано в статті як розставити пріоритети SEO-виправлень.

Чому виправлені помилки повертаються?

Зазвичай тому, що причина лежить вище за течією: оновлення плагіна CMS повертає noindex, деплой перезаписує robots.txt або правило CDN знову починає блокувати ботів. У документації Google про розширені результати зазначено, що якщо проблема повертається протягом 90 днів, зберігається початкова дата її виявлення. Після кожного релізу перевіряйте налаштування, які ламаються найчастіше. SEO-регресійне тестування перетворює це на чекліст, який можна повторювати.

Головне

• Не кожне повідомлення Search Console — помилка. Багато URL зі статусом «не проіндексовано» виключено навмисно.
• Ручні заходи, проблеми з безпекою та збої стану хоста зачіпають увесь сайт, тому перевіряйте їх першими.
• Оцінюйте помилки індексації за тим, які URL вони зачіпають. Фільтруйте за sitemap, щоб бачити важливі URL.
• Помилки HTTPS майже завжди виникають через суперечливі сигнали: canonical, sitemap або переспрямування, що вказують на HTTP.
• Проблеми з Core Web Vitals і розширеними результатами не блокують індексацію. Виправляйте їх на рівні шаблонів.
• Виправте, протестуйте, потім запустіть перевірку. Розраховуйте приблизно на два тижні для перевірки індексування і 28 днів для Core Web Vitals.