Crawler AI vào site qua cửa nào: phân bố cửa vào trong 12.867 yêu cầu bên ngoài suốt 11 ngày, và sự thật về 88 lượt đường dẫn /null

1. Tóm tắt: 11 ngày, 2.235.940 dòng log, nhưng chỉ có 12.867 yêu cầu hợp lệ từ bên ngoài

Đây là bài đầu tiên trong loạt bài "Kiểm toán khả năng tiếp cận của crawler AI". Câu hỏi rất cụ thể: crawler của các công cụ AI tạo sinh vào site của chúng tôi qua cánh cửa nào?

Chúng tôi lấy toàn bộ log truy cập nginx của site (yuezhitong.com) từ 2026-09-25 03:30 đến 2026-10-06 02:01 — 11 tệp log, 2.235.940 dòng yêu cầu. Sau ba lớp loại bỏ, chỉ còn 12.867 yêu cầu thực sự đến từ bên ngoài và có giá trị phân tích; trong đó crawler mang danh tính nhà cung cấp AI tạo sinh là 681 lượt.

Ba kết luận chính:

• Nhìn chung các cửa được đi đúng. Trong 681 lượt, có 97 lượt đọc robots.txt, 49 lượt đọc sitemap.xml, 159 lượt vào thư mục nội dung. Crawler AI tạo sinh thật sự đi theo lộ trình "xem luật trước, rồi lấy trang theo chỉ mục", chứ không lang thang ngẫu nhiên.
• Nhưng cánh cửa do chính chúng tôi xây thì không ai đi. Tệp llms.txt ở gốc site (tệp chỉ mục AI theo đề xuất llmstxt.org) được yêu cầu 14 lần trong 11 ngày, trong đó 0 lần đến từ crawler của bất kỳ nhà cung cấp AI nào — cả 14 lần đều từ script chấm điểm của chúng tôi, curl, và một nhà cung cấp dữ liệu bên thứ ba.
• Crawler giúp chúng tôi tìm lỗi, nhưng cũng tạo nhiễu. Trong 11 ngày có 88 lượt yêu cầu đánh vào đường dẫn dạng <thư mục>/null (ví dụ /geo/blog/null, /vietnam/ho-chi-minh/cost/null), 87 lượt trả về 404. Chúng tôi đã rà từng trang: trong mã nguồn site không tồn tại chuỗi "null", cũng không có thẻ liên kết nào thiếu href. Đây là đường dẫn giả phía crawler, đã được tái hiện ở nhiều site khác, không phải lỗi trang của chúng tôi — nhưng nó thật sự tiêu tốn ngân sách thu thập, nên vòng này chúng tôi đã xử lý ở phía máy chủ (mục tám).

Dưới đây là toàn bộ phạm vi đo, chân dung của bảy crawler, và một danh sách sáu bước tự kiểm tra có thể làm ngay.

2. Phương pháp: ba lớp loại bỏ và cách xác định danh tính

Bước dễ sai nhất khi phân tích crawler là không loại sạch "lưu lượng không phải khách truy cập". Trong log của site này, hơn 95% là health check nội bộ, cộng thêm máy phát hành và script kiểm toán của chính chúng tôi — không loại bỏ thì mọi kết luận về "tỷ trọng crawler" đều sai.

Cách xác định danh tính: phân loại theo khai báo UA trong header (GPTBot / OAI-SearchBot / ChatGPT-User / ClaudeBot / Claude-SearchBot / PerplexityBot / meta-externalagent...), không đối chiếu reverse DNS sau đó. UA có thể bị giả mạo, nên chúng tôi không khẳng định "IP này chắc chắn thuộc công ty kia", mà chỉ mô tả "các yêu cầu nhân danh nhà cung cấp nào đó". Mọi tỷ lệ chỉ đúng trong cửa sổ này và trên site này, không suy rộng thành tỷ lệ toàn ngành.

3. Bức tranh chung: crawler AI tạo sinh đi qua những cánh cửa nào

Phân loại 681 lượt theo "thứ đầu tiên được lấy sau khi vào site", ta có bảng phân bố cửa dưới đây:

Ba điểm cần đọc: Thứ nhất, robots.txt + sitemap.xml cộng lại 146 lượt (21,4%), cho thấy "luật + chỉ mục" là cửa vào thường quy của crawler AI tạo sinh; làm đúng hai tệp này là đầu tư chắc chắn có lãi. Thứ hai, thư mục nội dung chỉ 159 lượt (23,3%), cộng 20 lượt trang chủ, tức yêu cầu thật sự rơi vào "bài viết và báo cáo chúng tôi viết" chưa đến ba phần mười — ngân sách của crawler phân tán hơn ta tưởng. Thứ ba, "đường dẫn khác" chiếm 36,3%, trong đó lẫn rất nhiều quét tấn công và đường dẫn giả, cần tách ra bằng kiểm toán mẫu 404 ở phần sau.

