WWW và non-WWW

Tóm tắt — www.example.com và example.com là hai hostname riêng biệt thường được cấu hình để phục vụ cùng một website. Không định dạng nào vốn có lợi thế SEO. Việc cần làm chỉ là chọn một phiên bản, chuyển hướng phiên bản kia đến đó và dùng nhất quán ở mọi nơi. Lựa chọn thường phụ thuộc vào hosting và DNS, không phải SEO.

WWW và non-WWW thực chất là gì

www trong địa chỉ web là một subdomain, cùng loại với blog.example.com hoặc shop.example.com. Đây chỉ là quy ước lâu đời mang nghĩa “đây là website”. Phiên bản không có www, example.com, được gọi là bare domain, apex domain hoặc root domain; các tên này chỉ cùng một thứ.

Hai phiên bản thường trỏ đến đúng các trang giống nhau. Vì vậy, câu hỏi “có www hay không” không phải phiên bản nào tạo thành website tốt hơn, mà là địa chỉ nào bạn muốn trình duyệt và công cụ tìm kiếm xem là địa chỉ chính.

Việc này có ảnh hưởng đến thứ hạng không?

Không. Đây là một trong những vấn đề đã rõ ràng nhất trong SEO. Suốt hai thập kỷ, Google luôn nói họ không ưu tiên www hay non-WWW; chuyển đúng cách từ phiên bản này sang phiên bản kia không làm thay đổi thứ hạng.

Do đó, đừng lo phiên bản nào “thân thiện với SEO” hơn. Rủi ro nằm ở cách triển khai cẩu thả: để cả hai phiên bản tải được mà không chọn phiên bản chính, khiến cùng một trang tồn tại ở hai địa chỉ và công cụ tìm kiếm phải tự đoán.

Cách triển khai đúng

1. Chọn một phiên bản — www hoặc non-WWW đều được.
2. Chuyển hướng vĩnh viễn (301) phiên bản kia đến phiên bản đã chọn.
3. Đồng nhất mọi tín hiệu — liên kết nội bộ, sitemap và thẻ canonical đều phải dùng cùng phiên bản.

Trước đây Google Search Console có một cài đặt để khai báo lựa chọn này, nhưng Google đã bỏ nó. Phần Nâng cao giải thích cơ chế thay thế.

Điều mọi người thường hiểu sai nhất

Mọi người xem đây là quyết định SEO, trong khi thực chất là quyết định về hạ tầng. Nhiều website dùng www không phải vì thứ hạng mà vì cách DNS hoạt động; một số cấu hình không thể trỏ bare domain đến đích mong muốn nếu không có bước bổ sung. Tab Nâng cao trình bày cơ chế DNS, bẫy chứng chỉ khi chuyển đổi và lý do lời khuyên về “cookie-free domain” đã lỗi thời.

Tóm tắt — www là subdomain; non-WWW là apex/bare/root domain. Google khẳng định không có khác biệt xếp hạng từ năm 2005 và Mueller nhắc lại tháng 3/2024 rằng khi canonical đổi thì nó chỉ đổi. GSC đã bỏ Preferred Domain ngày 18/6/2019; cơ chế thay thế là tập hợp tín hiệu đồng thuận gồm rel=canonical, sitemap chỉ chứa phiên bản đã chọn và chuyển hướng vĩnh viễn từ phiên bản kia. DNS là lý do thực tế để nhiều website dùng www: CNAME không thể đặt ở zone apex, nên bare domain cần A/AAAA hoặc ALIAS/ANAME/CNAME flattening. Hãy lưu ý TLS/HSTS trên host nguồn chuyển hướng, phạm vi cookie theo hostname và bỏ lập luận cookie-free đã lỗi thời.

www là subdomain; non-WWW là apex

Điểm nền tảng là www là subdomain, có cấu trúc như blog. hoặc shop.. example.com là apex (cũng gọi là bare hoặc root domain), tức zone apex nơi có các bản ghi SOA và NS. Sự khác biệt tưởng nhỏ này lại quyết định toàn bộ câu chuyện DNS.

Không nên dùng mọi phát biểu của Google về subdomain để trả lời câu hỏi xếp hạng này. Câu thường được dẫn của Mueller rằng Google xử lý subdomain và thư mục con “the same” (bản dịch) «giống nhau» về mặt thuật toán nói về cách tổ chức nội dung khác nhau, chẳng hạn blog ở blog.example.com hay /blog/. WWW và non-WWW là nội dung giống nhau ở hai hostname, tức vấn đề canonicalization chứ không phải kiến trúc thông tin.

