Nginx Redirect Guide: Server Block Rules for URL, Domain, and HTTPS Redirects

Overview

If you manage redirects in Nginx, the goal is not just to make one URL go somewhere else. The goal is to create a predictable redirect layer that is correct for users, search engines, analytics, and operations. That means choosing the right status code, applying rules at the right level, and keeping your redirect logic simple enough to audit later.

For most website migrations and permanent URL changes, a 301 redirect is the default choice. For short-lived routing changes, maintenance flows, testing, or campaign switching, a 302 redirect may be more appropriate. If you want a broader refresher on status code choices, see 301 vs 302 vs 307 vs 308 Redirects: When to Use Each Status Code.

In Nginx, most redirects are handled in one of three places:

• Server block level for host-wide redirects such as one domain to another or HTTP to HTTPS.
• Location block level for path-specific URL redirects.
• Application or upstream level when routing depends on logic outside the web server.

As a rule, use Nginx for redirects that are stable, infrastructural, and easy to express as host or path rules. If a redirect depends on session state, logged-in users, or business logic, it may belong in the application instead.

Before adding any rule, decide four things:

1. Source: exactly which hostnames, paths, and protocols should match.
2. Destination: the final canonical URL users should reach.
3. Status code: permanent or temporary.
4. Side effects: whether query strings, trailing slashes, subdomains, and case variations should be preserved.

That upfront clarity prevents most redirect errors.

Checklist by scenario

Use the checklist below before editing your Nginx configuration. The examples are intentionally simple and should be adapted to your environment, naming conventions, and deployment workflow.

1. Redirect HTTP to HTTPS

This is one of the most common Nginx redirect tasks. The aim is to ensure every HTTP request resolves to the HTTPS version of the same host and path.

Checklist:

• Confirm the TLS certificate is already valid for the destination host.
• Make sure port 80 traffic is reaching Nginx.
• Decide whether the preferred host includes www or not.
• Use a single hop where possible: HTTP directly to the final HTTPS canonical host.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

This pattern is cleaner than sending HTTP to HTTPS first and then fixing host canonicalisation in a second step. For more detail, see HTTP to HTTPS Redirects: Best Practices, Common Mistakes, and Testing Steps.

2. Redirect one domain to another

For a rebrand, consolidation, or retired microsite, you may need a domain redirect Nginx rule that sends every request from an old host to a new one.

Checklist:

• List every hostname involved, including www and non-www.
• Decide whether to preserve paths and query strings.
• Check whether any old URLs need one-to-one mappings instead of blanket forwarding.
• Point DNS for the old domain at the Nginx server before relying on the redirect.

server {
    listen 80;
    listen 443 ssl;
    server_name oldexample.co.uk www.oldexample.co.uk;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    return 301 https://newexample.co.uk$request_uri;
}

If only some sections moved, use specific path rules first and the catch-all redirect last. Otherwise, you risk sending high-value legacy URLs to irrelevant destinations.

3. Redirect www to non-www, or the reverse

Host canonicalisation matters for consistency and crawl efficiency. Pick one preferred host and redirect all alternatives to it.

Checklist:

• Choose the preferred host before writing rules.
• Update internal links, canonical tags, sitemaps, and analytics settings.
• Avoid combining host and protocol changes across multiple hops.

server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    return 301 https://example.com$request_uri;
}

If you are still deciding which host should be canonical, see www vs non-www Redirects: How to Choose and Configure the Preferred Version.

4. Redirect a single URL to a new URL

For page-level changes, a location-specific rule is usually enough.

Checklist:

• Match the old path exactly if the redirect is one-to-one.
• Use a 301 for permanent content moves.
• Keep the destination final; do not redirect to a URL that redirects again.

location = /old-page/ {
    return 301 /new-page/;
}

This is a straightforward URL redirect pattern and often the safest approach when replacing a retired article, product, or resource page.

5. Redirect a directory or path prefix

When a section moves, use a prefix match to carry the remainder of the path forward.

Checklist:

• Test nested paths, trailing slashes, and assets.
• Check whether the old and new structures are truly parallel.
• Exclude special cases before the catch-all path rule if needed.

location /blog/ {
    return 301 /resources$request_uri;
}

In practice, many teams prefer more explicit mappings for critical pages. Broad rules are efficient, but they can hide edge cases.

6. Temporary redirect for short-term routing

Use a 302 when the move is intentionally temporary and you expect the original URL to return.

Checklist:

• Set a review date before deployment.
• Document why the redirect is temporary.
• Make sure related canonicals and internal links are not sending mixed signals.

location = /promo/ {
    return 302 /summer-offer/;
}

Temporary redirects are easy to forget. If a 302 stays in place for months without review, it usually deserves another look.

7. Bulk redirect mapping during a migration

Large migrations often need many path-level redirects. Nginx can handle them, but organisation matters.

Checklist:

• Create a redirect mapping file from old URL to new URL.
• Prioritise high-traffic, linked, or indexed pages.
• Group patterns where structure is consistent.
• Use exact rules for exceptions.
• Version-control the mapping file.

