Sites went down for the PHP fix — a 503 keeps them in Google, a 404 removes them
The emergency PHP patch took government and company sites off the internet this week, and a downtime request answered with a 404 is what removes pages from Google; this issue gives you the four-request check that proves your maintenance response keeps them.
The PHP project published fixes for two critical vulnerabilities on 21 October and asked every PHP installation serving web requests to update immediately. The patched builds are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. 1
Some owners patched in place. Others pulled their sites off the internet first: 32 UK government services went offline, and the BBC's Traitors site was down on the Thursday. 2
John Mueller posted one instruction that afternoon for anyone taking a site down to do the patch. Use HTTP 503, he wrote, instead of "letting responses time out / 404 / 500", and answer it "outside of PHP / point DNS elsewhere / CDN". 3
Google's status dashboard lists no new ranking incident this week. Its newest entry is still the September spam update, which finished on 8 October. 4 Search Engine Roundtable logged heavy volatility on 24 October with no confirmed update behind it. 5
A drop that started this week therefore has two candidates: the churn nobody has explained, or the hours your site spent answering requests. The response code tells you which.
The pitfall: the code your maintenance page sends
Google documents how its crawlers read each status code. 6
A 4xx response reports the page as gone. Google "doesn't index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index". 6 A 404 arrives by accident during a takedown: a host's parking page after a DNS change, a "not found" default while the app is stopped, a 403 from a firewall rule.
A 5xx response reports a server problem. Google's crawlers "temporarily slow down with crawling", and "already indexed URLs are preserved in the index, but eventually dropped". 6
Persistence is what ends it: the indexing pipeline "removes from the index URLs that persistently return a server error". 6 A 500, a 502 from an origin that refuses connections, and a request that times out all land in that group.
An error page served with a 200 lands differently again. Google reads it as content, and "if the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error". 6 A soft 404 is a page Google treats as missing while it answers normally. Google's downtime advice names that option and the 404 together as the two to avoid. 7
Two more rules matter in that same hour. The robots.txt file has to keep answering, because returning a 503 for it "blocks all crawling". 8 And the maintenance page must carry no
noindex tag: returning "403, 404, 410 ... or with a noindex robots meta tag or x-robots-tag HTTP header ... will remove the website's URLs from Google Search". 8The maintenance mode that ships with a PHP framework runs inside the application. Stopping the PHP workers to patch them also stops the page that was meant to explain the pause. What Google meets instead is the web server's own 500, or a connection that times out. 6
The one action: stand a static 503 in front of the site, then ask for four URLs
- Write the page as plain HTML with inline CSS and no external files. Google asks for static HTML and minimal off-page resources. 8
- Return it with
503and aRetry-Afterheader carrying a best-effort date or duration. 8 - Answer it for the whole host from outside PHP: a CDN rule at the edge (Cloudflare and Fastly both offer one), a separate static server, or DNS pointed at a placeholder. 3 Article pages, product pages and the homepage all need the same response.
- Leave robots.txt answering
200with your usual rules, and keep anynoindexdirective off the maintenance response. 8
Now ask for four URLs the way a crawler would, and read the status line. Google's own example uses
curl this way and expects HTTP/1.1 503 Service Unavailable back. 8curl -sI "https://example.com/" | head -n 5
curl -sI "https://example.com/blog/one-deep-page" | head -n 5
curl -sI "https://example.com/robots.txt" | head -n 5
curl -sI "https://example.com/sitemap.xml" | head -n 5| What the four requests show | What Google does with a page it already ranks | What to change |
|---|---|---|
Pages 503 with Retry-After, robots.txt 200 | Kept in the index, and Googlebot returns after the date in the header | Nothing |
404, 410 or 403 on any page | Removed from the index 6 | Route that path through the 503 rule as well |
500, 502, a timeout, or no output from curl | Kept for now and crawled less often; a persistent error ends in removal 6 | Find what still reaches PHP, then answer at the edge |
200 on the maintenance page | Read as content, and the error text can be filed as a soft 404 6 | Send the same page with 503 |
503 on robots.txt | Crawling stops for the whole site 8 | Exempt robots.txt and the sitemap from the rule |
Already patched and back online? Run the same four requests. A clean set of
200s means the site is healthy now. What still matters is which code Google met while it was down, and Page indexing keeps that record.Scope
Run this if your site serves PHP and stopped answering requests at some point since 21 October. The indie cases are the ordinary ones: a WordPress blog, a Laravel side project, a forum, a small shop on shared hosting.
Skip it if you patched in place and the site answered throughout. Your traffic question belongs to the volatility instead.
A shutdown that runs past a couple of days needs a different answer. Google asks for the 503 when the pause lasts one to two days, and for "an indexable home page as a placeholder" served with a
200 when it lasts longer. 8 The same page calls a whole-site shutdown "an extreme measure that should only be taken for a very short period of time (a few days at most)". 8If you have not patched yet, PHP's advisory lists interim settings that narrow specific attack paths and states plainly that "there are no complete mitigations, updating is the only safe choice". 1 Patch first, then decide how long you can afford to stay offline.
What to check afterwards, and how far the evidence goes
Once the site answers
200 again, URL Inspection shows what Google received. Inspect a page and open View crawled page for the HTTP request and response. 9Then open Page indexing and read the reasons table. Pages that answered
404 sit under Not found (404); pages that answered 5xx sit under Server error (5xx). 10 Fixing the response and clicking Validate fix starts a check that "typically takes up to about two weeks". 10Ask for the recrawl in the same sitting: Request indexing for a few key pages in URL Inspection, and a resubmitted sitemap for the rest. 8
The advice above is Google's, and the practitioners who replied under Mueller's post arrived at the same order. One reply ranked the codes "503 > 500 > 403 > 404 > 200", drawing the same line he did: a 500 survives a short outage, a 404 does not. Mueller answered, "Yes, that's a good model, thanks!" 3
Three limits are worth carrying into it. Google publishes no duration after which a 503 reads as permanent; its 2011 post says only that "lasting 503 HTTP result codes can eventually be seen as a sign that the server is now permanently unavailable and can result in us removing URLs from Google's index". 7 That post is fifteen years old, and Mueller linked it on 21 October. 3
Retry-After is a hint rather than a schedule. Googlebot "may use" it to decide when to recrawl a URL. 7And the promise Google makes for this whole method is narrow: no guarantee of crawling, indexing or ranking, but ways of handling downtime that "will generally not negatively affect your site's visibility in the search results". 7
References
- 1
- 2
- 3
- 4Google Search Status Dashboard
status.search.google.com
- 5Google Search Ranking Volatility Gets Heated October 24th
seroundtable.com
- 6How HTTP status codes affect Google's crawlers
developers.google.com
- 7How to deal with planned site downtime
developers.google.com
- 8Temporarily pause or disable a website
developers.google.com
- 9URL Inspection tool
support.google.com
- 10Page indexing report
support.google.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.