Redirect Generator

How the Redirect Generator works

Redirect generator: 301 versus 302

A redirect tells browsers and crawlers that a URL has moved. Get it right and the old URL's links, bookmarks and ranking carry over to the new one; get it wrong and you leave a trail of 404s and chained hops. Every server expresses redirects differently, and the formats are fiddly enough — escaped dots in Apache, exact-match location = in Nginx, :splat in Netlify — that writing them by hand for more than a handful of URLs is where mistakes creep in.

Input format. One redirect per line, source then target, separated by ->, =>, a comma, a pipe, a tab or a space. Sources are paths starting with /; if you paste full URLs the host is dropped, except in Cloudflare's bulk format, which can match on host. Targets can be paths or full URLs — a full URL is required when redirecting to another domain. Lines starting with # are comments and are skipped.

Wildcards. A source ending in * matches everything under that prefix, and a target ending in * receives the matched remainder: /blog/* -> /articles/* sends /blog/2024/post to /articles/2024/post. Each server has its own spelling — (.*) and $1 in Apache and Nginx, :splat in Netlify and Cloudflare, :path* in Vercel, {R:1} in IIS — and the tool writes the right one. A wildcard source with a fixed target sends everything under the prefix to one page, which is what you want when retiring a section.

Status codes. 301 is the permanent redirect and the one search engines transfer ranking through; use it for moved pages. 302 is temporary — the old URL keeps its ranking and will be re-checked — for A/B tests, maintenance and geo-redirects. 307 and 308 are the strict versions that preserve the request method, so a POST stays a POST; they matter for API endpoints and form handlers, and not for ordinary pages. Netlify, Cloudflare and Vercel accept all four; Apache and Nginx do too, though Nginx's permanent and redirect keywords map to 301 and 302 on rewrite rules, so for 307 and 308 on wildcards use a return in a location block instead.

Chains and loops. If line 3 redirects /a to /b and line 7 redirects /b to /c, then /a takes two hops. Google follows up to ten but each hop costs time and a little link equity, and some crawlers give up sooner. The check column flags chained targets so you can point /a straight at /c. A source that redirects to itself is an error, and a source listed twice is flagged because only the first rule will ever fire.

Per-server notes. Apache rules go in .htaccess at the site root or in the virtual host config, and need mod_rewrite enabled; the pattern matches with or without a trailing slash. Nginx rules go inside server { }; exact matches use location = and return, which is faster than rewrite. Caddy rules go inside the site block: exact matches are one redir line, and wildcards use handle_path, which strips the matched prefix so {uri} is the remainder. Netlify and Cloudflare Pages read a _redirects file from the publish directory, first match wins. Vercel reads vercel.json at the project root. IIS uses the URL Rewrite module. Meta refresh is a page-level fallback for static hosts with no server config — it works, but search engines treat it as a weak hint, so pair it with a canonical link, which the tool adds.

What it does not do. It does not fetch your URLs to confirm the targets exist, and it does not handle query-string matching, which each server does differently and most do not do at all in a redirect rule. Test the rules on a staging host before deploying, and check a sample of old URLs with a header-inspection tool afterwards.

Related tools