技術 SEO 是什麼？就是確保 Google 爬蟲能順利讀取、理解、索引你的網站。這份清單整理了 2026 年最重要的技術 SEO 檢查項目，從基礎到進階，照著做一遍，你的網站技術體質就會大幅改善。

（資料基準：2026-04-03）

技術 SEO 是什麼？

先講結論：技術 SEO 是所有 SEO 工作的地基。如果你的網站技術面有問題，內容寫得再好、反向連結再多，Google 可能根本看不到你的頁面。

你可以把 SEO 想成三根柱子：

  • 技術 SEO：讓 Google 能爬取、理解、索引你的網站
  • On-Page SEO：讓每個頁面的內容和標籤都針對目標關鍵字優化（詳見 On-Page SEO 教學）
  • Off-Page SEO：透過外部連結和品牌提及建立網站權威

技術 SEO 不需要你會寫程式，但你需要知道哪些東西要檢查、怎麼檢查、出問題怎麼修。這就是這篇清單的目的。完整的 SEO 學習路徑可以參考 SEO 完全教學。

一般來說，一個中小型網站（500 頁以下），花一個下午認真跑完這份清單，就能解決 80% 的技術 SEO 問題。剩下的 20% 是進階問題，我們在後面也會聊到。

爬取（Crawling）檢查清單

結論先講：如果 Google 爬蟲進不來你的網站，後面所有的 SEO 工作都是白做。爬取是整個流程的第一步——Google 派出爬蟲（Googlebot）去讀取你網頁的內容，然後才能決定要不要收錄。

robots.txt 檢查

robots.txt 是一個純文字檔案，放在你的網站根目錄（https://yourdomain.com/robots.txt），告訴爬蟲哪些地方可以去、哪些不行。

檢查項目：

  • 確認 robots.txt 存在且可以被讀取（用瀏覽器直接打開網址看看）
  • 沒有意外地封鎖了重要頁面（常見錯誤：Disallow: / 會封鎖整個網站）
  • 確認 Sitemap: 指令有指向你的 sitemap.xml
  • 不要用 robots.txt 來隱藏頁面——它不是安全機制，Google 有時候還是會索引被 Disallow 的頁面

在 Google Search Console 裡有一個 robots.txt 測試工具，可以直接測試特定 URL 是不是被封鎖了。

Sitemap.xml 檢查

Sitemap 是你主動告訴 Google「我的網站有這些頁面，請來看看」的方式。

檢查項目：

  • sitemap.xml 存在且格式正確（可以用瀏覽器打開確認）
  • 已經在 Search Console 中提交
  • 只包含你想被索引的頁面（不要放 noindex 頁面、不要放 404 頁面）
  • URL 數量不超過 50,000 個（超過就要拆分成多個 sitemap）
  • 包含 <lastmod> 標籤，而且日期是真正的最後修改日期（不要每天自動更新所有頁面的日期，Google 會忽略你的 sitemap）

Crawl Budget 優化

Crawl budget 就是 Google 願意花多少資源來爬取你的網站。小網站（幾百頁）通常不用擔心這個問題。但如果你的網站有上萬頁，或者頁面載入很慢，crawl budget 就會成為瓶頸。

優化方式：

  • 移除或 noindex 低品質頁面（空白頁、重複頁、過時內容）
  • 修復 404 和伺服器錯誤——Google 每次遇到錯誤頁面就浪費了一次爬取機會
  • 減少參數型 URL（?sort=price&page=2 這類）產生的無限頁面
  • 提升頁面載入速度——Google 會爬得更快
檢查項目工具合格標準
robots.txt 可讀取瀏覽器直接打開回傳 200 狀態碼
重要頁面未被封鎖Search Console robots 測試全部顯示「已允許」
Sitemap 已提交Search Console狀態顯示「成功」
Sitemap 中無錯誤 URLScreaming Frog0 個非 200 狀態碼的 URL
爬取錯誤數量Search Console 涵蓋範圍報表錯誤數逐月減少

索引（Indexing）檢查清單

結論：爬取到了不代表會被索引。Google 會判斷你的頁面值不值得收錄。索引問題通常比爬取問題更常見，也更容易被忽略。

Canonical 標籤

當同一個內容有多個 URL 時（例如有 www 和沒有 www 的版本），canonical 標籤告訴 Google 哪個是「正版」。

