Redirect Chains Explained: How to Fix Long or Insecure Redirects on NZ Sites

Quick answer

A redirect chain is what happens when a single URL request bounces through several intermediate URLs before landing on the final destination — for example http://www.yoursite.nz/old-path → https://www.yoursite.nz/old-path → https://yoursite.nz/old-path → https://yoursite.nz/new-path. Each hop costs round-trip time, leaks the previous URL in the Referer header, and is one more place for a misconfiguration (or a downgrade) to creep in. The fix is to flatten every chain to a single 301: when a user requests http://www.yoursite.nz/old-path, the server should respond directly with 301 → https://yoursite.nz/new-path and nothing in between.

If your scanner flags redirects, the Free Website Security Check shows the chain and tells you which hop is the right one to eliminate.

What a redirect chain actually is

Every time a browser asks for a URL, the server can respond in one of two ways: with a 200 OK (here is the page) or with a 3xx redirect (go somewhere else instead). When the response is a redirect, the browser issues the new request — and that response might itself be a redirect, and so on. A chain ends when the server finally responds with 200 OK (or a 4xx/5xx error).

The number of hops is the chain length. A clean site has chains of length 1 — every request either serves the page or sends a single 301 to the final URL. Most New Zealand school and small-business sites have chains of length 2 to 4. Some have chains of length 6 to 10 (1).

The common patterns:

• Protocol upgrade chains. http:// → https:// → https://www. — the user is bounced twice before they reach the page.
• Hostname chains. www.example.com → example.com → example.com/en — multiple hostname hops before the final URL.
• Path chains. /old-page → /v2/old-page → /v2/new-page — usually the result of a CMS migration that nobody flattened.
• Mixed chains. Some hops go http://, others https://, others are canonical, others are tracking redirects. These are the worst because they leak the previous URL across insecure hops.

Every redirect hop is a request that could fail, a TLS handshake that could be intercepted, and a Referer header that could leak the previous URL. A chain of length 4 is not "slightly slower" than a chain of length 1 — it is four times as many failure points.

Why long chains are bad for NZ sites

Three reasons they sit in the NZAI baseline rather than being filed under "cosmetic":

• They slow down the page. Each hop adds round-trip latency. On a coffee-shop Wi-Fi network, a chain of length 4 can easily add a full second of perceived load time. On a mobile connection, it can be more.
• They break HSTS and CSP on the first hop. If the first hop in the chain is plain http://, HSTS has not yet kicked in (it only fires on HTTPS responses), and CSP cannot enforce anything because the chain is not yet at the real page. The protection you set up in your headers is bypassed for the duration of the chain.
• CERT NZ and the NCSC both flag redirect chains as a baseline concern. "Baseline controls" are the things the agencies expect every New Zealand organisation to have done before an incident is investigated (2)(3). A scanner that flags redirects as too long is reporting a gap that other security tooling will also flag.

For the broader educator safety pathway, including account security, devices, phishing, and student data, see Building Cyber-Safe Habits as an NZ Educator.

How to inspect a redirect chain

Two reliable ways, in order of speed.

1. Run the free NZAI scanner

The Free Website Security Check follows every link on a page, counts the hops, and reports any chain longer than 1. For each chain it shows the protocol, hostname, and path of every hop. Run it after every change to your redirects.

2. curl from the command line

curl -sIL -o /dev/null -w "%{url_effective} → %{http_code}\n" https://yourschool.nz/old-path

-L follows redirects; -I issues a HEAD for each hop. To see every hop individually, drop the -o /dev/null and look at the response headers. For a longer chain, increase verbosity with -v.

curl -sILv https://yourschool.nz/ 2>&1 | grep -E "^(< HTTP|< Location|< location)"

You should see one or two lines of HTTP/1.1 followed by Location: headers, terminating in a 200. Anything beyond two redirects is a candidate for flattening.

The four rules for clean redirects

