Помилка сканування (Crawl anomaly) в Google Search Console: що це означає і що робити

Що насправді означає «Crawl anomaly»

У Google Search Console (GSC) «Crawl anomaly» — це категорія, а не діагноз. Це спосіб Google сказати:
«Ми намагалися просканувати цей URL, але результат вибірки не вписався в інші очікувані мітки
(наприклад чистий 404, очевидний 500 або редирект, який ми могли відслідкувати).»

Фактично, це зазвичай означає, що під час вибірки сталося одне з наступного:

• Збій на рівні з’єднання: збої DNS, відмова TCP-з’єднання, помилка TLS handshake або скидання посеред потоку.
• Таймаут: сервер був доступний, але не відповів достатньо швидко (або застиг під час відповіді).
• Дивна відповідь: обрізане тіло, пошкоджені заголовки, неконсистентний content-length або протокольні аномалії.
• Переривчаста поведінка на краю: політики CDN/WAF з rate limiting або механізми захисту від ботів, що інколи блокують Googlebot.
• Транзитне перевантаження сервера: піки, що викликають 5xx або повільні відповіді, але не настільки постійні, щоби класифікуватися як тривала помилка сервера.

Нюанс у тому, що GSC повідомляє з перспективи Google, а не вашої. Ваш моніторинг може показувати «99.99%»,
і все одно ви отримаєте crawl anomaly, якщо відмови локалізовані (один POP), залежать від user-agent (лише Googlebot)
або переривчасті (один з п’ятдесяти запитів).

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

Як сканує Googlebot (і чому виникають аномалії)

Googlebot — це не одна машина, яка ввічливо запитує ваш домашній індекс. Це розподілена система з кількома краулерами, діапазонами IP
і різною поведінкою запитів, що відрізняється за типом ресурсу (HTML проти зображень чи JS), пристроєм (смартфон проти десктопу)
та призначенням (відкриття нових URL проти оновлення старих). Аномалії з’являються, коли поведінка сайту нестабільна в цих вимірах.

Пайплайн сканування простими термінами операційника

1. Виявлення: Google знаходить URL через sitemap, посилання, редиректи, фіди або історичні дані.
2. Планування: вирішує, коли і з якою агресивністю сканувати, з огляду на попередні успіхи, «пропускну здатність» сайту та важливість.
3. Вибірка: DNS, TCP/TLS, HTTP-запит, заголовки та тіло, редиректи, контент-неґоціація.
4. Рендеринг (часто): особливо на сучасних сайтах, Google виконує JS і формує фінальний DOM.
5. Індексація: обробка контенту, канонізація, дедуплікація та злиття з іншими сигналами.

Де народжуються аномалії

«Crawl anomaly» зазвичай виникає на кроці 3 (вибірка) і інколи на межі між вибіркою та рендерингом
(наприклад, коли вибірка повертає технічно валідну, але операційно непридатну відповідь — 200 з CAPTCHA-сторінкою
або 200 з частковою відповіддю через upstream reset).

Оперативна реальність: Googlebot буде повторювати запити. Але повторні відмови можуть знизити швидкість краулінгу й уповільнити виявлення.
Ви можете потрапити у неприємне зачароване коло: транзитне перевантаження викликає відмови; відмови зменшують ефективність сканування;
Google змінює планування; ваша система бачить більш сплескові патерни; виникає більше перевантажень.

Цитата, бо вона універсальна і точна. Вернер Фогельс (CTO Amazon) сказав: «Everything fails, all the time.»
Це не песимізм; це ваша специфікація для дизайну моніторингу.

Швидкий план діагностики

Коли ви на виклику за SEO-надійність, не починайте з дискусії про канонічні теги. Почніть з того, чи це:
мережа/DNS, політика на краю, перевантаження origin або трик з контентом.
Ось швидка, опінійована послідовність, яка швидко знаходить вузьке місце.

По-перше: підтвердьте охоплення й свіжість

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

По-друге: відтворіть вибірку як бот

• Отримайте сторінку з різних мереж/регіонів (ваш ноутбук, хмарний VM, моніторинговий вузол).
• Використовуйте user-agent Googlebot і слідуйте за редиректами.
• Проаналізуйте заголовки: стан кешу, vary, location, server timing, маркери помилок CDN.

