Cách xử lý lỗi “Blocked due to unauthorized request (401)” trong Google Search Console

Lỗi “Blocked due to unauthorized request (401)” là gì?

Lỗi HTTP 401 xuất hiện khi một trang web yêu cầu xác thực danh tính (authentication) nhưng yêu cầu truy cập lại thiếu thông tin xác thực (credentials) hợp lệ như tài khoản, cookie phiên làm việc hoặc token truy cập.

Cần lưu ý rằng Googlebot thông thường không thể tự đăng nhập bằng tài khoản người dùng. Do đó, việc quản trị viên vẫn mở được trang nhờ phiên đăng nhập sẵn có không đồng nghĩa với việc trang đó đã được công khai hoàn toàn cho các công cụ tìm kiếm.

Ảnh hưởng đến SEO

Cần phân biệt crawling (thu thập dữ liệu) với indexing (lập chỉ mục). Khi nhận 401, Googlebot sẽ:

• Không đọc được nội dung chính được bảo vệ.
• Không đọc được metadata hoặc chỉ thị nằm sau lớp xác thực.
• Không thể lập chỉ mục nội dung đó trong lần truy cập này.

Phản hồi 401 vẫn có thể chứa HTML trang lỗi. Theo Google Search Central, URL đã được lập chỉ mục có thể bị loại khi Google xử lý lại phản hồi lỗi và không nhất thiết sẽ biến mất ngay.

HTTP 401 khác HTTP 403 thế nào?

Trước khi sửa: URL có thực sự cần được index không?

Mục đích URL quyết định hướng xử lý, không phải mong muốn xóa cảnh báo khỏi báo cáo. Trang không cần index chưa chắc là trang riêng tư.

Cây quyết định phân loại URL

Kiểm tra theo thứ tự:

1. Chứa dữ liệu riêng tư hoặc thuộc staging (môi trường thử nghiệm)? - Giữ kiểm soát truy cập.
2. Thuộc paywall (nội dung giới hạn theo thuê bao hoặc trả phí)? - Rà soát theo thiết kế paywall riêng.
3. Công khai và cần index? - Tìm lớp trả 401 ngoài ý muốn.
4. Công khai nhưng không muốn index? - Dùng noindex khi phù hợp và Google đọc được chỉ thị.

Nếu chưa rõ, xác nhận với chủ sở hữu nội dung trước khi thay đổi quyền truy cập.

Hành động tương ứng với từng nhóm

GSC phát hiện URL riêng tư không đồng nghĩa nội dung đã bị lộ. Tương tự, loại URL khỏi sitemap không bảo đảm Google quên URL hoặc xóa nó khỏi kết quả tìm kiếm.

Những nguyên nhân phổ biến khiến Googlebot nhận phản hồi 401

Các dấu hiệu ban đầu chỉ giúp khoanh vùng vấn đề. Để có kết luận chính xác, bạn cần kiểm tra mã trạng thái (status code), header và nhật ký máy chủ (server logs). Hãy đảm bảo đối chiếu đúng URL và thời điểm xảy ra lỗi.

CMS hoặc ứng dụng

Hệ quản trị nội dung (CMS) có thể vô tình kích hoạt chế độ thành viên (membership) cho các trang công khai. Ngoài ra, lớp xử lý trung gian (middleware) cũng có thể được thiết lập yêu cầu đăng nhập trên phạm vi quá rộng.

Plugin bảo mật hoặc membership

Hãy rà soát kỹ quy tắc kiểm soát truy cập và điều kiện kế thừa quyền trong plugin. Tránh kết luận lỗi do plugin chỉ vì vừa mới cài đặt; lưu ý rằng chế độ bảo trì có thể trả về nhiều mã trạng thái HTTP khác nhau.

Server, hosting hoặc proxy

Lỗi thường xuất hiện do cơ chế Basic Authentication (xác thực HTTP bằng tài khoản/mật khẩu) hoặc tính năng bảo vệ thư mục từ môi trường thử nghiệm (staging) chưa được gỡ bỏ khi đưa website lên chính thức.

CDN, WAF hoặc quản lý bot

