Crawl budget là gì? Tối ưu đúng cho website lớn

Một website 800 trang thường không cần “xin thêm crawl budget”. Một website 80.000 URL do bộ lọc sinh ra lại có thể khiến Googlebot dành phần lớn thời gian cho những trang không ai muốn index. Hai tình huống nhìn giống nhau trên Search Console nhưng cách xử lý hoàn toàn khác.

Bài này dành cho người quản trị ecommerce, báo điện tử, marketplace hoặc website programmatic SEO đang thấy nhiều URL ở trạng thái “Discovered – currently not indexed”, sitemap cập nhật chậm hoặc log server đầy request vào trang tham số.

Crawl budget là gì?

Crawl budget là tập hợp URL Google có thể và muốn crawl trên một website trong một khoảng thời gian. Nó hình thành từ hai phần:

• Crawl capacity limit: số request Googlebot có thể gửi mà không làm máy chủ quá tải.
• Crawl demand: mức Google muốn quay lại URL dựa trên độ mới, mức phổ biến, chất lượng và giá trị của trang.

Máy chủ nhanh giúp tăng khả năng phục vụ crawl, nhưng không đảm bảo Google sẽ crawl nhiều hơn. Nếu hàng nghìn URL gần trùng, mỏng hoặc không có nhu cầu tìm kiếm, crawl demand vẫn thấp.

Google lưu ý crawl budget chủ yếu đáng quan tâm với site rất lớn, site từ khoảng 10.000 URL thay đổi hàng ngày, hoặc site có tỷ lệ “Discovered – currently not indexed” cao. Với blog nhỏ, giữ sitemap sạch và internal link rõ thường đã đủ.

Trước khi tối ưu: xác định bạn có thật sự thiếu crawl budget

Đừng bắt đầu bằng chỉnh robots.txt. Hãy trả lời bốn câu:

1. URL quan trọng có được crawl sau khi xuất bản hoặc cập nhật không?
2. Có một lượng lớn URL hợp lệ nằm ở “Discovered – currently not indexed” trong nhiều tuần không?
3. Crawl Stats có cho thấy Googlebot dành request cho tham số, trang tìm kiếm nội bộ hoặc URL trùng không?
4. Server có trả nhiều 5xx, timeout hoặc phản hồi chậm khi Googlebot tăng crawl không?

Nếu câu trả lời đều là không, vấn đề thường nằm ở chất lượng nội dung, liên kết nội bộ hoặc indexability chứ không phải ngân sách crawl.

Bắt đầu từ log server, không phải cảm giác

GA4 không phải công cụ phân tích crawl. Googlebot không chạy giống người dùng và có thể không xuất hiện đầy đủ trong analytics. Access log mới cho biết crawler đã gọi URL nào, status gì và mất bao lâu.

Một báo cáo tối thiểu nên có:

Đừng tin user-agent một cách mù quáng. Bot xấu có thể tự xưng là Googlebot. Hãy xác minh bằng reverse DNS hoặc dải IP chính thức trước khi đưa dữ liệu vào báo cáo.

Bảy việc cải thiện hiệu quả crawl

1. Thu gọn “kho URL” mà Google nhìn thấy

Faceted navigation là thủ phạm phổ biến nhất. Một danh mục có 10 bộ lọc, mỗi bộ lọc nhiều giá trị và khả năng kết hợp tự do có thể tạo hàng chục nghìn URL.

Chia URL thành ba nhóm:

• Có search intent và nội dung riêng: cho index, self-canonical, thêm internal link.
• Hữu ích cho người dùng nhưng không cần index: kiểm soát crawl/index theo chiến lược rõ ràng.
• Không có giá trị: ngăn hệ thống sinh link hoặc loại bỏ hoàn toàn.

Canonical không phải công cụ tiết kiệm crawl tuyệt đối. Google vẫn phải tải trang để đọc canonical. Cách hiệu quả nhất là không phát tán URL vô ích ngay từ đầu.

2. Giữ sitemap như danh sách ưu tiên

Sitemap không phải bãi chứa toàn bộ URL database. Chỉ đưa vào:

• URL canonical;
• trả về 200;
• được phép index;
• có nội dung đủ chất lượng;
• dùng <lastmod> phản ánh lần thay đổi nội dung thật.

Đổi <lastmod> mỗi lần deploy footer làm tín hiệu mất giá trị. Hãy cập nhật khi nội dung chính, dữ liệu sản phẩm hoặc thông tin quan trọng thay đổi.

Bạn có thể dùng Sitemap Checker để kiểm tra sitemap index, số URL và trường lastmod.

3. Sửa redirect chain và URL cũ

Googlebot có thể đi qua redirect, nhưng chuỗi A → B → C → D làm chậm việc đến trang đích và khiến kiến trúc khó bảo trì. Internal link phải trỏ thẳng tới D; sitemap cũng chỉ chứa D.

Sau migration, đừng xóa redirect cũ quá sớm. Hãy rút gọn chuỗi thành một bước và theo dõi log để biết URL cũ còn được gọi hay không. Redirect Chain Checker giúp thấy nhanh toàn bộ hop.

4. Trả status code đúng

