Hreflang Là Gì? Hướng Dẫn SEO Đa Ngôn Ngữ Chuẩn Google (2026)

Bạn vừa đầu tư hàng chục triệu để dịch toàn bộ website sang tiếng Anh, kỳ vọng mở rộng thị trường. Nhưng sau ba tháng, Search Console cho thấy một điều khó hiểu: khách từ Singapore vẫn được Google trả về bản tiếng Việt, còn bản tiếng Anh thì gần như không có impression. Tệ hơn, thứ hạng của bản tiếng Việt — vốn đang ổn định — bắt đầu tụt dần. Hai phiên bản của cùng một trang đang tự cạnh tranh với nhau trong mắt Google.

Đây không phải lỗi dịch thuật, cũng không phải lỗi nội dung. Đây là lỗi thiếu tín hiệu hreflang — thứ duy nhất cho Google biết rằng hai URL đó không phải nội dung trùng lặp, mà là hai bản dịch của cùng một trang dành cho hai nhóm người dùng khác nhau. Bài viết này sẽ giải thích hreflang là gì, cú pháp chuẩn, ba cách triển khai, bộ mã ngôn ngữ đúng chuẩn ISO, tám lỗi phổ biến nhất và lộ trình triển khai từng bước cho website WordPress.

Hreflang là gì?

Hreflang là một thuộc tính HTML dùng để khai báo với công cụ tìm kiếm rằng một URL có các phiên bản thay thế dành cho ngôn ngữ hoặc khu vực địa lý khác. Google giới thiệu thuộc tính này từ năm 2011 và đến nay vẫn là tiêu chuẩn duy nhất để xử lý website đa ngôn ngữ, đa quốc gia.

Nói ngắn gọn: hreflang không dịch nội dung, không tạo ra trang mới, không quyết định trang nào xếp hạng cao hơn. Nó chỉ làm đúng một việc — chỉ đường. Khi Google đã xác định được một trang xứng đáng xuất hiện cho một truy vấn, hreflang giúp Google chọn đúng phiên bản ngôn ngữ nào của trang đó để hiển thị cho người tìm kiếm cụ thể.

Cú pháp chuẩn của thẻ hreflang

Dạng phổ biến nhất là thẻ link đặt trong phần head của trang HTML:

• <link rel="alternate" hreflang="vi" href="https://example.com/" />
• <link rel="alternate" hreflang="en" href="https://example.com/en/" />
• <link rel="alternate" hreflang="x-default" href="https://example.com/" />

Ba thành phần bắt buộc: rel="alternate" khai báo đây là bản thay thế; hreflang chứa mã ngôn ngữ (và tùy chọn mã quốc gia); href chứa URL tuyệt đối — bắt buộc đầy đủ giao thức và tên miền, không được dùng đường dẫn tương đối kiểu /en/.

Hreflang KHÔNG phải là gì — ba hiểu lầm phổ biến

Hiểu lầm 1: Hreflang là yếu tố xếp hạng. Không. Google đã nhiều lần khẳng định hreflang là tín hiệu phục vụ (serving signal), không phải tín hiệu xếp hạng (ranking signal). Cài hreflang không đẩy trang lên top. Nó chỉ đảm bảo khi trang đã có thứ hạng, người dùng ở đúng khu vực sẽ thấy đúng bản ngôn ngữ.

Hiểu lầm 2: Hreflang thay thế được thẻ canonical. Không. Hai thứ này giải quyết hai vấn đề khác nhau và phải dùng song song. Nếu bạn chưa nắm rõ vai trò của canonical, hãy đọc kỹ bài thẻ canonical là gì trước khi triển khai hreflang, vì cấu hình sai canonical là nguyên nhân số một khiến toàn bộ cụm hreflang bị Google bỏ qua.

Hiểu lầm 3: Chỉ website đa quốc gia mới cần hreflang. Không hẳn. Một website chỉ phục vụ thị trường Việt Nam nhưng có bản tiếng Việt và bản tiếng Anh cho khách nước ngoài vẫn cần hreflang. Ngược lại, một website chỉ có duy nhất một ngôn ngữ thì hoàn toàn không cần — thêm vào chỉ tạo thêm rủi ro lỗi.

Vì sao hreflang quan trọng với website đa ngôn ngữ?

Ba vấn đề cụ thể mà hreflang giải quyết, xếp theo mức độ thiệt hại thực tế:

1. Chặn nguy cơ bị xem là nội dung trùng lặp