По-третє: перевірте здоров’я origin і пропускну здатність

• Шукайте 5xx, таймаути, upstream reset у логах навколо вказаного часу.
• Перевірте насичення з’єднань (SYN backlog, conntrack table, ліміти воркерів Nginx).
• Перевірте залежності додатка (вичерпання пулу БД, затримки об’єктного сховища, виклики сторонніх сервісів).

По-четверте: перевірте політику robots і контроль на краю

• robots.txt має бути швидким і надійним.
• Правила WAF не повинні «інколи» піддавати Googlebot викликам.
• Rate limiting має враховувати сплески й повторні спроби.

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

Цікаві факти й історичний контекст

• Термін «Googlebot» передує сучасним сайтам з великим JS; раніше сканування передбачало в основному статичний HTML і передбачувані патерни вибірки.
• Search Console раніше називалася «Webmaster Tools», що відображало епоху, коли проблеми сканування були здебільшого пов’язані з robots.txt і 404.
• Google перейшов на mobile-first індексацію, тож поведінка сканування й рендерингу більше відображає мобільні user-agent і обмеження.
• Google працює кількома краулерами (discovery, refresh, rendering, image тощо), тому ваш край може бачити різні сигнатури запитів.
• Швидкість краулінгу адаптивна; повторні відмови можуть зменшити попит, але успіхи можуть швидко його підвищити.
• HTTP/2 і HTTP/3 змінили режими відмов; мультиплексування і QUIC додають нові місця, де проміжні ланки можуть поводитися некоректно.
• CDN стали типовою інфраструктурою, і багато аномалій сканування — це проблеми політики на краю, а не origin.
• robots.txt — одиночна точка політики; якщо він повільний або переривчасто падає, він може широку заборону на сканування, навіть якщо сторінки нормальні.

Тріаж за симптомом: поширені шаблони аномалій

1) Переривчасті таймаути на певних шаблонах

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

Як відрізнити: Логи показують 200 з дуже високим TTFB або 499/504 залежно від проксі й таймаутів.

Виправлення: Розумне кешування, таймаути навколо залежностей і повернення корисного HTML без очікування на необов’язкові віджети.

2) Googlebot інколи блокується

WAF, бот-менеджери та rate limit-и люблять ймовірнісне застосування політик. Це добре для зупинки credential stuffing.
Це погано для детермінованого сканування.

Як відрізнити: Відповіді включають challenge-сторінки, сплески 403/429 для UA Googlebot або заголовки з bot score.

Виправлення: Додайте в білд-лист перевірені IP Googlebot або пом’якшіть правила для Googlebot на основі reverse DNS + forward-перевірки.

3) Крихкість DNS і TLS

Неправильні налаштування DNS рідко виглядають як повні відмови. Вони проявляються як «деякі резолвери падають» або «деякі регіони бачать прострочені ланцюги сертифікатів».
Краулери Google знайдуть ці гострі кути.

Як відрізнити: Помилки з’єднання без HTTP-статусу; помилки TLS handshake; відтворюється лише в певних датацентрах.

Виправлення: Чистий DNS, резервні авторитетні сервери і правильні CAA-записи, а також автоматизація сертифікатів з моніторингом.

4) Петлі редиректів і ланцюги редиректів

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

Як відрізнити: Кілька стрибків 301/302; змішування http/https; canonical і редирект не збігаються.

Виправлення: Одноступінчаті редиректи до фінального канонічного URL, узгоджена схема та хост.

5) «200 OK», але не той контент (м’які блоки)

Сторінка може повертати 200 і водночас бути операційною невдачею: сторінки з логіном, «доступ заборонено», гео-блоки або заглушки від upstream.
Google може віднести такий випадок до аномалії, бо це не схоже на нормальну вибірку сторінки.

Як відрізнити: 200 з малим розміром тіла, однаковий HTML на багатьох URL або відомі відбитки сторінок блокування.

Виправлення: Подавайте коректний контент ботам, уникайте захисту публічних сторінок, використовуйте правильні статус-коди для сторінок помилок.

Практичні завдання (команди + що означає вивід + рішення)

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

Завдання 1: Відтворіть з Googlebot user-agent і перевірте заголовки

