How to Serve a 503 During an Emergency PHP Patch Without Losing Rankings

If you must take your site offline to patch PHP, return an HTTP 503 status code, not a 404, 500 or timeout. Google's guidance is that a 503 keeps already indexed URLs in search while you work. Keep the outage to hours, restore 200 responses as soon as the patch is live, and check Search Console afterward.

The PHP2Shell patches landed on October 21, 2026, and many teams scrambled to pull servers offline. This guide explains how to take a SaaS marketing site down without losing rankings. It covers the exact response to send, how long it is safe, what happens to robots.txt, and how to verify recovery. It is written for marketers and engineers who share responsibility for a site's organic traffic. Cekpr covers the technical side of getting found, and downtime is one of the easiest ways to lose that.

What Is PHP2Shell and Why Are Sites Going Offline?

PHP2Shell is the name given to two critical PHP vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619. Each is rated 9.2 out of 10 for severity. According to Malwarebytes' explanation of the PHP2Shell outages, an attacker could run malicious code on a vulnerable server without logging in.

The PHP project shipped fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with emergency updates scheduled for October 21, 2026. PHP 8.1 and earlier no longer receive regular security updates. Cloudflare's chief technology officer reported early attacks and said firewall mitigations are only a temporary fix.

This matters to marketers because many SaaS marketing sites run on PHP-based systems such as WordPress, Drupal or Joomla. Updating WordPress or its plugins does not update PHP itself. The hosting provider or server administrator usually has to apply the fix, and that can mean a short outage.

Why Should You Serve a 503 Instead of a 404?

A 503 tells Google the outage is temporary, while a 404 tells Google the page is gone. Google's Search Central team reminded site owners on October 21, 2026 to return a 503 during emergency patches. Its post said a 503 ensures already indexed URLs are preserved in Search while you work.

John Mueller of Google gave the same advice on Bluesky. For sites taken down for unplanned updates, he said to use HTTP 503 instead of letting responses time out, 404 or 500. He added that you can set the 503 up outside PHP, by pointing DNS elsewhere or using a CDN. Search Engine Roundtable reported the advice.

The difference comes from how Google's documentation treats each code. Indexed URLs that return 4xx errors are removed from the index. Server errors in the 5xx range cause Google's crawlers to slow down, and URLs are preserved for a time. A 200 response that shows an error page can be treated as a soft 404, which is the worst of both worlds.

How Long Can a Site Return 503 Without Losing Rankings?

Keep it to hours. Google's page on HTTP status codes and network errors says URLs that persistently return a server error are eventually dropped from the index. The page does not give a number of days, so treat any long outage as risky.

Earlier Google guidance, cited by PPC Land, advised against serving errors for more than one to two days. That is not in the status code page itself, so do not treat it as a promise. The safe approach is to plan for the shortest window you can, and to have a rollback plan if the patch fails.

Recovery is gradual too. Google decreases crawl rate in proportion to the number of URLs returning server errors. It then increases the rate again once the server returns 2xx responses. Expect crawling to ramp back up over time, not snap back at once.

If you want a longer treatment of managing crawl speed on purpose, see our guide on how to reduce Google's crawl rate safely on a SaaS site. It explains how 5xx responses and the Retry-After header interact with crawling.

What Happens to robots.txt During an Outage?

If your whole site is down, robots.txt is down too, and Google handles that in stages. Google's robots.txt documentation says that for the first 12 hours, Google stops crawling the site but keeps trying to fetch the file. After that, it uses the last good cached copy for up to 30 days while it keeps retrying.

If there is no cached copy, Google assumes there are no crawl restrictions. After 30 days, a generally available site is treated as having no robots.txt file. A site with general availability problems stays paused, and Google keeps asking for the file. Timeouts, DNS failures and reset connections all count as server errors.

The practical point is simple. A short 503 on robots.txt is safe, because Google pauses and then resumes. A long outage risks rules being lost or crawling stopping. The full rules sit in Google's robots.txt specification, which is worth reading before you plan any outage.

How Do You Serve a 503 Step by Step?

You can serve a 503 at the server, the CDN or the DNS layer. Follow this order so you do not lose time in the middle of an emergency:

Here is a minimal example for nginx. The rule returns a 503 for every request and serves a static page from a folder outside the application:

error_page 503 /maintenance.html;
location / { return 503; }
location = /maintenance.html {
  internal;
  root /var/www/maintenance;
  add_header Retry-After 3600 always;
}

Retry-After is a standard HTTP header that tells clients when to try again. Google's status code page does not mention it, so treat it as a courtesy and do not rely on it. The status code is what matters.

The key test is a header check. Run a request that shows only the response headers and confirm the first line reads 503. A maintenance page that returns 200 is the mistake to avoid, since Google may index the "we'll be back soon" text as real content.

How Do You Check That Rankings Recover?

Check Search Console, your server logs and a handful of key pages within a day of the patch. In the Crawl Stats report, look for 5xx errors in the outage window and a steady return to 200 responses afterward. In the Page indexing report, check that important URLs have not moved into excluded states.

Use your server logs to see Googlebot's real behavior. Filter for its user agent and count requests by status code per hour. You should see 503s during the outage, then a climb in 200s. If you do not, something in your caching or CDN layer may be serving the wrong response. Google lists its crawlers in its overview of Google crawlers.

Watch your organic traffic for a week. A dip right after an outage is normal. A dip that lasts is a signal to dig in. Our checklist on how to diagnose a SaaS organic traffic drop walks through the likely causes in order.

What Else Should a SaaS Team Do Besides the 503?

Confirm the fix is installed, not just scheduled. Malwarebytes advises site owners to ask their hosting or IT provider to confirm the patches are in place, and to upgrade any unsupported PHP version. CERT-EU recommends identifying PHP-based applications and patching them as soon as possible, or isolating internet-facing apps if an immediate fix is not possible.

Inventory your own estate. A SaaS company often has a marketing site, a blog, a help center, a docs site and a few landing page builders. Some run on PHP and some do not. List each one, note who owns it and write down its PHP version.

Also check that your AI crawler rules still hold after a restart. If you changed robots.txt recently, our setup guide on robots.txt for AI crawlers on SaaS sites shows what a healthy file looks like. A patch window is a good moment to confirm it.

What Should You Do Before the Next Emergency?

Prepare the maintenance page and the 503 rule now, so you can switch them on in minutes. Store the steps in a runbook that both marketing and engineering can follow. Agree on who decides to take the site offline and who confirms it is back.

Cekpr's editors checked this advice against Google's documentation and the reports of Google's October 21 guidance. Details may change as Google updates its pages, so confirm the latest wording before you act. The core rule has been stable for years: if you must go dark, say so with a 503, and come back fast.