HTTP Redirects

TL;DR — A redirect sends anyone who requests an old URL to a new one instead. The most common kind is a 301 (“moved permanently”), which tells Google to move the old page’s ranking signals to the new URL. A 302 is “temporary.” Get the permanent-vs-temporary choice right and pick real server-level redirects over JavaScript ones, and you’ve covered 90% of what matters.

What a redirect is

HTTP redirects use 3xx responses and a Location field to direct a client to another URI. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection Google treats permanent redirects as strong canonical signals but does not guarantee destination indexing. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Redirects and Search

When a page moves, you don’t want visitors (or Google) to hit a dead end at the old address. A redirect is the instruction that forwards them to the new one automatically. Someone clicks the old link, and the server quietly hands them the new page instead.

Under the hood, a redirect is just a specific kind of server response: a status code in the 300s (most often 301 or 302) plus a Location header that says “here’s where to go instead.” You don’t have to think about that plumbing to use one — but it’s why redirects are reliable in a way that a “this page moved, click here” message isn’t.

The two that matter most

• 301 — Moved Permanently. Use this when the move is for good. It tells search engines the page has a new home, so the old page’s rankings and links transfer to the new URL. This is the one you’ll reach for most.
• 302 — Found (temporary). Use this when the move is only for now — a short campaign, an A/B test, a page you’ll put back. It tells Google not to move the ranking signals, because the change isn’t permanent.

There are a few more numbers (303, 307, 308), but for most sites the practical decision is just: is this move permanent (301) or temporary (302)?

How you set one up

• On your server — Apache’s .htaccess or an nginx config rule. The classic.
• Through a CMS plugin — on WordPress, a redirect plugin usually just edits that .htaccess file for you.
• At your CDN / edge — Cloudflare and similar let you set redirects before the request ever reaches your server.

Avoid JavaScript redirects (where a script sends the browser onward) when you can. Google can honor them, but only after it successfully renders the page — an extra step that sometimes fails — so they’re slower and less reliable than a real server redirect.

The thing people get wrong

A redirect is not the same as a canonical tag. Redirect when the old URL should stop existing and everyone should end up on the new one. Use a canonical tag when several URLs need to stay live but you want Google to treat one as the “main” version (think product pages with tracking parameters). Redirect = one URL survives; canonical = several survive, one is preferred.

Want the protocol-level detail, the full 301/302/303/307/308 rundown, how long to keep a redirect, and the chain/loop pitfalls? Switch to the Advanced tab.

TL;DR — A redirect is an HTTP response with a 3xx status code and a Location header — protocol first, SEO second. Google collapses the codes into two canonicalization buckets: permanent (301/308) = strong signal (signals consolidate forward), temporary (302/303/307) = weak signal (they usually stay put, but a long-lived temporary redirect can flip). Within each bucket, 307 and 308 preserve the HTTP method and body; 301 and 302 may not. Implement server-side, at the CDN/edge (my preference), or via a CMS plugin; JS and delayed meta-refresh redirects are weaker because they depend on rendering. A single good redirect doesn’t leak PageRank — the real risks are chains (avoid them) and loops (search engines just ignore them). Keep redirects for at least a year. And a redirect is not a canonical tag.

What a redirect actually is, at the protocol level

Redirect status codes have standardized method-handling semantics. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection Search guidance distinguishes permanent and temporary signals while recommending direct server-side redirects for moves. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Redirects and Search

Most SEO writing jumps straight to “301 means permanent” without ever saying what a redirect is. It’s worth grounding here, because the mechanism explains everything downstream. Per MDN, “redirection is triggered by a server sending a special redirect response to a request. Redirect responses have status codes that start with 3, and a Location header holding the URL to redirect to.”

So a redirect is two things travelling together: a 3xx status code (301, 302, 303, 307, 308…) and a Location header naming the destination. The browser or crawler reads that response and re-requests the URL in Location. The status code is the semantics — permanent or temporary, method-preserving or not — and the Location header is the address. Everything an SEO cares about is downstream of which 3xx code you send.