WWW và non-WWW có ảnh hưởng thứ hạng không? Không.

Câu trả lời ổn định từ rất lâu. Bài viết năm 2005 của Google đã xem đây là vấn đề URL trùng lặp và hợp nhất, không phải xếp hạng. Tháng 3/2024, John Mueller trả lời một chủ website có canonical bị đổi từ www sang non-WWW sau khi chuyển sang Cloudflare: “This won’t cause problems with search visibility / rankings / indexing: when the canonical URL switches, it just switches. You might see a little blip, but it goes to normal very quickly.” (bản dịch) «Điều này không gây vấn đề về khả năng hiển thị, thứ hạng hay lập chỉ mục: khi URL canonical đổi, nó chỉ đổi. Có thể có dao động nhỏ nhưng sẽ nhanh chóng trở lại bình thường.»

Ngoại lệ quan trọng mà ông nêu là: “The only time it would cause bigger changes is if you switch canonicals to a different domain… with a www/non-www switch it’s all within the same domain and you should be fine.” (bản dịch) «Chỉ khi chuyển canonical sang một domain khác mới có thay đổi lớn hơn… còn chuyển www/non-WWW vẫn trong cùng domain nên không sao.» Đây là thay đổi hostname trong cùng registered domain, không phải đổi domain.

Vì vậy, hãy coi câu hỏi thứ hạng là đã được giải quyết và tập trung vào việc thực sự cần làm: DNS và chuyển hướng.

Sự nhất quán giúp loại bỏ mơ hồ do trùng lặp đối với crawler. Nó không bảo đảm thứ hạng, lưu lượng hay lượt trích dẫn từ AI Overview hoặc chatbot; canonicalization đúng chỉ cung cấp một địa chỉ rõ ràng thay vì hai.

Lịch sử cài đặt Preferred Domain của GSC

Trong nhiều năm, Google Search Console có cài đặt Preferred domain để bạn chọn hiển thị website có hay không có www. Nhiều hướng dẫn cũ vẫn yêu cầu bật cài đặt này, nhưng nó không còn tồn tại.

Google thông báo loại bỏ trong bài ngày 18/6/2019 Bye Bye Preferred Domain setting: “As we progress with the migration to the new Search Console experience, we will be saying farewell to one of our settings: preferred domain.” (bản dịch) «Khi tiếp tục chuyển sang trải nghiệm Search Console mới, chúng tôi sẽ chia tay cài đặt preferred domain.» Google cũng ngừng dùng mọi cấu hình cũ: “Note that with the deprecation we will no longer use any existing Search Console preferred domain configuration.” (bản dịch) «Sau khi ngừng hỗ trợ, chúng tôi sẽ không còn dùng cấu hình preferred domain hiện có.»

Không có nút mới thay thế; bạn phải làm cho một tổ hợp tín hiệu đồng thuận. Google liệt kê: “Use rel=“canonical” link tag on HTML pages / Use rel=“canonical” HTTP header / Use a sitemap / Use 301 redirects for retired URLs.” (bản dịch) «Dùng thẻ hoặc HTTP header rel=canonical, sitemap và chuyển hướng 301 cho URL đã ngừng dùng.» Trong thực tế:

1. Chuyển hướng 301 phiên bản không chọn đến phiên bản đã chọn.
2. Thẻ rel=canonical trỏ đến phiên bản đã chọn.
3. Sitemap chỉ liệt kê phiên bản đã chọn; hướng dẫn năm 2005 cũng nói việc có cả hai trong tài khoản “won’t affect the indexing of your site as long as you have submitted a Sitemap for only one version.” (bản dịch) «không ảnh hưởng lập chỉ mục miễn là bạn chỉ gửi sitemap cho một phiên bản.»

Vì sao “gợi ý, không phải quy tắc” khiến tính nhất quán quyết định

Tài liệu canonicalization của Google nói rõ mọi khai báo chỉ là đề xuất: “indicating a canonical preference is a hint, not a rule.” (bản dịch) «việc chỉ định lựa chọn canonical là gợi ý, không phải quy tắc.» Google cân nhắc HTTPS, chuyển hướng, sitemap, rel=canonical và các tín hiệu khác, nên vẫn có thể chọn phiên bản khác nếu backlink và liên kết nội bộ nghiêng về phía đó.

