Google 會抓取索引網站的JavaScript連結

你網站上那些靠 JavaScript 跑出來的連結，Google 真的抓到了嗎？這是很多用 React、Vue 或 Next.js 架站的站長不敢確認的問題。先給答案：會。Google 從 2014 年起就透過 官方 Webmaster Central Blog 公開承認會用無頭 Chromium 渲染網頁、發現並索引經由 JavaScript 動態產生的連結；現行 Google Search Central 的 JavaScript SEO 文件 也維持同一立場。但「會抓」不等於「每次都抓得到」，關鍵在 Google 採兩階段流程，JS 連結要等到第二階段渲染才被發現，延遲從數小時到數週都可能，所以你那條剛上線的 JS 連結三天沒被收錄，通常是正常現象，不是壞掉。

TL;DR：Google 抓得到 JavaScript 注入的正規 <a href> 連結，權重也會傳，但它發生在第二階段渲染，受 crawl budget 與資源封鎖影響；onclick、div 偽連結、純 SPA 路由則不穩甚至被忽略。重要連結請用純 HTML，再用 Search Console 驗證。

先講結論：Google 會抓 JS 連結，但「會抓」不等於「每次都抓得到」

直接回答最常被搜的那句「Google 會抓取 JavaScript 連結嗎」：會，而且不只內部連結，連別人用 JS 動態注入指向你的 反向連結，渲染成功後 Google 也會識別。但這個「會」後面藏了一堆條件，多數文章只講前半段，把後半段省略，結果讀者過度樂觀，以為用 onclick 寫連結也沒事。

用白話講整件事的機制。Google 對一個網頁分兩步處理。第一步只用 HTTP 把伺服器回傳的原始 HTML 抓回來，這一步只看得到伺服器端渲染（SSR）的內容；第二步才把頁面排進渲染佇列，用一個叫 Web Rendering Service（WRS）的元件、搭配無頭版本的 Chromium 去執行 JavaScript。JS 注入的連結、AJAX 載入的商品、動態分頁，全部要等到第二步才會被發現。

這就是為什麼「理論上會抓」和「你那條連結真的被收錄」之間有一段距離。第一步是即時的、資源便宜的；第二步是排隊的、資源貴的，要消耗 技術 SEO 常講的 crawl budget。網站越大、JS 越重，第二步就越慢，甚至可能因為資源被 robots.txt 擋掉、JS 檔案過大被截斷、或執行逾時，整批連結一起漏掉。

所以遇到 GSC 出現「已建立索引但未包含內容」這類問題，第一個該懷疑的就是渲染階段出了狀況。Google 看得到 JS 連結，但看到需要時間、需要資源、需要你沒自己把路堵死。

• 官方從 2014 年就承認會處理 JS，但請引用現行的 developers.google.com/search/docs 作為更可靠的佐證來源。
• 第一波抓取只看 server HTML，第二波渲染才發現 JS 連結，兩波之間有延遲。
• JS 連結會不會被收錄，取決於渲染是否成功，而渲染成功取決於資源沒被封鎖、JS 沒出錯、沒被 crawl budget 限制。

我自己習慣等 7 到 14 天再用 Search Console 下判斷，第一天就焦慮、急著改程式，通常只是嚇自己。先確認機制，再決定要不要動手。如果你想從源頭理解 Google 怎麼運作，先看一篇 Google 搜尋的運作方式 會更有概念，因為兩階段索引只是整個爬取、索引、排名流程裡的一段。整站的 網站架構 與 內部連結最佳化 如果本身亂，再正確的 JS 連結也會被架構問題拖累。

還有一個常被忽略的點：在 行動優先索引 下，Google 看的是手機版渲染結果，桌上版正常不代表手機版 JS 也跑得起來。所以驗證時請用手機版的網址與使用者代理，否則你修了半天修到的根本不是 Google 實際看到的版本。

什麼是 JavaScript 連結？正規 a href、onclick、SPA 路由的差別

「JavaScript 連結」其實是個模糊的統稱，實際涵蓋三種層次完全不同的寫法，把它們混為一談，是很多站長誤判的起點。有人說「JS 連結 Google 抓得到」是對的，有人說「JS 連結不可靠」也是對的，因為他們講的根本不是同一種東西。