檢查項目：

  • 每個頁面都有 <link rel="canonical" href="...">
  • Canonical 指向的是你想被索引的版本
  • 不要在 noindex 頁面上設定 canonical 指向另一個頁面（這會讓 Google 困惑）
  • 分頁系列（page 1, 2, 3...）各頁的 canonical 應該指向自己，不是全部指向第一頁

Noindex 使用

在 meta 標籤中加入 <meta name="robots" content="noindex"> 可以告訴 Google 不要索引這個頁面。

應該 noindex 的頁面：

  • 搜尋結果頁（站內搜尋產生的頁面）
  • 感謝頁面（表單送出後的頁面）
  • 後台管理頁面
  • 測試頁面和暫存頁面
  • 標籤頁和篩選頁（如果內容跟其他頁面高度重複）

常見錯誤：不小心在重要頁面加了 noindex。我們就遇過客戶的開發人員在上線時忘記把測試環境的 noindex 移除，整個網站從搜尋結果消失了兩週。

重複內容處理

Google 不會因為重複內容「處罰」你，但它會自己選一個版本來索引，不一定選你想要的那個。

常見重複內容來源：

  • HTTP vs HTTPS 版本（應該 301 重導向到 HTTPS）
  • 有 www vs 沒有 www（選一個，另一個 301 重導向）
  • 結尾有斜線 vs 沒有斜線（/about/ vs /about）
  • URL 參數產生的重複頁面（?ref=facebook 之類的追蹤參數）
  • 印表機版本、AMP 版本等同內容的不同版本

用 Screaming Frog 爬一遍你的網站，它會自動標出哪些頁面有重複的 Title Tag 或 Meta Description，這些通常就是重複內容的線索。

檢查項目工具合格標準
每頁有 canonical 標籤Screaming Frog100% 頁面有 canonical
重要頁面未被 noindexSearch Console 索引報表0 個意外 noindex
無重複 Title TagScreaming Frog每頁 title 獨特
HTTP 重導向到 HTTPS瀏覽器直接輸入 http:// 測試自動跳轉到 https://
索引頁面數量Search Console 或 site: 搜尋接近 sitemap 中的 URL 數

網站速度優化

結論：網站速度是 Google 的排名因素之一，也直接影響使用者體驗。根據 Google 的資料，頁面載入時間從 1 秒增加到 3 秒，跳出率增加 32%；從 1 秒到 5 秒，跳出率增加 90%。

Core Web Vitals

Core Web Vitals 是 Google 衡量網站使用者體驗的三個核心指標：

LCP（Largest Contentful Paint）——頁面最大元素載入完成的時間。目標：2.5 秒以內。最常見的問題是主圖片太大或伺服器回應太慢。

INP（Interaction to Next Paint）——使用者互動後到畫面更新的延遲。目標：200 毫秒以內。JavaScript 太重是最常見的原因。2024 年 3 月 INP 正式取代 FID 成為 Core Web Vitals 的一部分。

CLS（Cumulative Layout Shift）——頁面載入時畫面跳動的程度。目標：0.1 以下。圖片沒有設定寬高、字型載入造成的文字閃動、動態插入的廣告，都會造成 CLS。

用 Google PageSpeed Insights 檢測你的頁面，它會告訴你每個指標的分數和具體的改善建議。

圖片優化

圖片通常是頁面中最大的資源。優化圖片可以顯著提升載入速度。

  • 格式選擇：WebP 比 JPEG 小 25-35%，品質相當。2026 年所有主流瀏覽器都支援 WebP
  • 壓縮：照片類圖片壓縮到 100KB 以下，截圖類壓縮到 50KB 以下
  • 尺寸：不要用 CSS 縮放圖片，直接提供正確尺寸（例如顯示 800px 寬就不要上傳 3000px 的圖）
  • 設定 width 和 height 屬性——這能防止 CLS
  • 使用 srcset 提供不同裝置的不同圖片尺寸

Lazy Loading

不在畫面中的圖片和 iframe 不需要一開始就載入。加上 loading="lazy" 屬性，瀏覽器會等到使用者滾動到附近才載入。

注意：不要對首屏（above the fold）的圖片使用 lazy loading，特別是 LCP 元素——這反而會拖慢 LCP。

快取設定

設定適當的 HTTP 快取標頭，讓回訪使用者不用重新下載沒有變動的資源。

  • 靜態資源（CSS、JS、圖片）：Cache-Control: max-age=31536000（一年）搭配檔名加版本號
  • HTML 頁面：Cache-Control: max-age=3600（一小時）或 no-cache（每次都跟伺服器確認）

