How to Write .htaccess Redirect Rules That Actually Work

The Migration That Dropped 40% of Traffic

A WordPress agency migrated a client's site from a custom CMS to a new URL structure. They moved hundreds of pages, launched on a Monday, and by Wednesday the client was panicking. Organic traffic had dropped nearly 40% in two days.

The developers had written redirects for the top 20 pages. The other 200, they assumed, would "resolve themselves." They didn't. Every old URL returned a 404. Six years of link equity, gone.

This is not a rare story. Redirects feel like a detail. They're not.

What .htaccess Actually Does

The .htaccess file is an Apache server configuration file that sits in your website's root directory. No server restart required when you change it. Drop a rule in, save the file, and it takes effect within seconds. That's what makes it so powerful for redirects during a migration.

It's also what makes a syntax error so destructive. A single malformed line can take down your entire site with a 500 Internal Server Error. Apache processes .htaccess instructions sequentially, and a broken directive doesn't just skip itself, it can halt processing for everything below it.

So you write the rules carefully. Or you generate them.

301, 302, and 410: What You're Actually Choosing

Most people know that 301 is "permanent" and 302 is "temporary." What they don't know is what that distinction costs them if they get it wrong.

A 301 tells search engines to transfer ranking signals to the new URL. Link equity flows to the destination. Google eventually drops the old URL from its index. This is what you want during a site migration, a domain change, or any permanent restructure.

A 302 tells search engines: keep the original URL in the index, this is temporary. Use it during A/B tests or maintenance pages where you genuinely intend to remove the redirect later. Using a 302 when you mean 301 is one of the more expensive quiet SEO mistakes. The old URLs stay indexed, the new ones don't accumulate authority, and you've created a split signal that neither URL benefits from.

Then there's 410 Gone. It doesn't redirect anywhere. It tells search engines: this page was removed intentionally and it's not coming back. Search engines de-index 410s faster than 404s. If you're cleaning up discontinued product pages or content you've deliberately taken down, 410 is cleaner than leaving a 404. The .htaccess redirect generator handles 410 via RewriteRule with the [G,L] flag automatically.

Redirect vs. RewriteRule

Two syntaxes, different use cases.

Redirect is the simpler directive. One line per rule, easy to read, slightly faster for Apache to process:

Redirect 301 /old-page /new-page

RewriteRule is for anything more complex: pattern matching, regular expressions, query string handling, conditional logic. It requires the RewriteEngine On directive to be active and produces rules that look like this:

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

The [R=301,L] flags set the redirect status code and stop processing further rules. Get those flags wrong and you can create redirect loops or rules that fire but don't redirect.

If you're doing one-to-one URL redirects, the Redirect directive is fine. If you're redirecting based on patterns, or you need to handle query strings, use RewriteRule. The generator lets you choose which syntax to output.

How to Use the Generator

Open the .htaccess redirect generator, enter your old URL path in the first field and your destination URL in the second. Pick your redirect type. The rules generate in real time.

For a single rule or a handful, that's it. Copy the output, paste it into your .htaccess file.

The bulk import mode is where it earns its keep. Switch to Bulk Import, paste your URL pairs one per line with old and new separated by a comma or tab, and it generates all the rules at once. If you've exported a URL mapping from a spreadsheet during a migration audit, you can paste the whole thing directly. Two hundred redirect rules in under a minute.

A few things worth doing before you paste anything into production:

• Back up your existing .htaccess file first. Always.
• Test one rule on a staging environment if you have one.
• After you go live, visit several of the old URLs yourself to confirm the redirects fire.

For large migrations, running a quick crawl with Screaming Frog before and after is worth the time. It surfaces any chains (A redirects to B redirects to C, which costs PageRank) and catches rules that fired incorrectly.

How to Add Rules to Your .htaccess File

Connect via FTP, SFTP, or your hosting panel's file manager. The file lives in the root directory (usually public_html or www) and starts with a dot, so enable "show hidden files" in your FTP client.

If a .htaccess file already exists, add new rules at the top or in a clearly marked redirect block. If it doesn't exist, create a plain text file named exactly .htaccess (leading dot, no extension).

Special characters in URL paths (parentheses, question marks, dots) need backslash escaping in RewriteRule syntax. The generator handles this automatically.

FAQ

Do I need mod_rewrite enabled for RewriteRule to work?

Yes. mod_rewrite is an Apache module that must be enabled on your server. Most shared hosting providers have it active by default. If your RewriteRules aren't working, check with your host or run apache2ctl -M on the server to see loaded modules.

Can I use this for WordPress sites?

Yes, but WordPress already uses .htaccess for its own permalink structure. Add your redirect rules before the WordPress block that starts with # BEGIN WordPress. Rules inserted inside that block get overwritten by WordPress whenever you save permalink settings.

My redirect is looping. What's wrong?

Usually happens when the new URL matches the pattern of the old URL. If you're redirecting all traffic at the root level, a redirect from / to https://example.com/ on a server already serving example.com will loop. The fix is adding a condition with RewriteCond that checks the request isn't already at the destination.

Will these rules work on Nginx or IIS?

No. .htaccess is Apache-specific. Nginx uses a different directive syntax inside server block config files. IIS uses web.config with XML-based rewrite rules. You'll need to convert the output manually for non-Apache servers.

How do I test that a redirect is working?

The fastest way is curl -I https://yourdomain.com/old-url from the command line. It returns the response headers including the status code and Location header showing where you're being sent. You can also use your browser's developer tools under Network and look for the 301 response on the old URL.

Set It Up Before You Need It

Redirects are one of those things that are easy to defer and expensive to fix after the fact. Once a migration is live and old URLs start 404ing at scale, you're racing against Googlebot's recrawl schedule.

Generate your rules before launch, test them on staging, and deploy the .htaccess file as part of the migration, not as a follow-up. The .htaccess redirect generator takes the syntax out of the equation.

If your redirects involve URL-encoded characters or you need to verify that path strings are properly formatted before adding them to your rules, the URL encoder/decoder handles encoding and decoding in one step. And if you're rewriting URLs with complex regex patterns, the regex tester lets you validate the pattern against real URL strings before putting it in production.