Htaccess Redirect Generator — build safe Apache redirect rules

An htaccess redirect generator writes the exact Apache syntax for you, so a single misplaced flag or missing slash doesn't take your site offline. This free tool builds copy-ready rules for the redirect scenarios that come up constantly in real SEO work — permanent 301s, temporary 302s, forcing HTTPS, forcing or removing www, redirecting an entire domain, wildcard directory moves, and bulk 301 lists for migrations.

Redirects look simple until they go wrong, and when they go wrong they tend to go wrong expensively — lost rankings, lost backlink equity, or a site that returns a 500 error to every visitor. Arb Digital handles redirect strategy on every site migration and domain change we run, and this generator reflects the patterns we actually use in production, not generic boilerplate.

What This Htaccess Redirect Generator Does

Pick the redirect scenario that matches what you're actually trying to do, enter the old and new paths, and the tool writes valid .htaccess syntax using Apache's mod_rewrite module (RewriteEngine/RewriteCond/RewriteRule) or the simpler Redirect directive from mod_alias, depending on which is the right tool for that job. The bulk mode accepts a full list of old-URL-to-new-URL pairs and generates one clean 301 rule per line — ideal for site migrations where dozens or hundreds of URLs changed at once.

How to Use It

1. Choose your redirect type from the dropdown — this determines which fields you need to fill in.
2. Enter your old and new paths. For single redirects, use relative paths like /old-page/ or full URLs for cross-domain redirects.
3. For bulk moves, switch to bulk mode and paste one "old,new" pair per line.
4. Generate and review the output carefully — check that every old path and new path is correct before copying.
5. Back up your current .htaccess file, then paste the new rules near the top of the file, above any existing RewriteEngine block if one already exists (see the note on multiple rule blocks below).
6. Test immediately after uploading — visit a redirected URL directly and confirm it lands on the right page with the correct status code.

301 vs. 302 — The Mistake That Costs Rankings

This is the most consequential decision in this whole tool. A 301 redirect tells browsers and search engines "this page has moved permanently" — Google transfers essentially all of the ranking signals and link equity earned by the old URL to the new one, and it drops the old URL from its index in favor of the new one. A 302 redirect says "this is temporary, come back later" — Google keeps the original URL indexed, does not pass link equity to the destination, and will keep checking the old URL to see if it's back.

Using a 302 for a permanent page move is one of the most expensive and common SEO mistakes there is. It happens constantly by accident — a developer's default redirect snippet is often 302, or a CMS plugin defaults to it — and the damage compounds silently: rankings for the old URL slowly decay because Google isn't crediting the new URL, while the new URL never accumulates the authority it should have inherited immediately. According to Google's own documentation on redirects, 301s are the correct choice whenever a page has moved for good. Reserve 302s for genuinely temporary situations — a page down for maintenance, an A/B test, a seasonal redirect you intend to reverse.

Never Redirect Everything to the Homepage

When a site migration goes wrong, the fallback instinct is often "just redirect anything broken to the homepage." Don't do this. Google explicitly treats mass redirects to an unrelated page — especially the homepage — as a soft 404: the server claims the page exists (a 301 with a 200 destination), but the destination has nothing to do with what the user or crawler was looking for. Soft 404s get flagged in Search Console, waste crawl budget, and pass little to no real value, because Google can tell the redirect destination isn't a legitimate substitute for the missing content.

