Hãy tưởng tượng Googlebot như một vị khách VIP đến shop của bạn: họ chỉ có giới hạn thời gian mỗi ngày, có danh sách cụ thể muốn xem, sẽ nhanh chóng rời đi nếu shop chậm, và không quay lại thường xuyên nếu shop quá lớn và rối. Crawl Budget chính là "thời gian và tài nguyên" mà Google dành để crawl site của bạn.
Tại Việt Nam, phần lớn ecommerce lớn (>100k URL) đang gặp vấn đề crawl budget; nhiều news site lãng phí ngân sách crawl vào URL trùng lặp; và không ít site hàng triệu URL chỉ index được 30–50%.
Đây là bài nâng cao. Bạn không cần lo crawl budget nếu: site nhỏ (<5.000 trang), trang được crawl ngay sau khi publish, sitemap đầy đủ và cập nhật. Bạn cần nếu: site rất lớn (1M+ trang) update hàng tuần, site trung bình (10k+ trang) update hàng ngày, hoặc Search Console báo nhiều URL "Discovered – currently not indexed".
Phần 1: Crawl Budget là gì?
Theo Google, crawl budget là lượng thời gian và tài nguyên Google dành cho việc crawl một website. Nó được cấu thành từ hai yếu tố:
Yếu tố | Bản chất | Điều gì ảnh hưởng |
|---|---|---|
Crawl Capacity Limit | Số kết nối song song tối đa Google dùng để crawl, cùng độ trễ giữa các lần fetch | TĂNG khi site phản hồi nhanh, server ổn định, không lỗi. GIẢM khi site chậm, lỗi server (5xx), timeout |
Crawl Demand | Mức độ Google muốn crawl site của bạn | Phụ thuộc quy mô site, tần suất cập nhật, chất lượng trang và độ liên quan so với các site khác |
Crawl Demand lại phụ thuộc ba yếu tố: Perceived Inventory (bạn có bao nhiêu nội dung — càng nhiều URL độc nhất thì demand càng cao, càng nhiều duplicate thì càng lãng phí); Popularity (URL có nhiều backlink/traffic sẽ được crawl thường xuyên hơn); và Staleness (nội dung news/ecommerce hay thay đổi → crawl thường; trang tĩnh → crawl ít hơn).
Điểm mấu chốt: kể cả khi chưa chạm giới hạn crawl capacity, nếu crawl demand thấp thì Google vẫn crawl site bạn ít đi. Phải tối ưu cả hai.
Quan trọng: Crawl ≠ Index. Không phải trang nào được crawl cũng sẽ được index. Luồng thực tế: URL được biết tới → vào crawl queue (giới hạn bởi crawl budget) → được crawl → xử lý → đánh giá chất lượng → quyết định index (indexed / không index vì chất lượng thấp / gộp lại vì trùng lặp). Crawl budget chỉ là bước đầu — nội dung chất lượng vẫn là điều kiện cần.
Phần 2: Quản lý URL inventory
Gộp nội dung trùng lặp (canonical)
Sai lầm phổ biến: nhiều URL cho cùng một nội dung — /product?id=123, /aotrang?color=white, /products/ao-thun-trang... đều là một sản phẩm. Cách đúng là canonicalize:
html
<link rel="canonical" href="https://example.com/products/ao-thun-trang">Chặn crawl những gì không quan trọng
# robots.txt
User-agent: *
# Chặn trang kết quả tìm kiếm nội bộ
Disallow: /search?
Disallow: /*?q=
# Chặn bản sắp xếp
Disallow: /*?sort=
Disallow: /*?orderBy=
# Chặn bản lọc
Disallow: /*?filter=
Disallow: /*?color=&size=
# Chặn tracking parameters
Disallow: /*?utm_*
Disallow: /*?fbclid=
Disallow: /*?gclid=
Sitemap: https://example.com/sitemap.xmlKHÔNG dùng noindex để tiết kiệm budget
Đây là cảnh báo quan trọng từ Google: đừng dùng noindex để tiết kiệm crawl budget, vì Google vẫn phải request trang rồi mới thấy thẻ noindex — tức là vẫn tốn thời gian crawl.
Cách chặn | Google có fetch không? | Crawl budget |
|---|---|---|
| KHÔNG fetch | Tiết kiệm ✅ |
| CÓ fetch rồi mới biết | Lãng phí ❌ |
→ Với site lớn: dùng robots.txt, không phải noindex.
404/410 cho trang đã gỡ bỏ
404 Not Found là tín hiệu mạnh ("đừng crawl lại"); 410 Gone còn mạnh hơn ("đã gỡ vĩnh viễn"). Ngược lại, URL bị chặn bằng robots.txt sẽ nằm trong crawl queue lâu hơn và sẽ được crawl lại khi bỏ chặn. Việc xử lý lỗi 404 đúng cách và bảo toàn link equity là một phần của chiến lược này.
Loại bỏ Soft 404
Soft 404 = trả về status 200 OK nhưng nội dung lại là trang lỗi. Sai: URL /product/non-existent-id trả 200 OK kèm nội dung "Sản phẩm không tồn tại". Đúng: cũng nội dung đó nhưng trả về status 404 Not Found.
Sitemap luôn cập nhật và tránh redirect chain dài
xml
<url>
<loc>https://example.com/page</loc>
<lastmod>2026-05-21</lastmod>
</url>Đưa <lastmod> vào các URL có nội dung thay đổi. Đồng thời tránh chuỗi redirect dài: A → B → C → D → E (4 redirect, lãng phí budget) nên rút thành A → E (1 redirect).
Phần 3: Faceted Navigation — Vấn đề kinh điển
Ecommerce thường có nhiều bộ lọc: màu (10 lựa chọn) × size (5) × thương hiệu (20) × khoảng giá (8) × chất liệu (15) = 120.000 URL độc nhất — một quả bom crawl budget.
Chiến lược | Cách làm |
|---|---|
Cho phép tổ hợp quan trọng | Cho crawl |
Dùng canonical | Trang lọc trỏ canonical về trang danh mục chính |
robots.txt có chọn lọc |
|
Lọc bằng AJAX | Cập nhật nội dung qua API mà không tạo URL mới |
javascript
// Thay vì đổi URL khi lọc, dùng AJAX để cập nhật nội dung
button.onclick = async () => {
const filtered = await fetch('/api/filter?color=red');
updateUI(filtered);
// URL giữ nguyên → không sinh URL mới
};Phần 4: Kiến trúc site cho website lớn
Flat tốt hơn Deep. Cấu trúc sâu (home → category → subcategory → sub-sub → product, 5+ click) khiến trang khó được crawl; cấu trúc phẳng (product chỉ cách home 2–3 click) giúp trang được crawl thường xuyên hơn. Nguyên tắc internal linking: homepage → category (1 click) → sub-category (2 click) → product (3 click). Tránh orphan page (không có internal link nào trỏ tới) và tránh chôn quá sâu; nên cross-link nội dung liên quan và dùng breadcrumb.
Hub page (trang tổng hợp link tới nhiều trang con, ví dụ "Best Sellers" trỏ tới 50 sản phẩm) giúp tăng tần suất crawl cho các trang được link.
Pagination: tránh phân trang vô tận (?page=1 đến ?page=1000). Cách xử lý: trang 1 để index; các trang giữa dùng noindex, follow; các trang quá sâu thì chặn. Hoặc dùng trang "View All" làm canonical.
Phần 5: Trang tải hiệu quả & Crawl Stats
Trang tải nhanh giúp Google crawl được nhiều hơn trong cùng ngân sách. Các kỹ thuật: giảm thời gian phản hồi server (TTFB), nén asset (gzip/Brotli), dùng CDN, tối ưu truy vấn database, cache nội dung tĩnh, minify HTML/CSS/JS — tất cả nằm trong checklist Technical SEO và Core Web Vitals.
Crawl Stats (Search Console → Settings → Crawl Stats) cho biết: tổng số crawl request, tổng dung lượng đã tải, thời gian phản hồi trung bình và tình trạng host. Các pattern cần theo dõi: crawl request tăng đột ngột (có thể do update lớn — hoặc do crawl loop lãng phí); crawl request giảm (có thể do lỗi server — hoặc Google mất hứng thú); response time tăng (server quá tải → crawl giảm). Nên phân tích theo loại file, theo mục đích (discovery vs refresh) và theo response code (200/301/404/5xx) để phát hiện vấn đề nhanh.
Ngoài Search Console, có thể dùng server log (xác định request của Googlebot, tìm lỗi 404/500, phát hiện lãng phí) và các công cụ phân tích log như Screaming Frog Log Analyzer, JetOctopus, Botify.
Phần 6: Hai cách tăng Crawl Budget
Cách 1 — Tăng tài nguyên server. Dấu hiệu cần nâng cấp: báo "Hostload exceeded" trong URL Inspection, lỗi 5xx thường xuyên, response time chậm liên tục, site bị crawl ít dù có nội dung mới. Giải pháp: nâng hosting, thêm RAM/CPU, triển khai CDN, load balancing, tối ưu database, thêm lớp cache.
Cách 2 — Nâng chất lượng nội dung. Google phân bổ tài nguyên crawl dựa trên các yếu tố như độ phổ biến (backlink, traffic), giá trị tổng thể với người dùng, tính độc nhất của nội dung và khả năng phục vụ của site. Nói cách khác: nội dung chất lượng và authority càng cao thì crawl budget càng lớn.
Phần 7: 10 sai lầm làm lãng phí Crawl Budget
Sai lầm | Ví dụ |
|---|---|
Quá nhiều URL parameter |
|
Faceted navigation không kiểm soát | Hàng triệu tổ hợp URL lọc |
Session ID trong URL |
|
Infinite scroll không giới hạn |
|
Nội dung trùng lặp khắp nơi | Cùng một sản phẩm ở 5+ URL khác nhau |
Chuỗi redirect dài | A → B → C → D → E |
Server phản hồi chậm | TTFB > 1,5s |
Lỗi Soft 404 | Trả status 200 cho trang lỗi |
Dùng noindex thay robots.txt | Hàng triệu trang noindex vẫn bị fetch |
Sitemap lỗi thời | Sitemap chứa URL cũ, redirect, 404 |
Phần 8: Lộ trình tối ưu
Giai đoạn 1 — Audit (tuần 1–2): export crawl stats, xác định pattern lãng phí, phân tích server log.
Giai đoạn 2 — Quick wins (tuần 3–4): cập nhật robots.txt, sửa soft 404, khử URL trùng lặp bằng canonical, rút ngắn redirect chain.
Giai đoạn 3 — Cấu trúc (tháng 2): chiến lược faceted navigation, tối ưu pagination, rà soát internal linking, làm phẳng kiến trúc site.
Giai đoạn 4 — Server (tháng 3): tối ưu hiệu năng, triển khai CDN, tuning database, chiến lược cache.
Giai đoạn 5 — Giám sát (liên tục): kiểm tra crawl stats hàng tuần, audit toàn diện hàng tháng.
Phần 9: Case study — Ecommerce 500k SKU
Chỉ số | Trước | Sau 3 tháng |
|---|---|---|
Tổng URL trong queue | 5,2 triệu | 600k (−88%) |
Đã index | 380k (7,3%) | 450k (75%) |
Tốc độ crawl | 50k/ngày | 200k/ngày (+300%) |
Thời gian index sản phẩm mới | 14 ngày | 24–48 giờ |
Organic traffic | — | +47% |
Chuyển đổi | — | +32% |
Vấn đề phát hiện: 4,2 triệu URL sinh ra từ faceted navigation; 200k URL sản phẩm trùng lặp; 50k soft 404; 10k chuỗi redirect 3–5 chặng. Hành động: cập nhật robots.txt chặn bộ lọc xấu, triển khai canonical toàn site, sửa 404 đúng chuẩn, rút ngắn redirect, thiết lập CDN.
Kết luận
Crawl Budget là yếu tố "vô hình" nhưng ảnh hưởng lớn tới SEO của các site lớn. Năm thông điệp cốt lõi: (1) crawl budget chỉ thực sự quan trọng với site lớn (>10k trang, cập nhật thường xuyên); (2) robots.txt tốt hơn noindex khi muốn tiết kiệm budget; (3) canonical giúp gộp nội dung trùng lặp; (4) hiệu năng server ảnh hưởng trực tiếp; và (5) chất lượng nội dung quyết định độ lớn của budget.
Crawl Budget và Site Architecture là nền tảng để xây dựng website có khả năng mở rộng và phát triển SEO dài hạn. Nếu doanh nghiệp của bạn đang vận hành website lớn hoặc ecommerce nhiều sản phẩm — đặc biệt là website bán hàng cần SEO ở quy mô lớn — hãy tham khảo dịch vụ SEO kỹ thuật và liên hệ Tấn Phát Digital để được tư vấn.
Biên soạn và Việt hóa từ tài liệu Google Search Central về tối ưu crawl budget. Phần phân tích và case study thuộc về Tấn Phát Digital.
