技術 SEO 完整審核清單：從爬蟲設定到 Core Web Vitals 的全站診斷手冊

一個技術問題，可以讓你所有的內容努力付之一炬。Google 在 2026 年的官方聲明中再次強調：爬蟲無法正確讀取的頁面，永遠不會出現在搜尋結果中——無論內容品質多麼出色。

技術 SEO 審核，就是定期為網站做一次全身健康檢查，確保每一個頁面都處於可被發現、可被索引、可被排名的最佳狀態。本文整理了一份完整清單，涵蓋爬蟲設定、Core Web Vitals、URL 架構、行動裝置、HTTPS，以及結構化資料與 JavaScript 渲染六大核心領域，幫你系統化找出隱藏的技術瓶頸。

內容做得再好，技術出錯一樣排不上

許多品牌把 SEO 預算集中在內容創作與外部連結，卻忽略了技術基礎的維護。但技術問題往往最難被發現、影響卻最深。三個數據說明它的份量：

• 擁有 10,000 頁以上的網站，平均有 30% 的爬蟲預算浪費在低價值或重複頁面上，導致核心頁面被延遲爬取。
• Google 在 2025 年底的渲染更新中明確宣佈：非 200 狀態的頁面（301、302、404、500）將不再被渲染，頁面上的 JavaScript 內容對 Google 完全不可見。
• Core Web Vitals 不達標的頁面，在同等內容品質下，排名競爭力顯著低於技術優化到位的競爭對手。

技術審核不是一次性任務，而是需要定期執行的維護工作。建議至少每半年做一次完整審核，並在每次重大改版前後加做一次緊急診斷。

第一層：爬蟲怎麼讀你的網站，你能控制

robots.txt：爬蟲進門前讀的第一份規則

robots.txt 是 Google 爬蟲進入網站時讀取的第一份文件，決定哪些目錄和頁面可以被爬取。三個最常見的踩雷：

• Disallow 了整個網站：上線後忘記移除開發環境的 Disallow: / 設定，導致全站無法被索引。
• 過度開放：放任爬蟲進入後台登入頁、購物車頁等無排名價值的頁面，白白消耗爬蟲預算。
• 與 Canonical 或 Sitemap 衝突：頁面在 robots.txt 中被 Disallow，卻又出現在 Sitemap 中，對 Google 發出矛盾信號。

審核要點：用 Google Search Console 的「URL 檢查」確認每個重要頁面是否允許爬取，同時檢查 /robots.txt 是否有語法錯誤。

XML Sitemap：主動把重要頁面遞到 Google 面前

Sitemap 的作用是主動引導 Google 去爬你認為重要的頁面。一份健康的 Sitemap 應該做到：

• 只包含可索引的 200 狀態頁面，排除已刪除、已 noindex 或重定向的頁面。
• 定期更新，新頁面發布或頁面刪除後立即同步。
• 大型網站使用分割式 Sitemap（Sitemap Index），每個子 Sitemap 不超過 50,000 個 URL。

爬蟲預算：別讓 Google 把次數花在垃圾頁上

爬蟲預算是指 Google 在特定時間內願意爬取的頁面數量。中小型網站通常不必擔心，但大型電商或部落格若能管好爬蟲預算，重要頁面的索引速度會明顯加快。

最常見的四個漏洞：

• 無限的分頁（Pagination），如 /page/1、/page/2...page/500
• 大量的篩選器參數 URL（如電商的顏色、尺寸、排序組合）
• 未加 noindex 的測試頁面或暫存頁面
• 爬蟲能進入的無限深度目錄（Infinite Scroll 或動態生成的 URL）

Canonical：告訴 Google 哪個版本才算數

當多個 URL 提供相同或相似內容時，Canonical 標籤負責指認「正確版本」，把排名權重集中過去。四種常見的 Canonical 出錯情境：

• HTTP 與 HTTPS 版本同時存在，卻沒設 Canonical。
• 有無結尾斜線的版本（/page vs /page/）被當成兩個不同頁面。
• 帶 UTM 參數的 URL 被誤索引（?utm_source=...）。
• Canonical 指向的 URL 本身又指向另一個 Canonical，形成 Canonical Chain。

第二層：Core Web Vitals 三個指標，逐項抓問題

Core Web Vitals 是 Google 自 2021 年起正式納入排名因素的使用者體驗指標，並在 2024 年以 INP（Interaction to Next Paint）取代了舊的 FID（First Input Delay）。2026 年的標準門檻如下：

每項指標的完整優化方法，我們已在Core Web Vitals 優化指南中詳述。這裡補上 2026 年值得特別留意的三個診斷重點：

• LCP：確認最大內容元素（通常是英雄圖片或 H1）有設 fetchpriority="high"，並用 WebP 壓縮。別讓 CSS 背景圖片成為 LCP 元素——Google 無法像 <img> 標籤一樣提前預載它。
• INP：INP 測的是任意互動（點擊、鍵盤輸入）的響應延遲，長 JavaScript 任務（超過 50ms 的同步 Long Tasks）是主因。用 Chrome DevTools 的 Performance 面板找出並切分這些任務，或用 setTimeout 讓任務主動讓出主線程。
• CLS：所有圖片和廣告都要設明確寬高比（HTML 的 width、height 或 CSS 的 aspect-ratio），避免載入後推擠版面。動態插入的廣告或嵌入內容尤其要事先預留空間。