Vì vậy, mọi tín hiệu phải nhất quán. Thẻ canonical trỏ non-WWW trong khi sitemap và một nửa liên kết nội bộ trỏ www là thông điệp mâu thuẫn. Hãy chọn một phiên bản và đồng nhất toàn bộ; www/non-WWW chỉ là một trong khoảng 40 tín hiệu canonicalization.

Vì sao nhiều website mặc định dùng www? DNS.

Câu trả lời thực tế là DNS, không phải SEO hay thương hiệu.

Bản ghi CNAME là cách đơn giản để trỏ hostname đến CDN hoặc nhà cung cấp hosting: đặt www.example.com trỏ đến hostname của họ và hệ thống vẫn hoạt động khi IP thay đổi. Nhưng đặc tả DNS không cho phép CNAME tại zone apex. Apex phải có SOA và NS, trong khi CNAME phải là bản ghi duy nhất tại node; hai quy tắc xung đột, nên CNAME trần tại example.com là không hợp lệ theo RFC 1912/2181.

Để có hành vi tương tự trên bare domain, bạn cần một trong các cách sau:

• Bản ghi A/AAAA (đòi hỏi IP tĩnh mà nhiều CDN/host không cung cấp), hoặc
• ALIAS / ANAME theo nhà cung cấp, hay CNAME flattening của Cloudflare; các giải pháp này mô phỏng CNAME tại apex bằng cách phân giải phía server và không phải nhà cung cấp DNS nào cũng hỗ trợ.

Đây rất có thể là lý do nhiều nền tảng mặc định chọn www: hostname này luôn có thể dùng CNAME đơn giản. Đó là quyết định hosting/DNS được khoác áo SEO.

Cookie bị giới hạn theo hostname đã chọn

Cookie không có thuộc tính Domain là host-only cookie, chỉ được gửi lại đúng host đã đặt nó. Cookie phiên được đặt tại www.example.com mà không có Domain sẽ không đến example.com hay subdomain khác, và ngược lại.

Muốn dùng chung cookie cho apex và các subdomain, hãy đặt Domain thành apex, chẳng hạn Domain=example.com. Theo RFC 6265, giá trị này phải khớp host hiện tại hoặc host cha; trang trên www.example.com có thể đặt Domain=example.com để cookie áp dụng cho apex và mọi subdomain, nhưng không thể đặt cho domain không liên quan.

Điều này đặc biệt quan trọng khi migration. Cookie host-only trên hostname sắp ngừng dùng không đi theo chuyển hướng 301, nên khách có thể bị đăng xuất hoặc mất tùy chọn. Nếu cần tính liên tục, hãy đặt Domain về apex trước khi chuyển; nếu không, hãy dự kiến một lần đăng nhập lại.

Lập luận cookie-free domain đã lỗi thời

Lời khuyên dùng một domain không có cookie cho file tĩnh từng hợp lý thời HTTP/1.1: mọi request đến domain mang cookie đều gửi kèm số byte của cookie, kể cả ảnh và CSS. GTmetrix và PageSpeed từng cảnh báo việc này.

Ngày nay lợi ích gần như biến mất nhờ nén header HPACK của HTTP/2 và CDN phổ biến; tách asset sang host khác còn làm phát sinh kết nối mới. Đừng chọn www/non-WWW hoặc tạo assets subdomain vì lý do này vào năm 2026.

Bẫy HSTS và chứng chỉ

Hostname mà bạn chuyển hướng từ đó vẫn cần chứng chỉ TLS hợp lệ. Chuyển hướng 301 từ https://www.example.com đến https://example.com chỉ chạy sau khi trình duyệt hoàn tất TLS handshake với www.example.com; thiếu chứng chỉ phù hợp sẽ tạo cảnh báo bảo mật trước khi chuyển hướng. Hãy cấp chứng chỉ cho cả hai hostname, riêng biệt hoặc bằng SAN/wildcard.

HSTS khiến yêu cầu này nghiêm ngặt hơn. Chính sách HSTS áp dụng theo host: chính sách trên example.com không tự bảo vệ www.example.com và ngược lại. includeSubDomains chỉ truyền từ parent xuống subdomain, không truyền ngược. Nếu dùng HSTS preload hoặc ép HTTPS, DNS, chứng chỉ và HSTS phải nhất quán trên cả hai hostname.

