Phân tích log crawler AI

Tóm tắt — Phân tích nhật ký crawler AI là xem access log thô của máy chủ để biết bot AI nào — như GPTBot của OpenAI hay ClaudeBot của Anthropic — thực sự truy cập site, tần suất và nội dung chúng nhận được. Nhật ký là nơi duy nhất ghi lại hoạt động này. Google Search Console không hiển thị bot AI, còn Google Analytics chỉ thấy người nhấp vào site, không thấy chính các bot. Điểm khó là nhiều traffic tự nhận là bot AI nổi tiếng nhưng không phải, nên không thể chỉ tin vào tên.

Nhật ký là gì?

Nhật ký truy cập máy chủ ghi lại các yêu cầu đã đến máy chủ, gồm người dùng-agent, thời gian, đường dẫn và thông tin phản hồi nếu được cấu hình. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files Tài liệu của crawler xác định người dùng-agent, nhưng riêng chuỗi này không chứng minh bên yêu cầu là crawler thật. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

Mỗi khi bất kỳ thứ gì — trình duyệt của một người, Googlebot hay GPTBot — yêu cầu trang từ máy chủ, máy chủ sẽ ghi một dòng vào tệp nhật ký. Mỗi dòng ghi thời điểm, địa chỉ IP của khách truy cập, nội dung được yêu cầu, “người dùng-agent” (nhãn mà khách truy cập dùng để nhận diện mình, chẳng hạn GPTBot) và mã phản hồi máy chủ đã gửi (200 là thành công, 404 là không tìm thấy, v.v.).

Phân tích nhật ký crawler AI chỉ là đọc các dòng đó rồi lọc ra những bot AI. Nó trả lời các câu hỏi mà bạn gần như không thể trả lời bằng cách khác:

• Bot AI có thực sự ghé thăm trang web không?
• Nó đã lấy những trang nào, và bỏ qua những trang quan trọng nào?
• Đó có phải bot thật hay là thứ gì đó đang giả danh nó?
• Nó nhận được gì — nội dung thật hay một trang lỗi?

Nếu muốn biết đầy đủ các bot AI và mục đích của từng bot (bot huấn luyện, bot tìm kiếm và bot “fetch this page right now” (bản dịch) «lấy trang này ngay bây giờ»), đó là chủ đề riêng — xem Crawler AI. Trang này nói về cách làm: lấy nhật ký và đọc chúng.

Vì sao dashboard không cho bạn thấy điều này?

• Google Search Console có báo cáo Crawl Stats nhưng chỉ nói về Googlebot. Nó không hiển thị GPTBot, ClaudeBot hay PerplexityBot.
• Google Analytics (GA4) chỉ ghi nhận người nhấp vào liên kết đến trang web và đến cùng một “referrer”. Crawler lấy trang ở chế độ nền hoàn toàn không xuất hiện ở đó.

Vì vậy, nhật ký là nguồn sự thật. Không công cụ nào khác nhìn thấy bot.

Điều người mới thường bỏ sót

Nhãn GPTBot trong nhật ký không chứng minh đó thực sự là OpenAI. Bất kỳ ai cũng có thể đặt chuỗi người dùng-agent tùy ý vào một yêu cầu — giống như tự viết địa chỉ người gửi trên phong bì. Nhiều scraper gắn tên bot nổi tiếng vào lưu lượng của chúng để trông có vẻ hợp lệ. Cách duy nhất để chắc chắn là kiểm tra địa chỉ IP của bên truy cập với danh sách địa chỉ thật làm công ty AI công bố. Bước xác minh đó là cốt lõi của quy trình đúng, và tab Advanced sẽ hướng dẫn cách thực hiện.

Tóm tắt — Lấy access log Apache/Nginx hoặc CDN rồi làm bốn việc: xác minh (đối chiếu user-agent và IP với danh sách từng nhà vận hành công bố — tỷ lệ giả mạo từ 5,7% trong dữ liệu HUMAN Security đến 81,8% trong phép thử của Duane Forrester); chọn công cụ theo quy mô (grep → Screaming Frog Log File Analyser → ELK/Splunk → BigQuery/Cloudflare); đo lường tần suất crawl theo bot, trang được truy cập, crawl so với render và mã trạng thái; và diễn giải trung thực — retrieval là điều kiện cần nhưng chưa đủ, nên “more crawling = more citations” (bản dịch) «crawl nhiều hơn = được trích dẫn nhiều hơn» chưa được chứng minh. Đây là bài phương pháp song hành với Crawler AI (phụ trách bot là gì), Phân bổ traffic AI (phía lượt nhấp) và Khả năng hiển thị LLM (khung được truy xuất → được nhắc → được trích dẫn; nhật ký chỉ quan sát giai đoạn đầu).

Bài này phụ trách gì — và không phụ trách gì?

Nhật ký chứng minh request đã xảy ra, không chứng minh nội dung được dùng cho huấn luyện, retrieval hay câu trả lời. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files Khi có, hãy xác minh bot bằng cơ chế nhà cung cấp công bố và coi attribution là bằng chứng có giới hạn. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

Bài Crawler AI song hành đã phụ trách bảng theo từng bot, taxonomy ba nhóm (huấn luyện / tìm kiếm AI / fetch do người dùng kích hoạt), khác biệt Google-Extended là token chứ không phải bot và công thức robots.txt. Tôi không trình bày lại ở đây. Phân bổ traffic AI phụ trách phía GA4/referrer — bot gửi gì trở lại. Bài này nói về phía đối diện của funnel: bot lấy gì đi. Còn Khả năng hiển thị LLM phụ trách khung được truy xuất → được nhắc → được trích dẫn; phân tích log chỉ quan sát riêng giai đoạn được truy xuất, không cho biết bước nào sau đó.

Đây là phần tiếp nối trong kỷ nguyên AI của phân tích log SEO cổ điển. Khi tôi đánh giá bài Cách thực hiện phân tích log SEO của Ahrefs, các chiều phân tích là tần suất crawl, URL được crawl, mã trạng thái và xác minh bot với IP Google công bố. Khung ở đây tương tự, nhưng hướng vào nhóm bot phần lớn không render JavaScript, thường xuyên bị giả danh và crawl theo đợt thất thường thay vì dòng đều đặn.

Bước 1 — Lấy nhật ký

Nhật ký của bạn nằm ở một trong hai nơi, hoặc cả hai:

• Nhật ký máy chủ gốc. Apache (access.log), Nginx (access.log) hoặc máy chủ ứng dụng. Mỗi dòng tối thiểu có timestamp, IP máy khách, phương thức + đường dẫn yêu cầu, mã trạng thái, bytes, referrer và người dùng-agent.
• Nhật ký CDN / edge. Nếu đứng sau Cloudflare, Fastly, Akamai, v.v., nhiều lưu lượng bot được trả lời ở edge và có thể không bao giờ đến origin — vì vậy nhật ký edge mới đầy đủ hơn. Cloudflare cung cấp dữ liệu qua Logpush (và GraphQL API), còn Fastly có tính năng stream nhật ký theo thời gian thực.

Các trường thực sự cần cho phân tích bot AI là timestamp, client IP, user-agent, đường dẫn request, mã trạng thái, và tốt nhất có thêm số byte cùng referrer.

