Paste old and new URLs and generate clean redirect rules for Apache Mod_Rewrite or NGINX rewrite rules.
URL pairs
Help with rewrite rules for Apache and NGINX
Rewrite rules and redirects help route old URLs cleanly to new targets, switch HTTP to HTTPS, prevent duplicate content and handle relaunches without unnecessary ranking loss. The generator creates suitable individual redirects for Apache Mod_Rewrite and NGINX. The following examples show typical cases that are often additionally needed in server configurations.
Enable the basics
Apache commonly uses Mod_Rewrite in an .htaccess file. The Rewrite Engine has to be enabled once; the generator intentionally does not include this activation line with every individual redirect. NGINX does not use .htaccess; rules usually live in the matching server block.
Apache Mod_Rewrite
RewriteEngine On
NGINX
server {
listen 80;
server_name example.com www.example.com;
}
Comments start with # on both servers. A commented-out rule is not executed.
# RewriteRule .* /index.php [L]
Redirect HTTP to HTTPS
A permanent HTTPS redirect ensures that visitors and search engines only use the encrypted version. The status code 301 signals a permanent change. In Apache, R=301 or R=302 creates an external redirect; without R, an internal rewrite takes place. L stops the current rule chain as soon as the rule matches.
Apache Mod_Rewrite
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
A fixed host variant prevents duplicate content. The example redirects from example.com to www.example.com while keeping path and query string. ^ marks the beginning and $ the end of the string. NC makes the comparison case-insensitive.
The Apache flag NE means no escape. In older Apache environments, it prevents unwanted escaping for redirects with query strings.
Change domain with identical paths
During a domain change, the requested path is kept. In Apache, the condition also matches www.old-example.com and subdomains because the host is only checked at the end.
server {
server_name old-example.com www.old-example.com;
return 301 https://www.new-example.com$request_uri;
}
Redirect a single URL
Relaunches often map old detail pages to new target pages. This is exactly what the generator is designed for because old and new URLs can be entered line by line. Apache can check the URL directly in the RewriteRule or via %{REQUEST_URI} in a condition.
If only a directory name changes, the remaining path can be reused via a capture group. $1 contains the first parenthesized match in both Apache and NGINX.
GET parameters belong in a RewriteCond in Apache. If only one specific parameter is relevant, (^|&)site=index(&|$) checks this parameter regardless of its position in the query string. The question mark at the end of the Apache target removes the old query string. In NGINX, an exact location block with $arg_site is usually more robust for simple query redirects than comparing the full $request_uri.
If multiple query parameters are present in the source and all of them must match exactly, the complete query string can be checked instead. In that case, the order of the parameters matters.
If the complete URI including the order of all query parameters must match exactly, $request_uri can deliberately be used. This form should not be nested inside another if.
if ($request_uri = "/index.php?site=index&ref=google") {
return 301 https://www.example.com/home/;
}
For many redirects or combined conditions, map belongs in the http block. The redirect itself remains a simple if with return in the matching server block.
Apache only redirects to the maintenance page if maintenance.html exists. 307 stands for a temporary redirect. The maintenance page itself should additionally send the status code 503 Service Temporarily Unavailable. In NGINX, the maintenance file can be used directly as the error page for 503.
The Apache flag F returns 403 Forbidden. Multiple RewriteCond lines are AND-linked by default in Apache. With [OR], the current condition is OR-linked with the following condition. The IPs in the example come from the reserved documentation network 203.0.113.0/24.
Referrer spam can be blocked server-side. Apache uses %{HTTP_REFERER} for this, while NGINX uses the variable $http_referer. NC and ~* check without considering upper and lower case.
if ($http_referer ~* example\.com) {
return 403;
}
Front controller for applications
Many PHP applications internally route non-existing files, folders and symbolic links to index.php. This is not a redirect, but internal routing. NGINX usually uses return for simple redirects, while internal routing often uses try_files or rewrite ... last.
Cookies can be used to control variants or test versions server-side. The first example is suitable for a simple A/B test and routes internally to variant-default.php if the cookie abtest=variant-b is not present. Access control should not rely only on such rewrite rules.
if ($http_cookie !~* "(^|;\s*)abtest=variant-b(;|$)") {
rewrite ^ /variant-default.php last;
}
The second example checks a cookie value with an allowed digit length. [0-9]{2,4} means two to four digits. This can be used to route numbered campaign variants internally.
if ($http_cookie ~* "(^|;\s*)campaign_id=[0-9]{2,4}(;|$)") {
rewrite ^/offer/?$ /offer-campaign.php last;
}
Serve WebP versions automatically
This example describes content negotiation for images. If the browser supports WebP and a matching file such as image.jpg.webp exists next to the original, the WebP file is served internally. Vary: Accept is important so caches can distinguish between browsers with and without WebP support.
