Vercel 與 MERJ 針對超過五億次 GPTBot 抓取紀錄做的聯合分析，翻遍全部樣本，找不到任何一次執行 JavaScript 的痕跡。也就是說，如果你的網站靠 React、Vue、Next.js 這類前端框架，把標題、內文、價格、規格都交給瀏覽器現場跑 JavaScript 才組出來，GPTBot 抓到的很可能只是一具空殼。
這正是 JavaScript SEO（讓搜尋引擎與 AI 爬蟲都正確讀到 JavaScript 產生的內容）現在最棘手之處，它從 Google 一家的單選題，變成 Google 加上一整排 AI 爬蟲的雙重考卷。更麻煩的是，這道落差幾乎不會主動示警：頁面在 Google 排名穩定、自然流量正常、後台看起來一片健康，AI 引擎那一端讀到的卻是一片空白，兩件事安安靜靜地同時成立，沒有一根指針會提醒你該去查。
先弄懂 Google 跟 AI 爬蟲在「讀」這件事上到底差在哪、這個差別會不會因為你在乎的是哪家 AI 品牌而不同，再往下拆哪些頁面最危險、怎麼自己測，以及該怎麼補。
Google 會幫你把 JavaScript 跑完，大多數 AI 爬蟲不會
Google 處理一個網頁，依官方文件說明分成三個階段。第一階段是檢索（Crawling），Googlebot 抓下網址與 HTML、CSS、JavaScript 等資源；第二階段是轉譯（Rendering），Google 動用一套常駐更新的無頭 Chromium，把頁面上的 JavaScript 真的跑一遍，產生轉譯後的完整頁面；第三階段是建立索引（Indexing），依轉譯後的內容決定怎麼收錄。關鍵卡在中間那一關，因為會真的執行 JavaScript，React、Vue 做出來的內容，Google 才有機會在轉譯後讀到。
多數 AI 爬蟲少了這一關。GPTBot、ClaudeBot、PerplexityBot 抓到頁面後，只讀伺服器一開始回傳的原始 HTML，把裡面的文字直接抽出來就走，不執行任何腳本、不等畫面跑完，也不會回頭重抓。你的 JavaScript 事後才往 DOM 裡塞的商品規格、價格、評論、比較表，它們一概收不到。
這不是臆測。Vercel 與 MERJ 的分析發現，即使 GPTBot 確實會下載 JavaScript 檔案，約 11.5% 的抓取會這麼做，也只是下載，沒有一次真的執行。同樣的模式在 ClaudeBot、PerplexityBot，以及 Meta 與位元組跳動的爬蟲身上都成立。把樣本拉大來看，多份針對主流 AI 爬蟲的觀察分析也得出一致結論：多數 AI 爬蟲目前完全無法執行 JavaScript，只讀得到靜態 HTML。
會這樣設計不是爬蟲偷懶，是渲染太貴。AI 爬蟲抓取規模極大，又把單一頁面的逾時壓得很短，常常只給一到五秒，要在這種規模下逐頁跑 Chromium、等網路閒置，運算成本會高到不合理。略過渲染，抓取才能又快又便宜，而且這不是一個正在補的暫時缺口，是短期內不會變的設計取捨。Google 官方在 JavaScript SEO 指南裡也提醒，即便它自己的轉譯能力已經很成熟，仍建議採用伺服器端轉譯或預先轉譯，原因很直白，不是所有漫遊器都能執行 JavaScript。
GPTBot、OAI-SearchBot、ChatGPT-User，你真正該顧的是哪一個？
但「AI 爬蟲」這幾個字背後，其實藏著一層更容易被忽略的細節，多數人把它當成一種東西看待，其實同一家公司底下就分成好幾種身份，各自的工作不一樣，能不能用 robots.txt 分開管也不一樣。
以 OpenAI 為例，官方文件把旗下爬蟲拆成三隻，各自有獨立的 robots.txt 控制權杖。GPTBot 負責收集網頁內容，拿去改善生成式基礎模型，在 robots.txt 擋掉它，代表你的內容不會被用於訓練。OAI-SearchBot 負責把網站收進 ChatGPT 的搜尋功能，才是真正決定你會不會出現在 ChatGPT 搜尋結果裡的那一隻，一旦被擋，網站就不會出現在 ChatGPT 的搜尋答案裡，但還是可能以一般連結形式被提到。ChatGPT-User 負責在使用者於對話裡提問時，即時抓取某個網頁來回答，OpenAI 官方特別註明這隻不用來判斷網站要不要進搜尋結果，而且因為是使用者觸發，robots.txt 的規則不一定套用得上。三隻各自獨立設定，擋掉訓練用的 GPTBot，不代表 OAI-SearchBot 也一起被擋。
Anthropic 用的是同一套邏輯。依官方說明，ClaudeBot 負責蒐集網頁內容、訓練模型；Claude-User 負責在使用者向 Claude 提問、需要即時讀取某個網頁時出動；Claude-SearchBot 負責把內容收進 Claude 的搜尋索引，會不會出現在 Claude 的搜尋答案裡，看的主要是這一隻。三隻同樣可以分開允許或擋掉。
這個分工重要，不是因為它能解決渲染問題，恰恰相反，不管是訓練用的 GPTBot、ClaudeBot，還是負責搜尋結果的 OAI-SearchBot、Claude-SearchBot，全部都不執行 JavaScript，規則跟上一節講的一樣通用。差別只在於，如果你在乎的是會不會被 ChatGPT 或 Claude 的搜尋功能引用，真正該顧好原始 HTML 的對象，是 OAI-SearchBot 和 Claude-SearchBot 這兩隻，而不是常被拿來當代名詞的 GPTBot。
哪些頁面最容易在 AI 眼中變成一片空白？
知道要顧哪一隻爬蟲還不夠，真正決定你會不會中招的，是頁面本身的做法。風險最高的，偏偏是你最希望被引用的那幾種頁面——商品頁、比較頁、規格問答頁、分類頁。
這個重疊格外棘手。互動性愈強的頁面，愈習慣把內容事後注入：可篩選的商品列表、即時變動的價格、分頁式說明文件、現場運算的比較工具，這些都是 JavaScript 的強項，卻也正是它們讓內容在原始 HTML 裡缺席。一篇伺服器端輸出的部落格文章通常沒事；一個把功能、方案、評價全靠 API 在載入後才補上的比較頁，對 AI 爬蟲來說常常就是一張白紙。
用一個簡化例子看更清楚。假設某個 SaaS 方案比較頁的原始 HTML 只有一行 <div id="root"></div>，功能列表、價格級距、使用者評價全部要等 JavaScript 執行後才透過 API 填進畫面。瀏覽器跑完腳本，畫面完整漂亮；Google 轉譯後也讀得到。但 AI 爬蟲抓到的就是那一行空殼，只能如實認定這頁沒有內容。你以為自己做了一個資訊完整的比較頁，AI 眼中卻是一個什麼都沒寫的網址。
順帶一提，把重要連結做成 button 或 onclick、卻沒有正常的 <a href="...">，是同一類問題的延伸。爬蟲主要靠 HTML 連結發現新頁面，不在原始 HTML 裡的連結，連 Google 都可能漏掉，只讀靜態 HTML 的 AI 爬蟲更不用談。
還有一層更少人注意到的風險。ChatGPT 的搜尋功能背後，相當程度仰賴微軟 Bing 的索引提供結果來源，而 Bing 對 JavaScript 的處理能力同樣有限。也就是說，一個高度仰賴客戶端渲染的頁面，可能同時在「Bing 索引不到」與「AI 爬蟲直接抓不到」這兩個管道一起吃虧，不是顧好一邊就沒事。
三個免費自測法，找出你自己都不知道的破洞
這些風險頁面在原始 HTML 裡到底缺了什麼，不必用猜的，三個免費做法就能自己驗，看的都是「爬蟲實際收到什麼」，不是「瀏覽器渲染出什麼」。
第一個做法，看原始碼。在頁面上按右鍵選「檢視網頁原始碼」，注意是「檢視原始碼」，不是「檢查／Inspect」，後者顯示的是渲染後的 DOM，會騙過你的眼睛。如果標題、內文、價格、問答答案明明白白就在這份原始碼裡，代表內容走伺服器端輸出，AI 爬蟲讀得到；如果看到的大多是空的 div 和一堆 script 標籤，內容該在的地方全是空的，那就是客戶端渲染，AI 爬蟲什麼都讀不到。
第二個做法，關掉 JavaScript 重新載入。在瀏覽器設定裡停用 JavaScript，重新整理頁面，這幾乎就是不渲染的爬蟲所看到的畫面。把最值錢的幾頁，像是商品頁、比較頁、價格頁，一頁一頁這樣走過去，看什麼消失了，消失的那些區塊就是需要補渲染、AI 才讀得到的部分。
第三個做法，用爬蟲的視角抓一次。會用終端機的話，直接用 curl 把頁面抓下來，看回傳的原始 HTML 裡有沒有瀏覽器看得到的內容；再進一步，可以翻伺服器日誌，確認 GPTBot、ClaudeBot、OAI-SearchBot 這些爬蟲來抓的時候，拿到的是內容豐富、狀態碼 200 的 HTML，還是一個空殼。
這裡有個容易被忽略的細節。Google Search Console 的網址檢查工具，測的是 Google 轉譯後的結果。它能告訴你 Google 看不看得到，回答不了「AI 爬蟲看不看得到」這個問題。Search Console 過關，不代表 AI 那一關也過，要測 AI，還是得回到「原始 HTML 裡有沒有內容」這個更底層的問題。
抓出問題後，SSR、SSG、預渲染怎麼選？
測出問題之後，接下來是怎麼補。補法的核心其實很簡單，讓內容在 JavaScript 執行之前就已經存在於原始 HTML 裡，其他都是技術選擇的問題。能做到這件事的主要有三條路，差別在於這份 HTML 是什麼時候、為誰產生的。
伺服器端渲染（SSR）是伺服器在每次請求時，當場把完整 HTML 組好再送出，內容一開始就在回應裡。React 搭 Next.js、Vue 搭 Nuxt、Angular 搭 Angular Universal，都能在送到瀏覽器前先在伺服器把關鍵內容渲染好。它適合變動頻繁或因人而異的頁面，像即時價格、即時庫存，這類頁面每次都需要一份新鮮的 HTML。
靜態生成（SSG）是在網站建置時就先把 HTML 頁面產生好，內容直接烤進檔案裡。爬蟲一抓就拿到全部，人類使用者載入也快，最適合每次請求內容都一樣的頁面，像部落格文章、說明文件、比較頁、分類概覽。內容更新頻繁的話，可以搭配增量靜態再生成（ISR）這類做法，定時或按需重建頁面。
預渲染（Prerendering）走的是折衷路線，對爬蟲送出一份預先做好的 HTML 快照，對真人訪客則保留原本的動態體驗。它的好處是不必動到既有架構，保留現有的單頁式應用，只在外面加一層預渲染，把渲染好的 HTML 交給爬蟲。對沒辦法整個打掉重做、又想趕快補上可見度的團隊，這是務實的選項。
| 渲染方式 | 內容在何時產生 | 最適合的頁型 | 注意點 |
|---|---|---|---|
| SSR 伺服器端渲染 | 每次請求即時生成 | 即時價格、庫存、個人化頁 | 伺服器負載與回應時間要顧 |
| SSG 靜態生成 | 部署建置時預先生成 | 部落格、文件、比較、分類頁 | 內容常變要搭配 ISR 重建 |
| 預渲染 | 抓取時給爬蟲快照 | 不易重做的既有 SPA | 給爬蟲與真人的內容須一致 |
怎麼配，把渲染方式對到頁型就好：變動頻繁或個人化的頁面，像是即時價格、庫存、帳號區，走 SSR；穩定的內容頁，像是部落格、文件、比較、分類，走 SSG；不方便重做的既有 SPA，用預渲染當補丁。與其糾結該挑哪個前端框架，不如先守住一個更基本的原則，標題、主要內文、規格、問答這些真正要被讀到的東西放進初始 HTML，動態強化的互動效果再讓 JavaScript 事後接手也不遲。
動態渲染、llms.txt，都不是真正的解法
選定路線動工前，還有兩個常被誤會的做法得先講清楚，免得走了冤枉路。
動態渲染只是過渡方案，不是長期解法
要提醒的是，「動態渲染（Dynamic Rendering）」，也就是給一般使用者前端渲染、給爬蟲一份預先渲染好的 HTML，曾經是解 SPA 問題的常見手法。但如今 Google 官方已經把它定位成臨時性的權宜之計，不是建議的長期解法，原因是它會墊高系統複雜度與維護成本，還得很小心別讓爬蟲跟真人看到差太多的內容，否則就有被當成偽裝（cloaking）的風險。動態渲染跟預渲染的分界，就在於前者交給爬蟲的快照必須跟真人看到的內容一致，內容明顯不同才會被判定為偽裝。
llms.txt 解決不了「看不到」的問題
另一個常被誤會的解法是 llms.txt。這幾年常有人以為，只要在網站根目錄放一份 llms.txt，列出重點頁面與說明，AI 就能讀懂你的網站。但 Google 搜尋團隊已經公開表態，不支援也不打算把 llms.txt 當成排名或檢索的訊號。Google 的 Gary Illyes 在 2025 年 7 月的 Search Central Live 上直接說明這一點，John Mueller 也在公開場合把 llms.txt 類比成早就被棄用的關鍵字中繼標籤，並表示沒有任何一家 AI 服務公開表示會使用 llms.txt 做為判斷依據。OpenAI 與 Anthropic 官方的爬蟲文件，同樣沒有提到 llms.txt 是抓取或索引的判斷條件。放一份 llms.txt 給人看沒有壞處，但它解決不了「原始 HTML 裡沒有內容」這個底層問題，把渲染架構顧好，才是真正的解法。
驗收時，這幾個訊號真的都留在原始 HTML 裡了嗎？
架構顧好之後，還有最後一步不能省，回頭驗收。不論選了哪一條補救路徑，最後都要把「檢視原始碼」那一招再跑一遍，確認該在原始 HTML 裡的東西真的都在。
要特別檢查四樣：頁面的主要內文與標題、結構化資料（Schema）、canonical 標籤、meta description。這些訊號如果是靠 JavaScript 在載入後才補上去，對只讀原始 HTML 的 AI 爬蟲來說，等於不存在。常見的雷區還有幾個：用 JavaScript 事後改 title 或 canonical，可能跟原始 HTML 裡那一組打架，造成訊號衝突；不存在的頁面在單頁式應用裡全部回傳 200、卻顯示「找不到頁面」，會形成 soft 404，讓爬蟲分不清這頁有沒有效；還有要靠使用者滑動或點擊才載入的內容，爬蟲不一定觸發得到。
順序上有個重點。Google 官方提醒，如果原始 HTML 裡就放了 noindex，Google 可能直接不轉譯這個頁面，所以別指望用 JavaScript 事後把 noindex 拿掉。能在原始 HTML 階段就定好的訊號，就別留到轉譯之後。
這四樣聽起來瑣碎，但要驗的東西其實可以收斂成一句話，就是把這個頁面當成一張只有原始 HTML、沒有 JavaScript 的紙，問自己上面還讀不讀得到你要被搜到、被引用的所有資訊。讀得到，AI 那一關才算過。
這幾年，不少人把力氣都花在讓 Google 讀懂 JavaScript，渲染這一關確實補得差不多了，卻沒發現戰場早就換了地方。Googlebot 願意替你把腳本跑完，GPTBot、ClaudeBot 不會；就算搞定了訓練用的爬蟲，真正決定你會不會出現在搜尋答案裡的 OAI-SearchBot、Claude-SearchBot，還是得單獨確認一次，沒有一勞永逸這回事。能同時被搜尋引擎和一整排 AI 引擎讀到的網站，靠的從來不是更炫的前端框架，而是守住一個最基本的分寸，重要內容要在任何一段 JavaScript 開始執行之前，就先寫進原始 HTML 裡。下次改版或上線新頁面前，花十秒鐘把瀏覽器的 JavaScript 關掉，重新整理一次，眼見為憑最快。