Guide
Bulk redirects for Nginx, Apache, Vercel, Netlify, Cloudflare and Caddy
When pages move, every old URL needs to point at its new home, or visitors land on errors and search engines drop the ranking the old pages earned. Site migrations often involve dozens or hundreds of URLs kept in a spreadsheet, and each server spells redirect rules differently. This generator turns the list into rules for six common servers and hosts, and checks it for mistakes first.
Choosing the status code
301 Moved Permanently and 308 Permanent Redirect tell browsers and search engines that the move is final; 302 Found and 307 Temporary Redirect say it is temporary. The 30x pairs differ in how they treat the request method: 301 and 302 allow a client to turn a POST into a GET, while 307 and 308 must repeat the same method with the same body. For page moves, 301 is the usual choice; for API endpoints and form targets, 308 or 307 are safer.
The input format
Write one redirect per line: the old path, the new path or full URL, and optionally the status code. Spaces, tabs, commas, semicolons or arrows can separate them, so two columns copied from a spreadsheet paste in directly. Lines starting with # are comments. A source ending in * is a wildcard that matches everything below it, and :splat in the destination inserts what it matched, so /docs/* /help/:splat moves a whole section.
How each target writes rules
For Nginx, exact paths become location = /old { return 301 /new; } and wildcards become a regex location that returns the code with $1. Apache uses Redirect 301 /old /new for exact paths and RewriteRule with [R=301,L] for wildcards. vercel.json gets a redirects array with source, destination and permanent, using :path* for wildcards. Netlify and Cloudflare Pages share the _redirects format of source, destination and code on one line. Caddy uses redir, with a named path_regexp matcher for wildcard rules.
Checks before you deploy
The tool warns about sources that do not start with a slash, a source listed twice, where only one rule can apply, and a page redirected to itself, which loops forever. It also detects chains: if /a goes to /b and /b to /c, it suggests pointing /a straight at /c, saving visitors a round trip and keeping crawlers from giving up.
A worked example
The Sample list has seven redirects. For Nginx, the first line becomes location = /blog/old-post { return 301 /blog/new-post; } and the wildcard /docs/* becomes location ~ ^/docs/(.*)$ { return 301 /help/$1; }. The checks report that /a → /b → /c is a chain. Switching to vercel.json turns the wildcard into "source": "/docs/:path*", and in the Caddyfile it becomes a path_regexp matcher named r3 followed by redir @r3 /help/{re.r3.1} 301.
Testing after deploying
Check each old URL with curl -sI https://example.com/old-path and look for the status line and the Location header. For a long list, script it, or crawl the old sitemap and confirm that every URL ends at a 200 page in one hop.
Limits
Rules match the path only; query strings are passed through by most servers but not used for matching. Patterns more complex than a trailing wildcard, such as rewriting the middle of a path, need hand-written regular expressions.
Related tools
- Nginx Config Generator writes the server block the rules go into.
- HTTP Status Codes explains every 3xx code in detail.
- Access Log Analyzer finds the 404s that need redirects.
- URL Encoder encodes paths with spaces or special characters.
Checked against the current version of the Redirect Generator on .