The SEO framing on top of that, as I put it in my 11 Types Of Redirects & Their SEO Impact piece at Ahrefs: “A redirect is a way to send people and bots to a new URL when they request the old URL, but the page has changed locations.”

Why redirects matter for SEO

Google’s redirects documentation frames the purpose plainly: “Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location.” The SEO consequence splits cleanly by permanence:

• Permanent redirects show the new target in search results.
• Temporary redirects keep the source page in search results.

And there’s a link-equity dimension. Google keeps track of both ends of a redirect: “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent.” Permanent redirects consolidate signals forward to the new URL; temporary ones usually leave them with the old one.

The redirect landscape: 301, 302, 303, 307, 308

Here’s the whole family at a summary level — each has its own deep dive in this subcluster (see “Where to go next”):

• 301 (Moved Permanently) — the workhorse permanent redirect. A strong canonicalization signal; ranking signals consolidate forward. In Google’s crawler docs: “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.”
• 302 (Found) — the standard temporary redirect. Google follows it “and Google systems use the redirect as a weak signal.” Weak, not zero — leave a 302 in place long enough and it can end up treated like a 301.
• 303 (See Other) — the outlier. It’s grouped with the temporary bucket, and it’s the code behind the Post/Redirect/Get pattern (send a form, get bounced to a results page with a GET). It’s rare in SEO, and its treatment is genuinely murky — as I’ve noted, 303s have an undefined treatment from Google and may behave like a 301 or a 302 depending on how they function.
• 307 (Temporary Redirect) — same SEO meaning as a 302, but it preserves the HTTP method and body. Google’s docs put it bluntly: 307 is “equivalent to 302.” You’ll also see 307s appear automatically on HTTPS sites that use HSTS.
• 308 (Permanent Redirect) — same SEO meaning as a 301, but it preserves the method and body. Google: 308 is “equivalent to 301.”

The method-preservation detail (307/308 keep the original method and body; 301/302 permit a client to change a POST to GET on the way through) doesn’t change how Google ranks anything, but it matters a lot if you’re redirecting form submissions or API calls. Google’s own guidance is not to pick carelessly: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (There’s a full side-by-side in the Cheat Sheets tab.)

How redirects affect crawling, indexing, and link equity

Two buckets, one distinction. Google’s redirect docs describe permanent redirects (301, 308, instant meta refresh, JS location) as a case where “the indexing pipeline uses the redirect as a signal that the redirect target should be canonical,” and temporary ones (302, 303, 307, delayed meta refresh) as a case where “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.”

The PageRank myth is dead. The old chestnut that redirects “lose 10-15% of link equity” hasn’t been true for years. Google’s Gary Illyes said in 2016 that “30x redirects don’t lose PageRank anymore,” and John Mueller noted it wasn’t even new information at the time. A single, correctly implemented redirect passes essentially all of a page’s signal value. The costs come from chains and loops, not from the existence of a redirect.

How long to keep a redirect. Google’s site-move guidance says to “keep the redirects for as long as possible, generally at least 1 year” so it can transfer all signals to the new URLs. Gary Illyes floated the idea that “after 1 y all signals had time to pass on from A to B.” I actually tested that: I removed 301 redirects from four Ahrefs posts that had older content redirected to them, and watched what happened. There was “a clear drop in referring domains after I did this,” but “not much drop in traffic to these posts.” My honest conclusion: “I’m not willing to conclusively say that permanent redirects pass value even after one year, but what Gary said seems to mostly hold true.” The safe default is still: don’t rip out old redirects casually.

Redirect chains and redirect loops

