一、網站內容靠 JavaScript 呈現,AI 爬蟲看得到嗎?
Googlebot 能執行 JavaScript,不代表所有爬蟲都可以
若只討論 Google 搜尋,JavaScript 內容並非一定無法被讀取。Google 官方說明,Googlebot 取得網址後會先分析伺服器回傳的 HTML,再把符合條件的頁面排入渲染佇列;資源允許時,系統會以無頭版 Chromium 執行 JavaScript,並使用渲染後的 HTML 建立索引。
不過,這個流程包含等待與再次處理。Google 也指出,頁面可能在渲染佇列中停留數秒或更久;若 JavaScript 檔案、頁面或必要資源被 robots.txt、權限或技術錯誤阻擋,Google 就可能無法取得預期內容。因此,「Googlebot 有渲染能力」不是每次執行都一定成功的保證。
資料來源:Google:Understand the JavaScript SEO basics;Google 官方文件;Googlebot 會將頁面排入渲染佇列並執行 JavaScript,但仍受存取、狀態碼與資源可用性影響
下表依 Google 官方文件重新整理。閱讀時要注意,這是 Google 搜尋的處理流程,不代表其他 AI 爬蟲採用相同架構或具備相同能力。
圖表 1 Googlebot 處理 JavaScript 頁面的三個階段
| 階段 | Google 官方說明 | 企業需要確認 |
|---|---|---|
| 抓取 | 先取得網址回傳的 HTML,檢查 robots.txt、狀態碼與可存取性 | 伺服器是否回傳 200,重要資源是否可存取 |
| 渲染 | 頁面進入渲染佇列,由 Chromium 執行 JavaScript | 內容是否因錯誤、逾時、登入或權限而未出現 |
| 建立索引 | Google 使用渲染後的 HTML 分析內容與連結 | 重要文字、標題與連結是否存在於渲染結果 |
資料來源:Google JavaScript SEO 文件;官方流程;不包含其他 AI 平台。圖表為奇寶依原文重新整理
Google AIO 與其他 AI 搜尋工具需要分開判讀
Google 官方表示,頁面若要成為 AI 摘要或 AI Mode 的支援連結,必須先被 Google 搜尋建立索引,並符合在搜尋結果顯示摘要的資格;沒有額外的 AIO 專用技術條件。對 Google AIO 而言,JavaScript 風險仍應放在 Google 搜尋既有的抓取、渲染與索引流程中判斷。
資料來源:Google:AI features and your website;Google 官方文件;AIO 與 AI Mode 的支援連結需符合 Google 搜尋收錄及摘要資格,沒有額外技術要求
其他 AI 服務可能使用自己的自動爬蟲、搜尋合作夥伴索引,或在使用者提出問題時即時讀取網址。以 OpenAI 為例,官方將 OAI-SearchBot、GPTBot 與 ChatGPT-User 分成不同用途;允許其中一種,不代表另外兩種會以相同方式處理內容。官方文件也沒有承諾這些工具會像 Googlebot 一樣執行網站的 JavaScript。
資料來源:OpenAI:Overview of OpenAI Crawlers;OpenAI 官方文件;區分搜尋、模型訓練與使用者觸發的不同自動化程式,未宣稱具有與 Googlebot 相同的 JavaScript 渲染流程
二、看到頁面,為什麼不等於讀到內容?
原始 HTML 與渲染後畫面的差異
伺服器收到網址請求時,會先回傳一份 HTML。若產品名稱、服務說明、價格、文章正文與主要連結已經包含在這份回應中,即使 JavaScript 沒有執行,爬蟲通常仍能讀到核心資訊。這類做法常見於伺服器端渲染、靜態產生頁面,或在初始 HTML 中保留主要內容的混合架構。
相反地,有些用戶端渲染網站只回傳頁面外框與 JavaScript 檔案,必須等瀏覽器下載程式、呼叫 API,再把內容加入畫面。使用者可能只感受到短暫載入,但不執行 JavaScript 的爬蟲收到的仍可能是空殼。若頁面正文、內部連結或規格表都在這一步才出現,可讀性風險就會提高。
抓取、渲染與即時讀取是不同環節
一個 AI 回答能引用某個網站,不一定代表該服務當下直接讀取了完整網頁。平台可能先從 Google、Bing 或自己的索引找到內容,再以其他方式補充最新資訊。因此,網站曾被傳統搜尋建立索引,與 AI 爬蟲此刻能否直接讀取 JavaScript,是兩個不同問題。
這也解釋了為什麼同一網址有時能被 AI 回答引用,有時卻無法取得最新內容:平台可能使用既有索引、摘要或其他來源,而不是每次都完整執行頁面。企業不能只用聊天介面中的一次回答,反推爬蟲具備何種技術能力。
三、Profound 的伺服器紀錄研究發現什麼?
研究方法與主要觀察
Profound 於 2025 年 1 月發布第三方研究,分析 2024 年 12 月多個高流量網站的原始伺服器紀錄。研究不是依賴 GA4 等前端工具,而是從伺服器收到的請求辨識不同 AI 爬蟲,藉此觀察它們是否要求 JavaScript 資源,以及能否取得只在用戶端產生的內容。
研究提出三層流程:AI 服務可能先依賴傳統搜尋索引發現內容,再以直接爬取補充最新頁面,最後從取得的資料中選擇回答來源。Profound 觀察到,部分即時抓取程式不執行 JavaScript,因此只存在於渲染後畫面的內容,可能無法在即時讀取階段被取得。
資料來源:Profound:What we discovered about AI crawlers via server log analysis;第三方研究;觀察期間為 2024 年 12 月,2025 年 1 月 23 日發布,依多個高流量網站的伺服器紀錄分析
這張表先界定研究可以支持的結論。它能提醒企業注意用戶端渲染風險,但不能證明每一個 AI 平台在所有時間都無法執行 JavaScript。
圖表 2 Profound 研究的證據範圍與限制
| 項目 | 公開內容 | 判讀限制 |
|---|---|---|
| 資料來源 | 多個高流量網站的原始伺服器紀錄 | 未公開網站清單、產業分布與各網站請求占比 |
| 觀察期間 | 2024 年 12 月 | 平台能力可能更新,不能直接視為永久規則 |
| 觀察重點 | 不同 AI 爬蟲的請求與 JavaScript 處理差異 | 公開文章未提供逐一平台的完整原始紀錄與重複驗證 |
| 可支持結論 | 核心內容只在用戶端出現,可能增加部分爬蟲無法讀取的風險 | 不能推論所有 AI 平台、所有功能與所有網址都會失敗 |
資料來源:Profound 伺服器紀錄研究;第三方研究;公開頁面對處理量分別使用「數百萬」與「數十億」請求描述,且未提供完整原始資料,本文不引用請求總量
研究限制與不能直接推論的事項
Profound 的研究具有實務價值,因為伺服器紀錄能看見不會執行前端追蹤程式的自動請求;但公開文章沒有列出完整網站清單、各爬蟲樣本量、辨識誤差、測試頁面或可重複的原始紀錄。研究頁面也以不同量級描述處理的請求數,因此本文不採用請求總量作為證據。
此外,研究觀察的是 2024 年 12 月的狀態。AI 平台可能調整爬蟲、改用搜尋合作夥伴,或在特定使用者任務中啟用瀏覽工具。因此,合理結論是「重要內容只靠用戶端 JavaScript 會增加跨平台風險」,而不是「所有 LLM 永遠看不到 JavaScript」。
Search Engine Land 後續以這項研究說明迷思五,但文中另舉 ChatGPT 回答某篇文章的對話,屬作者個案,不是受控研究。個案可以提醒讀者:AI 回答出內容,仍可能是透過其他可讀來源取得;不能用它證明特定爬蟲實際渲染了原頁面。
資料來源:Search Engine Land:7 AI search myths, debunked;產業媒體解讀與作者個案;2026 年 9 月 28 日發布,個案不能視為平台能力測試
四、企業應先確認的 4 個技術判斷
判斷一:核心資訊是否存在於原始 HTML?
第一個問題不是網站有沒有使用 JavaScript,而是核心資訊是否必須執行 JavaScript 才出現。互動效果、篩選器與表單可以仰賴 JavaScript;但服務名稱、主要說明、重要規格、文章正文、價格條件與主要內部連結,若能存在於初始 HTML,跨平台可讀性通常更穩定。
企業不需要把每個互動元件改成靜態內容。奇寶會先找出會影響搜尋需求與顧客決策的資訊,檢查原始 HTML 與渲染後畫面是否一致,再判斷是否需要調整架構。
判斷二:目標平台使用哪一種爬蟲與資料來源?
Google AIO 依賴 Google 搜尋的收錄與摘要資格,因此應先用 Google 的 JavaScript SEO 流程檢查。ChatGPT Search、Claude 或其他服務則可能使用不同爬蟲、搜尋合作夥伴與使用者觸發工具。平台名稱相同,也可能存在不同用途的自動程式。
以 OpenAI 官方資料為例,OAI-SearchBot 用於 ChatGPT 搜尋,GPTBot 用於可能的模型訓練,ChatGPT-User 則可能在使用者要求下造訪網頁。三者的用途與 robots.txt 行為並不相同,因此只看到某個 User-Agent 出現在紀錄中,不能直接推論網站已具備完整的 ChatGPT 搜尋能見度。
資料來源:OpenAI:Overview of OpenAI Crawlers;OpenAI 官方文件;各自動程式用途不同,允許抓取也不保證內容一定被顯示或引用
判斷三:內容是否仰賴即時抓取才能保持正確?
若頁面內容長期穩定,平台從既有搜尋索引取得資訊,可能仍能找到主要內容;但庫存、價格、活動時間、產品狀態與即時規格若頻繁更新,直接抓取能否取得最新資訊就更重要。只在 JavaScript 執行後更新的內容,可能讓未執行程式的爬蟲讀到空白、舊資料或不完整版本。
這不代表把所有即時資料寫死在 HTML,而是要讓關鍵狀態有可被機器理解的伺服器回應或降級內容,並避免錯誤資訊在缺少 JavaScript 時仍被呈現。
判斷四:伺服器紀錄與實際回應能否互相驗證?
聊天介面的回答只能顯示最後結果,不能完整揭露資料取得路徑。較可靠的檢查需要交叉查看:伺服器對特定網址回傳什麼、原始 HTML 是否包含核心資訊、Google 渲染後看見什麼、AI 爬蟲是否實際造訪,以及造訪時收到哪一種狀態碼與內容。
若只依賴前端分析工具,未執行 JavaScript 的爬蟲可能完全不會留下工作階段。Profound 研究的價值正是在於使用伺服器紀錄補足這個缺口;不過 User-Agent 可以被模仿,因此正式判讀仍需搭配官方 IP 範圍、平台說明與網站安全紀錄。
五、CSR、SSR 與靜態頁面該怎麼選?
不同呈現方式的可讀性差異
網站架構不必只為爬蟲設計。選擇呈現方式時,仍需考量互動需求、更新頻率、維護成本與頁面效能。下表的「可讀性風險」是依內容是否出現在初始 HTML 所做的技術判讀,不是 Google 或任何 AI 平台公布的排名規則。
閱讀這張表時,先看「核心內容何時出現」,再看目標爬蟲是否必須執行 JavaScript。相同技術名稱仍可能因實作方式不同而有不同結果。
圖表 3 常見網頁呈現方式與 AI 爬蟲風險
| 呈現方式 | 核心內容何時出現 | 跨平台風險 | 適合的改善方向 |
|---|---|---|---|
| 靜態產生 | 建立頁面時已寫入 HTML | 較低 | 維持內容更新與正確狀態碼 |
| 伺服器端渲染 SSR | 每次請求時由伺服器回傳完整 HTML | 較低 | 確認快取、權限與錯誤頁回應 |
| 混合渲染/Hydration | 主要內容先在 HTML,互動由 JavaScript 接手 | 通常較低 | 確保接手前後內容一致 |
| 用戶端渲染 CSR | 瀏覽器執行 JavaScript、呼叫 API 後才出現 | 較高 | 讓核心資訊可由伺服器回傳,並提供可讀的降級內容 |
資料來源:Google JavaScript SEO 與動態渲染文件;Google 官方建議優先採用伺服器端渲染、靜態渲染或 hydration;表中跨平台風險為奇寶合理判讀,不是排名因子
不建議把動態渲染當成長期方案
動態渲染會依訪客是否為爬蟲,回傳不同版本的頁面。Google 官方將它定位為過渡性的替代作法,不建議當成長期方案,因為它增加維護與資源成本,也容易讓爬蟲版本與使用者版本不一致。Google 建議優先考慮伺服器端渲染、靜態渲染或 hydration。
資料來源:Google:Dynamic rendering as a workaround;Google 官方文件;動態渲染是替代作法,不是建議的長期方案
對企業而言,最實際的原則不是「拿掉 JavaScript」,而是讓重要資訊不必依賴某一種爬蟲的特殊能力才能被取得。互動功能仍可保留,但高商業價值內容應有穩定、可驗證的伺服器回應。
六、奇寶如何安排檢查與改善順序?
先檢查高商業價值頁面的核心資訊
奇寶在專案中不會要求企業全面改寫網站架構,而是先從服務頁、產品頁、價格頁、比較頁、重要文章與轉換頁開始,確認核心資訊在不同讀取環境下是否一致。若只有互動效果依賴 JavaScript,風險通常較低;若標題、正文、規格與主要連結都在執行後才出現,則優先處理。
這份流程是奇寶依官方文件與第三方研究整理的專案判讀方式。它用來找出技術風險,不代表完成檢查後就一定能獲得 AIO 或其他 AI 平台露出。
圖表 4 JavaScript 內容可讀性的四步檢查流程
| 步驟 | 檢查內容 | 發現落差時的判讀 |
|---|---|---|
| 1 原始回應 | 檢視伺服器回傳的 HTML、狀態碼與主要內容 | 核心資訊缺少,代表頁面依賴後續執行 |
| 2 渲染結果 | 比較瀏覽器畫面、Google 渲染內容與主要連結 | 版本不同,需找出被阻擋或執行失敗的資源 |
| 3 爬蟲存取 | 核對 robots.txt、CDN、WAF、登入與官方爬蟲識別 | 可進入不等於可讀完整內容,仍需確認實際回應 |
| 4 伺服器紀錄 | 查看特定爬蟲造訪、狀態碼、網址與時間 | 建立是否實際抓取的證據,避免只看聊天介面推論 |
資料來源:本表由奇寶依 Google、OpenAI 官方文件與 Profound 研究整理;屬技術檢查流程,不是 Google 官方演算法、AI 平台引用規則或成效保證
依證據修正,不把技術資格寫成露出保證
若檢查確認高價值內容只在用戶端出現,奇寶會依頁面角色與開發成本評估靜態產生、伺服器端渲染、混合渲染或降級內容,而不是直接指定所有頁面採用同一種技術。改善後再比對原始 HTML、渲染結果與伺服器紀錄,確認爬蟲實際收到的內容已改變。
技術可讀性只處理「是否有機會被取得」,不能證明平台一定選用、引用或推薦內容。Google 官方也明確提醒,即使頁面符合技術條件與最佳做法,抓取、建立索引及顯示仍不保證發生。因此,奇寶會把技術修正與內容價值、搜尋需求及品牌可信度一起判讀。
資料來源:Google:AI features and your website;Google 官方文件;符合技術與內容條件不等於保證被抓取、建立索引或顯示
七、結論:重要內容不應只存在於瀏覽器畫面
網站使用 JavaScript,不代表 AI 爬蟲一定看不到內容。Googlebot 會以 Chromium 執行 JavaScript,Google AIO 也延續 Google 搜尋既有的收錄與摘要資格;但 Google 同時提醒,並非所有自動程式都能執行 JavaScript。把 Googlebot 的能力套用到每一個 AI 平台,是這個迷思最主要的問題。
Profound 的伺服器紀錄研究顯示,部分 AI 爬蟲在即時抓取時不執行 JavaScript,核心內容若只存在於用戶端渲染後的畫面,可能增加無法被取得的風險。不過,該研究觀察的是 2024 年 12 月,且未公開完整網站清單、平台樣本與原始紀錄,因此不能把結果寫成所有 AI 服務永久適用的規則。
企業真正需要確認的不是「網站有沒有 JavaScript」,而是:核心資訊是否存在於原始 HTML、目標平台使用哪一種資料來源、內容是否需要即時抓取,以及伺服器紀錄能否證明實際存取。奇寶會先檢查高商業價值頁面,再依證據安排 SSR、靜態產生、混合渲染或降級內容,讓重要資訊不必依賴單一爬蟲的特殊能力才能被理解。
參考資料
1. Google:Understand the JavaScript SEO basics
2. Google:AI features and your website
3. Google:Dynamic rendering as a workaround
4. Google:Generative AI optimization guide
5. OpenAI:Overview of OpenAI Crawlers
6. Profound:What we discovered about AI crawlers via server log analysis
7. Search Engine Land:7 AI search myths, debunked
還想了解更多各類數位行銷資訊的話,歡迎訂閱電子報、加入奇寶 Line 好友,第一時間接收最新資訊!
歡迎轉載 KPN 奇寶部落格相關文章,在轉載前請先詳閱著作權聲明及轉載原則。