Khi bạn có trang /dich-vu/ tiếng Việt và /en/services/ tiếng Anh với cùng cấu trúc, cùng hình ảnh, cùng bố cục, Googlebot có thể coi đây là hai bản gần giống nhau và chỉ chọn một để lập chỉ mục. Nghiêm trọng hơn là trường hợp cùng một ngôn ngữ cho nhiều thị trường: bản tiếng Anh cho Mỹ và bản tiếng Anh cho Úc gần như giống hệt nhau về câu chữ. Không có hreflang, đây là duplicate content điển hình và Google sẽ tự chọn một bản, loại bản còn lại khỏi kết quả.

2. Gom tín hiệu xếp hạng thay vì chia nhỏ

Đây là lợi ích ít người để ý nhưng có giá trị lớn nhất về dài hạn. Khi các phiên bản ngôn ngữ được liên kết đúng bằng hreflang, Google hiểu chúng là một cụm (cluster). Tín hiệu uy tín thu được ở bản này — backlink, tương tác người dùng, lịch sử hiệu suất — được tính chung cho cả cụm thay vì bị chia lẻ ra từng URL riêng biệt. Một bản tiếng Anh mới ra mắt nhưng nằm trong cụm với bản tiếng Việt đã mạnh sẽ có xuất phát điểm tốt hơn hẳn so với việc đứng một mình.

3. Cải thiện tỷ lệ click và tín hiệu hành vi

Người Việt tìm kiếm mà nhận về trang tiếng Anh sẽ bỏ qua kết quả đó, hoặc click vào rồi thoát ra ngay trong vài giây. Cả hai hành vi đều là tín hiệu tiêu cực. Google ghi nhận truy vấn này không được phục vụ tốt, và về lâu dài thứ hạng của cả cụm bị ảnh hưởng. Đây chính là cơ chế pogo-sticking — người dùng quay lại SERP ngay sau khi click, một trong những tín hiệu xấu nhất mà một trang có thể tạo ra.

Chọn cấu trúc URL trước khi cài hreflang

Đây là bước nhiều người bỏ qua và phải trả giá đắt. Hreflang chỉ là lớp khai báo phía trên; nền móng thật sự là cấu trúc URL. Chọn sai cấu trúc, việc sửa về sau đồng nghĩa với một cuộc migration toàn site kèm hàng nghìn redirect 301 — rủi ro mất traffic rất cao.

Có ba lựa chọn chính, mỗi lựa chọn có đánh đổi riêng:

Tiêu chí	ccTLD (example.vn)	Subdomain (en.example.com)	Subfolder (example.com/en/)
Tín hiệu địa lý gửi Google	Mạnh nhất, tự động	Trung bình, cần khai báo	Yếu nhất, dựa vào hreflang
Kế thừa uy tín tên miền gốc	Không kế thừa	Kế thừa một phần	Kế thừa đầy đủ
Chi phí duy trì	Cao (nhiều tên miền)	Trung bình	Thấp nhất
Độ phức tạp kỹ thuật	Cao, nhiều hệ thống riêng	Trung bình	Thấp, một hệ thống
Phù hợp với	Tập đoàn có pháp nhân từng nước	Site có hạ tầng tách biệt	Đa số doanh nghiệp vừa và nhỏ
Rủi ro duplicate content	Cao nếu không có hreflang	Cao nếu không có hreflang	Trung bình

Khuyến nghị thực tế cho phần lớn doanh nghiệp Việt Nam: dùng subfolder. Lý do đơn giản là toàn bộ uy tín tên miền được dồn về một chỗ, chỉ cần quản lý một hệ thống, một chứng chỉ SSL, một sitemap tổng. Với domain còn trẻ, chia nhỏ uy tín ra nhiều ccTLD gần như chắc chắn dẫn tới việc không tên miền nào đủ mạnh để cạnh tranh. Khi chọn subfolder, hãy áp dụng đúng nguyên tắc trong bài cấu trúc URL chuẩn SEO: đặt mã ngôn ngữ ngay sau tên miền, ngắn gọn, nhất quán trên toàn site.

Một lưu ý quan trọng: không bao giờ dùng tham số truy vấn kiểu example.com/?lang=en để phân biệt ngôn ngữ. Loại URL này khó crawl, dễ sinh vô số biến thể và gây lãng phí crawl budget nghiêm trọng.

Ba cách triển khai hreflang

Google chấp nhận ba cách khai báo hreflang. Cả ba đều có hiệu lực ngang nhau, nhưng chỉ được chọn một cách duy nhất cho mỗi URL — khai báo cùng lúc bằng hai cách sẽ tạo ra tín hiệu mâu thuẫn và Google có thể bỏ qua toàn bộ.

Cách 1 — Thẻ link trong phần head (phổ biến nhất)

Đặt toàn bộ danh sách thẻ link rel="alternate" trong <head> của từng trang. Đây là cách trực quan nhất, dễ kiểm tra bằng mắt qua View Source, và được hỗ trợ bởi hầu hết plugin đa ngôn ngữ.

