Google's Search Central team today used its official LinkedIn page to remind site operators who are applying emergency PHP patches, or taking servers offline, to answer requests with a 503 (Service Unavailable) status code rather than a generic 404 or an error page served with a 200. The post, published at about 17:40 UTC on October 21, 2026, a few hours after fixes for two critical PHP vulnerabilities shipped, links to Google's documentation page "How HTTP status codes affect Google's crawlers," which carries a "Last updated" date of February 4, 2026. Nothing in either source indicates that the documentation itself changed today.

In Short

Google told website owners that when they take a site down to fix it, the server should send a specific "temporarily unavailable" signal called 503 rather than a "page not found" message. That matters because Google removes pages from search results when they say "not found," while a 503 tells Google to slow down and come back later. The catch, according to Google's own documentation, is that a 503 only protects pages for a while: if the errors persist, those pages are eventually dropped too.

What the post says

The post appeared on the Google Search Central showcase page on LinkedIn, the organization's own account rather than a personal profile. It is short. "Friendly reminder for everyone running emergency PHP patches or taking servers offline today: Don't forget the 503!" it opens.

The rest runs to four sentences and a link. "Serving a 503 (Service Unavailable) HTTP status code ensures already indexed URLs are preserved in Search while you work," according to Google Search Central. "Once you start serving 200 responses again, things naturally return to normal." The post then cautions against two common shortcuts during maintenance: "Avoid generic 404s or 200 error page during downtown." The word "downtown" appears in the original and reads as a typo for downtime. It closes with "Stay safe, patch smoothly, and happy maintaining!" and the hashtags #GoogleSearchCentral, #DevLife, #SEO, #Admin and #Maintenance.

The shortened link in the post resolves to the 5xx section of the documentation page, at developers.google.com/crawling/docs/troubleshooting/http-status-codes#5xx-server-errors. At the time the post was captured, it showed 20 reactions and five comments.

The timing is the news hook. Earlier today, PHP released fixed versions on four branches for two flaws that CERT-EU rated 9.2 on the CVSS scale, and both CERT-EU and the US National Security Agency told organisations to consider isolating or taking unpatched systems offline. PPC Land reported on those two PHP flaws at 17:07 UTC, roughly half an hour before the Search Central post went up. PHP runs a large share of WordPress publishers, storefronts and marketing systems, so a wave of planned and unplanned downtime across the web was a predictable side effect of the advisories.

The documentation behind the reminder

The page the post links to sits in Google's Crawling Infrastructure documentation, under a "Troubleshooting" heading alongside a separate page on network and DNS errors. It covers, by its own description, "the top 20 status codes that Google encounters on the web." It does not cover rarer codes. "More exotic status codes, such as 418 (I'm a teapot), aren't covered," according to Google. Experimental features of the supported protocols, HTTP and FTP, are also excluded unless stated otherwise.

The page sets out a principle that the LinkedIn post compresses. "Every HTTP status code has a different meaning, but often the outcome of the request is the same," according to the documentation. Multiple redirect codes, for example, lead to the same result for Google's crawlers. Search Console, the page says, "generates error messages for status codes in the 4xx-5xx range, and for failed redirections (3xx)."

The scope is wider than Google Search. The page describes how "Google's crawlers" handle each code and then, in most rows, adds what happens specifically "in the case of Google Search." That distinction matters for advertisers as well as publishers, because the same crawling infrastructure fetches content for products other than Search, and the page says several times that other products may behave differently.

2xx: received is not the same as indexed

For the success range, the documentation is explicit that a successful response is only the first step. "For Google Search, an HTTP 2xx (success) status code doesn't guarantee indexing," according to Google.

The page breaks the class into three behaviours:

  • 200 and 201: Google passes whatever it received to the next processing step, which is product specific. For Search, that next system is the indexing pipeline. "The indexing systems may index the content, but that's not guaranteed," according to the documentation.
  • 202 (accepted): Google waits for the content for a limited time, then passes on whatever it has. The timeout depends on the user agent. "Googlebot Smartphone may have a different timeout than Googlebot Image," the page says. No figure is given.
  • 204 (no content): Google receives nothing and therefore cannot process anything.

