Forcing HTTPS and handling redirects correctly
301 vs 302, www vs apex, and how to redirect without breaking your SEO.
Redirects are simple in concept and easy to get subtly wrong, in ways that cost you search rankings.
HTTP to HTTPS — always a 301
Once your certificate is working, redirect all plain HTTP to HTTPS:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}Use 301 (permanent) — it tells search engines to consolidate signals on the HTTPS version. A 302 (temporary) would leave ranking signals split.
Pick one canonical hostname
Decide whether your site lives at example.com or www.example.com, and redirect the other to it permanently. Do not serve both at 200 — that is duplicate content.
# canonical = www
server {
listen 443 ssl;
server_name example.com;
return 301 https://www.example.com$request_uri;
}301 vs 302 vs 307 vs 308
| Code | Meaning | Use for |
|---|---|---|
| 301 | Moved permanently | Consolidating rankings; permanent restructuring |
| 302 | Found (temporary) | Short-term moves; keeping the original URL indexed |
| 307 | Temporary, method preserved | Like 302 but keeps POST method |
| 308 | Permanent, method preserved | Like 301 but keeps POST method |
For SEO consolidation you want 301 (or 308 if you must preserve the request method).
Redirect chains and loops
A chain (A → B → C) wastes crawl budget and slows users. A loop (A → B → A) breaks the page entirely. After any redirect change, check for both — curl -I each hop, or use a redirect-chain checker. Never redirect a target back to a source.
Keep the paths
When you move a site, map old URL → new URL individually rather than sending everything to the homepage. Sending all traffic to / throws away years of accumulated relevance for individual pages and looks lazy to both users and search engines.
Related reading