429 Quá nhiều yêu cầu

Tóm tắt — 429 Too Many Requests nghĩa là máy chủ nói với khách truy cập hoặc bot: “bạn đang yêu cầu quá nhiều trang quá nhanh — hãy chậm lại”. Cơ chế đó gọi là giới hạn tốc độ. Tin tốt cho SEO là 429 là lỗi duy nhất trong nhóm được Google xử lý nhẹ nhàng. Thay vì loại trang, Googlebot chỉ giảm tốc và crawl chậm hơn một thời gian. Mã chỉ thành vấn đề nếu máy chủ tiếp tục trả 429 nhiều ngày liền.

429 thực sự nói gì

Mỗi khi trình duyệt, script hoặc crawler công cụ tìm kiếm yêu cầu một trang, máy chủ trả lời bằng mã trạng thái. 200 nghĩa là “trang đây”. 429 nghĩa là “bạn đã gửi quá nhiều yêu cầu trong một khoảng ngắn, nên tôi không trả lời lần này — hãy quay lại sau”.

Máy chủ cố ý dùng 429 để tự bảo vệ. Nếu một khách truy cập hoặc bot gửi yêu cầu dồn dập đến mức làm site chậm với mọi người, trả 429 là cách máy chủ nói hãy dừng một lúc. Phản hồi 429 đúng chuẩn thực hành còn có header Retry-After, cho client biết cần đợi bao nhiêu giây trước khi thử lại. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

Vì sao 429 là lỗi “dễ chịu” với SEO

Đây là phần khiến nhiều người bất ngờ. 429 thuộc nhóm “lỗi client 4xx”, ngay cạnh 403 Forbidden và 404 Not Found. Nếu Google liên tục thấy hai mã đó, đây là tin xấu: cuối cùng Google loại các trang khỏi tìm kiếm.

429 là ngoại lệ. Google đọc 429 là máy chủ đang bận, hãy chậm lại, giống cách đọc lỗi máy chủ 503 hoặc 500. Vì vậy, thay vì loại trang, Googlebot chỉ crawl site chậm hơn một thời gian. Google thực sự khuyến nghị 429 là cách đúng để làm crawler chậm lại và cảnh báo rõ không dùng 403 hay 404 cho việc đó. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Khi nào 429 trở thành vấn đề

Thỉnh thoảng có 429 là hoàn toàn bình thường và tự phục hồi; khi máy chủ ngừng trả mã, Google tự tăng tốc crawl trở lại. Bạn không cần yêu cầu.

Nguy hiểm xuất hiện khi 429 kéo dài. Nếu Googlebot tiếp tục gặp 429 trên cùng các trang trong hơn một hoặc hai ngày, Google có thể bắt đầu loại chúng khỏi chỉ mục vì từ phía Google, site có vẻ hỏng và không khả dụng nhiều ngày. Vì vậy 429 là công cụ ngắn hạn, không phải thiết lập vĩnh viễn.

Bạn nên xử lý thế nào

• Nếu bạn không chủ ý gửi 429 — mã bất ngờ xuất hiện trong Google Search Console hoặc công cụ crawl — một thành phần đang giới hạn tốc độ quá gắt, thường là plugin bảo mật, tường lửa WAF hoặc dịch vụ hosting/CDN. Hãy tìm và nới giới hạn để ngừng chặn công cụ tìm kiếm thật.
• Nếu bạn chủ ý gửi mã vì máy chủ đang chịu tải nặng, điều đó ổn; chỉ cần giới hạn thời gian và thêm header Retry-After. Hãy tắt trong một hoặc hai ngày.

Muốn xem cách cấu hình máy chủ, câu chữ chính xác của Google và các quan niệm sai phổ biến? Hãy chuyển sang thẻ Nâng cao.

Tóm tắt — 429 là mã 4xx duy nhất Google xử lý như 5xx: khi gặp số lượng đáng kể phản hồi 500/503/429, Google coi đó là tín hiệu máy chủ quá tải và giảm tốc độ crawl của Googlebot trên toàn hostname thay vì loại nội dung. Đây là mã duy nhất Google tán thành để làm crawler chậm lại — tuyệt đối không dùng 403 hay 404. Tài liệu Google hướng dẫn dùng khẩn cấp trong “vài giờ hoặc 1–2 ngày”; đây không phải cửa sổ an toàn được bảo đảm. 429 kéo dài trên cùng URL có nguy cơ khiến URL cuối cùng bị loại khỏi chỉ mục, còn tốc độ crawl bắt đầu tăng lại — không nhất thiết tức thì hay phục hồi hoàn toàn — khi lượng lỗi giảm. RFC 6585 nói phản hồi 429 NÊN giải thích tình trạng và CÓ THỂ gồm Retry-After; gửi header là thực hành khuyến nghị, không phải yêu cầu tuân thủ. Hãy giới hạn đúng lưu lượng và xác minh danh tính crawler trước khi tạo ngoại lệ.

429 ở cấp giao thức

Theo cách MDN diễn đạt trực tiếp từ đặc tả: “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (bản dịch) «Mã trạng thái phản hồi lỗi client HTTP 429 Too Many Requests cho biết client đã gửi quá nhiều yêu cầu trong một khoảng thời gian. Cơ chế yêu cầu client giảm tốc độ gửi yêu cầu thường được gọi là giới hạn tốc độ.» Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