Vấn đề thực tế là thời gian lưu trữ. Nhiều host chỉ giữ nhật ký trong vài ngày. Bài viết của Lauren Busby trên Search Engine Land nêu thẳng cách khắc phục: một lượt lấy theo lịch biến cửa sổ ngắn thành dữ liệu có thể phân tích theo thời gian. Một job SFTP theo lịch, workflow như n8n hoặc script là đủ để biến thời gian lưu trữ ngắn thành thứ bạn có thể thực sự phân tích lâu dài (Busby, SEL). Hãy thiết lập trước khi cần dữ liệu.

Một giới hạn cần ghi nhớ ngay từ đầu: như Busby nói, tệp nhật ký cho bạn biết điều gì đã đến trang web, nhưng không phải lúc nào cũng cho biết điều gì đã cố đến (SEL) — các yêu cầu bị chặn hoặc được trả lời ở upstream có thể hoàn toàn không xuất hiện.

Bước 2 — Xác minh trước khi tin người dùng-agent

Đây là bước phân biệt phân tích nhật ký bot AI với phiên bản SEO kinh điển, nhưng lại thường bị bỏ qua trong các bài hướng dẫn khác. Chuỗi người dùng-agent rất dễ bị giả mạo. Hai dữ liệu độc lập cho thấy vấn đề nghiêm trọng đến đâu:

• HUMAN Security phân tích hai tuần traffic tự nhận là một trong 16 crawler AI nổi tiếng và thấy 5,7% là giả mạo — khoảng 1 trong 18 request (được SEJ thuật lại).
• Duane Forrester thực hiện cùng phép kiểm tra trên log của mình và thấy kết quả tệ hơn nhiều. Trong 33 request mang tên live-fetch, sáu request đến từ IP nhà cung cấp công bố còn 27 thì không — tỷ lệ giả mạo 81,8% trong số request có thể kiểm tra (SEJ). Con số Googlebot còn tệ hơn: trong 799 request mang tên Googlebot, chỉ 107 đến từ địa chỉ Google đã xác minh — khoảng 87% còn lại không phải Google (SEJ).

Hãy coi các con số đó là chỉ dấu từ những mẫu và phương pháp khác nhau, không phải một tỷ lệ phổ quát. Quan trọng hơn, đừng áp dụng phương thức xác minh của một nhà cung cấp cho mọi bot. Một số operator công bố dải địa chỉ; số khác chỉ mô tả token người dùng-agent mà không có dải công khai hiện hành hay hợp đồng xác minh DNS (SEJ).

Phương thức xác minh:

1. Đối chiếu chuỗi user-agent. GPTBot tự nhận diện bằng Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.3; +https://openai.com/gptbot; OAI-SearchBot và ChatGPT-User có token riêng (tài liệu bot OpenAI).
2. Dùng phương thức xác minh chính thức hiện hành của nhà cung cấp nếu có. OpenAI cung cấp openai.com/gptbot.json, searchbot.json và chatgpt-user.json. Tài liệu crawler hiện hành của Anthropic nói rằng địa chỉ trong danh sách công bố của họ cho biết crawler đến từ Anthropic. Hãy dùng phương thức riêng hiện hành của từng nhà cung cấp; đừng biến nó thành quy tắc xác minh bot phổ quát.
3. Không tự bịa phương án dự phòng. DNS ngược rồi xuôi chỉ hợp lệ khi nhà cung cấp công bố mẫu hostname và quy trình xác minh. PTR khớp chung chỉ chứng minh quyền kiểm soát DNS, không chứng minh danh tính bot được khai báo. Screaming Frog Log File Analyser có thể áp dụng danh sách được xác nhận công khai khi có; tính năng verify-on-import tra cứu danh sách IP công khai để xác nhận bot là thật (Screaming Frog).

Việc xác minh nên cung cấp căn cứ cho chính sách cụ thể và phản hồi sự cố. Ưu tiên token robots được nhà cung cấp tài liệu hóa cho chính sách crawl; chỉ dùng kiểm soát mạng cho trường hợp lạm dụng hoặc bảo mật, và ghi nhãn chúng tách biệt với việc tuân thủ robots.

Bước 3 — Chọn công cụ

Hãy chọn theo quy mô công việc, từ miễn phí → trả phí và từ dữ liệu gốc → dịch vụ được quản lý:

• grep / PowerShell — đếm nhanh một lần và lọc có xét xác minh. Bài Crawler AI có đoạn mã đếm bot cơ bản; thẻ Scripts ở đây mở rộng thành xác minh IP, phân tích mã trạng thái và phát hiện crawl so với render.
• Screaming Frog Log File Analyser — công cụ desktop nhập log, có preset bot AI tích hợp (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot) và nút “Verify Bots When Importing” (bản dịch) «Xác minh bot khi nhập». Thẻ Response Codes phân tích 2XX/3XX/4XX/5XX theo URL; User Agents hiển thị request và tỷ lệ lỗi theo bot; URLs sắp theo Num Events để thấy trang được fetch nhiều nhất; IPs giúp điều tra nguồn đáng ngờ (hướng dẫn).
• ELK Stack (Elasticsearch / Logstash / Kibana) hoặc Splunk — nhập liên tục ở quy mô lớn hơn, kèm dashboard và cảnh báo, khi công cụ desktop nhập một lần quá chậm hoặc bạn cần giám sát liên tục thay vì export định kỳ.
• BigQuery — lưu dài hạn và truy vấn SQL ở quy mô lớn, thường nhận dữ liệu từ Cloudflare Logpush hoặc lượt lấy GraphQL theo lịch từ dataset httpRequestsAdaptiveGroups của Cloudflare, để truy vấn hoạt động bot theo trang, ngày và mã trạng thái mà không phải nhập lại file phẳng.
• Cloudflare AI Crawl Control (cho site dùng Cloudflare) — dashboard được quản lý về hoạt động crawler, mẫu request, xác minh bot và tuân thủ directive mà không phải tự xây pipeline (tài liệu).

Bước 4 — Đo gì và đọc như thế nào?

Tần suất crawl theo bot. Đếm lượt theo ngày/tuần cho từng tên bot. Bot AI crawl theo đợt, không đều đặn. Trong nghiên cứu nhật ký CDN 48 ngày của WISLR, GPTBot vắng mặt nhiều tuần rồi tạo 187 yêu cầu trong một tuần — 152 yêu cầu trong số đó dồn vào một đợt ba phút, đạt đỉnh 114 yêu cầu/phút (WISLR). Hãy đọc tần suất như một mẫu hành vi, không chỉ là tổng số.

Trang nào được truy cập — và trang quan trọng nào không. Sắp xếp theo số yêu cầu. Busby lưu ý crawler AI thường chỉ đi nông — thường chỉ thấy chúng giới hạn ở trang cấp cao: trang chủ, điều hướng chính và một số ít URL cấp cao (SEL) — rồi giảm mạnh ở các trang sâu, dù chính các trang sâu đó có thể quan trọng nhất cho việc được trích dẫn. Trang sâu không bao giờ xuất hiện trong nhật ký thì không thể được retrieval.

