隨想27 分鐘閱讀

四大 AI 巨頭統一 robots.txt 訓練退訂標準,但獨立站長或許該放下防白拿執念了

2026 年 10 月 30 日,OpenAI、Google、Microsoft 與 Anthropic 罕見同步表態支援基於 robots.txt 的跨廠商統一 AI 訓練退訂令牌 __usage_ai-training,惟協議既不管即時 RAG 抽乾點擊,亦擋不住高達 30% 的違規抓取與住宅代理爬蟲。在傳統 PC 網站流量時代早已落幕的今天,除非你在營運 linux.do 這類沉澱高濃度真實活人對話的社群,否則獨立網誌站長與其死守幾百行黑名單,不如讓內容對搜尋、AI 與人類體驗全面 Open,將真正的護城河建在更容易變現的產品上。

AAFeng

2026 年 10 月 30 日,Anthropic 標準技術負責人 Kevin Kelley 向互聯網工程任務組(IETF)提交了個人互聯網草案《Machine-Readable Training Preference Signal》(文件編號 draft-kelley-aipref-training-preference-signal-00),定義了基於標準 robots.txt 的跨廠商統一 AI 訓練偏好令牌 User-Agent: __usage_ai-training。同一天,Google、Microsoft、OpenAI 與 Anthropic 四大龍頭模型廠商罕見地同步表態支援——表面上看,網站站長苦熬了三年的「逐家封鎖百餘個爬蟲打地鼠」時代,終於要被一行簡單的設定終結了。

但將草案條款、四家大廠的落地細則與第三方伺服器遙測日誌攤開對照,便會發現這份妥協遠沒有聽上去那麼慷慨。它只管修改模型權重的預訓練與後訓練,完全不管直接截留搜尋點擊的即時檢索增強(RAG / Grounding);Google 甚至將其與 Gemini 問答引用捆綁成「二選一」;而面對高達 15% 至 30% 的公開違規爬蟲與輪換住宅代理 IP 的商業抓取商,一紙 robots.txt 連防盜紗窗都算不上。

更值得獨立開發者與個人站長想清楚的是,在傳統 PC 網站流量時代早已落幕的今天,除非你在營運像 linux.do 那樣沉澱高濃度真實活人對話的社群,否則死守幾篇公開靜態文章既防不住白拿,也換不來一分一毫實質利益。與其在幾百行黑名單裏內耗,不如徹底轉變觀念讓內容一切 Open——對搜尋引擎友好、對 AI 爬蟲友好、對人類閱讀體驗友好,將真正的護城河建在更容易變現的產品上;如果這個網站本來就不為變現,那就灑脫隨它去。

一行程式碼管四家,IETF 新草案到底約定了甚麼

要理解為何四大 AI 巨頭會在 2026 年 10 月底突然握手言和,不妨先看看此前的 robots.txt 黑名單已經荒誕到了甚麼地步。

就在四巨頭正式公布前一天(2026 年 10 月 29 日),獨立研究者 Kuldeep Paul 發布了針對 Tranco 全球排名前 10,000 個高流量網域中 5,701 份有效 robots.txt 與 197 個已知 AI 爬蟲(45 個官方公開 + 152 個社群追蹤)的深度審計報告。結合 Suff Digital 基於 HTTP Archive 1,547 萬個網站的全網掃描數據(全網 9.9%、CrUX 前 1,000 大網站中有 28.9% 封鎖了至少 1 個 AI 爬蟲),過去三年「按廠商逐家封鎖」的模式已經出現了系統性失靈:

  1. 半數網站陷入「漏勺式封鎖」:在顯式封鎖 OpenAI GPTBot 的 810 個大型網站裏,整整 50.0%(405 個網站)漏掉了至少 1 個其他主流大模型訓練爬蟲——其中 79.5% 未封鎖 cohere-training-data-crawler,75.3% 未封鎖 MistralAI-Training,37.0% 未封鎖 Amazonbot,35.1% 未封鎖 Applebot-Extended,34.1% 未封鎖 Meta-ExternalAgent,27.3% 未封鎖 Google-Extended,23.3% 未封鎖 Bytespider,18.8% 未封鎖 ClaudeBot。全樣本中僅有 6.0%(344 個網站)完整封堵了全部 8 家主流訓練爬蟲。
  2. 三分之二殘留「殭屍令牌」:在封鎖 3 個以上 AI 爬蟲的 1,037 個網站中,多達 66.2%(687 個)至今仍在規則裏寫入 Anthropic 早已廢棄的 anthropic-ai 或 Claude-Web 舊令牌;更有 51 個大型網站(包括 espn.com 與 abcnews.com)只封了廢棄舊名卻漏掉了現行 ClaudeBot,形同虛設。
  3. 規則膨脹與標準難產:為了防漏,不少網站被迫維護冗長的複製貼上列表,單一網站最高甚至將 192 個 AI 爬蟲列入黑名單(brand-catcher.com)。而 IETF 於 2025 年 1 月成立 aipref 工作組後原本推進的綁定草案 draft-ietf-aipref-attach-05,由於試圖在 robots.txt 中新增 Content-Usage: train-ai=n 指令行——既要修改全球既有 RFC 9309 解析器語法,又在即時 RAG 權限劃分上爭執不下,最終陷入僵局。