第一種：用 JS 動態插入正規 a href 標籤

這種是「最安全的一種 JS 連結」。畫面上看似是用 JS 產生的，但實際產出的是標準 <a href="真實網址"> 標籤。例如一個 內部連結 清單是前端 JS 根據資料庫渲染出來的，或一個 AJAX 分頁點下一頁後，JS 把新的文章列表連結插進 DOM。這種 Google 渲染後抓得到，權重也會傳。

WordPress 很多外掛產生的目錄、麵包屑、相關文章區塊就屬於這類，Google 抓得到，但建議照後面的方法用 GSC 驗證一次。

第二種：onclick 或 div 加點擊事件模擬連結

這種是地雷。寫法長得像 <div onclick="location.href='/product'"> 或 <span onclick="...">，視覺上是連結，但程式碼裡沒有 <a> 標籤，也沒有 href。Google 官方明確警告，這種寫法不視為連結，無法穩定傳遞權重，On-Page SEO 上等於不存在。

很多老網站當年就是這樣寫的，要全改成本不低，但起碼把首頁導覽、分類、重要商品頁這種關鍵連結先救回來，改回 <a href>。

第三種：SPA 框架的純路由切換

React Router、Vue Router 這類前端路由，如果只用 History API 切換畫面、但 DOM 裡沒有對應的真實 <a href>，那 Google 看到的是單一頁面，不會當成多個獨立頁面收錄。這就是「網站用 React 做的 SEO 會不會有問題」這類搜尋背後真正的痛點。要嘛搭配 SSR 或預渲染，要嘛確保每個路由都有實體 <a href> 連過去，外部連結 與內部連結的處理邏輯一致。

JS 連結寫法	Google 抓不抓	傳不傳權重	要不要改
JS 動態插入正規 <a href>	抓得到（第二波渲染後）	渲染成功就傳	不用，但建議 GSC 驗證
<div onclick> / <span onclick>	視為不可靠，常被忽略	幾乎不傳	務必改成 <a href>
SPA 純 JS 路由、無實體 a 標籤	看不到獨立頁面	無法傳	上 SSR 或預渲染

這張對照表是全文最該被引用的區塊。先搞清楚自己網站屬於哪一種，再決定要不要緊張。挑連結寫法時，可以把它跟 錨文字 的設計一起想：就算用對了 a href，錨文字如果是「點這裡」，傳遞的相關性訊號還是弱。連結的 主題權威 傳遞也跟整站內容是否形成 主題叢集 有關，單點修一條連結效果有限。

兩階段索引是什麼：為什麼 JS 連結不是「馬上」被抓

很多站長的焦慮來自時間差：剛上線的 JS 連結，過了好幾天 Google 還沒收錄，就懷疑網站壞了。其實這是兩階段索引的正常表現，不是 bug。根據 Google 官方對爬蟲與索引流程的說明，抓取與渲染是分開排程的兩件事。

第一波：抓取原始 HTML

第一波 Googlebot 只看伺服器回傳的 HTML。如果你這頁是純前端渲染，那第一波拿到的可能只是個空殼 <div id="root">，裡面的連結在這階段全部看不到。這不代表沒救，只是要等下一波。

第二波：WRS 渲染佇列

第二波才把頁面排進 WRS 的渲染佇列，用 Chromium 跑 JavaScript，這時 JS 注入的連結、AJAX 內容、動態分頁才會被發現。延遲不固定：小型網站可能幾小時就渲染完，大型網站或 JS 很重的網站，可能要等更久，甚至在 crawl budget 緊的時候被往後排。這也是 加速索引 跟連結能不能被發現高度相關的原因。

Google 早已 停止公開提交網址服務，所以你不要指望手動提交能跳過渲染佇列，它能加速第一波，但第二波還是得排。

• 第一波：只看 server HTML，純前端 JS 連結看不到。
• 第二波：WRS 用 Chromium 跑 JS，這時才發現 JS 連結。
• 延遲從數小時到數週都有，視網站規模與 crawl budget 而定。
• 實務建議：等 7 到 14 天再用 Search Console 確認，別第一天就下「沒被抓」的結論。