第三層：URL 與重定向，別讓權重在路上漏光

乾淨 URL 的三個原則

語意清晰的 URL 不只對使用者友善，也讓 Google 更容易理解頁面的主題層次。審核時對照這三點：

• 使用小寫英文和連字號（hyphen），避免底線、空格或特殊字元。
• URL 深度盡量不超過 3-4 層（/category/subcategory/page），過深的頁面爬取優先級較低。
• 避免無意義的 ID 參數（如 /page?id=12345），SEO 友善的 URL 應包含目標關鍵字。

重定向鏈：每多一層 301，就漏掉一點權重

重定向鏈（Redirect Chain）是技術 SEO 最容易越積越多的問題。每次改版、頁面搬移都可能疊上新的一層，而每增加一層 301，都有輕微的 Link Equity 損耗，同時拖慢載入時間。

審核要點：用 Screaming Frog 的「Response Codes」報告篩出所有重定向 URL，確認有沒有 A→B→C 的多層鏈，並把它們直接改成 A→C。

孤兒頁面：沒人連到它，Google 也難找到它

孤兒頁面是指沒有任何內部連結指向的頁面。問題在於 Google 可能長時間發現不了它、也難以重新爬取，而且它的 PageRank 無法靠內部連結補強。

診斷方法：把 Screaming Frog 爬出的所有 URL，與 Google Analytics 或 Sitemap 的 URL 清單比對。出現在 GA／Sitemap、卻不在 Screaming Frog 內部連結網絡裡的頁面，就是孤兒頁面。

第四層：手機版才是 Google 的判斷依據

Mobile-First Indexing：Google 看的是手機版

自 2023 年起，Google 已全面切換為 Mobile-First Indexing，判斷排名時依據的是手機版內容，而非電腦版。審核要點：

• 手機版與電腦版的內容必須一致：確認核心 SEO 內容（H1、H2、正文、結構化資料）沒有因響應式設計而被折疊隱藏。Google 仍會索引折疊內容，但某些 UI 框架以 JS 條件式渲染手機版，可能讓 Google 抓到的是空白狀態。
• 圖片在手機版的載入尺寸是否適當：別載入桌機大圖再縮小顯示，改用 srcset 提供響應式圖片。
• 字體大小至少 16px，可點擊元素（按鈕、連結）間距至少 48×48px，避免 CLS 和誤觸。

HTTPS：別讓瀏覽器幫你掛上警告

HTTPS 本身是 Google 的輕微排名信號，但更關鍵的是它直接影響使用者信任與瀏覽器警告。三項必查：

• 所有 HTTP 頁面是否都 301 重定向到 HTTPS 版本？
• SSL 憑證是否在有效期內？用 Let's Encrypt 免費憑證的話，要留意 90 天自動更新是否正常運作。
• 有沒有 Mixed Content 問題：頁面已是 HTTPS，但內嵌的圖片、字型、腳本仍走 HTTP，會被瀏覽器阻擋或警告。

第五層：結構化資料與 JavaScript 渲染

結構化資料（Schema Markup）幫助 Google 和 AI 搜尋引擎更準確理解頁面內容，進而取得 Rich Results（精選摘要、FAQ、商品評分等）。各類型的實作方式，我們在Schema 結構化資料實戰指南中已詳細說明。審核時請確認：

• 用 Google Rich Results Test 確認每個關鍵頁面的結構化資料能正確觸發 Rich Snippets。
• 檢查 Search Console 的「增強」報告，確認沒有結構化資料錯誤或警告。
• 確認 JSON-LD 語法正確，特別注意引號、括號和逗號的完整性。

SPA 框架的渲染陷阱：錯誤頁對 Google 是黑盒

如果你的網站用 React、Vue 或 Angular 等 SPA 框架，JavaScript 渲染就是必須特別盯緊的環節。Google 渲染 JavaScript 的速度比解析靜態 HTML 慢，而且 2025 年底更新後，非 200 狀態頁面完全不再渲染 JavaScript——這意味著客戶端渲染出來的錯誤頁面，對 Google 是完全不透明的。

更完整的 SPA SEO 優化策略，可參考我們的JavaScript SEO 完整指南。

該用哪些工具？一張表看懂優先順序

其中 GSC 是技術審核的第一步、也是最重要的一步。如何用它的免費數據揪出技術問題，我們在Google Search Console 進階使用指南中有完整拆解。

多久審一次？一份從每週到每年的節奏表

• 每週：檢查 Search Console 的 Coverage 錯誤和 Core Web Vitals 警告，及早抓到新冒出的技術問題。
• 每月：用 Screaming Frog 做小規模爬取，追蹤重定向鏈和新出現的 404 錯誤。
• 每季：執行完整的全站技術審核，涵蓋上述五個層面。
• 每年：深度審核資訊架構與主題叢集結構、確認 SSL 憑證自動更新機制、清點技術債（舊版 CMS、廢棄的 JavaScript 函式庫），並對照當年度 Google 演算法更新檢查是否有新增技術要求。
• 緊急觸發：核心演算法更新後流量異動超過 20%、網站改版或域名遷移前後、發現大量頁面突然從 Search Console 索引中消失。