Mạng phân phối nội dung (CDN) và tường lửa ứng dụng web (WAF) có thể áp dụng các chính sách chặn truy cập nghiêm ngặt. Tuy nhiên, các hệ thống này cũng có thể trả về mã 403, 429,... do đó bạn chỉ nên kết luận nguyên nhân do CDN/WAF khi đã có bằng chứng log rõ ràng.

Nguồn phát hiện URL riêng tư

Tệp XML sitemap, liên kết nội bộ (internal link), quy tắc chuyển hướng (redirect) và thẻ canonical giúp Googlebot phát hiện ra URL. Đây chỉ là các kênh dẫn đường khiến Google biết đến trang, chứ không phải là lớp trực tiếp tạo ra phản hồi lỗi 401.

Tình huống minh họa xuyên suốt: Sau khi triển khai website SaaS, đường dẫn /solutions/ bị cài đặt xác thực nhầm giống như khu vực /app/. Trong trường hợp này, nhóm trang giải pháp cần được mở công khai cho Google index, trong khi dashboard khách hàng thuộc /app/ vẫn phải giữ chế độ bảo vệ nghiêm ngặt.

Cách kiểm tra lỗi 401 từng bước

1. Xuất và phân nhóm URL từ GSC.
2. Kiểm tra khi chưa đăng nhập.
3. So sánh URL Inspection với kiểm tra trực tiếp.
4. Xác nhận HTTP status và header.
5. Đối chiếu cấu hình, log và thay đổi gần nhất.

Bước 1: Xuất URL từ báo cáo lập chỉ mục

Truy cập báo cáo Page Indexing trong GSC, chọn trạng thái lỗi 401 và xuất danh sách các URL ví dụ. Phân loại nhóm URL theo cấu trúc đường dẫn, mục đích sử dụng và mốc thời gian phát sinh lỗi.

Lưu ý: Báo cáo từ GSC có thể không liệt kê toàn bộ URL bị ảnh hưởng. Mục tiêu của bước này là xác định nhóm URL ưu tiên cần kiểm tra ngay, đặc biệt là các trang công khai quan trọng đối với website.

Bước 2: Mở bằng cửa sổ ẩn danh

Mở trình duyệt ở chế độ ẩn danh (Incognito) để kiểm tra URL ở trạng thái chưa đăng nhập. Ghi nhận thực tế trang hiển thị nội dung bình thường, bật hộp thoại yêu cầu xác thực hay tự động chuyển hướng về trang đăng nhập.

Lưu ý: Việc màn hình hiển thị giao diện đăng nhập chưa khẳng định trang trả về mã 401. URL đó vẫn có thể trả về mã 200 OK hoặc sử dụng mã chuyển hướng 3xx. Cần xác nhận lại mã phản hồi chính xác ở Bước 4.

Bước 3: Dùng URL Inspection và Test Live URL

Trong công cụ URL Inspection, xem lại dữ liệu lịch sử ở lần thu thập dữ liệu gần nhất (Index data). Sau đó, nhấn chọn Test Live URL để kiểm tra khả năng truy cập thực tế tại thời điểm hiện tại.

• Kết quả Live Test có thể khác biệt so với dữ liệu đã lưu trong lịch sử.
• Live Test thành công chỉ xác nhận Googlebot có thể truy cập ở thời điểm kiểm tra, chứ không chứng minh trang đã được lập chỉ mục hay khẳng định thẻ canonical Google sẽ lựa chọn.
• Nếu kết quả Live Test khác với dữ liệu Googlebot ghi nhận trong log máy chủ, cần nhờ bộ phận kỹ thuật hỗ trợ đối chiếu vì hai lần truy cập có thể áp dụng điều kiện xử lý khác nhau.

Bước 4: Kiểm tra HTTP status và header

Mở công cụ dành cho nhà phát triển (Developer Tools) trên trình duyệt, chọn tab Network, tải lại trang và chọn yêu cầu tài liệu chính (main document). Nếu cần thiết, hãy nhờ bộ phận kỹ thuật kiểm tra lệnh HTTP GET cùng chuỗi chuyển hướng liên quan.

Ghi lại chính xác URL thực sự trả về mã 401 và kiểm tra giá trị của header WWW-Authenticate:

• Basic: Gợi ý cơ chế xác thực HTTP bằng tài khoản và mật khẩu.
• Bearer: Gợi ý cơ chế xác thực bằng mã định danh (token).

Lưu ý: Header này gợi ý phương thức xác thực chứ không luôn chỉ ra chính xác lớp hệ thống gây ra lỗi. Ngoài ra, không nên chỉ dựa vào yêu cầu dạng HEAD vì máy chủ có thể xử lý khác so với phương thức GET.

Bước 5: Đối chiếu cấu hình và log

Rà soát lịch sử thay đổi cấu hình, mốc thời gian phát sinh lỗi, mã quy tắc và các phiên bản triển khai (deployment) gần nhất. Hãy tổng hợp đầy đủ bằng chứng kỹ thuật vào ticket hỗ trợ trước khi tiến hành chỉnh sửa.

Cảnh báo an toàn: Tuyệt đối không gửi cookie, token, mật khẩu hay các URL nhạy cảm vào các công cụ kiểm tra công khai. Lưu ý rằng việc giả mạo chuỗi User-Agent của Googlebot cũng không chứng minh được Googlebot thật có thể truy cập thành công.

Cách sửa lỗi 401 đối với trang công khai cần được index

Mục tiêu là khách chưa đăng nhập và crawler hợp lệ đọc được nội dung công khai. Không phải tạo một đường truy cập đặc biệt vượt xác thực.

Gỡ yêu cầu đăng nhập khỏi đúng URL công khai

Hãy xác định chính xác danh sách đường dẫn cần công khai trước khi điều chỉnh cấu hình hệ thống hoặc lớp trung gian (middleware).

• Ví dụ: Chỉ đưa nhóm đường dẫn /solutions/ về phạm vi công khai, trong khi khu vực quản trị /app/ vẫn phải giữ chế độ yêu cầu đăng nhập.
• Đừng quên kiểm tra kỹ các trang con (sub-paths) để tránh bị ảnh hưởng bởi quy tắc kế thừa quyền chặn truy cập.

Sửa quy tắc plugin bảo mật hoặc membership

Rà soát và sửa đổi các quy tắc phân quyền đang áp dụng sai dựa trên bằng chứng kỹ thuật.

• Kiểm tra điều kiện thành viên, nhóm phân loại nội dung và các xung đột plugin (nếu có).
• Việc cập nhật plugin chỉ là giải pháp hỗ trợ, không đảm bảo sửa triệt để lỗi. Tuyệt đối không tắt toàn bộ hệ thống bảo mật chỉ để thử nghiệm nhanh.

Điều chỉnh hosting, CDN hoặc WAF theo log

• Luôn sao lưu cấu hình cũ và chuẩn bị phương án khôi phục (rollback) trước khi thực hiện thay đổi.
• Chỉ áp dụng điều chỉnh đối với các quy tắc liên quan trực tiếp đến URL công khai đang bị lỗi.

Xác minh bot hợp lệ: Nếu cần tạo ngoại lệ cho công cụ tìm kiếm, hãy áp dụng đúng phạm vi công khai và xác minh bot bằng phương pháp Reverse DNS (kết hợp Forward DNS) hoặc dải IP chính thức do Google công bố.

Tách riêng trường hợp paywall

Trang thuộc cơ chế Paywall cần được thiết kế quyền truy cập và khai báo dữ liệu có cấu trúc (Structured Data) chuẩn theo hướng dẫn về nội dung trả phí của Google.

• Khai báo dữ liệu có cấu trúc không giúp tự động gỡ bỏ xác thực hay sửa lỗi 401.
• Đội ngũ Developer và SEO cần thống nhất rõ ràng phần nội dung mở cho tìm kiếm, phần giới hạn truy cập và phương án kỹ thuật triển khai.

Không whitelist chỉ theo User-Agent

User-Agent (chuỗi nhận diện phần mềm gửi yêu cầu) có thể bị giả mạo. Không dùng nó làm bằng chứng duy nhất để cho phép truy cập. Bot hợp lệ cũng không mặc nhiên được đọc dữ liệu riêng tư. Sau thay đổi, kiểm tra đồng thời trang công khai và dashboard.