cr0x@server:~$ curl -sS -D - -o /dev/null -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -L https://www.example.com/some/url
HTTP/2 200
date: Fri, 27 Dec 2025 10:12:34 GMT
content-type: text/html; charset=utf-8
cache-control: max-age=60
server: nginx
cf-cache-status: HIT

Що це означає: Ви отримали чистий 200 через HTTP/2, і CDN каже HIT (гарно). Якщо натомість бачите 403/429 або заголовок challenge, — це проблеми політик на краю.

Рішення: Якщо відповідь відрізняється від звичайних браузерів або від інших мереж, пріоритезуйте налаштування WAF/CDN перед налагодженням додатка.

Завдання 2: Виміряйте TTFB і загальний час; не вгадуйте «швидко»

cr0x@server:~$ curl -sS -o /dev/null -w "namelookup:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://www.example.com/some/url
namelookup:0.003 connect:0.012 tls:0.041 ttfb:1.876 total:1.901

Що це означає: TTFB = 1.8 с. Це не катастрофа, але червоний прапорець, якщо під час краулінгових сплесків це зростає. Якщо TTFB дуже великий і total близький до нього — бекенд повільний.

Рішення: Якщо TTFB > 1s на важливих сторінках, розглядайте це як інцидент продуктивності: зменшіть латентність залежностей, додайте кешування і перевірте таймаути upstream.

Завдання 3: Перевірте, що robots.txt швидкий і завжди доступний

cr0x@server:~$ curl -sS -D - -o /dev/null https://www.example.com/robots.txt
HTTP/2 200
content-type: text/plain
cache-control: max-age=3600

Що це означає: 200 — добре. Якщо ви бачите 5xx, 403 або 30x петлі, Google може зменшити краулінг або неправильно застосувати правила.

Рішення: Якщо robots.txt не повертає чистий кешований 200, виправте це перш ніж шукати причини на рівні сторінок.

Завдання 4: Перевірте резолюцію DNS з вашого сервера (не лише з ноутбука)

cr0x@server:~$ dig +time=2 +tries=1 www.example.com A

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 www.example.com A
;; ANSWER SECTION:
www.example.com. 60 IN A 203.0.113.10

Що це означає: Швидка відповідь з низьким TTL. Якщо ви бачите таймаути або SERVFAIL, Google також може їх бачити.

Рішення: Якщо DNS нестабільний, зупиніться: виправляйте авторитетний DNS, зменшуйте складність і підтверджуйте глобальну пропагацію.

Завдання 5: Підтвердіть ланцюг TLS і термін дії сертифіката

cr0x@server:~$ echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates
issuer=CN = Example Intermediate CA
subject=CN = www.example.com
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT

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

Рішення: Якщо сертифікат скоро спливає або видавець дивний, замініть сертифікати і перевірте доставку повного ланцюга на краю.

Завдання 6: Перевірте розподіл HTTP-статусів для постраждалих URL у access log

cr0x@server:~$ awk '$7 ~ /\/some\/url/ {print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
   1243 200
     37 304
     11 502
      6 504

Що це означає: Є 502/504 у вибірці. Класичний випадок «аномалії»: переривчасті upstream-відмови.

Рішення: Якщо є 5xx для коректних URL, розглядайте це як технічний борг надійності; переходьте до налагодження upstream і перевірки ємності.

Завдання 7: Відокремте запити Googlebot від решти трафіку

cr0x@server:~$ grep -i "Googlebot" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -nr | head
    312 200
     19 429
      8 503

Що це означає: Googlebot отримує rate limit (429) і інколи 503. Це не «Google занадто вибагливий». Це ви кажете Google йти геть.

Рішення: Якщо боти обмежуються, змініть правила: додайте allowlist для перевірених Googlebot IP, підвищте пороги або застосовуйте обмеження лише до дорогих ендпоінтів.

Завдання 8: Підтвердіть належність IP Googlebot (reverse DNS + forward check)

cr0x@server:~$ host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

cr0x@server:~$ host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Що це означає: Reverse резолвиться до домену googlebot, і forward резолвиться назад на той самий IP. Це стандартний патерн верифікації.

Рішення: Додайте в білд-лист лише на основі верифікованої належності. User-agent — дешевий обман; DNS-перевірка складніша для підробки.