On larger projects, think beyond syntax. A good redirect mapping process includes URL inventory, destination approval, QA, and post-launch validation. If your migration creates multi-hop paths, use this guide next: How to Fix Redirect Chains and Redirect Loops on Live Websites.

8. Redirect a domain at Nginx versus DNS forwarding

Some registrars offer domain forwarding, but server-side redirects usually give more control. If you need to preserve paths, manage multiple hosts, combine redirect logic with HTTPS, or audit rules in version control, Nginx is usually the better place.

Checklist:

• Use DNS to point traffic to the right server.
• Use Nginx to return the final redirect response.
• Do not assume DNS alone performs an HTTP redirect.

This distinction matters whenever someone asks how to redirect a domain. DNS gets visitors to the server; the web server issues the redirect.

What to double-check

Once you have written the rule, the real work is validation. A redirect that looks right in a config file can still fail because of certificate mismatches, host precedence, caching layers, or inherited rules elsewhere in the stack.

Run through this check list before and after deployment:

• Syntax test: validate the configuration with your normal Nginx test command before reloading.
• Single-hop behaviour: confirm the source URL reaches the final destination in one redirect where possible.
• Status code: verify the live response is 301 or 302 as intended, not an accidental 200, 404, or 500.
• Protocol and host: check HTTP, HTTPS, www, non-www, and any legacy subdomains.
• Path preservation: make sure deep URLs still resolve correctly, not just the homepage.
• Query strings: confirm campaign parameters or filtered URLs behave the way you intend.
• Trailing slash consistency: test both slash and non-slash variants if your platform treats them differently.
• Canonical alignment: the destination page should present itself as canonical, not point elsewhere unnecessarily.
• Internal links: update links to the destination URL rather than relying on redirects forever.
• Sitemaps and feeds: remove old URLs where appropriate and submit current ones.

It is also worth checking whether any upstream application, CDN, reverse proxy, or platform setting is issuing its own redirect. Many redirect loops are not caused by a single bad Nginx rule, but by two systems trying to enforce different versions of the same canonical URL.

If you manage both Apache and Nginx environments, compare behaviour carefully rather than assuming a rule will translate directly. For Apache-specific patterns, see Apache Redirect Guide: .htaccess Rules for Common SEO and Domain Changes.

Common mistakes

Most Nginx redirect problems follow familiar patterns. Knowing them in advance saves time during migrations and routine site changes.

Using the wrong status code

A permanent move implemented as a 302 can delay consolidation of signals. A temporary test implemented as a 301 can be harder to unwind later. Treat status code choice as part of the change request, not an afterthought.

Creating redirect chains

A classic example is HTTP to HTTPS, then www to non-www, then old path to new path. That may still work, but it adds latency and wastes crawl budget. Aim for a single final redirect whenever feasible.

Creating redirect loops

Loops often happen when one layer forces HTTPS while another layer redirects back to HTTP, or when host rules conflict between Nginx and a CDN. Audit every layer involved in request handling.

Relying on homepage redirects for everything

Sending every old URL to the homepage is rarely a good migration strategy. Users lose context, and search engines lose meaningful page-level continuity. Redirect each important old URL to the closest relevant new destination.

Forgetting TLS on redirecting hosts

If a host receives HTTPS requests, it needs to complete that TLS handshake before it can redirect. In practical terms, that means legacy domains often still need valid certificates even if they only exist to forward traffic.

Testing only the obvious URL

Teams often test the homepage and one sample page, then miss edge cases involving query strings, uppercase paths, missing trailing slashes, or language folders. Test realistic URL sets, not just happy paths.

Leaving temporary rules in place indefinitely

A 302 that solved a short-term routing need can become accidental long-term infrastructure. Add expiry dates to temporary redirects and review them in your normal deployment cycle.

When to revisit

Nginx redirect rules should be revisited whenever the underlying inputs change. That includes far more than a full site migration. In practice, redirect reviews are useful before seasonal planning cycles, before major content launches, and any time your workflows, hosting stack, or tooling changes.

Revisit your redirect setup when:

• You launch or retire a domain, subdomain, or microsite.
• You change CMS, framework, hosting provider, or reverse proxy setup.
• You switch canonical host strategy between www and non-www.
• You force HTTPS for the first time or change certificate management.
• You restructure sections, taxonomies, or product URLs.
• You import a new batch of legacy URLs from analytics, crawl data, or backlinks.
• You notice traffic drops, unexplained 404s, or indexed old URLs lingering longer than expected.
• You start seeing redirect chain or redirect loop warnings in crawls.

A practical review routine:

1. Export your current server block and redirect rules.
2. Compare them with your intended canonical architecture.
3. Test a sample of top URLs across host, protocol, and path variations.
4. Remove obsolete temporary rules.
5. Collapse chains into single-hop redirects where possible.
6. Update your redirect mapping document and keep it in version control.
7. Record why each non-obvious rule exists, so the next change is easier and safer.

The most durable Nginx redirect setups are the ones that stay readable. If a future teammate cannot tell why a rule exists, it is more likely to be broken during the next migration. Keep rules focused, documented, and tied to a clear canonical destination. That makes your Nginx server block redirect logic easier to maintain and gives you a reliable foundation for SEO-safe website changes.