---
title: "Taking your site offline to patch PHP: what Google advises"
description: "Patching a critical PHP vulnerability and need to take your site down for a while? John Mueller says to use HTTP 503. Here is how to do it without losing visibility in Google."
date: 2026-10-21
category: SEO
tags: ["Google", "HTTP 503", "PHP", "security", "crawling"]
url: https://uper.pl/en/blog/google-503-take-site-offline-php-patch/
---

# Taking your site offline to patch PHP — why Google wants a 503, not a 404 or a timeout

If you take your site down for an emergency PHP update, **return HTTP 503, not a timeout, a 404 or a 500**. That is the advice John Mueller of Google gave on October 21, 2026, in reaction to the wave of patching for two critical PHP vulnerabilities that Search Engine Roundtable covered under the name "PHP2Shell". The SEO takeaway: a short, clearly signalled outage does not have to cost you visibility, but a badly handled one can.

## What happened and why it matters for SEO

On October 20 and 21, 2026, the PHP project released security fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They address two vulnerabilities, both rated 9.2 on CVSS v4.0, which according to the PHP advisory allow unauthenticated remote code execution:

- **CVE-2026-109618** – an out-of-memory (OOM) handling bug where post-request cleanup can treat partially initialised data as valid,
- **CVE-2026-109619** – internal request state that survives a memory release and can be reused by the next request on the same worker process.

"PHP2Shell" is an industry nickname used by Search Engine Roundtable. The official PHP advisory only refers to the CVE numbers. According to the advisory, the full fix is to upgrade. Temporary settings (including `session.upload_progress.enabled=0` and request size limits) only narrow the attack paths.

Since the flaw lets an attacker take over a server without logging in, some administrators chose to take their sites offline while they upgraded. That is where the SEO problem starts: Googlebot has no idea it is looking at planned maintenance. All it sees is the server's response.

## What exactly Google said

John Mueller posted this on Bluesky on October 21:

> 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.