4. Chân dung từng nhà: sở thích cửa vào của bảy crawler AI tạo sinh

Tách phân bố cửa theo từng nhà, khác biệt lớn hơn ta tưởng:

Ba khác biệt đáng nhớ:

• OAI-SearchBot thuộc kiểu "chỉ đọc luật". 50 trong 63 lượt là robots.txt (79,4%), không lấy một trang nội dung nào. Nó giống như đang xác nhận ranh giới hơn là đến lấy nguyên liệu.
• ClaudeBot thuộc kiểu "đọc cửa rồi mới vào". 87 lượt luật + chỉ mục, 26 lượt trang nội dung — đi cả hai bước, và tỷ lệ 404 chỉ 0,8%, cho thấy chỉ mục nó nhận được là chính xác.
• meta-externalagent thuộc kiểu "chỉ vào, không xem cửa". 0 lượt robots.txt, 0 lượt sitemap, lấy thẳng 105 trang nội dung; nhưng phát ra từ 92 địa chỉ IP khác nhau, tỷ lệ 404 là 35,3%. Hành vi của nó giống như đang render trang rồi tiện thể đi theo các liên kết trên trang — đây cũng là nguồn của đường dẫn giả /null ở mục sáu.

Để đối chiếu, crawler của công cụ tìm kiếm cùng kỳ (Googlebot, bingbot, PetalBot...) tổng cộng 687 lượt, quy mô tương đương crawler AI tạo sinh; cửa vào của chúng cũng tập trung ở robots.txt (Googlebot 22 lượt, bingbot 17 lượt) và sitemap.xml (bingbot 24 lượt).

5. Nhận định 1: llms.txt là cửa chúng tôi tự xây, 11 ngày không có crawler AI nào đi

Ngày 2026-09-17, chúng tôi thêm llms.txt vào gốc site và khai báo rõ ràng việc cho phép crawler AI trong robots.txt, đồng thời liệt kê trong llms.txt theo đề xuất llmstxt.org: chủ thể công ty, dịch vụ cốt lõi, trung tâm nội dung, nghiên cứu ngành và phạm vi số liệu đối ngoại. Giả định của nó là: công cụ AI sẽ dùng tệp này như "sitemap dành cho máy".

Câu trả lời từ 11 ngày log là: nó được đọc 14 lần, nhưng không một lần nào đến từ crawler của nhà cung cấp AI.

So sánh cùng kỳ: robots.txt được yêu cầu 315 lần, sitemap.xml 87 lần. Nghĩa là trong cửa sổ tháng 9 đến tháng 10 năm 2026 này, cửa dành cho máy thật sự có tác dụng vẫn là robots.txt và sitemap.xml, còn llms.txt thì chưa.

Đánh giá của chúng tôi (bản trung thực): điều này không có nghĩa nên xóa llms.txt. Chi phí duy trì gần như bằng không, và với các công cụ kiểm toán GEO hay với những engine sau này mới đọc nó, đây là tài sản có sẵn; nhưng hiện tại nó không thể được coi là hạng mục bàn giao kiểu "làm rồi thì AI sẽ tìm thấy bạn". Trong chẩn đoán cho khách hàng, chúng tôi đặt nó ở nhóm "điểm cộng" chứ không phải "bắt buộc".

6. Nhận định 2: 88 lượt <thư mục>/null — đường dẫn giả phía crawler, tái hiện ở nhiều site

Khi bóc tách các lượt 404, chúng tôi thấy một nhóm yêu cầu có hình dạng rất đều: đường dẫn luôn bằng "thư mục hiện tại + /null". Chúng không tập trung ở một thư mục, mà đi theo trang mà crawler đang ở.

Cả 88 lượt đều đến từ cùng một UA: meta-externalagent. Chúng tôi làm ba bước rà soát:

1. Tìm kiếm trong mã nguồn trang. Lấy toàn bộ trang liên quan (cả bản tiếng Trung và tiếng Việt, trang bài viết, trang báo cáo ngành, trang kho thành phố), tìm chuỗi "null" không phân biệt chữ hoa chữ thường: 0 kết quả.
2. Kiểm tra tính đầy đủ của liên kết. Đếm số thẻ <a> và số thẻ thiếu href trên mỗi trang: ví dụ một trang báo cáo ngành bản tiếng Việt có "11 thẻ a / 0 thẻ thiếu href", và 5 thẻ <link> đều có href. Không có liên kết khuyết.
3. Đối chiếu chéo bên ngoài. Trong các ghi chép vận hành công khai, có ít nhất ba nơi tái hiện hoàn toàn cùng một dấu vân tay — cùng hình dạng "/null", cùng meta-externalagent, và cũng không tìm thấy chuỗi null trong mã nguồn trang.

