.htaccess Redirect Generator
An htaccess redirect generator writes the Apache rules that send visitors — and search engines — from an old URL to a new one, without you memorizing flag syntax. Enter the old path and the new destination, pick permanent (301) or temporary (302), and get a rule ready to drop into .htaccess. This guide covers which status code to choose, where rules must sit, and the mistakes that cause redirect loops.
301 vs 302 vs 307 vs 303: which status code?
This generator offers 301 and 302 — the two codes used for page redirects. The wider family is worth knowing so you can recognize the others in the wild:
| Code | Meaning | Cached? | Use it when… |
|---|---|---|---|
| 301 | Moved Permanently | Yes — aggressively | A page moved for good; passes ranking signals to the new URL. |
| 302 | Found (temporary) | No | A short-term move — maintenance pages, A/B tests. |
| 307 | Temporary Redirect | No | A temporary move that must preserve the request method (form POSTs). |
| 303 | See Other | No | After a form POST, send the browser to a thank-you page via GET. |
| 308 | Permanent Redirect | Yes | A permanent move that must preserve the request method. |
Rule of thumb: content moved forever → 301. Anything temporary → 302. Choosing 302 "just to be safe" for a permanent move is the most common SEO mistake — search engines keep indexing the old URL instead of transferring its signals.
Rule order matters
Apache reads .htaccess top to bottom and applies the first matching rule, so list specific redirects before general ones — /blog/old-post before a blanket /blog/ rule. With RewriteRule, the [L] flag stops further processing once a rule matches. One more placement rule for WordPress: custom redirects must go above the # BEGIN WordPress block, or WordPress's own front-controller rules will swallow the request first.
# Your redirects go here — BEFORE the WordPress block
Redirect 301 /old-page /new-page
# BEGIN WordPress
# ...
Common mistakes
- Redirect chains. A → B → C forces extra round trips and leaks ranking signals. Point every old URL at its final destination.
- Redirect loops. A → B combined with B → A — often from conflicting www/non-www rules — makes the page unloadable. Test both directions.
- Mixing Redirect and RewriteRule on the same paths. They belong to different Apache modules that execute in different phases, so the order you see in the file is not necessarily the order they run. Note that this tool emits both — mod_alias
Redirectfor your simple rules andmod_rewritefor HTTPS/www canonicalization — so keep them on different paths and pick one mechanism per redirect. - Prefix-matching surprises.
Redirect 301 /sale /new-salealso redirects/sale/item-1, because mod_alias matches path prefixes. UseRewriteRulewith anchors when you need an exact match. - Editing without a backup. A single typo in
.htaccessreturns a 500 error for the entire site. Download a copy before touching it.
Testing checklist
- Run
curl -I https://example.com/old-pageand confirm the status code (301/302) plus aLocation:header pointing at the right destination. - Test the www and non-www variants — this tool can generate the canonicalization rules for you.
- Clear your browser cache or use a private window — 301s are cached aggressively and a stale test will lie to you.
- After a migration, inspect the old URL in Search Console to confirm Google sees the 301.
How to use it
- Enter the old path and the new destination for each rule — click "Add another redirect" for bulk jobs; each row gets its own 301/302 dropdown and remove control.
- Turn on Force HTTPS and pick a www handling option if you want canonicalization rules added automatically.
- Copy the generated block and paste it into your site's
.htaccessfile, above any existing rewrite rules — for WordPress sites, that means above the# BEGIN WordPressblock — then test with the checklist above.
How it works
Simple redirects use Apache's mod_alias Redirect directive. HTTPS and www canonicalization use mod_rewrite conditions, since they need to check the current protocol and host before deciding whether to redirect.
Limitations
This assumes your host runs Apache with mod_rewrite and mod_alias enabled, which is standard on Hostinger-style shared hosting. It won't help if your host uses Nginx instead, which reads a different configuration format entirely.
Back up .htaccess first
Before pasting any generated rule, download a copy of your current .htaccess. If a rule misbehaves — a loop, a 500 error, a wrong destination — restoring the backup takes seconds, while debugging a live broken file under pressure does not. Test every rule with curl -I immediately after saving.
Frequently asked questions
- 301 or 302 — which should I use?
- Use 301 (permanent) when a page has moved for good — search engines will transfer its ranking to the new URL. Use 302 (temporary) if the move might be reversed, like during a short-term promotion.
- Where does this code go?
- Into the .htaccess file in your site's root folder (the same place as index.php). If the file doesn't exist yet, you can create a plain text file named exactly .htaccess.
- Will this break my site if I get it wrong?
- A bad rewrite rule can cause errors, so always keep a backup of your existing .htaccess before pasting in new rules, and test on a staging copy if you have one.
- Does this handle rewriting query strings?
- No — this generator covers simple path-to-path and path-to-URL redirects plus HTTPS/www canonicalization. Complex query-string rewriting needs hand-written mod_rewrite rules.
- Where do I put redirect rules in .htaccess on WordPress?
- Above the # BEGIN WordPress block. WordPress's own rules route every request through index.php, so anything placed below them never gets evaluated for pretty URLs. Your custom redirects must come first in the file, and always keep a backup of .htaccess before editing.
- What is a redirect chain and why should I avoid it?
- A chain is an old URL redirecting to an intermediate URL that redirects again to the final destination. Each hop adds latency and each hop loses some ranking signal. The fix is simple: point every old URL directly at its final destination, and re-check for chains after every migration.