ssheleg/seo-aeo-audit

seo-aeo-audit — 審計搜尋引擎 + 答案引擎可見性，然後交付一份計畫

一項任務：檢視真實網站，用證據證明問題所在，並回傳一份有優先順序的變更計畫，涵蓋傳統搜尋引擎（Google、Yandex、Bing）與答案引擎（AI Overviews / AI Mode、ChatGPT、Perplexity、Claude、Copilot、Gemini、Alice AI）。

此技能不做的事：撰寫內容、建立頁面、購買連結。它的任務止於經確認的診斷與一份可執行的計畫。

不可妥協的原則

1. 有證據才發言，否則保持沉默。 每項發現都必須包含：你觀察到的現象、位置（URL、file:line、報告名稱）、觀察到的數值以及日期。切勿報告你未在此網站上親自查證的發現。稱「最佳實踐建議」並非證據。
2. 標記每個建議的證據等級（參見 references/evidence-tiers.md）：CONFIRMED（由引擎文件記載或在此網站上重現）· STUDY（已發布的多站點資料）· FIELD（單一個案報告）· HYPOTHESIS。絕不允許 HYPOTHESIS 的排名高於 CONFIRMED 的阻擋器。
3. 先診斷，再處方。 在找出根本原因之前，不得將任何修復措施納入計畫。說「添加結構化資料」並非診斷。
4. 拒絕迷思清單。 請參閱下方的「迷思防護」——推薦那些項目會浪費客戶預算，這屬於缺陷，而非貼心之舉。
5. 絕不推薦欺騙性策略。 隱藏、偽造共識網絡、評論操縱、競爭對手抹黑攻擊以及點擊偽造信號，都不得納入計畫。它們在本技能中只出現於 references/threats-and-defense.md，作為偵測與防禦的對象。
6. 說明你無法檢查的項目。 缺乏 GSC 登入權限是報告中的一項缺口，而非默認遺漏。
7. 絕不混合測量值與假設值。 當某項交付成果同時包含兩者時——連結建立 CSV 通常如此——source 欄位會將它們分開，且未經測量列的流量數值應保持空白，而非零。0 表示「已測量，無需求」；空白表示「無人檢查過」。這個區別在於他人依據預算執行工作時最為重要。
8. 了解每項工具的盲點，並在輸出中說明。 原則 1 和 7 規範你撰寫的內容；它們無法察覺一個在你檢視之前就已混合或遺漏資料的工具。有兩者時常出現。靜態抓取無法看到 CMS 透過 JavaScript 注入的 JSON-LD，因此在任何使用 Yoast/RankMath/AIOSEO 的網站上，「未發現結構化資料」是一個錯誤的發現——scripts/page_audit.py 會在每個結構化資料清單旁邊印出此警告，且只有經過渲染檢查後才能報告資料缺失。使用同意模式建模的 GA4 會將觀察到的行為與估計的行為合併在一個數字中——請參閱 references/measurement.md J1 中的三個啟用條件、可見指示器以及僅觀察的備用方案。此原則大致通用：在將某項工具的沉默視為發現之前，必須先確認該工具確實能夠看到該事物。

步驟 0 — 偵測模式，不重複詢問

先檢查，再行動。依序進行：

1. 讀取 docs/seo/（或用戶指定的路徑）。如果存在先前的審計報告，此執行視為重新審計：與其進行比對，並優先說明發生了哪些變化。
2. 確認你可存取哪些項目：正式網站、暫存 URL、robots.txt、sitemap.xml、Search Console / Bing Webmaster / 分析工具存取權、爬取匯出檔（Screaming Frog、Sitebulb）、伺服器日誌、任何已連接的 MCP 工具（Ahrefs、GSC、分析工具、爬蟲 MCP，或 Prowl MCP 用於大量競爭與需求資料，無需每個供應商授權）。 測試權限，不要假設它有效。 已連接的伺服器不等於可運作的伺服器：API 階層會限制端點，且 Token 的範圍通常比儀表板顯示的更窄。在你圍繞資料來源規劃之前，先對每個來源進行一次關鍵呼叫測試，並記錄回傳結果——「已連線但回傳 Insufficient plan」是下一次審計需要的發現。
3. 僅在答案會改變工作內容時，才與用戶選擇範圍：整個網站、一個模板/區塊、一個問題（「為何五月流量下降」），或一次連結建立提取——為承包商提供目標、關鍵字與錨文字。這個更像是一項交付成果而非診斷：當請求是此項時，請閱讀 references/linkbuilding.md。無論是否有 Search Console 權限都能運作。
4. 用三行報告狀態——可用輸入、缺失輸入、範圍——然後開始。每次執行結束時，建議一個具體的下一步行動。

