Google told site owners on Wednesday to answer crawlers with an HTTP 503 while they take PHP servers offline for the emergency PHP2Shell patches. A maintenance window handled badly can add a ranking problem to a security problem. Handled well, it leaves the index untouched.
Google Search Central posted the guidance on LinkedIn, and John Mueller repeated it on Bluesky, Search Engine Journal reported. The timing follows the PHP project’s release of patches for a pair of severe vulnerabilities that allow remote code execution without a login. Search Engine Roundtable listed the patched builds as PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and cited a Reuters report that government, school, and hospital sites in Europe went dark as a precaution.
A 503 signals to Google that the outage will pass. According to Google’s post, pages already in the index are kept while the work happens, and normal service returns once the server answers with 200 again. The post also warned against bare 404s and against error pages served with a 200 status, since the second pattern can get the error text itself indexed.
The practical catch is the source of the response. If PHP is what you are stopping, a PHP script cannot send the 503. Mueller named three workarounds: generate it outside PHP, point DNS at another host, or set a rule at the CDN. He listed timeouts, 404s, and 500s as the outcomes to avoid. In a Bluesky reply, a user ordered the status codes 503, 500, 403, 404, and 200, with the first as the safest. Mueller called it “a good model.”
Duration is the limit. Google’s crawl rate documentation says a 503 should not run past a day or two, and a URL that keeps returning one over several days may fall out of the index. Crawl rate also drops across the whole hostname when many URLs return errors, so pages that still work get fetched less often until the errors clear. A Retry-After header can tell crawlers when to come back, as seconds or as a UTC date and time.
Two details trip up emergency work. Google’s documentation on pausing a site says never to serve a 503 for robots.txt, since that shuts off all crawling. It also says Google cannot update titles, descriptions, metadata, or structured data for any page answering with a 503, so content edits shipped during the window will wait.
None of this is new advice. Search Engine Roundtable noted Google gave similar guidance during the 2021 Log4j scare. What changes the stakes now is speed: teams patching under pressure improvise, and a server-level fix applied by an operations engineer rarely passes through anyone who knows how Googlebot reads status codes. That gap, not the 503 itself, is where rankings get lost.
The harder case is the site that cannot patch quickly. PHP has issued only partial source-level fixes for the 7.4 through 8.1 branches, according to Search Engine Journal, and hosts may supply their own. For a closure that outlasts two days, Google suggests serving an indexable placeholder home page with a 200 status. Google has not published any measurement of how long recovery takes after an extended outage.
Before your next maintenance window, confirm that a CDN or DNS-level 503 is configured and tested, that robots.txt keeps answering normally, and that someone owns the decision to switch to a placeholder page if the work passes the two-day mark.
Reported by Search Engine Journal on October 21, 2026, with additional coverage from Search Engine Roundtable.
