www vs Non-www Redirects: Choosing One Canonical Host

Technical SEO SEO Rule Last reviewed:

Direct Answer

Choose one canonical hostname, redirect the alternate host directly to it, and use the chosen host consistently in internal links, canonicals, hreflang, and sitemaps.

Documentation

What this topic means

This documentation focuses on www vs Non-www Redirects. The practical context is Choosing One Canonical Host. It defines the decision boundary and the preferred technical behavior. Adjacent failure states and broader workflows are covered by the related documents.

In practice, evaluate www vs Non-www Redirects on the live public response and compare at least one affected URL with a known-good example. Determine whether the behavior is isolated or generated by a shared route, template, component, proxy, or deployment rule.

Why it matters

Redirects affect how users and crawlers reach a resource and how URL changes are consolidated. Poor destinations, loops, or unnecessary hops make migrations slower to diagnose and maintain.

For www vs Non-www Redirects, the important distinction is between intended configuration and the state a crawler or user can actually fetch. Diagnose that gap before choosing a fix.

What to check

  • Confirm the live behavior for www vs Non-www Redirects on a representative public URL and record the exact response or rendered evidence.
  • Compare the affected case with a known-good URL so the difference is specific to www vs Non-www Redirects rather than an unrelated sitewide failure.
  • Request the old URL without automatically following redirects and record status plus Location.
  • Follow the redirect to confirm a valid, relevant, reachable final destination.

Implementation guidance

Implement the rule where it is easiest to keep deterministic and sitewide, usually at the server, edge, or routing layer. The source should terminate at the intended destination without cycling through legacy variants.

For www vs Non-www Redirects, make the intended behavior explicit at the layer that owns it and update generated internal references so new URLs do not recreate the old condition. If the behavior repeats across a template or route family, fix the shared source rather than patching individual pages.

Verify the result

Check the source response without auto-follow, then follow it and record the number of hops, final status, final URL, canonical, and internal-link references. A clean implementation reaches the intended destination directly.

The result is acceptable when the live URL consistently follows the intended www vs non-www redirects behavior, the related evidence is stable on repeated requests, and adjacent URLs or templates have not regressed.

Questions & Answers

What should be true after www vs Non-www Redirects is fixed or implemented?

The result is acceptable when the live URL consistently follows the intended www vs non-www redirects behavior, the related evidence is stable on repeated requests, and adjacent URLs or templates have not regressed.

Does this problem always cause a direct ranking loss?

No. Technical findings affect crawlability, rendering, consolidation, usability, or maintainability in different ways. Treat the finding as evidence to diagnose, not as a guaranteed ranking penalty.

Should the fix be made per URL or at a shared layer?

Use the narrowest layer that owns the behavior. If www vs non-www redirects repeats across URLs from the same template, route, proxy, or component, a shared fix is usually safer than many page-specific exceptions.

How should the change be tested?

Check the source response without auto-follow, then follow it and record the number of hops, final status, final URL, canonical, and internal-link references. A clean implementation reaches the intended destination directly.

Practical Check

  • Confirm the live behavior for www vs Non-www Redirects on a representative public URL and record the exact response or rendered evidence.
  • Compare the affected case with a known-good URL so the difference is specific to www vs Non-www Redirects rather than an unrelated sitewide failure.
  • Request the old URL without automatically following redirects and record status plus Location.
  • The result is acceptable when the live URL consistently follows the intended www vs non-www redirects behavior, the related evidence is stable on repeated requests, and adjacent URLs or templates have not regressed.

Sources

  1. Google Search Central — Redirects and Google Search
  2. RFC 9110 — HTTP Semantics
Your experience on this site will be improved by allowing cookies.