Cách xử lý URL riêng tư, staging hoặc không cần index

Với nội dung riêng tư, việc giữ kiểm soát truy cập là ưu tiên. Bạn không mở dữ liệu chỉ để Google đọc được một chỉ thị SEO.

Dọn XML sitemap

Loại bỏ hoàn toàn các URL riêng tư, môi trường thử nghiệm (staging) và bản xem trước (preview) ra khỏi XML sitemap công khai. Đồng thời, hãy điều chỉnh lại logic tự động khởi tạo sitemap để các URL này không bị xuất hiện trở lại.

Lưu ý: Theo tài liệu của Google, sitemap chỉ hỗ trợ khám phá URL chứ không quyết định quyền truy cập hay bảo đảm trang sẽ được lập chỉ mục.

Sửa nguồn phát hiện không phù hợp

Bạn kiểm tra liên kết nhầm tới staging, bản xem trước, dashboard cá nhân, canonical và chuyển hướng sai. Không xóa nút đăng nhập hoặc liên kết chức năng cần thiết chỉ vì đích đến yêu cầu xác thực.

Lưu ý rằng việc dọn dẹp nguồn phát hiện chỉ giúp hạn chế Googlebot tìm thấy URL, chứ không đảm bảo Google sẽ dừng truy cập ngay lập tức.

Phân biệt bảo mật, crawl, index và khám phá URL

Bản thân mã 401 không phải một hệ thống bảo mật hoàn chỉnh. Theo Google, robots.txt không bảo vệ dữ liệu và không bảo đảm URL không xuất hiện trên kết quả tìm kiếm.

Vì sao noindex không sửa được 401?

Thẻ meta noindex nằm sau lớp đăng nhập nên Googlebot không thể tiếp cận và đọc được chỉ thị này khi gặp phản hồi 401.

• Trang riêng tư: Cần giữ nguyên cơ chế xác thực (Authentication).
• Trang công khai không muốn index: Chỉ nên dùng thẻ noindex (dạng meta tag hoặc HTTP header) khi Googlebot có thể truy cập trang một cách bình thường (200 OK).

Kiểm tra sau khi sửa và những cách xử lý sai cần tránh

Checklist hậu kiểm

Dùng checklist này trước khi yêu cầu Google kiểm tra lại:

• URL cuối trả HTTP 200 với nội dung đúng.
• Trang mở được khi chưa đăng nhập.
• Live Test truy cập thành công.
• Nội dung chính và tài nguyên cần thiết tải được.
• Không có noindex ngoài ý muốn.
• Canonical khai báo phù hợp.
• Sitemap, nếu dùng, không chứa URL sai mục đích.
• Dashboard và staging vẫn được bảo vệ.
• Dùng Request Indexing cho URL quan trọng sau hậu kiểm.
• Theo dõi Google thu thập lại và báo cáo lập chỉ mục.

Nếu có Validate Fix, có thể yêu cầu xác minh nhóm lỗi. Chức năng này khác Request Indexing dành cho URL cụ thể. Không kỳ vọng báo cáo cập nhật tức thì.

Những cách xử lý sai cần tránh

Khi nào cần chuyển cho developer hoặc hosting?

Chuyển giao khi lỗi diện rộng sau triển khai, chưa tìm được lớp trả 401, hoặc trình duyệt, Live Test và log cho kết quả khác nhau. Không tự sửa server/WAF nếu thiếu quyền hoặc chuyên môn.

URL/nhóm URL: Mục đích: Công khai cần index / Công khai không cần index / Riêng tư / Paywall Thời điểm kiểm tra và múi giờ: HTTP status, URL cuối sau chuyển hướng: Kết quả ẩn danh và GSC Live Test: Thay đổi cấu hình gần nhất: Ảnh/header/log đã che thông tin nhạy cảm: Kết quả mong đợi và phạm vi không được mở:

Không đưa mật khẩu, token hoặc cookie vào ticket. Kết luận sau sửa chỉ áp dụng cho phạm vi đã kiểm tra, chưa chứng minh toàn website được index.

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

Lỗi "Blocked due to unauthorized request (401)" là gì?

