Đang nhận dự án và hợp tác sản phẩm mới

Website đa ngôn ngữ của bạn có lẽ chỉ được index ở một thứ tiếng

Đổi ngôn ngữ bằng JavaScript trên cùng một URL là cách phổ biến nhất khiến sáu bản dịch trở nên vô hình với công cụ tìm kiếm. Đây là thứ thật sự được index, và cách tổ chức một site tĩnh để chuyện đó không xảy ra.

Một mô-típ chúng tôi gặp thường xuyên: một công ty dịch website sang sáu thứ tiếng, gắn nút đổi ngôn ngữ, rồi không thấy lưu lượng nào từ các thị trường mới. Bản dịch tốt. Không ai tìm ra chúng.

Nguyên nhân gần như luôn giống nhau, và nó thuộc về kiến trúc chứ không phải nội dung.

Công cụ tìm kiếm index URL, không index trạng thái ứng dụng

Nếu nút đổi ngôn ngữ của bạn thay chữ trên trang và ghi nhớ lựa chọn trong localStorage hay cookie, thì mọi ngôn ngữ dùng chung một URL.

Bot gửi yêu cầu tới URL đó, nhận về đúng ngôn ngữ đã nướng sẵn trong HTML, và index nó. Sáu bản dịch còn lại không tồn tại dưới góc nhìn tìm kiếm. Không có URL thứ hai để xếp hạng, không có title riêng, không có description riêng.

Đây không phải hạn chế của bot để bạn lách. Một URL là đơn vị index. Một URL nghĩa là một tài liệu được index.

Phép thử rất đơn giản: bạn có gửi được cho ai đó một đường link mở trang của bạn bằng tiếng Nhật không? Nếu không, Google cũng không index được bản tiếng Nhật.

Khi nào đổi ngôn ngữ phía client là ổn

Cũng cần công bằng với mô hình này, vì nó không phải lúc nào cũng sai. Đổi phía client hoàn toàn hợp lý khi trang không phải thứ người ta tìm ra qua nội dung:

  • Giao diện ứng dụng phía sau đăng nhập
  • Dashboard và công cụ nội bộ
  • Một site giới thiệu nhỏ có lưu lượng đến từ quảng cáo, giới thiệu hay truyền miệng

Nó thành vấn đề ngay khi bạn muốn lưu lượng tìm kiếm tự nhiên ở các ngôn ngữ đó. Content marketing, tài liệu và blog chính là trường hợp ấy.

Cho mỗi ngôn ngữ một URL thật

Ba cấu trúc phổ biến, công cụ tìm kiếm đều chấp nhận:

Cấu trúcVí dụGhi chú
Thư mục conexample.com/ja/pageĐơn giản nhất. Thừa hưởng uy tín của tên miền. Thường là mặc định đúng.
Tên miền phụja.example.com/pageDùng được, nhưng thêm việc quản lý DNS và chứng chỉ.
Tên miền riêngexample.jp/pageTín hiệu địa phương mạnh nhất, đắt nhất. Mỗi miền tự xây uy tín riêng.

Với phần lớn đội ngũ: thư mục con. Bạn có một tên miền tích luỹ uy tín và không phải làm gì về hạ tầng.

Rồi báo cho công cụ tìm kiếm biết các trang này liên quan nhau

Chỉ tách URL thôi lại sinh rủi ro mới: bảy trang nói cùng một điều có thể trông như nội dung trùng lặp. hreflang là cách bạn nói "đây là cùng một trang ở các ngôn ngữ khác nhau, hãy hiện đúng bản".

Trên mọi bản của một trang, hãy liệt kê mọi bản, gồm cả chính nó:

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

Kèm một thẻ canonical tự trỏ trên từng bản:

<link rel="canonical" href="https://example.com/ja/page">