IETF Datatracker 系統中 Machine-Readable Training Preference Signal 草案官方歸檔頁截圖,顯示作者 Kevin Kelley、更新日期 2026-10-30 以及未獲 IETF 正式背書的個人草案提示框
圖 1 · IETF Datatracker 官方狀態頁顯示 draft-kelley-aipref-training-preference-signal-00 目前屬於有效期至 2027 年 5 月 3 日的個人互聯網草案(圖片來源:IETF Datatracker / ITmedia NEWS)

正是在工作組原方案擱淺的背景下,Anthropic 的 Kevin Kelley 繞開新語法之爭,交出了這份有效期至 2027 年 5 月 3 日的個人草案,並獲得了四大廠商同步背書:

"This document describes how a service operator binds usage preferences (e.g., 'no AI training') to paths by writing ordinary robots.txt groups keyed by a per-purpose policy token in the User-Agent line. It introduces no new directive names and no new grammar: the path language, longest-match precedence, and group structure of robots.txt are not changed." (本文件描述了服務營運者如何透過在 User-Agent 行中以按用途劃分的策略令牌為鍵編寫普通 robots.txt 規則組,將使用偏好綁定至路徑。它不引入新的指令名稱,亦不引入新的語法:robots.txt 的路徑語言、最長匹配優先順序與組結構均保持不變。)

按照草案規範,如果站長希望禁止全站內容用於生成式 AI 模型訓練,僅對 /press-kit/ 傳媒資料目錄放行,只需在 robots.txt 中寫入:

Text
User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/
展示 Tranco 前 10,000 個網站中 810 個封鎖 GPTBot 的網站漏封其他主流訓練爬蟲比例,以及 197 個已知爬蟲、僅 6.0% 完整封堵與 66.2% 殭屍令牌三大痛點的數據資訊圖
圖 2 · Tranco Top 10,000 網站 robots.txt 實證掃描,半數封鎖 GPTBot 的大型網站仍向其他訓練爬蟲敞開大門,66.2% 殘留已失效的舊令牌(數據來源:Kuldeep Paul,2026-10-29)

這幾行看似直白的設定背後,藏着四條必須看清的技術邊界:

  • 雙底線(__)防碰撞設計:正如日本 SEO 專家鈴木謙一在技術拆解中所指出的,__usage_ai-training 完全符合 RFC 9309 的字元集,開頭特意加上雙底線 __,是為了防止部分實作過於寬鬆(例如執行子字串模糊匹配)的舊版解析器將其與真實爬蟲名稱誤匹配。未適配該標準的傳統搜尋爬蟲會將其視為未知爬蟲直接跳過,確保既有搜尋收錄零影響。
  • 萬用字元 User-Agent: * 絕不繼承:草案第 4.2 節寫下了硬性禁令——User-Agent: * 規則組絕不能(MUST NOT)被解釋為匹配 __usage_ai-training。哪怕你的網站寫了全域 User-Agent: * + Disallow: /,只要沒有顯式寫出 __usage_ai-training,在該機制下便等同於 unknown(未表達訓練退訂意願)。
  • 僅限「生成式模型參數修改」,非生成式任務豁免:草案直接引用詞彙表 draft-ietf-aipref-vocab-08 的定義,只約束「修改生成式 AI 模型習得參數」的行為;如果模型僅用於分類、排序或垃圾內容評分(哪怕順帶輸出文字理由),其訓練完全不受此限。
  • 不阻斷抓取、不溯及既往、商業合約優先:__usage_ai-training 不會出現在 HTTP 請求標頭裏,亦不禁止爬蟲將網頁抓回本地;它只對抓取當下生效,不要求廠商刪除此前已入庫的數據或還原已訓練好的模型權重;而且平台與網站之間的私下商業協議可以直接覆蓋 robots.txt 聲明。