Nhược điểm: nếu bạn có 5 ngôn ngữ, mỗi trang phải chứa 5 thẻ (kể cả thẻ tự trỏ về chính nó) cộng thêm thẻ x-default. Với site 2.000 trang, đó là hơn 12.000 dòng khai báo nằm rải rác — khối lượng HTML tăng đáng kể và rủi ro sai sót cũng tăng theo.

Lưu ý bắt buộc: thẻ phải nằm trong <head>. Đặt nhầm xuống <body> là lỗi rất hay gặp khi chèn qua trình soạn thảo hoặc qua trình quản lý thẻ, và khi đó Google bỏ qua hoàn toàn.

Cách 2 — HTTP header (cho file không phải HTML)

Tài liệu PDF, file DOCX, hoặc bất kỳ nội dung nào không có phần head thì không thể dùng cách 1. Giải pháp là trả hreflang qua HTTP response header, khai báo ở tầng máy chủ. Cách này ít dùng vì phải can thiệp cấu hình server, nhưng là lựa chọn duy nhất cho thư viện tài liệu đa ngôn ngữ — chẳng hạn một site đăng catalogue sản phẩm dạng PDF cho nhiều thị trường.

Cách 3 — Khai báo trong XML sitemap

Đây là cách được khuyến nghị cho website lớn. Thay vì nhét khai báo vào từng trang, bạn gom toàn bộ quan hệ ngôn ngữ vào file sitemap, dùng namespace xhtml với các phần tử xhtml:link lồng trong mỗi url.

Ưu điểm rất rõ: HTML của trang giữ nguyên độ nhẹ, mọi quan hệ nằm tập trung tại một chỗ nên dễ audit và dễ sửa hàng loạt, và khi thêm một ngôn ngữ mới bạn chỉ sửa sitemap thay vì sửa toàn bộ template. Nhược điểm là không nhìn thấy được khi View Source, nên đội ngũ nội dung khó tự kiểm tra và phải phụ thuộc vào công cụ crawl.

Tiêu chí	Thẻ trong head	HTTP header	XML sitemap
Độ khó triển khai	Thấp	Cao	Trung bình
Ảnh hưởng dung lượng trang	Có, tăng theo số ngôn ngữ	Không	Không
Dùng được cho file PDF	Không	Có	Có
Kiểm tra bằng View Source	Được	Không	Không
Phù hợp quy mô	Dưới 500 trang	Thư viện tài liệu	Từ 500 trang trở lên
Chi phí sửa khi thêm ngôn ngữ	Cao	Trung bình	Thấp

Mã ngôn ngữ và mã quốc gia: viết sai là hỏng cả cụm

Giá trị của thuộc tính hreflang tuân theo hai chuẩn quốc tế, và Google kiểm tra rất chặt: mã ngôn ngữ theo ISO 639-1 (hai chữ cái), mã quốc gia theo ISO 3166-1 Alpha-2 (hai chữ cái, đặt sau dấu gạch ngang). Sai một ký tự là toàn bộ khai báo đó bị bỏ qua.

Ba quy tắc sống còn:

1. Mã ngôn ngữ là bắt buộc, mã quốc gia là tùy chọn. Bạn được phép viết hreflang="vi" nhưng không được viết hreflang="VN". Đây là lỗi kinh điển: nhiều người tưởng “VN” là Việt Nam nên viết như vậy, trong khi Google đọc ký tự đầu tiên như mã ngôn ngữ và không tìm thấy ngôn ngữ nào tên là “vn”.
2. Không tự sáng tạo mã. Nước Anh là en-GB chứ không phải en-UK. Hy Lạp là el chứ không phải gr. Nhật Bản là ja chứ không phải jp. Đan Mạch là da chứ không phải dk.
3. Chữ hoa chữ thường không ảnh hưởng nhưng nên viết nhất quán theo quy ước: ngôn ngữ viết thường, quốc gia viết hoa — vi-VN, en-US, zh-TW.

Bảng mã thường dùng cho doanh nghiệp Việt Nam mở rộng ra khu vực:

Thị trường mục tiêu	Mã đúng	Mã sai hay gặp	Ghi chú
Tiếng Việt (mọi khu vực)	vi	vn, vie	Dùng khi chỉ phân biệt ngôn ngữ
Tiếng Việt tại Việt Nam	vi-VN	vn-VN, vi-vi	Chỉ dùng khi có nhiều bản tiếng Việt
Tiếng Anh quốc tế	en	eng	An toàn nhất nếu chỉ có một bản tiếng Anh
Tiếng Anh tại Mỹ	en-US	en-USA, us
Tiếng Anh tại Anh	en-GB	en-UK	UK không phải mã ISO hợp lệ
Tiếng Anh tại Singapore	en-SG	sg
Tiếng Trung giản thể	zh-Hans	zh-CN đôi khi chưa đủ	Hans là mã chữ viết ISO 15924
Tiếng Hàn	ko	kr
Tiếng Nhật	ja	jp
Tiếng Thái	th	tha

