301 Redirect Generator

What is a 301 redirect?

A 301 redirect is an HTTP status code a server sends when a page has moved permanently to a new address. When a browser or a search-engine crawler requests the old URL, the server answers with 301 Moved Permanently plus a Location header pointing at the new URL. The browser then automatically requests the new address — usually so fast the visitor never notices anything happened.

That single response does three jobs at once. First, it keeps visitors from hitting dead ends: bookmarks, old emails, and links from other sites keep working. Second, it tells search engines the move is permanent, so Google transfers the old page's ranking signals — backlinks, history, relevance — to the new URL and eventually swaps the old URL for the new one in its index. Third, it is cacheable: browsers are allowed to remember a 301, which makes repeat visits faster but also means a 301 is hard to undo (more on that in the tips below).

When to use a 301 redirect

Use a 301 whenever a URL has moved for good and will not come back. The classic cases:

• Domain migration. oldshop.example becomes newshop.example — every old page 301s to its counterpart on the new domain.
• HTTP to HTTPS. Every http:// URL permanently moves to its https:// version.
• www canonicalization. Pick one host — www.example.com or example.com — and 301 the other to it, so link equity is not split across two versions of the same site.
• URL restructuring. A redesign changes /blog/2021/05/summer-sale to /blog/summer-sale; the old path 301s to the new one.
• Trailing-slash and case normalization. Consolidating /About and /about/ onto a single canonical URL.
• Retired content. A discontinued product page 301s to the closest equivalent page — not to the homepage (see the soft-404 tip below).

The permanence test is simple: will the old URL ever legitimately serve content again? If the answer is no, use 301. If the move is short-term — a maintenance page, a promo, an A/B test — use 302 instead.

301 vs 302 vs 307 vs 308

All four are redirects, but they differ in permanence and in whether the HTTP method is preserved:

For ordinary page migrations, 301 is the right answer. The method-preservation difference only matters when the request carries a body: a 301 or 302 may turn a form POST into a GET (dropping the submitted data), while 307 and 308 repeat the original method against the new URL. If you are redirecting API endpoints or form handlers permanently, prefer 308; temporarily, prefer 307.

SEO impact of a 301

A correct 301 passes essentially all ranking signals from the old URL to the new one — Google has confirmed that 301s no longer lose PageRank. The old URL eventually drops out of the index and the new URL takes its place. Two things can still go wrong. Chains (/a → /b → /c) force crawlers through extra hops and dilute signals, and mass redirects to the homepage are treated as soft 404s, which pass no value at all. Both are covered in the tips section, and this page's chain validator finds chains in your list automatically.

Where each output format goes

Worked example 1: domain migration (bulk)

A shop moves from oldshop.example to newshop.example. The redirect map is pasted into the Bulk tab — full URLs, bare paths, any separator works:

/services/web-design.html, https://newshop.example/services/web-design
https://oldshop.example/blog/2021/05/summer-sale -> https://newshop.example/blog/summer-sale
/shop/blue-jacket | https://newshop.example/products/blue-jacket

Choosing Apache (mod_rewrite) produces exactly this (verified against the generator engine):

RewriteRule ^services/web-design\.html$ https://newshop.example/services/web-design [R=301,L]
RewriteRule ^blog/2021/05/summer-sale$ https://newshop.example/blog/summer-sale [R=301,L]
RewriteRule ^shop/blue-jacket$ https://newshop.example/products/blue-jacket [R=301,L]

Switching the format dropdown to Nginx produces exact-match location blocks instead — for example:

location = /shop/blue-jacket { return 301 https://newshop.example/products/blue-jacket; }

The Netlify format is even terser — one from to status triple per line:

/services/web-design.html https://newshop.example/services/web-design 301

Deployment, step by step:

1. Back up the current .htaccess.
2. Paste the block (including RewriteEngine On) above any catch-all rules such as the # BEGIN WordPress section — rules run top to bottom.
3. Test with curl: curl -s -o /dev/null -D - https://oldshop.example/shop/blue-jacket and confirm a 301 with a Location: https://newshop.example/products/blue-jacket header.
4. Check one URL that should not redirect, to make sure nothing was over-matched.
5. Keep the rules for at least a year — and keep the old domain registered.

Worked example 2: HTTP to HTTPS plus www canonicalization

In the Canonicalizer tab, enter example.com, tick force HTTPS, and choose www → non-www. The Apache output is:

RewriteEngine On
# Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# www -> non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Every variant — http://example.com/x, http://www.example.com/x, https://www.example.com/x — now lands on https://example.com/x with at most one redirect hop. The Nginx equivalent is generated on the second output tab: a port-80 server block returning 301 https://example.com$request_uri for both hostnames, plus a port-443 block moving www.example.com to the apex.

Worked example 3: one regex rule instead of hundreds

A blog moves dated URLs like /blog/2023/07/hello-world to /articles/hello-world. Instead of one rule per post, the Regex tab takes a pattern and a target with $1-style back-references:

• Pattern: blog/(\d{4})/(\d{2})/([a-z0-9-]+)
• Target: https://example.com/articles/$3
• Test path: /blog/2023/07/hello-world → https://example.com/articles/hello-world

The generated Apache rule is:

RewriteRule ^blog/(\d{4})/(\d{2})/([a-z0-9-]+)$ https://example.com/articles/$3 [R=301,L]

The built-in tester shows the substitution result before you deploy, and rejects invalid regex with the exact engine error message.

Practical tips

• Never build chains. If /a → /b and /b → /c, replace both with /a → /c directly. Every hop costs a round trip, wastes crawl budget, and weakens signal transfer. The Chain tab flags chains, loops, and duplicate sources in your list.
• Never create loops. /a → /b → /a makes browsers show "too many redirects". The validator catches these.
• Do not mass-redirect to the homepage. Google treats hundreds of unrelated URLs pointing at / as soft 404s — the ranking value is lost. Map each old URL to the closest equivalent live page, or let it 404 honestly.
• Order matters in .htaccess. Specific rules go above broad catch-alls; Apache uses the first matching rule.
• Do not mix mod_alias and mod_rewrite for the same paths — the two modules run at different phases and the interaction surprises people.
• 301s are cached. Browsers may remember a 301 for months. Test new rules as 302 first (the status dropdown supports it), confirm with curl, then flip to 301.
• Test with curl, not just your browser (your browser cache lies): curl -s -o /dev/null -D - -L --max-redirs 0 https://old.example/page | grep -i -E "^(HTTP/|location:)". Expect HTTP/1.1 301 and exactly one Location: header per hop.
• Full URLs in, paths out. The generator strips scheme and host from sources automatically, escapes regex characters (. becomes \.), and anchors every pattern with ^…$ so /shop/blue-jacket never accidentally matches /shop/blue-jacket-xl.

301 Redirect Generator — all processing happens in your browser; your URL lists are never uploaded.

Frequently asked questions