Bị chặn do lỗi 4xx khác

Tóm tắt — “Blocked due to other 4xx issue” trong Google Search Console là nhóm còn lại cho lỗi phía client chưa được tách riêng thành 401, 403 hoặc 404. Googlebot yêu cầu trang và nhận một lỗi 4xx khác — như 400, 410 hoặc 451 — nên trang không thể được lập chỉ mục. Google không công bố danh sách chính xác các mã thuộc nhóm này; việc đầu tiên là xác định mã thực tế, vì cách sửa phụ thuộc hoàn toàn vào mã đó.

Trạng thái này có nghĩa gì

Nhóm Search Console này bao phủ response 4xx không được biểu diễn bằng loại lỗi cụ thể hơn trong báo cáo. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google xử lý response 4xx — trừ 429 — như nội dung không khả dụng để lập chỉ mục. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Khi mở báo cáo Page Indexing trong Search Console và thấy “Blocked due to other 4xx issue”, điều đó nghĩa Googlebot cố fetch URL và máy chủ trả lỗi 4xx phía client — nhưng không khớp các nhóm cụ thể đã được Google liệt kê riêng. Google tách 401 — cần đăng nhập, 403 — bị cấm, và 404 — không tìm thấy — thành các hàng riêng. Google chỉ mô tả hàng này là “a 4xx error not covered by any other issue type” (bản dịch) “lỗi 4xx không thuộc bất kỳ loại lỗi nào khác”; họ không công bố ánh xạ đầy đủ mọi mã còn lại vào nhóm. Trong thực tế, 400, 405, 408, 410 Gone, 411, 413, 414, 421, 422 và 451 thường xuất hiện ở đây, nhưng hãy coi đây là danh sách ứng viên có khả năng cần kiểm tra, không phải bảo đảm về kết quả sẽ tìm thấy.

Vì Google nhận lỗi thay cho trang, Google không đọc được nội dung nên trang sẽ không được lập chỉ mục — và bị loại nếu trước đây đã được lập chỉ mục.

Nhãn này là một nhóm hỗn hợp — hãy tìm mã thực

Đây là phần dễ gây nhầm. “Other 4xx” là một nhóm, không phải chẩn đoán. 410 Gone — bạn cố ý xóa trang — và 400 Bad Request — URL hỏng — đều có thể nằm cùng một hàng, nhưng cách xử lý cho hai trường hợp trái ngược nhau. Vì vậy, trước khi “sửa” bất cứ điều gì, hãy tìm status code thực tế:

• Trong Search Console, dùng URL Inspection và chọn Test live URL để xem Google hiện nhận gì.
• Mở DevTools → tab Network của trình duyệt và xem status code, hoặc fetch từ dòng lệnh bằng curl -I.
• Kiểm tra server log để biết mã Googlebot thực sự nhận được.

Đây có thực sự là vấn đề không?

Đôi khi “other 4xx” hoạt động đúng chủ đích. 410 Gone trên trang bạn đã xóa vĩnh viễn là response đúng — nó chỉ trở thành vấn đề nếu trang vẫn nằm trong sitemap hoặc còn được liên kết khi không nên. Nhưng nếu trang bạn muốn lập chỉ mục trả một mã 4xx bất thường, đó là lỗi thực sự cần sửa tận nguồn.

Lưu ý nhanh về 429

Bạn có thể đã đọc rằng 429 — “too many requests”, giới hạn tốc độ — thuộc nhóm này. Google xử lý 429 như tín hiệu máy chủ quá tải, không phải lỗi client bình thường, và dùng nó để giảm tốc crawl thay vì loại trang ngay. Tài liệu của Google không nói URL 429 thực tế xuất hiện ở hàng Page Indexing nào, vì vậy cũng đừng giả định chắc chắn nó bị loại khỏi nhóm này. Dù thế nào, đừng tắt rate limit để “sửa” trạng thái other-4xx — xem thêm trong tab Advanced.

Muốn xem hướng dẫn sửa theo từng mã, sắc thái của 429, chi tiết 410 so với 404 và cây quyết định chẩn đoán? Hãy chuyển sang tab Advanced.

Tóm tắt — “Blocked due to other 4xx issue” là hàng còn lại trong báo cáo Page Indexing: Googlebot nhận một mã 4xx chưa được tách thành loại lỗi riêng — 401/403/404. Google không công bố ánh xạ đầy đủ mọi mã khác vào hàng này; 400, 405, 408, 410, 411, 413, 414, 421, 422, 451, v.v. là các nhánh chẩn đoán cần kiểm tra sau khi biết mã thật, không phải danh sách thành viên được bảo đảm. Quy tắc của Google: mọi mã 4xx trừ 429 được xử lý giống nhau — nội dung được coi như không tồn tại nên trang không được lập chỉ mục, và không ảnh hưởng crawl rate. Nhãn gần như không cho biết nguyên nhân, vì vậy bước đầu luôn là xác định mã thật — live test của URL Inspection → Crawl Stats → tái hiện đúng request method ban đầu → đối chiếu log server/CDN/WAF/app — bởi cách xử lý 410, một lần xóa có chủ đích, trái ngược cách xử lý 400 hoặc 429. Lầm tưởng cần loại bỏ: 429 không phải 4xx bình thường — Google coi đó là lỗi máy chủ do quá tải và giảm tốc crawl, nhưng hành vi xử lý này không chứng minh URL 429 nhận nhãn Page Indexing nào; vị trí trong báo cáo chưa được xác nhận theo cả hai hướng. Đừng dùng 4xx để giảm tốc Googlebot; hãy dùng 429 hoặc 503. Xác định → sửa nguyên nhân gốc — hoặc xác nhận có chủ đích → xác nhận 200 trong Test live URL → Validate Fix, thao tác giúp URL đủ điều kiện được lập chỉ mục lại chứ không bảo đảm kết quả.

Google thực sự nói gì

Nhãn báo cáo là một danh mục, vì vậy hãy kiểm tra URL để xác định status code và nguyên nhân thực tế. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Hành vi HTTP được ghi trong tài liệu riêng, tách khỏi taxonomy của báo cáo. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Tài liệu Page Indexing của Google mô tả trạng thái này rõ ràng: máy chủ gặp lỗi 4xx không thuộc các loại lỗi khác mà báo cáo đã tách riêng, và lời khuyên là gỡ lỗi trang bằng URL Inspection. Theo định nghĩa, đây là nhóm còn lại — mọi 4xx chưa có hàng riêng như 401 — chưa xác thực, 403 — bị cấm, 404 — không tìm thấy. Google không công bố bảng đầy đủ ánh xạ mọi mã 4xx còn lại vào hàng này, vì vậy hãy coi mọi danh sách “mã thuộc nhóm” — kể cả danh sách dưới đây — là ứng viên thường quan sát được, không phải danh sách thành viên chính thức hay đầy đủ.

Hành vi phía sau nằm trong tài liệu status code HTTP riêng của Google, với một quy tắc cốt lõi chi phối gần như toàn bộ trang này: mọi lỗi 4xx, trừ 429, được xử lý giống nhau — crawler Google báo với hệ thống xử lý tiếp theo rằng nội dung không tồn tại. Với lập chỉ mục, kết quả giống 404: trang được coi là không tồn tại và sẽ không được lập chỉ mục — hoặc bị loại nếu đã có trong chỉ mục. Quan trọng là các mã 4xx — vẫn trừ 429 — không ảnh hưởng crawl rate; chúng không làm Googlebot chậm lại mà chỉ loại trang khỏi diện xem xét. Tuy nhiên, tần suất crawl của URL liên tục trả lỗi sẽ tự nhiên giảm dần theo thời gian khi Google luôn không tìm thấy nội dung.

Những mã 4xx thường xuất hiện ở đây

