Ngôn ngữ

Bị chặn do quyền truy cập bị cấm (403)

Trạng thái “Blocked due to access forbidden (403)” trong báo cáo Page Indexing của Google Search Console nghĩa là gì, vì sao Googlebot nhận 403 còn trình duyệt không, khác 401 ra sao và cách chẩn đoán, sửa, xác thực.

Xuất bản lần đầu: 23 thg 6, 2026 · Cập nhật lần cuối: 9 thg 8, 2026 · Advanced
Ngôn ngữ
AIĐược viết bởiAI v2
2 tín hiệu bằng chứng trên trang này

“Blocked due to access forbidden (403)” trong báo cáo Page Indexing GSC nghĩa là Googlebot crawl URL và máy chủ trả HTTP 403. Google không lập chỉ mục — và loại URL nếu trước đây đã lập chỉ mục. Trợ giúp Page Indexing của Google mô tả 403 là đã cung cấp thông tin xác thực nhưng bị từ chối; đó là cách diễn đạt riêng của báo cáo, không phải định nghĩa HTTP đầy đủ. RFC 9110 định nghĩa 403 rộng hơn và có thể không liên quan thông tin xác thực. Nếu URL cần công khai và lập chỉ mục, hãy coi 403 là lỗi cần tìm; nếu cần riêng tư, 403 có thể làm đúng nhiệm vụ và bạn nên sửa tín hiệu discovery. Với URL cần công khai, firewall, CDN hoặc WAF là thủ phạm thường được báo cáo, khiến trang tải trong trình duyệt nhưng trả 403 cho Google. Google xử lý 401 và 403 giống nhau khi lập chỉ mục và nói không dùng hai mã để giới hạn crawl rate; hãy dùng 429 hoặc 503. Xác minh Googlebot thật — reverse DNS / dải IP công bố / đúng danh mục client — trước khi allowlist, giới hạn ngoại lệ hẹp, rồi xác nhận 200 trong URL Inspection và dùng Validate Fix.

Tóm tắt — 403 trong báo cáo Page Indexing nghĩa là Googlebot nhận HTTP 403 trên URL nên Google không lập chỉ mục — và loại URL nếu trước đây đã lập chỉ mục. Trợ giúp Page Indexing của Google mô tả 403 là đã cung cấp thông tin xác thực nhưng bị từ chối; đây là cách diễn đạt của báo cáo Google, không phải định nghĩa HTTP đầy đủ. RFC 9110 định nghĩa 403 rộng hơn là “đã hiểu nhưng từ chối,” có hoặc không có thông tin xác thực; hãy coi cách diễn đạt Google là heuristic, không phải bằng chứng cấu hình sai. Trước hết quyết định URL có cần công khai và được lập chỉ mục hay không. Với URL cần công khai, firewall/CDN/WAF vô tình chặn Googlebot là nguyên nhân thường được báo cáo, khiến trang tải với bạn nhưng trả 403 cho Google; còn 403 trên URL cần riêng tư có thể hoạt động đúng chủ đích. Google xử lý 401 và 403 giống nhau khi lập chỉ mục, đồng thời nói rõ đừng dùng 401/403 để giới hạn crawl rate — hãy dùng 429 hoặc 503. Xác minh Googlebot thật — reverse DNS / dải IP công bố / đúng danh mục client — trước khi allowlist; giới hạn ngoại lệ ở route và quy tắc cụ thể; sau đó xác nhận 200 trong URL Inspection → Test live URL và chạy Validate Fix.

Google thực sự nói gì về 403 — và HTTP thực sự nói gì

Nhãn báo response đã quan sát, không phải WAF, CDN hoặc quy tắc truy cập cụ thể tạo ra response. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report Hệ quả lập chỉ mục đi theo cách Google xử lý 4xx nói chung. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: HTTP status codes

Tài liệu báo cáo Page Indexing của Google mô tả như sau: HTTP 403 nghĩa là user agent đã cung cấp thông tin xác thực nhưng không được cấp quyền truy cập; tuy nhiên Googlebot không bao giờ cung cấp thông tin xác thực, nên theo cách Google diễn đạt, máy chủ đang trả lỗi không đúng. Trang sẽ không được lập chỉ mục. Nếu muốn lập chỉ mục, cách sửa Google đưa ra là cho phép người dùng chưa đăng nhập hoặc cho phép rõ ràng request Googlebot mà không cần xác thực.