Bing không có lựa chọn tương đương Preferred Domain

Bing chưa từng có nút preferred-domain. Bing Webmaster Tools xem www, non-WWW và từng tổ hợp HTTP/HTTPS là property riêng để xác minh và báo cáo. Cơ chế hợp nhất vẫn giống Google: chuyển hướng 301 phía server, đồng nhất canonical và URL trong sitemap.

Cách chọn một phiên bản và duy trì nó

1. Chọn theo DNS/hosting, không theo SEO. Nếu host/CDN cần CNAME còn DNS không hỗ trợ ALIAS/flattening, www dễ nhất; nếu apex flattening được hỗ trợ, non-WWW là lựa chọn hợp lý. Thương hiệu có thể là tiêu chí phụ.
2. Chuyển hướng 301 phiên bản kia, không dùng 302 tạm thời.
3. Đồng nhất canonical, sitemap và liên kết nội bộ.
4. Kiểm tra cookie đăng nhập/tùy chọn có phải host-only không. Nếu cần giữ phiên, đặt Domain về apex trước khi đổi.
5. Bảo đảm cả hai hostname có chứng chỉ hợp lệ.
6. Thêm/xác minh property trong Google Search Console (Domain property bao phủ mọi biến thể) và Bing Webmaster Tools (xác minh riêng).

Sau đó hãy để nguyên. Đổi qua lại một thiết lập đang hoạt động không mang lại lợi ích xếp hạng.

Tóm tắt dành cho AI

Bản cô đọng của nội dung Nâng cao:

• Định nghĩa: www là subdomain; example.com là domain apex / bare / root. Đây là lựa chọn canonicalization, không phải xếp hạng.
• Không có khác biệt xếp hạng. Google đã nói vậy từ 2005; Mueller (3/2024) nói canonical trong cùng domain chỉ đổi và có thể dao động ngắn. Phát biểu riêng về subdomain/thư mục con nói đến tổ chức nội dung, không phải vấn đề này. Nhất quán cũng không bảo đảm lưu lượng hay lượt trích dẫn AI.
• Preferred Domain của GSC bị bỏ ngày 18/6/2019. Cơ chế thay thế là rel=canonical, sitemap chỉ chứa phiên bản chọn và 301 từ phiên bản kia.
• Canonical là gợi ý, không phải quy tắc, nên mọi tín hiệu phải đồng thuận; www/non-WWW là một trong khoảng 40 tín hiệu.
• DNS khiến website thường dùng www: CNAME không thể đặt ở apex do xung đột SOA/NS, nên bare domain cần A/AAAA hoặc ALIAS/ANAME/CNAME flattening.
• Cookie có phạm vi hostname: cookie host-only (không có thuộc tính Domain) không đi qua lại; đặt Domain=example.com trước migration nếu cần giữ phiên.
• Lập luận cookie-free domain đã lỗi thời sau HTTP/2.
• Bẫy TLS/HSTS: host nguồn chuyển hướng vẫn cần chứng chỉ; HSTS áp dụng theo host và includeSubDomains chỉ truyền parent → subdomain.
• Bing không có preferred-domain toggle và xem các biến thể là property riêng.
• Khuyến nghị: chọn theo DNS/hosting, 301 phiên bản kia (không dùng 302), đồng nhất mọi tín hiệu, cấp chứng chỉ cho cả hai rồi không thay đổi nữa.

Tài liệu chính thức

Tài liệu nguồn sơ cấp từ các công cụ tìm kiếm.

Google

• Bye Bye Preferred Domain setting (2019) — thông báo loại bỏ ngày 18/6/2019 và danh sách tín hiệu thay thế.
• What is URL canonicalization — các yếu tố Google cân nhắc và nguyên tắc “gợi ý, không phải quy tắc”.
• Consolidate duplicate URLs — hướng dẫn khai báo phiên bản ưu tiên.
• www vs non-www versions of a site (2005) — bài nền tảng, hiện được Google gắn nhãn nội dung cũ.
• SEO Starter Guide — bối cảnh chung về URL trùng lặp và hợp nhất.

Bing / Microsoft

• Bing Webmaster Guidelines — quan điểm chung về canonicalization; không có preferred-domain toggle.
• Better than canonical: URL Normalization — cách Bing chuẩn hóa URL, ưu tiên 301 và coi rel=canonical là tín hiệu thứ cấp.