Định nghĩa nhóm còn lại của Google không nêu riêng các mã sau; đây là những gì thường xuất hiện trong thực tế sau khi đã xác nhận mã thật. Với từng mã, hãy kiểm tra điều gì và tránh suy luận sai phổ biến nào:

• 400 — Request không hợp lệ — request target, cú pháp hoặc framing Host/routing sai, thường do URL hỏng hoặc encode sai. Suy luận sai: “code của trang hỏng”; hãy so sánh request chính xác máy chủ nhận với request bạn định tạo.
• 405 — Method không được phép — HTTP method không được phép với URL; response nên có header Allow nêu method được phép. Suy luận sai: curl -I — HEAD — thất bại chứng minh GET của Googlebot cũng thất bại; hãy kiểm thử riêng hai method.
• 408 Request Timeout — kết nối hoặc request không hoàn tất đúng hạn. Suy luận sai: “máy chủ ngừng hoạt động chung”; hãy đối chiếu thời điểm ở tầng connection/proxy/origin.
• 410 Gone — tài nguyên đã bị xóa vĩnh viễn. Thường có chủ đích; xem phần dưới.
• 411 Length Required — máy chủ yêu cầu header Content-Length trên request có body. Điều này bất thường với lượt fetch trang thông thường; hãy xác nhận request thực sự có nội dung và tầng nào từ chối trước khi đổi quy tắc.
• 413 Payload Too Large — nội dung request vượt giới hạn kích thước. Hãy xác nhận body/header của request đầu vào, không phải kích thước chính trang.
• 414 URI Too Long — bản thân URI của request vượt giới hạn chiều dài. Thường là vấn đề tham số được tạo hoặc chuỗi redirect, không phải nội dung trang.
• 415 / 422 — Loại media không được hỗ trợ / Không thể xử lý thực thể — content type hoặc chỉ thị trong request bị từ chối. Giống 411/413, đây là điều kiện nội dung request và không điển hình với GET trang thông thường; đừng nới lỏng validation chung khi chưa có bằng chứng về request thực sự bị từ chối.
• 421 Misdirected Request — kết nối bị chuyển sai; Google cũng ghi nhận việc trả 421 là cách chủ ý loại một route khỏi HTTP/2. Đừng giả định trang hỏng trên mọi protocol; hãy xác nhận Google có thử lại qua HTTP/1.1 không và response cuối là gì.
• 451 — Không khả dụng vì lý do pháp lý — điểm chặn do pháp lý hoặc policy. Chuyển tới người phụ trách rà soát pháp lý/policy thay vì coi là cấu hình geo/WAF thông thường.
• 429 Too Many Requests — rate limit. Mã này đặc biệt — xem phần dưới.

Mục đích của danh sách không phải để ghi nhớ như chân lý; nó cung cấp tập nhánh chẩn đoán ban đầu. Bạn vẫn phải xem mã thật và tầng tạo ra mã trước khi chọn cách sửa.

429 là ngoại lệ — tách ngữ nghĩa khỏi nhãn báo cáo

Nhiều bài viết bên thứ ba gộp 429 vào “other 4xx”. Cách đó nhập ba câu hỏi riêng cần được tách biệt: HTTP nói 429 nghĩa gì, crawler Google thực sự xử lý nó ra sao và URL 429 được báo ở hàng Page Indexing nào. Hai câu đầu có tài liệu; câu thứ ba thì không. Crawler Google coi status code 429 là tín hiệu máy chủ quá tải và xem đó là lỗi máy chủ — không phải lỗi client bình thường. Hệ quả thực tế:

• 429 khiến Googlebot giảm tốc thay vì loại trang ngay.
• Vì được xử lý như lỗi máy chủ, 429 thực có khả năng được báo như vấn đề máy chủ/crawl thay vì “Blocked due to other 4xx issue”; nhưng tài liệu Google mô tả hành vi xử lý, không mô tả taxonomy báo cáo, nên hãy coi vị trí trong báo cáo là chưa xác nhận thay vì giả định mã này bị loại khỏi nhóm.
• Động thái sai là tắt rate limit hợp lệ để “sửa” trạng thái other-4xx. Nếu máy chủ thực sự quá tải, hãy giữ rate limit và gửi header Retry-After — RFC 6585 quy định header này là tùy chọn trên response 429. Đây là vệ sinh HTTP hợp lý cho client tuân thủ chuẩn, nhưng tài liệu Google đã rà soát không nói Googlebot dùng giá trị header để lên lịch crawl kế tiếp. Hãy gửi như thực hành tốt, nhưng đừng coi là chỉ thị được bảo đảm. Như tôi viết trong hướng dẫn status code HTTP của Ahrefs: “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (bản dịch) “429 hơi đặc biệt vì thường được xử lý như lỗi máy chủ và khiến Google giảm tốc crawl. Nhưng cuối cùng Google vẫn sẽ loại các trang này khỏi chỉ mục.” Vì vậy 429 không miễn phí — nó mua thêm thời gian, không giữ trang trong chỉ mục vĩnh viễn.

410 so với 404 — thường không phải vấn đề đáng kể

410 Gone là mã có chủ đích phổ biến nhất trong nhóm này: bạn đã xóa trang và muốn nó biến mất. Nhiều người quá chú ý khác biệt 410 với 404, nhưng khác biệt thực tế nhỏ. Tài liệu crawl của Google liệt kê 410 trong các mã 4xx nhận cùng cách xử lý “nội dung không tồn tại” ở hạ nguồn như 404. Như tôi viết trong hướng dẫn status code HTTP của Ahrefs: “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (bản dịch) “404 và 410 được xử lý tương tự. Cả hai loại trang khỏi chỉ mục, nhưng 410 nhanh hơn đôi chút.” John Mueller cho biết chênh lệch tối đa chỉ vào khoảng vài ngày, và trong trung/dài hạn Google xử lý 404 với 410 giống nhau — cả hai đều bị loại khỏi chỉ mục. Việc Google liệt kê 410 trong cách xử lý 4xx chung tự nó không xác nhận URL 410 được báo ở hàng Page Indexing nào; nếu thấy một URL ở đây, điều đó phù hợp kỳ vọng chứ không phải điều chắc chắn đã được tài liệu hóa. Dù sao, nếu 410 trong nhóm có chủ đích thì nó hoạt động đúng thiết kế; chỉ hành động khi trang thực ra cần hoạt động, đồng thời xác nhận trạng thái trang trong Search Console thay vì suy ra chỉ từ mã.

Vì sao trạng thái này xảy ra

Phần lớn trạng thái “other 4xx” trong thực tế xuất phát từ một trong các nguyên nhân sau:

• Quy tắc WAF / bảo vệ bot / CDN trả một mã 4xx bất thường — thường không phải 403 chuẩn — khi mẫu request Googlebot kích hoạt quy tắc.
• Plugin bảo mật — chẳng hạn plugin WordPress — chặn hoặc challenge client không phải trình duyệt.
• Chặn IP / địa lý bắt Googlebot, vốn chủ yếu crawl từ IP Hoa Kỳ.
• Rate limit quá gắt trả 4xx sau N request — đúng ra nên là 429; xem phần dưới.
• URL sai — 400, giới hạn kích thước request — 413, hoặc lỗi validation — 422 do cách URL được tạo hoặc liên kết.
• Xóa có chủ đích — 410 nhưng URL lẽ ra không còn trong sitemap.

Một nguyên nhân lớn do chính website tạo ra là dùng 4xx để giảm tốc Googlebot. Google đã yêu cầu chủ website và CDN ngừng dùng 404 cùng mã 4xx khác nhằm giảm crawl rate Googlebot — việc đó không làm crawl chậm mà chỉ loại nội dung khỏi Search. Nếu cần Googlebot lùi lại, hãy trả 500, 503 hoặc 429, không dùng 4xx bình thường.

Cách chẩn đoán mã thực

Hãy xử lý theo cây quyết định từ trên xuống. Không công cụ đơn lẻ nào chắc chắn hiển thị lỗi chính xác; hãy nối các nguồn:

1. URL Inspection → Test live URL. Xác nhận khả năng truy cập hiện tại — Google đang nhận 4xx ngay bây giờ hay hàng báo cáo đã cũ. Live test thất bại không phải lúc nào cũng hiển thị raw response header hoặc status line, nên trước hết coi đây là kiểm tra khả dụng, không phải chẩn đoán hoàn chỉnh.
2. Báo cáo Crawl Stats. Cung cấp ví dụ đại diện về request crawl thực của Google — response code, response time, theo file type — hữu ích để đối chiếu điều một lượt crawl theo lịch đã thấy, vì Test live URL dùng Google-InspectionTool thay cho crawler thông thường.
3. Tự tái hiện, khớp request ban đầu. Mở URL trong tab Network của DevTools hoặc dùng curl; nếu nghi quy tắc bot, fetch bằng user-agent Googlebot — lý tưởng từ ngoài mạng — để kích hoạt cùng quy tắc. Phải khớp cả method: curl -I gửi HEAD, có thể nhận kết quả khác GET mà Google thực hiện — riêng HEAD trả 405 không chứng minh GET thất bại. Lệnh nằm trong tab Scripts.
4. Đọc và đối chiếu log server / CDN / WAF / auth proxy / ứng dụng. Đây thường là nơi duy nhất cho biết status chính xác, tầng từ chối và quy tắc/điều kiện tạo response, nhất là khi live test không hiển thị raw header.
5. Xác minh danh tính requester tách biệt với response. Chuỗi user-agent không chứng minh request đến từ Googlebot; xác nhận qua reverse + forward DNS hoặc dải IP Google công bố trước khi quyết định điểm chặn có tác động tới crawler hợp lệ không.
6. Ánh xạ mã với nguyên nhân. 400/405/408/414 → vấn đề framing/timing/URI của request. 411/413/415/422 → chỉ chẩn đoán là lỗi nội dung request khi có bằng chứng về method và body Google gửi; các mã này bất thường với lượt fetch trang thông thường. 410 → xóa có chủ đích — xác nhận URL cần biến mất. Với 421, xác minh cách Google dùng mã để opt out HTTP/2 và response fallback HTTP/1.1. 4xx từ tầng bảo mật → chỉ allowlist client đã xác minh trên route cụ thể, không tạo ngoại lệ bao quát. Mã lẽ ra là 429 → rate limit, xử lý như tải máy chủ chứ không như 4xx bình thường.

Cách sửa theo từng mã

• 400 / 405 / 408 / 414 — framing, method, timing, độ dài URI. Sửa nguồn tạo request sai, URL hỏng/quá dài, method không được phép hoặc kết nối chậm/không hoàn tất tại tầng thực sự tạo lỗi; so sánh request chính xác máy chủ thấy với điều ứng dụng định gửi.
• 411 / 413 / 415 / 422 — lỗi nội dung request. Các mã mô tả điều kiện gắn với body, chiều dài hoặc content type của request, không điển hình với GET trang thông thường. Trước khi nới giới hạn hoặc quy tắc validation, xác nhận từ log method và nội dung request nào thực sự kích hoạt lỗi cùng tầng từ chối; đừng nới giới hạn bảo mật chung khi chưa có bằng chứng.
• 410 — có chủ đích không? Nếu trang cần biến mất, 410 là đúng; chỉ cần xóa khỏi sitemap và internal link để không tiếp tục xuất hiện như “vấn đề”. Nếu trang cần hoạt động, 410 là sai sót phải hoàn tác.
• 421 — kiểm tra đây có phải HTTP/2 opt-out có chủ đích không. Google ghi nhận việc trả 421 là cách loại route khỏi crawl HTTP/2. Xác nhận request có fallback sang HTTP/1.1 không và response cuối là gì trước khi coi 421 là trang hỏng.
• 429 — rate limit đúng cách. Đừng tắt rate limit hợp lệ. Giữ quy tắc, thêm header Retry-After như thực hành tốt — header là tùy chọn theo đặc tả HTTP và tài liệu Google không xác nhận Googlebot dùng giá trị đó để lên lịch crawl kế tiếp — đồng thời nhớ Google hiểu 429 là “giảm tốc”, không phải “gỡ chỉ mục”. Nếu quy tắc trả 4xx cho Googlebot chỉ để giảm tốc, hãy đổi sang 429 hoặc 503.
• 451 — xác nhận bối cảnh pháp lý/policy trước. Đừng coi là cấu hình geo/WAF thông thường; chuyển tới người phụ trách quyết định pháp lý hoặc content policy trước khi đổi response.
• Điểm chặn WAF / CDN / plugin bảo mật. Trước hết xác định tầng và quy tắc từ chối chính xác. Allowlist Googlebot đã xác minh — bằng reverse DNS hoặc dải IP Google công bố, không tin riêng chuỗi user-agent có thể giả mạo — và giới hạn ngoại lệ hẹp ở route/client cần thiết, không cho phép bao quát mọi request nguồn Google hay mọi quy tắc bảo mật. Sửa quy tắc để URL trả 200.

Đừng dùng 4xx để làm Googlebot chậm lại

Điều này đáng được nêu riêng vì là nguyên nhân hàng đầu của “other 4xx” tự gây ra: trả mã 4xx để giảm tốc Googlebot không hiệu quả và loại nội dung khỏi Search. Như tôi tóm tắt trong hướng dẫn status code HTTP của Ahrefs: “4xxs will cause pages to drop from the index.” (bản dịch) “4xx sẽ khiến trang bị loại khỏi chỉ mục.” Nếu mục tiêu thực là giảm crawl, hãy dùng 429 hoặc 503 — đó là các mã Google hiểu là “hãy quay lại sau”, với tác động tạm thời.

Sau khi sửa

Sau khi giải quyết nguyên nhân nền tảng — hoặc xác nhận 410 có chủ đích và dọn sitemap/liên kết:

1. Dùng URL Inspection → Test live URL để xác nhận response live nay là 200.
2. Yêu cầu lập chỉ mục cho URL ưu tiên cao và/hoặc chọn Validate Fix trên hàng “Blocked due to other 4xx issue” trong báo cáo Page Indexing.
3. Response 200 làm URL đủ điều kiện để Google crawl, xử lý và có thể lập chỉ mục lại sau lần crawl tiếp theo; nó không bảo đảm được lập chỉ mục hay thời gian cố định. Đừng “Request indexing” hàng loạt trước khi sửa nguyên nhân gốc, nếu không URL chỉ quay lại cùng nhóm lỗi.

Trạng thái này có gây hại SEO không?

Chỉ khi trang bạn thực sự muốn lập chỉ mục đang trả 4xx — các trang đó bị loại khỏi chỉ mục và mất thứ hạng cho tới khi sửa. Nếu 4xx có chủ đích — 410 trên trang đã xóa, điểm chặn có chủ ý trên đường dẫn admin không nên nằm trong sitemap — hệ thống hoạt động đúng thiết kế và không gây hại.

Các trạng thái liên quan cần biết: “Blocked due to access forbidden (403)” và “Blocked due to unauthorized request (401)” là hàng riêng cho firewall/đăng nhập, còn “Not found (404)” có nhóm riêng. Trạng thái này bao gồm phần còn lại của họ 4xx. Muốn hiểu chính báo cáo và cách nhóm lý do chưa lập chỉ mục, hãy xem tổng quan Page Indexing.

Tóm tắt bằng AI

Bản rút gọn của nội dung trong tab Advanced:

• Đây là gì. “Blocked due to other 4xx issue” trong báo cáo Page Indexing GSC = Googlebot nhận 4xx chưa được tách riêng thành 401/403/404. Google không công bố danh sách đầy đủ các mã thuộc nhóm; 400, 405, 408, 410, 411, 413, 414, 421, 422 và 451 là ứng viên thường gặp cần kiểm tra, không phải danh sách thành viên được bảo đảm. Trang không được lập chỉ mục — và bị loại nếu trước đó đã được lập chỉ mục.
• Quy tắc cốt lõi. Mọi 4xx trừ 429 được xử lý giống nhau — Google coi nội dung không tồn tại như 404, và không ảnh hưởng crawl rate.
• Nhãn là một nhóm hỗn hợp. Nó không cho biết nguyên nhân — trước hết hãy tìm status code thực: live test của URL Inspection → Crawl Stats → tái hiện đúng request method ban đầu → đối chiếu log server/CDN/WAF. curl -I là HEAD, không phải GET, nên kiểm thử cả hai.
• 429 là ngoại lệ — và lầm tưởng phổ biến. Google coi 429 là lỗi máy chủ do quá tải và giảm tốc crawl thay vì loại trang, nhưng hành vi xử lý không xác nhận URL 429 được báo ở hàng Page Indexing nào; hãy coi vị trí báo cáo là chưa xác nhận. Giữ rate limit hợp lệ; gửi Retry-After như thực hành tốt — header là tùy chọn theo đặc tả HTTP và tài liệu Google không nói Googlebot lên lịch theo nó. Đừng tắt bảo vệ để “sửa” trạng thái other-4xx.
• 410 so với 404. 410 — Gone — là mã có chủ đích thường gặp ở đây; Google gộp nó vào cùng cách xử lý hạ nguồn “nội dung không tồn tại” như 404, và chênh lệch thời gian thực tế nhỏ. Nếu 410 có chủ đích, nó hoạt động đúng thiết kế; xác nhận mục đích trước khi thay đổi.
• 421 cũng có thể có chủ đích. Google ghi nhận 421 là cách loại một route khỏi crawl HTTP/2; hãy kiểm tra fallback HTTP/1.1 và response cuối trước khi giả định trang hỏng.
• Nguyên nhân. Điểm chặn WAF/CDN/plugin bảo mật, chặn IP/geo, rate limit, URL sai hoặc quá dài — 400/414, điều kiện nội dung request — 411/413/415/422, cần bằng chứng body thật — hoặc xóa có chủ đích — 410.
• Đừng giảm tốc bằng 4xx. Dùng 404/other-4xx để làm Googlebot chậm lại sẽ loại nội dung khỏi Search; hãy dùng 429 hoặc 503.
• Sửa + xác thực. Xác định mã — không dừng ở live test thất bại; lấy Crawl Stats và log được đối chiếu → sửa nguyên nhân gốc — hoặc xác nhận có chủ đích và dọn sitemap/liên kết → xác nhận 200 trong Test live URL → Validate Fix. 200 giúp URL đủ điều kiện được lập chỉ mục lại; không bảo đảm kết quả hay thời gian cụ thể.

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

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

Google

• Báo cáo Page Indexing — chính báo cáo, gồm mục “Blocked due to other 4xx issue” — lỗi 4xx không thuộc loại lỗi nào khác — và các trạng thái liên quan 401/403/404.
• Ảnh hưởng của status code HTTP, lỗi mạng và DNS tới Google Search — quy tắc mọi 4xx trừ 429 được xử lý giống nhau, 429 được xử lý như tín hiệu máy chủ quá tải, và 4xx — trừ 429 — không ảnh hưởng crawl rate.
• Don’t 404 my yum — Search Central Blog, 2023 — Google yêu cầu chủ website và CDN ngừng dùng 404 cùng các mã 4xx khác để giảm tốc Googlebot, đồng thời nêu mã thay thế — 500/503/429.
• Xác minh Googlebot và crawler Google khác — reverse + forward DNS và dải IP công bố để allowlist Googlebot thật trước khi đổi quy tắc WAF/firewall.

Bing / Microsoft

• Bing Webmaster Tools — Crawl Control — Bing không dùng nhãn “other 4xx” chính xác như Google, nhưng nguyên tắc giống nhau: 4xx nghĩa Bingbot không fetch được nội dung khả dụng nên URL không được lập chỉ mục. Hãy dùng Crawl Control để quản lý tốc độ Bingbot thay vì chặn bằng error code.

Trích dẫn từ nguồn

Các tuyên bố chính thức từ Google và từ hướng dẫn status code của chính tôi trên Ahrefs — nội dung tôi là tác giả và có thể xác nhận là lời của mình. Mỗi liên kết sâu chuyển tới đoạn được trích trên trang nguồn.

Google — cách xử lý 4xx, trừ 429

• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (Bản dịch) “Mọi lỗi 4xx, trừ 429, được xử lý giống nhau: crawler Google báo với hệ thống xử lý tiếp theo rằng nội dung không tồn tại.” — Tài liệu Google Search Central. Đi tới trích dẫn

Google — 429 được xử lý như 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 status code 429 là tín hiệu máy chủ quá tải và xem đó là lỗi máy chủ.” — Tài liệu Google Search Central. Đi tới trích dẫn

Google — đừng dùng 4xx để giới hạn crawl rate

• “The 4xx status codes, except 429, have no effect on crawl rate.” (Bản dịch) “Các status code 4xx, trừ 429, không ảnh hưởng crawl rate.” — Tài liệu Google Search Central. Đi tới trích dẫn

John Mueller, Google — 410 so với 404 — diễn giải

• John Mueller của Google mô tả chênh lệch 410 với 404 là nhỏ — tối đa khoảng vài ngày — và cho biết trong trung/dài hạn Google xử lý 404 với 410 giống nhau: cả hai bị loại khỏi chỉ mục. Nội dung được Search Engine Journal tường thuật trong Google đưa ra lời khuyên về status code 404 và 410 — SEJ. (Được diễn giải thay vì trích nguyên văn trong lúc chờ kiểm tra độc lập cách diễn đạt chính xác ở lượt này; hãy xác nhận cách nói chính xác với nguồn trước khi trích trực tiếp.)

Patrick Stox — tôi — từ hướng dẫn status code trên Ahrefs

• “4xxs will cause pages to drop from the index.” (Bản dịch) “4xx sẽ khiến trang bị loại khỏi chỉ mục.” — Patrick Stox, “Status code HTTP và tác động SEO,” Ahrefs. Đi tới trích dẫn
• “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (Bản dịch) “Cách xử lý 404 và 410 tương tự nhau: cả hai loại trang khỏi chỉ mục, còn 410 nhanh hơn một chút.” Đi tới trích dẫn
• “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (Bản dịch) “429 hơi đặc biệt vì thường được xử lý như lỗi máy chủ và khiến Google giảm tốc crawl. Nhưng cuối cùng Google vẫn loại các trang này khỏi chỉ mục.” Đi tới trích dẫn

Lưu ý về Retry-After: RFC 6585 cho phép — nhưng không bắt buộc — response 429 chứa header Retry-After. Gửi header là thực hành hợp lý với client tuân thủ chuẩn, nhưng tài liệu Google được rà soát cho trang này không nói Googlebot lập lịch crawl kế tiếp dựa trực tiếp vào giá trị đó; hãy trình bày nó như metadata response tùy chọn, không phải chỉ thị Googlebot đã được xác nhận.

Checklist chẩn đoán → sửa → xác thực other-4xx

Chạy checklist này với mọi URL hiển thị “Blocked due to other 4xx issue”:

• Trước hết tìm mã thực — URL Inspection → Test live URL, Crawl Stats để lấy chi tiết request đại diện, cộng tab Network của DevTools / curl — cả HEAD và GET — / log server-CDN-WAF đã đối chiếu. Nhãn nhóm không phải chẩn đoán và Google không công bố ánh xạ mã-sang-hàng hoàn chỉnh.
• Xác nhận lỗi đang live, không phải dữ liệu cũ — Test live URL hiển thị 4xx hiện tại, không phải báo cáo cũ; live test thất bại có thể không hiển thị raw header, nên đối chiếu log khi cần.
• Phân loại. Lỗi framing/timing/URI của request — 400/405/408/414? Điều kiện nội dung request cần bằng chứng body — 411/413/415/422? Xóa có chủ đích — 410? HTTP/2 opt-out có thể có chủ đích — 421? Pháp lý/policy — 451? Điểm chặn tầng bảo mật? Mã lẽ ra là 429 — rate limit?
• Nếu 410 — Gone: trang có cần biến mất không? Nếu có, response đúng; chỉ xóa khỏi sitemap/internal link. Nếu không, khôi phục trang.
• Nếu 421: xác nhận đây có phải HTTP/2 opt-out có chủ đích không và kiểm tra fallback HTTP/1.1 cùng response cuối trước khi coi là hỏng.
• Nếu lỗi request/framing: sửa URL sai hoặc quá dài, method được phép hay vấn đề timeout/kết nối tận nguồn; ngừng liên kết tới hoặc liệt kê URL xấu.
• Nếu lỗi nội dung request — 411/413/415/422: xác nhận method và body thực tế từ log trước khi nới giới hạn hay quy tắc validation.
• Nếu điểm chặn security/WAF/CDN: xác minh Googlebot thật — reverse DNS hoặc dải IP công bố — rồi allowlist hẹp theo danh tính/IP và route; không dựa vào user-agent, không cho phép bao quát.
• Nếu thực sự nhằm giảm tốc: đừng dùng 4xx; hãy trả 429 hoặc 503 và thêm header Retry-After như thực hành tốt. Giữ rate limit hợp lệ; đừng giả định lần crawl tiếp theo của Googlebot được lên lịch theo header.
• Xác nhận 200 — Test live URL nay trả 200 với trang bạn muốn lập chỉ mục.
• Xác thực — chọn Validate Fix trên hàng “other 4xx” và/hoặc Request indexing cho URL ưu tiên. Điều này làm URL đủ điều kiện được lập chỉ mục lại, không bảo đảm kết quả; đừng yêu cầu hàng loạt trước khi sửa nguyên nhân.

Các mô hình tư duy

1. Nhãn là một nhóm, không phải chẩn đoán. “Other 4xx” là hàng còn lại của Google cho mọi 4xx chưa được tách thành loại lỗi riêng. Google không công bố danh sách chính xác những mã thuộc hàng này, dù 400, 405, 408, 410, 411, 413, 414, 421, 422 và 451 là ứng viên thường gặp. Động thái đầu tiên không bao giờ là “sửa nó” mà là “thực tế đây là mã nào?” Mọi bước sau phụ thuộc câu trả lời.

2. Với lập chỉ mục, other-4xx = 404. Google xử lý mọi 4xx trừ 429 giống nhau: nội dung được coi như không tồn tại. Vì vậy dù mã cụ thể là gì, kết quả lập chỉ mục giống 404 — không được lập chỉ mục, bị loại nếu đã có. Điều đó cũng nghĩa mã không ảnh hưởng crawl rate.

3. 429 là lỗi máy chủ, không phải lỗi client — và vị trí báo cáo là câu hỏi riêng chưa được xác nhận. Google hiểu 429 là “máy chủ quá tải” và giảm tốc thay vì loại trang — điều này đã có tài liệu. Việc URL 429 có xuất hiện trong chính hàng báo cáo này hay không chưa được tài liệu hóa theo cả hai hướng, vì vậy đừng coi vị trí đã được xác quyết. Đừng tắt rate limit để làm trạng thái biến mất; gửi Retry-After như thực hành tốt nhưng không giả định Googlebot tuân theo lịch đó.

4. Có chủ đích so với sai sót. 410 trên trang đã xóa hoặc 421 loại route khỏi HTTP/2 đều có thể hoạt động đúng thiết kế; 400 trên trang bạn muốn lập chỉ mục là lỗi. Hãy hỏi “URL này có cần hoạt động không, và trên protocol nào?” trước khi sửa. Nếu URL không nên hoạt động, cách sửa là ngừng liệt kê nó — sitemap, liên kết — chứ không phải làm nó trả 200.

5. 4xx là công cụ giảm tốc sai. Nếu mục tiêu là làm Googlebot chậm lại, 4xx không làm được — nó gỡ chỉ mục. Các mã “hãy quay lại sau” là 429 và 5xx/503. Chọn mã khớp ý định: “nội dung đã biến mất” — 4xx — so với “tôi đang quá tải, thử lại sau” — 429/503.

Bảng tra nhanh other-4xx

Các mã thường xuất hiện ở đây — và cách sửa từng mã (Google không công bố danh sách thành viên đầy đủ của hàng này; hãy coi bảng là các nhánh chẩn đoán cần kiểm tra sau khi biết mã thực, không phải bảo đảm.)

Các trạng thái liên quan trong Page Indexing

Chọn đúng mã theo ý định

Tìm status code thực

Nhãn GSC không cho biết bạn đang gặp mã 4xx nào; hãy kiểm tra trực tiếp. -I gửi request HEAD, không phải GET mà Google thực sự dùng để lấy trang, vì vậy kết quả chỉ xảy ra với HEAD — chẳng hạn 405 — không chứng minh GET trả gì; hãy kiểm thử cả hai.

macOS / Linux

# HEAD only — read the status line (e.g. "HTTP/1.1 410 Gone")
curl -s -I https://www.example.com/page/

# GET — reproduces the method Google actually uses to fetch page content
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

# If you suspect a bot-specific block, fetch as Googlebot's user-agent (GET)
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

Windows (PowerShell)