Tuy nhiên, đó là cách trình bày của tài liệu trợ giúp Google, không phải định nghĩa HTTP hoàn chỉnh. RFC 9110 — đặc tả ngữ nghĩa HTTP hiện hành — định nghĩa 403 rộng hơn: “the server understood the request but refuses to fulfill it,” (bản dịch) “máy chủ hiểu request nhưng từ chối thực hiện,”. Thông tin xác thực có thể liên quan, nhưng RFC nói rõ request có thể bị cấm vì lý do hoàn toàn không liên quan thông tin xác thực: policy, quy tắc kiểm soát truy cập, quyết định bảo mật edge hoặc bất cứ điều gì chủ máy chủ quyết định. Vì vậy, kết luận hữu ích không phải “403 cho Googlebot theo định nghĩa luôn nghĩa quy tắc hỏng,” mà là “xác định URL này có cần truy cập được không rồi tìm chính xác quy tắc trả 403.” Với trang cần công khai và lập chỉ mục, 403 cho Googlebot hầu như luôn là lỗi cần sửa. Với trang chủ ý riêng tư hoặc bị cấm, 403 có thể là quyết định truy cập hợp lệ; vấn đề thường là Google lẽ ra không nên phát hiện URL — xem phần kiểm tra mục đích — chứ không phải firewall sai.

Dù thuộc trường hợp nào, tài liệu status code HTTP riêng của Google nói thẳng về hệ quả lập chỉ mục: Google không dùng nội dung từ URL trả 4xx; mọi lỗi 4xx trừ 429 được xử lý giống nhau — crawler nói với hệ thống tiếp theo rằng nội dung không tồn tại; pipeline lập chỉ mục loại URL khỏi chỉ mục nếu trước đây đã lập chỉ mục.

Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: HTTP status codes

Quyết định URL cần làm gì trước khi sửa

Không phải mọi hàng trong báo cáo đều cần cùng cách sửa. Trước tiên chia URL vào một trong bốn nhóm:

  1. Công khai và cần lập chỉ mục. 403 không có chủ đích; đi qua vòng chẩn đoán → sửa → xác thực phía dưới.
  2. Công khai nhưng không cần lập chỉ mục. Đừng dùng robots.txt để giải quyết. Directive disallow trong robots.txt là cổng crawl riêng với lý do Page Indexing riêng — “blocked by robots.txt”; tự nó không tạo HTTP 403 mà trạng thái này báo. Hãy phục vụ response 200 bình thường và dùng directive noindex — hoặc redirect/xóa đúng cách.
  3. Chủ ý riêng tư hoặc bị cấm. 403 có thể là kết quả chính xác cho tài nguyên requester không được truy cập. Nếu xuất hiện trong báo cáo, vấn đề có thể hành động thường là URL có thể được phát hiện — trong sitemap, liên kết nội bộ hoặc nơi khác — không phải quy tắc truy cập sai. Dọn tín hiệu discovery thay vì mở cửa.
  4. URL không nên tồn tại hoặc bạn không muốn xác nhận sự tồn tại. Chọn response theo policy bảo mật ứng dụng, không theo lối tắt SEO. Cả 403 và 404 — nếu không muốn xác nhận URL tồn tại — đều có thể hợp lệ.
Evidence for this claim A robots.txt disallow is a separate crawl gate and Page indexing reason; it does not itself generate the HTTP 403 response required for the Blocked due to access forbidden (403) reason. Scope: verified Search Console properties Confidence: high · Verified: Page indexing report

Mọi phần từ đây giả định trường hợp 1: URL bạn thật sự muốn crawl và lập chỉ mục.

403 so với 401 — cách phân biệt

Hai trạng thái này liên quan trong báo cáo; phần lớn bài viết làm mờ bằng quy tắc kinh nghiệm — “403 = không yêu cầu thông tin xác thực, 401 = login wall” — vốn không đủ đáng tin. Tầng auth cấu hình sai cũng có thể trả 403 và vẫn nằm ở hàng này. Chính response mới là tín hiệu thật:

  • 401 — unauthorized — theo RFC 9110, 401 cụ thể nghĩa là thiếu thông tin xác thực hợp lệ và response bắt buộc có header challenge WWW-Authenticate — HTTP auth, login wall. Google được báo cần xác thực nhưng không thể.
  • 403 — access forbidden — một dạng từ chối rộng hơn. RFC 9110 định nghĩa là “máy chủ hiểu request nhưng từ chối thực hiện,” có hoặc không có thông tin xác thực. Trong thực tế, hàng này thường là firewall/CDN/WAF hoặc quy tắc bảo mật chặn, nhưng cũng có thể là ứng dụng trả 403 từ kiểm tra auth hỏng, rate limiter hoặc quyết định kiểm soát truy cập có chủ đích.