其他速度優化

  • 啟用 Gzip 或 Brotli 壓縮——通常可以減少 60-80% 的傳輸大小
  • 減少 JavaScript——每多 100KB 的 JS，在中階手機上大約多 300ms 解析時間
  • 使用 CDN——讓全球使用者都能快速存取你的靜態資源
  • 減少第三方腳本——每個追蹤碼、聊天插件、廣告腳本都在拖慢你的網站
  • 預先連接重要的第三方來源：<link rel="preconnect" href="...">
指標良好需改善差
LCP≤ 2.5 秒2.5-4 秒> 4 秒
INP≤ 200 毫秒200-500 毫秒> 500 毫秒
CLS≤ 0.10.1-0.25> 0.25
PageSpeed 分數90-10050-890-49

行動裝置友善

結論：Google 已經全面採用 mobile-first indexing，意思是 Google 是用你的手機版網頁來評估排名的。如果你的網站在手機上有問題，桌面版做得再好也沒用。

Responsive Design 檢查

你的網站應該在任何螢幕尺寸上都能正常使用。檢查項目：

  • 有 viewport meta 標籤：<meta name="viewport" content="width=device-width, initial-scale=1">
  • 文字不需要縮放就能閱讀（最小 16px）
  • 按鈕和連結間距足夠（最小點擊區域 48x48 像素），手指不會誤觸
  • 沒有水平滾動條
  • 表格在手機上有適當的處理方式（水平滾動或重排）
  • 圖片會自動縮放，不會超出螢幕

行動版常見問題

彈出視窗（Interstitials）——Google 會懲罰在手機上使用全螢幕彈出視窗的網站（法律要求的除外，像 Cookie 同意書）。如果要用彈出視窗，確保它不會擋住主要內容，或者用頁面頂部/底部的 banner 代替。

手機版缺少內容——有些網站的手機版會隱藏部分內容，這在 mobile-first indexing 下等於讓 Google 看不到那些內容。確保手機版和桌面版的內容一致。

觸控目標太小——這不只是使用者體驗問題，Search Console 的行動裝置可用性報告也會標出這個問題。用 Chrome DevTools 的裝置模擬器測試各種螢幕尺寸。

網站架構

結論：好的網站架構讓 Google 更容易理解你的內容層級關係，也讓使用者更容易找到東西。架構不好的網站，Google 不知道你最重要的頁面是哪些。

URL 結構

好的 URL 規則：

  • 短——理想在 60 個字元以內
  • 有意義——/technical-seo-checklist 比 /post?id=394 好
  • 用英文和連字號——不要用中文（會變成一長串 %E5%... 編碼）
  • 小寫——避免大小寫混用造成重複 URL
  • 扁平結構——/seo-guide/technical-seo-checklist 比 /blog/2026/04/03/seo/technical-seo-checklist 好
  • 不要在 URL 中放不必要的資料夾層級

內部連結策略

內部連結是技術 SEO 中最被低估的一環。它的作用：

  • 幫助 Google 發現新頁面
  • 傳遞連結權重（PageRank）給重要頁面
  • 建立主題關聯性——告訴 Google 哪些頁面討論相關主題

實際做法：

  • 每篇文章至少 3-5 個內部連結
  • 錨文字要有描述性（「On-Page SEO 教學」比「點這裡」好）
  • 重要頁面應該被更多頁面連結到
  • 定期檢查有沒有孤立頁面（沒有任何內部連結指向它的頁面）——Screaming Frog 可以幫你找到這些
  • 修復內部連結中的 404（壞掉的連結會浪費 crawl budget 和連結權重）

麵包屑導航（Breadcrumbs）

麵包屑是頁面頂部的路徑導航，例如「首頁 > SEO 教學 > 技術 SEO 清單」。它的好處：

  • 幫助使用者理解自己在網站中的位置
  • 提供額外的內部連結
  • 配合 Schema 標記，可以在搜尋結果中顯示路徑

用 BreadcrumbList Schema 標記你的麵包屑，Google 就會在搜尋結果中顯示漂亮的路徑而不是 URL。

接下來推薦你看：
SEO KPI Dashboard 指標設計指南 →

安全性

結論：HTTPS 在 2026 年已經是基本要求，不是加分項。沒有 HTTPS 的網站，Chrome 會直接顯示「不安全」警告，使用者信任度大打折扣。

