Google Reminds Site Owners to Serve 503 Status Codes During PHP Patch Downtime

Website administrators scrambled this week after PHP released emergency fixes for two critical security flaws — and Google moved quickly to remind site owners how to handle the downtime without losing their search rankings.

Google Search Central posted a LinkedIn reminder on October 21, 2026, urging anyone taking servers offline for PHP patches to return a 503 Service Unavailable HTTP status code. The timing aligned directly with PHP's release of emergency fixes for two critical vulnerabilities that allow attackers to execute code on a server without logging in. The stakes are high for site owners: handle the downtime incorrectly and Google may quietly drop your URLs from its search index entirely.

These vulnerabilities are a sharp reminder of why maintaining strong website security practices is an ongoing operational priority, not a one-time configuration task.

---

What Google and John Mueller Said

Google Search Central was direct in its guidance: "Serving a 503 (Service Unavailable) HTTP status code ensures already indexed URLs are preserved in Search while you work. Once you start serving 200 responses again, things naturally return to normal."

The post also warned site owners against two common mistakes during downtime — returning generic 404 Not Found errors or serving a 200 OK status code on an error page. The 200 mistake is particularly damaging. In a 2013 post, Google's John Mueller wrote that returning an error page with a 200 OK status code causes Google to index that error content rather than preserving the original page.

Mueller echoed the reminder on Bluesky the same Wednesday morning and clarified a critical technical detail about where the 503 must originate: "If you're taking PHP sites down to schedule time to deal with 'unplanned updates', use HTTP 503 instead of letting responses time out / 404 / 500. You can do this outside of PHP / point DNS elsewhere / CDN."

That distinction matters enormously. Since PHP itself is the system being patched and taken offline, the 503 response has to come from a layer that remains operational — such as a CDN rule or a temporary server pointed to via a DNS change. A Bluesky user ranked HTTP responses from best to worst during downtime as 503, 500, 403, 404, and 200. Mueller called it "a good model."

Understanding the HTTP Response Hierarchy During Downtime

To put that ranking in practical terms, here is what each response signals to Google and why the order matters:

• 503 — Tells Google the server is temporarily unavailable; indexed URLs are preserved
• 500 — Signals a server error; less explicit about temporary intent but still preferable to a 404
• 403 — Indicates access is forbidden; Google interprets this as a deliberate block
• 404 — Tells Google the page no longer exists; risks permanent removal from the index
• 200 on an error page — The most damaging outcome; Google indexes the error content itself

Getting this hierarchy right is not a technical nicety — it is the difference between a clean recovery and a significant loss of search visibility.

---

How 503 Codes Affect Google's Crawling Behaviour

When Google's crawlers encounter large numbers of 503, 500, or 429 responses across a hostname, they automatically reduce the crawl rate for the entire domain — including URLs that are still returning content. Once the volume of errors drops, Google restores the crawl rate automatically.

Site owners can add a Retry-After HTTP header alongside the 503 response to tell Googlebot exactly when to return — either as a number of seconds or as a specific UTC date and time. This gives crawlers a precise window and reduces unnecessary crawl attempts during the outage.

The consequences of slower crawling extend beyond search rankings. Google's crawl rate documentation notes that reduced crawling means Googlebot discovers fewer new pages and refreshes existing ones less frequently. Google Ads campaigns tied to affected pages may also be canceled or paused during extended downtime.

Google's Gary Illyes offered some reassurance in 2024, saying a 503 lasting 10 to 15 minutes occasionally "is not 'extended' by any means, so you should be fine." The concern begins when downtime stretches across multiple days.

How Long Is Too Long to Serve a 503

Google's crawl rate documentation draws a firm line on duration: "We don't recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products. For example, in the case of Search, if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google's index."

Google's guide to pausing a website describes disabling an entire site as an extreme measure reserved for short periods — a few days at most. There is one additional rule site owners must not overlook: the robots.txt file must continue responding normally throughout any downtime. Returning a 503 for robots.txt blocks all crawling entirely. Google's systems also cannot refresh titles, descriptions, metadata, or structured data on any page returning a 503.

For outages expected to run longer than one to two days, Google's pause guide recommends serving an indexable placeholder home page with a 200 status code instead of a 503.

The Longer-Term PHP Version Risk

Sites running PHP 8.1 or older face a concern that extends beyond this patch cycle. Those versions no longer receive regular official updates. PHP has published limited source fixes for versions 7.4 through 8.1 for teams that build PHP themselves, and some hosting providers may supply their own patches — but this is not a sustainable long-term position.

For teams managing the operational impact of unplanned downtime, this patch cycle is a timely prompt to audit which PHP versions are running across your infrastructure and build a clear upgrade timeline before the next emergency forces the issue.

Once a site returns 200 responses after any downtime, Google's status codes documentation confirms that crawling picks back up gradually without requiring manual intervention.

---

Preparing Before the Next Maintenance Window

The real lesson from this incident is not technical — it is operational. Most of the SEO damage caused during emergency patches happens because site owners are configuring their response under pressure, without a tested plan already in place.

Configure your CDN or DNS failover now to serve a 503 with a Retry-After header during any future PHP or server-level maintenance. This approach protects indexed URLs without relying on PHP itself to be running — exactly the architecture Mueller described. Test it before you need it.

For teams who want to go further, understanding the full range of Google tools available to site owners — including Search Console's crawl stats and URL inspection tools — makes it significantly easier to monitor recovery after any period of downtime and confirm that Googlebot is re-indexing pages as expected.

Bookmark Google's HTTP status codes documentation and crawl rate page before your next planned maintenance window. Having the correct configuration ready in advance, rather than improvised under pressure, is the single most effective step a site owner can take to protect search visibility during any server-level emergency.