JavaScript SEO：Google 看得到你 JS 載入的內容嗎

有一種狀況，做過官網的人大概都遇過：用瀏覽器打開自家網站，產品清單、規格表、價格、服務說明，通通好端端地在那裡。但 Google 搜尋公司名稱加上產品型號，什麼都搜不到；Search Console 裡那一頁要嘛「已檢索，但目前尚未建立索引」，要嘛收錄了，標題卻是一片空白。

這時候如果在頁面上按右鍵選「檢視網頁原始碼」，往往就會看到答案：整份原始碼裡找不到你剛剛明明看到的那段文字，只有幾個空的 <div>，和一長串 <script>。內容不是寫在 HTML 裡，是網頁載入之後，由 JavaScript 跑出來的。

這件事本身不是錯誤，現在幾乎所有網站多少都這樣做。問題在於：人看得到，不等於搜尋引擎抓得到。這篇就把「JS 產生的內容到底會不會被收錄」講清楚，並給一套不用找工程師、十分鐘就能自己驗的檢查方法。

Photo by Etienne Girardet on Unsplash

一、Google 其實是分三步在處理你的網頁

多數人以為搜尋引擎就是「來抓一抓、然後收進去」，實際上 Google 在官方文件裡講的是三個分開的階段：檢索（crawling）、算圖（rendering）、建立索引（indexing）。

第一步檢索，是 Googlebot 來要一份 HTML。它會先看 robots.txt 允不允許，然後把拿到的 HTML 裡的 href 連結挑出來，排進下一輪的待抓清單。這一步拿到的，就是你按右鍵看到的那份原始碼——不包含 JS 跑完之後的結果。

第二步算圖，才是真正執行 JavaScript 的地方。回應狀態是 200 的頁面會被排進一個「算圖佇列」，等輪到它的時候，Google 用一套常保最新版本的無頭 Chromium 把頁面跑一遍，JS 執行完，再從跑完的結果裡重新找一次內容和連結。Google 自己的說法是，這個等待「可能幾秒鐘，也可能更久」，而且從外面看不出某一頁現在排在哪個佇列裡。

第三步才是把算完的結果拿去建立索引。

三件事值得記下來。其一，JS 產生的內容確實有機會被收錄，Google 不是看不懂 JavaScript，網路上「用 JS 就不會被收錄」的說法已經過時了。其二，這條路比較長、也比較容易中斷：腳本掛掉、第三方 API 逾時、檔案被擋住，任何一個環節出事，Google 看到的就是一頁空白。其三，非 200 的頁面可能根本不會被算圖；同樣地，如果原始 HTML 裡已經寫了 noindex，Google 可能直接跳過算圖，這表示「先寫 noindex、之後再用 JS 把它拿掉」這種做法通常不會成功。

二、十分鐘自己驗：你的內容在哪一層

不需要任何付費工具，四個動作就能判斷。

第一招，檢視原始碼找字。打開要檢查的頁面，按 Ctrl+U（Mac 是 Cmd+Option+U）叫出原始碼，再按 Ctrl+F，貼上頁面上一段獨特的內文——例如產品的完整型號、或某段服務說明的一句話。找得到，代表這段內容寫在 HTML 裡，最穩。找不到，就是 JS 產生的，要繼續往下驗。

第二招，把 JavaScript 關掉看一次。Chrome 開發者工具按 F12，用 Ctrl+Shift+P 叫出指令列，輸入 Disable JavaScript，然後重新整理。這時候畫面剩下什麼，大致就是「不會執行 JS 的程式」眼中的你的網站。如果整頁只剩一個轉圈圈的載入動畫，那就是一個明確的警訊。

第三招，用 Search Console 的網址審查。這是最接近事實的一招。貼上網址，點「測試線上網址」，再展開「檢視已檢索的網頁」裡的 HTML 分頁。那份 HTML 就是 Google 算完圖之後看到的版本。一樣用搜尋功能找你那段內文，找不到，就是 Google 真的沒看到。右側的「網頁資源」還會列出哪些檔案載入失敗，常常答案就在那裡。

第四招，用精確比對搜尋。在 Google 搜尋框輸入 site:你的網域 "一段完整的句子"，加上引號。有結果，代表那段文字真的進了索引。

Photo by Joachim Schnürle on Unsplash

三、最常見的六個踩雷點

驗出問題之後，九成會落在下面幾項裡。

一、內容要點一下才出現。規格、常見問答、評價、尺寸表被收在分頁標籤或「看更多」按鈕底下，使用者點了才載入。Google 在官方文件裡講得很直接：搜尋不會和你的頁面互動。沒人點，那段內容就不存在。正確做法是內容本來就在頁面上，只是用 CSS 收合，點擊只負責展開。

二、無限捲動沒有對應網址。商品列表滑到底自動載入下一批，看起來很順，但 Google 不會捲動。Google 的建議是：同時支援分頁式載入，讓每一批內容都有自己固定、唯一的網址（例如 ?page=12 這種絕對頁碼，而不是 ?date=yesterday 這種會變動的參數），並且用真正的連結把各頁串起來。

