A site can choose the apex hostname while still failing for visitors who enter WWW. The alternate host needs working DNS and TLS before a redirect can run.
Prepare both entry points, make WordPress and its integrations emit the apex, and keep one direct WWW-to-HTTPS-apex compatibility rule.
What it means
A WWW-to-non-WWW redirect changes only the hostname while preserving the requested path and query. The WWW host must resolve, present a valid certificate, and reach the redirect layer.
Canonical tags, sitemaps, internal links, cookies, and callbacks should use the chosen apex host directly.
A realistic WordPress example
The WordPress URLs use the apex, but the WWW CDN alias and certificate were never configured. HTTPS requests to WWW fail during TLS, before WordPress can redirect them.
Adding the alias and certificate makes the alternate entry valid; a single host-specific rule can then send it to the apex.
Why it matters and when to use it
Consistent hostnames reduce redirect chains and disagreements in cookies, caches, analytics, and search metadata. The alternate host remains necessary for old links and typed addresses.
Use this redirect after the apex has been chosen as the stable canonical hostname.
A straightforward route for beginners
- Verify DNS and valid certificates for WWW and the apex.
- Set the WordPress home and site URLs to the HTTPS apex.
- Identify existing CDN, server, and WordPress host redirects.
- Create one exact rule from WWW to the matching apex URL.
- Preserve the path and query string.
- Test HTTP and HTTPS, deep pages, login, forms, and media.
The advanced route
Audit cookie domains, OAuth and payment callbacks, webhooks, sitemaps, canonicals, analytics filters, and cache keys. Update first-party producers so normal traffic no longer depends on the redirect.
Restrict the rule to the owned WWW hostname to prevent open redirects. Trace all host-and-scheme combinations and confirm that no reverse apex-to-WWW policy or extra HTTPS hop remains.
Risks, common mistakes, backup, and rollback
Missing WWW TLS cannot be repaired after the handshake. Broad host conditions may accept attacker-controlled names, while competing canonical rules can loop.
Save DNS, certificate, WordPress URL, and redirect settings. Restore the previous host policy as one unit if login, callbacks, or cookies regress.
How AIOWS helps:
AIOWS Redirect Manager
AIOWS Redirect Manager can hold the WordPress-side compatibility rule that sends requests from the WWW hostname to the apex domain. Keeping that exact host mapping visible makes its destination and status straightforward to review.
Create an exact host-specific rule only after both names pass TLS. Test direct responses without an administrator cookie and verify path and query preservation.
Redirect Manager cannot create DNS records, issue the WWW certificate, or update external callbacks. Those dependencies must be aligned separately with the apex hostname.
Related AIOWS articles
- How to Redirect Non-WWW to WWW in WordPress
- WordPress Trailing Slash Redirect Problems
- WWW and Non-WWW Redirect Rules for WordPress .htaccess
Conclusion and recommended route
Make both hostnames reachable, configure first-party systems to emit only the apex, and retain one direct WWW-to-HTTPS-apex redirect for compatibility.
