Fix missing www/non-www redirect to canonicalize the host

What's happening

When both www.example.com and example.com return 200 with identical content, search engines treat them as duplicate pages competing for the same query. Internal links, backlinks, and bookmarks split between the two hostnames, diluting ranking signals. Cookies set on one host don't apply to the other, breaking auth and session continuity for users who switch.

The fix is to pick one hostname as canonical and 301 the other to it. Curl confirms the current state: curl -I https://example.com and curl -I https://www.example.com should show one returning 200 and the other returning 301 with the canonical Location header. If both return 200, canonicalization is broken.

Most modern CDNs and frameworks make this trivial — Cloudflare's "Always Use HTTPS" + a page rule, Vercel's Domains tab with primary-domain selection, Netlify's redirect rules. The hard part is picking the canonical: www.example.com is more traditional and allows DNS CNAMEs at the apex; example.com is shorter and more modern.

Why it matters

Duplicate-content signals split ranking power. Backlinks pointing to www and non-www each accrue PageRank to their respective host. Without consolidation, the canonical site ranks worse than it would with all signals combined.

Cookies and CORS break across hostnames. Users logged in on www.example.com aren't logged in on example.com, leading to confusing UX. Single-sign-on, session storage, and analytics tracking all fragment along the host boundary.

Common causes

• DNS records configured for both apex and www without a redirect rule.
• Wildcard SSL cert covering both hosts, masking the missing-redirect issue (no error, just duplicate content).
• Site move that didn't update the redirect when changing canonical host.
• Old web-server config that listened on both hostnames identically.
• CDN setup that allowed both hostnames as origins without a primary.

Detect this on your site

Run a quick scan with the Redirect Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Pick a canonical host

   www.example.com or example.com — pick one and commit. Apex (no www) is shorter and modern, but doesn't allow CNAME records at the root in many DNS providers. www allows CNAME flexibility. Both work fine; just pick.

2. 2

   Configure the redirect at one layer

   Pick one layer to own the redirect: CDN page rule (Cloudflare, Fastly), platform setting (Vercel Domains, Netlify), or web server (nginx/Apache). Don't configure it at multiple layers — that's how loops form.

3. 3

   Issue a 301, not 302

   Permanent redirect (301) tells browsers and search engines the canonical is the destination. 302 keeps the source as canonical. For host canonicalization, you always want 301.

4. 4

   Preserve the path and query string

   https://example.com/blog/post?utm_source=email should redirect to https://www.example.com/blog/post?utm_source=email, not to https://www.example.com. Use $request_uri (nginx) or:path* (Vercel) to preserve the rest of the URL.

5. 5

   Update internal links and absolute URLs

   Search for hardcoded URLs in code, sitemap, og:url, canonical tags, structured data, email templates. Replace with the canonical host. Internal navigation should never redirect.

6. 6

   Update Search Console properties

   Add both hosts as separate properties in Google Search Console, then in the canonical's Settings, mark it as the preferred. Submit an updated sitemap from the canonical host. Search Console reports any URLs still using the non-canonical.

7. 7

   Verify with curl and CheckFast /redirects

   curl -I https://example.com should return 301 with Location: https://www.example.com/. curl -I https://www.example.com should return 200. CheckFast's /redirects tool reports the chain explicitly. No chain longer than 1 hop.

Example

# Pick one canonical and 301 the other
server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.example.com;
    # ... actual app config
}

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

# Vercel: in Domains tab, set www.example.com as primary, example.com auto-redirects.
# Cloudflare: Page Rule "example.com/*" → "Forwarding URL: 301 to https://www.example.com/$1"

nginx 301 from apex to www, preserving path and query.

Related fixes