Your Website Works Without WWW but Fails With It: Fix Both Addresses Before Launch

A local electrician launches a website at example.com and puts www.example.com on a thousand business cards. The homepage looks fine when the owner checks it, but customers typing the printed address see an error. The website exists. The domain is registered. One small difference in the address is enough to make the advertising ineffective.

This problem is common because example.com and www.example.com are separate hostnames, even though they are usually part of the same business website. One may have working DNS, hosting, and HTTPS while the other has not been configured.

You do not normally need to buy a second domain to fix this. You need to decide which hostname customers should see, make both addresses reachable, and direct them to one consistent destination. Here is a practical way to do that without accidentally disrupting business email or other services.

Understand Why WWW Is a Separate Hostname

When you register example.com, you control that registered domain and can configure hostnames beneath it. www.example.com is one such hostname. It is not a different top-level domain, and the www prefix is not another extension.

The root name, often called the apex, is example.com. The www hostname sits beneath it. DNS can publish different answers for the two names, and a web server or hosting platform may be configured to accept one but not the other.

A small furniture workshop might publish its website at the apex while an old hosting account still has a www record pointing elsewhere. A new bakery might connect the root name to a website builder but forget the separate step for www. A consultant may have a valid HTTPS certificate for one hostname but not the other.

The symptoms can look similar to a customer: an unavailable page, a hosting welcome screen, a certificate warning, or an unexpected redirect. The underlying causes are different, so the first task is to identify which layer is failing.

Decide Which Version Will Be the Public Address

Both `https://example.com` and `https://www.example.com` can be legitimate primary addresses. Neither spelling is automatically more professional, faster, or better for search visibility simply because it includes or omits www.

Choose one version based on the website platform's requirements, the business's existing links, and what has already been printed. A small restaurant that has used www for years may prefer to keep it. A new salon with no published materials may prefer the shorter apex address. The important point is consistency.

Once you choose the primary version, configure the other to redirect to it. This gives customers a forgiving experience when they add or omit www from a business card, invoice, social profile, or email signature.

Record the decision in the business's website notes. Staff members preparing flyers should not have to guess which address is official. Use the same preferred version in menus, brochures, booking confirmations, and customer support templates.

A redirect is appropriate here because the two hostnames represent the same website. It is not a reason to register additional domains or create duplicate copies of every page.

Diagnose the Four Addresses Separately

A customer can arrive through four common starting points:

The table uses an illustrative domain. Replace it with your actual business domain when testing.

Open each address in a private browser window and note the final URL. Do not assume that a browser which automatically upgrades to HTTPS has proved the underlying HTTP route is configured correctly. Test with tools that show the actual response and redirect chain when necessary.

For each case, record whether the name resolves, whether the HTTPS connection succeeds, whether a redirect occurs, and which page finally loads. A useful result is a single expected destination, not merely a browser tab that eventually displays something.

A local accountant can use this simple test before sending a new client welcome packet. A florist can run it before ordering printed tags. It is far cheaper to correct the web address before customers begin using it.

Check DNS Before Editing the Website

DNS answers tell a browser where to connect. If example.com works but www.example.com does not resolve, the missing or incorrect record may be the immediate cause.

The apex often uses A or AAAA records pointing to the website service, although the exact setup depends on the provider. A www hostname commonly uses a CNAME pointing to another hostname, or it may use provider-specified A or AAAA records. Follow the instructions from the hosting or website platform rather than guessing at IP addresses.

A conventional CNAME cannot coexist with the records required at the zone apex. Some DNS providers offer ALIAS, ANAME, or CNAME-flattening features to support alias-like behavior there. Those are provider-specific solutions, not proof that every DNS service accepts the same apex configuration.

Check the authoritative nameservers first. Editing records in an old hosting panel will accomplish nothing if another DNS provider currently serves the domain. If you do not know which service is authoritative, inspect the nameserver delegation before making changes.

Keep a copy of the current zone. Do not delete MX records, email authentication TXT records, or unrelated service entries while fixing www. A website hostname problem should not become an email outage.

Confirm the Hosting Platform Accepts Both Names

A DNS record can point visitors to a server that has never been told to serve the requested hostname. In that case, the server may show a default page, return an error, or send visitors to an unrelated site.

Many website builders and hosting panels require you to add both the root domain and the www hostname as accepted or connected domains. The exact terminology varies: custom domains, aliases, additional hostnames, parked domains, or domain bindings.

A cafe using a managed website service should look for the platform's domain-connection instructions. A workshop using cPanel hosting should confirm the domain and its expected aliases are configured in the hosting account. A custom application may require the web server's virtual host or routing configuration to include both names.

Do not solve this by duplicating the entire website in two folders. That creates two copies to update and can lead to inconsistent content, broken forms, and confusing search signals. One application should normally handle the preferred hostname while the alternate hostname redirects.

If the hosting platform does not support the requested hostname arrangement, ask its support team what is required before changing DNS again.

Make HTTPS Work Before the Redirect

An important detail is easy to miss: when a customer enters `https://www.example.com`, the browser establishes a secure connection to that hostname before it can receive a normal HTTP redirect.

If the server does not have a valid certificate covering www.example.com, the customer may see a certificate warning before the redirect can help. A certificate for example.com alone does not necessarily cover www.example.com; inspect the certificate's actual hostname coverage.

For a shoe shop, that warning can look alarming even if the intended final website is secure. Customers do not know that the business meant to send them elsewhere. They see a browser warning and may leave.

Configure HTTPS for both public hostnames, then test the redirect. The certificate may be issued by the hosting platform or managed separately, depending on the service. Do not buy a certificate without checking what the selected hosting plan already includes and which names it covers.