Ba ghi chép bên ngoài đều kết luận giống nhau: khi render trang, crawler đọc một trường "đáng lẽ là URL" thành giá trị rỗng; giá trị rỗng bị ép thành chuỗi "null", rồi được phân giải như URL tương đối so với thư mục hiện tại, và tạo ra một lượt 404. Ở phía máy chủ, không có cấu hình nào tạo ra được mẫu này — vì xét riêng từng khâu trong chuỗi thì mọi thứ đều đúng.

Vì vậy chúng tôi xác định đây là đường dẫn giả phía crawler, không phải lỗi trang của mình. Định tính này quan trọng: nếu coi đó là bug nội bộ để "sửa trang", ta sẽ sửa vô ích một vòng; động tác đúng là xử lý rõ ràng loại đường dẫn này ở phía máy chủ để giảm lãng phí ngân sách thu thập.

7. Nhận định 3: tỷ lệ 404 của crawler AI dao động từ 0% đến 35%

Cùng một site, cùng một cửa sổ, tỷ lệ đụng 404 của từng crawler khác nhau rất lớn:

Một con số khác đáng xem hơn là "404 trong thư mục nội dung". Tổng yêu cầu bên ngoài có 5.085 lượt 404 (chiếm 39,5% yêu cầu bên ngoài), trong đó 5.024 lượt rơi vào đường dẫn không liên quan nội dung (/.env, /.git, /wp-login.php — dạng quét thông tin đăng nhập). Rơi vào /geo/blog/ chỉ có 18 lượt — và cả 18 lượt đều là /geo/blog/null.

Nói cách khác: trong 11 ngày, không có bất kỳ bài viết thật nào của chúng tôi trả về 404. Sức khỏe của tài sản nội dung là sạch; trong đống 404 trông có vẻ hỗn loạn, tuyệt đại đa số là quét từ bên ngoài và một đường dẫn giả này.

8. Xử lý: đổi <thư mục>/null từ 404 thành 410

Nguyên tắc xử lý có hai điểm: không động vào nội dung thật, chỉ đổi cách trả lời với đường dẫn giả; sau khi đổi phải chạy đối chứng dương và âm.

Vì sao không dùng phương án "sửa trang": vì trước đó chúng tôi đã chứng minh trang không có vấn đề (mã nguồn 0 kết quả "null", liên kết không khuyết). Đi tìm bug trên trang sẽ là công cốc.

Vì sao là 410 chứ không giữ 404: 410 Gone là tín hiệu rõ ràng — "tài nguyên này vĩnh viễn không còn". So với 404 nghĩa là "tạm thời chưa tìm thấy", nó kiềm chế crawler thử lại nhiều lần hơn và tiết kiệm chi phí máy chủ. Cách xử lý tương tự ở nơi khác cũng dùng giải pháp này (bản tương đương trên Apache là RedirectMatch 410 "/null/?$").

Ghi chú triển khai: các khối tiền tố kiểu location ^~ /geo/ và location ^~ /vietnam/ của nginx sẽ chặn location regex cấp server, nên không thể chỉ viết luật ở tầng server mà phải lồng thêm một dòng trong từng khối tiền tố tương ứng, đồng thời giữ một dòng dự phòng cấp server cho các đường dẫn còn lại. Sau khi sửa, chạy nginx -t đạt và reload có hiệu lực, rồi đọc lại từng dòng theo bảng trên. Kết quả xử lý: 8/8 đường dẫn giả chuyển 410, 10/10 đối chứng dương giữ 200, 2/2 đối chứng âm giữ 404.

9. Danh sách sáu bước tự kiểm tra khả năng tiếp cận cho khách hàng

Bộ động tác này không cần mua công cụ, chỉ cần log và một dòng curl trong terminal. Thứ tự xếp theo tỷ lệ đầu tư trên kết quả:

Thêm một kinh nghiệm: đừng đưa llms.txt vào KPI. Làm nó rất rẻ; nhưng trong cửa sổ 11 ngày của dự án này, lượt truy cập AI mà nó mang lại là 0. Thứ thật sự quyết định "AI có tìm thấy bạn hay không" vẫn là robots.txt, sitemap.xml và khả năng phân tích của chính trang nội dung.

10. Ranh giới và hạn chế