Before showing the configs, here are the four rules that turn a messy redirect graph into a single-hop one:

1. Always serve https:// on the first hop. If a user types http://yourschool.nz/anything, the very first response should be a 301 to https://yourschool.nz/anything. No intermediate hops.
2. Always serve https://yourschool.nz (or https://www.yourschool.nz) on the first hop. Pick one canonical hostname and stick to it. If a user types the wrong one, redirect directly to the right one on the right protocol.
3. Always serve the final path on the first hop. If a user requests /old-page and the new home for that content is /new-page, the redirect from /old-page should land directly on /new-page. Not on /old-page again, not on a tracker URL, not on /v2/new-page.
4. Never let an HTTP redirect chain survive. If any hop in the chain is plain http://, the chain is insecure regardless of what the final hop does. HSTS only fires after the first HTTPS response has been received (4).

Combined, these rules mean: one hop, HTTPS, canonical hostname, final path. Anything else is a fix waiting to happen.

Copy-paste fixes for nginx

Below are minimal, tested snippets for the most common redirect patterns on nginx. Paste them, reload nginx, and verify with the Free Website Security Check.

Flatten HTTP → HTTPS → canonical → final path

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

server {
    listen 443 ssl http2;
    server_name www.yourschool.nz;
    ssl_certificate     /etc/ssl/certs/yourschool.nz.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/yourschool.nz.key;
    return 301 https://yourschool.nz$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yourschool.nz;
    ssl_certificate     /etc/ssl/certs/yourschool.nz.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/yourschool.nz.key;
    # ... your real site config ...
}

Every request — http://, https://, with www., without www., on any path — lands on a single 301 redirect and ends up on the canonical HTTPS URL in one hop. Reload with nginx -s reload (or sudo systemctl reload nginx on systemd hosts).

Path-level redirects

For paths that have moved (e.g. an old /about-us page that is now /about), use the location block:

location = /about-us {
    return 301 https://yourschool.nz/about;
}

The = modifier means "exact match" — no further regex parsing, no surprises with query strings. Multiple old paths get multiple location blocks. Each one is a single hop.

Copy-paste fixes for Apache

The same pattern in .htaccess:

# Force HTTPS
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

# Force non-www
<IfModule mod_rewrite.c>
    RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
    RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
</IfModule>

# Path-level redirects
RedirectMatch 301 ^/about-us$ /about

If the redirects disappear or you see a server error, the most common cause is mod_rewrite not being loaded — confirm with apache2ctl -M | grep rewrite.

For nginx, the recommended way is to put these rules in the server config, not in .htaccess, because .htaccess is parsed on every request and slows the server down. For Apache, .htaccess is the standard location.

www to apex — pick one and enforce it

A surprisingly common source of redirect chains is the www ↔ apex split. Your site lives at https://yourschool.nz (no www), but links exist somewhere — in templates, in emails, in PDF documents — pointing at https://www.yourschool.nz/.... If both hostnames are configured, and one redirects to the other, you have at minimum a 1-hop redirect on every visitor who follows the wrong link.

The fix is to pick one canonical hostname and reject the other:

• For most NZ schools and small businesses, the apex (yourschool.nz) is the canonical choice because it is shorter in print and easier to read aloud.
• The www hostname becomes a redirect target. Every request to www.yourschool.nz returns a single 301 → https://yourschool.nz/....

The nginx snippet above already does this. The Apache snippet above does this too. Whichever stack you run, make sure both hostnames are handled in one config block, not split between two services or two CDNs.

For the deeper mixed-content rules that also apply when one of these hostnames has no TLS certificate, see the HTTPS Everywhere guide.

Every tracking redirect is one more hop that can fail, one more place the click ID can be dropped, and one more place the user's IP can be logged by a third party. Use tracking parameters that survive a single 301, and question every vendor that inserts a hop before your page.

Tracking redirects — the trap to avoid

