Ngôn ngữ

WWW và không WWW

Nên phục vụ trang web từ www.example.com hay example.com; vì sao đây là lựa chọn canonical chứ không phải yếu tố xếp hạng; điều gì thay thế cài đặt Preferred Domain của GSC; và các cơ chế DNS, chứng chỉ thực sự quyết định lựa chọn này.

Xuất bản lần đầu: 3 thg 7, 2026 · Cập nhật lần cuối: 20 thg 8, 2026 · Advanced
Ngôn ngữ
AIĐược viết bởiAI v2
1 tín hiệu bằng chứng trên trang này

www là một tên miền phụ; phiên bản không www là tên miền trần, đỉnh hoặc gốc. Google đã nói từ năm 2005 rằng không có khác biệt về thứ hạng — đây là lựa chọn canonical và tính nhất quán. Cài đặt “Preferred domain” cũ của GSC bị gỡ vào tháng 6 năm 2019; cách thay thế là các tín hiệu nhất quán gồm rel=canonical, sitemap và chuyển hướng 301 từ phiên bản không được chọn. Lý do thực tế khiến nhiều trang mặc định dùng www nằm ở DNS: CNAME không thể đặt tại đỉnh vùng, nên tên miền trần cần bản ghi A, ALIAS hoặc ANAME. Tên máy chủ mà bạn chuyển hướng đi vẫn phải có chứng chỉ TLS hợp lệ. Hãy chọn một phiên bản, chuyển hướng 301 phiên bản còn lại và giữ mọi tín hiệu nhất quán.

Tóm tắt — www là tên miền phụ; không www là tên miền đỉnh/trần/gốc. Google đã nói từ năm 2005 rằng không có khác biệt về thứ hạng, và Mueller tái khẳng định vào tháng 3 năm 2024 (“khi URL canonical chuyển đổi, nó chỉ chuyển đổi”). Cài đặt Preferred Domain của GSC bị gỡ vào 18 tháng 6 năm 2019 — phương án thay thế không phải một nút chuyển mà là nhóm tín hiệu thống nhất: 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 còn lại. Các tín hiệu canonical có thể bất đồng, nên tính nhất quán giữa tất cả tín hiệu quan trọng hơn bất kỳ cài đặt đơn lẻ nào. Lý do thực tế khiến trang mặc định dùng www là DNS — CNAME không thể nằm tại đỉnh vùng, nên tên miền trần cần A/AAAA hoặc ALIAS/ANAME/CNAME-flattening. Hãy chú ý cạm bẫy TLS/HSTS trên phiên bản bạn chuyển hướng từ đó, nhớ rằng cookie chỉ dành cho máy chủ không đi qua tên máy chủ khác trừ khi đặt Domain về đỉnh, và bỏ lập luận tên miền không cookie đã lỗi thời.

Evidence for this claim The www and non-www hostnames are distinct URLs; redirects and canonical signals can consolidate them to a preferred version. Scope: Current Google duplicate URL consolidation guidance. Confidence: high · Verified: Google Search Central: Canonicalization methods Evidence for this claim Changing a site's hostname is a URL-changing site move that requires redirects, updated internal signals, and monitoring rather than a simple ranking toggle. Scope: Current Google site-move guidance. Confidence: high · Verified: Google Search Central: Site moves with URL changes

www là tên miền phụ; không www là đỉnh miền

Hãy bắt đầu từ định nghĩa vì mọi phần sau đều dựa vào đó: www là tên miền phụ, có cấu trúc giống hệt blog. hoặc shop.. example.com là tên miền đỉnh (cũng gọi là “trần” hoặc “gốc”) — đỉnh vùng DNS, nơi đặt các bản ghi SOA và NS của tên miền. Sự phân biệt này nghe có vẻ quá chi li cho đến khi xét đến DNS, nơi nó quyết định toàn bộ vấn đề.

Vì www là tên miền phụ, bạn dễ muốn dùng mọi phát biểu của Google về tên miền phụ để trả lời câu hỏi xếp hạng — nhưng đó là bằng chứng sai mục đích. Câu thường được trích của Mueller rằng Google xử lý tên miền phụ và thư mục con “the same” (bản dịch: «như nhau») về mặt thuật toán trả lời một câu hỏi khác: nên tổ chức nội dung thực sự khác nhau ở đâu, chẳng hạn blog trên blog.example.com so với /blog/. www so với không www không phải lựa chọn kiểu đó; đây là cùng một nội dung có thể truy cập qua hai tên máy chủ, nên là câu hỏi về canonical hóa chứ không phải kiến trúc thông tin. Phần tiếp theo trình bày bằng chứng trực tiếp, dành riêng cho www, về việc “không có khác biệt xếp hạng”.

