Google Search Central is advising website operators who take their servers down to apply PHP security patches to respond with a 503 HTTP status code, signalling to the search engine that the interruption is only temporary. The guidance was shared in a LinkedIn post on Wednesday, the same day the PHP project released emergency fixes for two critical vulnerabilities that could allow an attacker to execute code without authenticating, according to Search Engine Journal.
The post did not specify a maximum duration for a 503 response. Google's crawl rate documentation, however, cautions against serving one for longer than one to two days, because URLs that keep returning it over several days risk being removed from the index.
Why it matters
For publishers and site owners, the distinction between a temporary outage and a permanent one is what decides whether existing search visibility survives a maintenance window. A 503 tells Google's crawlers that the site is temporarily unavailable and that indexed URLs should be retained, while other responses can send a different message. Search Engine Journal reports that the guidance also warns against using generic 404 pages or error pages that return a 200 status during downtime.
The timing is significant. The PHP fixes address two critical flaws that allow remote code execution without a login, which means many operators may need to take systems offline at short notice to apply them. How those outages are signalled to search engines can affect rankings and traffic after the patching is complete.
What Google says a 503 achieves
According to the LinkedIn post quoted by Search Engine Journal, returning a 503 Service Unavailable code keeps URLs that are already indexed in Search while the work is carried out, and normal behaviour resumes once the site starts returning 200 responses again.
The post directed readers to Google's documentation on how HTTP status codes affect its crawlers. Search Engine Journal notes that a 2013 post by Google's John Mueller explained that serving an error page with a 200 OK status causes Google to index the error content itself.
Mueller also posted a reminder on Bluesky on Wednesday, outlining where the 503 can be generated. He advised operators taking PHP sites down to free up time for unplanned updates to use HTTP 503 rather than letting requests time out or return 404 or 500 errors, and noted the response can be issued outside PHP, by pointing DNS elsewhere or through a CDN. The 2011 Google post he linked to demonstrates sending a 503 with PHP code, which Search Engine Journal points out is of little use when PHP itself is the component being taken offline.
In a reply on Bluesky, a user ranked the possible responses from best to worst as 503, 500, 403, 404 and 200, a ranking Mueller described as a good model, according to Search Engine Journal.
Crawl rates, retry headers and the limits of a 503
Google's crawl rate documentation lists 500, 503 and 429 responses as the means of urgently cutting crawler traffic for a short period. When Googlebot encounters a large number of URLs returning those codes, it slows crawling across the entire hostname, including pages that are still serving content normally. The rate is raised again automatically once the volume of errors falls.
Sites returning a 503 or 429 can include a Retry-After HTTP header telling Google's crawlers when to come back, expressed either as a number of seconds or as a UTC date and time. The same documentation warns that reduced crawling means Googlebot finds fewer new pages and refreshes existing ones less frequently, and that Google Ads campaigns may be cancelled or paused.
Search Engine Journal also cites comments from Google's Gary Illyes in 2024, who said a 503 lasting 10 to 15 minutes occasionally is not extended by any measure and should be fine. Google's documentation states that serving these codes for longer than one to two days may harm how a site appears in Google products, and that if Googlebot sees the same status on a URL for multiple days, that URL may be dropped from the index.
Google's status codes page, linked from the LinkedIn post, says indexed URLs that return server errors are preserved in the index but eventually dropped. The company's guide to pausing a website describes disabling an entire site as an extreme step that should last only a very short time, a few days at most.
That guide adds two further cautions: a 503 should not be returned for the robots.txt file, since doing so blocks all crawling, and Google's systems cannot refresh titles, descriptions, metadata or structured data on a page that returns a 503.
Practical constraints for site owners
Because the 503 has to originate from something that stays online while PHP is down, Search Engine Journal reports that operators need a CDN rule or a temporary server with DNS pointed at it. The robots.txt file should continue responding normally so crawling remains possible.
Sites running PHP 8.1 or older no longer receive regular official updates. According to Search Engine Journal, PHP has published limited source fixes for versions 7.4 through 8.1 for teams that compile PHP themselves, and hosting providers or support vendors may supply their own patches, as Vahan Petrosyan reported for SEJ.
For an outage expected to run beyond a day or two, Google's pause guide suggests leaving an indexable home page served with a 200 as a placeholder. Once a site returns 200 responses again, Google's status codes documentation says crawling resumes gradually.
Site operators applying the emergency PHP fixes should watch how long any 503 stays in place, since the one-to-two-day guidance is the point at which indexed pages begin to be at risk.