Lời khuyên thực dụng: nếu bạn chỉ có một bản tiếng Anh duy nhất phục vụ toàn thế giới, hãy dùng en chứ đừng dùng en-US. Khai báo en-US nghĩa là bản này chỉ dành cho người dùng ở Mỹ; khách tìm kiếm từ Singapore hay Úc có thể không được phục vụ bản đó. Chỉ thêm mã quốc gia khi bạn thực sự có nhiều bản khác nhau cho cùng một ngôn ngữ.

Thẻ x-default là gì và khi nào cần dùng?

x-default là giá trị đặc biệt, không phải mã ngôn ngữ. Nó chỉ định trang mặc định mà Google sẽ dùng khi người tìm kiếm không khớp với bất kỳ phiên bản ngôn ngữ nào bạn đã khai báo.

Ví dụ cụ thể: site của bạn có bản vi và bản en. Một người dùng ở Đức, ngôn ngữ trình duyệt là tiếng Đức, tìm kiếm thương hiệu của bạn. Google không tìm thấy bản de nào. Nếu không có x-default, Google phải tự đoán — thường là chọn bản khớp gần nhất theo tín hiệu địa lý, và kết quả có thể không như bạn muốn. Có x-default, bạn chủ động nói: “trường hợp không khớp thì đưa họ về trang này”.

Hai tình huống nên dùng x-default:

• Trang chọn ngôn ngữ (language selector). Nếu site có một trang trung lập để người dùng tự chọn khu vực, đó là ứng viên lý tưởng cho x-default.
• Bản ngôn ngữ phổ quát nhất. Nếu không có trang chọn ngôn ngữ, hãy trỏ x-default về bản mà bạn cho là dễ tiếp cận nhất với người ngoài — thường là bản tiếng Anh với site hướng quốc tế, hoặc bản tiếng Việt với site chỉ phục vụ nội địa là chính.

x-default không bắt buộc, nhưng gần như luôn nên có. Nó là mạng lưới an toàn cho mọi trường hợp bạn chưa lường trước — và cấu hình nó chỉ tốn đúng một dòng.

Ba nguyên tắc vàng khiến hreflang hoạt động hay bị Google bỏ qua

Rất nhiều website đã cài hreflang đầy đủ nhưng vẫn không có tác dụng, lý do gần như luôn nằm trong ba nguyên tắc dưới đây. Google xử lý hreflang theo kiểu tất-cả-hoặc-không-gì: chỉ cần một mắt xích trong cụm bị lỗi, cả cụm có thể bị vô hiệu.

Nguyên tắc 1 — Liên kết hai chiều (return link)

Đây là nguyên tắc nghiêm ngặt nhất. Nếu trang A khai báo trang B là bản thay thế, thì trang B bắt buộc phải khai báo ngược lại trang A. Quan hệ phải đối xứng hoàn toàn.

Lý do Google yêu cầu điều này rất hợp lý: nếu chỉ cần một chiều, bất kỳ ai cũng có thể khai báo website của bạn là “bản tiếng Anh” của họ và chiếm dụng tín hiệu. Liên kết hai chiều là cơ chế xác thực — cả hai bên phải cùng đồng ý.

Hệ quả thực tế: mỗi lần thêm một ngôn ngữ mới, bạn phải cập nhật khai báo trên tất cả các bản hiện có, không chỉ thêm bản mới. Đây chính là lý do cách khai báo qua XML sitemap dễ bảo trì hơn hẳn với site nhiều ngôn ngữ.

Nguyên tắc 2 — Mỗi trang phải tự trỏ về chính nó (self-referencing)

Danh sách hreflang trên trang tiếng Việt phải bao gồm cả dòng trỏ về chính trang tiếng Việt đó. Nghe có vẻ thừa nhưng đây là yêu cầu chính thức của Google và là lỗi bị bỏ sót nhiều nhất khi tự code thủ công.

Cách kiểm tra nhanh: nếu site có 3 ngôn ngữ, mỗi trang phải có đúng 4 dòng khai báo — 3 ngôn ngữ cộng 1 dòng x-default. Đếm được 3 dòng nghĩa là đang thiếu self-reference hoặc thiếu x-default.

Nguyên tắc 3 — Canonical phải tự trỏ, không trỏ chéo ngôn ngữ

