AI爬蟲不渲染JavaScript——我審計了自己的11個生產站點

來自《期刊》·2026年7月27日

你的網站歡迎AI爬蟲。而我的網站只向它們提供了六個詞。

Google的爬蟲會執行JavaScript。ChatGPT的爬蟲不會。我測量了這一差異對我十一個生產站點造成的代價——其中三個完全不可見。

作者：Maasi J. Smith博士 · 閱讀時間9分鐘 · 釋出於2026年7月27日

關鍵要點

AI爬蟲不執行JavaScript。GPTBot、ClaudeBot和PerplexityBot只讀取你的原始HTML一次然後離開。Googlebot會渲染JavaScript，但它們不會。

因此，一個客戶端渲染的單頁應用對它們來說是不可見的——不是排名差，而是不可見。

我測量了自己的十一個生產站點。其中三個向AI爬蟲提供了不到十個詞。這三個站點的robots.txt檔案都完美無缺，明確邀請這些爬蟲進入。

我透過構建時預渲染修復了這三個站點：詞量從5、6、8詞分別提升到1,442、3,048、3,021詞。渲染器花了一個下午。而阻止它部署出更差東西的防護措施花了更長時間——每一個都捕獲了一個真實的bug。

你可以在大約四秒內檢查任何站點。指令碼如下，我更希望你親自在自己的站點上執行它，而不是相信我的任何話。

兩分鐘版本

我曾以為我有內容問題

上週我讓ChatGPT推薦一個給分居父母使用的、能生成法庭認可溝通記錄的應用程式。我正巧構建了這樣一個產品。它已經上線數月。但ChatGPT沒有推薦它。

我原以為是內容問題：部落格文章不夠多，反向連結不夠多，等等。

實際上是管道問題：我的伺服器向AI爬蟲傳送了一個空房間。

背後的機制

實際發生了什麼

現在網際網路上有兩種爬蟲，它們的行為完全不同。

Googlebot執行一個無頭Chrome。它獲取你的頁面，執行JavaScript，等待框架構建DOM，然後索引結果。這就是為什麼單頁應用在Google中存活了十年。

AI爬蟲——GPTBot、OAI-SearchBot、ClaudeBot、PerplexityBot、CCBot——不會這樣做。它們只傳送一個HTTP請求，解析返回的任何HTML，然後離開。沒有渲染。沒有第二次嘗試。沒有等待。

Google的爬蟲執行JavaScript。ChatGPT的爬蟲不會。這唯一的一個差異決定了AI助手能否推薦你的產品。

這不是猜測。對超過5億次GPTBot獲取的分析發現零個JavaScript執行證據。爬蟲日誌研究顯示GPTBot在大約11.5%的請求中下載JavaScript檔案，ClaudeBot大約23.8%——但兩者從未被觀察到執行它們。它們拉取檔案，但不開啟。

所以，如果你的營銷頁面是一個React或Vue應用，啟動後只有空殼，那麼AI助手關於你公司的全部資訊就是：你的標題標籤和元描述。

就這些。這就是整個語料庫。

審計結果

我在自己站點上發現了什麼

我運營著八個消費者產品、一個B2B平臺、一個Web3市場和一個工作室網站。我寫了一個四行指令碼，指向所有十一個站點，然後去泡咖啡。回來時看到這些資料：

（2026年7月27日使用GPTBot使用者代理測量。指令碼見下文——請驗證我。）

站點服務詞數判定

FamilyCare.Help5不可見

CoParent.Help6不可見

PostPilot.Help8不可見

Inmigrante.Help2,479良好

FamilyCare Facility2,523良好

Nexaria Digital2,276良好

ExamPilot.Help2,212良好

Zari.Help2,178良好

PayLess.Help2,116良好

Smith App Studio2,120良好

ProfilePhoto.Help1,561良好

三個產品。分別只有5、6、8個詞。

最刺痛的部分是：我去檢視這三個站點的robots.txt檔案，期望在那裡找到問題。結果卻看到：

AI助手與答案引擎——明確歡迎以便發現性

User-agent: GPTBot User-agent: OAI-SearchBot User-agent: ChatGPT-User User-agent: ClaudeBot User-agent: PerplexityBot User-agent: Google-Extended User-agent: CCBot Allow: /

完美無缺。這三個站點也都提供了有效的llms.txt。它們都有規範標籤、開放圖譜圖片、Twitter卡片以及JSON-LD結構化資料。

我鋪好了紅地毯，用七種語言列印了歡迎標誌，卻全部指向了一個空房間。

得分良好的八個站點並不是市場做得更好。它們只是構建在伺服器端渲染的框架上。這就是全部區別。兩年產品工作，其可發現性卻歸結於一個下午做出的構建時決策。

為什麼是現在

為什麼今年比去年更重要

在2024年你還可以合理地忽略這一點。但現在不行了，有三個可測量的原因。

第一，排名和引用已經分離。Seer Interactive分析了超過5,000個URL在ChatGPT、Perplexity和AI概覽中的表現，發現Google前十結果與AI引用來源的重疊率從大約70%下降到了不到20%。你的Google排名不再是AI可見性的代理。它們現在是兩個獨立的分銷渠道，具有兩種不同的機制。

第二，AI助手壓倒性地引用品牌自身網站。Yext分析了ChatGPT、Gemini和Perplexity中的680萬次引用，發現86%來自品牌管理的來源。關於你產品的被引用最多的來源本該是你自己。如果你只提供六個詞，你等於預設放棄了這一表面積。

第三，產品發現正在轉移。人們不再搜尋“最佳共同養育應用”然後比較十個藍色連結。他們直接詢問AI助手並接受推薦列表。如果你不在推薦列表中，你就不在考慮範圍內，而且沒有第二頁可待。

