.htaccess Redirect Generator - Apache 301 and 302 Rules
What's included
Features
/About this tool
Need Apache Redirect Rules Without Rewriting .htaccess by Hand?
You changed URLs, moved a site, switched to HTTPS, or decided whether the canonical domain should use www or non-www. The redirect logic has to be correct because it affects users, search engines, analytics, and every old link pointing at your site. One wrong .htaccess rule can create a redirect loop, a 500 error, or a long redirect chain that wastes crawl budget.
This .htaccess Redirect Generator creates practical Apache redirect rules for common SEO and migration work. You can force HTTPS, choose a canonical host, add or remove trailing slashes, and create custom 301 or 302 redirect rows from old paths to new destinations. The preview updates instantly, with optional comments so the output is easier to review before it reaches production.
Use 301 redirects for permanent moves: old blog posts, service page slug changes, HTTP to HTTPS migration, www cleanup, deleted pages with a replacement, and full CMS migrations. Use 302 redirects for temporary tests, campaigns, maintenance paths, or short-lived routing where the original URL should keep its long-term identity. Keep the destination URL final, canonical, and already aligned with your Sitemap.xml Generator output.
Before deploying, back up the existing .htaccess file. Many Apache sites already use this file for WordPress routing, cache headers, security headers, or application rewrites. Add generated redirects carefully, test old URLs and canonical variants, and pair redirect work with the Security Headers Generator, Robots.txt Generator, and Meta Tag Generator when you are doing a full technical SEO cleanup.
The generator mixes two Apache mechanisms and orders them deliberately. Site-wide normalization uses mod_rewrite: the HTTPS rule checks %{HTTPS} !=on and rewrites to the same host and path over TLS; the host rules use a negated ^www\. condition to force www, or capture everything after www. with a backreference (%1) to strip it for non-www; and the trailing-slash rules guard against redirecting real files or directories by testing %{REQUEST_FILENAME} !-f (add mode) or !-d (remove mode) first, so a request for /style.css is never redirected to /style.css/. These blocks are always emitted in the same fixed order — HTTPS, host, slash — so protocol and domain normalize before any path logic runs. Custom old-to-new rows instead use the simpler mod_alias Redirect directive rather than RewriteRule, sufficient for exact-path matches and easier to audit visually. Every "From" path is normalized to a leading slash automatically, and rows missing a from or to value are silently dropped rather than producing a broken rule.
Step by step
How to Use
- 1Choose your global Apache redirect rulesDecide whether the site should force HTTPS, force
www, force non-www, add trailing slashes, or remove trailing slashes. These site-wide rules should match the canonical URLs in your Meta Tag Generator output and the URLs you submit through your Sitemap.xml Generator. - 2Pick the correct host modeUse Force non-www when
https://example.com/page/is the canonical version, or Force www whenhttps://www.example.com/page/is the canonical version. Avoid switching this casually on an existing site because host redirects affect every page, analytics path, canonical tag, and backlink target. - 3Set trailing slash behavior carefullyChoose Add slash or Remove slash only when your site has a clear URL style. Changing slash behavior can create site-wide redirects, so confirm that your CMS, internal links, canonical tags, and sitemap all use the same version before publishing the generated
.htaccessrules. - 4Add custom 301 or 302 redirect rowsEnter the old path in the From field and the final destination in the To field. Use 301 for permanent moves, deleted pages with a replacement, slug changes, and SEO migrations. Use 302 only for temporary campaigns, short tests, or routing that you expect to reverse.
- 5Review the generated .htaccess outputRead the preview before copying. Confirm that
RewriteEngine Onappears once, HTTPS and host rules are above custom redirects, old paths start with/, and each old URL points directly to the final destination rather than another redirecting URL. - 6Back up your current .htaccess fileBefore uploading, download or copy the existing production
.htaccessfile. A small syntax issue in Apache config can break the site, so always keep a known-good version ready and apply changes during a window where you can immediately test important pages. - 7Copy or download and deployUse Copy when editing directly in hosting file manager or Download to save a fresh
.htaccessfile. Upload it to the Apache document root, usually the same directory as the mainindex.phporindex.html, then test several old and canonical URLs in a browser. - 8Verify redirects after deploymentCheck that HTTP redirects to HTTPS, the wrong host redirects to the canonical host, and old URLs return the expected 301 or 302 status. If you also changed security headers or crawler rules, review the matching Security Headers Generator and Robots.txt Generator outputs.
Real-world uses
Common Use Cases
Got questions?
Frequently Asked Questions
For a simple Apache redirect, use a line like Redirect 301 /old-page/ https://example.com/new-page/. The old path should be relative to the site root and the destination should be the final canonical URL. This generator builds those rows for you and also adds optional HTTPS, host, and trailing slash rewrite rules. After publishing, test the old URL and confirm it returns a 301 status instead of a 302 or redirect chain.
Use 301 when the move is permanent: site migrations, changed slugs, merged pages, deleted pages with a replacement, and canonical cleanup. Use 302 only when the redirect is temporary and you expect the original URL to return, such as a short promotion or test. For SEO migrations, 301 is normally the right choice because it tells search engines to transfer signals to the new URL. Avoid using 302 for permanent moves because it can delay canonical consolidation.
Enable the Force HTTPS option to generate a RewriteCond that checks whether the request is not already HTTPS, followed by a RewriteRule that redirects to the HTTPS version of the same host and path. Put this rule near the top of the file so HTTP requests normalize before custom page redirects run. Make sure your SSL certificate is installed first. If HTTPS is broken at the hosting level, an .htaccess redirect cannot fix the certificate problem.
Choose Force non-www if your canonical URLs should use example.com, or Force www if they should use www.example.com. The generated rewrite conditions normalize the host before users and crawlers continue to page-level URLs. Keep this choice consistent with canonical tags, sitemap URLs, internal links, analytics settings, and Search Console properties. Mixing host versions creates duplicate URL signals and unnecessary redirects.
Yes. A redirect chain happens when URL A redirects to URL B, then URL B redirects again to URL C. Chains slow page loads, waste crawl budget, and make migrations harder to debug. Point every old URL directly to the final canonical destination whenever possible. If you are forcing HTTPS and host changes globally, make sure custom redirect destinations already use the final HTTPS canonical host.
Upload .htaccess to the Apache document root for the site, usually the folder containing index.php or index.html. On shared hosting this is often public_html. On some managed hosts, .htaccess editing may be restricted or generated by the platform. Always back up the existing file first because .htaccess can also contain WordPress rules, caching rules, security headers, or application routing that you should not overwrite blindly.
No. .htaccess is specific to Apache and hosts that support Apache per-directory configuration. Nginx uses server block configuration, Vercel uses redirects in vercel.json or framework config, and Netlify uses _redirects or netlify.toml. Use this generator only for Apache hosting, cPanel hosting, many WordPress installs, and environments where .htaccess rules are supported.
Usually yes. Normalizing protocol and host early means every request reaches the same canonical domain before page-level redirect logic is evaluated. That makes rules easier to reason about and prevents duplicate mappings for HTTP, HTTPS, www, and non-www variants. The main exception is an advanced application setup with custom routing requirements, where you should follow the server or CMS documentation.
Open several old URLs in a browser and confirm they land on the expected new pages. For status codes, use browser developer tools, curl -I, or an online HTTP header checker to verify 301 or 302 responses. Test HTTP, HTTPS, www, non-www, and trailing slash variants if you changed those rules. If the site returns a 500 error, restore the backup .htaccess file and inspect the generated rules for host-specific incompatibilities.
Yes, if the WordPress site runs on Apache or a host that supports .htaccess. Put custom redirects carefully around the existing WordPress rewrite block and avoid deleting platform-generated rules. For many migrations, page-level Redirect 301 rows are enough for old slug to new slug mapping. For large migrations, export a URL map from your old site and add rows in batches so you can test before publishing everything.