Nhận dạng các phương pháp và suy đoán hay nhất về phân trang SEO

Phân loại trang giống như một gã biến hình gian xảo vậy. Nó thường được sử dụng trong nhiều ngữ cảnh khác nhau, từ hiển thị các mục trên trang danh mục, đến lưu trữ bài viết, tới trình chiếu thư viện và chuỗi diễn đàn.

Đối với các chuyên gia SEO, đó không phải là vấn đề nếu bạn phải đối phó với phân trang, đó là vấn đề về thời điểm.

Tại một thời điểm phát triển nhất định, các trang web cần chia nhỏ nội dung trên một loạt các trang thành phần cho trải nghiệm người dùng (UX).

Công việc của chúng tôi là giúp các công cụ tìm kiếm thu thập dữ liệu và hiểu mối quan hệ giữa các URL này để chúng lập chỉ mục các trang có liên quan nhất.

Theo thời gian, các phương pháp xử lý phân trang tốt nhất của SEO đã phát triển. Cùng theo đó, nhiều suy đoán về phương pháp này cũng đã thể hiện nó là sự thật chứ không phải là tin đồn suy đoán. Nhưng không còn nữa rồi.

Bài viết này sẽ:
  • Vạch trần những suy đoán về cách phân trang gây ảnh hưởng xấu đến SEO.
  • Trình bày cách tối ưu để quản lý phân trang.
  • Xem xét về các phương thức con của xử lý phân trang hay những hiểu lầm thường gặp.
  • Điều tra cách theo dõi tác động KPI của phân trang.
Phân trang có thể gây ảnh hưởng xấu đến SEO như thế nào?

Có thể bạn đã đọc được đâu đó rằng phân trang sẽ gây ảnh hưởng xấu đối với SEO.

Tuy nhiên, trong hầu hết các trường hợp, điều này là do thiếu cách đúng để xử lý phân trang hơn là do sự tồn tại của phân trang.

Hãy xem xét các sự cố giả định về phân trang và cách khắc phục các vấn đề SEO mà nó có thể gây ra.

Phân trang gây ra nội dung trùng lặp

Điều đó là chính xác nếu phân trang thực sự đã được triển khai không đúng, chẳng hạn như có cả trang "Xem tất cả" và các trang được phân trang mà không có rel=canonical (thẻ trùng lặp URL) chính xác hoặc nếu bạn đã tạo trang = 1 ngoài trang gốc của mình.

Điều đó là không chính xác khi bạn có phân trang SEO thân thiện. Ngay cả khi thẻ H1 và thẻ meta của bạn giống nhau, nội dung trang thực tế khác nhau. Vì vậy, nó không phải là bị trùng lặp về nội dung.


(Joost de Valk: @JohnMu anh có đồng ý rằng mọi người thường có thể bỏ qua cảnh báo về mô tả meta trùng lặp trong Google Search Console một cách an toàn cho URL lưu trữ được phân trang không?

@JohnMu: Vâng, cũng không sao cả. Sẽ hữu ích khi nhận phản hồi về tiêu đề và mô tả trùng lặp nếu bạn vô tình sử dụng chúng trên các trang hoàn toàn riêng biệt, nhưng đối với chuỗi được phân trang, điều này khá là bình thường và cũng được mong đợi sử dụng như nhau.)

Phân trang tạo nội dung mỏng (thin content)

Chính xác nếu bạn đã chia nhỏ một bài viết hoặc thư viện ảnh trên nhiều trang (để thúc đẩy doanh thu quảng cáo bằng cách tăng số lần xem trang), nó để lại quá ít nội dung trên mỗi trang.

Không chính xác khi bạn đặt những mong muốn của người dùng để giúp bạn dễ dàng tiêu thụ nội dung vượt doanh thu quảng cáo biểu ngữ hoặc số lần truy cập trang tăng lên một cách giả tạo. Hãy đặt lượng nội dung thân thiện với UX trên mỗi trang.

Phân trang làm giảm xếp hạng tín hiệu

Đúng nếu phân trang không được xử lý tốt khi nó có thể gây ra liên kết nội bộ như nhau và các tín hiệu xếp hạng khác, chẳng hạn như backlinks và chia sẻ trên mạng xã hội, được chia thành các trang.

