301 vs 302 vs 303 vs 307 vs 308 Redirects

Redirects look simple. Most people treat them like a switch: “old URL goes to new URL, done.”

But if you’ve ever migrated a site, changed your URL structure, or run a promo landing page, you already know the ugly truth: the wrong redirect can keep the wrong URL indexed, create crawling dead-ends, tank performance with redirect chains, or break forms and checkouts.

Unfortunately, the SEO advice online is often too shallow. It’ll tell you “use 301 for permanent, 302 for temporary”… and skip the part that actually causes problems in real life: caching behaviour, method preservation (POST vs GET), and how search engines treat “temporary” when you leave it there for months.

What is an HTTP redirect (and why it matters)

Definition

An HTTP redirect is a server response that tells a browser (or Googlebot) “the page you asked for isn’t here anymore. Go fetch it from this other URL instead.”

In practice, a redirect response includes a 3xx status code (like 301 or 302) and a destination URL (the Location header). The browser then requests the new URL.

Why redirects matter for users

Users don’t care what a “301” is. They care whether they land on the page they expected.

• If redirects are done right, users barely notice anything.
• If redirects are done badly, you get slow loads, broken flows (especially on forms), confusing “page not found” errors, and sudden conversion drops.

Why redirects matter for SEO

Search engines use redirects to decide what to crawl, what to index, and which URL should be treated as the “real” version of a page.

That means redirects directly affect:

• Indexing: whether Google keeps the old URL indexed or replaces it with the new one
• Consolidation: whether signals (links, relevance, history) are consolidated onto the destination URL
• Crawl efficiency: whether Googlebot wastes time going through extra hops instead of crawling your important pages

The silent killer: redirect chains

A redirect chain is when one URL redirects to another URL, which redirects again, and maybe again.

Example:

• /old-page → /new-page → /new-page/ → /new-page?ref=canonical

Each hop adds an extra request. That means slower page loads for users and more wasted crawl capacity for search engines. In a big site migration, chains also make debugging harder because you stop knowing which redirect is actually responsible for the final outcome.

Worse: redirect loops

A loop is when redirects send a client in circles:

• /a → /b → /a

This can block crawling entirely and create “too many redirects” errors for users. If you’ve ever seen a browser error page when trying to access a URL, loops are a common culprit.

Redirects aren’t just “SEO settings”. They are infrastructure.

If you treat redirects like an afterthought, you’ll pay for it later. The clean approach is to treat redirects as part of your site architecture:

• Choose the right status code for the situation
• Keep redirects to one hop
• Send users and bots to the most relevant equivalent page (not your homepage)
• Test at scale, not “a few URLs”

Rule of Thumb

If you remember nothing else from this guide, remember this: redirects are not about what is “best for SEO” in theory. They are about being honest with intent.

If the move is permanent, use a permanent redirect. If the move is temporary, use a temporary redirect. If you lie with the status code, you get mixed signals and unpredictable outcomes.

Step 1: Is the old URL ever coming back as the primary URL?

• No, it’s gone for good: use 301 (default) or 308 (only if you must preserve method and request body).
• Yes, it will return: use 302 (default) or 307 (only if you must preserve method and request body).

Step 2: Does the redirect need to preserve the HTTP method?

This is the part many SEO articles skip, and it is exactly why 307 and 308 exist.

• If method does not matter (typical page views are GET requests): 301 or 302 is usually fine.
• If method matters (forms, checkout flows, API endpoints, anything that submits POST data): use 307 (temporary) or 308 (permanent).

Step 3: Are you redirecting after a form submission and want to land on a normal page?

If you have a POST request (form submit) and you want the user to end up on a confirmation page that should be loaded via GET, use 303. This is the standard POST/Redirect/GET pattern and helps prevent double submissions when users refresh.

Quick cheat sheet

Situation	Use this	Why
Permanent URL change (most SEO migrations)	301	Signals a permanent move and is widely supported by clients
Temporary change (maintenance, short promos, A/B tests)	302	Signals the original URL should remain the main one long term
Temporary redirect where POST must remain POST	307	Method and request body are preserved by definition
Permanent redirect where POST must remain POST	308	Permanent move with guaranteed method preservation
After a POST form submit, redirect to a GET page	303	Explicitly tells clients to follow with a GET, preventing resubmits

One warning before we go deeper

Do not pick a “temporary” code because you want to be cautious, then leave it in place for months. Search engines will eventually treat long-lived temporary redirects as effectively permanent in many cases. That is how people accidentally lose control of what gets indexed.

301, 302, 303, 307, 308 explained (with real use cases)

This is the section where most guides fall apart. They tell you “301 is permanent, 302 is temporary” and move on.

That is not enough. The differences that actually break sites or confuse search engines usually come down to two things:

• Caching behaviour (especially with 301)
• Method preservation (GET vs POST, and why 307/308 exist)

Let’s go status code by status code.

301 Moved Permanently

What it means

A 301 tells clients and bots the resource has moved permanently. The expectation is that the old URL is not coming back.

What browsers tend to do

• Browsers commonly cache 301 redirects aggressively.
• This is good for speed, but bad if you accidentally 301 the wrong thing and need to undo it.

What search engines tend to do

• They usually replace the old URL with the destination URL over time.
• Signals are generally consolidated to the destination URL, but do not assume this is instant or perfectly clean if your implementation is messy.

Use 301 when

• You are migrating to a new domain
• You are changing URL structure permanently
• You are enforcing one canonical version (HTTP → HTTPS, www → non-www, trailing slash rules)
• You are consolidating duplicate pages into a single preferred URL

Common 301 mistakes

• Using 301 for short-term changes (promos, tests). You will regret this because of caching.
• Redirecting everything to the homepage. This is lazy and often irrelevant. Map each old URL to the closest matching equivalent.
• Creating redirect chains. One hop beats three hops every time.

302 Found (Temporary Redirect)

What it means

A 302 tells clients and bots the move is temporary. The expectation is that the original URL will be used again as the main URL.

The confusing part

Historically, different clients treated 302 differently, especially around whether a POST could turn into a GET. That is one reason 303 and 307 were introduced, to remove ambiguity.

What search engines tend to do

• They usually keep the original URL as the primary URL in the index.
• If the 302 is left in place long enough, search engines may start treating it like a permanent move. This is where people lose control by accident.

Use 302 when

• Maintenance pages (short term)
• Temporary promo landing pages
• A/B testing and split testing
• Geolocation or device-based routing (when you still want the original URL to remain the main one)

Common 302 mistakes

• Using 302 for a permanent migration because it feels “safer”. It is not safer. It is mixed intent.
• Leaving 302s in place indefinitely. If it is permanent, make it permanent.

303 See Other

What it means

A 303 is used when you want the client to follow the redirect with a GET request to the new URL, even if the original request was a POST.

Why it exists

It supports the classic POST/Redirect/GET pattern. The goal is to prevent users from re-submitting a form when they refresh a page.

Use 303 when

• A user submits a form (POST) and you want to send them to a confirmation page (GET)
• You want to avoid duplicate submissions and messy user journeys

What not to do

• Do not use 303 as your default “temporary redirect” for normal page moves. It has a specific purpose.

307 Temporary Redirect

What it means

A 307 is a temporary redirect that preserves the method and request body. If the original request was POST, the redirected request must also be POST.

Why this matters

If you redirect a form submission or API call and the client changes the method, you can break checkouts, logins, subscriptions, and tracking endpoints. 307 exists to stop that ambiguity.

Use 307 when

• You need a temporary redirect and method preservation matters
• Forms, checkout flows, authenticated endpoints, APIs
• Marketing redirect systems where the destination may change, but you do not want clients caching a permanent rule

Common 307 mistakes

• Using 307 when you really mean permanent. If the old URL is not coming back, you are just creating long-term ambiguity.

308 Permanent Redirect

What it means

A 308 is a permanent redirect that also preserves the method and request body. It is essentially the “method-safe 301.”

Use 308 when

• You need a permanent redirect and the method must be preserved
• APIs where endpoints are permanently moved
• Permanent infrastructure changes that must not risk POST becoming GET

Compatibility reality

308 is newer than 301. Most modern clients handle it fine, but legacy clients can be a concern in edge cases. For standard SEO migrations where requests are almost always GET, 301 is still the simplest and safest default.

Common 308 mistakes

• Using 308 just because it is “newer” or “more modern.” If you do not need method preservation, you are not gaining anything meaningful.

So which one should you default to?

• Most SEO work: 301 for permanent moves, 302 for temporary moves.
• Engineering and API flows: 307/308 when method preservation matters.
• Form submit redirect pattern: 303 when you specifically want POST → GET after submission.

What redirects do to indexing and SEO signals

This is where people get themselves into trouble. They treat redirects like a pure technical detail, then act surprised when Google indexes the “wrong” URL or rankings move in ways they did not expect.

First principle: search engines respond to intent, consistency, and time

Redirects are a signal. A strong one, but still a signal. Search engines look at:

• Status code intent (permanent vs temporary)
• How long the redirect stays live
• Whether the destination is a true equivalent (topic match, intent match)
• Whether your site sends consistent signals elsewhere (internal links, canonicals, sitemaps)

If your signals disagree, you are basically asking Google to guess. And Google will guess in ways you do not like.

Permanent redirects (301 and 308) usually lead to replacement

When you use a permanent redirect, you are telling search engines the old URL should be replaced by the new one.

In most normal scenarios, this is what happens over time:

• The old URL gets crawled
• Google sees the permanent redirect
• The destination URL becomes the primary indexed URL
• Signals consolidate toward the destination URL

What can go wrong even with a 301

• Bad mapping: If you redirect to an irrelevant page (especially dumping everything to the homepage), you weaken relevance. Users bounce, and search engines lose confidence that the redirect is a true replacement.
• Chains: If A redirects to B and B redirects to C, you add latency and crawling complexity. It also increases the chances of something breaking later.
• Mixed signals: If internal links still point to the old URL, your sitemap lists the old URL, or canonicals contradict the redirect, you create confusion.

Temporary redirects (302 and 307) usually keep the original URL indexed

Temporary redirects tell search engines: “This move is not the new normal.”

That usually means:

• The original URL remains the main indexed URL
• The destination URL may be crawled, but it is not treated as the replacement
• Signals are not expected to consolidate in the same way as a permanent move

The trap: temporary redirects that never end

If you set a 302 and leave it for weeks or months, you are sending a mixed message. You are saying “temporary,” but behaving “permanent.”

Search engines do not stay literal forever. Over time, long-lived temporary redirects can start being treated more like permanent moves in practice. That is why “I used 302 for safety” is not a safe strategy. It is often just procrastination that leads to messy indexing later.

Why 307 and 308 are not “SEO upgrades”

Some people assume 307 and 308 are “better” because they are newer. That is not the point.

307 and 308 exist to remove method ambiguity. They are about correct behaviour for POST and other non-GET methods. From an SEO perspective, most page-level redirects are GET requests, so 301 and 302 remain the default choice for the majority of SEO use cases.

Caching affects more than speed. It affects debugging.

Browsers often cache 301 redirects aggressively. That means:

• You can fix a redirect server-side and still see the old behaviour in your browser
• You might think “the redirect is still broken” when it is actually cached

Blunt advice: when testing redirects, do not trust one browser session. Use multiple tools and methods (incognito, curl, header checkers, crawling tools) so you are seeing what a bot would see, not what your browser remembered.

What you should do to make redirects work in your favour

• Match code to intent: permanent means 301 or 308, temporary means 302 or 307.
• Map like-for-like: redirect each old URL to the closest equivalent page, not a generic catch-all.
• Align supporting signals: update internal links, canonical tags, and sitemaps to point to the destination URLs.
• Remove chains: one hop whenever possible.
• Do not leave “temporary” running forever: set a review date.

Common scenarios: migrations, HTTPS, promos, A/B tests, forms

Most redirect mistakes happen because people choose the status code in isolation. They do not think through the actual scenario, how long it will last, and what needs to keep working.

Here are the most common situations you will run into, and the redirect choices that make sense.

1) Full site migration to a new domain

Use: 301 (almost always)

Why: A domain migration is a permanent change. You want the new domain URLs to become the indexed versions, and you want signals to consolidate there.

How to do it properly

• Create a one-to-one redirect map from old URLs to the closest matching new URLs.
• Do not redirect everything to the homepage. That is a relevance downgrade and a user experience downgrade.
• Keep it one hop. Old URL should go directly to final destination.
• Update internal links and your XML sitemap to point to the new URLs, not the redirected ones.

2) URL structure change on the same domain (site rebuild, slug updates)

Use: 301 (default), 308 only if method preservation is critical

Why: If the old URLs are not coming back, this is permanent.

Typical examples

• /services/seo-singapore → /seo/
• /blog/post-name → /resources/post-name

3) HTTP to HTTPS migration

Use: 301

Why: You are enforcing a canonical, permanent version of the site. This should not be temporary.

What most people forget

• Update internal links to HTTPS, do not rely on redirects.
• Ensure canonicals point to HTTPS URLs.
• Make sure you only have one canonical host variant (decide on www vs non-www and enforce it).

4) www vs non-www (canonical hostname standardisation)

Use: 301

Why: This is a permanent canonical decision. Pick one and enforce it consistently.

5) Trailing slash, lowercase, and URL normalisation rules

Use: 301

Why: These are canonicalisation rules. The whole point is that one version is the permanent preferred version.

Examples

• /About → /about
• /category → /category/ (or the reverse, but be consistent)

6) Temporary maintenance page

Use: 302 (default), 307 if method preservation matters

Why: You want Google to keep the original URLs as the main ones. You also want rollback to be clean when maintenance ends.

Reality check

If maintenance is truly short term, 302 is usually the simplest. If you are redirecting flows that include POST requests (logins, forms, checkout), 307 reduces the chance of method-related breakage.

7) Short-term promotions and seasonal landing pages

Use: 302

Why: Most promos have an end date. A 301 can stick in browsers and keep sending users to the promo page even after you think you have reverted it.

Common approach

• Keep the evergreen URL as the main destination.
• Use a 302 only during the promo window.
• When the promo ends, remove the 302 and restore the evergreen behaviour.

8) A/B testing and split testing

Use: 302 (or testing frameworks that avoid server redirects entirely)

Why: You do not want search engines to treat the test variant as the permanent replacement.

Important warning

If you 301 a test variant, you are effectively telling search engines and browsers that the variant is the new normal. That is not a test anymore. That is a permanent change you cannot easily unwind.

9) Redirecting after a form submission

Use: 303

Why: This is the classic POST/Redirect/GET pattern. User submits a form via POST, you redirect them to a confirmation page that loads via GET. This helps prevent double submissions when they refresh the page.

10) APIs and endpoints where method and body must remain intact

Use: 307 (temporary) or 308 (permanent)

Why: APIs often rely on POST, PUT, PATCH. If a client changes method during redirect handling, you can break integrations.

11) Tracking links, short links, and destinations that change often

Use: 302 or 307 (often preferred over 301)

Why: If you use a permanent redirect, caching can reduce how often clients hit your redirect service, which can distort click tracking and make destination updates less reliable.

Summary table

Scenario	Recommended redirect	Key reason
Domain migration	301	Permanent replacement and consolidation
HTTPS enforcement	301	Canonical permanent version of the site
Maintenance mode	302 (or 307)	Temporary change with clean rollback
A/B testing	302	Avoids signalling permanent replacement
POST submit → confirmation page	303	Forces GET on next request and avoids resubmits
API endpoint moved	307 or 308	Preserves method and request body

Best practices: chains, loops, mapping, internal links

You can pick the correct status code and still mess up your SEO if your redirect implementation is sloppy. In real projects, the damage usually comes from bad mapping, redirect chains, and mixed signals across the site.

1) Map old URLs to the most relevant equivalent page

This is non-negotiable. Redirects work best when the destination page matches the original page’s intent.

Good mapping looks like this

• Old service page → new service page (same topic, same intent)
• Old blog post → new blog post URL (same content)
• Old category page → new category page (same product group)

Bad mapping looks like this

• Redirecting everything to the homepage
• Redirecting to a generic category page that does not answer the same query
• Redirecting to a page that is only loosely related because it is “close enough”

Blunt truth: if you redirect an old page with strong relevance and links to an irrelevant destination, you are trading relevance for convenience. Search engines can often tell. Users can definitely tell.

2) Avoid redirect chains. One hop should be the goal.

Redirect chains increase load time and waste crawl resources. They also create technical debt because when you change one rule later, you can break the entire chain.

What to do instead

• Make the old URL redirect directly to the final URL.
• Remove “middle” redirects created by CMS rules, trailing slash rules, or plugin conflicts.

Example

• Bad: /old → /new → /new/
• Better: /old → /new/

3) Prevent redirect loops

Loops break user access and block crawling. They often happen when multiple systems try to enforce rules at the same time.

Common loop causes

• HTTP → HTTPS rules conflicting with CDN or load balancer rules
• www → non-www rules conflicting with application-level routing
• Trailing slash rules conflicting with framework routing
• Old redirect rules left behind after a migration

Practical fix

• Centralise redirect logic as much as possible.
• Document your redirect rules so changes do not stack unpredictably.
• Test with header checks and crawling tools, not just your browser.

4) Update internal links to point to final destination URLs

Internal links should not rely on redirects. Redirects are for external traffic and legacy URLs. If your navigation and body links still point to redirected URLs, you are creating unnecessary hops and sending mixed signals.

What to update

• Main navigation and footer links
• In-content links inside blogs and resource pages
• Breadcrumb links
• Pagination and category links

5) Align canonical tags with your redirect intent

If a page permanently redirects to a destination, the destination should usually be canonical. If canonicals point somewhere else, you are telling search engines conflicting stories.

Common canonical mistakes during migrations

• Old pages still have canonicals pointing to themselves while redirecting elsewhere
• New pages still canonicalise to the old domain
• Template-level canonicals are not updated sitewide

6) Update XML sitemaps and feed Google the right URLs

Your sitemap should list the URLs you actually want indexed, not the URLs that redirect.

After a migration or restructure

• Generate a fresh sitemap of destination URLs
• Remove redirected URLs from the sitemap
• Resubmit in Google Search Console

7) Do not mix “temporary” redirects with permanent behaviour

If you use 302 or 307, treat it like a temporary measure. That means:

• Set a clear end date or review date
• Document why it is temporary
• Remove it when the temporary condition ends

If you know the change is permanent but you keep using 302 “just in case,” you are not being cautious. You are being indecisive, and that indecision creates SEO ambiguity.

8) Avoid redirecting to blocked or non-indexable destinations

This is a surprisingly common self-inflicted wound. If your destination URL is blocked by robots.txt, noindexed, or returns errors intermittently, your redirect is effectively sending bots into a wall.

Check for

• Destination returns 200 (not 404, not 5xx)
• Destination is indexable if you want it indexed
• Destination is not canonicalised away to something else unexpectedly

Best-practice checklist table

Campaign Component	Best Practice	Expected Impact
Redirect mapping	Map each old URL to the closest equivalent destination page	Stronger relevance retention and cleaner consolidation
Redirect chains	Keep redirects to one hop and remove outdated middle rules	Faster load times and improved crawl efficiency
Internal links	Update internal links to final URLs instead of relying on redirects	Fewer hops and stronger sitewide signal consistency
Sitemaps and canonicals	Ensure canonicals and sitemaps list the URLs you want indexed	Less ambiguity and more predictable indexing outcomes
Temporary redirect discipline	Set an end date and remove 302 or 307 when the temporary condition ends	Prevents accidental permanent indexing shifts

Testing and QA checklist

If you only test redirects by clicking a few pages in your browser, you are not testing redirects. You are guessing.

Browsers cache redirects, plugins interfere, CDNs rewrite rules, and one “it works for me” check does not tell you what Googlebot will see at scale.

Before launch: pre-migration testing

1) Validate the redirect list

• Confirm every important legacy URL has a mapped destination.
• Confirm there are no “catch-all to homepage” rules unless you have a very specific reason.
• Confirm the destination pages exist and return 200.

2) Check status codes and final destinations

• Old URLs should return the intended 3xx code (301, 302, 307, 308).
• Destination URLs should return 200 and load the correct content.
• There should be no accidental 302s caused by application logic or plugins.

3) Hunt redirect chains

• Identify URLs that redirect more than once.
• Fix chains by redirecting old URLs directly to the final URL.
• Pay special attention to trailing slash rules, uppercase rules, and HTTP to HTTPS enforcement. These frequently create extra hops.

4) Hunt redirect loops

• Test for “too many redirects” errors.
• Check CDNs, load balancers, and application routing rules for conflicting redirects.
• Verify that only one system is enforcing each canonical rule (HTTPS, www, slash behaviour).

5) Validate canonical tags and internal links

• Canonicals on destination pages should point to themselves (or the chosen canonical), not to old URLs.
• Navigation, footer, and internal links should point to final URLs, not redirected ones.
• Check template-level canonical settings so they are consistent across the site.

6) Validate XML sitemaps

• Sitemap should list only final destination URLs that you want indexed.
• Do not include redirected URLs in the sitemap.
• Ensure sitemap URLs return 200 and are indexable.

7) Check non-GET flows if relevant

If your site includes forms, logins, checkout flows, or API endpoints, test the critical paths.

• Form submissions should not break due to method switching.
• If you are redirecting POST flows temporarily, consider 307.
• If you are permanently moving an API endpoint, consider 308.

Launch day: live verification

1) Spot-check high-value pages

• Top landing pages by traffic
• Top converting pages
• Top linked pages (backlink targets)
• Key category and service pages

2) Verify server responses using tools, not feelings

• Use header checkers, crawling tools, and command-line checks where available.
• Test in a clean session (incognito) to reduce caching interference.

3) Confirm there are no surprise redirects

• Look for unexpected 302s caused by cookies, geolocation rules, or “maintenance mode” plugins.
• Look for CDN rules that override server rules.

After launch: monitoring and cleanup

1) Monitor Google Search Console

• Watch for spikes in 404s, soft 404s, and redirect errors.
• Review “Pages with redirect” to confirm the right pages are being redirected.
• Check indexing trends. If the wrong URLs stay indexed too long, investigate mixed signals.

2) Crawl the site and compare against your expectations

• Confirm redirect mapping is correct at scale.
• Identify and fix chains and loops that slipped through.
• Check for orphaned pages that are no longer linked internally.

3) Clean up temporary redirects

• List all 302 and 307 rules.
• Confirm each one is still needed.
• Remove or convert to permanent where appropriate.

QA checklist table

Campaign Component	Best Practice	Expected Impact
Status code validation	Verify 3xx codes and final URLs with header checks and crawls	Prevents wrong intent signals and indexing surprises
Chain and loop detection	Eliminate multi-hop redirects and resolve conflicting rules	Faster pages and fewer crawl failures
Signal alignment	Update internal links, canonicals, and sitemaps to final URLs	Cleaner consolidation and more predictable indexing
Post-launch monitoring	Track GSC errors and crawl results, then fix issues quickly	Reduces traffic loss during reindexing and stabilisation

FAQs

Do redirects hurt SEO?

Redirects are not inherently bad. What hurts SEO is using the wrong redirect for the situation, redirecting to irrelevant destinations, or creating chains and loops.

• If the change is permanent, use a permanent redirect and map pages properly.
• If the change is temporary, use a temporary redirect and remove it when the condition ends.
• Keep it one hop and align internal links, canonicals, and sitemaps with the final URLs.

Do 301 redirects “pass link equity” and rankings?

A 301 is the correct signal for a permanent move, and search engines generally consolidate signals to the destination over time. But do not treat that as a magic guarantee.

