WWW Hay Không WWW? Chọn Domain Chính Và Cách Chuyển An Toàn

WWW hay không WWW không chỉ là lựa chọn giao diện khi gõ địa chỉ website. Đây là quyết định kỹ thuật về canonical domain: phiên bản nào được xem là địa chỉ chính, phiên bản còn lại chuyển hướng ra sao, Google Search Console ghi nhận thế nào, cookie có bị mở rộng phạm vi không và các subdomain sẽ vận hành theo cấu trúc nào.

Nếu để đồng thời https://example.com và https://www.example.com trả về cùng một website mà không có quy tắc rõ ràng, bạn đang tạo ra hai URL hợp lệ cho toàn bộ nội dung. Về SEO, đó là rủi ro trùng lặp toàn site, phân tán tín hiệu liên kết và làm sai lệch dữ liệu phân tích.

www là gì và vì sao lựa chọn này vẫn quan trọng?

www là gì? Về mặt kỹ thuật, www là một hostname, thường được dùng làm subdomain của tên miền gốc. Ví dụ, trong www.example.com, phần www là subdomain còn example.com là domain chính.

Ban đầu, tên miền theo dạng www.example.com giúp phân biệt dịch vụ web với các dịch vụ khác như mail, FTP hoặc máy chủ ứng dụng. Hiện nay, website có thể chạy tốt với cả hai dạng:

• https://example.com: phiên bản non-www, còn gọi là apex domain hoặc naked domain.
• https://www.example.com: phiên bản www, trong đó www là subdomain.

Hai URL trên không mặc nhiên là một địa chỉ. Trình duyệt, máy chủ, CDN, công cụ tìm kiếm và hệ thống đo lường có thể xử lý chúng như hai hostname khác nhau. Vì vậy, việc chọn một bản làm canonical domain cần được thực hiện trước hoặc ngay khi triển khai website, không nên để từng đội tự quyết định.

Về SEO, canonical domain không chỉ nằm ở thẻ rel="canonical". Cấu hình đúng phải đồng bộ giữa DNS, HTTPS, redirect 301, liên kết nội bộ, sitemap XML, dữ liệu có cấu trúc, cookie, công cụ phân tích và Google Search Console.

Bảng so sánh domain www và non-www

Không có bằng chứng kỹ thuật đáng tin cậy để kết luận bản www luôn xếp hạng cao hơn bản non-www, hoặc ngược lại. Lợi thế thực tế đến từ khả năng quản trị, tính nhất quán và việc giảm lỗi trong toàn bộ hệ thống.

Nên chọn WWW hay không WWW?

Chọn non-www khi cấu trúc website đơn giản

Non-www thường phù hợp với website doanh nghiệp, blog, trang dịch vụ hoặc thương mại điện tử không có nhiều subdomain phụ thuộc vào domain gốc. URL ngắn giúp giảm một phần ký tự trong quảng cáo, tài liệu in ấn và các kênh truyền thông.

Trường hợp nên nghiêng về non-www gồm:

• Website chỉ phục vụ nội dung qua một hostname chính.
• Không có yêu cầu rõ ràng về việc tách cookie cho các subdomain.
• Hệ thống DNS hoặc nền tảng lưu trữ hỗ trợ apex domain ổn định.
• Thương hiệu đã in, quảng bá và xây liên kết chủ yếu bằng dạng non-www.

Tuy nhiên, non-www không phải lúc nào cũng tối ưu. Một số hạ tầng CDN hoặc nền tảng SaaS xử lý CNAME thuận tiện hơn với subdomain www. Việc cố dùng apex domain trong khi nhà cung cấp yêu cầu CNAME có thể dẫn đến cấu hình DNS vòng vo, phụ thuộc bản ghi ALIAS/ANAME hoặc tính năng riêng của nhà cung cấp.

Chọn www khi cần phân tách hạ tầng và cookie

WWW đáng cân nhắc với website lớn, hệ thống có CDN, nhiều subdomain hoặc kế hoạch phát triển ứng dụng riêng. www.example.com có thể được trỏ CNAME tới lớp CDN, trong khi example.com vẫn dùng cho DNS gốc, email hoặc các dịch vụ khác.

Điểm quan trọng là cookie. Cookie được đặt với thuộc tính Domain=example.com có thể được gửi tới www.example.com và nhiều subdomain phù hợp khác. Ngược lại, cookie chỉ dành cho www.example.com sẽ không tự động gửi tới app.example.com hoặc api.example.com.

