HTTP Status Codes and SEO: 301, 302, 404, 410 and 503

HTTP status codes matter for SEO because they are the first thing Google reads about every URL. Before looking at any content, Googlebot checks the status code to decide what to do: index the page (200), follow it somewhere else (301, 302, 307, 308), drop it (404, 410), or slow down and try again later (429, 500, 503).

When a server returns the wrong code, such as a 200 for a missing product or a 302 for a permanent move, Google acts on the code, not on what you meant. The result can be thousands of empty pages in the index, rankings that never transfer after a migration, or a whole site dropping out during a long maintenance window.

This guide follows Google's documentation on how status codes affect its crawlers and adds the patterns we use to get them right in PHP applications.

How Google reads HTTP status codes and SEO signals

Google's article on how HTTP status codes affect Google's crawlers groups codes by their first digit, and each group leads to different behaviour.

A status code is a promise about the resource. Google takes that promise at face value, which is why mismatches between the code and the content cause so many SEO problems.

Network problems sit outside this table but have similar effects. DNS failures, connection timeouts and TLS errors stop Google reaching the server at all, and it treats them much like server errors: it slows down, retries and eventually drops URLs if the problem persists.

200: success, but only for real content

A 200 response tells Google that the URL exists and has content worth considering. Google then decides whether to index it based on the content itself. Returning 200 does not guarantee indexing; returning it for the wrong pages guarantees confusion.

Soft 404s

A soft 404 is a page that says "not found", "no products" or "this item is no longer available" while returning a 200 status. Google often detects these and treats them as errors, but it spends crawl time doing so, and some slip through into the index as thin pages.

• Deleted products that render an empty product template with a 200.
• Search and filter pages that show "0 results" with a 200.
• Catch-all routes that render a friendly error page without changing the status.
• JavaScript applications that render a "not found" view on the client while the server returns 200 for every path.

Fix them at the source: when a record is missing, the controller should return a real 404 with a helpful error page. Search Console's page indexing report lists suspected soft 404s, which is a good starting point.

3xx: redirects and when to use each

Redirects tell Google a resource lives somewhere else. Google's guidance on redirects and Google Search distinguishes permanent from temporary redirects, and the difference matters for which URL appears in results.

A permanent redirect is a strong signal that the target should be shown in results instead of the source. A temporary redirect is a weak signal, so Google may keep showing the original URL. Using 302 for a permanent change is one of the most common reasons rankings fail to transfer after a migration.

Google follows a limited number of hops in a chain, and each hop slows users down. Redirect directly to the final URL and update internal links so they never rely on redirects at all. Our guide to canonical URLs and duplicate content covers normalisation redirects in detail.

// Laravel: permanent redirect for a renamed article.
Route::permanentRedirect('/blog/old-article-slug', '/blog/new-article-slug');

// Plain PHP equivalent.
header('Location: https://example.com/blog/new-article-slug', true, 301);
exit;

404 and 410: content that is gone

When a page no longer exists and has no close replacement, return a 404 (not found) or 410 (gone). Google treats them very similarly: neither is indexed, and indexed URLs returning them are removed over time. A 410 states more explicitly that the removal is permanent, which some teams prefer for deliberately deleted content.

• Do not redirect every missing page to the home page. Google often treats these as soft 404s, and visitors find them confusing.
• Do redirect when there is a genuine replacement, such as a newer version of a product or a merged article.
• Keep 404 pages helpful: search, popular links and a route back to the main sections.
• Fix internal links that point to removed pages rather than leaving them to return errors.

404s on URLs that never existed, such as typos in other sites' links, are normal and do not harm your site. If an old URL with valuable links returns 404, though, a redirect to the closest relevant page is worth adding. Our article "Is my website on Google?" explains how these appear in Search Console.

429 and 5xx: overload and server errors

Server errors and the 429 status tell Google that the problem is on your side and probably temporary. Google responds by slowing its crawl rate. If the errors continue, it starts dropping the affected URLs from the index, because it cannot confirm they still exist.

• 500 errors usually mean application bugs; monitor logs and fix the cause.
• 502 and 504 errors often come from proxies, load balancers or timeouts in upstream services.
• 429 responses from rate limiters or bot protection can slow Googlebot if they are too aggressive; verified Googlebot traffic should usually be allowed.
• Persistent 5xx on robots.txt can pause crawling of the whole site, so keep that file fast and reliable.

Our guide to uptime monitoring explains how to catch error spikes before they affect customers and crawlers alike.

503 for planned maintenance

For short, planned maintenance, return 503 Service Unavailable with a Retry-After header for every URL, including robots.txt if your server handles it. Google understands that the outage is temporary and comes back later, without treating pages as removed.

// Maintenance mode: 503 with Retry-After (seconds).
http_response_code(503);
header('Retry-After: 3600');
header('Content-Type: text/html; charset=UTF-8');
echo '<h1>We are updating the site and will be back shortly.</h1>';

Keep maintenance short. A 503 is meant for hours, not weeks. Prolonged errors eventually lead Google to drop URLs, just as with other server errors. Laravel's built-in maintenance mode returns a 503 by default, which is the right behaviour.

For longer work, keep the existing site running and switch over only when the new version is ready. If parts of the site must be unavailable for days, consider keeping the important pages online with a notice rather than returning errors for everything.

Status codes during migrations

Platform migrations and redesigns change thousands of URLs at once, and status codes decide whether search visibility survives the move. A careful plan maps every old URL with traffic or links to its closest new equivalent and returns a 301 for each one.

• Map one to one wherever a clear equivalent exists: old product to new product, old article to new article.
• Return 404 or 410 for content that is deliberately not moving, rather than redirecting it all to the home page.
• Keep redirects in place for at least a year, and longer for URLs that still receive visits or links.
• Crawl the old URL list after launch and confirm every entry returns the intended code in a single hop.

Our guide to migrating a store without losing SEO covers redirect mapping and post-launch monitoring in detail.

Testing status codes

Templates, middleware and caching layers can all change the status code that actually reaches the client, so test what the server really returns rather than what the controller intends.

1. Write HTTP tests asserting 404 for missing records, 410 for deliberately removed content and 301 for known redirects.
2. Test through the full stack, including any CDN or reverse proxy, with a tool such as curl -I.
3. Crawl the site after each release and list every non-200 internal link.
4. Check that cached error pages keep their error status rather than being cached and served as 200.
5. Review Search Console's page indexing report for soft 404s, server errors and redirect errors.

Our technical SEO checklist includes these checks for online stores, where product deletions create soft 404s more often than anywhere else.

Frequently asked questions

Seeing soft 404s or server errors in Search Console? Our SEO services include technical audits, and our developers can fix the responses.