四大巨頭同床異夢,過渡期設定與捆綁暗坑

促成四大巨頭在同一天集體表態的直接推手,其實是歐美監管高懸的達摩克利斯之劍。

一方面,歐盟《人工智能法案》(EU AI Act)第 53(1)(c) 條及配套《通用 AI(GPAI)行為準則》強制要求模型供應商支援透過 IETF 制定的跨行業統一 robots.txt 控制標準,Google 在官方公告裏直接點名新提案是為了對齊歐盟準則。另一方面,英國政府在 2026 年 3 月 18 日向國會提交的《版權與人工智能報告》中披露,在 11,500 餘份公眾諮詢意見裏,高達 88% 的受訪者要求強制事前授權(Opt-in),僅 3% 支持機器可讀退訂(Opt-out),迫使英國政府正式放棄推出法定 TDM 退訂例外。為了證明「行業自願技術標準足以解決問題、無需更嚴厲的事前許可立法」,四巨頭火速推出了這套統一信號。

但只要細讀四家公司的官方細則,便會發現同一行 User-Agent: __usage_ai-training 在各家後台觸發的真實後果截然不同:

對比 Microsoft Bing、Google、OpenAI 與 Anthropic 四家廠商對 __usage_ai-training 的生效時間、既有爬蟲體系及 AI 引用 Grounding 捆綁策略差異的四宮格資訊圖
圖 3 · 四大巨頭落地細則橫評,Microsoft 將模型訓練與 AI 回答引用徹底拆開,而 Google 將退訂信號映射至 Google-Extended,連帶封殺網站在 Gemini Apps 中的曝光機會
參與廠商 計劃生效時間 既有專有爬蟲與控制令牌 對 AI 搜尋 / Grounding 引用的連帶影響 關鍵注意事項與暗坑
Microsoft(Bing) 2027-02-01 Bingbot、頁面級 ai-training 與 ai-grounding 完全解耦,退訂訓練預設仍允許 Copilot 與 Bing AI 引用並導流 2027-03-01 正式廢棄 NoArchive / NoCache 的 AI 退訂語義,逾期未遷移將回退為 Allow
Google 2027 年初 Googlebot、Google-Extended(專有令牌優先順序更高) 強制捆綁 Gemini Apps,退訂訓練即喪失 Gemini 回答 Grounding 引用與點擊 Google 搜尋本體的 AI Overviews 與 AI Mode 綁死在 Googlebot 上,不受此信號約束
OpenAI 未來幾個月內 GPTBot(訓練)、OAI-SearchBot(搜尋)、ChatGPT-User 搜尋展示由 OAI-SearchBot 獨立控制,理論上不連帶封死 公告將範圍限定為「基礎生成式 AI 訓練」,與 GPTBot 衝突時的優先順序尚未公布
Anthropic 開發中(未定) ClaudeBot(訓練)、Claude-SearchBot、Claude-User 作為現有爬蟲體系的補充,搜尋爬蟲獨立劃分 Kevin Kelley 坦言跨服務邊緣案例複雜,上線仍需時日

這裏反差最強烈的是 Microsoft 與 Google 截然相反的產品誠意。

Microsoft Bing 首席產品經理 Krishna Madhavan 在官方網誌中明確承諾「出版商不應被迫在能夠於 Bing 中被發現與決定生成式模型如何使用其作品之間作出抉擇」,不僅將 AI Training 與頁面級 AI Grounding 徹底拆成兩個獨立開關,還新增了一個極具針對性的 DisallowExtended 級別——允許內容出現在 Bing AI、Copilot 和 Microsoft 365 自營回答裏換取引用曝光,但禁止 Microsoft 透過 Web IQ 或 Azure Foundry API 將你的內容轉售予第三方商業客戶。唯一需要留心的是,依賴舊版 NoArchive / NoCache 標籤防 AI 的舊網站,必須在 Bing Webmaster Tools 於 2026 年 12 月 15 日開放的過渡面板(有效期至 2027 年 9 月 30 日)或 2027 年 3 月 1 日大限前完成遷移。

