Nginx Redirect Generator

Generate Nginx redirect rules using the return directive. Handle individual path redirects, HTTP→HTTPS, and www/non-www preferences with production-ready Nginx configuration code.

Redirect Configuration

301 passes ~90-99% of link equity. Use 302 only for temporary situations.
The path you want to redirect FROM (e.g., /old-page) or a full URL.
The full destination URL including protocol (e.g., https://example.com/new-page).

Global Rules

Quick samples:

About the Nginx Redirect Generator

This tool generates Nginx return directive redirect rules based on your input configuration. It produces production-ready code for both simple page redirects and global rules (HTTPS enforcement, www canonicalization) using Nginx server blocks.

301 & 302 Support

Choose between permanent (301) and temporary (302) redirects depending on your use case.

Force HTTPS

Automatically generate a server block to redirect all HTTP traffic to HTTPS using the return directive.

www / non-www Canonicalization

Choose a preferred domain version and redirect all traffic to it for consistent SEO signals.

301 vs 302: Which Should You Use?

The difference between 301 (Permanent) and 302 (Temporary) redirects is critical for SEO:

  • 301 (Permanent):Tells search engines the page has moved permanently. Passes approximately 90-99% of link equity to the new URL. The old URL is deindexed and replaced with the new one. Use for: site migrations, URL restructuring, domain changes, permanently moved content.
  • 302 (Temporary):Tells search engines the move is temporary. Does not pass full link equity. The old URL remains indexed. Use for: maintenance pages, A/B testing, seasonal landing pages, temporary redirects.

Nginx Redirect Methods: return vs rewrite

Nginx offers two main ways to configure redirects:

  • return directive:Best for simple, single-path redirects. Fastest method — evaluated at the very start of request processing. Syntax: return 301 https://example.com/new-page;
  • rewrite directive:More flexible for pattern-based redirects using regular expressions. Slightly slower but more powerful for complex URL transformations. Syntax: rewrite ^/old/(.*)$ /new/$1 permanent;

Best Practices for Nginx Redirects

  • Prefer return over rewrite when a simple path redirect is sufficient — it's faster and simpler.
  • Place specific redirects before catch-all rules in your server block configuration.
  • Always use 301 redirects for permanent URL changes and site migrations.
  • Redirect to the most relevant page — avoid redirecting everything to the homepage.
  • Keep redirect chains short (ideally 1 hop). Long chains slow down page loads and dilute SEO value.
  • Test all redirects after deployment: nginx -t then nginx -s reload, followed by curl -I verification.
  • Keep a backup of your working Nginx configuration files before making changes.
  • Avoid redirect chains — each hop adds latency and dilutes link equity.
  • For high-traffic sites, place redirects at the server level (in site config) rather than inside location blocks for better performance.

Why Proper Redirects Matter for SEO

Redirects are not just about user experience — they directly impact your search rankings. When you change a URL without a proper 301 redirect, you lose all the SEO authority built up by that page. Search engines rely on redirects to discover new content locations, consolidate ranking signals, and provide accurate search results. Common scenarios where proper redirect management is critical include:

  • Site migrations — Moving to a new domain or CMS requires a complete redirect map to preserve rankings.
  • URL restructuring — Changing your URL hierarchy (e.g., /blog/post to /resources/post) needs careful redirect planning.
  • HTTPS migration — Switching from HTTP to HTTPS requires a 301 redirect to ensure all traffic uses the secure protocol.
  • Content consolidation — Merging multiple pages into one needs redirects from the old URLs to the new canonical page.
  • Removing outdated content — Deleted pages should return 410 (Gone) or redirect to relevant alternatives, not 404 (Not Found).

Frequently Asked Questions

A 301 redirect tells search engines the page has moved permanently and passes approximately 90-99% of link equity (ranking power) to the new URL. A 302 redirect signals a temporary move and does not pass full link equity. For SEO purposes, use 301 for permanent URL changes like site migrations or restructuring, and use 302 only for temporary situations like maintenance pages or A/B testing where you plan to restore the original URL. In Nginx, both use the same return directive syntax.
The return directive is simpler and faster — it stops processing immediately and sends a redirect response to the client. The rewrite directive is more flexible, supports regular expressions for pattern matching, and can modify the URI before further processing. For simple path-to-URL redirects, use return. For complex conditional redirects or regex-based pattern matching, use rewrite. The return directive is evaluated at the very start of request processing, making it more performant.
Nginx redirect rules should be placed inside a server {} block in your site configuration file (typically /etc/nginx/sites-available/example.com or /etc/nginx/conf.d/example.com.conf). Specific redirect rules should be placed before catch-all rules. For return directives, order matters — Nginx processes them sequentially within a location block. Place your most specific redirects first, followed by more general rules.
Yes — incorrect Nginx configuration can prevent your site from loading or cause a 500 Internal Server Error. Always test your configuration with nginx -t before reloading. Common mistakes include: missing semicolons, unmatched braces, incorrect server_name values, and redirect loops. A single syntax error in your Nginx configuration will prevent the server from starting. Always keep a backup of your working configuration files before making changes.
Yes — for server-level redirects (like HTTP→HTTPS or www/non-www canonicalization), the return directive must be inside a server {} block with a matching server_name. When Nginx processes a request, it matches the Host header against server_name directives across all server blocks. If no match is found, the default server block handles the request. Using the correct server_name ensures your redirects only apply to the intended domains.
For www to non-www (or vice versa) redirects, use a server {} block with a return directive. This is the cleanest approach: create a separate server block that matches the unwanted domain variant and use return to redirect to the preferred domain. This method is faster than using rewrite and easier to maintain. Example: server { listen 443 ssl; server_name www.example.com; return 301 https://example.com$request_uri; }
Yes, but carefully — they operate at different processing stages. The return directive is executed during the rewrite phase and immediately terminates further processing. If you use both, place return directives before rewrite directives in the same context, as return will always take precedence and halt processing. Mixing them in complex configurations can lead to unexpected behavior if you are not careful about the order of execution.
After adding redirect rules, follow these steps: (1) Run nginx -t to check for syntax errors. (2) Reload Nginx with nginx -s reload (or systemctl reload nginx). (3) Use curl -I https://example.com/old-page to verify the correct HTTP status code and Location header. (4) Use a redirect checker tool that follows the full chain to ensure no redirect loops. (5) Test on a staging server first before deploying to production.
The HTTPS redirect block creates a server {} block that listens on port 80 (HTTP) and returns a redirect to the HTTPS version of the same URL. This uses the server variable $host to preserve the original domain and $request_uri to preserve the full path and query string. This is the standard approach for enforcing HTTPS across your entire site. The redirect type (301 or 302) determines whether search engines treat it as a permanent or temporary HTTPS migration.
Indirectly, yes. Each redirect adds an extra HTTP round trip before the final page loads, increasing time-to-first-byte (TTFB). Long redirect chains (Page A → Page B → Page C) significantly slow down page loads and waste crawl budget. Nginx return directives are extremely fast (they execute at the start of request processing), but the network overhead of additional round trips still applies. Google recommends keeping redirect chains to a single hop for optimal performance.
Reviewed Jun 2026 · Sources and limitations

Review details: 2026-06-10 · Marc LaClear · v1.0

Reference sources:

Known limits:

  • Checks are based on publicly fetchable HTML, response headers, and browser-side input. They do not use private Google Search Console, analytics, or ranking data.
  • Scores and warnings are diagnostic aids, not guarantees of ranking improvement or Google indexation.
  • Pages blocked by robots.txt, login walls, bot protection, heavy JavaScript, or network timeouts may return incomplete results.
  • Validate critical fixes with official Google tools such as Search Console, Rich Results Test, Lighthouse, and your own crawl data.

Report an issue with this tool