Trích dẫn từ nguồn

Các phát biểu công khai của Google; mỗi liên kết đi thẳng đến đoạn được trích trong trang nguồn.

Google, 2005 — cách đặt vấn đề ban đầu

• “Two URLs to a site—one that is prefaced with www and one that is not (for instance, https://www.example.com/ and https://example.com/)—often point to the same location on a server. But depending on the server configuration, they may point to different locations, so search engines can’t assume they are the same.” (bản dịch) «Hai URL của một website, một có www và một không, thường trỏ cùng vị trí trên server; nhưng cấu hình có thể khiến chúng trỏ khác nơi nên công cụ tìm kiếm không thể mặc định chúng giống nhau.» — Vanessa Fox, Google. Đi đến trích dẫn
• “Note that having both versions of the site’s URL listed in your account won’t affect the indexing of your site as long as you have submitted a Sitemap for only one version—the version you want to be indexed.” (bản dịch) «Có cả hai phiên bản trong tài khoản không ảnh hưởng lập chỉ mục miễn là sitemap chỉ gửi phiên bản bạn muốn lập chỉ mục.» — Vanessa Fox, Google. Đi đến trích dẫn

Google, tháng 6/2019 — loại bỏ Preferred Domain

• “As we progress with the migration to the new Search Console experience, we will be saying farewell to one of our settings: preferred domain.” (bản dịch) «Khi chuyển sang Search Console mới, chúng tôi sẽ chia tay cài đặt preferred domain.» — Daniel Waisberg, Google. Đi đến trích dẫn
• “Note that with the deprecation we will no longer use any existing Search Console preferred domain configuration.” (bản dịch) «Sau khi ngừng hỗ trợ, chúng tôi không còn dùng cấu hình preferred domain hiện có.» — Daniel Waisberg, Google. Đi đến trích dẫn
• “Use rel=“canonical” link tag on HTML pages” (bản dịch) «Dùng thẻ liên kết rel=canonical trên trang HTML» — lựa chọn đầu tiên trong bốn tín hiệu thay thế (thẻ canonical, HTTP header canonical, sitemap và chuyển hướng 301). Đi đến trích dẫn

Google — canonicalization là gợi ý, không phải quy tắc

• “There are a handful of factors that play a role in canonicalization” (bản dịch) «Có một số yếu tố tham gia vào canonicalization» — gồm HTTP/HTTPS, chuyển hướng, sitemap và rel=canonical; “indicating a canonical preference is a hint, not a rule.” (bản dịch) «khai báo lựa chọn canonical là gợi ý, không phải quy tắc.» Đi đến trích dẫn
• “The canonical page will be crawled most regularly; duplicates are crawled less frequently in order to reduce the crawling load on sites.” (bản dịch) «Trang canonical được crawl thường xuyên nhất; bản trùng lặp ít được crawl hơn để giảm tải.» Đi đến trích dẫn

John Mueller, Google — tháng 3/2024, về đổi canonical www ⇄ non-WWW

• “This won’t cause problems with search visibility / rankings / indexing: when the canonical URL switches, it just switches. You might see a little blip, but it goes to normal very quickly.” (bản dịch) «Việc này không gây vấn đề về hiển thị, thứ hạng hay lập chỉ mục; canonical đổi thì chỉ đổi, có thể dao động nhẹ rồi nhanh chóng bình thường.» — John Mueller trên Reddit.
• “The only time it would cause bigger changes is if you switch canonicals to a different domain, and the domains have something different set up… with a www/non-www switch it’s all within the same domain and you should be fine.” (bản dịch) «Chỉ đổi sang domain khác mới gây thay đổi lớn hơn… www/non-WWW vẫn cùng domain nên không sao.» — John Mueller trên Reddit. Hai trích dẫn là câu trả lời Reddit của Mueller được Barry Schwartz đăng tại Search Engine Roundtable (19/3/2024); thread Reddit gốc chưa được tìm nạp độc lập nên SERoundtable là nguồn được ghi nhận.

John Mueller, Google — subdomain được xử lý giống nhau (bối cảnh hỗ trợ, không dành riêng cho www)

• “In general, we see these the same… I would personally try to keep things together as much as possible… Use subdomains where things are really kind of slightly different.” (bản dịch) «Nhìn chung chúng tôi xem chúng giống nhau… tôi sẽ cố giữ mọi thứ cùng nhau… dùng subdomain khi nội dung thực sự hơi khác.» — John Mueller về subdomain và thư mục con. Đọc bài viết Phát biểu này trả lời câu hỏi tổ chức nội dung khác nhau, không phải thứ hạng www/non-WWW. Bằng chứng trực tiếp cho kết luận đó là bài năm 2005 và câu trả lời năm 2024 ở trên.

Nên chọn phiên bản nào và làm thế nào?

Không có đáp án đúng hơn về SEO. Cây quyết định này dựa trên thực tế DNS/hosting, sau đó đưa ra các bước thực thi. Hãy bắt đầu từ trên cùng.

Checklist hợp nhất www/non-WWW

Kiểm tra một phiên bản là canonical và phiên bản kia được chuyển hướng gọn gàng:

• Đã chọn một phiên bản làm canonical theo DNS/hosting, không theo lợi thế SEO tưởng tượng.
• DNS phân giải apex đúng bằng A/AAAA hoặc ALIAS/ANAME/CNAME flattening; CNAME trần tại apex không hợp lệ.
• Một chuyển hướng 301 duy nhất (vĩnh viễn, không phải 302) từ host phụ đến host chính, được định nghĩa tại đúng một nơi để tránh vòng lặp.
• Cả hai hostname có chứng chỉ TLS hợp lệ, bằng SAN hoặc wildcard.
• HSTS nhất quán; includeSubDomains chỉ truyền parent → subdomain.
• Cookie đặt Domain=example.com trước migration nếu cần giữ phiên/tùy chọn.
• rel=canonical trên mọi trang trỏ đến phiên bản đã chọn.
• XML sitemap chỉ liệt kê URL của phiên bản đã chọn.
• Liên kết nội bộ dùng nhất quán hostname đã chọn.
• Không tạo assets subdomain không cookie chỉ vì lý do thời HTTP/1.1.
• Thêm Domain property trong Google Search Console.
• Xác minh riêng các biến thể trong Bing Webmaster Tools.
• Không định đổi một thiết lập đang hoạt động chỉ vì SEO.

Bảng ghi nhớ www và non-WWW

Quyết định trong nháy mắt

Thực tế DNS của apex và www

Thông tin nhanh

• Preferred Domain bị bỏ ngày 18/6/2019 và cấu hình cũ không còn được dùng.
• Có khoảng 40 tín hiệu canonicalization; www/non-WWW là một trong số đó.
• Domain tĩnh không cookie đã lỗi thời sau HTTP/2.
• Cookie host-only không đi qua www ↔ non-WWW nếu chưa đặt Domain=example.com.
• HSTS includeSubDomains chỉ truyền parent → subdomain.

Chuyển hướng một phiên bản sang phiên bản kia

Chọn phiên bản canonical rồi chuyển hướng 301 phiên bản còn lại. Dưới đây là cấu hình cho ba web server phổ biến; hãy đổi chiều theo lựa chọn của bạn.

Apache (.htaccess) — chuyển non-WWW → www

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

Apache (.htaccess) — chuyển www → non-WWW

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Nginx — chuyển non-WWW → www (server block riêng nên không cần if mỗi request)

server {
    listen 443 ssl;
    server_name example.com;
    # This host still needs a valid cert, or the 301 never fires:
    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://www.example.com$request_uri;
}

Nginx — chuyển www → non-WWW

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/www.example.com.pem;
    ssl_certificate_key /etc/ssl/www.example.com.key;
    return 301 https://example.com$request_uri;
}

