Критичні вразливості PHP: Google радить віддавати код 503, якщо ви вимикаєте сайт на час оновлення

21 жовтня 2026 року команда PHP випустила термінові виправлення двох критичних вразливостей. Через них зловмисник може виконати код на сервері сайту без авторизації. Частина сайтів у світі на час оновлення тимчасово пішла офлайн. Google нагадав, що робити, якщо ви вирішили вимкнути сайт: щоб не нашкодити індексації, сайт має віддавати код HTTP 503.

Що сталося

За даними Search Engine Journal, вразливості виправлено у версіях PHP 8.5.12, 8.4.27, 8.3.36 і 8.2.35. У PHP наголошують, що обхідного шляху, який повністю закриває проблему, немає. Тому безпечний варіант лише один: оновитися. Search Engine Roundtable пише, що вразливі всі версії від 5.4 до 8.5.11. Найбільше ризикують сервери Apache з mod_php. Версії 8.1 і старші вже не отримують регулярних оновлень. Для 7.4, 8.0 і 8.1 опубліковано лише обмежені виправлення у вихідному коді, і постійної підтримки вони не повертають.

Як повідомляють видання, низка державних, освітніх і медичних сайтів у Європі, зокрема в Нідерландах і Фінляндії, завчасно відключилася. Того ж дня Google Search Central нагадав у LinkedIn: поки сайт вимкнений, він має віддавати код 503 (Service Unavailable). Тоді вже проіндексовані сторінки залишаються в пошуку. Джон Мюллер із Google уточнив у Bluesky, що 503 кращий за тайм-аути та коди 404 чи 500. Віддавати його можна без участі PHP: через CDN або перенаправивши DNS на інший сервер.

Що це означає для бізнесу

Якщо ваш сайт працює на WordPress чи іншій платформі на PHP, оновлення самого WordPress або плагінів версію PHP не змінює. Її оновлює хостинг. Якщо сайт зламають, можуть витекти дані клієнтів, а сайт може втратити видимість у пошуку.

Шкодить і неправильне вимкнення. Якщо під час простою сайт показує сторінку помилки з кодом 200, Google може проіндексувати текст цієї помилки. Але й 503 годиться лише на короткий час. У самому нагадуванні в LinkedIn строк не вказано, проте в документації Google про частоту сканування сказано, що не варто віддавати такий код довше 1–2 днів, бо інакше URL можуть випасти з індексу. Коли Googlebot бачить багато помилок, він рідше сканує весь домен. До того ж Google не може оновити заголовки, описи та структуровані дані сторінки, яка віддає 503. За даними Search Engine Journal, у тій самій документації згадано, що кампанії Google Ads у такому разі можуть призупинити або скасувати. Інші подібні ризики ми розібрали в статті про технічні помилки, що заважають індексації.

Що ми рекомендуємо зробити

• Перевірте версію PHP. У WordPress: Інструменти → Здоров'я сайту → Інформація → Сервер.
• Попросіть хостинг встановити одну з виправлених версій або підтвердити, що його оновлення містить обидва виправлення. Якщо перемикаєте версію в cPanel, переконайтеся, що обрана версія вже містить патч.
• Якщо у вас PHP 8.1 або старіша версія, зробіть резервну копію і заплануйте перехід на версію, яка ще підтримується.
• Якщо сайт доводиться вимкнути, сторінка техобслуговування має віддавати 503 через вебсервер або CDN, а не через PHP. Можна додати заголовок Retry-After, щоб підказати Google, коли повернутися.
• Стежте, щоб robots.txt не віддавав 503, бо це блокує сканування всього сайту.
• Якщо простій триває понад день-два, Google радить поставити на головну сторінку заглушку з кодом 200, яку пошуковик може проіндексувати.
• Вебфаєрвол (WAF), наприклад Cloudflare, може відсікти частину атак, але оновлення він не замінює. Переконайтеся, що весь трафік проходить через нього.
• Після оновлення перевірте сайт на вебшели, незнайомі облікові записи адміністраторів і неочікувані зміни у файлах PHP. Патч не прибирає злам, який уже стався.
• Заздалегідь домовтеся з хостинг-провайдером або адміністратором сервера, хто відповідає за термінові оновлення і за рішення тимчасово вимкнути сайт.

Ми в RBK Digital вважаємо, що до таких інцидентів краще готуватися заздалегідь: знати версію PHP, контакти хостингу і порядок дій на випадок простою. Якщо не впевнені, що з вашим сайтом усе гаразд, почніть із безкоштовної перевірки сайту.