Đây là lỗi gây thiệt hại nặng nhất và cũng khó phát hiện nhất. Nhiều người nghĩ rằng vì bản tiếng Anh là “bản dịch” của bản tiếng Việt, nên nên đặt canonical của trang tiếng Anh trỏ về trang tiếng Việt. Làm vậy là tự xóa bản tiếng Anh khỏi Google.

Canonical trỏ chéo nghĩa là bạn đang nói: “trang tiếng Anh này chỉ là bản sao, đừng lập chỉ mục nó, hãy dùng bản tiếng Việt thay thế”. Google tuân thủ và loại bản tiếng Anh khỏi kết quả. Đồng thời hreflang lại nói ngược lại — rằng hai trang là bản thay thế ngang hàng. Hai tín hiệu mâu thuẫn, và Google thường chọn tin canonical.

Quy tắc đúng: canonical của mỗi trang luôn trỏ về chính nó. Trang /en/services/ có canonical là /en/services/. Trang /dich-vu/ có canonical là /dich-vu/. Hreflang lo phần liên kết giữa các bản; canonical chỉ lo phần chống trùng lặp trong nội bộ từng ngôn ngữ.

Tương tự, tuyệt đối không đặt thẻ meta robots dạng noindex lên các bản ngôn ngữ phụ với suy nghĩ “để tránh trùng lặp”. Trang bị noindex không thể tham gia cụm hreflang, và mọi khai báo trỏ tới nó đều trở thành liên kết chết.

Triển khai hreflang trên WordPress

WordPress không hỗ trợ đa ngôn ngữ sẵn trong lõi, nên bạn có ba hướng đi. Chọn đúng ngay từ đầu quan trọng hơn nhiều so với việc tối ưu chi tiết về sau, vì đổi plugin đa ngôn ngữ giữa chừng thường đồng nghĩa với việc xây lại toàn bộ cấu trúc URL.

Hướng 1 — Dùng plugin đa ngôn ngữ chuyên dụng

Các plugin phổ biến như Polylang, WPML hay TranslatePress đều tự sinh thẻ hreflang cho mọi trang đã có bản dịch. Đây là lựa chọn của đại đa số website vì bạn gần như không phải đụng vào code.

Tuy nhiên đừng tin tuyệt đối vào plugin. Ba điểm phải tự kiểm tra sau khi cài:

• Kiểm tra self-reference. Một số cấu hình plugin chỉ xuất thẻ cho các ngôn ngữ khác, bỏ qua dòng tự trỏ. Mở View Source và đếm số dòng khai báo.
• Kiểm tra trang chưa dịch. Khi một bài chỉ có bản tiếng Việt mà chưa có bản tiếng Anh, plugin không được phép xuất thẻ hreflang trỏ tới URL tiếng Anh không tồn tại. Đây là nguồn gốc của hàng loạt lỗi “hreflang trỏ tới trang 404”.
• Kiểm tra x-default. Phần lớn plugin không tự thêm x-default, bạn phải bật thủ công trong cài đặt hoặc chèn qua hook.

Hướng 2 — Chèn thủ công qua hook của theme

Với site nhỏ, nội dung đa ngôn ngữ chỉ giới hạn ở vài trang chính (trang chủ, giới thiệu, dịch vụ, liên hệ), cài cả một plugin nặng là thừa. Cách gọn hơn là viết một hàm nhỏ móc vào wp_head, đọc ánh xạ URL từ một mảng cấu hình và xuất thẻ tương ứng.

Ưu điểm là kiểm soát tuyệt đối, không thêm gánh nặng cho site và không phụ thuộc vào vòng đời cập nhật của plugin bên thứ ba. Nhược điểm là không mở rộng được khi số trang tăng lên hàng trăm. Nếu bạn chọn hướng này, hãy rà lại toàn bộ checklist trong bài SEO WordPress để tránh xung đột với các plugin SEO đang chạy — nhiều plugin SEO cũng can thiệp vào wp_head và có thể ghi đè lẫn nhau.

Hướng 3 — Khai báo qua sitemap tùy chỉnh

Với site từ 500 trang đa ngôn ngữ trở lên, đây là hướng bền vững nhất. Bạn tạo một sitemap riêng chứa đầy đủ quan hệ xhtml:link giữa các phiên bản, nộp lên Search Console và để HTML của site hoàn toàn sạch. Mỗi lần thêm ngôn ngữ, bạn sinh lại sitemap thay vì sửa hàng nghìn trang.

Tám lỗi hreflang thường gặp và cách sửa

Dưới đây là các lỗi xuất hiện nhiều nhất khi audit website đa ngôn ngữ, xếp theo mức độ nghiêm trọng:

Lỗi	Biểu hiện	Hậu quả	Cách sửa
Canonical trỏ chéo ngôn ngữ	Trang /en/ có canonical về /vi/	Bản phụ biến mất khỏi Google	Đổi canonical thành tự trỏ
Thiếu return link	A trỏ B nhưng B không trỏ A	Google bỏ qua cả cặp	Bổ sung khai báo ngược trên B
Thiếu self-reference	Trang không có dòng trỏ chính nó	Cụm bị coi là không hợp lệ	Thêm dòng tự trỏ vào mọi trang
Mã ngôn ngữ sai chuẩn	Dùng vn, en-UK, jp, kr	Khai báo bị bỏ qua hoàn toàn	Tra lại ISO 639-1 và ISO 3166-1
Dùng URL tương đối	href=”/en/” thay vì URL đầy đủ	Không được ghi nhận	Chuyển sang URL tuyệt đối có https
Trỏ tới trang 404 hoặc redirect	Bản dịch đã xóa nhưng thẻ còn	Lãng phí crawl, cụm bị lỗi	Đồng bộ thẻ khi xóa hoặc đổi URL
Thẻ nằm ngoài head	Chèn nhầm vào body	Google không đọc được	Đưa về trong head hoặc dùng sitemap
Noindex trên bản ngôn ngữ phụ	Bật noindex để chống trùng lặp	Trang rời khỏi cụm hreflang	Gỡ noindex, để hreflang lo phần này

Một lỗi thứ chín ít gặp hơn nhưng đáng nhắc: trộn lẫn hai cách khai báo. Site vừa xuất thẻ trong head qua plugin, vừa khai báo trong sitemap với ánh xạ khác nhau. Khi hai nguồn mâu thuẫn, Google có xu hướng không tin nguồn nào cả. Hãy chọn đúng một cách và tắt hẳn cách còn lại.

Cách kiểm tra hreflang đã hoạt động chưa

Một thay đổi quan trọng mà nhiều tài liệu cũ chưa cập nhật: báo cáo International Targeting trong Google Search Console đã bị Google gỡ bỏ từ năm 2022. Nếu bạn đang tìm mục báo lỗi hreflang trong giao diện Search Console thì sẽ không thấy — nó không còn tồn tại. Điều này khiến việc tự kiểm tra trở nên quan trọng hơn trước.

Quy trình kiểm tra thực tế gồm bốn lớp, từ nhanh tới sâu:

Lớp 1 — Kiểm tra thủ công bằng View Source

Mở một trang bất kỳ, nhấn Ctrl+U, tìm chuỗi hreflang. Đếm số dòng và đối chiếu với số ngôn ngữ cộng một. Kiểm tra mắt thường ba thứ: có dòng tự trỏ không, URL có đầy đủ https không, mã ngôn ngữ có đúng chuẩn không. Lớp này mất 30 giây và bắt được khoảng một nửa số lỗi.

Lớp 2 — Crawl toàn site

Dùng công cụ crawl để quét toàn bộ site và kiểm tra tính đối xứng của mọi cặp khai báo. Đây là cách duy nhất phát hiện lỗi thiếu return link ở quy mô lớn, vì bạn không thể mở thủ công hàng nghìn trang. Công cụ sẽ liệt kê rõ URL nào khai báo mà không được khai báo ngược lại.

Lớp 3 — Kiểm tra bằng URL Inspection

Trong Google Search Console, dùng công cụ Kiểm tra URL để xem Google thực sự nhìn thấy gì trên trang sau khi render. Đây là bước quan trọng với site dùng JavaScript để chèn thẻ — thẻ có thể tồn tại trong DOM nhưng không có trong HTML thô mà Googlebot đọc ở lượt crawl đầu tiên.

Lớp 4 — Kiểm tra bằng dữ liệu hiệu suất thực

Đây là lớp xác nhận cuối cùng và cũng thuyết phục nhất. Trong báo cáo Hiệu suất của Search Console, lọc theo Quốc gia và đối chiếu với từng trang đích. Nếu hreflang hoạt động đúng, bạn sẽ thấy bản tiếng Anh nhận impression chủ yếu từ các nước nói tiếng Anh, bản tiếng Việt nhận impression chủ yếu từ Việt Nam. Nếu bản tiếng Việt vẫn đang nhận phần lớn impression từ Mỹ, tín hiệu chưa được Google áp dụng.

Lưu ý về thời gian: hreflang không có hiệu lực tức thì. Google phải crawl lại tất cả các trang trong cụm rồi mới đối chiếu được quan hệ hai chiều. Với site vừa và nhỏ, thời gian thực tế thường là hai đến sáu tuần. Đừng đánh giá kết quả sau ba ngày rồi kết luận là không hiệu quả.

