Why HTTP status codes matter for SEO
HTTP status codes tell browsers, crawlers, APIs, and other clients what happened when a resource was requested. For SEO, they help search engines understand whether a page is available, has moved, is missing, or cannot currently be served. The code is only one signal: the response body, redirect destination, canonical tags, internal links, sitemap entries, and broader site architecture also matter. A technically valid response can still be confusing when its content contradicts the status. Review status codes as part of a complete URL and template audit, not as isolated numbers.
The three broad status-code groups
Status codes are grouped into informational responses, successful responses, redirects, client errors, and server errors. In everyday SEO work, 2xx responses usually mean the requested resource was served, 3xx responses indicate a redirect or other redirection behaviour, 4xx responses indicate a problem with the request, and 5xx responses indicate a server-side failure. These broad groups are useful for triage but do not replace checking the exact code and context. A 404 page intentionally removed may be correct, while a 404 returned for a live product is a defect.
200 OK: the expected success response
A 200 response generally means the server successfully served the requested resource. Important indexable pages should normally return a stable 200 response with the intended content, an appropriate canonical, and crawlable internal links. However, a 200 alone does not guarantee indexing or quality. A thin page, duplicate page, soft 404, blocked resource, or page with contradictory canonical signals may still be unsuitable for search. Confirm that the body matches the URL’s purpose and that the response is not a generic error template disguised as success.
301 permanent redirects
A 301 response indicates that a resource has moved permanently. It is commonly used when a URL has a durable replacement, such as after a site migration, a slug change, or consolidation of duplicate URLs. Redirect directly to the closest relevant destination, update internal links and sitemaps to the final URL, and remove avoidable redirect chains. Do not redirect every deleted page to the homepage: irrelevant destinations can confuse visitors and search engines. Test both the response code and the destination, including mobile variants, trailing slashes, and query parameters.
302 temporary redirects
A 302 indicates a temporary redirect in common HTTP usage. It can be appropriate when a resource is temporarily available at another URL and the original is expected to return. Examples may include short-term campaigns or temporary operational changes, depending on the actual architecture. The important question is not whether one code is universally better, but whether the response accurately represents the intended duration and destination. Review temporary redirects that remain in place for months, and avoid using them as a substitute for deciding the permanent URL strategy.
Other redirect codes: 303, 307 and 308
Other redirect status codes have specific semantics. A 303 commonly directs a client to retrieve another resource with a GET request after a prior request. A 307 preserves the request method for a temporary redirect, while a 308 is the permanent counterpart that preserves the method. Most ordinary content-page SEO migrations involve 301 or 308 depending on infrastructure and requirements, but the correct choice depends on how the resource is requested. Do not change methods or redirect behaviour without testing forms, APIs, checkout flows, and other non-GET requests.
404 Not Found: when a URL does not exist
A 404 response means the requested resource was not found. It can be correct when a page has been removed and no equivalent replacement exists. Search engines regularly encounter missing URLs, including old links, typos, and outdated external references; a 404 is not automatically a sitewide SEO emergency. Investigate patterns and impact. A 404 on a high-value product page that should be available is different from a long-deleted URL that has no traffic, backlinks, or useful replacement.
410 Gone: deliberate removal
A 410 response indicates that a resource is gone and the condition is likely permanent. It can be useful when a site intentionally removes content and wants to state that the resource is no longer available. For many ordinary websites, a proper 404 is also acceptable when a URL no longer exists. Choose a consistent policy based on the system and the reason for removal rather than assuming that every deletion needs a 410. Ensure internal links and XML sitemaps no longer advertise the removed URL.
Soft 404s: a response that sends the wrong message
A soft 404 occurs when a page appears to be missing or empty but returns a success status such as 200, or otherwise fails to communicate its real state clearly. Examples include a generic ‘not found’ message on a 200 page, an empty product category, or a search-results page with no useful results. The response code is only part of the diagnosis; page content and context matter. If content is genuinely unavailable, return an appropriate error or provide a useful replacement page where one exists.
500 Internal Server Error
A 500 response means the server encountered an unexpected condition. Causes can include application exceptions, broken deployments, database errors, plugin conflicts, and unhandled input. A single temporary 500 may be recoverable, but recurring errors on important pages can interfere with crawling and users’ ability to complete tasks. Check server logs, application logs, recent releases, database availability, and plugin or theme changes. Do not rely only on a crawler report: correlate errors with timestamps and real server telemetry to identify the underlying failure.
502, 503 and 504 errors
A 502 commonly means a gateway received an invalid response from an upstream server, a 503 indicates temporary unavailability or overload, and a 504 indicates a gateway timeout waiting for an upstream response. These often arise from infrastructure, load balancers, application servers, rate limits, or slow dependencies. A 503 may be appropriate during planned maintenance when configured carefully, but prolonged or frequent server errors are harmful to users and can disrupt crawling. Monitor frequency, duration, affected URLs, and whether errors cluster around traffic spikes or deployments.
Redirect chains and loops
A redirect chain occurs when one URL redirects to another URL that redirects again before reaching the final destination. Chains add latency and create more points of failure. A redirect loop occurs when URLs redirect to each other or eventually back to an earlier URL, preventing the browser from reaching a final page. Crawl redirects from the original URL through to the end, and fix the source rules rather than layering additional redirects on top. Update links to point directly to the final URL and test variants such as HTTP versus HTTPS and host aliases.
Redirect maps for migrations
Before changing domains, URL patterns, CMS platforms, or site structure, create a redirect map from each old URL to its most relevant new destination. Export known URLs from the current sitemap, analytics, Search Console, crawl data, and backlink reports. Include legacy URLs that may no longer appear in the current navigation. Map one-to-one where possible, prioritise high-value pages, and avoid sending unrelated URLs to a single generic destination. Test the map on staging and after launch, then keep monitoring old URLs and server logs.
Canonical tags are not redirects
A canonical tag suggests which URL should be treated as the preferred version among duplicate or similar pages. It does not redirect users and does not guarantee that a search engine will select the declared URL. A page can return 200 and point its canonical to another URL, but the destination should be accessible and consistent with internal links and sitemap signals. Do not use a canonical tag to hide a page that should be redirected or removed. Understand the difference between redirecting, canonicalising, blocking crawling, and returning an error.
Robots.txt and status codes
Robots.txt controls crawler access to URL paths; it does not make an inaccessible page disappear from every search result, nor does it replace an HTTP status. If a URL is blocked from crawling, a search engine may have limited ability to see its content or a noindex directive on the page. Avoid blocking URLs that need to be crawled to discover redirects or understand page directives. Check robots rules and response codes together, especially during migrations and when troubleshooting unexpected indexed URLs.
Internal links to redirects and errors
Internal links should normally point directly to the intended canonical destination rather than through redirects or to error pages. Redirecting internal links waste time, complicate analytics, and may confuse users; links to 404s create dead ends. Crawl the site and export internal inlinks for affected URLs. Fix templates, menus, breadcrumbs, related-post modules, and editorial links at their source. If many URLs are affected after a slug change, use a systematic search-and-replace or CMS mapping approach, with backups and testing to avoid modifying unrelated URLs.
XML sitemaps should list valid canonical URLs
An XML sitemap should generally contain the canonical URLs the site wants search engines to discover, and those URLs should return successful responses. Remove URLs that redirect, return errors, are blocked, or canonicalise elsewhere unless a specific technical setup requires a different approach. Keep lastmod values accurate when the content meaningfully changes. A sitemap is a discovery hint, not a command to index every listed URL. Compare sitemap entries with crawl results and Search Console to find inconsistent signals and outdated entries.
Query parameters and URL variants
Query parameters can create many variants of a page, including tracking parameters, sorting, filters, session values, and internal search queries. Some variants are useful and should remain crawlable; others duplicate content or create low-value URL spaces. Do not remove parameters indiscriminately, because they may control product selection, pagination, or application state. Define which parameters alter meaningful content, how canonicalisation should work, and whether internal links expose unnecessary variants. Validate redirects and canonical tags with real examples, not assumptions about parameter order.
Trailing slashes, case, and host variants
Sites may expose URL variants involving uppercase and lowercase paths, trailing slashes, HTTP and HTTPS, www and non-www hosts, or encoded characters. Search engines can often recognise duplicate signals, but a clear URL policy helps avoid fragmented internal links and unnecessary redirects. Configure one preferred version where appropriate, ensure redirects are consistent, and update internal links to match. Test edge cases because server frameworks, hosting rules, and case-sensitive file systems can behave differently. Never assume that two visually similar URLs are equivalent in every system.
404 page design and recovery paths
A helpful 404 page should explain that the requested content is unavailable and give visitors practical next steps, such as site search, category navigation, or links to important sections. Preserve the correct 404 response even when the page is well designed; a branded error template returning 200 can create a soft 404. Avoid redirecting every missing URL to the homepage simply to reduce reported errors. Use analytics and server logs to identify common broken paths and fix the source links where possible.
E-commerce product status and discontinued items
Product URLs need a policy that reflects stock status, product lifecycle, and customer intent. A temporarily out-of-stock product may still be useful if it has specifications, alternatives, restock information, and demand. A discontinued product with a genuine successor may be redirected to that successor; a discontinued product with no relevant replacement may need to remain as an informative page or return an appropriate not-found response, depending on the business. Avoid blanket redirects from every removed product to a broad category, and coordinate SEO decisions with inventory and customer support.
Pagination, filters, and empty states
Pagination and filters can create complex status-code patterns. A valid category page with no products because of a temporary stock state is not automatically the same as a nonexistent URL. Empty search results, invalid filter combinations, expired facets, and malformed page numbers need deliberate handling. Preserve useful navigation and avoid generating endless crawlable combinations. Decide whether invalid pages should return 404, redirect to a relevant parent, or display a valid empty state with a success response based on the URL’s meaning. Test the policy across representative combinations.
JavaScript applications and client-side routing
Single-page applications can make a URL appear to load successfully even when the underlying route is missing. The server may return a generic 200 shell for every path, leaving the client to display an error after JavaScript executes. That can produce soft-404 problems and inconsistent user experiences. Ensure server responses and rendered content accurately represent the requested route where possible. Test direct URL requests, refreshes, navigation without JavaScript, and routes that do not exist. A crawler’s rendered view and the raw HTTP response can reveal different parts of the problem.
CDNs, proxies, and caching layers
The response observed by a browser may pass through a CDN, reverse proxy, web server, application, and cache. Different layers can produce different status codes or stale responses. A deployment may fix the origin while an edge cache continues serving an old redirect, or a proxy may generate a 502 before the application receives the request. Inspect headers and logs at the appropriate layers. Purge caches selectively, verify the final public response from multiple locations if relevant, and avoid confusing an origin test with what real visitors receive.
Monitor status codes with crawl tools
A site crawler can identify status codes, redirect destinations, redirect chains, internal inlinks, canonical tags, and sitemap discrepancies. Configure the crawl to respect robots rules where appropriate, and use authenticated or staged crawls when important sections are not publicly accessible. Set sensible crawl rates to avoid overloading the site. Export results and prioritise by URL importance, number of inlinks, organic traffic, conversions, and backlink value. A raw list of every 404 is rarely the most efficient remediation plan.
Use server logs to investigate Googlebot
Server logs show requests reaching the server, including timestamps, requested paths, response codes, user agents, and response sizes or durations depending on the log format. They can help identify repeated 5xx responses, unexpected redirects, crawl spikes, and important URLs that receive little crawler attention. Validate crawler identity when making decisions about Googlebot, and handle log data according to privacy and retention policies. Pair logs with crawl exports and Search Console; each source reveals different aspects of how the site behaves.
Search Console and URL inspection
Search Console can help identify indexed URLs, crawl issues, and the page Google selected as canonical in supported reports. URL inspection can provide information about a specific URL’s indexing state and last crawl, although it is not a full-site status-code crawler. Use it to investigate representative examples rather than assuming every report covers every URL. If Search Console reports a URL as indexed but a live check returns an error, compare timestamps and request conditions; the report may reflect a previous crawl or a temporary response.
Prioritise by impact, not by raw count
Not all status-code issues deserve the same priority. A 404 on a high-converting landing page linked from navigation is more urgent than a missing URL created by an old typo with no traffic or backlinks. Rank issues using business importance, search visibility, internal links, external links, frequency, and whether the response blocks an important user task. Group related errors by template or cause so one fix can resolve hundreds of URLs. Document why a URL is being kept, redirected, restored, or removed.
A safe remediation workflow
First, collect affected URLs from a crawl, Search Console, logs, sitemaps, analytics, and migration records. Second, classify each issue by the intended outcome: keep, redirect, restore, remove, or investigate. Third, identify the source rule or template causing the response. Fourth, test fixes on staging or a controlled sample. Fifth, deploy and recrawl. Finally, monitor status codes and business outcomes over time. Keep a record of changes, because redirect rules and status-code policies can become difficult to debug when several teams modify them independently.
Testing commands and browser tools
Developers can inspect HTTP responses with browser developer tools, command-line clients such as curl, or automated test scripts. Check the full redirect chain, response headers, content type, cache behaviour, and final page content. Test both the URL with and without trailing slashes when relevant, and include representative query parameters. Avoid relying on a single request from one network if a CDN or geographic routing could affect the result. Make sure test commands do not submit forms or trigger destructive actions on production systems.
Common mistakes that create SEO problems
Common mistakes include redirecting every deleted URL to the homepage, leaving internal links pointed at redirects, putting redirecting URLs in XML sitemaps, returning 200 for missing content, blocking a URL before a search engine can process the intended response, and treating temporary errors as permanent deletions. Another frequent error is deploying a redirect rule that captures too many paths. Use explicit rules where practical, test edge cases, and inspect actual responses after release. Fix the underlying cause rather than repeatedly patching individual URLs.
A practical status-code audit checklist
For each important URL, confirm the intended status, final destination if redirected, content quality, canonical target, indexability, sitemap inclusion, internal inlinks, and user journey. Check that 200 pages are genuinely useful, 3xx destinations are relevant, 404 and 410 pages are intentional, and 5xx responses are rare and investigated. Review mobile and desktop variants if they use different routing. Repeat the audit after migrations, redesigns, major CMS updates, plugin changes, and changes to CDN or server configuration.
Frequently asked questions
Are 404 errors always bad for SEO? No; they are correct for URLs that genuinely do not exist, but important pages that unexpectedly return 404 should be fixed. Should every removed page redirect? No; redirect only when there is a relevant replacement, otherwise an appropriate 404 or 410 can be correct. Is a 301 always better than a 302? No; choose based on whether the move is permanent or temporary and the behaviour required. Can a 200 page be excluded from indexing? Yes, but status and indexing directives are different signals. Why do 5xx errors matter? They can prevent users and crawlers from accessing content, especially if persistent.
Official documentation and further reading
For authoritative details, review MDN’s HTTP status code reference, Google Search Central’s redirect guidance, Google’s soft 404 guidance, Google’s robots.txt introduction, and Google’s sitemap documentation. Use current documentation when designing migration and indexing policies.
Related technical SEO resources
For a deeper site audit, connect status-code analysis with the website migration SEO checklist, the advanced canonicalisation guide, the robots.txt SEO guide, and the log file analysis guide. These topics cover adjacent signals that should agree with the response returned by a URL.
How My Advisers can help
My Advisers provides practical technology consulting and digital growth support for startups, professionals, and small and medium-sized businesses. A technical SEO review can include crawling, response-code classification, redirect mapping, canonical checks, sitemap validation, server-log analysis, and a prioritised implementation plan. The aim is to make important pages accessible, remove confusing signals, and help users reach the correct destination. Start with evidence, fix root causes in templates or configuration, and verify the public response after changes are deployed.
How to maintain a redirect register
Keep a redirect register for major URL changes. Record the old URL, new destination, reason, owner, date, status, and validation result. This is especially useful when several migrations, campaigns, or content restructures happen over time. A register helps prevent duplicate rules, loops, and chains, and it gives future maintainers context for decisions that otherwise look arbitrary. Review old rules periodically, but do not remove them simply because they are old: external links and bookmarks can continue to use legacy URLs for years.
Handling external backlinks to missing pages
When a missing page has valuable external links, inspect what the links were intended to reference before deciding on a replacement. If a closely equivalent resource exists, a redirect may preserve a useful journey. If no relevant page exists, restoring the original content or creating a genuinely useful successor may be better than redirecting to a generic destination. Contact the linking site when the relationship matters and the link can be corrected. Do not treat backlink value as a reason to send visitors to an unrelated page.
International sites and regional redirects
International sites sometimes redirect visitors based on IP address, browser language, or geolocation. Automatic redirects can prevent people and crawlers from accessing the version they need, especially when a user travels or wants to view another language. Prefer clear language and region selectors and make alternate versions discoverable. If automatic redirection is used, ensure it is not an irreversible trap and that search engines can crawl the intended URLs. Review status codes, hreflang annotations, canonicals, and internal links together.
Temporary maintenance and incident response
During planned maintenance, use a clear maintenance page and a response strategy suited to the duration and operational context. A temporary 503 can communicate that the service is unavailable, but ensure the site returns to normal responses promptly when maintenance ends. For unexpected incidents, monitor how long important URLs remain unavailable and communicate with the technical owner. Avoid leaving a generic maintenance response cached after the service recovers. Verify key pages and forms after the incident rather than checking only the homepage.
Build automated regression tests
For important routes, automated tests can verify expected status codes, redirect destinations, canonical tags, and the presence of key content. Run them after deployments and configuration changes. Keep the test set representative and maintain it as URLs evolve; otherwise, stale expectations can create noisy failures. Include negative tests for paths that should return 404 and test redirect chains so that a new rule does not introduce a loop. Automation complements periodic full-site crawls, but it does not replace investigation of unexpected real-world requests.
Editorial workflows and URL changes
Content teams should know that changing a slug can affect links, redirects, analytics, and external references. Before publishing a changed URL, check whether the old URL has backlinks, traffic, or links from other pages. Update internal links, confirm the canonical, and make sure the old path redirects only if the change is permanent and a replacement exists. Avoid changing URLs merely to insert a keyword when the existing URL already works well. URL changes should have a clear user or maintenance benefit.
Distinguish temporary outages from permanent removal
The same URL may return different codes at different times, so interpretation requires a timeline. A temporary outage should not be treated as proof that the content is permanently gone, and a deleted URL should not be restored blindly just because an old cache briefly served it. Compare logs, deployment history, uptime monitoring, and the current intended state. For high-value pages, set alerts for sustained errors and establish an escalation path so that a transient issue does not persist unnoticed.
Reporting the audit to stakeholders
A useful report groups findings by cause and impact rather than presenting thousands of raw URLs. Summarise the most important affected templates, example URLs, response evidence, user impact, recommended action, owner, and validation status. Distinguish confirmed defects from cases that require a business decision, such as whether an obsolete product should be redirected or removed. Include a follow-up crawl date and note any exclusions. This turns a technical list into a manageable improvement plan.
Every response-code fix should be validated after deployment using the public URL, not only a local configuration file. Confirm that the intended status is returned, the content matches the URL, the redirect reaches a relevant final destination, and internal links and sitemap entries are consistent. Recheck important pages after cache invalidation and keep an eye on server logs for recurring patterns.