Trong hệ thống có tài khoản, giỏ hàng hoặc dữ liệu nhạy cảm, phạm vi cookie rộng làm tăng bề mặt rủi ro. Nếu website dùng www, đội kỹ thuật có thể đặt cookie theo host bằng cách không khai báo thuộc tính Domain, hoặc chỉ định rõ Domain=www.example.com. Cần kiểm tra thêm Secure, HttpOnly và SameSite thay vì chỉ tập trung vào SEO.

Không nên chọn www chỉ vì nghĩ rằng nó “chuyên nghiệp hơn”. Nếu hệ thống không có CDN, không có subdomain đáng kể và thương hiệu đang nhất quán với non-www, việc đổi sang www chỉ tạo thêm một lần migration không cần thiết.

Cấu hình canonical domain đúng về mặt kỹ thuật

Giả sử chọn https://www.example.com làm domain chính, nguyên tắc là mọi truy cập tới biến thể còn lại phải được chuyển hướng một lần duy nhất tới URL tương đương trên bản chính:

http://example.com/trang
→ https://example.com/trang
→ https://www.example.com/trang

Cách tốt hơn là gộp quy tắc để giảm số lần chuyển hướng:

http://example.com/trang
→ https://www.example.com/trang

Tương tự, các biến thể sau cũng phải về đúng một URL:

• http://example.com
• http://www.example.com
• https://example.com
• https://www.example.com

Chỉ bản cuối cùng nên trả về mã trạng thái 200. Ba bản còn lại nên trả về 301 nếu đây là thay đổi vĩnh viễn. Không dùng redirect theo JavaScript, meta refresh hoặc chuyển hướng tạm thời 302 cho một quyết định canonical lâu dài.

Redirect phải giữ nguyên path và query cần thiết. Ví dụ, /san-pham-a phải chuyển tới /san-pham-a, không phải trang chủ. Tham số theo dõi như utm_source có thể được giữ hoặc loại bỏ theo chính sách phân tích, nhưng cần kiểm thử để tránh biến hàng nghìn URL theo dõi thành các biến thể lập chỉ mục.

Ngoài redirect, hãy đồng bộ các lớp sau:

• Thẻ rel="canonical" tự trỏ tới URL trên domain chính.
• Liên kết nội bộ dùng tuyệt đối hoặc tương đối nhưng phải thống nhất hostname.
• Sitemap XML chỉ chứa URL canonical, không trộn hai phiên bản.
• Hreflang, Open Graph, Twitter Card và dữ liệu có cấu trúc dùng domain chính.
• Robots.txt được phục vụ từ domain chính và kiểm tra trên cả hostname phụ.
• Ảnh, JavaScript và CSS không phát sinh redirect hàng loạt do dùng domain cũ.

Thẻ canonical không thay thế redirect. Canonical là tín hiệu gợi ý cho công cụ tìm kiếm, còn redirect buộc người dùng và bot đi tới địa chỉ mới. Với hai hostname cùng trả nội dung, cần dùng cả hai lớp theo đúng vai trò.

Thiết lập Google Search Console khi đổi domain chính

Trong Google Search Console, nên xác minh Domain property cho domain gốc để bao quát HTTP, HTTPS, www và non-www cùng các subdomain. Kiểu xác minh này thường thực hiện qua bản ghi DNS. Đồng thời, có thể thêm các URL-prefix property như:

• https://example.com/
• https://www.example.com/
• http://example.com/
• http://www.example.com/

URL-prefix property hữu ích khi cần xem riêng dữ liệu theo từng phiên bản, nhưng không nên hiểu rằng việc xác minh bốn property sẽ hợp nhất dữ liệu. Mỗi property có phạm vi báo cáo riêng.

Trước khi chuyển, hãy xuất các URL quan trọng từ sitemap, báo cáo hiệu suất và công cụ crawl. Sau đó thực hiện theo thứ tự:

1. Chọn domain chính và cập nhật cấu hình máy chủ trên môi trường staging.
2. Kiểm tra HTTPS, redirect, canonical, sitemap và liên kết nội bộ.
3. Triển khai production vào khung giờ có ít giao dịch, thường dành ít nhất 2–4 giờ để theo dõi trực tiếp.
4. Gửi sitemap mới trong property của domain chính.
5. Kiểm tra các URL quan trọng bằng công cụ kiểm tra URL, log máy chủ và crawler.
6. Theo dõi 404, redirect chain, URL được lập chỉ mục và hiệu suất trong 7, 14 và 28 ngày tiếp theo.

