{"id":4058,"date":"2026-01-03T15:11:22","date_gmt":"2026-01-03T12:11:22","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/www-vs-non-www-canonical-domains-301-redirects-hsts-and-seo-safe-setup\/"},"modified":"2026-01-03T15:11:22","modified_gmt":"2026-01-03T12:11:22","slug":"www-vs-non-www-canonical-domains-301-redirects-hsts-and-seo-safe-setup","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/www-vs-non-www-canonical-domains-301-redirects-hsts-and-seo-safe-setup\/","title":{"rendered":"www vs Non-www Canonical Domains: 301 Redirects, HSTS and SEO-Safe Setup"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Every serious website eventually faces the same question: should the canonical domain be www.example.com or example.com? On the surface it looks like a cosmetic choice, but on real servers this decision touches DNS architecture, SSL, HSTS, cookies, CDNs and SEO signals all at once. Configure it carelessly and you end up with redirect chains, mixed canonical signals and tricky bugs that only appear after browsers cache HSTS for months. Configure it properly and you get a clean, predictable setup where search engines see exactly one main version of your site, visitors always land on HTTPS and your hosting stack is simpler to manage. In this guide we will walk through how we, as the dchost.com team, approach www vs non-www decisions on shared hosting, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> and <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s: how to pick a canonical host, implement 301 redirects correctly on Apache and Nginx, combine that with HSTS and preload, and test the final configuration so it remains SEO-safe for years.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_the_www_vs_Non-www_Decision_Actually_Matters\"><span class=\"toc_number toc_depth_1\">1<\/span> Why the www vs Non-www Decision Actually Matters<\/a><\/li><li><a href=\"#www_vs_Non-www_Real_Technical_Differences\"><span class=\"toc_number toc_depth_1\">2<\/span> www vs Non-www: Real Technical Differences<\/a><ul><li><a href=\"#1_DNS_and_load_balancing\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 1. DNS and load balancing<\/a><\/li><li><a href=\"#2_Cookies_and_subdomain_strategy\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 2. Cookies and subdomain strategy<\/a><\/li><li><a href=\"#3_Perception_and_legacy_links\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 3. Perception and legacy links<\/a><\/li><li><a href=\"#4_HSTS_and_includeSubDomains\"><span class=\"toc_number toc_depth_2\">2.4<\/span> 4. HSTS and includeSubDomains<\/a><\/li><\/ul><\/li><li><a href=\"#SEO_and_Canonicalization_What_Search_Engines_Expect\"><span class=\"toc_number toc_depth_1\">3<\/span> SEO and Canonicalization: What Search Engines Expect<\/a><ul><li><a href=\"#Preferred_SEO_pattern\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Preferred SEO pattern<\/a><\/li><li><a href=\"#Common_SEO_mistakes_with_www_vs_non-www\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Common SEO mistakes with www vs non-www<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_an_SEO-Safe_Canonical_Strategy\"><span class=\"toc_number toc_depth_1\">4<\/span> Designing an SEO-Safe Canonical Strategy<\/a><ul><li><a href=\"#Step_1_Decide_on_www_or_non-www_with_future_needs_in_mind\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Step 1: Decide on www or non-www with future needs in mind<\/a><\/li><li><a href=\"#Step_2_Map_required_redirects\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Step 2: Map required redirects<\/a><\/li><li><a href=\"#Step_3_Choose_where_redirects_are_implemented\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Step 3: Choose where redirects are implemented<\/a><\/li><li><a href=\"#Step_4_Plan_DNS_and_TTLs_for_cutover\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Step 4: Plan DNS and TTLs for cutover<\/a><\/li><\/ul><\/li><li><a href=\"#Implementing_301_Redirects_on_Common_Hosting_Stacks\"><span class=\"toc_number toc_depth_1\">5<\/span> Implementing 301 Redirects on Common Hosting Stacks<\/a><ul><li><a href=\"#Apache_and_htaccess_on_shared_hosting\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Apache and .htaccess on shared hosting<\/a><\/li><li><a href=\"#Nginx_server_block_configuration_on_VPS_or_dedicated_servers\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Nginx server block configuration on VPS or dedicated servers<\/a><\/li><li><a href=\"#Panel-based_hosting_cPanel_DirectAdmin_Plesk\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Panel-based hosting (cPanel, DirectAdmin, Plesk)<\/a><\/li><\/ul><\/li><li><a href=\"#HSTS_Preload_and_Canonical_Hosts_Getting_Strict_HTTPS_Right\"><span class=\"toc_number toc_depth_1\">6<\/span> HSTS, Preload and Canonical Hosts: Getting Strict HTTPS Right<\/a><ul><li><a href=\"#What_HSTS_does_and_why_it_matters_here\"><span class=\"toc_number toc_depth_2\">6.1<\/span> What HSTS does and why it matters here<\/a><\/li><li><a href=\"#Safe_HSTS_strategy_with_www_vs_non-www\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Safe HSTS strategy with www vs non-www<\/a><\/li><li><a href=\"#HSTS_preload_and_the_apex_vs_www\"><span class=\"toc_number toc_depth_2\">6.3<\/span> HSTS preload and the apex vs www<\/a><\/li><\/ul><\/li><li><a href=\"#Testing_Monitoring_and_Avoiding_Common_Pitfalls\"><span class=\"toc_number toc_depth_1\">7<\/span> Testing, Monitoring and Avoiding Common Pitfalls<\/a><ul><li><a href=\"#1_Check_redirect_behaviour_with_curl\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Check redirect behaviour with curl<\/a><\/li><li><a href=\"#2_Watch_for_redirect_chains_and_loops\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Watch for redirect chains and loops<\/a><\/li><li><a href=\"#3_Validate_SEO_signals_in_search_consoles\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Validate SEO signals in search consoles<\/a><\/li><li><a href=\"#4_Combine_with_clean_robotstxt_and_sitemaps\"><span class=\"toc_number toc_depth_2\">7.4<\/span> 4. Combine with clean robots.txt and sitemaps<\/a><\/li><\/ul><\/li><li><a href=\"#Hosting-Side_Best_Practices_and_How_dchostcom_Helps\"><span class=\"toc_number toc_depth_1\">8<\/span> Hosting-Side Best Practices and How dchost.com Helps<\/a><\/li><li><a href=\"#Wrapping_Up_A_Stable_Canonical_Domain_for_the_Long_Term\"><span class=\"toc_number toc_depth_1\">9<\/span> Wrapping Up: A Stable Canonical Domain for the Long Term<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_the_www_vs_Non-www_Decision_Actually_Matters\">Why the www vs Non-www Decision Actually Matters<\/span><\/h2>\n<p>From a pure SEO ranking perspective, modern search engines do not prefer www or non-www by default. What they care about is consistency and clear canonical signals. However, from a hosting and browser behaviour perspective, the choice has practical consequences.<\/p>\n<ul>\n<li><strong>DNS architecture<\/strong>: www is a subdomain and can use CNAME records; the root domain (apex) cannot, which affects certain load-balancing and CDN patterns.<\/li>\n<li><strong>Cookies and subdomains<\/strong>: Setting cookies on the apex vs www has different scopes for subdomains such as app.example.com or cdn.example.com.<\/li>\n<li><strong>Redirect complexity<\/strong>: You must combine HTTP to HTTPS redirects with non-canonical to canonical host redirects without creating chains or loops.<\/li>\n<li><strong>HSTS and preload<\/strong>: If you enable strict HTTPS with HSTS (and includeSubDomains), the relationship between www and the apex becomes even more important.<\/li>\n<\/ul>\n<p>On top of that, many brands have legacy backlinks to both variants and even to multiple domains. If you are managing several domains that point to a single website, our detailed guide on <a href='https:\/\/www.dchost.com\/blog\/en\/birden-fazla-alan-adini-ayni-siteye-yonlendirmek-seo-301-canonical-ve-park-alan-adi-stratejileri\/'>pointing multiple domains to one website with 301 redirects and canonical tags<\/a> is a great companion to this article.<\/p>\n<h2><span id=\"www_vs_Non-www_Real_Technical_Differences\">www vs Non-www: Real Technical Differences<\/span><\/h2>\n<h3><span id=\"1_DNS_and_load_balancing\">1. DNS and load balancing<\/span><\/h3>\n<p>The apex domain example.com usually has A and AAAA records pointing directly to IP addresses. Standards do not allow a plain CNAME at the apex, so if you need advanced DNS-based load balancing you often have to rely on provider-specific features like ALIAS or ANAME records.<\/p>\n<p>In contrast, www.example.com is a regular subdomain. You can point it to another hostname via CNAME (for example to a reverse proxy or CDN entry point), which can make complex architectures simpler. If your long-term plan includes multi-region or anycast setups, having www as your canonical host can reduce future DNS friction.<\/p>\n<h3><span id=\"2_Cookies_and_subdomain_strategy\">2. Cookies and subdomain strategy<\/span><\/h3>\n<p>Browsers attach cookies to domains, and the domain attribute in Set-Cookie headers defines where they are sent:<\/p>\n<ul>\n<li>Cookies for example.com are sent to example.com and all subdomains (www, app, cdn, etc.).<\/li>\n<li>Cookies for www.example.com are sent only to www.example.com and its deeper subdomains (rarely used).<\/li>\n<\/ul>\n<p>If you plan to host static assets or separate apps on subdomains, using www as the canonical host can prevent unnecessary cookies from being sent to cdn.example.com or img.example.com, which slightly improves performance and privacy.<\/p>\n<h3><span id=\"3_Perception_and_legacy_links\">3. Perception and legacy links<\/span><\/h3>\n<p>Many older sites and marketing materials use www by habit. Some industries still expect the www prefix visually. If a brand has 10+ years of links and printed material, we often recommend keeping the historically dominant variant as canonical, provided it works with your DNS and SSL strategy.<\/p>\n<h3><span id=\"4_HSTS_and_includeSubDomains\">4. HSTS and includeSubDomains<\/span><\/h3>\n<p>HTTP Strict Transport Security (HSTS) tells browsers to only use HTTPS for a domain for a defined period. With the includeSubDomains flag, this also covers all subdomains. This is powerful but unforgiving; a misconfigured subdomain will stay broken until HSTS expires in visitors browsers.<\/p>\n<p>When you combine HSTS with the canonical decision, you must think carefully about which host is covered. Our in-depth article on <a href='https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-x-frame-options-ve-referrer-policy-dogru-nasil-kurulur\/'>HTTP security headers including HSTS, CSP and related options<\/a> goes deeper into security trade-offs; here we will focus on how it interacts with www vs non-www.<\/p>\n<h2><span id=\"SEO_and_Canonicalization_What_Search_Engines_Expect\">SEO and Canonicalization: What Search Engines Expect<\/span><\/h2>\n<p>Search engines treat http:\/\/example.com, https:\/\/example.com, http:\/\/www.example.com and https:\/\/www.example.com as four separate URLs. Your job is to collapse them into one canonical home that consistently returns 200, and have the others send strong signals pointing there.<\/p>\n<h3><span id=\"Preferred_SEO_pattern\">Preferred SEO pattern<\/span><\/h3>\n<ul>\n<li><strong>Exactly one<\/strong> variant returns 200 OK as the main homepage (for example https:\/\/www.example.com).<\/li>\n<li>All other variants (<strong>both<\/strong> HTTP and HTTPS, both www and non-www) respond with a single 301 redirect directly to the canonical URL.<\/li>\n<li>The HTML of the canonical page includes a rel=canonical tag referring to itself.<\/li>\n<\/ul>\n<p>This pattern avoids duplicate content, consolidates link equity and provides a very clear signal. If you are planning a larger domain change, our guide on <a href='https:\/\/www.dchost.com\/blog\/en\/alan-adi-degistirirken-seo-kaybetmemek\/'>changing a domain without losing SEO<\/a> explains how to combine domain-level migration with canonical host decisions.<\/p>\n<h3><span id=\"Common_SEO_mistakes_with_www_vs_non-www\">Common SEO mistakes with www vs non-www<\/span><\/h3>\n<ul>\n<li><strong>Serving 200 on both hosts<\/strong> and relying only on canonical tags. Search engines eventually figure it out, but you are wasting crawl budget and risk split signals.<\/li>\n<li><strong>Using 302 or 307 instead of 301<\/strong> for permanent canonical redirects. Temporary redirects do not consolidate signals as strongly.<\/li>\n<li><strong>Creating redirect chains<\/strong>, for example:\n<ul>\n<li>http:\/\/example.com \u2192 301 \u2192 https:\/\/example.com \u2192 301 \u2192 https:\/\/www.example.com<\/li>\n<\/ul>\n<p>    Instead, redirect directly in one hop.\n  <\/li>\n<li><strong>Mixing canonical host with path changes<\/strong> during a redesign. If you must also change URL structure, treat it as a separate project and study our article on <a href='https:\/\/www.dchost.com\/blog\/en\/seo-kaybi-olmadan-url-yapisini-degistirmek-htaccess-ve-nginx-301-yonlendirme-rehberi\/'>SEO-safe URL structure changes with 301 redirects<\/a>.<\/li>\n<\/ul>\n<h2><span id=\"Designing_an_SEO-Safe_Canonical_Strategy\">Designing an SEO-Safe Canonical Strategy<\/span><\/h2>\n<h3><span id=\"Step_1_Decide_on_www_or_non-www_with_future_needs_in_mind\">Step 1: Decide on www or non-www with future needs in mind<\/span><\/h3>\n<p>There is no universal right answer, but we usually use this checklist:<\/p>\n<ul>\n<li><strong>Need for CDN or complex DNS?<\/strong> Canonical www can be more flexible thanks to CNAME and provider-specific features.<\/li>\n<li><strong>Many existing links to one variant?<\/strong> Prefer the historically dominant one unless it conflicts with your technical plan.<\/li>\n<li><strong>Planned subdomains for apps or assets?<\/strong> Canonical www keeps apex available for other roles and reduces cookie leakage.<\/li>\n<\/ul>\n<p>For new projects without legacy constraints we, as dchost.com, often recommend https:\/\/www.example.com as canonical, especially if you plan to grow into more advanced architectures. But if the brand is already established as example.com and you do not expect complex DNS needs, apex as canonical is perfectly fine.<\/p>\n<h3><span id=\"Step_2_Map_required_redirects\">Step 2: Map required redirects<\/span><\/h3>\n<p>Suppose you choose https:\/\/www.example.com as canonical. Then you need:<\/p>\n<ul>\n<li>http:\/\/example.com \u2192 301 \u2192 https:\/\/www.example.com<\/li>\n<li>https:\/\/example.com \u2192 301 \u2192 https:\/\/www.example.com<\/li>\n<li>http:\/\/www.example.com \u2192 301 \u2192 https:\/\/www.example.com<\/li>\n<\/ul>\n<p>If you choose https:\/\/example.com as canonical, simply reverse the roles. The critical point is that each non-canonical variant redirects directly to the canonical URL in a <strong>single step<\/strong>.<\/p>\n<h3><span id=\"Step_3_Choose_where_redirects_are_implemented\">Step 3: Choose where redirects are implemented<\/span><\/h3>\n<p>You can implement these redirects at several layers:<\/p>\n<ul>\n<li>Web server level (Apache, Nginx, LiteSpeed) on your hosting or VPS.<\/li>\n<li>Application level (PHP, Laravel, WordPress plugins) \u2013 not ideal for canonical host redirects.<\/li>\n<li>Edge or CDN level (for example Cloudflare page rules or workers).<\/li>\n<\/ul>\n<p>For reliability and speed, we strongly prefer web server or edge level redirects. Application-level redirects consume unnecessary PHP resources and can behave inconsistently during outages.<\/p>\n<h3><span id=\"Step_4_Plan_DNS_and_TTLs_for_cutover\">Step 4: Plan DNS and TTLs for cutover<\/span><\/h3>\n<p>When changing canonical host or domain, DNS caching can slow down the transition. Before a planned switch, it is smart to lower TTL values a few days in advance so changes propagate faster. We use the same techniques described in our <a href='https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/'>TTL playbook for zero-downtime migrations<\/a> to make canonical host changes feel almost instant.<\/p>\n<h2><span id=\"Implementing_301_Redirects_on_Common_Hosting_Stacks\">Implementing 301 Redirects on Common Hosting Stacks<\/span><\/h2>\n<h3><span id=\"Apache_and_htaccess_on_shared_hosting\">Apache and .htaccess on shared hosting<\/span><\/h3>\n<p>On many shared hosting plans the easiest place to manage canonical redirects is the .htaccess file in your web root. Below is an example for canonical <strong>https:\/\/www.example.com<\/strong>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Enable rewrite engine\nRewriteEngine On\n\n# Force HTTPS and www in one step\nRewriteCond %{HTTPS} !=on [OR]\nRewriteCond %{HTTP_HOST} !^www.example.com$ [NC]\nRewriteRule ^(.*)$ https:\/\/www.example.com\/$1 [L,R=301]\n<\/code><\/pre>\n<p>This rule checks two things:<\/p>\n<ul>\n<li>If the request is not HTTPS, or<\/li>\n<li>If the host is not www.example.com,<\/li>\n<\/ul>\n<p>then it redirects to the canonical host over HTTPS in a single 301. Paths and query strings are preserved by default.<\/p>\n<p>If your canonical host is the apex (https:\/\/example.com), you can invert the condition:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">RewriteEngine On\n\n# Force HTTPS and non-www apex\nRewriteCond %{HTTPS} !=on [OR]\nRewriteCond %{HTTP_HOST} !^example.com$ [NC]\nRewriteRule ^(.*)$ https:\/\/example.com\/$1 [L,R=301]\n<\/code><\/pre>\n<p>On cPanel or DirectAdmin, you can also use the GUI redirect tools, but we recommend inspecting the generated .htaccess to make sure there are no duplicate or chained rules.<\/p>\n<h3><span id=\"Nginx_server_block_configuration_on_VPS_or_dedicated_servers\">Nginx server block configuration on VPS or dedicated servers<\/span><\/h3>\n<p>On a VPS or dedicated server with Nginx you typically create separate server blocks for each host and point non-canonical hosts at a simple redirect block.<\/p>\n<p>Canonical https:\/\/www.example.com setup:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\"># 1) Redirect all HTTP traffic to HTTPS on www\nserver {\n    listen 80;\n    listen [::]:80;\n    server_name example.com www.example.com;\n\n    return 301 https:\/\/www.example.com$request_uri;\n}\n\n# 2) Canonical HTTPS server block\nserver {\n    listen 443 ssl http2;\n    listen [::]:443 ssl http2;\n    server_name www.example.com;\n\n    # SSL config here\n    # ...\n\n    root \/var\/www\/example;\n    index index.php index.html;\n\n    # PHP, caching, etc.\n    # ...\n}\n<\/code><\/pre>\n<p>Here, any request coming to either example.com or www.example.com over HTTP is redirected to HTTPS on www.example.com.<\/p>\n<p>If you prefer apex canonical (https:\/\/example.com), swap roles:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\"># 1) Redirect HTTP to HTTPS on apex\nserver {\n    listen 80;\n    listen [::]:80;\n    server_name example.com www.example.com;\n\n    return 301 https:\/\/example.com$request_uri;\n}\n\n# 2) Redirect HTTPS www to apex\nserver {\n    listen 443 ssl http2;\n    listen [::]:443 ssl http2;\n    server_name www.example.com;\n\n    # SSL config for www\n    # ...\n\n    return 301 https:\/\/example.com$request_uri;\n}\n\n# 3) Canonical HTTPS apex\nserver {\n    listen 443 ssl http2;\n    listen [::]:443 ssl http2;\n    server_name example.com;\n\n    # SSL config for apex\n    # ...\n\n    root \/var\/www\/example;\n    index index.php index.html;\n\n    # Application config\n    # ...\n}\n<\/code><\/pre>\n<p>The principle is the same: everything flows into one canonical HTTPS server block that returns 200, and every other variant is a thin redirect-only server.<\/p>\n<h3><span id=\"Panel-based_hosting_cPanel_DirectAdmin_Plesk\">Panel-based hosting (cPanel, DirectAdmin, Plesk)<\/span><\/h3>\n<p>On managed environments at dchost.com we typically set up:<\/p>\n<ul>\n<li>Separate vhosts for example.com and www.example.com.<\/li>\n<li>Auto-SSL so both hosts have valid HTTPS certificates.<\/li>\n<li>Canonical redirects via vhost configuration or .htaccess, depending on stack.<\/li>\n<\/ul>\n<p>If you are unsure which file or panel option is authoritative on your plan, our support team can check the active vhost configuration and suggest the cleanest place to implement your canonical redirect logic.<\/p>\n<h2><span id=\"HSTS_Preload_and_Canonical_Hosts_Getting_Strict_HTTPS_Right\">HSTS, Preload and Canonical Hosts: Getting Strict HTTPS Right<\/span><\/h2>\n<h3><span id=\"What_HSTS_does_and_why_it_matters_here\">What HSTS does and why it matters here<\/span><\/h3>\n<p>HSTS (HTTP Strict Transport Security) is an HTTP response header telling browsers to:<\/p>\n<ul>\n<li>Always use HTTPS for this domain for a given max-age.<\/li>\n<li>Optionally apply this to all subdomains (includeSubDomains).<\/li>\n<li>Optionally add the domain to the browser preload list (preload directive + separate submission).<\/li>\n<\/ul>\n<p>Once a browser receives a strong HSTS policy, it will never attempt HTTP again until max-age expires. This is fantastic for security but unforgiving for misconfigurations. Our dedicated article on <a href='https:\/\/www.dchost.com\/blog\/en\/httpden-httpse-gecis-rehberi-301-yonlendirme-hsts-ve-seoyu-korumak\/'>full HTTP to HTTPS migration with 301 redirects and HSTS<\/a> walks step by step through a safe HTTPS-only rollout.<\/p>\n<h3><span id=\"Safe_HSTS_strategy_with_www_vs_non-www\">Safe HSTS strategy with www vs non-www<\/span><\/h3>\n<p>Combine HSTS with the canonical decision carefully:<\/p>\n<ul>\n<li><strong>Stage 1<\/strong>: Configure clean HTTPS and 301 redirects between www and non-www; ensure there are no loops or chains.<\/li>\n<li><strong>Stage 2<\/strong>: Enable HSTS <strong>without<\/strong> includeSubDomains and with a modest max-age (for example a few weeks).<\/li>\n<li><strong>Stage 3<\/strong>: After monitoring logs and resolving any HTTPS issues on subdomains, consider includeSubDomains and longer max-age values.<\/li>\n<li><strong>Stage 4<\/strong>: Only when you are absolutely sure all present and future hosts are HTTPS-ready should you consider HSTS preload.<\/li>\n<\/ul>\n<p>For example, on Nginx for canonical https:\/\/www.example.com you might add:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains' always;\n<\/code><\/pre>\n<p>Make sure both example.com and www.example.com respond with valid HTTPS and correct redirects before applying a long HSTS policy. If example.com is non-canonical, it will still need a proper certificate and redirect; otherwise HSTS can lock users into a broken state.<\/p>\n<h3><span id=\"HSTS_preload_and_the_apex_vs_www\">HSTS preload and the apex vs www<\/span><\/h3>\n<p>HSTS preload is a browser-maintained list of domains that ship with an HTTPS-only rule built in. To be eligible, you must serve a specific HSTS header from the <strong>apex domain<\/strong> (not only www), usually with includeSubDomains. This means:<\/p>\n<ul>\n<li>If you preload example.com, every subdomain (including www) must be HTTPS-only forever, or you will break access for users.<\/li>\n<li>You cannot safely preload only www.example.com; browsers key on the apex list.<\/li>\n<\/ul>\n<p>In practice this makes HSTS preload a commitment that affects all current and future subdomains. For many small and medium sites, a strong HSTS policy without preload is already a big win with much less risk.<\/p>\n<h2><span id=\"Testing_Monitoring_and_Avoiding_Common_Pitfalls\">Testing, Monitoring and Avoiding Common Pitfalls<\/span><\/h2>\n<h3><span id=\"1_Check_redirect_behaviour_with_curl\">1. Check redirect behaviour with curl<\/span><\/h3>\n<p>Run tests from your local machine or a server:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -I http:\/\/example.com\ncurl -I https:\/\/example.com\ncurl -I http:\/\/www.example.com\ncurl -I https:\/\/www.example.com\n<\/code><\/pre>\n<p>Verify that:<\/p>\n<ul>\n<li>Non-canonical variants return 301 with Location pointing directly at the canonical HTTPS URL.<\/li>\n<li>The canonical URL returns 200 with the expected content and correct rel=canonical.<\/li>\n<li>HSTS headers appear only on HTTPS responses and match your intended policy.<\/li>\n<\/ul>\n<h3><span id=\"2_Watch_for_redirect_chains_and_loops\">2. Watch for redirect chains and loops<\/span><\/h3>\n<p>Common misconfigurations include:<\/p>\n<ul>\n<li><strong>Double redirects<\/strong>: HTTP non-www \u2192 HTTPS non-www \u2192 HTTPS www. Solve this by combining both rules into one condition, as in the Apache example above.<\/li>\n<li><strong>Infinite loops<\/strong>: For example, one layer forcing www while another layer (CDN or application) forces non-www. Always ensure that only one layer owns the final decision.<\/li>\n<\/ul>\n<h3><span id=\"3_Validate_SEO_signals_in_search_consoles\">3. Validate SEO signals in search consoles<\/span><\/h3>\n<p>After deployment, monitor Google Search Console and other tools for:<\/p>\n<ul>\n<li>Canonical URLs chosen by Google; they should match your preference.<\/li>\n<li>Crawl errors, especially around HTTP vs HTTPS and www vs non-www.<\/li>\n<li>Any sudden drop in impressions or clicks around cutover dates.<\/li>\n<\/ul>\n<p>When we help customers at dchost.com with domain or canonical host changes, we typically schedule the switch at a low-traffic time, keep old URLs redirecting for the long term and log 4xx and 5xx errors closely right after go-live.<\/p>\n<h3><span id=\"4_Combine_with_clean_robotstxt_and_sitemaps\">4. Combine with clean robots.txt and sitemaps<\/span><\/h3>\n<p>Make sure robots.txt and XML sitemaps reference only the canonical host, for example using absolute URLs with https:\/\/www.example.com. If you are reviewing SEO-critical hosting files, our guide on <a href='https:\/\/www.dchost.com\/blog\/en\/robots-txt-ve-sitemap-xml-dogru-kurulumu-adim-adim-seo-ve-hosting-rehberi\/'>setting up robots.txt and sitemap.xml correctly<\/a> is worth reading alongside this article.<\/p>\n<h2><span id=\"Hosting-Side_Best_Practices_and_How_dchostcom_Helps\">Hosting-Side Best Practices and How dchost.com Helps<\/span><\/h2>\n<p>A clean www vs non-www canonical setup is easier when your hosting architecture is predictable and well documented. On our shared hosting, VPS, dedicated server and colocation services we aim for:<\/p>\n<ul>\n<li><strong>Clear vhost separation<\/strong> so each hostname has an explicit configuration and SSL state.<\/li>\n<li><strong>Automatic SSL provisioning<\/strong> for both apex and www hosts so redirects never land on an invalid certificate.<\/li>\n<li><strong>Staging or test environments<\/strong> where you can experiment with redirects and HSTS before enabling them on production.<\/li>\n<li><strong>Monitoring and logging<\/strong> so redirect loops or unexpected 4xx\/5xx responses are caught early.<\/li>\n<\/ul>\n<p>If you are preparing a bigger migration that also changes domain, protocol and infrastructure, combine the ideas here with our detailed <a href='https:\/\/www.dchost.com\/blog\/en\/httpden-httpse-gecis-rehberi-301-yonlendirme-hsts-ve-seoyu-korumak\/'>HTTPS migration guide<\/a> and the <a href='https:\/\/www.dchost.com\/blog\/en\/alan-adi-degistirirken-seo-kaybetmemek\/'>domain change checklist<\/a>. Together they form a complete blueprint for zero-drama migrations.<\/p>\n<p>As the dchost.com team, we regularly help customers audit their existing canonical setup, clean up legacy redirects and design a future-proof configuration that works well with our hosting platform. Whether your site runs on shared hosting, a managed VPS or a dedicated or colocated server, the core principles are the same: pick one canonical host, redirect everything else there with a single 301, enforce HTTPS carefully with HSTS when ready and keep DNS and hosting configuration as simple and explicit as possible.<\/p>\n<h2><span id=\"Wrapping_Up_A_Stable_Canonical_Domain_for_the_Long_Term\">Wrapping Up: A Stable Canonical Domain for the Long Term<\/span><\/h2>\n<p>Choosing between www and non-www is less about winning an argument and more about committing to a clean, long-term architecture. Once you decide, the real work is in aligning DNS, SSL, HSTS, redirects, application settings, robots.txt and sitemaps so they all tell the same story: this is the one canonical home for your content. When you do this well, search engines consolidate signals, browsers stop trying HTTP, users always see the expected URL and your logs become easier to reason about.<\/p>\n<p>If your current setup has grown organically over years of quick fixes, now is a good moment to pause and straighten it out. Start by mapping how your site responds on each variant, design your ideal canonical pattern, then update web server configs and headers step by step. If you host with dchost.com or plan to move to our shared hosting, VPS, dedicated server or colocation services, our team can help you review your canonical domain, plan redirects safely and test everything before and after the cutover. A solid www vs non-www strategy is a small investment that pays off every day in speed, security and SEO stability.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Every serious website eventually faces the same question: should the canonical domain be www.example.com or example.com? On the surface it looks like a cosmetic choice, but on real servers this decision touches DNS architecture, SSL, HSTS, cookies, CDNs and SEO signals all at once. Configure it carelessly and you end up with redirect chains, mixed [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4059,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4058","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4058","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4058"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4058\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4059"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4058"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4058"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4058"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}