Redirection Rules Generator

Redirection Rules Generator - Create Redirects for Any Platform

URL redirects are how the web survives change without breaking. Whenever a site changes domain, restructures its URL scheme, retires a product page, or migrates from HTTP to HTTPS, every existing bookmark, search-engine link, social-media share, email signature, and third-party citation pointing to the old URL must either continue to work or you lose that traffic, that ranking, and that authority forever. The redirect — a small server response that says 'this address has moved, go to that one' — is the cheapest insurance policy in web operations. This generator produces production-ready redirect configuration for the three platforms most operators actually need: Apache (.htaccess with RewriteRule/Redirect directives), Nginx (server-block return/rewrite directives), and Netlify (the simple _redirects file syntax used by every JAMstack and static-hosting platform). It supports all four standard HTTP redirect status codes: 301 (permanent, transfers SEO authority — the right choice for ~95% of cases), 302 (temporary, no SEO transfer — for maintenance pages and A/B tests), and the newer method-preserving 307/308 (essential for API endpoints where POST/PUT must remain POST/PUT after the redirect). Bulk import lets you paste a CSV-like list of old/new/code triples from a spreadsheet, then download a complete config file ready to upload. The generated rules are syntactically correct — no typos, no missing flags, no escaped characters that should not be escaped.

What are URL redirects?

URL redirects automatically send visitors from one URL to another. When someone visits the old URL, the server responds with a redirect status code and the new URL location.

**Why use redirects?**

• Site Migration: Moving to a new domain or platform
• URL Changes: Restructuring your site URLs
• SEO Preservation: Maintain search rankings from old pages
• Duplicate Content: Consolidate multiple URLs to one canonical version
• Broken Links: Fix 404 errors by redirecting to relevant pages
• HTTPS Enforcement: Redirect HTTP to HTTPS
• WWW Consistency: Force www or non-www URLs

**Common scenarios:**

1. **Rebranding:** oldsite.com → newsite.com
2. **Content moved:** /blog/post → /articles/post
3. **Product URLs:** /products/123 → /shop/item-123
4. **Deleted pages:** /old-page → /relevant-new-page
5. **URL cleanup:** /page.html → /page

Redirects are essential for maintaining user experience and preserving SEO value when URLs change.

What's the difference between redirect types?

**301 - Permanent Redirect**

**When to use:**
• Content has permanently moved
• Site migration or domain change
• Consolidating duplicate content
• Permanently restructuring URLs

**SEO Impact:**
• Passes 90-99% of link equity (PageRank)
• Search engines update their index
• Old URL removed from search results over time
• Best for SEO when making permanent changes

**Browser behavior:**
• Heavily cached by browsers
• Future visits may go directly to new URL without hitting server

**302 - Temporary Redirect**

**When to use:**
• Temporary page maintenance
• A/B testing
• Seasonal content
• Temporary promotions
• Content temporarily unavailable

**SEO Impact:**
• Does NOT pass link equity
• Search engines keep original URL in index
• Use when you plan to restore the original URL

**307 - Temporary (Method Preserved)**

**When to use:**
• Same as 302, but preserves HTTP method
• Important for POST requests
• Modern alternative to 302

**Difference from 302:**
• 302: Browser may change POST to GET
• 307: Browser must preserve POST method

**308 - Permanent (Method Preserved)**

**When to use:**
• Same as 301, but preserves HTTP method
• For APIs and POST endpoints
• Modern alternative to 301

**Difference from 301:**
• 301: Browser may change POST to GET
• 308: Browser must preserve POST method

**Quick Guide:**

| Type | Duration | SEO Value | Caching | Use Case |
|------|----------|-----------|---------|----------|
| 301 | Permanent | Transfers | Heavy | Site migration, permanent moves |
| 302 | Temporary | None | Light | Maintenance, testing |
| 307 | Temporary | None | Light | POST requests, API temp redirects |
| 308 | Permanent | Transfers | Heavy | POST requests, API permanent moves |