Most marketing platforms (UTM-tagged links, email tracking, social-media click trackers) add their own redirect hops before the user reaches your site. A typical pattern looks like:

https://link.email.yourvendor.nz/click/abc123 → https://yourschool.nz/?utm_source=newsletter → https://yourschool.nz/about

That is a 2-hop chain before your own server gets a chance to respond. Two more hops if the user typed www. or http://.

You cannot flatten third-party trackers — they belong to the vendor, not to your server. What you can do:

• Audit which trackers you actually need. Most NZ schools use one or two; if your page is bouncing through four, you probably have leftover trackers from old campaigns.
• Use direct links where possible. Link directly to https://yourschool.nz/about?utm_source=newsletter from the email rather than going through the vendor's tracker. You lose click-tracking but you eliminate one hop.
• Keep the chain length off your own server. Even if a third-party adds a hop, make sure your own response is a single 301 to the final URL.

Verify before you ship

Setting the redirect rules is half the job. Two ways to confirm they are clean.

1. Run the free NZAI scanner

The Free Website Security Check flags any chain longer than 1 as a redirects finding, with the exact URLs involved. Run it after every config change.

2. Browser DevTools

Open your site in Chrome or Firefox, press F12, switch to the Network tab, and reload. The Status column should show mostly 200 and a small number of 301 rows. If you see two 301s in a row before a 200, you have a chain.

Common redirect mistakes to avoid

From running the free scanner across New Zealand school and small-business sites, the most frequent missteps are:

• HTTP on the first hop. A user types http://yourschool.nz and the server redirects to https://yourschool.nz — but then the page itself fires a second redirect to https://yourschool.nz/about. The first hop is insecure; HSTS cannot fire yet. Always serve HTTPS on the first hop.
• www and apex both responding 200. Some sites accidentally configure both hostnames as the live site rather than as a redirect. Pick one and serve from it.
• Tracking redirects that 301 to a 301. The vendor tracker redirects to your canonical URL with utm_source=..., and the canonical URL then redirects again because the page has moved. Two hops, both yours.
• CDN adding hops. Some CDNs add their own redirect to normalise URLs. If the CDN is not configured to do a single hop, you get an extra round-trip on every request.
• Old 302 redirects left in place. A 302 is "temporary" — the browser keeps asking. Long-lived 302s are worse than a clean 301 because the browser never stops checking.

Knowledge check

Test your understanding of redirect chains and how to flatten them with these questions. Click or tap each card to flip it and see the answer.

Sources and references

[1] Mozilla. (2025). MDN Web Docs — HTTP redirects. https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections

[2] CERT NZ. (2025). Top 11 cyber security tips for your business. https://www.cert.govt.nz/business/guides/top-tips-for-cyber-security/

[3] New Zealand. National Cyber Security Centre. (2025). Cyber security baseline controls for organisations. https://www.ncsc.govt.nz/

[4] Internet Engineering Task Force. (2012). RFC 6797 — HTTP Strict Transport Security (HSTS). https://datatracker.ietf.org/doc/html/rfc6797

[5] Cloudflare. (2025). URL normalisation settings. https://developers.cloudflare.com/rules/normalization/

[6] New Zealand. Parliament. (2020). Privacy Act 2020. https://www.legislation.govt.nz/act/public/2020/0031/latest/whole.html

What to do next

• Run the Free Website Security Check to see whether your site has any redirects findings, and which URLs are chained.
• For the broader HTTPS / www ↔ apex rules that also shape the first hop, see the HTTPS Everywhere guide.
• For the HSTS-specific gotchas — preload list submission, includeSubDomains pitfalls, testing — see the HSTS Strict-Transport-Security guide.
• For the full set of recommended response headers (CSP, X-Frame-Options, Referrer-Policy and friends), see the Security Headers Explained guide.
• For the /.well-known/security.txt file that benefits from a single-hop canonical URL, see the Security.txt RFC 9116 guide.