#RFC 9309: Robots Exclusion Protocol

robots.txt là file để chủ website hướng dẫn crawler nên hoặc không nên truy cập những URL nào. RFC 9309, được công bố vào tháng 9 năm 2022, chuẩn hóa các quy tắc cốt lõi của Robots Exclusion Protocol.

Bài viết tập trung vào hai phần dễ gây lỗi nhất trong RFC:

• Section 2: cách crawler đọc và chọn group phù hợp.
• Section 2.2.2: cách so khớp Allow và Disallow, trong đó path cụ thể hơn được ưu tiên và Allow thắng khi hai rule tương đương.

robots.txt không phải là authentication, authorization hay firewall. Bất kỳ ai cũng có thể mở file này, và crawler không tuân thủ có thể bỏ qua nó.

#File robots.txt ở đâu?

File phải nằm ở root của origin, có tên chính xác là /robots.txt và được phục vụ dưới dạng UTF-8:

https://example.com/robots.txt

https://example.com/robots.txt và https://www.example.com/robots.txt thuộc hai authority khác nhau, vì vậy mỗi host cần được kiểm tra riêng. Một file trong /booking/robots.txt không thay thế được file ở root.

Ví dụ tối thiểu:

User-agent: *
Disallow:

Disallow: có giá trị rỗng, nghĩa là không có path nào bị chặn. Đây là cách diễn đạt rõ ràng hơn việc bỏ trống cả file.

#Parser xử lý robots.txt như thế nào?

#1. Đọc các group

Một group bắt đầu bằng một hoặc nhiều dòng User-agent, sau đó là các dòng Allow hoặc Disallow. Group kết thúc khi gặp User-agent tiếp theo hoặc hết file.

User-agent: ExampleBot
Disallow: /private/
Allow: /private/preview.html

Các rule đứng trước User-agent đầu tiên không thuộc group hợp lệ nên crawler nên bỏ qua. Comment bắt đầu bằng # và có thể đặt trên dòng riêng hoặc ở cuối dòng:

# Không cho crawler vào khu vực quản trị
User-agent: *
Disallow: /admin/ # Khu vực nội bộ

#2. Chọn group theo User-agent

User-agent trong robots.txt nhận product token của crawler. Product token chỉ gồm chữ cái, dấu gạch ngang hoặc dấu gạch dưới. Việc tìm group là case-insensitive substring matching: crawler phải so khớp không phân biệt hoa thường, và product token được kỳ vọng là một substring trong chuỗi nhận diện của crawler.

Ví dụ, group sau áp dụng cho User-Agent có chứa HotelBot, hotelbot hoặc biến thể hoa thường tương ứng:

User-agent: HotelBot
Disallow: /internal/

Nếu có nhiều group cùng match một product token, các rule của chúng được gộp thành một group trước khi áp dụng. Nếu không có group cụ thể nào match, crawler dùng group có User-agent: * làm fallback. * không phải là cách để override một group cụ thể đã match.

User-agent: Googlebot
Disallow: /private/

User-agent: *
Disallow: /tmp/

Trong ví dụ trên, Googlebot chịu rule /private/ của group riêng; group * là fallback cho các crawler không có group cụ thể. Việc một crawler có thêm chuỗi Googlebot trong User-Agent không tự động biến crawler đó thành Googlebot đáng tin cậy.

#3. Chọn rule Allow hoặc Disallow

Crawler so khớp path của URL với các pattern trong group đã chọn. Rule phải match từ octet đầu tiên của path. Khi nhiều rule cùng match, rule có pattern cụ thể nhất, tức có nhiều octet match nhất, được chọn.

User-agent: *
Disallow: /booking/
Allow: /booking/confirmation.html

Kết quả:

Nếu Allow và Disallow có cùng mức độ cụ thể, RFC 9309 khuyến nghị dùng Allow:

User-agent: *
Disallow: /public/
Allow: /public/

Trong trường hợp này /public/ được cho phép. Tuy vậy, không nên tạo các rule xung đột nếu có thể viết configuration rõ ràng hơn.

#Pattern: prefix, * và $

Một pattern thông thường là prefix. Disallow: /private/ match /private/, /private/a và /private/a/b.

RFC 9309 định nghĩa các ký tự đặc biệt sau:

• * match không hoặc nhiều ký tự.
• $ đánh dấu cuối pattern.
• # bắt đầu comment.