Không chính xác khi thuộc tính liên kết rel=”prev” và rel=”next” được sử dụng trên các trang được phân trang, để Google biết cách hợp nhất các tín hiệu xếp hạng.

Phân trang sử dụng ngân sách thu thập thông tin

Đúng nếu bạn cho phép Google thu thập dữ liệu các trang được phân trang. Và có một số trường hợp bạn muốn sử dụng ngân sách đó.

Ví dụ: Googlebot di chuyển qua các URL được phân trang để hợp nhất tín hiệu xếp hạng và tiếp cận các trang nội dung sâu hơn.

Thường không chính xác khi bạn đặt xử lý thông số phân trang của Google Search Console thành "Không thu thập thông tin" hoặc đặt robots.txt không cho phép, trong trường hợp bạn muốn tiết kiệm ngân sách thu thập dữ liệu của mình cho các trang quan trọng hơn.

Quản lý phân trang theo các phương pháp hay nhất về SEO

Sử dụng thuộc tính liên kết rel=”next” & rel=”prev”

[​IMG]

Bạn nên chỉ ra mối quan hệ giữa các URL thành phần trong một chuỗi được phân trang với các thuộc tính rel=”next” và rel=”prev”.

Google khuyên bạn nên dùng tùy chọn này, lưu ý rằng đánh dấu này là "gợi ý cặn kẽ" mà bạn muốn các trang được coi là "chuỗi logic, do đó hợp nhất các thuộc tính liên kết của các trang và thường gửi người tìm kiếm đến trang đầu tiên".

Thực tế, điều này có nghĩa là rel=”next” / “prev” được coi là tín hiệu hơn là chỉ thị. Chúng sẽ không ngăn các trang phân trang được hiển thị trong kết quả tìm kiếm. Nhưng một sự xuất hiện như vậy sẽ rất hiếm xảy ra.

Bổ sung rel=”next” / “prev” với liên kết tự tham chiếu rel=”canonical”. Vì vậy, / category?dage=4 nên rel=”canonical” đến / category?page=4.

Đây là cách tiếp cận được khuyến cáo bởi Google, khi phân trang thay đổi nội dung trang và trở thành bản sao chính của trang đó.

Nếu URL có thông số bổ sung, hãy bao gồm các tham số này trong liên kết rel=”prev” / “next”, nhưng không thêm chúng vào trong rel= ”canonical”.

Ví dụ như:

Mã:
<link rel="next" href="https://www.example.com/category?page=2&order=newest" /> <link rel="canonical" href="https://www.example.com/category?page=2" />
Làm như vậy sẽ cho biết mối quan hệ rõ ràng giữa các trang, không gửi tín hiệu xếp hạng tới các URL dựa trên tham số không liên quan đến SEO và ngăn chặn tiềm năng của nội dung trùng lặp.

Các lỗi phổ biến cần tránh:
  • Đặt các thuộc tính liên kết trong nội dung <body>. Chúng chỉ được các công cụ tìm kiếm hỗ trợ trong phần <head> của HTML của bạn.
  • Thêm liên kết rel=”prev” vào trang đầu tiên (được biết đến là trang gốc) trong chuỗi hoặc liên kết rel=”next” đến cuối cùng. Đối với tất cả các trang khác trong chuỗi, cả hai thuộc tính liên kết phải có mặt.
  • Hãy coi chừng URL chuẩn của trang gốc của bạn. Cơ hội được ở trong ?page=2, rel=prev nên liên kết đến trang chuẩn, không phải là page?=1.
Mã <head> của một loạt bốn trang sẽ trông giống như sau:
  • Một thẻ phân trang trên trang gốc, trỏ đến trang tiếp theo trong chuỗi.
Mã:
<link rel="next" href="https://www.example.com/category?page=2″> <link rel="canonical" href="https://www.example.com/category">
  • Hai thẻ phân trang trên trang 2.
Mã:
<link rel="prev" href="https://www.example.com/category"> <link rel="next" href="https://www.example.com/category?page=3″> <link rel="canonical" href="https://www.example.com/category?page=2">
  • Hai thẻ phân trang trên trang 3.
Mã:
<link rel="prev" href="https://www.example.com/category?page=2″> <link rel="next" href="https://www.example.com/category?page=4″> <link rel="canonical" href="https://www.example.com/category?page=3">
  • Một thẻ phân trang trên trang 4, trang cuối cùng trong chuỗi được phân trang.
