Website Maintenance SEO: Use 503 and Retry-After Without Deindexing the Site

01

Preconditions

The first maintenance decision is whether the site truly needs to disappear.

Google recommends keeping the site online and limiting functionality when a temporary business or technical issue affects transactions. For example, disable checkout, display an accurate banner, update product availability, and preserve public pages. This minimizes search disruption and still lets users find product details, reviews, manuals, contact information, and business updates. ^[1]

Use a whole-site maintenance response only when the entire application cannot safely serve normal pages.

Classify the interruption:

Feature outage
Read-only mode
Partial section outage
Brief deployment window
One-to-two-day emergency closure
Longer closure
Permanent shutdown

These states require different responses.

A 503 Service Unavailable response means that the server is temporarily unable to handle the request because of overload or scheduled maintenance and is expected to recover after some delay. RFC 9110 permits a Retry-After header to indicate when the client should try again. ^[2]

Before maintenance, define:

• start time
• expected end time
• maximum allowed duration
• affected routes
• unaffected routes
• status code by route
• Retry-After value
• robots.txt behavior
• monitoring
• rollback trigger
• status communication
• customer support contact
• restoration checklist
• decision owner

Do not start with “show a maintenance page.” A maintenance page returned with 200, 404, or 503 has different machine meaning despite looking identical to a human.

02

Ordered process

1. Prefer degraded functionality over full shutdown.

Keep informational pages accessible when possible.

For commerce:

• disable purchases
• mark products unavailable accurately
• update structured data
• update Merchant Center feeds
• display delivery or reopening information
• preserve wishlists and product research where safe

For services:

• disable booking or submissions
• explain delays
• preserve service descriptions
• provide contact alternatives
• update operating hours

Google strongly recommends this approach over disabling the whole site. ^[1]

1. Scope maintenance narrowly.

If only checkout is unavailable, do not return 503 for editorial pages, help documentation, and the homepage.

If one section is under maintenance, return temporary errors only for that section and keep the rest of the site serving normally.

A global edge rule is easy to deploy and easy to overapply. Exclude:

• robots.txt
• status page
• monitoring endpoints
• necessary support resources
• unaffected public content
• static assets needed by the maintenance page

1. Use 503 for a short whole-site outage.

Google recommends 503 for an urgent complete shutdown lasting roughly one or two days. Longer full closures can have significant search effects even when implemented correctly. ^[1]

Return:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html; charset=utf-8

The Retry-After value can be a delay in seconds or an HTTP date under the HTTP specification. Use a realistic value. Do not promise sixty seconds when the maintenance window is six hours.

1. Keep robots.txt available.

Do not return 503 for robots.txt. Google warns that an unavailable robots.txt can block crawling behavior. Do not replace it with a global disallow rule either; that changes crawl permission and can contribute to URLs disappearing from search. ^[1]

Serve the ordinary valid robots.txt with 200, or an accurate 404 if the site intentionally has none.

Test it separately:

GET /robots.txt
Expected: normal robots response

1. Build a low-dependency maintenance page.

Use static HTML and minimal resources.

The maintenance response should not depend on:

• the failed database
• the unavailable application API
• a complex JavaScript bundle
• third-party font servers
• several CSS files
• the same CDN function being deployed
• authenticated sessions
• runtime rendering

Google recommends static HTML and minimizing off-page resources. ^[1]

Include:

• plain-language status
• affected service
• expected next update or restoration time
• support contact
• status-page link
• emergency instructions where appropriate
• current date and timezone

Avoid a decorative animation that consumes more infrastructure than the application it is apologizing for.

1. Do not use removal signals for temporary maintenance.

Google explicitly advises against returning:

• 403
• 404
• 410
• robots noindex
• X-Robots-Tag: noindex
• Search Console temporary removal requests

These mechanisms communicate blocking, absence, or removal rather than temporary service unavailability. ^[1]

Do not redirect every page to a single maintenance URL with a permanent redirect. That suggests the content moved. Even a temporary redirect can collapse useful route-level context and complicate monitoring. Returning the maintenance representation at each requested URL with 503 is usually clearer for a brief whole-site outage.

1. Preserve the requested URL.

When possible, let:

/example-product

