連結可抓取怎麼檢查：導航到 JS 連結排查（2026）
連結可抓取會直接影響發現和抓取。本文從導航、按鈕、卡片和 JavaScript 連結入手，講清檢查順序。
連結可抓取會直接影響發現和抓取。本文從導航、按鈕、卡片和 JavaScript 連結入手，講清檢查順序。
很多網站的收錄問題，表面上像是“Google 沒來抓”。往下查，常常不是抓取頻次不夠，而是連結本身就不夠可抓。導航寫成了按鈕，卡片跳轉靠 JavaScript 事件，分頁只在滾動後才出現，重要頁面藏在表單、彈窗、tab 或搜尋結果後面。使用者點得開，不代表 Google 找得到。
Google 在 Make your links crawlable 文件裡把原則講得很直白：最穩的做法，是使用帶真實 `href` 的 `` 元素，並且讓目標 URL 是一個搜尋系統能解析的地址。反過來，如果頁面跳轉靠 `onclick`、`javascript:`、按鈕事件、表單提交或別的互動邏輯應急，Google 對這些連結的發現能力就會明顯變差。
這篇文章重點放在一件事上：連結可抓取到底怎麼查。不是講文案，不是講點選率，而是講發現路徑。導航、正文內鏈、按鈕、卡片、麵包屑、分頁、JavaScript 路由、篩選和 tab，哪些寫法更穩，哪些寫法最容易讓重要頁面變成孤立頁。
很多團隊檢查頁面時，重點放在“這個 URL 能開啟”。這只是第一步。SEO 裡更關鍵的一步，是“Google 到底能不能順著站內連結把它發現出來”。如果頁面只能靠站內搜尋、使用者篩選、指令碼點選、登入後選單、彈窗入口才能看到，那它就算存在，也可能長期處在弱發現狀態。
這也是為什麼 孤立頁排查、JavaScript SEO 渲染排查 和連結可抓取，實際上是一條線。頁面不是突然丟的。很多時候，是一開始就沒被好好連上。
Google 官方文件給出的建議並不複雜。核心就三條：
這裡最常被忽略的一點，是“可抓取連結”和“能點選的東西”不是一回事。一個 `div`、`span`、`button`，再加上再漂亮的樣式和事件，也不自動等於可抓取連結。前端看的是互動成立，搜尋系統看的是連結關係成立。
| 寫法 | 使用者能不能點 | Google 發現穩定性 |
|---|---|---|
| <a href=”/product/”> | 能 | 通常最穩 |
| <button onclick=”go(‘/product/’)”> | 能 | 不穩 |
| <a href=”javascript:void(0)”> | 能 | 不推薦 |
| 滾動後非同步插入連結 | 通常能 | 取決於渲染與暴露方式 |
另一個常見問題，是把路由狀態寫進 fragment，也就是 `#` 後面。Google 在分頁和 URL 相關文件裡都強調過，fragment 不適合拿來承載你希望被單獨發現的重要內容。使用者能切換，不代表搜尋系統會把它當成一個新的可發現目標。
| href 寫法 | 建議程度 | 原因 |
|---|---|---|
| `/service/seo-audit/` | 推薦 | 目標明確，可抓取，可複用 |
| `#case-list` | 謹慎 | 更適合頁內定位，不適合承載新頁面發現 |
| `javascript:void(0)` | 不推薦 | 實際跳轉依賴指令碼，不是穩定發現路徑 |
| 空 href 或省略 href | 不推薦 | 連結語義不完整，搜尋系統難以判斷目標 |
現代前端裡常見一種說法：我們用了 History API，位址列會變，所以沒問題。這個判斷只說對一半。`pushState` 和 `replaceState` 確實能幫助你把前端狀態變成更像真實頁面的 URL，但前提是這個 URL 本身要穩定、可訪問，而且頁面裡要有正常連結能指過去。
Google 在 JavaScript SEO basics 和 URL structure best practices 裡都給過相近的原則：地址要能被理解，狀態不要全藏在指令碼里。如果 History API 只是幫使用者“看起來換了頁”，卻沒有任何靜態連結、穩定 URL 和一致的服務端響應，那發現問題還是會在。
換句話說，History API 是增強，不是替代。它可以讓體驗更順，但不能替代真正的連結網路。
主導航、二級導航、移動端摺疊選單，是最不該出問題的地方，但現實裡偏偏最常出問題。原因很簡單：設計和前端都愛在這裡加動畫、加展開層、加互動狀態。結果選單看著很完整，底層卻未必留下穩定連結。
常見問題有這些：
如果核心欄目都這麼做，搜尋系統的第一層發現路徑就已經弱了。站點結構再好，也很難完全發揮出來。這個問題和我們站裡那篇 網站架構 SEO 是直接相連的。
麵包屑也是同理。很多站把麵包屑做成純文字，或者把中間層級做成不可點選狀態。這樣使用者也許還能看懂層級，但 Google 失去了一條很穩定的上下級連結路徑。Google 在 Breadcrumb 文件 裡講的是結構化資料，但背後邏輯一樣：層級關係應該清楚、可解釋、可被解析，而不是隻有視覺提示。
很多團隊誤會成“按鈕不能用”。不是這個意思。按鈕當然可以用，尤其是在互動控制、篩選展開、提交動作裡。但如果一個重要頁面的訪問，只能靠按鈕事件觸發跳轉，而沒有任何等價的真實連結，那 SEO 風險就起來了。
Google 在 JavaScript SEO basics 裡反覆強調，基礎發現路徑不要過度依賴複雜指令碼行為。換成更直白的話：按鈕可以保留，但重要路徑最好還有 `` 這條主路。
很多企業站喜歡做大卡片。產品卡片、案例卡片、文章卡片，整塊都能點，使用者體驗上沒毛病。但開發實現時，常見兩種風險：
第一種是典型的不可抓取風險。第二種雖然比第一種好一點，但連結訊號仍然偏弱，尤其當標題連結被樣式壓得很深、很隱蔽時，站內連結網路就不夠清楚。
更合適的做法，通常是讓卡片裡的主標題或核心區域直接使用清楚的 ``，而不是隻靠指令碼接管整個卡片點選。
很多企業站把大量內容藏在站內搜尋和篩選裡。產品型號靠搜尋框搜，案例靠行業下拉框篩，下載資料靠選擇器切換。使用者當然能用。但從 SEO 角度看，這些入口預設都不等於穩定內鏈。
Google 並不會像真實使用者那樣主動去提交表單、嘗試篩選組合、輸入關鍵詞再一路點開結果。這也是為什麼只把頁面放進搜尋結果裡，不給它穩定欄目頁、正文內鏈、相關頁入口，最後很容易變成弱發現頁。類似問題，和 Faceted Navigation 這條線其實是同一個根。
更合適的做法通常是這樣：搜尋和篩選可以保留，但真正重要的集合頁、詳情頁、專題頁，仍然要透過導航、列表頁、正文推薦、麵包屑或分頁等穩定連結系統露出來。
很多人把分頁當成另一個話題。其實分頁能不能被發現，本質上仍然是連結可抓取問題。Google 在 Pagination and incremental page loading 文件裡說得很清楚：Google 通常透過 `` 發現分頁頁，不會替你點按鈕。
所以如果你的“下一頁”“載入更多”只是一個指令碼按鈕，或者無限滾動到底才懶載入下一批結果，那後續內容的發現鏈路就會變得很脆。這個問題，我們剛寫完的 分頁和無限滾動指南 會繼續往下拆。
現在很多站用 React、Vue、Next.js、Nuxt 或別的前端框架。路由切換很絲滑，頁面也確實在變。問題是，有些實現只是前端狀態切換，不一定留下穩定、可請求、可內鏈的 URL。搜尋系統看到的，有時只是一個外殼。
Google 在 Fix search-related JavaScript problems 和前面的 JavaScript SEO 文件裡都在強調：URL、連結、狀態碼、canonical 這些基礎訊號，要能在渲染鏈裡站得住。否則頁面再豐富，發現還是會斷。
如果你的網站大量依賴客戶端渲染，還應該順手檢查兩件事。第一，初始 HTML 裡是否已經露出關鍵連結。第二，渲染後 DOM 裡的連結有沒有被延遲到使用者互動之後才出現。很多專案的問題，不是完全沒有連結，而是連結出現得太晚，太依賴動作。
| 實現方式 | 使用者體驗 | SEO 穩定性 |
|---|---|---|
| 服務端已輸出主連結 | 穩 | 通常最好 |
| 渲染後自動補出連結 | 一般沒問題 | 取決於執行與抓取時機 |
| 點選後才注入連結 | 使用者可用 | 風險高 |
| 只改前端狀態，不暴露 URL | 看起來順 | 風險高 |
企業站很愛把內容塞進 tab。產品引數一個 tab，案例一個 tab，下載一個 tab，FAQ 一個 tab。使用者端看很整齊。但如果這些內容對應的是獨立價值頁面，卻沒有真實連結，只能在當前頁點選切換，那它們就不會自然形成新的發現路徑。
這類問題常見於：
這裡不是說 tab 不能用，而是說別拿 tab 代替站內連結體系。展示層可以收納，發現層還是要把路修出來。
連結可抓取解決的是“能不能走到”，錨文字解決的是“走過去後大概是什麼”。Google 在 anchor text and placement 相關說明裡講得很明確：描述性錨文字更有幫助。對站內發現來說，這一點尤其值錢。
如果一個頁面到處都只被寫成“檢視更多”“點此瞭解”“Read More”，Google 當然未必完全看不懂，但這條站內路徑的語義會明顯更弱。相反，像“技術 SEO 審計清單”“JavaScript SEO 渲染排查”“Google Ads 轉化追蹤指南”這類錨文字，既更利於使用者判斷，也更利於搜尋系統理解頁面關係。
這裡不用走極端，不是每條內鏈都要堆關鍵詞。更重要的是別把所有重要連結都寫成空泛按鈕文案。
更實用的排查順序，通常是這樣：
到了這一步，很多“收錄異常”問題就會開始變具體。不是抽象地說“Google 怎麼不抓我”，而是能明確地說“這個欄目只有按鈕，沒有連結”“這個分頁只有滾動事件，沒有下一頁地址”“這個案例頁只在篩選裡出現，沒有正文內鏈”。問題一旦具體，修起來就快。
如果要做得再穩一點，建議把 Search Console 也一起拉進來。用 URL Inspection 抽查幾個典型 URL，看 Google 選到的 canonical、抓取狀態和最後看到的頁面有沒有偏差。這樣就不會只停留在“我們覺得沒問題”。
還有一個常見誤區：覺得反正 URL 已經進 sitemap 了，就算沒有很好內鏈也無所謂。這個判斷不穩。站點地圖當然有幫助，Google 在 Build and submit a sitemap 文件裡也一直建議提交 sitemap。但 sitemap 更像補充線索，不是替代站內導航、正文內鏈和分頁關係的主系統。
一個頁面如果只存在於 sitemap，卻在站內幾乎沒有任何真實入口，它依然更容易變成弱訊號頁面。換句話說，sitemap 可以告訴 Google “有這麼個 URL”，但站內連結網路才更像在說“這個 URL 在整站裡處在什麼位置，和誰有關係，值不值得經常走”。
連結不可抓，不只是單頁損失。它會連帶帶出三個後果：
所以這篇文章最好和 Orphan Pages、Crawl Budget、伺服器日誌分析 這幾篇一起看。它們不是平行話題，而是一套發現路徑治理的不同切面。
最後給一個更落地的執行順序。很多團隊一發現連結問題，就想一次性全站大翻修。沒這個必要。更值錢的修法，通常是先抓最影響發現效率的地方。
因為前面幾層，決定的是整站最粗的發現主幹。主幹順了，很多深層頁自然會更容易被帶出來。主幹都沒修好，就先去摳邊角元件，通常不划算。
最後說個很現實的點。連結可抓取問題，很多時候不是要推翻頁面設計，也不是要重做整站互動。大量問題只需要改輸出方式：把按鈕外面補上真實連結，把卡片主標題改成 ``，把分頁補成可訪問 URL，把動態選單改成更穩定的連結暴露。
也就是說，這不是“SEO 要求犧牲前端體驗”。更準確地說，是前端體驗和搜尋發現可以同時存在，但前提是別把真正的連結關係藏起來。使用者看到的是頁面，Google 看到的是路徑。路徑順了，很多抓取和收錄問題自然就輕了。