反觀 Google,搜尋倡導者 John Mueller 給出的映射規則堪稱精明的「二選一捆綁」:

"When a website uses this policy token to opt out of training in its robots.txt file (and Google-Extended is not explicitly specified), Google plans to interpret that as if the publisher had disallowed Google-Extended... Websites that specifically allow Google-Extended are eligible to appear in responses and receive clicks via grounding in Gemini Apps." (當網站在其 robots.txt 檔案中使用此策略令牌退訂訓練且未顯式指定 Google-Extended 時,Google 計劃將其解釋為如同出版商禁止了 Google-Extended……顯式允許 Google-Extended 的網站才有資格在 Gemini Apps 的回答中透過 Grounding 展示並獲得點擊。)

正如《Search Engine Journal》高級編輯 Matt G. Southern 所批評的,由於 Google-Extended 將「訓練下一代 Gemini 模型」與「Gemini Apps 即時 Grounding 引用」綁在同一根繩上,站長只要寫了 __usage_ai-training 退訂,便會自動丟掉 Gemini Apps 的回答引用;而如果你為了保住 Gemini 引用去寫 Google-Extended: Allow,根據專有令牌優先規則,你的內容又會重新被拿去餵 Gemini 模型。至於流量體量更大的 Google 搜尋 AI Overviews(月活躍用戶 25 億)與 AI Mode(月活躍用戶逾 10 億),則直接綁死在傳統主爬蟲 Googlebot 身上——Kuldeep Paul 的退訂不對稱性研究證實,在封鎖 Google-Extended 的 667 個大型網站裏,99.85%(666 個)根本不敢動 Googlebot 一根毫毛。

再加上 Meta 傳訊主管僅在社交平台口頭稱讚該標準是「重要一步」卻拒絕承諾遵守(甚至在 2026 年 10 月試圖透過修改商業服務條款強迫使用 Facebook/Instagram 工具的傳媒授權抓取外部網站,引發 WAN-IFRA 等全球出版商協會聯合抗議後才將生效期推遲至 11 月 20 日),以及 Apple、ByteDance、Perplexity 和中國內地大模型廠商尚未跟進,如果站長現階段確實想在規則層面拒絕訓練、保留搜尋引用,2026 至 2027 過渡期絕不能刪掉既有爬蟲名稱,標準設定應當是「新通用信號 + 未生效期四巨頭訓練令牌 + 未加入協議廠商令牌」並存:

Text
# 1. 跨廠商統一 AI 訓練退訂信號(2026 年底至 2027 年初陸續生效)
User-Agent: __usage_ai-training
Disallow: /

# 2. 過渡期保留四大巨頭獨立訓練令牌(放行 OAI-SearchBot / Claude-SearchBot 保搜尋引用)
User-Agent: GPTBot
User-Agent: ClaudeBot
User-Agent: Google-Extended
Disallow: /

# 3. 尚未承諾支援統一信號的其他主流訓練與數據採集爬蟲
User-Agent: CCBot
User-Agent: Bytespider
User-Agent: Meta-ExternalAgent
User-Agent: Applebot-Extended
User-Agent: Amazonbot
User-Agent: cohere-training-data-crawler
User-Agent: MistralAI-Training
Disallow: /

算清流量賬與攻防賬,一紙君子協定鎖不住內容

將上面這段嚴絲合縫的 robots.txt 部署上線之後,你的原創心血就真的免遭「白拿」了嗎?只要算清流量與攻防這兩筆硬賬,答案其實很殘酷。

左右雙欄對比展示各大模型平台懸殊的爬取點擊回流比(Anthropic 高達 147,755 比 1,AI 引薦佔比僅 0.04% 至 0.16%)與 15% 至 30% 違規抓取、90% 付費牆被住宅代理攻破及日誌零可觀測性的資訊圖
圖 4 · 流量與攻防雙重殘酷現實,大模型抓十萬次才施捨一次點擊,而違規爬蟲與商業代理早已繞過 robots.txt 君子協定(數據來源:Cloudflare Radar & TollBit)

先算第一筆**「只吃不吐」的流量賬**,這亦是絕大多數內容創作者本能反感大廠無償取用的根源。