• A redirect chain is more than one hop between the requested URL and its final destination (Page 1 → Page 2 → Page 3). Google follows up to 10 redirect hops (“By default, Google’s crawlers follow up to 10 redirect hops”) — but its current site-move guidance says to avoid chains and, if one is unavoidable, keep it to no more than 3 and fewer than 5 hops. Ten is a crawler ceiling; 3-to-5 is practical guidance, not a conflicting limit. Chains add latency, waste crawl budget, and muddy analytics.
• A redirect loop is a chain that eats its own tail — a URL redirects to itself, or back to an earlier URL in the chain — so it never resolves. Browsers throw a “too many redirects” error; search engines simply give up. As John Mueller put it: “a redirect loop is a URL that doesn’t work, so it’s essentially a broken link. We ignore these for search.” Loops also trap crawlers and waste server resources.

There is also dated representative guidance behind the familiar five-hop number. In a 2014 webmaster hangout at 46:03, John Mueller described Googlebot following as many as five redirects in one crawl and, when more remained, continuing them on the next crawl. In 2020 he separately described Google as following up to five hops per crawl attempt. These historical statements help explain the number, but neither overrides the current documentation or guarantees that every long chain will be resumed on a particular schedule.

My independent practitioner observation is that Google often does pick longer chains back up, and I use about five hops as a fix-priority threshold. That’s an operational judgment from what I’ve seen, not a Google platform limit. The target when you control the redirects is still one direct hop.

Both have their own dedicated articles below.

How to implement redirects

There’s no single “right” place to put a redirect — pick what you can maintain:

• Server-side config. Apache .htaccess, nginx rules, or server-side scripts. The default for most sites, and the most reliable. On WordPress, “most WordPress installs will be running Apache and the plugins used for redirecting will actually be editing a website’s .htaccess file” — the plugin is just a friendlier front end.
• CDN / edge. Cloudflare rules, edge workers, and similar fire before the request reaches your origin. This is my own preference: “I typically prefer to have redirects on the edge (CDN-level) over having them on the server.” That said, for most people I “always recommend going with what is easiest for you to implement. For many people that is server-level redirects.”
• Client-side: meta refresh. A <meta http-equiv="refresh"> tag. An instant (0-second) meta refresh is read by Google as permanent; a delayed one as temporary. Slower and clumsier than a server redirect, but occasionally the only lever you have.
• Client-side: JavaScript. A script sets window.location. Google can honor it, but only if rendering succeeds — a separate, sometimes-failing pipeline step. Google’s own advice: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” My recommended order for permanent redirects reflects that reliability ladder: 308 / 301 → meta refresh 0 → JavaScript → crypto.

Redirect vs. canonical tag

These solve different problems and get conflated constantly.

• Redirect — use it when the old URL should stop resolving to its own content entirely. Only one URL should exist going forward. The old address forwards; it no longer serves a page of its own.
• Canonical tag — use it when several URLs must stay live and independently accessible, but you want Google to treat one as the preferred version. Think faceted-nav variants, tracking-parameter URLs, or print versions — all reachable, all pointing a rel=canonical at the main one.

Bing frames the same split cleanly in its December 2025 duplicate-content post: “Use 301 redirects to consolidate variants into a single preferred URL. Apply canonical tags when multiple versions must remain accessible.” If a canonical hint is being ignored and you truly want consolidation, you can escalate to a redirect — but only when that duplicate URL doesn’t need to keep serving its own content.

A note on Bing

Directionally, Bing agrees with Google: permanent moves get 301s, and temporary ones get 302s. Bing’s Fabrice Canel has said it’s “preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended,” and his colleague Frédéric Dubut clarified the “2 days” wasn’t a hard threshold — “anytime a redirect is temporary… you should use 302s.” Same mental model, just phrased around how soon the target might change.

Where to go next: the redirects subcluster

This hub is the map. Each topic below is its own deep dive, nested under this hub and listed in the sidebar:

The individual redirect codes