IIS (web.config) — chuyển non-WWW → www

<rule name="Redirect to www" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTP_HOST}" pattern="^example\.com$" />
  </conditions>
  <action type="Redirect" url="https://www.example.com/{R:1}"
          redirectType="Permanent" />
</rule>

Chỉ đặt quy tắc ở một nơi. Quy tắc thứ hai theo chiều ngược lại trong plugin, CDN hoặc CMS là nguyên nhân kinh điển của vòng lặp chuyển hướng www/non-WWW.

Xác minh chuyển hướng và cả hai chứng chỉ

macOS / Linux — xác nhận chỉ có một 301 sạch và cả hai host có chứng chỉ hợp lệ:

# Follow the redirect chain — you want ONE 301 to the canonical host
curl -sIL https://example.com/ | grep -Ei 'HTTP/|^location:'

# Check the cert on the host you redirect FROM (must be valid, or the 301 never fires)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates

Windows (PowerShell)

# Inspect the redirect without auto-following it
Invoke-WebRequest -Uri "https://example.com/" -MaximumRedirection 0 `
  -ErrorAction SilentlyContinue | Select-Object StatusCode, Headers

Nếu header Location trỏ đến phiên bản đã chọn với mã 301 và cả hai host xuất trình chứng chỉ hợp lệ, bạn đã hoàn tất.

Những điều không nên làm

Phục vụ cả hai phiên bản mà không chuyển hướng. Đây là kết quả thật sự có hại: mọi trang tồn tại ở cả www và non-WWW mà không được hợp nhất, khiến công cụ tìm kiếm thấy URL trùng lặp và phải đoán canonical.

Dùng 302 thay vì 301. 302 báo “tạm thời”, trong khi bạn cần hợp nhất vĩnh viễn và chuyển giá trị bằng 301. Chỉ dùng 302 cho thay đổi thực sự tạm thời.

Hai quy tắc chuyển hướng đối đầu. CMS gửi non-WWW → www còn CDN gửi www → non-WWW sẽ tạo vòng lặp “too many redirects”. Chỉ thực thi lựa chọn tại một lớp.

Quên chứng chỉ trên host nguồn. Chuyển www → non-WWW nhưng chỉ cấp chứng chỉ bare domain sẽ khiến người truy cập https://www. gặp cảnh báo trước khi 301 chạy. Hãy bao phủ cả hai hostname.

Đổi thiết lập đang hoạt động “vì SEO”. Không có lợi ích xếp hạng, chỉ có rủi ro cấu hình sai hoặc dao động tạm thời. Nếu đang chạy tốt, đừng chạm vào.

Tìm cài đặt Preferred Domain cũ. Nó đã biến mất từ 6/2019 và cấu hình cũ bị bỏ qua. Công việc thật sự là 301, canonical và sitemap.

Tạo assets subdomain không cookie để tăng tốc. Mẹo thời HTTP/1.1 này đã lỗi thời sau HTTP/2; chi phí kết nối mới thường lớn hơn số byte cookie tiết kiệm.

Trộn lẫn tín hiệu. Canonical trỏ non-WWW trong khi sitemap và liên kết nội bộ trỏ www là gợi ý mâu thuẫn. Hãy làm cho mọi tín hiệu đồng thuận.

Các lỗi canonicalization hostname thường gặp

Cả hai hostname đều trả 200

Triệu chứng: www.example.com/page và example.com/page tải độc lập. Nguyên nhân có thể: DNS trỏ cả hai host đến website nhưng không có chuyển hướng host ưu tiên. Cách sửa: Chọn host hiện hành, chuyển hướng vĩnh viễn host kia trong một hop, rồi đồng nhất canonical, liên kết nội bộ và sitemap.

Hostname phụ báo lỗi chứng chỉ

Triệu chứng: HTTPS thất bại trước khi trình duyệt theo chuyển hướng. Nguyên nhân có thể: Chứng chỉ chỉ bao phủ hostname ưu tiên. Cách sửa: Duy trì DNS và TLS hợp lệ trên host chuyển hướng; kết nối HTTPS phải thành công trước khi nhận được HTTP redirect.

Request hostname lặp hoặc tạo chuỗi

Triệu chứng: Request bật qua lại giữa các host hoặc đi qua nhiều hop HTTP, HTTPS, hostname và dấu gạch chéo. Nguyên nhân có thể: Quy tắc CDN, origin và ứng dụng không thống nhất. Cách sửa: Định nghĩa một URL cuối và cho mọi biến thể đi thẳng đến đó tại lớp kiểm soát sớm nhất.

Rà soát kế hoạch migration hostname

Dán bản ghi DNS, hostname trong chứng chỉ, quy tắc chuyển hướng, mẫu canonical, host trong sitemap, cấu hình analytics và bản đồ URL đại diện:

Audit this www/non-www migration plan. Identify contradictions between DNS, TLS,
redirects, canonicals, internal links, sitemaps, and measurement. For every issue,
state the observed evidence, the likely user or crawler impact, the exact check to
run, and whether it blocks launch. Do not claim one hostname has an SEO ranking
advantage. Return a pre-launch table and a post-launch verification sequence.

Công cụ chọn và thực thi một hostname

• Redirect Chain Mapper — lần theo thay đổi HTTP/HTTPS, www/non-WWW, dấu gạch chéo và path để kết thúc ở một URL trong một hop.
• Canonicalization Checker — tìm trang có host canonical xung đột với response hoặc đích chuyển hướng cuối.
• Redirect Checker — kiểm tra cùng path trên hai hostname sau thay đổi cấu hình.
• Công cụ kiểm tra DNS và TLS — xác nhận cả hai hostname phân giải và có chứng chỉ hợp lệ.
• Crawler toàn site — tìm liên kết nội bộ, canonical, hreflang và sitemap còn phát hostname cũ.

Xác minh URL tương đương trên hai host

Bài kiểm tra: Gửi các path www và non-WWW tương ứng vào Redirect Chain Mapper. Kết quả mong đợi: Host ưu tiên tải thành công; host kia chuyển hướng vĩnh viễn cùng path trong một hop. Diễn giải lỗi: Thiếu quy tắc, sai chiều hoặc làm mất path/query. Cửa sổ theo dõi: Ngay sau triển khai. Điều kiện rollback: Vòng lặp, chuyển hàng loạt về trang chủ hoặc lỗi trên host ưu tiên.

Xác minh TLS và các tín hiệu được phát

Bài kiểm tra: Kết nối cả hai hostname HTTPS rồi crawl canonical, liên kết nội bộ và URL sitemap. Kết quả mong đợi: Cả hai chứng chỉ hợp lệ và mọi tín hiệu SEO dùng host ưu tiên. Diễn giải lỗi: Host phụ không thể gửi chuyển hướng hoặc template/cấu hình vẫn dùng host cũ. Cửa sổ theo dõi: Ngay lập tức với TLS, sau một lượt crawl đầy đủ với tín hiệu toàn site. Điều kiện rollback: Lỗi chứng chỉ hoặc xuất hiện nhiều canonical xung đột.

Tự kiểm tra: WWW và non-WWW

Năm câu hỏi nhanh về bản chất lựa chọn www/non-WWW và cách thực thi. Chọn một đáp án cho mỗi câu rồi kiểm tra.

Tài nguyên đáng đọc

Bài viết liên quan của tôi

• Google Uses ~40 Canonicalization Signals — bức tranh rộng hơn về cách Google cân nhắc chuyển hướng, canonical và sitemap.
• Redirects for SEO: A Simple (But Complete) Guide — chuyển giữa các phiên bản bằng 301 mà không mất giá trị.
• Trailing Slash: To Use or Not to Use? — cùng nguyên tắc “chọn một và thực thi nhất quán” cho tín hiệu khác.
• The Beginner’s Guide to Technical SEO — vị trí của canonicalization và hợp nhất hostname trong bức tranh lớn.

Bài nói của tôi

• How Search Works (SlideShare) — trình bày quy trình crawl, render, lập chỉ mục và xếp hạng mà canonicalization cung cấp đầu vào. Tuyên bố miễn trừ vẫn áp dụng: “This is my understanding of systems… not going to be 100% complete or accurate.” (bản dịch) «Đây là cách tôi hiểu các hệ thống… không thể đầy đủ hoặc chính xác 100%.»

Từ ngành

• Bye Bye Preferred Domain setting (Google Search Central) — thông báo loại bỏ năm 2019 và cơ chế thay thế.
• What is URL canonicalization (Google Search Central) — nguyên tắc “gợi ý, không phải quy tắc”.
• Google: Canonicalizing From WWW to Non-WWW Won’t Impact Your Search Rankings (Search Engine Roundtable, Barry Schwartz) — câu trả lời “it just switches” của Mueller tháng 3/2024.
• WWW vs. non-WWW: Which is Better for SEO? (Search Engine Journal, Winston Burton) — tổng quan chọn một phiên bản và chuyển hướng 301 phiên bản kia.
• Why cant a domain’s root be a CNAME — and other tidbits about the DNS (freeCodeCamp) — giải thích giới hạn apex/CNAME.
• CNAME flattening (Cloudflare DNS docs) — cách nhà cung cấp mô phỏng CNAME tại apex.
• HSTS Redirects: WWW to non-WWW and HTTP to HTTPS (Sentinel Stand) — bẫy chứng chỉ và HSTS khi chuyển hướng giữa các host.

Nhật ký thay đổi