403 у відповідь Googlebot — це не спрацьований захист, а сторінка, яка йде з індексу. Google формулює це прямо у звіті про індексування: код 403 означає, що агент передав облікові дані й отримав відмову, але «Googlebot ніколи не передає облікові дані, тому сервер повертає цю помилку неправильно». Сторінку не буде проіндексовано.
Цим 403 відрізняється від більшості проблем обходу. Майже ніколи це не усвідомлене рішення щодо конкретної сторінки. Це правило фаєрвола, фільтр ботів або обмеження частоти, під яке Googlebot потрапив випадково, — а власник сайту дізнається про це за тижні, коли трафік уже пішов.
Що Google робить з відповіддю 403
Документація з обходу обробляє всю родину 4xx однаково, з одним винятком: «Усі помилки 4xx, крім 429, обробляються однаково: сканери Google повідомляють наступній системі обробки, що контенту не існує». Для пошуку з цього випливають два наслідки, записані в тому ж документі:
- «конвеєр індексування видаляє URL з індексу, якщо його було проіндексовано раніше»;
- «Будь-який контент, який Google отримує з URL, що повертають код 4xx, ігнорується» — тобто що б не було написано на вашій сторінці помилки, як контент це не читається.
Ні відстрочки, ні проміжного стану в документації немає. Сторінка, яка відповідає 403, для Google — зникла сторінка. Решта родини 4xx поводиться так само: 401, 404, 410 і 411 закінчуються тим самим, тому й лагодиться все однаково, який би з них не віддавав сервер.
403 не сповільнює обхід — і в цьому головна помилка
Більшість 403 для Googlebot з'явилися тому, що хтось хотів менше ботового трафіку. Документація відповідає саме на це: «Не використовуйте коди 401 і 403 для обмеження частоти сканування. Коди 4xx, крім 429, не впливають на частоту сканування».
Тобто блокування не робить нічого з навантаженням і робить усе з індексом. Задокументований сигнал про перевантаження — 429: сканери Google «сприймають його як сигнал про перевантаження сервера», і обробляється він як помилка сервера, а не як відсутність сторінки. Якщо мета — розвантажити сервер, відповідь 429, а 403 — це шкода.
Чому в браузері сторінка відкривається, а Googlebot її не бачить
Саме тому 403 важко помітити: ви відкриваєте URL, і він працює. Правила, які його породжують, майже завжди умовні, і умова — майже ніколи не «цей URL».
| Що спрацьовує | Чому під це потрапляє Googlebot |
|---|---|
| Правило WAF або антибот-захисту | Правило ловить user-agent або шаблон запитів, а трафік сканера виглядає саме так, як шаблон, проти якого правило писали. |
| Обмеження частоти за user-agent | Googlebot запитує багато URL за короткий час — саме та форма, яку просте правило вважає зловживанням. |
| Геоблокування | Google сканує переважно з американських адрес. Білий список країн без них блокує сканер, а не аудиторію. |
| Захист від хотлінку і перевірка referer | У запитів сканера немає referer, тому правило, яке його вимагає, відмовляє. |
| Забута авторизація зі стейджа | Basic auth або білий список IP переживає запуск: головна відкрита, розділи глибше — ні. |
| Пейвол або закритий розділ | Усвідомлено, але тоді цих URL не повинно бути ні в sitemap, ні у внутрішніх посиланнях. |
Друга пастка: правило може блокувати запити, які називають себе Googlebot, тоді як справжнього сканера можна перевірити. Google документує два способи підтвердити, що запит дійсно прийшов від його сканерів: зворотний DNS-запит або звірка IP з опублікованими діапазонами Googlebot. Фільтрація лише за рядком user-agent блокує справжній сканер і пропускає підроблений.
Як знайти всі 403 на своєму сайті
Три перевірки по порядку, від найширшої до найточнішої. Жодна не потребує платного інструмента.
- Проскануйте сайт і прочитайте колонку статусів. Краул покаже, які URL відповідають 403 прямо зараз, включно з тими, про які Search Console ще не повідомила, бо не перезапитувала їх. Наш сканер сайту виводить код відповіді для кожного знайденого URL.
- Перевірте конкретний список URL. Якщо розділ уже під підозрою — каталог, фільтри, посторінкова навігація, — вставте список у перевірку редиректів і статусів і читайте коди пачкою, а не по одному.
- Подивіться, що вже записала Search Console. У звіті про індексування є статус із точним формулюванням «Доступ заблоковано (помилка 403)». Наш інструмент проблем індексації групує такі URL, щоб було видно: це шаблон, папка чи весь сайт.
Щоб довести, що конкретний URL відмовляє саме Googlebot, а не вам, запустіть живу перевірку в інструменті перевірки URL. Він запитує сторінку як Google і показує фактично отриману відповідь — це закриває суперечку «у мене відкривається» одним кліком.
Як лагодити — за причинами
Лагодження — це не «віддавати 200 усьому підряд». Це привести відповідь у відповідність до призначення URL.
| Ситуація | Правильна відповідь |
|---|---|
| Сторінка має бути в пошуку | Пропустити сканер. Перевіряти запит по-справжньому, а не фільтрувати за user-agent. |
| Сервер справді перевантажений | 429, а не 403: це задокументований сигнал перевантаження, і обробляється він як помилка сервера. |
| Сторінку взагалі не треба обходити | Заборонити в robots.txt, щоб сканер не витрачав на неї запити. |
| Сторінки більше немає | 410 або 404 — обидва прибирають її з індексу і обидва кажуть правду. |
| Контент переїхав | 301 на нову адресу. |
| Розділ закрито навмисно | 403 залишити, але прибрати URL із sitemap і з внутрішніх посилань. |
Після виправлення надішліть на переобхід кілька зачеплених URL, а не всі: сканер повернеться сам, коли сторінки почнуть відповідати нормально. Решта рішень щодо кодів відповіді зібрана в нашому довіднику HTTP-статусів.
За чим стежити після виправлення
403, який тримався тижнями, не відіграється в день полагодження. Сторінки потрібно переобійти, обробити і переіндексувати, і строків на це документація Google не називає. Стежити можна за формою: число у статусі «Доступ заблоковано (помилка 403)» має падати, а покази за зачепленими URL повернуться раніше за кліки. Якщо за пару тижнів число не зрушило взагалі — правило досі спрацьовує для сканера, хоча для вас уже ні, і це повертає до перевірки справжності вище. Звіти для всього цього — в інструментах Search Console.