WWW vs Non-WWW: Which Should You Choose for SEO?

WWW vs non-www is a foundational choice for any new site, and it decides how your domain, cookies, and redirects behave for the life of the project. The short answer is that neither version ranks better by itself, but picking one and enforcing it with a canonical and a 301 redirect keeps your link equity clean and your analytics accurate.

Key Takeaways

• Google treats www and non-www as two separate hosts, so you must pick one and redirect the other.
• Neither version is an SEO ranking factor on its own; consistency and redirects matter far more.
• WWW gives you more control over cookie scope and subdomain flexibility at scale.
• Set a canonical URL, a 301 redirect, and your preferred domain in Search Console together.
• Fix self-referral spam in analytics by excluding your own domain from referral traffic.

What Is the Difference Between Www and Non-Www?

A non-www address, often called a bare domain or apex domain, is the root of your site such as example.com. A www address places the site on a subdomain of that root, such as www.example.com. Technically these are two distinct hosts from the perspective of DNS and browsers. A user typing either one usually lands on the same content, but under the hood they are separate endpoints that can resolve to different servers, carry different cookies, and receive different SSL certificates.

The practical difference shows up in how the domain is managed. A bare domain is anchored at the zone apex, which limits some DNS options because many providers cannot place a CNAME record at the root. A www subdomain, by contrast, can sit behind a CNAME and therefore behind a content delivery network or a load balancer more easily. For a small brochure site this distinction is minor, but for a large platform that serves traffic through multiple edge providers it becomes a real architectural lever.

Does Www vs Non-Www Affect SEO?

The www versus non-www decision is not itself a ranking signal. Google has stated repeatedly that it does not prefer one form over the other. What affects SEO is inconsistency. If both versions are indexable and serve the same pages without a clear signal, you create duplicate content, split your backlinks across two URLs, and dilute the authority that each page accumulates.

The risk is not the prefix, it is the duplication. When example.com/page and www.example.com/page both return 200 status with identical content, crawlers may index both, and link equity from external sites may be divided between them. The fix is not to argue about the prefix but to declare one preferred host, redirect the other, and mark the preferred one with a canonical URL. Once that is in place, the SEO impact of your earlier choice becomes effectively neutral.

How Do You Choose Between Www and Non-Www?

Start by checking what already exists. If your site has earned backlinks, rankings, or brand recognition on one version, keep that version as your preferred domain to avoid disrupting accumulated signals. A new project with no history can choose freely, and many modern stacks default to the bare domain for brevity.

Consider scale and engineering needs. If you expect to run many subdomains, shift traffic across CDNs, or tightly control cookie scope, the www subdomain is the safer long-term home because it supports CNAME records and scoped cookies. If you want the shortest possible brand URL and run a simpler stack, the bare domain is reasonable. The most important rule is to choose once and enforce it everywhere, rather than flip-flopping later.

How Do You Set a Canonical and Redirect the Other Version?

The canonical tells search engines which URL is the master copy, and the 301 redirect sends users and crawlers from the unwanted host to the preferred one. These two signals must agree. A canonical pointing at www while the server serves non-www with no redirect sends mixed messages and slows consolidation.

Begin by deciding the preferred host from the previous section. Then configure your web server or CDN so that every request to the non-preferred host returns a 301 status and a Location header pointing to the preferred host, preserving the path and query string. Next, emit a canonical link element on every page that references the preferred absolute URL. Finally, confirm in server logs that the redirect is a true 301 and not a 302, because a temporary redirect will not pass link equity the same way.

How Do Cookies and Subdomains Affect the Choice?

Cookies set on a bare domain are sent to every subdomain, including static.example.com or app.example.com. That can bloat requests to assets that never need the cookie and can complicate caching. Cookies set on www.example.com are scoped to that subdomain and its children, so your static or application subdomains stay cookie-free and faster to serve.

For a single-site owner this nuance is small, but for a product with separate app, api, and cdn subdomains it becomes a performance and privacy lever. Choosing www as the canonical host lets you keep the main site cookie-scoped while leaving other subdomains clean. The table below summarizes the trade-offs across the dimensions that usually drive the decision.

How Does the Choice Change Analytics and Self-Referrals?

Analytics platforms attribute referral traffic by looking at the referring hostname. When a user moves from example.com to www.example.com, or vice versa, the destination may log the other host as a referrer. This produces self-referral spam, where your own site appears as a top traffic source and masks where visitors actually came from.

The remedy is twofold. First, enforce the single preferred host with the 301 redirect so sessions do not cross hosts. Second, configure your analytics to exclude your own domain from referral sources, usually through an internal or excluded-referrer list. With one canonical host and the self-referral exclusion in place, session counts, conversion paths, and attribution reports become far more trustworthy, regardless of whether you chose www or non-www.

