Thẻ rel=”canonical” báo cho công cụ tìm kiếm biết “URL nào là phiên bản chuẩn (canonical) của nội dung này”, từ đó ngăn chặn sự phân tán quyền lực.
Trong SEO của Google, nó được sử dụng bằng cách thêm <link rel=”canonical” href=”URL chuẩn”> vào phần <head> của trang.
Dữ liệu cho thấy các trang web thương mại điện tử triển khai thẻ Canonical đúng cách ghi nhận mức tăng trung bình 28% về tỷ lệ lập chỉ mục cho các trang danh sách sản phẩm của họ và giảm 40%-60% số lượng URL trùng lặp được robot thu thập;
Các trang web tin tức hợp nhất các bài báo tương tự bằng cách sử dụng thẻ canonical trải qua mức tăng trưởng trung bình 19% về số lần nhấp từ tìm kiếm tự nhiên cho nội dung chính của họ.
Tuy nhiên, một khảo sát thực tế cho thấy chỉ 31% các trang web sử dụng thẻ này đúng 100% (các lỗi thường gặp bao gồm: trỏ đến URL sai, không tuân thủ giao thức/tên miền, xếp chồng nhiều thẻ, v.v.).
Tại sao cần sử dụng thẻ canonical
Trong quá trình thu thập thông tin hàng ngày của Google, hơn 65% các trang web gặp phải vấn đề nội dung trùng lặp do thiết kế cấu trúc URL không phù hợp.
Điều này được thể hiện dưới dạng:
- Cùng một bài viết có thể truy cập qua URL có tham số (ví dụ: ?utm_source=xxx)
- URL có hậu tố thư mục (ví dụ: /page/ và /page/index.html)
- Các tên miền phụ khác nhau (ví dụ: www và non-www)
John Mueller của Google đã nhiều lần đề cập trong các phiên hỏi đáp chính thức rằng, khi công cụ tìm kiếm gặp phải “nhiều URL hiển thị nội dung rất giống hoặc hoàn toàn giống nhau”, nó sẽ phải đối mặt với tình thế khó xử là “nên trao quyền lực cho URL nào”.
Một trang sản phẩm thương mại điện tử có thể tạo ra hơn chục URL khác nhau do bộ lọc màu sắc hoặc tham số sắp xếp; một thông cáo báo chí có thể được gửi đến nhiều chuyên mục, tạo ra nhiều liên kết đầu vào.
Bằng cách sử dụng thẻ canonical, bạn đang nói rõ ràng với công cụ tìm kiếm: “Mặc dù nội dung này có thể được xem qua nhiều URL, nhưng vui lòng tập trung quyền lực và trọng tâm xếp hạng vào URL cụ thể mà tôi đã chỉ định này“.
Nội dung trùng lặp ảnh hưởng đến SEO như thế nào
Bản thân nội dung trùng lặp không dẫn đến hình phạt trực tiếp từ công cụ tìm kiếm (Google đã tuyên bố rõ ràng rằng “sẽ không phạt các trang web chỉ vì nội dung trùng lặp”), nhưng nó gây ra sự phân tán quyền lực.
Khi cùng một nội dung có thể truy cập qua nhiều URL, công cụ tìm kiếm sẽ coi những URL này là “các trang khác nhau” và xử lý chúng riêng biệt.
Ví dụ, một bài viết gốc được hiển thị qua 4 URL sau:
https://example.com/articlehttps://example.com/article?source=newsletterhttps://example.com/article#commentshttps://www.example.com/article(phiên bản có www)
Nếu không có nhận dạng chuẩn, công cụ tìm kiếm có thể thu thập tất cả 4 URL này cùng một lúc và tính toán quyền lực lập chỉ mục cho từng URL riêng biệt.
Tuy nhiên, nhu cầu tìm kiếm của người dùng về bản chất chỉ là một câu trả lời duy nhất, và cuối cùng, xếp hạng của 4 phiên bản này có thể thấp (vì quyền lực bị phân tán), hoặc chỉ một trong số đó bị chọn nhầm vào chỉ mục, và các phiên bản khác vẫn ở trạng thái “chưa được lập chỉ mục” hoặc “xếp hạng thấp” trong một thời gian dài.
Trong một trang web thương mại điện tử, một trang chi tiết sản phẩm có thể tạo ra trung bình 8-12 URL trùng lặp do tham số (ví dụ: ?size=XL, ?color=red), và tỷ lệ thu thập của robot đối với các trang này có thể đạt 15%-20% tổng số lần thu thập (mà lẽ ra phải được phân bổ cho các trang mới có giá trị hơn).
Các trang web tin tức, do nội dung được đăng lên nhiều chuyên mục (ví dụ: “Tin tức mới nhất”, “Xu hướng ngành”, “Đề xuất phổ biến”), một bản nháp duy nhất có thể tạo ra 3-5 URL đầu vào khác nhau.
Một trường hợp cụ thể hơn: trước khi chuẩn hóa URL, tỷ lệ lập chỉ mục của các trang danh sách sản phẩm của một trang web thương mại điện tử cỡ trung bình chỉ là 62% (tức là Google chỉ lập chỉ mục 62 trên 100 trang và có thể tham gia xếp hạng);
Sau khi thêm thẻ Canonical vào các trang danh sách có tham số (ví dụ: ?category=shoes&sort=price), trỏ chúng đến URL cơ bản không có tham số (ví dụ: /shoes), tỷ lệ lập chỉ mục đã tăng lên 81% sau 3 tháng, và lưu lượng tìm kiếm tự nhiên cho các sản phẩm liên quan đã tăng 17%.
Nó không phải là “xóa trùng lặp”, mà là “chỉ định phiên bản có thẩm quyền”
Nhiều quản trị web hiểu sai về thẻ canonical, tin rằng nó được sử dụng “để xóa các trang trùng lặp”.
Trên thực tế, chức năng cốt lõi của nó là “nói với công cụ tìm kiếm: trong số nhiều URL hiển thị cùng một nội dung, URL nào là phiên bản mà bạn nên ưu tiên lập chỉ mục, xếp hạng và trao quyền lực”
Khi bạn thêm đoạn mã sau vào phần <head> của một trang:
<link rel=“canonical” href=“https://example.com/URL_chuẩn” />
Bạn đang gửi một tín hiệu rõ ràng đến công cụ tìm kiếm: “Mặc dù nội dung này có thể được truy cập qua trang này (ví dụ: /article?source=email có tham số), tôi muốn bạn tập trung quyền lực và cơ hội xếp hạng của nó vào địa chỉ https://example.com/URL_chuẩn”.
Theo tài liệu chính thức của Google và quan sát dữ liệu thu thập thực tế:
- Cấp độ thu thập: Công cụ tìm kiếm sẽ tiếp tục thu thập tất cả các phiên bản của trang (bao gồm URL có tham số và thư mục), nhưng nó sẽ tham khảo thẻ canonical để điều chỉnh “mức độ quan trọng” của nó đối với các trang đó. Ví dụ, URL có tham số có thể được thu thập, nhưng robot sẽ không truy cập nó thường xuyên hoặc lập chỉ mục sâu như phiên bản chuẩn.
- Cấp độ lập chỉ mục: Nếu nội dung của nhiều URL rất giống nhau (tỷ lệ trùng lặp vượt quá 80%), công cụ tìm kiếm thường sẽ bao gồm phiên bản chuẩn trong chỉ mục, và các phiên bản khác có thể không được lập chỉ mục riêng biệt, hoặc, ngay cả khi được lập chỉ mục, chúng sẽ không tham gia vào cuộc cạnh tranh xếp hạng chính.
- Cấp độ quyền lực: Khi một liên kết bên ngoài trỏ đến bất kỳ phiên bản trùng lặp nào của URL, công cụ tìm kiếm, theo hướng dẫn của thẻ canonical, sẽ “chuyển” hoặc “liên kết” phần quyền lực liên kết bên ngoài đó với phiên bản chuẩn (mặc dù nó không phải là chuyển giao 100% hoàn toàn, nhưng trong hầu hết các trường hợp, hiệu quả là tương tự).
Lấy một kịch bản thực tế: một bài viết blog được xuất bản đồng thời trên hai chuyên mục: “Đề xuất trang chủ” và “Chuyên mục công nghệ“, tạo ra hai URL:
https://example.com/home/recommend/123(Đầu vào đề xuất trang chủ)https://example.com/tech/article/123(Đầu vào chuyên mục công nghệ)
Nội dung hoàn toàn giống nhau, nhưng URL đề xuất trang chủ đã thu hút một số liên kết bên ngoài do có lưu lượng truy cập cao hơn.
Nếu không có thẻ canonical, công cụ tìm kiếm có thể coi hai trang này là nội dung độc lập, và mặc dù URL đề xuất trang chủ có liên kết bên ngoài, tiềm năng xếp hạng của nó có thể thấp hơn chuyên mục công nghệ vì định vị chuyên mục không đủ chuyên sâu (đề xuất trang chủ thường là nội dung chung chung).
Nếu đội ngũ kỹ thuật thêm thẻ canonical trên cả hai trang, trỏ đến https://example.com/tech/article/123, phù hợp hơn với chủ đề nội dung, công cụ tìm kiếm sẽ biết rõ: “phiên bản có thẩm quyền của nội dung này là URL chuyên mục công nghệ”, và sẽ liên kết quyền lực của các liên kết bên ngoài từ trang chủ đến URL này, cải thiện khả năng cạnh tranh xếp hạng của trang đó dưới “các từ khóa liên quan đến công nghệ”.
Điều gì xảy ra nếu không sử dụng thẻ Canonical
Ngân sách thu thập của robot bị lãng phí
“Số lần thu thập hàng ngày” mà công cụ tìm kiếm phân bổ cho mỗi trang web là có giới hạn (gọi là “ngân sách thu thập”), ưu tiên thu thập các trang quan trọng (như trang chủ, các trang nội dung có tần suất cập nhật cao).
Nếu một trang web có nhiều URL trùng lặp (ví dụ: một trang chi tiết sản phẩm thương mại điện tử có 10 tham số sắp xếp, tạo ra hơn 1000 URL khác nhau), robot sẽ tiêu tốn một phần ngân sách vào các trang “nội dung giống nhau, nhưng URL khác nhau” này, điều này dẫn đến việc giảm tần suất thu thập các trang mới thực sự cần được thu thập (như các sản phẩm mới ra mắt, tin tức cập nhật).
Dữ liệu cho thấy, phân tích nhật ký thu thập của một trang web thương mại điện tử quần áo cho thấy các trang sản phẩm trùng lặp có tham số (ví dụ: ?size=M, ?color=blue) chiếm 22% tổng số lần thu thập, và tỷ lệ thoát của các trang này cao tới 85% (người dùng đang tìm kiếm các sản phẩm cụ thể, sẽ không vào qua các URL có tham số).
Khi trang web thống nhất thêm thẻ canonical trên các trang chi tiết sản phẩm (trỏ đến URL cơ bản không có tham số), tần suất thu thập các trang sản phẩm chính của robot đã tăng 30% và thời gian các sản phẩm mới ra mắt được lập chỉ mục đã giảm từ trung bình 7 ngày xuống còn 3 ngày.
Phiên bản lập chỉ mục lộn xộn, xếp hạng không ổn định
Nếu không có nhận dạng chuẩn, công cụ tìm kiếm có thể chọn ngẫu nhiên một URL làm “phiên bản hiển thị mặc định”, nhưng lựa chọn này không cố định.
Ví dụ, khi người dùng tìm kiếm một từ khóa, đôi khi họ thấy phiên bản có www (https://www.example.com/page), đôi khi là phiên bản không có www (https://example.com/page), và thậm chí có thể là phiên bản có tham số (https://example.com/page?from=social).
Trường hợp: trang “Liên hệ với chúng tôi” của một trang web dịch vụ địa phương tồn tại hai phiên bản https://example.com/contact và https://example.com/contact-us (nội dung hoàn toàn giống nhau), không thiết lập thẻ canonical. Google đã lập chỉ mục hai URL này vào các thời điểm khác nhau, dẫn đến việc khi người dùng tìm kiếm “Thông tin liên hệ dịch vụ sửa chữa Thành phố XX”, đôi khi họ thấy phiên bản đầu tiên xếp hạng cao hơn, và đôi khi là phiên bản thứ hai.
Khi người dùng nhấp vào, nếu họ vào một phiên bản không phải là chính (như contact-us), tỷ lệ chuyển đổi có thể giảm do sự khác biệt trong thiết kế điều hướng trang (ví dụ: thiếu nút đặt lịch trực tuyến).
Sau đó, trang web đã thêm thẻ canonical trên cả hai phiên bản, trỏ đến https://example.com/contact, và sau 3 tháng, xếp hạng của trang này đã được cải thiện, và tỷ lệ nhấp từ tìm kiếm (CTR) tăng 11%.
Phân tán quyền lực của liên kết bên ngoài
Nếu nhiều phiên bản URL trùng lặp được các trang web bên ngoài liên kết (ví dụ: ai đó đã sử dụng URL có tham số khi đăng lại nội dung, hoặc một liên kết mới được tạo ra khi quảng bá trang chuyên mục), nhưng các liên kết bên ngoài này lại trỏ đến các địa chỉ khác nhau, công cụ tìm kiếm không thể tự động hợp nhất quyền lực.
So sánh dữ liệu: một bài viết về “Hướng dẫn ôn thi sau đại học” của một trang web giáo dục đã được 5 trang web bên ngoài đăng lại, trong đó 3 trang liên kết đến phiên bản không có tham số (https://example.com/guide/kaoyan), và 2 trang liên kết đến phiên bản có tham số (https://example.com/guide/kaoyan?from=partner).
Nếu không có thẻ canonical được thiết lập, công cụ tìm kiếm sẽ liên kết 5 liên kết bên ngoài này với các URL khác nhau một cách riêng biệt. Sau khi trang web thêm thẻ canonical trên tất cả các phiên bản (trỏ đến phiên bản không có tham số), lưu lượng tìm kiếm tự nhiên của trang đã tăng 24% trong 6 tháng.
Cú pháp và định dạng cơ bản của thẻ canonical
Khoảng 32% các trang đặt thẻ canonical trong phần <body> (thay vì khu vực <head> được yêu cầu), 19% giá trị thuộc tính href thiếu tiêu đề giao thức đầy đủ (ví dụ: chỉ viết example.com thay vì https://example.com), và 15% các trang trỏ đến các “phiên bản chuẩn” khác nhau trên nhiều URL trùng lặp (điều này gây nhầm lẫn cho công cụ tìm kiếm).
Từ góc độ triển khai kỹ thuật, thẻ canonical về cơ bản là một thẻ liên kết HTML đơn giản, nhưng vị trí của thẻ (phải nằm trong <head>), định dạng cú pháp (phải tuân thủ nghiêm ngặt đặc tả HTML) và URL mà nó trỏ đến (phải hoàn toàn khớp với nội dung thực tế và có thể truy cập) là những yếu tố then chốt để công cụ tìm kiếm chấp nhận và áp dụng đúng.
Dữ liệu cho thấy khi thẻ canonical được triển khai theo cách viết chuẩn (tức là đặt ở đầu <head>, sử dụng giao thức HTTPS đầy đủ, trỏ đến một URL chuẩn duy nhất và chính xác), xác suất nó được công cụ tìm kiếm nhận dạng và áp dụng đúng vượt quá 95%;
Và trên các trang có lỗi viết, khoảng 60% ý định chuẩn không được công cụ tìm kiếm chấp nhận, dẫn đến vấn đề nội dung trùng lặp vẫn còn tồn tại.
Ví dụ, khi một trang web thương mại điện tử thêm thẻ canonical trên trang chi tiết sản phẩm (chẳng hạn như phiên bản ?color=red có tham số), do thiếu tiêu đề giao thức (viết là //example.com/product hoặc example.com/product), Google đã không thể phân tích cú pháp chính xác URL đích.
Cấu trúc cú pháp chuẩn
Cú pháp đầy đủ của thẻ canonical chỉ là một dòng mã HTML: <link rel=“canonical” href=“https://www.example.com/URL_đầy_đủ_của_trang_chuẩn” />
Dòng mã này bao gồm 3 phần chính, không thể thiếu và có thứ tự cố định:
Loại thẻ: <link>
- Đây là thẻ HTML được sử dụng để xác định mối quan hệ giữa tài liệu và tài nguyên bên ngoài, và thẻ canonical là một loại “mối quan hệ liên kết”, vì vậy nó phải sử dụng
<link>làm cấu trúc cơ bản.
Thuộc tính: rel="canonical"
rellà thuộc tính bắt buộc của thẻ<link>, được sử dụng để mô tả mối quan hệ giữa liên kết hiện tại và tài liệu hiện tại. Khi giá trị của nó được đặt thànhcanonical, nó rõ ràng nói với công cụ tìm kiếm: “thẻ này xác định phiên bản chuẩn (có thẩm quyền) của nội dung trang hiện tại”.
Thuộc tính: href="URL"
hreflà một thuộc tính bắt buộc khác của thẻ<link>, được sử dụng để chỉ định địa chỉ web cụ thể của phiên bản chuẩn. URL này phải hoàn chỉnh và có thể truy cập, bao gồm giao thức (http hoặc https), tên miền (www hoặc non-www), đường dẫn và tham số (nếu cần).
Ví dụ:
- Cách viết đúng:
href="https://www.example.com/products/shoes" - Cách viết sai 1 (thiếu giao thức):
href="//www.example.com/products/shoes"(trình duyệt có thể tự động hoàn thành, nhưng công cụ tìm kiếm có thể không phân tích cú pháp chính xác URL đích) - Cách viết sai 2 (thiếu tên miền):
href="/products/shoes"(đường dẫn tương đối, công cụ tìm kiếm không biết trang cụ thể thuộc về trang web nào) - Cách viết sai 3 (lỗi chính tả):
href="https://www.exaple.com/products/shoes"(tên miền viết sai, trỏ đến một trang không tồn tại)
Các chi tiết khác:
- Thẻ này nên kết thúc bằng
/(nếu bản thân URL yêu cầu dấu gạch chéo cuối), nhưng trong hầu hết các trường hợp, các công cụ tìm kiếm hiện đại có khả năng chịu đựng cao hơn đối với việc có hay không có dấu gạch chéo cuối (miễn là việc chuẩn hóa là nhất quán). - Thẻ nên được viết trên một dòng duy nhất (xuống dòng có thể khiến một số công cụ phân tích thất bại, mặc dù công cụ tìm kiếm thường có thể tự động khắc phục).
- Phần đóng của thẻ là
/>(thẻ tự đóng, tiêu chuẩn HTML5 cho phép bỏ qua/cuối, nhưng nên giữ lại để đảm bảo tính tương thích).
Tại sao nó phải nằm trong <head>
Bởi vì khi robot của công cụ tìm kiếm thu thập thông tin một trang, nó sẽ ưu tiên phân tích nội dung trong vùng <head> (đặc biệt là thông tin meta, tiêu đề, thẻ canonical và các “chỉ thị kiểm soát” khác), và sau đó mới xử lý nội dung thực tế trong <body>.
Nếu thẻ canonical bị đặt sai trong <body> (ví dụ: lồng trong một đoạn văn bản bài viết hoặc mã chân trang), công cụ tìm kiếm sẽ trực tiếp bỏ qua thẻ <link rel="canonical"> bên trong <body>.
Các lưu ý khác:
- Một trang chỉ được có một thẻ canonical (nếu có nhiều hơn một, công cụ tìm kiếm thường chỉ nhận dạng cái đầu tiên, và những cái sau sẽ bị bỏ qua).
- Thẻ này không được lồng trong các thẻ khác (ví dụ: không thể đặt trong
<div>hoặc<script>). - Đối với các trang được tạo động (như các trang được tạo bằng ngôn ngữ backend như PHP, Python, v.v.), cần đảm bảo rằng công cụ tạo mẫu chèn thẻ canonical đúng cách vào vùng
<head>trong quá trình tạo HTML (thường được kiểm soát thông qua các biến mẫu).
5 Lỗi phổ biến nhất
Lỗi 1: Trỏ đến URL sai (phiên bản chuẩn không khớp với nhu cầu thực tế)
- Hiện tượng: Hướng thẻ canonical đến một URL có nội dung không hoàn toàn nhất quán (hoặc không phải là cùng một nội dung). Ví dụ, trang chi tiết sản phẩm (hiển thị giày đỏ) trỏ đến trang giày trắng.
- Hậu quả: Công cụ tìm kiếm sẽ tập trung quyền lực vào trang không liên quan theo hướng dẫn sai, điều này sẽ dẫn đến việc xếp hạng của nội dung chính bị giảm.
- Khắc phục: Kiểm tra nội dung thực tế của trang hiện tại và đảm bảo rằng URL trong href trỏ đến phiên bản chuẩn “hiển thị nội dung hoàn toàn giống nhau” (ví dụ: thống nhất sử dụng URL cơ bản không có tham số, hoặc trang chuyên mục phù hợp nhất với ý định tìm kiếm của người dùng).
Lỗi 2: Thiếu tiêu đề giao thức (chỉ viết tên miền hoặc sử dụng đường dẫn tương đối)
- Hiện tượng: Mã được viết là
href="//example.com/page"(đường dẫn tương đối giao thức) hoặchref="/page"(đường dẫn tương đối). - Hậu quả: Công cụ tìm kiếm có thể không phân tích cú pháp chính xác địa chỉ đầy đủ của URL đích (đặc biệt trong các trường hợp đa giao thức hoặc đa tên miền), dẫn đến ý định chuẩn hóa không hiệu quả.
- Khắc phục: Luôn sử dụng giao thức đầy đủ + tên miền + đường dẫn, định dạng là
href="https://www.example.com/page"(nên sử dụng giao thức https để đảm bảo an toàn).
Lỗi 3: Xung đột giữa URL có tham số và phiên bản chuẩn
- Hiện tượng: Phiên bản không có tham số của một trang danh sách sản phẩm (
https://example.com/products) là phiên bản chuẩn, nhưng phiên bản có tham số (nhưhttps://example.com/products?sort=price) không trỏ đúng đến nó, mà trỏ đến một URL khác có tham số khác (như?sort=date). - Hậu quả: Nhiều phiên bản có tham số trỏ lẫn nhau đến các URL khác nhau, tạo thành “chuẩn hóa vòng tròn” hoặc phân tán quyền lực.
- Khắc phục: Thống nhất thẻ canonical của tất cả các URL có tham số để chúng trỏ đến phiên bản cơ bản không có tham số (hoặc phiên bản sắp xếp/lọc được sử dụng phổ biến nhất), đảm bảo tất cả các phiên bản biến thể trỏ đến cùng một địa chỉ chuẩn.
Lỗi 4: Thẻ được đặt trong <body>
- Hiện tượng: Khi chỉnh sửa trang thông qua backend của CMS, mã canonical bị dán nhầm vào khu vực nội dung bài viết (phần <body>), thay vì khu vực <head> của mẫu trang web.
- Hậu quả: Robot của công cụ tìm kiếm có thể bỏ qua thẻ, dẫn đến các trang trùng lặp không được chuẩn hóa đúng cách.
- Khắc phục: Liên hệ với đội ngũ kỹ thuật để kiểm tra các tệp mẫu (chẳng hạn như header.php của WordPress, theme.liquid của Shopify) và đảm bảo rằng thẻ canonical được tạo trong thẻ <head> của HTML.
Lỗi 5: Xếp chồng nhiều thẻ canonical
- Hiện tượng: Do lỗi mẫu hoặc thêm thủ công, nhiều thẻ
<link rel="canonical">xuất hiện trên một trang (ví dụ: đồng thời trỏ đến /page và /page/). - Hậu quả: Công cụ tìm kiếm thường chỉ nhận dạng thẻ đầu tiên và các thẻ tiếp theo sẽ bị bỏ qua, điều này có thể gây nhầm lẫn trong ý định chuẩn hóa.
- Khắc phục: Kiểm tra mã, loại bỏ các thẻ canonical dư thừa và đảm bảo rằng mỗi trang chỉ có một chỉ thị chuẩn hóa.
Sự khác biệt giữa canonical và các thẻ khác (như noindex, chuyển hướng 301)
Thẻ canonical dùng để “chỉ định phiên bản có thẩm quyền của cùng một nội dung” (giữ lại tất cả các URL, nhưng tập trung quyền lực), thẻ noindex dùng để “cấm công cụ tìm kiếm lập chỉ mục trang hiện tại” (cho phép thu thập, nhưng không hiển thị), và chuyển hướng 301 dùng để “chuyển hướng vĩnh viễn URL cũ đến URL mới” (chuyển giao hoàn toàn lưu lượng truy cập và quyền lực).
Sự khác biệt cơ bản giữa chuẩn, cấm và chuyển hướng
Thẻ canonical (thẻ chuẩn): Được sử dụng cho “kịch bản một nội dung có nhiều URL”, mục đích là nói với công cụ tìm kiếm “nội dung của các trang này thực sự là giống nhau, nhưng bạn chỉ nên tập trung vào URL cụ thể mà tôi đã chỉ định này (phiên bản chuẩn), và tập trung quyền lực ở đây”.
- Kịch bản điển hình: Trang chi tiết sản phẩm thương mại điện tử có tham số (ví dụ: ?color=red và ?color=blue), thông cáo báo chí được gửi đến nhiều chuyên mục (ví dụ: “Tin tức mới nhất” và “Xu hướng ngành”), URL riêng biệt cho điện thoại di động và PC nhưng nội dung giống nhau.
Thẻ noindex (thẻ cấm lập chỉ mục): Được sử dụng cho “kịch bản cho phép thu thập, nhưng cấm hiển thị”, nói với công cụ tìm kiếm “bạn có thể thu thập trang này, nhưng đừng đưa nó vào chỉ mục kết quả tìm kiếm”.
- Kịch bản điển hình: Các trang quản lý nội bộ (như trang đăng nhập, trang thống kê backend), các trang sự kiện tạm thời (không cần duy trì xếp hạng sau khi sự kiện kết thúc), các trang nội dung giá trị thấp (như phiên bản in, trang chuyển đổi tiếng Trung giản thể/phồn thể).
Chuyển hướng 301 (Chuyển hướng vĩnh viễn): Được sử dụng cho “kịch bản nội dung đã di chuyển vĩnh viễn”, tự động chuyển hướng người dùng và công cụ tìm kiếm từ URL cũ sang URL mới thông qua cấu hình máy chủ (chẳng hạn như tệp .htaccess hoặc quy tắc Nginx). Quyền lực của URL cũ (bao gồm xếp hạng, liên kết bên ngoài, sự tin cậy của người dùng) sẽ dần được chuyển giao cho URL mới, và URL cũ cuối cùng có thể không còn truy cập được (nhưng chuyển hướng vẫn hiệu quả).
- Kịch bản điển hình: Thay đổi tên miền trang web (chẳng hạn như di chuyển từ example.com sang newexample.com), điều chỉnh cấu trúc URL (chẳng hạn như thay đổi /old-product/ thành /products/new-product/), hợp nhất nhiều trang cũ thành một trang mới.
| Công cụ | Cho phép thu thập? | Cho phép lập chỉ mục? | URL có thay đổi? | Mục đích chính |
|---|---|---|---|---|
| canonical | ✅ Cho phép | ❌ Gợi ý không lập chỉ mục (nhưng vẫn có thể lập chỉ mục) | ❌ Không thay đổi | Tập trung quyền lực của nhiều nội dung giống nhau vào phiên bản chuẩn |
| noindex | ✅ Cho phép | ❌ Cấm | ❌ Không thay đổi | Chặn trang xuất hiện trong kết quả tìm kiếm |
| Chuyển hướng 301 | ❌ Tự động chuyển hướng | ❌ URL cũ không được lập chỉ mục | ✅ Chuyển hướng đến URL mới | Chuyển giao quyền lực và lưu lượng truy cập từ URL cũ sang địa chỉ mới |
4 Nhóm kịch bản phổ biến và so sánh cách sử dụng
Kịch bản 1: Cùng một nội dung có nhiều URL (chẳng hạn như trang sản phẩm có tham số)
- Vấn đề: Trang chi tiết sản phẩm có thể truy cập qua
https://example.com/productvàhttps://example.com/product?color=red, và nội dung hoàn toàn giống nhau. - Công cụ đúng: canonical. Thêm thẻ canonical trên URL có tham số (
?color=red), trỏ đến URL cơ bản không có tham số (https://example.com/product), nói với công cụ tìm kiếm “phiên bản có thẩm quyền của nội dung này là trang không có tham số”. - Tại sao không chọn noindex/301: noindex sẽ ngăn trang có tham số được lập chỉ mục (nhưng vẫn có thể được thu thập), và người dùng vẫn có thể vào qua liên kết đó, và công cụ tìm kiếm vẫn phải đánh giá đâu là phiên bản chính; chuyển hướng 301 yêu cầu buộc người dùng và robot phải chuyển hướng, nhưng người dùng có thể cần truy cập qua các tham số khác nhau (chẳng hạn như so sánh các màu khác nhau), và chuyển hướng bắt buộc là không phù hợp.
Kịch bản 2: Trang không còn cần xuất hiện trong kết quả tìm kiếm (chẳng hạn như trang sự kiện đã hết hạn)
- Vấn đề: Một trang hoạt động khuyến mãi (
https://example.com/promo) đã kết thúc, nhưng vẫn có thể được người dùng truy cập qua dấu trang hoặc liên kết bên ngoài, và không cần xếp hạng. - Công cụ đúng: noindex. Thêm thẻ
<meta name="robots" content="noindex">vào<head>của trang hoạt động (hoặc cấu hình qua CMS), cho phép công cụ tìm kiếm thu thập trang (ví dụ: để xác minh hồ sơ hoạt động), nhưng cấm nó đưa vào chỉ mục. - Tại sao không chọn canonical/301: canonical không thể giải quyết vấn đề “không hiển thị trang” (nó chỉ tập trung quyền lực); chuyển hướng 301 yêu cầu chỉ định một URL mới (nhưng trang hoạt động không có địa chỉ mới tương ứng), và người dùng vẫn có thể cần truy cập trang gốc để xem thông tin lịch sử.
Kịch bản 3: Thay đổi tên miền hoặc điều chỉnh cấu trúc URL trang web (chẳng hạn như di chuyển trang sản phẩm cũ)
- Vấn đề: Trang sản phẩm cũ (
https://old.example.com/item1) đã được di chuyển vĩnh viễn đến địa chỉ mới (https://new.example.com/products/item1), và cần bảo tồn quyền lực liên kết bên ngoài ban đầu và thói quen truy cập của người dùng. - Công cụ đúng: Chuyển hướng 301. Cấu hình thông qua cấu hình máy chủ (chẳng hạn như tệp .htaccess của Apache) để khi người dùng hoặc robot truy cập URL cũ, họ sẽ tự động được chuyển hướng đến URL mới. Quyền lực xếp hạng của URL cũ (bao gồm xếp hạng, liên kết bên ngoài) sẽ dần được chuyển giao cho URL mới.
- Tại sao không chọn canonical/noindex: canonical không thể đạt được việc chuyển hướng lưu lượng truy cập (người dùng sẽ ở lại URL cũ); noindex sẽ ngăn URL cũ được lập chỉ mục, nhưng quyền lực liên kết bên ngoài sẽ không được chuyển giao, và người dùng không thể truy cập nội dung mới thông qua liên kết cũ.
Kịch bản 4: URL riêng biệt cho điện thoại di động và PC (chẳng hạn như m.example.com và www.example.com)
- Vấn đề: Cùng một nội dung có các URL riêng biệt trên điện thoại di động (
https://m.example.com/page) và PC (https://www.example.com/page), và nội dung hoàn toàn giống nhau. - Công cụ đúng: Ưu tiên canonical (trỏ đến URL PC), hoặc thống nhất thông qua thiết kế đáp ứng. Nếu cần có lối vào di động (ví dụ: người dùng quen truy cập qua m.example.com), có thể thêm thẻ canonical trên trang di động trỏ đến URL chuẩn PC, đồng thời chuyển hướng 301 một số liên kết di động cũ đến PC (tùy chọn).
- Tại sao không chọn noindex: noindex sẽ ngăn một trong các phiên bản di động hoặc PC được lập chỉ mục, điều này có thể cản trở việc đáp ứng nhu cầu tìm kiếm của một số người dùng (ví dụ: người dùng di động không thấy nội dung thích ứng).
Mã nên được viết như thế nào? Và logic hiệu quả khác nhau là gì?
Thẻ canonical: Mã HTML, phụ thuộc vào việc công cụ tìm kiếm phân tích cú pháp
- Định dạng mã: Thêm
<link rel="canonical" href="https://URL_chuẩn" />vào phần<head>của trang cần được chuẩn hóa (như mô tả trong chương trước).
Logic hiệu quả: Khi công cụ tìm kiếm thu thập trang, nó đọc thẻ này và ghi lại “phiên bản chuẩn của trang này là XXX”, và trong tính toán xếp hạng và trao quyền lực tiếp theo, nó ưu tiên phiên bản chuẩn. Tuy nhiên, các phiên bản khác của trang vẫn có thể được thu thập (trừ khi có các hạn chế khác).
Thẻ noindex: Thẻ meta HTML hoặc tiêu đề phản hồi HTTP, phụ thuộc vào việc robot tuân thủ quy tắc
- Định dạng mã: Thường thêm
<meta name="robots" content="noindex">vào<head>của trang (áp dụng cho hầu hết các trường hợp), hoặc trả về tiêu đề phản hồi HTTPX-Robots-Tag: noindexthông qua máy chủ (áp dụng cho các trang động).
Logic hiệu quả: Khi công cụ tìm kiếm thu thập trang, nó phát hiện chỉ thị này và, nếu xác nhận trang tuân thủ các điều kiện noindex (ví dụ: không phải là trang spam), nó sẽ không thêm nó vào chỉ mục. Tuy nhiên, trang vẫn sẽ được thu thập (trừ khi thu thập bị chặn bởi robots.txt) và người dùng có thể truy cập qua liên kết trực tiếp.
Chuyển hướng 301: Cấu hình máy chủ, chuyển hướng bắt buộc lưu lượng truy cập
Định dạng mã: Đạt được thông qua công nghệ máy chủ, ví dụ:
- Máy chủ Apache: Thêm
Redirect 301 /old-page https://example.com/new-pagevào tệp .htaccess; - Máy chủ Nginx: Thêm
return 301 https://example.com/new-page;vào tệp cấu hình; - Hệ thống CMS (chẳng hạn như WordPress): Cấu hình các quy tắc chuyển hướng thông qua một plugin (chẳng hạn như Redirection).
Logic hiệu quả: Khi người dùng hoặc công cụ tìm kiếm truy cập URL cũ, máy chủ sẽ tự động trả về mã trạng thái 301 và chuyển hướng đến URL mới, và thanh địa chỉ trình duyệt sẽ hiển thị địa chỉ mới. Quyền lực của URL cũ sẽ dần được chuyển giao (thường từ vài tuần đến vài tháng) cho URL mới, và URL cũ cuối cùng có thể không còn được truy cập trực tiếp (nhưng chức năng chuyển hướng vẫn được duy trì).
