Htaccess Redirect Generator Free Tool
About Htaccess Redirect Generator
What the Htaccess Redirect Generator Does
The Htaccess Redirect Generator builds the exact .htaccess directives you need to redirect one URL to another on an Apache web server, without requiring you to memorize Apache's mod_rewrite or mod_alias syntax. You fill in a source URL (or pattern) and a destination URL, choose a redirect type — typically 301 (permanent) or 302 (temporary) — and the tool outputs ready-to-paste code such as a Redirect directive or a RewriteRule block. You copy that output into your site's .htaccess file, save it, and the redirect is live the moment Apache reads the updated file. No server restart is required because .htaccess is read per-request (or cached briefly, depending on server configuration).
This matters because Apache is still one of the most widely deployed web servers, and a large share of shared hosting environments (cPanel, WHM-based hosts, many CyberPanel/LiteSpeed setups running Apache-compatible rewrite rules, and classic LAMP stacks) rely on .htaccess as the primary mechanism for URL rewriting and redirection at the directory level. If you manage a site on one of these hosts and don't have root access to edit the main Apache configuration (httpd.conf), .htaccess is often the only place you can define redirects at all.
Why Redirects Matter for SEO and Site Management
Redirects are not just a convenience feature — they are one of the more consequential technical SEO tools available to a webmaster, because they control how both users and search engine crawlers resolve a URL that has moved, changed, or been retired. Get them wrong and you risk broken links, lost link equity, duplicate content penalties, and frustrated visitors landing on 404 pages. Get them right and you preserve rankings, consolidate signals to the correct URL, and keep your site's link graph clean.
Common scenarios where a properly written .htaccess redirect is the correct fix:
- You migrated a page from
/old-page.htmlto/new-page/and need the old URL to forward visitors and link equity automatically. - You changed domains (e.g., from
oldsite.comtonewsite.com) and need every URL on the old domain to map to its equivalent on the new one. - You want to force
https://instead ofhttp://, or enforce a single canonical version of your domain (wwwvs. non-www). - You restructured your URL slugs (changed a category path, renamed a product, flattened a folder structure) and the old paths are still indexed or linked externally.
- You retired an entire section of the site and want visitors redirected to a relevant hub page instead of hitting a dead end.
- You're consolidating duplicate content — two URLs serving near-identical content — into one canonical URL.
In every one of these cases, the alternative to a proper server-side redirect is either a client-side JavaScript redirect (which search engines treat as a weaker signal and which delays the redirect for real users) or doing nothing, which leaves a 404 or a dead link in place. Server-side 301 redirects, issued directly by Apache before any page content is even served, are the standard-recommended approach for permanent URL changes because they pass link signals to the destination URL and update how the URL is stored in a crawler's index over time.
How to Use the Htaccess Redirect Generator: Step by Step
- Choose your redirect type. Decide whether this is a permanent change (301) or a temporary one (302). If you're not sure, default to 301 for anything you expect to be permanent — see the comparison table below for the distinction.
- Enter the source path. This is the old URL or pattern that visitors and bots currently hit. Depending on the tool's mode, this can be a single exact path (e.g.
/old-page.html) or a pattern with a wildcard for redirecting a whole folder or a group of similar URLs. - Enter the destination URL. This is where you want traffic to land — either a relative path on the same domain (e.g.
/new-page/) or a full URL if you're redirecting to a different domain (e.g.https://newsite.com/new-page/). - Select single-URL vs. whole-site/domain redirect if the tool offers that option. A single-URL redirect maps one old path to one new path. A domain-level redirect (using mod_rewrite with a condition on
%{HTTP_HOST}) forwards every request from an old domain to the equivalent path on a new one. - Generate the code. The tool outputs a block of Apache directives — either simple
Redirect/RedirectMatchlines (mod_alias) or aRewriteEngine OnplusRewriteCond/RewriteRuleblock (mod_rewrite), depending on the complexity of what you asked for. - Open your site's
.htaccessfile. This file lives in your site's root directory (or, in rarer cases, in a subdirectory if you're scoping the redirect to a specific folder). Access it via FTP/SFTP, your hosting control panel's file manager, or SSH. - Back up the existing file first. Download a copy of the current
.htaccessbefore editing it. If a new rule is malformed, Apache can return a 500 Internal Server Error for the entire site, and having the previous working version to restore from saves you a stressful debugging session. - Paste the generated code near the top of the file, generally above any existing
RewriteEngine Onblock if one already exists (you should only have a singleRewriteEngine Online per file — if the tool generates one and your file already has one, remove the duplicate). - Save and test. Load the old URL in a browser (ideally in an incognito/private window to avoid cached redirects) and confirm it lands on the intended destination with the expected status code.
301 vs. 302 vs. 307: Picking the Right Status Code
Redirect type is the single most consequential choice you make when generating a rule, because it tells both browsers and search engine crawlers how to treat the change. Below is a quick reference.
| Status Code | Meaning | When to Use | SEO Effect |
|---|---|---|---|
| 301 | Moved Permanently | The old URL is gone for good; the new URL is its permanent replacement (page moved, domain migration, slug restructure). | Link signals and indexing are consolidated to the destination URL over time; browsers and crawlers cache this redirect. |
| 302 | Found (Temporary) | The move is temporary — A/B testing, seasonal content, maintenance pages, or a page you expect to restore later at the original URL. | Search engines are told to keep the original URL indexed rather than replacing it, since the change isn't meant to be permanent. |
| 307 | Temporary Redirect (strict) | Same intent as 302, but guarantees the request method (GET, POST, etc.) is preserved exactly — relevant for form submissions or API calls. | Same as 302 in terms of indexing behavior; the distinction matters mainly for non-GET requests. |
| 410 | Gone | Not a redirect at all — used when content is deliberately and permanently removed with no replacement. | Signals to crawlers that the URL should be dropped from the index rather than re-checked indefinitely. |
Most redirect requests generated for SEO purposes — page moves, domain changes, URL restructures — should be 301s. Reach for 302 only when the change genuinely isn't permanent, since defaulting to 302 for a permanent move is a common mistake that delays the consolidation of ranking signals to the new URL.
Types of Redirect Rules the Tool Can Produce
Depending on what you're trying to accomplish, the generator can output several different flavors of Apache directive:
- Simple single-page redirect (mod_alias) — a one-line
Redirect 301 /old-page.html /new-page/that maps exactly one path to another. Fast, simple, and sufficient for one-off page moves. - Pattern-based redirect (RedirectMatch) — uses a regular expression to catch a group of similar URLs, e.g. redirecting every URL under
/blog/2019/to a corresponding path under/archive/2019/. - Full domain/host redirect (mod_rewrite) — a
RewriteCondchecking%{HTTP_HOST}combined with aRewriteRulethat forwards the entire domain (and every path on it) to a new domain, preserving the requested path. - Force HTTPS redirect — a rule checking
%{HTTPS}or%{SERVER_PORT}and forcing any plain HTTP request to its HTTPS equivalent. - Force www or non-www — a rule that standardizes every request to either always include or always exclude the
wwwsubdomain, which is a common canonicalization fix. - Trailing slash normalization — a rule that adds or strips a trailing slash so that
/pageand/page/don't exist as two separately crawlable URLs. - Folder or subdirectory redirect — redirects everything under one folder path to a different folder path while preserving the rest of the URL structure.
Simple mod_alias Redirect directives are easier to read and debug, but they match on the beginning of a path rather than full patterns. mod_rewrite gives you far more control — conditional logic, regex capture groups, query-string handling — at the cost of more complex syntax. The generator's job is to spare you from writing that regex by hand while still producing a rule that follows correct Apache syntax.
Where the .htaccess File Lives and How It's Processed
The .htaccess file sits in the root directory of your website (the same folder as your homepage's index.html or index.php) unless you deliberately place a secondary one in a subdirectory to scope rules to just that folder. It's a plain text file — no special extension, just a dot-prefixed filename, which is why it's often hidden by default in file managers and FTP clients (you may need to enable "show hidden files" to see it).
Apache reads .htaccess on every request to the directory it's in (and its subdirectories, unless overridden), which is what makes it convenient: no reload or restart needed, edits take effect immediately. The tradeoff is a small performance cost, since Apache has to check for and parse this file on every request — a cost most sites never notice, but one of the reasons some higher-traffic Apache deployments move frequently-used rules into the main server config instead, where AllowOverride settings permit it.
One prerequisite worth flagging: for any RewriteRule-based redirect to work, mod_rewrite must be enabled on the server and AllowOverride must permit rewrite directives in .htaccess for that directory. Nearly all shared hosting providers enable this by default because so much software (WordPress, most CMS platforms) depends on it, but if you're on a custom VPS setup and redirects aren't taking effect, this is the first thing to check.
Common Mistakes and How to Avoid Them
| Mistake | Why It's a Problem | Fix |
|---|---|---|
| Redirect chains (A → B → C) | Each hop adds latency and dilutes signal clarity; some crawlers stop following after several hops. | Always redirect the original URL directly to its final destination, updating old rules if the destination changes again. |
| Redirect loops (A → B → A) | Causes an infinite loop, resulting in a browser error ("too many redirects") and a completely inaccessible page. | Double-check source and destination paths aren't accidentally identical or pointing back at each other, especially after combining www/https rules. |
| Using 302 for a permanent move | Search engines may keep the old URL as canonical instead of transferring signals to the new one. | Use 301 for anything meant to be permanent. |
Multiple RewriteEngine On lines |
Not strictly fatal, but sloppy and can cause confusion when debugging; some configurations misbehave with duplicates. | Keep a single RewriteEngine On at the top of the mod_rewrite section. |
| Forgetting to preserve query strings | Redirecting /page?id=5 without the QSA (query string append) flag can silently drop URL parameters users or tracking links depend on. |
Add the QSA flag to mod_rewrite rules when query parameters need to survive the redirect. |
| Editing the live file without a backup | A single syntax error in .htaccess can trigger a 500 error across the entire site until fixed. |
Always download/copy the current file before saving changes, and test immediately after publishing. |
Best Practices When Generating and Deploying Redirects
- Redirect to the most specific relevant page, not just the homepage. A generic homepage redirect for every retired page is a weaker experience for users and passes less specific relevance signal than a redirect to the closest matching live content.
- Keep a running log of every redirect you add, especially during a migration involving many URLs — it makes auditing and troubleshooting far easier months later.
- Test each generated rule in a private/incognito browser window immediately after publishing, since browsers aggressively cache 301 redirects and a stale cache can make you think a fix didn't work when it did (or vice versa).
- Group related rules together and comment your
.htaccessfile (Apache ignores lines starting with#) so future edits don't require reverse-engineering what each block does. - When migrating a whole site or domain, prefer a single generic mod_rewrite rule that preserves the path (redirecting
olddomain.com/anythingtonewdomain.com/anything) over hundreds of individual one-to-one rules, unless the URL structure actually changed between old and new sites. - Place redirect rules before any CMS-generated rewrite block (for example, WordPress's default rewrite rules) so they're evaluated first and don't get overridden by later, broader pattern matches.
Limitations to Keep in Mind
The generator produces syntactically correct Apache directives based on the inputs you provide, but it can't account for everything specific to your hosting environment. A few limitations worth understanding before you deploy:
- It assumes you're running Apache (or an Apache-compatible server such as LiteSpeed with
.htaccesssupport enabled). Nginx does not read.htaccessfiles at all — Nginx redirects are configured differently, directly in the server block. - It can't verify that
mod_rewriteormod_aliasis actually enabled on your specific server — that's a hosting-configuration detail outside the tool's visibility. - It won't catch conflicts with existing rules already in your
.htaccessfile (like an existing rule that already matches the same path with different logic). You need to review the full file after pasting in new rules. - Complex, highly conditional redirect logic (redirecting based on user-agent, geographic origin, or multiple combined query parameters) generally requires manual refinement beyond what a generator focused on standard URL-to-URL mapping can produce.
- It doesn't test the live redirect for you — always verify manually after deployment, since the only way to confirm real-world behavior is checking response headers or loading the page directly.
Frequently Asked Questions
Does this tool actually change my website, or just generate code?
It only generates the code. Nothing on your live site changes until you copy the output into your own .htaccess file and save it. This keeps the process safe — you can review, test in a staging copy, or ask a developer to check the rule before it ever touches your production site.
Where exactly do I paste the generated code?
Into the .htaccess file located in your website's root directory, accessible via FTP/SFTP, your hosting control panel's file manager, or SSH. If a RewriteEngine On line already exists in the file, don't duplicate it — place your new RewriteRule or RewriteCond lines within the existing mod_rewrite block instead.
What's the difference between a 301 and a 302 redirect, and which should I choose?
A 301 tells browsers and search engines the move is permanent, which consolidates ranking signals to the new URL over time. A 302 signals a temporary change, so the original URL is kept as the reference point. Use 301 for anything you expect to be permanent — page moves, restructures, domain changes — and reserve 302 for genuinely temporary situations like maintenance pages or short-term tests.
Will this work on my hosting if I'm not using WordPress?
Yes — .htaccess is a server-level feature of Apache, independent of any specific CMS. It works the same way whether your site is built on WordPress, a static HTML site, a custom PHP application, or any other Apache-hosted platform. The one requirement is that your host runs Apache (or an Apache-compatible server with .htaccess support) and has mod_rewrite/mod_alias enabled.
Can I redirect an entire domain to a new domain with one rule?
Yes. A domain-level redirect uses a mod_rewrite condition checking the requested host and a rule that forwards to the new domain while preserving the requested path, so every URL on the old domain maps automatically to the same path on the new one. This is far more efficient than writing a separate rule for every individual page during a domain migration.
My redirect isn't working — what should I check first?
First, clear your browser cache or test in a private/incognito window, since browsers cache 301 redirects aggressively. Second, confirm the rule was actually saved in the correct .htaccess file in your site's root. Third, check that mod_rewrite is enabled on your server if you're using a RewriteRule-based rule — contact your host if you're unsure. Finally, look for a conflicting rule earlier in the file that might be matching the same path first and preventing your new rule from ever being reached.
Is it safe to edit .htaccess directly, or could I break my site?
A malformed .htaccess file can cause a 500 Internal Server Error across your entire site, so it's not entirely risk-free — but the fix is simple as long as you keep a backup. Always download or copy the existing file before making changes, so you can instantly restore it if a new rule causes an error.