Should a Webflow Site Use www or the Root Domain?

Should a Webflow site use www or the root domain?

For SEO, either choice works. What matters is picking one version as the default, redirecting the other to it, and using it everywhere: internal links, sitemap, canonical tags, ads, and email signatures. The practical tiebreakers are your DNS provider, your cookie and tracking setup, and how your brand is written.

This question comes up at launch, when a founder connects a domain to Webflow for the first time, and again during a rebrand or migration. It feels like a decision with hidden SEO consequences. It mostly is not. The consequences come from inconsistency, not from the choice itself.

So this article covers what Google actually says about duplicate URLs, the technical reasons one option may suit you better, and the checks I run so the choice stays consistent across the site and the tools around it.

Does Google prefer www or non-www?

Google does not prefer one over the other. Its documentation treats a page reachable at several addresses, including a www version, as one page with duplicate URLs, and it picks a canonical. Your job is to send clear, matching signals so Google picks the version you want.

Google's page on consolidating duplicate URLs gives an example of a single page reachable in multiple ways, including a version on www. When that happens, Google chooses one URL as canonical and treats the others as duplicates. Nothing about the www prefix itself helps or hurts.

The same page explains which signals matter. Google describes redirects as a strong signal that the target of the redirect should become canonical, and rel="canonical" annotations as a strong signal too. It describes sitemap inclusion as a weak signal. That ranking of signals is the whole strategy in one line: redirect, annotate, and list the same version.

Google also says it prefers HTTPS pages over equivalent HTTP pages as canonical. On a modern site, HTTPS should already be standard, so the real decision is only about the prefix.

What actually goes wrong when sites get this wrong?

The damage comes from mixed signals: both versions load without a redirect, internal links point to one version while canonicals point to another, or the sitemap lists a third. Google then has to guess, analytics split visits across hostnames, and link equity spreads thin across duplicate URLs.

The most common pattern I find is a site that switched versions at some point. The original launch used www, a later redesign set the root domain as default, and old blog posts still link to the www version in their body text. Every one of those links now passes through a redirect. That works, but it adds a hop and muddies the signal.

Google's guidance is direct on two related points. Do not specify different URLs as canonical for the same page using different methods, and when linking within your site, link to the canonical URL rather than a duplicate. Both are easy to follow on a new site and easy to break during a migration.

Why might the root domain be harder to set up?

The root domain can be harder because of DNS rules. A CNAME record is not allowed at the root of a domain under the DNS standard, so root setups use other record types or provider features that work around that limit. Some DNS providers handle this well, and some make it awkward.

This is the main technical reason many hosts have historically leaned toward www as the smoother default. A www subdomain can point anywhere with a simple CNAME. The bare root needs A records or a provider feature, sometimes called CNAME flattening or ALIAS records, depending on the DNS service.

I will not list record values here, because they change and Webflow publishes them in its own help center. Webflow has specific articles on setting a default domain and on setting the root domain as default, including the DNS records each one needs. Follow those exactly, and check your DNS provider's documentation for how it handles root records.

If your DNS provider makes root records painful, that is a good reason to choose www. Fighting your DNS setup to save four characters is not worth it.

How do cookies and tracking change the decision?

Cookie scope is a real tiebreaker for B2B teams. Cookies set on a root domain can be shared with subdomains in ways that www-only cookies may not, which matters if your app, help center, or booking pages live on subdomains. Check how your analytics and CRM tracking code handle domains before you choose.

Think about the full set of hostnames your buyers touch. A typical B2B SaaS has the marketing site on Webflow, the product on app.yourdomain.com, docs on a help subdomain, and maybe a status page. If you want one visitor journey across all of them, your tracking setup needs to treat them as one site.

Your CRM's tracking code and your analytics tool each have their own domain settings. I check them after any default domain change, because a mismatch can split sessions or drop the original traffic source on the way to a demo form. I covered why source data breaks so easily in how UTM discipline keeps your reporting honest.

None of this makes one choice universally better. It means the decision belongs to whoever owns the GTM data, not only to whoever connects the domain.

How do you set the default domain in Webflow?

Webflow lets you connect both versions of your domain and mark one as the default, so visitors on the other version are sent to it. The exact menu path and DNS records live in Webflow's help center, and you should follow its current article step by step, then publish and test both versions in a browser.

I do not reproduce Webflow's menu steps here on purpose. Interfaces change, and an out-of-date tutorial is how sites end up with redirect loops. Webflow's own articles on setting a default domain and on using the root domain as default are the source of truth.

What I add is the testing routine. After publishing, type both versions into a browser, with and without a path. Each should end on the default version with the same path. Then check a few old URLs from your previous site, if you migrated, to confirm they land on the right page and not on the homepage.

If you see a "too many redirects" error, stop and recheck the DNS records against Webflow's article before changing anything else. Those loops usually come from records that do not match the default you chose.

What should you update after choosing a version?

Update everything that names your URL: internal links in CMS content, canonical settings, your sitemap submission in Google Search Console, social profiles, ad destination URLs, email signatures, and integrations with webhooks or allowed domains. The goal is that the redirect becomes a safety net, not a busy road.

CMS content is the part people forget. Rich text fields in blog posts often contain hard-coded absolute links from years of publishing. A quick search of your collection for the old hostname, followed by an update pass, removes most of the unnecessary redirects in one session.

Integrations deserve a check too. Some tools restrict where embedded forms, chat widgets, or booking widgets may load, based on a list of allowed domains. If that list only includes the old version, a widget can quietly fail on the new one. Test every embedded tool on the live default domain.

If you are also moving content between hostnames, my piece on moving a blog from a subdomain to a subfolder covers the redirect planning that goes with it.

Should you switch versions on an established site?

Only with a reason beyond preference. Switching an established site means every URL redirects, every internal and external link takes an extra hop, and tracking settings need review. If the current version works and signals are consistent, leave it. Fix inconsistencies instead of switching.

Good reasons do exist. A DNS move to a provider that handles root records differently, a cookie scope need for a new app subdomain, or a rebrand that changes how the domain appears in print can all justify the change. In those cases, plan it like a small migration, with a redirect check and a Search Console review afterward.

Bad reasons include "the root domain looks cleaner" or "a competitor uses it." Those are aesthetic choices, and the cost lands on your traffic and your reporting rather than on your brand.

What should you do next?

Check which version your site serves today, then confirm that the other version redirects to it, that canonicals and the sitemap match it, and that internal links use it. If you are launching, choose based on your DNS provider and tracking needs, follow Webflow's help article exactly, and test both versions.

I build websites and the automations behind them for lead generation, and domain and tracking setup is where that work starts on every Webflow launch. If you want a second check on your domain, redirects, and tracking before or after a move, reach out at pravinkumar.co. Let's chat.