PHP2Shell patching: Google says serve a 503 if you take your site down
If you take a PHP site offline to patch the PHP2Shell flaws, Google says to return an HTTP 503 from outside PHP. Avoid 404s, 500s, timeouts and 200 error pages, and keep the outage under one to two days.
- Google's John Mueller and Search Central advise an HTTP 503 for sites taken offline to patch PHP2Shell.
- A 503 preserves indexed URLs short term, but multiple days of 503s can lead to URLs being dropped.
- Serve the 503 from a CDN or separate server, keep robots.txt responding, and patch quickly.
Ask your own AI: ChatGPT Perplexity Claude AI Mode
On this page
Google is telling site owners who take PHP servers offline to patch the critical PHP2Shell vulnerabilities to return an HTTP 503 status code. Timeouts, 404s, 500s and error pages served with a 200 are the wrong choices. The advice came on October 21, 2026, the same day PHP shipped emergency fixes.
What did Google say about PHP2Shell downtime?
Google’s John Mueller said on Bluesky that sites going down for these unplanned updates should serve a 503, and that the response can come from outside PHP: a CDN, or DNS pointed at another server, as reported by Search Engine Roundtable. Google Search Central repeated the advice on LinkedIn, saying a 503 “ensures already indexed URLs are preserved in Search while you work,” according to Search Engine Journal.
The patched PHP releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Search Engine Roundtable reports that PHP versions 5.4 through 8.5.11 are vulnerable to unauthenticated remote code execution.
Does a 503 protect rankings during PHP2Shell patching?
A 503 protects rankings only for a short outage. It tells Google the outage is temporary, so indexed URLs stay in place. Search Engine Journal points to Google’s crawl rate documentation, which advises against serving 503s for longer than one to two days. URLs that return them for multiple days may be dropped from the index.
There are side effects even during a short outage. Google cuts crawling across the whole hostname when many URLs return 503s, and it can’t refresh titles, descriptions or structured data on pages returning them. Crawling picks up again gradually once normal 200 responses return. If you run Google Ads, the crawl rate documentation notes that campaigns may be paused or canceled. Planning the outage window matters as much as choosing the status code.
The other responses are worse. A 404 says the page is gone. A 200 error page can get the error content indexed. Timeouts give Google nothing useful at all. Most sites can patch without downtime, so going offline should be a deliberate choice, not the default.
How to serve a 503 when PHP itself is offline
The 503 has to come from something that keeps running while PHP is down. A 503 snippet written in PHP won’t help when PHP is the thing you’ve switched off. Before you shut anything down, take these steps:
- Set the 503 outside PHP. Use a CDN rule, a web server config, or DNS pointed at a temporary server that returns 503 for every page.
- Add a Retry-After header. Give it a number of seconds or a UTC date and time so Googlebot knows when to come back.
- Keep robots.txt responding normally. Google’s pause guide warns that a 503 on robots.txt blocks all crawling.
- Keep the outage short. Aim for hours, not days. If the site must stay down longer than a day or two, Google’s guidance suggests an indexable placeholder home page served with a 200.
- Patch to a fixed release. That means 8.2.35, 8.3.36, 8.4.27 or 8.5.12. If you run PHP 8.1 or older, check with your host or support vendor, since those versions no longer get regular official updates.
- Monitor afterwards. Check Search Console’s crawl stats and page indexing reports for server errors or dropped URLs once the site is back.