說到底，兩階段索引是 Google 為了控制成本設計的妥協，不是針對你。理解這個機制，你才不會把正常的延遲誤判成網站出問題。網頁速度也會影響渲染佇列的處理順序，網頁速度對 SEO 的影響 不只是排名訊號，也會回頭影響 JS 連結被發現的速度。如果同時有 重複內容 問題，Google 還得先花資源判斷正本，等於再拖慢渲染。把 SERP 上你想搶的位置當目標，倒推回來決定哪些連結值得放到第一波 HTML，會比一律依賴 JS 更務實。

JS 連結會傳遞權重嗎？差別在「條件」而非「有沒有」

這是原文拋出來但沒講透的問題。答案要分兩層講。第一層：渲染成功之後，JS 注入的正規連結，傳遞的權重與一般 HTML 連結沒有本質差異；寫在 JS 裡的 301 轉址，Google 也會跟隨並傳遞訊號。第二層：但這一切的前提是「渲染成功」。

所以與其問「權重一不一樣」，不如問「這條連結有沒有可靠地被渲染到」。一般連結在第一波就生效，JS 連結要等渲染，而渲染取決於 JS 沒報錯、資源沒被 技術 SEO 錯誤 擋住、檔案沒大到被截斷。任何一個條件沒滿足，本來該傳的權重就消失了。

寫在 JS 裡的 301 轉址 也一樣。Google 會處理，但要等渲染。如果你想確保轉址訊號第一時間就生效，轉址應該寫在伺服器層，不要依賴前端 JS 觸發。在連結權重整體被討論會不會變薄的趨勢下（參考我們對 外部連結權重下降 的整理），讓重要連結穩定被識別更重要，不是更不重要。

JS 報錯時，權重會怎樣

一個常被忽略的風險：只要 JS 丟出一個未捕捉的例外，整段渲染可能中斷，後面所有靠 JS 注入的連結全部消失，不只是壞掉那一條。我碰過一個案子，客戶的相關文章區塊整批連結長期沒被收錄，追到後來查出來是某個廣告外掛的 JS 在某個頁面拋錯，把整個渲染流程打斷。修掉那個錯，兩週後連結陸續進索引。

這個例子要傳達的重點是：JS 連結的權重傳遞是「全有或全無」式的脆弱。要穩，就把關鍵連結放進 server HTML。連結權重的分配也跟 連結建立策略 的整體佈局有關，與其把賭注押在單一條 JS 連結能不能被渲染，不如讓 外部連結與反向連結 的來源更多元。講到連出去的目標網站，HTTPS 連到 HTTP 是否影響 SEO 也是常被問的延伸問題，原則同樣是看渲染後的實際連結屬性，而不是寫法。

JS 連結的好處與壞處：原文只講了一半

原文點出 JS 連結的好處跟壞處，但壞處講得太輕。兩面都攤開來看，你才知道自己網站到底是在佔便宜還是在踩雷。

好處：現代網站功能不會因為用了 JS 就失去 SEO 價值

動態分頁、個人化推薦、用單一 JS 檔集中管理外部連結，這些現代網站常見的功能，只要產出的是正規 <a href>，渲染後都能正常發揮作用。你不必為了 SEO 把所有動態功能砍掉重練。

壞處 1：被植入惡意連結而渾然不覺

這是最危險的一塊。不懂程式的站長根本不知道 JS 裡藏了什麼，一旦被植入壞連結、被加進垃圾導向的 JS（這正是 SEO 中毒 常見的手法），這些連結也會被 Google 一起抓到、算到你網站頭上，反而拖累排名。原文提到風險但沒講怎麼排查，這個缺口後面的章節會補。

壞處 2：渲染失敗時整批連結一起消失

前面講過，JS 報錯或資源被封鎖會讓整批連結漏抓。對純內容站來說，很多 JS 連結其實可以改成純 HTML，風險更低、效果一樣，沒必要賭渲染。優質的 自然反向連結 取得不易，不要讓自己網站的內部連結因為渲染問題白白流失。