RFC 6585 §4 chính xác hơn phần lớn bản tóm tắt. Nội dung phản hồi 429 NÊN giải thích tình trạng và CÓ THỂ gồm header Retry-After, cho client biết số giây cụ thể cần đợi trước khi thử lại; RFC 9110 cũng cho phép ngày HTTP. Retry-After là thực hành khuyến nghị, không phải yêu cầu tuân thủ. Đặc tả cũng không quy định cách nhận diện client hay cách đếm yêu cầu; toàn bộ do thành phần phát phản hồi quyết định, như theo IP, phiên, khóa API hay tài nguyên. Một quy tắc dễ bỏ sót: RFC 6585 nói phản hồi 429 không được lưu trong cache. Nếu thấy 429 có vẻ được cache hoặc phát lại khi origin khỏe, đó là lỗi của thành phần trung gian như CDN hay proxy, không phải origin vừa quyết định giới hạn lại.

Tôi luôn diễn đạt đơn giản trong hướng dẫn Mã trạng thái HTTP và tác động SEO: 429 là “a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.” (bản dịch) «một hình thức giới hạn tốc độ để bảo vệ máy chủ vì client gửi quá nhiều yêu cầu quá nhanh.» Theo danh nghĩa, đây là lỗi client vì client đã yêu cầu quá nhiều. Nhưng chính cách nhìn đó là nơi câu chuyện SEO tách khỏi đặc tả.

Ngoại lệ duy nhất trong nhóm 4xx

Sự thật quan trọng nhất của bài này: Google không xử lý 429 như phần còn lại của nhóm 4xx. Gary Illyes viết cả một bài Google Search Central về chủ đề này vào tháng 2 năm 2023 vì nhiều site và CDN dùng sai 404 để làm Googlebot chậm lại đến mức Google phải yêu cầu họ dừng.

Quy tắc của ông: 429 là ngoại lệ “too many requests” (bản dịch) «quá nhiều yêu cầu», tín hiệu rõ ràng để robot tuân thủ như Googlebot chậm lại khi làm máy chủ quá tải. Mặt ngược lại trong tài liệu mã trạng thái của Google: “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (bản dịch) «Đừng dùng mã 401 và 403 để giới hạn tốc độ crawl. Mã 4xx, trừ 429, không ảnh hưởng tốc độ crawl.»

Vì vậy, trong khi 403 và 404 khiến nội dung bị loại khỏi Search, 429 tạo ra tình trạng giảm tốc tạm thời. Google thực sự gom mã này với lỗi máy chủ: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (bản dịch) «Crawler Google coi 429 là tín hiệu máy chủ quá tải và xem đó là lỗi máy chủ.» Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Điều này khiến 429 trở thành họ hàng hữu ích của 503 Service Unavailable, tín hiệu bảo trì hoặc tạm không khả dụng truyền thống, và đối lập hoàn toàn với 403 Forbidden, công cụ sai cho giới hạn tốc độ dù nhiều tường lửa dùng mặc định.

Tác động tốc độ crawl ở toàn hostname — khi vượt ngưỡng

Hai phạm vi khác nhau thường bị đánh đồng. Cách bạn đếm và đặt khóa giới hạn — theo IP, phiên, khóa API, tài nguyên hay máy chủ — là chính sách riêng; đặc tả HTTP không quy định. Cách Google xử lý lỗi mà họ quan sát là hành vi riêng đã được ghi nhận và phụ thuộc vào lượng lỗi, không phải một phản hồi: “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (bản dịch) «Hạ tầng crawl của Google giảm tốc độ crawl site khi gặp số lượng đáng kể URL trả 500, 503 hoặc 429.» Khi vượt ngưỡng, “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (bản dịch) «Tốc độ giảm ảnh hưởng toàn hostname, cả URL trả lỗi lẫn URL trả nội dung.»

Nói cách khác, nếu bạn trả 429 cho một nhóm trang, chẳng hạn đường dẫn API nặng, với lượng đủ lớn, Googlebot giảm crawl trên toàn bộ hostname, gồm cả trang vẫn trả 200. Đây thường là hiệu ứng mong muốn khi mục tiêu là giảm tổng tải. Nhưng riêng một 429 cô lập trên một đường dẫn không chứng minh hiệu ứng toàn hostname; câu chữ của Google giới hạn vào “số lượng đáng kể” phản hồi lỗi, không phải bất kỳ phản hồi đơn lẻ nào.

Hướng dẫn 1–2 ngày — lúc 429 trở nên rủi ro

429 là tín hiệu ngắn hạn, và Google đưa ra hướng dẫn dùng khẩn cấp cụ thể chứ không phải cửa sổ an toàn hay ngưỡng cứng: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (bản dịch) «Nếu cần khẩn cấp giảm tốc độ crawl trong thời gian ngắn, như vài giờ hoặc 1–2 ngày, hãy trả 500, 503 hoặc 429 thay vì 200 cho yêu cầu crawl.»

Kéo dài hơn sẽ vào vùng rủi ro, dù Google mô tả là khả năng chứ không phải lời hứa: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (bản dịch) «Chúng tôi không khuyến nghị làm việc này lâu hơn 1–2 ngày vì có thể ảnh hưởng tiêu cực đến cách site xuất hiện trong sản phẩm Google; nếu Googlebot thấy các mã này trên cùng URL nhiều ngày, URL có thể bị loại khỏi chỉ mục.» Tài liệu mã trạng thái nói tương tự cho 5xx và 429: “already indexed URLs are preserved in the index, but eventually dropped.” (bản dịch) «URL đã lập chỉ mục được giữ lại, nhưng cuối cùng sẽ bị loại.»

