你精心寫好一篇技術分析或產品架構文章，發布在個人網站或官方工程部落格上。過去的目標很單純：爭取 Google 與 Bing 的第一頁排名，等待工程師在搜尋結果中點擊那條藍色超連結。
但現在，越來越多工程師不再打開 Google 逐一翻閱搜尋結果，而是直接將問題拋給 ChatGPT、Claude 或 Perplexity，甚至是讓在終端機運作的 Coding Agent 自動檢索解決方案。這時，你的內容能不能「被看見」，不再取決於關鍵字密度或外鏈炒作，而是取決於生成式模型能不能讀懂並直接引用你的段落。
這正是從 SEO（Search Engine Optimization，搜尋引擎最佳化）走向 GEO（Generative Engine Optimization，生成式引擎最佳化）的典範轉移。
獨立開發者 Kai Wang（@hqmank）於 2026 年 8 月 24 日在 X 貼文 中，基於 Anthropic 內部近期廣泛運用的「/eli5」視覺提示詞框架（源自 Thariq 的 分享），將自己在 hqman.me 的實戰佈局提煉為一套具體的工程檢查流程。本文以此實踐為起點，從邊緣網關（Edge Gateway）、爬蟲 Token 分級、純文字內容端點到排版結構，深入探討工程團隊如何讓自己的技術產出通過 AI 檢索時代的五道過濾防線。
內容發布與格式
結構化 HTML + 支援 .md 純文字端點
邊緣防火牆檢驗
Cloudflare 精準放行，嚴格回傳 HTTP 200
爬蟲分類與索引
區分搜尋爬蟲與對話抓取代理，讀取 sitemap 與 llms.txt
SERP 搜尋藍色連結
Google / Bing 經典索引庫挑選與排序
LLM 即時合成與引用
ChatGPT / Claude / Perplexity 摘錄句子並附註來源
五道過濾關卡（任一關卡失敗即失去曝光）
爬蟲能否看見網址？依賴 sitemap.xml 與主題集群內鏈，防範 robots.txt Disallow。
造訪是否成功回傳 200？嚴防 Cloudflare 403 誤殺、機器人挑戰與登入牆。
主題是否一目了然？標題採用「工具+動作+情境」，前 100 字直接給出答案。
是否為最佳權威來源？拒絕 AI 模板廢話，確保第一手踩坑經驗與論點獨特性。
模型能否直接提煉引用？提供可獨立抽取的段落結構，並維護 llms.txt 文件地圖。
一條道路的兩個分流：SEO 與 GEO 的本質差異
無論是傳統搜尋還是生成式對話，網頁內容進入機器世界的第一哩路是一樣的：你撰寫頁面 ➔ 機器人前來抓取 ➔ 伺服器回傳 HTTP 200 ➔ 機器人將內容存入索引資料庫。
關鍵的轉折發生在「有人提出問題」的瞬間，整條資訊消費的路徑正式分流：
- 傳統 SEO 路徑（Index Lookup ➔ Blue Link）：搜尋引擎從倒排索引庫中挑選出最相關的網頁標題與網址，呈現給人類使用者。使用者的動作是「在藍色連結中挑選並點擊進入網站」。
- 現代 GEO 路徑（Context Retrieval ➔ Synthesis & Citation）：大語言模型（LLM）透過向量檢索或即時爬蟲取得頁面上下文，將多個來源的資訊綜合理解後，直接在對話中提煉出一句結論，並在句子旁標註引用出處（Citation）。使用者的動作是「在對話界面中閱讀現成答案，只有需要深入查核時才回溯點擊來源」。
五道過濾關卡：任一關失敗，你就從 AI 世界徹底消失
在 GEO 的鏈路中，內容能否成為最終被引用的答案，必須依序通過以下五道檢驗關卡（Five Gates）。這是一條短路管線（Short-circuit Pipeline），任何一步回傳失敗，後續的優化就毫無意義。
Gate 1：Find（能看見網址嗎？）
機器人必須能發現並追蹤到你的 URL。
- 放行條件：根目錄提供標準且持續更新的
/sitemap.xml；站內具備良好的主題集群（Topic Cluster）內部超連結；robots.txt宣告清晰。 - 失敗致命點：頁面成為孤島（Orphan Page），無任何內部連結導流；或者
robots.txt誤將路徑設為全域Disallow: /。
Gate 2：Open（造訪打得開嗎？）
爬蟲發出 GET 請求時，伺服器必須乾淨回傳 HTTP 200 OK。
- 放行條件：邊緣網路（Edge CDN）精準放行各大 AI 爬蟲的 User-Agent 與 IP 網段，靜態或快取頁面毫秒級回應。
- 失敗致命點：Cloudflare 等邊緣防火牆觸發 403 阻擋、強制彈出 Cloudflare Turnstile 驗證挑戰（JS Challenge）、或者內容被鎖在需要帳號密碼的登入牆（Login Wall）之後。只要這一步卡住，即使正文寫得再出色，對 AI 來說該頁面就是不存在的空白。
Gate 3：Read（主題能讀懂嗎？）
爬蟲或模型解析 HTML 時，能否在第一時間抓住核心主題與解答？
- 放行條件：頁面 Title 採用「工具 + 行動 + 情境」的具體工程命名；H1 標籤聚焦一致；前 100 字直接給出核心解答與論點，拒絕廢話前言。
- 失敗致命點：標題使用抽象抒情詞彙（如「關於架構的一些思考」）；文章開頭堆砌 500 字的背景脈絡與生活感言，真正結論埋在頁面最底端。
Gate 4：Pick（模型會選你嗎？）
在成千上萬個相關網頁中，大語言模型為什麼選擇引用你的句子而非競品？
- 放行條件：具備不可替代的第一手實測數據、踩坑日誌與鮮明的工程權衡判斷；站內主題明確，不自我衝突。
- 失敗致命點：AI 產生的公版洗稿內容（Fluff & Slop）；站內多篇文章鎖定同一個問題卻給出互相矛盾或稀釋的說法（Keyword Cannibalization）。
Gate 5：Quote（句子能直接引用嗎？）
模型在生成回答時，能否在不產生語義斷層的前提下，將你的論點抽成單一完整段落？
- 放行條件：核心論斷以自洽、獨立成段的格式呈現；網站根目錄提供
/llms.txt與乾淨的.md純文字端點。 - 失敗致命點：答案深埋在雜亂的多層巢狀組件與複雜排版中；缺乏純文字標註，導致 LLM 在長上下文截斷中漏掉關鍵句。
爬蟲機器人分級管理：搞懂搜尋、對話與訓練的三種職責
若把搜尋、即時代理與訓練用途混在同一封鎖政策，可能阻擋原本希望接納的抓取。排查時要看實際受影響的 crawler 與規則，不能只憑「AI Bots」這個設定名稱判定搜尋與對話讀取都已被封鎖。
要做好 GEO，首先要把來訪的機器人劃分為三大職責維度，並在邊緣設定與 robots.txt 中分別治理：
1. 搜尋索引爬蟲（Search Indexers）—— 必須放行（ALLOW）
這類機器人負責將你的網頁抓回索引庫，供 AI 搜尋引擎（如 ChatGPT Search、Claude Search）即時召回。若封鎖它們，你的內容將徹底退出 AI 搜尋版圖。
OAI-SearchBot：OpenAI 專門用於 ChatGPT 搜尋的索引爬蟲（不等於訓練爬蟲）。Claude-SearchBot：Anthropic 用於支援 Claude 搜尋與即時參照的索引器。PerplexityBot：Perplexity 搜尋引擎專用爬蟲。Googlebot與Bingbot：傳統搜尋核心；值得注意的是，ChatGPT 搜尋有相當高比例的底層檢索結果會參考 Bing 索引。
2. 即時對話抓取代理（Chat Fetch Agents）—— 必須放行（ALLOW）
當一般使用者在 ChatGPT 或 Claude 的對話框中貼上你的文章連結並詢問「請幫我整理這篇文章」時，觸發的是這類即時抓取代理。
ChatGPT-User：由使用者操作觸發的即時網址抓取。Claude-User：由使用者在 Claude 介面貼入網址時發動的抓取。
3. 模型預訓練爬蟲（Training Bots）—— 依商業政策決定（YOUR CALL）
這類機器人抓取內容的目的，是將資料送進大語言模型的下一代預訓練資料集（Pre-training Dataset）。這不會即時為你的網站帶來流量跳轉或對話標註，而是長期的模型知識沈澱。
GPTBot：OpenAI 官方用於訓練 GPT 模型的爬蟲。ClaudeBot：Anthropic 用於模型訓練的爬蟲。Google-Extended：Google 獨立出的爬蟲 Token，專門控制是否允許內容用於 Gemini 模型訓練與 Grounding。
邊緣網關與 Origin 站台工程配置
要讓這套分流機制順暢運作，邊緣層（Edge）與來源端（Origin）必須協同配置。Kai Wang 在 hqman.me 上實際部署的架構為我們提供了極佳的參考範本。
邊緣網關配置（以 Cloudflare 為例）
邊緣層的責任是「守門而不誤殺」：
- AI bot policies：先按內容政策區分 Search、Agent 與 Training，再核對需要接納的 crawler。Cloudflare 官方文件已提供按用途設定的選項；不能把「允許搜尋」理解成必須同時允許訓練。
- Cloudflare Managed robots.txt：它會在既有檔案前加入託管區段。官方範例限制
GPTBot、ClaudeBot等爬蟲，沒有列出對OAI-SearchBot或ChatGPT-User的禁止規則。是否符合自訂政策，要檢查正式/robots.txt的合併回應，不能斷言開啟後必然破壞放行。 - Bot Fight Mode 與 Super Bot Fight Mode：先由 Security Events 的 Service 欄位定位誤擋產品。普通 Bot Fight Mode不能用 WAF custom rules 的 Skip／Bypass 豁免；若確認它誤擋所需流量，需評估全域停用該產品的防護取捨，或改用支援例外的產品。Super Bot Fight Mode則支持以 Skip 略過其階段，請求仍繼續經過其他安全檢查。本文建議只對必要公開路徑與已驗證 crawler 來源建立最小例外，例如核對業者公布的 IP 範圍；不要僅憑可偽造的 User-Agent 放行，並保留其他防護。
- AI Crawl Control：依逐 crawler 的 Allow／Block 能力落實政策，觀察成功與失敗請求。Allow 不代表其他安全規則都會放行；Failed 也可能來自其他規則或回應錯誤，應回到事件與日誌定位。
以上是讀者可採用的配置與驗證方法，不代表 CarlStack 已實施這些 Cloudflare 設定。
來源端檔案配置（Origin Files）
在伺服器根目錄，至少需要具備三份關鍵機器文件，並支援純文字端點：
1. 標準 robots.txt 放行契約
在 public/robots.txt 明確宣告搜尋爬蟲與對話代理的放行規則：
User-agent: Google-Extended
Allow: /
User-agent: *
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=yes
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: Claude-User
Allow: /
User-agent: PerplexityBot
Allow: /
Sitemap: https://yourdomain.com/sitemap.xml2. 機器友善內容大綱：/llms.txt
/llms.txt 是目前開源社群廣泛採納的標準，用純文字 Markdown 為大語言模型提供一份「不帶 HTML 雜訊的網站導航地圖」：
# 網站名稱與作者聲明
> 一到兩句核心定位，說明本站的主題範圍、實測環境與主要受眾。
本站所有文章均為第一手工程實踐記錄。HTML 頁面供人類閱讀，Markdown 頁面供 AI Agent 讀取。若引用觀點，請附帶文章原始 URL。
## 核心頁面
- [首頁](https://yourdomain.com/index.md): 網站核心介紹與技術棧總覽。
- [文章總覽](https://yourdomain.com/blog.md): 已發布文章目錄。
## 主題專題
- [AI Agent 工程化](https://yourdomain.com/topics/agent-workflows.md)
- [系統架構實踐](https://yourdomain.com/topics/architecture.md)3. 每篇文章同步提供 .md 端點
HTML 中的樣式、導覽與腳本可能增加模型輸入量；可考慮提供 /blog/<slug>.md，或透過 Accept: text/markdown 協商回傳 Markdown。Cloudflare 於 2026 年 2 月 12 日公布的案例是該篇部落格 HTML 16,180 tokens、轉換後 Markdown 3,150 tokens，約減少 80%。這是單頁案例，實際比例取決於頁面結構與客戶端前處理，也不是整個 Agent 工作的成本比例。較少 tokens 不代表引用率提高；仍需確認正文、連結與程式碼轉換完整，再用固定問題測試檢索與引用成效。
頁面排版的六個信號發聲點（Loud Spots）
當爬蟲與模型讀取文章時，它們的注意力權重分布與傳統閱讀者有所不同。文章中必須刻意設計六個高強度訊號發聲點：
- URL 語意路徑：直接宣告主題與動詞（例如
/blog/clear-slug/），避免無意義的動態資料庫查詢字串（如/p?id=12）。 - Page Title（頁面標題）：長度維持在 50 至 60 個字元，將核心名詞置前。強烈建議套用**「工具 + 行動 + 情境」（Tool + Action + Situation）**的工程命名公式。
- H1 標題：全頁維持唯一的 H1，其核心詞彙必須與 Title 保持高度語意一致。
- 前 100 字（First 100 Words）：第一段直接給出答案與核心判斷。工程師與 LLM 都不需要「自古以來、隨著 AI 時代演進」之類的無效暖身前言（No warmup essay）。
- H2 / H3 結構化層次：每一層小標必須是讀者在閱讀前一段後「緊接著會產生的下一個具體問題」，引導模型做連續的上下文推理。
- 站內主題集群連結（Internal Links）：主動連回該領域的總覽頁面（Topic Pillar）與同系列的關聯文章，形成稠密的語意拓撲。
落地執行的七步工程檢驗清單
優化不能憑感覺。按照 Kai 提出的實戰時間表，工程師應該依序推進，切忌跳過前三步邊緣連通性就急於進行關鍵字堆疊：
階段一：連通性與邊緣放行（第 1–3 天）
- 驗證搜尋引擎能見度（Day 1–2）：在 Google Search Console（GSC）與 Bing Webmaster Tools 提交
/sitemap.xml，確認狀態為成功（ChatGPT 搜尋深度參考 Bing）。 - 手動請求首批文章索引（Day 3）：在 GSC 使用 URL Inspection 工具手動請求 3 篇核心文章索引（每日有配額限制，勿對同一 URL 反覆點擊）。
- 定位邊緣誤擋並驗證政策（Day 1）：按前節方法核對 Security Events、正式
/robots.txt與逐 crawler 政策；區分 Bot Fight Mode 與 Super Bot Fight Mode 的例外能力，修正後重測必要公開路徑，保存請求狀態與規則證據。
階段二：內容排版與格式標準化（第 4–7 天）
- 重構最新文章的信號發聲點（Day 4）：檢查最新文章的 Title、H1、前 100 字是否開門見山給出答案、配置 2–3 個內部連結，並確保發布時間標記具備可驗證的時間戳。
- 標準化後續寫作工作流（Day 6–7）：維持第一手實證紀錄風格；將具備引用價值的結論獨立成段；同步登錄至
/llms.txt；配置純文字輸出。
階段三：資料觀測與 AI 基準驗證（第 1–6 週）
- 雙儀表板監控（Week 1–4）：比對 GSC（Sitemap 已處理、網址狀態為 Indexed）與 Cloudflare AI Crawl Control（Allowed 請求線條平穩上升、Failed 降至零）。
- 多模型基準測試（Week 2–6）：挑選 5 個與文章主題密切相關的典型問題，分別在 ChatGPT、Claude 與 Perplexity 進行測試，記錄是否有被檢索並列出來源出處。
下一步：用一篇文章建立驗證紀錄
先選一篇核心文章，保存 HTTP 與抓取日誌、正式 robots 回應、HTML／Markdown 正文比對，以及固定問題的來源引用結果。把「能取得內容」與「答案採用內容」分開記錄，再依失敗證據調整對應關卡，避免為沒有引用的結果直接放寬邊緣政策。