Every HTTP request your browser sends receives a three-digit response code before a single byte of content arrives. Those codes determine whether a page ranks, whether users see an error, and whether your server is functioning correctly. Misreading them - or ignoring them entirely - is one of the most common sources of silent SEO damage and confusing user experiences on the web.
This reference covers what HTTP status codes are, how the five classes work, a deep dive into the codes you will encounter most often, their SEO implications, and how to debug unexpected responses in WordPress.
What HTTP Status Codes Are and Why They Matter
When a client - a browser, a crawler, a REST API consumer - sends an HTTP request, the server responds with a status line containing a three-digit code and a short reason phrase. That code tells the client exactly what happened: the resource was found, it moved, access is denied, or the server failed. Everything else in the response - headers, body, content - is secondary to that code.
For user experience, status codes determine what a visitor actually sees. A 404 shows an error page. A 301 invisibly sends them to the right URL. A 503 tells them the site is temporarily unavailable. Each of these produces a fundamentally different outcome for the person on the other end.
For SEO, the stakes are just as high. Search engine crawlers treat status codes as authoritative signals about a page's canonical state. A 200 means "index this." A 301 means "transfer all signals to this new URL." A 410 means "this resource is permanently gone - stop crawling it." Serving the wrong code can cause pages to lose ranking signals, accumulate crawl budget waste, or disappear from the index entirely.
The Five Classes of HTTP Status Codes
The HTTP specification organizes all status codes into five classes, each identified by the first digit.
1xx - Informational: The server has received the request and the client should continue. These are protocol-level signals rarely seen in standard web development, though
101 Switching Protocolsappears in WebSocket handshakes.2xx - Success: The request was received, understood, and accepted. The most important class for confirming that resources are being served correctly.
3xx - Redirection: Further action is needed to complete the request. The client must follow a new location. The distinctions within this class carry significant SEO weight.
4xx - Client Errors: The request contains an error on the client side - a bad URL, missing authentication, or a resource that does not exist. The server understood the request but cannot or will not fulfill it.
5xx - Server Errors: The server failed to fulfill a valid request. These indicate problems on the server side, not with the request itself.
Deep Dive: The Status Codes That Matter Most
200 OK
The standard success response. The request succeeded, and the response body contains the requested resource. For GET requests, this means the page content. For POST requests, it means the action was processed and the response describes the result.
SEO implication: A 200 signals to crawlers that a page is live and eligible for indexing. Combined with appropriate meta directives and canonical tags, a 200 is the foundation of a crawlable, indexable page. Serving a 200 with a "Page Not Found" message in the body - sometimes called a soft 404 - is a common mistake that confuses crawlers and wastes crawl budget.
201 Created
Returned when a POST or PUT request results in a new resource being created. The response should include a Location header pointing to the new resource's URL. This code is primarily relevant in REST API development rather than traditional page serving.
SEO implication: Minimal for public web pages. Critical for API correctness - clients and integrations rely on this code to confirm that a resource was actually created rather than just processed.
204 No Content
The server successfully processed the request but has no content to return. Common in REST APIs for DELETE operations or form submissions where no redirect is needed. The response must not include a body.
SEO implication: Not applicable to crawlable pages. If a public URL returns 204, crawlers will find nothing to index, which is effectively the same as the page not existing.
301 Moved Permanently
The requested resource has permanently moved to the URL specified in the Location header. Clients should update bookmarks. Crawlers should transfer all signals - including link equity - to the new URL.
SEO implication: The workhorse of SEO redirects. A properly implemented 301 passes the vast majority of PageRank and ranking signals from the old URL to the new one. Use 301 when a page has genuinely and permanently moved: domain migrations, URL restructures, HTTP to HTTPS consolidation. Chained redirects (A to B to C) dilute signal transfer and slow down crawling - flatten redirect chains wherever possible.
302 Found
The resource is temporarily located at a different URL. Unlike a 301, the original URL should be retained by the client, and crawlers are expected to continue indexing the original.
SEO implication: 302s do not reliably transfer ranking signals. Google has historically treated some 302s as 301s in practice, but this is not guaranteed behavior and should not be depended upon. Use 302 only when a redirect is genuinely temporary - A/B testing, maintenance pages, or feature flags. Using a 302 when you mean a 301 is one of the most common causes of lost ranking signals during migrations.
307 Temporary Redirect
Functionally similar to 302, but with an explicit guarantee: the HTTP method must not change on the redirect. A POST request to a 307 URL must remain a POST to the new URL, not be converted to a GET.
SEO implication: Like 302, a 307 does not transfer ranking signals. Its primary value is in API and form handling contexts where method preservation matters. For SEO-driven redirects, prefer 301 or 308.
308 Permanent Redirect
The permanent counterpart to 307. The resource has permanently moved, and the HTTP method must be preserved across the redirect. A POST to a 308 URL remains a POST to the new URL.
SEO implication: Equivalent to 301 for SEO purposes - signals transfer to the new URL. Browser support is now broad, but 301 remains the safer choice for general page redirects unless method preservation is specifically required.
400 Bad Request
The server cannot process the request due to a client-side error - malformed syntax, invalid framing, or deceptive request routing. The client should not repeat the request without modification.
SEO implication: A 400 on a public URL prevents crawling and indexing. More commonly seen in API contexts, but can appear on WordPress sites when query strings are malformed or when security plugins reject suspicious requests.
401 Unauthorized
Authentication is required and has not been provided or has failed. The response should include a WWW-Authenticate header indicating the authentication scheme. Despite the name, this code is technically about authentication, not authorization.
SEO implication: Crawlers cannot authenticate, so a 401 effectively blocks indexing. Staging environments protected by HTTP basic auth will return 401 to Googlebot - intentional in development, catastrophic if it leaks to production.
403 Forbidden
The server understood the request but refuses to authorize it. Unlike 401, re-authenticating will not help - the server knows who you are and the answer is still no. This is the authorization failure code.
SEO implication: Similar to 401 - crawlers are blocked. A 403 on a URL that should be public is a serious crawlability problem. Common causes in WordPress include misconfigured file permissions, security plugins blocking bot user agents, or .htaccess rules that are too aggressive.
404 Not Found
The server cannot find the requested resource. No indication is given whether the absence is temporary or permanent. The URL may have existed before, may never have existed, or may exist in the future.
SEO implication: A 404 tells crawlers the page does not exist. Google will eventually drop 404 URLs from the index, typically within a few weeks to months depending on crawl frequency. Soft 404s - pages that return 200 but display "not found" content - are worse because they occupy index space without value. Use 410 instead of 404 when you know a resource is permanently gone.
410 Gone
The resource is permanently gone and no forwarding address exists. Unlike 404, the server is explicitly stating the removal is intentional and permanent.
SEO implication: A 410 signals to crawlers to remove the URL from the index immediately rather than waiting for the retry cycle that accompanies a 404. For deliberately deleted content - discontinued products, removed posts, expired campaigns - a 410 is the correct and more efficient choice. Google responds to 410s faster than 404s, making it the preferred code for deliberate content removal.
500 Internal Server Error
A generic server-side failure. The server encountered an unexpected condition that prevented it from fulfilling the request. No specific information about the failure is given to the client.
SEO implication: Crawlers treat 500 errors as temporary and will retry. A brief 500 is unlikely to cause indexing loss. A sustained 500 - hours or days - will cause Googlebot to back off and eventually treat the site as unreachable, which can drop pages from the index. In WordPress, 500 errors are frequently caused by PHP fatal errors, exhausted memory limits, or plugin conflicts.
502 Bad Gateway
A server acting as a gateway or proxy received an invalid response from an upstream server. Common in architectures involving reverse proxies, load balancers, or CDNs sitting in front of an origin server.
SEO implication: Like 500, treated as temporary by crawlers. Persistent 502s indicate infrastructure problems - a misconfigured Nginx/Apache proxy, an overloaded PHP-FPM pool, or an origin server that is down. On WordPress sites behind a CDN, a 502 almost always points to the origin, not the CDN itself.
503 Service Unavailable
The server is temporarily unable to handle the request, typically due to overload or scheduled maintenance. A Retry-After header can indicate when the service will be available again.
SEO implication: The correct code to serve during planned maintenance. When accompanied by a Retry-After header, Googlebot will respect the delay and return later without penalizing the site. Serving a 503 during maintenance is far preferable to serving a 200 with a maintenance page, which can cause the maintenance content to be indexed instead of the real page.
SEO Implications at a Glance
| Code | Crawler Behavior | Index Impact |
|---|---|---|
| 200 | Crawl and index | Page eligible for indexing |
| 301 | Follow, transfer signals | Destination URL indexed, origin dropped |
| 302/307 | Follow, signals may not transfer | Origin URL may remain indexed |
| 404 | Retry, eventually deindex | Slow removal from index |
| 410 | Deindex promptly | Fast removal from index |
| 500/502/503 | Retry with backoff | Temporary; sustained errors cause deindexing |
| 401/403 | Blocked, cannot index | Page not indexed |
How to Debug Unexpected Status Codes in WordPress
WordPress introduces several layers where status codes can go wrong: PHP itself, the WordPress application, .htaccess rewrite rules, server configuration, and any plugins or themes sitting in between.
Check the actual response, not the browser
Browsers follow redirects and cache responses aggressively. Always check status codes with a tool that shows the raw HTTP response. Browser DevTools (Network tab, disable cache) works for quick checks. For crawl-level verification, use a command-line tool:
curl -I -L https://example.com/your-page/The -I flag fetches only headers, and -L follows redirects so you can see the full redirect chain. The Signocore SEO Analyzer also surfaces redirect chains and status code issues as part of a full technical audit.
Diagnose 500 errors in WordPress
Enable WordPress debug logging by adding these lines to wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );This writes PHP errors to wp-content/debug.log without exposing them to visitors. Fatal errors causing 500 responses will appear there. If the debug log is empty, the failure may be at the server level - check your PHP-FPM or Apache/Nginx error logs directly.
Isolate plugin and theme conflicts
Deactivate all plugins and switch to a default theme (Twenty Twenty-Four) to test whether the status code issue disappears. If it does, reactivate plugins one by one to identify the source. For 403 errors specifically, security plugins like Wordfence or iThemes Security are frequent culprits - they can block legitimate bot user agents or flag valid requests as threats.
Audit your .htaccess file
WordPress relies on .htaccess for permalink rewrites. A corrupted or conflicting .htaccess file can cause widespread 404s or redirect loops. Start by replacing it with the minimal WordPress default:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressIf that resolves the issue, add your custom rules back incrementally. For generating clean, correct .htaccess configurations, the .htaccess Generator can produce a valid baseline without manual syntax errors.
Verify redirect logic
WordPress redirects can originate from multiple sources: the wp_redirect() function in theme or plugin code, .htaccess rules, server-level configuration, or a dedicated redirect plugin. When a redirect produces the wrong status code - a 302 where you need a 301, or a redirect loop - trace the source by checking each layer. The curl -I -L command above will show the full chain including intermediate codes.
Use Google Search Console for crawl-level data
Google Search Console's Coverage and URL Inspection reports show how Googlebot sees your pages, including the status codes it receives. A URL that returns 200 in your browser but shows as a crawl error in Search Console may be experiencing intermittent 5xx errors under load, or may have been cached by a CDN at a different state than the live server. Cross-referencing Search Console data with your server logs gives the most accurate picture of what crawlers actually encounter. A full technical SEO audit can surface these discrepancies before they compound into ranking problems.
Treating Status Codes as First-Class Signals
HTTP status codes are not bureaucratic protocol details - they are the primary communication channel between your server and everything that interacts with it, from browsers to search engine crawlers to API clients. Getting them right means users land where they expect, crawlers build an accurate picture of your site, and server problems surface quickly rather than silently degrading performance and rankings. The difference between a 301 and a 302, or a 404 and a 410, is rarely visible to the human eye but is immediately significant to the systems that determine whether your content gets found.
Understanding these codes at the level of their actual HTTP semantics - not just their common descriptions - is what separates developers who debug confidently from those who guess. Keep this reference close whenever you are auditing a site, building a redirect strategy, or tracing an unexpected crawler behavior. The answer is almost always in the headers.
