HTTP Status Code SEO Checklist

Use this for: Any status-code review of a website or release.

List the page types your website actually uses, such as services, products, categories, articles and language versions. Select an important published example from each type, plus a recently changed page and a known removed page. Add the specific URLs reported as errors in your crawl or Search Console.

Write the intended state beside each example: live content, moved, missing, removed or private. An intentionally protected account page should not be judged against the same public-access test as a service page. For a larger review, use the template sample to interpret a broader crawl.

1. List the distinct templates and important reported problem URLs.
2. Choose representative examples and state the intended behavior.
3. Include changed, removed and deliberately private controls where relevant.

Use this for: HTML pages whose response needs verification.

Open Chrome Developer Tools and select Network. Enable Preserve log and Disable cache, keep DevTools open, then load the exact URL. Select the main document request and open Headers. Read its Request URL, Request Method and Status Code; if it redirects, inspect the final document separately.

Use the Response or Preview panel and the visible page to confirm what arrived. A red image request does not mean the HTML page returned 404, and a visible branded error screen does not prove that the server sent an error status.

1. Load the URL with Network recording active.
2. Select the document and read the exact URL, method and status.
3. Compare the response body and any redirect destination with the intended page.

Use this for: Inconsistent responses, recent repairs and 304 or cache-served results.

If Network reports a memory cache, disk cache or service-worker response, repeat the request with browser caching disabled or ask the developer for a clean GET outside that service worker. Keep the exact URL unchanged while checking whether the result is current.

A 304 Not Modified can be correct for a conditional request: it tells the client to reuse its cached representation. It is not a redirect to another page. When verifying new content, inspect a fresh GET and the current body; do not change a valid 304 merely to make every log row show 200.

1. Check whether the response came from a browser cache, service worker or conditional request.
2. Repeat with a fresh GET when the result may be stale.
3. If responses still differ, ask the developer to compare the public CDN response with the origin.

Use this for: Reported crawl errors, intermittent responses or claims about crawler access.

In Search Console URL Inspection, note the available crawl date and fetch or indexing finding for the exact address. Compare it with today’s document response. Use Crawl stats and server or CDN request records when the issue appears intermittent or affects many pages.

A successful browser request cannot erase an earlier crawler failure, and an old failure does not prove that today’s repair failed. Match the URL and time window before deciding. A request merely claiming to be Googlebot needs verification before you use it as proof of Google’s behavior.

1. Compare the current URL response with the dated Search Console finding.
2. For intermittent failures, inspect relevant request records and error time windows.
3. Classify the finding as current, historical or still unverified.

Use this for: Published HTML pages intended to provide useful public content.

Open each wanted template example and compare its main content with the page promised by its title and URL. Check the body as well as the 200 status. Look for a blank application shell, failed product details, a large error message or a login screen replacing public information.

If Search Console reports Soft 404 for a page that should exist, inspect the rendered result and failed resources. Repair the missing content or loading fault. The label is not a universal word-count threshold, and adding filler does not repair a failed template.

1. Read the main content of the 200 document.
2. Compare it with the page’s intended subject and visitor task.
3. Repair missing content or failed resources and inspect the rendered page again.

Use this for: Public route handlers and custom error-page templates.

Create a clearly nonexistent test path under your own site and request it directly. Check the document status and visible error page. Repeat under a different route family if the application has separate handlers. The original missing URL should normally return 404 with a helpful explanation.

Do not count the status of a separate /404/ address as the missing URL’s response. A redirect to the homepage or a 200 response with “not found” text can conceal the failure. Keep useful navigation on the error page without turning the error into a success response.

1. Request a deliberately nonexistent path in each relevant routing family.
2. Read the status of that original document request.
3. Correct the missing-route handler and confirm real pages still return their intended responses.

Use this for: Existing 404 or 410 findings and retired content.

Check the content record or ask its owner whether the page is missing unexpectedly, intentionally removed, or replaced elsewhere. Restore content that should still exist. If there is a close replacement, map the old address to it; if there is none, return a genuine missing or gone response.

404 says the resource was not found; 410 says it is intentionally gone and likely permanently unavailable. Google’s current guidance treats these responses alike for indexing purposes. Do not promise faster removal from 410, or redirect unrelated pages just to make a report’s error total smaller. Remove obsolete internal links and current sitemap entries.

1. Confirm whether the page should exist, has a suitable replacement or is removed.
2. Restore it, redirect to the relevant replacement, or use a genuine removal response.
3. Update your internal references and verify the original address.

Use this for: Single-page applications and routes that depend on client-side data.

