The worst hour of a site migration I ever did was spent staring at a 500 error on a live site, and the cause was a single stray character in an .htaccess file. I had hand-written a batch of redirects for a WordPress rebuild, fat-fingered a RewriteRule flag, and Apache responded by refusing to serve the entire domain. The redirects themselves were fine; the syntax around them was not, and .htaccess is unforgiving that way. After that I stopped writing redirect rules by hand and started generating them, which is exactly what the htaccess Redirect Generator on toolz.dev does. This guide covers how Apache redirects work, when to use each type, and how to canonicalize HTTPS and www without breaking anything.
TL;DR: An .htaccess file tells Apache how to redirect URLs. Use a 301 for permanent moves, a 302 for temporary ones,
Redirectfor exact paths, andRewriteRulefor patterns. The htaccess Redirect Generator builds all of these plus force-HTTPS and www rules from a simple list, correctly ordered, entirely in your browser with nothing uploaded.
What is an htaccess redirect generator?
An .htaccess redirect generator turns a plain list of old-to-new URL mappings into the exact Apache directives that perform the redirects. Which status code you pick is a protocol question, not an Apache one: RFC 9110 defines 301 as permanent and 302 as found. The .htaccess file is a per-directory configuration file that Apache reads on every request, and on shared hosting it is usually the only place you can declare redirects, because you cannot edit the main server configuration. The generator writes both flavours of redirect Apache supports: the mod_alias Redirect directive for straightforward one-to-one path changes, and the mod_rewrite RewriteRule directive for pattern matches that catch many URLs at once.
The reason to generate these rather than type them is that .htaccess syntax is precise and punishing. A misplaced flag, an unescaped dot in a pattern, or a rule in the wrong order does not produce a warning; it produces a 500 error that takes the whole site down until you find and fix it. The directives also have to appear in a specific order, with the rewrite engine turned on before any RewriteRule, and site-wide rules ahead of page-level ones, or they misbehave in ways that are hard to debug. A generator encodes that order and syntax so you cannot get it subtly wrong.
On toolz.dev the flow mirrors how you actually think about a migration. You list each old path and its new destination, choose whether the move is permanent or temporary and whether it is an exact path or a pattern, and optionally switch on the two site-wide rules almost every site needs. The tool assembles the whole file in the correct order and flags anything suspicious, such as a rule that redirects a path to itself, before you paste it into your site.
What is the difference between a 301 and a 302 redirect?
A 301 is a permanent redirect and a 302 is a temporary one, and to a search engine that distinction is the whole point. A 301 tells browsers and crawlers that the page has moved for good, and search engines respond by transferring almost all of the old URL's accumulated ranking signals to the new address and eventually dropping the old URL from their index. A 302 tells them the move is temporary, so they keep the original URL indexed and ranked and treat the destination as a stand-in that will go away.
Choosing the wrong one has real consequences. Use a 302 for a permanent move and search engines may keep the old URL ranked while your new page struggles to accumulate its own authority, because the signals never transferred. Use a 301 for something genuinely temporary, like a page that is down for maintenance or a seasonal landing page, and you may permanently lose the ranking of the original once the situation reverts. The rule of thumb is simple: if the old URL is never coming back, use 301; if it is, use 302.
Here is how the two compare on the properties that matter:
| Property | 301 Permanent | 302 Temporary |
|---|---|---|
| Meaning | Page has moved for good | Page is temporarily elsewhere |
| Ranking signals | Transferred to the new URL | Stay with the original URL |
| Old URL in index | Eventually dropped | Kept |
| Typical use | Redesigns, migrations, merged pages | Maintenance, A/B tests, seasonal pages |
| Browser caching | Cached aggressively | Not cached by default |
The generator lets you set the status per rule, so a migration that is mostly permanent moves with one temporary promotional redirect is a single mixed list rather than two files. Because 301s are cached aggressively by browsers, it is worth getting them right the first time; a wrong 301 can persist in a visitor's browser long after you fix the server.
When should I use Redirect versus RewriteRule?
Use the Redirect directive for an exact, one-to-one path change, and a RewriteRule when you need to match a pattern. Redirect 301 /old-page /new-page is the whole rule for moving a single page, and it is readable, hard to get wrong, and handled by Apache's mod_alias module. When you have a handful of specific pages that each moved to a specific new location, a list of Redirect lines is the clearest and safest way to express it.
A RewriteRule earns its complexity when one rule needs to catch many URLs. If every post under /blog/2023/ moved to the same path without the year, writing a Redirect line for each post would be hundreds of rules; a single RewriteRule ^blog/2023/(.*)$ /blog/$1 [R=301,L] handles all of them by capturing the part after the year and reusing it in the destination. The power comes from regular expressions and capture groups, but so does the risk, because an unescaped special character or a greedy pattern can match far more than you intended.
The generator picks the right directive for you based on the match type you choose per rule: exact rules become Redirect lines and pattern rules become RewriteRule lines, with the rewrite engine automatically switched on when any pattern rule is present. It also keeps the two groups in the correct order in the output. If you are new to writing the patterns themselves, the regex tester lets you check a pattern against sample URLs before you trust it in a redirect, which is how I confirm a capture group does what I expect.
How do I force HTTPS in htaccess?
To force HTTPS, you add a rewrite condition that checks whether the current request is not already secure, followed by a rule that redirects to the https version of the same host and path. The standard form checks %{HTTPS} off and then rewrites to https://%{HTTP_HOST}/$1 with a 301, so every plain-HTTP request is permanently upgraded to the encrypted version of the identical URL. Serving a site over both http and https without this redirect means search engines can index two versions of every page, splitting your ranking signals between them.
The subtlety is ordering. The HTTPS rule has to run before any host rewrites, such as adding or removing www, so that those later rules also land on the secure scheme rather than sending a visitor from http to https and then through a second redirect. Getting this wrong produces redirect chains, where a single request bounces through two or three hops before arriving, which is slower for users and dilutes the ranking benefit of the redirect. The generator places the HTTPS rule first for exactly this reason.
Switch on Force HTTPS in the tool and it inserts the correct condition and rule at the top of the output, ahead of your page redirects and www rule. Because HTTPS is now a baseline expectation rather than an optional extra, and browsers increasingly flag plain-http pages as insecure, this is a rule I add to essentially every site. It pairs naturally with the canonical-host rule covered next, and together they settle a site on exactly one address for every page.
How do I redirect www to non-www or the reverse?
You canonicalize the www prefix with a rewrite rule that checks the host and redirects to the version you have chosen. To remove www, you match hosts that start with www., capture the rest, and redirect to the bare domain; to add www, you match hosts that do not start with www. and redirect to the prefixed version. Either way, the goal is that every page is reachable at exactly one canonical host, because serving the same content at both www.example.com and example.com is a classic duplicate-content problem that splits ranking signals just as an unresolved http/https split does.
There is no SEO advantage to www over non-www or the reverse; what matters is that you pick one and enforce it consistently. Large sites historically used www for technical reasons around cookies and subdomains, while many modern sites drop it for brevity. The important thing is that once you choose, every link, every canonical tag, and every redirect points at the same version, so search engines consolidate all your authority onto one host rather than dividing it.
The generator offers a single www setting with three options: leave it unchanged, force www, or remove www. It writes the matching condition and rule and places it after the HTTPS rule so the two cooperate rather than chain. Whichever host you settle on should also be the one in your canonical tags and your sitemap, so it is worth generating your sitemap with the same canonical host and declaring your crawl rules in a matching robots.txt. Consistency across all three is what makes the canonicalization actually stick.
Do these redirects work on Nginx?
No. The .htaccess format is specific to the Apache web server and the servers that deliberately emulate it, most notably LiteSpeed. Nginx does not read .htaccess files at all; it ignores them completely, so pasting Apache directives into an Nginx setup does nothing. Nginx handles redirects with its own return and rewrite directives inside server and location blocks in the main configuration, using a different syntax and a different evaluation model.
This matters because a surprising number of redirect problems come from applying the right rule to the wrong server. If your redirects seem to be ignored no matter what you write, the first thing to check is which web server is actually serving your site, because an .htaccess file on an Nginx host is inert. Managed WordPress hosts in particular sometimes run Nginx in front of or instead of Apache, and there the .htaccess file you carefully edited has no effect.
The generator produces Apache syntax, which covers the large majority of shared hosting and any host running Apache or LiteSpeed. If you are on Nginx, the logic of the rules translates directly, a permanent redirect is still a 301 and a canonical host is still a canonical host, but the syntax must be rewritten for Nginx's directives, which is a job for your host's configuration rather than an .htaccess file. Knowing which server you are on before you start saves the confusion I have watched swallow whole afternoons.
When would I actually use this?
Site migrations are the primary case. Whenever I rebuild a site, whether it is a WordPress project moving to new URL structures or a fresh build replacing an old one, every old URL that had traffic or backlinks needs a 301 to its new home, or that traffic and authority evaporate into 404s. Listing those mappings and generating the redirect block in one pass, correctly ordered and syntactically clean, is far safer than hand-editing a file that can take the site down over one typo. The pattern rules handle whole sections that moved as a group.
Enforcing HTTPS and a canonical host is the everyday case. Even on a site with no page-level redirects, the force-HTTPS and www rules are worth adding to consolidate ranking signals and meet the security baseline browsers now expect. I generate these two rules for essentially every new site and paste them in before launch, so the site is canonical from day one rather than being cleaned up later once duplicate versions have already been indexed.
Cleaning up after the fact rounds it out. Old redirects accumulate, some chain through two or three hops, and some point at pages that have since moved again. Regenerating the whole block from a clean list, with the loop and format warnings the tool provides, is a good way to flatten those chains back to single hops. Redirects are one corner of on-site SEO, and they sit alongside the meta tag generator and the rest of the on-page toolkit; the broader case for keeping this kind of utility in the browser is one I make in the web developer toolkit guide, and the productivity angle in the developer productivity tools guide.
Is my URL data private?
Yes. Every rule is generated in JavaScript inside your browser. The URLs you enter, your domain, and your redirect map are never transmitted, logged, or stored, and the tool keeps working with no network connection once the page has loaded. A redirect map is effectively a diagram of your site's structure and its most valuable pages, and while it is not secret in the way a password is, there is no reason for it to flow through someone else's server just to assemble a text file.
Because the work happens locally, you can plan a migration offline, generate the rules on a laptop with no connection, and paste them in when you are ready, without any part of your site's URL structure leaving the device. That local-first approach is the same one behind every tool on toolz.dev, and it means the tool is as usable on a plane as it is at a desk. The general argument for preferring browser-based tools that never upload your data is one I set out in the data privacy in online tools guide.
FAQ
What is the difference between a 301 and a 302 redirect?
A 301 is a permanent redirect: it tells browsers and search engines the page has moved for good and passes almost all of the old URL's ranking signals to the new one. A 302 is temporary: it forwards visitors but signals that the original URL should keep its ranking and may return. Use 301 for permanent moves and 302 only when the change is genuinely temporary.
Where do I put the htaccess file?
Place the .htaccess file in the root directory of your website, usually the folder that also contains index.php or index.html. Redirects declared there apply to the whole site. The file name begins with a dot and has no extension, and Apache must have AllowOverride enabled for the directory, which most shared hosts configure by default.
When should I use Redirect versus RewriteRule?
Use the mod_alias Redirect directive for a straightforward one-to-one path change, such as /old-page to /new-page. Use a mod_rewrite RewriteRule when you need to match a pattern, for example sending every URL under /blog/2023/ to the same path without the year. This tool emits Redirect for exact rules and RewriteRule for pattern rules automatically.
How do I force HTTPS in htaccess?
Enable Force HTTPS and the generator adds a RewriteCond that checks whether HTTPS is off, followed by a RewriteRule that redirects to the https version of the same host and path with a 301. Placing this rule before your other redirects ensures every request is upgraded to a secure connection first, without chaining through extra hops.
Do these redirects work on Nginx?
No. The .htaccess format is specific to the Apache web server and servers that emulate it, such as LiteSpeed. Nginx does not read .htaccess files and uses its own rewrite and return directives in the server configuration, so you would need to translate these rules into Nginx syntax. Check which server your site runs on before troubleshooting ignored redirects.
Will these redirects hurt my SEO?
Used correctly, redirects protect SEO rather than harm it. A 301 preserves the ranking of a moved page, and canonicalizing HTTPS and www prevents duplicate versions from splitting your signals. The risks come from redirect chains, loops, or redirecting to irrelevant pages, so keep each rule pointing directly at the most relevant destination.
Can one rule redirect many URLs at once?
Yes. Set the rule to pattern mode and use a regular expression in the source field with capture groups, then reference them in the destination with $1, $2, and so on. For example, ^blog/(.*)$ redirected to /articles/$1 moves every page under /blog/ to the matching page under /articles/ with a single rule.
Is my URL data private?
Yes. The rules are generated in your browser with JavaScript. Nothing you enter is uploaded, logged, or stored, and the tool keeps working with no internet connection once the page has loaded. A redirect map describes your site's structure, and with a client-side tool it never leaves your device to assemble the file.
Build your redirects with the free htaccess Redirect Generator. It writes Apache 301 and 302 rules, force-HTTPS, and www canonicalization from a simple list, correctly ordered, entirely in your browser with nothing uploaded.
