If you take a site offline this week to install the PHP security patch, serve a 503 status code from something that keeps running. Google keeps the URLs in the index while the 503 lasts. Serve a friendly maintenance page as a 200 and the message on it can end up as the indexed snippet.
PHP released emergency fixes for two critical flaws on 21 October 2026. Google Search Central posted the reminder about 503s the same day. Those two facts landed together for a reason, and the second one is the part most site owners will get wrong.
What a 503 status code tells Google
A 503 means the server is temporarily unavailable, so Googlebot backs off and keeps the URL in the index without recrawling it constantly. A 200 means the page loaded fine, so whatever text is on that maintenance screen becomes the page content. Same visible outcome for a visitor, opposite outcome for search.
The five responses, ranked by what they do to your site
Google’s status code documentation describes what each one triggers. This is the short version for a site owner who has one afternoon to patch and no appetite for a crawl audit.
| What the server returns | What Google does | What you should expect afterwards |
|---|---|---|
| 503 with a Retry-After header | Keeps indexed URLs, cuts crawl rate across the whole host, treats the outage as planned | Crawl picks up again over days once 200s return |
| 500 | Reads it as a server error and slows down | Same recovery, but no signal that a human planned this |
| 403 | Can read as a block on the crawler | Risk of URLs dropping, and no clean way to tell Google otherwise |
| 404 | Reads the page as gone | Drops out of the index if it persists |
| 200 with a maintenance message | Indexes the message as page content | Your title and description can be replaced by “we’ll be back soon” |
John Mueller put it in a sentence on Bluesky on 21 October: use 503 instead of letting responses time out, 404 or 500. You can serve it outside PHP, by pointing DNS elsewhere or through a CDN.
The 503 has to survive PHP going down
This is the practical trap. Most WordPress maintenance plugins are PHP, so they stop working at exactly the moment you need them, because PHP is what you are patching. The status code has to come from the layer above. That means a CDN rule, a host control panel toggle, or a web server rule in Apache or LiteSpeed that returns 503 before PHP is invoked.
On shared hosting, that usually means a support ticket rather than a settings page. Ask the host for a maintenance mode that returns 503 and does not depend on the application. Ask them to leave robots.txt responding normally, because Google’s own guide to pausing a site warns that a 503 on robots.txt blocks crawling entirely.
Two days is the limit
Google’s crawl rate documentation says not to serve a 503 for longer than one to two days, because a URL that keeps returning it can be dropped from the index. That window is comfortable for a patch and tight for a rebuild. If the work runs past two days, the better option is a real home page served with a 200, which gives Google something indexable to hold.
Google’s systems also cannot refresh titles, descriptions or structured data on a page that returns 503. Anything you fix during the outage only takes effect after normal responses resume.
What the PHP flaw actually is
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP says updating is the only complete fix. Apache servers running mod_php carry the highest risk, because a demonstrated attack can execute before the site’s own code starts. That detail matters for WordPress, where the fix is almost never something you can apply from the dashboard. SEJ’s report on the patch has the full list.
Governments treated it as urgent. The Dutch parliament and the national cyber security centre took their sites offline as a precaution. Finnish government web services went down before the release, and CERT-EU published advisory 2026-018 ahead of it. Those are not small sites with careless admins. They are sites that decided an outage was cheaper than the alternative.
What to do this week, in order
- Open Tools, Site Health, Info, then Server, and read the PHP version. Two minutes, no ticket needed.
- Compare it against 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If yours is not on the list, you are unpatched.
- Write the host a one-line ticket: request an update to the nearest fixed version, and ask which version they will install.
- If they cannot patch today, ask for a 503 maintenance mode that runs without PHP, and switch it on before you start.
- After patching, check for web shells, unfamiliar admin accounts and PHP files with recent modification dates.
Step five is the one people skip. A patch closes the door. It does not remove anyone who came through it, and a compromised site can serve redirects for months while the dashboard looks normal. If your traffic or rankings moved strangely in the last fortnight, that is worth checking before you assume an algorithm update did it.
The part I would not skip
A 503 is a promise that you will be back. Keep it short, keep robots.txt alive, and give the crawler a Retry-After header so it knows when to look. Then put the site back on 200 and leave it alone for a week. The recovery is gradual, and watching it hourly will only make it feel slower than it is.
This is the same crawl-access question that came up in the Cloudflare pilot post, with a harder deadline attached.
