How to Set Up 301 Redirects in .htaccess Without Losing Your Rankings

The Migration That Took Eighteen Months to Recover From

A development agency relaunched a client's e-commerce site in November. New platform, cleaner URLs, better performance. They redirected the homepage. They forgot the 4,200 product and category pages.

By January, the site had dropped from page one to page four for its core commercial terms. The old URLs had three years of backlinks and domain authority behind them. None of it transferred. The ranking signals that took years to accumulate just evaporated.

Getting redirects wrong on a site migration is one of the more expensive mistakes in web development. Not because the fix is complicated, but because the damage accumulates quietly before anyone notices.

The Actual Difference Between 301 and 302

Everyone knows the numbers. Not everyone knows when to use which.

A 301 tells search engines: this page has moved permanently. Transfer everything. The link equity, the ranking signals, the crawl priority. Point it here from now on. Use this any time a URL has a new permanent home.

A 302 says: this is temporary. Keep the original URL in the index. Don't transfer ranking signals. Use this for A/B tests, maintenance pages, or redirecting users during a short-term campaign while the original page stays live in search.

The common mistake is using a 302 when you mean a 301. Developers default to 302 because it feels safer. But if the page isn't coming back, a 302 wastes the link equity. Search engines hold onto the old URL while the new one builds no authority.

One more to know: 410 Gone. Not a redirect at all. It tells search engines a page has been permanently removed with no replacement. Google de-indexes 410s faster than 404s because the status signals intentional removal. Most site owners leave deleted pages returning 404s and wonder why they're still in Search Console six months later.

Redirect or RewriteRule: Which One Do You Actually Need

Apache gives you two ways to write a redirect in .htaccess. The simpler one is the Redirect directive:

Redirect 301 /old-page /new-page

Clean. Readable. Slightly faster for Apache to process. Works perfectly for straightforward one-to-one URL mappings.

RewriteRule (from mod_rewrite) handles everything the Redirect directive can't: pattern matching, regular expressions, query string conditions, conditional logic. The syntax looks like this:

RewriteEngine On
RewriteRule ^old-page/?$ /new-page [R=301,L]

The [R=301,L] flags matter. R=301 sets the redirect type. L tells Apache to stop processing further rules once this one matches. Skip the L flag on a busy .htaccess file and you'll spend an afternoon debugging redirect loops.

There's one case where RewriteRule is required even for simple redirects: the 410 Gone status. The Redirect directive doesn't support 410. You have to write it like this:

RewriteRule ^deleted-page/?$ - [G,L]

The - means no substitution URL. The [G,L] flags return the 410 response and stop further processing. Easy to get wrong if you're working from memory.

Using the Generator for Real Work

Writing mod_rewrite rules by hand is where things go sideways. Special characters in URL paths need escaping. Trailing slashes need handling. One typo produces a redirect loop, a 500 error, or a silent failure where the rule does nothing and you don't find out until you check the analytics.

The .htaccess redirect generator takes old and new URL pairs and outputs properly formatted directives. Choose Redirect or RewriteRule syntax, pick your status code, and the output updates as you type. Copy the block, paste it into your .htaccess file.

The bulk import is what I reach for on migrations. Paste a list of old URLs next to new URLs, comma or tab-separated, one pair per line. The tool generates all the rules at once.

Before building that list, Screaming Frog is the right tool for crawling the old site and exporting every indexable URL as a CSV. Run the crawl, map old URLs to new ones in a spreadsheet, paste the columns into the bulk import field. For a 500-page site, the whole process takes about an hour. Writing rules by hand would take a day and you'd still make mistakes.

Actually Getting the Rules Into the File

The .htaccess file lives in your server's root directory, usually /public_html/ or /www/. The filename starts with a dot, making it hidden on Unix systems. Enable hidden files in your FTP client if you can't see it.

If the file doesn't exist, create one in a plain text editor, save as .htaccess with no other extension, and upload to the root.

Before editing an existing file: download a backup. Always. A broken .htaccess causes a 500 error across the entire site. One mismatched bracket takes down every page.

Paste your generated rules near the top of the file, before any existing RewriteRule blocks. Apache processes rules in order, so rules higher in the file take priority. For WordPress sites, there's already a WordPress permalink block in .htaccess. Your redirect rules go above it.

Test immediately after uploading. Visit the old URL and confirm it lands on the correct destination. Use curl -I <old-url> from the command line to verify the status code is actually 301 and not a 302 or 200.

FAQ

What happens if I use 302 for a permanent move?

The page stays indexed at the old URL indefinitely. Search engines won't transfer ranking signals because the 302 signals "this is temporary, check back." Swap to 301 as soon as you catch it. The search engines will figure it out eventually, but you'll lose ground in the meantime.

Do redirects slow down my site?

Each redirect adds one HTTP round trip. A single hop is negligible. Chains are the problem: A redirects to B, B redirects to C. Two extra round trips per request, and search engines stop following chains after a certain depth. If relaunching a site with existing redirects, update the old ones to point directly to the final destination.

Will these rules work on my WordPress site?

Yes, if your host runs Apache, which most shared hosting does. WordPress comes with an existing .htaccess file for its permalink structure. Paste your redirect rules above the # BEGIN WordPress block so they're processed first.

My host uses Nginx. Does any of this apply?

No. .htaccess is Apache-specific. Nginx ignores it entirely and uses a different configuration format in its server block files. If you're on a VPS, managed hosting, or a cloud provider running Nginx, you'll need rewrite or return directives in the Nginx config instead.

How do I confirm the redirect type in the response?

Run curl -I <old-url> from the command line and look at the status line and Location header. Or open your browser's developer tools Network tab, click the redirected URL, and check the status code. You want to see 301 Moved Permanently, not 302 Found.

Get the Redirect Rules Right Before the Migration

Redirects fail silently. The traffic drops, the rankings slip, and by the time someone connects it to the missing .htaccess rules, the damage is already done.

Write them correctly the first time using the .htaccess redirect generator. Single redirects take thirty seconds. Bulk imports handle hundreds of URL pairs in one pass.

If you're updating meta tags at the same time (which you should be, for any replatforming), the meta tag generator handles title tags, descriptions, and Open Graph tags for the new URLs. And if your redirect rules involve complex URL patterns, the regex tester lets you validate the pattern before it goes anywhere near a live server.