If your Webflow site loads at www.example.com but fails at example.com, check the domain setup before changing the design. Those addresses are separate hostnames. A working www record does not establish that the root domain is connected, published, or able to redirect visitors.
Start by identifying where the failure happens: DNS resolution, the HTTPS connection, or the redirect to your preferred address. That distinction will save you a lot of trial and error.
1. Test both addresses directly
Open the root and www addresses in separate tabs, including https:// in each URL. Record what you actually see.
- A domain-not-found error points toward DNS or the domain itself.
- A certificate warning means the browser reached a server but could not establish the expected trusted connection.
- A redirect loop means the request is reaching a service, but its redirect rules need checking.
- An old version of the site can indicate a cached answer, an old hosting destination, or a different publication target.
Also check the site's webflow.io staging address. If staging works, that narrows the investigation toward the custom-domain setup. It does not prove every production setting is correct.
2. Compare Webflow with the authoritative DNS settings
In Webflow, open Site settings → Publishing → Production. Check that the intended domain is connected, identify the default domain, and use the DNS values currently shown for that site.
Then confirm which provider actually hosts the domain's DNS. The registrar where you bought the domain may be different from the service named in its authoritative nameservers. Editing records in an unused DNS panel will not change the public result.
Check the root and www records separately. Look for obsolete or conflicting web-hosting records, including an unexpected IPv6 destination. Preserve unrelated records such as those used for email. If a change is necessary, save the existing values first so you have a clear rollback reference.
Avoid copying IP addresses from an old tutorial. Webflow has changed its hosting records, and its current domain connection documentation points you to the values for your site.
3. Compare DNS answers before clearing caches
On a Mac or another system with dig, these read-only checks show the answers returned by two public resolvers. Replace example.com with your domain:
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 www.example.com CNAME +short
dig @8.8.8.8 www.example.com CNAME +shortDifferent answers can indicate cached information. Matching answers tell you those resolvers agree; they do not prove every resolver or device has updated. A blank CNAME answer is also not automatically a failure: some DNS providers flatten records or return address records instead. Check the provider's configuration as well as the lookup result.
Try a second network, such as mobile data. If the site works there but fails on your normal connection, local or upstream caching becomes a stronger possibility. A private browser window can help isolate browser state, but it does not guarantee a fresh DNS lookup.
4. Confirm the preferred address and redirect
Choose the domain you want visitors to use, make it the default in Webflow, and publish to the intended production domains. Once both hostnames resolve and their HTTPS connections work, confirm the alternate address reaches the preferred one.
These commands inspect the response headers without changing anything:
curl -I https://example.com
curl -I https://www.example.comLook for the HTTP status and any Location header. If you investigate a loop, check forwarding at the registrar or proxy alongside Webflow's default-domain setting. Repeatedly adding redirects in multiple places can make the problem harder to understand.
5. Treat Cloudflare proxying as a separate setup
For a standard Cloudflare DNS connection, follow Webflow's Cloudflare domain guide. It distinguishes DNS-only records from the supported Orange-to-Orange configuration for using Cloudflare's proxy features. Follow the guide for your intended arrangement before changing the proxy switch.
DNS caches expire according to their existing lifetimes. Changing a TTL now does not erase answers already cached elsewhere. Webflow allows up to 48 hours for propagation in its troubleshooting guidance, although many changes become visible sooner. If the authoritative records are wrong, waiting will not fix them.
When asking for help, include the two affected hostnames, the error text, the current default domain, the DNS provider, and when the records changed. That gives the next person evidence to work with instead of another guess.
From the forum archive
This article expands my August 31, 2020 answer in No www, no site, where I explained why cached DNS answers can make a changed website appear unavailable. The checklist above has been updated for the current domain workflow; it is a new article rather than a copy of the original discussion.