The 2xx class is also where the soft 404 sits. "If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error," according to the page. That is the mechanism behind the post's warning about a "200 error page": a maintenance message served with a success code tells Google the page exists and that this message is its content. The documentation does not say what happens to an indexed page once Google classifies it as a soft 404; it says only that Search Console reports the error. PPC Land covered a related December 2025 clarification, in which Google said rendering might be skipped for pages returning non-200 codes and described ways for client-side applications to avoid soft 404s.

3xx: 10 hops, strong and weak signals

Redirects carry the page's only hard limit. "By default, Google's crawlers follow up to 10 redirect hops," according to the documentation. Specific crawlers may differ. Googlebot "generally follows 10 redirect hops when crawling for general web content, but Google Inspection Tools doesn't follow redirects," the page says.

Content served from the redirecting URL itself is discarded. "Any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead," according to Google.

The page then sorts the codes into two groups by signal strength:

  • 301 (moved permanently) and 308: Google follows the redirect, and its systems "use the redirect as a strong signal that the redirect target should be processed." The page lists 308 as "Equivalent to 301."
  • 302 (found), 303 (see other) and 307: By default the crawlers follow the redirect, and Google's systems treat it "as a weak signal that the redirect target should be processed." The page adds that "Other products may handle the redirect differently." 307 is listed as "Equivalent to 302."

Google acknowledges that grouping codes this way flattens real differences. "While Google treats these status codes the same way, keep in mind that they're semantically different," according to the page, which notes that other clients, such as e-readers and other search engines, may benefit from the precise code.

304: a caching signal, not an indexing one

The 304 (not modified) code is filed under redirection but behaves differently. Google's crawlers "signal the next processing system that the content is the same as last time it was crawled," according to the documentation. For Search, "the indexing pipeline may recalculate signals for the URL, but otherwise the status code has no effect on indexing."

That is the full extent of what this page says about caching. The conditional request headers that produce a 304, such as ETag and Last-Modified, are covered elsewhere in Google's crawling documentation. When Google expanded that documentation in November 2025, it said its crawlers support both headers and prioritise ETag when both are present.

4xx: removed from the index, no effect on crawl rate

The client error range is where the LinkedIn post's warning about 404s comes from. "Google doesn't use the content from URLs that return 4xx status codes," according to the documentation. "In the case of Google Search, 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."

The page groups 400, 401, 403, 404, 410 and 411 together. "All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist," it says. For Search, the indexing pipeline removes a previously indexed URL, "Newly encountered 404 pages aren't processed," and "The crawling frequency gradually decreases."

Two details stand out. First, 410 (gone) receives no separate treatment on this page; it sits in the same row as 404. Second, the page says outright that these codes do nothing to slow Google down. "Don't use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate," according to Google.

Put together, a site that answers every request with a 404 during a maintenance window gets the worst of both outcomes: Google keeps crawling at its usual pace, and each indexed URL it reaches is treated as gone. PPC Land has reported Google's position that 404 errors do not affect the rankings of other pages on a site, which is a separate question from whether the URL returning the 404 stays in the index.

429 and 5xx: slow down, preserve, then drop

The 429 (too many requests) code is the exception within the 4xx range. "Google's crawlers treat the 429 status code as a signal that the server is overloaded, and it's considered a server error," according to the documentation.

The 5xx section is the one the Search Central post links to. "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling," the page says. "For Google Search, already indexed URLs are preserved in the index, but eventually dropped."

The page lists 500 (internal server error), 502 (bad gateway) and 503 (service unavailable) in a single row and gives them the same handling. "Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error," according to Google. "For Google Search, Google's indexing pipeline removes from the index URLs that persistently return a server error." As with redirects and client errors, "Any content Google receives from URLs that return a 5xx status code is ignored."

Recovery is gradual, not instant. "Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site," the page says.

robots.txt

The status code page does not describe how Google handles a robots.txt file that returns errors or redirects. In both the 3xx and 5xx sections it points readers to Google's robots.txt specification instead, with links to that page's "redirection" and "server-error" anchors.

Where the post and the page differ

The LinkedIn post and the documentation it links to agree on the core recommendation, but the post is more reassuring than the page in two places.

The post says a 503 "ensures already indexed URLs are preserved in Search while you work." The documentation says indexed URLs are "preserved in the index, but eventually dropped," and that URLs that "persistently return a server error" are removed. Neither source defines how long "eventually" or "persistently" is. The status code page contains no figure in hours or days.