Mô hình rủi ro trung thực là: 429 ngắn hạn phù hợp cửa sổ Google khuyến nghị cho dùng khẩn cấp; 429 kéo dài trên cùng URL nhiều ngày là lúc ngôn ngữ của Google chuyển sang “có thể” và “cuối cùng bị loại” — rủi ro có tài liệu, không phải kết quả được bảo đảm theo hướng nào. Cơ chế giống 503 kéo dài.

Tốc độ crawl tự phục hồi

Mặt tích cực là không có cờ phạt nào bám theo site. Khi lỗi giảm, Google nói “the crawl rate will automatically start increasing again.” (bản dịch) «tốc độ crawl sẽ tự động bắt đầu tăng lại.» Bạn không cần nộp hay yêu cầu lại gì. Nhưng lưu ý câu chữ chính xác: Google nói “bắt đầu tăng”, không nói “instantly returns to your prior rate.” (bản dịch) «lập tức trở lại tốc độ trước». Hãy coi đây là hướng phục hồi được ghi nhận, không có lịch cố định hay đích được bảo đảm, chứ không phải SLA.

Đối chiếu với vấn đề ngược lại — muốn Google vĩnh viễn crawl ít hơn. Nếu không thể phục vụ lỗi, Google nói hãy “file a special request to report a problem with unusually high crawl rate” (bản dịch) «gửi yêu cầu đặc biệt để báo vấn đề tốc độ crawl cao bất thường»; đây là quy trình thủ công có thể mất nhiều ngày và không được bảo đảm. Phục hồi không có trở ngại đó.

Bing xử lý 429 thế nào

Nhiều nguồn trong ngành báo cáo Bingbot hành xử tương tự, lùi lại khi thấy 429/500/503 báo quá tải, nhưng trong lượt nghiên cứu này tôi không thể xác nhận độc lập câu chữ hiện hành trên trang trợ giúp Bing vì đó là SPA render bằng JavaScript không cung cấp văn bản tĩnh có thể fetch. Hãy coi nhận định tương đồng là thông tin ngành, không phải điều tôi đã xác minh với tài liệu Bing hiện hành. Điều Bing xác nhận trong hướng dẫn lịch sử là hai cơ chế chủ động mà Google không cung cấp cùng hình thức:

• Crawl Control trong Bing Webmaster Tools, lưới số yêu cầu mỗi giây cho phép đặt tốc độ Bingbot theo giờ trong ngày.
• Chỉ thị crawl-delay trong robots.txt. Hướng dẫn Bing Webmaster hiện hành ghi nhận giá trị 1–20 giây. Đây là tính năng riêng của Bing; nó không làm Googlebot chậm lại.

Vì vậy với Bing, bạn có thể chủ động điều tiết bằng crawl-delay hoặc Crawl Control thay vì phản ứng bằng mã trạng thái. Google đã ngừng thanh trượt tốc độ crawl thủ công năm 2024 và hiện dựa hoàn toàn vào phản hồi máy chủ.

Khi nào nên chủ ý gửi 429

Các lý do hợp lệ để chủ ý trả 429:

• Tải máy chủ khẩn cấp — lưu lượng tăng đột biến, di chuyển lỗi hoặc sự cố khiến bạn cần Googlebot giảm tải ngay trong vài giờ.
• Bảo vệ API và endpoint không phải HTML khỏi lạm dụng crawler/bot — crawler công cụ tìm kiếm, crawler SEO bên thứ ba như Ahrefs hay Screaming Frog và scraper đều có thể chạm giới hạn chống lạm dụng.

429 không dùng để chặn vĩnh viễn bot bạn không muốn. Nếu không bao giờ muốn nội dung được crawl, hãy dùng disallow trong robots.txt, không phải 429. Nếu muốn giữ trang nhưng loại khỏi chỉ mục, dùng noindex. 429 chỉ nghĩa là “sau”, không phải “không bao giờ”.

429 ngoài ý muốn — thủ phạm thường gặp

Khi 429 xuất hiện trong báo cáo Page Indexing hay Crawl Stats của GSC mà bạn không đặt, nguồn thường là một trong các thành phần sau. Tôi không biết bằng chứng tốt cho thứ hạng phổ biến toàn cầu, nên hãy coi đây là danh sách ứng viên cần xác nhận hoặc loại trừ, không phải chẩn đoán:

• Rule WAF / tường lửa kích hoạt nhầm trên dải IP crawler hợp lệ.
• Giới hạn tốc độ mặc định của hosting dùng chung hoặc CDN quá chặt cho một lần crawl thật.
• Công cụ quản lý bot phân loại nhầm Googlebot hoặc Bingbot là lưu lượng lạm dụng.
• Middleware giới hạn tốc độ quá gắt dành cho chống lạm dụng API nhưng bắt cả crawler của chính bạn.

Trước khi đổi ngưỡng hoặc viết rule miễn trừ bot tìm kiếm thật, hãy xác lập nguồn gốc; đừng đoán tầng nào sở hữu phản hồi. Lấy header phản hồi thô, dòng log yêu cầu chính xác chứ không phải tóm tắt dashboard, mã rule hoặc vùng giới hạn đã kích hoạt, khóa client được đếm theo IP/phiên/khóa API, route, POP CDN hoặc vị trí edge và cửa sổ thời gian. Tổ hợp đó cho biết tầng nào thực sự phát 429 và đang đếm gì; chỉ lúc đó mới hợp lý để nới giới hạn hoặc thêm ngoại lệ. Xác minh danh tính crawler bằng DNS ngược rồi DNS xuôi theo phương pháp chính thức của Google, không chỉ dựa vào chuỗi user-agent vì “Googlebot” giả rất phổ biến. Thẻ Scripts có lệnh chính xác.