The correct approach is always to redirect each old URL to its closest genuine equivalent — the same product under a new URL, the merged article that now covers that topic, the new category page that replaced the old one. If no reasonable equivalent exists anywhere on the site, it is more honest, and often better for SEO, to let that URL return a real 404 (or a 410 Gone if it's permanently retired) than to fake a redirect to an unrelated page.

Avoid Redirect Chains

A redirect chain happens when URL A redirects to URL B, which itself redirects to URL C. Each additional hop adds latency for the visitor, adds a small amount of diluted link equity, and adds one more point where something can break. Over years of site changes, chains build up invisibly — a page redirected during one migration gets redirected again during the next, and nobody goes back to update the original rule to point straight at the final destination. Periodically audit your redirect rules and update any old rule that now points to another redirect, so it points directly at the final live URL instead.

Forcing HTTPS and WWW Consistency

Every site should serve exactly one canonical version of every URL — not four (http/https × www/non-www). Mixed signals across those four variants split link equity, confuse search engines about which version is canonical, and can create duplicate content issues. The "Force HTTPS" and "Force www" (or "Remove www") options in this generator write the RewriteCond/RewriteRule pairs that collapse all variants into one, using a 301 so the consolidation is treated as permanent. Apache's own mod_rewrite documentation is the authoritative reference for the syntax these rules are built on.

Backing Up Before You Touch .htaccess

A single typo in .htaccess — a missing closing bracket, an unescaped special character in a regex, a rule referencing a module that isn't enabled — can cause an Internal Server Error (500) across your entire site, not just the page you were trying to redirect. Before pasting any generated rules, download a copy of your current .htaccess file so you can instantly restore it if something breaks. After uploading new rules, load a few pages of your site immediately, including the homepage, to confirm the site is still up before moving on to anything else.

Where Redirect Rules Belong in the File

Order matters in .htaccess. Apache reads rules from top to bottom and, for mod_rewrite rules with the [L] flag, stops processing further rewrite rules once a match is found and applied. If you're adding redirects to a file that already has an existing RewriteEngine On block — common on WordPress sites, which insert their own permalink rewrite rules — don't create a second, separate RewriteEngine On declaration lower in the file. Instead, paste new RewriteCond/RewriteRule pairs directly underneath the existing RewriteEngine On line, above the rules the CMS manages, so your redirects are evaluated first. Simple Redirect 301 lines (mod_alias syntax, not mod_rewrite) are less order-sensitive and can typically go anywhere near the top of the file.

Testing Redirects Properly

Don't rely on your browser alone to confirm a redirect works — browsers cache redirects aggressively, especially 301s, which can make a broken rule look like it's still working correctly for days after you've tried to fix it. Test in a private/incognito window, or better, use a command-line tool like curl -I https://example.com/old-page/ to see the raw HTTP response headers, including the status code (301 vs. 302 vs. 200 vs. 500) and the exact Location header the server is sending. This confirms precisely what search engines and other automated tools will see, independent of any caching in your own browser.

Redirects and Query Strings

A detail that trips up a lot of otherwise correct redirect rules: by default, a basic RewriteRule does not automatically carry over query string parameters (the part of a URL after a ?) from the old URL to the new one. If your old URLs relied on tracking parameters, filters, or session data in the query string that still need to reach the destination, you generally need the [QSA] (Query String Append) flag added to the rule. Left off when it's needed, visitors following a link with tracking parameters can land on the new page having silently lost that data — usually invisible in casual testing, but a real problem for analytics and campaign attribution at scale.

Common Mistakes to Avoid

• Using 302 for a permanent move. It withholds link equity from the new URL and keeps the old one lingering in the index.
• Mass-redirecting broken URLs to the homepage. Google treats this as a soft 404 and it wastes crawl budget.
• Not backing up .htaccess first. A syntax error can bring down the whole site with a 500 error.
• Building redirect chains. Always point a rule at the final live URL, not at another redirect.
• Forgetting trailing slashes. /page and /page/ can behave differently depending on server config — be consistent.
• Not testing after deployment. Visit the redirected URLs directly and confirm both the destination and the status code are correct.

Related Free Tools From Arb Digital

Once your redirects are live, make sure moved pages are properly discoverable with the XML sitemap generator and correctly referenced in your robots.txt generator. Confirm your new URLs are getting indexed with the Google cache checker, review on-page tags with the meta tag generator, add structured data with the schema markup generator, or browse our full free online tools hub.

Frequently Asked Questions