• 301 Redirect — the permanent workhorse: how it consolidates signals forward, and when to reach for it.
• 302 Redirect — the standard temporary redirect, why it’s a weak (not zero) signal, and how it can drift into 301 behavior.
• 303 Redirect (See Other) — the Post/Redirect/Get code, why it’s rare in SEO, and why its Google treatment is genuinely undefined.
• 307 Temporary Redirect — same SEO meaning as a 302, but it strictly preserves the HTTP method, and where it shows up (HSTS, form/API redirects).
• 308 Permanent Redirect — same SEO meaning as a 301, but it strictly preserves the HTTP method and body.

The head-to-head comparisons

• 301 vs. 302 Redirect — permanent vs. temporary, forward vs. backward signal consolidation, and which to use when.
• 301 vs. 308 Redirect — same SEO meaning, but 308 preserves the HTTP method and body.
• 302 vs. 307 Redirect — same story on the temporary side: identical for SEO, but 307 keeps the method and body for forms and APIs.

The client-side implementations

• JavaScript Redirects — why they’re the weakest option, how Google’s render pipeline treats them differently from a server-side 301, and when they’re an acceptable last resort.
• Meta Refresh Redirect — instant vs. delayed refreshes, why it sits between server-side and JavaScript in Google’s order of preference, and why it’s discouraged.

The pitfalls

• Redirect Chains — why to redirect straight to the final URL, the 10-hop limit, and how chains waste crawl budget.
• Redirect Loops — the never-resolving redirect, why search engines ignore it, and how to break the cycle.

In Google Search Console

• Page with Redirect — what this Page Indexing status means, why it’s normal and not an error, and the rare cases that need action.
• Redirect Error — Google’s four causes (chain too long, loop, max URL length, bad/empty URL), and how it differs from the normal “Page with redirect” status.

For the whole HTTP status-code picture this subcluster sits inside — the 2xx/3xx/4xx/5xx families and the codes beyond redirects — see the cluster index at /technical-seo/http-status-codes/.

AI summary

A condensed take on the Advanced version:

• A redirect = a 3xx status code + a Location header. The status code is the semantics (permanent/temporary, method-preserving or not); Location is the destination. Protocol first, SEO second.
• Two canonicalization buckets: permanent 301/308 = strong signal (signals consolidate forward to the new URL); temporary 302/303/307 = weak signal (signals usually stay with the old URL, but a long-lived temporary can flip).
• Within each bucket: 307/308 preserve the HTTP method and body; 301/302 may not. No ranking difference, but it matters for forms and APIs.
• 303 is the outlier — the Post/Redirect/Get code, rare in SEO, with genuinely undefined Google treatment.
• PageRank myth is dead: a single correct redirect doesn’t leak equity (Illyes, 2016). Costs come from chains (Google follows up to 10 hops but says avoid them) and loops (search engines ignore them as broken links).
• Keep redirects ≥ 1 year. Patrick’s own test of removing year-old 301s showed a drop in referring domains but little traffic loss — “mostly holds true,” so don’t remove casually.
• Implement server-side (.htaccess/nginx), at the CDN/edge (Patrick’s preference), or via a CMS plugin (which usually just edits .htaccess). JS and delayed meta-refresh are weaker because they depend on rendering.
• Redirect ≠ canonical: redirect when only one URL should exist going forward; canonicalize when several stay live but one is preferred.

Official documentation

Primary-source documentation on redirects.

Google

• Redirects and Google Search — the canonical doc: permanent vs. temporary framing, the redirect-type tables (301/308/302/303/307, meta refresh, JS, crypto), and the alternate-URL / link-equity concept.
• How HTTP Status Codes Affect Google’s Crawlers — 3xx behavior, the 10-hop follow limit, and 301/302/307/308 crawler treatment.
• Move a site with URL changes — avoid chaining redirects, and “keep the redirects… generally at least 1 year.”
• Consolidate duplicate URLs — why a canonical preference is “a hint, not a rule,” and how it interacts with redirects.
• Search Off the Record — Google’s Search Relations team has an episode on redirect types (301 vs. 302, what 307/308 are for, domain merges).