Phiên bản ngắn của playbook

1. Dùng 429 hoặc 503 kèm Retry-After để làm crawler chậm lại — không bao giờ dùng 403 hay 404.
2. Giới hạn trong vài giờ hoặc 1–2 ngày; kéo dài hơn có thể khiến URL bị loại.
3. Nhớ rằng điều tiết áp dụng trên toàn hostname và tự phục hồi khi lỗi dừng.
4. Giới hạn phạm vi đúng lưu lượng và xác minh danh tính crawler trước khi miễn trừ bot.

Tóm tắt cho AI

Bản cô đọng của phần Nâng cao:

• 429 Too Many Requests = máy chủ báo client như trình duyệt, script hoặc crawler đã gửi quá nhiều yêu cầu quá nhanh, tức “giới hạn tốc độ”. Theo danh nghĩa đây là lỗi client 4xx.
• Cấp giao thức: RFC 6585 nói phản hồi 429 NÊN giải thích tình trạng và CÓ THỂ gồm Retry-After; đây là khuyến nghị, không bắt buộc. Phản hồi cũng KHÔNG ĐƯỢC lưu cache; 429 bị cache/phát lại là lỗi trung gian, không phải origin. Cách đếm hoặc đặt khóa giới hạn theo IP, phiên, khóa API hay tài nguyên là chính sách của bạn; đặc tả không quy định.
• Ngoại lệ 4xx duy nhất: Google xử lý 429 như lỗi máy chủ 5xx, không như 403/404. Google đọc mã là “server overloaded, slow down” (bản dịch) «máy chủ quá tải, hãy chậm lại» và điều tiết tốc độ crawl thay vì loại nội dung.
• Google tán thành 429 cùng 500/503 để làm crawler chậm lại — không bao giờ dùng 403 hay 404. Gary Illyes viết riêng bài năm 2023 yêu cầu site/CDN ngừng dùng 404 để điều tiết Googlebot.
• Điều tiết áp dụng toàn hostname khi vượt ngưỡng: câu chữ Google điều kiện hóa hiệu ứng toàn hostname vào việc gặp “số lượng đáng kể” phản hồi 500/503/429, không phải một 429. Khi vượt ngưỡng, trang vẫn phục vụ 200 cũng được crawl ít hơn.
• Hướng dẫn 1–2 ngày, không phải ngưỡng cứng: tài liệu Google hướng dẫn dùng khẩn cấp trong “vài giờ hoặc 1–2 ngày”. 429 kéo dài trên cùng URL nhiều ngày có nguy cơ khiến URL cuối cùng bị loại khỏi chỉ mục — “có thể” và “cuối cùng”, không phải bảo đảm — tương tự 503 kéo dài.
• Phục hồi có hướng, không tức thì: ngừng gửi 429 và Google nói tốc độ crawl “bắt đầu tăng lại”; không cần yêu cầu lại, không có hình phạt kéo dài, nhưng cũng không hứa tốc độ được khôi phục ngay hoặc đầy đủ theo lịch cố định.
• Client thử lại: tôn trọng Retry-After hợp lệ khi có. Khi không có, RFC không quy định công thức; dùng chính sách backoff có jitter và giới hạn, chặn số lần thử và kiểm tra tính idempotent trước khi lặp yêu cầu không idempotent.
• Giới hạn đúng lưu lượng và xác minh danh tính crawler bằng DNS ngược + xuôi trước khi miễn trừ bot.
• Bing được nhiều nguồn báo cáo là cũng lùi lại trước 429, dù nhận định tương đồng chưa được xác nhận độc lập với tài liệu Bing hiện hành trong lượt này; hướng dẫn lịch sử của Bing xác nhận crawl-delay và lưới Crawl Control là lựa chọn chủ động.
• 429 không phải chặn: mã nghĩa là “sau”, không phải “không bao giờ”. Dùng robots.txt để ngăn bot và noindex để loại trang.

Tài liệu chính thức

Tài liệu nguồn sơ cấp từ công cụ tìm kiếm và đặc tả HTTP.

Google

• Đừng dùng 403 hay 404 để giới hạn tốc độ — bài tháng 2 năm 2023 của Gary Illyes; phát biểu chuẩn rằng 429 là ngoại lệ còn 403/404 là công cụ sai.
• Giảm tốc độ crawl của Google — hướng dẫn “trả 500, 503 hoặc 429”, cửa sổ 1–2 ngày, điều tiết toàn hostname và tự phục hồi.
• Mã trạng thái HTTP, lỗi mạng và DNS — cách Google xử lý từng mã; 429 được gom với lỗi máy chủ, cũng có ở đường dẫn cũ search/docs/crawling-indexing/http-network-errors.
• Giảm tốc độ crawl của Google — quy trình yêu cầu đặc biệt — quy trình thủ công “báo vấn đề tốc độ crawl cao bất thường” khi không thể phục vụ lỗi.

Bing / Microsoft