Lộ trình triển khai hreflang trong 6 bước

Áp dụng theo đúng thứ tự này để tránh phải làm lại:

1. Chốt cấu trúc URL trước mọi thứ khác. Quyết định subfolder, subdomain hay ccTLD. Ghi lại quy ước đặt tên và tuân thủ tuyệt đối. Đây là quyết định khó đảo ngược nhất nên hãy dành thời gian cho nó.
2. Lập bảng ánh xạ URL. Tạo một bảng tính liệt kê từng trang và URL tương ứng ở mọi ngôn ngữ. Cột nào trống nghĩa là trang đó chưa có bản dịch và tạm thời không được đưa vào cụm hreflang. Bảng này là nguồn sự thật duy nhất cho toàn bộ dự án.
3. Chốt bộ mã ngôn ngữ. Viết ra danh sách mã chính xác theo ISO, kèm trang nào sẽ làm x-default. Kiểm tra chéo với bảng mã ở phần trên để chắc chắn không có mã tự chế.
4. Triển khai và kiểm tra trên một cụm mẫu. Đừng cài cho cả site ngay. Chọn ba đến năm trang quan trọng nhất, cài đầy đủ, kiểm tra kỹ bằng Lớp 1 và Lớp 2. Chỉ khi cụm mẫu hoàn toàn sạch lỗi mới nhân rộng.
5. Nhân rộng toàn site và cập nhật sitemap. Sau khi nhân rộng, nộp lại sitemap lên Search Console để thúc đẩy quá trình crawl lại. Kiểm tra sitemap không chứa URL 404 hay URL bị chuyển hướng.
6. Theo dõi 8 tuần và đối chiếu dữ liệu. Ghi lại chỉ số nền trước khi triển khai (impression theo quốc gia của từng bản), so sánh sau 4 tuần và sau 8 tuần. Đây là cách duy nhất chứng minh hreflang có tác dụng thật.

Checklist rà soát nhanh trước khi kết thúc dự án

• Mọi trang trong cụm đều có dòng hreflang tự trỏ về chính nó.
• Mọi cặp khai báo đều đối xứng hai chiều, không có liên kết một chiều.
• Toàn bộ href dùng URL tuyệt đối, đầy đủ giao thức https.
• Không có mã ngôn ngữ nào nằm ngoài chuẩn ISO 639-1 và ISO 3166-1.
• Có đúng một trang được chỉ định làm x-default.
• Canonical của mọi trang đều tự trỏ, không trỏ chéo sang ngôn ngữ khác.
• Không có bản ngôn ngữ nào bị gắn noindex.
• Không có hreflang nào trỏ tới URL trả về mã 404 hoặc mã chuyển hướng.
• Chỉ dùng duy nhất một phương pháp khai báo trên toàn site.
• Sitemap đã được nộp lại và không chứa URL lỗi.

Hreflang và tín hiệu người dùng: mối liên hệ ít ai nói tới

Phần lớn tài liệu về hreflang dừng lại ở khía cạnh kỹ thuật. Nhưng có một khía cạnh quan trọng hơn về mặt kết quả: hreflang tồn tại để cải thiện trải nghiệm của người thật, và chính trải nghiệm đó mới là thứ Google đo lường.

Hãy hình dung chuỗi sự kiện khi hreflang sai. Người dùng ở Việt Nam tìm kiếm, nhận về trang tiếng Anh, click vào, nhận ra không đọc được, bấm quay lại trong vòng năm giây. Google ghi nhận: truy vấn này, kết quả này, người dùng không hài lòng. Lặp lại vài trăm lần, toàn bộ cụm trang bị đánh giá là không phù hợp với nhóm truy vấn đó.

Ngược lại khi hreflang đúng, người dùng nhận đúng bản ngôn ngữ, ở lại đọc, cuộn trang, click sang trang khác trong site. Toàn bộ chuỗi tín hiệu đảo chiều. Đây là lý do một cấu hình hreflang đúng thường mang lại cải thiện thứ hạng có thể quan sát được — không phải vì hreflang là yếu tố xếp hạng, mà vì nó cải thiện gián tiếp các tín hiệu hành vi vốn có trọng số thật.

Điều này cũng có nghĩa: hreflang đúng nhưng nội dung dịch kém vẫn không cứu được gì. Một bản dịch máy nguyên khối, đọc trúc trắc, không khớp thói quen tìm kiếm của thị trường đích sẽ bị người dùng bỏ đi ngay dù được phục vụ đúng. Hreflang mở đúng cánh cửa; nội dung mới là thứ giữ người ở lại.

Câu hỏi thường gặp về hreflang

Hreflang có bắt buộc không nếu site tôi chỉ có tiếng Việt?