www so với không www có ảnh hưởng thứ hạng không? Không.

Đây là câu hỏi mọi người thực sự muốn được trả lời, và câu trả lời đã ổn định lâu hơn gần như mọi chủ đề SEO khác. Bài viết gốc năm 2005 của Google đã coi đây là vấn đề URL trùng lặp/hợp nhất, không phải vấn đề xếp hạng. Gần hai mươi năm sau, vào tháng 3 năm 2024, John Mueller trả lời một chủ trang có đợt di chuyển Cloudflare đã âm thầm đổi canonical từ www sang không 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 sẽ không gây vấn đề về khả năng hiển thị tìm kiếm, thứ hạng hay lập chỉ mục: khi URL canonical đổi, nó chỉ đổi theo. Bạn có thể thấy một dao động nhỏ nhưng mọi thứ sẽ nhanh chóng trở lại bình thường.»)

Lưu ý bổ sung của ông nêu đúng điểm phân biệt then chốt: “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 đổi canonical sang một tên miền khác thì mới có thể gây thay đổi lớn hơn… với chuyển đổi www/không www, mọi thứ vẫn trong cùng một tên miền nên bạn sẽ ổn.») Vì vậy đây là thay đổi ít kịch tính: www và không www thuộc cùng một tên miền đã đăng ký. Bạn không đổi tên miền; bạn chỉ chọn một tên máy chủ.

Vì vậy, hãy coi câu hỏi “có ảnh hưởng thứ hạng không?” là đã có đáp án — không — và dành công sức cho phần thực sự cần làm: thiết lập DNS và chuyển hướng.

Cũng cần nói chính xác lợi ích của tính nhất quán: chọn một tên máy chủ và căn chỉnh các tín hiệu sẽ xóa mơ hồ trùng lặp cho trình thu thập. Việc đó không bảo đảm thứ hạng, lưu lượng hay việc AI Overview hoặc chatbot trích dẫn bạn — nó chỉ loại bỏ một vấn đề kỹ thuật có thể tránh được và làm bằng chứng canonical rõ ràng hơn.

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 trực tiếp cho Google biết nên hiển thị trang dưới dạng www hay không www và Google tôn trọng lựa chọn đó. Đây là cài đặt mà nhiều hướng dẫn cũ vẫn bảo bạn bật. Cài đặt này không còn nữa.

Google công bố việc gỡ bỏ trong bài viết ngày 18 tháng 6 năm 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) «Trong quá trình chuyển sang trải nghiệm Search Console mới, chúng tôi sẽ chia tay một trong các cài đặt: tên miền ưu tiên.» Điều quan trọng là Google cũng ngừng tôn trọng 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) «Lưu ý rằng sau khi ngừng hỗ trợ, chúng tôi sẽ không còn dùng bất kỳ cấu hình tên miền ưu tiên nào hiện có trong Search Console.» Vì vậy, dù bạn đã đặt nó từ nhiều năm trước, hiện tại nó không còn tác dụng.

Thứ thay thế tùy chọn cũ không phải là một nút chuyển mới, mà là một tổ hợp tín hiệu cần được giữ nhất quán. Google nêu các lựa chọn trong cùng bài viết đó: “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ẻ liên kết rel=“canonical” trên trang HTML / Dùng tiêu đề HTTP rel=“canonical” / Dùng sơ đồ trang web / Dùng chuyển hướng 301 cho các URL đã ngừng sử dụng.») Trên thực tế, điều đó có nghĩa là:

  1. Chuyển hướng 301 từ phiên bản bạn không chọn sang 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ủa Google đã cảnh báo không gửi sitemap cho cả hai phiên bản.
  4. Liên kết nội bộ nhất quán trỏ đến phiên bản đã chọn.
  5. Chú thích hreflang và mọi tín hiệu URL phát ra khác dùng cùng tên máy chủ.

Vì sao “gợi ý, không phải quy tắc” có nghĩa tính nhất quán sẽ thắng

Đây là lý do tư duy dựa vào một cài đặt duy nhất trước đây trở nên nguy hiểm. Tài liệu canonical của Google nói rõ tất cả những tín hiệu này chỉ là gợi ý: “indicating a canonical preference is a hint, not a rule.” (bản dịch) «Việc chỉ ra một canonical ưu tiên là gợi ý, không phải quy tắc.» Google cân nhắc nhiều yếu tố — HTTP so với HTTPS, chuyển hướng, việc URL có trong sitemap và chú thích rel=canonical — và vẫn có thể chọn phiên bản bạn không muốn nếu các tín hiệu khác như backlink hoặc liên kết nội bộ nghiêng về phía đó.

