AEO 技術稽核
判斷一個網站的內容能不能被 AI 搜尋引擎抓到與讀懂。這是 AEO 的地基:內容寫得再好,抓不到就等於不存在。
為什麼要靠腳本而不是自己判讀
這個 skill 的價值主張是「方法論可稽核」——報告裡每個數字都要能指回一段可讀的程式碼。市面上的同類工具給出一個 73 分卻不說怎麼算的,那正是它們不被信任的地方。
所以有一條線要守住:任何會變成報告數字的東西,都由 scripts/ 算,不要自己推估或目測。 你負責決定跑什麼、解讀結果、排出優先序、把發現寫成人話。這樣 skill 版和未來 CLI 版的數字才會一致。
流程
1. 確認範圍
問清楚要稽核哪個網址。如果使用者只給網域,預設稽核首頁,但主動說明:首頁通常不是 AI 引用的目標頁,產品頁、定價頁、FAQ 頁往往更關鍵,建議一併跑。
2. 執行量測
uv run --script scripts/audit.py <URL>
輸出一份 JSON,路徑會印在 stdout。常用選項:
| 選項 | 用途 |
|---|---|
--skip-render | 跳過 Playwright 渲染比對(環境裝不起來時) |
--skip-probe | 跳過對目標站的實測請求(不想產生額外流量時) |
--crux-key KEY | 提供 CrUX API key 以取得 Core Web Vitals |
-o PATH | 指定輸出路徑 |
渲染探測需要 Chromium。 首次使用若報錯,執行 uv run --script scripts/render_probe.py --install(約 150MB,只需一次)。裝不起來也不要緊——其餘檢測完全不受影響,報告會標明這一項跳過。不要為了這個相依讓整趟稽核失敗。
3. 產出報告
python3 scripts/build_report.py <audit.json>
產生同名的單一 HTML 檔。一定要產。 報告會被截圖、貼進簡報、轉傳給老闆,它的傳播價值遠高於對話視窗裡的文字。做完後告訴使用者檔案在哪。
4. 解讀
讀 JSON 後,依下面的判讀原則寫出結論。這一段是你的價值所在,不要只是把數字唸一遍。
判讀原則
這幾條是這個領域最常見的錯誤結論,弄錯會直接損害專業信譽。
訓練型與檢索型爬蟲必須分開講
GPTBot、Google-Extended、ClaudeBot、CCBot 這類是訓練語料抓取。擋掉它們不會降低 AI 可見度——那是版權與資料治理決策,該由法務與內容策略決定。
OAI-SearchBot、PerplexityBot、Claude-SearchBot、Googlebot 這類是即時檢索抓取。擋掉才會真的讓品牌從 AI 答案裡消失。
絕對不要說出「建議開放 GPTBot 以提升 AI 可見度」。那是錯的,而且是這個領域最容易被行家一眼看穿的錯誤。
宣告層與實測層是兩回事
robots.txt 是站方宣告的規則;CDN 與 WAF 才是實際執行阻擋的地方。腳本兩層都測,報告要分開講。
特別注意 reason 欄位裡的「差別待遇」與「疑似差別供稿」:瀏覽器 UA 拿到 200、bot 拿到 404 或只拿到十分之一的內容——這是最陰險的一種阻擋,因為它不會出現在任何 robots.txt 裡,站方通常根本不知情。抓到這種發現,把它排在建議清單第一位。
渲染落差要用句子講,不要只講比例
sentence_coverage 比 static_to_rendered_ratio 更有意義,因為字元比例會被導覽列與頁尾稀釋。真正該給使用者看的是 missing_samples——那些是 AI 實際讀不到的句子,具體到可以指著說「這段話 ChatGPT 看不到」。
同時要說清楚:Googlebot 會執行 JavaScript,但多數 AI 檢索型 bot 不會。所以一個在 Google 排名正常的網站,完全可能在 AI 搜尋裡是隱形的。這個落差是本工具最有說服力的發現。
FAQPage 不要過度承諾
Google 的 FAQ 富摘要自 2023 年起已大幅限縮,實質只保留政府與醫療類網站。FAQPage 現在的主要價值是供 LLM 讀取,不是讓搜尋結果變好看。承諾外觀會改變,客戶事後會發現。
Core Web Vitals 不要併進 AEO 結論
LCP / INP / CLS 是使用者體驗訊號。AI 檢索 bot 不執行互動、不感知版面位移,這組數字與 AI 可見度沒有直接因果關係。它值得單獨呈現為 SEO 項目,但把它算進 AEO 判讀會污染結論。
不要發明綜合分數
使用者可能會要一個「總分」。可以理解這個需求,但要說明為什麼不給:加權公式一旦不能公開驗證,整份報告就退回成黑盒,而可稽核正是這個工具存在的理由。改為給「依嚴重度排序的問題清單」,那對決策更有用。
撰寫建議清單
修復建議放在報告之後的對話裡,依這個順序排:
- 檢索型 bot 被擋(宣告層或實測層)——影響最大且通常最好修
- 渲染落差導致關鍵內容 AI 讀不到
- JSON-LD 語法錯誤(整塊會被忽略,等同不存在)
- 缺 Organization 實體或缺
sameAs外部權威連結 - 結構化資料與可見內容不一致
- Core Web Vitals(獨立列出,標明屬 SEO 而非 AEO)
每一條要寫出具體怎麼改,不要停在「建議優化」。robots.txt 的修改給出 diff。
絕對不要做的事
不要修改使用者的網站。 不要寫入 robots.txt、不要改 CMS、不要送出任何會改變線上狀態的請求。只產出建議 diff,由人決定要不要套用。這個 skill 的實測請求是唯讀的 GET,除此之外不碰目標站。
延伸資料
需要時再讀,不必預先載入:
references/ai-bots.md— 各 bot 的用途、官方文件出處、名稱變動的維護說明references/remediation.md— 常見問題的具體修法(robots.txt 範本、SSR 選項、JSON-LD 模板)references/methodology.md— 每個指標的計算方式與已知限制,客戶質疑時的依據
這個 skill 不做的事
單次稽核是一個時間點的快照。趨勢比較、競品引用佔比、排程監測需要時序資料,不在範圍內。如果使用者要的是「持續追蹤」,誠實說明這一點。
要量測品牌在 AI 答案中實際被引用的比率,用 aeo-visibility-check。