301 vs 302 vs 307 vs 308 Redirects: Differences, SEO, and Debugging

HTTP redirects look simple: one URL sends a visitor to another. In production, the status code you choose affects caching, request methods, migrations, APIs, browser behavior, and how search engines understand URL changes.

The four redirect codes developers see most often are 301, 302, 307, and 308.

Quick comparison

The important distinction is not only permanent versus temporary. For APIs and non-GET requests, method preservation matters too.

301 Moved Permanently

Use a 301 when a resource has moved permanently and the old URL should normally be replaced by the new one.

Common uses:

• changing a page slug;
• moving HTTP traffic to HTTPS;
• consolidating www and non-www;
• migrating an old site structure;
• redirecting discontinued landing pages to a true replacement.

For SEO migrations, map each old URL to the most relevant new URL. Avoid sending every removed page to the homepage because that creates a poor experience and weakens the meaning of the redirect.

302 Found

A 302 is commonly used for a temporary redirect.

Examples:

• a temporary campaign;
• a short maintenance flow;
• an experiment;
• a temporary geographic route;
• a resource that is expected to return to the original URL.

If the move is actually permanent, use an appropriate permanent redirect instead of keeping a 302 forever.

307 Temporary Redirect

A 307 is a temporary redirect with clearer method-preserving semantics.

This matters when the original request is not a simple GET. If a client sends a POST request, you generally do not want a redirect to silently turn it into a GET.

For APIs, form submissions, upload endpoints, and other method-sensitive requests, understanding this behavior is essential.

308 Permanent Redirect

A 308 represents a permanent redirect while preserving the request method.

It is useful when you want permanent canonicalization but need stronger method semantics than older redirect patterns may provide.

As with any permanent redirect, make sure the new destination is truly intended to replace the old URL.

Trace the real redirect chain

Do not assume your application creates only one redirect.

A request might pass through:

1. HTTP to HTTPS;
2. apex domain to www;
3. old path to new path;
4. locale routing;
5. authentication routing.

Use Duck Cloud's Redirect Checker to trace the chain. A direct redirect is easier to maintain and usually faster than several sequential hops.

Avoid redirect loops

A redirect loop happens when rules send a request back to an earlier URL.

Typical causes include:

• Cloudflare forces HTTPS while the origin believes the request is HTTP;
• a reverse proxy adds or removes www differently from the application;
• locale middleware redirects between two versions;
• a trailing-slash rule conflicts with a framework route rule;
• authentication middleware sends a login route back to itself.

When debugging a loop, write down every URL in sequence instead of changing rules randomly.

Check the status and Location header

A redirect is an HTTP response with a Location header.

Use the HTTP Header Checker to inspect the status and destination. Then use the Website Status Checker to confirm the final URL returns the expected success status.

If you do not recognize a code, the HTTP Status Code Lookup provides a quick reference.

Redirects during a domain migration

For a domain migration:

• keep the path mapping as specific as possible;
• redirect old pages to equivalent new pages;
• update internal links to point directly to the new URLs;
• update canonical tags and sitemaps;
• keep redirects active long enough for users, links, and crawlers to transition;
• verify that robots.txt and authentication do not block the destination;
• monitor 404s after launch.

Do not create a long chain such as old domain → intermediate domain → new domain. Redirect the old URL directly to the final URL whenever possible.

Redirect checklist

Before deploying a redirect rule, ask:

• Is the move permanent or temporary?
• Must the request method be preserved?
• Does the destination exist?
• Will this create a loop?
• Is there already another CDN, proxy, framework, or server redirect?
• Can the old URL point directly to the final URL?
• Have internal links been updated?
• Does the final page return the expected status?

A redirect is small configuration with large consequences. Choose the code intentionally, test the full chain, and keep your URL architecture simple.