# 策展 · X (Twitter) 🔥
> 作者：Tw93 (@HiTw93) · 平台：X (Twitter) · 日期：2026-05-04
> 原始來源：https://x.com/HiTw93/status/2050931710066565374
## 中文摘要
# 你所不知道的 GEO：AI 可見性原則、實踐與權衡
## 花一小時讓 AI 找到你的內容
最近有幾位朋友私訊我，說他們在詢問 AI 問題時，我的開源工具出現在了搜尋結果中。我其實沒做什麼刻意的操作，所以我想：為什麼不花一小時把這些結構整理好呢？整理完後，我發了一則簡短的推文，但當時的筆記有點雜亂。沒想到大家似乎真的很感興趣，所以我決定將其寫成一篇正式的文章，供大家參考。
我討厭為了排名而作弊，也討厭生成垃圾內容。這篇文章不會教你任何捷徑，重點在於如何幫助 AI 更好地理解你現有的內容。
我研究了為什麼會發生這種情況，發現 AI 搜尋的邏輯完全不同。傳統 SEO 是為了擠進前 10 名，但 83% 的 AI Overview 引用來源來自前 10 名以外的頁面。AI 獎勵的是清晰的結構與可靠的來源，而不是 PageRank。我的專案規模不大，但 README 和文件寫得夠好，以至於 AI 在大型網站內容貧乏的地方，會優先選擇我的專案。這大概就是為什麼朋友們會在 AI 結果中看到 Pake 和 MiaoYan 的原因。
AI 搜尋成長迅速：2025 年上半年年增率達 527%，ChatGPT 在 2026 年 2 月達到每週 9 億活躍使用者，且推薦流量的轉換率約為傳統搜尋的 5 倍。但它目前仍佔總推薦流量不到 1%。這是一個品牌可見性策略，而非流量策略。花一小時設定是值得的，不需要花上一週，因為你的產品才是真正的競爭優勢，而不是這些技巧。
## 使用 robots.txt 整理爬蟲類型
大多數人將 robots.txt 視為一個開關：要嘛封鎖所有 AI 爬蟲，要嘛全部允許。但 AI 爬蟲分為好幾種類型，它們的功能各不相同。
訓練用爬蟲（GPTBot、ClaudeBot、Meta-ExternalAgent、CCBot）會抓取你的內容來訓練模型。封鎖它們可以讓你的內容不進入訓練資料，但不會影響目前的 AI 搜尋結果。
搜尋與檢索爬蟲（OAI-SearchBot、Claude-SearchBot、PerplexityBot）會即時抓取內容來回答使用者的查詢。封鎖這些，你就會從 AI 搜尋中消失。
使用者觸發的抓取器（ChatGPT-User、Claude-User、Perplexity-User、Google-Agent）只有在有人將你的網址貼到聊天視窗時才會啟動。封鎖它們，使用者在詢問「總結這個頁面」時將一無所獲。
退出代幣（Google-Extended、Applebot-Extended）並非真正的爬蟲。它們是你宣告在 robots.txt 中以退出 AI 訓練的訊號。
未宣告的爬蟲（Bytespider、xAI 的 Grok bot）不會自我識別，也不一定會遵守規則。
我的做法是：允許搜尋/檢索與使用者觸發的爬蟲，封鎖訓練用與未宣告的爬蟲。
```
# Search & retrieval: allow
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
# User-triggered: allow
User-agent: ChatGPT-User
Allow: /
User-agent: Claude-User
Allow: /
# Training: block
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
# Opt-out tokens
User-agent: Google-Extended
Disallow: /
# Undeclared: block
User-agent: Bytespider
Disallow: /
```
## 撰寫你的 llms.txt 並連結你的網站
llms.txt 是一個新標準，類似於 robots.txt，但專為 AI 閱讀而設計。你在網站根目錄放置一個 Markdown 文件，描述網站的功能、關鍵頁面以及背後的開發者。AI 系統在爬取你的內容時會優先處理此文件。
BuiltWith 追蹤到超過 84 萬個部署了 llms.txt 的網站，包括 Anthropic、Cloudflare、Stripe 和 Vercel。但在 SE Ranking 對 30 萬個網域的調查中，採用率僅為 10%。現在還在早期階段，而搶先佈局就是一種優勢。
格式很簡單：
```markdown
# Your Project Name
> One-line description of what this is.
## Links
- [Documentation](https://yoursite.com/docs)
- [GitHub](https://github.com/you/project)
- [Blog](https://yoursite.com/blog)
## About
Short paragraph explaining the project, its purpose,
key features, and what makes it different.
```
建立好之後，提交到 directory.llmstxt.cloud、llmstxt.site，並透過 PR 提交到 GitHub 上的 llms-txt-hub 儲存庫。
我還做了一件有趣的事：我讓每個網站的 llms.txt 都參照了彼此。我維護著 tw93.fun、weekly.tw93.fun 和 yobi.tw93.fun。每個網站的 llms.txt 都連結到其他網站，形成一個網狀結構。AI 爬蟲從任何一個網站進入，都可以順著連結發現其他所有內容。
這些變更會在爬蟲重新造訪你的網站後生效，通常在幾天內。之後，嘗試在 ChatGPT 中搜尋你的專案名稱，引用來源和描述準確度應該會有所提升。
## 提供完整內容與 Markdown 路由
llms.txt 是摘要，而 llms-full.txt 是完整版本，通常為 30-60KB，包含專案描述、常見問題 (FAQ)、使用情境、競品比較以及 README 摘錄。Mintlify 的 CDN 分析顯示，llms-full.txt 的流量是 llms.txt 的 3-4 倍。找到摘要的 AI 系統會想要閱讀完整版本。
Markdown 路由則更進一步。Evil Martians 建議為網站上的每個頁面提供 .md 版本。一個 15,000 token 的 HTML 頁面轉換成 Markdown 文件後僅需 3,000 token，減少了 80% 的雜訊。
告訴 AI 你有 Markdown 版本的最簡單方法，是在頁面的 `` 中加入這段程式碼：
```htmlbars
```
Claude Code 和 Cursor 在抓取文件時已經會發送 `Accept: text/markdown` 標頭。這是自 1997 年以來就存在的標準 HTTP/1.1 內容協商機制。
## 在搜尋平台註冊你的網站
前述章節中 robots.txt 和 llms.txt 的工作讓你的內容對 AI 可讀，但 AI 必須先找到你。ChatGPT 的搜尋運行在 Bing 之上，Google AI Overview 使用 Google 自己的索引，Perplexity 也依賴搜尋 API。如果你的頁面沒有被搜尋引擎索引，上述所有的結構化工作都沒用。因此，第一步是確保 Google 和 Bing 已經索引了你的網站。
設定很簡單：前往 Google Search Console，透過 DNS 或 HTML 文件上傳驗證你的網域，然後提交你的 Sitemap 網址（通常是 yoursite.com/sitemap.xml）。檢查「頁面」索引報告，查看哪些頁面已索引，哪些有問題。如果重要頁面未被索引，請使用網址檢查工具手動請求索引。
你可能認為 Bing 不重要，但 Copilot、DuckDuckGo 和 Yahoo 的底層都運行在 Bing 的索引上。請在 Bing Webmaster Tools 註冊，提交你的 Sitemap，並查看「AI 效能」面板，了解 AI 引用你內容的頻率。順便設定 IndexNow，這樣當你發布新內容時，Bing 會立即收到通知，而不需要等待爬蟲發現。
設定 IndexNow 意味著在網站根目錄放置一個 API 金鑰文件，然後在每次發布內容時，向 `api.indexnow.org/indexnow` 發送一個包含變更網址列表的 POST 請求。Bing 會在幾分鐘內抓取它們。許多靜態網站產生器和 CMS 平台都有提供 IndexNow 的 plugin。
Google Search Console 目前還沒有 AI 專用面板，但提交 Sitemap 並監控索引狀態仍然值得做。Google 的 AI Overviews 涵蓋範圍比傳統搜尋結果更廣，因此即使是未排在前 10 名的頁面，也有機會出現在 AI 生成的答案中。
Perplexity 的使用者比你想像的還要多。他們在 `pplx.ai/publisher-program` 運行一個發布者計畫。一旦獲得批准，你將獲得 80/20 的營收分成，並能存取引用分析資料。
## 我為 AI 建立了一個專屬知識網站
與其等待 AI 從零散的來源抓取資訊，不如給它一個組織完善的單一入口。
一個知識網站應該提供三個層次：概覽 (llms.txt)、完整版本 (llms-full.txt, 30-60KB) 以及針對每個核心專案的獨立知識頁面。加入結構化的 JSON API，讓 AI 工具可以透過程式呼叫取得資料。從 GitHub API 等上游來源即時拉取資料，並配合定期重新整理的快取，將維護成本降至接近零。
有一點很容易被忽略：給 AI 一個敘事結構，而不僅僅是一份專案清單。如果你有多個專案，寫一段描述將它們串聯起來，說明它們的關聯、你的技術方向以及整體願景。當 AI 回答「這個人是誰」或「這個團隊在做什麼」時，連貫的敘事比平鋪直敘的清單效果好得多。
我的實作稱為 Yobi（源自日語「呼び / よび」，意為「呼叫」或「召喚」）。它提供一個 llms.txt 概覽、一個 50KB 的 llms-full.txt、各專案頁面，以及四個 JSON 端點（`/api/profile`、`/api/projects`、`/api/blog`、`/api/weekly`），這些端點透過 GitHub API 即時拉取資料，並使用每小時重新整理的 ISR 快取。技術棧：Next.js + TypeScript on Vercel。
JSON API 回傳帶有即時 GitHub 統計資料的結構化專案資料：
## 給每個專案一個獨立頁面
每個專案都需要自己的獨立頁面，而不是清單中的一行文字，而是一個包含可引用摘要、核心功能、競品比較、使用案例和安裝指令的自包含 Markdown 文件。Ahrefs 發現，被引用的頁面標題與使用者查詢的語意相似度更高，且自然語言的網址別名（如 `/projects/pake`）比模糊的 ID（如 `/page?id=47`）更容易被引用。
網址結構很重要。`/projects/pake` 在模型讀取第一行之前就告訴它頁面內容是什麼。`/page?id=47` 則什麼都沒說。
## 將結構化資料同步到你的主網域
子網域的權重低於根網域。發現 `example.com` 的 AI 爬蟲不會自動找到 `docs.example.com` 或 `api.example.com`。如果你的 llms.txt、專案頁面和 API 資料分散在各個子網域，AI 可能只能看到全貌的一部分。
解決方法是將關鍵結構化資料鏡像到你的主網域，讓 `example.com/llms.txt`、`example.com/projects/xxx.md` 和 `example.com/api/projects.json` 都集中在同一個地方。AI 爬蟲透過搜尋索引發現你的主站，就能在不離開的情況下找到所有內容。實作選項包括排程 CI 同步、建置時抓取或反向代理。我使用一個 GitHub Action，每晚將子網域資料同步到部落格儲存庫。
啟動新網站時，使用檢查清單來避免遺漏。核心項目：robots.txt（分類爬蟲權限）、llms.txt（包含交叉參照的網站摘要）、Sitemap（提交給搜尋引擎）、Bing Webmaster Tools（啟用 IndexNow）、Google Search Console（監控索引）。每個網站的 llms.txt 都應該參照其他網站，形成一個發現網格。
做這些工作時最容易陷入的陷阱，就是對遇到的每一種 GEO 技術都過度熱衷，試圖全部加上去，結果弄得一團亂，反而失去了重點。
## 這些方法沒用
`` 和 ``：沒有規範，也沒有任何主流 AI 系統採用。
`/.well-known/ai.txt`：有多個競爭提案，沒有真正的採用。等待勝出者出現吧。
帶有 AI 提示的 HTML 註解：解析器在 AI 看到內容之前就會移除註解。
透過 User-Agent 偵測來提供 Markdown：對機器人和人類回傳不同內容屬於「偽裝 (cloaking)」。Google 會懲罰你。
非官方的 AI meta 標籤：除非主流 AI 提供者明確記錄支援，否則它們只是雜訊。
## JSON-LD 並沒有你想像中那麼有用
我最初認為 JSON-LD 對 AI 可見性很有幫助。深入研究後發現情況更複雜。SearchVIU 進行了一項實驗，他們只將資料放在 JSON-LD 中，而不顯示在頁面上。他們測試的所有五個 AI 系統都沒能找到這些資料。Mark Williams-Cook 的後續實驗顯示，LLM 將 `