壞處 3：吃掉 crawl budget，拖慢整站收錄

JS 很重的網站，Google 每渲染一頁要消耗的資源遠高於純 HTML 頁，在 crawl budget 受限的情況下，整站被收錄的速度變慢。大網站尤其有感，這也是最常被忽略的技術 SEO 問題之一。

誠實講一句：對純內容站，多數 JS 連結改回純 HTML，成本不高、風險明顯下降，沒有理由堅持用 JS。JS 連結真正不可取代的場景，是那些「內容必須根據使用者狀態動態決定」的功能，例如登入後才出現的選單。連 Google 自己的 內部 SEO 策略 也強調「做出小改變、接受新技術」，但不代表把所有東西都丟給前端 JS。John Mueller 在多場直播講過 網站越簡單 Google 越容易懂，這句話套到連結策略一樣成立：能讓爬蟲一眼看懂的連結，就別讓它繞路。

怎麼用 Search Console 驗證 Google 真的看到你的 JS 連結

理論講再多，不如動手驗證。用 Google Search Console 的「網址檢查」工具，你可以直接看到 Google 渲染後實際抓到的版本，這是判斷 JS 連結有沒有被抓最可靠的方法。底下是 4 步驟實戰。

步驟 1：打開網址檢查，輸入要驗證的頁面

登入 GSC，在頂端搜尋框輸入你想驗證的完整網址。如果你之前被 GSC 的 PageSpeed 警告 嚇過，這裡的介面是同一個，不用緊張。

步驟 2：點「測試線上網址」，再看「查看已渲染的畫面」

點進去後選「測試線上網址」，等 Google 重新抓取與渲染。完成後你會看到「已檢索的網頁」與「已渲染的網頁」兩個分頁，前者是第一波拿到的 HTML，後者是第二波渲染後的 HTML。

步驟 3：比對兩份 HTML 的連結差異

重點來了。如果某條連結只出現在渲染版、沒出現在檢索版，代表它確實是靠 JS 渲染才被發現，這正常。如果連渲染版都沒有，那就是渲染失敗或 JS 出錯，要往下一步排查。這個比對法也能用來抓出「已建立索引但未包含內容」的真正原因。

步驟 4：渲染版缺連結時，檢查這三件事

• robots.txt 是不是封鎖了 JS 檔或 CSS 檔（Google 渲染需要這些資源）。
• JS 有沒有 console 錯誤，瀏覽器開發者工具直接看。
• JS 檔案是不是大到被截斷或逾時。

輔助工具方面，Screaming Frog 開啟 JavaScript 渲染模式可以預先批次抓出問題頁，免費的 Google SEO 工具 裡也有幾個能輔助檢查。預先抓問題，比等 Google 收錄失敗再救快得多。驗證時也順手看一下 GSC 的 PageSpeed 警告，速度分數差的頁面，渲染排程常常也比較慢。

習慣每季把重點頁面丟進 PageSpeed Insights 跑一次，等於同時監控速度與渲染健康度，這也是 改善 SEO 的免新文章技巧 裡最划算的一項。把驗證流程固定下來，比每次出問題才急著找工具有效率得多。

最常見的 4 個錯誤寫法：抓不到或抓到反而扣分

整理實務上最常見、也最該避免的四種寫法。前三種會讓你該有的連結權重流失，第四種是被動輸出壞連結的雙重風險。

錯誤 1：div 或 span 加 onclick 偽連結

Google 官方明說不視為連結。改成 <a href> 才會被當連結，這是技術 SEO 排查時第一個該清的項目。

錯誤 2：純 onclick 事件導航，沒有實體 a 標籤

常見於「為了動畫效果」把整個選單做成 JS 事件。解法是補上 <a href> 做漸進增強：HTML 先有連結，JS 再疊加互動，兩者不衝突。對 WordPress SEO 來說，多數佈景主題已經是正規寫法，自訂選單才容易踩到。

錯誤 3：SPA 沒有真實 URL 與 SSR

