Якщо сайт доводиться тимчасово зупинити для оновлення PHP, сервер має повертати HTTP 503 Service Unavailable. Google Search Central нагадала про це на тлі термінових виправлень безпеки PHP: правильний код відповіді повідомляє пошуковому роботу, що сторінки недоступні тимчасово.
У повідомленні Google Search Central йдеться про збереження вже проіндексованих URL під час короткої перерви. Проте 503 не дає безстрокової гарантії збереження сторінок у пошуку: тривалі серверні помилки можуть призвести до їхнього вилучення з індексу.
Приводом стали дві критичні вразливості PHP — CVE-2026-109618 і CVE-2026-109619. Виправлення вийшли 21 жовтня у версіях PHP 8.2.35, 8.3.36, 8.4.27 та 8.5.12. В офіційних оголошеннях PHP розробники закликають оновитися негайно через ризик віддаленого виконання коду без автентифікації.
Саме оновлення PHP не обов’язково потребує повного вимкнення сайту. Рекомендація Google стосується випадків, коли сторінки на час робіт справді стають недоступними.
HTTP 503 дозволяє відрізнити тимчасову перерву від видалення документа. Якщо замість нього повертати 404 Not Found, пошукова система отримує сигнал, що сторінки немає. Для вже проіндексованих адрес це може закінчитися вилученням із пошуку.
Сторінка «Технічні роботи» з відповіддю 200 OK теж створює проблему: сервер повідомляє про успішне завантаження, хоча очікуваного вмісту немає. Google може обробити отриманий текст як контент або розпізнати таку сторінку як soft 404. Тому одного повідомлення для відвідувача недостатньо — важливий фактичний HTTP-код.
Для коротких робіт Google рекомендує 503, але не радить тримати серверні помилки довше одного-двох днів. Якщо Googlebot отримує їх за тими самими адресами кілька днів поспіль, сторінки можуть випасти з індексу.
Один-два дні — рекомендація, а не точний таймер. Немає правила, за яким на 49-й годині сайт обов’язково зникне з Google. Водночас планувати довге відключення, розраховуючи лише на код 503, не варто.
Джон Мюллер окремо нагадав, що відповідь можна організувати поза PHP — наприклад, через вебсервер або CDN. Це важливо, якщо оновлюють чи зупиняють сам інтерпретатор: PHP-скрипт обслуговування тоді не зможе надійно відповісти на запит.
Практичний варіант — легка статична HTML-сторінка, яку інфраструктура віддає зі статусом 503. На ній можна пояснити причину перерви й указати орієнтовний час відновлення.
До відповіді також можна додати заголовок Retry-After. Наприклад, Retry-After: 120 означає рекомендовану затримку перед повторним запитом у 120 секунд. Інший допустимий варіант — конкретна дата й час. Це орієнтир для клієнта, а не гарантія повернення Googlebot у зазначену секунду.
Окремо потрібно залишити доступним robots.txt. За правилами обробки robots.txt, у перші 12 годин серверних помилок під час його завантаження Google зупиняє обхід сайту й повторює запити до файлу. Надалі поведінка залежить, зокрема, від наявності збереженої справної копії.
Тому загальне правило обслуговування не має випадково повертати 503 і для robots.txt. Також не потрібно закривати весь сайт від сканування через Disallow: робот повинен мати можливість побачити тимчасові відповіді сторінок і подальше відновлення роботи.
Велика кількість відповідей 500, 503 або 429 знижує частоту запитів до всього хоста, включно зі справними сторінками. Через це Google може повільніше знаходити нові публікації та оновлювати вже відомі. Після зменшення кількості помилок інтенсивність обходу поступово відновлюється.
Для довшої зупинки Google радить принаймні залишити доступну для індексації головну сторінку з кодом 200 та поясненням ситуації. Це не означає, що всі старі URL потрібно замінити однаковою заглушкою, і не гарантує збереження їхньої видимості.
Перед початком робіт я б перевірив три речі: який код фактично отримує клієнт, чи доступний robots.txt і чи працює сторінка обслуговування незалежно від PHP. Після завершення — чи повернулися звичайні сторінки з відповіддю 200 і справжнім вмістом. Саме це дозволяє коректно повідомити Google про коротку перерву, не перетворюючи її на тривалу проблему з індексацією.