Also check that the final page does not load insecure scripts, images, or forms. HTTPS at the address bar is a necessary transport control, not a complete assessment of website security.

Redirect the Alternate Hostname Permanently

For a stable public website, a permanent redirect is generally appropriate when the alternate hostname should always lead to the preferred one. Common choices are HTTP 301 or 308. A 308 preserves the request method and body; 301 is widely used for ordinary page navigation, but applications should consider method-handling behavior before redirecting non-GET requests.

For example, if the preferred address is `https://example.com`, a request for `https://www.example.com/services` should normally land at `https://example.com/services` not simply at the homepage. The path matters when customers follow a link to a particular service or product.

Preserve query strings where appropriate, particularly when the site uses them for product filters or campaign tracking. At the same time, avoid redirect rules that accidentally expose sensitive information or loop between the two hostnames.

Do not create one rule that sends the apex to www and another that sends www back to the apex. That causes a redirect loop. Keep the chosen primary address in one place and test the result after every change.

A landscaping company with printed links to /estimate should make sure those links continue to reach the estimate page regardless of which hostname customers type.

Avoid Common Fixes That Create New Problems

The first mistake is adding random DNS records until the browser appears to work. A wrong A record may point one hostname to an obsolete server while the other remains correct. Copying a configuration from a different platform is not a safe shortcut.

The second mistake is treating a DNS CNAME as a web redirect. A CNAME helps a hostname resolve through another hostname; it does not tell the browser to change the address displayed in the URL bar. The web service must still accept the hostname and issue the intended HTTP redirect.

The third mistake is using a temporary redirect for a permanent branding decision without a reason. Temporary redirects have different semantics and can complicate consistent indexing and caching. Choose the status that matches the intended behavior.

The fourth mistake is enabling strict HTTPS policies before both hostnames and relevant subdomains have been tested. HSTS can be valuable, but a broad or premature configuration may make recovery from certificate problems more difficult. Do not enable an includeSubDomains policy casually when unrelated services may exist beneath the domain.

Finally, do not assume that a green homepage test means the contact form, booking flow, customer login, and checkout work. Test the important customer journeys after the redirect is in place.

Check Search Signals and Customer-Facing Materials

Search engines may encounter both hostname versions through old links, bookmarks, and site navigation. Permanent redirects help consolidate the public address, while consistent internal links and canonical URL signals reinforce the preferred version.

Update the website's navigation, XML sitemap, canonical tags, and other configured base URLs to the preferred hostname where applicable. A canonical tag is not a replacement for a working redirect, especially when a customer types the alternate address and encounters an error.

Review social profiles, directory listings, email signatures, business cards, invoices, and printed materials. You do not need to reprint everything merely because it contains the alternate hostname if that address works correctly and redirects. But new materials should use one consistent public version.

A small hotel might have years of brochures containing www. A functioning redirect can preserve those customer visits while the business uses the shorter address on future materials. A dental practice might have appointment reminders pointing to the apex. Both routes should remain dependable.

After a change, review website analytics and search reporting for unexpected errors. A sudden drop in visits to one hostname may be normal if those requests are redirecting correctly; a rise in failed requests is not.

Run a Practical Launch-Day Test

Use this sequence before announcing the website:

1. Confirm the registered domain is active and the authoritative nameservers are correct.
2. Verify DNS answers for the apex and www hostnames.
3. Confirm the hosting platform accepts both names.
4. Check valid HTTPS certificates for both hostnames.
5. Test all four HTTP and HTTPS starting addresses.
6. Verify that redirects reach the preferred hostname without loops.
7. Test a deep page, a contact form, and any booking or checkout flow.
8. Confirm that business email still sends and receives normally.
9. Update new printed and digital materials to the preferred address.
10. Record the final DNS and redirect configuration for future changes.

A simple command-line check can help a technical assistant see the response headers:

curl -I https://www.example.com/services

Look at the HTTP status and any Location header. The command is a diagnostic example, not a complete security or availability test. It may not reveal every application behavior, and certificate errors should be investigated rather than bypassed to make a test appear successful.

If you do not manage servers yourself, send the test results to your website provider. A precise report such as "the apex works over HTTPS, but www returns a certificate mismatch" is far more actionable than "the domain is broken."

How SoxDomains Helps With DNS, Hosting, and HTTPS

At SoxDomains, we provide domain registration and management along with web hosting and SSL certificate options. These services can support the DNS, website, and HTTPS configuration behind a consistent business address.

If your domain is already registered, you usually do not need to purchase it again to fix a www issue. Start by checking where DNS is managed and which hostnames the website service accepts. Our domain management information can help you understand the registration side, while the hosting provider's configuration determines how the site responds.

For a new business, compare domain options before choosing the address that will appear on signs and invoices. Then configure both hostname variations before publishing the website. The best domain is of little use when half the customers' typing habits lead to an error.

Check the specific hosting plan and certificate coverage before purchasing additional products. The right solution may be a small DNS correction, a hosting alias, a certificate update, or a redirect rule rather than a new service.

Make Every Version of Your Business Address Work

Customers should not have to understand DNS to find a bakery, book an appointment, or request an estimate. If your domain is printed with www, that address must work. If a customer leaves it out, that should work too.

Choose one primary hostname, configure DNS and HTTPS for both, and redirect the alternate version cleanly. Test the real customer journey before printing or publishing your next campaign.

Need a dependable domain and hosting foundation for a new website? Explore SoxDomains domain registration and hosting and get the address right before customers start typing it.