Redirects and HTTP errors

HTTP status codes tell browsers, search engines, and AI crawlers what happened to a URL: redirected, not found, or server error. Poorly managed, they fragment crawling and erode the trust granted to a site.

301, 302, and 308: what's the difference

All three codes signal a redirect, but with different implications:

• 301 (permanent redirect): the URL has changed for good. It signals that the page's authority and history should transfer to the new address. Use it for any lasting URL migration.
• 302 (temporary redirect): the original URL remains the long-term reference (for example, a product page temporarily unavailable that redirects to the category page). An engine will generally keep the original URL in its index.
• 308 (permanent redirect, method preserved): equivalent to a 301 but guarantees the HTTP method of the request (GET, POST) is preserved during the redirect — useful in particular for form submissions.

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-url

Using a 302 for a permanent change is the most common mistake: the engine keeps treating the old URL as the reference, which delays transferring authority to the new page. This confusion is even more common because many frameworks and hosting platforms use 302 as the default redirect code when the desired type isn't explicitly specified — it's worth actually checking, with an HTTP header inspection tool, which code your configuration really returns rather than assuming it.

Redirect chains to avoid

Every redirect adds a step the crawler must follow before reaching the final content. A chain of several successive redirects (A → B → C → D) slows down crawling, potentially dilutes the transferred signal, and some bots give up following after a limited number of hops. Best practice is to systematically redirect straight to the final destination (A → D), updating existing redirects with each new migration instead of stacking them.

These chains most often form gradually, migration after migration, with no single step being wrong in isolation: a page migrates once (A → B), then again months later (B → C), with nobody thinking to update the original redirect so it points straight to C. A periodic audit of existing redirects, especially on sites that have gone through several redesigns, helps spot and flatten these chains.

404 errors: normal, but worth monitoring

A page removed with no relevant replacement content should return a 404 error ("not found") — that's the correct HTTP behavior, not an anomaly in itself. The problem arises when:

• active internal links on the site still point to a 404 page (a broken link to fix);
• a large number of 404s come from pages that had value (backlinks, historical traffic) and would deserve a 301 redirect to equivalent content instead of a flat error.

A well-designed 404 page (clear message, link to internal search or main categories) still helps a human visitor who lands on a broken link, even though it changes nothing about how bots handle the 404 code itself.

5xx errors: a signal of degraded trust

A server error (500, 502, 503) means the page couldn't be delivered at all, regardless of its content. Frequent or repeated 5xx errors, especially at the moment a crawler tries to access the site, degrade the perception of the site's technical reliability and can reduce how often it comes back to crawl your pages. These errors typically occur during load spikes, poorly prepared server updates, or resource limits being hit on undersized hosting — causes often unrelated to the content itself, but that still affect the site's overall perception.

How to check your site's HTTP statuses

A page's HTTP status isn't visible to the naked eye in a regular browser: a page returning a 500 error can display a generic message with no clear sign of the actual code on screen. The network inspection tools built into browsers (the "Network" tab in developer tools) show the exact status code returned for each request, letting you concretely verify that a redirect announced as permanent actually returns a 301, or that a page assumed to be working isn't quietly returning a 5xx error. On a large site, a periodic audit with a dedicated crawling tool remains the most reliable way to catch these anomalies at scale, rather than a manual, page-by-page check.

Impact on crawling and trust

A site riddled with redirect chains, unhandled 404s, and intermittent 5xx errors sends a signal of poor technical maintenance. Crawlers, human and automated alike, generally place more confidence in a site whose URLs are stable and whose errors are rare and properly handled. Regularly checking these statuses is one of the points covered in the complete technical checklist, alongside crawler access control covered in the lesson on robots.txt.

Finally, don't confuse a redirect with a canonical tag: the former makes one URL disappear in favor of another, while the latter leaves both URLs active while indicating which one to prefer.