大多數人的做法：抄一份 GEO checklist，逐項打勾，然後不知道為什麼沒效果。 真正該做的事：先看懂管線，才知道每一項在修哪個階段的問題。
Checklist 會過期，機制不會。 這一篇講機制。
一、先確認一件事：AI 引擎看到的不是你看到的
打開瀏覽器看到的頁面，和 AI crawler 拿到的東西，可能是兩份完全不同的文件。
瀏覽器 AI Crawler
┌──────────────────────┐ ┌──────────────────────┐
│ HTML │ │ HTML │
│ ↓ 執行 JS │ │ ✘ 多數不執行 JS │
│ ↓ 呼叫 API │ │ ✘ 拿不到 API 資料 │
│ ↓ 水合（hydrate） │ │ ✘ 沒有水合 │
│ ↓ 載入圖片、字型 │ │ ✘ 通常只要 HTML │
│ = 完整頁面 │ │ = 可能是空殼 │
└──────────────────────┘ └──────────────────────┘
驗證方法（30 秒）：
1# 瀏覽器看到的：假設有 12,000 字
2# AI crawler 看到的：
3curl -s -A "GPTBot" https://your-site.com/page \
4 | python3 -c "import sys,re; h=sys.stdin.read(); \
5 t=re.sub(r'<script.*?</script>|<style.*?</style>','',h,flags=re.S); \
6 t=re.sub(r'<[^>]+>',' ',t); print(len(t.split()))"
如果輸出遠小於實際內容量，後面所有優化都是白做的。這是 Part 4 Step 7 要解的問題。
二、AI Crawler 全表：誰在爬你、為了什麼
不同的 bot 服務不同目的。擋錯一個，等於關掉一整條路徑。
User-Agent 所屬 用途 擋掉的後果
──────────────────────────────────────────────────────────────────────────────
GPTBot OpenAI 訓練語料收集 不進未來模型的內在知識
OAI-SearchBot OpenAI ChatGPT Search 索引 ChatGPT 搜尋不到你 ← 嚴重
ChatGPT-User OpenAI 使用者觸發的即時抓取 使用者貼你的網址也讀不到
ClaudeBot Anthropic 訓練語料收集 同 GPTBot
Claude-Web Anthropic 即時瀏覽 Claude 讀不到你的頁面
Claude-SearchBot Anthropic 搜尋索引 搜尋結果中缺席
Google-Extended Google Gemini 訓練（不影響搜尋） 不進 Gemini 內在知識
Googlebot Google 一般索引 + AI Overview AI Overview 完全消失 ← 致命
PerplexityBot Perplexity 索引 Perplexity 引用不到你
Perplexity-User Perplexity 即時抓取 同上
Bingbot Microsoft 索引 + Copilot Copilot 消失
Applebot-Extended Apple Apple Intelligence Siri / Apple 摘要缺席
Amazonbot Amazon Alexa / Rufus 電商語音場景缺席
Bytespider ByteDance 豆包 / TikTok 搜尋 中文市場缺席
CCBot Common Crawl 公開資料集 間接影響多數開源模型
Meta-ExternalAgent Meta Llama / Meta AI Meta AI 缺席
2.1 關鍵區分：訓練 bot vs 檢索 bot
這是最多人搞錯的地方。
訓練 bot 檢索 bot
────────────────────────────────────────────────────────────────
代表 GPTBot, ClaudeBot, OAI-SearchBot,
Google-Extended, CCBot Claude-SearchBot,
PerplexityBot, Googlebot
擋掉的影響 內容不進下一代模型權重 內容在「今天」的 AI 回答中消失
（6-24 個月後才有感） （立刻生效）
版權疑慮 高（內容被用來訓練） 低（只是引用並附連結）
該不該擋 看你的立場 幾乎永遠不該擋
實務建議的預設值：
# robots.txt —— 對多數 B2B / SaaS / 內容品牌適用
User-agent: *
Allow: /
# 訓練用：可依商業立場決定
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: CCBot
Disallow: / # 常見取捨：不進公開資料集，但仍允許各家檢索
# 檢索用：一律開放
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
2.2 robots.txt 只是門面，真正擋你的常常是 CDN
大量網站的 robots.txt 是開放的，但 AI crawler 仍然拿不到內容。原因通常在這幾層：
請求 → ┌─ DNS ──────────────────┐
├─ CDN / WAF ────────────┤ ← 90% 的問題在這
│ • Cloudflare Bot Fight Mode
│ • AWS WAF Bot Control
│ • Rate limiting（AI crawler 爬得很密集）
│ • Managed rule：「Block AI Scrapers」一鍵開關
├─ 反向代理 ──────────────┤
│ • 地區封鎖（AI crawler 來自特定 IP 段）
├─ 應用層 ────────────────┤
│ • 需要 Cookie / Session
│ • JS challenge
└─ 原始碼 ────────────────┘
• <meta name="robots" content="noai, noimageai">
Cloudflare 尤其要注意：2024 年後預設對新網域啟用了 AI 爬蟲封鎖選項，很多人是在完全不知情的狀況下被擋掉的。檢查路徑：Security → Bots → AI Scrapers and Crawlers。
診斷腳本：
1#!/usr/bin/env bash
2# ai-crawler-check.sh —— 逐一驗證各家 bot 的實際存取結果
3URL="${1:?usage: ./ai-crawler-check.sh https://example.com/page}"
4AGENTS=(
5 "GPTBot/1.0"
6 "OAI-SearchBot/1.0"
7 "ChatGPT-User/1.0"
8 "ClaudeBot/1.0"
9 "Claude-SearchBot/1.0"
10 "PerplexityBot/1.0"
11 "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
12 "Mozilla/5.0 (compatible; bingbot/2.0)"
13)
14printf "%-22s %-6s %-10s %s\n" "USER-AGENT" "CODE" "BYTES" "SERVER"
15for ua in "${AGENTS[@]}"; do
16 out=$(curl -sS -A "$ua" -o /tmp/body.$$ -w "%{http_code} %{size_download}" "$URL" 2>/dev/null)
17 code=$(echo "$out" | cut -d' ' -f1)
18 size=$(echo "$out" | cut -d' ' -f2)
19 srv=$(curl -sSI -A "$ua" "$URL" | grep -i '^server:' | tr -d '\r' | cut -d' ' -f2-)
20 printf "%-22s %-6s %-10s %s\n" "${ua:0:20}" "$code" "$size" "$srv"
21done
22rm -f /tmp/body.$$
正常結果應該是所有 bot 都 200、且 bytes 相近。任何一行 403 / 429 / bytes 明顯偏小，都是問題。
三、檢索管線拆解：從問題到候選 chunk
回到 Part 1 的六階段圖，這裡逐階段講清楚「什麼會被淘汰」。
3.1 Query Fan-out：你的用詞決定你有沒有入場券
使用者問「ERP 要花多少錢」，引擎不會只用這七個字去查。它會展開：
原始問題：「台灣中小企業導入 ERP 大概要花多少錢？」
┌──────────────────────────────────────┐
│ LLM 生成 4-8 個檢索查詢 │
└──────────────────────────────────────┘
│
┌───────────┬───────┴────────┬──────────────┐
▼ ▼ ▼ ▼
"ERP 導入費用" "ERP 報價 中小企業" "ERP cost SMB" "鼎新 ERP 價格"
│ │ │ │
▼ ▼ ▼ ▼
各自打索引，各取 top-K，合併去重 → 候選池 40-150 個 chunk
對 GEO 的含義：
- 你的內容如果只用了「系統導入預算」這種說法，而市場慣用「導入費用」「報價」，你在多數子查詢中都不會被撈到。
- 不是塞關鍵字，是要覆蓋語意空間。同一個概念的 3-5 種說法，各自出現在自然的句子中。
實務做法：
在同一篇文章中自然使用這些變體：
導入費用 / 導入成本 / 報價 / 預算 / 花多少錢 / implementation cost / TCO
錯誤做法（會被判為 keyword stuffing）：
「ERP 導入費用、ERP 導入成本、ERP 報價、ERP 預算…」堆在一起
3.2 Retrieval：兩種索引並存
候選池
▲
┌─────────┴─────────┐
│ │
┌───────────────┐ ┌───────────────────┐
│ 倒排索引 │ │ 向量索引 │
│ (BM25 / 關鍵字)│ │ (Embedding 語意) │
├───────────────┤ ├───────────────────┤
│ 擅長： │ │ 擅長： │
│ • 專有名詞 │ │ • 換句話說 │
│ • 型號、代碼 │ │ • 概念相近 │
│ • 精確片語 │ │ • 跨語言 │
│ 不擅長： │ │ 不擅長： │
│ • 同義改寫 │ │ • 精確數字/型號 │
└───────────────┘ └───────────────────┘
└─────────┬─────────┘
Hybrid Search
（主流引擎都用混合檢索）
推論：既要有精確的專有名詞（給 BM25），也要有自然的概念表述（給向量）。只做其中一邊會漏掉一半的檢索路徑。
3.3 Rerank：淘汰率最高的一關
這是整條管線中最殘酷的一步。
候選池 120 個 chunk
│
▼ Cross-encoder 對 (query, chunk) 逐對打分
┌──────────────────────────────────────────────┐
│ chunk_042 score 0.91 ← 直接回答了問題 │
│ chunk_007 score 0.88 │
│ chunk_113 score 0.85 │
│ ─────────── 截斷線（top-12） ─────────── │
│ chunk_055 score 0.61 ← 相關但不夠直接 │
│ chunk_089 score 0.44 │
│ ... （其餘 108 個全部丟棄） │
└──────────────────────────────────────────────┘
│
▼
進入 context window 的 8-20 個 chunk
淘汰率通常在 85-93%。這代表：被檢索到 ≠ 被讀到。
Cross-encoder 打的分數，本質上是在問：「這段文字，是不是在直接回答這個問題？」
同一個資訊，兩種寫法的 rerank 分數差異（示意）
問題：「Redis 的 TTL 精確度是多少？」
寫法 A（分數低 ~0.42）
「Redis 提供了多種資料結構，包括 String、Hash、List、Set 與
Sorted Set。此外，Redis 也支援過期時間的設定，這在快取場景
中非常實用。開發者可以透過多種指令來操作…」
→ 問題的答案被埋在一段泛泛的介紹中，chunk 整體相關度被稀釋
寫法 B（分數高 ~0.89）
「Redis TTL 的過期檢查不是即時的。Redis 採用惰性刪除
（存取時檢查）加上定期取樣刪除（預設每秒 10 次，每次隨機
取樣 20 個 key）。因此一個 key 過期後，實際被清除的時間
可能延遲數百毫秒到數秒，取決於 key 空間大小與存取頻率。」
→ 整個 chunk 都在回答這個問題，沒有雜訊
這就是 GEO 最核心的一條原則：以 chunk 為單位寫作，不是以文章為單位。
四、Chunking：你的頁面在模型眼中的樣子
4.1 常見的切塊策略
策略 切法 對 GEO 的影響
────────────────────────────────────────────────────────────────────
固定長度 每 512 / 1024 token 硬切 句子被切斷，語意破碎
→ 你無法控制
遞迴字元切分 依 \n\n → \n → 。 → 空白 段落是主要邊界
（最常見） 逐層退讓，直到符合長度 → 你的段落長度很重要
語意切分 用 embedding 找語意斷點 主題轉換處切開
→ 一段一主題最安全
結構感知切分 依 HTML 標題層級切 H2/H3 是天然邊界
（品質最高） → 標題結構直接決定 chunk
多數生產級 RAG 用的是「結構感知 + 遞迴」的混合。這給了我們兩個可操作的槓桿：
- 標題層級 = chunk 邊界。H2 / H3 用得好，切出來的 chunk 就乾淨。
- 段落長度 = chunk 內容。理想的段落是 100-300 字，自成一個完整答案。
4.2 一個具體對照
❌ 壞的結構（切出來的 chunk 全是碎片）
## 產品介紹
我們的產品很好用。（20 字）
它支援很多功能。（15 字）
包括 A、B、C。（12 字）
價格方面，基本版每月 500 元，專業版 1500 元，
企業版需洽詢。（30 字）
→ 切出 4 個過短 chunk，每個都無法獨立回答任何問題
→ 「價格」那段脫離上下文後，讀者不知道是什麼產品的價格
✔ 好的結構（每個 chunk 獨立成立）
## OrderFlow 的定價方案有哪些？
OrderFlow 提供三個方案。基本版每月 500 元新台幣，含
3 個使用者席次與每月 1,000 筆訂單處理；專業版每月
1,500 元，含 10 席次、無限訂單與 API 存取；企業版採
年約報價，起價約 12 萬元／年，包含 SSO、專屬客戶成功
經理與 99.9% SLA。三個方案都提供 14 天免費試用，
不需信用卡。（2026 年 7 月定價）
→ 一個 chunk 完整回答「定價」這個問題
→ 主詞明確（OrderFlow），脫離上下文仍成立
→ 有數字、有單位、有日期，可接地
4.3 「主詞消失」問題
這是中文內容特別嚴重的一個坑。
原文（在頁面上讀起來很順）：
「本產品採用分散式架構，可支援每秒 5 萬筆交易。
它的延遲中位數為 12ms。」
被切成 chunk 後，模型看到的：
「它的延遲中位數為 12ms。」
→ 「它」是誰？模型無法接地，這個 chunk 的價值歸零。
規則：每 2-3 個段落就要重新出現一次完整主詞（品牌名 / 產品名 / 主題名）。這在人類閱讀時稍微冗贅，但對 GEO 是必要的。
一個實用的自檢方法：
1# chunk-independence-check.py
2# 粗略檢查：把文章依段落切開，找出沒有明確主詞的段落
3import re, sys
4
5ENTITY = sys.argv[2] if len(sys.argv) > 2 else "OrderFlow"
6PRONOUNS = ["它", "他們", "這個", "該產品", "本系統", "上述", "如前所述"]
7
8text = open(sys.argv[1], encoding="utf-8").read()
9paras = [p.strip() for p in text.split("\n\n") if len(p.strip()) > 40]
10
11for i, p in enumerate(paras):
12 has_entity = ENTITY in p
13 has_pronoun = any(w in p[:40] for w in PRONOUNS)
14 if not has_entity and has_pronoun:
15 print(f"[段落 {i+1}] 依賴上文代詞、缺少主詞：\n {p[:80]}…\n")
五、Grounding 與引用選擇：模型憑什麼選你
進到 context window 之後，還有最後一關：模型要決定這句話掛誰的引用。
Context window 裡有 12 個 chunk，其中 4 個都提到「ERP 導入約需 3-6 個月」
模型的選擇邏輯（依權重排序）：
① 具體性 有數字、有範圍、有條件 > 泛泛陳述
「3-6 個月（20-50 人規模、標準模組）」
勝過「大約半年」
② 可查核性 有來源、有日期、有方法論 > 沒有
「根據我們 2026 年 47 個專案的統計」
勝過「業界經驗顯示」
③ 新鮮度 頁面有明確日期且較新 > 無日期或過舊
→ 沒有日期的頁面在時效性題目上幾乎必敗
④ 網域權威 被廣泛引用的網域 > 陌生網域
→ 這是短期內最難改變的一項
⑤ 一致性 與其他 chunk 說法一致 > 孤例
→ 你的數字如果和所有人都不同，會被視為離群值丟棄
⑥ 表述清晰 單句可直接搬用 > 需要重組
→ 模型偏好可以幾乎原句引用的內容
5.1 「可原句搬用」的重要性
生成模型在寫答案時，成本最低的路徑是輕度改寫既有句子。你的句子越接近「可以直接放進答案的形狀」，被選中的機率越高。
可搬用度低：
「關於部署時間這個議題，其實需要考慮相當多的變數，
包含但不限於團隊規模、既有系統的複雜度，以及…」
→ 模型必須重組整段才能用
可搬用度高：
「標準 ERP 導入時程為 3-6 個月：需求訪談 3-4 週、
設定與客製 6-10 週、資料移轉 2-3 週、UAT 與教育訓練 3-4 週。」
→ 模型幾乎可以原封不動放進答案
5.2 為什麼「比較表」特別容易被引用
因為表格天生具備上面六項的前四項：具體、可查核、結構清晰、可直接搬用。
實測上，一個格式良好的比較表被引用的機率，通常是同樣資訊寫成散文的 2-3 倍。這也是為什麼 Part 3 會要求「每篇核心內容至少一張表」。
六、八個讓頁面永遠不被引用的技術死因
按「發生頻率 × 殺傷力」排序。每一項附診斷指令。
╔════════════════════════════════════════════════════════════════╗
║ 死因 1：純客戶端渲染（CSR） ║
╚════════════════════════════════════════════════════════════════╝
症狀：curl 拿到 <div id="root"></div> 加一包 JS
影響：致命。內容等於不存在
診斷：curl -s -A "GPTBot" URL | grep -c "你文章中的某個句子"
→ 回 0 就中了
解法：SSR / SSG / 預渲染（Part 4 Step 7）
╔════════════════════════════════════════════════════════════════╗
║ 死因 2：CDN / WAF 封鎖 AI bot ║
╚════════════════════════════════════════════════════════════════╝
症狀：Googlebot 200，GPTBot 403
影響：致命，且完全無聲——你不會收到任何告警
診斷：第二節的 ai-crawler-check.sh
解法：CDN 規則加白名單（Part 4 Step 1）
╔════════════════════════════════════════════════════════════════╗
║ 死因 3：內容在互動元件裡（Accordion / Tab / Modal） ║
╚════════════════════════════════════════════════════════════════╝
症狀：FAQ 全放在點擊才展開的手風琴，且內容由 JS 注入
影響：高。最諷刺的是 FAQ 正是最該被引用的內容
診斷：檢視原始碼，看答案文字在不在 HTML 裡
解法：內容一律進 HTML，用 CSS 控制顯示；或用 <details>
╔════════════════════════════════════════════════════════════════╗
║ 死因 4：沒有日期或日期不可信 ║
╚════════════════════════════════════════════════════════════════╝
症狀：頁面沒有 datePublished / dateModified，或每天自動更新成今天
影響：中高。時效性題目直接出局；假造更新日會傷害信任
診斷：curl -s URL | grep -o 'dateModified[^,]*'
解法：JSON-LD 正確標註，且只在真的改內容時更新
╔════════════════════════════════════════════════════════════════╗
║ 死因 5：Chunk 主詞缺失 ║
╚════════════════════════════════════════════════════════════════╝
症狀：段落全靠上下文，抽出來看不懂
影響：中高。內容被讀到但無法被接地
診斷：第四節的 chunk-independence-check.py
解法：每 2-3 段重述主詞
╔════════════════════════════════════════════════════════════════╗
║ 死因 6：關鍵資訊只存在於圖片 ║
╚════════════════════════════════════════════════════════════════╝
症狀：定價表、規格表、流程圖是 PNG
影響：中高。多數檢索管線不做 OCR
診斷：把頁面轉純文字，看關鍵數字還在不在
解法：圖片 + 對應的 HTML 表格（圖給人看，表給機器看）
╔════════════════════════════════════════════════════════════════╗
║ 死因 7：無限捲動 / 分頁內容 ║
╚════════════════════════════════════════════════════════════════╝
症狀：文章第二頁之後靠 JS 載入
影響：中。後半內容完全不可見
診斷：curl 拿到的字數 vs 實際字數
解法：提供完整單頁版本（?view=all）並在 canonical 指向它
╔════════════════════════════════════════════════════════════════╗
║ 死因 8：登入牆 / Cookie 牆 / 地區牆 ║
╚════════════════════════════════════════════════════════════════╝
症狀：AI crawler 拿到同意畫面或 302 到登入頁
影響：致命
診斷：curl 不帶 cookie 看回什麼
解法：內容前 N 段對 bot 開放；或用 Schema.org 的 isAccessibleForFree
標註 paywall 範圍（誠實標註比偽裝好）
七、實測：同一份資訊，四種寫法的差異
以下是一個可以自己重跑的小實驗設計。用同一份事實資訊，寫成四種形式，各自建成獨立頁面，觀察 4-6 週後的引用情況。
版本 寫法 被檢索到 進 rerank 被引用
────────────────────────────────────────────────────────────────────────
A 行銷散文，無數據 ✔ ✘ 0%
「業界領先的效能表現」
B 行銷散文 + 少量數據 ✔ 偶爾 ~8%
「效能提升超過 40%」
C 結構化段落 + 數據 + 日期 ✔ ✔ ~28%
每個 H3 對應一個問題
D C + 比較表 + 具名來源 + FAQ ✔ ✔ ~45%
數字為示意量級（實際會依主題競爭度大幅變動），但相對關係在各種主題上都很穩定：
影響力排序（由大到小）
1. 有沒有可接地的事實（數字、日期、來源） ← 決定「能不能」被引用
2. chunk 是否獨立成立 ← 決定「會不會」被選中
3. 是否有表格 / 清單等高密度格式 ← 決定引用機率的乘數
4. 網域權威 ← 決定同分時誰勝出
5. 頁面速度、圖片、字型等傳統 SEO 項目 ← 幾乎不影響 GEO
最後一項值得強調：Core Web Vitals 對 GEO 幾乎沒有直接影響。AI crawler 不在意 LCP。如果你的團隊資源有限，把精力從「把 LCP 從 2.1s 優化到 1.8s」移到「把 20 篇核心文章重寫成 chunk-friendly」，投報率高一個數量級。
八、為什麼選 X 不選 Y
選擇 選 X 的理由 不選 Y 的理由
──────────────────────────────────────────────────────────────────────────────
SSG / SSR AI crawler 直接拿到完整 HTML 純 CSR：內容等於不存在
vs 純 CSR 首屏內容 100% 可見 動態渲染（給 bot 不同版本）：
維護成本低 雙軌維護、有被判 cloaking 風險
翻轉條件：內容是高度個人化的儀表板（本來就不該被引用）時，CSR 沒問題。
──────────────────────────────────────────────────────────────────────────────
結構感知 chunking 標題層級即語意邊界 固定長度切分：句子被腰斬
（H2/H3 分節） 你能主動控制切點 語意切分：你控制不了引擎用哪種
vs 長篇不分節 每節可獨立回答一個問題
翻轉條件：敘事型長文（案例故事、訪談）分節反而破壞流暢度——這類內容本來就不是
GEO 的主力，用來建立品牌即可。
──────────────────────────────────────────────────────────────────────────────
開放檢索 bot 立即可見，附帶連結流量 全部封鎖：等於退出 AI 搜尋
vs 全部封鎖 引用會標註來源，是曝光不是竊取 全部開放：訓練 bot 涉及版權立場
（訓練 bot 另議）
翻轉條件：廣告變現媒體、付費內容站——這類站應該「開放檢索 bot 但只給摘要層級
內容」，用 isAccessibleForFree 誠實標註。
──────────────────────────────────────────────────────────────────────────────
HTML 表格 可被解析成結構化資料 圖片表格：多數管線不做 OCR
vs 圖片表格 可被原句搬用 PDF：可被讀但優先級低於 HTML
可被複製
翻轉條件：資訊圖表（infographic）本身是傳播素材時用圖，但必須同時提供 HTML 版。
──────────────────────────────────────────────────────────────────────────────
具體數字 + 來源 可接地，grounding 階段存活 模糊修飾詞：無法接地，直接丟棄
vs 模糊修飾詞 可查核，提升網域信任 誇飾語言：實測為負向因子
翻轉條件：沒有。這一條沒有例外。
──────────────────────────────────────────────────────────────────────────────
主動比較競品 比較型查詢流量大、意圖明確 迴避競品：把整類查詢讓給對手
vs 完全不提對手 比較表格易被引用
展現領域專業度
翻轉條件：法務對比較性廣告有嚴格規範的產業（醫療、金融、法律）——改用
「選型考量因素」的中立框架，不指名。
九、把機制翻譯成一張診斷流程
當你發現某個問題上自己沒被引用，用這張圖逐層排查：
「問題 Q 上我沒被引用」
│
▼
┌───────────────────────────────┐
│ 你有沒有一個頁面在回答 Q？ │ ✘ → 內容缺口，去寫（Part 3）
└───────────────┬───────────────┘
│ ✔
▼
┌───────────────────────────────┐
│ AI crawler 拿得到完整內容嗎？ │ ✘ → 死因 1/2/3/7/8（Part 4 Step 1/7）
│ (curl -A "GPTBot") │
└───────────────┬───────────────┘
│ ✔
▼
┌───────────────────────────────┐
│ 傳統搜尋搜得到嗎？ │ ✘ → 索引問題，先修 SEO
│ (site:yoursite.com "關鍵句") │
└───────────────┬───────────────┘
│ ✔
▼
┌───────────────────────────────┐
│ 回答 Q 的那一段能獨立成立嗎？ │ ✘ → 死因 5，重寫 chunk
│ (抽出來單獨讀，看得懂嗎) │
└───────────────┬───────────────┘
│ ✔
▼
┌───────────────────────────────┐
│ 那一段有可接地的事實嗎？ │ ✘ → 加數字、日期、來源
│ (數字 / 日期 / 具名來源) │
└───────────────┬───────────────┘
│ ✔
▼
┌───────────────────────────────┐
│ 被引用的是誰？他們多了什麼？ │ → 通常是：更新的日期、
│ (去讀勝出的那 3 個頁面) │ 更具體的數字、更高的網域權威
└───────────────┬───────────────┘
│
▼
剩下的是網域權威問題 → 長期戰（Part 3 第六節）
這張流程圖能解掉 80% 的「為什麼我沒被引用」。剩下 20% 是權威度與競爭問題，那需要時間。
十、小結：三個必須內化的機制
Rerank 是瓶頸，不是 retrieval。 被找到很容易，被選中很難。85-93% 的候選在 rerank 掛掉。所有內容決策都要問一句：「這一段被單獨抽出來，是不是在直接回答某個問題？」
Chunk 是優化單位，不是頁面。 你在優化的不是「這篇文章」，而是「這篇文章能切出幾個高品質的獨立答案」。一篇好文章可能貢獻 5 個可引用 chunk；一篇壞文章貢獻 0 個。
可接地性決定生死。 模型不能引用它無法驗證的東西。沒有數字、沒有日期、沒有來源的句子，在 grounding 階段會被靜靜丟掉——你甚至不會知道發生過。
下一篇進入方法層：把這些機制轉成一份有優先順序的行動清單。
本系列文章：
- Part 1：概念篇 — 當搜尋結果不再是十條藍色連結
- Part 2（本篇）：原理篇 — AI 引擎如何檢索、選擇與引用你的內容
- Part 3：方法篇 — 內容、結構、技術三層 GEO 策略
- Part 4：實作篇 — 從零把網站改造成 AI 可引用
- Part 5：量測與案例篇 — 建立 GEO 監測系統與實戰復盤
- Part 6：實戰案例 — 大型企業官網（多語系 + AWS + 法遵）
- Part 7：實戰案例 — 電商網站（12,000 SKU + 價格新鮮度）
- Part 8：實戰案例 — 單頁式產品 Landing Page
- Part 9：實戰案例 — 線上課程平台（付費牆 + 影片）
- Part 10：實戰案例 — 私有 Repo 與內部知識庫
- 商業篇：Part 11 市場 ｜ Part 12 GEO vs SEO 判斷 ｜ Part 13 顧問方法論 ｜ Part 14 產業劇本 ｜ Part 15 工具與技術棧 ｜ Part 16 規模化
