Redirect Reference Manual

Redirect manual: which redirect types exist, when to use them, and how not to break SEO

This is not a blog post. It is a working reference page for teams, developers, and SEOs who need a practical guide to redirect types, production patterns, and decision rules.

Reference

Which redirect types exist

Not every redirect solves the same problem. The most common production mistake is not the presence of a redirect, but choosing the wrong one.

301 Moved Permanently

A permanent server-side redirect.

Use for
moving a page to a new URL permanently
HTTP to HTTPS migrations
www/non-www canonicalization
duplicate cleanup and consolidation
Avoid for
Do not use it for temporary promotions, A/B tests, or short campaigns.
Verdict: The main SEO-safe redirect for permanent changes.
302 Found

A temporary server-side redirect.

Use for
short-term page replacement
temporary campaigns
temporary maintenance flow
Avoid for
Do not leave 302s in place for months when the move is actually permanent.
Verdict: Correct only when the change is genuinely temporary.
307 Temporary Redirect

A temporary redirect that preserves the HTTP method.

Use for
API and form flows where POST/PUT must not turn into GET
temporary backend routing cases
Avoid for
For standard SEO URLs, 302 is often simpler and more familiar.
Verdict: More useful for technical behavior than for content pages.
308 Permanent Redirect

A permanent redirect that preserves the HTTP method.

Use for
permanent API moves
cases where the original request method must be preserved
Avoid for
Not the default choice for most content migration URLs.
Verdict: Technically correct, but 301 is usually simpler and more familiar for SEO pages.
Meta Refresh

A redirect implemented in HTML instead of HTTP.

Use for
almost never
Avoid for
Do not use it as your primary migration redirect.
Verdict: A weak and fragile option. Worse than server-side redirects for SEO and reliability.
JavaScript Redirect

A redirect triggered in the browser after page load.

Use for
only as a last fallback if server-side redirect is impossible
Avoid for
Do not build migration or canonical control around it.
Verdict: A poor default choice for SEO. Crawlers and external clients see it inconsistently.

Decision

Which redirect to use in real scenarios

The most useful question is not “which status code exists?” but “which one is correct in this case?”

Scenario

A page moved to a new slug permanently

Answer
301
Why

The URL changed permanently, so browsers and search engines need a stable permanent signal.

Scenario

A full move to a new domain

Answer
301
Why

This is a classic permanent migration. Old URLs should point directly to final canonical URLs.

Scenario

A temporary promo page or short-term campaign

Answer
302
Why

When the campaign ends, the original URL should return as the main destination.

Scenario

An API endpoint moved temporarily, but POST must stay POST

Answer
307
Why

307 preserves the request method and is better for technical flows.

Scenario

An API endpoint moved permanently, and the method must stay the same

Answer
308
Why

It combines a permanent move with preservation of the request method.

Scenario

You want to “solve it quickly” with a JavaScript redirect

Answer
Do not do that
Why

That is usually a temporary hack that later damages SEO, debugging, and crawl stability.

Checklist

Production-safe redirect rules

Even the correct status code is not enough if the redirect layer is assembled carelessly.

Prefer one direct hop to the final canonical URL instead of a chain with two or three intermediate steps.

Do not mix multiple goals in one chain. HTTP to HTTPS, non-www to www, and old-path to new-path should ideally collapse into one final redirect.

Do not keep temporary 302s in place when the decision is already permanent.

Do not redirect removed content to the home page just to avoid a 404.

Test redirects not only in the browser, but as a real HTTP chain: intermediate hops, final URL, response time, and issues.

Before rollout, the migration map should be checked on the most linked and most important URLs.

Risks

What not to do

These are the patterns that most often make a redirect layer technically “working” but operationally harmful.

301 -> 302 -> 200

It mixes permanent and temporary semantics, complicates crawl paths, and adds extra failure points.

Send every old URL to the home page

This is weak UX and weak semantic matching. For SEO, it is often worse than an honest 404/410 or a relevant target.

Redirect only through the front-end router

The browser may render the right screen, but the HTTP response stays wrong for search engines and external clients.

Keep meta refresh as “we will fix it later”

That “later” often never happens. The migration ends up living on a weak redirect mechanism for months.

Fast SEO-safe conclusion

If a URL moved permanently, in most cases you want a 301.

If the change is temporary, use a 302.

If this is an API or form flow and the HTTP method must be preserved, look at 307 or 308.

If the idea is to solve it with JavaScript redirect or meta refresh, the architectural choice is usually wrong.

FAQ

Is 301 always better than 302?

No. 301 is better only when the change is permanent. If the change is temporary, 302 is the more honest and correct choice.

Can I use 308 instead of 301?

Yes, but for most content SEO cases 301 remains the more familiar and expected option. 308 is more useful when preserving the HTTP method matters.

When is 404 or 410 better than a redirect?

When the old URL has no relevant replacement. Redirecting to an unrelated page only to avoid a 404 is often worse.

Even after reading the manual, you still need to test redirects on a real chain

The correct redirect type on paper does not guarantee that production returns it without extra hops, loops, or temporary responses. The final check should always happen at HTTP level, not just in the browser UI.