scripts/preflight.py 會自動執行步驟 2 中可自動化的部分，並報告失敗觸發的獨立關卡——Search Console、GSC API 和 PageSpeed 皆會因不同原因回傳 403。請閱讀 references/preflight.md 以了解它確實探測的項目以及留給你的部分（Bing/Yandex、分析工具、伺服器日誌、爬取匯出檔及每個 MCP 工具）。綠燈的預檢不代表步驟已完整執行。

# Claude Code 外掛：${CLAUDE_PLUGIN_ROOT} 會在技能內容中展開。
SKILL_DIR="${CLAUDE_PLUGIN_ROOT}/skills/seo-aeo-audit"
# 任何其他管道：當此技能載入時，harness 指定的基礎目錄——此 SKILL.md 所在的目錄。在依賴它之前先確認：
ls "$SKILL_DIR/scripts/preflight.py"

此處顯示 No such file or directory 並非功能缺失，也不是可以默默繼續進行的理由。這表示六項工具皆無法存取，因此它們本應進行的每項檢查都會降至證據階梯的最底層——而發現的階層會限制其證據等級。在三行狀態中說明此事；一個默默變成手動審計的審計，已改變其結論的價值（不可妥協原則 #6）。

python3 "$SKILL_DIR/scripts/preflight.py" --site sc-domain:example.com --origin https://example.com

存取規則：預設為唯讀。絕不提交表單、請求索引、撤銷連結或更改線上屬性，除非在此對話中獲得明確批准；那些是對外的操作。

步驟 1 — 在提出意見前先建立基線

記錄（含日期）以便後續的每個聲明都能與之比較：

• 自然點擊/曝光/平均排名（按國家與裝置），12 個月（GSC + Bing），以及是否有下降或停滯的時間區段；
• 每個模板的已索引 vs 已發布 URL 數量（site: 是初步檢查，GSC Pages 報告才是正確數字）；
• 前 20 大營收或轉換頁面及其當前排名；
• AI 表面基線：針對你能觸及的每個引擎，執行 references/aeo-geo.md 中的品牌與類別提示集，並逐字記錄答案；
• 哪些 AI 爬蟲實際抓取該網站（伺服器日誌；使用正向確認反向 DNS 過濾偽造者），以及哪些 AI 推薦來源出現在分析工具中；
• 更新時間軸：在對任何原因形成假設之前，先將曲線中的每次變化與 references/algorithm-updates.md 進行日期對齊。

當完全沒有第一方存取權限時，在三行狀態中說明，並退而依賴第三方索引所能建立的項目：該網域目前的排名、其連結檔案相對於一組規模化競爭對手的大小，以及其目標詞組是否具有可測量的需求（references/prowl-mcp.md）。該基線僅限於 STUDY 等級，無法回答「為何此頁面未被索引」——但足以區分新網站起步與流量衰退，而這兩者需要截然不同的計畫。

如果網站聲稱流量下降，首先區分報告失敗與排名失敗：凍結的 GSC 報告會將點擊固定在一個日期，而實際的流量下降會持續產生新的下降數據點。在診斷演算法原因之前，交叉比對 GA4 會話、伺服器日誌與獨立的排名追蹤工具。

步驟 2 — 十個面向

執行所有在範圍內的面向。每個面向都有各自的參考檔案，包含具體檢查項目、2026 年當下的注意事項以及要捕獲的證據。

#	面向	回答的問題	參考資料
A	存取與索引經濟學	Bot 能否抓取、渲染並負擔得起這個頁面？爬取預算在哪裡被消耗？	technical-checks.md
B	權威化與重複內容	哪個 URL 是權威頁面，引擎是否同意——包含 hreflang？	technical-checks.md
C	架構與連結權重	營收頁面是否獲得權威性、深度與爬取頻率？	architecture-and-equity.md
D	意圖與 SERP 匹配	每個頁面是否符合 SERP，以及頁面之間是否存在關鍵字自相殘殺？	intent-and-content.md + onpage-checks.md
E	內容價值	是否有 AI 無法複製的理由讓你獲得排名？	intent-and-content.md + ranking-model.md
F	可提取性與 AEO/GEO	答案引擎能否檢索、讀取並引用它？	aeo-geo.md
G	實體與品牌共識	模型是否一致地認識該品牌，並提及它？	entity-and-brand.md
H	體驗、轉換與歸因	任務在此完成還是跳出？是否有轉換，且是否被測量？	experience-signals.md + demand-and-conversion.md
I	風險與威脅	懲罰、劫持、注入、下架。	threats-and-defense.md
J	衡量機制	是否有人能夠判斷計畫是否奏效？	measurement.md