llms.txt能做什麼和不能做什麼

我想謹慎地說，因為關於這個有很多自信的廢話。

llms.txt是一個提議的約定：一個位於域名根目錄的純文本檔案，為語言模型總結你的網站。它廉價、靜態、由伺服器提供，我認為你應該有一個。

但它不是這個問題的解決方案。它是一個採用率參差不齊的自願約定，它不取代任何爬蟲索引中的實際頁面，而且——這是重要的一點——我的站點中已經有了。所有三個不可見站點都提供了完美的llms.txt，但它沒有拯救它們，因為一個110詞的摘要不能替代一個網站。

把llms.txt當作名片。有用。但不是一棟建築。

自己動手

在四秒內檢查你的站點

以下是指令碼。它以GPTBot的身份獲取URL，剝離指令碼、樣式、註釋和標籤，並計算實際剩下的內容——即爬蟲實際讀取的內容。

（指令碼內容略）

執行它：

chmod +x ai-visibility.sh ./ai-visibility.sh https://yoursite.com/ https://yoursite.com/pricing

解讀結果。這些閾值是判斷性而非標準化的——但在我測試的所有站點中都適用：

詞數含義

200以下客戶端渲染。AI助手只知道你的標題標籤，其他一無所知。

200–600部分。可能是混合應用，或懶載入真實內容的頁面。

600以上伺服器端渲染。爬蟲正在獲取你的實際論點。

兩個誠實的提醒。第一，詞數是內容的代理，而非衡量標準——2000詞導航連結和法律模板並非2000詞價值。第二，perl隨macOS和Linux一起提供；在Windows上使用Git Bash或WSL。

修復方法

如何修復

按努力程度排序。從頂部開始，直到你的數字改善。

預渲染你的營銷路由。對於Vite或CRA應用，這通常是一個半天內的改動，是最高槓杆的修復。一個構建後步驟在無頭瀏覽器中爬取你的路由，並將真實HTML檔案寫入磁碟。你的應用繼續保持現有工作方式；伺服器只是在JavaScript啟動前有了可提供的內容。

將營銷站點遷移至伺服器端渲染框架。Next.js、Astro、Remix、Nuxt。如果你正在重建，這是持久的答案。注意，你只需要對公開頁面這樣做——登入後的所有頁面可以永遠保持客戶端渲染，因為任何爬蟲都不應看到它們。

將營銷站點從應用中分離。被低估了。在yourdomain.com上的靜態站點和app.yourdomain.com上的應用，提供了完美的可爬取性和更快的營銷站點，並消除了整個類別的路由問題。

不要使用動態渲染。根據使用者代理向機器人和人類提供不同HTML曾是標準建議。但它脆弱，存在偽裝風險，而預渲染解決了同樣的問題，無需任何人信任你的使用者代理檢測。

然後做那些廉價的事情。向必應網站管理員工具提交每個站點地圖——ChatGPT的搜尋依賴於Bing的索引，這是二十分鐘的工作，幾乎沒人做。新增Article和FAQPage架構。放置一個真正的llms.txt。將你的標題寫成問題，並在第一句回答，因為這是AI系統實際提取的單位。

結果

我做了什麼

我為所有三個站點構建了預渲染器。以下是差異：

站點之前之後

FamilyCare.Help51,442

CoParent.Help63,048

PostPilot.Help83,021

大約270個頁面現在提供了真實的HTML。沒有一個低於200詞閾值。

有三件我未預料到的事，而它們正是真正的教訓：

天真的版本悄無聲息地讓事情變得更糟

我的第一個可用版本寫了54個頁面，但這些頁面都帶有首頁的標題，因為我為每個路由的後設資料應用等待了固定的500ms，而在四個併發無頭標籤下，有時後設資料尚未應用。五十四個URL共享一個標題就是重複內容。我僅在對比了標題後才捕獲到它。

預渲染憑空創造了一個規範標籤錯誤

HTML外殼硬編碼了rel="canonical" href="/"。當爬蟲只獲取一個檔案時無害。但一旦每個路由都是自己的檔案，每個頁面就會攜帶兩個規範標籤——一個真實指向自身，一個堅持它是首頁。這比沒有預渲染更糟糕，而且我們的一個部落格之前已經因完全相同的錯誤被去索引。

構建發現了一個沒人注意到的損壞頁面

PostPilot的/platforms頁面從未設定自己的標題、描述或規範標籤——它一直提供通用首頁後設資料。其他所有公開頁面都有。沒什麼曾暴露這個問題，因為在單頁應用中，除非你刻意去查詢，否則看不到差別。

所以誠實的總結是：預渲染是容易的部分。防護措施才是工作。如果你這樣做，在編寫渲染器之前先編寫那些能使構建失敗的檢查——我的每一個檢查都捕獲了真實問題。

前兩個生產部署也直接失敗了，因為構建映象沒有Chrome，後來又沒有執行Chrome所需的系統庫。兩個失敗都沒有影響到任何人：指令碼在任何問題時都會以非零退出，所以之前的正常工作部署保持了活躍。這就是構建時防護措施應嚴格失敗而非發出警告的理由。

常見問題

AI爬蟲執行JavaScript嗎？

不。GPTBot、ClaudeBot和PerplexityBot獲取原始HTML，不執行JavaScript。對超過5億次GPTBot獲取的分析沒有發現JavaScript執行的證據。Googlebot是例外——它使用無頭Chrome引擎渲染JavaScript。

ChatGPT能看到我的React網站嗎？

只有當網站內容在伺服器端渲染或預渲染後才可見。否則，ChatGPT只會看到你的標題標籤和元描述。

（由於AI成本控制，原文被截斷。）