Завдання 9: Перевірте насичення з’єднань і listen backlog

cr0x@server:~$ ss -s
Total: 2438 (kernel 0)
TCP:   1987 (estab 612, closed 1201, orphaned 0, timewait 1201)

cr0x@server:~$ ss -lntp | grep ':443'
LISTEN 0      511          0.0.0.0:443        0.0.0.0:*    users:(("nginx",pid=1324,fd=6))

Що це означає: Ви слухаєте з backlog 511. Якщо бачите дуже багато timewait/close і ретрансляцій, ви можете падати під сплеском з’єднань.

Рішення: Якщо насичення виникає під час краулінгових сплесків, налаштуйте worker_connections у Nginx, ліміти ОС і розгляньте захист CDN, щоб згладити хвилі.

Завдання 10: Перегляньте error.log Nginx на upstream reset/таймаути

cr0x@server:~$ tail -n 50 /var/log/nginx/error.log
2025/12/27 10:03:11 [error] 1324#1324: *9812 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 66.249.66.1, server: www.example.com, request: "GET /some/url HTTP/2.0", upstream: "http://127.0.0.1:8080/some/url", host: "www.example.com"

Що це означає: Upstream (додаток) не відповів вчасно. Цього разу клієнтом був Googlebot, але наступним може бути платний користувач.

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

Завдання 11: Швидко перевірте латентність додатка і частоту помилок (systemd + journal)

cr0x@server:~$ systemctl status app.service --no-pager
● app.service - Example Web App
     Loaded: loaded (/etc/systemd/system/app.service; enabled)
     Active: active (running) since Fri 2025-12-27 08:01:12 UTC; 2h 12min ago
   Main PID: 2201 (app)
     Tasks: 24
     Memory: 1.2G
        CPU: 38min

cr0x@server:~$ journalctl -u app.service -n 20 --no-pager
Dec 27 10:01:55 app[2201]: ERROR db pool exhausted waiting=30s path=/some/url

Що це означає: Вичерпання пулу БД. Це створює повільні відповіді й таймаути, які стають аномаліями сканування.

Рішення: Якщо пули вичерпуються, обережно збільшіть розмір, оптимізуйте запити і зменшіть залучення БД на запит. Додайте circuit breaker, щоб «опціональні» виклики не блокували формування HTML.

Завдання 12: Визначте, чи корелюють аномалії з деплоєм

cr0x@server:~$ grep -E "deploy|release|migrate" /var/log/syslog | tail -n 10
Dec 27 09:55:00 web01 deploy[9811]: release started version=2025.12.27.1
Dec 27 09:57:14 web01 deploy[9811]: release finished

Що це означає: Деплой стався прямо перед початком помилок. Кореляція не означає причинності, але це підказка, яку не ігнорують.

Рішення: Якщо аномалії збігаються з релізами, робіть rollback або хотфікс. SEO-аутейджі не стають менш реальними, бо це «лише боти».

Завдання 13: Виявлення ланцюгів і петель редиректів

cr0x@server:~$ curl -sS -I -L -o /dev/null -w "%{url_effective} %{num_redirects}\n" http://www.example.com/some/url
https://www.example.com/some/url 2

Що це означає: Два редиректи (часто http→https плюс non-www→www або навпаки). Це допустимо, але витратно в масштабі.

Рішення: Якщо редиректів більше одного стрибка, уніфікуйте правила так, щоб бот і користувач потрапляли за один крок.

Завдання 14: Перевірте, чи challenge-сторінки маскуються під 200

cr0x@server:~$ curl -sS -A "Googlebot/2.1" https://www.example.com/some/url | head -n 20
<html>
<head><title>Just a moment...</title></head>
<body>
<h1>Checking your browser before accessing</h1>

Що це означає: Це — challenge-сторінка, а не ваш контент. Google може віднести це до аномалії або індексувати сміття, в залежності від того, що бачить.

Рішення: Виправте правила бот-митигейшну. Публічні сторінки не повинні вимагати танцю браузера, щоб їх прочитав краулер.