Không nên xóa property cũ ngay sau khi chuyển. Hãy giữ quyền truy cập để theo dõi lỗi, backlink cũ và các URL vẫn được người dùng hoặc bot truy cập. Với thay đổi hostname, tín hiệu thường cần thời gian để xử lý; không nên kết luận migration thất bại chỉ sau 24 giờ.

Cảnh báo: chạy song song hai bản là trùng lặp toàn site

Sai lầm phổ biến nhất là để cả example.com và www.example.com trả mã 200, cùng hiển thị toàn bộ nội dung và chỉ hy vọng Google tự chọn bản đúng. Đây là tình huống chạy song song hai bản, thực chất tạo ra bản sao của toàn website.

Hậu quả có thể gồm:

• Trang sản phẩm, bài viết và danh mục tồn tại ở hai URL.
• Internal link phân tán tín hiệu giữa hai hostname.
• Backlink trỏ vào hai phiên bản, làm tín hiệu phổ biến không tập trung.
• Log và dữ liệu phân tích bị chia đôi, khó xác định URL thật sự hiệu quả.
• Ngân sách crawl bị sử dụng cho các bản sao, đặc biệt ở website lớn.
• Cookie, đăng nhập hoặc giỏ hàng hoạt động không nhất quán giữa hai host.

Chỉ đặt canonical đôi khi vẫn chưa đủ, nhất là khi các URL có thể tiếp tục được người dùng truy cập và liên kết nội bộ vẫn trộn lẫn. Nếu không có yêu cầu kinh doanh bắt buộc phải phục vụ hai hostname độc lập, hãy redirect một bản về bản chính.

Trường hợp không nên chạy song song là website nội dung thông thường, e-commerce một storefront hoặc landing page có một bộ dữ liệu duy nhất. Chỉ cân nhắc hai hostname hoạt động riêng khi chúng thực sự là hai hệ thống khác nhau, có nội dung, cookie, mục đích và chiến lược index độc lập.

Quy trình chuyển WWW và non-WWW an toàn

Migration hostname nhỏ không có nghĩa là không có rủi ro. Trước ngày triển khai, cần lập danh sách URL được crawl, các bản ghi DNS, cấu hình CDN, rule máy chủ, cookie, sitemap, analytics và tích hợp bên thứ ba. Với website có hàng trăm nghìn URL, nên chạy thử trên một nhóm URL đại diện trước khi áp dụng toàn bộ.

Checklist trước khi chuyển

• TTL DNS được hạ xuống khoảng 300–600 giây trước thời điểm thay đổi, nếu nhà cung cấp và quy trình vận hành cho phép.
• Chứng chỉ TLS bao phủ cả domain gốc và hostname www.
• Redirect không tạo chuỗi quá một bước trong kịch bản chuẩn.
• Máy chủ vẫn giữ đúng path, dấu gạch cuối, chữ hoa/thường và tham số cần thiết.
• Canonical, sitemap và liên kết nội bộ đã đổi sang bản chính.
• Cookie, đăng nhập, thanh toán và CORS đã được kiểm tra trên các subdomain.

Checklist sau khi chuyển

• Kiểm tra tối thiểu 20 URL đại diện: trang chủ, danh mục, sản phẩm, bài viết, ảnh và URL lỗi.
• Đo tỷ lệ phản hồi 3xx, 4xx và 5xx trong 24 giờ đầu; đặc biệt điều tra mọi đột biến 404 hoặc 5xx.
• Quét lại website sau 24–72 giờ để tìm canonical trỏ sai, link cũ và redirect chain.
• Đối chiếu dữ liệu organic, chuyển đổi và doanh thu theo ngày trong 7–28 ngày.
• Giữ redirect lâu dài, không gỡ sau vài ngày chỉ vì URL mới đã xuất hiện trên Google.

Chi phí của lựa chọn www hay non-www không nằm ở vài ký tự trong URL. Chi phí thật nằm ở số URL phải chuyển, số hệ thống tích hợp, phạm vi cookie và thời gian đội kỹ thuật phải giám sát. Với website mới, quyết định này có thể hoàn tất trong một buổi kiểm thử. Với website đang có traffic và hàng nghìn backlink, chọn một domain chính ngay từ đầu vẫn luôn rẻ hơn sửa một hệ thống chạy song song hai bản.

Đọc thêm

• Audit website — triển khai trọn gói, có cam kết đo lường bằng số.
• Dịch vụ seo tổng thể — xem phạm vi công việc và mức đầu tư.
• Các Bản Cập Nhật Thuật Toán Google Và Cách Ứng Phó
• Organic Search Trong Bức Tranh Các Kênh Traffic