# GET request, matching what Google actually uses to fetch page content
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Get `
  -UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescription

Nếu mã khác nhau giữa HEAD với GET, hoặc giữa request bình thường với request dùng user-agent Googlebot, bạn đã tìm thấy quy tắc riêng theo method hoặc bot. WAF tinh vi còn có thể dựa trên IP, protocol hoặc danh mục client thay vì riêng user-agent; để tái hiện đầy đủ, hãy kiểm thử từ ngoài mạng và đừng giả định khớp user-agent chứng minh cùng quy tắc áp dụng cho lưu lượng Googlebot thật.

Xác minh bot thật sự là Googlebot — trước khi allowlist

Nếu 4xx đến từ tầng bảo mật và bạn sắp cho crawler đi qua, trước hết xác nhận đó thật sự là Googlebot. User-agent rất dễ giả mạo, và chỉ thay user-agent trong request kiểm thử không tái hiện IP nguồn, danh mục client, protocol hoặc đường đi quy tắc edge thực của Google.

macOS / Linux

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / 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 reverse lookup không kết thúc bằng domain Google hoặc forward lookup không khớp IP ban đầu, đó không phải Googlebot; đừng allowlist. Bạn cũng có thể khớp IP với dải Google công bố — googlebot.json. Chỉ allowlist theo danh tính / dải IP đã xác minh, không bao giờ theo riêng chuỗi user-agent.

Gửi Retry-After trên 429 — đừng tắt rate limit

Nếu URL thật sự bị rate limit, hãy trả 429 cùng Retry-After như thực hành HTTP tốt — thay vì tắt bảo vệ hoặc trả 4xx “thật”. Retry-After là tùy chọn theo RFC 6585 và tài liệu Google không xác nhận Googlebot lập lịch crawl kế tiếp dựa trên giá trị này, vì vậy hãy coi đây là vệ sinh hợp lý chứ không phải cách sửa đã được chứng minh. Các đoạn dưới đây là điểm khởi đầu minh họa; hãy rà soát với cấu hình server/CDN và policy bảo mật riêng trước khi triển khai.

Apache (.htaccess / config)

# Example: return 429 with a 1-hour Retry-After for rate-limited responses
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 429"

Nginx

# limit_req_status makes throttled requests return 429 instead of 503
limit_req_status 429;
# add a Retry-After hint on 429 responses
error_page 429 = @rate_limited;
location @rate_limited {
    add_header Retry-After 3600 always;
    return 429;
}

Tài nguyên đáng dành thời gian

Chính thức

• Báo cáo Page Indexing — Google — mục “other 4xx” và các trạng thái liên quan 401/403/404.
• Cách status code HTTP ảnh hưởng Google Search — Google — quy tắc mọi 4xx trừ 429, sắc thái 429 là lỗi máy chủ và “không ảnh hưởng crawl rate”.
• Don’t 404 my yum — Google, 2023 — đừng dùng 404/other-4xx để giảm tốc Googlebot.
• Xác minh Googlebot — Google — reverse DNS + dải IP công bố.

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

• Status code HTTP và tác động SEO — hướng dẫn đầy đủ của tôi về ý nghĩa từng status code với SEO, gồm các dòng 4xx, 410-so-với-404 và 429 được trích ở đây.
• Hướng dẫn Technical SEO cho người mới — vị trí của lỗi crawl/lập chỉ mục như trường hợp này trong bức tranh lớn.

Từ nguồn khác

• r/TechSEO — cộng đồng gỡ lỗi crawl/lập chỉ mục, gồm các thread về “4xx lạ trong GSC”.
• Google cảnh báo không dùng 403 hoặc 404 để giới hạn crawl rate — Search Engine Land — bài tường thuật hướng dẫn “Don’t 404 my yum” của Gary Illyes; dùng 500/503/429 thay thế.
• Google: status code 404 so với 410 — khác biệt rất nhỏ — Search Engine Roundtable — Mueller giải thích vì sao chênh lệch 410-404 không đáng kể trong thực tế.
• Google đưa ra lời khuyên về status code 404 và 410 — Search Engine Journal — nguồn tường thuật nhận xét của Mueller về tốc độ 410 so với 404; kiểm tra cách diễn đạt chính xác trên trang live trước khi trích trực tiếp.
• Cách sửa Blocked due to other 4xx issue — Onely — hướng dẫn từng bước cho các mã thường gặp, hữu ích với bước audit sitemap và internal link. Coi tuyên bố mã thuộc nhóm là cách đọc riêng của nguồn, không phải taxonomy Google đã xác nhận.
• Blocked due to other 4xx issue — SEOTesting — trình bày phân tích server log và giám sát phòng ngừa, đồng thời nêu 422, 405, 413, 414. Áp dụng cùng lưu ý với tuyên bố mã thuộc nhóm.

Tìm mã thật phía sau “other 4xx”

“Other 4xx” là nhóm hỗn hợp, nên động thái đầu tiên hữu ích duy nhất là xác định mã nào thực sự kích hoạt — đó là ý của phần chẩn đoán khi nói “xử lý như cây quyết định từ trên xuống”. Trước hết xác nhận mã live, sau đó phân nhánh theo họ mã trước khi chạm vào cấu hình.

Theo dõi nhóm “other 4xx”, không chỉ việc nhóm tồn tại

Con số đáng theo dõi là số URL nằm trong hàng “Blocked due to other 4xx issue” của báo cáo Page Indexing theo thời gian. Snapshot riêng lẻ không cho biết cách sửa có hiệu quả hay mã lỗi ngoài ý muốn mới đang phát sinh, nhất là khi nhóm trộn nguyên nhân có chủ đích với ngoài ý muốn.

Số lượng trong nhóm other-4xx theo thời gian

• Chỉ số — Số URL trong “Blocked due to other 4xx issue” của báo cáo Page Indexing GSC, theo dõi từng tuần và lý tưởng được chia theo status code thực sau khi xác định từng URL.
• Ý nghĩa — Cho biết cách sửa request/validation — 400/405/411/413/422 — và allowlist WAF/CDN thực sự có hiệu lực không. Với URL có mã thực là 410 có chủ đích, số lượng của chính các URL đó nên ổn định sau khi dọn sitemap/internal link; số tăng thường nghĩa trang “đã xóa” mới vẫn bị liên kết hoặc đưa vào sitemap nhầm, không phải lỗi mới.
• Cách lấy — Báo cáo Page Indexing GSC lọc hàng “other 4xx”; kiểm tra URL riêng bằng URL Inspection → Test live URL để xác nhận báo cáo không hiển thị snapshot cũ.
• Benchmark / khoảng thực tế — Không có mục tiêu phổ quát; phụ thuộc hoàn toàn số URL bạn cố ý trả 410 — hoặc tương tự. Ngưỡng trung thực: không other-4xx trong URL cần lập chỉ mục và số lượng ổn định — không tăng — với URL đã chủ ý xóa. Thiết lập baseline riêng trước khi đánh giá hướng xu thế.
• Nhịp đo — Hằng tuần ngay sau khi sửa cho tới khi số lượng ổn định; hằng tháng sau đó để kiểm tra hồi quy, nhất là khi dựa vào WAF/CDN có quy tắc thay đổi độc lập với deploy.

Runbook: xác định, sửa, xác thực

Workflow “other 4xx” là cùng một vòng lặp ngắn cho mọi URL trong nhóm, bất kể mã cụ thể phía sau; trước hết xác định mã thật vì cách sửa rẽ nhánh mạnh từ đó.

1. Xác nhận mã live. Chạy URL Inspection → Test live URL để xác nhận Google hiện nhận 4xx và xem response — riêng hàng báo cáo có thể đã cũ, đồng thời live test thất bại không phải lúc nào cũng hiển thị raw header. Đối chiếu với báo cáo Crawl Stats để lấy ví dụ đại diện về response crawler theo lịch thực sự nhận.

2. Tái hiện, khớp request ban đầu. Mở URL trong tab Network của DevTools hoặc dùng curl; kiểm thử method GET, không chỉ curl -I — gửi HEAD và có thể cho kết quả khác. Nếu nghi quy tắc riêng cho bot, fetch bằng user-agent Googlebot, lý tưởng từ ngoài mạng, để kích hoạt cùng quy tắc lượt crawl thật có thể gặp; nhưng chỉ đổi user-agent không tái hiện IP, protocol hay danh mục client thực của Google.

3. Đọc log. Kiểm tra log server, CDN, WAF và auth proxy để tìm mã chính xác cùng quy tắc hoặc điều kiện tạo ra mã. Cách này thường nhanh hơn đoán từ trình duyệt và hay là cách duy nhất xem raw response data mà live test không hiển thị.

4. Ánh xạ mã với nguyên nhân. 400/405/408/414 → vấn đề framing, method, timeout hoặc chiều dài URI của request. 411/413/415/422 → chỉ chẩn đoán là lỗi nội dung request khi có bằng chứng về method/body Google thực sự gửi. 410 → xóa có chủ đích — xác nhận URL cần biến mất. Với 421, hãy xác minh cách Google dùng mã để opt out HTTP/2 và response fallback HTTP/1.1. 451 → rà soát pháp lý/policy. 4xx từ tầng bảo mật → điểm chặn cần allowlist hẹp. Mã lẽ ra là 429 → rate limit được xử lý như tải máy chủ; vị trí báo cáo chưa được xác nhận theo cả hai hướng.

5. Sửa theo nguyên nhân. Lỗi framing request → sửa nguồn — URL xấu/quá dài, method sai, timeout — và ngừng liên kết/liệt kê URL xấu. Lỗi nội dung request → xác nhận request thực từ log trước khi nới giới hạn. 410 có chủ đích hoặc 421 opt-out → giữ nguyên, chỉ dọn sitemap/internal link — 410 — hoặc xác nhận protocol fallback — 421. 451 → chuyển tới rà soát pháp lý/policy. Điểm chặn tầng bảo mật → xác minh Googlebot thật — reverse DNS hoặc dải IP công bố — và allowlist hẹp theo danh tính/route, không theo user-agent hay quy tắc bao quát. 429/rate limit → giữ rate limit, thêm Retry-After như thực hành tốt — tùy chọn theo RFC 6585, không phải lịch Googlebot đã xác nhận; nếu quy tắc trả 4xx cho Googlebot chỉ để giảm tốc, đổi sang 429 hoặc 503.

6. Xác thực rồi dừng. Xác nhận Test live URL nay trả 200 với trang cần lập chỉ mục, sau đó chọn Validate Fix trên hàng “other 4xx” và/hoặc yêu cầu lập chỉ mục URL ưu tiên. Response 200 làm URL đủ điều kiện để Google crawl lại và có thể lập chỉ mục lại; không bảo đảm kết quả hay thời gian cố định. Đừng yêu cầu hàng loạt trước khi nguyên nhân gốc thực sự được sửa, nếu không URL chỉ quay lại cùng nhóm.

Prompt AI dùng ngay

Các prompt có thể sao chép để phân loại mã “other 4xx” đang gặp và cách sửa phù hợp từ đầu ra chẩn đoán thô. Luôn xác nhận kết luận với cấu hình server/WAF thực trước khi thay đổi.

Phân loại mã và nguyên nhân từ đầu ra curl

I'm diagnosing a "Blocked due to other 4xx issue" status in Google Search
Console. Below is the raw output of GET and HEAD requests to the URL (note
that curl -I alone only tests HEAD, which can differ from what Google's GET
request receives). Tell me the exact status code, and classify the likely
cause as one of: (1) a request-framing/timeout/URI-length issue (400, 405,
408, 414), (2) a request-content condition needing body evidence (411, 413,
415, 422), (3) an intentional 410 Gone, (4) a possible HTTP/2 opt-out (421),
(5) a legal/policy block (451), (6) a WAF/CDN/security-plugin block, or (7) a
mislabeled 429 rate limit. Explain which detail in the output pointed you to
that answer, and flag anything you can't determine from this output alone.

CURL OUTPUT (GET and HEAD):
[paste]

Phân loại một dòng log WAF/server

I'm investigating an "other 4xx" status Googlebot is hitting on a page I want
indexed. Below is a log line (or a few) from my server/CDN/WAF showing the
blocked request. Tell me whether this looks like a bot-identity rule
(user-agent or IP based), a rate-limit/challenge rule that should really be
returning 429, or a request/validation error, and what I'd need to change or
allowlist to fix it without disabling the underlying protection.

LOG LINE(S):
[paste]

Kiểm tra nhanh cách sửa trước khi triển khai

I'm about to change how a URL responds because it's currently returning
[status code] and showing as "Blocked due to other 4xx issue" in Search
Console. Here's what I'm about to change: [describe]. Point out anything I
might be missing — for example, whether this could accidentally expose or
re-index a page that's supposed to stay gone (a 410 I'm about to undo), or
whether I should allowlist verified Googlebot instead of loosening a security
rule for everyone.

Tự kiểm tra: “Blocked due to other 4xx issue”

Năm câu hỏi về ý nghĩa nhóm “other 4xx”, ngoại lệ 429 và cách chẩn đoán/sửa. Chọn đáp án cho từng câu rồi kiểm tra.

Công cụ chẩn đoán và sửa trạng thái “other 4xx”

• HTTP Status Checker — dán URL bị ảnh hưởng — hoặc một nhóm — để xác nhận status code thực phía sau nhãn GSC, xem toàn bộ chuỗi response và phát hiện redirect xảy ra trước 4xx.
• Googlebot Verifier — kiểm tra IP tự nhận là Googlebot có hợp lệ không — dải IP công bố cùng reverse DNS — trước khi allowlist qua WAF, CDN hoặc plugin bảo mật.
• Google Search Console — URL Inspection → Test live URL — cách gần nhất để xem response chính xác Googlebot nhận ngay lúc này thay vì hàng báo cáo có thể đã cũ.
• curl -I — cách nhanh nhất đọc raw status line của URL và fetch lại bằng user-agent Googlebot nếu nghi quy tắc riêng cho bot.
• Dashboard log server/CDN/WAF — Cloudflare, Akamai, Sucuri, log riêng của plugin bảo mật, v.v. — để tìm mã chính xác cùng quy tắc hoặc điều kiện tạo ra nó.

Vấn đề thường gặp theo từng mã

Mỗi mã xuất hiện trong “other 4xx” là một tình huống triệu chứng-nguyên nhân-cách-sửa độc lập; nhóm không có nguyên nhân gốc duy nhất, vì vậy hãy coi đây là các thẻ tra cứu riêng thay vì một chuỗi.

400 Bad Request

Triệu chứng: URL bị ảnh hưởng trả 400 cho một request.

Nguyên nhân có khả năng: Request target sai hoặc encode kém, vấn đề cú pháp hay framing Host/routing khiến app hoặc edge từ chối hoàn toàn — tham số query xấu, ký tự không hợp lệ, routing ngoài dự kiến.

Cách sửa + kiểm tra: So sánh request chính xác máy chủ nhận với điều bạn định tạo; sửa URL và ngừng tạo/liên kết phiên bản hỏng. Kiểm tra lại bằng request GET — không chỉ curl -I, vốn là HEAD — cho tới khi trả 200.

405 — Method không được phép

Triệu chứng: URL trả 405 cho một số request dù chính trang có vẻ hoạt động trong trình duyệt.

Nguyên nhân có khả năng: HTTP method dùng cho route không được phép — thường là quy tắc server/CDN chỉ cho phép GET trên đường dẫn nhưng có request gửi HEAD hoặc method khác bị từ chối. Kiểm tra header Allow của response để biết method được phép, và đừng giả định lỗi chỉ xảy ra với HEAD — như curl -I — chứng minh GET cũng thất bại.

Cách sửa + kiểm tra: Cho phép method đúng trên route. Kiểm thử lại cả HEAD và GET.

408 Request Timeout

Triệu chứng: URL thỉnh thoảng trả 408 hoặc kết nối treo trước khi có status.

Nguyên nhân có khả năng: Kết nối hoặc request không hoàn tất trong cửa sổ timeout của server, proxy hoặc CDN — đây là vấn đề timing/kết nối, không phải bằng chứng máy chủ ngừng hoạt động chung.

Cách sửa + kiểm tra: Đối chiếu timing kết nối/request trên toàn chuỗi proxy/CDN/origin và protocol đang dùng. Kiểm thử lại sau khi điều chỉnh timeout liên quan hoặc sửa đường origin chậm.

410 Gone

Triệu chứng: URL trả 410, và số lượng “other 4xx” gồm các trang bạn khá chắc đã cố ý xóa.

Nguyên nhân có khả năng: Xóa có chủ đích — hoạt động đúng thiết kế với trang cần biến mất. Nếu trang cần hoạt động, 410 là sai sót.

Cách sửa + kiểm tra: Nếu có chủ đích, xóa URL khỏi sitemap/internal link để nó ngừng xuất hiện như “vấn đề”. Nếu không, khôi phục trang.

411 Length Required

Triệu chứng: URL trả 411 trên một số request.

Nguyên nhân có khả năng: Máy chủ yêu cầu header Content-Length trên request có body — bất thường với GET trang thông thường. Xác nhận từ log rằng request thực sự có nội dung trước khi giả định đây là vấn đề crawl thường lệ.

Cách sửa + kiểm tra: Trước hết xác nhận method và body thực; nới hoặc sửa yêu cầu phía server, hoặc bảo đảm request có header. Sau đó kiểm thử lại với cùng method/nội dung.

413 Payload Too Large

Triệu chứng: URL trả 413, thường trên request có body hoặc header/cookie lớn.

Nguyên nhân có khả năng: Nội dung request vượt giới hạn kích thước do server, CDN hoặc WAF đặt ra — vấn đề nằm ở request đầu vào, không phải kích thước response của chính trang.

Cách sửa + kiểm tra: Xác nhận request đầu vào từ log trước khi tăng giới hạn; sửa phần tạo request quá lớn hoặc chỉ tăng giới hạn nếu nó thực sự quá gắt với request hợp lệ. Kiểm thử lại để xác nhận request kích thước bình thường nay trả 200.

414 URI Too Long

Triệu chứng: URL trả 414, thường với URL dài được tạo hoặc có nhiều tham số.

Nguyên nhân có khả năng: Bản thân URI request vượt giới hạn chiều dài — thường do quá trình tạo tham số hoặc chuỗi redirect sai, không phải vấn đề nội dung trang.

Cách sửa + kiểm tra: Sửa quá trình tạo URL/redirect tận nguồn thay vì tăng giới hạn mù quáng, đồng thời dọn mọi mục sitemap/internal link trỏ tới mẫu quá dài.

415 / 422 — Loại media không được hỗ trợ / Không thể xử lý thực thể

Triệu chứng: URL trả 415 hoặc 422 dù request trông hợp lệ trong trình duyệt.

Nguyên nhân có khả năng: Máy chủ hiểu request nhưng từ chối content type hoặc validation thất bại trên nội dung/chỉ thị — không điển hình với GET trang thông thường. Xác nhận nội dung request thực trước khi giả định đây là vấn đề nội dung trang chung.

Cách sửa + kiểm tra: Xác nhận request từ log rồi sửa quy tắc validation hoặc xử lý content type, hay sửa phần tạo request bị từ chối. Kiểm thử lại cho tới khi response là 200.

421 Misdirected Request

Triệu chứng: URL trả 421, đôi khi chỉ qua HTTP/2.

Nguyên nhân có khả năng: Kết nối bị chuyển sai — nhưng Google cũng ghi nhận việc trả 421 là cách chủ ý loại route khỏi crawl HTTP/2, nên không tự động nghĩa trang hỏng.

Cách sửa + kiểm tra: Xác nhận request có fallback sang HTTP/1.1 không và response cuối là gì. Nếu đây là HTTP/2 opt-out có chủ đích, không cần sửa; nếu không có fallback và trang không truy cập được trên mọi protocol, hãy sửa routing kết nối / xử lý SNI/Host.

451 — Không khả dụng vì lý do pháp lý

Triệu chứng: URL trả 451.

Nguyên nhân có khả năng: Điểm chặn do pháp lý hoặc policy, có thể hoàn toàn có chủ đích — chẳng hạn nội dung bị hạn chế ở một số khu vực pháp lý; đừng coi là cấu hình geo/WAF thông thường.

Cách sửa + kiểm tra: Chuyển tới người phụ trách quyết định pháp lý hoặc content policy để xác nhận điểm chặn có chủ đích. Nếu có, hệ thống hoạt động đúng; dọn sitemap/liên kết trỏ tới URL. Nếu không, gỡ điểm chặn.

429 bị nhầm là “other 4xx”

Triệu chứng: Bạn dự kiến tìm 4xx bình thường nhưng mã thực lại là 429.

Nguyên nhân có khả năng: Rate limit kích hoạt trên request Googlebot. Google xử lý 429 như tín hiệu máy chủ quá tải, không phải lỗi client như phần còn lại của nhóm, nên 429 thực có khả năng được báo là vấn đề crawl/server thay vì giữ nhãn “other 4xx”. Tuy nhiên, tài liệu Google nói về hành vi xử lý chứ không phải taxonomy báo cáo; hãy coi vị trí chính xác là chưa xác nhận.

Cách sửa + kiểm tra: Đừng tắt rate limit hợp lệ; thêm header Retry-After như thực hành tốt — tùy chọn theo RFC 6585; Google không xác nhận Googlebot dùng header để lập lịch crawl kế tiếp. Nếu quy tắc trả 4xx cho Googlebot chỉ để giảm tốc, đổi quy tắc sang 429 hoặc 503.

Chứng minh cách sửa thực sự hiệu quả

Sau khi sửa lỗi request/validation, dọn 410 có chủ đích, allowlist Googlebot đã xác minh hoặc xác nhận rate limit được xử lý đúng, các phép thử sau tách “cấu hình đã đổi” khỏi “Google nay thực sự truy cập được trang”. Chạy theo thứ tự.

Kiểm tra 1 — Request mới nay trả status mong đợi

• Kiểm tra cần chạy — Chạy curl với request GET trên URL bị ảnh hưởng — khớp method Google thực sự dùng; riêng curl -I chỉ kiểm thử HEAD — hoặc dùng HTTP Status Checker.
• Kết quả mong đợi — Với trang cần lập chỉ mục, status line là HTTP/1.1 200 OK. Với trang chủ ý bị xóa, status có thể tiếp tục là 410; phép thử quan trọng ở đó là Kiểm tra 3.
• Diễn giải khi thất bại — Vẫn là 4xx ban đầu nghĩa cách sửa chưa thật sự áp dụng cho đường dẫn hoặc bạn kiểm thử sai URL/môi trường. Mã 4xx khác trước — chẳng hạn 400 thành 403 — nghĩa bạn đổi một điểm chặn lấy điểm chặn khác; kiểm tra quy tắc WAF/CDN.
• Khoảng theo dõi — Ngay lập tức; máy chủ trả lời khi thay đổi hoạt động.
• Điều kiện rollback — Nếu nới quy tắc validation hoặc kích thước mở hành vi ngoài ý muốn, khôi phục quy tắc cũ và sửa nguyên nhân gốc theo cách khác — chẳng hạn sửa request thay vì tăng giới hạn.

Kiểm tra 2 — Google xác nhận nay có thể truy cập trang

• Kiểm tra cần chạy — Chạy URL Inspection → Test live URL trong Google Search Console trên URL bị ảnh hưởng.
• Kết quả mong đợi — Với trang cần lập chỉ mục, live test thành công và hiển thị 200, không báo 4xx.
• Diễn giải khi thất bại — Nếu Test live URL vẫn báo 4xx sau khi phép thử curl ẩn danh đạt, hãy nghi quy tắc giới hạn riêng cho dải IP Googlebot — vấn đề allowlist WAF/CDN — thay vì vấn đề request chung.
• Khoảng theo dõi — Ngay lập tức tới vài phút sau khi sửa.
• Điều kiện rollback — Không áp dụng; đây là phép thử chỉ đọc. Nếu vẫn thất bại, quay lại nhánh lỗi của Kiểm tra 1 thay vì rollback.

Kiểm tra 3 — Trạng thái biến mất — hoặc giữ ổn định có chủ đích — trong báo cáo Page Indexing

• Kiểm tra cần chạy — Dùng Validate Fix trên hàng “Blocked due to other 4xx issue” trong báo cáo Page Indexing và theo dõi số lượng nhóm trong các tuần tiếp theo — xem tab How to Measure.
• Kết quả mong đợi — URL đã sửa đủ điều kiện rời nhóm sau khi Google crawl lại response 200; điều này không bảo đảm được lập chỉ mục lại hay thời gian cụ thể, chỉ là đủ điều kiện. URL có 410 chủ đích vẫn nằm trong nhóm, nhưng sitemap/internal link không còn trỏ tới.
• Diễn giải khi thất bại — Không có nhịp retry công bố, nên đừng coi validation chậm là lỗi mới. Nếu số lượng không có xu hướng giảm sau vài tuần với URL thực sự đã sửa, chạy lại Kiểm tra 1 để xác nhận cách sửa vẫn hoạt động — redeploy hoặc cache CDN có thể âm thầm đưa quy tắc cũ trở lại.
• Khoảng theo dõi — Vài ngày tới vài tuần, theo dõi qua số lượng nhóm.
• Điều kiện rollback — Chỉ xem lại cách sửa nền tảng nếu Kiểm tra 1 bắt đầu thất bại; đừng đuổi theo timing của báo cáo Page Indexing.

Nhật ký thay đổi