Ngày 6/10/2026, Google cập nhật tài liệu crawl rate (tốc độ Googlebot thu thập dữ liệu trên website của bạn), bổ sung hướng dẫn dùng Retry-After HTTP header vào mục xử lý khẩn cấp. Cơ chế này không phải mới, nhưng đưa vào mục khẩn cấp giúp dễ tìm hơn: kèm mã lỗi báo quá tải, bạn có thể cho crawler của Google biết khi nào được thử lại.
Google thay đổi gì trong tài liệu crawl rate?
Theo Search Engine Roundtable (6/10/2026), Google tái cơ cấu mục giảm crawl rate khẩn cấp và bổ sung thông tin cùng ví dụ code về Retry-After HTTP header. Google giải thích: “Support for the Retry-After HTTP header is not new (it was already documented in Temporarily pause or disable a website), and adding it directly to the crawl rate reduction guide makes it easier to find and understand when urgently reducing crawler traffic.”
So sánh tài liệu hiện tại với phiên bản lưu trữ, Search Engine Roundtable ghi nhận phần lớn thay đổi là sắp xếp lại nội dung, không phải tính năng hoàn toàn mới.
Header Retry-After hoạt động ra sao với phản hồi 503 và 429?
Khi server trả về mã trạng thái 503 (Service Unavailable) hoặc 429 (Too Many Requests), bạn có thể kèm Retry-After HTTP header (theo chuẩn RFC 9110 HTTP Semantics, tiêu chuẩn kỹ thuật quy định hành vi phản hồi HTTP) để chỉ định thời điểm Googlebot thử lại. Theo tài liệu Google mới cập nhật, có hai định dạng được hỗ trợ:
- Độ trễ theo giây:
Retry-After: 120cho biết crawler có thể thử lại sau 120 giây. - Ngày giờ UTC tuyệt đối:
Retry-After: Wed, 21 Oct 2026 07:28:00 GMTnêu thời điểm thử lại cụ thể.
Tài liệu Google cũng lưu ý: trả về 500, 503 hoặc 429 ảnh hưởng đến toàn bộ hostname (ví dụ: subdomain.example.com), làm giảm crawl rate trên tất cả URL của subdomain đó, không chỉ riêng những URL đang báo lỗi. Crawl rate tự phục hồi khi số lỗi giảm xuống.
Điều gì khiến Googlebot đột ngột crawl dồn dập?
Tài liệu Google xác định hai nguyên nhân phổ biến cần kiểm tra trước khi áp dụng biện pháp khẩn cấp:
- Faceted navigation (chức năng lọc và sắp xếp tạo ra nhiều tổ hợp URL).
- URL theo lịch: một trang lịch có rất nhiều URL cho từng ngày cụ thể.
Google khuyến nghị kiểm tra server access log với nhà cung cấp hosting trước để xác định nguồn gốc của traffic spike (đột biến lưu lượng). Nếu hạ tầng không cho phép trả về mã lỗi, tài liệu Google có một hướng khác: gửi yêu cầu đặc biệt để báo cáo crawl rate bất thường, kèm tốc độ mong muốn. Quá trình này có thể mất vài ngày để được xem xét. Yêu cầu tăng crawl rate không được tiếp nhận qua kênh này.
Ý nghĩa với khả năng hiển thị trên AI search
Header Retry-After là thay đổi tài liệu nhỏ, nhưng nó lấp một khoảng trống quan trọng khi mọi thứ đi sai. Rủi ro thực sự với các thương hiệu đang muốn được AI search gợi ý không phải là sự cố quá tải, mà là khoảng trống lập chỉ mục (indexing gap) xảy ra ngay sau đó.
Hình dung thế này: site của bạn sập hai tiếng, Googlebot nhận 503 liên tục nhưng không có Retry-After. Crawler sẽ giảm tốc và chỉ tự tăng lại khi số lỗi giảm. Những trang vừa cập nhật nội dung có thể chưa được crawl lại kịp. Với nội dung phụ thuộc độ tươi mới (bài tin tức, trang sản phẩm, knowledge base), khoảng trống đó đủ để AI tổng hợp câu trả lời từ thông tin cũ, hoặc ưu tiên trang đối thủ vừa được lập chỉ mục gần hơn.
Khi bạn đặt Retry-After, ví dụ hai tiếng kể từ lúc này, crawler của Google nhận được tín hiệu rõ ràng về thời điểm thử lại, thay vì để thuật toán backoff tự quyết hoàn toàn.
Một lưu ý cần ghi nhớ: hướng dẫn này áp dụng riêng cho Googlebot (crawler tìm kiếm và lập chỉ mục của Google). Những site quản lý quyền truy cập crawler cho nhiều hệ thống AI không nên giả định một header này bao phủ toàn bộ bot traffic.
Góc nhìn Hingewise
Header Retry-After là loại cấu hình bạn nên làm trước khi cần, không phải trong lúc server đang sập.
Phần lớn sự cố kỹ thuật không kéo dài, nhưng khoảng trống lập chỉ mục có thể. Nếu Googlebot lỡ cửa sổ tái crawl sau sự cố, bạn không chỉ chậm một bước trong kết quả tìm kiếm thông thường. Với AI Overviews (bảng trả lời do AI của Google tổng hợp trên trang kết quả) và các tính năng AI search tương tự, nếu trang đối thủ được crawl trong khi trang của bạn vẫn đang “im lặng” vì sự cố, lợi thế hiển thị có thể nghiêng về phía họ cho đến lần crawl tiếp theo của bạn. Đây là dạng thiệt hại khó thấy ngay nhưng tích lũy theo thời gian.
Theo nhận định của Hingewise: chi phí cấu hình Retry-After gần như bằng không, trong khi giá trị của nó tích lũy qua từng sự cố. Với các site mà độ tươi mới của nội dung ảnh hưởng trực tiếp đến khả năng được AI trích dẫn, đây là biện pháp phòng thủ đáng được ưu tiên cao hơn mức chú ý mà nó thường nhận được.
Checklist trước khi server gặp sự cố tiếp theo
- Xác nhận server hoặc CDN (mạng phân phối nội dung, lớp hạ tầng phục vụ trang web đến người dùng toàn cầu) có thể gửi custom response header kèm mã 503 và 429.
- Chọn định dạng phù hợp: độ trễ theo giây (đơn giản hơn, khi không biết chính xác thời điểm phục hồi) hay UTC timestamp tuyệt đối (chính xác hơn, phù hợp cho bảo trì theo lịch).
- Kiểm tra header có thực sự được gửi đi bằng cách xem response header trong DevTools trên trình duyệt hoặc dùng công cụ dòng lệnh như curl.
- Xem lại server log để nắm các pattern 500/503/429 hiện tại, biết mức ảnh hưởng cơ bản trước khi sự cố xảy ra.
- Kiểm tra xem faceted navigation hay URL theo lịch có đang tạo ra khối lượng URL bất ngờ không, trước khi quy crawl spike cho vấn đề tải.
- Nếu bạn quản lý nhiều subdomain, lưu ý phản hồi lỗi làm giảm crawl rate trên toàn bộ hostname. Một subdomain staging cấu hình sai có thể ảnh hưởng đến crawl budget của môi trường production.
Google chưa báo hiệu thêm thay đổi nào trong tài liệu crawl rate. Hành vi của 500, 503 và 429 như tín hiệu giảm crawl vẫn không đổi. Điều thay đổi là site owner nay có hướng dẫn rõ ràng, tập trung hơn để dùng Retry-After như một tín hiệu bổ sung khi cần độ chính xác trong sự cố.
Nguồn: Search Engine Roundtable (6/10/2026); Google Crawling Infrastructure documentation.
Bài viết được soạn với sự hỗ trợ của AI từ các nguồn dẫn ở trên và đối chiếu với các nguồn đó trước khi đăng. "Góc nhìn Hingewise" là nhận định biên tập của Hingewise, dựa trên khung phân tích và lập trường chúng tôi dùng trong công việc GEO. Cách chúng tôi làm việc: Chính sách biên tập.