.htaccess Redirect Generator
Generate clean, valid Apache .htaccess redirect rules — bulk 301s, regex patterns, force HTTPS, www normalisation — without hand-writing a single mod_rewrite directive or copy-pasting from a stale Stack Overflow thread.
Format: /old /new per line. Absolute URLs auto-detected and emitted as RedirectMatch.
Always back up your .htaccess before making changes. A single typo can take down your entire site. Test in a staging environment first.
# Configure rules on the left to see your .htaccess output here.When you actually need .htaccess redirects (and when there's a better way)
The .htaccess file is Apache's per-directory configuration mechanism. It runs on every standard Apache install — shared hosting like Bluehost, SiteGround, and Hostinger, plus most cPanel-managed VPS environments. It also runs on LiteSpeed and OpenLiteSpeed, which read .htaccess for backwards compatibility with Apache. If your site is hosted on any of those, .htaccess is the right place for redirect rules.
Nginx is a different story. Nginx ignores .htaccess entirely — redirects live in the server block in nginx.conf or a sites-available file, using rewrite or return 301 directives instead. If you're on nginx, generating .htaccess rules is a waste of time. Run curl -I yourdomain.com and check the Server header before you start — five seconds of verification can save an afternoon of debugging.
For modern stacks — Next.js on Vercel, SvelteKit on Cloudflare Pages, anything sitting behind a CDN edge — platform-level redirects are usually a better choice. Vercel reads redirects() in next.config.js. Cloudflare has Bulk Redirect Rules in the dashboard with a 100,000-rule cap. Netlify uses a _redirects file. These execute at the edge before the request ever hits your origin, which is faster, cheaper, and easier to roll back than .htaccess. If your stack supports it, use it.
Where .htaccess still wins is the classic SEO use case: a WordPress site is being migrated to a new permalink structure, an ecommerce store has restructured its SKU URLs from /products/sku-1234 to /shop/category/product-name, or a blog is consolidating five subdomains into one. These migrations involve hundreds or thousands of one-to-one URL mappings, and .htaccess handles them cleanly with no deploy pipeline, no CI, no risk of a Vercel build failing in the middle of a launch. Generate the rules here, paste them into the file, upload, and you're live.
301 vs 302 vs RewriteRule: pick the right tool
Choosing the wrong status code is the silent killer of redirect projects. Here's when each one applies.
Permanent
The default for migrations. Tells search engines to transfer link equity, drop the old URL from the index, and replace it with the new one. Use for any URL change that is meant to last.
Temporary
For short-term redirects — a maintenance page, a temporary promo URL, an A/B test. Does not pass full link equity and tells Google to keep the old URL in the index.
Preserve method
Like 302, but strictly preserves the request method. A POST stays a POST. Used almost exclusively for API endpoints — not relevant for typical SEO redirects.
Pattern-based
When you need regex matching, capture groups, or conditional logic (RewriteCond). Slightly heavier per request than Redirect, but the only option for one-rule-handles-many-URLs scenarios.
Migration playbook: how to redirect 5,000 URLs without breaking SEO
Five thousand redirects sounds like a lot until you realise that most of them follow a handful of repeating patterns. The first task on any migration is grouping. Pull your full URL list out of the old site (a Screaming Frog crawl works), open a spreadsheet, and sort by URL prefix. You will almost always find that 80% of the URLs fall into five to ten distinct patterns — /blog/2018/*, /products/sku-*, /categories/*/products/*. Each of those becomes a single RewriteRule with a regex capture group, not a thousand individual Redirect lines. A 5,000-URL migration usually compresses to 50-200 actual rules.
The remaining one-off URLs go in a Redirect block at the bottom — straight one-to-one mappings, generated in bulk mode above. The order matters: more specific rules first, more general rules last. Apache evaluates top to bottom, and once a rule matches with the L flag set, it stops. Put your catch-all at the end or risk it eating requests meant for more specific rules.
Query strings are the next gotcha. By default, RewriteRule discards the original query string when it rewrites the URL. If your old URLs included tracking parameters (?utm_source=newsletter), filter parameters (?color=red&size=large), or any other meaningful data after the question mark, add the QSA flag to preserve them. But only add it where you actually need it — preserving stale tracking params on a fresh URL is a minor analytics-pollution problem, not a feature.
Test before deploying. Pick twenty representative URLs from your old site — five popular pages, five medium-traffic pages, five long-tail pages, five edge cases (URLs with query strings, encoded characters, or trailing slashes), and a few you expect to NOT match. Drop the .htaccess into a staging environment, run those URLs through curl, and verify each one returns 301 with the right Location header. Most failed migrations had no testing step.
Deployment order matters. The sequence is: deploy the new site → deploy the redirects → submit the new sitemap to Google Search Console → submit the old sitemap one last time so Google sees the 301s in context → request reindex on the top 20-50 priority pages individually. Then watch GSC for the next two to four weeks. Soft 404 reports will tell you which redirects landed on weak destinations. Coverage reports will show pages that got dropped. Every issue caught in the first month is a saved ranking.
Five .htaccess mistakes that silently kill your traffic
None of these throw an error or fail loudly. The site keeps loading, redirects keep firing, and rankings just slowly bleed out over the following months. These are the patterns we see most often when auditing post-migration sites.
Chained redirects
A redirects to B, B redirects to C, C redirects to D. Every hop adds 100-300ms of TTFB and Google has historically dropped some link equity at every step beyond the first. After a few migrations the chains get long enough to genuinely hurt. Audit periodically with a tool like httpstatus.io or Screaming Frog — flatten any chain longer than one hop by editing the upstream rule to point directly at the final destination.
Redirecting to a 404
You wrote 5,000 redirects against a list of new URLs. Half of those new URLs do not exist yet because that section of the new site has not shipped. Apache happily issues the 301 and the user lands on a 404. Audit the destination of every redirect against a live crawl of the new site BEFORE the migration goes live, not after.
Regex that matches more than intended
A pattern like /blog/.* without anchors will match /blog/post, /blog/post/comments, and /blog/post.html — possibly redirecting URLs you never meant to touch. Always anchor with ^ at the start and $ at the end unless you genuinely want a prefix match. Use the test panel in this generator and run twenty sample URLs against your pattern before deploying.
Forgetting the L flag
Without the L (Last) flag, Apache continues evaluating subsequent rules even after a match. The result is rules stacking — your URL gets rewritten by rule 5, then rewritten again by rule 12, then redirected to a completely different place by rule 18. The .htaccess file looks correct, but the live behaviour is bizarre. Add [L] to every rule unless you have a specific reason not to.
Testing in production with no rollback plan
You upload the new .htaccess straight to live, take a half-day off, and come back to find the homepage returning a 500. Always keep a backup named .htaccess.bak in the same directory before you change anything. If the new file breaks, you can SFTP in, rename .htaccess to .htaccess.broken, rename .htaccess.bak to .htaccess, and you are back in under thirty seconds. The cost of this habit is zero. The cost of skipping it is hours of downtime.
After the redirects ship, monitor what actually happens
A redirect map is half the migration. Tracking the result is the other half.
The first two weeks after a migration are the highest-risk window. Google is recrawling the old URLs, following the 301s, and re-evaluating the new destinations. If your rankings are going to drop, this is when it happens. A few things go wrong silently: the new pages have weaker on-page signals than the old ones, internal links still point at the old URLs (one extra hop), or the redirect rules cover 95% of URLs but missed a long-tail batch.
Catch the issues fast by tracking your top keywords daily for the first month. Sudden position drops are the most reliable signal that a redirect rule is broken or that a destination page is underperforming. Search Console's coverage and crawl error reports lag by several days, which is too slow for an active migration.
RankNow.ai's Rank Tracker handles the daily monitoring side, and the Site Audit catches the technical issues — broken redirects, redirect chains, missing destination pages — before Google does.
.htaccess Redirect FAQ
The questions we get asked most often about Apache redirects, mod_rewrite, and migration safety.
Contact SupportProperly implemented 301 redirects pass essentially all link equity to the destination URL — Google has confirmed this multiple times since 2016. What hurts rankings is messy implementation: chained redirects (A → B → C → D), redirects that land on 404s or soft 404s, redirects pointed at irrelevant content, or temporary 302s used where a 301 belongs. Build a clean one-hop map from old to new and you will keep the rankings you have earned.
Both are permanent. The difference is what they do with the request method. A 301 historically allowed the browser to change a POST request into a GET, which is the behaviour most older clients still rely on. A 308 strictly preserves the original method — a POST stays a POST, a PUT stays a PUT. For SEO and the typical "old URL → new URL" rewrite, 301 is the correct choice and what every search engine expects. Use 308 only when you are redirecting an API endpoint that handles non-GET traffic and you need the method preserved.
No — that is the point of a redirect. The old URL responds with a 301 status code and a Location header pointing at the new URL. The original page does not need to exist on disk and should not return a 200. If both the old and new URLs return 200 with the same content, you have a duplicate-content problem instead of a clean migration.
Permanently for any URL that ever earned an external link or had measurable organic traffic. Google has stated that one year is the minimum to fully consolidate signals, but the cost of leaving a redirect in place forever is essentially zero, while the cost of removing one and serving 404s to live backlinks is real. The only reason to ever remove a redirect is if the destination itself goes away — and at that point you need a new redirect, not an empty rule.
You can, but you should not. Each hop adds latency (TTFB grows by roughly 100-300ms per hop on a typical Apache server) and Google has historically dropped some equity at every hop beyond the first. Google now follows up to ten redirect hops in one crawl, but two or three is where measurable damage starts. Always flatten chains: if A redirects to B and B redirects to C, edit your rules so A redirects directly to C.
No. .htaccess is an Apache-specific configuration file, also supported by LiteSpeed and OpenLiteSpeed because they are Apache-compatible. Nginx uses a completely different config syntax (server blocks with rewrite or return directives in nginx.conf or sites-available files) and ignores any .htaccess file you upload. If you are unsure what server you are on, run "curl -I yourdomain.com" and check the Server header in the response.
Three options in order of safety. First — clone your production site to a staging subdomain, deploy the .htaccess there, and crawl with Screaming Frog or a curl loop. Second — use the htaccesstester.com sandbox to dry-run rules against sample URLs. Third — if you must test on production, deploy in chunks of ten to fifty rules at a time, monitor Google Search Console crawl errors and your real-time logs for 5xx responses, and keep a known-good copy of the previous .htaccess so you can roll back in seconds.
Marginally, but not in any way you will notice on a typical site. Both directives evaluate per request. Redirect uses simple prefix matching, RewriteRule uses regex compilation. On a file with a thousand simple URL pairs, Redirect 301 is actually slightly faster because there is no regex engine to invoke. Use Redirect 301 for plain "old → new" URL pairs and RewriteRule only when you need pattern matching, conditions, or flags. Mixing both in the same file is fine.
Only if you use any RewriteRule, RewriteCond, or RewriteMap directive. Without "RewriteEngine On" Apache silently ignores the entire mod_rewrite block, which is the single most common reason a freshly deployed .htaccess "does nothing". Plain Redirect and RedirectMatch directives do not need it because they belong to mod_alias, which is enabled by default on every standard Apache install.
Other free tools you might like
See all 10 free toolsSchema Markup Generator
Generate valid JSON-LD structured data for Article, Product, FAQ, LocalBusiness, Recipe, Event, and Organization in seconds.
UTM Link Builder
Build clean, consistent UTM-tagged URLs one at a time or in bulk via CSV. Perfect for paid campaigns, email blasts, and referral attribution.
SERP Snippet Simulator
Preview exactly how your title tag and meta description appear in Google desktop and mobile SERPs — pixel-accurate truncation included.
Just shipped a migration? Catch the broken redirects before Google does.
RankNow.ai's Site Audit crawls your full site, flags redirect chains and 404 destinations, and tracks your most important keywords daily — so you know in hours if a rule went wrong, not weeks.
Try Site Audit Free