JavaScript SEO：被高估的渲染，被低估的收錄

電商檔期的活動頁上線滿兩週。廣告有訂單，社群貼文有訂單，老客戶回購也正常，唯獨自然搜尋安安靜靜，就連品牌名加活動名一起查，結果裡也找不到那一頁。

檢討會議上，工程端說得篤定：Google 早就會執行 JavaScript，頁面在瀏覽器看得到，搜尋引擎就看得到。行銷端把收錄報表投影到螢幕上反問：那為什麼這個網址上週還在、這週消失？兩邊各自堅持，會議停在原點。

兩邊可能都沒說錯，因為他們描述的是同一個網站的兩個版本。訪客眼前的是腳本執行完的畫面；搜尋引擎先拿到的是還沒執行的伺服器回應，執行後的內容要等另一階段的處理才補齊。抓取與渲染之間的時間差、執行的成敗、兩個版本各自的訊號，就是收錄異常最常見的現場。接下來的流程不預設誰對誰錯：先照症狀分流，再用是非題往下走，用三個時間點對照收證，找到斷在哪一層，才決定修什麼。

快速重點：Google 會執行 JavaScript，但收錄分抓取與渲染兩階段，渲染排在另一條佇列、不保證及時發生；成敗在渲染能否補齊內容，以及原始回應的完整度。關鍵內容與索引指令放進伺服器回應最穩。現在就能做兩件事：在原始碼裡搜尋正文關鍵字，再到 Search Console 看收錄狀態。

先別急著改文案：四種症狀，四個樓層

流量或收錄出現異常時，多數團隊的第一個反應是改內容：換標題、補關鍵字、加連結。這些動作對其中幾種症狀有效，對其餘幾種完全無效，差別在於該先往哪一層查。把網站想成一棟大樓：讀取層在地下，更新偵測層在中段，載入觸發層再往上，內容與體驗層在頂樓。行銷與工程常在不同樓層各自挖牆，挖了半天，才發現問題根本不在自己那層。

表裡的一分鐘確認法都不需要工程支援。行銷端可以自己打開原始碼搜尋關鍵字、自己核對報表的時間標記，帶著證據去開協調會議，比帶著「我覺得網站有問題」有效得多。前兩種症狀先往讀取與更新查，第三種先往載入設計查，第四種才回到內容本身；順序走對，力氣才不會花在錯的樓層。會議上最有價值的一句話，也會從「網站是不是壞了」換成「該先往哪一層查」，爭執當場少一半。

官方文件對基本事實說得很直接：Google 可以執行 JavaScript，頁面以可成功的回應為前提，排入處理之後才談得上收錄。真正的分水嶺不在能不能執行，而在這一頁何時被讀、讀了幾次、每次讀到哪個版本。把焦點從執行能力移到閱讀的時間軸，前面四種症狀才對得上各自的原因。

「Google 會執行 JavaScript」與「頁面有被收錄」是兩件事，把兩者畫上等號，正是開場那場會議各說各話的源頭。這裡談的始終是索引資格與可見性，不是排名承諾：讀得到，代表取得參與資格；至於排不排得上，取決於內容、需求與競爭。想看整棟大樓的運作全貌，可以從搜尋引擎處理網頁的完整流程讀起；負責執行這套流程的Googlebot，身分與工作方式另有完整介紹。接下來的章節，就照時間軸逐層往下走。

同一個頁面，Google 分兩階段讀

內容放在 JavaScript 裡，Google 是讀不到，還是晚一點才讀到？多數情況是後者。抓取時，搜尋引擎先收下伺服器回應的原始 HTML；回傳 HTTP 200、且原始回應未指示 noindex 的頁面，之後會排進另一條渲染佇列，不論有沒有 JavaScript，差別在於倚賴腳本的正文，要等這一步才補得進來。官方文件把兩者描述成分開排程的階段，並未承諾緊接再訪同一網址；本文以「第二遍閱讀」簡稱渲染階段，這一步可能延後、批次合併，甚至一直沒發生，而原始回應裡的訊號，第一遍就被記下了。

第一遍拿到的是伺服器給什麼就是什麼：回應內容、當下可解析的連結、原始碼裡已存在的標籤。第二遍補的是執行後的結果：Google 用以 Chromium 瀏覽器專案為基礎的環境跑完頁面上的程式，把腳本產生的內容、之後才出現的連結一併讀進去。兩遍讀到的東西可以差很多，而索引採用哪一遍的版本，取決於渲染階段有沒有發生、成不成功。