根據 Cloudflare Radar 橫跨 12 個月觀測週期的全球遙測與流量用途拆解報告,全網 AI 爬蟲請求中高達 80% 用於餵養模型訓練,僅 18% 用於 AI 搜尋索引,2% 至 3.2% 用於用戶觸發訪問。每向原網站送回區區 1 次真實人類點擊,Anthropic 平均要抓取網頁 147,754.7 次(2025 年 1 月峰值甚至達到驚人的 286,930.1:1),OpenAI 平均抓取 1,437.8 次,Perplexity 抓取 172.4 次,Microsoft 抓取 42.3 次,Google 抓取 11.8 次。

TollBit 對全球出版商第一方伺服器日誌的追蹤更直觀地印證了這種失衡:網站上「AI 爬蟲訪問 : 人類訪問」的密度由 2025 年第一季的 1:200 飆升至第四季的 1:31(2026 年上半年歐洲網站達 1:33),然而 AI 平台帶來的外部引薦流量加起來僅佔總外部引薦的 0.04% 至 0.16%;AI 引薦平均點擊率(CTR)在半年內由 0.80% 暴跌至 0.27%,比傳統 Google 自然搜尋 8.6% 的平均點擊率低了近 96%(即便是 Google AI Overviews,點擊率亦僅有約 0.9%,見 Search Engine Roundtable)。

更關鍵的是,BBC 代表 Chris Needham 在 IETF 工作組 Issue #172 中一針見血地指出,真正抽乾原創網站點擊量的是即時 RAG 與問答摘要,而 __usage_ai-training 對此完全不管;Adobe 與 Mozilla 工程師在 Issue #246 和 Issue #254 中亦警告,將網頁切成向量嵌入(Embeddings)快取或是藉 AI Agent「用戶觸發」之名代讀,都成了規避訓練退訂的「偏好黑洞」。同時,與內置計費協議的 RSL 1.0、歐盟 W3C TDMRep,或是 Cloudflare 推出的 HTTP 402 Pay Per Crawl 按爬計費及覆蓋逾 380 萬個網域的 Content Signals 策略(2026 年 9 月 15 日起已預設替新接入廣告網站於邊緣節點攔截訓練爬蟲)不同,四巨頭推行的 __usage_ai-training 純粹是無償二元開關,不產生一分一毫版權收益。

再算第二筆**「防君子不防小人」的攻防賬**。

  • 高達三成的公開違抗:TollBit 日誌審計顯示,亮明身份的 AI 爬蟲直接無視 robots.txt Disallow 強行抓取的違規比例,由 2024 年底的 3.3% 一路飆升至 2025 年底的 30%(2026 年上半年歐洲網站仍高達 15%)。
  • 隱身代理與商業轉售橫行:早在 2025 年 8 月,Cloudflare 安全團隊便透過取證證實,當網站用 robots.txt 與防火牆封禁 PerplexityBot 後,對方會切換至偽裝成 macOS Chrome 瀏覽器的隱身爬蟲並輪換住宅代理 IP 繞過封鎖。TollBit 在 2026 年上半年的金絲雀測試更發現,向 AI 實驗室倒賣語料的 14 至 15 家商業抓取平台,在單次請求中輪換 32 至 43 個住宅代理 IP 並偽造 Googlebot 身份,成功攻破了 30 家受測英美主流媒體中 27 家(90.0%)的硬付費牆,轉手以最高 22.50 美元/千頁的價格賣給大模型團隊。
  • 後台訓練零可觀測性:安全與治理分析師 P.K. Sharma 在簡報裏點破了最後一層窗戶紙:

"A 'signal' that a provider will 'honor' sounds like a lock. The documents say otherwise. The vocabulary draft states that preferences are 'not a security mechanism'... A training preference attached to content that was fetched for another purpose leaves no such trace in a site's logs. Whether the training use of a page happened under one crawl or another is something only the operator can say." (供應商承諾「遵守」的「信號」聽起來像是一把鎖。但文件說的並非如此。詞彙表草案聲明偏好「不是一種安全機制」……附加在出於其他目的抓取的內容上的訓練偏好不會在網站日誌裏留下任何痕跡。一個頁面的訓練使用究竟發生在哪一次抓取之下,只有模型營運方自己知道。)

當 Googlebot、Bingbot 或 OAI-SearchBot 合法抓走你的網頁用於搜尋後,這份 HTML 在大廠內網裏有沒有流進後訓練或合成數據管線,獨立站長從自己的 Nginx 日誌裏連一絲痕跡都查不到。

後 PC 時代的護城河分野,誰該嚴防死守,誰該徹底放手