Жарт №1 (коротко, по темі): Якщо ваш WAF «захищає» вас від Googlebot, вітаємо — ви успішно захистили себе від клієнтів теж.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Середній маркетплейс перейшов на новий CDN. Проект виглядав чисто: тестовий трафік був нормальний, дашборди спокійні, і перехід відбувся
у вікно з малою активністю. За два дні GSC засвітилася crawl anomaly, концентровані на сторінках продуктів.

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

Справжня причина: продукт захисту від ботів у CDN трактував порядок заголовків HTTP/2 і деякі TLS-фінгерпринти як підозрілі.
Більшість користувачів були в порядку, бо браузери мали знайомий фінгерпринт і куки. Googlebot — ні. Деякі запити отримували 200 challenge-сторінку,
інші обривалися посеред з’єднання, і CDN не завжди логував це як очевидний блок.

Вони виправили це, реалізувавши правила allow для перевірених Googlebot (reverse+forward DNS), вимкнувши challenge для цього сегмента
і забезпечивши консистентну поведінку кешу для HTML. Аномалії сканування зникли за кілька циклів перекаулінгу.

Урок: припущення «rate limit» без доказів — як спалити тиждень. Аномалії часто пов’язані з неконсистентною поведінкою,
а не лише з «занадто багато трафіку».

Міні-історія 2: Оптимізація, що обернулась проти

Корпоративний контент-сайт хотів прискорити сторінки категорій. Хтось запропонував «розумну» оптимізацію на краю:
кешувати HTML для незалогінених користувачів 30 хвилин, але обходити кеш, якщо є query-параметри, щоб не віддавати неправильні варіанти.
Звучало логічно і тестувалося добре.

Потім SEO-команда запустила кампанію, яка створила тисячі нових параметризованих URL через внутрішню навігацію
(фільтри, сортування, трекінгові параметри). Googlebot швидко їх виявив. Раптом origin load подвоївся.

Origin не був розрахований на такий сплеск, бо більшість трафіку використовувала кешований HTML. Тепер Googlebot навалював uncached варіанти.
Додаток почав таймаутитись на дорогих агрегуючих запитах; Nginx логував upstream таймаути; GSC повідомляла про crawl anomaly,
і індексація нових сторінок сильно сповільнилась.

Вирішення не було просто «більше заліза» (вони пробували; допомогло, але не вирішило проблему). Вирішили політикою:
нормалізувати і видаляти смітні параметри, додати canonical теги, обмежити внутрішні посилання, що породжують нескінченні комбінації фільтрів,
і кешувати нормалізовані варіанти з контрольованим ключем.

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

Міні-історія 3: Нудна, але правильна практика, що врятувала день

SaaS-компанія мала щомісячний процес ротації сертифікатів. Це було нудно: автоматичне видавання, поетапний деплой і моніторинг,
що перевіряв термін дії і ланцюг ззовні кожну годину. Ніхто не хвалився цим.

Однієї п’ятниці upstream CA мав інцидент, що спричинив проблеми з розповсюдженням деяких проміжних сертифікатів. Частина їхніх edge-вузлів
стала показувати неповний ланцюг після рутинного reload. Більшість браузерів працювали через кешовані проміжні сертифікати.
Деякі клієнти падали. Краулери не гарантовано мали кеш потрібних проміжних сертифікатів.

Їхній моніторинг помітив це за кілька хвилин: TLS валідація впала з кількох регіонів. On-call відкатив конфігурацію краю,
розгорнув повний bundle ланцюга і підтвердив за допомогою зовнішньої openssl-перевірки.

GSC ніколи не встигла ескалувати до помітної події crawl anomaly, ймовірно тому, що вікно було коротким. SEO-команда навіть не знала.
Це мрія: найкращий SEO-інцидент — той, що ніколи ним не стає.

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

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

Сплеск crawl anomaly одразу після ввімкнення WAF/бот-менеджера

Симптом: Зростання аномалій у GSC; access логі показують 403/429 або підозріло маленькі 200 для Googlebot.

Корінна причина: Bot challenge або reputation scoring інколи блокує або змінює відповіді краулерам.

Виправлення: Перевірте IP Googlebot і додайте в білд-лист; вимкніть challenge для верифікованих ботів; забезпечте, щоб сторінки блокування повертали 403/429 (не 200).

Аномалії концентруються в директорії на кшталт /product/ або /blog/