Evidence for this claim A 401 response means valid authentication credentials are missing and must include a WWW-Authenticate challenge; a 403 is a refusal that can occur with or without credentials. Scope: 401 and 403 responses Confidence: high · Verified: RFC 9110: HTTP Semantics

Để thật sự phân biệt trên một URL, hãy kiểm tra status và header trả về — response có header WWW-Authenticate không? — thay vì suy ra cơ chế chỉ từ nhãn báo cáo. Hai mã có cùng kết quả — không lập chỉ mục — và thường cùng cách sửa — cho Googlebot đã xác minh đi qua hoặc mở nội dung cho người dùng ẩn danh. Khi biết đang gặp mã nào, cùng vòng chẩn đoán phía dưới áp dụng cho cả hai hàng.

403 làm gì với việc lập chỉ mục

Ba điều xảy ra khi Googlebot nhận 403:

  1. Nội dung bị bỏ qua. Google không dùng nội dung từ URL 4xx, nên không phần nào trên trang được lập chỉ mục.
  2. URL bị loại nếu trước đây đã lập chỉ mục. 403 có thể deindex trang từng xếp hạng; đây không chỉ là vấn đề “không được thêm” mà còn là “bị loại.”
  3. Tần suất crawl giảm dần. Theo thời gian Google crawl URL 4xx ít hơn, nên 403 kéo dài được truy cập thưa hơn và phục hồi chậm hơn khi bạn sửa.

Vì sao Googlebot nhận 403 còn trình duyệt không

Đây là câu hỏi khiến mọi người đi vòng. Trang tải trong trình duyệt nên nội dung rõ ràng bình thường, nhưng Google báo 403. Giải thích có khả năng là trình duyệt và Googlebot tạo request rất khác nhau; quy tắc quản lý bot nhằm chặn scraper có thể kích hoạt với crawler nhưng phục vụ người dùng bình thường. Tuy nhiên, hãy coi đó là giả thuyết cần xác nhận, không phải kết luận sẵn, vì thuộc tính thật sự quan trọng khác nhau theo website:

  • Trình duyệt gửi cookie, user-agent trình duyệt thật và có thể giải JS/CAPTCHA challenge; request Googlebot thường không có những phần đó — không cookie, user-agent crawler, không thể giải challenge tương tác. Tuy vậy, Google-InspectionTool có kết xuất JavaScript và báo đầu ra đã kết xuất, nên “Googlebot has no JavaScript” (bản dịch) “Googlebot không có JavaScript” không chính xác trong mọi khía cạnh.
  • Ngoài khác biệt phía client, hai request còn có thể khác về IP nguồn/danh mục, địa lý, method, referrer, trạng thái cache và quy tắc thật sự kích hoạt; bất kỳ thuộc tính nào cũng có thể là trigger thật.

Đừng đoán thuộc tính gây lỗi. So sánh chính xác log edge và origin của một request bị chặn thật với lượt trình duyệt bình thường: cùng rule ID, response header, method, UA, IP nguồn cùng danh mục đã xác minh, geo, cookie, referrer, trạng thái cache và kết quả challenge. Thay đổi từng thuộc tính một cho tới khi tìm được thuộc tính làm response đổi. Đó là cách xác nhận 403 có chọn lọc thay vì chỉ giả định.

Nguyên nhân phổ biến

  • Quản lý bot CDN / WAF. Cloudflare — Bot Fight Mode / Super Bot Fight Mode, Browser Integrity Check, Managed Challenge — Akamai, Imperva/Incapsula, Sucuri, AWS WAF có thể challenge hoặc trả 403 cho client không phải trình duyệt, gồm Googlebot. Với URL cần công khai, đây là một trong các nguyên nhân được báo cáo thường xuyên nhất và hầu như luôn ngoài ý muốn, dù không có số liệu độc lập xác minh tỷ trọng.
  • Firewall máy chủ / quy tắc bảo mật. mod_security / OWASP CRS, fail2ban hoặc firewall cấp host gắn mẫu Googlebot là lạm dụng.
  • Quy tắc user-agent / referrer / hotlink. Quy tắc trả 403 cho request thiếu user-agent hoặc referrer giống trình duyệt.
  • Chặn địa lý / IP. Loại dải IP Googlebot crawl — chủ yếu từ IP Hoa Kỳ — nên country block có thể âm thầm bắt bot.
  • Login / credential wall. Yêu cầu cookie hoặc đăng nhập để xem nội dung lẽ ra công khai; trùng với trường hợp 401.
  • Quy tắc rate limit trả 403 sau N request. Đừng làm vậy; xem phần dưới.

Đừng dùng 403 để giảm tốc Googlebot