Mã:
<link rel="prev" href="https://www.example.com/category?page=3"> <link rel="canonical" href="https://www.example.com/category?page=4">
Sửa đổi tiêu đề trang được phân trang & mô tả thẻ meta

Mặc dù các thuộc tính rel=”next” và rel=”prev” nên trong hầu hết các trường hợp, khiến Google trả về trang gốc trong SERPs, bạn có thể khuyến khích điều này và ngăn chặn cảnh báo “Duplicate meta descriptions (mô tả thẻ meta trùng lặp)” hoặc “Duplicate title tags (thẻ tiêu đề trùng lặp)” trong Google Search Console chỉ với một chút sửa đổi rất dễ dàng đối với mã của bạn.

Nếu trang gốc có công thức như sau:
[​IMG]

Các trang được phân trang liên tiếp có thể có công thức như sau:

[​IMG]

Các tiêu đề trang URL được phân trang và mô tả meta này có mục đích tối ưu hóa để không cho phép Google hiển thị các kết quả này, thay vì trang gốc.

Không bao gồm các trang được phân trang trong Sơ đồ trang web XML

Mặc dù URL phân trang rel = ”next” / “prev” có thể lập chỉ mục về mặt kỹ thuật, chúng không phải là ưu tiên SEO để chi tiêu thu thập thông tin ngân sách.

Như vậy, chúng không thuộc về sơ đồ trang web XML của bạn.

Xử lý thông số phân trang trong Google Search Console

Nếu bạn có lựa chọn, hãy chạy phân trang thông qua tham số thay vì URL tĩnh.

Ví dụ:

Mã:
example.com/category?page=2 TRÊN example.com/category/page-2
Sau đó, bạn có thể định cấu hình tham số trong Google Search Console thành “Paginates (phân trang)” và bất kỳ lúc nào thay đổi tín hiệu cho Google để thu thập thông tin “Every URL (mọi URL)” hoặc “No URLs (không có URL)”, dựa trên cách bạn muốn sử dụng ngân sách thu thập dữ liệu của mình. Không cần đến nhà phát triển!

Những giải pháp SEO sai, lỗi thời, hiểu lầm dành cho nội dung được phân tran

Không làm gì cả

[​IMG]

Google cho biết rằng họ làm "một việc tốt nhằm đưa lại kết quả có liên quan nhất cho người dùng, bất kể nội dung được chia thành nhiều trang" và khuyên bạn có thể xử lý phân trang bằng cách không làm gì cả.

Có một sự thật về những tuyên bố như thế này, nếu bạn không làm gì cả nghĩa là bạn đang đánh cược với SEO của mình.

Luôn có giá trị trong việc cung cấp hướng dẫn rõ ràng cho người thu thập thông tin về cách bạn muốn họ lập chỉ mục và hiển thị nội dung của bạn.

Tiêu chuẩn hóa đối với một trang xem được tất cả

[​IMG]

Tùy chọn cuối cùng được Google đề xuất là một trang Xem được tất cả. Phiên bản này phải chứa tất cả nội dung trang thành phần trên một URL.

Ngoài ra, tất cả các trang được phân trang đều nên rel=”canonical” vào trang Xem Tất cả để hợp nhất các tín hiệu xếp hạng.

Đối số ở đây là người tìm kiếm muốn xem toàn bộ bài viết hoặc danh sách các mục danh mục trên một trang, miễn là tải nhanh và dễ điều hướng.

Vì vậy, nếu chuỗi phân trang của bạn có phiên bản Xem Tất cả thay thế cung cấp trải nghiệm người dùng tốt hơn, Google sẽ ưu tiên trang này để đưa vào kết quả tìm kiếm trái ngược với trang phân đoạn có liên quan của chuỗi phân trang.

Điều này lại đặt ra câu hỏi - tại sao bạn lại có trang được phân trang ở vị trí đầu tiên?

Hãy khiến điều này trở nên đơn giản.

Nếu bạn có thể cung cấp nội dung của mình trên một URL trong khi cung cấp trải nghiệm người dùng tốt, không cần phải phân trang hoặc phiên bản Xem Tất cả.