On a JavaScript application, open a valid deep route directly in a new tab and reload it. Then request an invalid item or route directly. Compare the initial document response with the content after the application runs. A client-side transition alone can hide what a fresh visitor or crawler receives.

Ask the developer to return the correct status from the server where possible. If the architecture cannot send a route-specific error, review a supported fallback such as sending missing content to a URL that really returns 404, or applying noindex to the error view. Test valid routes as well so the fallback does not exclude working pages.

1. Directly open and reload a valid deep route and an invalid counterpart.
2. Compare the initial response with the rendered content.
3. Repair the missing-content branch and retest both routes.

Use this for: Unexpected 401 or 403 responses on pages intended to be public.

Request the affected public page while signed out. A 401 concerns missing or invalid authentication; a 403 means access is refused. Compare the page with a deliberately private account route and ask the developer or host to inspect the matching authentication, firewall or CDN event.

If public pages are blocked by mistake, correct the narrow rule or deployment setting that caused it. Keep intended account protections in place. Do not use 401 or 403 as a way to slow Google’s crawling, and do not disable all security rules merely to make a test crawler pass.

1. Reproduce the affected public response in a signed-out request.
2. Find the matching authentication or security rule with its owner.
3. Correct the unintended restriction and retest a public page plus a private control.

Use this for: 429 responses found during a crawl or in request records.

If your crawl begins returning 429, pause or reduce its request rate and read any Retry-After header before testing again. Check the host or CDN rate-limit records for the affected URL and time. One audit tool exceeding a threshold is different from ordinary visitors or verified search crawlers being limited.

For unwanted limits on legitimate traffic, ask the responsible owner to tune the matching rule or capacity using the actual request records. Google treats 429 as an overload signal. Changing it to 403 would not solve the cause or provide the same crawl-rate signal.

1. Check whether the 429 begins with your test traffic and inspect Retry-After.
2. Compare the rate-limit event with ordinary and verified crawler requests.
3. Adjust the audit pace or the responsible rule as appropriate, then retest without overloading the site.

Use this for: Unexpected or repeated 5xx page responses.

For a failing URL, record the time and any response request ID, then check the matching application, hosting or CDN error log with the responsible developer. Compare a working page from another template. A 500 indicates a server failure; 502 and 504 point toward a gateway or upstream response problem, but the status alone does not identify the cause.

Prioritize repeated errors across important templates and visitor journeys. Correct the failing application, dependency or delivery configuration and test again. Do not turn the error page into a 200 response or blanket-redirect failures to the homepage to hide the outage.

1. Reproduce a limited sample and capture the time or request ID.
2. Match it to server, application or gateway records and compare a working control.
3. Repair or restore the failing component, then request the affected templates again.

Use this for: Planned temporary unavailability of public pages.

If maintenance makes a public page unavailable, have the developer serve a temporary 503 response with a clear message at the affected URL. Include a realistic Retry-After value when the expected recovery time is known. Check how the CDN caches that response so an old maintenance page does not persist after recovery.

Return the real content and its normal response as soon as service resumes. A 503 is not a way to preserve a page indefinitely during an extended closure: persistent server errors can eventually lead to removal from Google’s index. A misleading 200 maintenance page does not solve that problem.

1. Check the affected document’s actual maintenance status and message.
2. Review Retry-After and cache behavior with the hosting owner.
3. After recovery, confirm the normal response and content across affected templates.

Use this for: Crawl reports or samples containing multiple response findings.

Sort crawl results by status, then group affected URLs by template, host and intended state. Open examples from each pattern. Keep expected removals and protected routes separate from broken public pages; many valid 404s do not mean a sitewide emergency.

Fix widespread 5xx responses or accidental access blocks on important live pages first. Next address false success responses, broken replacements and missing pages that should exist. Assign the repair to the layer or content owner that controls the problem.

1. Group the findings by status, template and intended behavior.
2. Check representative examples to confirm the pattern.
3. Prioritize the affected visitor journeys and assign a specific repair.

Use this for: Published response fixes and closure of intermittent-error investigations.

After a repair is published, request the same URL with the same relevant signed-out, path and query conditions. Compare its status and body with the original failure. Test another page using the affected template and a control that should remain missing, private or otherwise unchanged.

For intermittent errors, inspect new requests in the time or load conditions that previously failed, using your normal monitoring records. Keep that outcome pending if there is not enough fresh evidence. Separately check later Search Console records; a live repair and an updated search record are different observations.

1. Repeat the original failing request after publication.
2. Check a second affected-template example and an unchanged control.
3. Confirm recovery in fresh records where intermittency matters, and review later search records separately.