Nginx 301 Redirect Maps After Migration (Skip Slow Plugins)

If you just migrated a site and rankings or referral hits are falling off a cliff, bloated redirect plugins are often part of the problem—not the fix. This guide walks Australian homeowners, sole traders, and small business operators through clean, native Nginx redirect maps so permanent 301s live in the server config, not in PHP on every request. You will inventory old URLs, build a maintainable map file, wire it into your server block, verify with curl and logs, and know when remote help from Fixwebnode is the safer path.

Delivery is remote and digital: SSH, config edits, reload, and verification. The same pattern works whether you run bare metal, a VPS, or a control-panel stack that still exposes Nginx. For where Fixwebnode works across Australia, see all service areas.

Why migration redirects belong in Nginx, not another plugin

After a redesign, domain change, or CMS move, search engines and bookmarks still hit old paths. Every missed 301 is a soft 404, a diluted ranking signal, or a bounce. WordPress-style redirect plugins solve the mapping problem in the application layer: they load on each request, query rules, and add latency—especially painful on shared or modest VPS plans common for Australian SMBs.

Nginx map directives resolve redirects before PHP-FPM or your app ever starts. That means permanent 301s with almost no per-request overhead, clearer logs, and one source of truth you can version in git. Fixwebnode helps Australian operators implement exactly this pattern remotely when traffic or SEO is already on the line.

How do I set permanent 301s in Nginx after a site migration in Australia without a redirect plugin?

Put old-to-new paths in an Nginx map (or a separate map file included from the main config), reference the mapped variable in a server block with return 301, test with nginx -t, reload, then confirm status codes and cache behaviour with curl -I. Skip plugin rule engines unless you truly need non-technical editors to add one-off redirects in wp-admin.

Common issues that kill traffic after a migration

1. Soft 404s and “page gone” on high-value legacy URLs

Google Search Console or analytics still show hits to /old-service/ or query-string landing pages that now 404. Rankings slip because equity never transfers.

2. Plugin redirect tax: slower TTFB and worse Core Web Vitals

A redirect manager loads on the front end, checks a large rule table, and only then issues 301s. Mobile users in Australia on average connections feel the delay; bounce rate climbs even when the destination is correct.

3. Redirect chains and protocol/host mismatches

HTTP→HTTPS, www→apex, then old path→new path creates two or three hops. Crawlers waste budget; users see flicker; some tools report “redirect error.”

4. Map syntax mistakes that break the whole site on reload

A missing semicolon, bad regex, or map included in the wrong context causes nginx -t failure—or worse, a partial config that serves the wrong vhost.

5. Forgetting query strings, trailing slashes, or case variants

Only exact paths were mapped. Marketing links with ?utm_ or alternate slash forms still 404, so paid and email traffic looks “broken” after launch.

Issue 1 — Restore equity: build a clean Nginx redirect map

Goal: one permanent hop from each important old URL to its new equivalent, outside PHP.

Step 1 — Inventory old URLs

Export from Search Console (Pages), analytics landing pages, and your old sitemap. Deduplicate and prefer the final public path (no tracking params in the map key if you will strip args separately).

Step 2 — Create a dedicated map file

On Debian/Ubuntu-style layouts this often lives under conf.d or a snippets folder. Example:

sudo mkdir -p /etc/nginx/redirects
sudo nano /etc/nginx/redirects/legacy-paths.map

Map file content (keys are old URIs; values are new paths or full URLs):

map $uri $legacy_redirect {
 default "";
 /old-home /;
 /services/web-design /web-design/;
 /blog/2022/launch-post /insights/launch-recap/;
 /contact-us /contact/;
}

Step 3 — Include the map in the http context

map must sit inside http { }, not inside server. In the main nginx.conf (or a file already included there):

include /etc/nginx/redirects/legacy-paths.map;

Step 4 — Enforce 301 in the server block

server {
 listen 443 ssl http2;
 server_name example.com.au www.example.com.au;

 # SSL and root omitted for brevity — keep your existing cert paths

 if ($legacy_redirect != "") {
 return 301 $legacy_redirect;
 }

 location / {
 try_files $uri $uri/ /index.php?$args;
 }
}

Prefer exact map keys for speed. If you must use regex maps, keep the list short and ordered carefully. For full URL targets (domain change), set values like https://new.example.com.au/path/ and return 301 $legacy_redirect; still works.

Step 5 — Test and reload

sudo nginx -t
sudo systemctl reload nginx

Step 6 — Verify status and hop count

curl -sI https://example.com.au/old-home | head -n 20
curl -sI https://example.com.au/services/web-design | grep -iE 'HTTP/|location:'

Expect a single 301 and one Location header pointing at the final URL. Check error log if something fails:

sudo tail -n 50 /var/log/nginx/error.log

When to call Fixwebnode: large URL lists, mixed old domains, or panel-managed Nginx where includes are non-obvious. Remote session via website repair Australia.

Issue 2 — Remove the plugin tax and reclaim TTFB

Goal: stop running redirect logic in PHP on every front-end hit.

Step 1 — Measure before you change anything

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' https://example.com.au/

Note TTFB on a legacy path that currently redirects through the plugin.

Step 2 — Export plugin rules

Use the plugin’s export (CSV) or database table dump so nothing is lost. Convert rows into the map format above.