User-agent: *
Disallow: /*.json$
Allow: /api/public.json

Rule trên chặn các path kết thúc bằng .json, ngoại trừ /api/public.json vì pattern Allow cụ thể hơn. Khi URL có ký tự ngoài ASCII hoặc ký tự reserved của URI, cần chú ý dạng percent-encoded trước khi so khớp; đừng giả định rằng path hiển thị trong browser luôn là chuỗi octet mà crawler dùng để match.

/robots.txt luôn được cho phép ngầm định. Việc dùng Disallow: / không thể ngăn crawler đọc chính file hướng dẫn.

#Mẫu an toàn cho website khách sạn

Website khách sạn thường có các URL nên được crawl và những URL chỉ phục vụ thao tác, session hoặc dữ liệu trùng lặp:

# Áp dụng cho crawler không có group riêng
User-agent: *

# Cho phép các trang có giá trị tìm kiếm
Allow: /
Allow: /rooms/
Allow: /locations/
Allow: /offers/

# Không crawl các endpoint thao tác và dữ liệu tạm
Disallow: /admin/
Disallow: /api/
Disallow: /checkout/
Disallow: /account/
Disallow: /booking/confirmation
Disallow: /*?session=
Disallow: /*?utm_

Sitemap: https://hotel.example/sitemap.xml

#Vì sao không nên chặn nhầm trang đặt phòng?

Giả sử website có:

• /rooms/deluxe: landing page mô tả phòng, nên được index.
• /booking/search: form chọn ngày và số khách, thường không cần index.
• /booking/confirmation: trang kết quả sau khi đặt phòng, không nên xuất hiện trên kết quả tìm kiếm.

Rule an toàn là chặn đúng các endpoint thao tác:

User-agent: *
Disallow: /booking/search
Disallow: /booking/confirmation

Không nên dùng Disallow: /booking/ nếu bên dưới đó còn các trang nội dung công khai như /booking/packages hoặc /booking/rooms. Prefix rộng có thể làm mất khả năng crawl các trang có doanh thu cao.

Đặc biệt, đừng viết:

User-agent: *
Disallow: /
Allow: /rooms/

Mẫu này chỉ cho phép những path có pattern dài hơn /, còn toàn bộ phần còn lại của website bị chặn. Nếu mục tiêu là chỉ chặn các trang xác nhận, hãy chặn chính xác /booking/confirmation thay vì deny toàn site rồi mở lại từng thư mục.

#HTTP status và caching

Crawler không chỉ đọc nội dung file; nó còn phải xử lý kết quả HTTP:

• 2xx: tải thành công thì parse các rule có thể parse được.
• 3xx: crawler nên follow ít nhất năm redirect liên tiếp. Tránh redirect vòng hoặc chuỗi redirect dài cho /robots.txt.
• 4xx: file được xem là unavailable; crawler có thể truy cập tài nguyên trên server.
• 5xx hoặc lỗi mạng: file được xem là unreachable; crawler phải giả định complete disallow trong thời gian lỗi.

Điểm cuối rất quan trọng khi deploy. Một lần trả 503 tạm thời có thể khiến crawler ngừng truy cập toàn bộ website, trong khi một 404 lại có thể được hiểu là không có hạn chế. Hãy monitor riêng request tới /robots.txt, status code, content type và nội dung trả về.

Crawler có thể cache robots.txt. RFC 9309 khuyến nghị không dùng bản cache quá 24 giờ, trừ khi file không thể truy cập. Sau khi sửa rule, hãy kiểm tra cả response thực tế qua CDN, reverse proxy và origin; chỉnh file trong repository chưa chắc đã đồng nghĩa với file đã được phục vụ.

#robots.txt không bảo vệ dữ liệu

Không đặt secret, token, đường dẫn quản trị nhạy cảm hoặc thông tin cá nhân vào robots.txt. Các path trong file này được công khai và còn có thể khiến khu vực cần che giấu trở nên dễ đoán hơn.

Nếu cần bảo vệ /admin/, /account/ hoặc API đặt phòng, hãy dùng cơ chế phù hợp ở application layer:

• authentication và authorization;
• session kiểm tra ở server;
• noindex cho chỉ thị indexing khi nội dung vẫn cần crawl;
• response không chứa dữ liệu nhạy cảm cho người dùng chưa xác thực.

Disallow chỉ nói “crawler được yêu cầu không truy cập”, không nói “người dùng không được truy cập”.

#Checklist trước khi triển khai

1. Mở https://your-domain.example/robots.txt trên đúng production host và kiểm tra status 200.
2. Xác nhận file nằm ở root, tên chữ thường là robots.txt, encoding là UTF-8 và content type là text/plain.
3. Kiểm tra group cụ thể trước group *; nhớ rằng product token được match không phân biệt hoa thường.
4. Với mỗi URL quan trọng, liệt kê tất cả Allow và Disallow có thể match rồi chọn pattern dài nhất.
5. Kiểm tra các cặp rule có cùng độ dài: Allow được ưu tiên khi tương đương.
6. Test cả URL trang phòng, trang địa điểm, trang ưu đãi, form tìm phòng và confirmation page.
7. Kiểm tra query string, percent-encoding, trailing slash và redirect qua CDN.
8. Đặt sitemap chính xác bằng URL tuyệt đối và đảm bảo các URL trong sitemap không bị Disallow.
9. Dùng authentication cho dữ liệu cần bảo mật; không dựa vào robots.txt.
10. Sau deploy, xem access log để phát hiện request bất thường và theo dõi trạng thái crawl.

#Tài liệu tham khảo

• RFC 9309 - Robots Exclusion Protocol
• RFC 9309 trên IETF Datatracker