HTTPS 檢查

  • 確認 SSL 憑證有效且未過期（可以用瀏覽器點網址列的鎖頭圖示確認）
  • 所有 HTTP 請求都 301 重導向到 HTTPS
  • 確認 HSTS 標頭已設定（告訴瀏覽器以後直接用 HTTPS 連線）
  • SSL 憑證涵蓋所有子網域（如果你有用子網域的話）

Mixed Content 問題

Mixed content 是指你的 HTTPS 頁面載入了 HTTP 的資源（圖片、CSS、JavaScript）。這會讓瀏覽器顯示警告，也可能導致資源被封鎖。

檢查方式：

  • 在 Chrome DevTools 的 Console 中找 mixed content 警告
  • Screaming Frog 可以掃出所有 HTTP 的資源引用
  • 把所有 http:// 的資源引用改成 https:// 或協議相對 URL（//example.com/image.jpg）

其他安全性檢查

  • 定期更新 CMS 和外掛——過期的 WordPress 外掛是最常見的被駭入口
  • 移除不再使用的外掛和主題
  • 設定適當的 HTTP 安全標頭（Content-Security-Policy、X-Frame-Options 等）
  • 在 Search Console 中確認沒有安全性問題的通知

結構化資料

結論：結構化資料不直接影響排名，但能讓你的搜尋結果更搶眼（Rich Results），提升點擊率。根據搜尋引擎觀察，有 Rich Results 的搜尋結果 CTR 平均比沒有的高 20-30%。

什麼是 Schema Markup

Schema 是一套標準化的詞彙，讓你用機器可讀的方式描述你的內容。例如告訴 Google「這是一篇文章，作者是某某人，發布日期是某某日」。

最常用的 Schema 類型：

  • Article——部落格文章和新聞
  • HowTo——教學和步驟指南
  • FAQ——常見問題（可以在搜尋結果中直接展開 Q&A）
  • Product——產品頁面（顯示價格、評分）
  • LocalBusiness——在地商家（顯示營業時間、地址）
  • BreadcrumbList——麵包屑導航

JSON-LD 實作

Google 推薦用 JSON-LD 格式來加入結構化資料。它是一段 JavaScript，放在頁面的 <head> 或 <body> 中都可以，不會影響頁面顯示。

範例——FAQ Schema：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "技術 SEO 是什麼？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "技術 SEO 是確保搜尋引擎能順利爬取、理解、索引你的網站的優化工作。"
    }
  }]
}
</script>

加好之後，用 Google Rich Results Test 測試你的結構化資料有沒有錯誤。

常見結構化資料錯誤

  • 必填欄位遺漏（Google 會在 Search Console 中提醒你）
  • 標記的內容跟頁面實際內容不符（這可能導致手動處罰）
  • 使用了過時的 Microdata 格式而不是 JSON-LD
  • FAQ Schema 中放了跟頁面無關的問答

進階技巧

結論：以下這些技巧不是每個網站都需要，但如果你的網站夠大或有特殊需求，這些做法可以帶來明顯的效果。

Log File Analysis（伺服器日誌分析）

伺服器日誌記錄了每一次對你網站的請求，包括 Google 爬蟲的每一次造訪。分析這些日誌可以告訴你：

  • Googlebot 多常來、爬了哪些頁面
  • 哪些頁面被頻繁爬取（可能是 Google 認為重要的頁面）
  • 哪些頁面從來沒被爬過（可能是孤立頁面或太深層的頁面）
  • 爬蟲遇到了哪些錯誤（5xx、404 等）

Screaming Frog 的付費版有 Log File Analyser 功能，可以把日誌資料視覺化。不想付費的話，也可以用試算表軟體篩選和分析原始日誌。

JavaScript SEO

如果你的網站用 React、Vue、Angular 等 JavaScript 框架，有些內容可能需要 JavaScript 才能渲染。Google 可以執行 JavaScript，但有幾個限制：

  • Google 渲染 JavaScript 的速度比爬取 HTML 慢很多——可能延遲數天到數週
  • 有些 JavaScript 功能 Google 不支援（例如某些 IntersectionObserver 的用法）
  • JS 渲染會消耗 crawl budget

解決方案：

  • 使用 SSR（Server-Side Rendering）或 SSG（Static Site Generation）——讓伺服器直接輸出完整的 HTML
  • 重要內容不要完全依賴 JavaScript 渲染
  • 用 Search Console 的「URL 檢查」工具，看看 Google 實際渲染出來的頁面長什麼樣子
  • 測試關掉 JavaScript 後你的頁面還有沒有主要內容