Симптом: Постраждав лише один шаблон; інші сторінки скануються нормально.

Корінна причина: Шаблон-залежність бекенду повільна (запит до БД, персоналізація, зовнішній API) або гарячий шар.

Виправлення: Додайте кешування, оптимізуйте запити, таймаути та граціозне деградування. Робіть HTML без опціональних віджетів.

Аномалії виглядають «випадковими» по всьому сайту

Симптом: Розкидані URL по різних шаблонах; важко корелювати.

Корінна причина: Переривчасті інфраструктурні проблеми: флапи DNS, перевантаження балансувальника, conntrack exhaustion або проблеми POP CDN.

Виправлення: Поліпшіть резервування, підвищте ліміти ОС/мережі, додайте регіональні health checks і підтвердіть підключення CDN→origin.

GSC показує аномалії, але ваші синтетичні перевірки зелені

Симптом: Моніторинг перевіряє один URL з одного регіону — він в порядку. Google незадоволений.

Корінна причина: Ви тестуєте «легкий» шлях. Google б’є по довгих хвостах, параметрних варіантах і різних регіонах/UA.

Виправлення: Додайте багаторегіональні перевірки, включіть важливі шаблонні URL, тестуйте з Googlebot UA і алертуйте на латентність/TTFB, а не лише на аптайм.

Аномалії під час піків трафіку і сплесків 5xx

Симптом: Зростання 502/504; upstream таймаути; сплески CPU або навантаження БД.

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

Виправлення: Плануйте ємність під сплески, використовуйте кешування, ізолюйте дорогі ендпоінти, реалізуйте backpressure і черги, налаштуйте таймаути.

Аномалії після зміни правил редиректів

Симптом: GSC повідомляє аномалії на URL, які тепер редиректять; ви бачите петлі або ланцюги.

Корінна причина: Конфліктні правила редиректів між додатком, CDN і балансувальником; змішання каноніків і цілей редиректів.

Виправлення: Робіть редиректи однострибковими, встановіть canonical на фінальний URL і приберіть дублюючу логіку редиректів по шарах.

Жарт №2 (коротко, по темі): Crawl anomaly — це як сигнал диму з розрядженими батарейками: технічно «працює», але вам повідомляють, що щось не так.

Контрольні списки / покроковий план

Покроково: від сповіщення до кореневої причини за 60–180 хвилин

1. Витягніть вибірку постраждалих URL з GSC (експортуйте, якщо можливо) і згрупуйте за директорією/шаблоном.
2. Виберіть 10 репрезентативних URL: 5 важливих і 5 випадкових з списку аномалій.
3. Відтворіть вибірки за допомогою curl з Googlebot UA з принаймні двох мереж.
4. Занотуйте результати: HTTP-статус, кількість редиректів, TTFB, загальний час, розмір відповіді та будь-які відбитки challenge-сторінок.
5. Перевірте robots.txt на доступність і латентність.
6. Витягніть логи для цих URL: статуси, upstream-таймінги і помилки.
7. Сегментуйте трафік ботів: порівняйте патерни Googlebot та не-ботів.
8. Перевірте політику на краю: події WAF, ліміти частоти, рішення бот-менеджера (якщо є).
9. Перевірте здоров’я origin: CPU, пам’ять, відкриті файлові дескриптори, вичерпання пулів БД, rate помилок upstream.
10. Вносіть одне коригування за раз і перевіряйте цілеспрямовано fetch-тести.
11. Запит на валідацію в GSC подавайте для підмножини URL лише після того, як виправлення було повністю розгорнуто.

Операційний чеклист: зробіть сканування нудним

• Переконайтесь, що robots.txt статичний, кешований і подається з того ж надійного шляху, що й сайт.
• Тримайте редиректи однострибковими; уникайте дублювання логіки редиректів між CDN і додатком.
• Підтримуйте стабільні відповіді для публічних сторінок: уникайте CAPTCHA, consent walls або гео-блоків для верифікованих ботів.
• Моніторте TTFB та 95/99-перцентилі латентності для ключових шаблонів, а не лише аптайм.
• Інструментуйте латентність upstream і додавайте таймаути/circuit breakers.
• Контролюйте експлозію параметрів: канонізація, дисципліна внутрішніх посилань і гігієна кеш-ключів.
• Запускайте зовнішні перевірки DNS/TLS з кількох регіонів.