Phụ thuộc HTML thô — hãy đo, đừng khái quát hóa. Tài liệu nhà cung cấp không đưa ra một hợp đồng render JavaScript dùng chung cho GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot và các agent khác. Một dấu hiệu quan sát vẫn hữu ích: trong mẫu WISLR, ChatGPT-User chỉ lấy HTML — không request ảnh, CSS hay file JS — trong khi Googlebot và OAI-SearchBot cũng lấy ảnh (WISLR). Nếu log cho thấy bot AI liên tục gọi trang có HTML thô gần như chỉ là shell JS rỗng, đó là rủi ro phụ thuộc có thể kiểm tra, không phải bằng chứng mọi nhà cung cấp luôn hành xử như vậy. Hãy so sánh HTML được phân phối với kết quả hoặc phép thử fetch riêng theo nhà cung cấp. (Xem JavaScript SEO để biết nền tảng về render.)

Phân tích mã trạng thái / yêu cầu bị chặn. Theo dõi: 200 (thành công), 304 (không thay đổi — crawl lại hiệu quả), 404 (liên kết hỏng mà bot đã theo) và 403/429 (bị chặn / giới hạn tốc độ). Busby nhấn mạnh rằng nhật ký cho thấy nơi crawler gặp vấn đề, gồm phản hồi 403 (yêu cầu bị chặn) và 429 (giới hạn tốc độ) (SEL). Hãy kiểm tra việc chặn đó là chủ ý hay tai nạn.

Request robots.txt và llms.txt là tín hiệu riêng. Đối chiếu bot nào request /robots.txt trước khi crawl — trong mẫu WISLR, GPTBot và Meta-WebIndexer không hề kiểm tra tệp đó suốt 48 ngày — và đường dẫn bị cấm có vẫn bị truy cập không. WISLR cũng ghi nhận không có request tới /llms.txt từ bất kỳ bot AI nào trong 48 ngày đó (WISLR), phù hợp với phát hiện khoảng 97% không được đọc trong bài Crawler AI. Đừng coi request llms.txt trong log là bằng chứng nó “hoạt động”.

Crawl nhiều hơn có nghĩa là được trích dẫn nhiều hơn không? Hãy trung thực.

Không có dữ liệu đã được thiết lập nào hỗ trợ “crawl more, get cited more” (bản dịch) «crawl nhiều hơn, được trích dẫn nhiều hơn». Retrieval là điều kiện cần cho trích dẫn nhưng còn xa mới đủ — trang thường xuyên được crawl mà không bao giờ được dẫn, do render phía máy khách, paywall, nội dung mỏng hoặc trùng lặp, hay đơn giản thua nguồn tốt hơn ở bước retrieval/xếp hạng của model. Khung cốt lõi nằm trong bài khả năng hiển thị LLM: được truy xuất → được nhắc → được trích dẫn; phân tích log chỉ quan sát giai đoạn đầu.

Để khép vòng một cách trung thực, hãy ghép phía đầu vào crawl (log của bạn) với phía đầu ra trích dẫn. Báo cáo AI Performance của Bing (public preview, tháng 2/2026) là công cụ chính thức đầu tiên hiển thị dữ liệu trích dẫn cùng grounding query — các cụm từ chính AI dùng khi truy xuất nội dung được tham chiếu trong câu trả lời do AI tạo (Bing Webmaster Blog). Log cho biết nội dung nào đã bị lấy; grounding query và số trích dẫn cho biết kết quả. Không bên nào tự nó cho toàn cảnh — xem hub đo lường và báo cáo để biết các lớp này kết hợp thế nào.

Điểm khó của việc crawl lén

Xác minh không phải audit một lần. Theo Clint Spaulding của Seer Interactive, sau khi bị chặn, crawler lén có thể xuất hiện lại dưới header trình duyệt chung và IP không liên quan — các phiên đó trông như người trong log, khiến số phiên bị đội lên, traffic bot bị đếm thiếu và phân đoạn GEO kém tin cậy hơn (Seer). Tóm tắt thẳng thắn của ông: nếu không nhìn thấy crawler lén, bạn không thể đo tác động của chúng. Đó là lý do phân tích log cần xác minh lại và thiết lập baseline lại định kỳ, không phải chỉ một lượt.

Tóm tắt AI

Tóm lược cô đọng của phiên bản Advanced:

• Phân tích log crawler AI = đọc log máy chủ/CDN thô để tìm request của bot AI, dùng dữ liệu bên thứ nhất xác minh bot nào truy cập, bot có thật không và nhận được gì. GSC (chỉ Googlebot) và GA4 (chỉ referrer) không thấy hoạt động này.
• Phạm vi: đây là phương pháp. Bot là gì thuộc bài Crawler AI; phía lượt nhấp thuộc Phân bổ traffic AI; khung được truy xuất → được nhắc → được trích dẫn thuộc Khả năng hiển thị LLM (log chỉ quan sát trạng thái được truy xuất).
• Tách danh tính đã xác minh khỏi user-agent tự nhận. User-agent có thể bị giả — HUMAN Security đo 5,7% trên 16 bot; Duane Forrester tự kiểm tra thấy 81,8% request live-fetch là giả (87% với Googlebot). Đối chiếu UA và IP nguồn với danh sách chính thức hiện hành của nhà vận hành khi có (ví dụ openai.com/gptbot.json hoặc claude.com/crawling/bots.json của Anthropic). Không tự bịa phương án DNS ngược chung.
• Công cụ theo quy mô: grep → Screaming Frog LFA (preset AI + xác minh khi nhập) → ELK/Splunk → BigQuery / Cloudflare AI Crawl Control.
• Đo lường: tần suất crawl theo bot (theo đợt, ví dụ 152 request GPTBot trong 3 phút ở WISLR), trang được truy cập, phụ thuộc HTML thô (mẫu ChatGPT-User của WISLR không lấy ảnh/CSS/JS), mã trạng thái (403/429) và request robots.txt/llms.txt (WISLR không ghi nhận lượt truy cập llms.txt nào trong 48 ngày).
• Crawl ≠ trích dẫn. Retrieval là điều kiện cần nhưng chưa đủ — “more crawls = more citations” (bản dịch) «crawl nhiều hơn = được dẫn nhiều hơn» chưa được chứng minh. Ghép log với grounding query của Bing để khép vòng.
• Xác minh lại định kỳ — crawler lén bị chặn có thể xuất hiện lại như người dùng.

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

Nguồn chính — tệp xác minh của chính operator bot và tài liệu nền tảng.

OpenAI

• Tài liệu bot / crawler OpenAI — chuỗi user-agent và hành vi của GPTBot, OAI-SearchBot, ChatGPT-User và OAI-AdsBot.
• Danh sách IP công bố để xác minh: gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json.

Anthropic

• Anthropic có crawl dữ liệu từ web không? — tên bot hiện hành, mục đích, kiểm soát robots và tuyên bố rằng địa chỉ trong danh sách công bố cho biết đó là crawler Anthropic.
• Danh sách IP crawler Anthropic — nguồn xác minh dùng chung hiện hành cho ClaudeBot, Claude-SearchBot và Claude-User.

Google

• Báo cáo Crawl Stats — góc nhìn của Google về hoạt động crawl (chỉ Googlebot; không bao phủ bot AI bên thứ ba, vì vậy cần log thô cho chúng).

Cloudflare

• AI Crawl Control — dashboard được quản lý cho hoạt động crawler AI, xác minh bot và tuân thủ directive.

Bing / Microsoft

• Giới thiệu AI Performance trong Bing Webmaster Tools (Public Preview) — phần đối chiếu kết quả trích dẫn cho phân tích log: Total Citations, Average Cited Pages, Grounding Queries và hoạt động trích dẫn cấp trang.