Năm lỗi làm hỏng chuyện này

  1. Thiếu liên kết ngược. hreflang phải đối xứng. Nếu trang tiếng Anh trỏ sang tiếng Nhật mà tiếng Nhật không trỏ ngược lại, cặp đó bị bỏ qua. Đây là lỗi phổ biến nhất, bỏ xa các lỗi còn lại.
  2. Canonical trỏ sang ngôn ngữ khác. Một trang tiếng Nhật có canonical trỏ về URL tiếng Anh là đang ra lệnh cho công cụ tìm kiếm loại bỏ nó. Canonical phải trỏ về chính nó.
  3. Nhầm ngôn ngữ với vùng. hreflang="ja" là ngôn ngữ Nhật. hreflang="ja-JP" là tiếng Nhật riêng cho nước Nhật. Hãy dùng mã ngôn ngữ trần trừ khi bạn thật sự có bản riêng theo vùng; thu hẹp không cần thiết sẽ mất độc giả ở nơi khác.
  4. Sai mã. Phần vùng là mã quốc gia, không phải mã ngôn ngữ. Tiếng Anh Anh là en-GB, không phải en-UK. Với tiếng Trung, hệ chữ quan trọng hơn quốc gia: zh-Hanszh-Hant.
  5. URL tương đối. hreflang và canonical cần URL tuyệt đối, có cả giao thức và tên miền.

Dịch cả slug

Một điểm dễ ăn mà hay bị bỏ qua: các từ trong URL là tín hiệu liên quan ở chính ngôn ngữ đó. Nếu trang tiếng Việt của bạn nằm ở /vi/how-to-look-up-a-character, URL không đóng góp gì bằng tiếng Việt cả.

Hãy dịch slug và giữ một định danh nội bộ ổn định để ghép các bản với nhau. Đó đúng là cách chúng tôi tổ chức blog này: mỗi bài có một id không bao giờ đổi và một slug theo ngôn ngữ thì có đổi.

Đừng tự chuyển hướng theo IP

Rất cám dỗ, và gây thiệt hại thật. Nếu bạn phát hiện quốc gia của khách rồi ép chuyển hướng:

  • Bot phần lớn truy cập từ một quốc gia và có thể chỉ nhìn thấy đúng một bản.
  • Bạn ghi đè lên lựa chọn có chủ ý của người dùng. Rất nhiều người ở Nhật muốn đọc bản tiếng Anh.

Hãy gợi ý, đừng ép. Đưa ra một thanh thông báo, giữ nút đổi ngôn ngữ ở chỗ dễ thấy, và để URL quyết định nội dung.

Site tĩnh làm việc này rất dễ

Không có gì trong số trên cần CMS hay máy chủ. Hãy sinh ra một file HTML cho mỗi ngôn ngữ của mỗi trang lúc build, với các thẻ đúng đã nướng sẵn, rồi tải cả thư mục lên. Kết quả là các file tĩnh thuần; phần thông minh nằm ở bộ sinh mà bạn chạy trước khi deploy.

Đó là cách chúng tôi làm với blog này: nội dung nằm trong một file cho mỗi bài mỗi ngôn ngữ, một script nhỏ sinh ra HTML kèm hreflang, canonical, JSON-LD và các mục sitemap theo ngôn ngữ, còn bản thân site vẫn là một thư mục file tĩnh, hoàn toàn không có backend.

Danh sách kiểm tra

  • Mỗi ngôn ngữ có URL riêng mà bạn gửi được cho người khác
  • Mỗi trang liệt kê mọi ngôn ngữ trong hreflang, gồm cả chính nó, và đối xứng hai chiều
  • x-default cho khách mà bạn không khớp được ngôn ngữ
  • Canonical trên mỗi trang trỏ về chính nó
  • Slug được dịch, có id ổn định ghép chúng lại phía trong
  • Sitemap liệt kê mọi URL ngôn ngữ kèm các bản thay thế
  • html lang khớp với nội dung thật
  • Không ép chuyển hướng theo IP
SEO Kỹ thuật Đa ngôn ngữ