apex vs www: how one redirect quietly splits your rankings
there is a decision almost nobody makes deliberately: whether your site lives at example.com or www.example.com. it usually gets made by whichever host you signed up with, silently, on the day you pointed the dns. and then it sits there causing a slow, invisible problem that never shows up as an error anywhere.
to a browser, those two addresses are interchangeable because your host redirects one to the other. to google, they are two different sites. every link, every crawl, every scrap of accumulated signal attaches to one host or the other. if your site has been reachable at both for years, you have been quietly dividing your own ranking signal between two addresses.
this is one of the checks in every audit we run, and it is one of the few where the wrong fix is more expensive than doing nothing.
the two ways this goes wrong
the split. both hosts serve content. neither redirects. google indexes both, sees identical pages, and picks a canonical for you. sometimes it picks the one you would have picked. sometimes it splits — some pages canonicalised to apex, some to www — and now your internal links, which all point at one host, are passing signal to pages google has decided are the duplicates.
the mismatched declaration. one host redirects to the other, which sounds solved, except every page declares a canonical pointing at the host that gets redirected away from. so the page google can actually fetch is telling google "the real version of me is over there", and "over there" immediately bounces back. we have seen this on sites where the redirect was added years after the canonicals were written, and nobody thought of the canonical as something the redirect affected.
this is the sitewide version of the duplicate-content problem covered in technical seo basics every website owner should understand — the same mechanism, applied to every url you have at once.
why the status code matters more than you would think
here is the part that catches people who otherwise know what they are doing.
a 301 or 308 is a permanent redirect. it says: this url has moved, for good, update your records. google treats it as a strong signal to transfer indexing and ranking to the destination.
a 302 or 307 is temporary. it says: go over there for now, but keep asking me. google is explicitly told not to consolidate — the original url stays in the index as the canonical one, because you have told google it is coming back.
most hosting platforms default to a 307 for the apex-to-www hop. vercel, netlify and cloudflare all do a temporary redirect in various configurations, because a temporary redirect is the safe default when the platform cannot know your intent. it works perfectly for humans and it does not transfer canonical status.
the result is a site where every visitor lands on www, every page declares a www canonical, and google has kept the apex as the canonical host — because the only thing google was ever told about the apex is that it temporarily points elsewhere.
check yours in one line:
curl -sI https://example.com | grep -i '^HTTP\|^location'
if you see 307 or 302, and you intend the redirect to be permanent, that is a finding.
check what google actually chose before you change anything
this is the important instruction and it is the opposite of what the finding above suggests you should do.
before you switch hosts, or change the redirect, or rewrite your canonicals — go and find out which host google has actually settled on. the url inspection tool in search console shows two separate values for any url:
- user-declared canonical — what the page's
<link rel="canonical">says - google-selected canonical — the one google actually uses
when those two disagree, google is telling you it overrode you. and here is the counterintuitive part: if google has settled on the apex and is happily indexing your pages there, a site that serves from www and declares www canonicals looks misconfigured but may be working fine. changing the host at that point asks google to re-index the entire site, which means a period of instability you did not need to buy.
we hit exactly this on our own properties. on one site the apex 307s to www, google settled on www for content pages, every page declares a www canonical, and the code and google agree — nothing to do. on another, the report showed the apex indexed and the www version marked duplicate without user-selected canonical, which was a real finding because the homepage declared no canonical at all. same-looking symptom, different diagnosis, and the only thing separating them was reading what google chose. that whole audit is written up in we broke our own seo.
the rule: reading is free, switching is expensive. read first.
how to settle it properly
once you know which host google is using, pick a host and make everything agree with it. there is no seo advantage to apex over www or the other way around — google has said so repeatedly and nothing in the ranking systems distinguishes them. pick the one google already prefers, unless you have a technical reason not to.
then align all six of these:
1. one permanent redirect, at the edge. every url on the losing host 301s or 308s to the same path on the winning host. example.com/services goes to www.example.com/services, not to www.example.com/. a blanket redirect to the homepage is one of the most damaging things you can do to an established site, because it converts every deep link you have ever earned into a homepage visit with no page-level signal.
2. no redirect chains. http://example.com → https://example.com → https://www.example.com is three requests and two hops. do it in one: http://example.com → https://www.example.com directly. chains dilute signal and waste crawl budget.
3. canonicals on the winning host, absolute, per page. declare the full url including protocol and host. and declare it per page — a canonical set once in a root layout is inherited by every page that does not override it, which quietly canonicalises your entire site to whatever that layout says. we cover the framework specifics in technical seo for next.js app router sites.
4. the canonical must be inside <head>. a canonical rendered into the body does not count at all. this happens more than you would expect on sites where a component injects it client-side.
5. sitemap urls on the winning host. every <loc> in your sitemap should use the canonical host. a sitemap listing apex urls on a www site is a document full of redirects, which is not fatal but is a wasted signal and makes coverage reports harder to read.
6. internal links relative or on the winning host. hardcoded absolute links to the losing host in your own nav or footer are self-inflicted redirect hops on every page load.
a domain property saves you some of this
in search console, a domain property (sc-domain:example.com) covers every host and protocol under the domain — apex, www, http, https, and any subdomain — in one place. a url-prefix property covers exactly one. if you are on url-prefix properties you may be looking at half your traffic and not know it.
domain properties need dns verification rather than a file upload, which is a five-minute job and worth doing. it also removes the class of confusion where a site "has no traffic" because you were looking at the apex property while google was indexing www. more on reading these correctly in how to actually read google search console.
what to expect afterwards
if the two hosts were genuinely split, consolidating them is one of the few technical seo changes with a visible effect: impressions attributed to the losing host taper off and reappear on the winner over a few weeks. google has to re-crawl to see the new redirect status, and that happens at whatever rate it already crawls you.
if google was already treating one host as canonical and you have simply tidied up the declarations, expect nothing to visibly change — and that is the correct outcome. you removed an ambiguity that was going to bite during your next redesign, which is when this problem usually becomes expensive. see how to redesign your website without losing your seo rankings for why.
one habit worth keeping either way: after making the change, wait seven to ten days before touching anything else technical. if you consolidate hosts, rewrite your titles and restructure your urls in the same week, you will never know which one moved the numbers.
if you are not sure which host google has chosen for your site, that is one of the first things a technical audit establishes. see what our seo work covers.