原始回應是空殼時，賭注最重。這種頁面的索引內容幾乎完全押在渲染的成敗上：執行成功，內容補齊；執行失敗或只跑了一半，搜尋引擎手上的版本就是缺的。新頁面要等第二遍完成才可能出現，改版後的新內容也要等第二遍才反映，這類時間差屬於機制的代價，不是懲罰，實際間隔隨網站狀態浮動，沒有適用所有網站的固定天數。

同樣的機制也解釋了另一種症狀：頁面上週還在、這週消失。未必有誰刻意移除它；值得先查的，是某次重新處理有沒有拿到不完整的版本，若有，索引會跟著換成那個版本，換下來的舊內容看起來就像被拔掉了。把消失的原因往「重新處理的成敗」找，比往「被降權」找，更容易找到可以修的東西。

但不是每種頁面都要用同一把尺。需要被搜尋找到的行銷頁、商品頁，對第二遍的依賴要壓低；登入後才看得到的儀表板、本來就不該被索引的應用內頁，維持前端產生內容反而合理。把站上的頁型列出來，逐型標註要不要索引，這張表在後面選處方時還會再用一次。

對應的檢查動作很樸素：用收錄狀態查詢確認目標網址現在落在哪一格，用XML Sitemap確保重要網址有另一條被發現的路。sitemap 是補路，不是替代；第二遍有沒有發生、抓的是哪一版，仍要靠逐頁檢視。這一整套都屬於技術性 SEO的日常範圍，不需要特效藥。

第二遍閱讀會在三個地方失手：時間、資源、許可

排到第二次處理的頁面，中途失敗或只做一半的機會比想像中高。腳本逾時或中途出錯、關鍵內容依賴額外的網路請求、資源檔被 robots.txt 擋掉，任何一關出事，渲染版本就缺內容，而且這些失敗在一般瀏覽器畫面上多半看不出任何異狀。內容愈晚到位，失敗點就愈多。

時間是第一道關。渲染排程有資源上限，頁面數量大、腳本份量重的網站，要優先留意兩遍閱讀之間的間隔是否被拉長，時效性內容等不起。報表上的線索要分開判讀：上次造訪時間長期停在舊日期，先查的是抓取有沒有落後；渲染有沒有完成，要看渲染後的內容與資源狀態，兩種延遲不要混在一起。頁數規模大到一定程度的站，檢索量的分配本身就是要管理的變數，相關邏輯在檢索預算有完整拆解；一般規模的網站先顧好單頁品質即可。

資源是第二道關，也是最容易默默出事的一道。腳本丟出未處理的例外、長時間佔住主執行緒，執行環境會提前收工，頁面以不完整的版本定案；更常見的情況是正文得等頁面載入後再向 API 要資料：回應太慢、必須登入、請求被擋下來，任何一種都會讓渲染版本缺了那段內容，等於把收錄的成敗外包給另一條網路鏈，而這條鏈斷在哪裡，畫面上看不出來。

許可是第三道關。有些網站為了整潔，把整包前端資源目錄寫進 robots.txt 的 disallow，等於收了門票又把教室鎖上：頁面本身開放抓取，執行所需的腳本與樣式卻拿不到，搜尋引擎讀到的版本就像打了馬賽克。robots.txt 管的是抓取範圍，不是權限控制，語法細節與常見誤用在robots.txt 規則一篇整理過。

這三道關都有官方的排查建議可以對照，Google 的疑難排解文件把常見失敗模式列得清楚，拿來當檢查表比憑印象猜可靠。這些問題也常與速度問題同源：同一包過重的腳本，既拖累第二次處理，也拖累真人訪客，網站速度優化的改善常常一次解決兩邊。

四個是非題照順序問，答案會帶路

沒有工程背景，也能自己定位問題在哪一層。方法是把檢查收斂成四個是非題，照順序問，每一題的答案直接決定下一題要不要問：原始碼就找得到正文的頁面，渲染測試那一題可以跳過，連結與索引版本照查。一個下午可以把所有重點頁走完。