Bing / Microsoft

• Does Duplicate Content Hurt SEO and AI Search Visibility? — Fabrice Canel & Krishna Madhavan on using 301s to consolidate variants vs. canonical tags when versions must stay live.

Technical reference

• Redirections in HTTP — MDN’s protocol-level definition (3xx status + Location header) and per-code method/body handling.

Quotes from the source

On-the-record statements from Google, Bing, and MDN. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what redirects are for, and permanent vs. temporary

• “Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location.” — Google Search Central docs. Jump to quote
• “we recommend that you use a permanent server-side redirect whenever possible.” Jump to quote
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL).” Jump to quote
• “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” Jump to quote

Google — crawler treatment of the codes

• “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (301) Jump to quote
• “Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (302) Jump to quote
• “While Google treats these status codes the same way, keep in mind that they’re semantically different.” (307 ≈ 302, 308 ≈ 301) Jump to quote
• “By default, Google’s crawlers follow up to 10 redirect hops.” Jump to quote

Google — chains, and how long to keep redirects

• “Avoid chaining redirects.” Jump to quote
• “ideally no more than 3 and fewer than 5.” Jump to quote
• “Keep the redirects for as long as possible, generally at least 1 year.” Jump to quote

John Mueller, Google — dated five-hop statements

• In a 2014 webmaster hangout, Mueller described Googlebot following up to five redirects in one crawl and continuing any remainder on the next crawl. Watch from 46:03
• “up to 5 hops in the chain per crawl attempt” (2020 Reddit comment, relayed via Search Engine Journal.) Read the coverage

John Mueller, Google — redirect loops

• “In general, a redirect loop is a URL that doesn’t work, so it’s essentially a broken link. We ignore these for search.” Jump to quote

Fabrice Canel, Microsoft Bing — 301 vs. 302 timing

• “When the future is uncertain… preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended.” Jump to quote

MDN — the protocol-level definition

• “redirection is triggered by a server sending a special redirect response to a request. Redirect responses have status codes that start with 3, and a Location header holding the URL to redirect to.” Read the doc

Redirect implementation checklist

Before and after you put a redirect live:

• Right code for the situation — permanent move → 301/308; temporary → 302/307; preserving a form POST → 307/308.
• Redirect to the closest-matching URL, not a blanket redirect of everything to the homepage (that reads as a soft 404 to Google).
• Straight to the final destination — no chain. Update the source rule whenever a target itself later moves.
• No loops — confirm the target doesn’t redirect back into the chain (curl -IL the old URL and read the whole hop sequence).
• Server-level or edge, not JavaScript, wherever possible.
• Standardize the obvious variants — www vs. non-www, HTTP vs. HTTPS, trailing-slash, and letter case — to one canonical form.
• Update internal links to point at the new URL directly, so you’re not relying on the redirect for your own navigation.
• Keep it in place ≥ 1 year (Google’s guidance) — longer for high-value pages; don’t remove old redirects casually.
• Keep a rollback path — note the prior target (or the old page’s own content, if it’s being retired) before you flip the redirect live, so a bad destination or unexpected drop can be reverted quickly.
• Verify after deploy — check the status code and final destination with curl -IL, a browser’s Network tab, or a site crawler; watch for chains and loops in bulk. -I sends a HEAD request — if you suspect the server handles HEAD and GET differently, re-check with a plain curl -L (which uses GET) or your crawler’s GET-based mode.

The redirect types, side by side

The five 3xx redirect codes at a glance

The two things that actually decide it

• Permanent vs. temporary → determines the canonicalization signal (strong vs. weak) and whether search shows the new or old URL.
• Method preserved or not → 307/308 keep the original method and body; 301/302 permit a client to swap a POST for a GET on the way through (a compatibility carryover for older clients, per the Fetch Standard); 303 always forces GET. Irrelevant to ranking, critical for forms and APIs — use 307/308 when the method and body must survive the hop.

