Start by identifying what fails
example.com and www.example.com may look like two ways to reach the same website, but they are distinct hostnames. DNS, the web server, and the HTTPS certificate must each handle www.example.com for it to work. A working bare domain does not automatically make the www version work.
First, note exactly what happens when you open each address. Does www.example.com produce a browser message that the server cannot be found? Does it reach a server but show the wrong site? Does the browser warn about the certificate, or does a redirect lead to an error? These outcomes point to different parts of the connection. Test with both https://example.com and https://www.example.com so that a browser’s automatic choice of HTTPS does not obscure the result.
Check whether www has a DNS record
If the browser cannot find www.example.com, inspect the DNS records for the domain. The bare domain might have an A record pointing to an IPv4 address, while www has no record at all. A common setup gives www a CNAME record pointing to example.com. Another setup uses an A or AAAA record for www, often when a hosting provider supplies specific addresses. Follow your provider’s instructions rather than assuming the two hostnames need identical records.
Check the record’s full name and value before changing anything. DNS control panels vary: some expect you to enter only www in the name field, while others show the complete hostname. A typo, an unintended extra suffix, or a record pointing to an old service can send visitors elsewhere. Also check for an AAAA record that points to a different destination from the intended site; some visitors may use IPv6 while others use IPv4.
Make sure you are editing DNS at the service that actually hosts the domain’s authoritative nameservers. Records displayed in an unused DNS account will not affect public lookups. After a correction, allow time for cached answers to expire. A record’s TTL influences how long resolvers may retain an answer, so results can differ temporarily between networks.
Verify that the website accepts the www hostname
A valid DNS answer only directs a visitor to a destination. The hosting service must also be configured to recognize www.example.com. If DNS resolves but the visitor sees a default page, an unrelated site, or a hosting error, look for a domain or hostname setting in the website platform, web server, or CDN. Add the www hostname using that service’s documented process. Pointing www at the right address alone may not complete the setup.
If the page loads over HTTP but HTTPS reports a certificate error, check whether the certificate covers www.example.com. A certificate for example.com does not necessarily cover its www hostname. Many hosting platforms can issue or manage a certificate after the hostname has been added and its DNS record is correct. Wait for that process to finish before treating a temporary certificate warning as a redirect problem; do not ask visitors to bypass the warning.
Inspect redirects without creating a loop
You may want one hostname to be the primary address and the other to redirect to it. For example, www.example.com can redirect to https://example.com. The redirect is an HTTP response from the website or hosting service, not something a CNAME record does by itself. The www hostname still needs to resolve, reach a service that handles it, and support HTTPS if visitors open its HTTPS address.
If both versions resolve but the page never opens, check the redirect rules at every layer that might apply them: the website, hosting platform, and CDN. Conflicting rules can send example.com to www.example.com and then send www.example.com straight back. Choose one primary address and configure a single, consistent direction. Test an ordinary page as well as the home page, since path-specific rules can behave differently.
Confirm the fix from more than one place
After making a change, compare DNS results for example.com and www.example.com using a DNS lookup tool, then open both addresses in a browser. Check that each reaches the intended site without a certificate warning and that any redirect ends at the chosen primary address. If one device still fails while another works, cached DNS answers may explain the difference; recheck after the relevant TTL has passed.
Change one part of the setup at a time and record what you changed. That makes it easier to distinguish a missing record from a hosting or HTTPS issue—and easier to undo a mistaken edit. Avoid altering unrelated records, particularly email records, just to fix a website hostname. The aim is a complete path for www.example.com: a correct DNS answer, a service that accepts the hostname, a valid HTTPS certificate, and a redirect if you want one.