Google Discover 不屬於這十個面向之一，也不屬於面向 A 的一部分。 它有自己的排名機制、自己的門檻（兩個 meta 標籤，缺少它們則完全不會顯示卡片）以及自己的新鮮度曲線。因此，如果 Discover 是網站的重大流量來源，則需要將 references/discover.md 作為第十一個附加面向來執行；而如果它不是，則可以完全跳過。在決定之前，先檢查 GSC Discover 報告：該參考檔案最初只能從此檔案底部的列表中存取，這意味著作業順序的代理從未打開它。

在任何下降診斷之前，執行 references/algorithm-updates.md 中的日期對齊與更新回應協議——「核心更新衝擊了我們」不是一項發現，而一半有記載的 GSC 故障都與演算法更新發布時間重合。

每個面向都有兩個部分：診斷工作（問題是什麼以及原因）以及一個機械式掃描以確保完整性——面向 A/B 請參考 technical-checks.md §A3，面向 D/E 請參考 onpage-checks.md。先執行診斷；之後的掃描會捕捉枯燥的失敗，且只有具有可觀察影響的掃描項目才會被提升至發現表格中。

順序很重要。 面向 A 的阻擋器（網站無法被抓取、預渲染原始碼中有 noindex、人工處置）會使所有其他發現變得無效——人工處置是一個二元乘數：在它被解除之前，你改進的任何事情都不算數。在花費時間於面向 F/G 之前，先依序完成 A → B → C。

證據階梯——完整的路由規則位於 references/tooling.md；它依據證據強度而非便利性排序：伺服器日誌 → Search Console / Bing / Yandex → 完整爬取 → 現場效能資料 → 第三方索引 → 手動抓取與 DevTools。對每項檢查使用你實際能達到的最高階層，並在報告中說明該發現依賴哪個階層。僅有公開資料、無網站權限的審計是有效的工作，但其索引與查詢發現是推論而非觀察，因此會獲得相應的等級劃分。

六個預先包裝的腳本——preflight.py、gsc_pull.py、page_audit.py、url_inspection.py、sitemap_audit.py、psi_pull.py——負責收集每個面向的機械性部分。請閱讀 references/scripts.md 以了解呼叫方式、參數、配額以及每個腳本的限制。

決定發現是否真實的四個陷阱：

• page_audit.py 的結構化資料清單僅讀取伺服器渲染的 HTML。若 CMS 透過 JavaScript 注入 JSON-LD，空的清單並非缺少標記的證據（不可妥協原則 #8）。
• --format json 會輸出一个陣列，每個頁面對應一個物件，即使只有一個 URL：請索引 data[0]。
• 被 --max-bytes 截斷的回應會使所有基於計數的發現失效，而非將片段發布為測量結果。
• 每項發出的發現除了嚴重性之外，還必須攜帶證據等級，且只有等級會進入分類公式。 嚴重性是發現的響亮程度；等級是它的依據。url_inspection.py 是向索引查詢，而非從抓取推斷，這是發現達到 CONFIRMED 等級的唯一方式——每個屬性每日配額 2000 次，每分鐘 600 次，因此每個模板取樣一個 URL，再加上發現實際涉及的頁面。

步驟 3 — 分類

為每項發現評分，然後排序。不要展示未排序的清單。

priority = (impact × confidence) / effort

• impact 1–5 分：營收頁面被封鎖 = 5；模板範圍的漏洞 = 4；單一資訊頁面 = 1。在基線允許的情況下，以流量或營收術語進行估計。
• confidence：CONFIRMED 1.0 · STUDY 0.7 · FIELD 0.4 · HYPOTHESIS 0.2。
• effort 1–5 分，以工程天數計算，包含發布流程，而不僅僅是編輯時間。

將輸出分為四個類別，依此順序：

1. 阻擋器 — 索引問題、懲罰、劫持、營收頁面無法存取。
2. 漏洞 — 爬取預算浪費、權重流失、關鍵字自相殘殺、閱讀預算浪費。
3. 增益點 — 意圖匹配、資訊增益、可提取性、實體共識。
4. 實驗 — 任何低於 CONFIRMED 等級、值得進行分割測試而非全面發布的項目。根據 references/experiments.md 進行設計；絕不將 HYPOTHESIS …

…[已截斷以利翻譯]