1. 原始碼裡找得到正文嗎？在目標頁面檢視原始碼，搜尋正文的獨特關鍵字。找得到，第二題直接跳過，前往第三題；找不到，代表內容押在第二次處理上，進第二題。
2. 渲染之後看得到嗎？打開網址檢查工具跑即時測試，看執行後的畫面與 HTML 有沒有正文和連結。看得到，渲染這關先過，繼續核對訊號面與已索引版本；看不到，照第三道關的清單查資源與 API。
3. 連結是帶 href 的錨點嗎？判準看渲染後的 HTML：只要是有 href 的錨點，由腳本注入也算數，Google 讀得到。停用 JavaScript 走一次導覽是最保守的快篩：仍能換頁，一定過關；失效也先別定罪，回頭確認渲染後的錨點，真找不到 href，才代表通路只對腳本開放。
4. 索引版本是新的嗎？回到網址檢查看上次造訪時間，對照站上內容的更新時間。落後太多，先查重新抓取與處理進度，渲染也還在待查清單裡，先別急著排除。

四題的順序有講究。第一題最便宜、最不需要工具，先問它，能把一大半頁面直接分流出去；渲染測試每跑一次都要等，留給真正需要的頁面。判斷流程本身也有成本，讓它輕，流程才持續得下去。

走完四題，手上的東西會從「感覺網站怪怪的」變成一張每題都註明是、非或未測的證據清單。這張清單拿去和工程團隊對話，雙方才有共同語言：哪一題破了，就修哪一層，不必把整個網站送進重構。需要的工具只有瀏覽器與後台報表；開發者工具怎麼上手，在F12 開發者工具教學裡有完整說明。

現在測試、上次抓取、索引結果：三個時間點不要混為一談

網址檢查顯示一切正常，搜尋結果裡卻還是舊內容，這個矛盾幾乎每輪診斷都會遇到。原因在於三個時間點各自獨立：即時測試是當下的渲染結果，上次抓取是搜尋引擎前一次看到的版本，索引結果才是真正參與排名的內容。三欄必須對照著看，任何單一的綠色勾勾都不足以宣布結案。

判讀的分歧點只有兩個。即時測試正常、索引落後，問題偏向更新與重新處理的進度，先查上次抓取與渲染排程、讓新版本早點被讀到，但渲染因素不能就此排除；即時測試本身失敗，問題在渲染，要回頭查腳本、資源與 API。只看即時測試就收工，最容易誤判成已經修好了，實際上索引裡躺的還是舊版本。

具體操作是：把網址貼進Search Console 的網址檢查，選「測試公開網址」，看即時測試跑出來的畫面與 HTML 有沒有正文和連結；接著對照報表上的上次抓取時間與索引狀態，再到頁面索引報表確認這個網址落在哪一格。即時測試是當下的結果，已建立索引的版本是另一份存證，兩者本來就可能不同，而差異本身就是診斷結論，不是工具故障。

單頁的網址檢查與全站的頁面索引報表要交叉著讀：前者給證據，後者給趨勢。改版之後兩邊都要看，單頁正常不代表整批頁面都正常；趨勢往下走時，先挑跌幅最大的幾頁回頭跑單頁檢查，把哪一層出事的答案帶回報表，兩邊互相收斂。

驗收時把兩份存證分開留存：即時測試跑出的渲染結果一份，已索引版本一份。工具回報正常，只代表本次測試讀得到、渲染得出來，不能排除所有索引問題，更與排名是兩回事；索引版本與站上內容一致，才是這一輪修正可以簽字收工的標準。

晚到的內容能等，晚到的指令會出事

哪些東西可以晚點生成，哪些不行？判斷的基準只有一條：內容晚到，可能延遲收錄，渲染失敗時甚至缺漏；會影響索引決策的訊號若在兩遍閱讀之間換了版本，等於讓先後兩遍聽到不同的說法，出事的是判定，不是速度。

連結是第一種訊號。官方的判準比想像中寬：連結由腳本注入無妨，只要渲染後出現的是帶 href 的錨點，Google 就讀得到；跳頁只綁在點擊事件上、渲染後也找不到 href，這條通路才只對滑鼠開放，抓取端走不進去。停用 JavaScript 走導覽是保守快篩，走不到不代表出局，判定以渲染後的錨點為準。內部連結的經營原則與錨點文字的多樣性，在內部連結經營有完整討論，前端渲染的網站尤其該把這條列進驗收。

用一個常見的情境把這節具體化：在地服務業的官網，首頁有漂亮的預約行事曆、可展開的服務項目、折疊起來的顧客評論，全部由前端元件在載入後生成。訪客用起來順，搜尋引擎第一遍卻只讀到導覽列；服務項目沒有獨立頁面，評論要點開才載入，等於把最有搜尋價值的內容全部押在第二遍的成敗上。

