Patching PHP This Week? Google Says Use a 503 While Your Site Is Down

A lot of site owners had an unplanned job on their hands this week.

On October 21, PHP pushed out emergency security releases for two critical flaws. The same day, Google Search Central posted a short reminder on LinkedIn for anyone taking a site offline to patch.

The message was simple. If your site has to go down, return a 503.

John Mueller said the same thing on Bluesky. So I went back to Google's own docs to check two things: how long a 503 is actually safe, and what else can go wrong during a maintenance window.

What happened on October 21

PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21. According to the PHP security advisory, they fix two vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that can allow unauthenticated remote code execution. PHP rated both 9.2 on CVSS v4.0.

The advisory says updating is the only safe fix. PHP 8.1 and older no longer get official releases, although PHP says minimal backports exist in the php-src repository and some distributions ship their own fixes.

For many sites, that means some downtime: upgrading PHP, restarting workers, or moving off an old version in a hurry.

That's where SEO comes in. How your server responds while it's down decides what Googlebot sees.

What Google said

Here's the core of the Google Search Central post:

"Serving a 503 (Service Unavailable) HTTP status code ensures already indexed URLs are preserved in Search while you work. Once you start serving 200 responses again, things naturally return to normal."

The post also asked people to avoid generic 404s or a 200 error page during downtime.

John Mueller posted the same day:

"If you're taking PHP sites down to schedule time to deal with "unplanned updates", use HTTP 503 instead of letting responses time out / 404 / 500. You can do this outside of PHP / point DNS elsewhere / CDN."

I like that last line. If PHP is the thing you're patching, PHP can't be the thing that sends the 503. Your web server, load balancer or CDN can.

In the replies, a Bluesky user ranked the options from best to worst as 503 > 500 > 403 > 404 > 200. Mueller replied: "Yes, that's a good model, thanks!"

What Googlebot does with each response

This is how Google's crawling docs describe each case. I put it in one table because the differences are easy to forget when you're rushing.

Sources: HTTP status codes, network and DNS errors, and reducing crawl rate.

How long can a 503 stay up?

A 503 buys you a short window. It doesn't protect your pages forever.

Google's crawl rate page says it doesn't recommend serving these codes "for a long period of time (meaning, longer than 1-2 days)". If Googlebot keeps seeing them on the same URL for multiple days, the URL may be dropped from the index.

The status codes page says the same in fewer words: indexed URLs are "preserved in the index, but eventually dropped."

And one thing I hadn't thought about: Google's guide to pausing a site notes that while a page returns 503, Google can't refresh its title, description or structured data.

Most PHP upgrades take minutes or a few hours, so you should be well inside that window. Just don't leave the maintenance rule on by mistake.

Don't 503 your robots.txt

This one is easy to miss if you add a catch-all maintenance rule. Google's pause guide says:

"Don't return a 503 HTTP response status code for the robots.txt file because this blocks all crawling."

Google's robots.txt documentation explains why. If Google can't fetch robots.txt because of a server error, it stops crawling the site for the first 12 hours and keeps retrying.

So if your rule sends every URL to a 503 page, add an exception for /robots.txt.

My checklist for the patch window

1. Send the 503 from something that stays up while PHP is down: your web server, load balancer or CDN.
2. Add a Retry-After header with a rough time you'll be back. Google's crawl docs accept a delay in seconds or a UTC date.
3. Keep /robots.txt returning its normal file with a 200.
4. Show visitors a short "back soon" message. Google ignores the content of a 5xx page, so this is just for people.
5. Check the response before you start. curl -I https://www.example.com/ should show HTTP/1.1 503 Service Unavailable.
6. When you're back, check that key pages return 200 again and keep an eye on Crawl stats in Search Console for a few days.

Important note

None of this guidance is new. Google covered it in a 2011 Search Central blog post on planned downtime, and Mueller wrote about 503s on his own site back in 2013. What's new is the timing, with a lot of sites patching at once.

I'm also not a security expert. The patch comes first. The 503 just makes sure Search isn't another thing to fix afterwards. For the patch itself, follow PHP's advisory and your host's instructions.

Google hasn't said exactly when a URL serving a 503 drops out. The 1-2 days is its general guidance, so I'd plan to be back well before that.

My takeaway

Patch first. But take two minutes to make sure your maintenance page returns a 503, not a 200 or a 404.

It's a small detail, and it's the kind of thing that gets missed in a rush.

Did your site go down for this PHP update? Did you check what status code it was returning?