Sản phẩm đã xóa vĩnh viễn nên trả 404 hoặc 410, không trả trang “không tìm thấy” với status 200. Soft 404 khiến crawler tiếp tục xử lý một URL không có giá trị.

Lỗi 5xx và timeout còn nghiêm trọng hơn. Khi server liên tục lỗi, crawl capacity có thể giảm để tránh gây tải. Theo dõi theo template và thời gian giúp phân biệt lỗi ứng dụng với đợt crawl lớn.

5. Làm trang nhẹ hơn cho cả người dùng lẫn crawler

Response nhanh, HTML gọn và tài nguyên ổn định giúp Google tải nhiều nội dung hơn trong cùng điều kiện. Tối ưu TTFB, cache, truy vấn database, ảnh và JavaScript không chỉ phục vụ Core Web Vitals.

Đặc biệt với trang JavaScript nặng, Google còn cần render sau khi crawl HTML. Server-side rendering hoặc pre-rendering nội dung quan trọng giảm phụ thuộc vào hàng đợi render.

6. Tạo internal link theo giá trị kinh doanh

URL quan trọng nhưng chỉ nằm trong sitemap vẫn có thể bị xem là yếu. Danh mục, hub, breadcrumb và bài viết liên quan nên tạo đường crawl tự nhiên tới sản phẩm hoặc landing page ưu tiên.

Một quy tắc thực tế: nếu đội nội dung không thể chỉ ra người dùng sẽ đi tới trang bằng đường nào, crawler cũng có thể gặp khó khăn tương tự.

7. Dọn lịch phát hành và cập nhật

Với báo chí hoặc marketplace, đẩy hàng trăm nghìn thay đổi cùng lúc có thể tạo đỉnh tải. Chia batch hợp lý, dùng sitemap index theo loại nội dung và cập nhật lastmod chính xác giúp crawler nhận biết phần vừa thay đổi.

Những “mẹo crawl budget” dễ phản tác dụng

Noindex hàng loạt để Google khỏi crawl

Google phải crawl URL mới thấy noindex. Nếu mục tiêu là ngăn crawl một vùng vô ích, noindex không giải quyết phần request. Tuy nhiên, robots.txt cũng không nên dùng như nút vặn ngân sách tùy tiện; URL bị chặn vẫn có thể nằm trong hàng đợi lâu.

Chặn CSS và JavaScript

Google cần tài nguyên để render và đánh giá trang. Chặn file quan trọng có thể làm crawler nhìn thấy một giao diện thiếu nội dung hoặc không thân thiện mobile.

Xóa sitemap cũ rồi chờ Google “ưu tiên” sitemap mới

Sitemap là tín hiệu khám phá, không phải lệnh phân bổ quota. Sitemap sạch giúp Google hiểu inventory, nhưng không biến nội dung mỏng thành nội dung đáng crawl.

Tăng crawl rate bằng mọi giá

Nếu server đang trả chậm hoặc lỗi, ép crawler truy cập nhiều hơn chỉ làm tình hình xấu đi. Ưu tiên crawl health trước, sau đó mới nhìn nhu cầu crawl.

Kế hoạch 14 ngày cho website lớn

Ngày 1–3: đo baseline

Xuất Crawl Stats, Indexing report và 7–14 ngày access log. Nhóm URL theo template, status, tham số và thời gian phản hồi.

Ngày 4–6: chọn ba nguồn lãng phí lớn nhất

Thông thường đó là URL bộ lọc, chuỗi redirect và soft 404. Đừng sửa 20 vấn đề cùng lúc; bạn sẽ khó biết thay đổi nào tạo tác động.

Ngày 7–10: sửa ở nguồn phát sinh

Loại link tham số khỏi component, chuẩn hóa URL, cập nhật sitemap generator và trả đúng status. Kiểm thử trên staging nhưng nhớ rằng crawler chỉ đánh giá môi trường public.

Ngày 11–14: theo dõi sau triển khai

So sánh tỷ lệ request vào URL ưu tiên, số 5xx, response time và trạng thái index. Crawl pattern không đổi ngay trong một đêm, nhưng log sẽ cho tín hiệu sớm hơn báo cáo tổng hợp.

Khi nào nên dùng Search Console và khi nào dùng log?

Search Console tốt để nhìn xu hướng crawl, trạng thái index và lỗi ở cấp website. Log tốt để trả lời chi tiết: bot nào gọi URL nào lúc mấy giờ, nhận status gì, tốn bao lâu.

Hai nguồn không cạnh tranh nhau. Search Console cho bản đồ; log cho dấu chân.

Bước khởi đầu: chạy SEO audit miễn phí để tìm sitemap, robots, redirect và indexability; sau đó dùng log server để đo crawl thực tế trên site lớn.

Kết luận

Tối ưu crawl budget không phải tìm mẹo khiến Googlebot ghé nhiều hơn. Mục tiêu là để phần crawl hiện có đi vào URL đáng giá, trong khi server phản hồi nhanh và ổn định. Hãy giảm URL rác, giữ sitemap trung thực, sửa status code, rút gọn redirect và xây internal link theo mức ưu tiên. Nếu site chưa đủ lớn, dành thời gian nâng chất lượng nội dung thường mang lại kết quả tốt hơn.

Nguồn tham khảo: Google Search Central – Crawl Budget Management và Googlebot.