About

A misconfigured redirect loses link equity and fractures crawl budgets. Search engines treat a 301 (Moved Permanently) differently from a 302 (Found / Temporary): only the former passes approximately 95% of accumulated PageRank to the destination URL. Getting the syntax wrong on Apache versus Nginx versus IIS means the directive is silently ignored and the old URL returns a 404, compounding organic traffic loss at a rate proportional to the page's backlink profile. This tool generates syntactically correct redirect directives for 8 server environments, validates source and target paths, and exports production-ready config files.

The generator supports HTTP status codes 301, 302, 307, and 308. It handles bulk imports so migrations involving hundreds of URLs can be processed in seconds rather than hand-typed. Note: regex-based redirects (RewriteRule patterns) are not generated here; this tool produces literal path-to-path mappings only. Always test generated config in a staging environment before deploying to production.

Formulas

A 301 redirect instructs HTTP clients via a response header:

HTTP/1.1 301 Moved Permanently
Location: target_url

Apache .htaccess directive syntax:

Redirect 301 source_path target_url

Nginx location block syntax:

location = source_path { return 301 target_url; }

Where source_path = the old URL path (e.g., /old-page), and target_url = the full destination URL or path. The HTTP status code determines cache behavior: 301 is cached indefinitely by browsers, 302 is not cached by default, 307 preserves the request method (POST stays POST), and 308 is the permanent equivalent of 307.

PageRank transfer approximation:

PR_transferred ≈ 0.95 × PR_original

Where PR_original is the PageRank of the source page before the redirect. This approximation is based on historical Google statements; the exact dampening factor is not publicly disclosed.

Reference Data

Server / Method	Config File	Directive	Regex Support	Notes
Apache 2.4+	`.htaccess`	`Redirect` / `RewriteRule`	Yes (mod_rewrite)	Requires `mod_alias` or `mod_rewrite` enabled
Nginx	`nginx.conf`	`return 301` / `rewrite`	Yes (PCRE)	Requires `nginx -s reload` after edit
IIS 7+	`web.config`	`<httpRedirect>`	Yes (URL Rewrite module)	XML-based; must be well-formed
PHP	Any `.php` file	`header("Location: ...")`	N/A (script logic)	Must be called before any output
JavaScript (client)	HTML `<script>`	`window.location.replace()`	N/A	Not crawlable by all bots; fallback only
HTML Meta	HTML `<head>`	`<meta http-equiv="refresh">`	No	Delay in seconds; poor SEO signal
Cloudflare Pages	`_redirects`	`/old /new 301`	Splats only (`*`)	Max 2000 rules; processed top-down
WordPress (PHP)	`functions.php`	`wp_redirect()`	N/A	Hook into `template_redirect` action
Vercel	`vercel.json`	`redirects` array	Yes (path patterns)	JSON config; max 1024 redirects
Netlify	`_redirects` / `netlify.toml`	`/old /new 301!`	Splats (`:splat`)	Force flag `!` overrides existing file
Amazon S3	Bucket policy (XML)	`<RoutingRules>`	Prefix only	Only prefix-based; no full regex
Firebase Hosting	`firebase.json`	`redirects` array	Glob patterns	Processed in order; first match wins
Caddy 2	`Caddyfile`	`redir`	Yes (matcher)	Clean syntax; automatic HTTPS
Traefik	Labels / TOML	`RedirectRegex`	Yes	Middleware-based configuration
LiteSpeed	`.htaccess`	Same as Apache	Yes	Compatible with Apache directives

Frequently Asked Questions

Use a 301 when the move is permanent and you want search engines to transfer link equity to the new URL and deindex the old one. Use a 302 when the redirect is temporary (A/B testing, maintenance pages, geo-targeting) and you want the original URL to retain its rankings. Misusing 302 for permanent moves can cause search engines to keep indexing the old URL for months.

Each hop in a redirect chain incurs a small ranking signal loss. Google has stated they will follow up to 5 redirect hops before abandoning the chain, but each additional hop adds latency (typically 50 - 200ms per hop) and risks partial equity loss. Best practice is to update all redirects to point directly to the final destination URL, eliminating intermediate hops entirely.

Yes. Cross-domain redirects are fully supported by all server types. For Apache, use the full absolute URL as the target (e.g., https://newdomain.com/page). For Nginx, the return 301 directive accepts absolute URLs natively. Cross-domain 301 redirects pass link equity the same way as same-domain redirects, though the receiving domain must be accessible and return a 200 status.

Apache's Redirect directive automatically appends the query string from the original request to the target URL. To strip it, you need RewriteRule with a ? at the end of the target. Nginx's return 301 does not append query strings by default; use $is_args$args to preserve them. This generator produces literal path redirects; if your migration requires query string manipulation, you will need to manually adjust the output.

Both 307 and 308 preserve the HTTP method of the original request. A 301 or 302 may cause browsers to change a POST request to GET on the redirect, which breaks form submissions. 307 is the temporary variant (do not cache), and 308 is the permanent variant (cache indefinitely). Use 308 for API endpoint migrations where POST/PUT methods must be preserved.

Apache .htaccess has no hard limit but performance degrades linearly with rule count; beyond 1000 rules, consider using RewriteMap with a database or text file. Nginx handles large numbers efficiently since config is compiled at startup. Cloudflare Pages caps at 2000 rules. Vercel allows 1024. For very large migrations (10000+ URLs), server-side scripting (PHP/Node) with database lookups is more appropriate than static config files.