Ví dụ: nếu bạn không thể làm được điều đó, với các trang danh mục có hàng nghìn sản phẩm sẽ quá lớn và mất quá nhiều thời gian để tải nhanh chóng, và phân trang bằng rel=”next” / “prev”. Xem Tất Cả không phải là lựa chọn tốt nhất vì nó sẽ không cung cấp trải nghiệm người dùng tốt.

Sử dụng cả rel = ”next” / “prev” và phiên bản Xem Tất cả sẽ không đưa ra yêu cầu rõ ràng cho Google và điều này sẽ dẫn đến trình thu thập thông tin nhầm lẫn.

Đừng làm điều đó.

Tiêu chuẩn hóa đối với trang đầu tiên

[​IMG]

Một sai lầm phổ biến là chỉ ra thẻ rel="canonical" từ tất cả các kết quả được phân trang vào trang gốc của chuỗi.

Một số người làm SEO thiếu thông tin đề xuất điều này như là một cách để củng cố sự cho phép trên toàn bộ các trang tới trang gốc, nhưng điều này là không mấy cần thiết khi bạn đã có các thuộc tính rel=”next” và rel=”prev”.

Việc chuẩn hóa sai trang gốc sẽ dẫn đến nguy cơ dẫn hướng sai công cụ tìm kiếm vào suy nghĩ rằng bạn chỉ có một trang kết quả.

Googlebot sau đó sẽ không lập chỉ mục các trang xuất hiện xa hơn trong chuỗi, cũng như không thừa nhận các tín hiệu cho nội dung được liên kết từ các trang đó.

Bạn không muốn các trang nội dung chi tiết của bạn bỏ qua chỉ mục do xử lý phân trang kém.

Google rõ ràng về yêu cầu. Mỗi trang trong một chuỗi được phân trang phải có một quy tắc tự tham chiếu, trừ khi bạn sử dụng trang Xem tất cả.

Nếu sử dụng thẻ rel=canonical không chính xác và có khă năng rất cao là Googlebot sẽ chỉ bỏ qua tín hiệu của bạn mà thôi.

Trang được phân trang Noindex (Không chỉ mục)

[​IMG]

Một phương pháp cổ điển dùng để giải quyết vấn đề phân trang chính là một thẻ ngăn lập chỉ mục rô bốt để ngăn các công cụ tìm kiếm lập chỉ mục nội dung được phân trang.

Chỉ dựa vào thẻ noindex để xử lý phân trang sẽ dẫn đến tín hiệu xếp hạng từ các trang thành phần của bạn không được hợp nhất. SEO sẽ kém rõ ràng hơn khi sử dụng rel=”next” / “prev”.

Nhưng khi phương thức rel=”next” / “prev” cho phép các công cụ tìm kiếm lập chỉ mục các trang phân trang, tôi cũng đã thấy một số người dùng SEO khuyên hãy thêm “bảo mật bổ sung” bằng thẻ noindex.

Điều này là không cần thiết. Chỉ trong những trường hợp hiếm hoi, Google sẽ chọn trả lại một trang được phân trang trong SERPs. Những lợi ích tốt nhất là lý thuyết.

Nhưng những gì bạn có thể không nhận thức được là một noindex dài hạn trên một trang cuối cùng sẽ khiến Google để nofollow các liên kết trên trang đó. Vì vậy, một lần nữa, nó có khả năng gây ra nội dung liên kết từ các trang được phân trang để được loại bỏ khỏi chỉ mục.

Phân trang và cuộn vô hạn

[​IMG]

Một hình thức xử lý phân trang mới hơn bằng cách cuộn vô hạn, nơi nội dung được tìm nạp trước và được thêm trực tiếp vào trang hiện tại của người dùng khi họ cuộn xuống.

Người dùng có thể đánh giá cao điều này, nhưng Googlebot? Không nhiều lắm.

Googlebot không mô phỏng hành vi như cuộn xuống cuối trang hoặc nhấp để tải thêm. Có nghĩa là không cần đến trợ giúp, công cụ tìm kiếm không thể thu thập dữ liệu tất cả nội dung của bạn một cách hiệu quả được.

Để thân thiện với SEO, hãy chuyển đổi trang cuộn vô hạn của bạn thành một chuỗi được phân trang tương đương có thể truy cập được ngay cả khi JavaScript bị tắt.