國際化 SEO（Hreflang）

如果你的網站有多語言版本，用 hreflang 標籤告訴 Google 每個語言版本的對應關係。

例如：<link rel="alternate" hreflang="zh-TW" href="https://example.com/zh-tw/page">

常見錯誤：hreflang 標籤沒有雙向對應（A 指向 B，但 B 沒有指回 A）。這會導致 Google 忽略你的 hreflang 設定。

常見錯誤與解決方法

結論：以下是我們在幫網站做技術 SEO 健檢時最常看到的錯誤。很多錯誤其實很容易修，但因為沒人去檢查，就一直放在那裡影響排名。

錯誤 1：整個網站沒有 sitemap.xml

原因：很多人建好網站就忘了這件事。影響：Google 可能漏掉你的某些頁面。修復：用 CMS 的外掛自動生成（WordPress 用 Yoast SEO、Rank Math 都有內建），然後在 Search Console 提交。

錯誤 2：staging 環境可被 Google 爬取

原因：測試環境沒有設定 noindex 或密碼保護。影響：Google 索引了你的測試內容，可能造成重複內容問題。修復：在 staging 環境加 noindex meta 標籤，或者用 HTTP 基本認證保護。

錯誤 3：重導向鏈太長

原因：A 重導向到 B、B 重導向到 C、C 又重導向到 D... 影響：每多一次重導向就損失一些連結權重和速度。Google 最多跟 10 次重導向。修復：讓所有重導向直接指向最終目的地（A → D）。

錯誤 4：圖片沒有設定寬高

原因：HTML 中 img 標籤沒有 width 和 height 屬性。影響：造成 CLS（頁面跳動），Core Web Vitals 扣分。修復：在所有 img 標籤加上 width 和 height。

錯誤 5：404 頁面沒有回傳 404 狀態碼

原因：伺服器設定錯誤，不存在的 URL 回傳 200 狀態碼和一個「找不到頁面」的內容。這叫 soft 404。影響：浪費 crawl budget，Google 可能索引這些無用頁面。修復：確保伺服器對不存在的 URL 回傳正確的 404 狀態碼。

錯誤 6：canonical 標籤指向錯誤的 URL

原因：CMS 模板中的 canonical 標籤是硬編碼的，或者設定錯誤。影響：可能導致 Google 不索引你想被收錄的版本。修復：用 Screaming Frog 掃全站，檢查每頁的 canonical 標籤是否指向正確的 URL。

錯誤 7：沒有設定 301 重導向就改 URL

原因：改了頁面 URL 但忘記做舊 URL 到新 URL 的重導向。影響：舊 URL 變成 404，所有指向舊 URL 的外部連結權重都浪費了。修復：每次改 URL 都要設定 301 重導向。保留一份 URL 變更紀錄。

我們的使用經驗

老實說，技術 SEO 聽起來很嚇人，但其實大部分問題都是「知道要檢查 → 花時間修」的事。第一次做完整的健檢會比較花時間，之後定期跑一遍清單就夠了。

我們日常用的工具組合：

Google Search Console

完全免費，而且是 Google 官方工具——這代表數據是第一手的，不是估算值。索引涵蓋範圍報表、Core Web Vitals 報表、行動裝置可用性報表，這三個建議定期查看。詳細用法請看 Search Console 完整教學。

缺點也要說：

  • 數據延遲 2-3 天，你沒辦法看到即時的爬取狀態，有時候急著確認問題有沒有修好，只能等
  • 沒辦法匯出完整的爬取日誌，只給你彙整過的報表，想做深度分析還是得看伺服器日誌
  • 對大型網站（10 萬頁以上），報表只抽樣顯示部分數據，不是全貌

Google PageSpeed Insights

檢測網站速度和 Core Web Vitals 的首選工具。它結合了 Lighthouse 分析（實驗室數據）和 Chrome User Experience Report（真實使用者數據），給你的改善建議很具體。

缺點：

  • 每次只能測一個 URL，如果你有 500 個頁面想測，就得一頁一頁來（或者用 API，但那又需要技術能力）
  • 實驗室數據和真實使用者數據經常有差距——你本機測 95 分，但真實使用者的分數可能只有 70 分，因為很多使用者用的是中低階手機和慢速網路
  • 給的建議有時候過於技術化，像「避免大型 DOM 結構」——好的，但如果你用的是現成的 WordPress 主題，你也改不了 DOM 結構