Implementation methods, strongest to weakest (permanent)

Fast facts

• A single correct redirect doesn’t lose PageRank (Illyes, 2016).
• Google documents a 10-hop ceiling, but recommends no more than 3 and fewer than 5 when a chain can’t be avoided.
• Mueller’s 2014 and 2020 comments describe about five hops per crawl; the 2014 comment also described continuing the rest later. Treat both as dated representative statements, not a current scheduling guarantee.
• Keep redirects ≥ 1 year.
• 307 ≈ 302, 308 ≈ 301 for Google — the difference is method preservation.
• Redirect = only one URL survives; canonical tag = several survive, one is preferred.

Resources worth your time

My writing

• 11 Types Of Redirects & Their SEO Impact — my full deep dive on every redirect type (301, 302, 303, 307, 308, meta refresh, JS, crypto, chains, loops), the piece this hub condenses.
• HTTP Status Codes & Their SEO Impact — where redirects fit in the whole 1xx–5xx status-code picture.
• Is It OK to Remove 301 Redirects After a Year? We Tested It — my controlled test of pulling year-old redirects (referring domains dropped; traffic mostly held).
• 301 vs. 302 Redirects for SEO: Which Should You Use? — the head-to-head, featuring my experiment where a 302 caused Google to drop the old domain for the new one.
• A Website Migration Takes More Than A Checklist To Be Successful — redirects in the context of a full site move.

From around the industry

• Redirects and Google Search (Google) — the canonical doc behind most of this hub’s claims.
• How HTTP Status Codes Affect Google’s Crawlers (Google) — 3xx crawler treatment and the 10-hop limit.
• Does Duplicate Content Hurt SEO and AI Search Visibility? (Bing) — the current on-the-record Microsoft take on redirects vs. canonical tags.
• Redirections in HTTP (MDN) — the protocol-level reference for 3xx codes and method/body handling.
• Google: No PageRank dilution when using 301, 302, or 30x redirects anymore (Search Engine Land) — the origin of the PageRank myth-correction.
• Google Search Ignores Redirect Loops (Search Engine Roundtable) — the Mueller “essentially a broken link” quote on loops.
• Bing: Use 302s For URLs That May Change In Two Days, Otherwise Go 301 (Search Engine Roundtable) — Fabrice Canel’s 301-vs-302 timing guidance.
• The redirects guide for SEO (Conductor Academy) — a solid competitor overview of the redirect landscape.

Redirect or canonical? Use the survival test

The two signals can point toward the same preferred URL, but they solve different problems.

Redirect when the source URL should stop serving its own content

Choose a server-side redirect when users and crawlers requesting the old URL should be sent somewhere else. Use a permanent code (301 or 308) for a lasting move and a temporary code (302, 303, or 307) when the source is expected to return.

Typical cases: a changed URL, merged page, HTTP-to-HTTPS move, or domain migration. The destination must be a genuine equivalent; mass-redirecting unrelated old URLs to the homepage can be treated as a soft 404.

Canonicalize when multiple URLs must remain accessible

Choose rel="canonical" when duplicate or near-duplicate variants still need to return their own 200 responses, but one URL should be treated as preferred for indexing. A canonical is a hint, not navigation: users remain on the requested URL. It’s also a hint to Google, not a rule — Google says “indicating a canonical preference is a hint, not a rule,” and it may choose a different page as canonical based on other signals.

Typical cases: useful sort/filter variants, syndicated or parameterized versions, or duplicates that cannot be removed yet.

No relevant replacement exists

Don’t force a redirect onto an unrelated page just to have somewhere to send the old URL — a catch-all or homepage redirect for content with no real successor reads as a soft 404 to Google. If there’s no genuine equivalent, that’s a signal to leave the decision to a deliberate 404/410 rather than invent a destination.