標籤是第二種訊號。title、canonical、robots 指令由腳本在執行期改寫時，兩遍讀到的值可能不同，最終生效的是哪一遍，要驗證，不能假設；時間標記決定誰說了算。canonical 的值在兩個版本之間漂移，頁面可能被併進重複內容的判定；不想被索引的頁面，指令讀不讀得到也有講究，robots.txt 與 noindex 的分工值得對照著讀。

結構化資料是第三種。腳本產生的標記是有效的，但它存在於第二遍，驗證時必須看渲染後的版本，只看原始碼會漏掉，只看渲染版又可能誤信；兩版對照，才確認得了標記在什麼時間點存在。標記的選擇與常見錯誤，結構化資料標記有完整指引，其中價格、庫存這類變動頻繁的欄位，穩定性風險要一併評估。

延遲載入是第四種。靠捲動或點擊才出現的區塊，對沒有捲動動作的抓取端而言等於不存在，列表的第二頁、圖片庫的後半批都是常見受害者。解法不是停用延遲載入，而是給每段內容獨立的網址或分頁路標，實作細節在延遲載入指南；載入體驗與可取得性，這兩件事要同時成立。

狀態碼是 SPA 唯一的誠實頻道

前端路由讓每個網址都拿到同一份成功回應時，狀態碼這條頻道就失去分辨作用，搜尋引擎只能從內容線索推測；畫面顯示找不到、回應卻仍是 200 的頁面，常被判定為軟 404：外觀是錯誤頁，身分卻是正常頁，判定系統收到兩組矛盾的訊號。

機制上，HTTP 狀態碼是伺服器層的訊號，前端路由預設不會改變它。要讓頻道說實話，規則很簡單：頁面不存在，回 404 或 410；內容搬走，回 301 或 302 指到新位置。這是這類網站成本最低、卻最常被省略的修正，因為它不影響任何畫面，只在搬遷與除錯時才看得出價值。

檢查的方法不神祕：把不再維護的舊網址直接輸入瀏覽器，看畫面之餘，也看回應的狀態碼；要批次驗證，交給除錯工具或伺服器紀錄。隨手輸入一個不存在的路徑，看回傳的是 404，還是一頁看起來像錯誤畫面的 200，答案立見分曉。

放著不管的代價要謹慎估計。大量「看起來像 404 的 200」可能稀釋品質訊號、拖累檢索效率，實際幅度依網站規模與比例而異，沒有通用的數字；可以確定的是，它讓判定系統持續處理矛盾訊號，修掉從來不是壞事。

換框架與大改版是這類問題的高風險窗口。路由重寫時，狀態碼與轉址的映射最容易漏，舊網址一批批落回 200 的空殼。完整的風險控管，網站搬遷與改版有逐項流程；渲染面的檢查是其中一節，不是全部。

發現路徑上，sitemap 只放可索引的正式網址，選出 canonical 版本再放進去，讓它作為連結之外的補充路徑，產生與提交的細節見sitemap 產生與提交。

三張處方箋：快修、改體質、爭取時間

確認問題在讀取層之後，修法不是只有整套改伺服器輸出一條路。依診斷的輕重與手上的資源，有三張處方可選，從小刀到大工程，各自對應不同的處境。

快修：把關鍵內容、連結與索引標籤移回伺服器回應。標題、正文首段、主要連結、canonical，這幾項從執行期搬到回應期，工程範圍小，風險低，對整頁讀不到的症狀收效最直接。先救流量與訂單貢獻最大的頁面，其他頁面排隊。

改體質：按頁面角色決定內容的出發時間。有的頁面適合建置時就預先產生，有的適合請求進來時當場組好，有的維持前端產生。分配的起點只有一個問題：這一頁的內容需不需要出現在搜尋與 AI 檢索裡。各種輸出方式的完整光譜，web.dev 的渲染模式整理值得當成對照表。

第三張處方是爭取時間：短期內動不了架構、又等不了第二次處理的網站，還有一種過渡手段，由伺服器辨識來訪身分，把預先備好的版本轉寄給抓取端，訪客照舊拿原本的頁面。官方對這類做法的定位寫得明白：它是權宜手段，不建議新專案採用，而且抓取端取得的內容必須與訪客相近，差距大到被認定為誤導，就踩進了欺騙搜尋引擎的紅線；雙版本的同步成本也會隨時間上升，一份改了、另一份沒跟上，問題會用更安靜的方式回來。

