關鍵事實:多數 AI 爬蟲不跑 JavaScript
這個事實多數工程師知道但多數老闆不知道——因此導致大量「我們花百萬做了漂亮的 SPA 但 AI 引用 0」的故事。
下表整理 2026 年主要 AI 爬蟲的 JS 執行能力(依各家公開文件 + 第三方測試的綜合觀察,個別行為可能隨時間變化):
| 爬蟲 | 是否執行 JavaScript | 用途 |
|---|---|---|
GPTBot(OpenAI 訓練) |
❌ 不執行 | 訓練語料抓取 |
ChatGPT-User(即時引用) |
⚠️ 部分執行(簡單 JS) | 對話即時引用 |
ClaudeBot(Anthropic 訓練) |
❌ 不執行 | 訓練語料抓取 |
PerplexityBot(Perplexity) |
⚠️ 部分執行 | 搜尋 + 即時引用 |
Google-Extended(Gemini 訓練) |
⚠️ 部分執行(共用 Googlebot) | 訓練語料 |
CCBot(Common Crawl) |
❌ 不執行 | 開放資料集,多家 LLM 採用 |
Googlebot |
✅ 執行(Chrome renderer) | Google 搜尋索引 |
Bingbot |
⚠️ 部分執行 | Bing + ChatGPT browse |
結論:
- 訓練語料抓取(
GPTBot/ClaudeBot/CCBot)幾乎都不執行 JS - 即時引用(
ChatGPT-User/PerplexityBot)部分執行簡單 JS,但複雜的 React / Vue hydration 多半失敗 - 只有 Google 自家爬蟲完整執行 JS(這也是為什麼 SEO 圈過去覺得「JS 不影響搜尋」——只就 Google 而言)
怎麼快速驗證你網站屬於哪種
開終端機,跑:
# 模擬 GPTBot 看到的內容
curl -A "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)" \
-L https://yoursite.com/ | grep -c "你網站某個關鍵內容"
換掉「你網站某個關鍵內容」為一段你期望出現的文字(例:你的服務名稱、客戶見證關鍵字)。
判斷:
- 回
1或更多 → AI 看得到:SSR / SSG / Hybrid - 回
0→ AI 看不到:純 SPA 或被擋 - 回
0但瀏覽器看得到 → 典型 SPA 殼問題
進階驗證(看完整 HTML 大小):
curl -s -A "GPTBot/1.0" https://yoursite.com/ | wc -c
判斷:
- < 5,000 byte 且
<body>接近空 → 純 SPA - 5,000–50,000 byte 含實質內容 → SSR / SSG / Hybrid 之一
-
100,000 byte → 可能 SSR 但有大量 inline JS / CSS(HTML 容量 dim 會扣分)
4 種渲染策略詳解
策略 1:SSG(Static Site Generation)— 引用率最高
代表:Hugo、Astro、Jekyll、11ty、Docusaurus、Next.js export、Gatsby
運作方式:建構時把每一頁預先 render 成 HTML,部署時是純靜態檔案。
對 AI 爬蟲:完美。AI 拿到的就是完整渲染好的 HTML,不需執行任何 JS。
好處:
- 每個 URL 對應一個 .html 檔案
- CDN 快取友善(任何 CDN 都能服務靜態檔)
- 載入速度極快
- 無伺服器運算成本
限制: - 內容更新需要重新建構(部署時間幾分鐘到幾小時) - 不適合動態內容多、即時資料的應用
適合:部落格、行銷網站、文件站、產品介紹站、Landing pages
策略 2:SSR(Server-Side Rendering)— 引用率高
代表:Next.js (getServerSideProps)、Nuxt SSR、Rails + ERB、Django、Laravel + Blade
運作方式:每次 HTTP 請求時伺服器即時 render HTML 回傳。
對 AI 爬蟲:完美。每次請求都是完整 HTML。
好處: - 內容即時、無需建構步驟 - 可依使用者個人化(登入狀態 / 地區 / 語系) - 適合電商、社群、儀表板
限制: - 每次請求都需伺服器運算(有營運成本) - TTFB(Time To First Byte)較慢 - CDN 快取需要更精細設計
適合:電商、會員制應用、頻繁更新的內容站
策略 3:Hybrid(SSR + Client Hydration)— 引用率視實作
代表:Next.js (default)、Nuxt、SvelteKit、Remix、Astro Islands
運作方式: 1. 第一次請求:伺服器 render 完整 HTML(AI 看得到) 2. 後續互動:用戶端 React/Vue/Svelte 接管,JS 渲染剩餘內容
對 AI 爬蟲:取決於關鍵內容是否在初始 HTML
好處: - AI 拿到第一份完整 HTML - 使用者互動體驗等同 SPA - 兼顧 SEO 與 UX
陷阱:
- 如果關鍵內容(產品列表、文章正文、FAQ)是 client-side fetch + render,AI 還是看不到
- Hydration mismatch 可能讓 AI 看到的版本與真人看到的不一致
- M3-18 修的就是這類問題:geoweb.tw 早期 <article id="seo-content"> 預先渲染但 SPA hydrate 時被 empty() 清掉,AI 第二次重訪時看到空殼
適合:絕大多數 modern web 應用,但必須做 SEO 內容檢查(用 curl 驗證關鍵內容在初始 HTML)
策略 4:純 SPA(Single Page Application)— 引用率近 0
代表:Create React App、純 Vite + React、舊 Angular(無 Universal)、純 Vue CLI
運作方式:
1. 第一次請求:伺服器只回傳一個近乎空的 <div id="app"></div> HTML 殼
2. JS bundle 載入後 → fetch API → render 內容
對 AI 爬蟲:致命。AI 拿到的就是空殼,看不到任何內容。
典型 curl 結果:
<!DOCTYPE html>
<html>
<head>
<title>Your Site</title>
</head>
<body>
<div id="root"></div>
<script src="/static/js/main.abc123.js"></script>
</body>
</html>
這就是 AI 看到的全部。沒有產品介紹、沒有部落格內容、沒有任何文字資訊。
為什麼還有人用純 SPA:
- 開發者經驗熟悉、容易上手
- 部署簡單(純靜態檔案 → CDN)
- 早期 React/Vue tutorial 都教這個
- 誤以為 Google 能完全 render JS = 沒問題(實際上 Google 也有限制)
修法:
不能直接「升級到 SSR」(往往要重寫整個架構),但有三條路:
修法 A:用 prerender service
服務(Prerender.io、Rendertron)依 User-Agent 偵測爬蟲,動態 render 後回傳 HTML。
- 優點:不需重寫
- 缺點:付費服務、可能被 AI 廠商視為 cloaking
修法 B:遷移到 Next.js / Nuxt
把現有 React/Vue 程式碼漸進遷移到 SSR 框架。
- 優點:架構長期正確
- 缺點:工程量大(中型專案 1–3 個月)
修法 C:在 SPA 殼內預先渲染關鍵內容
在 index.html 內手動嵌入關鍵 SEO 內容(首頁的服務介紹、FAQ、客戶見證)作為 <noscript> 或預設可見的 <article>,SPA hydrate 後再決定要不要隱藏。
- 優點:最小修改、立即見效
- 缺點:手動維護、可能 desync
- 範例:geoweb.tw 自家就用這招(M3-18),
<article id="seo-content">與<div id="app-root">並列,CSS 控制可見性
一個常見的工程誤判
「Googlebot 都能 render JS 了,AI 應該也可以吧?」
這個推論錯在三個地方:
- Googlebot 的 JS 執行有 timeout(通常 5 秒)。如果你的 hydration 超過 5 秒,內容還是看不到
- 訓練爬蟲(GPTBot / ClaudeBot / CCBot)跟 Googlebot 是不同基礎設施,他們沒拿到 Chrome renderer
- 即時引用爬蟲(ChatGPT-User / PerplexityBot)有 latency budget(使用者等不及),通常只跑簡單 JS
結論:「Googlebot OK」不能推論到 AI 爬蟲 OK。要分開驗證。
量測:你網站每個關鍵頁的「無 JS 可見內容」
跑下面這個 shell 腳本檢查多個頁面:
#!/bin/bash
URLS=(
"https://yoursite.com/"
"https://yoursite.com/products"
"https://yoursite.com/about"
"https://yoursite.com/blog"
"https://yoursite.com/contact"
)
for url in "${URLS[@]}"; do
size=$(curl -s -A "GPTBot/1.0" "$url" | wc -c)
echo "$url → ${size} bytes"
done
健康指標:每頁 ≥ 10,000 bytes 且含實質文字內容。
如果有任何頁 < 5,000 bytes,那一頁對 AI 等於不存在。
一個容易被忽略的策略:llms.txt
無論你用哪種渲染策略,可以建立 /llms.txt 作為純文字 fallback:
# Your Company
Your Company 是 [一句話介紹], 專注於 [服務領域].
## 主要服務
- 服務 A: [簡短描述]
- 服務 B: [簡短描述]
## 聯絡
Email: [email protected]
Website: https://yoursite.com/
這個檔案 AI 爬蟲特別喜歡(已成事實標準),即便你的主站是 JS-heavy SPA,至少 /llms.txt 給 AI 一個可靠的事實源。
詳細規範見前篇:GPTBot / ClaudeBot / PerplexityBot — 8 大 AI 爬蟲規則差異與最佳設定
第一步:用 curl 驗證你網站對 AI 的可見度
跑本文「快速驗證」段的 curl 指令,看你網站對 GPTBot 是 SSR/SSG/Hybrid/純 SPA 哪一種。
如果是純 SPA:你的 GEO 投資 ROI 會接近 0,無論寫多少內容都白做。先解決渲染問題。
👉 跑 GeoWeb 健檢看完整 12 維度評估 — 健檢的「HTML 容量」與「語意結構」維度會反映出 SPA 殼問題。
渲染策略遷移是工程級專案(中型專案 1–3 個月),不適合邊做邊摸。框架選型、漸進遷移計畫、效能基準對比、AI 爬蟲驗證、跨團隊(前端 / 後端 / DevOps / SEO)協調——這些每一項決策錯一次都可能讓網站好幾個月不能服務。GEO 託管包含工程顧問評估,避免企業自己摸坑:[email protected]
GEO 深度系列。前一篇:「整站跨頁一致性 — 為什麼模板雷同會被 AI 降權」
先收藏,明天上班拿這篇curl -a gptbot那段去打臉我們前端 == 我們整站cra做的,難怪寫一堆內容都沒人引用
等等想問一下 表格裡chatgpt-user寫『部分執行簡單js』,那如果我的內容是很單純的fetch一個json再render,這種算不算簡單到它跑得動?還是只要是client fetch一律當看不到比較保險
身為做電商的,看到SSR那段『可依使用者個人化、適合電商』很有感,但我更怕的是品類頁是無限捲動client render,那AI是不是只看得到第一屏的商品而已
這篇給工程師看剛好,但我老闆看不懂curl,文章開頭那句『多數工程師知道但多數老闆不知道』根本講到精隨orz要怎麼讓老闆有感才是真難題
補充一個文章沒提的:就算你ssr了,robots.txt把gptbot claudebot擋掉一樣是0,我們之前就是cdn預設規則把ai bot全block,渲染再好也沒用
prerender.io那條『可能被視為cloaking』看得我一頭霧水,到底是什麼意思啊。我們官網是給架站公司弄的,什麼SSR、SPA我完全分不出來,是不是要打電話去問他們我們家是哪一種
文章說純spa修法c是在index.html手動塞seo-content,但你自己也寫『可能desync、要手動維護』,那這種治標不治本的東西你還推喔?感覺只是拖時間
哈哈你抓到重點了,修法c本來就是先止血不是根治。我自己的排序是:能走b(遷next/nuxt)長期最乾淨,但那是1,3個月的工程;c是給你下週就要有東西被看到、又還沒空重寫的過渡。desync風險我沒藏,所以才寫css控可見性而不是hydrate後empty()清掉——用empty()清掉那種做法我們踩過雷,AI第一次抓到的內容第二次重訪就整個消失,比完全沒做還難查。真要長期穩,還是得處理渲染本身,c只是讓你不要流血流到重寫完那天。
看完整篇有個疑惑,你表格裡Google-Extended和PerplexityBot都標『部分執行』,那我到底該照哪個標準做?做到能被最爛的那個(完全不跑JS的GPTBot)抓到就好嗎
對,抓最低標就對了。你只要做到完全不跑js也看得到關鍵內容,那上面所有部分執行、完整執行的爬蟲自然全部涵蓋。設計目標瞄準gptbot/claudebot這種完全不跑js的,等於把地基墊到最低水位線以下,其他比它強的就不用個別煩惱了。不要反過來賭"反正perplexity會跑一點js",那個latency budget一緊就先放棄你。
想問llms.txt真的值得做嗎?看下面有人說沒哪家明文保證會讀,感覺像在賭
那位讀者的質疑其實蠻合理的,我不會跟你保證"每家一定讀",這部分還在演進。但我自己的看法是:它成本超低(一個純文字檔),就算某些引擎沒讀也沒損失,而不少場景它確實是個乾淨的fallback,尤其你主站是js-heavy spa的時候,至少留一條ai抓得到的事實源。我把它定位成"便宜的保險"而不是"核心解法",核心還是渲染要對。賭注小、下檔有限,我傾向做。前一篇講8大爬蟲規則那篇有寫得細一點,可以接著看。
想請教curl -A GPTBot回的byte數可以信嗎?我另外挑了服務頁測,curl出來8000多bytes看起來過關,但實際內容好像是被一堆inline script灌出來的,文字反而沒幾個字,這樣到底算OK還是不OK?
你的直覺是對的,byte數只是第一關,過了不代表內容真的在。文章後面那條 > 100,000 byte那種就是被inline js/css灌大的典型,html容量那維反而會扣分。你8000 bytes但文字沒幾個字,等於體積有了、實質沒了。建議把grep -c那條也跑一遍,直接搜你最想被引用的那句話(服務名、見證關鍵字)有沒有真的出現在原始html,回0就是殼問題。byte看體型,grep看有沒有肉,兩個要一起看 😅
問個笨問題,文章一直講AI爬蟲不跑JS,那Google搜尋不是也會被AI Overview拿去用嗎?我Google看得到我網站,是不是代表AI也看得到?
同問+1 我也一直搞不懂這個!Google看得到跟AI看得到到底是不是同一件事根本沒人跟我說過。是不是代表我以後如果要接這種案子,光看Google結果來判斷是不夠的?還是說其實差不多,我想太多了QQ 有沒有懂的人可以說白話一點的版本
手上剛好有個做B2B服務的客戶,全站靠一個Vite + React撐,我提遷SSR他們老闆直接說沒預算。除了文章那三條修法,有沒有比較務實一點的順序建議?我這種案子接不少,先講給客戶聽也是我要先想清楚
b2b服務站其實好消息:真正需要被ai看到的就那幾頁(首頁、服務介紹、案例、聯絡),不像電商上萬個sku。我會先幫他做兩件不用動架構的:一是文章最後那個llms.txt,先給ai一份可靠純文字事實源;二是修法c把那幾頁的核心文字預嵌進html。這兩個成本低、這週就能上,也比較好跟老闆交代。遷ssr留到真有預算再說。排序就是llms.txt先上、核心文字預嵌第二,這兩步做完你就能拿去跟老闆交差了,遷ssr不急著這季排。
那個量測多頁的shell腳本我跑了,blog那頁回4xxx bytes但products回6萬多bytes,是不是代表blog有問題products沒事?
先別急著結案。blog 4xxx確實偏低(文章說 <5000對ai約等於不存在),那頁要查;但products 6萬bytes不等於沒事,有可能是商品都client fetch、html裡塞的是一堆骨架/script撐出來的體積。建議兩頁都補grep -c搜真實商品名或文章標題,看那串字到底在不在原始html。byte大只證明檔案大,不證明ai讀得到字。
笑死 標題就是在說我們公司 去年花了一筆做漂亮的React SPA,結果ChatGPT問到我們產業完全找不到我們,原來是空殼QQ
問個蠢問題喔,所以是不是只要框架選對就沒事了?還是說重點根本不是框架本身?我們網站是外包廠商弄的,我也不知道他們是用什麼撈資料的方式,這樣要怎麼自己檢查有沒有中招啊orz
M3-18那個hydrate時被empty() 清掉的故事有點可怕欸,等於AI第一次抓對的、第二次重訪反而看到空的,這種desync用curl一次根本測不出來吧?
純技術文寫得不錯,但結尾那個[email protected] + 12維度健檢,業配味還是飄出來了啦 哈哈 不過內容本身ok我給過
推wc -c那招 我直接拿來掃我們五個關鍵頁,首頁3xxx bytes... 心都涼了
llms.txt那段是不是太樂觀==『ai爬蟲特別喜歡、已成事實標準』這個我持保留,目前還沒看到哪家明文說一定會讀吧,會不會寫了根本沒人理