純前端切換畫面、沒有對應網址，Google 看不到獨立頁面。用 Next.js、Nuxt 的 SSR 或預渲染解決，確保每個路由都有可被直接抓取的 URL。一個常見的誤解是「我用了 Next.js 就沒事」，其實 Next.js 也能設成純用戶端渲染，若沒明確開啟 SSR 或靜態匯出，產出的 HTML 一樣是空殼，連結還是等於不存在。框架只是工具，重點是你交付給爬蟲的那份 HTML 裡到底有沒有連結。

錯誤 4：放任第三方外掛或廣告 JS 注入來路不明的連結

這是資安與 SEO 的雙重風險，跟 SEO 中毒直接相關。定期用 GSC 渲染檢視、審查外掛與廣告碼，看頁面上實際多了哪些你沒寫的連結。

一個共通原則貫穿這四種錯誤：關鍵連結（首頁導覽、分類、重要商品頁、重要文章入口）一律用純 HTML <a href>，不要賭渲染。裝飾性、登入後才出現的次要連結，才放寬用 JS。如果還想知道連結屬性怎麼搭配，nofollow、sponsored、ugc 三大屬性 的整理把贊助與 UGC 連結的處理講得很清楚；而整體網站該怎麼排連結層級，網站程式碼最佳化 跟 頁面 SEO 最佳化 有更系統的做法。

標題與標籤層面也不能放著不管。H1、H2 標題標籤的 SEO 寫法 會影響 Google 解析連結所處區塊的權重，同一條連結放在 H2 底下跟放在頁尾，傳遞的訊號強度不同。連結寫法、屬性、擺放位置三件事一起顧到，才算完整。

2027 年的調整：AI 搜尋爬蟲根本不執行 JavaScript

這是 2027 年最該寫進連結策略的新變數。主流 AI 搜尋引擎的爬蟲，包含 ChatGPT、Perplexity 這個 AI 答案引擎，以及 Google AI Overviews 的部分流程，大多不執行 JavaScript，或執行能力遠弱於 Googlebot。這代表只靠 JS 注入的連結與內容，AI 搜尋可能完全看不到、也收錄不到對應頁面。

換句話說，你的 JS 連結可能進得了 Google 傳統索引，卻進不了 AI 引用池。在 AI SEO 當道的年代，這個落差會越來越傷。

實測上有一個很快的驗證法。把你的網址丟進 ChatGPT 或 Perplexity，問它「這個頁面有哪些連結」或「這個頁面在講什麼」。如果它答出來的內容明顯缺了靠 JS 載入的那一塊，就代表 AI 爬蟲拿到的只是第一波空殼 HTML，你那些動態產生的連結與內容對它而言等於不存在。這個測試不用任何工具，三十秒就做完，卻能直接看出你的網站對 AI 引用池到底開不開門。

面向	Google 傳統爬蟲（Googlebot + WRS）	多數 AI 搜尋爬蟲
是否執行 JavaScript	是（第二階段渲染）	多半不執行或極弱
JS 注入連結的命運	渲染後可被發現與收錄	常常完全看不到
核心內容該放哪	SSR 仍建議，但 JS 路徑走得通	務必放進第一波 server HTML
結構化資料	加分	對 AI 引用更關鍵

2027 年的安全做法

• 核心內容與關鍵連結改用 SSR 或預渲染，確保第一波 HTML 就完整，不要把可被引用的內容賭在第二波渲染。
• 補上結構化資料（結構化資料、BreadcrumbList、SiteNavigationElement），讓 生成式 AI 搜尋 更容易解析你的連結結構。
• 把 JS 退化為體驗增強層，而不是內容與連結的唯一來源。

這不是要你全面拋棄 JS。把 JS 退回它該待的位置就好：動畫、互動、即時更新這類體驗增強，JS 很強；但內容、連結、可被引用的事實，請留在 HTML。Google 官方近年也傾向鼓勵 SSR，dynamic rendering 已被標示為過渡方案，這個方向跟 2027 SEO 趨勢 一致。

如果你還在猶豫要不要為了 AI 搜尋重寫網站，記得這句：AEO（答案引擎最佳化） 的地基，其實就是「讓任何爬蟲在第一波就能讀到完整內容與連結」。做到這件事，傳統 SEO 與 AI SEO 同時受益。從 AI 視角看，AISO 與 GEO（生成式引擎最佳化） 都把「可被引用的事實與連結是否在 HTML 裡」當成基本條件。

