У разі перевантаження сервера спочатку відновіть доступність сайту разом із відповідальним за інфраструктуру, потім з’ясуйте, які запити та процеси створюють навантаження. Зростання кількості звернень із назвою Googlebot у журналі ще не доводить ні справжності робота, ні його ролі у збої.
Якщо внесок підтверджено й потрібен терміновий захід, розробник може тимчасово обмежити обробку запитів із коректною HTTP-відповіддю. Дія повинна мати область застосування, строк перегляду та план скасування: тривалі помилки здатні завадити обходу й вплинути на присутність сторінок у Google.
Зіставте навантаження та події в часі
Зафіксуйте ознаки інциденту: зростання часу відповіді, черги застосунку або бази даних, кількість помилок, недоступні розділи та дії покупців, на які вплинув збій. Запишіть початок і кінець спостережуваного періоду, часовий пояс і джерело кожного показника. Порівняйте їх зі звичайним періодом у подібних умовах, якщо є надійна база для порівняння.
Звірте підтверджені запити робота з користувацьким трафіком, імпортами товарів, завданнями за розкладом, змінами кешу та недавніми релізами. Одночасне зростання двох графіків – привід перевірити зв’язок, але ще не доказ того, що причина одна. Навантаження може виникнути через поєднання частих звернень і ресурсоємного запиту до бази.
Враховуйте рівень збирання. Журнал основного сервера не покаже всі відповіді, які CDN віддав із кешу, а дані CDN і застосунку описують різні ділянки шляху. Перевірте пропуски, правила вибірки та часові пояси. Не додавайте автоматично два записи одного звернення як два окремі запити.
Перевірте походження робота
Виділіть кандидатів за User-Agent, потім підтвердьте початковий IP за процедурою Google: для окремих адрес зіставте зворотний DNS, допустиме ім’я та результат прямого DNS; для великого масиву використовуйте актуальні діапазони відповідного класу роботів. Значення User-Agent можна підробити, а IP проксі не дорівнює автоматично адресі клієнта.
Розділіть основний Googlebot, спеціальні роботи та завантажувачі, які запускаються за запитом користувача. Збережіть метод, час перевірки та частку рядків, які не вдалося підтвердити. До звіту включайте агреговані дані; початкові IP та параметри URL зберігайте лише там, де це погоджено й необхідно.
Якщо походження не підтверджено через відсутність початкового IP або помилку DNS, не оголошуйте запит підробленим без додаткових даних. Перед будь-яким обмеженням попросіть фахівця перевірити наслідки для відвідувачів, пошукових роботів та інших сервісів.
Знайдіть вузьке місце на шляху запиту
Зіставте частоту підтверджених запитів із завантаженням процесора, з’єднаннями, чергами та часом роботи застосунку або бази даних. Розділіть відповіді з CDN і запити, що дійшли до основного сервера. Уточніть, що означає поле тривалості в кожному журналі: час обробки запиту, відповідь застосунку та завантаження сторінки користувачем – різні величини.
Розберіть, які групи URL потребують більше ресурсів. Ресурсоємний фільтр каталогу, генерація багатьох комбінацій, порожній кеш або одночасний імпорт можуть впливати на одну й ту саму базу. Перевірте кілька запитів та їхній шлях до джерела навантаження; кількість звернень сама по собі не показує вартість кожного.
Якщо сайт створює непотрібні комбінації фільтрів або календарів, знайдіть джерело їхніх посилань і погодьте постійне виправлення. При цьому захистіть корисні категорії, сторінки пагінації та користувацькі сценарії. Масова заборона всіх параметрів без такої перевірки може закрити потрібні URL і не усуває збій застосунку.
Приклад: збіг ще не означає єдину причину
В умовному магазині з 10:00 до 10:15 зріс час відповіді каталогу. У той самий період збільшилася кількість підтверджених запитів Googlebot, але команда також запустила імпорт залишків і виявила зниження частки відповідей із кешу CDN. Дати, показники та ситуація вигадані: це схема розслідування, а не дані клієнта.
| Період | Навантаження | Підтверджені запити | Помилки | Дія | Критерій скасування |
|---|---|---|---|---|---|
| До 10:00 | Каталог відповідає у звичайному для прикладу режимі | Є початковий рівень звернень | Суттєвого сплеску не помічено | Зберегти порівнянні метрики та налаштування | Обмеження ще не вводилося |
| 10:00–10:15 | Відповідь каталогу сповільнилася; триває імпорт, менше відповідей із кешу | Звернень Googlebot стало більше | З’явилися серверні помилки | Відновити доступність, вивчити імпорт, кеш і ресурсоємні маршрути | Переглянути заходи після стабілізації помилок і часу відповіді |
| Після тимчасового обмеження | Спостерігати застосунок, базу та CDN | Окремо відстежувати звернення підтвердженого робота | Відзначати фактичні 429/503 та їхню область | Виправити вузьке місце й поступово зняти тимчасове правило | Відповідальні підтвердили стабільність і перевірили важливі сторінки |
У цьому прикладі не можна заздалегідь призначити винуватцем лише Googlebot. Якщо після аналізу виявлено ресурсоємний імпорт і несправний кеш, виправляють ці причини; якщо внесок обходу теж підтверджено, добирають тимчасовий захід з урахуванням загального стану сервера.
Виберіть тимчасовий захід і обмежте його строк
В екстреній ситуації Google описує тимчасове повернення кодів 500, 503 або 429 на запити сканування як спосіб знизити частоту звернень. Якщо такі помилки повертають багато URL, частота може знизитися для всього хоста, включно зі справними сторінками. Рішення про конкретну відповідь і область її застосування ухвалює відповідальний за сервер. Не повертайте помилку справним сторінкам безстроково й не приховуйте від команди фактичну недоступність.
Для 429 або 503 можна передати заголовок Retry-After із затримкою в секундах або датою й часом у GMT. Він повідомляє, коли запит можна повторити; не слід трактувати його як гарантію точного часу наступного відвідування. Перевірте, як правило впливає на кеші, покупців та інші клієнтські застосунки.
Google не рекомендує використовувати такі відповіді довше двох днів: якщо помилки зберігаються протягом кількох днів, URL може бути видалено з індексу. Зниження обходу здатне також затримати виявлення нових сторінок і оновлення цін або наявності, а для деяких роботів зачепити рекламні процеси. Це аварійний захід, а не постійне налаштування SEO.
Якщо інфраструктура не дає змоги повертати такі відповіді роботам, Google описує спеціальний запит на зниження частоти у виняткових випадках. Його обробка може тривати кілька днів, тому він не замінює негайного відновлення сайту. Не розраховуйте на попередній регулятор швидкості в налаштуваннях Search Console як на універсальний доступний інструмент.
Поверніть нормальну роботу й перевірте наслідки
- Призначте відповідального, час наступної перевірки та умови зняття обмеження до його ввімкнення. Збережіть попередні налаштування й область дії.
- Виправте підтверджене вузьке місце: наприклад, збій кешу, ресурсоємне звернення до бази або неконтрольовану генерацію посилань. Перевіряйте зміни на погодженій області.
- Коли навантаження та помилки стабілізувалися, знімайте тимчасовий захід за планом. Відкрийте важливі сторінки й перевірте фактичні HTTP-відповіді, навігацію та основні дії відвідувачів.
- Порівняйте доступні логи, стан хоста й динаміку звернень за періоди з подібними умовами. Враховуйте CDN і незавершені фонові завдання.
- Окремо спостерігайте дані Google про важливі URL. Повернення відповіді 200 не підтверджує автоматичного відновлення індексації, показів або рекламних процесів.
Якщо для обмеження обходу окремих технічних шляхів розглядається robots.txt, спочатку перевірте цільові групи роботів і винятки. Порядок складання та перевірки описано в статті про правила robots.txt. У журналі інциденту збережіть початкові спостереження, застосовані заходи, час скасування та питання, що залишилися.
Потрібна допомога з вашим проєктом?
Залиште ім’я та номер телефону. Зв’яжуся з вами, щоб обговорити завдання, обсяг робіт і наступний крок.