return a 503 maintenance response at that same URL.

This lets the crawler retry the original resource later. It also preserves browser bookmarks and avoids building a temporary redirect graph that must be removed perfectly.

1. Test headers, not screenshots.

Use a command-line client or monitoring system to verify:

Status = 503
Retry-After present
Content-Type correct
robots.txt not 503
No noindex
No permanent redirect
No cache trapping
Maintenance page reachable without application dependencies

Check through:

• CDN
• origin
• IPv4
• IPv6
• www
• apex
• HTTP
• HTTPS
• regional edges
• authenticated and unauthenticated paths

A browser showing a maintenance message proves only that some route returned some HTML.

1. Control caching.

A CDN or browser can continue serving the maintenance response after the site recovers.

Set cache behavior so the 503 page is not stored for an excessive period. Purge relevant caches at restoration. Ensure the Retry-After value does not outlive the actual window.

At the same time, avoid sending every request to a fragile origin. A small controlled edge-served maintenance response can protect the application while preserving accurate status semantics.

1. Monitor crawler and user behavior.

Track:

• request volume
• status codes
• maintenance duration
• robots.txt requests
• Googlebot requests
• cache behavior
• regional variance
• error-page latency
• customer support volume
• restoration checks

Google cannot refresh titles, descriptions, metadata, or structured data while pages return 503. ^[1] A short outage is one thing; an indefinite 503 prevents normal page processing.

1. Escalate when the outage will be longer.

If the site will be unavailable beyond a very short period, reconsider the architecture.

Google recommends an indexable 200 temporary homepage notice for a longer closure rather than serving the entire site as 503 for weeks. ^[1]

A longer-term notice should explain the business status and preserve contact information. It does not preserve every removed product or article URL, so the organization should restore informational content wherever possible.

1. Restore in a controlled order.

At reopening:

1. restore origin and application health
2. test representative pages directly
3. disable the maintenance rule
4. purge maintenance caches
5. confirm 200, redirects, 404, and other ordinary statuses
6. confirm robots.txt
7. confirm canonicals and robots directives
8. confirm structured data and availability
9. test forms and transactions
10. monitor crawler and user errors
11. update the public status message
12. remove temporary operational bypasses

Do not remove the maintenance layer before the application is ready, then re-enable it repeatedly. Flapping status creates inconsistent caches and user experiences.

03

Failure cases

The whole site closes for a checkout problem. Searchable information disappears unnecessarily.

The maintenance page returns 200. Every URL appears to contain the same maintenance content and can be treated as a soft 404 or duplicate.

The site returns 404 or 410. Temporary unavailability is expressed as permanent absence.

Robots.txt returns 503. Crawlers cannot retrieve the site’s crawl policy.

A global disallow is deployed. The operator changes crawl permission instead of indicating temporary service failure.

Noindex is added everywhere. Pages are explicitly marked for removal during a temporary event.

Retry-After is fiction. Clients are told to retry at a time the service cannot meet.

The maintenance page depends on the broken application. It fails when needed.

The CDN caches 503 for a day. The recovered site remains unavailable at the edge.

The outage lasts weeks. A short-term status becomes a prolonged loss of crawlable content and metadata freshness.

The removal tool is used for closure. Users lose the ability to find the official explanation while third-party information may continue appearing.

04

Completion criteria

The maintenance implementation is complete when unaffected functionality remains online where possible and affected routes return the intended temporary behavior.

For a full short outage, ordinary page URLs should return 503 with a realistic Retry-After, the maintenance HTML should be static and lightweight, and robots.txt should remain accessible with its normal status. No global noindex, removal request, permanent redirect, 404, or 410 should be introduced.

At restoration, caches must be purged, representative URLs must return their normal status and content, robots.txt must be correct, and monitoring must show the disappearance of maintenance responses. The outage duration and recovery evidence should be preserved in the incident record.

Continue with Domain Migration SEO when maintenance is part of a hostname cutover and Hosting and CDN Migration SEO when infrastructure is moving without public URL changes.

References

Sources behind this record

1. Temporarily pause or disable a website — Google Search Central (accessed August 2, 2026)
2. RFC 9110: HTTP Semantics — RFC Editor / IETF (accessed August 2, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.