• Crawl Control — lịch yêu cầu mỗi giây của Bingbot trong Bing Webmaster Tools.
• Hướng dẫn Bingbot — hướng dẫn Bing Webmaster hiện hành cho crawl-delay từ 1–20 giây.

Đặc tả HTTP

• MDN — 429 Too Many Requests — định nghĩa giao thức, Retry-After và kiến thức cơ bản về giới hạn tốc độ.

Trích dẫn từ nguồn

Phát biểu được ghi nhận từ Google, Bing và đặc tả HTTP. Mỗi liên kết dẫn sâu đến đoạn được trích trên trang nguồn.

Google — Gary Illyes, “Đừng dùng 403 hay 404 để giới hạn tốc độ” (tháng 2 năm 2023)

• “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate.” (bản dịch) «Trong vài tháng qua, chúng tôi nhận thấy ngày càng nhiều chủ site và một số CDN cố dùng 404 cùng lỗi client 4xx khác, nhưng không phải 429, để giảm tốc độ crawl của Googlebot.» Đi đến trích dẫn
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (bản dịch) «Ngoại lệ duy nhất là 429, nghĩa là ‘quá nhiều yêu cầu’. Lỗi này báo rõ cho mọi robot tuân thủ, gồm Googlebot, rằng nó cần chậm lại vì đang làm máy chủ quá tải.» Đi đến trích dẫn
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (bản dịch) «Mọi mã trạng thái HTTP 4xx, một lần nữa trừ 429, sẽ khiến nội dung bị loại khỏi Google Search.» Đi đến trích dẫn
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (bản dịch) «Dùng Search Console để tạm giảm tốc độ crawl. Trả mã HTTP 500, 503 hoặc 429 cho Googlebot khi nó crawl quá nhanh.» Đi đến trích dẫn

Google — Giảm tốc độ crawl / tài liệu mã trạng thái

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (bản dịch) «Nếu cần khẩn cấp giảm tốc độ crawl trong thời gian ngắn, như vài giờ hoặc 1–2 ngày, hãy trả 500, 503 hoặc 429 thay vì 200 cho yêu cầu crawl.» Đi đến trích dẫn
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (bản dịch) «Tốc độ crawl giảm ảnh hưởng toàn hostname của site… Khi số lỗi giảm, tốc độ crawl sẽ tự động bắt đầu tăng lại.» Đi đến trích dẫn
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (bản dịch) «Chúng tôi không khuyến nghị làm việc này lâu hơn 1–2 ngày… URL có thể bị loại khỏi chỉ mục Google.» Đi đến trích dẫn
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (bản dịch) «Crawler Google coi 429 là tín hiệu máy chủ quá tải và xem đó là lỗi máy chủ.» Đi đến trích dẫn
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (bản dịch) «Đừng dùng 401 và 403 để giới hạn tốc độ crawl. Mã 4xx, trừ 429, không ảnh hưởng tốc độ crawl.» Đi đến trích dẫn

MDN — định nghĩa giao thức

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (bản dịch) «Mã phản hồi lỗi client HTTP 429 Too Many Requests cho biết client gửi quá nhiều yêu cầu trong một khoảng thời gian. Cơ chế yêu cầu client giảm tốc độ gửi thường gọi là giới hạn tốc độ.» Đi đến trích dẫn

Bing — hướng dẫn Webmaster hiện hành

• Hướng dẫn Bingbot ghi nhận giá trị crawl-delay từ 1–20 giây. Hãy coi đây là hướng dẫn riêng của Bing, không phải cơ chế điều tiết crawler chung.

Nguồn ngành xác nhận phát biểu của Google

• Bài tháng 2 năm 2023 của Illyes được trích nguyên văn bởi Search Engine Land, Search Engine Roundtable và Search Engine Journal; cả ba đều gọi 429 là “the one exception” (bản dịch) «ngoại lệ duy nhất». Đây là bài báo ngành về cùng một bài Google; nguồn sơ cấp là bài Illyes được trích ở trên.

Gửi 429 đúng cách — kèm Retry-After

Phần quan trọng nhất của phản hồi 429 đúng chuẩn thực hành là header Retry-After. Nó cho mọi client tuân thủ, gồm Googlebot, biết cần đợi bao lâu. Giá trị có thể là số giây hoặc ngày HTTP:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Không có Retry-After không vi phạm đặc tả, nhưng thêm header là thực hành tốt nhất và cung cấp cho crawler tín hiệu lùi lại cụ thể.

nginx — giới hạn tốc độ trả 429

Mặc định limit_req của nginx trả 503. Để có ngữ nghĩa thân thiện với crawler, đổi thành 429 và thêm header Retry-After. Ví dụ này cho phép 10 yêu cầu mỗi giây theo IP, kèm một khoảng burst nhỏ:

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache — giới hạn tốc độ bằng mod_ratelimit / mod_evasive

mod_ratelimit lõi của Apache điều tiết băng thông, không phải số yêu cầu; để giới hạn tốc độ yêu cầu, bạn thường dùng mod_evasive hoặc WAF. Muốn phản hồi bị điều tiết trả 429 kèm Retry-After, hãy đặt rõ:

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

Lưu ý: bản mod_evasive cũ mặc định trả 403 khi chặn — đúng mã Google nói không dùng cho giới hạn tốc độ. Xác nhận bản của bạn trả 429, hoặc đặt CDN/WAF phía trước để làm việc đó.

Cloudflare / CDN — giới hạn tốc độ thành 429

