查 AI crawler 可存取性的做法，是把八層證據分開查：先確認指定 crawler 請求得到，再確認它拿到的內容讀得懂，最後把索引和 AI 產品觀測獨立記錄。這適用於要對某個 URL、某個 crawler、某個日期給出結論的稽核；只用瀏覽器打開頁面看到 200，證明的是你這台電腦在那一刻的結果。本文提供的是可以照著跑的東西：可存取的三個層次、八層檢查表、逐層執行方法與指令示例，以及哪些結論不能從技術檢查推出來。
一個 URL 打不開的原因，比大多數人想的多。robots.txt 的 Allow 只是第一道門，後面還有 DNS、TLS、HTTP 狀態、WAF、登入、noindex、canonical、JavaScript 渲染、空白 HTML。這有點像寄一封掛號信：地址寫對只是最開始，中間還有分揀、投遞、大樓管理室、對方在不在家——任何一關卡住，信都沒送到，而寄件人看到的只是「查無投遞紀錄」。
通過技術檢查不等於索引或 AI citation 成立。
先定義可存取，不要直接寫成可引用
可存取有三個層次：指定 crawler 建立得了連線、收得到頁面回應、回應裡有讀得懂的內容。AI 產品會不會用這份內容，是第四層的產品與查詢選用。用瀏覽器手動打開頁面，證明的是「一般讀者在這個環境打得開」——你的瀏覽器帶著你的 IP、你的 cookie、你的地區，crawler 一項都沒有。
Google 的 robots.txt 介紹 說明 robots.txt 控制 crawler 可以請求哪些 URL，但它不是完整的隱藏機制；Google 的 AI features 文件 則要求頁面可被抓取、編入索引並具備摘要資格，且抓取、索引和顯示都不保證。這兩份官方邊界支持的是分層稽核。從「robots 寫了 Allow」直接跳到「會被 AI 引用」，中間跳過了六層。
跨平台的 user-agent 和政策矩陣已在 robots.txt 管理 AI crawler另行整理。本篇不重複每家 crawler 的名稱，而是提供一個可套用到指定平台、指定 URL 的檢查流程。
八層檢查表總覽
| 層次 | 要回答的問題 | 主要證據 | 常見未確認 |
|---|---|---|---|
| 1. 範圍 | 查哪個 URL、哪個 crawler、哪個日期？ | URL、user-agent、時區 | 沒有固定查詢範圍 |
| 2. 網路 | DNS、TLS、連線是否可用？ | request 結果、錯誤碼 | CDN 或區域限制未讀取 |
| 3. HTTP | 回應是否為可處理的狀態？ | status、header、redirect chain | 只測瀏覽器，不知 crawler response |
| 4. robots | 規則是否允許目標路徑？ | robots.txt 版本與解析結果 | 平台是否遵循未查證 |
| 5. WAF | 安全層是否放行真實 crawler？ | WAF event、IP 或 UA 規則 | UA 可偽造，來源未核對 |
| 6. HTML | 回應是否有標題、文字、連結與指令？ | initial HTML、headers | 只看渲染後畫面 |
| 7. 渲染 | 重要內容是否依賴 JavaScript？ | rendered DOM、錯誤 log | 目標 crawler 是否渲染未知 |
| 8. 索引與產品 | 頁面是否索引、是否在答案中被選用？ | URL tool、Search Console、固定觀測 | 沒有資料不能寫成零 |
這張表把技術讀取和產品結果放在不同層。前七層在你的網站與測試環境就拿得到局部證據；第八層要指定搜尋產品、property、日期和查詢——它是唯一能回答「有沒有被用到」的一層，前七層全過也替代不了它。
逐層執行 AI crawler 稽核
1. 先建立 URL 與 crawler 範圍
先寫下完整 URL、協定、主機、路徑、查驗日期、指定 user-agent 和地區。只查了首頁的話，結論就停在首頁——產品頁、圖片 URL 或 API 可能走不同的路由和規則。要比較不同 crawler 時，用相同 URL、相同時段、相同測試條件；差一小時測，看到的差異可能只是 WAF 當下的心情。
2. 測 DNS、TLS 和 HTTP
記錄 DNS 是否解析、TLS 是否成功、response status、content type、content length 和 redirect chain。可在測試環境用不含憑證的基本請求建立紀錄：
curl -I -L -A "指定的測試 user-agent" https://example.com/page這個命令只是示範檢查方法，真實 crawler 未必送出相同 header。Response 是 401、403、429、5xx 或一長串重新導向時，先找出存取層的原因。瀏覽器最後顯示 200 很容易讓人收工——中間那幾跳的拒絕，和換一個 user-agent 之後的結果，都還沒有被看過。
3. 讀 robots.txt 與實際路徑
保留被測日期的 robots.txt 內容，逐條比對 user-agent、Allow、Disallow 和 sitemap 宣告。Google 文件提醒，robots.txt 不能用來當作從搜尋結果隱藏頁面的完整方法，禁止存取的 URL 仍可能以沒有內容的形式出現在索引中。若目標是傳遞 noindex，必須讓 crawler 能讀取頁面指令。
別只看最上面的 User-agent: *。更具體的 token 規則會蓋過它，解析方式也要按 RFC 9309 和平台文件理解。跨平台的政策細節回到各家官方文件——同一份 robots.txt，七個服務可能有七種讀法。
4. 檢查 WAF、CDN 與速率限制
WAF 可能依 IP、ASN、TLS 指紋、header、請求頻率或地區作出判斷。user-agent 字串可以被偽造，所以只以一個 UA 名稱放行，證據強度有限。若要核對官方 crawler，保存官方發布的 IP 或驗證方法、WAF event、response status 和時間窗；若拿不到這些資料，就把來源驗證記為未知。
網站 log 也要留意 403 與 429，不要只統計 200。若同一 URL 在不同時間收到不同回應，記錄快取、負載和規則版本，避免把一次成功請求當成長期可存取。
把 robots、WAF 與 HTTP 分開記錄
可用下表保存每次稽核，並把「允許」和「已讀到」分開：
| 欄位 | 範例值 | 判讀界線 |
|---|---|---|
| URL | https://example.com/guide | 必須固定 canonical 版本或明確說明參數 |
| crawler | 指定平台 token | 產品用途與 token 來源需記錄 |
| robots | allowed、disallowed、unparsed | 只代表規則解析，不代表 HTTP 成功 |
| HTTP | 200、403、429、5xx | 只代表本次 request response |
| WAF | allowed、challenged、blocked | 需有 event 或規則證據 |
| HTML | text present、thin、empty | 要標示 initial 或 rendered |
| index | verified、未確認、excluded | 需要搜尋工具或第一手證據 |
| answer | observed、not observed、無資料 | 需固定 query、日期、產品 |
這種紀錄比單一綠燈更適合交接。not observed 是在指定樣本中沒有看到，無資料是資料不足，未確認是尚未知道狀態，三者都不能簡化成零。
初始 HTML 與渲染內容
如果重要答案只在 JavaScript 執行後出現，檢查 initial HTML 和 rendered DOM 的差異。Google 的 JavaScript SEO basics 說明 Google 會經過抓取、渲染、索引階段，且不是所有 crawler 都執行相同的 JavaScript。頁面至少要在可接受的 HTML 或可驗證的渲染結果中提供標題、主要文字、內部連結、canonical 和 robots 指令。
不要把 screenshot 當成 HTML 證據。檢查原始 response、DOM、console、network 和 HTTP 狀態，並標示檢查是在本地、測試環境或正式環境。若不同 crawler 的渲染能力未知，結論應保留平台範圍，不能說「AI crawler 都能讀」。
如何保存未確認與無資料
每次完成稽核後，至少保存四份內容：測試條件、取得的 response、判斷規則、尚未取得的資料。以下是適合報告的句型：
- 已取得：指定 URL 在某日期、某 user-agent 下回傳 200，initial HTML 含有主要文字。
- 部分取得：robots.txt 顯示允許，但尚未取得 WAF event 或官方 crawler IP 驗證。
- 未知：尚未確認該 AI 產品是否使用 JavaScript 渲染或該頁是否已索引。
- 無資料：指定日期沒有足夠的固定查詢結果，因此不計算引用率。
這些句型能把技術證據和產品推論分開。若需要整理網站整體可見度，可以從 EthorX GEO 服務了解工作範圍；若需要產品層的觀測入口，可參考 Otlex。兩個連結都不是本次 crawler 稽核的外部成果證據。
常見問題
robots.txt 允許 AI crawler 就代表頁面會被引用嗎？
robots 處理的是部分 crawler 的 URL 存取規則，後面還有 HTTP、WAF、HTML、索引和產品選用五層。指定查詢沒看到引用時，保留查詢與日期——允許規則是一道門開著，不是有人走進來。
一個 200 response 就足以證明 AI crawler 能讀內容嗎？
200 證明的是那一次請求成功了。還要看 content type、內容完不完整、有沒有登入牆、依不依賴 JavaScript，以及指定 crawler 實際收到什麼——同一個 URL 回 200，內容可能是一段「請先登入」。只測過一般瀏覽器的話，crawler 版本記成未知。
WAF 只用 user-agent 放行可以嗎？
它可以是規則的一部分。UA 這個欄位任何人都能自己填——所以用它當唯一條件放行，等於在門口只問名字。要主張官方 crawler 已被驗證，依平台官方文件核對 IP、DNS、WAF event 或其他方法；拿不到來源證據時，把放行規則的限制寫出來。
AI crawler 可讀取圖片就代表可理解文章嗎？
文章能不能被理解，還涉及可見文字、HTML 結構、標題、內部連結、圖片替代文字、渲染結果和來源歸屬。圖片抓得到、文章讀不到的情況很常見——兩者是不同的觀測，要分開記。
稽核完成後就能計算 AI 搜尋 SOV 嗎？
可存取稽核給的是技術條件。SOV 或提及率需要固定平台、查詢樣本、日期、分母和有效回答規則——這五項一項都不在稽核結果裡。沒有產品答案資料時保存無資料狀態；從一個 200 或一行 robots Allow 推出比例，那個分母是憑空的。
查證邊界
本文以 Google、RFC 9309 與相關 crawler 文件整理檢查步驟；清單中的 WAF、HTTP、渲染與答案觀測欄位是編輯方法，不是任一平台的通用驗證規格。未取得指定 URL、伺服器 log、平台文件或產品答案時，保留未知與無資料，不把一般瀏覽器結果推廣成所有 AI crawler 的現況。