「怎麼才能被 ChatGPT 引用？」這個問題通常會得到一份清單式的回答：寫好內容、加結構化資料、做一個 llms.txt。這些建議與其說是錯的，不如說打錯了層。它描述的是一個頁面應該長什麼樣，卻跳過了真正決定結果的兩個問題：檢索系統到底夠不夠得著你的頁面，以及頁面上有沒有哪一段話，被從上下文里揪出來之後還站得住。
這篇講的是機制，按它實際運行的順序講。這些檢查我們在自己站上跑，其中有兩條幫我們發現了再多內容功夫也補不上的問題。
引用是檢索問題，不是排名問題
ChatGPT 帶連結回答時，並不是每個問題都去實時讀一遍網路。一個檢索步驟先從索引里撈出候選段落；模型再用撈回來的東西組織答案，並給它真正倚重的那部分標上出處。由此推出兩條結論，對做慣了傳統 SEO 的人來說都不太直覺：
- 單位是段落，不是頁面。一個頁面可以排得很好卻毫無貢獻——因為那個值得被引用的事實，藏在一張圖里、一張沒有文字等價物的圖表裡，或者一段要等 JavaScript 跑完才存在的文字裡。
- 能被檢索到和值得被引用，是兩道不同的門檻。進索引只是前提。成為關於這個問題「現有最乾淨的那句話」，才是拿到出處標注的原因。大多數 GEO 清單只處理了第一道，然後困惑於流量為什麼沒動。
排名和引用在實踐中是會分開的。你可以穩坐某個詞的第三位卻從沒被引用過，因為你上面那兩個頁面恰好用一句自足的話把答案說清楚了，而你把答案埋在一個叫「我們的理念」的小節的第四段裡。
三個爬蟲，三份不同的工作
最貴的錯誤就發生在這裡，因為人們把「OpenAI 的爬蟲」當成一個東西來想。OpenAI 文件里寫明的是三個獨立的 agent，它們做的不是同一份工作：
- GPTBot——為模型訓練做的大規模抓取。擋掉它，改變的是未來的模型從你站上吸收了什麼。它不會把你從 ChatGPT 的實時引用里拿掉。
- OAI-SearchBot——構建檢索所讀的那個搜索索引。決定你到底能不能被引用的，是這一個。
- ChatGPT-User——當使用者的問題觸發實時瀏覽時，去抓取某個具體 URL。擋掉它，抓取就恰好失敗在有人正在問起你的那一刻。
常見的翻車是這樣的：一個團隊決定不希望自己的內容被拿去訓練模型，於是擋掉 GPTBot，並且認為自己做了個深思熟慮的決定。確實做了——關於訓練的。關於檢索，他們什麼都沒說。更糟的版本是：有人用一條通配規則擋掉所有 OpenAI 的 agent，悄無聲息地把公司從 AI 答案里刪了，然後花一個季度納悶為什麼被引用的都是競爭對手。
這些是可以分開的選擇，那就分開做。我們自己的 robots.txt 三個都放行，只擋掉 /api/ 和分享連結——分享連結是使用者內容，本來就不該進索引。你的選擇可以不一樣：訓練和檢索是兩筆性質確實不同的交易。只是要按爬蟲決定，而不是按廠商決定，並且隔一陣子重讀一遍廠商文件，因為這些策略是會變的。
真正卡住你的那道門，不是 robots.txt
robots 是一個請求，也是所有人都會去檢查的那一層。真正咬人的是你的 CDN 或 WAF。在不少預設配置下，邊緣平台會對不認識的 user agent 做挑戰或直接攔截，而結果是無聲的：robots.txt 上寫著 Allow，邊緣返回 403，於是你實際上無法被抓取，而你倉庫里的每一個檔案都在堅稱大門敞開。
這個檢查花十秒鐘，卻幾乎沒人做：
curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "ChatGPT-User" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "PerplexityBot" https://your-site/200 表示夠得著。返回 403、503 或者一個挑戰頁，就意味著你有一個內容功夫永遠補不上的可見性問題。要打到生產環境、從你自己網路之外打、並且每個域名都打一遍——每個域名通常有各自的邊緣配置，而它們會隨時間跑偏。
如果這篇文章你只做一件事，就做這件。它是單位時間回報最高的檢查，而且對任何內容審計都是隱形的。
如果一個事實需要 JavaScript 才出現，它就不存在
檢索爬蟲通常只解析原始 HTML，不執行 JavaScript。所以判斷一條主張能不能被引用，標準不是你瀏覽器里看到什麼，而是這個：
curl -s https://your-site/page/ | grep -i "the claim you want quoted"輸出里沒有，就等於沒有東西可引。這有一個實打實的設計後果：對引用關鍵的文字——你的定義、關鍵事實、FAQ 答案、價格與安全主張——必須在服務端返回的 HTML 里。一個在 hydration 之後替換文案的運行時字典，作為增強很好；但它不能是這個事實唯一存在的地方。
這一點在多語言站上咬得最狠，也正是我們刻意繞開的坑。如果你的中文文案只活在一個 JavaScript 的 i18n 字典里，那麼對一個讀原始 HTML 的爬蟲來說，你的中文內容壓根不存在。我們的做法是把每種語言都內聯成真實標記，再讓 CSS 決定人類看到哪一種。爬蟲拿到四種語言，讀者拿到一種。代價是頁面體積，值得。
把話寫成能被整段揪走還站得住的樣子
這部分才是真正在「寫」，而不是在搭管道；管道通了之後，槓桿就在這裡。
一個被檢索出來的片段，抵達模型時是不帶你頁面的。沒有標題層級、沒有上一段、沒有導航。就照這個前提去寫：
- 先給答案。標題下的第一句話應該是答案，不是跑道。「X 是 Y」勝過「在當今快速演進的格局中……」——後者什麼都沒回答，也永遠不會被引用。
- 主語要寫出來。「它支援 OAuth」被摘出去之後沒法用；「Orkas 支援 OAuth」能活下來。代詞會死在切片里。
- 每條主張都要自足。實體、限定條件、邊界，都在一句話里：「使用自己的供應商時，模型流量直接發往該供應商，不經 Orkas 代理。」這句話單獨被引用也不會變成假話——這正是它可被引用的原因。
- 寧可可覈實，不要顯得漂亮。含混的最高級從不會被引用，因為它們沒有回答任何人問過的問題。
問題本身就是檢索的鑰匙
使用者是在提問，而檢索匹配的是長得像問題的文本。一個直接就是那句問題的標題——「Orkas 會代理模型流量嗎？」——比「模型架構」這種名詞短語匹配得更好。FAQ 區塊對 AI 可見性的收益之所以遠超其體量，靠的是這個，而不是什麼結構化資料的魔法：它們本身就是一問一答，而這正是被檢索的那個東西的形狀。
結構化資料讓你可解析，不是讓你被偏愛
JSON-LD 買不到引用。它買到的是無歧義的分類：這個頁面是什麼、誰發佈的、哪段文字是問題、哪段是它的答案。有兩條規則比其餘的都重要：
- FAQ 結構化資料必須和可見文本逐字對應。結構化資料聲稱了頁面沒說的話，這是個信任問題；搜索引擎會把這種不一致當作垃圾信號，而不是排版失誤。
- 永遠不要偽造評分、獎項或數量。一個引擎抓到你編造了一個聚合評分，它就有了理由把你說的其他一切都打折。
1:1 這條規則屬於會悄悄腐爛的那類——有人改了可見 FAQ、忘了改結構化資料，半年後兩者開始互相矛盾。我們用一個測試來強制它：遍歷 sitemap 里的每一個頁面，從 JSON-LD 里取出 FAQ，斷言每一條問題和答案都逐字出現在該頁的可見文本里。一旦漂移，構建就掛。結構化資料是你對自己頁面下的一個斷言，就該按斷言來檢驗。
llms.txt：便宜、有用，且被吹過頭了
對這個檔案要誠實。llms.txt 是一個提案性質的約定。沒有哪個主流引擎承諾會讀它，誰告訴你這是一條攝入通道，誰就是在猜。
它真正的用處更窄，但仍然值那一個小時：一個穩定的地方，把你的規範事實平鋪直敘地講清楚——產品是什麼、模型與資料怎麼處理、價格、真正重要的那些 URL。當爬蟲或者真人研究者確實落到這個檔案上時，他拿到的是沒有話術的版本，而不用從營銷頁面里去拼。它同時是個不錯的倒逼機制：如果你沒法用四十行、不帶形容詞地把產品事實講清楚，那你的頁面也做不到——而這本來就是你早晚要面對的內容問題。
它不是什麼：不是保證，也不能替代這些事實出現在頁面本身上。
自相矛盾會讓你被丟掉
答案引擎會交叉核對。如果你的價格頁說一套、文件說另一套、首頁 FAQ 說第三套，引擎不會替你裁決——它要麼含糊其辭，要麼去引用一個前後一致的人。
所以跨頁面的事實一致性是真正工作量的大頭，而且一點都不光鮮。當一個模型、價格或安全事實變了，它必須在同一次改動里到處都改——頁面、文件、首頁 FAQ、llms.txt——否則你就製造了一個比這次改動活得更久的矛盾。我們把這條當硬規則而不是習慣來執行，因為習慣是打不過 deadline 的。
外部佐證勝過自我聲明
下面是最難接受的一點：關於你自己，你自己的站是現有最弱的信源。引擎會給佐證加權，而且這麼做是對的。只出現在你自己域名上的主張，是營銷話術；同一條主張出現在 GitHub 上、第三方對比里、論壇帖子里、別人寫的文件里，就是事實。
所以一旦站內基本功真的做扎實了，站外的功夫就比再建一個落地頁更划算——倉庫、目錄站、榜單、真實的討論。說白了：站內功夫讓你可被引用，站外功夫讓你被引用。團隊總是穩定地在前者上投入過度，因為那是他們能控制的那一半。
怎麼衡量，而不自欺
GEO 類文章通常在這裡開始發虛，所以直說：ChatGPT 的引用你沒法乾淨地衡量。沒有儀錶盤。你手上只有三個不完美的信號：
- 服務器日誌。去 grep
OAI-SearchBot和ChatGPT-User。抓取頻率、以及哪些 URL 被抓，會告訴你是否在索引里、以及什麼正在被實時拉取。這是你擁有的最誠實的信號。 - 來自助手的引薦流量。真實，但只是一部分——大量引用被讀到卻從沒被點擊，而這恰恰就是答案引擎的意義所在。
- 人工抽查。把你想拿下的十個問題挨個問一遍，記錄誰被引用了。笨、只能看方向，但仍然是唯一能觀察到答案界面本身的辦法。
這三個都只當方向看。任何人賣給你一個精確的「GEO 分數」，賣的都是他自己編出來的數字。
換我們會先做什麼
按回報排序，不是按它在 PPT 里好不好看：
- 1. 用
curl -A拿檢索爬蟲打生產環境。如果邊緣在攔它們，這份清單上其他事都不重要。 - 2. 用
curl | grep檢查你的關鍵主張。把任何只靠 JavaScript 才出現的內容，挪進服務端返回的 HTML。 - 3. 把每個標題下的第一句話改寫成答案，主語寫出來。
- 4. 讓 FAQ 文本和 FAQ 結構化資料完全一致；任何拿不出可見文本支撐的結構化資料，刪掉。
- 5. 把頁面、文件、
llms.txt之間互相打架的事實對齊。 - 6. 然後——也只有到這時——再去掙站外的佐證。
第 1 步和第 2 步通常就是那些消失的引用藏身的地方。它們也是沒人寫文章講的兩步，因為它們不是內容營銷。
收尾
被 ChatGPT 引用，沒有它周圍那個縮寫聽起來那麼神秘。讓檢索爬蟲夠得著你。不靠 JavaScript 也能讀到你。用一句自足的話就能引用你。你自己的各個界面之間不打架。在你的營銷站之外的某個地方，有人替你佐證。工具會換來換去；這五條不會。
這些檢查我們在自己站上跑，也把它們做進了 Orkas 的一個工作流里——它會審計一個站點的搜索與 AI 答案可見性，並給回一份按優先級排好的修復清單。想看這底下那一層——主 agent 怎麼規劃工作、怎麼派遣專才去乾——去讀多 Agent 編排實戰。