談完協議細節與殘酷數據,我想跳出技術參數,談談自己作為獨立開發者與網誌站長的真實想法。

站在創作者的立場上,不想被大廠無償白拿是再正當不過的本能。辛辛苦苦排查幾天軟件 Bug、實測整理出來的深度長文,大廠連招呼都不打就拿去餵百億參數的商業模型,既不付費,連幾個回流點擊都吝嗇給,換了誰心裏都會覺得不忿。這亦是為何每逢新的防爬標準出台,站長圈總會掀起一輪抄設定熱潮。

但冷靜下來換個角度想,就算我們將 robots.txt 設定得滴水不漏,徹底不讓 AI 訓練甚至不讓 AI 引用,又能改變甚麼呢?

我們必須承認一個已經發生的結構性事實:傳統 PC 網站的時代,基本上已經結束了。

過去二十年裏,獨立站長習以為常的那套「寫文章 → 等搜尋引擎收錄排上首頁 → 讀者點進 PC 網頁閱讀 → 靠 AdSense 展示廣告或聯盟連結變現」的流量循環,不管你防不防 AI 爬蟲,都已經不可逆地萎縮了。用戶獲取資訊的入口早已由「打開十個藍色連結逐頁比對」,遷移到了對話視窗、流動端推送與 AI 智能體工作流裏。將自家網誌的大門焊死,並不會讓已經消失的 PC 時代傳統搜尋流量重新回到你的網站上,只會讓你在新的資訊分發網絡裏徹底隱形。

左右對照剖析後 PC 時代網站護城河分水嶺的架構圖,左側為 linux.do 等擁有高頻活人對話核心資產、需靠 WAF 嚴防死守的社群論壇,右側為不必死守靜態文章的絕大多數獨立網誌與普通網站
圖 5 · 認清網站的真實護城河邊界,只有承載鮮活真人互動生態的社群才需要重兵防爬,普通靜態內容網站死守黑名單並無商業回報

在我看來,今天到底要不要防爬蟲,核心取決於你的網站屬於哪一種物種:

極少數真正需要嚴防死守爬蟲的,是像 linux.do、Reddit 這類沉澱着高濃度「真實活人數據」的論壇與社群。 在 AI 生成廢話氾濫成災的年代,成千上萬真實開發者每天高頻發帖、即時互助、插科打諢、分享一手踩坑經驗與資源所形成的鮮活對話和社群氛圍,是全網最稀缺的數碼資產,亦是這類論壇真正的立身護城河。如果不加防範,任由各路爬蟲高頻並行掃蕩,不僅核心社群壁壘會被瞬間抽空,源站數據庫與頻寬亦會被直接打穿。而且你會發現,這類社群防爬蟲從來不會天真地指望一行 robots.txt,而是直接祭出 Cloudflare 高強度五秒盾、WAF 行為質詢、登入狀態與等級閱讀門檻——因為人家守的是真金白銀的活人生態。

但對於絕大多數獨立網誌、個人文件站與中長尾網站而言,幾篇公開的靜態文章本身並不是靠「藏着不讓 AI 看」就能保值的護城河。 既然技術上防不勝防(防住了守規矩的大廠訓練爬蟲,防不住套着住宅代理的數據轉售商與單次抓取重用),商業上鎖死了也帶不來任何真實收益,那我們最該更新的其實不是 robots.txt,而是自己的觀念。

內容一切 Open,把體驗做透,把變現交給真正的產品

既然防不勝防、防了亦無利可圖,獨立站長更聰明的活法反而是徹底反過來——放下防白拿執念,讓內容一切 Open,去打磨真正容易變現的產品。

展示獨立站長以對搜尋引擎友好 SEO、對 AI 爬蟲友好 GEO、對用戶體驗友好 UX 三大支柱構建全面開放底座,進而分流至商業產品變現與非功利個人網誌灑脫心態的策略路線圖
圖 6 · 後 PC 時代的獨立站長破局法則,用搜尋、AI 與人類體驗的三重開放攢足信任籌碼,商業回報交給真正的產品,純粹分享則坦然隨它去

