Apache .htaccess and Nginx redirect generator for canonical URLs and migrations
Generate Apache .htaccess redirects for HTTPS, www or non-www canonical hosts, trailing slash policy, index file cleanup and URL moves, then review the Nginx equivalent, expected redirect matrix, migration warnings and copyable snippets before editing server configuration.
Redirect rules can affect every URL. Test on staging, keep a backup and verify important pages with a redirect checker after deployment.
Redirect rules should reduce complexity, not create chains
A good migration sends users and crawlers from the old URL directly to the final canonical URL. A poor rule set can create chains, loops, mixed protocol hops, www and non-www conflicts, accidental 302 redirects, broken paths and confusing sitemap behavior. Because .htaccess rules run on every request, order and specificity matter.
This .htaccess redirect generator creates Apache rules for common SEO migration tasks: forcing HTTPS, choosing a canonical host, cleaning index files, adding or removing trailing slashes and mapping old URLs to new ones. It also produces an Nginx equivalent, expected redirect matrix and warnings so you can understand what the server should do before editing production configuration.
How to test redirect rules
Test the homepage, a moved URL, a page with and without trailing slash, an old index file, sitemap URLs and a few important article or tool URLs. A 301 is usually right for permanent migrations. A 302 is useful for temporary testing, but it should not be left behind for canonical SEO moves. After deployment, update internal links so normal navigation points directly to final URLs.
- Specific URL moves should appear before broad canonical rules.
- Canonical host rules should not fight WordPress or CDN settings.
- HTTPS redirects should happen once, not through a chain.
- Trailing slash policy must match WordPress permalink settings.
- Nginx config belongs in server blocks, not .htaccess.
Common redirect mistakes
Redirecting every path to the homepage loses relevance and is usually bad for SEO. Chaining http to https and then non-www to www adds latency. Using 302 for a permanent site move can keep search engines uncertain. Applying both add-slash and remove-slash rules creates loops. Editing .htaccess without a backup can take the site down with a small syntax error.
Common questions
Should I use 301 or 302?
Use 301 for permanent URL moves and canonical cleanup. Use 302 only when the redirect is temporary.
Can I use these rules on Nginx?
No. Apache .htaccess and Nginx use different syntax. This tool generates both, but they belong in different server environments.
Should internal links still point to old URLs?
No. Keep redirects for old traffic, but update internal links and sitemaps to final URLs.
What is the difference between a 301 and a 302 in .htaccess?
R=301 is a permanent redirect that passes ranking to the target; R=302 is temporary and keeps value on the original. Use 301 for moved content.
Why is my .htaccess redirect causing a loop?
Usually a rule that rewrites a URL to a pattern that matches itself again. Add a condition to exclude the already-correct state, for example only redirect when HTTPS is off.
Does .htaccess work on Nginx?
No. .htaccess is an Apache feature. On Nginx you express the same redirects with return or rewrite directives in the server config instead.