Ở tầng CDN, đặt phản hồi hành động của rule giới hạn tốc độ thành 429; nhiều hệ thống mặc định dùng 403 hoặc challenge. Trong rule Rate Limiting của Cloudflare, trạng thái khi vượt giới hạn có thể cấu hình: chọn 429 và thêm Retry-After nếu được hỗ trợ. Nguyên tắc giống nhau trên Fastly, Akamai hoặc API gateway: hành động khi vượt giới hạn phải là 429 Too Many Requests, không phải 403 Forbidden.

Phía client: thử lại sau 429 khi không có công thức

Nếu viết client, RFC cho đúng một quy tắc cứng và không cho thuật toán dự phòng: tôn trọng Retry-After hợp lệ khi có. Khi vắng header, RFC 6585 không quy định khoảng thử lại, công thức backoff, phân phối jitter, số lần thử hay điều kiện “thành công”; đó là chính sách của bạn, không phải yêu cầu đặc tả. Đừng trình bày bất kỳ công thức nào, kể cả ví dụ bên dưới, như luật HTTP; đây chỉ là mặc định có giới hạn hợp lý.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

Các thành phần quan trọng bất kể con số cụ thể: giới hạn tổng thời gian chờ và số lần thử để không lặp mãi, jitter để cả nhóm client không thử lại cùng nhịp rồi tái kích hoạt giới hạn, và kiểm tra tính idempotent trước khi lặp yêu cầu không an toàn. Một POST không idempotent cần khóa chống trùng, không phải thử lại mù quáng.

Xác minh bot thật sự là Googlebot trước khi miễn trừ

Nếu viết ngoại lệ giới hạn tốc độ cho công cụ tìm kiếm, hãy xác nhận danh tính bằng kiểm tra DNS ngược + xuôi. User-agent “Googlebot” giả rất phổ biến và riêng chuỗi UA không chứng minh gì.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Nếu kết quả ngược không kết thúc bằng miền Google hoặc kết quả xuôi không khớp IP gốc, đó không phải Googlebot. Bạn cũng có thể đối chiếu dải IP công bố của Google trong googlebot.json.

Quan niệm sai phổ biến về 429 và SEO

Quan niệm sai: “Bất kỳ 429 nào cũng làm hại SEO hoặc khiến tôi bị deindex.” Không. Google thiết kế cách xử lý 429 như tín hiệu điều tiết an toàn, được dự kiến. 429 ngắn hạn hoặc gián đoạn là bình thường và tự sửa. Nguy cơ deindex chỉ xuất hiện khi cùng URL trả 429 liên tục nhiều ngày; hướng dẫn 1–2 ngày của Google là ranh giới.

Quan niệm sai: “429 và 503 về cơ bản có thể thay thế nhau với SEO.” Google xử lý tương tự cho điều tiết crawl, nhưng hai mã có nghĩa khác. 503 Service Unavailable là tín hiệu truyền thống cho “tạm ngừng/bảo trì”, còn 429 nói rõ quá tải do tốc độ hoặc lượng yêu cầu. Dùng mã đúng ngữ nghĩa quan trọng với giám sát, công cụ và hệ thống phía sau đọc trạng thái, dù Googlebot lùi lại với cả hai.

Quan niệm sai: “Có thể dùng 403 hoặc 404 để làm Googlebot chậm lại như 429.” Bài tháng 2 năm 2023 của Illyes bác bỏ trực tiếp; cách làm phổ biến đến mức Google phải viết bài riêng yêu cầu dừng. 403/404 không ảnh hưởng tốc độ crawl và chủ động loại nội dung khỏi chỉ mục. 429 là mã 4xx duy nhất điều tiết.

Quan niệm sai: “Giới hạn tốc độ bot tìm kiếm gây cắt ngân sách crawl vĩnh viễn.” Mức giảm là tạm thời và tự phục hồi khi lượng lỗi hạ. Không có cờ kéo dài trên site sau khi lỗi dừng; tài liệu Google nói tốc độ crawl “will automatically start increasing again.” (bản dịch) «sẽ tự động bắt đầu tăng lại».

Quan niệm sai: “Googlebot gặp 429 thì bỏ URL vĩnh viễn.” Google thử lại sau. Điều đáng lo là 429 kéo dài nhiều ngày trên mỗi URL, không phải giới hạn đơn lẻ hoặc thỉnh thoảng; Googlebot chỉ tôn trọng rồi quay lại.

Câu hỏi thường gặp

Lỗi 429 có làm hại SEO không? Không phải tự nó. 429 ngắn hạn hoặc gián đoạn chỉ tạm làm Googlebot chậm và tự phục hồi. Rủi ro chỉ xuất hiện khi cùng URL trả 429 nhiều ngày.

Tôi có thể trả 429 bao lâu trước khi Google deindex trang? Tài liệu Google nói “a couple of hours, or 1–2 days.” (bản dịch) «vài giờ hoặc 1–2 ngày». Sau đó, “the URL may be dropped from Google’s index.” (bản dịch) «URL có thể bị loại khỏi chỉ mục Google». Hãy coi 1–2 ngày là trần cứng, không phải mục tiêu.

429 khác 503 thế nào với SEO? Google điều tiết crawl tương tự với cả hai. Nhưng 503 nghĩa là “tạm không khả dụng/bảo trì”, còn 429 nghĩa riêng “bạn gửi quá nhiều yêu cầu”. Dùng mã đúng ngữ nghĩa để hệ thống giám sát và công cụ của bạn hiểu đúng.