Two things stand out. The status code should be **503**, and it can be served **outside of PHP**, for example by pointing DNS somewhere else or using a CDN. Under the post, Mueller linked two Google resources: [the blog post on planned site downtime](https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime) and [the documentation on temporarily pausing a website](https://developers.google.com/search/docs/crawling-indexing/pause-online-business). Search Engine Roundtable notes that Google gave similar advice during the Log4j vulnerability in 2021.

## Why 503 and not 404, 500 or a timeout

Each of the wrong responses tells the crawler something other than what you mean:

| Response | How Google reads it | Risk |
|---|---|---|
| **503** | Temporarily unavailable, come back later | Lowest, this is the right signal |
| **404 / 410** | The page no longer exists | Pages dropping out of the index on the next visits |
| **500** | Server error of unclear nature | Uncertain state, a longer run of errors lowers trust in the host |
| **Timeout** | The server does not respond | Similar to 500, and you waste crawl budget on top |

Google's documentation on pausing a site lists 403, 404 and 410 among the responses that can remove a site from search results. That matches what you see in practice: you don't want a patching window to look to the crawler like a decision to delete your content.

## How to do it right

### 1. Serve the 503 outside of PHP

This is the core of Mueller's advice. If PHP itself is the problem, you can't count on it to generate a proper error page. Sensible options:

- a static page from the web server configuration (Nginx, Apache) returned with a 503,
- a CDN or firewall rule that answers 503 before the request reaches the origin,
- pointing DNS to a simple static host that returns 503 for everything.

With the last option, keep DNS propagation in mind, and remember that switching back is not instant either.

### 2. Check what the server actually returns

Google's documentation recommends verifying the status with a tool such as `curl -I`. Test every kind of URL: the home page, subpages and static files.

### 3. Add a Retry-After header

Google describes it as a "best effort" hint with an approximate date or duration. It does not guarantee any particular crawler behaviour, but it helps.

### 4. Don't block robots.txt

This mistake does more damage than the outage itself. According to Google's guidelines, robots.txt must stay reachable: if it returns a 503, all crawling is blocked. Don't swap it for a version with `Disallow: /` either. For a refresher on how the file works, see [robots.txt – how it works and how to configure it](/en/blog/robots-txt/).

### 5. Keep the error page lightweight

Google's guidelines suggest a simple 503 page: static HTML, inline styles, as few external resources as possible. For human visitors, say when the site will be back and how to get in touch.

## How long can you stay offline

It's worth being clear about what we don't know. Google's documentation treats taking a site fully offline as a last resort and talks about it in terms of "a few days at most". For one to two days it recommends an information page with a 503, and for longer outages an indexable home page returning 200 as a placeholder. **It does not give a threshold after which a 503 leads to removal from the index**, and it does not describe exactly how it handles Retry-After.

Among the side effects, the documentation lists possible loss of information in knowledge panels (such as a phone number or logo), failed verification in Search Console and a slow recovery of visibility after a longer outage that is hard to speed up. As long as pages return 503, Google also won't refresh titles, descriptions or structured data.

A PHP patch usually takes minutes or hours, not days, so most sites stay well within the safe zone. The risk appears when a "short break" drags on because of migration issues, plugin compatibility problems or recovery after an incident.

## Should you take the site down at all

There is no single answer, and it should depend on risk. With a flaw that allows unauthenticated remote code execution, waiting has a real cost: a compromised server means malware, spam in the index and browser warnings, which hurt visibility far more than an hour of 503s. The PHP advisory also makes it clear that mod_php setups are the most exposed.

In my audit work, the outage itself rarely does the damage. What hurts is how it's handled: a home page returning 200 with a "maintenance in progress" message, redirecting everything to a single URL, a robots.txt block, or a noindex added "just for a moment" and then forgotten. These are exactly the mistakes Google names as reasons for pages dropping out of search.

If you can upgrade PHP without taking the site down (a rolling update, switching traffic to an already-upgraded server), that beats any 503. Before any upgrade, make sure your backups actually work. See the guide to [WordPress backups](/en/blog/wordpress-backups/).

## Checklist for an emergency outage

1. Find out whether you can upgrade without downtime. If not, plan a window and keep it as short as possible.
2. Prepare a 503 response that doesn't depend on PHP (web server, CDN or a separate host).
3. Add a `Retry-After` header.
4. Make sure robots.txt returns 200 and doesn't block crawling.
5. Run `curl -I` against the home page and a few subpages.
6. Don't use noindex, 404 or 410 as a "temporary" fix.
7. After the upgrade, remove the 503, check the status codes and the indexing report in Search Console.
8. If you can, check that no old redirect rules were left behind after the site came back.

## Summary

Google has nothing against a short maintenance window as long as you signal it clearly: a 503, ideally served from outside PHP, with robots.txt still reachable and no extra signals that remove pages from the index. Nobody knows exactly how long Google tolerates a 503, so treat any outage as a matter of hours, not weeks. And don't delay the patch for SEO reasons: a compromised site costs far more than a temporary 503.

<FaqBlog
  questions={[
    {
      question: 'Which status code should I return when taking my site down for a PHP update?',
      answer: '<strong>HTTP 503</strong> (Service Unavailable). According to John Mueller, a 503 is better than letting requests time out or return 404 or 500 errors. Add a <strong>Retry-After</strong> header and check the response with curl.'
    },
    {
      question: 'Can I serve a 503 without PHP?',
      answer: 'Yes, and that is the recommended way. Mueller pointed out that a 503 can be returned outside of PHP, for example by pointing DNS elsewhere or using a CDN. Another option is a static error page in the Nginx or Apache configuration.'
    },
    {
      question: 'How long can a site return 503 without hurting rankings?',
      answer: 'Google does not give an exact threshold. Its documentation treats taking a site fully offline as something for "a few days at most", and for one to two days it recommends an information page with a 503. The longer the outage, the harder and less predictable the return to previous visibility.'
    },
    {
      question: 'Should I block crawlers in robots.txt during the outage?',
      answer: '<strong>No.</strong> robots.txt should stay reachable and must not return a 503, because that stops all crawling. Don\'t upload a version with Disallow: / either. Read more in the article <a href="/en/blog/robots-txt/">about robots.txt</a>.'
    },
    {
      question: 'Should I patch PHP right away, even if it means downtime?',
      answer: 'With vulnerabilities that allow unauthenticated remote code execution, the risk of a server takeover usually outweighs the cost of a short 503. Ideally upgrade without downtime; if that is not possible, plan the outage so it lasts hours, not days.'
    }
  ]}
  heading="Frequently Asked Questions"
  id="faq"
/>

## Sources

1. **Search Engine Roundtable: Google on taking sites offline while patching PHP2Shell**
[https://www.seroundtable.com/google-php2shell-42353.html](https://www.seroundtable.com/google-php2shell-42353.html)
2. **John Mueller, Bluesky post**
[https://bsky.app/profile/johnmu.com/post/3myfhjovzvk27](https://bsky.app/profile/johnmu.com/post/3myfhjovzvk27)
3. **PHP.net – 2026 news archive (advisory of October 21, 2026)**
[https://www.php.net/archive/2026.php#2026-10-21-5](https://www.php.net/archive/2026.php#2026-10-21-5)
4. **Google Search Central – Temporarily pause or disable a website**
[https://developers.google.com/search/docs/crawling-indexing/pause-online-business](https://developers.google.com/search/docs/crawling-indexing/pause-online-business)
5. **Google Search Central Blog – How to deal with planned site downtime (2011)**
[https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime](https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime)