SEO Redirects: 301 vs 302, Chains, Loops, and the Rules That Rot

Redirects are the most boring part of technical SEO and one of the few that can quietly delete a site’s search visibility. They are also badly served by the usual advice, which stops at “use a 301” and never mentions the two things that actually cause damage in production: chains that accumulate one deploy at a time, and redirect rules that break long after the person who wrote them has moved on.

Google documents this territory in more detail than most people realise, including a ranking of redirect types by how reliably it can interpret them. That ranking is the useful part, and it is where this guide starts.

An SEO redirect is a server or client instruction that resolves one URL to another. Google treats permanent forms — chiefly HTTP 301 and 308 — as a signal that the target should become the canonical URL, and temporary forms — 302, 303, 307 — as an instruction to follow the redirect while continuing to show the source URL in search results.

Key takeaways

• Google ranks redirect types by reliability, not just by meaning. Its table is ordered by how likely Google is able to interpret correctly, with server-side redirects at the top and “crypto redirects” — a plain link saying you moved — at the bottom.
• The permanent/temporary choice is about which URL appears in results. Google’s framing: permanent redirects show the new redirect target in search results; temporary redirects show the source page.
• A chain costs one crawl request per hop, literally. The Crawl Stats documentation states that each request in the redirect chain is counted as a separate request, and the crawl budget guide asks you to avoid long chains outright.
• A meta refresh changes meaning at zero seconds. Google reads an instant meta refresh as permanent and a delayed one as temporary — a one-character difference with opposite canonical consequences.
• The old URL does not disappear, and that is intended. Google keeps both source and target, and the non-canonical one becomes an alternate name that may appear in search results when a query hints the user trusts it.

What Google actually does with each redirect type

Google’s redirect documentation contains a table most people have never read, and its ordering principle is the interesting bit. The types are listed “by how likely Google is able to interpret correctly,” with server-side redirects at the top because they have the highest chance of being read as intended.

Permanent — Googlebot follows the redirect, and the indexing pipeline treats it as a signal that the target should be canonical:

Type	Notes
HTTP 301 (moved permanently)	Server-side. The default choice.
HTTP 308 (moved permanently)	Server-side. Preserves the request method.
meta refresh at 0 seconds	Client-side. Only when server config is out of reach.
HTTP Refresh header at 0 seconds	The header equivalent of the above.
JavaScript location	Requires rendering before Google sees it.
Crypto redirect	A link saying “we moved”. Barely a redirect.

Temporary — Googlebot follows the redirect, but the indexing pipeline does not use it as a canonicalisation signal. Google adds a caveat worth keeping: “The target page might still be indexed if other canonicalization signals are present.”

Type	Notes
HTTP 302 (found)	The common temporary redirect.
HTTP 303 (see other)	Usually post-form navigation.
HTTP 307 (temporary redirect)	Preserves the request method.
meta refresh after more than 0 seconds	Delayed refresh reads as temporary.
HTTP Refresh after more than 0 seconds	As above.

Two practical readings of that ordering.

JavaScript redirects sit near the bottom for a reason. Google notes it interprets and executes JavaScript using the Web Rendering Service once crawling of the URL has completed — so a JavaScript redirect is only seen after rendering, on a deferred pass. Googlebot will get there. AI crawlers such as GPTBot, ClaudeBot and PerplexityBot do not render at all, so a JavaScript redirect is invisible to them; they see the source page and stop. If a URL matters for AI citation as well as for search, the redirect has to be in the HTTP response. The wider version of that constraint is in JavaScript SEO.

The crypto redirect is real, and Google is funny about it. If nothing else is possible, Google suggests simply linking to the new page with a short explanation, and says it “may understand this as a crypto redirect, (like the Loch Ness monster, its existence may be disputed; not all search engines may recognize this pseudo-redirect as an official redirect).” Treat it as the last resort it is described as.

301 vs 302: the question is which URL you want in the results

The usual framing — permanent means forever, temporary means for a while — is not wrong, but it is not the decision. Google’s own framing is about output:

Permanent redirects: Show the new redirect target in search results. Temporary redirects: Show the source page in search results.

Ask which URL you want people to land on from Google in three months, and the answer follows.

Use a permanent redirect (301 or 308) when the page has genuinely moved and you want the new URL to become the canonical one. Google’s recommendation is direct: if you need to change the URL of a page as it is shown in search results, use a permanent server-side redirect whenever possible.

Use a temporary redirect (302, 303, 307) when you want to keep the original URL in the index. Google’s own example is a service that is temporarily unavailable — send users to a page explaining what is happening, “without compromising the original URL in search results.”

The costly mistake is the second case done with a 301. Redirect a product URL to a category page while the product is out of stock, using a permanent redirect, and you have told Google the product page’s canonical is now the category page. It comes out of the index, and getting it back is slower than taking it out was. A temporary redirect is the correct tool and the one most CMS defaults do not reach for.

The mirror-image mistake is a permanent move served as a 302. Google will follow it but will not treat the target as canonical, so the old URL keeps showing in results and the new one competes with it. Migrations that “did not pass authority” often turn out to be this, and the diagnosis takes one curl.

One thing that will not go wrong, and that people worry about anyway: 301 versus 308 rarely matters for SEO. Both are permanent and both are read as canonicalisation signals; 308 preserves the request method, which matters for POST endpoints and almost never for content URLs.

What a redirect chain actually costs

“Avoid long redirect chains, which have a negative effect on crawling” is the whole of Google’s crawl budget guidance on the subject. The Crawl Stats documentation supplies the mechanism, and it is more concrete than the vague dilution story usually told:

“If a URL has a server-side redirect, each request in the redirect chain is counted as a separate request. So if page1 redirects to page2, which redirects to page3, if Google requests page1, you will see separate requests for page1 (returns 301/302), page2 (returns 301/302), and page3 (hopefully returns 200).”

So the cost is arithmetic. A three-hop chain spends three crawl requests to deliver one page. On a site with a handful of chains that is irrelevant. On a site large enough to have a crawl budget problem, where redirects accumulated over several migrations, it is a measurable share of everything Googlebot does — and the Crawl Stats report will show it, because redirect responses are grouped under file type “Other file type” rather than HTML.

Two related details from the same documentation. Client-side redirects are not counted in the report, so a chain that passes through a JavaScript hop will under-report. And Google lists “Redirect error” as its own bad response code, covering “too many redirects, empty redirect, or circular redirect” — the point at which Googlebot abandons the fetch entirely.

Chains are almost never authored. They accumulate:

1. /old-product → /products/old-product during a URL restructure.
2. /products/old-product → /shop/old-product when the shop moves.
3. /shop/old-product → /shop/new-product when the SKU is replaced.

Nobody wrote a three-hop rule. Three people each wrote one, months apart. The fix is to flatten rather than append: when adding a rule, rewrite every existing rule whose target is the URL you are now redirecting, so all of them point at the final destination. That is a five-minute discipline that never happens without a check enforcing it.

Loops, and the rules that rot

A redirect loop — A to B to A — takes a page out of the index and, unlike most SEO problems, does it immediately. Loops are usually produced by two rules that were each correct in isolation: a trailing-slash normaliser and a lowercase normaliser can loop on a mixed-case path with no slash; an HTTPS rule and a www rule can loop when they are evaluated in the wrong order behind a proxy that rewrites the protocol header.

Rarer and more damaging is the rule that quietly stops doing its job. Redirect configuration is one of the few parts of a site with no test coverage anywhere, and it decays in three specific ways:

• The target 404s. The destination page was renamed or deleted months after the rule was written. The rule still fires and now delivers a redirect to nothing.
• The rule chains into another rule. Someone added a second rule whose source is the first rule’s target. Two rules, each fine on its own, now form a chain.
• The rule shadows a real route. A broad pattern added for an old section starts matching a URL that later became a real page. The page is unreachable, and it is unreachable silently — the redirect works perfectly, which is the problem.

I gate all three in CI on this site. The build produces the routes, a script reads them alongside the redirect configuration, and the build fails on a dead internal link or a broken rule; a link that resolves only through a 301 is reported rather than fatal, because the hop is worth knowing about and not worth blocking a deploy for. Adding that check found rules that had been broken for months and had never appeared in any report, because nothing in Search Console tells you that a redirect rule’s target has since been deleted.

The general principle is worth more than my implementation: redirect rules are code, so treat them like code. They belong in version control, they need a test that runs on every deploy, and the test should read the built site rather than the source, because the failure mode is always a target that changed somewhere else.

Redirect, canonical, or 404?

Redirects get reached for in situations where they are the wrong instrument. The distinction Google draws is between telling a crawler a page moved and telling it a page is gone or duplicated.

Situation	Correct response	Why
Page permanently moved to a new URL	301 / 308	Transfers canonical status to the target
Page temporarily unavailable, URL should stay indexed	302 / 307	Google keeps showing the source URL
Page permanently deleted, no equivalent	404 or 410	A 404 is a strong signal not to crawl that URL again
Near-duplicate that should stay reachable	rel="canonical"	Consolidates without removing the page
Site moved to a new domain	301 across the board	Google’s primary documented use case
Page you do not want in the index but users need	noindex	A redirect would remove the page from users too

The row people get wrong is the third. Redirecting every deleted page to the homepage is a habit, and Google treats an irrelevant redirect target as a soft 404 — which means the URL keeps being crawled and keeps costing budget, instead of being retired by an honest 404. If a removed page has a genuine equivalent, redirect to that equivalent. If it does not, let it 404. The full decision framework between removing, consolidating and suppressing is in canonical vs noindex.

Why the old URL still shows up after a redirect

This one generates support tickets, and it is documented behaviour rather than a fault.