Đây là anti-pattern đáng gọi tên. Một số người — và CDN — trả 403 hoặc 404 để làm Googlebot chậm lại và giảm tải máy chủ. Google nói rõ cách này không hoạt động và không nên dùng: đừng dùng status code 401 và 403 để giới hạn crawl rate. Chúng không ảnh hưởng crawl rate mà chỉ deindex trang. Nếu thật sự cần Googlebot chậm lại, hãy trả 429 — hoặc 5xx như 503; đó là mã Google hiểu là “chậm lại,” với tác động tạm thời chứ không vĩnh viễn.

Cách chẩn đoán

  1. URL Inspection → Test live URL. Chạy URL bị ảnh hưởng qua Search Console và dùng Test live URL để xác nhận Google hiện nhận 403 — không phải báo cáo cũ. Lưu ý phép thử dùng Google-InspectionTool, một client Google cụ thể; live test đạt chỉ cho biết InspectionTool đi qua tại thời điểm đó, không chứng minh common Googlebot theo lịch sẽ đi chính xác cùng đường WAF, geo, cache hoặc rate-limit ở lần crawl sau.
  2. Tái hiện như Googlebot. Đừng kiểm tra từ trình duyệt bình thường; fetch URL với user-agent Googlebot, lý tưởng là từ bên ngoài mạng và nhiều khu vực — Google chủ yếu crawl từ IP Hoa Kỳ nhưng có thể chuyển sang quốc gia khác nếu request Hoa Kỳ bị chặn, nên đạt ở một vùng không chứng minh quyền truy cập toàn cầu. Lệnh nằm trong tab Scripts.
  3. Đọc log CDN / WAF / firewall. Tìm quy tắc chính xác kích hoạt trên request Googlebot; so sánh response header, rule ID và trigger — user-agent, IP, challenge, rate limit — với log lượt trình duyệt bình thường thay vì giả định thuộc tính nào gây ra.
  4. Xác minh Googlebot thật — và danh mục client. Trước khi allowlist, xác nhận request thật sự là Googlebot bằng reverse + forward DNS hoặc dải IP Google công bố, đồng thời kiểm tra client Google nào gửi request. Common Googlebot, crawler trường hợp đặc biệt và fetcher do người dùng kích hoạt — như Google-InspectionTool — dùng hostname mask và danh sách IP khác nhau; xác minh với sai danh sách có thể khiến request thật trông như giả.

Cách sửa

  • Tạo ngoại lệ hẹp cho Googlebot đã xác minh trong WAF / firewall, theo danh tính đã xác minh — reverse + forward DNS, khớp đúng danh mục client — hoặc dải IP crawler Google hiện hành; không chỉ tin user-agent. Giữ ngoại lệ hẹp ở route cần thiết và quy tắc đang chặn, thay vì cho phép mọi thứ từ Google. Giữ nguyên kiểm soát bảo mật, rate limit và logging khác, đồng thời đặt ngày hết hạn/xem lại để allowlist cũ không âm thầm tồn tại quá lý do. Yêu cầu nhà cung cấp CDN/firewall xác nhận Googlebot được phép và tự động kiểm tra quy tắc chặn với subnet IP Google hiện hành để cập nhật dải IP sau này không âm thầm chặn lại.
  • Mở nội dung công khai cho người dùng ẩn danh. Nếu 403 xuất phát từ yêu cầu login/cookie trên nội dung cần công khai, hãy bỏ yêu cầu đó — đây cũng là cách sửa chung với trạng thái 401.
  • Đổi rate limit 403 thành 429. Nếu quy tắc trả 403 sau ngưỡng request, đổi sang 429 — hoặc 503 — để Googlebot hiểu là “chậm lại” thay vì “biến mất.”

Xác thực cách sửa và lập chỉ mục lại

Sau khi sửa quy tắc, URL phải trả 200. Tiếp theo:

  1. URL Inspection → Test live URL để xác nhận response trực tiếp nay là 200.
  2. Request indexing cho URL ưu tiên và/hoặc nhấp Validate Fix trên hàng “Blocked due to access forbidden (403)” trong báo cáo Page Indexing.
  3. Lập chỉ mục lại diễn ra tự động khi Google crawl lại response 200; không có bảo đảm chính thức về tốc độ chính xác và URL vẫn phải vượt một lần crawl bình thường trước khi xuất hiện lại. Bạn không cần kích hoạt thủ công ngoài việc gỡ chặn, xác nhận response khỏe và cho Google thời gian crawl lại.
Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report

Để hiểu bức tranh lớn hơn về các lý do không lập chỉ mục và cách báo cáo nhóm chúng, xem tổng quan Page Indexing; trạng thái liên quan “Blocked due to unauthorized request (401)” là phiên bản 401 của cùng vấn đề.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.