Чеклист рішень: коли ескалювати

• Ескалюйте негайно, якщо аномалії зачіпають критичні сторінки доходу і логи показують 5xx/таймаути.
• Ескалюйте до команди безпеки/edge, якщо бачите 403/429/сторінки challenge для Googlebot.
• Деприоритезуйте, якщо аномалії обмежені неканонічними параметрними URL, які ви плануєте видалити з індексу — після підтвердження, що важливі URL в порядку.
• Ескалюйте до власника DNS/TLS, якщо бачите помилки резолвера або проблеми ланцюга; це тихі вбивці.

Питання й відповіді (FAQ)

Чи «crawl anomaly» те ж саме, що «server error (5xx)»?

Ні. 5xx — це чітка серверна HTTP-помилка. «Crawl anomaly» — це суміш, що часто включає збої з’єднання, таймаути,
неконсистентні відповіді або втручання на краю, яке не вкладається в чисту категорію.

Чи можуть аномалії сканування погіршити ранжування?

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

Чому аномалії з’являються, коли сайт в браузері виглядає нормально?

Тому що ваш браузер — один клієнт з одного місця з куками й знайомим фінгерпринтом. Googlebot — це розподілений краулер,
що б’є по long-tail URL, холодним кешам і різним регіонам. Ваш сайт може бути «в порядку» для вас і водночас крихким для нього.

Чи потрібно білд-листити Googlebot?

Лише якщо ваш захисний стек викликає або блокує його. Якщо білд-листите, робіть це правильно: верифікуйте через reverse DNS і forward lookup.
Ніколи не довіряйте лише user-agent рядкам.

Який найшвидший спосіб визначити, чи це проблема WAF/CDN?

Порівняйте відповіді для того самого URL з Googlebot UA з різних мереж. Якщо бачите 403/429, challenge HTML або неконсистентні заголовки (стан кешу, bot-score),
ймовірно це політика на краю.

Чи можуть проблеми з рендерингом JavaScript викликати crawl anomaly?

Іноді, але більшість сповіщень «crawl anomaly» виникають на шарі вибірки. Проблеми рендерингу частіше проявляються як «indexed but content missing».
Проте якщо сервер повертає різний HTML в залежності від виконання JS, це може створити дивні результати вибірки.

Скільки часу GSC потребує, щоб відобразити виправлення?

Зазвичай дні, іноді довше — залежить від графіка сканування і важливості URL. Виправте проблему спочатку, потім запросіть валідацію для репрезентативних URL.
Не оновлюйте GSC панічно, немов це біржовий графік.

Чи варто збільшувати серверні таймаути, щоб зупинити аномалії?

Рідко як первинний фікс. Вищі таймаути можуть зменшити 504, але вони також збільшать використання ресурсів на запит і можуть погіршити перевантаження.
Краще виправити повільні залежності, кешувати і повертати частковий контент швидко.

Що робити, якщо аномалії зачіпають тільки URL, які мені не важливі?

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

Чи може sitemap викликати spike аномалій?

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

Наступні кроки, що дійсно мають значення

Ставтесь до «crawl anomaly» як до сигналу надійності від дуже наполегливого клієнта, якого ви хочете тримати задоволеним.
Не починайте з SEO-фольклору. Почніть із системної роботи: відтворіть, виміряйте, зіставте і виправте нестабільність.

1. Запустіть швидкий план діагностики і визначте, чи проблема в DNS/TLS, політиці на краю, ємності origin або логіці шаблону.
2. Виконайте практичні завдання на репрезентативному наборі URL, зосередившись на статусах, TTFB і відповідях для ботів.
3. Виправляйте реальну причину (allowlist WAF, налаштування таймаутів з виправленнями залежностей, нормалізація кешування, спрощення редиректів).
4. Покращуйте виявлення: додайте багаторегіональні проби і дашборди по логах, сегментовані ботами та користувачами.
5. Підтвердіть у GSC після того, як виправлення розгорнуто і стабільне, а не під час експериментів.

Зробіть сканування нудним. Нудне масштабується. І це дешевше за екстрені наради про те, чому «Google нас не бачить», коли всі інші бачать.