.htaccess & Nginx Redirect Generator

What Is the .htaccess & Nginx Redirect Generator?

This tool turns a plain list of old and new URLs into working redirect rules for either Apache (as .htaccess mod_rewrite rules) or Nginx (as a snippet for a server block). It handles exact paths, wildcard patterns that carry the rest of the URL across, 301/302/307/308 redirects and 410 Gone responses. One switch each adds the site-wide redirects most sites need: forcing HTTPS, adding or removing www, and adding or removing the trailing slash. Every rule is checked for loops, chains and typos before it is written.

How to Use This Tool

Choose Apache or Nginx, then enter one rule per line as /old-path -> /new-path [301]. The status code is optional and defaults to 301. Use * to match anything: /blog/* -> /articles/* sends every old blog post to the same path under /articles/. For a page that is gone for good, write /old-page [410]. Tick or choose any site-wide redirects you need. Problems are listed by line number above the output, and lines with errors are left out of the file so a typo can't break your server.

Which Status Code to Use

Practical Uses

• Preserving rankings after a site restructure or a change of URL pattern
• Moving a whole section with a single wildcard rule instead of hundreds of lines
• Making every URL resolve to one canonical version: https, with or without www, one trailing-slash style
• Moving from Apache to Nginx and needing the same redirects in the new format

After a restructure, update your sitemap with the Sitemap XML Generator so it lists only the new URLs, and check your crawl rules with the Robots.txt Generator.

How Paths Are Matched

A plain path matches exactly that page, with or without a trailing slash. /old-page catches /old-page and /old-page/, but not /old-page/photos. A * matches any characters, including slashes, and each * in the target is replaced by whatever the matching * in the source captured. Matching is case-sensitive, as on the server itself. Query strings can't be matched by a path rule, but they are carried across: a visitor to /old-page?ref=mail lands on /new-page?ref=mail. If your target contains its own ?, the original query string is dropped instead. Apache works this way by default, and the Nginx output copies it.

Encoded characters are handled for you. Both servers match the decoded path, so a source written as /caf%C3%A9 becomes a rule for /café. A percent sign in a target is escaped so Apache doesn't read %20 as one of its back-references, and the NE flag stops it encoding the target a second time.

A Worked Example

The tool opens with four rules: an exact 301 from /old-page to /new-page, a wildcard 301 from /blog/* to /articles/*, a temporary 302 from /summer-sale to /offers, and /discontinued-product marked 410. With Force HTTPS ticked and "Force example.com (no www)" chosen, the Apache output has four parts:

• RewriteEngine On
• Your four rules. The wildcard becomes RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L], and the 410 becomes RewriteRule ^discontinued-product/?$ - [G].
• A www rule that captures the bare domain and redirects straight to https://, so a visitor to http://www.example.com needs only one redirect.
• An HTTPS rule for any remaining plain-http requests.

Switch to Nginx and the same rules appear as location ~ "^/blog/(.*)$" { return 301 /articles/$1$is_args$args; } and similar blocks, with the www and HTTPS redirects as if ($host ...) and if ($scheme = http) lines.

What the Checks Catch

• Lines the tool can't read: a missing arrow, spaces inside a path, or an unsupported status code.
• Sources that don't start with /, sources with a query string, and targets that aren't a path or a full http(s) URL.
• Characters that would break a config file, such as spaces, quotes, semicolons and braces. Encode them instead; a space is %20.
• A rule that redirects to itself, which would loop forever.
• A chain, where one rule's target is the source of another. Point the first rule straight at the final URL.
• The same source listed twice, where only the first rule would ever run.
• A target with more * than its source.

Testing Safely

• Back up the existing .htaccess or Nginx config first. A broken .htaccess returns a server error for the whole site, and Nginx refuses to reload. Run nginx -t before reloading.
• Browsers cache 301s aggressively, so test in a private window, or use 302 while experimenting and switch to 301 once the rules are right.
• Behind a proxy or CDN that ends HTTPS before your server (for example Cloudflare's Flexible mode), the server may see every request as plain http, and the Force HTTPS rule will loop. Use the CDN's own "Always use HTTPS" setting in that case.
• With a trailing-slash rule turned on, a redirect target without the slash gets a second redirect to add it. Write targets in their final form.
• In Nginx, the server-level www, HTTPS and slash directives run before any location block. In Apache, the rules run in the order written, with your rules first. Either way, a full target URL on your final host (https://example.com/new-page) gets old links there in a single redirect.

Frequently Asked Questions