Do not send conflicting instructions

If URL A redirects to B, B should not canonicalize back to A. Keep internal links and sitemaps aligned with the surviving destination. The framework is simple: one URL survives → redirect; several must stay live → canonical.

Prompt: audit a redirect map for weak destinations

Paste a redirect-map CSV with old URL, proposed destination, reason, old title or topic, destination title or topic, intended permanence, and traffic/link signals if available.

Review this proposed redirect map for relevance and implementation risk.

For each row:
1. Classify the destination as strong equivalent, plausible but needs review,
   irrelevant/catch-all, self-redirect, chain risk, loop risk, missing destination,
   or insufficient evidence.
2. Explain the classification using only the supplied old/destination topics and
   URL evidence.
3. Flag many-to-one mappings to a homepage or broad category for manual review.
4. Check whether the intended permanence matches the proposed 3xx code when a code
   column is present.
5. Do not invent a replacement URL. If no equivalent is supplied, recommend manual
   mapping or an intentional 404/410 decision.

Return a table with old URL, destination, verdict, evidence, recommended action, and
priority. End with a summary of repeated rule patterns that could create chains or
loops.

DATA:
[PASTE REDIRECT MAP HERE]

Human-review every content-equivalence judgment before deploying the map.

Tools for planning and verifying redirects

• Redirect Checker — quickly verify the final status, every hop, and destination for a URL or small batch after deployment.
• Redirect Chain Mapper — diagnose multi-hop paths, see what changes at each hop, and export flattened cleanup rules for common server platforms.
• Bulk HTTP Status Code Checker — validate a larger redirect inventory, filter temporary or multi-hop results, and export evidence.
• Redirect Map Builder — plan old-to-new mappings, keep unmatched URLs and a 410 kill-list explicit, and export platform-oriented rules. Its suggestions still require content-equivalence review.
• Browser DevTools → Network — verify the document response’s 3xx code and Location header while reproducing browser-specific behavior.

Test yourself: HTTP Redirects

Five quick questions on how redirects work and how search engines treat them. Pick an answer for each, then check.

Redirect

A redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't.

Related: 301 redirect, 302 redirect, Redirect chain

Redirect

A redirect, broadly, is anything that automatically sends a visitor from a requested URL to a different one. An HTTP redirect is the specific mechanism where the server’s response has a status code starting with 3 (a “3xx” response) paired with a Location header naming the URL to go to instead — the browser or crawler re-requests the URL in that header. As MDN puts it, redirection “is triggered by a server sending a special redirect response to a request.” Meta refresh tags and JavaScript window.location changes also redirect visitors, but neither is itself a 3xx response — the source page still returns a normal 200, and something in that page’s content does the redirecting instead.

In SEO terms, a redirect is how you send people and bots to a new URL when the old one has moved. Google’s Search documentation tells the two families apart by whether they count as a canonicalization signal:

• Permanent — 301 and 308. Google treats these as a signal the target should be canonical, so ranking signals like links consolidate forward to the new URL.
• Temporary — 302, 303, and 307. Google doesn’t use these as a canonical signal, so signals usually stay with the original URL — though other canonicalization signals can still get the target indexed, and a long-lived temporary redirect can eventually be treated like a permanent one.

The difference between the codes within each bucket (301 vs. 308, 302 vs. 307) is whether the original HTTP method and request body are preserved — which matters for forms and APIs, not for Google’s indexing. 301 and 302 carry a historical RFC 9110 allowance to change a POST to GET; 307 and 308 must preserve the method.

A redirect is distinct from a canonical tag: a redirect is for when only one URL should exist going forward (the old one stops resolving to its own content); a canonical tag is a hint for duplicate or near-duplicate pages that all stay live at their own URLs.

Related: 301 redirect, 302 redirect, Redirect chain

Changelog