Đó chính là lý do tính nhất quán giữa mọi tín hiệu quan trọng hơn bất kỳ cài đặt đơn lẻ nào. Thẻ canonical trỏ đến không www trong khi một nửa liên kết nội bộ và sitemap trỏ đến www sẽ tạo thông điệp hỗn hợp. Hãy chọn một phiên bản và làm cho tất cả cùng thống nhất — đây là nguyên tắc “tính nhất quán quan trọng hơn tối ưu hóa” xuyên suốt phần cấu trúc URL của technical SEO.

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

Đây là câu hỏi mà gần như mọi bài viết khác bỏ qua, và cũng là câu trả lời thực sự: DNS, không phải SEO hay thương hiệu.

Bản ghi CNAME là cách đơn giản để trỏ tên máy chủ đến CDN hoặc nhà cung cấp lưu trữ: bạn dùng CNAME để trỏ www.example.com đến tên máy chủ của nhà cung cấp, và cấu hình tiếp tục hoạt động nếu nhà cung cấp đổi IP. Nhưng đặc tả DNS không cho phép CNAME nằm tại đỉnh vùng. Đỉnh miền phải chứa các bản ghi SOA và NS, còn CNAME phải là bản ghi duy nhất tại nút của nó. Hai quy tắc đó xung đột, nên một CNAME thuần tại example.com là không hợp lệ theo đặc tả (RFC 1912 / 2181), và phần lớn nhà cung cấp DNS sẽ từ chối.

Để có hành vi “trỏ đến CDN của tôi” tương tự trên tên miền trần, bạn cần một trong các cách sau:

  • bản ghi A/AAAA (cần IP tĩnh, trong khi nhiều cấu hình CDN/nhà cung cấp không cấp IP này), hoặc
  • bản ghi ALIAS / ANAME riêng của nhà cung cấp, hoặc tính năng CNAME flattening của Cloudflare — tất cả đều mô phỏng CNAME tại đỉnh bằng cách phân giải phía máy chủ. Không phải nhà cung cấp DNS nào cũng hỗ trợ các lựa chọn này.

Trở ngại đó rất có thể là lý do thực tế khiến nhiều nền tảng mặc định dùng www: tên máy chủ này luôn có thể nhận một CNAME đơn giản. Đây là quyết định về hosting/DNS được khoác áo quyết định SEO.

Lựa chọn tên máy chủ còn có một hệ quả dễ bị bỏ sót: phạm vi cookie. Cookie được đặt không có thuộc tính Domain là cookie chỉ dành cho máy chủ — nó chỉ được gửi trở lại đúng máy chủ đã đặt cookie. Nếu đặt cookie phiên trên www.example.com mà không có Domain, cookie đó không bao giờ đến example.com (hoặc tên miền phụ khác), và ngược lại.

Nếu muốn dùng chung cookie giữa đỉnh miền và các tên miền phụ, hãy đặt rõ Domain về đỉnh — ví dụ Domain=example.com. Theo RFC 6265, giá trị Domain của cookie phải khớp máy chủ hiện tại hoặc miền cha của nó. Vì vậy, trang trên www.example.com có thể đặt Domain=example.com để cookie áp dụng cho example.com và mọi tên miền phụ, nhưng không thể đặt Domain cho một tên miền không liên quan.

Điều này quan trọng nhất trong quá trình di chuyển. Nếu cookie phiên hoặc tùy chọn chỉ dành cho máy chủ trên phiên bản sắp ngừng, trạng thái đó không đi qua chuyển hướng 301 sang tên máy chủ mới — người truy cập có thể bị đăng xuất hoặc mất tùy chọn đã lưu ở lần truy cập đầu tiên sau khi chuyển. Hãy đặt Domain về đỉnh trước khi di chuyển nếu bạn cần duy trì trạng thái trên cả hai tên máy chủ trong lúc chuyển hướng hoạt động; nếu không, hãy dự tính một lần đăng nhập lại vào ngày chuyển đổi.

