Dispatch
What Is a 301 Redirect and When Should You Use One
A 301 redirect is a server response that tells a browser or crawler a page has moved permanently to a new URL, and that future requests should go to the...
On this page
A 301 redirect is a server response that tells a browser or crawler a page has moved permanently to a new URL, and that future requests should go to the new location. The “301” refers to the HTTP status code returned by the server; everything else, the browser jumping to the new page, a search engine updating which URL it shows in results, happens because that status code carries a specific, well-defined meaning that both browsers and crawlers are built to respect.
It’s one of the most basic tools in technical SEO, and also one of the most frequently misunderstood, mostly because of outdated assumptions about how much “value” a redirect loses in transit. That part is worth clearing up first.
Does a 301 Redirect Lose Ranking Value?
For years, conventional SEO wisdom held that redirecting a URL caused some unavoidable loss of ranking power, sometimes described in terms of PageRank “dilution.” That belief largely dates to older, less precise statements from Google about how redirects were handled. Google has since walked that back directly. In a widely reported July 2016 tweet, Google’s Gary Illyes stated that 301 (and other 3xx) redirects no longer cause any PageRank loss, a clarification that Search Engine Land covered in detail at the time. Google’s John Mueller has separately and repeatedly made a related point in public Q&As: a redirect should generally be left in place for a long time (Google has suggested keeping them in place for at least a year, and often longer, as covered by Search Engine Journal), partly because Google needs time to process the change, and partly because real users still arrive at the old URL through old bookmarks, external links, and stale search results long after a migration.
The practical implication: a properly implemented 301 redirect, done once, set up correctly, and left in place, is not a meaningful tax on your rankings. The risks come from poor implementation, not from the redirect mechanism itself.
301 vs. 302 vs. Other Redirect Types
The status code you choose communicates intent, and search engines treat that intent differently. Google’s own Redirects and Google Search documentation lays out the distinction plainly: permanent redirects (301, 308) are expected to show the new target URL in search results, while temporary redirects (302, 307) are expected to keep showing the original URL, because Google assumes the redirect won’t last.
| Status code | Type | When to use it |
|---|---|---|
| 301 | Permanent, method may change | The page has moved for good; this is the default choice for migrations and consolidations |
| 302 | Temporary | A short-lived redirect, for example during planned maintenance or A/B testing, where the original URL should keep being indexed |
| 307 | Temporary, preserves HTTP method | Like 302, but guarantees the request method (e.g., a POST) isn't changed in transit |
| 308 | Permanent, preserves HTTP method | Like 301, but guarantees the request method isn't changed |
Getting this choice wrong has a real cost: using a 302 for what is actually a permanent move can leave Google continuing to index and show the old URL indefinitely, since you’ve told it the change is temporary. If a move is permanent, use a 301 (or 308 if method preservation matters), not a 302.
Server-Side Redirects vs. Client-Side Alternatives
A server-side redirect happens before the page content is ever sent to the browser: the server itself returns the 301 status code along with the new location, and the browser (or crawler) acts on it immediately. This is what Google’s documentation describes as the most reliable method, because it requires no JavaScript execution and no rendering step to be understood.
Client-side alternatives, a meta refresh tag in the page’s <head>, or a JavaScript-driven redirect, work differently. The original page has to load first, and only then does the redirect trigger. Google’s redirect documentation explicitly ranks these as less reliable than server-side redirects, since they depend on the page being fully fetched and, in the case of JavaScript redirects, rendered before the crawler can determine where the content actually lives. They aren’t unusable; Google can follow JavaScript redirects in many cases, but they introduce an extra layer of dependency that a server-side 301 simply doesn’t have. For anything that matters for SEO (a real page move, a consolidation, a permanent URL change), a server-side redirect is the more dependable choice.
Redirect Chains and Loops
A redirect chain happens when URL A redirects to URL B, which itself redirects to URL C, and so on, instead of A redirecting directly to the final destination. Each additional hop adds an extra round trip the browser or crawler has to follow before reaching the final page, which adds latency and, in longer chains, increases the risk that a crawler gives up before reaching the end. There’s no need to invent a precise millisecond figure to make the point: more hops simply means more network round trips and more opportunity for something in the chain to break.
A redirect loop is the more serious version of the same problem: A redirects to B, B redirects back to A, with no terminal destination at all. Browsers will eventually stop following a loop and show an error; crawlers will also abandon it, which means the content effectively becomes unreachable and unindexable. Both chains and loops are worth fixing by pointing every redirect directly at its true final destination rather than letting hops accumulate over successive migrations.
Common, Legitimate Uses for a 301
- Site migrations. Moving to a new domain, switching from HTTP to HTTPS, or changing subdomains all require redirecting every old URL to its corresponding new URL. Google’s Site Moves and Migrations documentation covers this scenario specifically and recommends mapping old URLs to new ones as precisely as possible, rather than redirecting everything to a single homepage or category page.
- URL structure changes. Restructuring how URLs are formed (adding or removing categories, changing slugs, switching CMS platforms) requires the same one-to-one mapping discipline.
- Consolidating duplicate or overlapping content. When two pages cover the same topic and one is merged into the other, redirecting the removed URL to the surviving one passes both users and accumulated signal to the consolidated page.
- Deprecated or discontinued pages. A product that’s been discontinued, an outdated piece of content that’s been replaced, these are reasonable candidates for a 301 to the most relevant current page, rather than leaving visitors at a dead end.
What 301s should not be used for: redirecting many unrelated old URLs to a single generic page (like the homepage) just to avoid 404s. That pattern, sometimes called a “soft 404 via redirect,” doesn’t genuinely serve the user who was looking for specific content, and Google has been clear that mass irrelevant redirects don’t behave like legitimate one-to-one moves.
Auditing Redirects at Scale
On a small site, checking a handful of redirects by hand (using a browser’s network inspector, or a command-line tool like curl -I to see the returned status code) is sufficient. On a larger site, especially after a migration, a full crawl is the only realistic way to catch every chain, loop, or wrong-status-code redirect across potentially thousands of URLs. A crawler like Screaming Frog’s SEO Spider can map an entire site’s redirect paths in one pass, flagging chains, loops, and redirects that return the wrong status code for their intended use. Google Search Console is also useful after the fact: its Page indexing report (the report formerly known as the Index Coverage report) shows whether Google has actually picked up on a redirect and updated which URL it considers canonical, which is the clearest confirmation that a migration has fully taken effect from Google’s side.
The Practical Takeaway
A 301 redirect, implemented server-side, pointed directly at its true final destination, and left in place long-term, is a low-risk, well-understood tool. The outdated fear of major ranking loss from redirecting isn’t supported by Google’s current guidance. The things that actually cause problems are avoidable: using a temporary status code for a permanent move, letting redirect chains accumulate across successive migrations, relying on client-side redirects where a server-side one would be more reliable, or mass-redirecting unrelated pages to a single catch-all destination instead of mapping URLs one to one. If you’re about to run a migration, build the old-URL-to-new-URL map first, as a literal spreadsheet, before a single redirect rule gets written, every failure mode above traces back to skipping that step.