Không. Website đơn ngôn ngữ, chỉ phục vụ một thị trường thì hoàn toàn không cần hreflang. Thêm vào chỉ tạo rủi ro cấu hình sai mà không mang lại lợi ích nào. Chỉ cân nhắc khi bạn thực sự có từ hai phiên bản ngôn ngữ trở lên, hoặc có nhiều bản cùng ngôn ngữ cho các thị trường khác nhau.

Tôi dùng Google Dịch tự động trên site, có cần khai báo hreflang không?

Không nên. Nội dung dịch tự động bằng widget thường không tạo ra URL riêng — nó thay đổi nội dung ngay trên cùng một URL bằng JavaScript. Không có URL riêng thì không có gì để khai báo. Ngoài ra Google đánh giá thấp nội dung dịch máy thuần túy không qua biên tập. Nếu muốn làm nghiêm túc, hãy tạo URL riêng và biên tập lại bản dịch.

Mất bao lâu để thấy hiệu quả sau khi cài hreflang?

Thông thường hai đến sáu tuần với site vừa và nhỏ, lâu hơn với site lớn. Google cần crawl lại toàn bộ các trang trong cụm rồi mới xác minh được quan hệ hai chiều, nên tốc độ phụ thuộc trực tiếp vào tần suất Googlebot ghé thăm site của bạn. Site được crawl thường xuyên sẽ thấy kết quả nhanh hơn rõ rệt.

Hreflang có tác dụng với Bing và các công cụ tìm kiếm khác không?

Bing có hỗ trợ hreflang nhưng ưu tiên thấp hơn, và khuyến nghị bổ sung thẻ meta content-language. Yandex hỗ trợ đầy đủ. Baidu thì không hỗ trợ hreflang, thay vào đó dựa vào thẻ meta ngôn ngữ và tín hiệu máy chủ. Nếu thị trường Trung Quốc quan trọng với bạn, cần một chiến lược kỹ thuật riêng biệt.

Tôi có nên dùng chuyển hướng tự động theo IP thay vì hreflang không?

Tuyệt đối không nên dùng thay thế. Chuyển hướng tự động theo địa chỉ IP gây hai vấn đề nghiêm trọng: Googlebot crawl chủ yếu từ IP tại Mỹ nên sẽ chỉ nhìn thấy một phiên bản duy nhất và không bao giờ lập chỉ mục được các bản còn lại; và người dùng bị khóa cứng vào một bản, không tự chọn được. Nếu vẫn muốn dùng, hãy chuyển sang gợi ý mềm — hiển thị một banner đề nghị đổi ngôn ngữ thay vì tự động chuyển hướng.

Nếu chỉ một vài trang có bản dịch, phần còn lại thì sao?

Hoàn toàn bình thường và rất phổ biến. Hreflang hoạt động theo từng cụm trang độc lập, không yêu cầu toàn site phải đồng bộ. Trang nào có bản dịch thì khai báo cụm riêng cho trang đó; trang chỉ có một ngôn ngữ thì không khai báo gì cả. Điều quan trọng là không bao giờ khai báo trỏ tới một URL bản dịch chưa tồn tại.

Kết luận: bắt đầu từ đâu ngay hôm nay

Hreflang không phải kỹ thuật phức tạp về mặt cú pháp — toàn bộ quy tắc gói gọn trong vài dòng. Cái khó nằm ở tính kỷ luật: quan hệ phải đối xứng tuyệt đối, mã phải đúng chuẩn tuyệt đối, canonical phải nhất quán tuyệt đối. Chỉ một mắt xích lệch là cả hệ thống ngừng hoạt động mà không có thông báo lỗi nào.

Nếu website của bạn đang có nhiều phiên bản ngôn ngữ, hãy làm ba việc ngay trong hôm nay. Thứ nhất, mở View Source một trang bản dịch và kiểm tra xem thẻ canonical đang trỏ về đâu — nếu nó trỏ chéo sang ngôn ngữ khác, bạn vừa tìm ra nguyên nhân khiến bản dịch không bao giờ xuất hiện trên Google. Thứ hai, đếm số dòng hreflang trên trang đó và đối chiếu với công thức số-ngôn-ngữ-cộng-một. Thứ ba, mở báo cáo Hiệu suất trong Search Console, lọc theo quốc gia và xem từng bản ngôn ngữ đang nhận impression từ đâu.

Ba việc này mất chưa tới mười lăm phút nhưng thường đủ để phát hiện lỗi đang âm thầm chặn toàn bộ nỗ lực mở rộng thị trường của bạn. Sửa xong, hãy kiên nhẫn theo dõi tám tuần và đối chiếu số liệu — đó là cách duy nhất biết chắc mọi thứ đã chạy đúng.