你在 Google Analytics 裡永遠看不到 GPTBot。GA4 和多數第三方分析工具，都要靠瀏覽器執行 JavaScript 才記下一次造訪，而 GPTBot 不跑 JS、也不會觸發那段追蹤碼。要證明 OpenAI 的爬蟲真的來抓過你的頁面、抓到什麼、拿到哪種回應，唯一可信的證據是伺服器的原始存取日誌（access log）。
為什麼伺服器日誌才是唯一的真相
AI 爬蟲和真人使用者走的是兩條路。真人開瀏覽器，載入頁面、執行 JS、觸發 GA4 事件，於是你在儀表板看到一次工作階段。GPTBot 這類爬蟲只發出一個 HTTP 請求、把回傳的 HTML 收走就離開，不執行你的追蹤程式碼，分析工具因此完全漏記它。伺服器日誌不一樣：每一個打進來的請求，不論來自真人、Googlebot 還是 GPTBot，Nginx 或 Apache 都會逐行寫下來源 IP、時間、請求路徑、回傳狀態碼與 User-Agent。這份紀錄無法被前端擋掉，也不會因為對方不跑 JS 就消失。
先認得三隻 OpenAI 爬蟲，別只盯著 GPTBot
很多人以為 OpenAI 只有一隻爬蟲，於是在 log 裡只搜 GPTBot，結果嚴重低估自己的能見度狀況。OpenAI 至少有三隻用途不同的爬蟲，各自帶不同的 User-Agent，你要分開看待、也要分開統計。
- GPTBot：為模型訓練與改進而抓取，User-Agent 內含「GPTBot」。它遵守 robots.txt，來源 IP 公開在 openai.com/gptbot.json。
- OAI-SearchBot：為 ChatGPT 內的搜尋功能建立索引，User-Agent 內含「OAI-SearchBot」。這隻和你在 ChatGPT 答案裡「被引用」的關係最直接。
- ChatGPT-User：使用者在 ChatGPT 中即時要求讀取某個連結時才觸發，User-Agent 內含「ChatGPT-User」。它出現，代表當下有真人透過 ChatGPT 造訪你的頁面。
- 延伸一步：同一份 log 裡通常還有 PerplexityBot、ClaudeBot、Google-Extended 等其他 AI 爬蟲，判讀方法完全一樣。
第一步：從 access log 撈出 GPTBot 的足跡
以最常見的 Nginx combined 格式為例，一行日誌長這樣：來源 IP、時間、"GET /blog/geo-audit HTTP/1.1"、狀態碼 200、回傳位元組數，最後是 User-Agent 字串。GPTBot 的請求，User-Agent 尾端會標明 compatible; GPTBot/1.2; +https://openai.com/gptbot。有了這個特徵，用幾行指令就能把它的行為攤開。
- 撈出所有 GPTBot 請求：grep -i "GPTBot" /var/log/nginx/access.log
- 數它今天來了幾次：grep -ic "GPTBot" access.log
- 看回傳狀態碼分布（combined 格式第 9 欄是 HTTP 狀態碼）：grep -i "GPTBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
- 看它最常抓哪些頁（第 7 欄是請求路徑）：grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
- 一次比較三隻爬蟲的抓取量：grep -c "GPTBot" access.log；grep -c "OAI-SearchBot" access.log；grep -c "ChatGPT-User" access.log
輸出會立刻告訴你三件事：頻率（一天幾次、集中在哪個時段）、覆蓋範圍（它有沒有抓到你最重要的產品頁和文章，還是只在首頁繞圈），以及回應健康度（狀態碼是不是幾乎都 200）。如果 grep 出來一片空白，代表過去這段時間 GPTBot 根本沒來，那要回頭查 robots.txt 或防火牆是不是把它擋在門外。
第二步：確認這隻 GPTBot 是真的
User-Agent 字串可以隨便偽造。任何爬蟲、甚至惡意流量，都能在標頭裡填上「GPTBot」來假冒身分，藉此繞過某些規則或消耗你的資源。所以撈到之後還要驗真偽，方法有兩個，可靠度都高。
- 比對官方 IP 清單：OpenAI 把各爬蟲的來源 IP 區段公開在 openai.com/gptbot.json、openai.com/searchbot.json、openai.com/chatgpt-user.json。把 log 裡的來源 IP 拿去比對，落在對應區段內才算數。
- 反向 DNS 驗證：對來源 IP 做 PTR 查詢（host 或 dig -x），正牌 GPTBot 會解析回 OpenAI 名下的網域；再對那個網域做一次正向查詢，確認解析回同一個 IP（forward-confirmed rDNS）。兩邊對得上才可信。
第三步：看它抓到什麼、拿到什麼狀態碼
爬蟲有來，不代表你被抓好抓滿。真正決定你能不能被 ChatGPT 引用的，是它每一次請求「拿到什麼」。這裡有四個訊號要盯。
- 狀態碼：理想是清一色 200。大量 403 通常是 Cloudflare 或 WAF 把 GPTBot 當可疑流量擋掉；404 代表你的 sitemap 或內部連結指向已失效的網址；連續 5xx 則是伺服器在爬蟲來的時候出錯。
- 覆蓋的頁面：核對它抓的路徑清單，最該被引用的定價頁、方案頁、深度文章有沒有在裡面。只抓首頁和幾支舊文，等於你的主力內容對 AI 是隱形的。
- llms.txt 與 robots.txt 的命中：log 裡看得到爬蟲有沒有請求 /llms.txt 和 /robots.txt。如果你放了 llms.txt 卻從沒被讀取，代表這隻爬蟲目前不吃這套，別高估它的作用。
- 抓取頻率與新鮮度：對照你發文或改版的時間，看 GPTBot 多久回來重抓一次。回訪間隔太長，代表你的新內容要很久才會進到模型的認知裡。
先看日誌，再談優化
在你花力氣寫 llms.txt、補 Schema、重寫內容之前，先花十分鐘 grep 一次 access log。Tenten 接手過一個案子：客戶的 llms.txt 和 Schema 都做足了，log 一撈才發現 GPTBot 半年來每次都被 WAF 回 403，前面的優化全打了水漂。日誌會誠實告訴你 GPTBot 到底來不來、抓到什麼、被擋在哪，這是所有 GEO 技術優化裡最便宜、也最該先做的一步。想知道自己的日誌藏了哪些能見度缺口、又該先修哪一個，可以預約一場 30 分鐘 GEO 診斷，我們直接對著你的抓取狀況，指出最該動手的地方。
