A 301 redirect is a server response telling browsers and search engines that a page has moved permanently to a new address. The visitor lands on the new URL without noticing, and search engines transfer their understanding of the old page, including its ranking signals, to the new one. It is the correct tool whenever a URL changes and you want to keep what that URL had earned.
Redirects are the difference between a site restructure that preserves years of accumulated search equity and one that throws it away. They are also among the easiest things to get subtly wrong, in ways that only surface as a traffic decline weeks later.
A correction worth making
You will still read that a 301 redirect “passes 90 to 99 percent of link equity,” or that it loses 15 percent. That was reasonable inference from the original PageRank paper years ago, and it is no longer accurate. Google has stated since 2016 that no PageRank is lost through 3xx redirects.
This matters practically, because the myth leads people to avoid redirects they should use, or to fear that consolidating pages will cost them. It will not. What does cost you is redirecting to something irrelevant, chaining redirects together, or removing them later.
301 and the other redirect codes
301 Moved Permanently. The move is permanent. Search engines update their index to the new URL and eventually drop the old one. Browsers cache it aggressively, which is worth knowing because a mistaken 301 can be stubborn to undo in a browser that has already cached it.
302 Found and 307 Temporary Redirect. The move is temporary. Search engines keep the original URL indexed and do not transfer signals. Correct for maintenance pages, A/B tests, and genuine short-term diversions. Wrong for anything permanent, and a 302 left in place where a 301 belonged is a common cause of a page never quite ranking.
308 Permanent Redirect. Like a 301 but preserves the HTTP method, which matters for form submissions and APIs rather than ordinary page moves.
Meta refresh and JavaScript redirects are worse options in every respect: slower, less reliably understood, and unnecessary when a server redirect is available.
When to use one
URL changes. Any time a slug, path or structure changes, old to new, one to one.
Site migrations. New domain, new platform, HTTP to HTTPS. This is where redirects are most consequential and most often rushed. See website migration.
Consolidating pages. When several thin pages merge into one strong one, redirect the retired URLs to the survivor. The content audit that identifies the overlap should produce the redirect map alongside it.
Retiring services or products. Send the old URL to the closest relevant replacement.
Fixing duplicate access paths, such as www and non-www, or trailing-slash variants, so one canonical form is served.
Where redirects go wrong
Redirect chains. Old URL to a second URL to a third. Each hop adds latency for visitors and crawl cost for search engines, and Google gives up after a limited number of hops. When you add a new redirect, update the existing ones to point straight at the final destination rather than stacking another link on the chain. On a site that has been restructured more than once, chain cleanup is often the single largest available technical win.
Redirect loops. A points to B, B points back to A. The page becomes unreachable entirely.
Everything to the homepage. The most common mistake and the most damaging. If the destination is not a genuine equivalent of the old page, Google treats it as a soft 404, transfers nothing, and the visitor who clicked a specific link is dumped somewhere unhelpful. If there is no relevant replacement, letting the URL return 404 or 410 is the honest and more useful answer.
Redirecting in bulk without mapping. A migration needs a real old-to-new map, built page by page for anything that had traffic or links.
Internal links left pointing at redirected URLs. The redirect works, but every internal link routes through an unnecessary hop. Update the links to the final destination; the redirect is there for external links and bookmarks you cannot change.
Removing redirects too soon. External links and bookmarks persist for years. Google has said to keep redirects in place for at least a year, and there is rarely a good reason to remove them at all.
Where to implement them
Redirects can live at the server or platform level, or inside WordPress via a plugin. The distinction matters more than it looks.
Server or platform level (nginx or Apache rules, or your host’s redirect interface, such as WP Engine’s) is resolved before WordPress loads. It is faster, survives plugin changes, and does not consume PHP on every redirected request. This is where redirects belong once they are settled.
Plugin level (Redirection and similar) is convenient, gives editors a UI, and logs 404s usefully, which makes it good for discovering what needs redirecting. The cost is that every redirect boots WordPress first, and a site accumulating thousands of plugin-managed redirects pays for that on every hit.
A practical pattern: use a plugin or a theme-level rules file to move quickly while a restructure is in flight, then migrate the settled rules to the host platform. That is how we handle it on our own site, where interim rules live in the theme with a note to move them to WP Engine once stable.
Checking they work
Test the status code, not the browser. A page that visibly lands in the right place may have arrived via a 302 or a chain. Use a redirect checker or a command-line request that shows every hop.
Crawl the site with a tool such as Screaming Frog to find chains, loops, and internal links pointing at redirected URLs.
Watch Search Console after a migration for a rise in “Page with redirect” and for 404s on URLs that should have been mapped.
Check the old URLs specifically, the ones with traffic and links, rather than assuming a pattern rule caught everything.
One caution from experience: verify what is served at the exact URL, with no query string appended. Caching layers can serve a stale copy at the bare URL while every test with a parameter looks correct, which is the same failure mode that once hid a stale sitemap on our own site.
Where this fits
Redirect mapping and chain cleanup are part of our technical SEO services, and they are the highest-stakes element of any migration or restructure. Redirects also interact closely with canonical tags and indexability, since all three tell search engines which URL is the real one. If you are planning a restructure, or traffic dropped after one, book a discovery call.
