301 Redirects: How to Use Them Without Damaging SEO
TL:DR
- A 301 redirect permanently moves a page and passes its ranking signals to the new URL. A 302 signals a temporary move and doesn’t pass those signals across.
- Used correctly, a 301 protects your SEO. The damage comes from chains, wrong destinations or the wrong redirect type, not from the redirect itself.
- Set one up in a few minutes through .htaccess on Apache or a WordPress plugin.
- Keep 301 redirects in place indefinitely for pages that have permanently moved. Removing them early can strand links still pointing at the old URL.
- Avoid redirect chains (A to B to C). Each extra hop dilutes signal and slows the page down.
What Is a 301 Redirect?
A 301 redirect is a permanent, server-side instruction that tells browsers and search engines a page has moved to a new URL for good. The number itself comes from the HTTP status code; 301 stands for “Moved Permanently”, and it sits within the wider 3xx family of redirect codes that all tell a browser where to go next instead of showing the page it asked for.
Because a 301 signals permanence, search engines treat it as the strongest available cue to drop the old URL from their index and transfer its ranking signals, including backlinks and search equity, to the new one. Google’s own documentation on site moves confirms this is the recommended redirect type whenever a page or domain change is permanent, which is exactly why it’s the default choice for migrations, rebrands and URL restructures. Redirects like this sit within the broader discipline of technical SEO, the parts of optimisation concerned with how a site is built and crawled, rather than the content sitting on the page.
How a 301 Redirect Actually Works
The mechanism is simple, even though the result feels seamless to anyone browsing the site. Here’s what happens in the background:
1. A browser or search engine crawler requests the old URL, either because someone clicked a link or Googlebot is recrawling a known page.
2. The server checks its redirect rules, finds a match, and responds with a 301 status code instead of returning the page.
3. That response includes a Location header pointing to the new URL. This is the actual instruction, not the page content itself.
4. The browser follows it automatically and loads the new page. Users rarely notice the extra step happened at all.
5. Search engine crawlers do the same, but they also update their index: the old URL gets dropped in favour of the new one, and its ranking signals move across with it.
You can see this response for yourself with a browser’s developer tools (the Network tab) or by running curl -I against the old URL from a terminal. Both show the 301 status and the Location header directly, before any redirect actually completes.
301 vs 302: Why the Difference Matters
Not every redirect should be a 301. Picking the wrong type is one of the more common ways a redirect ends up working against you instead of protecting you.
| 301 Redirect | 302 Redirect | |
| Meaning | Moved Permanently | Found (temporary) |
| Use when | The move is permanent | The move is short-term |
| Old URL | Dropped from the index over time | Stays indexed |
| Ranking signals | Transfer to the new URL | Stay with the original URL |
Use a 302 for genuinely temporary situations, a site under maintenance, an A/B test, or a seasonal page you’ll bring back. Set one up as a 301 by mistake, and you risk permanently losing the original URL’s rankings for a change that was never meant to be permanent.
Canonical tags solve a different problem entirely. They’re for pages that both need to stay live, duplicate or near-duplicate content, not pages that have moved. If the old URL should disappear for good, that’s a 301. If both versions have a genuine reason to exist, that’s a canonical tag.
Use a 302 for genuinely temporary situations, a site under maintenance, an A/B test, or a seasonal page you’ll bring back. Set one up as a 301 by mistake, and you risk permanently losing the original URL’s rankings for a change that was never meant to be permanent.
Canonical tags solve a different problem entirely. They’re for pages that both need to stay live, duplicate or near-duplicate content, not pages that have moved. If the old URL should disappear for good, that’s a 301. If both versions have a genuine reason to exist, that’s a canonical tag.
Do 301 Redirects Damage SEO?
No, not on their own. A correctly implemented 301 redirect passes the large majority of a page’s ranking signal to its new URL. That’s the entire reason Google recommends it for permanent moves. If 301 redirects inherently damage SEO, no agency would ever recommend a site migration.
What actually happens: when a search engine crawls a 301 and confirms the move is genuine, it folds the old URL’s ranking signals, including backlinks, topical relevance and historical performance, into the new URL, then drops the old one from its index over time. This isn’t instant. Processing a redirect can take anywhere from a few days to several months depending on how often the page is crawled, so a temporary dip in visibility during that window is normal and not a sign anything has gone wrong.
This is also the answer to a related question worth naming directly: does a 301 redirect pass on link equity, sometimes still called “PageRank” or “link juice” from older SEO terminology? Yes, it does, and it’s the primary reason 301s exist as a tool. A backlink pointing at your old URL still counts for something once that URL redirects, provided the redirect is a single hop straight to the relevant new page.
Google’s own documentation on redirects is worth reading directly rather than taking a specific figure from any third party, including this guide. Wording and detail get updated periodically, so it’s worth checking the current version before you publish anything that quotes a precise number.
The damage people attribute to “301 redirects” almost always traces back to how they were implemented, not the redirect type itself:
- Redirecting to a page that isn’t a genuine match for the old content, rather than the closest equivalent
- Chaining redirects through multiple hops instead of pointing straight at the final destination
- Using a 301 for a move that was only ever meant to be temporary, so the original loses signal it should have kept
- Redirecting an entire site to a single URL, usually the homepage, during a migration instead of mapping pages individually
None of these is inherent to the 301 status code. They’re implementation choices, and each is avoidable with proper planning. The next section covers exactly how to avoid them.
The method depends on your platform, but two approaches cover the vast majority of businesses: editing .htaccess directly if you’re on Apache hosting, or using WordPress’s own tools if that’s your CMS. Both take minutes once you know where to look.
Using .htaccess (Apache)
If your site runs on Apache, .htaccess is usually the fastest route. For a single page, add a line like this:
Redirect 301 /old-page/ /new-page/
This works for a straightforward, one-to-one redirect. If you’re redirecting a pattern of URLs rather than a single page, for example an entire old blog category, a rewrite rule is more flexible:
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]
Place redirect rules near the top of the file, before any other rewrite rules that might intercept the request first, and always test the live URL immediately after saving. A rule further down the file can silently override the one you just added.
In WordPress
WordPress offers two options, depending on how comfortable you are with code.
The simplest route for most site owners is a redirect plugin. Redirection is the most widely used option, and it’s free. Install it, add the old and new URL, set the type to 301, and it’s live immediately with no code involved.
If you’d rather avoid adding a plugin, or you’re comfortable in the theme’s functions.php file, this achieves the same result:
add_action(‘template_redirect’, function() {
if (is_page(‘old-page’)) {
wp_redirect(home_url(‘/new-page/’), 301);
exit;
}
});
Either method works. The plugin is easier to manage at scale, especially if you’re tracking dozens of redirects from a migration, while the code method avoids adding another plugin to maintain.
Other Platforms at a Glance
| Platform | Where to do it |
| Shopify | Online Store > Navigation > URL Redirects |
| Squarespace | Settings > URL Mappings |
| Wix | SEO & GEO dashboard > Tools and settings > URL Redirect Manager |
| Nginx | Server block config, using a return 301 directive |
| Cloudflare | Rules > Redirect Rules (single) or Bulk Redirects (many at once) |
Common 301 Redirect Mistakes That Actually Hurt SEO
Every mistake below causes a specific, measurable problem, not just a vague sense that “redirects are risky”. Here’s what to watch for.
- Redirect chains and loops. A chain points to another redirect instead of the final URL (A to B to C), usually the leftover result of several migrations stacked without cleanup. A classic example: an old HTTP URL redirecting to HTTPS, which then redirects again to a new page. Each extra hop adds load time and dilutes the signal being passed. A loop, where a redirect eventually points back to its own starting URL, is worse: crawlers and browsers give up entirely, and the page becomes unreachable.
- Redirecting to a page that isn’t a genuine match. Sending an old page to your homepage instead of its closest equivalent is one of the most common shortcuts in a rushed migration. Search engines read the mismatch as a weak signal and, rather than transferring the old page’s rankings, often treat it closer to how they’d treat a 404.
- Using the wrong redirect type for the situation. A 302 left in place for a permanent change never fully consolidates. The original URL just sits in limbo indefinitely. A 301 used for a genuinely temporary change is worse to reverse: undoing it later can cause a real, visible dip while search engines re-evaluate both URLs.
- Leaving internal links pointing at the old URL. If your own navigation, related content links or sitemap still point to a redirected URL, every visitor and every crawler takes an unnecessary extra hop to reach the real destination. Update internal links to point directly to the new URL once the redirect is live. The redirect is a safety net for external links and old bookmarks, not a replacement for good housekeeping on your own site.
- Mass-redirecting during a migration instead of mapping page by page. Redirecting an entire old site to a single new URL is faster to set up, but it throws away the individual ranking signals and backlinks each old page earned on its own. This shows up most often when pruning or consolidating old content: it’s tempting to send everything you’re removing to one surviving page rather than finding a genuine match for each. A proper migration maps every old URL to its closest new equivalent, one-to-one.
Every one of these is a planning problem, not a redirect problem. Map your URLs before you move anything, and the SEO gets protected as a side effect.
How to Check Your Redirects Are Working
Checking a redirect properly means confirming the status code, not just landing on the right page. Browsers follow redirects automatically and silently, so a page that “looks right” can still be running on a 302, or through several unnecessary hops.
For a single URL, two quick options: open your browser’s developer tools, go to the Network tab, reload the old URL, and check the status code on the first request. Or run curl -I https://yoursite.com/old-page/ from a terminal. The response headers show the status code and the Location header directly, no clicking required.
For how Google specifically sees a redirect, use the URL Inspection tool in Search Console. It shows whether Google has crawled the redirect yet and which URL it currently considers canonical.
For checking redirects across an entire site, particularly after a migration, a crawler like Screaming Frog is the practical option. Point it at your full URL list, and it flags every redirect, chain, and any that resolve to a 404 or error instead of the intended page.
Where to Go From Here
A 301 redirect is one of the safest tools in SEO, provided it’s used with care. The redirect type itself was never the risk. Poor mapping, chains, and mismatched redirect types quietly cost sites their rankings. Plan the move properly, test what you’ve built, and a 301 protects the value your pages have already earned rather than threatening it.
If you’re about to migrate a site, restructure your URLs, or you’re just not confident your existing redirects are set up correctly, Mayfly’s SEO audit will show you exactly where you stand before anything goes live.
- What’s the difference between a 301 and a 302 redirect?
A 301 tells browsers and search engines the move is permanent, so ranking signals transfer to the new URL. A 302 redirects to a temporary location, so the original URL stays indexed and retains its signals.
- Do 301 redirects pass on link equity?
Yes, a correctly set up 301 passes the large majority of ranking signal to the destination. Long redirect chains can dilute this, which is why single-hop redirects are best practice.
- How long should I keep a 301 redirect in place?
Indefinitely, for pages that have permanently moved. Search engines can take weeks to months to fully process a redirect, and removing it early can strand any links or bookmarks still pointing at the old URL.
- Can too many redirects harm my site?
A handful of well-planned, single-hop redirects cause no issues. Long chains (A to B to C to D) slow page load and can cause search engines to stop following the chain altogether.
- Is a 301 redirect permanent, or can it be reversed?
It’s permanent in intent but technically reversible at any time. Reversing a long-standing one can cause a temporary dip while search engines re-crawl and re-evaluate both URLs.
- How do I add a 301 redirect in WordPress?
Through a redirect plugin, or by adding a rule to .htaccess if you’re on Apache hosting. Both reach the same result. The plugin route is just easier for non-developers.
- Why isn’t my 301 redirect working?
Usually a typo in the destination URL, browser or CDN caching still serving the old page, a conflicting rule earlier in .htaccess, or the redirect being set to 302 instead of 301.
