Nginx Redirect Generator: Create 301 and 302 Rules for Nginx

Nginx config

		

	
















FREE TOOL · NO SIGN-UP





This Nginx redirect generator writes ready-to-paste server rules for HTTPS, www or non-www, and individual page redirects with 301, 302 or 410 responses. It is for developers, sysadmins and SEOs moving URLs on an Nginx server who want clean rules without looking up syntax. Enter your domain and old and new paths, click Generate Nginx rules, and copy the config.





You can add redirects one row at a time or paste a whole list of old and new URL pairs. The output uses Nginx’s fast return directive and exact-match locations, which are easy to read and hard to get wrong.













How Redirects Work in Nginx





Nginx has no .htaccess file. Redirects live in the server configuration, usually inside server { } blocks in /etc/nginx/sites-available/ or /etc/nginx/conf.d/.





return vs rewrite





The return directive stops processing and sends a status code with a new URL, for example return 301 https://example.com/new/;. It is simple, fast and the approach Nginx’s own documentation favors for straightforward redirects. The rewrite directive matches a regular expression against the URI and changes it, optionally sending a redirect with the permanent (301) or redirect (302) flag. Use rewrite only when you need pattern matching with capture groups, such as moving a whole folder structure. For one-to-one page moves and domain changes, return is the better choice, and it is what this generator outputs.





301 vs 302 vs 308





A 301 is a permanent redirect. Search engines treat the new URL as the replacement and pass ranking signals to it. A 302 is temporary, useful for short promotions or maintenance, and tells search engines to keep the old URL. A 308 is also permanent but requires the browser to keep the same request method, which matters for form posts and APIs. For page moves, 301 is standard. The generator also supports 410, which tells search engines a page is gone for good.













How to Generate Nginx Redirect Rules





The form covers site-wide rules first, then page-level redirects.





Step 1: Enter old and new URLs





Set Force HTTPS and your preferred domain (non-www, www or leave as is), then type your domain. In the redirect rows, enter the old path, such as /old-page/, and the new URL, either a path like /new-page/ or a full URL on another domain. Click “+ Add redirect” for more rows.





Step 2: Pick redirect type





Choose 301 for permanent moves, 302 for temporary ones, or 410 for pages you have deleted with no replacement. For 410 rows, the new URL field can stay empty. Rows without an old path are skipped.





Step 3: Add bulk pairs





For larger moves, paste pairs into the bulk box, one per line, old and new separated by a space, such as /blog/old-post/ /blog/new-post/. Bulk pairs are written as 301 redirects. Every rule uses an exact location = match, so each one affects only that exact path.





Step 4: Copy into your server block





Click Generate Nginx rules and copy or download the config. The HTTPS and www blocks are separate server { } blocks. Add your real ssl_certificate lines where the placeholder comment sits. Paste the location lines inside your main server block for the preferred domain.













Common Nginx Redirect Recipes





Most sites need the same handful of redirects.





HTTP to HTTPS and www





With Force HTTPS on, the generator writes a server block listening on port 80 for both example.com and www.example.com that returns 301 https:// plus your preferred host and $request_uri. $request_uri keeps the path and query string, so http://www.example.com/shop?page=2 lands on https://example.com/shop?page=2 in one hop. A second block listens on 443 for the non-preferred host and sends it to the preferred one. This avoids a chain where HTTP goes to HTTPS www, then to HTTPS non-www.





Folder and wildcard redirects





To move a whole folder, use a regex location with a capture group, written by hand: location ~ ^/old-blog/(.*)$ { return 301 /blog/$1; }. This sends /old-blog/post-name/ to /blog/post-name/. Test regex rules carefully, because they can match more than you expect. For mixed lists of individual pages, the exact-match rules from this tool are safer.













Testing and Reloading Safely





A broken config can take a site offline, so always test before applying.





nginx -t and reload





After editing, run sudo nginx -t. It checks syntax and reports the file and line of any error. Only when it says the test is successful, apply the change with sudo systemctl reload nginx or sudo nginx -s reload. A reload applies new config without dropping active connections, unlike a full restart. Keep a backup of the working config so you can roll back quickly.





Checking with curl -I





Test each redirect from a terminal with curl -I http://example.com/old-page/. The response should show the expected status, such as 301 Moved Permanently, and a Location header with the new URL. Add -L to follow the redirect to the end and spot chains. Check a few rules from each group, plus the HTTP and www variants of your homepage.













Redirects During a Site Migration





Migrations often involve hundreds or thousands of URL changes.





Redirect maps for many URLs





For very large lists, Nginx’s map directive is more efficient than many separate location blocks. It lets you keep old-to-new pairs in a separate file and look them up with a single rule. For a few hundred redirects, exact location = blocks work fine.





Avoiding chains





Point every old URL straight to its final destination. If page A already redirects to B, and B now moves to C, update A to go to C. Chains slow users down and can lose signals.













Nginx Redirect Mistakes





These three cause most broken redirects.





Redirect loops





A loop happens when a rule redirects a URL to itself or two rules point at each other, often when the 443 block catches the preferred host too. Check server_name values.





Wrong location precedence





Nginx checks exact = matches first, then prefix and regex locations. A broad regex can override the rule you expect. Exact matches avoid this.





Losing query strings





return 301 /new/; drops the query string. Add $is_args$args to the target if parameters must carry over.













Move URLs Without Losing Rankings





Fill in your domain and redirects above to get a clean Nginx config you can test and deploy in minutes. On Apache hosting, use the .htaccess Redirect Generator instead. Strip tracking tails from old URLs with the URL Cleaner, then update your XML Sitemap Generator output with the new addresses. More free tools are on FHSEO Hub.













Nginx Redirect Generator: Create 301 and 302 Rules for Nginx FAQs









Set up a 301 redirect in Nginx by adding a location block with a return directive inside your server block, such as `location = /old/ { return 301 /new/; }`. Save the file, run `nginx -t` to check syntax, then reload Nginx. Test the result with curl -I to confirm the status and Location header.









Use return for most redirects, because it is simpler, faster and easier to read. Choose rewrite only when you need regular expression matching with captured values, such as moving every URL in one folder to a new folder. For single pages and domain changes, return with an exact location match is the recommended choice.









Redirect HTTP to HTTPS in Nginx with a server block that listens on port 80 for your domain names and returns `301 https://$host$request_uri`, or your fixed preferred host. Using $request_uri keeps the path and query string. Your HTTPS server block on port 443 then serves the site normally.









Test Nginx redirects by running `nginx -t` to check syntax, reloading Nginx, then using `curl -I` on each old URL. The response should show the correct status code and Location header. Add -L to follow every hop and catch chains, and test both HTTP and www versions of key pages.









An Nginx redirect loops when a rule sends a URL back to itself, or when two rules redirect to each other. Common causes are a server block that catches the preferred host, HTTPS forced both at a proxy and in Nginx, or a broad regex matching its own target. Review server_name and location rules.