Apache .htaccess and Nginx redirect generator for canonical URLs and migrations
One bad line in .htaccess once took a whole site offline for me. So yeah, I get the nerves. Tell this thing your domain and what you actually want: force HTTPS, pick www or non-www, sort out the trailing slashes, clean up stray index files, point old URLs at new ones. It writes the Apache rules. You also get the Nginx version and a little matrix showing what redirects where, plus warnings, so you can read what the server’s about to do before anything touches production.
These rules touch every URL on the site. Back up first. Try it on staging if you can, then once it’s live, push a few key pages through a redirect checker just to be sure.
Redirect rules should reduce complexity, not create chains
What you want is dead simple. Someone hits the old URL, they land on the final one, done. One hop. Trouble starts when the rules pile up and begin fighting each other: http bounces to https, then non-www bounces to www, then some stray slash rule kicks in, and now a crawler’s doing three round-trips just to read one page. Loops happen. So do broken paths. And because .htaccess runs on every single request, the order you write the rules in genuinely changes what comes out the other end.
So this tool builds the Apache rules for the stuff you actually migrate: forcing HTTPS, locking in a canonical host, tidying up index files, choosing whether slashes stay or go, and pointing old URLs at new ones. You get the Nginx version too, plus a matrix and a warnings list, because I’d rather you read what the server’s going to do than find out in production.
How to test redirect rules
My rough checklist. Hit the homepage. Hit a URL you moved. Try a page with the trailing slash, then without it. Throw in an old index file, a couple of sitemap URLs, a few pages you genuinely care about. Permanent move? You want a 301, almost always. A 302 is fine while you’re still poking at things, but honestly, don’t leave one sitting on a canonical move, search engines read it as “eh, this might change back.” Then once you’ve shipped, go fix your internal links so people aren’t bouncing through a redirect just to click around your own site.
- Specific URL moves go first, way before any of the broad canonical rules.
- Canonical host rules shouldn’t be wrestling with whatever WordPress or your CDN is already doing.
- HTTPS redirects should fire once. Not http to https to www in some little chain.
- Trailing slash policy has to agree with your WordPress permalink settings. Otherwise, loop.
- Nginx config lives in server blocks. It never goes in .htaccess, not ever.
Common redirect mistakes
The big one I keep seeing: dumping every old URL onto the homepage. Feels tidy. But you throw away all the relevance, and Google more or less reads it as a soft 404. Then the chain, http to https to non-www to www, which is just latency you hand every visitor for nothing. Leave a 302 on a permanent move and search engines keep wondering if the old URL is coming back. Run add-slash and remove-slash together and you’ve built yourself a guaranteed loop. And editing .htaccess with no backup? One typo, the whole site throws a 500 until you fix it. Maybe it’s just me, but that one feels worse than all the others combined. Ask me how I know.
Common questions
Should I use 301 or 302?
Permanent move, canonical cleanup, old URL gone for good? Use 301. Save the 302 for when you genuinely mean “this is temporary and I’m putting it back.”
Can I use these rules on Nginx?
The Apache ones? No. Totally different syntax. I generate both versions for you, but each only works on its own server. Paste Apache rules into an Nginx config and nothing good comes of it.
Should internal links still point to old URLs?
Nope. Keep the redirects up, they’re there to catch old links and bookmarks. But your own internal links and sitemaps should hit the final URLs straight off. Why send your visitors on a detour through your own site?
What is the difference between a 301 and a 302 in .htaccess?
R=301 is permanent. It passes your ranking on to the new URL, so that’s the one you want for moved content. R=302 is temporary, which means the value stays parked on the original URL. Reach for 301 unless you’ve got a real reason not to.
Why is my .htaccess redirect causing a loop?
Almost always, it’s a rule that rewrites a URL into something matching that same rule again. So it just keeps firing. Forever. The fix: add a condition that excludes the state you’re already in, like only redirecting when HTTPS is genuinely off, instead of on every single request.
Does .htaccess work on Nginx?
No. The .htaccess file is an Apache thing, full stop. Nginx doesn’t read it at all. You get the same behavior over there with return or rewrite directives written straight into the server config.
