www.example.comand example.comare different hostnames even when they show the same WordPress site. If certificates, URLs, and redirects disagree, visitors may encounter TLS errors or needless redirect chains.
Choose the hostname the business will keep, prepare both entry points, and make every application and integration use the same canonical HTTPS address.
What it means
A canonical host policy selects either WWW or the apex as the permanent public name. Both names still need correct DNS and TLS because the browser verifies the alternate host before it can follow a redirect.
The redirect should go directly to the canonical HTTPS URL without changing the path or query string.
A realistic WordPress example
WordPress emits the apex hostname while marketing links use WWW. The CDN applies separate rules, and the WWW certificate is missing, so visitors see a certificate warning before a two-hop redirect.
Covering both names with valid certificates, aligning WordPress with the chosen host, and replacing the competing rules with one direct redirect fixes the path.
Why it matters and when to use it
Inconsistent hostnames fragment canonical signals, analytics, cookies, callbacks, and caches. They can also break OAuth, payment returns, webhooks, and links copied from administrative screens.
Use this process when consolidating the site on one hostname or correcting an existing chain between WWW, the apex, HTTP, and HTTPS.
A straightforward route for beginners
- Choose the canonical hostname and record the current WordPress home and site URLs.
- Verify DNS and certificates for both WWW and non-WWW.
- Update WordPress to emit the chosen HTTPS host.
- Put one direct redirect from every alternate scheme and host to the canonical URL.
- Preserve paths and query strings, and remove reverse or duplicate rules.
- Test public pages, login, media, forms, and a deep URL on all four entry combinations.
The advanced route
Audit canonical tags, hreflang, sitemaps, internal links, feeds, cookies, CDN cache keys, analytics filters, OAuth callbacks, payment returns, and webhook registrations. Update producers as well as consumers so traffic does not depend indefinitely on redirects.
Trace raw responses for both hosts and both schemes. The accepted path should have at most one canonical hop, identical final content, and no route back to the alternate hostname. Restrict host matching to prevent open redirects.
Risks, common mistakes, backup, and rollback
An alternate hostname without a valid certificate fails before any redirect. Broad host rules can redirect attacker-controlled names, and domain-wide cookies may conceal a mismatch during testing.
Save DNS, certificate bindings, WordPress URLs, and redirect rules. If the cutover breaks administration or an integration, restore the previous canonical settings as a unit instead of adding another redirect.
How AIOWS helps:
AIOWS SSL Manager
AIOWS SSL Manager can help review supported WordPress-side HTTPS and URL settings after both hostnames are valid at the infrastructure layer. It is useful for confirming that WordPress emits the chosen canonical HTTPS address.
AIOWS cannot issue missing certificates, change DNS or CDN bindings, or update third-party callback registrations. Those parts of the hostname cutover remain external.
Use SSL Manager to check WordPress URLs, login, assets, forms, and redirects. Pair that with raw requests to all host and scheme combinations, plus checks of sitemaps and canonical output, before considering the consolidation complete.
Related AIOWS articles
- Cloudflare Flexible SSL Causes a WordPress Redirect Loop
- How to Redirect HTTP to HTTPS in WordPress with .htaccess
- HTTPS Canonical URLs and Sitemaps in WordPress
Conclusion and recommended route
Prepare both entry points, align WordPress and its integrations with one canonical HTTPS hostname, and keep a single path-preserving redirect from the alternate. The hostname choice is complete only when users and automated clients reach the same final URL without chains.