• Consolidation is cleaner when the destination is a true equivalent and your site signals are consistent.
• You can still lose performance if you redirect to irrelevant pages or create a messy chain of redirects.

Is 302 safer than 301 because it is temporary?

No. A 302 is only “safer” if the move is genuinely temporary.

If the change is permanent and you use 302 “just in case,” you are sending mixed intent. Over time, that can create unpredictable indexing behaviour and more work for you later.

How long can I keep a 302 in place?

There is no universal number that guarantees outcomes. The practical rule is simple: if you do not have a planned end date, it is not truly temporary.

If a redirect is intended to remain indefinitely, treat it as permanent and use 301 or 308.

When should I use 307 instead of 302?

Use 307 when you need a temporary redirect and you must preserve the HTTP method and request body.

• Forms, checkout, login flows
• Authenticated routes
• API endpoints that accept POST, PUT, PATCH

For normal page redirects where requests are GET, 302 is usually enough.

When should I use 308 instead of 301?

Use 308 when the move is permanent and you must preserve the HTTP method and request body. This is most relevant for APIs and non-GET workflows.

For typical SEO migrations where requests are GET, 301 is still the most common and simplest default.

Is 308 better for SEO because it is newer?

No. 308 is not an SEO upgrade. It exists to clarify method preservation. If you do not need method preservation, you are not gaining anything meaningful by switching from 301 to 308.

What redirect should I use for HTTP to HTTPS?

Use 301. This is a permanent canonicalisation change. Then update internal links and canonical tags to use HTTPS so you are not relying on redirects across your own site.

What redirect should I use for www vs non-www?

Use 301. Pick one canonical hostname and enforce it consistently.

Should I redirect deleted pages or let them 404?

Redirect only when there is a genuinely relevant replacement page. If there is no close equivalent, a 404 can be the correct outcome.

The worst option is redirecting everything to the homepage. That usually creates irrelevant user journeys and weak relevance signals.

Why does my browser still show the old redirect after I fixed it?

301 redirects are often cached aggressively by browsers. That means you can update the server and still see the previous behaviour in your browser session.

• Test in incognito mode.
• Use header checks and crawling tools to validate what the server is returning.
• Do not rely on a single browser test as your source of truth.

Should I use JavaScript or meta refresh redirects?

Server-side redirects are the cleanest and most reliable option in most cases. Client-side redirects can work, but they are generally less predictable for crawling and can be slower for users.

If you control the server, use proper 3xx redirects.

Conclusion

Redirects are not complicated, but they punish sloppy thinking.

If you treat every redirect as “just send the user somewhere,” you will eventually create a mess. Pages will load slower, crawling will get inefficient, and you will lose control of what gets indexed because your signals are inconsistent.

The practical rules to follow

• Match intent: permanent moves use 301 (or 308 if method preservation matters). Temporary moves use 302 (or 307 if method preservation matters).
• Use 303 for POST/Redirect/GET: when you want a POST submission to land on a GET confirmation page.
• Map like-for-like: redirect each old URL to the closest equivalent destination page. Do not dump everything to the homepage.
• Keep it one hop: remove redirect chains and avoid redirect loops.
• Align site signals: update internal links, canonical tags, and XML sitemaps to point to the final URLs you want indexed.
• Be disciplined with temporary redirects: if you do not have an end date, it is not temporary.
• Test properly: validate status codes, destinations, chains, loops, and non-GET flows before launch.

One last blunt reminder

If you choose a temporary redirect because you want to keep your options open, then leave it running indefinitely, you are not keeping options open. You are handing the decision to search engines and browser caches.

If you want expert help auditing your redirect setup as part of a migration or broader SEO strategy, work with an SEO agency that treats redirects as infrastructure, not an afterthought.

And if your issues go beyond redirects into crawlability, indexation, rendering, or site architecture, your redirects should be reviewed as part of proper technical SEO services.

Make the intent clear, implement it cleanly, and test it properly. That is how redirects stop being a recurring SEO problem and start being a stable part of your site infrastructure.