- 首頁
- 知識庫
- SEO 搜尋引擎最佳化
- JavaScript 網頁 Google 讀得到嗎？Googlebot 轉譯、延遲載入與檢查方法
SEO 搜尋引擎最佳化
JavaScript 網頁 Google 讀得到嗎？Googlebot 轉譯、延遲載入與檢查方法
作者：JamXu更新日期：2026-10-16
讀得到，但有條件。Googlebot 會用持續更新的 Chromium 執行 JavaScript，先檢索原始 HTML，再把網頁排進轉譯佇列，最後用轉譯後的 HTML 建立索引。只要內容要等使用者點擊、捲動才載入，連結不是含 href 屬性的 a 元素，或 JavaScript 檔被 robots.txt 封鎖，Google 就可能看不到。最可靠的做法是讓重要內容直接出現在伺服器回傳的 HTML，並用 Search Console 網址審查查看轉譯後的 HTML 與螢幕截圖。
JavaScript 網頁 Google 讀得到嗎？先看結論
「網站是用 JavaScript 做的，Google 會不會看不懂？」這是許多公司在改版、外包新網站，或發現某些頁面一直搜不到時最常問的問題。答案沒有想像中那麼可怕：Google 搜尋會以持續更新版本的 Chromium 執行 JavaScript，所以多數用 JavaScript 產生的文字、連結和結構化資料，Google 都有能力讀到。
但「有能力讀到」和「每一次都順利讀到」是兩回事。Google 要先下載網頁，再等資源允許時才執行 JavaScript，過程中只要有一個環節卡住，例如程式出錯、資源被封鎖、內容要等使用者操作才出現，Google 建立索引時用的那份畫面就會少了一塊，而你在自己的瀏覽器裡完全看不出異狀。
所以這篇文章不打算教你寫程式，而是幫網站負責人和行銷人員建立一個判斷順序：先搞懂 Google 處理 JavaScript 的流程，再知道哪些寫法最容易出問題，最後學會用免費工具親眼確認 Google 看到的內容。
| 網站類型 | 內容在哪裡產生 | Google 讀取難度 | 建議做法 |
|---|---|---|---|
| 傳統網站、伺服器端轉譯網站 | 伺服器直接回傳完整 HTML | 低：原始 HTML 就有全部內容 | 維持現狀，定期抽查新功能 |
| 架站平台建置的網站 | 多數由平台在伺服器組好 HTML | 低到中：自行加入的程式或嵌入元件要另外確認 | 抽查自訂區塊、嵌入元件與追蹤代碼插入的內容 |
| 局部使用 JavaScript 的網站 | 主要內容在 HTML，評論、商品列表等由程式載入 | 中：被程式載入的區塊可能漏掉 | 用網址審查確認這些區塊出現在轉譯後 HTML |
| 用戶端轉譯的單頁應用程式（SPA） | 瀏覽器下載程式後才產生畫面 | 高：原始 HTML 幾乎是空殼 | 優先改用伺服器端轉譯或靜態產生，並逐項檢查本文的 SPA 陷阱 |
還要記得一件事：Google 只是眾多會來讀你網站的程式之一。Google 自己在說明文件中提醒，不是所有漫遊器（爬蟲）都能執行 JavaScript，其他搜尋引擎也可能直接忽略 JavaScript 產生的內容。重要的文字放在原始 HTML，等於同時照顧到所有讀者。
Googlebot 怎麼處理 JavaScript：檢索、轉譯、建立索引
Google 的 JavaScript SEO 基礎知識文件把處理流程分成三個階段：檢索、轉譯、建立索引。這比一般常說的「檢索、建立索引、排名」多了一個轉譯步驟，而 JavaScript 網站的問題幾乎都發生在這一步。如果你對搜尋運作的整體概念還不熟，可以先看SEO 搜尋引擎最佳化主題頁中「Google 搜尋怎麼運作」那一節，再回來看細節。
- 檢索：Googlebot 從檢索佇列取出網址，發出要求之前會先讀 robots.txt。網址被禁止檢索，就不會發出要求，被封鎖的網頁或檔案裡的 JavaScript 也不會被轉譯。允許檢索的話，Googlebot 下載原始 HTML，並從其中含 href 屬性的連結找出新網址。
- 排入轉譯佇列：除非 robots meta 標記或回應標頭表明不要建立索引，回傳 200 狀態碼的網頁都會排進轉譯佇列，不論網頁上有沒有 JavaScript。網頁可能只等幾秒，也可能等更久，而且從外部看不出它正在等檢索還是等轉譯。
- 轉譯：在 Google 的資源允許時，無頭 Chromium 會載入網頁並執行 JavaScript，產生「轉譯後的 HTML」。Google 會再從這份 HTML 找一次連結，把新發現的網址排回檢索佇列。
- 建立索引：Google 使用轉譯後的 HTML 建立索引。換句話說，轉譯後 HTML 裡沒有的內容，就不會被編入索引。
三種可能略過轉譯的情況
第一種是 robots.txt 封鎖：網頁本身被封鎖時根本不會被下載；網頁沒被封鎖、但它需要的 JavaScript 或 CSS 檔被封鎖時，Google 轉譯出來的畫面就可能缺內容或排版錯亂。robots.txt 的寫法與「哪些資源不能擋」，在robots.txt 怎麼寫一文有完整說明。
第二種是狀態碼不是 200。錯誤頁面回傳 404 這類狀態碼時，Google 可能略過轉譯，這是合理的設計。第三種是原始 HTML 一開始就帶有 noindex：Google 看到 noindex 可能就不執行 JavaScript，所以想靠程式在載入後把 noindex 拿掉，可能完全不會生效。這一點在後面 SPA 的段落還會再談。
Googlebot 讀檔案有大小上限
依 Google 對 Googlebot 的說明，為 Google 搜尋檢索時，Googlebot 會讀取支援檔案類型的前 2 MB（PDF 為前 64 MB）；HTML 引用的 CSS、JavaScript 等資源會個別擷取，每個檔案同樣適用這個上限，而且以未壓縮的大小計算。超過上限的部分不會被讀取。一般企業網站的 HTML 很少接近 2 MB，但如果把大量資料直接內嵌在 HTML 或把所有程式打包成一個巨大的檔案，就值得留意。
原始 HTML 與轉譯後 HTML：四種渲染方式怎麼影響搜尋
要判斷網站的風險，先分清楚兩份 HTML。「原始 HTML」是伺服器回傳、還沒執行任何程式的那一份，在瀏覽器按「檢視網頁原始碼」看到的就是它。「轉譯後 HTML」是執行完 JavaScript 之後的結果，開發人員工具的「Elements」面板、Search Console 網址審查的 HTML 分頁看到的都是這一份。兩份差得越多，你的網站就越依賴轉譯。
網站是在哪裡把資料組成畫面，業界通常用以下幾個名詞描述。Google 的 web.dev 在「在網路上算繪」一文中整理了這些做法，並且鼓勵開發人員優先考慮伺服器端轉譯或靜態轉譯。
| 做法 | 怎麼運作 | 原始 HTML 有內容嗎 | 對搜尋的影響 |
|---|---|---|---|
| 伺服器端轉譯（SSR） | 每次有人造訪，伺服器即時組好完整 HTML 再送出 | 有 | 最穩定；內容不必等轉譯就看得到 |
| 靜態轉譯（SSG） | 在建置網站時就預先產生每個網址的 HTML 檔 | 有 | 同樣穩定，且速度快；適合內容不常變的頁面 |
| 用戶端轉譯（CSR） | 伺服器送出幾乎空白的 HTML，瀏覽器下載程式後才產生內容 | 幾乎沒有 | 完全依賴轉譯；其他不執行 JavaScript 的漫遊器（爬蟲）看不到內容 |
| 水合（Hydration） | 先送出伺服器組好的 HTML，再由瀏覽器的程式接手加上互動功能 | 有 | 搜尋面接近 SSR；要注意程式接手後不要改掉標題、canonical 等關鍵標記 |
React、Vue、Angular 這些常見框架都有對應的伺服器端轉譯方案（例如 React 的 Next.js、Vue 的 Nuxt），問題通常出在專案一開始只做了用戶端轉譯，上線後才發現搜尋表現不如預期。如果網站還在規劃階段，把「重要頁面要有伺服器端轉譯」寫進需求，比上線後補救便宜得多。
動態轉譯：只是暫時的替代方案
過去有一種折衷做法叫「動態轉譯」：伺服器判斷來訪者是檢索器，就送出預先轉譯好的靜態 HTML，一般使用者則照常拿到用戶端轉譯的版本。Google 目前的文件把它定位為暫時的替代方案，不是長期解法，因為它會增加系統的複雜度與資源需求，建議改用伺服器端轉譯、靜態轉譯或水合。
動態轉譯只要提供給檢索器和使用者的內容相似，Google 一般不視為偽裝；但如果給檢索器和給使用者的是完全不同的內容，就可能被當成偽裝行為。已經在用動態轉譯的網站，應把它列入技術債，安排改用更穩定的做法。
哪些內容最容易因為 JavaScript 被 Google 漏掉
多數 JavaScript 搜尋問題都不是「Google 不會執行程式」，而是程式的設計假設了一個真人使用者：會點擊、會捲動、會登入、會保留上一頁的狀態。Googlebot 不是這樣的訪客。下表整理企業網站最常見的情況，你可以拿來對照自己的網站。
| 情況 | 為什麼會漏掉 | 比較好的做法 |
|---|---|---|
| 要點擊按鈕、展開或切換分頁後才「去伺服器抓」的內容 | Google 搜尋不會和網頁互動，不會替你按按鈕 | 內容在載入時就放進 HTML，按鈕只負責顯示或隱藏 |
| 要捲動到底才載入的下一批文章或商品 | Google 不會像真人一樣捲動頁面 | 提供有獨立網址的分頁，並在頁面中連結到下一頁 |
| 用 onclick 或 span 做的「假連結」 | Google 一般只檢索含 href 屬性的 a 元素 | 改成標準的 a 連結，href 填真實網址 |
| 用 #/products 這類網址片段切換頁面 | Google 無法可靠地把片段當成不同網頁 | 改用 History API，讓每個畫面有真正的網址 |
| 需要登入、相機、定位等授權才顯示的內容 | Googlebot 會拒絕授權要求 | 讓內容在不授權的情況下也能看到 |
| 依賴 Cookie 或本機儲存資料才顯示的內容 | 每次載入網頁時 Cookie 與本機儲存資料都會被清除 | 不要讓主要內容依賴前一次瀏覽留下的狀態 |
| 透過 WebSocket 等連線即時推送的內容 | Googlebot 用 HTTP 要求擷取內容，不支援 WebSocket、WebRTC | 提供可用 HTTP 取得內容的備援 |
| 第三方元件嵌入的評論、社群貼文 | 內容由外部程式載入，屬於對方平台 | 重要資訊另外用文字寫在自己的頁面上 |
表中最常見的是前兩項。很多網站把常見問題、規格表或「更多介紹」做成折疊區塊，這本身沒有問題：只要文字在載入時就存在於 HTML，只是先被收起來，Google 仍然讀得到。真正的問題是「按下去才去伺服器要資料」的設計，因為沒有人替 Google 按那個按鈕，那段內容對搜尋來說就不存在。
連結一定要是含 href 的 a 元素
Google 的連結最佳做法說得很直接：一般來說，Google 只能檢索含有 href 屬性的 <a> 元素。<a href="/products/shoes"> 是好連結，即使同時綁了 onclick 事件也沒關係；<span href="…">、只有 onclick 沒有 href 的 a 元素，或 href 寫成 javascript:goTo(…)，Google 都可能無法正確解析。用 JavaScript 動態插入的連結可以被檢索，前提是插入的仍是標準 a 元素。連結對網站結構與排名的意義，可以搭配內部連結怎麼做一起看。
程式檔案改版後，Google 可能還在用舊版
Googlebot 為了減少網路要求會積極快取，負責轉譯的網頁轉譯服務（WRS）可能忽略快取標頭，用到舊版的 JavaScript 或 CSS。Google 建議在檔名加上內容指紋，例如 main.2bb85551.js，檔案內容一改檔名就跟著改。改版後發現 Google 轉譯的畫面還是舊排版，可以先請工程師確認檔名有沒有隨內容更新。
延遲載入怎麼做才不會讓 Google 看不到
延遲載入（lazy loading）是把暫時看不到的圖片、影片或內容，等快要進入畫面時才載入，用來加快網頁速度。這是很好的做法，但 Google 在修正延遲載入內容的說明中也提醒，做錯了可能會不小心對 Google 隱藏內容。關鍵在於「用什麼觸發載入」。
- 建議的觸發方式：瀏覽器內建的延遲載入（img 與 iframe 的 loading="lazy" 屬性）、IntersectionObserver API，或在內容進入可視區域時才載入資料的程式庫。這些方法都不依賴捲動、點擊等使用者動作。
- 有風險的觸發方式：監聽捲動事件、滑鼠移入，或按下「載入更多」按鈕才載入。Google 搜尋不會與網頁互動，這類內容很可能停在「還沒載入」的狀態。
- 首屏內容不要延遲載入：使用者一打開就會看到的內容如果被延遲，反而會讓畫面出現得更慢。主視覺圖片尤其不要設延遲載入，它常常就是最大內容繪製（LCP）的那個元素。
判斷做法是否正確，Google 給的標準很具體：在網址審查查看轉譯後的 HTML，如果圖片或影片網址出現在 img 或 video 元素的 src 屬性中，就代表設定正確。如果只看到 data-src 之類的屬性、src 是空的，代表那張圖要等程式觸發才會換上真正網址，Google 很可能看不到。延遲載入和速度指標的關係，在PageSpeed Insights 怎麼看一文有更多改善方法。
無限捲動要搭配分頁網址
部落格、作品集或商品列表常用「往下捲就自動載入更多」的無限捲動。對使用者很方便，但 Google 不會一直往下捲。Google 建議讓每一段內容都有可以單獨開啟的分頁網址，做法可以整理成四點：
- 每一段內容都有自己固定不變的網址，例如在網址加上 ?page=2、?page=3 這類絕對頁碼。
- 同一個網址每次打開，顯示的內容都要相同；避免用 ?date=yesterday 這種相對的參數。
- 在頁面上依序連結到各個分頁網址，讓搜尋引擎能沿著連結找到每一頁。
- 當新載入的區塊成為畫面主要內容時，用 History API 更新網址列，讓使用者重新整理、分享時回到同一段內容。
電商網站的分類頁、篩選條件與分頁怎麼兼顧收錄，在電商網站 SEO 怎麼做有更完整的說明；這裡只要記得一個原則：每一批想被搜尋到的內容，都要有一個可以直接打開的網址。
單頁應用程式（SPA）常見的四個陷阱
單頁應用程式只載入一次網頁，之後切換畫面都由 JavaScript 處理，使用起來很順暢，卻也是 JavaScript SEO 問題最集中的地方。以下四個陷阱，建議交給開發團隊逐項確認。
陷阱一：每個畫面沒有自己的網址
如果整個網站的網址都長得一樣，或只是在 # 後面換字，Google 無法把每個畫面當成獨立網頁。Google 已在 2015 年停止支援舊的 AJAX 檢索配置，所以不能再期待 #! 這類網址被特別處理。正確做法是用 History API，讓「服務介紹」「案例」「聯絡我們」各自有像 /services 這樣的真實網址，並且直接開啟這個網址時也能顯示對應內容。
陷阱二：找不到的頁面卻回傳 200（軟 404）
用戶端轉送的單頁應用程式，不論使用者打開什麼網址，伺服器往往都回傳 200，再由程式顯示「查無此商品」。對 Google 來說，這看起來像一個正常的網頁，可能因此把錯誤頁編入索引，這就是軟 404。Google 建議兩種處理方式擇一：用 JavaScript 轉址到一個伺服器會回傳 404 狀態碼的網址（例如 /not-found），或用 JavaScript 在錯誤頁加上 noindex 的 robots meta 標記。
陷阱三：標題、描述與 canonical 被程式改掉
Google 允許用 JavaScript 設定或變更 title 與 meta description，所以單頁應用程式在切換畫面時更新標題是可行的，重點是每個網址都要有獨特、能描述內容的標題。canonical 則要小心：最好的方式是直接寫在 HTML；如果一定要用 JavaScript，程式設定的標準網址必須和原始 HTML 中的一致，而且整頁只能有一個 rel="canonical"。至於noindex、canonical、301 怎麼選，要看你想讓 Google 合併重複頁面、排除頁面，還是把舊網址轉到新網址。
陷阱四：想用 JavaScript 解除 noindex
有些網站在原始 HTML 先放 noindex，打算等資料載入成功後再用程式拿掉。前面提過，Google 看到 noindex 可能直接略過轉譯，程式根本沒有機會執行。Google 的說明很明確：如果你希望網頁被編入索引，原始程式碼裡就不要放 noindex。反過來的情況是可行的，也就是原本可以索引的頁面，在資料不存在時用程式加上 noindex。
結構化資料可以用 JavaScript 產生
JSON-LD 結構化資料可以由 JavaScript 產生後插入網頁，Google 轉譯時讀得到。不過 Google 也提醒，商品資料若以動態方式產生，購物相關的檢索可能較不頻繁、較不可靠；價格、庫存這類常變動的資訊，最好由伺服器直接輸出。結構化資料怎麼做一文則整理了各類型的資格與測試方式。
用網址審查看 Google 轉譯後的網頁：一步一步來
理論再多，最後都要回到一個問題：Google 實際看到了什麼？Search Console 的網址審查工具（Google 說明文件中稱為網址檢查工具）可以直接回答。工具的基本用法、索引狀態判讀與「要求建立索引」的時機，已經在Google Search Console 教學的「網址審查」一節介紹過，這裡專注在與 JavaScript 有關的三個畫面：轉譯後的 HTML、螢幕截圖，以及頁面資源與 JavaScript 控制台訊息。
- 貼上網址：在 Search Console 上方的搜尋框貼上要檢查的完整網址。先看「已建立索引」的結果，它顯示的是 Google 上次檢索時的版本，不是現在的網頁。
- 執行即時測試：按「測試線上網址」，讓 Google-InspectionTool 用現在的網頁重新檢索、轉譯一次。網頁必須是不用登入就能開啟的公開網址。
- 開啟「查看已測試的網頁」：（已建立索引的結果中則是「查看已檢索的網頁」）側邊面板會出現 HTML、螢幕截圖與更多資訊三個部分。
- 檢查 HTML 分頁：這裡是轉譯後的 HTML。用瀏覽器的搜尋功能找一句應該出現的重點文字、一個重要連結的網址，以及 title、canonical、robots meta 標記，確認它們都在、而且是你預期的值。
- 看螢幕截圖：確認畫面不是空白、沒有一直停在載入動畫、主要內容與圖片都出現。螢幕截圖只在即時測試時提供。
- 展開「更多資訊」：看「頁面資源」有沒有載入失敗的檔案，以及「JavaScript 控制台訊息」有沒有錯誤。載入失敗的原因若顯示為被 robots.txt 封鎖，而那個檔案又影響內容呈現，就要解除封鎖。
使用網址審查時有三個限制要知道。第一，即時測試通過只代表 Google-InspectionTool 能存取並轉譯這個網頁，不保證網頁一定會被編入索引，Google 仍會評估重複內容、品質等其他條件。第二，Google 對每個資源每天的即時測試與要求建立索引次數都有上限，適合抽查重點頁面，不適合逐頁大量測試。第三，即時測試會自動跟隨轉址，測的是最終網址，而且不會特別標示發生過轉址。
Google 的網址檢查工具說明也建議，修正問題後要再測試一次線上網址，確認 Google 認同問題已經解決。實務上就是再跑一次即時測試，確認轉譯後 HTML 已經出現原本缺少的內容，再視情況按「要求建立索引」。
沒有 Search Console 權限時，還能怎麼檢查
網址審查只能檢查自己有權限的網站。想在網站交接前先看看外包商做的成品、評估競爭對手的網站，或是還沒拿到 Search Console 權限時，可以用下面幾種方式粗略判斷。
複合式搜尋結果測試
Google 的複合式搜尋結果測試不需要網站擁有權，任何公開網址都能測。它預設用智慧型手機使用者代理程式檢索，除了檢查結構化資料，也能看到轉譯後的程式碼、載入的資源與 JavaScript 控制台輸出。雖然它的主要用途是結構化資料，拿來確認「Google 轉譯後有沒有這段文字」也很實用。
用瀏覽器比對兩份 HTML
- 在網頁上按右鍵選「檢視網頁原始碼」，這是原始 HTML。用搜尋功能找一句頁面中段的重點文字，看它在不在。
- 按 F12 開啟開發人員工具，在「Elements」面板搜尋同一句文字，這是瀏覽器轉譯後的結果。
- 兩邊都有：內容不依賴 JavaScript，最穩定。只有 Elements 有：內容由 JavaScript 產生，要用網址審查或複合式搜尋結果測試確認 Google 也讀得到。兩邊都沒有：那段文字可能是圖片，或要等操作才載入。
- 進階一點，可以在開發人員工具暫時停用 JavaScript 再重新整理。web.dev 也建議用這個方式判斷網頁是靜態產生還是依賴用戶端程式：畫面越接近空白，代表越依賴 JavaScript。
瀏覽器的結果只能當作初步判斷。你的瀏覽器會保留 Cookie、可能已經登入，也會自動捲動與互動，和 Googlebot 的環境不同；最後仍以 Google 自己的工具為準。
用搜尋結果反查
如果網頁已經上線一段時間，也可以在 Google 搜尋用「site:你的網域」加上一句只會出現在 JavaScript 區塊中的完整句子（用引號框起來），看看能不能找到。找得到代表那段內容已被索引；找不到不一定代表有問題，因為 site: 的結果本來就不完整，這只是輔助線索。
用架站平台建置的網站要注意什麼？以 Sharing AI 為例
多數企業網站不是從零開發，而是用架站平台建置。這時要問的不是「要不要做伺服器端轉譯」，而是「平台產生的頁面，重要內容在不在原始 HTML」。我們在 2026 年 10 月用本站實際比對：本站以 Sharing AI 架站平台建置，我們抓取文章頁、主題頁與首頁伺服器回傳的原始 HTML，再和瀏覽器執行完 JavaScript 後的結果逐項比較。
- 頁面標題（title）、robots meta 標記與標準網址（canonical）在原始 HTML 中就已存在，執行 JavaScript 前後相同。
- 唯一的 H1、各段 H2 與內文文字都在原始 HTML 中，畫面上看得到的文字，在原始 HTML 中都找得到。
- 頁面中的連結是標準的 a 元素，並寫有 href 網址。執行 JavaScript 前後，唯一多出來的是本站右下角的 AI 客服聊天視窗，它是網頁載入後才由程式加入的互動元件。
- 頁面設定的結構化資料（例如 BreadcrumbList、Article、FAQPage）以 JSON-LD 寫在原始 HTML 中。
- 內文圖片使用瀏覽器內建的 loading="lazy"，圖片網址直接寫在 src 屬性中，不需要程式觸發。
換句話說，用平台內建的頁面、文章與區塊編輯出來的內容，Google 不必等轉譯就能讀到。需要自己多留意的，是這些「後來加上去」的東西：
- 自行撰寫的程式區塊：在自訂 HTML 區塊裡寫程式去外部抓資料再顯示，那段內容就變成依賴 JavaScript，上線後要用網址審查確認。
- 透過代碼管理工具插入的內容：用 Google 代碼管理工具（GTM）插入文字或結構化資料，一樣屬於轉譯後才出現的內容；追蹤代碼本身的安裝步驟，在網站行銷代碼怎麼裝一文有逐步說明。
- 第三方嵌入元件：社群貼文、評價、地圖、聊天視窗等元件的內容由對方平台的程式載入，不要把服務說明、價格或聯絡方式只放在嵌入元件裡，重要資訊另外寫成頁面上的文字。
從其他系統搬到架站平台時，舊網站若是單頁應用程式，舊網址常常是 # 片段或沒有獨立網址，要在搬家前先整理網址對照表，網站搬家怎麼做一文有完整的盤點與轉址步驟。
常見錯誤與正確做法
| 常見錯誤 | 會造成的問題 | 比較好的做法 |
|---|---|---|
| 在 robots.txt 封鎖 /js/ 或 /assets/ 資料夾 | Google 轉譯時缺少程式或樣式，畫面不完整 | 只封鎖與呈現無關的檔案，用網址審查確認頁面資源 |
| 重要內容要點「看更多」才從伺服器載入 | Google 不會點擊，那段內容不會被索引 | 內容在載入時就放進 HTML，按鈕只負責展開 |
| 列表只靠無限捲動載入下一頁 | 後面的文章或商品沒有網址可以被找到 | 提供 ?page=2 這類分頁網址並互相連結 |
| 導覽選單用 onclick 切換頁面 | Google 找不到其他頁面的網址 | 改成含 href 的標準 a 連結 |
| 錯誤頁面回傳 200 | 查無資料的頁面被當成正常網頁收錄（軟 404） | 轉址到回傳 404 的網址，或加上 noindex |
| 原始 HTML 放 noindex，想靠程式移除 | Google 可能不執行程式，網頁一直不被收錄 | 要被收錄的頁面，原始碼不放 noindex |
| JavaScript 改寫成不同的 canonical | Google 收到互相矛盾的標準網址信號 | 程式設定的值與原始 HTML 一致，且只有一個 |
| 首屏主視覺設延遲載入 | 最大內容繪製變慢，使用者體驗變差 | 首屏圖片正常載入，下方內容才延遲載入 |
| 只在自己的瀏覽器確認畫面正常 | 看不出 Google 環境中才會發生的錯誤 | 用網址審查看轉譯後 HTML、螢幕截圖與控制台訊息 |
這張表的共同點是：在自己的瀏覽器看起來一切正常，不代表 Google 也看到一樣的東西。凡是會影響內容出現方式的改版，上線後都值得抽查幾個代表頁面。
JavaScript SEO 檢查清單與下一步
把整篇整理成一張清單，網站改版、加入新功能或換外包團隊時，都可以拿出來逐項確認：
- 重要頁面的標題、主要內容與內部連結，在原始 HTML（檢視網頁原始碼）中就找得到
- 網站使用的 JavaScript、CSS 沒有被 robots.txt 封鎖
- 所有導覽與內文連結都是含 href 的 a 元素，網址是真實路徑而不是 # 片段
- 每個畫面或每批內容都有可以直接開啟的網址，列表提供分頁網址
- 延遲載入的圖片在轉譯後 HTML 的 src 屬性中出現真正網址，首屏圖片沒有延遲載入
- 不存在的頁面回傳 404，或在單頁應用程式中轉址到 404 網址、加上 noindex
- 要被收錄的頁面原始碼沒有 noindex，canonical 只有一個且前後一致
- 程式檔名帶有內容指紋，改版後 Google 不會沿用舊檔
- 用網址審查即時測試代表頁面：HTML 有重點文字、螢幕截圖完整、控制台沒有影響內容的錯誤
- 自訂程式區塊、代碼管理工具插入的內容與第三方嵌入元件，上線後各抽查一次
如果你是第一次替網站做技術檢查，建議先從網站 SEO 健檢要先看什麼排出整體順序，JavaScript 只是其中一個環節。想從更多觀念文章逐步建立 SEO 基礎，可以回到SEO 搜尋引擎最佳化主題頁；若希望由專業團隊協助檢查網站的轉譯、收錄與技術架構，我們的AI SEO 顧問服務可以從健檢開始協助，也歡迎直接與我們聯絡討論。