Crawl budget: khi nào cần lo, và nên sửa đúng những gì

Nếu website của bạn dưới mười nghìn trang, gần như chắc chắn bạn không cần lo về crawl budget. Google nói thẳng trong tài liệu của họ: ngưỡng đáng quan tâm là khoảng một triệu trang trở lên mà nội dung đổi hằng tuần, hoặc từ mười nghìn trang trở lên mà nội dung đổi hằng ngày, hoặc khi bạn thấy nhiều URL nằm ở trạng thái "Discovered - currently not indexed" trong Search Console. Bài viết mới đăng hôm nay mà mai đã có trên Google thì bạn chỉ cần giữ sitemap cho đúng.

Với các site thương mại điện tử hay tin tức trong nước, nơi một sản phẩm sinh ra hàng chục URL vì bộ lọc màu sắc, kích cỡ và thứ tự sắp xếp, câu chuyện lại khác hẳn. Ngân sách thu thập gồm hai phần. Phần thứ nhất là giới hạn năng lực thu thập, phụ thuộc vào việc máy chủ của bạn chịu được bao nhiêu kết nối song song. Mọi site đều bắt đầu ở mức mặc định thận trọng như nhau, Google tự nâng lên khi thấy phản hồi nhanh và ổn định, và hạ xuống khi gặp độ trễ cao, lỗi 5xx hay mã 429. Phần thứ hai là nhu cầu thu thập, tính theo quy mô, tần suất cập nhật, chất lượng và độ liên quan của site so với những site khác.

Điểm đáng nhớ nhất: trong ba yếu tố tạo ra nhu cầu, Google khẳng định lượng URL mà Googlebot cho rằng site bạn đang có là "yếu tố bạn kiểm soát được nhiều nhất". Nếu bạn không chỉ đường, Googlebot sẽ cố bò hết những gì nó tìm thấy. Hai yếu tố còn lại là độ phổ biến và độ cũ của nội dung, bạn tác động gián tiếp qua liên kết nội bộ và lịch cập nhật.

Sai lầm phổ biến nhất ở Việt Nam là dùng thẻ noindex để tiết kiệm ngân sách thu thập. Cách này không hoạt động, và Google nói rõ là đừng làm. Googlebot vẫn phải tải trang về rồi mới đọc được thẻ noindex và bỏ đi, nghĩa là chi phí thu thập đã mất rồi. Muốn chặn thật sự thì phải dùng robots.txt. Nhưng cũng đừng kỳ vọng chặn bớt vài thư mục sẽ dồn ngân sách sang chỗ khác: Google chỉ chuyển phần dôi ra khi site của bạn vốn đã chạm trần năng lực thu thập.

Việc thực sự cần làm là dọn kho URL. Gộp nội dung trùng lặp để Googlebot tập trung vào nội dung khác nhau chứ không phải vào các URL khác nhau, đây chính là chỗ các tham số lọc và phân trang gây lãng phí nhiều nhất. Trả về 404 hoặc 410 cho trang đã gỡ hẳn, vì mã 404 là tín hiệu mạnh để Google thôi quay lại, trong khi một URL bị chặn bằng robots.txt vẫn nằm trong hàng đợi rất lâu và sẽ được thu thập lại ngay khi bạn bỏ chặn. Đặc biệt chú ý lỗi soft 404, kiểu trang "không tìm thấy sản phẩm" nhưng vẫn trả mã 200, vì loại này bị thu thập lại mãi mãi.

Nhóm việc thứ hai là làm cho mỗi lượt tải rẻ đi. Tránh chuỗi chuyển hướng dài, thứ mà Google nói thẳng là có ảnh hưởng tiêu cực đến thu thập, và chuỗi này hay phát sinh âm thầm sau mỗi lần đổi cấu trúc URL. Cải thiện thời gian phản hồi của máy chủ, giảm dung lượng tài nguyên mỗi trang phải tải, bật HTTP caching và trả về 304 Not Modified khi nội dung chưa đổi để Googlebot gần như không tốn gì cho lần ghé lại.

Hai điểm kỹ thuật nữa nên làm cho đúng. Giữ sitemap luôn cập nhật và khai báo thẻ lastmod nếu nội dung thay đổi, vì Google đọc sitemap thường xuyên để quyết định nên ghé lại chỗ nào. Và nếu site của bạn phục vụ HTML riêng cho di động và máy tính, hãy đảm bảo bản di động có đủ bộ liên kết như bản desktop. Google bổ sung hướng dẫn này từ tháng 11 năm 2024, lý do rất đơn giản là chỉ bản di động được lập chỉ mục, nên menu di động bị cắt gọn sẽ làm chậm việc phát hiện toàn bộ trang nằm phía sau. Không làm được thì đưa các URL đó vào sitemap.

Để đo, hãy xem công cụ Kiểm tra URL: khi nó báo "Hostload exceeded" thì nút thắt nằm ở máy chủ chứ không phải ở nội dung, và việc cần làm là nâng hạ tầng. Báo cáo Lập chỉ mục trang cho bạn thấy soft 404 và tình trạng chỉ mục, còn log máy chủ cho biết Googlebot thực sự ghé vào đâu và bỏ quên khu vực nào.

Cuối cùng, đừng mong có nút xin thêm ngân sách. Google chỉ đưa ra hai hướng: tăng năng lực phục vụ nếu bạn đang chạm trần, và tăng giá trị cùng tính độc nhất của nội dung. Cũng nên nhớ được thu thập không đồng nghĩa với được lập chỉ mục, vì mỗi trang còn phải qua bước đánh giá. Cứ làm theo thứ tự trùng lặp, soft 404, chuyển hướng, tốc độ, và bạn sẽ thấy phần lớn vấn đề thu thập thật ra là vấn đề quản lý kho nội dung.