• Phạm vi: mọi tỷ lệ trong bài chỉ đại diện cho site này (yuezhitong.com) trong cửa sổ 2026-09-25 03:30 đến 2026-10-06 02:01, không suy rộng thành tỷ lệ toàn ngành.
• Danh tính: danh tính crawler phân loại theo khai báo UA, chưa đối chiếu reverse DNS hay dải IP; UA có thể giả mạo, nên bài này mô tả các yêu cầu "nhân danh một nhà cung cấp".
• Cửa sổ: log luân chuyển lúc 03:2x, tệp cũ nhất còn trên máy chủ là 2026-09-25, các cửa sổ sớm hơn không còn cục bộ nên không thể truy hồi.
• Giới thiệu: trong cửa sổ này, số yêu cầu có referer trỏ tới chatgpt.com hay perplexity.ai là 0. Referer bị tước khi mở trong app và ở chế độ riêng tư, nên số 0 này là "cận trên quan sát được bằng 0", không đồng nghĩa "AI chắc chắn không mang lại khách".
• Định tính: kết luận nguyên nhân của <thư mục>/null dùng phương pháp "loại trừ bằng mã nguồn phía máy chủ + đối chiếu chéo nhiều site", không phải xác nhận từ tài liệu chính thức của nhà cung cấp. Việc chúng tôi làm trên cơ sở đó là "trả lời rõ ràng cho đường dẫn giả", không phải "tuyên bố một nhà cung cấp có bug".
• Mục không thể tính lại: ba ghi chép công khai dùng để đối chiếu chéo là quan sát của bên thứ ba; chúng tôi chỉ so khớp dấu vân tay, không chạy lại môi trường của họ.

11. Quy về GEO: vì sao việc này quan trọng với thương hiệu Trung - Việt

Sự suy giảm của tìm kiếm truyền thống đã là kết luận: Gartner (2024-02) dự báo lưu lượng tìm kiếm truyền thống sẽ giảm 25% vào năm 2026; khảo sát của Bain cho thấy 80% người tiêu dùng đã giao ít nhất 40% nhu cầu tìm kiếm cho kết quả AI. Thị trường GEO Trung Quốc từ 349,3 tỷ CNY năm 2025 dự kiến lên 942 tỷ CNY năm 2026 (iiMedia Research 2026-02); tại Việt Nam, tỷ lệ phủ ChatGPT đã đạt 81% (Technode 2025-08).

Những con số này thường được dùng để lập luận "phải mua dịch vụ GEO". Nhưng dữ liệu của bài này chỉ về một kết luận mộc mạc hơn: engine tạo sinh lấy nguyên liệu từ robots.txt, sitemap và thư mục nội dung — ba việc này không làm tốt thì nói chuyện được trích dẫn chỉ là nói suông; làm đúng ba việc này rồi mới có tư cách bàn đến nội dung và thương hiệu.

Vì vậy trong chẩn đoán GEO cho khách hàng, ba hạng mục đầu tiên của chúng tôi chính là ba cánh cửa ở mục ba bài này: luật đọc được (robots.txt cùng khai báo cho phép), chỉ mục đầy đủ (sitemap không có loc trả 404), trang nội dung phân tích được (dữ liệu có cấu trúc và phần thân sạch). Hạng mục thứ tư mới là nội dung.

12. Nguồn dữ liệu và cách kiểm chứng

Nguồn thứ nhất (có thể tính lại): toàn bộ log truy cập nginx của site yuezhitong.com, cửa sổ 2026-09-25 03:30:02 đến 2026-10-06 02:01:28, gồm 11 tệp log, 2.235.940 dòng; quy trình là phân loại theo khai báo UA cộng ba lớp loại bỏ (health check nội bộ / nguồn của chính mình / yêu cầu hợp lệ bên ngoài), xuất ra số đếm có cấu trúc rồi viết vào bài. Mọi con số thứ nhất trong bài đều có thể tính lại bằng cùng một script ETL trên log gốc, không dựa vào lấy mẫu.

Đối chiếu chéo bên thứ ba (dấu vân tay /null ở mục sáu): bản khôi phục log tình báo mối đe dọa của shuffle-on.com (Null: Eight Hundred Requests for a Page Nobody Ever Wrote) · ghi chép xử lý của máy chủ WooCommerce tại headwall-hosting.com (đổi /null thành 410) · ghi chép rà soát 404 trên Search Console của dev.ootssu.com. Cả ba là ghi chép quan sát độc lập (hai trong số đó có dấu thời gian log năm 2026), dấu vân tay trùng khớp.

Chuẩn số liệu ngành (dùng thống nhất khi đối ngoại): Gartner (2024-02, tìm kiếm truyền thống giảm 25% vào 2026) · Bain (80% người tiêu dùng dùng AI cho ít nhất 40% nhu cầu tìm kiếm) · iiMedia Research (2026-02, thị trường GEO Trung Quốc 349,3 tỷ CNY năm 2025, dự kiến 942 tỷ CNY năm 2026) · Technode (2025-08, tỷ lệ phủ ChatGPT tại Việt Nam 81%).

Kiểm chứng xử lý: cấu hình nginx được sao lưu trước khi đổi, kiểm tra cú pháp bằng nginx -t, sau khi reload dùng curl đọc lại từng dòng cho 8 đường dẫn giả, 10 đối chứng dương và 2 đối chứng âm; kết quả ở bảng mục tám.