Getting a redirect wrong is a common and expensive mistake. A 302 used where a 301 was needed tells search engines the move is temporary, so they keep the old URL in the index and never fully transfer its ranking signal to the new one. A redirect rule with a typo in its regular expression can silently fail to match anything, or worse, match far more than intended and send unrelated pages somewhere they should never go.
Every rule generated here follows the syntax Apache and Nginx actually expect, tested against the common patterns a site migration or a URL restructuring needs, so the output can be pasted directly into a live configuration file. Used purely as a 301 redirect generator for permanent moves, or switched to 302 for something temporary, the same apache redirect rules and their nginx redirect equivalent come out the other side.
301 versus 302, and why the difference actually matters
A 301 redirect means moved permanently. It tells both browsers and search engines that the old URL should be replaced by the new one going forward, and search engines respond by transferring the old URL's accumulated ranking signal to the new URL over time, then gradually dropping the old URL from the index. This is the correct choice for essentially every permanent site restructuring, domain change or URL cleanup.
A 302 redirect means moved temporarily. Search engines keep the original URL indexed and treat the redirect as a detour rather than a replacement, which is the correct behaviour for something genuinely temporary, such as a maintenance page or a short lived promotional redirect, but it becomes a real problem when used for a permanent change, since the old URL lingers in search results indefinitely instead of consolidating its value into the new one.
- Use a 301 for any permanent URL change, including a site migration, a rebrand or a URL structure cleanup.
- Use a 302 only for a genuinely temporary redirect, such as a maintenance page or a short campaign.
- Never leave a 302 in place for a change you already know is permanent, since it delays the ranking transfer indefinitely.
- A redirect chain, where a URL redirects to another redirect, should be flattened to a single hop wherever possible.
Plain, wildcard and regex modes, and when each one is right
Plain path mode redirects one specific URL to one specific destination, the simplest and least error prone option, correct when a single page has moved and nothing else needs to change. Wildcard mode is a wildcard url redirect for an entire folder to a new location while preserving everything after the matched path, which is the common case when a whole section of a site is renamed, for example moving every URL under /blog/ to /articles/ while keeping each individual post's slug intact.
Regex mode gives full control using Apache's mod_rewrite pattern syntax, needed when the transformation is not a simple prefix swap, for example redirecting a numeric product ID pattern to a different URL structure, or redirecting several distinct old patterns to one consolidated new page. It is also the most error prone mode, since an overly broad pattern can capture and redirect URLs that were never meant to be affected.
Why Apache and Nginx need completely different syntax
Apache reads redirect rules from a distributed .htaccess file placed inside the folder the rules should apply to, or from the main server configuration, using either the simpler Redirect directive for plain path and wildcard cases or mod_rewrite's RewriteRule for regex based cases. Nginx has no per folder .htaccess equivalent at all, since it deliberately does not support distributed configuration for performance reasons, and instead every rule lives in a server or location block inside the main Nginx configuration file, using the return or rewrite directives.
This is why a redirect rule copied verbatim from an Apache setup does nothing on an Nginx server and produces a configuration error if pasted as is. This generator produces both forms for every rule you build, so moving a site between the two, or simply confirming which server you are actually running, does not mean rewriting the rules from scratch in the second syntax.
Common mistakes that break a redirect rule
A missing leading slash on the source path in Apache's Redirect directive causes the rule to be silently ignored rather than throwing a visible error, which makes it one of the easiest bugs to miss during testing. In regex mode, forgetting to escape a literal dot inside a pattern, since a dot is a special regex character meaning any character, can cause a pattern intended to match one specific file extension to match far more than intended.
Rule order also matters in both servers. A broad rule placed before a more specific one can catch a request the specific rule was meant to handle, so the more specific patterns generally need to come first in the file, and this generator lists rules in the order you add them, which is worth reviewing deliberately before deploying rather than assuming order does not matter.
How this htaccess redirect generator builds each rule
Plain and wildcard mode rules are built using Apache's Redirect and RedirectMatch directives with the status code, source path and destination URL escaped and formatted correctly. Regex mode rules are built using mod_rewrite's RewriteRule syntax, including the RewriteEngine On directive every .htaccess file needs before any RewriteRule will take effect, a requirement that is easy to forget when writing rules by hand.
The Nginx equivalent for every rule is generated from the same source path, destination and status code, translated into the return directive syntax Nginx expects inside a location block, so the two outputs describe the same redirect behaviour even though the underlying syntax looks nothing alike.
| Code | Meaning | Use for |
|---|---|---|
| 301 | Moved permanently | Any permanent URL change |
| 302 | Found, temporary | A genuinely short lived redirect |
| 307 | Temporary, method preserved | A temporary redirect that must keep the request method |
How to use the htaccess redirect generator
- 1
Choose a redirect mode
Pick plain path for one URL, wildcard for a whole folder, or regex for a pattern based transformation.
- 2
Enter the source and destination
Add the old path and the new destination URL. Wildcard and regex modes support capturing part of the original path.
- 3
Choose 301 or 302
Use 301 for a permanent change and 302 only for a genuinely temporary redirect.
- 4
Copy the Apache or Nginx output
The htaccess redirect generator output includes both the .htaccess rule for Apache and the equivalent Nginx configuration block.
Related tools worth bookmarking
Sources and further reading
- MDN: HTTP 301 Moved PermanentlyThe reference for the 301 status code's meaning and how browsers and crawlers are expected to respond to it.developer.mozilla.org
- RFC 9110: HTTP SemanticsThe internet standard defining the 301 and 302 status codes and the redirection behaviour they specify.rfc-editor.org
- Google Search Central: Redirects and Search ConsoleGoogle's own guidance on how 301 redirects affect indexing and ranking signal transfer during a site migration.developers.google.com
Frequently asked questions
Common questions about the htaccess redirect generator.
Writing Apache and Nginx redirect syntax from memory is where small mistakes creep in, such as a missing RewriteEngine On directive, an unescaped dot in a regex pattern, or a leading slash left off a source path. An htaccess redirect generator applies the correct syntax for the mode you pick every time and shows both the Apache and Nginx forms together, so a mistake in one server's dialect does not get carried into the other.
Use a 301 for any permanent change, such as a migrated page or a site restructuring, since it tells search engines to transfer ranking signal to the new URL and eventually drop the old one from the index. Reserve 302 for something genuinely temporary, like a maintenance page, since it keeps the original URL indexed and does not pass ranking signal to the destination the same way.
The most common causes are a missing RewriteEngine On directive before a RewriteRule, a missing leading slash on the source path, or the rule being placed in a .htaccess file the server is not actually configured to read. Some hosting environments disable .htaccess override entirely for performance, in which case the equivalent rule needs to go in the main server configuration instead.
No. Nginx does not read .htaccess files at all and has no equivalent distributed configuration mechanism, by design, for performance reasons. Every Nginx redirect rule needs to live inside the main server configuration, in a server or location block, using entirely different directive syntax from Apache's Redirect and RewriteRule.
Wildcard mode covers the common case of redirecting an entire folder to a new location while automatically preserving whatever follows the matched path, useful for a straightforward folder rename. Regex mode uses full regular expression syntax for anything more specific, such as transforming a numeric ID pattern into a different URL structure, at the cost of being easier to get wrong if the pattern is not carefully tested.
A short chain is generally handled without serious harm, but each additional hop adds latency for the visitor and marginally dilutes the ranking signal passed along the chain. Where practical, redirect the original URL straight to its final destination in a single rule rather than through an intermediate URL that itself redirects elsewhere.
Yes. Characters with special meaning in regular expressions, most commonly a literal dot in a file extension, need to be escaped with a backslash or they will match more than intended, since an unescaped dot matches any single character rather than a literal period. This generator escapes literal characters automatically in the patterns it builds.