**Best practices:**
• Use 301 for permanent changes (99% of cases)
• Use 302/307 only for truly temporary redirects
• For normal page redirects, 301/302 are sufficient
• For API endpoints with POST, consider 307/308

How do I use this redirect generator?

**Step-by-step guide:**

**1. Select Your Server/Platform**

Choose from:
• **Apache** - For most shared hosting, cPanel, traditional servers
• **Nginx** - For VPS, dedicated servers, modern hosting
• **Netlify** - For Netlify-hosted static sites

**2. Add Your Redirects**

For each redirect:
• **From:** Old URL path (e.g., /old-page)
• **To:** New URL path or full URL (e.g., /new-page or https://newsite.com/page)
• **Type:** Choose redirect type (301, 302, 307, 308)

Click "Add Redirect" for multiple redirects.

**3. Bulk Import (Optional)**

For many redirects, use bulk import:
```
/old-page /new-page 301
/another-old /another-new 301
/temp /temporary 302
```

Format: `/from /to [type]`
One redirect per line.

**4. Generate Rules**

Click "Generate Rules" to create configuration.

**5. Copy or Download**

• Click "Copy" to copy to clipboard
• Click "Download" to save as file

**6. Install on Your Server**

**Apache:**
• Paste into .htaccess file in website root
• Upload via FTP or file manager

**Nginx:**
• Add to server block in nginx.conf
• Test: `sudo nginx -t`
• Reload: `sudo nginx -s reload`

**Netlify:**
• Save as `_redirects` file (no extension)
• Place in publish directory
• Deploy site

**7. Test Your Redirects**

• Visit old URLs in browser
• Check they redirect to new URLs
• Verify redirect type (use browser dev tools Network tab)
• Test on incognito/private mode

**Tips:**
• Start with a few redirects to test
• Always backup before modifying config files
• Use 301 for permanent moves (most common)
• Test thoroughly before large-scale deployment

Apache vs Nginx vs Netlify - Which should I use?

**Apache (.htaccess)**

**Best for:**
• Shared hosting (cPanel, Plesk)
• WordPress sites
• Traditional web hosting
• When you don't have root access
• Per-directory configuration

**Advantages:**
• No server restart needed
• Easy to modify (just edit .htaccess)
• Most shared hosting supports it
• Per-directory rules
• Widely documented

**Disadvantages:**
• Slight performance overhead
• Must be enabled by host (AllowOverride)

**Configuration file:** `.htaccess` (in website root)

**Nginx**

**Best for:**
• VPS or dedicated servers
• High-traffic websites
• Modern web applications
• When you have root/sudo access
• Performance-critical sites

**Advantages:**
• Faster performance
• Lower memory usage
• Better for high traffic
• More efficient handling of static files

**Disadvantages:**
• Requires server reload
• Need root access to edit config
• More complex syntax
• Can't do per-directory config like .htaccess

**Configuration file:** `nginx.conf` or site-specific config (usually in `/etc/nginx/sites-available/`)

**Netlify (_redirects)**

**Best for:**
• Static sites on Netlify
• JAMstack applications
• Sites deployed via Git
• Serverless setups

**Advantages:**
• Very simple syntax
• Automatic on Netlify deploy
• No server management needed
• Git-based workflow
• Edge network distribution

**Disadvantages:**
• Only works on Netlify
• Limited to 1000 redirects (or 3000 on paid plans)
• Cannot use with other hosting

**Configuration file:** `_redirects` (in publish directory)

**Quick Decision Guide:**

**Question 1:** Are you on Netlify?
• Yes → Use Netlify format
• No → Continue to Question 2

**Question 2:** Do you have root/sudo access?
• Yes → Check Question 3
• No → Use Apache (.htaccess)

**Question 3:** Which web server are you using?
• Run: `curl -I yoursite.com | grep Server`
• Apache or LiteSpeed → Apache format
• Nginx → Nginx format

**Still not sure?**
• Check your hosting control panel (cPanel = Apache)
• Contact your hosting provider
• Most shared hosting = Apache
• Most VPS with manual setup = Nginx

**Can I use multiple?**
No, use only the format for your specific server. Mixing formats won't work and may cause errors.

How do redirects affect SEO?

Redirects have significant SEO implications. Here's what you need to know:

**301 Redirects and SEO**

**Positive impacts:**
• Passes 90-99% of link equity (PageRank) to new URL
• Preserves backlinks and domain authority
• Consolidates duplicate content
• Maintains search rankings (when done correctly)
• Tells search engines the move is permanent

**Best practices:**
• Use 301 for permanent moves
• Redirect to most relevant page
• Update internal links instead of redirecting
• Avoid redirect chains (A→B→C)
• Keep redirects in place for at least 1 year

**302 Redirects and SEO**

**Impacts:**
• Does NOT pass link equity
• Original URL stays in search index
• Search engines may show original URL
• Use only for temporary situations

**Common mistakes:**
• Using 302 when you mean 301
• Leaving 302 in place permanently
• Using for site migrations (wrong!)

**Redirect Chains**

**What are they?**
Multiple redirects in sequence: A → B → C → D

**Why they're bad:**
• Slower page load times
• Link equity dilution
• Search engines may stop following chain
• Poor user experience
• Wastes crawl budget

**Solution:**
• Always redirect to final destination
• Audit and fix chains regularly
• Update old redirects when URLs change again

**Redirect Best Practices for SEO**

**1. Choose the right redirect type**
• Permanent move? → 301
• Temporary? → 302
• When in doubt → 301

**2. Redirect to relevant content**
• Bad: /product-123 → /homepage
• Good: /product-123 → /new-product-123
• Best: /product-123 → /products/category/similar-item

**3. Update internal links**
• Don't rely on redirects for internal navigation
• Update links in your content and menus
• Redirects should mainly handle external/old links

**4. Avoid redirect loops**
• A → B → A = infinite loop
• Breaks site and confuses search engines

**5. Monitor in Google Search Console**
• Check for redirect errors
• Monitor crawl stats
• Watch for unexpected redirects

**6. Keep redirects forever (or at least 1+ year)**
• Backlinks may stay active for years
• Search engines need time to update
• Removing too soon = lost SEO value

**Site Migration Checklist**

When moving entire site:

1. ✓ Create redirect map (old URL → new URL)
2. ✓ Use 301 redirects
3. ✓ Redirect 1:1 (page to page, not all to homepage)
4. ✓ Update internal links
5. ✓ Update sitemap.xml
6. ✓ Update Google Search Console
7. ✓ Monitor rankings and traffic
8. ✓ Keep redirects in place permanently

**Common SEO Mistakes**

❌ Redirecting everything to homepage
❌ Using 302 for site migration
❌ Creating redirect chains
❌ Not updating internal links
❌ Removing redirects too soon
❌ Not monitoring post-migration

**Expected SEO Impact Timeline**

• **Week 1-2:** Search engines discover redirects
• **Week 3-4:** Index starts updating
• **Month 2-3:** Most changes reflected
• **Month 3-6:** Full migration complete

**Note:** Rankings may fluctuate during this period. This is normal. Maintain redirects and monitor closely.

How do I redirect an entire old domain to a new domain while preserving paths?

Use a single wildcard rule that captures the path and appends it to the new domain. This is the cleanest 1:1 migration and the only acceptable pattern for SEO.

Apache (.htaccess on oldsite.com):
RewriteEngine On
RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L]