Step 3 — Deploy the Nginx map and disable the plugin

After nginx -t and reload succeed, deactivate the redirect plugin in the CMS. Clear full-page cache (plugin, host, or CDN).

Step 4 — Confirm PHP is no longer required for the hop

curl -sI https://example.com.au/old-home
# 301 should appear without Set-Cookie noise from the app on that response

Re-check TTFB with the same curl write-out. Spot-check a few URLs in an incognito window.

Step 5 — Watch application and access logs

sudo tail -n 100 /var/log/nginx/access.log | grep ' 301 '
sudo journalctl -u php8.2-fpm -n 50 --no-pager

Adjust the php-fpm unit name to your version (php8.1-fpm, php-fpm, etc.).

When to call Fixwebnode: multiple redirect plugins, custom mu-plugins, or cache layers that still serve old 302s. Related WordPress structural work (for example multisite brand setups) is covered separately on WordPress Multisite Network Setup Docklands | Central Brand Management if that is in scope after redirects are stable.

Issue 3 — Collapse chains: host, TLS, then path—once

Goal: browser and bot take exactly one redirect to the canonical URL.

Step 1 — See the full chain

curl -sI http://www.example.com.au/old-home | grep -iE 'HTTP/|location:'
curl -sIL https://www.example.com.au/old-home | grep -iE 'HTTP/|location:'

-L follows redirects so you can count hops.

Step 2 — Canonical server blocks first

Separate concerns: one block (or map) for HTTP→HTTPS and www↔apex, then path maps only on the canonical HTTPS server. Example HTTP elevators:

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

Step 3 — Path map only on the final host

Do not 301 to a path on the non-canonical host. Map values should already use the canonical scheme and host when the domain changed; otherwise relative new paths are fine on the canonical server.

Step 4 — Certificates must match before you advertise HTTPS

sudo certbot certificates
# or
openssl s_client -connect example.com.au:443 -servername example.com.au </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Renew or expand names if www and apex are both required:

sudo certbot --nginx -d example.com.au -d www.example.com.au
sudo nginx -t && sudo systemctl reload nginx

Step 5 — Re-test until a single 301 remains

curl -sI https://example.com.au/old-home | grep -iE 'HTTP/|location:'

When to call Fixwebnode: CDN in front (Cloudflare-style rules duplicating Nginx), expired certs mid-migration, or panel “force HTTPS” fighting custom maps.

Issue 4 — Safe config discipline so a map never takes production down

Step 1 — Always test

sudo nginx -t

Fix every error before reload. Never restart blindly on a live shop.

Step 2 — Use reload, not hard restart, for map changes

sudo systemctl reload nginx

Step 3 — Keep maps out of the wrong context

If nginx -t complains that map is not allowed, you included the file inside server or location. Move the include to http.

Step 4 — Backup before edits

sudo cp -a /etc/nginx /root/nginx-backup-$(date +%F)
sudo cp -a /etc/nginx/redirects /root/redirects-backup-$(date +%F)

Step 5 — Roll back quickly if needed

sudo cp -a /root/nginx-backup-YYYY-MM-DD/. /etc/nginx/
sudo nginx -t && sudo systemctl reload nginx

Issue 5 — Query strings, slashes, and stubborn variants

Step 1 — Decide whether args must pass through

Default return 301 $legacy_redirect; drops the original query string unless you append it:

if ($legacy_redirect != "") {
 return 301 $legacy_redirect$is_args$args;
}

Only keep args when the destination actually needs them (search pages, filtered catalogues). Strip tracking noise when the new URL is purely editorial.

Step 2 — Normalise trailing slashes deliberately

Either map both variants or enforce a slash policy with a careful primary rule—avoid creating a loop with a second blanket slash redirect.

Step 3 — Sample real 404s from logs after launch

sudo awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 40

Add the highest-count paths to the map weekly until the tail dies down.

Step 4 — CMS-specific leftovers

If contact forms broke during the same migration, fix delivery separately—redirects will not repair SMTP. Use a dedicated pass such as Fix Broken WordPress Contact Forms & Configure SMTP Delivery rather than papering over form posts with 301s.

When DIY is enough vs when to book Fixwebnode

DIY is enough when you have SSH, a short list of stable URLs, one canonical domain, working TLS, and confidence running nginx -t before every reload. Follow the numbered steps above, keep backups, and monitor Search Console coverage for two to four weeks.

Book Fixwebnode when any of these apply: hundreds of legacy URLs; domain + CMS + CDN changing together; multisite or reverse proxies; repeated 500s after reload; SEO already dropping and you cannot risk extended downtime; or the host hides Nginx behind a panel with non-standard include paths. Fixwebnode is a direct specialist provider for remote website repair across Australia—not a freelance marketplace—so you work with one technical team on this migration problem end to end.

Soft scheduling note: remote diagnostic slots are often available the same day when booked early, subject to existing incident load.

Talk through your redirect map with Fixwebnode

If old URLs are still 404ing, plugins are taxing TTFB, or chains are confusing crawlers after your migration, bring your inventory and current Nginx layout to a focused remote session. Start the conversation on the landing page for individuals, sole traders, and local operators: https://fixwebnode.com.au/website-repair-australia. We will help you enforce clean permanent 301s in native maps, verify with real requests, and keep SEO equity moving to the new site—without another bloated redirect plugin in the path.