Trích dẫn từ nguồn

Các phát biểu được ghi nhận từ operator và những người thực hành có tên.

Anthropic — phạm vi hiện hành

• Trang hỗ trợ hiện hành của Anthropic phân biệt ClaudeBot, Claude-SearchBot và Claude-User, mô tả cách áp dụng kiểm soát robots và nói rằng địa chỉ trong danh sách công bố cho biết đó là crawler Anthropic. Nguồn

Lauren Busby, đồng sáng lập Trebletree — Search Engine Land

• “Log files are the closest thing to that missing layer. They don’t summarize or interpret activity. They record it — every request, every URL, every crawler.” (bản dịch) «Log là thứ gần nhất với lớp còn thiếu đó. Chúng không tóm tắt hay diễn giải hoạt động; chúng ghi lại mọi request, mọi URL, mọi crawler.»
• “Tools like Screaming Frog Log File Analyzer make it possible to process that data quickly.” (bản dịch) «Công cụ như Screaming Frog Log File Analyzer giúp xử lý dữ liệu đó nhanh chóng.»
• Về độ sâu của crawler AI: “It’s common to see them limited to top-level pages – the homepage, primary navigation, and a small number of high-level URLs.” (bản dịch) «Thường thấy chúng chỉ giới hạn ở trang cấp cao — trang chủ, điều hướng chính và một số ít URL cấp cao.»
• Về vấn đề được phát hiện: “Log files also surface where crawlers encounter issues. This includes: 403 responses (blocked requests). 429 responses (rate limiting).” (bản dịch) «Log cũng cho thấy nơi crawler gặp vấn đề, gồm phản hồi 403 (request bị chặn) và 429 (giới hạn tốc độ).»
• Về lưu trữ: “A scheduled SFTP job – whether built in a workflow tool like n8n, or scripted – is enough to turn a short retention window into something you can actually analyze over time.” (bản dịch) «Một job SFTP theo lịch — được xây trong công cụ workflow như n8n hay bằng script — đủ để biến cửa sổ lưu trữ ngắn thành dữ liệu có thể phân tích theo thời gian.»
• Giới hạn trung thực: “Log files show you what reached your site. They don’t always show you what tried to.” (bản dịch) «Log cho biết điều gì đã đến site, nhưng không phải lúc nào cũng cho biết điều gì đã cố truy cập.» Nguồn

Duane Forrester — Search Engine Journal

• “Of 33 requests carrying one of those live-fetch names. Six came from an IP the vendor publishes. Twenty-seven did not. That is an 81.8% spoof rate among the requests I could check.” (bản dịch) «Trong 33 request mang một trong các tên live-fetch đó, sáu đến từ IP nhà cung cấp công bố còn 27 thì không. Đó là tỷ lệ giả mạo 81,8% trong số request tôi có thể kiểm tra.»
• “The real check is not complicated. The major operators publish the actual IP addresses their bots use, as plain files you can open right now, and a request is legitimate only if the name matches and the address sits inside the published list.” (bản dịch) «Phép kiểm tra thật không phức tạp. Các nhà vận hành lớn công bố địa chỉ IP thật mà bot dùng dưới dạng file có thể mở ngay; request chỉ hợp lệ khi tên khớp và địa chỉ nằm trong danh sách công bố.»
• Về Googlebot để thấy quy mô: “Of 799 requests carrying the Googlebot name, only 107 came from a verified Google address. The other 692, roughly 87%, were not Google.” (bản dịch) «Trong 799 request mang tên Googlebot, chỉ 107 đến từ địa chỉ Google đã xác minh. 692 request còn lại, khoảng 87%, không phải Google.»
• Lời kêu gọi hành động: “Do not take my numbers; take the method… Pull a date range, match the names, verify the IPs against the published lists, and find your real fraction.” (bản dịch) «Đừng lấy con số của tôi; hãy lấy phương pháp… Lấy một khoảng ngày, đối chiếu tên, xác minh IP với danh sách công bố và tìm tỷ lệ thật của bạn.» Nguồn

Clint Spaulding, quản lý cấp cao về SEO kỹ thuật, Seer Interactive

• “Once blocked, stealth crawlers can reappear under generic browser headers and unrelated IPs.” (bản dịch) «Sau khi bị chặn, crawler lén có thể xuất hiện lại dưới header trình duyệt chung và IP không liên quan.»
• “These sessions look human in logs. That means session counts get inflated, bot traffic gets undercounted, and GEO segmentation becomes less trustworthy.” (bản dịch) «Các phiên này trông như người dùng trong log. Điều đó làm số phiên bị đội lên, traffic bot bị đếm thiếu và phân đoạn GEO kém tin cậy hơn.»
• “If you can’t see these stealth crawlers, you can’t measure their impact.” (bản dịch) «Nếu không thể nhìn thấy các crawler lén này, bạn không thể đo tác động của chúng.» Nguồn

Screaming Frog — hướng dẫn Log File Analyser (tài liệu sản phẩm)

• Về xác minh khi nhập: “Search engine bots are often spoofed, and this performs a lookup against publicly confirmed IP lists to confirm they are genuine.” (bản dịch) «Bot công cụ tìm kiếm thường bị giả mạo; tính năng này tra cứu danh sách IP đã xác nhận công khai để xác minh chúng là thật.»
• “If you see high request volumes from IPs that don’t verify, you’re likely dealing with fake bot traffic that should be blocked at server level.” (bản dịch) «Nếu thấy lượng request lớn từ IP không xác minh được, nhiều khả năng bạn đang gặp traffic bot giả cần chặn ở cấp máy chủ.» Nguồn

Bing Webmaster Tools — báo cáo AI Performance (public preview tháng 2/2026)

• Grounding Queries: “Shows the key phrases the AI used when retrieving content that was referenced in AI-generated answers.” (bản dịch) «Hiển thị các cụm từ chính AI dùng khi truy xuất nội dung được tham chiếu trong câu trả lời do AI tạo.»
• Total Citations: “Shows the total number of citations that are displayed as sources in AI-generated answers during the selected time frame.” (bản dịch) «Hiển thị tổng số trích dẫn được trình bày như nguồn trong câu trả lời do AI tạo ở khoảng thời gian đã chọn.» Nguồn

“Request bot AI này có thật không và tôi nên làm gì?”

Hãy đưa một dòng nhật ký đáng ngờ — hoặc toàn bộ lưu lượng của bot — qua cây này. Đây là logic xác minh ở Bước 2 được chuyển thành một luồng quyết định.

Checklist phân tích nhật ký crawler AI

Một lượt kiểm tra có thể lặp lại, từ lấy nhật ký đến đọc dữ liệu:

