Google 會跑 JavaScript 不等於會收錄：四個前端渲染誤解與驗證法
Google 能處理 JavaScript，但頁面上由它產生的內容不一定都會被收錄。要點擊才載入、資源被擋、載入後才改寫標籤的內容，都可能不在索引裡。確認方法是用 Search Console 網址檢查看轉譯後的 HTML，再用指令抽查。
開場：一場週會上的對話
下面這段對話是示範情境，不是特定公司的實際紀錄。但類似的對話，我在中小企業的週會上聽過很多次。
行銷主管說：「新的商品頁上線一個月了，規格表那段文字，在 Google 上怎麼搜都搜不到。」
工程師說：「不可能。Google 早就看得懂 JavaScript 了，我們的網站用的是主流框架，畫面也都正常。」
老闆看向我：「所以到底是誰對？」
我的答案通常是：兩個人講的都是事實，但都只講了一半。工程師說的「Google 看得懂」是能力；行銷看到的「搜不到」是結果。中間隔著好幾個環節。這篇我想反駁四個常聽到的說法，再整理一套不用寫程式也能做的驗證方法。
誤解一：「Google 會執行 JavaScript，所以不用管」
我不同意。能執行，和「你希望它看到的那段內容剛好在它執行時出現」，是兩件事。
在示範情境裡，商品規格表放在一個「規格」分頁裡。使用者點了分頁，前端程式才去伺服器抓資料，再把表格畫出來。人看得到，因為人會點。爬蟲在網址檢查的畫面裡呈現的，是頁面載入完成後的狀態，沒有人替它點那個分頁。
類似的情況還有這幾種：
- 捲到頁面底部才載入的評論或相關商品
- 要先選尺寸或顏色，價格與庫存才出現
- 依訪客所在地區或登入狀態，才決定顯示哪一段內容
- 用按鈕的點擊事件換頁，而不是用一般的連結網址
第四種情況還會影響內部連結。導覽和分頁如果不是一般的連結元素，而是靠點擊事件切換，爬蟲可能根本發現不了後面的頁面。這和渲染方式有關，各種渲染方式的差異可以參考JavaScript 網站五種渲染方式的實測差異。
誤解二：「瀏覽器看得到，Google 就看得到」
瀏覽器和爬蟲的權限不一樣。你的瀏覽器可以載入所有檔案，爬蟲要先遵守 robots.txt。
我看過的示範情境是這樣：網站的 robots.txt 為了擋掉後台，把整個 API 路徑都封鎖了。結果前端程式要去 API 抓商品資料時，爬蟲被擋在門外。畫面在瀏覽器上完全正常，在網址檢查裡卻是一片空白的規格區。
Google 的入門指南也提醒，要確認 Google 能存取網頁所需的資源，並用網址檢查工具看 Google 眼中的頁面長什麼樣子，可以對照Google 搜尋引擎最佳化入門指南。robots.txt 寫錯會造成哪些後果，可以參考robots.txt 寫錯的六種後果。
誤解三：「網址檢查說網址在 Google 上，就沒問題了」
這是我最常需要反駁的一句。網址檢查告訴你的是「這個網址在不在索引裡」，不是「頁面上每一段內容都被收進去了」。
一個網址可以被收錄，但只收錄了伺服器第一次送出的那層內容：標題、導覽、頁尾，加上一段簡短介紹。真正有價值的規格、價格、問答，因為是後來才由程式補上的，不一定在裡面。
還有一個反方向的狀況：頁面根本沒被收錄，報表顯示的是「已檢索，但尚未建立索引」。這時候問題不一定在 JavaScript，也可能是內容品質或重複。判斷方式可以參考頁面索引報表的五種狀態判斷表，不要一看到沒收錄就怪渲染。
誤解四：「改成伺服器端渲染，就一勞永逸」
伺服器端渲染確實能降低風險，因為主要內容在第一次回應時就已經在 HTML 裡。但我不同意「一勞永逸」。上線後我最常檢查到的問題有三種：
- 標籤被改寫：伺服器送出的標題、描述或標準網址是對的，前端程式載入後又把它改成另一個值
- 結構化資料不同步：伺服器輸出一份，前端又插入一份，兩份的價格或庫存不一致
- 內容不一致：伺服器版本和使用者實際看到的畫面不同，例如伺服器版本少了某些區塊
結構化資料的格式與基本要求，請以Google 結構化資料簡介為準。驗證時的重點很簡單：轉譯完成之後，頁面上只能有一份正確的資料。
怎麼驗證一段 JavaScript 內容有沒有被收錄？
下面這張表，是我在示範情境裡給行銷主管的驗證順序。不需要寫程式，只需要 Search Console 權限和一個瀏覽器。
| 驗證方法 | 怎麼做 | 能證明什麼 | 不能證明什麼 |
|---|---|---|---|
| 比對原始碼與畫面 | 在瀏覽器檢視網頁原始碼，搜尋那段關鍵句 | 這段內容是不是伺服器一開始就送出的 | Google 有沒有收錄 |
| 網址檢查線上測試 | 測試線上網址，查看已測試網頁的 HTML 與截圖 | Google 轉譯時看不看得到這段內容 | 這段內容已經進入索引 |
| 查看已檢索的網頁 | 對已收錄的網址查看 Google 存下的版本 | 上一次檢索時 Google 拿到的內容 | 最新改版後的狀態 |
| 搜尋指令抽查 | 用 site: 加上網域，再加引號包住一句獨特的句子 | 這段文字目前能不能被搜到 | 搜不到的確切原因 |
| 成效報表觀察 | 在 Search Console 成效報表看該頁的查詢字串 | 有沒有使用者因為這段內容找到你 | 沒有曝光是收錄問題還是需求問題 |
驗證時挑一句「只有那段內容才有」的句子，例如規格表裡某個特定型號加尺寸，不要挑品牌名稱這種到處都有的字。一頁挑三段：主要內文、價格或規格、問答區。三段都找得到，才算過關。
搜尋指令的結果只能當抽查，不能當報表。它會變動，也不保證完整。真正要依據的，還是網址檢查裡轉譯後的 HTML。
該優先檢查哪些內容
不是每段 JavaScript 內容都需要被收錄。客服聊天視窗、推薦商品輪播、彈出式優惠，收不收都沒關係。我會依下面的順序檢查：
- 會被搜尋的主要內文與商品規格
- 價格、庫存、營業時間這類會變動的事實資訊
- 導覽與分頁的連結，確保是爬蟲能跟隨的一般連結
- 標題、描述、標準網址、語言標記這些頁面標籤
- 結構化資料，轉譯前後各看一次
示範情境裡的商品頁，修法並不複雜：規格表改成在頁面載入時就輸出，不再等使用者點分頁；robots.txt 只擋後台，不擋商品資料用的 API 路徑。修完後用網址檢查重新測試，再要求重新檢索。後續有沒有被搜到，要給它一段時間觀察，不要隔天就下結論。
驗證結果怎麼交給工程師
行銷和工程吵不起來的前提，是雙方看同一份證據。我建議每次驗證完，整理成一份很短的紀錄，交給工程師時只附這幾項：
- 受檢查的網址，以及檢查日期
- 挑選的三句關鍵句，分別出自頁面哪個區塊
- 每一句在原始碼、轉譯後 HTML、搜尋指令三處找不找得到
- 網址檢查的截圖，特別是畫面空白或缺區塊的地方
- 你希望被收錄、但目前找不到的內容是哪一段
這份紀錄不需要寫出解法。解法是工程師的專業，行銷要做的是把問題描述到可以被重現。示範情境裡的工程師，看到轉譯後 HTML 少了整張規格表、robots.txt 又擋著 API 路徑，很快就知道該從哪裡改。爭論從「誰對」變成「先改哪一個」，週會就省下很多時間。
適用與不適用的情況
這套驗證方法適合：用前端框架建置的官網或電商；用網站建置平台但大量依賴外掛載入內容的網站；以及工程與行銷對「到底有沒有被收錄」各說各話的團隊。它讓雙方看同一份證據。
不適合：內容幾乎都是靜態頁面的傳統網站，風險本來就低，不必花時間逐段驗證；也不適合把「搜不到」全部歸因於渲染，排名和曝光還受內容品質、搜尋需求與競爭影響。驗證只能告訴你 Google 看不看得到，不能保證排名。
如果你需要有人協助判讀網址檢查結果，或和工程團隊一起排修正順序，可以參考冠誠的技術 SEO 健檢與網站維運顧問服務。