Screaming Frog

桌面版的 SEO 爬蟲工具，可以爬取你的整個網站，找出各種技術問題。免費版最多爬 500 個 URL，付費版每年約 259 美元（2026 年價格）。

缺點：

  • 免費版 500 個 URL 的限制，對稍微大一點的網站就不夠用了。一個中型電商網站隨便都有幾千個產品頁面，500 個上限只能爬一小部分
  • 學習曲線不低，介面不太直覺，第一次打開會被滿螢幕的數據嚇到。要搞懂各個分頁、篩選器、報表之間的關係，至少需要幾天的摸索
  • 吃電腦資源——爬大型網站時 RAM 使用量可以輕鬆超過 4GB，舊電腦或低記憶體的筆電跑起來會很痛苦

GTmetrix

另一個網站速度分析工具，提供 Lighthouse 分數和 Web Vitals 數據。它的特色是可以選擇不同的測試地點和瀏覽器，還提供頁面載入的瀑布圖（Waterfall Chart），讓你看到每個資源的載入時序。

缺點：

  • 免費帳號每天只能測有限次數，而且只能從溫哥華的伺服器測試。如果你的網站主要客群在台灣，從加拿大測出來的速度數據參考價值有限
  • 免費版看不到歷史趨勢——你這個月改善了速度，想跟上個月比較？抱歉，要付費才能看歷史報告。想監控速度是否退步也需要升級
  • 分數系統跟 PageSpeed Insights 有時候會有出入，讓人不知道該相信哪個，造成判斷上的混亂

整體來說，我們建議的工具組合是：Search Console（每週看報表）+ Screaming Frog（每月爬一次全站）+ PageSpeed Insights（重要頁面定期測速度）。更多免費工具推薦可以參考 免費 SEO 工具總整理。

最後想說的是，技術 SEO 不是一次性的工作。網站會更新、CMS 會升級、Google 的規則會改——你需要定期檢查。不用每天看，但至少每個月花一兩個小時跑一遍重點項目。把它當成網站的健康檢查，預防勝於治療。

常見問題

技術 SEO 需要會寫程式嗎？

不用。大部分的技術 SEO 檢查可以用工具完成（Search Console、Screaming Frog 等），修復也通常是在 CMS 後台操作。但如果你懂一些 HTML 基礎（知道什麼是 meta 標籤、什麼是 301 重導向），會更容易理解問題和溝通修復方案。遇到比較深層的問題（像伺服器設定、JavaScript 渲染），可能需要開發人員的協助。

技術 SEO 和 On-Page SEO 有什麼不同？

技術 SEO 解決的是「Google 能不能讀到你的內容」，On-Page SEO 解決的是「你的內容有沒有針對關鍵字優化」。打個比方：技術 SEO 是確保你的店面大門打得開、招牌掛好了、地址在 Google 地圖上找得到；On-Page SEO 是確保店裡的商品陳列整齊、標價清楚、客人走進來能快速找到想要的東西。兩者都要做，但技術 SEO 是基礎——大門都打不開，裡面佈置得再好也沒用。詳見 On-Page SEO 教學。

小型網站也需要做技術 SEO 嗎？

需要，但不用做到很深。一個 50 頁以下的小網站，重點放在：HTTPS 正常、有 sitemap 且已提交 Search Console、沒有 noindex 誤用、頁面速度合格（PageSpeed 90 分以上）、手機版正常。這些大概一兩個小時就能全部檢查完。crawl budget、log file analysis 這些進階項目可以先跳過。

技術 SEO 做好了多久會看到效果？

看情況。修復爬取和索引問題（像是移除錯誤的 noindex），效果通常在 Google 重新爬取後就看得到，大概 1-4 週。速度優化的效果通常需要 2-3 個月才會反映在排名上，因為 Core Web Vitals 的數據是根據 28 天的滾動平均計算的。最不確定的是結構化資料——加了 Schema 不保證會出現 Rich Results，Google 會自己判斷要不要顯示。

每隔多久要做一次技術 SEO 檢查？

建議每月做一次基礎檢查（Search Console 報表、爬取錯誤、Core Web Vitals），每季做一次完整檢查（用 Screaming Frog 爬全站）。另外，每次網站有重大更新（改版、搬家、換主機、大量新增或刪除頁面）之後，都應該做一次完整的技術 SEO 檢查。很多技術 SEO 問題就是在改版過程中產生的。

相關免費工具