When you redirect a URL, Google keeps track of both the source and the target. One becomes the canonical, and the other becomes what Google calls an alternate name — “different versions of a canonical URL that users might recognize and trust more.” Google says alternate names “may appear in search results when a user’s query hints that they might trust the old URL more.”

Its guidance for a domain move is explicit and unusually reassuring: it is very likely Google will continue to occasionally show the old URLs even though the new ones are indexed, and “this is normal and as users get used to the new domain name, the alternate names will fade away without you doing anything.”

So an old URL appearing in results after a correctly implemented 301 is not evidence the redirect failed. Check the redirect returns 301 with the right target, then leave it alone. The rest of the migration checklist is in site migration.

Verifying redirects properly

Three checks, and the first two take seconds.

Follow the chain and count the hops. Do not use a browser — it hides everything interesting:

curl -sIL https://example.com/old-page | grep -iE "^HTTP|^location"

Every HTTP/… line is a hop. Two or more redirect lines before the 200 is a chain to flatten. curl also caps redirects, so a loop announces itself by exhausting the limit rather than by hanging.

Check the status code is the one you intended, not the one your platform defaulted to:

curl -sI https://example.com/old-page | head -1

CDNs, hosting platforms and CMS plugins all have opinions here, and a rule written as permanent in a config file can emerge as a 302 at the edge. The response is the only thing that counts.

Crawl the whole set after any migration. Individual checks miss the pattern, and the patterns are what hurt: a section where every URL gained a hop, a rule that matches more than it was meant to, a chain that only appears for URLs with query strings. Then keep the crawl — the value of the redirect map is that you can diff it after the next deploy.

Where this fits

Redirects sit between two adjacent decisions: whether a URL should exist at all, covered in canonical vs noindex, and what happens to the crawl requests they consume, covered in crawl budget. At scale they are a migration concern — site migration covers the sequencing — and the URL-level evidence of whether Googlebot is spending its time on redirect hops lives in log file analysis for SEO.

If you are planning a migration and would rather have the redirect map designed, tested and gated than discovered afterwards in a traffic chart, that is part of GEO and technical SEO consulting.

FAQ

What is the difference between a 301 and a 302 redirect for SEO?

Google’s distinction is about which URL appears in search results. A permanent redirect shows the new redirect target and is used by the indexing pipeline as a signal that the target should be canonical. A temporary redirect is followed, but “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical,” so the source URL keeps its place in the results. Use 301 when the move is real and you want the new URL to rank; use 302 when the original URL should stay indexed, such as during a temporary outage.

Do redirect chains hurt SEO?

Yes, and the cost is concrete rather than theoretical. Google’s crawl budget guidance asks you to avoid long chains, and the Crawl Stats documentation explains why: each request in the redirect chain is counted as a separate request, so a three-hop chain spends three crawl requests to deliver one page. Beyond a certain length Googlebot gives up entirely — Search Console reports that as a “Redirect error”, covering too many redirects, an empty redirect, or a circular one. Flatten chains by rewriting the earlier rules to point at the final destination.

How many redirects in a chain is too many?

Google does not publish a number, so treat one hop as the target rather than chasing a limit. Each additional hop costs a crawl request and adds latency for the user, and chains grow on their own as migrations stack up. The practical rule: whenever you add a redirect, update every existing rule whose target is the URL you are now redirecting, so no chain forms in the first place.

Should I use a redirect or a 404 for a deleted page?

Redirect only if there is a genuinely equivalent page. If there is not, return 404 or 410. Redirecting a deleted page to the homepage or a broad category is read as a soft 404, and Google notes that soft 404 pages continue to be crawled and waste your budget — whereas a 404 is “a strong signal not to crawl that URL again.” An honest 404 retires the URL; an irrelevant redirect keeps it alive as a cost.

Does a meta refresh work as a redirect for SEO?

It does, with a distinction that turns on the delay value. Google interprets an instant meta refresh — zero seconds — as a permanent redirect, and a delayed one as temporary. Both sit below server-side redirects in Google’s ordering of how reliably it can interpret them, so use a meta refresh only when server configuration genuinely is not available to you.

Will Google still show my old URL after a 301?

Sometimes, and it is documented behaviour rather than a failure. Google keeps track of both the redirect source and the target; the non-canonical one becomes an alternate name that “may appear in search results when a user’s query hints that they might trust the old URL more.” After a domain move Google says it is “very likely” to keep showing the old URLs occasionally, and that these will “fade away without you doing anything.” Verify the redirect returns the right status and target, then wait.

Do AI crawlers follow redirects?

They follow HTTP redirects, since those are resolved before any page content is processed. They do not follow JavaScript redirects, because GPTBot, ClaudeBot and PerplexityBot do not execute JavaScript — Google itself notes that it only interprets a JavaScript redirect after crawling completes, on a rendering pass those crawlers never run. If a URL matters for AI citation, the redirect must be in the HTTP response rather than in a script.