我所說的「內容一切 Open」,並不是躺平不管網站質素,而是將原本浪費在折騰防爬黑名單上的精力,全部收回來投入到「三個友好」上:

  1. 對搜尋引擎友好(SEO 優化):將語義化 HTML 結構、清晰的 URL 層級、精準的標題摘要元數據與頁面首屏回應速度做到位,讓傳統搜尋引擎依然能毫無阻礙地抓取與理解你的內容。
  2. 對 AI 爬蟲與問答引擎友好(GEO 優化):坦然拆掉那些糾結的爬蟲封鎖,寫出結論先行、論據紮實、程式碼區塊可重現、結構層次分明的文章。當同行在 ChatGPT、Claude、Copilot 或 Gemini 裏搜尋解決方案時,你的網誌能夠成為大模型優先採信與引用的權威信源,AI 反而成了替你在全網篩選同頻讀者的免費擴音器。
  3. 對真實人類的閱讀體驗友好:這是最核心、卻被太多站長忽視的一環。去掉遮擋正文的彈出式視窗與牛皮癬廣告,克制排版字重與配色對比度,提供順暢的多語言閱讀體驗。哪怕只有十分之一的讀者順着搜尋或 AI 引用點進你的網站,乾淨利落的體驗亦能讓他立刻記住你的名字與審美質素。

想通這一層,接下來的選擇便會變得異常清爽:

如果你的網站承載着商業目標,想要在 AI 時代賺到錢,那就別指望靠鎖住幾篇圖文收過路費,而是直接去做更容易變現、AI 抓走幾頁網頁也抄不走的產品與服務——例如解決具體工程痛點的 SaaS 軟件工具、開源項目的託管增值版、深度工作流擴展模組或高交付價值的顧問服務。就算未來有一天你要跟平台或客戶洽談商業合作與利益交換,也得先將用戶體驗、專業口碑與觸達廣度做出來,手裏才有坐上牌桌談利益的籌碼。公開內容越開放、傳播越廣,流向你核心變現產品的信任漏斗便越紮實。

而如果你的獨立網誌本質上就不是一個用來變現的產品,純粹是工作之餘記錄技術實踐、整理思考感悟的一塊自留地——那其實就更沒必要跟爬蟲糾纏了。隨它去吧,寫出來的文字無論是被搜尋引擎收錄,還是被裝進某個大模型的參數與檢索庫裏,只要最終能幫另一個素昧平生的讀者解決一個具體問題,這篇內容便已經圓滿完成了它的使命。

參考資料與延伸閱讀

  1. Kevin Kelley (Anthropic) / IETF:《Machine-Readable Training Preference Signal (draft-kelley-aipref-training-preference-signal-00)》與 IETF Datatracker 官方狀態頁(2026-10-30)
  2. John Mueller / Google Search Central Blog:《Supporting a shared AI training control for websites》與 Google 通用爬蟲官方文件(2026-10-30)
  3. Krishna Madhavan / Microsoft Bing Blog:《Your content, your choice: clearer preferences for training and grounding》與 Bing Webmaster Tools 新偏好說明文件(2026-10-30)
  4. OpenAI 官方聲明:《Making it easier for websites to express AI training preferences》(2026-10-30)
  5. Kevin Kelley / IETF ai-control 郵件列表:《Announcement of draft-kelley-aipref-training-preference-signal-00》(2026-10-30)
  6. Kuldeep Paul:《Who blocks AI crawlers in 2026: a robots.txt study of 10,000 top domains》與《The AI search opt-out asymmetry》(2026-10-29)
  7. Matt Suffoletto / Suff Digital:《What Percentage of Websites Block AI Crawlers? (HTTP Archive 15.47M Sites)》(2026-09-24)
  8. João Tomé / Cloudflare Radar:《The crawl-to-click gap: Cloudflare data on AI bots, training, and referrals》與《Perplexity is using stealth, undeclared crawlers to evade website no-crawl directives》(2025-08)
  9. TollBit:《State of the Bots Report Series (Q4 2024 – H1 2026: The Bad Bots)》(2026-07-15)
  10. Matt G. Southern / Search Engine Journal:《Google, Microsoft & OpenAI Plan To Honor Shared AI Training Opt-Out》(2026-11-01)與鈴木謙一《AI学習の拒否を一括設定、GoogleやOpenAIなど主要AI企業が共通シグナルに対応へ》(2026-11-02)
  11. Parminder Kumar Sharma (P.K. Sharma):《OpenAI to Honor Common robots.txt Signal for AI Training Preferences: What the Post Says and Does Not Establish》(2026-10-30)
  12. UK Government:《Report on Copyright and Artificial Intelligence》(2026-03-18)與 European Commission EU AI Act Art. 53(1)(c) & GPAI Code of Practice