• Log đang được thu với các trường cần thiết: timestamp, client IP, user-agent, đường dẫn request, mã trạng thái (số byte + referrer cũng hữu ích).
• Bạn lấy dữ liệu từ đúng lớp — log CDN/edge nếu đứng sau Cloudflare/Fastly (nhiều traffic bot không bao giờ tới origin).
• Lượt lấy theo lịch (SFTP/n8n/script) vượt qua cửa sổ lưu trữ để có lịch sử, không chỉ vài ngày gần nhất.
• Mọi request bot AI đều được xác minh: user-agent khớp và IP nguồn được đối chiếu với danh sách nhà vận hành công bố (DNS ngược chỉ là phương án phụ khi có tài liệu).
• Request giả mạo/chưa xác minh bị loại khỏi chỉ số crawl AI, không được tính là bot mang tên đó.
• Có baseline tần suất crawl theo từng bot (theo dõi mẫu theo đợt so với đều đặn).
• Đã xác định trang được fetch nhiều nhất — và xác nhận trang sâu/ưu tiên có được crawl hay không.
• Đã kiểm tra crawl so với render: bot AI có chỉ lấy HTML trên trang được render bằng JS không? (Ghi đây là phép thử phụ thuộc HTML thô; hành vi tùy agent và có thể không được tài liệu hóa.)
• Đã xem mã trạng thái: 200/304 khỏe; 404 là liên kết hỏng; 403/429 được xác nhận là có chủ ý hoặc đã sửa.
• Đã kiểm tra request robots.txt (bot có lấy tệp trước khi crawl không?); không có lượt truy cập bất ngờ vào đường dẫn bị cấm.
• Đã ghép với dữ liệu phía trích dẫn (grounding query Bing / tính năng AI trong GSC) trước khi kết luận “có hoạt động không”.
• Đã lên lịch xác minh lại — đây không phải audit một lần (crawler lén có thể tái xuất như người dùng).

Bảng tra nhanh phân tích nhật ký crawler AI

Tệp xác minh (hãy lưu lại)

Mã trạng thái cần theo dõi

Xác minh, đừng chỉ tin

• Chỉ có user-agent = chưa xác minh. Đối chiếu UA và dữ liệu xác minh nhà cung cấp công bố khi có; nếu không, giữ nguyên sự không chắc chắn.
• Tỷ lệ giả mạo quan sát ngoài thực tế: 5,7% (HUMAN, 16 bot) → 81,8% (log live-fetch của Forrester); 87% Googlebot giả trong cùng audit.

Dấu hiệu phụ thuộc HTML thô

• Bot chỉ lấy HTML, không có yêu cầu .js/.css/ảnh, là một mẫu fetch quan sát được. Trên trang phụ thuộc JS, đó là tín hiệu rủi ro, không phải bằng chứng về năng lực phổ quát.

Thông tin nhanh

• Tần suất crawl ≠ khả năng được trích dẫn. Retrieval là điều kiện cần nhưng chưa đủ.
• Dùng token robots đã được tài liệu hóa cho chính sách crawl; giữ chặn mạng như một biện pháp riêng cho lạm dụng/bảo mật.

Script cho phân tích nhật ký crawler AI

Bài Crawler AI có đoạn mã “đếm lượt bot” cơ bản. Các script dưới đây đi xa hơn: trích xuất, xác minh, phân tích mã trạng thái và phát hiện crawl so với render.

1. Trích xuất từng dòng bot AI (grep + regex)

macOS / Linux — một biểu thức thay thế cho các người dùng-agent AI phổ biến:

# Pull all AI-bot requests from a combined-format access log
grep -Ei 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Applebot|Amazonbot|Bytespider|CCBot|Meta-ExternalAgent' \
  access.log > ai-bots.log

# Count requests per bot (which token, how many hits)
grep -Eoi 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Perplexity-User|CCBot|Bytespider' \
  access.log | sort | uniq -c | sort -rn

Windows PowerShell:

Select-String -Path .\access.log -Pattern 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider' |
  ForEach-Object { ($_ -match '(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider)') | Out-Null; $Matches[1] } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

2. Xác minh IP GPTBot được khai báo với danh sách OpenAI công bố

Chỉ người dùng-agent không chứng minh gì — hãy kiểm tra IP. Đoạn này lấy danh sách của OpenAI rồi kiểm tra IP trong nhật ký có nằm trong một CIDR đã công bố hay không:

# Requires jq and (for CIDR math) grepcidr — brew/apt install both
IP="203.0.113.45"   # the IP from your log line
curl -s https://openai.com/gptbot.json \
  | jq -r '.prefixes[].ipv4Prefix // .prefixes[].ipv6Prefix' \
  | while read -r cidr; do
      echo "$IP" | grepcidr "$cidr" >/dev/null 2>&1 && echo "VERIFIED in $cidr"
    done
# No output = the IP is NOT in OpenAI's published range → treat as spoofed.

Với Anthropic, hãy lấy danh sách hiện hành từ https://claude.com/crawling/bots.json và điều chỉnh đường dẫn jq theo cấu trúc được tài liệu hóa. Nếu operator không công bố feed xác minh hiện hành, hãy giữ kết quả là người dùng-agent tự nhận.

3. DNS ngược + xuôi làm phương án phụ (IP ngoài danh sách)

Chỉ dùng cách này khi provider được nêu tên công bố hậu tố hostname dự kiến và quy trình xác minh ngược-xuôi. Đây không phải bằng chứng chung cho danh tính bot:

IP="203.0.113.45"
HOST=$(host "$IP" | awk '/pointer/ {print $NF}' | sed 's/\.$//')
echo "PTR: $HOST"
host "$HOST" | grep -q "$IP" && echo "FORWARD-CONFIRMED" || echo "MISMATCH → suspect"

4. Phân tích mã trạng thái theo bot

Phát hiện việc chặn 403/429 và các lỗi 404s mà bot gặp phải:

# For GPTBot: tally status codes (combined log format; $9 is the status)
grep -i 'GPTBot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# → e.g. "812 200 / 47 404 / 15 403" — the 403s are worth investigating

5. Tín hiệu phụ thuộc HTML thô — bot đang lấy loại tệp nào?

Nếu bot tự nhận chỉ lấy .html// mà không bao giờ lấy .js/.css/ảnh, trong khi nội dung của bạn được render bằng JS, đó là tín hiệu phụ thuộc cần điều tra:

# What extensions is ChatGPT-User actually requesting?
grep -i 'ChatGPT-User' access.log \
  | awk '{print $7}' \
  | grep -oE '\.(html?|js|css|png|jpe?g|webp|svg|woff2?)(\?|$)' \
  | sort | uniq -c | sort -rn
# All HTML, zero subresources = compare the raw body with provider-specific outcomes.

6. Chrome DevTools Console — phát hiện fetch AI trên trang đang chạy

Đoạn này không ghi nhật ký yêu cầu, nhưng kiểm tra nhanh nội dung trang gửi trong HTML thô so với sau khi chạy JS (bot AI có thể hoặc không nhìn thấy gì). Dán vào Console:

// Compare rendered text length to what's in the initial HTML source.
// A big gap means most content depends on JS; provider behavior must be verified separately.
(async () => {
  const raw = await (await fetch(location.href, { cache: "no-store" })).text();
  const rawText = new DOMParser().parseFromString(raw, "text/html").body.innerText.trim().length;
  const renderedText = document.body.innerText.trim().length;
  console.log({ rawText, renderedText, jsDependentRatio: +(1 - rawText / renderedText).toFixed(2) });
})();
// jsDependentRatio near 1 = almost all content is JS-injected; flag dependency, not invisibility.

7. Bookmarklet — mở danh sách IP của từng bot

Kéo đoạn này thành bookmark để mở các tệp xác minh trong nhiều tab và tra cứu nhanh:

javascript:(function(){["https://openai.com/gptbot.json","https://openai.com/searchbot.json","https://openai.com/chatgpt-user.json","https://claude.com/crawling/bots.json"].forEach(u=>window.open(u,"_blank"));})();

