Most guides on how to set up 301 redirects hand you a line of Apache config and call it done. That line is maybe 10% of the job. The reason migrations go wrong isn’t a typo in a RewriteRule — it’s a redirect map that points old URLs at the wrong destinations, chains that leak link equity, and a launch that nobody tested against real HTTP requests. The config is the easy part. The thinking is where rankings are won or lost. This guide walks the whole chain: what a 301 actually does under the hood, when to use one versus a 302 or a canonical, how to build the map, the exact platform rules, and the mistakes that quietly erase a quarter of your traffic.
What a 301 redirect actually does
Before you learn how to set up 301 redirects, it helps to know exactly what one does. A 301 is an HTTP status code — “Moved Permanently” — that your server returns before it ever sends a page. When Googlebot or a browser requests the old URL, the server responds with 301 plus a Location header pointing at the new URL. The client then requests that new URL, which should return 200 OK. Two mechanisms matter for SEO. First, Google eventually drops the old URL from its index and consolidates the ranking signals — links, historical authority, relevance — onto the new one. Second, that consolidation is near-total but not instant: Google has to recrawl the old URL, see the 301, then recrawl and reprocess the target. On a small site that takes days; on a large one it takes weeks. Understanding this is why patience beats panic when traffic dips post-launch.
301 vs 302 vs 307 vs canonical: pick the right tool
Reaching for a 301 by reflex is the second most common mistake after a bad map. Each redirect type sends a different signal, and using the wrong one either fails to move equity or moves it when you didn’t want to.
- 301 (permanent) — the move is forever. Use it for retired pages, domain migrations, HTTP-to-HTTPS, and consolidating duplicates. This is the only type that reliably consolidates ranking signals long-term.
- 302 / 307 (temporary) — the original URL is coming back. Use it for A/B tests, geo-routing, a page down for maintenance, or a seasonal promo. Google keeps the original URL indexed. Use a 302 as a staging tool, then switch to 301 once the move is confirmed permanent.
- Canonical tag — not a redirect at all. Both URLs stay live and reachable, but you tell Google which one to index. Use it when you genuinely need both pages (a printer-friendly version, parameter variants) but only one should rank.
- Meta refresh / JavaScript redirect — avoid for SEO. Slow, unreliably interpreted, and a red flag to crawlers. If you can set a server-side 301, do that instead.
The decision rule: is the old URL never coming back, and should its signals move permanently? Only then is it a 301.
Build the redirect map before you touch a config file
The map is the deliverable. Everything downstream is transcription. Open a spreadsheet with columns for old URL, new URL, redirect type, and a reason. Source your old URLs from three places, not one: a full site crawl (every URL that exists), Search Console’s Performance report (every URL Google sends traffic to), and your backlink profile (every URL other sites link to). The overlap of those three is where the value lives — a page with 40 referring domains and steady organic traffic deserves manual review; an orphaned tag archive does not.
The non-negotiable rule: redirect each old URL to its closest semantic equivalent, not to the homepage. A discontinued blue running shoe should point at the current blue running shoe, or failing that the running-shoe category — never the homepage. When you bulk-redirect dead pages to the homepage, Google treats those as soft 404s, ignores the redirect, and the equity evaporates. Manually review your top 100–200 URLs by traffic and links. Pattern-match the long tail.
A worked example: one row, one rule
Say you’re moving /blog/2019/seo-tips.html to /guides/seo-tips/ and you have hundreds of dated blog URLs in the same shape. Your map row is exact: old URL, new URL, type 301, reason “date-based to evergreen slug.” For a handful of one-offs, a literal rule is fine. For the whole pattern, one regex rule covers them all in Apache:
RedirectMatch 301 ^/blog/[0-9]{4}/(.*)\.html$ /guides/$1/
This captures the slug, drops the year and .html, and rebuilds it under /guides/ — in a single hop. The single-hop part is critical. If a separate rule also forces HTTPS and another forces trailing slashes, an old http:// URL can bounce through three redirects before landing. Each hop is a chance for equity to leak and for crawlers to give up. Collapse them: one request in, one 301 out, straight to the final HTTPS URL. Test the regex against real URLs before shipping — a greedy pattern that matches too much is how you accidentally redirect your entire blog to one page.
Apache, nginx, and CDN-level redirects
On Apache, use Redirect 301 /old /new in .htaccess for simple one-to-one moves and RewriteRule or RedirectMatch for patterns. Order matters: specific rules go before broad ones, because Apache stops at the first match. Once you pass roughly 20,000 rules, move them out of .htaccess (which is re-read on every request) into the virtual host config or a CDN.
On nginx, redirects live in server blocks as return 301 https://example.com$request_uri; for whole-domain moves, or location blocks for specifics. nginx doesn’t have a per-directory .htaccess equivalent, so everything is central and fast — but it requires a reload to take effect.
At the CDN level (Cloudflare Rules, Fastly, CloudFront), redirects survive origin swaps and run at the edge before the request ever hits your server — ideal for full platform migrations. The trap is documentation: a redirect buried in a Cloudflare rule that no one remembers will confuse the next engineer for years. Keep the map as the source of truth regardless of where rules physically live.
WordPress and Shopify: plugin or server?
On WordPress, a redirect plugin (Redirection, Rank Math) is convenient because it bootstraps the whole CMS to serve each redirect — fine for a few dozen ad-hoc moves, needlessly slow across thousands. For a large migration, put the bulk rules at the server level (Apache/nginx) and let the plugin handle one-off editorial changes. Never run both systems on the same URLs, or you’ll create chains that are miserable to debug.
On Shopify, you’re constrained to the platform: URL redirects via the admin (Online Store → Navigation → URL Redirects) or a bulk CSV import. You can’t touch server config, and Shopify locks certain path prefixes like /products/ and /collections/, so plan around those limits rather than fighting them.
Test with curl, not your browser
Browsers cache redirects aggressively and will happily show you a 301 that no longer exists on the server. Use curl -I -L https://example.com/old-url to see the raw header chain. What you want is exactly one 301 followed by a 200. Two 301s in the chain means you built a redirect chain — fix it. A 301 pointing at a 404 means your map has a dead destination. A 301 pointing back at itself is a loop, and it will hard-fail for users and crawlers alike.
Test in three passes: on staging before launch, on your top 50–100 URLs immediately after go-live, and with a full site crawl a week later once the dust settles. This is where a real-crawler audit earns its keep. SEO Rocket’s site audit crawls the live site the way Googlebot does and flags redirect chains, loops, 301s that resolve to 404s, and internal links still pointing at redirected URLs — the class of problem that never shows up when you spot-check three pages by hand. Fixing internal links to point straight at final URLs also removes every unnecessary hop from your own navigation.
The launch sequence and the traffic dip you should expect
Knowing how to set up 301 redirects is only useful if the launch is disciplined. Run the move in order: freeze content changes, deploy and verify on staging, push live, test your top URLs with curl, submit the updated XML sitemap in Search Console, then monitor. Submitting the sitemap of new URLs speeds recrawl; you can also keep a sitemap of the old URLs temporarily so Google revisits them and sees the 301s faster.
Then expect a dip. A clean migration typically loses 10–25% of organic traffic for two to four weeks while Google recrawls and reprocesses, then recovers to baseline or slightly above. A dip that deepens past week four, or never recovers, means something is broken — usually a chain, a map error, or mass redirects to the homepage. Watching the recovery curve is exactly what rank tracking is for: top-100 daily snapshots show you the trend line, so you can tell normal migration jitter from a genuine regression instead of panicking at day-three noise or missing a real problem for a month.
Mistakes that quietly cost you rankings
The failures that hurt most are the silent ones. Redirect chains — old → interim → final — leak equity and waste crawl budget; always redirect to the final destination in one hop. Redirecting everything to the homepage triggers soft 404s and throws away the equity you were trying to preserve. Removing redirects too soon is the sleeper: keep 301s live for at least a year, and permanently if the old URLs still attract links or type-in traffic. There’s no expiry benefit to deleting them. For cross-domain moves, pair your 301s with Search Console’s Change of Address tool, which explicitly tells Google the whole site relocated and accelerates consolidation. And mixing redirect systems (plugin plus server plus CDN) is how loops are born — pick one layer per URL.
Frequently asked questions
Do 301 redirects pass full link equity?
Effectively yes. Google has stated that 301s (and other redirect types) no longer lose PageRank the way they once did. The practical caveat: consolidation isn’t instant, and it only happens cleanly when the destination is genuinely relevant. A 301 to an unrelated page is treated as a soft 404, and that equity is lost — not because of the redirect, but because the relevance signal broke.
How long should I keep a 301 redirect in place?
At minimum a year, and indefinitely for any URL that still earns links or direct traffic. Redirects cost almost nothing to maintain, and removing one resurfaces a 404 for every link and bookmark still pointing at the old URL. Treat permanent redirects as permanent.
When should I use a 302 instead of a 301?
Whenever the original URL is coming back — maintenance windows, A/B tests, geo or device routing, temporary promos. A 302 keeps the original URL indexed. If you use a 302 for a move that’s actually permanent, Google may keep the old URL ranking and never fully consolidate signals onto the new one.
Will setting up 301 redirects hurt my rankings?
A correctly built redirect causes a short, recoverable dip, not lasting damage. Rankings suffer when the map points at wrong destinations, chains stack up, or redirects go to the homepage. Done properly, a migration costs a few weeks of volatility; done badly, it costs a quarter or more.
The bottom line
Learning how to set up 301 redirects is really learning to respect the map and the mechanism, because the config is trivial by comparison. Match every old URL to its closest live equivalent, choose 301 only when the move is truly permanent, collapse every chain to a single hop, verify with curl instead of a browser, and keep the redirects live for the long haul. Test the whole thing with a real crawler before and after launch, watch the recovery curve on a rank tracker rather than a single day’s numbers, and give Google the few weeks it needs to reprocess. Do that and your links, authority, and rankings move with your URLs — which is the entire point.
