HandyBench

Redirect Generator

Build .htaccess and Nginx redirect rules.

How to use the Redirect Generator

  1. 1 List your redirects, one per line, as "source target".
  2. 2 Choose Apache or Nginx and the redirect type (301 or 302).
  3. 3 Optionally force HTTPS or www (for www, enter your domain without the www), then copy the generated config.

Choosing the status code

The tool offers the two codes most people need. Others are listed for context.

CodeMeaningMethod preserved?Typical SEO use
301Moved permanentlyClients may switch POST to GETSite migrations, URL changes, HTTPS and www canonicalisation
302Found (temporary)Clients may switch POST to GETShort-lived moves, A/B tests, maintenance pages
307Temporary redirectYesTemporary move for API or form traffic
308Permanent redirectYesPermanent move for API or form traffic

Search engines treat 301 and 308 as signals to index the new URL, and Google has said that ranking signals pass through redirects generally. A 302 usually keeps the old URL indexed, though a long-lived 302 may eventually be treated as permanent. Use 307 or 308 only when you must preserve the request method; the dropdown here has just 301 and 302, so edit the code in the output by hand if you need them.

What the generated rules look like

Enter one pair per line, separated by spaces, tabs or a comma. Lines with no target are ignored. For the pair /old-page /new-page with 301, Apache output is Redirect 301 /old-page /new-page and nginx output is location = /old-page { return 301 /new-page; }.

Force www asks for your domain without the www (for example example.com), because the rule must name the exact host it applies to. With Force HTTPS and Force www both ticked and that domain entered, the Apache block is:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The generated block also contains comment lines, including a commented X-Forwarded-Proto condition (see the pitfalls). The apex rule comes first and always points at the final HTTPS www address, so every visitor gets at most one redirect: http://example.com, https://example.com and http://www.example.com each go straight to https://www.example.com. For nginx, the whole-site rules are written as separate server blocks instead of if lines: a listen 80 block that returns a 301 to the final HTTPS address, and, when www is forced as well, a listen 443 ssl block for the bare domain that redirects to www (you add the certificate paths it asks for). Your individual location redirects are listed separately, to paste inside your existing server block.

Pitfalls

  • Prefix versus exact matching. Apache's Redirect matches a path prefix, so /old also catches /old/page and appends the rest. Nginx location = matches that exact path only.
  • Redirect chains. The generated Force HTTPS and Force www rules are ordered so a request takes one hop, not two. Redirects you add from other places (a CDN setting, your application, a plugin) can still add hops, so test the real chain.
  • The www rule is for one domain. It only matches the exact domain you enter, so subdomains such as blog.example.com are left alone. The bare domain and the www host are the only two names it touches.
  • Behind a proxy or CDN. If TLS ends at a load balancer, CDN or reverse proxy, your server only sees plain HTTP and cannot tell which requests were HTTPS, so a plain "is this HTTPS" test redirects forever. Test the X-Forwarded-Proto header instead (the Apache output includes the commented condition; in nginx use $http_x_forwarded_proto), or do the HTTPS redirect at the proxy and leave it out here.
  • Placement. Apache rules go in .htaccess or the virtual host, with mod_alias and mod_rewrite enabled. In nginx, the location lines belong inside your existing server block, while the generated whole-site server blocks go at the same level as your other servers, followed by a reload.
  • Query strings. Nginx return does not append the original query string unless you add $is_args$args.

After deploying, confirm each hop with the HTTP headers checker, and keep the robots.txt generator output free of blocked redirect targets.

Examples

  • ▸ Mapping old blog URLs to new ones after a redesign.
  • ▸ Forcing HTTPS and www across a whole domain.

Frequently asked questions

When should I use 301 vs 302?

Use 301 for permanent moves so search engines transfer ranking signals to the new URL. Use 302 only for temporary redirects you intend to reverse.

Where do I put the generated rules?

Apache rules go in a .htaccess file in your site root (or a vhost). For nginx, the whole-site HTTPS and www rules are separate server blocks that go alongside your other servers, and the location lines go inside your existing server block; reload nginx after saving.

What about 307 and 308 redirects?

They behave like 302 and 301 but guarantee the request method is kept, which matters for POST and API traffic. The dropdown offers only 301 and 302, so change the code in the generated output by hand if you need 307 or 308.

Do Apache and Nginx match the old URL the same way?

No. Apache Redirect matches a path prefix, so /old also redirects /old/page. The Nginx location = rule matches that exact path only, and return does not carry the query string unless you add $is_args$args.

Do Force HTTPS and Force www create two redirects?

They do not. The generated rules are ordered so that http://example.com, https://example.com and http://www.example.com each go straight to https://www.example.com in a single hop. Redirects added elsewhere, such as in a CDN or application, can still add extra hops, so test the full chain.

Will the www rule redirect my subdomains?

No. Force www asks for your domain (for example example.com) and only redirects that exact domain to www.example.com. Subdomains such as blog.example.com are left alone.

Why does my site loop when I force HTTPS behind a CDN or proxy?

If TLS ends at a CDN or load balancer, your server only sees plain HTTP, so a plain HTTPS test redirects every request again. Test the X-Forwarded-Proto header instead (the Apache output includes it as a commented line; in nginx use $http_x_forwarded_proto), or do the HTTPS redirect at the proxy.

Related guides