Nginx (server block for oldsite.com):
server {
server_name oldsite.com www.oldsite.com;
return 301 https://newsite.com$request_uri;
}

Netlify (_redirects):
https://oldsite.netlify.app/* https://newsite.com/:splat 301!

Why this matters: '/blog/my-post' on the old domain becomes '/blog/my-post' on the new domain, not '/'. If you redirect everything to the homepage instead, you lose every individual page's SEO authority (each page resets to zero) and frustrate every user who clicked a deep link expecting the actual content. Pair this with a freshly submitted sitemap.xml on the new domain and Search Console's 'Change of address' tool to speed Google's reindexing.

How do I write a wildcard / path-capturing redirect for each platform?

A wildcard redirect forwards every URL under a path to the matching URL under a new path (1:1), which is the SEO-correct way to move a whole section instead of collapsing every deep link to one page. In this tool, end the 'From' with '/*' and the 'To' with '*' — for example '/blog/*' → '/articles/*' — and each format is translated correctly:

**Apache (.htaccess)** uses a captured group and a $1 backreference:
RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L]
The '(.*)' captures everything after the prefix; '$1' re-inserts it. A literal '*' in a RewriteRule means 'zero-or-more of the previous character', NOT 'any path', which is why a bare '*' fails.

**Nginx** uses a rewrite with the same capture, and the flag maps to the code (301/308 → permanent, 302/307 → redirect):
rewrite ^/blog/(.*)$ /articles/$1 permanent;
For a whole-host move use the request URI instead:
location / { return 301 https://newsite.com$request_uri; }

**Netlify (_redirects)** uses ':splat' on the destination (a bare '*' on the right side is invalid):
/blog/* /articles/:splat 301

**Query strings:** Apache appends [QSA] (Query String Append) to keep '?utm=...' on the destination; Nginx preserves the query automatically with rewrite, or use $request_uri (path + query) instead of $uri (path only); Netlify matches query parameters with a 'from' like '/search id=:id' and reuses ':id' on the destination. Always confirm whether you need the query string carried over before deploying.

Why does HSTS make redirects 'sticky' and what should I know?

When you redirect HTTP to HTTPS and also send the Strict-Transport-Security header on the HTTPS response (e.g., 'max-age=31536000; includeSubDomains'), the browser remembers that your domain is HTTPS-only for the specified duration — even if you later remove the redirect, the browser will refuse to make an HTTP request at all. This is a great security feature but can bite you in two ways. (1) If you accidentally set max-age too high (years) and later need to roll back HTTPS for any reason, every user who visited during that window is locked out of the HTTP version until their max-age expires. (2) If you preload HSTS via hstspreload.org, removal requires waiting months for major browsers to ship updated preload lists. Start max-age small (300 seconds for testing, then 86400 for a week, then a year) so you have a rollback window. Only add the 'preload' directive once you're confident your entire site (and all subdomains, if includeSubDomains is set) will serve HTTPS forever.

Common redirect mistakes and how to avoid them

**1. Redirect Chains**

**Problem:** Multiple redirects in sequence
• /page1 → /page2 → /page3 → /page4

**Why it's bad:**
• Slow page loads (each redirect adds delay)
• SEO link equity dilution
• Search engines may stop following
• Wastes server resources

**Solution:**
• Always redirect to final destination
• Audit existing redirects regularly
• Use redirect checker tools
• Update old redirects when URLs change

**2. Redirect Loops**

**Problem:** Circular redirects
• /page-a → /page-b → /page-a

**Result:**
• "Too many redirects" error
• Site completely breaks
• Terrible user experience

**Solution:**
• Test redirects before deploying
• Use redirect testing tools
• Check for conflicting rules
• Clear browser cache when testing

**3. Using Wrong Redirect Type**

**Problem:** Using 302 for permanent moves

**Impact:**
• Lost SEO value (no link equity transfer)
• Search engines keep old URL
• Rankings may drop

**Solution:**
• Use 301 for permanent moves
• Use 302 only for truly temporary situations
• Audit existing redirects
• Fix 302s that should be 301s

**4. Redirecting All Pages to Homepage**

**Problem:** Site migration that redirects everything to /

**Why it's bad:**
• Terrible user experience
• Loss of SEO value
• High bounce rate
• Looks like spam to search engines

**Solution:**
• Create 1:1 redirect mapping
• Redirect to most relevant page
• Maintain URL structure if possible
• If no equivalent, redirect to related category

**Example:**
❌ Bad: /products/shoes/nike-air → /
✓ Good: /products/shoes/nike-air → /shop/shoes/nike-air
✓ Acceptable: /products/shoes/nike-air → /shop/shoes (if specific product gone)

**5. Not Testing Redirects**

**Problem:** Deploying without testing

**Can cause:**
• Broken site
• Lost traffic
• SEO damage
• Customer complaints

**Solution:**
• Test on staging server first
• Use redirect checker tools
• Test in multiple browsers
• Check in incognito mode (avoids cache)
• Verify redirect type (use browser dev tools)
• Test mobile and desktop

**6. Not Updating Internal Links**

**Problem:** Relying on redirects for internal navigation

**Why it's bad:**
• Slower page loads
• Unnecessary server load
• Search engine crawl waste
• Poor user experience

**Solution:**
• Update links in your content
• Fix menu/navigation links
• Update sitemap.xml
• Use redirects for external/old links only

**7. Removing Redirects Too Soon**

**Problem:** Deleting redirects after a few months

**Impact:**
• Broken backlinks
• Lost SEO value
• 404 errors
• Lost traffic from old bookmarks/links

**Solution:**
• Keep redirects for at least 1 year
• Preferably keep them forever
• Monitor traffic to redirected URLs
• Only remove if truly no traffic

**8. Mixed Content After HTTPS Redirect**

**Problem:** Forcing HTTPS but loading HTTP resources

**Result:**
• "Not Secure" warnings
• Broken images/CSS/JS
• Poor user experience
• SEO penalties

**Solution:**
• Update all internal links to HTTPS
• Check images, CSS, JS, fonts
• Use relative URLs (//domain.com or /path)
• Scan for mixed content

**9. Conflicting Redirect Rules**

**Problem:** Multiple rules affecting same URL

**Causes:**
• Old .htaccess sections not removed
• Conflicting CMS redirects
• Multiple redirect plugins (WordPress)

**Solution:**
• Remove old redirect rules
• Audit entire .htaccess/config
• Use only one redirect method
• Document all redirects

**10. Not Monitoring After Implementation**

**Problem:** Set and forget approach

**Missed issues:**
• Redirect errors
• Traffic drops
• Ranking losses
• User complaints

**Solution:**
• Monitor Google Search Console
• Check server logs
• Track 404 errors
• Monitor traffic and rankings
• Set up alerts for issues

**Pre-Deployment Checklist**

✅ Backup current config
✅ Test on staging server
✅ Check for redirect chains
✅ Verify no redirect loops
✅ Confirm redirect types (301 vs 302)
✅ Test all redirects manually
✅ Check mobile and desktop
✅ Verify HTTPS/HTTP handling
✅ Update internal links
✅ Update sitemap
✅ Prepare rollback plan

**Testing Tools**

• Redirect Checker (httpstatus.io)
• Screaming Frog SEO Spider
• Google Search Console
• Browser Developer Tools (Network tab)
• curl command: `curl -I yoursite.com/old-page`

Key Features

• Generate redirects for Apache, Nginx, and Netlify
• Wildcard path-preserving rules (Apache $1, Nginx rewrite, Netlify :splat)
• Duplicate-source and redirect-loop warnings before you deploy
• Support for 301, 302, 307, and 308 redirect types
• Easy-to-use visual redirect editor
• Bulk import for multiple redirects
• Load sample redirects for quick testing
• Real-time rule generation
• Copy to clipboard with one click
• Download as .htaccess, nginx.conf, or _redirects file
• Clear installation instructions for each platform
• Automatic syntax formatting
• No registration required
• 100% free tool
• Works offline after page load
• Mobile-friendly interface
• SEO-friendly redirect configurations