A hostname rule in .htaccesscan consolidate WWW and non-WWW URLs, but it cannot compensate for missing DNS or certificate coverage. If a CDN enforces the opposite choice, the two layers can send visitors back and forth.
Choose the canonical hostname across WordPress and its integrations, make both names reachable, then match only the alternate host and redirect it once.
What it means
A hostname canonicalization rule sends one host variant to the corresponding path on the chosen host. Both variants need DNS and TLS because the initial connection occurs before Apache returns a redirect.
The destination should be a fixed trusted hostname. Reflecting an arbitrary incoming Host header can create an open redirect or catch names that do not belong to the site.
A realistic WordPress example
WordPress stores the WWW URL, while a CDN rule sends WWW to the apex and Apache sends the apex back to WWW. Sign-in and an OAuth callback cross hosts and fail.
The administrator removes the CDN conflict, adds certificate coverage for both names and updates the callback registration. The Apache rule now matches only the exact apex host and points directly to HTTPS WWW.
Why it matters and when to use it
One hostname keeps canonical tags, cookies, caches, sitemaps and analytics consistent. The rule is useful when Apache is the designated owner and the canonical choice has already been made throughout the application.
Do not add it at the origin when an edge service already performs the same redirect correctly.
A straightforward route for beginners
- Select WWW or the apex as the canonical public hostname.
- Verify DNS and certificates for both variants.
- Align WordPress URLs, internal links and registered callbacks with the canonical name.
- Remove any rule that enforces the opposite direction.
- Add an exact alternate-host condition outside the WordPress markers.
- Test HTTP and HTTPS, paths, queries, sign-in and transactions from both names.
The advanced route
Trace the public and direct-origin routes to identify the responder at each hop. Account for trusted proxy headers and CDN caching before attributing a Location header to Apache.
Use a literal destination host, preserve the request path and required query string, and exclude unrelated aliases or staging names. Verify that noncanonical requests complete in one redirect.
Risks, common mistakes, backup, and rollback
Missing certificate coverage fails before the redirect, while broad regular expressions can include attacker-supplied or administrative hostnames. Conflicting edge and origin rules commonly produce loops.
Back up WordPress, CDN and .htaccesssettings together. A rollback must restore a coherent hostname choice across all three, not just remove the last line edited.
How AIOWS helps:
AIOWS Htaccess Editor
AIOWS Htaccess Editor can be used to review and maintain the Apache rule when hostname canonicalization belongs in the supported .htaccessfile. Keep the custom block separate from WordPress permalink markers.
Save the original file, use an exact host condition and confirm that the public response reaches the fixed destination directly. Test stateful WordPress flows as well as simple pages.
The editor does not create DNS records or certificates and cannot remove a conflicting CDN redirect. Resolve those dependencies in their own systems before relying on the Apache rule.
Related AIOWS articles
- How to Redirect WWW to Non-WWW in WordPress
- How to Redirect Non-WWW to WWW in WordPress
- Best .htaccess Rules to Force HTTPS in WordPress
Conclusion and recommended route
Make one hostname canonical everywhere, ensure both hostnames complete TLS successfully and let a single layer redirect the alternate host directly. Exact matching prevents loops and unrelated hosts from entering the rule.