SOP: rà soát nhật ký crawler AI hằng tháng

Quy trình lặp lại theo nhịp định kỳ (hằng tháng với phần lớn site; hằng tuần nếu traffic AI quan trọng). Mỗi lần chạy tạo một baseline có thể so sánh.

Chuẩn bị

1. Lấy cửa sổ log kể từ lần đánh giá trước từ đúng lớp (log CDN/edge nếu đứng sau CDN, nếu không thì log origin). Xác nhận lượt lấy SFTP/n8n theo lịch thực sự đã chạy — khoảng trống ở đây âm thầm phá vỡ đường xu hướng.
2. Nạp vào công cụ chuẩn (Screaming Frog LFA cho lượt nhập định kỳ; BigQuery/ELK nếu dùng pipeline).

Xác minh (không bao giờ bỏ qua) 3. Làm mới từng nguồn xác minh hiện hành do nhà cung cấp công bố (gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json và claude.com/crawling/bots.json của Anthropic) — chúng thay đổi. 4. Bật verify-on-import (Screaming Frog) hoặc chạy kiểm tra IP-trong-CIDR (thẻ Scripts) với mọi request bot AI. 5. Chia traffic thành đã xác minh và chưa xác minh. Báo cáo tỷ lệ chưa xác minh — đó là tỷ lệ giả mạo kỳ này. Mức tăng tự nó đã là một phát hiện.

Đo lường (chỉ traffic đã xác minh) 6. So tần suất crawl theo bot với kỳ trước — ghi nhận bot mới, bot biến mất và các đợt tăng. 7. Xác định trang được fetch nhiều nhất; xác nhận trang ưu tiên/trang sâu có được crawl hay không. 8. Kiểm tra nhanh phụ thuộc HTML thô trên 2–3 template nặng JS (bot có chỉ lấy HTML không?). 9. Phân tích mã trạng thái theo bot; điều tra mọi cụm 403/429/404 mới. 10. Kiểm tra sự hiện diện của request robots.txt / llms.txt và mọi lượt truy cập đường dẫn bị cấm.

Báo cáo và hành động 11. Ghi số liệu kỳ này vào bảng theo dõi liên tục (lượt truy cập đã xác minh theo bot, % giả mạo, trang hàng đầu, cụm lỗi) để có xu hướng thay vì ảnh chụp rời rạc. 12. Ghép với dữ liệu phía trích dẫn (grounding query Bing / tính năng AI trong GSC) trước khi kết luận về khả năng hiển thị. 13. Tạo hạng mục sửa cụ thể: chặn có chủ ý hay ngoài ý muốn, khoảng trống render JS, liên kết hỏng, quy tắc user-agent chính xác cho đối tượng giả danh đã xác nhận.

Lưu ý về nhịp: chạy lại xác minh ở mọi kỳ — đừng cache danh sách IP “đã biết là tốt”. Crawler lén có thể tái xuất dưới IP mới và UA trình duyệt chung.

Playbook: “GPTBot (hoặc ClaudeBot) nhận lỗi 403/429 và tôi không biết có chủ ý hay không”

Runbook tuyến tính cho sự cố phổ biến — một bot AI đã xác minh gặp lỗi trong log. Hãy thực hiện đúng thứ tự.

Bước 1 — Trước hết xác nhận đó là bot thật. Trước mọi việc khác, dùng phương thức xác minh chính thức hiện hành của nhà cung cấp được nêu tên. Nếu không có, danh tính vẫn chưa được xác minh; đừng âm thầm coi nó là thật hoặc giả. Lỗi 403 vẫn có thể là WAF đang làm đúng nhiệm vụ.

Bước 2 — Xác định chính xác phản hồi và nguồn phát sinh. Lấy phân tích mã trạng thái cho bot đó (thẻ Scripts). Đó là 403 (bị chặn), 429 (bị giới hạn tốc độ) hay 503? Ghi lại việc chặn nằm ở CDN/WAF, cấu hình máy chủ hay quy tắc liên quan robots.txt.

Bước 3 — Quyết định: việc chặn có chủ ý không?

• Bạn chủ ý chặn bot này (ví dụ crawler huấn luyện mà bạn đã opt out) → lỗi 403 hoạt động đúng thiết kế. Giữ chính sách robots được tài liệu hóa tách khỏi mọi quy tắc lạm dụng/bảo mật cấp mạng. Hoàn tất.
• Bạn không chủ ý chặn bot này (ví dụ OAI-SearchBot / PerplexityBot và bạn muốn khả năng hiển thị tìm kiếm AI) → tiếp tục.

Bước 4 — Tìm quy tắc ngoài ý muốn. Thủ phạm thường gặp: quy tắc WAF “bot” quá rộng, ngưỡng giới hạn tốc độ quá thấp cho crawler theo đợt (hãy nhớ đỉnh 114 request/phút của GPTBot trong dữ liệu WISLR — giới hạn mỗi phút có thể kích hoạt với đợt hợp lệ), lệnh disallow trong robots.txt bị quên, hoặc chặn địa lý/ASN bắt nhầm dải IP của nhà vận hành.

Bước 5 — Sửa chính xác. Cho phép bot đã xác minh theo user-agent + dải IP công bố, hoặc tăng riêng ngưỡng giới hạn tốc độ cho bot đó. Đừng nới bảo vệ cho tất cả.

Bước 6 — Xác minh bản sửa trong log. Sau khi triển khai, lấy lại log của bot. Cụm 403/429 phải chuyển thành 200/304 trên các trang bạn quan tâm.

Bước 7 — Thiết lập lại baseline và theo dõi. Ghi thay đổi vào bảng theo dõi. Kiểm tra lại ở kỳ tiếp theo — và chú ý bot tái xuất dưới UA khác nếu bạn chủ ý chặn nó (crawl lén).

Sai lầm phân tích log dẫn đến kết luận sai

Mỗi mục là một niềm tin ngoài thực tế, lý do nó sai và việc nên làm thay thế.

Ngộ nhận: “Nếu robots.txt chặn bot thì nó sẽ không có trong log / không còn là vấn đề.” Vì sao sai: robots.txt là một request, không phải cơ chế cưỡng chế. Fetcher do người dùng kích hoạt tự loại mình khỏi một số quy tắc, và có báo cáo crawler vượt qua việc chặn (crawl lén của Perplexity, Cloudflare tháng 8/2025). Lệnh chặn có thể bị bỏ qua hoàn toàn. Nên làm: Dùng log để kiểm tra quy tắc có được tuân thủ không — tìm lượt truy cập đường dẫn bị cấm và xem bot có request /robots.txt hay không.

Ngộ nhận: “User-agent GPTBot / ClaudeBot trong log nghĩa là thật sự OpenAI / Anthropic.” Vì sao sai: User-agent rất dễ bị giả — HUMAN Security đo 5,7% giả trên 16 bot, còn Duane Forrester thấy 81,8% request live-fetch của chính ông là giả. Nên làm: Đối chiếu user-agent và dùng phương thức xác minh chính thức hiện hành của nhà vận hành khi có; nếu không, gắn nhãn danh tính chưa xác minh.