三、用井字號當網址。像 example.com/#/products/123 這種寫法，井字號後面的部分在規格上屬於「頁面內的片段」，不是獨立網址。整站可能只被當成一頁。改用 History API，讓每個頁面都有乾淨、各自獨立的網址。

四、把重要標籤交給 JS 去塞。canonical、noindex、標題與描述，能寫在原始 HTML 就寫在裡面。用 JS 動態插入的風險是：不一定來得及執行，而且很容易出現原始 HTML 一個值、JS 又塞一個值，兩邊互相打架。

五、前端的「找不到商品」其實回 200。單頁式網站常見的問題：網址隨便打都回 200，然後畫面上顯示「查無此商品」。對搜尋引擎而言，這是一堆內容重複又沒價值的頁面，也就是所謂的軟性 404。處理方式是讓它真的回傳 404，或至少在錯誤頁面上加上 noindex。

六、在 robots.txt 把自己的腳本擋掉。有些網站為了「省檢索資源」，把 /js/、/assets/ 整個 disallow 掉。Google 要不到這些檔案，就算不出完整的頁面。該擋的是後台和搜尋結果頁，不是渲染頁面要用的資源。

四、三種修法，成本由低到高

確認問題之後，不一定要打掉重做。

最低成本：把該被搜尋到的東西寫回 HTML。不是整站改架構，而是挑出真正需要被搜到的欄位——頁面標題、產品名稱與型號、主要說明文字、分類與商品的連結——讓它們直接出現在伺服器吐出來的那份 HTML 裡。連結尤其重要：要用真正的 <a href="/路徑">，不要用 <div onclick> 之類的寫法，否則 Googlebot 在第一步就找不到路往下走。很多情況下這一步就解決了八成問題。

中成本：預先渲染或靜態輸出。內容不常變動的頁面——服務介紹、文章、案例、型錄——可以在發布時就先產生好靜態 HTML，之後交給瀏覽器的是成品，不是半成品。對內容型網站來說，這通常是投資報酬率最高的一種。

高成本：伺服器端渲染。每次請求都在伺服器先把頁面組好再送出。效果最完整，但牽涉到架構與主機成本，比較適合商品數量大、資料即時性高的網站，或是在改版時一併評估。

Photo by Declan Sun on Unsplash

五、AI 爬蟲讓這件事變得更要緊

過去幾年，「Google 會算圖」讓很多人覺得這個問題沒那麼嚴重。現在多了一個變數：越來越多流量與曝光，來自 AI 聊天工具與 AI 搜尋的引用，而這些爬蟲的行為跟 Googlebot 並不一樣。

Vercel 在 2024 年底公布過一份跨網站的爬蟲流量分析，結論是當時主要的 AI 爬蟲——包括 OpenAI 的 GPTBot、Anthropic 的 ClaudeBot、Perplexity 的爬蟲——都不執行 JavaScript。報告裡有個細節很說明問題：這些爬蟲其實會去下載 JS 檔案（ChatGPT 的請求裡約一成一，Claude 約兩成四），但下載了並不執行，所以用戶端才產生的內容，它們一樣讀不到。相對地，Google 體系與 Apple 的爬蟲是會算圖的。

這份數據有時間與範圍的限制，各家爬蟲的能力也可能隨時調整，不適合當成永久定律。但方向是清楚的：只有寫在原始 HTML 裡的內容，才是對所有程式都成立的版本。同一份工，做一次，Google、AI 爬蟲、分享到 LINE 時的預覽卡片，一起受益。

六、也不是每一頁都要這樣處理

最後補一個常被忽略的分寸問題。會員中心、購物車、訂單查詢、後台報表、互動式地圖與試算工具，本來就不需要被搜尋引擎收錄，用 JS 全權處理完全合理，有些還應該主動加上 noindex。

真正要盯的，是那些你希望陌生人透過搜尋找到的頁面：首頁、服務與產品頁、分類頁、文章頁、據點頁。把網站的頁面分成「要被搜尋到」和「不用被搜尋到」兩堆，力氣只花在前面那一堆，是比較務實的做法。

結語：這週可以做的三件事

如果看完想立刻動手，建議從這三步開始。

第一，挑出官網最重要的五頁——首頁、主力產品或服務頁、分類頁、一篇文章、聯絡或據點頁——每頁用「檢視原始碼找字」驗一次，把結果記在同一張表上。第二，對沒通過的頁面，再用 Search Console 的網址審查看一次算圖後的 HTML，確認是真的沒進去，順便看看有沒有資源載入失敗。第三，拿著這張表去找負責維護網站的人或廠商，問題會具體很多：不是「我們 SEO 好像有問題」，而是「這三頁的產品名稱沒有出現在伺服器回傳的 HTML 裡，能不能改成輸出在原始碼」。

搜尋引擎並沒有要為難用 JavaScript 的網站。它只是誠實地告訴你：它看到的版本，跟你在瀏覽器裡看到的，不一定是同一份。先弄清楚這兩份差在哪，後面的事情才有得談。