{"id":2072,"date":"2026-05-07T15:13:47","date_gmt":"2026-05-07T12:13:47","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=2072"},"modified":"2026-08-02T12:09:22","modified_gmt":"2026-08-02T12:09:22","slug":"how-to-redirect-non-www-to-www-in-wordpress","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/how-to-redirect-non-www-to-www-in-wordpress\/","title":{"rendered":"How to Redirect Non-WWW to WWW in WordPress"},"content":{"rendered":"

A team may choose www.example.com<\/code> as its public hostname even though WordPress and several integrations still use the apex domain. Adding a redirect before those dependencies are aligned can create loops, extra hops or failed callbacks.<\/p>\n

A sound migration makes WWW canonical across WordPress and its consumers, keeps the apex host reachable long enough to issue a direct redirect, and verifies real application paths before the old behavior is retired.<\/p>\n

\nTable of contents<\/strong><\/p>\n
    \n
  1. What it means<\/a><\/li>\n
  2. A realistic WordPress example<\/a><\/li>\n
  3. Why it matters and when to use it<\/a><\/li>\n
  4. A straightforward route for beginners<\/a><\/li>\n
  5. The advanced route<\/a><\/li>\n
  6. Risks, common mistakes, backup, and rollback<\/a><\/li>\n
  7. How AIOWS helps: AIOWS Redirect Manager<\/a><\/li>\n
  8. Related AIOWS articles<\/a><\/li>\n
  9. Conclusion and recommended route<\/a><\/li>\n
  10. Official sources<\/a><\/li>\n<\/ol>\n<\/div>\n

    What it means<\/h2>\n

    An apex-to-WWW redirect sends requests for example.com<\/code> to the same path and query string on www.example.com<\/code>. DNS and TLS must still work for the apex host because the browser connects to it before receiving the redirect.<\/p>\n

    The redirect is only one part of the change. WordPress URLs, canonical tags, cookies, CDN settings, OAuth and payment callbacks, webhooks and outbound links should all agree that WWW is the primary hostname.<\/p>\n

    A realistic WordPress example<\/h2>\n

    An ecommerce site adopts WWW for a new CDN configuration. Its WordPress Address is updated, but the payment provider still returns customers to the apex domain and an old server rule redirects WWW back to the apex. Checkout now crosses both hostnames and can enter a loop.<\/p>\n

    The team first removes the conflicting rule, confirms certificate coverage for both hosts and updates the registered callback. A single exact-host rule then sends each apex request directly to the corresponding HTTPS WWW URL.<\/p>\n

    Why it matters and when to use it<\/h2>\n

    Using one canonical hostname reduces duplicate URLs and makes cache keys, cookies, analytics and external integrations easier to reason about. The change is appropriate when WWW is an intentional site-wide standard, not as a speculative response to an unrelated redirect problem.<\/p>\n

    Complete the surrounding configuration first. If the apex domain cannot complete TLS, no application-level redirect can rescue that request.<\/p>\n

    A straightforward route for beginners<\/h2>\n
      \n
    1. Confirm that both the apex and WWW names resolve to the intended service and have valid certificates.<\/li>\n
    2. Record the current WordPress Address, Site Address, redirect chain and important callback URLs.<\/li>\n
    3. Update WordPress and the required integrations so they use the HTTPS WWW address.<\/li>\n
    4. Remove any rule that sends WWW back to the apex, then add one exact apex-to-WWW redirect in a single layer.<\/li>\n
    5. Test pages, assets, sign-in, checkout, forms, webhooks and representative query strings in a private browser session.<\/li>\n
    6. Keep the previous configuration ready until logs and user journeys remain stable.<\/li>\n<\/ol>\n

      The advanced route<\/h2>\n

      Inspect every response in the chain rather than accepting the final 200 alone. The apex HTTP and HTTPS variants should reach the final HTTPS WWW URL without an intermediate host, a lost query string or a changed request method where that method matters.<\/p>\n

      Check proxy scheme headers, host matching, cookie Domain attributes, CDN cache keys, canonical and hreflang output, sitemaps and provider callback registrations. An exact host condition is safer than constructing a destination from an untrusted incoming Host header.<\/p>\n

      Risks, common mistakes, backup, and rollback<\/h2>\n

      The common failures are missing apex certificate coverage, contradictory redirects at different layers and host-scoped cookies that break authenticated or transactional flows. Broad host matching can also create an open redirect or catch staging domains unexpectedly.<\/p>\n

      Rollback means restoring the previous WordPress URLs and integration settings together with the earlier redirect configuration. Test both hostnames after the reversal so a cached or upstream rule is not mistaken for a successful recovery.<\/p>\n

      \n

      How AIOWS helps:<\/p>\n

      AIOWS Redirect Manager<\/h2>\n

      AIOWS Redirect Manager can hold the WordPress-side apex-to-WWW rule with an explicit source, destination and status. Keeping that rule in a managed interface makes its intent easier to review than an undocumented code fragment.<\/p>\n

      Use a narrowly scoped rule only after DNS, certificates and dependent services are ready. Verify paths and query strings through the public route, and retain the prior configuration until the application checks pass.<\/p>\n

      The module does not provision DNS or TLS and cannot update third-party callback registrations. If an edge proxy or web server already owns hostname canonicalization, keep that responsibility there rather than creating a second competing redirect.<\/p>\n

      Explore AIOWS Redirect Manager<\/a>Compare AIOWS plans<\/a><\/p>\n<\/section>\n

      Related AIOWS articles<\/h2>\n