Nội dung
Search Console báo 646 trang của marketing365.vn chưa vào chỉ mục, 322 trang đã vào. Phản xạ đầu tiên của gần như ai cũng vậy: chắc nội dung chưa đủ tốt, chắc thiếu backlink, chắc phải viết dài hơn. Chúng tôi cũng nghĩ thế, cho đến khi ngồi đếm log máy chủ.
Con số hiện ra là thứ khác hẳn. Trong 14 ngày đầu tháng 8/2026, Googlebot lấy về trung bình 8 trang HTML mỗi ngày. Cùng khoảng thời gian đó, sitemap của site phình thêm 27 địa chỉ mỗi ngày. Không có bài viết nào đủ hay để lấp được khoảng cách 19 trang mỗi ngày đó.
Đếm ở đâu mới ra số đúng
Trước khi tin bất kỳ con số nào ở trên, phải nói rõ nó lấy từ đâu, vì chỗ này có một cái bẫy đã làm chúng tôi mất một buổi.
Chỗ ai cũng nghĩ tới đầu tiên là /var/log/nginx/access.log. Trên máy chủ này nó vô dụng: nginx đang phục vụ 13 tên miền khác nhau, tất cả ghi chung vào một file, và định dạng log mặc định không có trường host. Nghĩa là nhìn một dòng log bạn biết ai vào, vào lúc nào, vào đường dẫn nào — nhưng không biết vào site nào. Mọi phép đếm từ file đó đều là gộp của 13 site.
Chỗ đếm đúng là log của riêng container WordPress:
$ docker inspect --format='{{.LogPath}}' mna_wp
/var/lib/docker/containers/50ac37c8.../50ac37c8...-json.logContainer này chỉ phục vụ một site, nên mọi dòng trong đó đều là của marketing365.vn. Nhớ đọc cả các file .log.1.gz, .log.2.gz bên cạnh — Docker xoay log và nén lại, nếu chỉ mở file hiện hành thì bạn chỉ thấy đúng ngày hôm nay. Lần đầu chúng tôi bỏ sót đúng chỗ này và ra kết quả “cửa sổ đo: 1 ngày”.
Việc thứ hai là lọc cho ra Googlebot thật. Trường User-Agent ai cũng giả được, và có kha khá công cụ quét tự xưng là Googlebot. Cách chắc chắn là lọc theo dải địa chỉ IP Google công bố, ở đây là 66.249.*. Toàn bộ số liệu trong bài này chỉ tính request đến từ dải đó.
Bốn phần năm ngân sách bò không đi vào bài viết
Đếm toàn bộ cửa sổ log còn giữ được — 09/06 đến 14/08/2026, tức 50 ngày có dữ liệu, đứt đoạn 25/06–11/07 do vòng xoay log — Googlebot gửi 3.851 request. Nhưng “request” và “trang được đọc” là hai chuyện khác nhau.
Chỉ 688 request, tức 17,9%, là trang HTML. Phần còn lại: 1.653 request cho CSS, JS và font (42,9%), 965 request cho ảnh (25,1%), 195 cho sitemap, 143 cho wp-json, 136 cho robots.txt với llms.txt, 71 cho feed RSS.
Đây không phải lỗi của Google. Googlebot phải tải CSS và JS để dựng trang mà nó đang đọc — đó là cách nó nhìn thấy trang giống người dùng. Nhưng nó có nghĩa là mỗi bài viết bạn muốn được index đều kéo theo một chùm request phụ, và chùm đó ăn vào cùng một ngân sách. Site càng nhiều tài nguyên rời rạc thì phần dành cho nội dung càng mỏng.
Nhìn theo hướng này thì việc cắt file CSS của theme từ 1,2 MB xuống 243 KB có thêm một lợi ích mà lúc làm chúng tôi không nghĩ tới: nó không chỉ nhanh hơn cho khách, nó còn bớt một phần chi phí mỗi lần Googlebot ghé.
Tốc độ bò đang giảm chứ không tăng
Phần khó chịu nhất nằm ở xu hướng. Số trang HTML lấy về mỗi ngày trong nửa đầu tháng 8:
01/08 20 06/08 5 11/08 4
02/08 6 07/08 10 12/08 5
03/08 22 08/08 8 13/08 5
04/08 7 09/08 4 14/08 3
05/08 12 10/08 1Bảy ngày đầu trung bình 11,7 trang/ngày. Bảy ngày sau trung bình 4,3. Trong khi đó tốc độ xuất bản không hề giảm — sitemap ngày 13/08 có 1.652 địa chỉ, ngày 14/08 có 1.679.
Google không công bố lý do phân bổ ngân sách bò, nên chúng tôi không đoán. Cái nói được chắc chắn là hệ quả số học: nếu bò 4 trang/ngày mà thêm 27 trang/ngày, thì kho trang chưa được đọc lần nào sẽ dài ra mỗi ngày 23 trang, mãi mãi, bất kể nội dung viết hay đến đâu.
Đây cũng là lý do trạng thái “Đã phát hiện – hiện chưa được lập chỉ mục” trong Search Console cứ tăng: 518 trang ở trạng thái đó. Google biết những địa chỉ này tồn tại, nó đọc sitemap đều đặn (195 request cho sitemap là bằng chứng), nó chỉ chưa xếp được lịch tới lấy về.
Chờ đợi không phải là một chiến lược
Với tốc độ 4–8 trang/ngày, để bò hết hơn một nghìn trang chưa từng được đọc cần khoảng 4 đến 8 tháng, giả sử trong suốt thời gian đó không đăng thêm bài nào. Mà site vẫn đăng đều 27 trang mỗi ngày. Nói cách khác: chờ tự nhiên là phương án không bao giờ về đích.
Ba hướng còn lại, xếp theo thứ tự chúng tôi đang làm:
- Đẩy chủ động qua Indexing API. Đây là hướng duy nhất tác động thẳng vào tốc độ, không phải chờ Google tự xếp lịch. Hạn mức 200 địa chỉ mỗi ngày, gấp 25 lần tốc độ bò tự nhiên hiện tại. Phần triển khai và số đo thực tế nằm ở bài riêng.
- Giảm phần ngân sách bị tài nguyên phụ ăn mất. Bớt file CSS, bớt font, gộp tài nguyên. Mỗi request tiết kiệm được là một chỗ trống cho một trang HTML.
- Xem lại tốc độ xuất bản. Đăng 27 trang mỗi ngày vào một site mà Google chỉ đọc được 8 trang thì phần thừa không biến mất, nó xếp hàng. Nếu hàng đợi đã dài hơn 1.000 trang, thêm bài mới không giúp gì cho hôm nay.
Cách tự kiểm tra trên site của bạn
Nếu Search Console của bạn cũng đang báo một đống trang “đã phát hiện nhưng chưa index”, ba việc này làm trong nửa tiếng và cho biết bạn đang ở tình huống nào:
Một. Đếm số địa chỉ trong sitemap hôm nay, ghi lại. Ngày mai đếm lại. Hiệu số là tốc độ xuất bản thật của bạn, thường lớn hơn con số bạn tưởng vì có cả trang chuyên mục, trang phân trang và bản dịch.
Hai. Tìm file log ghi riêng cho site đó — không phải log gộp của cả máy chủ — rồi đếm số dòng có IP bắt đầu bằng 66.249. và đường dẫn không phải ảnh, CSS, JS, sitemap hay feed. Chia cho số ngày.
Ba. So hai con số. Nếu tốc độ bò lớn hơn tốc độ xuất bản, vấn đề của bạn nằm ở chất lượng trang chứ không phải ở ngân sách bò — lúc đó mới quay lại chuyện nội dung. Nếu ngược lại như trường hợp này, viết thêm bài không giải quyết được gì. Phần nền về cách đọc các báo cáo trong Search Console thì đã có bài cách dùng Google Search Console cho người mới.
Số liệu trong bài này là của một site cụ thể, ở một thời điểm cụ thể, đo bằng một cách cụ thể. Site của bạn gần như chắc chắn ra số khác. Cái đáng mang đi là phép so: tốc độ vào so với tốc độ ra, đo bằng log của chính mình.