Ngộ nhận: “Nhiều lượt crawler AI = dễ được trích dẫn hơn.” Vì sao sai: Không có dữ liệu nhân quả/tương quan đã thiết lập nào hỗ trợ điều đó. Retrieval là điều kiện cần nhưng chưa đủ — trang được crawl nhiều vẫn thường không được dẫn. Nên làm: Xem log chỉ như khả năng quan sát giai đoạn được truy xuất, rồi ghép với dữ liệu phía trích dẫn (grounding query Bing, tính năng AI trong GSC).

Ngộ nhận: “Mọi crawler AI có cùng hành vi render.” Vì sao sai: Các nhà cung cấp không công bố một hợp đồng JavaScript/subresource dùng chung; hành vi quan sát được khác nhau theo agent và mẫu. Nên làm: So sánh phản hồi thô với trang đã render, kiểm tra request subresource theo từng bot được nêu tên và gắn nhãn kết quả là quan sát thay vì phổ quát.

Ngộ nhận: “Bot AI ít nhất cũng kiểm tra llms.txt của tôi.” Vì sao sai: Mẫu 48 ngày của WISLR ghi nhận không có request /llms.txt từ bất kỳ bot AI nào, phù hợp với phát hiện khoảng 97% không đọc trong bài Crawler AI. Nên làm: Đừng coi request llms.txt là phép xác thực được kỳ vọng; hãy đo thứ bot thực sự fetch.

Ngộ nhận: “Chặn mạng và chính sách robots là cùng một biện pháp.” Vì sao sai: robots truyền đạt tùy chọn crawl; firewall cưỡng chế truy cập mạng và có thể ảnh hưởng traffic không liên quan. Nên làm: Dùng quy tắc user-agent được tài liệu hóa cho chính sách, và chỉ chặn mạng khi có lý do lạm dụng/bảo mật riêng.

Trường hợp thực tế

Duane Forrester — tự kiểm tra tỷ lệ giả mạo trong log của mình. Forrester chạy đúng phương pháp này trên site và công bố số liệu. Trong 33 request live-fetch, chỉ 6 đến từ IP nhà cung cấp công bố — tỷ lệ giả mạo 81,8%; trong 799 request mang tên Googlebot, chỉ 107 xác minh được — khoảng 87% giả (SEJ). Trước: nếu tin user-agent, traffic “AI assistant” (bản dịch) «trợ lý AI» của ông trông có vẻ thật. Sau: khi đối chiếu tên với danh sách IP công bố, phần lớn là giả danh. Kết luận: phương pháp quan trọng hơn con số cụ thể — như ông nói, hãy lấy khoảng ngày của bạn và tìm tỷ lệ thật.

WISLR — 48 ngày log CDN và dấu hiệu crawl so với render. Tony Castillo phân tích 288 566 dòng log CDN (12 099 request AI/bot) trong 48 ngày (WISLR). Phát hiện cụ thể: GPTBot vắng mặt nhiều tuần rồi tạo đợt 152 request trong ba phút (đỉnh 114 request/phút); ChatGPT-User không lấy ảnh, CSS hay JS — chỉ trích xuất HTML; và không có request /llms.txt trong toàn bộ cửa sổ. Trước: có thể giả định crawl đều và bot hiểu JS. Sau: log cho thấy hành vi theo đợt, chỉ HTML — n=1, dữ liệu của một site, nhưng minh họa rõ điều phân tích thật phát hiện. Kết luận: mẫu không lấy JS là bằng chứng trực tiếp cho phép kiểm tra crawl so với render.

Cloudflare — tỷ lệ crawl so với referral ở quy mô mạng. Dữ liệu tổng hợp của Cloudflare cho thấy rất ít hoạt động crawl chuyển thành traffic: với mỗi khách truy cập Anthropic giới thiệu về website, crawler của họ đã truy cập hàng chục nghìn trang (Cloudflare). Trước: trực giác cho rằng crawl nhiều nghĩa là tương tác. Sau: ở quy mô mạng, tỷ lệ lệch mạnh — huấn luyện hiện tạo phần lớn hoạt động bot AI, mà bot huấn luyện vốn không nhằm gửi traffic trở lại (Cloudflare). Kết luận: trang được crawl nhiều nhưng không có referral là bình thường, không phải dấu hiệu thành công — chính vì vậy tần suất crawl không dự báo trích dẫn.

Prompt AI dùng ngay

Các prompt có thể sao chép để dùng LLM tăng tốc phân tích log crawler AI. Luôn kiểm tra tính hợp lý của đầu ra với log thô — LLM có thể hallucinate, và pipeline xác minh tin vào kết quả khớp IP bị bịa còn tệ hơn không có pipeline.

Soạn parser log có xét xác minh

Write a Python script that parses combined-format Nginx access logs and, for each
request whose user-agent matches a known AI bot (GPTBot, OAI-SearchBot,
ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot,
Bytespider), does the following:

1. Extract timestamp, client IP, request path, status code, user-agent.
2. Fetch and cache OpenAI's current IP lists (gptbot.json, searchbot.json,
   chatgpt-user.json, adsbot.json) and Anthropic's current bots.json list.
3. Mark an OpenAI or Anthropic request VERIFIED only if the user-agent matches AND
   the client IP falls inside the matching provider-published ranges; mark providers
   without an official method UNVERIFIED, not spoofed.
4. Output two CSVs: verified requests and unverified ("spoofed") requests.
5. Print a summary: verified vs. unverified count per bot, and the top 20 fetched
   paths (verified only).

Do NOT count unverified requests in any per-bot metric. Add clear comments.

Tóm tắt báo cáo mã trạng thái + crawl so với render

I'll paste a table of AI-bot log data (columns: bot, path, status_code,
file_extension). Produce:
- A per-bot status-code breakdown, flagging any 403/429/404 clusters.
- A raw-HTML dependency read: for each bot, the ratio of HTML requests to
  JS/CSS/image requests, and a note on whether the bot appears to fetch only HTML
  in this sample. Treat HTML-only on a JS-rendered page as a dependency risk, not
  proof of a universal no-JavaScript capability.
Keep every conclusion tied to a number from the data — do not infer beyond it.

DATA:
[paste]

Phân loại một IP đáng ngờ

A request in my logs claims to be [BOT NAME] from IP [IP ADDRESS]. Walk me through
verifying it: which operator IP-list file to check, how to test whether the IP is
in range, and the reverse+forward DNS fallback if it's not on a published list.
Tell me explicitly what result means "verified" vs. "treat as spoofed." Do not
guess whether this specific IP is legitimate — give me the steps to check.

Công cụ phân tích log crawler AI

Ước tính: miễn phí/sự thật nền tảng → trả phí/quản lý:

• grep / PowerShell — cách nhanh nhất để đếm lượt bot và lọc access log thô có xét xác minh. Không cần thiết lập; xem thẻ Scripts.
• Screaming Frog Log File Analyser — công cụ desktop nhập log, có preset bot AI tích hợp và nút “Verify Bots When Importing” (bản dịch) «Xác minh bot khi nhập» đối chiếu danh sách IP được xác nhận công khai. Có các thẻ Response Codes, User Agents, URLs (sắp theo Num Events) và IPs. Phù hợp nhất cho lượt nhập định kỳ.
• ELK Stack (Elasticsearch / Logstash / Kibana) hoặc Splunk — nhập liên tục, dashboard và cảnh báo khi việc nhập bằng desktop quá chậm hoặc bạn cần giám sát thường xuyên.
• BigQuery — lưu dài hạn và SQL ở quy mô lớn, thường nhận dữ liệu từ Cloudflare Logpush hoặc lượt lấy GraphQL theo lịch từ httpRequestsAdaptiveGroups.
• Cloudflare AI Crawl Control — cho site dùng Cloudflare: view được quản lý về hoạt động crawler, xác minh bot và tuân thủ directive mà không cần pipeline riêng.
• Google Search Console — Crawl Stats — không dành cho bot AI (chỉ Googlebot), nhưng là mẫu cho phân tích theo crawler + mã phản hồi mà bạn đang xây lại từ log thô cho bot AI.
• Bing Webmaster Tools — AI Performance — phần đối chiếu kết quả trích dẫn: ghép grounding query và số trích dẫn với log đầu vào crawl để khép vòng.

