Google advises 503 status for PHP sites taken offline to patch

Google's John Mueller has advised owners of PHP sites that go offline to patch two critical security flaws to return an HTTP 503 status code, which can be served from outside PHP, for example from a CDN or from a server that DNS points to, to limit the damage the outage does to their rankings and indexed pages.

The advice, posted on Bluesky on 21 October, follows the PHP project's release of PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Those versions fix two vulnerabilities that can allow unauthenticated remote code execution, and PHP is telling every user to update immediately. The pair of flaws has become widely referred to as PHP2Shell.

Many sites can patch without going offline. Some organisations have chosen to switch off until the update is done, and reports on Wednesday described government, school and hospital websites in Europe going offline as a precaution. For an Australian business on WordPress, WooCommerce or any other PHP platform the decision is the same one at a smaller scale: patch now, and if the site has to drop out for a while, drop out in a way Google understands.

mod_php carries the demonstrated exploit

PHP's advisory says the risk applies to every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod_php as the highest risk, with a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

The first flaw, CVE-2026-109618, allows remote code execution through PHP's out-of-memory handling. The second, CVE-2026-109619, lets request-owned internal state survive after its memory has been freed, so a later request on the same worker can use the stale data.

Linux distributions and long-term-support vendors received the patches in advance, so hosts running packaged PHP should check with their vendor for updated packages. PHP 8.1 and older no longer receive updates from the PHP project. Because of the severity, the security team has published minimal source backports for PHP 7.4, 8.0 and 8.1, aimed at people who build from source or have no vendor to lean on. A site still on PHP 7 was overdue for an upgrade before this week.

Let a CDN or DNS switch serve Mueller's 503, not PHP itself

Mueller's post was short. If a PHP site is being taken down to deal with what he called "unplanned updates", he wrote, "use HTTP 503 instead of letting responses time out / 404 / 500. You can do this outside of PHP / point DNS elsewhere / CDN."

The last part matters. A maintenance page generated by the PHP application is still a request handled by PHP, which is the thing being patched. Serving the 503 from a CDN rule, a reverse proxy or a holding server that DNS points to takes PHP out of the loop while the work happens.

Google's documentation on HTTP status codes explains why a server error is safer than a 404. Server errors prompt Googlebot to slow its crawling temporarily, and already indexed URLs are kept in the index for a time. Once the server returns 200 again, Google gradually brings the crawl rate back up.

Knowledge Panels can lose phone numbers

The alternatives behave very differently. Google treats a 4xx response as a statement that the content does not exist. Indexed URLs that start returning 404 are removed from the index, and crawling of them tails off. A broken maintenance setup that answers every request with "not found" is telling Google to forget the site.

Google's documentation also says server errors lower the crawl rate in proportion to the number of URLs failing, and URLs that persistently return a server error are removed from the index. A 503 is still a server error. What makes it the right choice is that it means temporarily unavailable, and Google's own guide to pausing a website names it as the code to use for a short closure. A request that hangs until it times out is exactly what Mueller said to avoid.

That pause guide is blunt about the stakes. Disabling a whole site is described as an extreme measure for a very short period, a few days at most. Beyond that the effects in Search are significant even when done properly: Knowledge Panels can lose details such as phone numbers and logos, Search Console verification can fail, and recovering a site that needs to be reindexed takes an uncertain amount of time.

Every page 503, except robots.txt

The same Google guide lists the practical details for a short shutdown, and they are easy to get wrong in a hurry.

• Return the 503 for pages, but keep robots.txt available with a normal response. A robots.txt that returns 503 blocks all crawling.
• Do not block the site with 403, 404 or 410 responses, a noindex meta tag or an X-Robots-Tag header. Any of those removes URLs from Google Search.
• Do not upload a robots.txt that disallows everything, and do not use the temporary removal tool in Search Console for a closure.
• Add a retry-after header with a best-effort time or duration, and keep the error page as static HTML with inline CSS so it is cheap to serve.
• Tell people on the page when the site is expected back and how to contact the business meanwhile.
• Check the result with a tool such as curl and confirm the status line shows 503 (for example HTTP/1.1 503 Service Unavailable, or HTTP/2 503).

If the fix is going to take longer than a day or two, Google's recommendation changes. At that point it suggests a placeholder home page that returns 200 and can be indexed, so people searching for the business still find something first-hand.

Search Console will record the server errors, but its reports can run days behind, as the recent Search Console data delays showed, so do not judge the outage by the next morning's numbers.

Shared-hosting owners rarely control these settings

PHP is clear that only the update is a complete fix. For sites that cannot patch immediately, its advisory lists settings that narrow specific attack paths without making an installation safe.

For the out-of-memory flaw, PHP suggests setting memory_limit to -1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and lowering post_max_size to 8M for applications without file uploads or 32M where uploads are needed, with upload_max_filesize kept below it. PHP pairs this with a container or cgroup memory limit, so one runaway request cannot take the whole server's memory, and warns against using RLIMIT_AS or RLIMIT_DATA instead. It also suggests enforcing request size and field count limits at the web server or proxy.

For the stale state flaw, PHP recommends setting session.upload_progress.enabled to 0 and restarting every worker, applied through php.ini, the FPM pool or server configuration rather than ini_set or a .user.ini file. On PHP 8.5, setting fatal_error_backtraces to 0 and restarting closes one more confirmed path. PHP adds that hiding diagnostics with error_reporting, display_errors or the @ operator does nothing to help.

These are developer settings, and on shared hosting most of them are out of the site owner's hands. That is why the useful move for an owner is to ask the host directly.

Confirm the host runs 8.5.12, 8.4.27, 8.3.36 or 8.2.35

Many Australian small business sites sit on managed or shared hosting, where the PHP version is the host's responsibility. The owner's job is to confirm it has been done and to control how any downtime looks to Google.

• Which PHP version is the site running now, and is it one of 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor package carrying the same fix?
• Does the update need the site to go offline at all? PHP's advisory treats the update itself as the fix, and many hosts can apply it in place.
• If it does go offline, where will the 503 be served from: the CDN, a proxy, or a separate holding server?
• Will robots.txt keep returning normally during the window?
• How long is the window, and what is the plan if it runs past two days?

Patching is also not the moment to rebuild or rename anything. Google put on record this month that keywords in URLs are a tiny ranking signal, which is one more reason to leave working URLs alone, get the server onto a patched version and bring the site back on a 200 as quickly as possible.

The next step takes two minutes: ask the host for the site's PHP version in writing today. If the answer is anything older than the four patched releases or a vendor backport, book the update now and agree on the 503 plan before anyone switches the site off.