Có nên chặn Googlebot bằng 429 nếu muốn crawler giảm vĩnh viễn? Không; 429 là tín hiệu ngắn hạn, không phải thiết lập vĩnh viễn. Để giảm lâu dài, Google nói gửi yêu cầu đặc biệt về tốc độ crawl cao. Muốn loại bot khỏi cả khu vực, dùng robots.txt; muốn loại trang khỏi chỉ mục, dùng noindex.

Bingbot có tôn trọng 429 giống Googlebot không? Bingbot cũng được báo cáo là lùi lại trước tín hiệu quá tải như 429/500/503. Bing còn có cơ chế chủ động Google không có: chỉ thị crawl-delay trong robots.txt và lưới số yêu cầu mỗi giây Crawl Control trong Bing Webmaster Tools.

Header Retry-After là gì và tôi có cần không? Retry-After cho client biết cần đợi bao lâu trước khi thử lại, bằng số giây hoặc ngày HTTP. Không bắt buộc tuyệt đối, nhưng là thực hành tốt nhất và cung cấp tín hiệu lùi lại cụ thể cho crawler.

Google có crawl bình thường lại sau khi tôi ngừng trả 429 không? Có, tự động. Khi lượng lỗi giảm, “tốc độ crawl sẽ tự động bắt đầu tăng lại”. Không cần yêu cầu lại và không có hình phạt lâu dài.

WAF hoặc CDN có thể vô tình trả 429 cho Googlebot không? Điều này thường xảy ra. Rule tường lửa gắt, giới hạn mặc định của CDN/hosting và công cụ quản lý bot có thể phân loại nhầm Googlebot hoặc Bingbot. Xác minh danh tính crawler bằng DNS ngược + xuôi trước khi viết ngoại lệ và nới giới hạn bắt nhầm công cụ tìm kiếm thật.

429 là lỗi client hay lỗi máy chủ? Về kỹ thuật, đây là lỗi client 4xx trong đặc tả HTTP. Nhưng Google xử lý như lỗi máy chủ cho mục đích crawl; đây là mã 4xx duy nhất được gom với 5xx.

Client nên làm gì khi nhận 429 không có Retry-After? HTTP không bắt buộc công thức; đặc tả để việc đó cho chính sách. Mặc định có giới hạn hợp lý là backoff lũy thừa kèm jitter, trần tổng thời gian chờ và số lần thử để không lặp mãi, cùng kiểm tra tính idempotent trước khi gửi lại yêu cầu không an toàn để lặp. Xem thẻ Scripts để có mã giả hoàn chỉnh.

Tôi nên xử lý 429 thế nào?

Các vấn đề 429 thường gặp

Googlebot nhận 429 nhưng khách truy cập bình thường thì không

Triệu chứng: báo cáo crawler hiển thị 429 trong khi kiểm tra bằng trình duyệt trả 200. Nguyên nhân có khả năng: quản lý bot, rule UA hoặc giới hạn tốc độ theo IP. Cách sửa: đối chiếu sự kiện WAF với IP crawler đã xác minh, rồi thu hẹp hoặc sửa rule chịu trách nhiệm; đừng allowlist riêng chuỗi user-agent.

Tốc độ crawl của toàn hostname giảm

Triệu chứng: crawl chậm vượt ra ngoài URL đã trả 429. Nguyên nhân có khả năng: Google áp dụng tín hiệu quá tải trên toàn hostname. Cách sửa: dừng 429 ngoài ý muốn, khôi phục phản hồi thành công ổn định và để tốc độ crawl tự phục hồi.

Phản hồi 429 tiếp tục sau sự cố

Triệu chứng: máy chủ đã khỏe nhưng URL vẫn trả 429. Nguyên nhân có khả năng: cache CDN, rule edge hoặc trạng thái limiter tồn tại lâu hơn sự kiện. Cách sửa: tắt hoặc làm hết hạn rule tạm, purge phản hồi bị cache sai và xác minh trên các đường dẫn cùng khu vực đại diện.

Retry-After vắng mặt hoặc không dùng được

Triệu chứng: client biết bị giới hạn nhưng không biết khi nào thử lại. Nguyên nhân có khả năng: phản hồi do rule bảo mật chung tạo ra. Cách sửa: để tầng phát phản hồi gửi độ trễ hoặc ngày HTTP hợp lệ và kiểm tra header thô.

Prompt: audit rule giới hạn tốc độ

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

Prompt: chẩn đoán 429 không rõ nguyên nhân

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

Công cụ điều tra 429

• Công cụ kiểm tra mã trạng thái HTTP hàng loạt: kiểm tra nhóm URL đại diện và xuất đường dẫn hiện trả 429.
• Công cụ kiểm tra header HTTP: xem Retry-After, dấu vết CDN và các bước redirect trên phản hồi bị giới hạn.
• Công cụ xác minh Googlebot: xác thực bằng chứng IP trước khi tạo ngoại lệ crawler.
• Công cụ phân tích log: chia lượng lãng phí theo mã trạng thái, bot và khu vực trong khi giữ log tải lên ở trình duyệt.
• Crawl Stats trong Search Console: so sánh thời điểm 429 với thay đổi yêu cầu crawl và hành vi phản hồi host.

Xác thực cấu hình 429

Kiểm tra hợp đồng phản hồi

