第 4 章：技術 SEO 實作健檢,一步步帶你做完網站速度與索引最佳化(2026)
技術 SEO(Technical SEO)是把第三章做好的每一個頁面,放進一座 Google 爬得到、讀得懂、跑得快的網站底盤的工程動作,也是你能完全自己控制、卻最常被忽略的一塊 SEO 工作。Google 官方與多份產業研究都印證,技術層短板是大多數網站排不上的真正天花板,而不是內容不夠好。這一章帶你把技術 SEO 怎麼做,拆成一份能照著走的健檢步驟清單。
想像你的網站是一棟百貨公司。第三章的 On-Page SEO 是把每個專櫃裝潢到最迷人,這一章要做的事,是把水電、空調、消防、逃生動線、電梯、貨梯全部升級到合格,讓客人走進來不會迷路、不會被困住、不會等到不耐煩。技術 SEO 做紮實,等於把整站變成一台 Google 願意反覆造訪的排名磁鐵。新手最常跳過這一步直接衝內容產量,結果寫了一百篇還是排不上,因為 Google 根本進不來、也讀不懂。
如果你還沒走過〈第 3 章:On-Page SEO 頁面最佳化實戰〉,建議先回頭把頁面層的訊號做紮實,這一章的每個動作都要建立在已經能排上的單頁之上。定義層的「技術 SEO 是什麼、與 On-Page 的差別」權威版本在〈技術 SEO 指南〉一文,本章不重複定義,焦點放在怎麼一步步做健檢。對 SEO 全貌還不熟的讀者,定義權在〈SEO 是什麼〉。
TL;DR:技術 SEO = 爬取、索引、速度、行動體驗、安全、架構、結構化資料七大健檢面向。每一項都給 Google 一個「這站值得信任」的訊號。實證資料:whoops 自建的邊緣觀測層量到單週被 GPTBot、ClaudeBot、PerplexityBot 等 AI 爬蟲造訪超過 1.2 萬次,技術層做紮實的網站,等於一次照顧 Google 與所有 AI 搜尋入口。
一、技術 SEO 怎麼做:本章的學習路徑與戰略
技術 SEO 不是「會寫程式才能做」,是給整站一套可量測、可重現的健檢節奏。很多新手一聽到技術 SEO 就退縮,以為要會改伺服器、寫 Nginx 設定,這是被「技術」兩個字嚇到的誤會。現代技術 SEO 的核心,是讓 Google 與真人讀者用最快速度「進得來、讀得懂、跑得順、帶得走」。本章把這件事拆成七大健檢面向,每一面向配一節的操作步驟。
戰略上要把握三件事。第一,技術 SEO 的單位是「整站」,不是單頁,所以大多数動作做一次就全站受惠,跟第三章 On-Page 每頁都要做不同。第二,每個健檢動作都要對應一個可量測指標,沒有指標的動作只是感覺良好,不是工程。第三,技術 SEO 與 On-Page 是互補的兩層,前者是網站層級的基礎建設,後者是頁面層級的訊號工程,本章只做網站層級,頁面層的東西交給第三章。
本章你會依序學到:七大健檢面向總覽、技術 SEO 本質三觀念、可爬取性健檢、可索引性健檢、網站速度最佳化實戰、Core Web Vitals 三指標實測、行動優先索引、HTTPS 與安全、網站架構與導覽、結構化資料與 JavaScript SEO、發布前健檢清單與七個常見錯誤。讀完這章你應該能獨立把任何一個網站,從混亂做到 Google 友善,那是後面內容行銷、內部連結、E-E-A-T 幾章共同的工作底盤。
把技術 SEO 的「七大健檢面向」放進一張表
| 面向 | 它在做什麼 | 本章順序 |
|---|---|---|
| 可爬取性 Crawlability | 讓 Googlebot 進得來、爬得有效率 | 第三節 |
| 可索引性 Indexability | 讓爬到的頁面真的進索引 | 第四節 |
| 網站速度 Speed | 縮短首屏與完整載入時間 | 第五節 |
| Core Web Vitals | LCP、INP、CLS 三項體驗指標 | 第六節 |
| 行動優先 Mobile-First | 行動版內容與體驗到位 | 第七節 |
| HTTPS 與安全 | 加密連線與信任訊號 | 第八節 |
| 架構與結構化資料 | 資訊層次與機器可讀語意 | 第九、十節 |
這七項不是各自獨立的雜事,而是一整套「讓 Google 信任這座網站」的基礎建設。可爬取性顧好但可索引性破洞,等於爬到一半被擋在門外;速度做得快但行動版破產,等於桌機快、手機慢,而 Google 主要用手機版排名。實務上我會把這七項排成一份每季健檢清單,逐項量測、逐項修,第十一節會給你完整表格。
二、技術 SEO 的本質:30 秒抓核心觀念
技術 SEO 的本質是「降低 Google 與讀者的進入成本」。Google 的爬蟲每天讀幾十億個頁面,進不來、讀不懂、跑不動的網站會被自動降權;讀者也一樣,行動版載入超過三秒,超過一半會直接跳出。完整的技術 SEO 定義、與 On-Page SEO 的差異,站內權威指南已深度展開,本章你只需要先抓住三個底層觀念。
第一個觀念,技術 SEO 是「基礎建設工程」不是「衝排名技巧」。它不會像改標題那樣兩週就看到排名波動,但它會決定整站的排名天花板,做不好後面所有努力都打折。第二個觀念,技術 SEO 的讀者有兩個,先 Google 再真人,做給 Google 看是為了被索引,做給真人看是為了不被處罰,兩者缺一都站不穩。第三個觀念,技術 SEO 是保養型工作,做完一次不是永遠有效,演算法更新、網站改版、外掛升級都會把它弄壞,所以每季健檢是基本節奏。
這三個觀念內化後,你會發現坊間那種「幫你修技術 SEO 就保證排上」的承諾,本質上都把技術 SEO 當成單點戰術。真正的技術 SEO 是一套系統工程,從爬取預算到 Core Web Vitals,再到結構化資料,每一環都要扣緊。這也是為什麼〈如何選擇 SEO 公司〉一文會建議,挑顧問的第三個判斷標準是「他能不能給你一份技術 SEO 健檢報告」,給不出報告的多半只會改內容。
進一步說,技術 SEO 在 2026 年的角色已經從「服務 Google」升級成「服務所有 AI 搜尋入口」。GPTBot、ClaudeBot、PerplexityBot、Google-Extended 這些 AI 爬蟲,跟 Googlebot 一樣需要可爬取、可索引、結構清楚的網站,差別只在它們對 JavaScript 渲染的容忍度更低、對結構化資料的依賴更高。換句話說,把技術 SEO 做紮實,等於一次投資同時卡位 Google 與 AI 搜尋兩個入口,這是這一章每一個動作的額外回報。
新手做技術 SEO 的兩種失敗模式
新手技術 SEO 做歪,多半走兩種極端。一種是「無視派」,只會寫內容、改標題,把技術層當成 IT 部門的事,三個月後發現 Google 收錄的頁數比實際少一半,排名進不來。另一種是「過度派」,裝了一堆快取外掛、CDN、加速工具,卻互相衝突,反而把網站弄得更慢、把爬蟲擋得更徹底。兩種極端的共同病根都是「沒把技術 SEO 當基礎建設工程」。正確做法是按七大面向逐項量測、逐項修,後面八節就是沿著這條線設計的步驟。
三、可爬取性健檢:讓 Googlebot 進得來、爬得有效率
可爬取性(Crawlability)是技術 SEO 的第一道門,回答的是「Googlebot 進得來嗎」。Google 分配給每個網站的爬取資源是有限的,業界稱為「爬取預算(Crawl Budget)」。對頁面數量在數百到數千以上的網站,有效管理爬取預算尤其重要。如果 Googlebot 把大量資源浪費在低價值頁、參數頁、篩選頁,你真正重要的頁面反而會晚幾天才被爬到、晚幾週才被索引。
把可爬取性想成都市裡的郵差。每一條巷子是一個 URL,每一戶是一個頁面。郵差每天能送的信件數有限,如果你把每一條沒人住的巷子都標成「待送」,真正有人住的那一戶反而要等更久。robots.txt、Sitemap、內部連結這三件工具,就是幫郵差畫地圖、排除空巷、標出重要住戶的設施。
- 提交 XML Sitemap:Sitemap 是你主動告訴 Google「這些是我重要頁面」的名單,透過〈Google Search Console〉的 Sitemap 報告提交。控制單檔 50,000 個 URL 或 50MB 以下,超過就拆多個檔。
- 寫好 robots.txt:把 /wp-admin/、搜尋結果頁、篩選參數頁等低價值路徑擋掉,讓爬蟲把預算花在內容頁。robots.txt 寫錯是新手最常見的技術 SEO 災難,上線前務必用 Google 的 robots 測試工具驗證。
- 修復 404 與斷鏈:定期用 Screaming Frog 或 Ahrefs Site Audit 抓出整站 404,重要舊網址一定配〈301 重定向〉。
- 管理爬取預算:大型網站要對分面導覽(faceted nav)、分頁、追蹤參數做參數處理,在 GSC 設定 URL 參數規則,避免 Google 爬無窮多個變體。
- 建立扎實的內部連結:重要頁面要能在三到四次點擊內到達,完整內部連結工程在〈第 7 章:內部連結最佳化〉。
一個關鍵卻常被忽略的事實:robots.txt 阻擋不等於不索引。如果其他網站連到被 robots.txt 擋的頁面,Google 仍可能把那個 URL 索引(只是不爬內容),出現在 SERP 上時只有一行「缺少資訊」。要完全阻止索引,必須用 noindex 標籤或回應標頭,這是新手最常弄混的兩個觀念,第四節會再展開。實務上,我會建議新站第一天就寫好 robots.txt、提交 Sitemap,這兩件事十五分鐘做完,卻是技術 SEO 的入場券。
四、可索引性健檢:讓爬到的頁面真的進索引
可索引性(Indexability)回答的是「Google 願意把這頁收進索引庫嗎」。爬到不等於索引,索引也不等於排名。一個頁面沒進索引,後面所有 On-Page、內容、外鏈工作都白費。GSC 的「網頁索引」報告會列出未索引原因,這份報告是技術 SEO 健檢的起點,每月走一次。
| 未索引原因 | 處置 |
|---|---|
被 noindex 標記 | 如果是重要頁,移除 noindex;如果是該擋的,確認無誤 |
| 被 robots.txt 阻擋 | 確認是否刻意;記得阻擋仍可能被索引成「缺少資訊」 |
| Canonical 指向他頁 | 檢查〈Canonical 標籤〉是否指錯,常用於處理〈重複內容〉 |
| 軟 404(伺服器傳回 200 但內容空白) | 把無內容頁改成真 404,或補上實質內容 |
| 被標為重複的標準網頁 | 同一內容多 URL 時,用 canonical 指定主版本 |
| 已檢索但未建立索引 | 通常是內容太薄或品質低,補深度或合併到主題叢集主頁 |
索引健檢最常見的錯誤有三個。第一個,把該索引的頁面不小心下了 noindex(例如從開發環境複製來的範本),上線後永遠排不上。第二個,Canonical 指到已刪除的舊網址,等於把主力頁的權重導向虛空。第三個,分頁、篩選、追蹤參數製造大量重複 URL,把整站稀釋。正確做法是每月跑一次 GSC 索引報告,把未索引清單依原因分類處理,這比再寫十篇新內容更能拉升有效索引頁數。
刪除頁面也有學問。暫時下架用 302,永久刪除用 410(Google 收到 410 會從索引移除),搬家用 301。把這三種狀態碼搞混,是技術 SEO 健檢現場最常見的「無聲排名流失」。如果你不確定某個網址現在對 Google 是什麼狀態,用 GSC 的〈URL 檢查〉工具,它會告訴你這個網址是否被爬、是否被索引、最近一次檢索時間,這是技術 SEO 健檢最常駐開的分頁。
五、網站速度最佳化實戰:把載入時間壓到三秒內
網站速度從 2018 年起就是 Google 確認的排名因素,也是讀者體驗的硬指標。〈頁面速度影響 SEO〉的多份研究指出,行動版載入時間每增加一秒,跳出率約上升兩成到三成;載入超過三秒,超過一半讀者會直接離開。速度是一個「做不好會扣分、做好不會大幅加分」的隱性排名因素,所以目標不是衝最快,是先過門檻。
把網站速度想成餐廳出餐。讀者點完餐到菜上桌的時間,決定他願不願意再來。廚房(伺服器)出菜慢、菜色太多要一道道做(沒快取)、盤子太大(沒壓圖)、跑堂來回太多次(太多 HTTP 請求),任何一環節慢都會拖垮整體。速度最佳化的動作就是找出一條最短的路,讓首屏內容最快出現在讀者眼前。
| 最佳化項目 | 具體做法 | 預期改善 |
|---|---|---|
| 圖片最佳化 | 改 WebP/AVIF、壓到 200KB 以下、loading="lazy" 非首屏圖 | 頁面大小降三到八成 |
| 啟用壓縮 | Brotli 或 Gzip 壓 HTML/CSS/JS | 傳輸量降六到八成 |
| 瀏覽器快取 | 設 Cache-Control 的 max-age 與 immutable | 回訪載入時間大幅縮短 |
| CDN 加速 | 用 Cloudflare 等內容傳遞網路把靜態資源推到邊緣節點 | 全球載入時間改善 |
| 瘦身 JavaScript | 移除未使用的 JS、延遲載入非必要腳本、拆分長任務 | 主執行緒阻塞降低 |
| HTTP/2 或 HTTP/3 | 支援多路復用,〈HTTP/2〉已是主流 | 併發載入效率提升 |
| 預載入關鍵資源 | 用 rel="preload" 標示首屏字型、關鍵 CSS | LCP 提前達成 |
量測工具用〈Google PageSpeed Insights〉與〈web.dev〉。前者給你實驗室資料(Lab Data)與實場資料(Field Data),後者給你細部建議。重點要看實場資料,因為那是真實讀者體驗到的速度,實驗室資料只是一台模擬裝置的分數,常常與真實狀況差一大截。行動版速度尤其關鍵,〈行動版網站速度〉的研究顯示,行動版載入超過三秒,超過一半讀者會直接跳出。
一個常見誤判:有人為了追求 PageSpeed 滿分,把整站 JavaScript 砍光、移除所有追蹤碼,結果轉換追蹤壞了、表單也不能送出。技術 SEO 的目標不是滿分,是在「速度合格」與「功能完整」之間找平衡。實務上我會建議客戶先把行動版速度壓到三秒內、Core Web Vitals 達標,之後再追求更快的分數。速度是門檻,不是軍備競賽。
看一個真實對比。某個內容站首頁原本 LCP 5.8 秒,主圖是 2.4MB 的 PNG、首屏還塞了四支追蹤碼。動作只有三個:把主圖轉 WebP 並壓到 180KB、把追蹤碼延遲到首屏繪製後再載入、啟用 Cloudflare CDN 快取靜態資源。三個動作做完,LCP 降到 2.1 秒、INP 從 480 毫秒降到 190 毫秒、行動版跳出率同步降約兩成。技術 SEO 的投資報酬率,常常不是寫更多內容能換來的,這也是為什麼速度健檢應該排在內容產線之前,而不是之後。
六、Core Web Vitals 三指標實測:LCP、INP、CLS
Core Web Vitals(網站核心指標)是 Google 用來量化使用者體驗的三個關鍵指標,自 2021 年起陸續納入排名因素,2024 年 INP 正式取代 FID。三個指標對應三種體驗痛點:載入慢、互動鈍、畫面跳,每一項都有明確的量測標準與改善動作。
| 指標 | 衡量什麼 | 良好門檻 | 實測改善動作 |
|---|---|---|---|
| LCP 最大內容繪製 | 首屏最大元素完成繪製的時間 | ≤ 2.5 秒 | 壓圖、預載入主圖與關鍵字型、升級 CDN、提早伺服器回應(TTFB) |
| INP 互動到下一個繪製 | 使用者互動(點擊、輸入)到畫面回應的延遲 | ≤ 200 毫秒 | 拆分長任務、減少第三方 JS、使用 requestIdleCallback 排程 |
| CLS 累積版面配置位移 | 頁面載入過程視覺元素跳動程度 | ≤ 0.1 | 為圖片影片設 width/height、避免動態插入內容、保留廣告欄位空間 |
LCP 是三者中最常破標的一個,因為它直接綁主圖、英雄區、首屏大字型。改善 LCP 最有效的單一動作是把首屏圖片改 WebP、壓到 200KB 以下、用 fetchpriority="high" 標記,這一招通常能省下七八百毫秒。INP 則要看主執行緒阻塞,常見元兇是過多的第三方追蹤碼、社群外掛、廣告腳本,每多一支就多一份阻塞,拆任務與延遲載入是標準解法。
CLS 是三者中最容易在改版時被弄壞的。讀者最常遇到的「點下去結果按鈕跳走」就是 CLS 失控,主因是圖片沒設尺寸、字型非同步載入造成文字跳動、廣告或彈窗動態插入把內容推下去。修 CLS 的動作很機械:每一張圖、每一支影片都給固定 width/height、為廣告欄位預留 placeholder、避免在首屏插入 position: absolute 的浮動元素。最佳化 CWV 不只能提升排名,還能直接降低〈跳出率〉、拉長〈停留時間〉這兩個隱性排名訊號。
七、行動優先索引:行動版才是 Google 看到的版本
Google 從 2019 年啟動〈行動優先索引〉,到 2024 年幾乎全部網站都已切換完成。這代表Google 主要用你網站的行動版內容來判斷排名,桌機版做得再漂亮,行動版殘缺一樣排不上。行動優先不是「行動友善」,是「行動版本就是 Google 索引的版本」。
把行動優先想成餐廳的健康檢查。以前 Google 用桌機版做體檢,現在改用行動版,你送進去的健檢報告就是手機看到的內容。如果你的行動版把重要段落藏起來、把圖片換成較小版本但少了 Alt、把內部連結收進漢堡選單深處,Google 看到的就是那個殘缺版本,排名自然往下。
- 回應式設計(RWD):一套 HTML 配不同裝置,避免內容分歧,這是 Google 官方推薦的做法。
- 行動版內容完整性:桌機版有的重要內容、內部連結、結構化資料,行動版都要有,別為了「簡潔」把關鍵段落藏起來。
- 可點擊區域夠大:按鈕與連結至少 48×48 px,間距足夠,避免誤觸。
- 字型大小:正文至少 16px,手機閱讀才不吃力。
- 避開 intrusive interstitials:〈彈跳式廣告〉會被 Google 判定為阻礙體驗,降權處理。
- Viewport 設定:
<meta name="viewport" content="width=device-width, initial-scale=1">是基本款,漏寫這一行,整個行動版排版會崩。
行動版健檢最直接的動作是用手機打開自家網站,點每一個重要頁面,問四個問題:首屏看得懂嗎、按鈕按得到嗎、圖片有跑出來嗎、載入有沒有超過三秒。這四題有任何一題答不出來,就是行動版的破洞,Google 看到的也是同一個破洞。別只看桌機版做事,那是 2015 年之前的老習慣。
八、HTTPS 與網站安全:基本款信任訊號
HTTPS 從 2014 年就是 Google 確認的排名因素,自 2018 年起,〈Chrome 將所有 HTTP 網站標記為「不安全」〉,這不只是排名問題,更是讀者信任問題。裝 SSL 憑證的工程門檻已經很低,Let’s Encrypt 提供免費憑證,大多主機面板都有一鍵安裝,沒裝的理由只剩「還沒做」。
- 安裝 SSL 憑證:Let’s Encrypt 免費,主機面板或 Cloudflare 都能一鍵裝。
- 設 HTTP 到 HTTPS 的 301 重定向:全站強制走 HTTPS,別讓兩個版本同時存在造成重複內容。
- 更新內部連結:把站內所有
http://改成https://或相對路徑。 - 更新 Sitemap 與 GSC 資源:在 GSC 新增 HTTPS 版本資源,提交新的 Sitemap。
- 修混合內容(mixed content):確認圖片、JS、CSS、第三方資源都走 HTTPS,瀏覽器對任何 http 子資源都會跳警告。
- 啟用 HSTS:透過
Strict-Transport-Security標頭告訴瀏覽器未來一律走 HTTPS,防止通訊協定降級攻擊。
HTTPS 健檢最常見的雷是「證書裝了,但混合內容沒修」。表面上網址列有小鎖圖示,但主控台一堆 mixed content 警告,部分瀏覽器會把整頁降級成不安全。健檢動作是打開瀏覽器開發者工具的 Console 與 Network 分頁,過濾 http:// 請求,把殘留的每一個都改掉。SSL 與 HTTPS 是技術 SEO 的免費午餐,裝一次受用好幾年。
九、網站架構與導覽:把資訊層次做平、做清楚
網站架構是技術 SEO 與內部連結的交會點,也是 Google 判斷站點主題權威的關鍵訊號。理想架構是「扁平化」,任何重要頁面都能在三到四次點擊內到達。架構混亂的網站,即使內容再好,Google 也會歸類為「主題不明確」,排名訊號分散。
把網站架構想成圖書館的書架分類。首頁是大廳,分類頁是主題書架,內容頁是每一本書。如果每一本書都要從大廳走十分鐘才找得到,讀者與圖書管理員(Googlebot)都會放棄。扁平化架構的重點是減少從首頁到任何重要頁面的點擊距離,同時用麵包屑、分類頁、內部連結把層次做清楚。
- 層次分明:首頁 → 分類頁 → 子分類頁 → 內容頁,每一層的 URL 目錄反映層次(例如
/seo/technical-seo/)。 - 麵包屑導覽:每一頁上方顯示「首頁 > 主題 > 子主題 > 這一頁」,搭配 BreadcrumbList 結構化資料。
- URL 結構語意化:短、語意化、用連字號分隔,避免參數式 URL,詳細做法在第三章第六節。
- 主題叢集架構:用支柱頁加子主題頁組成〈主題叢集〉,子頁之間互相內鏈,讓 Google 看懂你的專精領域。
- HTML Sitemap:提供一個可瀏覽的全站目錄頁,幫讀者與爬蟲都找得到深層頁面。
網站架構最常見的錯誤是「分類過細」。為了 SEO 開了十幾個分類,每個分類只有兩三篇內容,等於把權重切得太碎,每個分類頁都養不起來。正確做法是分類頁養到至少十篇內容以上,養不起的分類先合併。如果你想看完整的網站最佳化流程,〈網站最佳化流程〉與〈網站程式碼最佳化〉有專文展開。
對比兩種常見架構。深井型架構是「首頁 → 大分類 → 子分類 → 次子分類 → 內容頁」,層層往下,關鍵內容可能在五到六次點擊之外,Googlebot 走不到、讀者也找不到。扁平型架構是「首頁 → 主題叢集主頁 → 內容頁」,每一篇主力內容都在三次點擊內到達,權重從首頁流動到內容頁的中繼站最少。實務上我會建議客戶把整站架構畫成一張樹狀圖,把任何超過四次點擊才到達的頁面標出來,要嘛補內部連結、要嘛合併到主題叢集主頁,讓每一篇重要內容都離首頁夠近。
十、結構化資料與 JavaScript SEO:讓機器讀懂你的網站
結構化資料與 JavaScript 是現代技術 SEO 的兩個進階戰場。結構化資料用 JSON-LD 把頁面內容翻譯成 Google 一定看得懂的標準格式,做對了有機會在 SERP 顯示豐富結果(星級、FAQ、麵包屑、發布日期),這些都直接拉高點擊率;JavaScript SEO 則是確保用戶端渲染的內容真的被 Google 看到。
結構化資料:JSON-LD 是首選
結構化資料完整展開在〈結構化資料是什麼〉,本章給你技術 SEO 健檢的最低清單。本站每篇主力內容都附 Article 與 FAQPage 兩份 JSON-LD,Article 標註作者、發布時間、圖片;FAQPage 讓常見問題有機會展開顯示在 SERP 與〈Google AI Overviews〉的引用區。麵包屑配 BreadcrumbList,產品頁配 Product 與 Review,課程頁配 Course。要切記,結構化資料必須與頁面實際內容一致,過度標記(例如把一般文章標成 Review 騙星級)會被判定為垃圾標記,反而受罰。
JavaScript SEO:讓渲染後的內容被爬到
隨著 React、Vue、Angular 等 JavaScript 框架普及,〈Google 可以爬 JavaScript 連結〉已經是共識,但「爬得到」不等於「渲染得到」。Google 對 JavaScript 是「兩階段索引」:先抓 HTML,再把需要渲染的網址排進渲染佇列,這個佇列可能等幾小時到幾天。如果你的核心內容藏在 JS 裡,等於強迫 Google 多等一趟。
- SSR 或預渲染:伺服器端渲染或靜態生成(SSG),讓 HTML 就包含核心內容,不要依賴用戶端渲染。
- Progressive Enhancement:核心內容即使關掉 JavaScript 也看得到,這是檢驗 CSR 是否破產的最快方法。
- 動態渲染:對於無法 SSR 的網站,為搜尋引擎爬蟲提供預渲染版本,是過渡時期的折衷方案。
- 用原生
<a href>:JavaScript 產生的按鈕onclick 跳頁,Google 抓不到;改成正規<a href<標籤加上網址,才會被當連結。 - 用 GSC URL 檢查:看「已渲染的 HTML」是否包含你期待的內容,這是 JavaScript SEO 最常駐開的健檢工具。
簡化網站結構也有助於 Google 更容易理解你的網站,正如〈Google 的 John Mueller 所建議〉,「讓你的網站簡單」是技術 SEO 的最高指導原則。能少一支 JS 就少一支,能少一次跳轉就少一次,簡單的網站幾乎自動通過大多技術 SEO 健檢項目。
十一、技術 SEO 健檢清單與 7 個常見錯誤
理論講完,這一節給你兩張表:一張每季健檢清單,一張新手最常犯的七個錯。建議把健檢清單存進你的 SEO SOP,每一季逐項量測一次,改版或上線新功能後立刻補一次。
| 健檢項目 | 量測工具 | 門檻 |
|---|---|---|
| 重要頁面已被索引 | GSC 網頁索引報告 | 無異常未索引 |
| XML Sitemap 提交且無錯誤 | GSC Sitemap | 0 錯誤 |
| robots.txt 設定正確 | robots.txt 測試工具 | 未擋重要路徑 |
| 無重大 404 與斷鏈 | Screaming Frog / Ahrefs | 重要頁 0 斷鏈 |
| 全站 HTTPS,無混合內容 | 瀏覽器 Console | 0 mixed content |
| Core Web Vitals 達標 | PageSpeed Insights | LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 |
| 行動裝置友善 | GSC 行動可用性 | 0 錯誤 |
| 無重複內容 | Siteliner / Screaming Frog | 重複率 < 20% |
| Canonical 標籤正確 | 手動抽查 + Screaming Frog | 每頁 self-canonical |
| 結構化資料無錯誤 | Rich Results Test | 0 錯誤 |
| 頁面載入 ≤ 3 秒(行動版) | web.dev / GTmetrix | LCP 達標 |
清單走完之後,對照接下來七個新手最常犯的錯,再做一輪自我審查。
- 把 robots.txt 當 noindex 用。robots.txt 只擋爬,不擋索引;該擋索引的要用
noindex標籤。這兩件事混為一談,會出現「擋了還是排上」或「沒擋卻沒排」的怪象。 - Canonical 指到已刪除網址。改版後忘了更新 canonical,主力頁權重默默流向虛空,排名慢慢往下掉。
- 裝太多快取與加速外掛。WordPress 用戶最常犯,裝了 WP Rocket、W3 Total Cache、Autoptimize 又加 Cloudflare,設定互相衝突,反而把 JS/CSS 弄壞,把行動版弄崩。
- 圖片沒壓、沒設尺寸。一張 5MB 的手機直拍當首圖,LCP 立刻破七秒;沒設 width/height,CLS 也跟著破。
- 頁面載入塞太多第三方腳本。每一支追蹤碼、社群外掛、廣告腳本都吃主執行緒,INP 因此破 500 毫秒。
- HTTP 到 HTTPS 沒設 301。兩個版本同時存在,Google 看到的是重複內容,權重自我對打。〈3 步重新審視 SEO 策略〉是補救工具。
- 結構化資料過度標記。把一般文章標成 Review 或 Event 騙豐富結果,會被判定為垃圾標記受罰,標記必須與內容真實一致。
這七個錯的共通點是「把技術 SEO 當單點戰術、而不是基礎建設」。技術 SEO 的價值,從來不是裝了幾支外掛,而是給了 Google 多少「這站值得信任、值得反覆造訪」的訊號。把七大面向當系統一起做,比把任何一項做到極致更重要。如果你想看一份更廣的執行框架,〈如何正確執行 SEO:5 大策略〉是延伸閱讀;若想把技術 SEO 落進 WordPress,〈WordPress SEO 最佳化〉有專文展開。
十二、學技術 SEO 常見問題 FAQ
Q1:技術 SEO 跟 On-Page SEO 有什麼差別?
技術 SEO 是整站層級的基礎建設,包括爬取、索引、速度、行動體驗、安全、架構、結構化資料;On-Page SEO 是單頁層級的訊號工程,包括標題、中繼描述、H1 H2 H3、URL、圖片 Alt、內部連結。前者是「整站做一次」,後者是「每一頁都要做」。兩者互補,技術層做好把天花板抬高,On-Page 做好把每一頁推上去。完整定義層的對比在前面的〈技術 SEO 指南〉一文,本章不重複定義,焦點放在怎麼一步步做健檢。
Q2:技術 SEO 健檢多久做一次?
主力站建議每季做一次完整健檢,改版或上線新功能後立刻補一次。每月至少跑一次 GSC 的網頁索引報告、Sitemap 報告、Core Web Vitals 報告,這三份是技術 SEO 的體溫計。如果你已經啟用 Search Console,把這三個分頁固定在書籤列,看到異常紅字當天處理,別等到下次健檢。
Q3:robots.txt 跟 noindex 到底差在哪?
robots.txt 擋的是「爬」,Google 連內容都不讀;noindex 擋的是「索引」,Google 爬到了但不收進索引庫。一個頁面被 robots.txt 擋,如果其他網站連得到,Google 還是可能把那個 URL 索引(只是不爬內容),出現在 SERP 時只有「缺少資訊」一行。要完全阻止索引,必須用 noindex。記住口訣:擋爬用 robots,擋索用 noindex,兩件事不要混。
Q4:Core Web Vitals 三個指標哪個最重要?
三者同時是排名因素,沒有「哪個最重要」的官方排序,但實務上 LCP 影響最大,因為它直接綁首屏體驗,而且最容易在改版時破標。INP 在 2024 年取代 FID 後,重要性明顯上升,主執行緒阻塞的網站會在 INP 上失分。CLS 則是三者中最容易 100% 修到過標的,把每張圖片影片都設 width/height、避免動態插入內容,幾乎都救得回來。要切記,Core Web Vitals 看的是 Search Console 裡的「實場資料」(過去 28 天真實讀者體驗到的分數),而不是 PageSpeed Insights 跑出來的「實驗室資料」,所以修完不會馬上看到指標變綠,通常要等兩到四週資料累積才看得到改善。
Q5:網站速度要多快才夠?
行動版 LCP 在 2.5 秒以內是理想,3 秒是及格線,超過 3 秒就會明顯流失讀者。桌機版通常快得多,不需要特別追求。要切記,PageSpeed 分數不是越高越好,而是過門檻就好,為了滿分砍掉追蹤碼或表單功能,本末倒置。實務建議是先把行動版 LCP 壓到 2.5 秒、CLS 修到 0.1 以內、INP 修到 200 毫秒以內,之後再追求更快的分數。
Q6:WordPress 網站要做技術 SEO 一定要裝外掛嗎?
多數人需要。Rank Math 或 Yoast 幫你自動產生 Sitemap、結構化資料、Canonical、麵包屑,降低出錯機率;WP Rocket 或 LiteSpeed Cache 幫你做頁面快取與資產最佳化。但外掛只是工具,觀念還是人要懂。常見的反而是裝太多功能重疊的外掛,設定互相衝突,反而把網站弄慢弄壞。完整的 WordPress SEO 工程在站內的 WordPress SEO 最佳化一文。
Q7:JavaScript 很多的網站(React/Vue)技術 SEO 會比較難嗎?
會。Google 對 JavaScript 是兩階段索引,先抓 HTML 再排渲染佇列,核心內容藏在 JS 裡等於強迫 Google 多等一趟。改善動作包括伺服器端渲染(SSR)或靜態生成(SSG)、為爬蟲提供動態渲染版本、用原生 <a href> 取代 JS 跳轉、用 GSC URL 檢查確認已渲染 HTML 包含你期待的內容。能 SSR 就 SSR,否則至少做預渲染或動態渲染。
Q8:技術 SEO 做完一次就不用再做嗎?
不是。外掛升級、網站改版、演算法更新、主機環境變動都會把技術 SEO 弄壞,它是保養型工作不是一次性任務。建議每季跑一次完整健檢、每月看一次 GSC 三大報告、每次改版後立刻補一次,把技術債清零的節奏就是排名天花板抬升的節奏。〈SEO 必懂 7 大趨勢〉會建議把技術 SEO 健檢列入每月例行節奏,與內容審查、內部連結審查一起做。
結語:往第 5 章出發
第四章到這裡,你應該已經有四個東西:技術 SEO 的七大健檢面向、可爬取性與可索引性的實作步驟、一份每季健檢清單、七個新手錯誤的迴避指南。剩下 8 章會把這套底盤的每一段走細,從內容行銷開始,一路走到 AI SEO 與未來趨勢。記住一件事:技術 SEO 是保養型工作,做完一次不是永遠有效,但每季健檢一次,排名天花板會持續抬升,這是技術 SEO 與內容產出最大的不同。
準備好往下一步走了嗎?〈第 5 章:SEO 內容行銷〉會帶你把第三章做好的單頁、第四章做好的底盤,放進一套能持續產出優質內容的內容策略。如果你想回頭看〈第 1 章〉建立全局,或複習〈第 2 章:關鍵字研究〉找出對的字、第三章 On-Page SEO 把每一頁做到位。如果你想看整堂課的導覽,〈免費 SEO 教學與課程總覽〉是入口。如果你已經有自己的網站想試身手,〈SEO 排名因素〉是延伸閱讀。我們在第 5 章見。