排序的原則比選哪張處方更重要：先救商業價值最高的頁面，分批遷移，避免全站一次性重構把所有風險集中在同一天。每一批上線後，回頭跑一次三個時間點的對照，確認索引版本真的換新了，再開下一批；批次之間保留觀察期，索引的反映本來就有時間差，全部擠在同一週上線，出了問題會分不清是哪一批帶進來的。

伺服器先發，不等於前端變輕。預先產生或當場組好的頁面，照樣會掛上整套互動程式，瀏覽器拿到 HTML 之後要重新執行一遍，按鈕、表單、選單才恢復作用；程式的份量取決於套件怎麼拆、互動怎麼分批載入。所以選型時要同時量測三件事：伺服器回應多快、可見內容多早到位、互動多快有反應，三個數字一起看，而不是由渲染模式直接推定速度。

互動那一項，現行的口徑是 INP，它已取代退役的 FID，成為 Core Web Vitals 裡量測互動回應的指標，來龍去脈見INP 與 FID 的交接。速度確實影響體驗與放棄率，官方對速度與使用者行為的說明把這層關係講得保守而清楚；對應的體驗指標整理在Core Web Vitals。工具分數反映的是體驗狀況，不是流量保證，這條界線同樣適用。

同一套診斷，兩份報酬：搜尋與 AI 檢索

現在花力氣做這套檢查，對 AI 搜尋與聊天機器人的引用有幫助嗎？有，但是間接的。各家 AI 服務的抓取與執行能力不一，有的會跑腳本，有的只讀回應內容；把關鍵內容放進伺服器回應，是不必賭特定工具能力、風險最低的做法：能取得原始 HTML 的系統，都比較容易讀到；只存在於執行後的版本，就要看該系統願不願意跑腳本、跑不跑得成功。差別只在於，傳統搜尋至少公開說明了自己會執行腳本，多數 AI 工具連這一點都不承諾。

一次修正，兩邊同時受益。Google 的 AI 功能仍以既有搜尋索引為基礎，不需要為了 AI 另塞特殊標記，可抓取、可索引這套基礎就是同一套。各種自動瀏覽與代理上網的行為差異，AI 代理瀏覽的準備有完整討論。

檢索增強生成的基本原理也支持同一個結論：系統先從來源取得內容，生成回答時才有材料可用，先被讀到，才談得上被引用，原理的展開見RAG 的運作原理。技術可讀性是入場券，被引用與否，取決於各服務自己的挑選機制，這一點沒有人能保證。

所以對AI Overviews這類功能的合理期待是：修正讓網站取得被讀取的資格，引用與推薦則是內容、需求與競爭之後的事。名詞與方法的地圖，可以從GEO、AEO 與 LLMO 的比較讀起；實際排程再參考AI 搜尋的實務做法，先把同一套基礎做完，其他調整再往上加。

把診斷寫進流程：驗收單與行事曆

這次修好了，下次改版會不會又悄悄破功？會，除非把檢查變成流程。視覺驗收會過，瀏覽器測試會過，唯獨搜尋引擎的視角沒有人負責看；把這個視角寫進驗收單，問題才會在上線前被擋下。

驗收單加三道關卡：新舊版原始碼對照，確認舊站讀得到的內容新站一樣讀得到；代表性頁面的渲染抽查，每種頁型挑幾頁跑即時測試；索引標籤核對，title、canonical、robots 的值逐項確認。上線前後各跑一次，把舊站可讀取的內容逐項列冊，在新站逐項確認仍可取得。

推進的節奏用時間框取代一次性專案。本週做免工具的原始碼抽查與收錄對照；本月完成商業價值最高那批頁面的處方施作；每季固定跑一次渲染覆核，菜單是索引報表趨勢加代表性頁面的網址檢查，改版後強制加跑一輪。行事曆一旦排下去，檢查就不再是誰有空誰做，而是有名字、有日期的排程。優先序以流量與轉換貢獻排序，長尾頁面分批處理，不必齊頭並進。

驗收的標準從頭到尾只有一條：索引裡的內容與站上實際的內容一致，而不是短期的流量數字。修正前後的證據留存，事後才有辦法歸因；網址大量異動或平台轉移，另有完整流程要走，渲染檢查是其中一節。修好可見性，換來的是索引資格與穩定性，排名與引用仍取決於內容、需求與競爭，這條邊界在開頭講過，收尾再劃一次。基礎觀念的補課，從SEO 入門開始就好。