Bạn vẫn sẽ thấy lời khuyên dùng một tên miền không cookie riêng (thường là tên miền trần hoặc một tên miền phụ chuyên cho tài nguyên) để phục vụ tệp tĩnh. Đây từng là tối ưu hóa thực sự thời HTTP/1.1: cookie được gửi theo mọi yêu cầu đến tên máy chủ, nên tách hình ảnh/CSS sang tên máy chủ không cookie tiết kiệm byte.

Lập luận này hiện gần như đã lỗi thời. Nén tiêu đề HPACK của HTTP/2 cùng việc CDN được dùng gần như phổ biến cho tài nguyên tĩnh đã xóa phần lớn lợi ích; tách tài nguyên sang máy chủ riêng còn tốn thêm một lần thiết lập kết nối. Năm 2026, đừng chọn www/không www — hoặc dựng tên miền phụ cho tài nguyên — vì lý do này.

Cạm bẫy HSTS và chứng chỉ

Đây là cạm bẫy thực tế thường xuất hiện giữa lúc chuyển đổi nhưng ít được nói đến. Khi chuyển hướng một tên máy chủ sang tên kia, tên máy chủ bạn chuyển hướng từ đó vẫn cần chứng chỉ TLS hợp lệ riêng. Chuyển hướng 301 từ https://www.example.com sang https://example.com chỉ chạy sau khi trình duyệt bắt tay TLS với www.example.com. Nếu www không có chứng chỉ hợp lệ (hoặc chứng chỉ không bao phủ nó), khách truy cập sẽ thấy cảnh báo bảo mật toàn trang trước khi chuyển hướng chạy. Hãy bao phủ cả hai tên máy chủ bằng chứng chỉ riêng hoặc một chứng chỉ SAN/wildcard.

HSTS khiến yêu cầu này nghiêm ngặt hơn. Chính sách HSTS gắn với từng máy chủ: chính sách đặt trên example.com không tự bảo vệ www.example.com, và ngược lại. includeSubDomains chỉ truyền theo một hướng (chính sách miền cha có thể bao phủ tên miền phụ; chính sách tên miền phụ không bao giờ bao phủ miền cha). Nếu dùng HSTS preload hoặc ép HTTPS, hãy bảo đảm chứng chỉ và HSTS nhất quán trên cả hai tên máy chủ; nếu không, bước ép HTTPS sẽ làm lộ cảnh báo thiếu chứng chỉ trước chuyển hướng.

Bing không có cài đặt tương đương Preferred Domain

Bing chưa từng có nút tên miền ưu tiên. Trong thực tế, Bing Webmaster Tools coi www, không www và từng tổ hợp HTTP/HTTPS là các thuộc tính riêng để xác minh và báo cáo. Vì vậy, ngay cả sau khi chọn canonical và chuyển hướng các biến thể còn lại, bạn vẫn quản lý chúng như các thuộc tính riêng trong Bing. Cơ chế hợp nhất giống Google: đặt 301 phía máy chủ và giữ canonical cùng URL sitemap thống nhất với lựa chọn.

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

  1. Chọn theo thực tế DNS/hosting, không theo SEO. Nếu nhà cung cấp/CDN cần CNAME mà DNS của bạn không hỗ trợ ALIAS/flattening, www là đường ít trở ngại nhất. Nếu DNS hỗ trợ flattening tại đỉnh và bạn thích tên miền trần gọn hơn, hãy chọn không www. Ưu tiên thương hiệu là tiêu chí phụ hợp lý vì đây thực sự là kết quả hòa.
  2. Chuyển hướng 301 phiên bản còn lại — dùng 301 vĩnh viễn, không dùng 302. (302 báo hiệu “tạm thời” và không hợp nhất theo cách bạn cần.)
  3. Giữ thẻ canonical, sitemap và liên kết nội bộ cùng thống nhất một phiên bản.
  4. Kiểm tra cookie đăng nhập/tùy chọn có chỉ dành cho máy chủ không. Nếu cần giữ phiên hoặc tùy chọn qua lần chuyển, hãy đặt Domain về đỉnh trước khi đổi chuyển hướng; nếu không, hãy dự tính người truy cập bị đăng xuất một lần.
  5. Bảo đảm cả hai tên máy chủ đều có chứng chỉ hợp lệ để chuyển hướng không gây cảnh báo.
  6. Thêm/xác minh thuộc tính trong Google Search Console (thuộc tính Domain bao phủ mọi biến thể) và Bing Webmaster Tools (xác minh riêng từng biến thể).

Sau đó hãy để nguyên. Cũng như việc đổi URL nói chung, tranh luận lại www/không www trên một trang đang hoạt động chỉ tốn công mà không mang lại lợi ích xếp hạng.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.