How Do You Tell Google Your Preferred Version?

After the redirect and canonical are live, use Google Search Console to declare the preferred domain. In the legacy interface this was a "preferred domain" setting, but the durable signal is the combination of your 301 redirect and canonical tags. Search Console reflects the version it sees indexed, so the tool mostly confirms what your server already declares.

Use the URL Inspection tool on a few pages from both hosts. The non-preferred host should report a redirect, and the preferred host should report as indexed with the correct canonical. If you manage both www and non-www properties, verify each and watch which one Search Console lists as the canonical. Submitting a sitemap that contains only preferred-host URLs reinforces the choice and helps crawlers converge faster.

What Are the Most Common Www vs Non-Www Mistakes?

The first mistake is serving both versions with 200 status and no redirect, which splits link equity and creates duplicate indexing. The second is setting a canonical to one host while redirecting to the other, which confuses crawlers. The third is using a 302 instead of a 301, accidentally signaling a temporary move that fails to consolidate authority.

Another frequent error is fixing the homepage but forgetting deeper pages, so subpages remain accessible on both hosts. Teams also forget to update internal links and sitemaps, leaving mixed signals across the site. Finally, many owners skip the analytics self-referral exclusion, so they never notice the split in their own data. Auditing both hosts page by page catches most of these issues before they cost rankings.

If you later decide to switch your preferred domain, do it as a planned migration rather than a silent flip. The ordered list below walks through the safe sequence so you preserve as much equity as possible during the change.

1. Back up your current server config, analytics settings, and a full list of indexed URLs.
2. Configure the 301 redirect from the old host to the new preferred host, preserving paths and query strings.
3. Update all internal links, templates, and sitemaps to use the new preferred host.
4. Set the canonical URL element on every page to the new preferred absolute URL.
5. Confirm the change in Search Console by inspecting URLs from both hosts and reviewing indexed versions.
6. Monitor rankings, crawl stats, and referral reports for at least a few weeks after the switch.

Notice that the steps above mirror the setup steps in reverse order of emphasis. The redirect does the heavy lifting, the canonical reinforces it, and Search Console confirms it. Skipping the backup or the monitoring step is the usual reason a migration goes sideways, so treat them as required rather than optional.

For most site owners the practical plan is simple. Pick the version that already has links, redirect the other with a 301, add a matching canonical, scope your cookies intentionally, and exclude self-referrals in analytics. The www or non-www for SEO question then stops being a daily worry and becomes a one-time configuration that quietly protects your visibility.

Remember that this page is about the host decision and its redirects, not a general canonical tutorial. The canonical URL is only one part of the picture here. The durable win comes from aligning the redirect, the canonical, the cookie scope, and the analytics exclusion so they all point at the same preferred domain without contradiction.

Frequently Asked Questions

Is Www or Non-Www Better for SEO?

Neither version is better for SEO by itself. Google does not rank one prefix above the other. The real factor is consistency: you must choose one host, redirect the other with a 301, and set a matching canonical. When both versions are live and indexable without redirects, you split links and create duplicates. Once one preferred domain is enforced everywhere, the SEO difference between www and non-www disappears completely for almost every site.

Does Using Www or Non-Www Change Page Speed?

The prefix alone does not change page speed in any meaningful way. The indirect effect comes from cookie scope. A bare domain sends cookies to all subdomains, which can add weight to static asset requests. A www host can scope cookies so your cdn or app subdomains stay lean. For most small sites this is negligible, but at high traffic volumes the cookie-scoping difference can shave bytes off every asset request and improve caching efficiency slightly.

How Do I Move from Www to Non-Www Without Losing Rankings?

Treat it as a planned migration. Back up configs, then add a 301 redirect from www to non-www that preserves paths and query strings. Update internal links, templates, and sitemaps to the new host, and set canonical tags to the non-www URL. Verify in Search Console that the old host redirects and the new host is indexed. Monitor crawl stats and rankings for several weeks. Equity transfers through the 301, so a clean, consistent switch preserves most of your visibility.

What Is the Difference Between a Bare Domain and Www?

A bare domain, also called a non-www or apex domain, is the root such as example.com. A www address is a subdomain of that root, such as www.example.com, and is technically a separate host. DNS treats them differently: the apex often cannot use a CNAME, while www can. Cookies and SSL behavior also differ. Users rarely notice, but servers, CDNs, and analytics see two distinct endpoints that must be reconciled with redirects and canonicals.

Can I Use Both Www and Non-Www at the Same Time?

You can serve both, but you should not let both be indexable. If you serve content on both without a 301 redirect and a canonical, search engines see duplicate pages and split your authority. The safe approach is to serve both at the network level but redirect one to the other and declare a single canonical URL. Using both as equal, unredirected endpoints is a mistake that creates duplicate content and confuses crawlers, so enforce one preferred host.