SEO quốc tế: mở thị trường bằng kiến trúc và bằng chứng bản địa, không bằng bản dịch
Dịch vụ SEO quốc tế của RED: ma trận thị trường–ngôn ngữ, chọn kiến trúc URL theo đánh đổi, hreflang đối xứng, ranh giới canonical và đo lường theo từng quốc gia.
Cách hiểu phổ biến nhất về SEO quốc tế cũng là cách hiểu tạo ra nhiều dự án thất bại nhất: dịch toàn bộ website sang năm ngôn ngữ, gắn thẻ hreflang, chờ kết quả.
Vấn đề của cách này không nằm ở kỹ thuật mà ở giả định phía sau. Nó giả định rằng người dùng ở các thị trường khác nhau tìm kiếm theo cùng một cách, chỉ khác ngôn ngữ. Trong thực tế, cùng một sản phẩm có thể được gọi bằng những thuật ngữ hoàn toàn khác nhau ở hai nước cùng nói một ngôn ngữ, cấu trúc kết quả tìm kiếm khác nhau giữa các thị trường, và những gì người mua cần biết trước khi quyết định — về giá, về pháp lý, về cách giao hàng, về đơn vị đo — không giống nhau.
Tài liệu của Google phân biệt rõ hai khái niệm: website đa ngôn ngữ là website có nội dung ở nhiều ngôn ngữ, còn website đa khu vực là website nhắm tới người dùng ở nhiều quốc gia. Một website có thể là một trong hai, hoặc cả hai. Việc lẫn lộn hai chiều này là nguồn gốc của phần lớn các quyết định sai về kiến trúc.
Trang này mô tả cách RED tiếp cận SEO quốc tế: tách rõ chiều quốc gia và chiều ngôn ngữ trước khi bàn về kỹ thuật, chọn kiến trúc URL bằng cách so sánh đánh đổi chứ không theo một khuyến nghị chung, làm rõ khác biệt giữa bản địa hóa và dịch thuật, kiểm tra tính đối xứng của khai báo hreflang, giữ ranh giới giữa hreflang và canonical, xây bằng chứng bản địa từ hiện diện thật, triển khai theo từng thị trường có cổng kiểm soát, và đo lường tách theo quốc gia.
Ranh giới đặt trước: RED không cam kết thứ hạng ở bất kỳ quốc gia hay ngôn ngữ nào, và không tạo các tín hiệu bản địa không phản ánh hoạt động thật của doanh nghiệp.
Quốc gia và ngôn ngữ là hai chiều khác nhau
Câu hỏi: thị trường nào cần một phiên bản riêng, và vì sao?
Hai chiều này thường bị gộp làm một trong các dự án thực tế, dẫn tới hai kiểu sai. Kiểu thứ nhất: tạo một phiên bản tiếng Anh duy nhất cho toàn bộ các thị trường nói tiếng Anh, bỏ qua việc sản phẩm, giá, điều kiện pháp lý và cách gọi tên khác nhau giữa các nước. Kiểu thứ hai: tạo một phiên bản riêng cho mỗi quốc gia trong danh sách mong muốn, kể cả những nước doanh nghiệp chưa bán được hàng, dẫn tới hàng chục phiên bản gần như giống hệt nhau và không ai duy trì nổi.
Ma trận thị trường và ngôn ngữ
| Chiều đánh giá | Câu hỏi | Ảnh hưởng tới quyết định |
|---|---|---|
| Khả năng phục vụ thực tế | Doanh nghiệp có thực sự bán và giao được ở thị trường này không? | Không tạo phiên bản cho thị trường chưa phục vụ được |
| Ngôn ngữ người dùng | Người mua ở thị trường này dùng ngôn ngữ nào để tìm kiếm? | Quyết định số phiên bản ngôn ngữ cần có |
| Khác biệt về sản phẩm | Sản phẩm, gói dịch vụ, tính năng có khác giữa các thị trường không? | Nếu khác thì cần nội dung riêng, không chỉ bản dịch |
| Giá và đơn vị tiền tệ | Giá hiển thị bằng đơn vị nào, có khác nhau không? | Ảnh hưởng nội dung và cấu trúc trang |
| Điều kiện pháp lý | Có ràng buộc về cách quảng bá, về thông tin bắt buộc không? | Có thể buộc phải tách phiên bản dù nội dung giống |
| Nhu cầu tìm kiếm đã tồn tại | Có bằng chứng người ta đang tìm không? | Quyết định thứ tự ưu tiên mở thị trường |
| Cạnh tranh tại thị trường | Ai đang chiếm chỗ trên kết quả tìm kiếm ở đó? | Đánh giá tính khả thi |
| Năng lực vận hành | Có người xử lý yêu cầu bằng ngôn ngữ đó không? | Không mở thị trường nếu không tiếp nhận được khách |
Hai dòng đầu và dòng cuối là các cổng chặn. Nếu doanh nghiệp chưa bán được ở một thị trường, hoặc không có ai trả lời được yêu cầu bằng ngôn ngữ đó, thì việc tạo phiên bản cho thị trường ấy tạo ra chi phí mà không tạo ra giá trị — và tệ hơn, nó tạo ra trải nghiệm xấu cho những người tìm tới rồi không được phục vụ.
Bốn tình huống thường gặp
Nhiều ngôn ngữ, một thị trường: website phục vụ một quốc gia có nhiều ngôn ngữ được sử dụng. Cần các phiên bản ngôn ngữ với URL riêng, không cần phân tách theo khu vực.
Một ngôn ngữ, nhiều thị trường: cùng ngôn ngữ nhưng sản phẩm, giá hoặc điều kiện pháp lý khác nhau giữa các nước. Đây là tình huống khó nhất về mặt kỹ thuật vì các phiên bản gần giống nhau, và cần xử lý cẩn thận để tránh việc chúng bị coi là trùng lặp.
Nhiều ngôn ngữ, nhiều thị trường: tình huống phức tạp nhất, cần cả hai chiều phân tách và cần quản trị chặt để tránh việc số phiên bản bùng nổ.
Một ngôn ngữ, một thị trường nhưng bán ra nước ngoài: doanh nghiệp phục vụ khách hàng quốc tế bằng một ngôn ngữ duy nhất. Trường hợp này thường không cần cấu trúc quốc tế phức tạp.
Nguyên tắc: bắt đầu từ khả năng phục vụ thật, không từ danh sách thị trường mong muốn. Việc mở rộng có thể làm dần theo từng thị trường; việc thu hẹp sau khi đã tạo hàng chục phiên bản thì tốn kém hơn nhiều.
Chọn kiến trúc URL bằng đánh đổi, không bằng một khuyến nghị chung
Câu hỏi: dùng tên miền quốc gia riêng, tên miền phụ, hay thư mục con?
Tài liệu của Google mô tả các phương án cấu trúc URL cho website đa khu vực cùng với ưu nhược điểm của từng phương án, và nêu rằng việc dùng tham số URL để phân biệt phiên bản không được khuyến nghị. Điều tài liệu không làm là chỉ định một phương án tốt nhất cho mọi trường hợp — vì không có.
Việc thị trường có nhiều bài viết khẳng định một cấu trúc luôn tốt hơn các cấu trúc khác là dấu hiệu của việc đơn giản hóa quá mức. Lựa chọn đúng phụ thuộc vào mô hình vận hành, năng lực kỹ thuật và chiến lược thương hiệu của từng doanh nghiệp.
Bản ghi quyết định kiến trúc URL
| Phương án | Phù hợp khi | Điểm mạnh | Điểm yếu | Chi phí vận hành |
|---|---|---|---|---|
| Tên miền quốc gia riêng | Có thực thể pháp nhân hoặc thương hiệu riêng ở từng thị trường; nguồn lực đủ để vận hành nhiều website | Tín hiệu nhắm quốc gia rõ ràng; tách bạch hoàn toàn | Mỗi tên miền phải xây từ đầu; chi phí duy trì cao; khó chia sẻ tài nguyên | Cao |
| Tên miền phụ | Muốn tách hạ tầng hoặc tách đội quản lý nhưng giữ chung thương hiệu | Linh hoạt về hạ tầng; tách được đội quản lý | Cần thiết lập nhắm quốc gia riêng; quản trị phức tạp hơn thư mục con | Trung bình đến cao |
| Thư mục con | Muốn tập trung tài nguyên trên một tên miền; đội quản lý tập trung | Dùng chung một tên miền; triển khai và quản trị đơn giản hơn | Phụ thuộc vào cùng một hạ tầng; khó tách bạch khi cần | Thấp đến trung bình |
| Tham số trong URL | — | — | Không được khuyến nghị cho mục đích này | — |
Ba câu hỏi quyết định lựa chọn trong thực tế.
Đội nào quản lý các phiên bản? Nếu mỗi thị trường có đội riêng với quyền tự chủ cao, tên miền phụ hoặc tên miền riêng phù hợp hơn. Nếu quản lý tập trung, thư mục con giảm đáng kể chi phí vận hành.
Hạ tầng có tách được không? Nếu các thị trường cần hạ tầng khác nhau vì lý do hiệu năng hoặc pháp lý về lưu trữ dữ liệu, phương án tách là bắt buộc.
Thương hiệu có khác nhau không? Nếu doanh nghiệp dùng tên khác nhau ở các thị trường, tên miền riêng là lựa chọn tự nhiên.
Điều quan trọng cần nói rõ: nếu đang có một cấu trúc và cân nhắc chuyển sang cấu trúc khác, đó là một dự án chuyển đổi có rủi ro thật, không phải một điều chỉnh nhỏ. Khi việc mở rộng quốc tế kéo theo thay đổi tên miền, tên miền phụ hoặc đường dẫn, các yêu cầu về bản đồ URL và chuyển hướng của quy trình SEO Migration được áp dụng.
Về việc điều hướng theo địa chỉ IP: tài liệu của Google lưu ý rằng việc thay đổi nội dung dựa trên vị trí suy ra từ IP có hạn chế, vì crawler có thể không thấy được mọi biến thể của trang. Đây là lý do cần có URL riêng cho từng phiên bản thay vì dựa vào việc phát hiện vị trí để phục vụ nội dung khác nhau trên cùng một URL. Gợi ý chuyển phiên bản là chấp nhận được; tự động chuyển hướng bắt buộc thì tạo rủi ro cho cả người dùng lẫn crawler.
Bản địa hóa không phải dịch từng chữ
Câu hỏi: ngoài ngôn ngữ, những gì cần thay đổi cho từng thị trường?
Đây là phần quyết định chất lượng của toàn bộ chương trình, và cũng là phần bị cắt giảm đầu tiên khi ngân sách eo hẹp. Một bản dịch chính xác về mặt ngôn ngữ vẫn có thể hoàn toàn không phù hợp: nó dùng thuật ngữ mà người bản địa không dùng khi tìm kiếm, đưa ví dụ không liên quan tới bối cảnh của họ, hiển thị giá bằng đơn vị họ không dùng, và bỏ qua những thông tin mà người mua ở thị trường đó cần biết.
Tài liệu của Google nêu rằng nội dung hiển thị trên trang giúp xác định ngôn ngữ của trang, và khuyến nghị tránh trộn lẫn nhiều ngôn ngữ trên cùng một trang theo cách gây khó khăn cho việc xác định.
Ma trận kiểm tra bản địa hóa
| Hạng mục | Cần làm gì | Ai chịu trách nhiệm | Rủi ro khi bỏ qua |
|---|---|---|---|
| Nghiên cứu nhu cầu tìm kiếm | Tìm cách người bản địa thực sự gõ, không dịch từ khóa gốc | Người bản địa cùng đội SEO | Nội dung dùng thuật ngữ không ai tìm |
| Thuật ngữ chuyên ngành | Xác nhận cách gọi đúng trong ngành tại thị trường đó | Chuyên gia bản địa | Mất độ tin cậy với người đọc chuyên môn |
| Cấu trúc chào bán | Gói dịch vụ, cách đóng gói sản phẩm theo thị trường | Đội kinh doanh khu vực | Chào bán thứ không có ở thị trường đó |
| Giá và đơn vị tiền tệ | Hiển thị bằng đơn vị người mua dùng | Đội tài chính | Người mua không đánh giá được |
| Ví dụ và tình huống | Dùng bối cảnh của thị trường đó | Người bản địa | Nội dung xa lạ, giảm thuyết phục |
| Đơn vị đo và định dạng | Ngày tháng, số, đơn vị đo lường | Người bản địa | Gây nhầm lẫn |
| Thông tin pháp lý | Điều khoản, chính sách theo quy định địa phương | Pháp chế | Rủi ro tuân thủ |
| Thành phần tạo niềm tin | Chứng nhận, đối tác, thông tin liên hệ tại thị trường | Đội kinh doanh khu vực | Thiếu cơ sở để người mua tin tưởng |
| Kiểm tra sau khi dịch | Người bản địa đọc lại toàn bộ | Người bản địa | Lỗi diễn đạt làm mất uy tín thương hiệu |
Về dịch máy: công cụ dịch có thể dùng làm bản nháp, nhưng cần một vòng biên tập bởi người thành thạo ngôn ngữ đích và hiểu lĩnh vực. Việc xuất bản nội dung dịch máy chưa qua biên tập trên diện rộng tạo ra hai rủi ro — chất lượng nội dung không đủ để phục vụ người đọc, và tổn hại uy tín thương hiệu khi có lỗi diễn đạt.
Điều RED không làm: không đưa ra các tuyên bố về thị trường mà chưa xác minh với người bản địa hoặc với đội kinh doanh khu vực. Việc viết một trang cho thị trường Nhật Bản dựa trên hiểu biết chung về Nhật Bản, không có ai ở Nhật đọc lại, là cách nhanh nhất để tạo ra nội dung nghe sai với người đọc.
Hreflang phải đối xứng và đúng mã locale
Câu hỏi: các phiên bản liên kết với nhau thế nào?
Tài liệu của Google khuyến nghị sử dụng URL riêng cho từng phiên bản ngôn ngữ và dùng chú thích hreflang để cho biết các phiên bản thay thế của cùng một trang. Đây là công cụ giúp Google hiểu mối quan hệ giữa các phiên bản, không phải công cụ để chỉ định phiên bản nào nên được ưu tiên hiển thị.
Lỗi phổ biến nhất trong triển khai không phải lỗi cú pháp mà là thiếu tính đối xứng: trang A khai báo trang B là phiên bản thay thế, nhưng trang B không khai báo ngược lại. Khi thiếu tính đối xứng, khai báo đó không được xử lý như dự định.
Ma trận đối xứng hreflang
| Hạng mục kiểm tra | Yêu cầu | Cách xác minh | Lỗi hay gặp |
|---|---|---|---|
| Tính đối xứng | Mọi phiên bản khai báo lẫn nhau, hai chiều | Crawl toàn bộ và đối chiếu | Một phiên bản mới thêm nhưng các phiên bản cũ chưa cập nhật |
| Tự khai báo | Mỗi trang khai báo cả chính nó | Kiểm tra danh sách khai báo | Bỏ sót khai báo tự trỏ |
| Mã ngôn ngữ | Dùng mã ngôn ngữ hợp lệ | Đối chiếu với chuẩn mã | Dùng mã tự đặt |
| Mã khu vực | Chỉ dùng khi thực sự phân tách theo khu vực; dùng mã hợp lệ | Kiểm tra từng khai báo | Dùng mã khu vực cho một ngôn ngữ không phân vùng |
| Giá trị mặc định | Có một phiên bản mặc định cho người dùng không khớp phiên bản nào | Kiểm tra sự tồn tại | Không có, hoặc có nhiều hơn một |
| URL trong khai báo | Là URL tuyệt đối, trả mã 200, cho phép lập chỉ mục | Chạy toàn bộ danh sách URL trong khai báo | Trỏ tới URL đã chuyển hướng hoặc đã bị chặn |
| Nhất quán với canonical | Mỗi phiên bản có canonical tự trỏ | Đối chiếu hai giá trị | Canonical trỏ phiên bản khác làm gãy cả cụm |
| Cách triển khai | Chọn một cách và giữ nhất quán | Kiểm tra không có xung đột giữa các cách | Vừa khai trong mã trang vừa khai trong sitemap với nội dung khác nhau |
Dòng cuối cùng đáng lưu ý với các dự án lớn. Khi số phiên bản nhiều, việc khai báo trong mã trang khiến mỗi trang phải chứa danh sách dài; nhiều tổ chức chuyển sang khai báo trong sitemap. Cả hai cách đều hợp lệ, nhưng việc dùng đồng thời hai cách với nội dung không khớp nhau tạo ra xung đột.
Nguyên tắc kiểm tra: hreflang cần một quy trình xác minh tự động chạy định kỳ, không phải kiểm tra một lần khi triển khai. Mỗi lần thêm một phiên bản mới, toàn bộ các phiên bản cũ phải được cập nhật — và đây là việc rất dễ bị bỏ sót khi các thị trường do các đội khác nhau quản lý.
Canonical và hreflang không được mâu thuẫn nhau
Câu hỏi: các trang cùng ngôn ngữ phục vụ các khu vực khác nhau xử lý vấn đề trùng lặp thế nào?
Đây là tình huống khó nhất trong SEO quốc tế: hai trang cùng ngôn ngữ, nội dung gần như giống hệt, chỉ khác về giá, đơn vị tiền tệ và một vài chi tiết pháp lý. Về mặt kỹ thuật chúng gần trùng lặp; về mặt mục đích chúng phục vụ hai nhóm người dùng khác nhau.
Tài liệu của Google mô tả canonicalization là quá trình chọn một URL đại diện khi có nhiều URL cùng nội dung giống hoặc gần giống, và thẻ canonical do website khai báo là một tín hiệu được cân nhắc.
Ranh giới canonical trong bối cảnh quốc tế
| Tình huống | Xử lý đúng | Xử lý sai và hậu quả |
|---|---|---|
| Các phiên bản ngôn ngữ khác nhau | Mỗi phiên bản canonical tự trỏ; liên kết bằng hreflang | Canonical mọi phiên bản về bản gốc làm các phiên bản khác không được xem là trang riêng |
| Cùng ngôn ngữ, khác khu vực, nội dung khác biệt thật | Mỗi phiên bản canonical tự trỏ; hreflang khai mã ngôn ngữ kèm khu vực | Canonical chéo giữa hai khu vực làm mất một thị trường |
| Cùng ngôn ngữ, khác khu vực, nội dung giống hệt | Cân nhắc gộp thành một phiên bản thay vì tạo hai trang trùng | Tạo nhiều phiên bản rỗng chỉ để phủ nhiều nước |
| Phiên bản toàn cầu và phiên bản khu vực cùng tồn tại | Xác định rõ trang nào phục vụ ai; mỗi trang canonical tự trỏ | Canonical mọi phiên bản khu vực về trang toàn cầu |
| Nhiều tên miền cho các thị trường | Canonical trong phạm vi từng tên miền; hreflang liên kết chéo | Canonical chéo giữa các tên miền |
Nguyên tắc cốt lõi: hreflang không thay thế canonical và không dùng để giải quyết trùng lặp. Hai cơ chế trả lời hai câu hỏi khác nhau — canonical trả lời "trong nhóm URL trùng nội dung này, đâu là bản đại diện", hreflang trả lời "trang này có những phiên bản thay thế nào cho các ngôn ngữ và khu vực khác".
Câu hỏi kiểm tra trước khi tạo một phiên bản khu vực mới: phiên bản này có gì khác biệt thật so với phiên bản đã có, ngoài mã quốc gia trong URL? Nếu câu trả lời là không có gì, thì việc tạo nó chỉ tạo thêm trùng lặp và thêm chi phí bảo trì.
Tín hiệu bản địa phải đến từ hiện diện thật
Câu hỏi: địa chỉ, đơn vị tiền tệ, đánh giá và liên kết từ thị trường đó có vai trò gì?
Người mua ở một thị trường cần cơ sở để tin rằng doanh nghiệp thực sự phục vụ được họ. Cơ sở đó đến từ những chi tiết cụ thể: có cách liên hệ bằng ngôn ngữ của họ, có thông tin về cách giao hàng tới nơi họ ở, có điều khoản phù hợp với quy định địa phương, có đối tác hoặc khách hàng ở khu vực đó.
Kế hoạch xây bằng chứng bản địa
| Loại bằng chứng | Cách xây | Điều kiện |
|---|---|---|
| Thông tin liên hệ tại thị trường | Số điện thoại, kênh hỗ trợ bằng ngôn ngữ địa phương | Phải có người thực sự trả lời |
| Đơn vị tiền tệ và điều kiện thanh toán | Hiển thị giá bằng đơn vị người mua dùng | Phải thực sự nhận thanh toán được |
| Thông tin về giao hàng hoặc cung cấp dịch vụ | Cách thức, thời gian, chi phí tới thị trường đó | Phải phản ánh đúng khả năng thật |
| Điều khoản và chính sách | Phù hợp quy định địa phương | Cần pháp chế xác nhận |
| Khách hàng hoặc đối tác tại thị trường | Nêu tên khi được phép | Phải có thật và được đồng ý |
| Nguồn dẫn từ các ấn phẩm bản địa | Xây quan hệ với truyền thông tại thị trường | Cần nội dung đáng đưa tin cho thị trường đó |
| Hồ sơ doanh nghiệp trên nền tảng bản đồ | Chỉ khi có địa điểm hoặc khu vực phục vụ đủ điều kiện | Phải thể hiện đúng thực tế hoạt động |
Điều RED tuyệt đối không làm: không tạo địa chỉ không có thật để tỏ ra có hiện diện tại một thị trường, không tạo hoặc mua đánh giá, và không nêu tên khách hàng hoặc đối tác không có thật. Ngoài vấn đề đạo đức và pháp lý, những việc này đổ vỡ ngay khi có người kiểm chứng — và với thị trường nước ngoài thì việc kiểm chứng thường xảy ra ở đúng thời điểm doanh nghiệp cần uy tín nhất.
Khi doanh nghiệp chưa có hiện diện thật ở một thị trường, cách xử lý đúng là nói rõ mô hình phục vụ — phục vụ từ xa, qua đối tác, hoặc chỉ nhận một số loại yêu cầu — chứ không phải tạo vẻ ngoài của một hiện diện địa phương.
Triển khai theo từng thị trường với cổng kiểm soát
Câu hỏi: thị trường nào mở trước, và điều kiện gì để mở tiếp?
Cách làm sai phổ biến: chuẩn bị đồng thời cho mười thị trường, ra mắt cùng lúc, rồi phát hiện cùng một lỗi lặp lại trên cả mười phiên bản — và phải sửa cả mười.
Cách làm đúng là chọn một hoặc hai thị trường thí điểm, hoàn thiện quy trình trên đó, rút kinh nghiệm, rồi mới mở rộng. Chi phí của việc đi chậm ở giai đoạn đầu nhỏ hơn nhiều so với chi phí sửa lỗi trên diện rộng.
Cổng kiểm soát mở thị trường
| Nhóm điều kiện | Yêu cầu trước khi mở | Ai xác nhận |
|---|---|---|
| Sẵn sàng kỹ thuật | Cấu trúc URL đã triển khai, hreflang đối xứng, canonical đúng, sitemap riêng | Kỹ thuật SEO |
| Nội dung đã bản địa hóa | Đủ bộ trang tối thiểu, đã qua biên tập bởi người bản địa | Trưởng nhóm nội dung khu vực |
| Sẵn sàng về sản phẩm và pháp lý | Sản phẩm bán được, điều khoản phù hợp quy định | Đội kinh doanh và pháp chế |
| Sẵn sàng vận hành | Có người tiếp nhận và xử lý yêu cầu bằng ngôn ngữ đó | Trưởng bộ phận vận hành khu vực |
| Sẵn sàng đo lường | Đã cấu hình theo dõi riêng cho thị trường, đã có đường cơ sở | Đội dữ liệu |
| Điều kiện mở rộng | Thị trường thí điểm đã ổn định, quy trình đã được ghi lại | Chủ sở hữu chương trình |
Nguyên tắc: không mở một thị trường khi bất kỳ nhóm điều kiện nào chưa đạt. Đặc biệt là điều kiện về vận hành — mở một thị trường mà không có ai trả lời được yêu cầu bằng ngôn ngữ đó tạo ra trải nghiệm xấu và làm tổn hại thương hiệu ở chính thị trường đang muốn thâm nhập.
Về việc chọn thị trường thí điểm: nên chọn thị trường có nhu cầu đã được xác nhận và có nguồn lực bản địa sẵn sàng, không nhất thiết là thị trường lớn nhất. Mục tiêu của giai đoạn thí điểm là hoàn thiện quy trình, và điều đó dễ đạt hơn ở một thị trường mà đội ngũ có sẵn hiểu biết.
Đo lường tách theo từng quốc gia
Câu hỏi: lưu lượng tổng có che giấu một thị trường đang thất bại không?
Có, và đây là vấn đề gần như chắc chắn xảy ra với chương trình đa thị trường. Khi một thị trường tăng mạnh và một thị trường khác sụt giảm, đường tổng cho thấy tăng trưởng nhẹ — và cả hai thông tin quan trọng đều bị mất.
Search Console cho phép xem dữ liệu theo chiều quốc gia bên cạnh chiều truy vấn và chiều trang, và đây là cơ sở để tách nhóm.
Bảng theo dõi theo quốc gia
| Chiều đo | Cách chia | Lưu ý khi đọc |
|---|---|---|
| Số nhấp và số lần hiển thị | Theo quốc gia, kết hợp với nhóm URL theo phiên bản | Dữ liệu theo quốc gia dựa trên vị trí người tìm, không phải phiên bản họ xem |
| Trạng thái lập chỉ mục | Theo từng phiên bản, dùng sitemap riêng cho mỗi thị trường | Sitemap tách theo thị trường giúp chẩn đoán theo nhóm |
| Nhóm truy vấn thương hiệu và phi thương hiệu | Tách riêng cho từng thị trường | Ở thị trường mới, nhóm thương hiệu thường rất nhỏ |
| Trang đích chính | Theo phiên bản | Kiểm tra người dùng có tới đúng phiên bản không |
| Chuyển đổi | Theo thị trường | Cần thống nhất định nghĩa chuyển đổi giữa các thị trường |
| Giá trị kinh doanh | Theo thị trường, có quy đổi tiền tệ | Biến động tỷ giá làm sai lệch so sánh theo thời gian |
| Tình trạng hreflang | Kiểm tra định kỳ tính đối xứng | Lỗi thường xuất hiện sau khi thêm thị trường mới |
Hai lưu ý về diễn giải.
Không quy tăng trưởng toàn cầu cho một thị trường. Khi tổng số nhấp tăng, cần kiểm tra phần tăng đến từ đâu trước khi kết luận về hiệu quả của một thị trường cụ thể.
Cẩn thận với quy đổi tiền tệ khi so sánh giá trị kinh doanh qua thời gian. Một thị trường có thể tăng trưởng về số lượng đơn hàng nhưng giảm khi quy đổi về đơn vị tiền tệ báo cáo do biến động tỷ giá — và đó không phải vấn đề của kênh tìm kiếm.
RED không cam kết thứ hạng ở bất kỳ quốc gia nào và không đưa ra dự báo lưu lượng cho một thị trường chưa có dữ liệu lịch sử.
Ranh giới với các phạm vi khác
SEO quốc tế xử lý bài toán kiến trúc, bản địa hóa và quản trị đa thị trường ở mức không phụ thuộc nền tảng. Khi doanh nghiệp vận hành trên một nền tảng thương mại điện tử cụ thể, cách triển khai các phiên bản thị trường có những ràng buộc và tính năng riêng của nền tảng đó — phần này được xử lý trong SEO Shopify. Với mô hình phần mềm dịch vụ mở rộng ra nhiều thị trường, các đặc thù về cấu trúc sản phẩm và nội dung thuộc SEO SaaS.
Câu hỏi thường gặp
SEO quốc tế khác việc dịch website thế nào?
Dịch website chỉ giải quyết chiều ngôn ngữ. SEO quốc tế xử lý cả chiều quốc gia: sản phẩm và giá khác nhau, điều kiện pháp lý khác nhau, cách người bản địa gọi tên và tìm kiếm khác nhau, cấu trúc kết quả tìm kiếm khác nhau. Ngoài ra còn có phần kiến trúc URL, khai báo hreflang, ranh giới canonical và bằng chứng bản địa — những thứ không xuất hiện trong một dự án dịch thuật.
Nên dùng tên miền quốc gia, tên miền phụ hay thư mục con?
Tài liệu của Google mô tả các phương án cùng ưu nhược điểm của từng loại nhưng không chỉ định một phương án tốt nhất cho mọi trường hợp. Lựa chọn phụ thuộc vào ba yếu tố: đội nào quản lý các phiên bản, hạ tầng có cần tách không, và thương hiệu có khác nhau giữa các thị trường không. Việc dùng tham số URL để phân biệt phiên bản không được khuyến nghị.
Hreflang có thay thế canonical không?
Không. Hai cơ chế trả lời hai câu hỏi khác nhau. Canonical xác định URL đại diện trong nhóm URL có nội dung giống hoặc gần giống. Hreflang cho biết một trang có những phiên bản thay thế nào cho các ngôn ngữ và khu vực khác. Mỗi phiên bản nên có canonical tự trỏ; việc canonical các phiên bản về một bản gốc làm các phiên bản còn lại không được xem là trang riêng.
Có nên tự động chuyển hướng người dùng theo địa chỉ IP không?
Tài liệu của Google lưu ý rằng việc thay đổi nội dung dựa trên vị trí suy ra từ IP có hạn chế, vì crawler có thể không thấy được mọi biến thể. Cách phù hợp là mỗi phiên bản có URL riêng truy cập trực tiếp được, và nếu muốn hỗ trợ người dùng thì dùng gợi ý chuyển phiên bản thay vì chuyển hướng bắt buộc.
Có cần nghiên cứu từ khóa riêng cho từng quốc gia không?
Có. Dịch danh sách từ khóa từ ngôn ngữ gốc là một trong những sai lầm tốn kém nhất trong SEO quốc tế. Cùng một sản phẩm có thể được gọi bằng các thuật ngữ khác nhau ở hai nước cùng nói một ngôn ngữ, và cấu trúc kết quả tìm kiếm cũng khác nhau giữa các thị trường. Nghiên cứu cần được thực hiện hoặc kiểm chứng bởi người bản địa.
Đo kết quả theo từng quốc gia thế nào?
Tách nhóm theo chiều quốc gia trong Search Console, kết hợp với việc nhóm URL theo phiên bản và dùng sitemap riêng cho mỗi thị trường để chẩn đoán trạng thái lập chỉ mục. Cần theo dõi riêng nhóm truy vấn thương hiệu và phi thương hiệu cho từng thị trường, và cẩn thận khi so sánh giá trị kinh doanh qua thời gian vì biến động tỷ giá có thể làm sai lệch kết luận.
Gửi kế hoạch mở rộng để RED đánh giá phạm vi
Nếu doanh nghiệp đang chuẩn bị mở rộng ra thị trường nước ngoài hoặc đang vận hành nhiều phiên bản mà kết quả không như mong đợi, hãy gửi cho RED:
- Danh sách thị trường và ngôn ngữ mục tiêu, kèm mức độ ưu tiên
- Khả năng phục vụ thực tế ở từng thị trường: sản phẩm, giao hàng, thanh toán, hỗ trợ
- Cấu trúc website hiện tại và nền tảng đang dùng
- Nguồn lực bản địa sẵn có: người thành thạo ngôn ngữ, đối tác, đội kinh doanh khu vực
- Quyền truy cập Search Console và công cụ phân tích, nếu chia sẻ được
RED sẽ đánh giá ma trận thị trường và ngôn ngữ, khuyến nghị kiến trúc URL kèm phân tích đánh đổi, và phản hồi bằng bản mô tả phạm vi triển khai theo giai đoạn. RED không cam kết thứ hạng ở bất kỳ quốc gia hay ngôn ngữ nào và không tạo các tín hiệu bản địa không phản ánh hoạt động thật của doanh nghiệp.