Đây là thông báo từ Google Search Console cho biết Googlebot đã cố gắng thu thập dữ liệu (crawl) một trang web nhưng bị máy chủ từ chối vì yêu cầu xác thực. Trạng thái này có nghĩa là trang web yêu cầu thông tin đăng nhập, mà Googlebot thì không có.

Tại sao trang web của tôi gặp lỗi này trong Search Console?

Lỗi xảy ra khi Googlebot phát hiện đường dẫn (URL) của bạn thông qua sitemap hoặc các liên kết nội bộ, nhưng trang đó lại đang được bảo vệ bởi mật khẩu, cấu hình staging, hoặc cơ chế kiểm soát truy cập (Access Control) ở cấp máy chủ hoặc WAF (Web Application Firewall).

Tôi có nên sửa tất cả các URL báo lỗi 401 không?

Không. Bạn chỉ nên sửa các trang công khai (public) mà bạn muốn Google lập chỉ mục (index). Nếu đó là các trang riêng tư như dashboard khách hàng, khu vực quản trị hoặc môi trường staging, bạn nên giữ nguyên trạng thái bảo mật và chỉ cần đảm bảo chúng không nằm trong XML sitemap.

Tôi có thể thêm thẻ "noindex" để khắc phục lỗi 401 không?

Không. Googlebot cần truy cập được vào trang web mới có thể đọc được thẻ noindex. Khi trang bị chặn bởi lỗi 401, bot sẽ bị từ chối ngay từ cổng vào và không bao giờ thấy được thẻ meta của bạn, do đó noindex không có tác dụng trong trường hợp này.

Làm cách nào để phân biệt giữa lỗi 401 và lỗi 403?

Lỗi 401 (Unauthorized) có nghĩa là máy chủ yêu cầu thông tin xác thực (đăng nhập) hợp lệ. Lỗi 403 (Forbidden) có nghĩa là máy chủ hiểu yêu cầu của bạn nhưng từ chối thực hiện vì bạn không có quyền truy cập, bất kể bạn có cung cấp thông tin đăng nhập hay không.

Việc dọn dẹp XML sitemap có giúp xóa trang khỏi Google không?

Việc xóa URL khỏi sitemap giúp Google ngừng chủ động khám phá các trang đó, nhưng không xóa ngay lập tức các trang đã được lập chỉ mục trước đó. Để trang sớm biến mất khỏi kết quả tìm kiếm, trang cần phải truy cập được để Google đọc chỉ thị kiểm soát index hoặc máy chủ phải trả về mã lỗi 404/410.

Nếu trang web là một hệ thống trả phí (paywall), tôi phải làm sao?

Với nội dung trả phí, bạn không nên gỡ bỏ lớp bảo mật. Thay vào đó, hãy áp dụng "Structured Data" dành riêng cho nội dung trả phí (Paywalled Content) theo hướng dẫn kỹ thuật của Google. Điều này cho phép Googlebot hiểu nội dung mà không cần phải vượt qua hàng rào đăng nhập trái phép.

Read more:

• Structured Data là gì? Hướng dẫn cách tối ưu SEO website chuẩn
• So sánh HTTP/2 và HTTP/3: Cơ chế truyền tải và hiệu suất
• Lỗi 451 là gì? Tìm hiểu về mã trạng thái HTTP 451

Kết luận

Xử lý lỗi “Blocked due to unauthorized request (401)” bắt đầu từ mục đích URL, không phải việc gỡ đăng nhập. Với trang công khai cần index, bạn hãy tái hiện lỗi, xác định lớp trả 401 và sửa quy tắc áp dụng sai. Sau đó, kiểm tra nội dung thực tế bằng phiên chưa đăng nhập và Live Test.

Với dashboard, staging hoặc dữ liệu khách hàng, tiếp tục giữ xác thực. HTTP 200 và kiểm tra trực tiếp thành công chỉ xác nhận một phần điều kiện kỹ thuật, không bảo đảm Google lập chỉ mục ngay. Hãy dùng checklist và mẫu ticket trong bài để hậu kiểm, bàn giao. Nếu nhiều URL công khai cùng lỗi hoặc lỗi tái diễn, nên thực hiện Technical SEO audit kết hợp rà soát hạ tầng và quyền truy cập.