這個條件跟生成式 AI 搜尋對內容擷取的要求完全一致。所以與其分頭最佳化 Google 與 AI，不如把「讓第一波 HTML 就完整」當成共通地基，一次解決兩邊。

若想了解搜尋意圖怎麼影響 AI 要不要引用你，可以再看 搜尋意圖 的拆解。講白了，2027 年的連結策略，本質就是「連 Google 都抓得到，AI 也才抓得到」。把這個原則記住，再去決定哪些連結要搬進 server HTML，方向就不會錯。

FAQ 與行動清單：7 個常見問題，加今天就能做的檢查表

講了這麼多，回到最常被問的問題，一次給答案，再附一張今天就能執行的檢查表。

FAQ 1：onclick 連結算反向連結嗎？

不算可靠的。onclick 模擬的連結 Google 不視為連結，自然也談不上傳遞反向連結權重。改用正規 <a href> 才會被當連結處理。

FAQ 2：JS 連結要主動提交給 Google 嗎？

不用。渲染後 Google 會自動發現。但你可以用 sitemap 加速第一波抓取，第二波渲染還是得照佇列排。手動提交已經不是主流做法，詳見我們對 Google 停止公開提交網址的整理。

FAQ 3：被別人用 JS 連到我網站，對我是好是壞？

多數情況是好的，等於多了一條反向連結。但要警覺一種風險：如果你網站突然被大量低品質來源用 JS 方式連進來，可能是把你當成連結農場的目標，這時反而要監控是否被演算法判斷為不自然連結型態。

FAQ 4：我的網站要全面改 SSR 嗎？

不一定。純內容站，先把關鍵連結改回 HTML、補上結構化資料，往往就解決八成問題，不必動到整站架構。只有當你的網站是重度 SPA、且內容大量靠 JS 注入時，SSR 才值得列為優先。

FAQ 5：WordPress 外掛產生的連結 Google 抓得到嗎？

多數抓得到，因為 WordPress 外掛通常輸出的是 server 端 HTML 或正規 <a href>。但少數純前端渲染的外掛例外，建議照前面的 GSC 4 步驟驗證一次。WordPress 站可以參考 WordPress SEO 最佳化的完整做法。

FAQ 6：JS 連結跟 nofollow 混用會怎樣？

nofollow 仍然有效，規則與一般連結一致。要了解三種屬性的差別，看 nofollow、sponsored、ugc 連結屬性的整理即可，不因為連結是 JS 產生而有特殊待遇。

FAQ 7：多久該重新檢查一次 JS 連結？

改版或加新外掛後立即查一次，平時每季跑一次渲染檢查。尤其是裝了新的廣告或追蹤碼之後，務必確認沒有偷偷注入來路不明的連結。

今天就能做的 5 步檢查表

1. 列網址清單：挑出 5 到 10 個你最在意的頁面（首頁、分類頁、主力商品或文章頁）。
2. 跑 GSC 渲染檢查：逐頁比對「已檢索」與「已渲染」兩份 HTML，看連結有沒有缺。
3. 確認關鍵連結是 a href：首頁導覽、分類、重要頁面入口，一律改成純 HTML，不要賭渲染。
4. 審查第三方 JS：檢查外掛、廣告碼、追蹤碼有沒有注入你沒寫的連結。
5. 評估 SSR 必要性：若網站是重度 SPA，把核心內容與連結改 SSR 或預渲染。

回到搜尋意圖。多數人搜「Google 會抓取 JavaScript 連結嗎」，要的不是一篇論文，而是一個明確的「會，但條件是…」加上可執行的下一步。把上面的檢查表跑完，你就比九成還在網路上找答案的站長更清楚自己網站的連結到底算不算數。

最重要的連結，不要讓 Google 猜，更不要讓 AI 爬蟲猜。想系統化把技術 SEO 體質一次補強，從技術 SEO 基礎開始走一遍，會比單點修連結更有效率。