Kiểm tra cần chạy: kích hoạt giới hạn an toàn trong môi trường kiểm soát và xem phản hồi thô. Kết quả mong đợi: 429 kèm Retry-After hợp lệ, không có redirect hay trạng thái thành công ngoài ý muốn. Diễn giải lỗi: sai tầng hoặc template lỗi đang sở hữu phản hồi. Cửa sổ theo dõi: ngay lập tức. Điều kiện rollback: yêu cầu bình thường bị giới hạn hoặc thử nghiệm làm dịch vụ mất ổn định.

Kiểm tra phạm vi

Kiểm tra cần chạy: thử một client dự kiến bị giới hạn, người dùng bình thường và lưu lượng crawler đã xác minh trên các nhóm URL đại diện. Kết quả mong đợi: chỉ lưu lượng được định nghĩa vượt giới hạn. Diễn giải lỗi: khóa hoặc phạm vi rule quá rộng. Cửa sổ theo dõi: suốt thử nghiệm kiểm soát và thời gian lan truyền edge. Điều kiện rollback: route, người dùng hay host không liên quan nhận 429.

Kiểm tra phục hồi

Kiểm tra cần chạy: dừng tác nhân, đợi hết khoảng thử lại đã cấu hình rồi lặp yêu cầu. Kết quả mong đợi: phản hồi bình thường ổn định trở lại mà không cần cách né thủ công theo URL. Diễn giải lỗi: 429 trong cache hoặc trạng thái limiter còn tồn tại. Cửa sổ theo dõi: khoảng cấu hình cộng thời gian lan truyền triển khai. Điều kiện rollback: hostname vẫn bị giới hạn sau khi tải nền đã hết.

Kiểm tra lưu trữ cache

Kiểm tra cần chạy: đặt cache hoặc edge CDN trước route bị giới hạn, kích hoạt 429 rồi yêu cầu lại cùng URL sau khi điều kiện nền đã hết. Kết quả mong đợi: yêu cầu thứ hai được đánh giá mới, không có 429 cache hoặc phát lại từ edge. Diễn giải lỗi: thành phần trung gian đang lưu phản hồi mà RFC 6585 nói không được cache; hãy kiểm tra header kiểm soát cache và cấu hình rule edge, không phải origin. Cửa sổ theo dõi: ngay lập tức trên nhóm node/POP edge đại diện. Điều kiện rollback: bất kỳ 429 cache nào được phục vụ sau khi origin phục hồi.

Kiểm tra chính sách thử lại của client

Kiểm tra cần chạy: cho client đi qua 429 cả khi có và không có header Retry-After hợp lệ. Kết quả mong đợi: khi có header, client đợi đúng khoảng; khi không có, client dùng backoff kèm jitter có giới hạn, tôn trọng số lần thử tối đa và kiểm tra tính idempotent trước khi lặp yêu cầu không idempotent. Diễn giải lỗi: client thử lại ngay, không giới hạn hoặc lặp mù yêu cầu không idempotent có chính sách thử lại hỏng, không phải vấn đề tuân thủ HTTP. Cửa sổ theo dõi: toàn bộ chuỗi thử lại có giới hạn. Điều kiện rollback: client tái kích hoạt cùng giới hạn bằng các lần thử ngay hoặc vô hạn.

Tài nguyên đáng xem

Bài viết liên quan của tôi

• Mã trạng thái HTTP và tác động SEO — hướng dẫn đầy đủ của tôi về tác động SEO của từng mã, gồm vị trí của 429.
• Hướng dẫn nhập môn Technical SEO — vị trí của kiểm soát crawl và mã trạng thái trong bức tranh lớn.
• Câu chuyện chặn hai trang xếp hạng cao bằng Robots.txt — thử nghiệm sơ cấp của tôi về điều thực sự xảy ra khi cắt crawler.

Bài nói của tôi

• Cách Search hoạt động trên SlideShare — phần trình bày về crawl, render, lập chỉ mục và xếp hạng, gồm cách máy chủ báo crawler chậm lại. Tuyên bố giới hạn thường trực áp dụng: “This is my understanding of systems… not going to be 100% complete or accurate.” (bản dịch) «Đây là hiểu biết của tôi về các hệ thống… không thể đầy đủ hoặc chính xác 100%.»

Tài nguyên trong ngành

• Đừng dùng 403 hay 404 để giới hạn tốc độ (Google Search Central, Gary Illyes) — phát biểu chuẩn rằng 429 là ngoại lệ.
• Giảm tốc độ crawl của Google (Google) — cửa sổ 1–2 ngày, điều tiết toàn hostname và tự phục hồi.
• Google cảnh báo không dùng 403 hay 404 để giới hạn tốc độ Googlebot (Search Engine Land) — bài báo ngành về nội dung của Illyes.
• Google nói hãy ngừng dùng 403 hoặc 404 để giảm tốc độ Googlebot (Search Engine Roundtable) — bản tóm tắt gọi 429 là “ngoại lệ duy nhất”.
• Google: Đừng dùng phản hồi lỗi 403/404 để giới hạn tốc độ Googlebot (Search Engine Journal) — bài độc lập thứ ba về cùng hướng dẫn.
• MDN — 429 Too Many Requests — định nghĩa đặc tả HTTP và tham chiếu Retry-After.
• Hướng dẫn Bingbot — hướng dẫn Bing hiện hành cho chỉ thị crawl-delay.

Tự kiểm tra: 429 Too Many Requests

Năm câu hỏi nhanh về cách 429 hoạt động và cách Google xử lý mã. Chọn đáp án rồi kiểm tra.

Nhật ký thay đổi