Khi người dùng cuộn, hãy sử dụng JavaScript để điều chỉnh URL trong thanh địa chỉ đến trang được phân trang thành phần.

Ngoài ra, hãy triển khai pushState cho bất kỳ hành động nào của người dùng giống như một lần nhấp hoặc chủ động chuyển một trang. Bạn có thể xem chức năng này trong bản demo do John Mueller tạo ra.

Về cơ bản, bạn vẫn đang triển khai các phương pháp tốt nhất về SEO đã được đề xuất ở trên, bạn chỉ cần thêm chức năng trải nghiệm người dùng bổ sung ở trên cùng.

Phản đối hoặc chặn thu thập dữ liệu phân trang

[​IMG]

Một số chuyên gia SEO khuyên bạn nên tránh các vấn đề xử lý phân trang đại khái bằng cách chặn Google thu thập dữ liệu URL được phân trang.

Trong trường hợp này, bạn sẽ muốn có được các sơ đồ trang web XML được tối ưu hóa tốt nhất để đảm bảo các trang được liên kết thông qua phân trang có cơ hội được lập chỉ mục.

Có ba cách để làm điều này:
  • Cách lộn xộn: Thêm nofollow vào tất cả các liên kết trỏ tới các trang được phân trang.
  • Cách dọn dẹp: Sử dụng robots.txt không cho phép.
  • Không cần đến dev: Đặt tham số trang được phân trang thành " Pagination (Phân trang)" và để Google thu thập thông tin "Không có URL" trong Google Search Console.
Bằng cách sử dụng một trong các phương pháp này để ngăn cản các công cụ tìm kiếm thu thập thông tin các URL được phân trang, bạn cần:
  • Ngăn các công cụ tìm kiếm thực hiện hợp nhất tín hiệu xếp hạng của các trang được phân trang.
  • Ngăn chặn việc chuyển giao quyền sở hữu liên kết nội bộ từ các trang được phân trang xuống các trang nội dung đích.
  • Cản trở Google có khả năng khám phá các trang nội dung đích của bạn.
Điểm nổi bật rõ ràng là bạn tiết kiệm ngân sách thu thập dữ liệu.

Không có quyền rõ ràng hay sai ở đây. Bạn cần phải quyết định xem độ ưu tiên cho trang web của bạn là gì.

Theo cá nhân, nếu tôi được ưu tiên thu thập thông tin ngân sách, tôi sẽ làm như vậy bằng cách sử dụng xử lý phân trang trong Google Search Console vì nó có sự linh hoạt tối ưu để thay đổi quyết định của bạn.

Theo dõi tác động KPI của phân trang

Vì vậy, bây giờ bạn biết phải làm gì, làm thế nào để bạn theo dõi sự hiệu quả của xử lý phân trang tối ưu?

Thứ nhất, thu thập dữ liệu điểm chuẩn để hiểu cách xử lý phân trang hiện tại của bạn đang tác động đến SEO như thế nào.

Nguồn cho KPI có thể bao gồm:
  • Server log files (Tệp nhật ký máy chủ) cho số lần thu thập dữ liệu trang được phân trang.
  • Trang web: toán tử tìm kiếm (ví dụ: site:example.com inurlage) để hiểu số lượng trang được phân trang mà Google đã lập chỉ mục.
  • Báo cáo phân tích tìm kiếm trên Google Search Console được lọc theo các trang có chứa phân trang để hiểu số lần hiển thị.
  • Báo cáo trang đích Google Analytics được lọc bởi các URL được phân trang để hiểu hành vi trên trang web.
Nếu bạn gặp sự cố khi công cụ tìm kiếm thu thập dữ liệu phân trang trang web của bạn để tiếp cận nội dung của bạn, bạn có thể muốn thay đổi liên kết phân trang.

Khi bạn đã khởi chạy phương pháp xử lý phân trang tốt nhất của mình, hãy truy cập lại các nguồn dữ liệu này để đo lường thành công những nỗ lực của chính bạn.

Ghi nguồn waytomarketing.com khi sao chép lại nội dung bài viets này.
Link: Nhận dạng các phương pháp và suy đoán hay nhất về phân trang SEO.​
Nguồn: www.thegioiseo.com