Other Google documentation has been more specific. When PPC Land reported on Google's November 2025 crawling documentation update, Google's crawl rate guidance warned against serving error responses for more than one to two days, because URLs could be dropped from the index if errors persisted for several days. That guidance comes from a different page and is not repeated on the status code page or in today's post.

The post also says that "things naturally return to normal" once 200 responses resume. The documentation says Google "gradually increases the crawl rate," which describes a ramp rather than an immediate restoration, and it does not say how long the ramp takes.

No sign of a documentation change

The Google page is dated, unlike many PPC Land sources. Its footer reads "Last updated 2026-02-04 UTC." Today's LinkedIn post does not describe the page as new or revised, and neither the post nor the page lists what, if anything, changed on February 4. The page links to a changelog for the crawling documentation, but the captured page does not include its contents, so the specific edit made in early February cannot be identified from these sources.

The date falls in the same week as another crawling documentation change. PPC Land reported on February 6, 2026 that Google's Googlebot documentation, updated on February 3, now said Googlebot crawls the first 2MB of a supported file type, down from 15MB. Whether the February 4 timestamp on the status code page relates to that change is not stated in either source.

Why marketers have reason to care

The documentation describes behaviour that has been discussed piecemeal for years. Google deprecated the crawl rate limiter in Search Console on January 8, 2024, and at the time said the fastest way to slow crawling was through server responses. That leaves status codes as one of the few levers a site has over how hard Googlebot hits its servers, which in turn affects crawl budget on large sites.

Google engineers have described the mechanics in more detail elsewhere. In episode 105 of the Search Off the Record podcast, PPC Land reported in March 2026, a 503 was described as triggering an additional slowdown because it signals overload, while 403 and 404 responses were treated as routine client errors that do not cause throttling. The status code page is consistent with that, though it puts 500, 502 and 503 in one row with identical handling.

The distinctions have direct commercial weight. For publishers, the difference between a 503 and a 404 during a patch window decides whether indexed article pages stay in Search Console reports as temporary server errors or start disappearing from the index. For retailers, product pages served as "200 error page" maintenance screens risk being classified as soft 404s. Neither outcome is fatal on its own, but both take time to reverse, given that Google's crawl rate recovers gradually after an outage.

Crawl volatility has also hit sites for reasons that had nothing to do with their own servers. In August 2025, PPC Land documented a sharp fall in crawling across sites hosted on Vercel, WP Engine and Fastly, which Google's John Mueller later attributed to an issue on Google's side. And in July 2026, a classifieds operator told Google's Gary Illyes that more than 50% of Googlebot hits on his site went to 404 pages, a reminder that the "no effect on crawl rate" rule for 4xx codes cuts both ways: Google does not slow down on 404s, but it does not stop requesting them either.

The documentation also clarifies a point often confused in practice: robots.txt errors are handled separately. A site that takes its entire server offline will return errors for its robots.txt file as well, and the rules for that case live in a different document.

What today's post does not resolve is the question most operators in the middle of an emergency patch will have: how long a 503 can safely stay up. The status code page gives no number, and the post does not either.

Timeline

Summary

Who: Google Search Central, through its official LinkedIn page, addressing site operators applying emergency PHP patches or taking servers offline. The linked documentation is published by Google in its Crawling Infrastructure documentation.

What: The post tells operators to serve a 503 status code during downtime instead of 404s or error pages returned with a 200. The linked page explains how Google's crawlers handle 20 common status codes: 2xx content is considered but not guaranteed indexing, redirects are followed for up to 10 hops, 4xx URLs are removed from the index with no effect on crawl rate, and 429 and 5xx errors slow crawling, with indexed URLs preserved for a time but eventually dropped.

When: The post went up at about 17:40 UTC today, October 21, 2026, hours after PHP released fixes for two critical vulnerabilities. The documentation page was last updated on February 4, 2026; nothing in the sources shows a change today.

Where: On LinkedIn and on Google's developers.google.com Crawling Infrastructure documentation, applying to Google's crawlers worldwide, with Search-specific effects noted separately.

Why: Patch-driven downtime across PHP sites raises the risk that maintenance pages or 404 responses remove indexed URLs from Google Search. The documentation shows that a 503 limits that risk but does not remove it, and neither source says how long a server error can last before indexed pages are dropped.