Các đợt tăng đột biến traffic bot AI được khai báo qua đêm

Triệu chứng: request mang user-agent crawler nổi tiếng tăng đột ngột. Nguyên nhân có thể: giả mạo, traffic giám sát hoặc thay đổi crawl thật. Cách khắc phục: xác minh IP nguồn bằng phương thức hiện hành nhà vận hành công bố trước khi quy traffic cho bot, rồi phân đoạn theo ASN, đường dẫn, trạng thái và thời gian.

Log cho thấy crawl nhưng nội dung không bao giờ được trích dẫn

Triệu chứng: bot đã xác minh fetch trang nhưng không tăng trích dẫn hiển thị. Nguyên nhân có thể: crawl chỉ là bằng chứng đủ điều kiện; retrieval và lựa chọn câu trả lời là hai bước riêng. Cách khắc phục: xác nhận bot nhận được HTML có nội dung, rồi đánh giá khả năng lập chỉ mục, chất lượng passage, độ phù hợp truy vấn và sự xác nhận off-site mà không coi số lượt crawl là xếp hạng.

Mọi request dường như đều trả về 200

Triệu chứng: URL bị thiếu và nội dung bị chặn vẫn được ghi là thành công. Nguyên nhân có thể: app shell, quy tắc CDN hoặc trang lỗi tùy chỉnh trả soft 404. Cách khắc phục: lấy mẫu body phản hồi và header cuối, rồi sửa cách xử lý trạng thái thay vì chỉ tin mã trạng thái.

Bot đã xác minh nhận một shell rỗng

Triệu chứng: trình duyệt hiển thị nội dung, nhưng các lượt fetch khớp với log chỉ nhận được rất ít HTML hữu ích. Nguyên nhân có thể: trang phụ thuộc vào JavaScript phía máy khách mà crawler không thực thi. Cách khắc phục: so sánh đầu ra thô với đầu ra đã render, rồi phân phối nội dung và liên kết quan trọng trong HTML qua SSR, render tĩnh hoặc một cơ chế phân phối đáng tin cậy khác.

Các chỉ số cho AI-crawler nhật ký

Tài nguyên đáng đọc

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

• Cách thực hiện phân tích log SEO (Ahrefs, Patrick Stox & Michal Pecánek đánh giá) — mẫu trước kỷ nguyên AI mà bài này tiếp nối cho bot AI: cần đo gì, công cụ và xác minh bot.
• Phân tích log là gì? (thuật ngữ Ahrefs) — bài định nghĩa song hành.
• Gặp các crawler web mới: Bot AI đang tiến gần bot công cụ tìm kiếm — phân tích Cloudflare Radar của tôi về tỷ lệ crawl của bot AI.
• Các bot AI bị khoảng 140 triệu website chặn nhiều nhất — dữ liệu tỷ lệ chặn trong robots.txt trên web mở.
• 80% traffic tìm kiếm AI của chúng tôi đến trang chủ, trang sản phẩm và công cụ miễn phí — phân tích hoạt động AI theo loại trang, tương ứng với câu hỏi “trang nào được crawl”.

Bài nói của tôi

• Tìm kiếm hoạt động thế nào (SlideShare) — phần trình bày của tôi về crawl, render, lập chỉ mục và xếp hạng, là nền tảng hữu ích để đọc hành vi bot trong log. (Vẫn áp dụng tuyên bố miễn trừ: đây là hiểu biết của tôi về hệ thống, không bảo đảm đầy đủ hoặc chính xác 100%.)

Từ ngành

• Vì sao phân tích log quan trọng với crawler AI và khả năng hiển thị tìm kiếm — Lauren Busby (Trebletree), Search Engine Land: khung “log là lớp còn thiếu”, cửa sổ lưu trữ và lỗi 403/429.
• 81,8% traffic “AI Assistant” của tôi là giả; con số Googlebot còn tệ hơn — Duane Forrester, Search Engine Journal: nghiên cứu tình huống xác minh bên thứ nhất và phương pháp nổi bật.
• Perplexity, crawl AI lén và tác động tới GEO cùng phân tích log — Clint Spaulding, Seer Interactive: vì sao bot bị chặn tái xuất như người dùng.
• Cách giám sát bot AI trong Log File Analyser — Screaming Frog: hướng dẫn công cụ thực tế kèm xác minh khi nhập.
• Khoảng cách crawl đến click: dữ liệu Cloudflare về bot AI, huấn luyện và referral — Cloudflare: tỷ lệ crawl/referral cấp mạng và phân tách huấn luyện so với tìm kiếm.
• Anthropic có crawl dữ liệu từ web không? — tài liệu hiện hành của Anthropic về mục đích bot và kiểm soát robots.
• Tài liệu bot / crawler OpenAI — chuỗi user-agent và file IP công bố để xác minh.

Số liệu đáng trích dẫn

• Tỷ lệ giả mạo — 5,7% trên 16 crawler AI. Phân tích hai tuần của HUMAN Security về traffic tự nhận là một trong 16 crawler AI nổi tiếng cho thấy khoảng 1 trong 18 request là giả mạo (số liệu nhà cung cấp, được SEJ thuật lại).
• Tỷ lệ giả mạo — 81,8% trong log của một người làm thực tế. Audit tự thực hiện của Duane Forrester thấy 27 trong 33 request live-fetch đến từ IP nhà cung cấp không công bố; con số Googlebot của ông giả khoảng 87% (SEJ).
• Tỷ lệ crawl/referral, ClaudeBot so với OpenAI. Dữ liệu Cloudflare (tuần 25/5–1/6/2026) đặt ClaudeBot ở khoảng 11 122 trang crawl cho mỗi referral và OpenAI ở khoảng 857:1, so với Googlebot khoảng 5:1 (Cloudflare).
• Huấn luyện tạo phần lớn hoạt động bot AI. Theo Cloudflare, huấn luyện hiện tạo gần 80% hoạt động bot AI, tăng từ 72% một năm trước — bối cảnh giải thích vì sao crawl nhiều mà không có referral vẫn bình thường (Cloudflare).
• Một cửa sổ log thật: 288 566 dòng, 12 099 request bot, 48 ngày. Nghiên cứu tình huống WISLR — với đợt GPTBot tạo 152 request trong 3 phút và ChatGPT-User không lấy ảnh/CSS/JS (WISLR).

Tự kiểm tra: Phân tích nhật ký crawler AI

Năm câu hỏi nhanh về cách lấy và đọc log bot AI. Chọn một đáp án cho mỗi câu rồi kiểm tra.

Nhật ký thay đổi