技術 SEO 完全指南：讓 Google 正確讀懂你的網站
技術 SEO 是讓 Google 讀得到你網站的地基：這一課涵蓋可檢索、可索引、可被理解、網址結構、Core Web Vitals 速度與行動優先索引六大層次，並附九項健檢清單，幫你找出「有寫卻排不上」的技術兇手。
作者：褚崇名（Sliven）
本頁目錄
- 技術 SEO 為什麼是地基，不是裝飾
- 可檢索：robots.txt、sitemap、爬取預算
- robots.txt：網站的門口警衛
- sitemap.xml：把地圖遞給 Google
- 爬取預算：大型或複雜網站才需要優先處理
- 可索引：noindex、canonical、重複內容處理
- noindex：直接告訴 Google 不要收錄
- canonical：處理重複內容的標準網址
- 四種重複內容處理方式的比較
- 可被理解：結構化資料與語意
- 常見的結構化資料類型
- 怎麼部署結構化資料
- 網址結構與中文網址 SEO
- 好網址的幾個原則
- 中文網址的 SEO 兩難
- HTTPS 與網址一致性
- 網站速度與 Core Web Vitals
- 三個核心指標
- 速度優化的優先順序
- 行動優先索引
- 行動版的檢查重點
- 一份技術 SEO 健檢清單
- 常見問題 FAQ
- 技術 SEO 一定要會寫程式嗎
- 技術 SEO 和內容 SEO 哪個比較重要
- Core Web Vitals 多少分才算及格
- 中文網址會影響 SEO 排名嗎
- sitemap 要多久更新一次
- 完成本課
技術 SEO 做的事，是讓 Google 的爬蟲進得來你的網站、把頁面收進索引、讀懂每個頁面在講什麼，而且讀得夠快。它是地基，因為關鍵字、內容、連結這些你比較熟悉的環節，全部都架在「搜尋引擎讀得到你」這個前提之上；地基沒打穩，上層做再多優化都是在空轉。這一課會把可檢索、可索引、可被理解、網址結構、速度、行動優先這六個層次一次講清楚，結尾再給你一份能對著自己網站逐項打勾的健檢清單。
技術 SEO 為什麼是地基，不是裝飾
其實不少人都遇過這種情況：花了三天寫一篇紮實的文章，發布後等了一個禮拜，在 Google 怎麼搜都搜不到。你開始懷疑內容不夠好、關鍵字沒下對，於是回去改標題、塞更多字。但真正的兇手常常不在內容，而在更前面那一層：搜尋引擎根本還沒把這篇文章讀進去。我手上輔導過的站，第一個月流量起不來，原因出在技術地基的，比出在內容的還多。
一個常見的誤解是把技術 SEO 當成「工程師的事」「等網站變大再來管」。小站也該先確認重要頁面可被檢索與索引，不過多數小型網站不需要特別優化爬取預算；Google 官方主要建議大型、更新頻繁或出現明顯檢索問題的網站關注這件事。小站更常見的風險，是全站 noindex、錯誤轉址或權限設定等基本問題。
我把技術 SEO 想成一個直白的比喻：摩擦力。搜尋引擎要讀你的網站，中間會經過一道又一道關卡，每一道關卡沒處理好，就多一層摩擦力。摩擦力越大，Google 越難把你該被收錄的頁面正確收錄。技術 SEO 的工作，就是一道一道把摩擦力拆掉，讓搜尋引擎滑進你的網站時越順暢越好。
還有一個觀念我想先講清楚，免得你把力氣放錯地方。技術 SEO 不會憑空把你排上第一頁，它做的事是「把天花板抬高」：移除那些卡住你的障礙，讓你內容與連結的努力能真正發揮。一個地基很乾淨但內容很空的站，不會因為技術 SEO 做好就突然有流量；但一個內容很紮實、地基卻漏風的站，把風補起來，常常會看到一波明顯的成長。這一課就是教你怎麼把風補起來。
改版時最該防的技術錯誤之一：把測試環境的
Disallow: /或 noindex 一起帶到正式站。前者會阻止 Googlebot 檢索，後者在被讀取後可能讓頁面退出索引。上線清單應明確檢查 robots.txt、meta robots、HTTP 標頭與驗證權限，不要等流量變化才發現。
可檢索：robots.txt、sitemap、爬取預算
可檢索是最底層的前提。Google 的爬蟲得先走進你的網站、沿著連結把頁面一個個抓下來，後面的事才有得談。這一層會出問題，通常是三個地方：robots.txt 寫錯規則、sitemap 沒有或沒提交、爬取預算被低價值頁面吃掉。
robots.txt：網站的門口警衛
robots.txt 是放在網站根目錄的一個小檔案（網址是 你的網域/robots.txt），它告訴遵守規則的爬蟲哪些路徑不要抓。最常見的兩種錯誤：一種是開發階段加了 Disallow: /，上線後忘記拿掉；另一種是把不想被收錄的頁面用 robots.txt 擋掉，導致 Google 看不到頁面上的 noindex，網址仍可能因外部訊號出現在搜尋結果。robots.txt 不是存取控制，機密、後台與私人內容必須用登入驗證或伺服器權限保護。
記住一個原則：robots.txt 用來擋 crawl，noindex 用來擋 index，兩者不要混用。如果你希望某頁不要出現在搜尋結果，正確做法是允許爬蟲抓它（robots.txt 不擋），再用 noindex 告訴 Google 不要收錄。這個差別我在robots.txt 與 noindex 的比較那篇有完整展開，搞混的人非常多。想完整搞懂 robots.txt 的寫法，可以讀這篇 robots.txt 教學。
sitemap.xml：把地圖遞給 Google
sitemap 是你提供給 Google 的標準網址清單，用來協助發現頁面。沒有 sitemap，爬蟲仍能沿著內部連結找到內容；提交 sitemap 也不保證檢索、索引或排名。大型網站、新站、新聞站或內部連結較不完整的網站通常更需要它。可以把 sitemap 網址寫進 robots.txt（Sitemap: https://你的網域/sitemap.xml），並在 Google Search Console 的「Sitemap」欄位提交。
sitemap 應放你希望出現在搜尋結果中的標準網址，並與 canonical、狀態碼與索引指令一致。不要放被 noindex、重新導向、回傳錯誤或非標準版本的網址。列錯網址不等於其他頁面一定會被「擠掉」，但會讓 sitemap 報告難以判讀，也浪費不必要的檢索。
爬取預算：大型或複雜網站才需要優先處理
爬取預算（crawl budget）是 Googlebot 能且願意在網站上投入的檢索資源，不是固定配額。多數僅有數百或數千個正常頁面的網站，不必把它列為優先專案；真正需要關注的通常是大型網站、更新非常頻繁的網站，或 Search Console 已顯示檢索與發現問題的網站。
參數網址與多面向篩選確實可能產生大量組合。處理方式要看平台：避免生成無限網址、限制內部連結、為近似頁面提供一致 canonical，或讓不需要索引的頁面可被檢索後讀到 noindex。Search Console 的舊「網址參數」工具已在 2022 年停止使用，不能再依賴。想深入看爬取預算怎麼優化，我把實務做法整理在爬取預算的七大優化策略那篇。
可索引：noindex、canonical、重複內容處理
爬蟲抓到了頁面，不代表它會被收進索引庫。索引是 Google 認定「這個頁面值得放進搜尋結果」的動作，這一層的核心問題是：你的站上有沒有大量不值得索引的頁面，在稀釋 Google 對你重要頁面的注意力。
noindex：直接告訴 Google 不要收錄
noindex 可以放在頁面 <head> 的 meta 標籤（<meta name="robots" content="noindex">），或寫在 HTTP 標頭裡，用來要求支援該指令的搜尋引擎不要把頁面放進搜尋結果。它適合感謝頁、內部搜尋結果頁或部分篩選頁。登入後內容應先用驗證保護，不能把 noindex 當成隱私或安全機制。
一個關鍵觀念：noindex 不能單獨存在，必須搭配允許爬蟲抓取。如果你同時用 robots.txt 擋掉爬蟲、又設了 noindex，Google 根本抓不到頁面，也就看不到 noindex 指令，這時候那個頁面反而可能因為外部連結的關係出現在索引裡。所以設定 noindex 的頁面，robots.txt 一定要允許 crawl。
canonical：處理重複內容的標準網址
同一份或近似內容出現在多個網址，是網站的常態，例如獨立行動版、列印版、追蹤參數、http 與 https。這不會自動受到重複內容處罰，但搜尋引擎需要選出代表版本。canonical 標籤（<link rel="canonical" href="標準網址">）是向 Google 提示偏好的標準網址；Google 會綜合重新導向、sitemap、內部連結等訊號，仍可能選擇不同版本。
canonical 是技術 SEO 裡最容易設錯的指令之一。常見的錯誤包括：全站每個頁面的 canonical 都指向首頁（等於告訴 Google「我整個站僅有一頁有價值」）、canonical 指向被 noindex 的頁面、或忽略了參數網址沒設 canonical 導致追蹤連結被當成獨立頁面收錄。canonical 的細節與誤用案例，我在SEO Canonical 標準網址那篇有完整展開，強烈建議讀一次。
四種重複內容處理方式的比較
| 情境 | 正確工具 | 為什麼 |
|---|---|---|
| 頁面對使用者有用，但不該從搜尋進來（感謝頁、內部搜尋結果） | noindex | 允許爬蟲抓、但不收錄，索引位置留給重要頁面 |
| 同一份內容多個網址（行動版、參數、列印版） | canonical | 合併權重到標準網址，避免自己搶自己的排名 |
| 後台、測試環境或私人內容 | 登入驗證、網路限制或伺服器權限 | 真正限制存取；robots.txt 不能保護內容 |
| 兩個頁面內容重複，但其中一個已沒有存在必要 | 301 重定向 + 刪除 | 永久把權重與流量轉移到留下的頁面 |
這幾種工具不是互斥的，重點是搞清楚每個工具解決的是哪個層次的問題。把 noindex 當 canonical 用、或把 robots.txt 當 noindex 用，是我看過最常見、也最隱形的技術 SEO 錯誤。
site: 查詢可以抽看 Google 顯示哪些網址，但結果數是粗略估計，不能拿來盤點完整索引。比較可靠的做法是看 Search Console「網頁」報告、sitemap 與伺服器或爬蟲清單，再抽查 Google 選定的 canonical。發現參數、列印版或標籤頁時，先判斷用途，再用重新導向、canonical、noindex 或內部連結規則處理；不要把所有重複網址都視為處罰。
可被理解：結構化資料與語意
頁面被收錄了，Google 還要判斷它在講什麼、跟其他頁面是什麼關係。Google 從文字內容、標題、連結去推測頁面的主題，但這個推測過程有可能誤解，也有成本。結構化資料（structured data）的作用，是用一套 Google 公開的格式（schema.org 詞彙表），直接把「這是一篇文章、作者是誰、發布時間是哪天、這是一個產品、價格多少、庫存多少」這些事實用機器讀得懂的方式標示出來。
結構化資料不會憑空把你排上第一頁。它以標準格式描述頁面內容，部分 Google 支援的類型可讓頁面取得複合式搜尋結果資格，例如產品資訊與桌面版麵包屑；是否顯示仍由 Google 決定，也不保證點閱率提升。
常見的結構化資料類型
結構化資料的詞彙表很大，但對多數內容站來說，常用的就那幾個：
- Article：可描述文章標題、發布時間、更新時間、作者與圖片。Google 的 Article 文件沒有 required properties，列出的欄位屬建議內容；是否部署應依網站需求決定。
- BreadcrumbList：描述頁面在網站階層裡的位置，可取得桌面版搜尋結果麵包屑資格；Google 自 2025 年起不再於行動版結果顯示麵包屑。
- FAQPage：Schema.org 詞彙仍存在，但 Google 已在 2026 年 5 月停止 FAQ 複合式搜尋結果，不要再以取得 FAQ 版位為部署理由。
- HowTo：Schema.org 詞彙仍可供其他系統使用，但 Google Search 已不提供舊有 HowTo 複合式搜尋結果。
- Product / Review：產品頁與評論頁，顯示價格、庫存、評分星等，電商站必備。
- Organization / WebSite：提供網站名稱與組織層級資訊。Google 已在 2024 年停止 sitelinks search box 顯示，WebSite 標記不應再以取得該搜尋框為理由。
怎麼部署結構化資料
結構化資料可用 JSON-LD、Microdata 或 RDFa，Google 通常建議採 JSON-LD。部署後可用 Google 的複合式結果測試工具檢查語法、支援欄位與該類型真正要求的 properties，再到 Search Console 查看適用的複合式搜尋結果報告。不要把某一類型的必要欄位套到所有 Schema；例如 Article 就沒有 required properties。想完整搞懂結構化資料的類型與實作，讀SEO 結構化資料介紹那篇。
一段文章頁最基本 JSON-LD 的長相大概是這樣，你可以對照自己的後端有沒有把這些欄位輸出對：
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "文章標題",
"author": { "@type": "Person", "name": "作者名" },
"datePublished": "2026-07-14",
"dateModified": "2026-07-14",
"image": "https://你的網域/封面圖.jpg",
"publisher": {
"@type": "Organization",
"name": "網站名稱",
"logo": { "@type": "ImageObject", "url": "https://你的網域/logo.png" }
}
}幾個容易踩的坑：日期要符合 ISO 8601 並與頁面可見資訊一致；image 應使用可檢索的代表圖片網址，Google 建議高解析度圖片，並依文件提供適合的長寬比；作者、日期、價格或評論等標記也必須與使用者看得到的內容一致。Article 沒有 required properties，上面的 JSON-LD 僅是示例，不是「少一欄就報錯」的固定範本。
網址結構與中文網址 SEO
網址（URL）是技術 SEO 裡一個容易被低估的環節。好的網址結構同時服務三個對象：使用者看得懂、Google 讀得懂、未來好維護。壞的網址結構一旦上線、被收錄、被外部連結指向，要改就很痛，因為每一個改動都牽涉到 301 重定向，改不好還會把累積的權重丟掉。所以網址結構最好在上線前就想清楚。
好網址的幾個原則
- 簡短、可讀、包含關鍵字：一個理想的網址讓人光看網址就大概知道頁面內容，例如
/seo-guide比/p=12345好。 - 用連字號分隔單字：Google 官方建議用連字號（-）分隔詞，不要用底線（_），因為 Google 的斷詞器把連字號當空白處理。
- 路徑保持可管理：
/category/article通常比堆疊不必要目錄更容易閱讀。不過網址層數不等於點擊深度；爬蟲是否容易觸及，主要看內部連結。 - 參數要有一致規則：搜尋引擎可以處理動態網址。真正的風險是無限組合、同內容多網址與不一致的 canonical，而不是網址出現問號就一定有問題。
- 小寫、不要用特殊字元：大寫小寫在某些伺服器被當成不同頁面，空格與特殊字元則會被編碼成一串 % 符號，又醜又難維護。
中文網址的 SEO 兩難
在台灣與華語市場，站長常問：網址要用中文還是英文？這是一個沒有絕對答案、但可以照原則判斷的問題。中文網址有兩種形式：一種是直接用中文字（例如 /技術seo指南），瀏覽器會顯示中文，但實際傳輸時是被編碼成 %E6%8A%80... 這種一長串百分號編碼；另一種是英文或拼音（例如 /technical-seo-guide）。
中文與英文 slug 都能被 Google 處理。中文路徑在複製到某些系統時可能顯示百分比編碼，英文 slug 則較方便跨系統閱讀與維護；這是操作取捨，不是英文排名較穩。選定一種可長期維護的規則並保持一致即可。
使用中文路徑時，確認伺服器、CMS、sitemap 與內部連結都輸出一致的百分比編碼即可。Punycode 用於國際化網域名稱，不是一般網址路徑。不要僅因網址是中文就把 canonical 指向不同內容的英文網址；canonical 必須指向同一份或高度近似內容的代表版本。
HTTPS 與網址一致性
HTTPS 是現代網站的最低標準。Google 在 2014 年把 HTTPS 列為輕量排名訊號，而 Chrome 等瀏覽器會把非加密的 http 頁面標示為「不安全」，影響使用者信任。上 HTTPS 之外，還要做到網址一致性：固定一個網域版本（有 www 或沒有 www），http 全部 301 轉到 https，非標準網域版本轉到標準網域版本。這些變體是不同的 URL 或主機名稱，應用重新導向與 canonical 清楚整併，不要讓多個版本同時可用。完整設定流程可讀HTTPS 與 SSL 入門。
網站速度與 Core Web Vitals
速度很容易憑感覺誤判。桌面電腦與高速網路下的體驗，可能和行動裝置、較慢網路下差很多。Core Web Vitals 用來衡量載入、互動與視覺穩定性；它們是頁面體驗的一部分，也是相對輕量的排名訊號，首要價值仍是改善使用者體驗。
三個核心指標
| 指標 | 衡量什麼 | 及格標準 | 常見原因 |
|---|---|---|---|
| LCP（最大內容元素繪製） | 頁面最大那塊內容（通常是主圖或大標題）多快載入完成 | ≤ 2.5 秒 | 大圖未壓縮、伺服器回應慢、渲染被 CSS 或 JS 阻擋 |
| INP（互動到下一次繪製） | 使用者點按後頁面多快有視覺回應 | ≤ 200 毫秒 | 過多的第三方腳本、未優化的 JavaScript、長任務阻塞主執行緒 |
| CLS（累計版面位移） | 頁面載入過程畫面會不會突然跳動 | ≤ 0.1 | 圖片沒設長寬、廣告或字體動態插入、動態載入元素 |
INP 是 2024 年三月正式取代舊指標 FID（首次輸入延遲）的新指標，比 FID 嚴格很多，很多過去能過關的站在 INP 上反而卡住，值得特別注意。想看這三個指標怎麼逐項優化，我把實戰做法整理在Core Web Vitals 完全攻略，網頁速度的整體優化方向則在網頁速度優化那篇。
速度優化的優先順序
速度優化很容易陷入「改很多、但感覺沒差」的陷阱，因為可改的東西太多。我建議照下面這個順序，把影響最大的先做掉：
- 壓縮與正確尺寸的圖片：這是多數網站 LCP 不及格的第一兇手。改用 WebP 或 AVIF 格式、設定正確的顯示尺寸、加上
loading="lazy"給非首屏圖片，通常一個動作就能把 LCP 拉一大截。 - 伺服器回應時間（TTFB）：如果伺服器本身回應就慢，後面再怎麼優化前端都有限。檢查主機效能、使用 CDN、啟用快取。
- 減少阻塞渲染的 CSS 與 JS：把非必要的腳本延後載入（defer / async）、移除沒在用的 CSS、避免載入整個框架僅用其中一小塊。
- 移除多餘的第三方腳本：分析工具、追蹤碼、聊天室、廣告腳本，每一個都會吃效能。定期盤點，把沒在用的或重複的拿掉。
- 為圖片與廣告預留空間：在圖片、嵌入式影片、廣告欄位上設定固定長寬，避免它們載入時把下方內容擠動，這是修 CLS 最直接的方法。
做完之後，回到 PageSpeed Insights 跑一次實際數據，不要用感覺認定。那個工具會給你兩種數據：一種是「實驗室資料」（Lab Data，工具當場模擬跑出來的），一種是「實際使用者資料」（Field Data，來自真實訪客的 Chrome 使用體驗報告）。Google 排名用的是後者，所以要以 Field Data 為準。
這裡有一個新手常見的迷思要破除：實驗室分數不是越高就保證排名越好。改善明顯緩慢或不穩定的頁面，通常能直接提升使用體驗；Core Web Vitals 在搜尋排名中則是較輕量的頁面體驗訊號，沒有「過線就取得固定加分」的公式。先處理真實使用者資料中未達良好門檻的頁面，再依影響範圍與工程成本排序，不必為了把單次測試從 90 分推到 95 分而犧牲更重要的內容與技術工作。
行動優先索引
行動優先索引（mobile-first indexing）是 Google 主要使用智慧型手機版內容進行檢索與索引的做法，已全面實施。它描述的是索引基準，不是「手機版」這個獨立排名加分項。如果行動版沒有桌面版的重要內容、內部連結或結構化資料，Google 可能無法從主要版本取得那些資訊。
對大多數用響應式設計（responsive design）的現代網站來說，行動優先索引不是問題，因為同一份 HTML 同時服務桌面與行動，內容本來就一致。問題通常出在兩種情況：一是老網站用獨立的行動版網域（例如 m.網域.com），桌面版與行動版是兩套程式碼，很容易出現內容不同步；二是響應式設計裡用 display:none 把某些元素在手機上隱藏，誤以為「反正手機上看不到」，但 Google 是抓行動版 DOM，被隱藏的內容如果還在 DOM 裡就會被讀到，不在 DOM 裡就真的讀不到。
行動版的檢查重點
- 內容一致性：桌面版有的重要內容、標題、內部連結、結構化資料，行動版也要有。不要為了手機版面而刪掉實質內容。
- 可點擊元素大小：按鈕與連結要夠大、間距要夠，手指點得到。這同時影響使用者體驗與 INP。
- 字體與版面：字體在手機上要夠大、不要出現橫向捲動。
- 檢查工具：Search Console 的「行動裝置可用性」報告與 Google 行動裝置相容性測試都已在 2023 年停止。改用 PageSpeed Insights、Lighthouse、Chrome DevTools 與實機測試，並在網址檢查中查看 Google 抓取狀態。
行動優先不是另一個獨立的技術 SEO 主題，它其實是把前面講的所有層次（可檢索、可索引、結構化資料、速度）放到行動版這個基準上重新檢查一遍。你做每一項技術優化時，都要問自己：這個優化在手機版的表現如何，而不是僅在桌面版看起來沒問題就放過。
有一個很實際的檢查動作，我建議每個站長至少做一次：用你的手機，切到行動網路（不要用家裡的 Wi-Fi），打開你自己網站的前五個重要頁面，像一個第一次來的訪客那樣實際用一遍。點選單、讀文章、點內部連結、填表單。你會立刻發現哪些地方在手機上卡卡的：選單點不開、圖片擋住文字、按鈕太靠近誤觸、某個段落字小到要放大才能看。這些都是報告數字不一定能完全反映、但真實影響使用者留存的問題。技術 SEO 工具告訴你機器讀起來的狀況，自己的手機告訴你真人用起來的狀況，兩個都要看。
如果網站仍有獨立行動版（例如 m. 子網域），要確認行動版與桌面版互相對應，內容與結構化資料一致，並依 Google 文件設定 canonical 與 alternate。多語系或多區域網站的 hreflang 必須讓各版本雙向回指，也要列出自己；細節可讀hreflang 多語系 SEO。
一份技術 SEO 健檢清單
前面六個層次講完，現在你需要的是一份能照著跑的健檢流程。下面這份清單是我自己對著新站、或接手一個陌生網站時，逐項打勾的順序。照這個順序走，你會在半天內對一個網站的技術健康度有完整的掌握。你可以把它當作動手練習，直接拿你自己的網站跑一次。
- 看索引狀態：打開 Google Search Console，左側選「網頁」。看「已編入索引」有多少頁，點開「未編入索引」逐一檢查原因。重點看「遭到 noindex 標記排除」「已檢索但尚未編入索引」「重複網址」「遭 robots.txt 封鎖」這幾類的數量。把數量異常大的記下來。
- 檢查 robots.txt：在瀏覽器打開
你的網域/robots.txt，確認沒有Disallow: /把全站擋掉，重要路徑沒有被誤擋，並且有寫入 sitemap 網址。 - 提交 sitemap：到 Search Console 的「Sitemap」欄位，確認 sitemap 有提交、狀態是「成功」。如果還沒提交，提交一次。
- 抽查 canonical：隨機挑五個重要頁面，檢視原始碼看
rel="canonical"指向的網址是不是頁面本身的標準網址，有沒有指到首頁或被 noindex 的頁面。 - 查重複網址：以 Search Console「網頁」報告、sitemap 與網站爬取清單比對索引狀態，再抽查 Google 選定的 canonical。
site:可用來抽看，不要把結果數當成完整索引統計。 - 驗證結構化資料：用 Google 複合式結果測試工具跑首頁與一篇文章頁，看結構化資料有沒有錯誤、缺欄位。再到 Search Console「複合式結果」報告看有沒有大面積錯誤。
- 跑行動版與速度：在 PageSpeed Insights 貼上首頁網址，手機版跑一次，抄下 LCP、INP、CLS 三個數值與不及格的項目。再到 Search Console「Core Web Vitals」報告看整站的體驗分布。
- 查 HTTPS 與一致性：確認網站走 https、http 會 301 跳轉、www 與非 www 僅有一個版本生效。在瀏覽器分別開這幾個版本，看是不是都導向同一個標準網址。
- 看內部連結：在 Search Console「連結」報告看內部連結最多的頁面是不是你最重要的頁面。如果重要頁面內部連結很少，那是下一課要處理的內部連結議題。
跑完這九個項目，你會得到一份你網站的地基體檢報告：哪一層漏、漏多大、第一個要修的是什麼。我的建議是照報告的嚴重程度修，不要同時全改。被封掉整個站的問題，比單一頁面 canonical 沒設重要幾百倍，先修會立即止血的。
常見問題 FAQ
技術 SEO 一定要會寫程式嗎
不一定。技術 SEO 大部分的工作是設定與檢查，而不是從頭寫程式。robots.txt、sitemap、canonical、noindex、結構化資料這些，多數 CMS（WordPress、Astro、Shopify）都有外掛或設定欄位能處理，不需要動到程式碼。你需要的是看得懂這些設定的意義、會用 Search Console 與 PageSpeed Insights 診斷、會判讀報告。真正需要寫程式的，通常是大型電商或客製化網站的複雜情境，那時候再找工程師配合。對小型站長來說，不會寫程式完全可以把基本功打好。
技術 SEO 和內容 SEO 哪個比較重要
技術 SEO 是地基，內容 SEO 是房子，兩者不是擇一。先修阻止檢索、索引或正常使用的明顯問題，再持續投入內容；近似重複內容本身不等於處罰，Core Web Vitals 也僅是較輕量的排名訊號。技術修正能移除障礙，但沒有固定一兩個月就會成長的保證。
Core Web Vitals 多少分才算及格
Core Web Vitals 的及格不是一個分數，而是三個指標各自有門檻：LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1。要注意的是，Google 排名用的是來自真實使用者的 Field Data（在 Search Console 的 Core Web Vitals 報告裡），不是 PageSpeed Insights 當場模擬的 Lab Data。兩者方向一致但數字會有差距，以 Field Data 為準。三項全部及格是「良好」，有任何一項在門檻邊緣或不及格就需要處理。不用追求滿分，先把不及格的拉到及格線以上，投報比最高。
中文網址會影響 SEO 排名嗎
中文網址 Google 能處理，不會因為是中文就被扣分。但中文網址有幾個實際副作用，會間接影響 SEO 成效：分享與被連結時容易出現編碼亂碼，降低被自然連結的意願；在台灣的論壇、通訊軟體裡顯示不穩定；管理與維護成本較高。我的建議是除非有明確的在地化理由，一般用英文 slug。這不是因為中文網址直接傷排名，而是英文 slug 在被連結、被分享的現實環境裡更穩定，長期累積的連結與權重會更乾淨。
sitemap 要多久更新一次
sitemap 的更新頻率應該跟你的發文頻率一致。如果你用 CMS，sitemap 通常是每次發布新內容自動更新的，不需要手動維護。重點不在於多常更新，而在於 sitemap 裡的網址都是你希望被收錄的優質頁面，沒有混入被擋的、重複的、薄的頁面。新站或剛改版的站，發布後可以手動到 Search Console 重新提交一次 sitemap，加快 Google 抓取。穩定運作的站，Google 會自己定期來抓 sitemap，不用每篇都手動提交。
完成本課
這一課帶你把技術 SEO 想成「搜尋引擎讀你網站的摩擦力」，並走過可檢索、可索引、可被理解、網址結構、速度、行動優先這六個層次，收尾用一份九項健檢清單讓你對著自己的網站跑一次。你現在手上應該有一份地基體檢報告，知道漏在哪一層、第一個該修什麼。技術 SEO 不會一次做完就永遠不動，網站會長大、會改版、會加新功能，每一個變動都可能偷偷加上新的摩擦力，所以把它當成定期體檢，不是一次性裝修。
地基補好之後，接下來要蓋的是內容這棟房子。下一課我們進到內容與內部連結，談怎麼為真人寫、同時為搜尋引擎鋪好路，把你在這堂課打穩的地基，真正承接起流量。前往下一課：內容 SEO →
← 回課程總覽 | ← 上一課：關鍵字研究 | 下一課：內容 SEO →
作者是 Sliven 褚崇名，Whoops SEO 創辦人。技術 SEO 修的通常是已經存在、但尚未被發現的檢索、索引或呈現問題。