技術性 SEO 完全指南：網站架構優化與排名提升

技術性 SEO 在解決什麼：把「好內容」變成「Google 看得到的好內容」

想像一下，你花了三個月寫出一篇一萬字的深度指南，上架那天滿心期待地打開 Google Search Console，等了一週、兩週，那篇文章始終停留在「已檢索，尚未建立索引」。你回頭檢查文字，沒有錯字、論點紮實、關鍵字也佈局了。問題不在內容，問題在於 Google 的爬蟲根本沒走進你這一頁，或者走進了卻讀不懂你在講什麼。

這就是技術性 SEO 存在的理由。它決定你的內容「能不能被看見」，是所有搜尋流量的地基。把一篇好文章放上線，不等於它會出現在搜尋結果裡；它得先通過 Google 的三道關卡：找得到、讀得懂、願意推薦。

技術性 SEO 解決的核心問題只有一個：移除你的網站與 Google 理解之間的摩擦。爬蟲進得來嗎？進來讀得懂嗎？讀懂了會推薦嗎？這三句話，就是整篇文章的主軸。

Ahrefs 的 2023 年搜尋流量研究指出，其資料庫中超過九成的頁面沒有取得 Google 自然搜尋流量。這份研究不能證明無流量主要源自技術問題；搜尋需求、連結、排名、內容與索引都可能影響結果。技術 SEO 的工作，是先排除爬取、索引與呈現上的可驗證障礙。

SEO 這個大工程，實務上通常拆成三塊來看。站內 SEO 處理內容與單頁優化，站外 SEO 處理反向連結與品牌聲量，技術性 SEO 則是底層的工程與結構。前兩者決定你「值不值得排名」，技術性這一塊決定你「有沒有資格被放進排名的候選名單」。順序錯了，再好的內容也會被擋在門外。想把三塊串起來看，可以接著讀 SEO 搜尋引擎優化完整指南。

你的網站對 Google 說的三句話：本文的核心框架

把技術性 SEO 重新組織成三個層次，對應你的網站必須對 Google 成功傳達的三句話：

• 讓我進門（Crawlability）：爬蟲找得到、進得來你的每一個頁面。
• 讓我讀懂（Understandability）：爬蟲看懂這一頁的主題、結構、與其他頁面的關係。
• 讓我推薦你（Rankability）：爬蟲相信這一頁值得端給真人使用者。

接下來三個段落，會一層一層拆開。你看完之後會發現，那些你聽過的技術名詞（robots.txt、sitemap、canonical、Core Web Vitals、HTTPS、schema），其實都能歸進這三句話裡，不再是一堆零散的清單。這個分類方式，也是做網站健檢時腦袋裡的決策樹：看到一個症狀，先判斷它屬於哪一層，再往下找根因。

為什麼要特意用「三句話」來組織，而不直接給你一長串檢查表？因為檢查表的問題在於，它讓你誤以為把每個格子打勾就等於做好技術性 SEO。真實世界裡，網站的技術問題常常是牽一髮動全身的：你為了擋掉低價值頁面而修改 robots.txt，可能不小心連帶封鎖了重要的 CSS 與 JavaScript，導致渲染後的內容 Google 看不到；你為了加快速度而快取了整個頁面，可能讓使用者在結帳時看到別人的購物車。用「三句話」把目的講清楚，你才會知道每一個技術動作到底服務哪一個目的，而不會為了打勾而打勾、改了 A 卻弄壞 B。

層次	核心問題	對應技術	壞掉時你會看到的症狀
讓我進門	爬蟲找得到頁面嗎	robots.txt、sitemap、內部連結、爬取預算	大量頁面「已檢索，未建立索引」、收錄數偏低
讓我讀懂	爬蟲看懂主題與關係嗎	網址結構、階層、canonical、結構化資料	關鍵字排得進去卻上不來、重複內容互相吃流量
讓我推薦你	Google 願意端給使用者嗎	速度、Core Web Vitals、行動體驗、HTTPS	點進來立刻跳出、手機版體驗差、瀏覽器安全警示

第一句｜讓我進門：爬蟲怎麼找到你的每一頁

Googlebot 會依網站狀況調整抓取量，不會無限制地抓完每一個網址。你的工作，是把網站的門開好、把路標立清楚。

robots.txt：網站的入口管理員

robots.txt 是放在網站根目錄的一個小檔案，作用是告訴爬蟲「哪些地方可以爬、哪些地方不要爬」。它像一棟大樓的門禁規則，立得好，爬蟲走得順；立錯了，整棟大樓被擋在外面。

網站改版時，常會先在 robots.txt 封鎖測試環境；若上線後忘了移除規則，Googlebot 就無法抓取正式站內容。這種錯誤修起來不難，但 robots.txt 不是測試站的安全措施，測試環境仍應使用登入驗證或網路層存取限制。

有一個常被誤解的觀念要澄清：robots.txt 的 disallow 不等於「不要收錄」。如果一個頁面被其他網站連到，Google 還是可能把它收錄進索引，只是不會去抓取頁面內容。真正要阻止收錄，得用 noindex 指令。這兩件事不要搞混，搞混的後果是該收錄的沒收錄、想封鎖的卻還在。

XML Sitemap：主動遞給 Google 的一份目錄

sitemap.xml 是你主動交給搜尋引擎的「頁面清單」，可列出希望被搜尋引擎知道的網址與最後更新時間。它能協助 Google 發現新頁面或較難靠連結找到的頁面，但不保證抓取或建立索引。提交 sitemap 的標準管道是 Google Search Console，細節可見 Google 搜尋中心的 sitemap 說明。想深入了解完整流程，可以參考 Sitemap 產生與提交實作教學，或是 網站 Sitemap 入門指南。

爬取預算：大網站繞不過的觀念

當網站規模大、內容更新頻繁，或大量網址長期停在「已發現，目前尚未建立索引」時，就要檢查爬取預算（crawl budget）。Google 會綜合網站可承受的抓取量、抓取需求與資源狀況決定抓取活動。頁面愈多、結構愈亂，篩選器、分頁與追蹤參數產生的網址就愈可能占用抓取資源。

Google 把進階爬取預算指南定位給超大型、更新很快，或有明顯抓取問題的網站，例如每週更新、約有百萬個不重複頁面的站，以及每天更新、約有一萬個不重複頁面的站。多數小型網站通常不用把它列為優先事項，這是 Google 搜尋中心爬取預算指南的官方定位。電商、內容站、論壇若產生大量可抓取網址，則應持續管理。完整的方法論整理在 爬取預算優化策略 這篇。

內部連結：爬蟲在站內移動的公路

爬蟲是順著連結走路的。從首頁出發，它靠內部連結一頁一頁發現新內容。如果某一個重要頁面沒有任何內部連結指向它（所謂的孤兒頁，orphan page），Google 要發現它的機率就會大幅降低。把內部連結布建當成一項持續的工程，而不只是寫完文章就放著，這是很多站長略過的一環。連結的類型與作用，在 四大類型連結解析 裡有完整說明。

伺服器回應與軟性 404：進門之後有沒有被善待

爬蟲進門之後，伺服器怎麼回應它，是另一個容易被看漏的細節。理想的情況是，存在的頁面回傳 200（正常），不存在的頁面回傳 404（找不到）。Google 會根據伺服器的穩定度與回應速度，動態調整它對你網站的爬取節奏：伺服器常常回 5xx（伺服器錯誤）或回應太慢，它會主動放慢爬取，避免壓垮你的主機；這對小網站是保護，對大網站卻可能變成收錄變慢的元凶。

更刁鑽的是「軟性 404」（soft 404）。這是指伺服器回傳 200，但頁面內容或呈現方式讓 Google 判斷它其實是錯誤頁，例如只有「找不到內容」的空白頁。這種回應會讓搜尋引擎把時間花在不存在的內容上。真正不存在的頁面應回傳 404 或 410；若有高度相關的替代頁，才用 301 轉向該頁。Search Console 的「網頁索引」報表會列出判定為軟性 404 的網址（見 Google 搜尋中心的疑難排解文件）。

索引控制的完整工具箱：noindex、X-Robots-Tag 與 robots.txt 的分工

把爬蟲擋在門外，和把頁面踢出索引，是兩件不同的事，工具也不同。很多人把這幾個指令混著用，結果是該索引的沒索引、該移除的還賴在搜尋結果裡。這幾個工具的分工一次講清楚。

目的	工具	作用層級	注意事項
禁止收錄單一頁面	noindex meta 標籤	HTML 頁面	必須允許 Google 抓取才能讀到；robots.txt 封鎖會讓 noindex 失效
禁止收錄非 HTML 資源	X-Robots-Tag HTTP 標頭	PDF、圖片、影片、API 回應	在伺服器或 CDN 層設定，能一次套用整個目錄或檔案類型
降低或禁止抓取	robots.txt disallow	網址路徑	只管抓取不管收錄；被外部連結指向的頁面仍可能以網址形式出現在索引
禁止索引但不另設連結限制	noindex	HTML 頁面	follow 是預設值，通常不必明寫；不要把它解讀成長期抓取或傳遞訊號的保證

這裡有幾個容易踩錯的組合。最經典的錯誤，是用 robots.txt 封鎖一個你想 noindex 的頁面：Google 進不去，就讀不到 noindex，可是只要別站連到它，Google 仍可能把它當成「知道網址存在、但沒內容」的條目留在索引裡，這就是所謂的 URL-only 索引。正確順序是先解除 robots.txt 封鎖，讓 Google 抓到 noindex，等它從索引移除後，再決定是否進一步壓低抓取。

Google 現行官方文件沒有承諾長期 noindex 頁面會按某個時程降低抓取頻率。相反地，Google 必須重新抓取頁面才能看到 noindex，而移除索引的處理可能需要數月；爬取預算指南也明確提醒，不要用 noindex 節省抓取量，因為 Google 仍得提出請求後才能讀到指令，這點在 Google 的 noindex 說明與 爬取預算指南都有交代。robots.txt 裡未正式支援的 noindex 規則，則自 2019 年 9 月 1 日起不再由 Google 採用（見當年的 A note on unsupported rules in robots.txt 公告）。

如何讓新內容更快被索引

很多站長共同的焦慮是：文章上架了，Google 要等多久才收錄？現實是，Google 不保證一定索引任何頁面，也沒有公開的固定時間表。但你可以做幾件具體的事，把「被發現」與「被處理」的摩擦降到最低，索引速度通常會跟著改善。

• 維護 XML Sitemap：新內容上架後，確認網址已進入 sitemap，並在 GSC 確認 Google 能讀取。已提交且未變更位置的 sitemap，不必每新增一頁就重新提交。
• 用網址審查的「要求索引」：對少數重要新頁面，可在 GSC 的網址審查手動觸發檢索請求。這對零基礎的新站特別有用，但它有每日額度，不是大量提交的工具。
• 從高抓取頻率的頁面連過去：首頁、分類頁、熱門文章是 Googlebot 經常造訪的節點，從這些頁面放一條一般 <a href> 連結指向新頁面，等於把爬蟲直接帶過去，比指望它自己發現快得多。
• 移除抓取與渲染障礙：新頁面別誤掛 noindex、別被 robots.txt 封鎖、JS 渲染的內容確保在初始 HTML 或能被 WRS 讀到。這些障礙會讓前面三步全部白費。

做完整套，仍可能遇到新頁面遲遲不索引。這時要回頭看的不是「再加什麼招」，而是頁面是否重複、過度單薄、品質不足，或 Google 已選擇其他網址作為代表版本。搜尋需求會影響流量，不是公開的索引資格條件。技術能移除障礙，但不能保證 Google 建立索引。

第二句｜讓我讀懂：網址、階層、重複內容與結構化資料

爬蟲進門之後，下一個挑戰是讀懂。Google 要理解的不只是「這一頁的文字內容」，還包括這一頁在整個網站裡的地位、跟其他頁面的關係、以及它到底是什麼「東西」。

網址結構：URL 是給機器讀的第一行線索

一個乾淨、可讀、帶有描述詞的網址，對使用者和搜尋引擎都有幫助。Google 官方文件建議網址結構保持簡單，使用可讀、具描述性的字詞，並減少不必要的參數。比較一下這兩個網址：

• yoursite.com/p=12345&cat=4&session=abc
• yoursite.com/seo/technical-seo-guide

後者一眼就能看出主題與分類，前者連人都看不懂，更別說要 Google 判斷關聯。網址不只是位址，它是一種語意訊號。實際的命名規則與 WordPress 永久連結設定，可以參考 SEO 網址優化指南 和 WordPress 永久連結設定教學。

網站階層：扁平與深層的取捨

一個結構清楚的網站，應使重要頁面能從首頁或主要分類透過少量連結抵達。「三到四次點擊」可當檢查用的經驗法則，不是 Google 的排名門檻；真正要避免的是重要內容被埋得太深，導致爬蟲與使用者都不容易找到。

網站架構可以想成一棵倒過來的樹：首頁連到主要分類，再連到文章或商品。清楚的階層與一般 HTML 連結能幫助讀者和爬蟲發現重要頁面，但「離首頁愈近就繼承固定較高權重」不是公開公式。詳細做法可看SEO 友善的網站架構與網站架構圖規劃全攻略。

重複內容與 Canonical：別讓自己跟自己搶排名

同一份內容出現在多個網址上，是技術 SEO 常見問題。可能是 www 與非 www、HTTP 與 HTTPS 並存，也可能是篩選器產生大量變體。Google 通常會從相似頁面中選擇 canonical，而不是把它們視為「互相搶字」或施加重複內容處罰；站方仍應統一轉址、canonical 與內部連結，減少爬取和代表網址選擇的不確定性。

canonical 標籤用來指出一組重複或高度相似網址中的偏好版本。它不會把使用者導走，而且是 Google 會與轉址、sitemap、內部連結等訊號一起判斷的提示。完整設定方法與常見錯誤整理在 Canonical URL 完全指南。永久搬頁優先使用 301 或 308；短期移動可用 302 或 307，Google 仍會依情境處理 canonical 與訊號，不宜簡化成「暫時轉址就完全不移交權重」。相關差異見 301 與 302 轉址。

篩選器導覽：電商與內容站的隱形殺手

如果你的網站有篩選器、排序、分頁這類互動功能（電商最常見：顏色、尺寸、價格區間、排序方式排列組合出成千上萬個網址），你正面對的，是技術性 SEO 裡最容易翻車的一塊。每一個篩選組合都可能產生一個新的、可被索引的網址，而這些網址的內容彼此高度重疊，等於你主動製造了幾千份「重複內容」讓爬蟲去消化。

正確的處理方式是分類管理：有搜尋價值的篩選組合才考慮開放索引，其他的依目的使用工具。內容確實重複且有代表頁時可用 canonical；要阻止索引用 noindex，但必須允許 Google 抓到頁面；要降低特定網址模式的抓取才用 robots.txt。麵包屑導覽（breadcrumb）則能幫使用者理解目前位置，也可透過結構化資料說明頁面階層。

結構化資料：主動把「我是什麼」告訴 Google

一般的 HTML 文字，Google 靠語意分析去推測頁面主題。結構化資料（Schema.org）是一套標準化的標記格式，讓你用機器能直接讀懂的語言，明確聲明「這是一篇食譜」「這是一個產品」「這是一則常見問題」。Schema.org 由 Google、Microsoft、Yahoo、Yandex 發起，詞彙由開放社群持續發展（見 schema.org 官方說明）。

結構化資料一方面幫助 Google 理解內容，一方面可能讓頁面符合特定複合式搜尋結果（rich results）的資格，例如星等評分或麵包屑導覽。Google 在 2026 年 5 月 7 日更新文件，說明 FAQ 複合式搜尋結果不再顯示；其他版位是否顯示也不保證，更新內容發布在 Google 搜尋中心的文件更新紀錄。完整標記方法可以參考 結構化資料 Schema 標記完整教學。

結構化資料也能描述頁面中的人、組織、產品與其他實體，但 Google 的 AI Overviews 與 AI Mode 不要求特殊 Schema，也沒有保證提高引用機率。標記應以頁面可見內容與 Google 支援類型為準；實體概念可延伸參考 Entity SEO。

JavaScript SEO 與渲染佇列：Google 怎麼讀懂用戶端渲染的頁面

現代網站大量使用 JavaScript 來產出內容。React、Vue、Next.js 等框架可採用伺服器端、靜態或用戶端渲染，實際結果取決於架構與設定。若正文只在瀏覽器執行 JavaScript 後才出現，Googlebot 抓到的初始 HTML 可能沒有完整內容，這就是 JavaScript SEO 需要處理的落差。

Google 把 JavaScript 網頁的處理說明為抓取、渲染、建立索引三個階段。Googlebot 先抓回 HTML 與可用資源；頁面收到 200 回應後會進入渲染佇列，再由以 Chromium 為基礎的網頁渲染服務（Web Rendering Service，WRS）執行 JavaScript。官方只說排隊可能是幾秒，也可能更久，沒有公布「數小時到數天」的固定範圍或上限（見 Google 的 JavaScript SEO 基礎說明）。因此，重要內容不宜把即時可見性完全押在第二次渲染上。

實務上會碰到問題的，通常是這幾種情況：

• 連結只用 JavaScript 綁定：把 <a> 寫成純 onclick 事件、沒有真實的 href 屬性。Googlebot 能跟著標準 <a href> 走，但對沒有 href 的可點擊元素，發現與爬取都不可靠。
• 內容全部用戶端渲染：正文、標題、結構化資料都靠 JS 注入，初始 HTML 幾乎空白。渲染排隊、資源錯誤或腳本失敗，都可能延後或妨礙內容處理。
• hash 路由：用 #/page 切換畫面的單頁應用，片段識別碼不適合拿來定義需要個別索引的內容。應讓每個畫面有獨立網址，並使用 History API 管理路由。
• JS 與 CSS 被誤擋：robots.txt 封鎖了 /assets/ 之類的資源路徑，WRS 拿不到樣式與腳本，可能無法正確算出版面，甚至讀不到內容。

架構選擇決定了你與 Google 之間的摩擦大小。伺服器端渲染（SSR）與靜態網站產生（SSG）把組裝好的 HTML 直接回傳，搜尋引擎和使用者可較快取得主要內容；純用戶端渲染（CSR）則更依賴腳本與渲染流程。Google 目前把動態渲染定位為權宜方案，不建議當成長期解法，並建議改用伺服器端渲染、靜態渲染或 hydration，這是 Google 搜尋中心對動態渲染的說明中的立場。Google 的 JavaScript SEO 指南也把伺服器端或預先渲染稱為好做法，因為能讓爬蟲與使用者更快取得內容。想完整理解這塊，可以讀 JavaScript SEO 完整指南。

hreflang：多語系與多區域網站的索引訊號

當你的站同時有繁中、英文、日文版本，或同時經營台灣、香港、美國市場，搜尋結果常常會出現「錯地區」的困擾：台灣使用者看到美國版頁面、英文版頁面跟繁中版互相搶排名。hreflang 是 Google 提供的訊號，用來標註「這一頁是給哪個語言、哪個地區的使用者看的」，以及「同一份內容的其他語言版本在哪裡」。

要先釐清一個觀念：hreflang 不是排名加分的開關，它的作用是把一群語言或地區版本的頁面綁成一組，讓 Google 在「同一組」裡挑最適合的版本回給特定使用者。標了 hreflang，不等於該語言版本就會排上去；它降低的是「選錯版本」的機率，而不是提升排名上限。

hreflang 最容易在這幾個地方出錯：

• 缺少回鏈（return tag）：hreflang 是雙向的。A 頁標註指向 B 頁，B 頁就必須反向標註指向 A 頁；缺少回鏈時，Google 可能忽略那一對標註，不代表整組所有關係必然失效。
• 漏掉自我參照：每個頁面也要標註自己的語言版本，完整的標註是「自己加全部對應版本」。
• 代碼用錯：語言用 ISO 639-1（zh、en、ja），地區用 ISO 3166-1 alpha-2（TW、HK、US）。常見誤寫是把國碼當語言碼，或把繁簡差異（zh-Hant、zh-Hans）與地區混淆。
• 與 canonical 打架：若 hreflang 指向的版本不是 Google 可索引的代表網址，訊號會互相衝突。不同語言頁通常各自 canonical；同語言、內容幾乎相同的區域版本，則可能需要先選代表網址，再由該網址標註語言與地區版本。

沒有對應語言版本時，可以用 x-default 標註不符合其他語言或地區條件時的預設頁，常見目標是語言選擇頁或中立的預設版本，不必固定指向英文版或首頁。hreflang 是提示而非絕對指令，Google 仍會依整體訊號判斷是否採用（見 Google 搜尋中心的 hreflang 說明）。完整的語系策略與區域 SEO 規劃，整理在 多語系 SEO 完整指南。hreflang 的代碼規則、三種實作方式與除錯清單，另外整理在 hreflang 完整設定教學。

第三句｜讓我推薦你：速度、行動體驗與信任訊號

Google 找到你的頁面、也讀懂了內容，最後一道關卡是：它願不願意把這一頁端給真人使用者。這一層考量的已經不是「有沒有內容」，而是「能不能提供好的使用體驗」。

網站速度：從 2010 年起就是排名因素

Google 在 2010 年宣布把網站載入速度納入排名系統，當時說明只影響少量查詢，公告全文見 Google Webmaster Central。後續 Google 又以 Core Web Vitals 衡量部分頁面體驗，但沒有公開一條「速度重要性逐年上升」或「慢一秒固定損失多少排名」的公式。速度優化仍應優先服務實際使用體驗與轉換。

速度對使用者的影響，通常比微小的排名差異更直接。web.dev 整理的案例顯示，改善載入與互動速度可能伴隨轉換、留存或營收改善，但幅度會因網站與測量方法而異。Think with Google 的早年基準研究也指出，較慢的行動版體驗與較差的使用者行為相關。因此，速度應同時從搜尋、轉換與留存資料評估，不要套用固定損失公式。

想動手優化，可以從 網頁速度優化 與 我們整理的速度指南 兩篇開始。如果你還沒用 CDN，那幾乎是成本最低、效果最立竿見影的一步，原理與服務選擇寫在 CDN 完整解析。

測量速度時，要分清兩種資料來源。一種是「實驗室資料」（lab data），來自 Lighthouse 與 PageSpeed Insights 模擬的制式環境，適合用來找問題、對著清單逐項修；另一種是「實地資料」（field data），例如 Chrome UX Report（CrUX），反映符合條件的 Chrome 使用者實際體驗。Google 評估 Core Web Vitals 時使用實地資料；實驗室數字則適合診斷與回歸測試。你本機跑 Lighthouse 拿到滿分，不代表真實使用者也有同樣體驗，兩種資料應搭配判讀。

Core Web Vitals：Google 公開的使用者體驗量化指標

速度只是一個面向。Google 在 2020 年提出「網頁體驗」（page experience）的觀念，把幾個使用者體驗指標打包進排名考量，其中最具代表性的就是 Core Web Vitals，說明可見 Google 2020 年的 Evaluating page experience for a better web。這三個指標把「使用者感受」翻譯成可以量測、可以追蹤的數字：

• LCP（Largest Contentful Paint）：最大元素載入時間，衡量「主要內容多快被看到」，理想在 2.5 秒內。
• INP（Interaction to Next Paint）：互動到下次繪製的延遲，衡量「頁面多快回應使用者的點擊輸入」，理想在 200 毫秒內。INP 已正式取代舊的 FID 指標（見 Google 搜尋中心的 Making INP a stable Core Web Vital 公告）。
• CLS（Cumulative Layout Shift）：累計版面位移，衡量「頁面載入過程會不會跳動」，理想在 0.1 以內。

完整的優化實戰，可以看 Core Web Vitals 完全攻略 與 CWV 白話文介紹。這裡先把三個指標最常見的解法點出來，讓你知道下一步該從哪裡下手：

• 拉低 LCP：最大元素通常是首圖或大標題區塊。常見解法是壓縮並改用現代格式（WebP、AVIF）、為圖片設定明確的寬高避免重新計算版面、把首屏圖片改為優先載入（priority loading）、移除會卡住首屏繪製的轉譯阻塞 CSS 與 JavaScript。
• 壓低 INP：互動遲鈍多半來自過重的 JavaScript，尤其第三方追蹤碼、廣告腳本、動畫函式庫。拆分長任務（long task）、延後載入非必要的腳本、減少主執行緒的佔用，是把點擊回應速度拉起來的關鍵。這也是為什麼裝太多外掛的 WordPress 站，INP 往往特別難看。
• 穩住 CLS：版面跳動的元凶幾乎都是「沒有預留空間」的元素：圖片沒設寬高、字體載入太慢導致文字位移、廣告或嵌入區塊晚一步才長出來。給所有媒體元素固定尺寸、預留廣告欄位、避免在首屏動態插入內容，CLS 就能穩下來。

INP 深度除錯：找出真正的卡頓元兇

三個 Core Web Vitals 裡，INP 通常是最難修的。LCP 的元兇多半是圖片或轉譯阻塞資源，CLS 多半是缺尺寸的媒體，這兩個肉眼看得見；INP 卻藏在主執行緒的長任務裡，要在「使用者點了某個按鈕、頁面延遲回應」的瞬間才會暴露。這也是為什麼很多站 LCP 與 CLS 都過了，INP 還是卡在不合格區間。

要對症修 INP，得先量化是哪一段拖慢了回應。Google 把 INP 的延遲拆成幾個階段：輸入延遲（input delay，從點擊到事件處理器開始執行的等待）、處理時間（processing duration，事件處理器本身的執行）、呈現延遲（presentation delay，處理完到下次繪製之間的等待），各階段的定義可見 web.dev 的 INP 文件。知道瓶頸落在哪一段，才知道是該減少主執行緒的佔用（處理時間長）、還是該排開長任務讓點擊能立刻被處理（輸入延遲長）。

實務上常用 web-vitals JavaScript 函式庫搭配 attribution 填充，在實地收集每筆 INP 事件背後的元素、互動目標與長任務資訊；進階可透過 Long Animation Frames API（LoAF）抓出造成卡頓的具體腳本，這對第三方追蹤碼與廣告腳本氾濫的站特別有用，web-vitals 函式庫的 README 有相關說明。把責任歸屬找出來，INP 的優化才會從「盲目拆外掛」變成「精準移除或延後真正佔用主執行緒的腳本」。完整的 CWV 優化實戰，仍以 Core Web Vitals 完全攻略 為主。

行動裝置優先索引：手機版就是 Google 看到的版本

行動裝置的流量佔比，早已超過桌面。Statista 的資料顯示，全球網站流量來自行動裝置的比例長期維持在五到六成之間。Google 在 2023 年正式宣告，行動優先索引（mobile-first indexing）全面上路，詳情見官方公告 Mobile-first indexing is here。

這代表 Google 主要使用網站的行動版內容進行索引與排名。如果桌面版有重要內容、行動版卻省略，Google 可能無法使用被省略的部分。響應式設計（RWD）能讓同一份內容適配不同裝置，通常較容易維護，但不是唯一可行架構。相關觀念可參考響應式網頁設計 RWD與網站跳出率與 SEO。

HTTPS：基礎信任訊號，不是加分題

Google 從 2014 年起，就把 HTTPS 列為排名訊號，這是 Google Webmaster Central 當年的公告。當年它的權重被形容為「微小」，但十多年過去，HTTP 網站在現代瀏覽器裡會直接被標示為「不安全」，這對使用者信任的殺傷力，遠超過它在排名上的微小權重。

HTTPS 是現代網站的基本要求：它是 Google 公開的輕量排名訊號，也避免瀏覽器對不安全連線提出警示。SSL 憑證的挑選與安裝，可以參考 SSL 憑證完整解析；HTTP 換 HTTPS 的流程則整理在 HTTP 換 HTTPS 完整攻略。網址要不要帶 www、兩個版本怎麼統一，可以一併看 www 與 non-www 網址差異全解析。

用 Google Search Console 做一次技術性健檢

講了這麼多觀念，落實到操作，你最常打開的工具會是 Google Search Console（簡稱 GSC）。它是 Google 免費提供、直接從搜尋引擎內部取資料的官方工具，也是技術性 SEO 健檢的第一站。如果想要一份可以照著勾的項目表，技術 SEO 健檢清單把常見檢查點整理成逐項條列，健檢時搭配使用會更省事。

一次完整的健檢，建議照這個流程走：

1. 先看「網頁索引」報表，把「已檢索，尚未建立索引」「已排除」「發生錯誤」這幾個狀態的頁面撈出來。每一個未收錄的頁面，GSC 都會給出原因，例如「被 noindex 標記」「被 canonical 指向別頁」「重複網址」「被 robots.txt 封鎖」。順著原因修，就能把收錄率拉上來。
2. 用「網址審查」工具針對單一頁面做檢查，確認它的索引狀態、檢視 Google 實際抓取到的內容、是不是有覆蓋範圍問題。
3. 檢查 Sitemap 提交狀態，確認 sitemap 能被正常讀取，再依未收錄原因判斷是否需要修正。沒有適用所有網站的「低於八成就不健康」門檻。
4. 自行測試行動版，檢查文字、點擊區域與內容寬度。Search Console 已停止提供原本的「行動裝置可用性」報表，不能再把它列為現行操作步驟。
5. 翻「核心網頁指標」報表，找出 CWV 不合格的網址群組，對照 LCP、INP、CLS 分別處理。

GSC 看似功能簡單，但它給的是「Google 視角」的第一手資料，任何第三方工具都無法完全取代。完整的功能導覽與實戰技巧，整理在 Google Search Console 完整教學、GSC 實戰技巧，以及 網頁收錄查詢教學。WordPress 站長的 GSC 驗證設定，可另見 WordPress 提交 GSC 完整攻略。如果排名忽然掉了，第一個該開的也是 GSC，排查流程寫在 Google 排名急救技巧。

看 GSC 時有一個心態要先建立：數字會波動是正常的。曝光、點擊、收錄數每天都會有些微浮動，這是 Google 持續重新評估的結果，不代表你的網站出了問題。真正該警覺的訊號是「趨勢性」的變化：收錄數連續兩週往下掉、特定頁面的曝光突然腰斬、或是「已檢索，尚未建立索引」的數量異常暴增。把基線記下來，盯著長期趨勢、別盯著單日數字，你才分得出「正常雜訊」與「真的該動手修」的差別。這也是為什麼技術性 SEO 是持續工程，做完一次並不代表可以放著不管。

症狀對照表：從搜尋表現往回找技術根因

做健檢時，真正省力的是反過來看：先盯症狀，再回頭找根因。把你在 GSC 與分析工具裡看到的異常，對照下面這張表，多半能直接指向該檢查的技術層與第一步排查動作。

你在報表看到的症狀	最可能的技術層	第一步該檢查
大量頁面「已檢索，尚未建立索引」	進門（爬取到了但沒收錄）	該頁是否有 noindex、canonical 指向別處、或被 soft 404 拖累；價值低的批次考慮用 robots.txt 降低抓取
收錄數突然連續下滑	進門（爬取受阻）	robots.txt 是否誤封路徑、伺服器是否連續回 5xx、是否有大面積誤設 noindex
同主題多個網址互相排擠、排名上不去	讀懂（重複內容或 canonical 失靈）	檢查這群網址的 canonical 是否一致、是否該用 301 合併、篩選器變體是否沒處理
排名穩定但點閱率偏低、跳出率高	推薦（體驗與呈現）	Core Web Vitals（特別是 INP）、行動版內容是否完整、標題與摘要是否與搜尋意圖相符
改版後某一批舊網址流量歸零	進門（轉址缺失）	比對舊網址清單，確認是否漏了 301、或殘留 noindex 與 robots 封鎖
JS 渲染頁面內容長期沒進索引	讀懂（渲染未完成或資源被擋）	用網址審查看 Google 抓到的 HTML 是否含正文、robots.txt 是否擋了 JS 與 CSS、是否該改 SSR

這張表不是窮舉，而是訓練你看「症狀到層次到動作」這條鏈。技術性 SEO 的診斷功力，多半建立在這種對照經驗上：見過的症狀夠多，判斷就快。重點是把症狀先歸進三句話的哪一句，才不會一看到排名掉了就慌亂地改東改西。

伺服器記錄檔分析：從 Googlebot 真實行為看問題

Google Search Console 告訴你「索引狀態」，但有一層資訊它給不了：Googlebot 實際上來抓了哪些網址、抓了幾次、伺服器回了什麼狀態碼。這層第一手資料，藏在你的伺服器記錄檔（server log）裡。對頁面數量大、或懷疑有爬取預算問題的網站，記錄檔分析是技術性 SEO 健檢進階的一步。

記錄檔與 GSC 的差別，在於視角不同。GSC 是「結果導向」，告訴你某個網址究竟有沒有被索引、為什麼沒有；記錄檔是「過程導向」，讓你看到 Googlebot 每天實際把抓取額度花在哪些路徑、撞到了多少 5xx、走了幾層轉址才到終點。兩者搭配，才能把「爬蟲進門」這一層看透。

分析時，先做一件功課：驗證真假 Googlebot。網路上有大量偽造使用者代理的爬蟲，直接把所有自稱 Googlebot 的請求拿來分析會誤判。Google 公開的驗證方式是反向 DNS 查詢，合格的 Googlebot 來源網域會落在 googlebot.com 或 google.com，再用正向 DNS 確認能對回原 IP，完整步驟在 Google 搜尋中心的驗證說明。

通過驗證的 Googlebot 記錄，可以看這幾件事：

• 抓取額度的流向：把被請求的網址依類型分組（文章頁、分類頁、篩選器變體、分頁），看看比例。如果大量請求落在低價值的篩選器或追蹤參數變體，這就是爬取預算的破洞。
• 狀態碼分佈：5xx 比例偏高，代表伺服器穩定度問題，會直接讓 Google 放慢抓取；大量 301 連鎖，代表轉址沒清乾淨，每次抓取都在浪費往返。
• 高頻抓取但低價值的網址：某些參數變體被反覆抓取，卻從未進入索引，這類網址最適合用 robots.txt 或 canonical 處理。
• 孤兒頁的線索：記錄檔裡幾乎沒有 Googlebot 請求的頁面，可能就是內部連結沒接好的孤兒，或是被某層封鎖擋住。

記錄檔不是每個站都拿得到，虛擬主機環境可能不開放原始 log；能拿到時，它補上的是 GSC 與第三方爬蟲都給不出的「真實行為」這一塊。取得成本與隱私合規要一併評估，記錄檔含 IP 等資訊，處理時要符合適用的隱私法規要求。

WordPress 是技術性 SEO 的雙面刃

你不能迴避一個現實：根據 W3Techs 到 2026 年 6 月的統計，WordPress 佔了全世界所有網站的四成以上，在 CMS 市佔更是壓倒性領先。電商領域裡，WooCommerce 同樣是使用最廣的平台之一（依 W3Techs 的市佔統計）。

WordPress 之所以是雙面刃，是因為它的技術性 SEO 同時具備「先天友善」與「後天容易出包」兩個特質。

友善的那一面

WordPress 提供標題、段落、連結與永久連結等基本能力，外掛也能協助產生 sitemap、結構化資料與社群標籤。不過輸出的 HTML 與效能仍取決於主題、編輯器和外掛組合，不能把「使用 WordPress」直接等同於程式碼乾淨或技術 SEO 已完成。

容易出包的那一面

正因為門檻低，它也最容易在不知不覺中累積技術債：

• 外掛裝太多、彼此衝突，拖垮網站速度，CWV 直接崩盤。
• 佈景主題的程式碼品質參差不齊，有些會輸出多餘的 CSS 與 JavaScript，或重複的標題標籤。
• 分頁、標籤頁、分類頁、篩選器產生大量低價值的變體網址，吃掉爬取預算、稀釋內容權重。
• 改版或搬家時沒處理好轉址，舊網址 404，累積下來的反向連結權重付諸流水。

WordPress 的 SEO 從入門到進階，是另一個完整的大題目，另可參考 WordPress 架站與 SEO 全攻略。外掛的選擇，可以看 WordPress SEO 外掛評測 與 Yoast vs Rank Math 比較。遇到 404 頁面該怎麼設計才不讓流量白白流失，整理在 404 頁面設計全攻略；主機環境的選擇與 FTP 操作，則可以參考 WordPress FTP 教學。

主機與基礎架構：技術性 SEO 的最底層

技術性 SEO 不只看外掛與設定，也要看主機與伺服器。回應慢、頻繁故障或資源不足，會拖累載入與抓取穩定性；實際影響仍要用 TTFB、錯誤率與流量尖峰資料判讀。虛擬主機、VPS、雲端主機在資源、管理責任與擴充方式上不同，虛擬主機完整指南有完整比較。

選主機時，可比較伺服器回應時間（TTFB，Time to First Byte）、正常運作時間（uptime），以及 HTTP/2、HTTP/3 等傳輸協定的支援。TTFB 與 uptime 要用實際監測資料判讀，不要把單一毫秒或百分比當成所有網站通用的 SEO 門檻；它們會受快取、地區、應用程式與測試方法影響。CDN 則能讓靜態資源從較近的節點傳送，是否有明顯改善仍要看訪客分布與原始架構。

網站搬家與改版：技術性 SEO 風險最高的一關

技術性 SEO 平時是持續工程，但有一種情境會把風險瞬間放大：網站搬家或大改版。換網域、換網址結構、換 CMS、整站重新設計，任何一個把既有網址動掉的決定，都可能讓累積多年的排名與反向連結權重在一夜之間大量流失。這是每年都在發生的真實失血情境。

搬家會出事，本質上是因為「Google 對你網站的認識，很大一部分綁在舊網址上」。舊網址累積了收錄、排名、外部連結、點擊資料；一旦網址換了，Google 等於面對一個相對陌生的版本，得重新評估。技術性 SEO 的工作，就是在這個重新評估的過程中，把訊號的流失壓到最低。

搬家前：把網址對應表備齊

搬家工程裡最關鍵的產出物，是一份「舊網址到新網址」的一對一對應表（redirect map）。把現有每一個有價值的網址列出來，逐一指定它的新家。理想是做到一對一：舊的 A 頁對到內容最相近的新 A 頁，而不是全部導回首頁。全站導首頁是 Google 明確不建議的做法，這類「對不存在的網址回傳首頁」的行為正屬於軟性 404 的典型，等於告訴它「舊的具體內容一概不認」，Google 早在 2008 年的 Farewell to soft 404s 一文就點出這個問題。

對應表除了文字頁面，別漏掉圖片、文件、下載連結這些資源的網址，它們常各自帶有搜尋流量與外部連結。內部連結也要在搬家前清查，準備好新站的內部連結一次性改指向新網址，避免新站上線後還殘留一堆指向舊網址、再靠轉址兜回去的內部連結。

搬家當下與上線後：監控收錄與排名

上線瞬間要做的事，是把對應表裡的 301 轉址一次開好，提交新的 XML Sitemap，然後盯著 Google Search Console 的「網頁索引」報表，看新網址的收錄速度、舊網址的收錄數是否如預期下滑。新站不該殘留測試環境的 noindex 或 robots.txt 封鎖，這是最常見的「上線第一天流量歸零」原因。

上線後的兩到四週是關鍵觀察期。重點看的不是單日波動，而是趨勢：新網址收錄是否穩定上升、舊網址是否逐步退出索引、整體曝光與點擊是否回到搬家前的基線。同時留意 GSC 是否冒出大量軟性 404、轉址鏈、或新版網址回傳 5xx。一個常見的診斷陷阱，是同時改了網址結構又大改內容，當排名下滑時，會分不清是轉址沒做好、還是內容品質變了；技術性搬家與內容改寫最好分階段進行，讓問題可以隔離排查。完整的搬家流程與常見失誤，寫在 SEO 網站搬家完整指南。

技術性 SEO 的五個常見誤解

你可能聽過的說法	實際情況
技術性 SEO 做一次就好	它是持續工程。網站每次改版、加頁面、裝外掛都可能引入新問題，需要定期健檢。
速度是最重要的排名因素	Core Web Vitals 是頁面體驗的一部分，但 Google 沒有公開可與內容相關性直接換算的固定權重。速度更直接影響使用者能否順利操作與轉換。
robots.txt disallow 等於不收錄	disallow 只禁止爬蟲抓取，被其他站連到的頁面仍可能被收錄；要禁止收錄得用 noindex。
裝了 SEO 外掛就等於做好技術性 SEO	外掛只是工具。它幫你產生 sitemap 與 schema，但無法替你決定網站架構、修復效能瓶頸、處理內容重複。
HTTPS 權重很小可以忽略	它是輕量排名訊號，但更直接的理由是保護傳輸安全，並避免瀏覽器對不安全連線提出警示。

技術 SEO 能幫助搜尋引擎抓取、理解與索引頁面，但內容仍需提供足夠的原創資訊、證據與使用價值。可參考SEO 資訊增益的整理方式，檢查內容是否只是重述既有答案。

從今天開始：一份照著做的技術性 SEO 行動清單

把整篇文章濃縮成一份你今天就能動手的清單，按三個層次排列。不必一次做完，但請按順序，進門的問題沒解決，讀懂與推薦都無從談起。

排列順序背後有一套排程邏輯。技術問題的影響範圍與修復成本往往不成正比：一條誤設的 robots.txt 規則可能阻止大量重要頁面被抓取；錯誤 canonical 也可能讓 Google 選到非預期的代表網址。先處理影響面大、修復成本低的收錄障礙，再處理理解訊號與體驗問題，通常比較有效率。團隊作業時，工程與主機可負責抓取及效能，內容與編輯負責頁面結構與標記。

第一步：清查「讓我進門」的障礙

1. 打開 Search Console 的「網頁索引」報表，把所有「未建立索引」的頁面匯出，逐類標記原因。
2. 檢查 robots.txt，確認沒有誤封重要路徑，尤其是改版後遺留的全站封鎖。
3. 產生並提交 XML Sitemap，依 Search Console 顯示的未收錄原因逐類排查；沒有適用所有網站的八成健康門檻。
4. 找出孤兒頁，那些沒有任何內部連結指向的頁面，把它們接回站內連結網絡。

第二步：補上「讓我讀懂」的訊號

1. 檢查網址結構，把冗長、帶無意義參數的網址，透過 301 轉址改為語意清楚的版本。
2. 全站統一 www 與非 www、HTTP 與 HTTPS，通常以伺服器轉址導向偏好版本，並維持 canonical 一致。
3. 只為 Google 目前支援且與可見內容相符的頁面類型加上結構化資料，再用複合式搜尋結果測試工具驗證。FAQ rich result 已停止顯示。
4. 梳理網站階層，讓使用者與爬蟲能透過一般連結找到重要頁面；三到四次點擊可作為檢查線索，不是 Google 的硬性門檻。

第三步：強化「讓我推薦你」的體驗

1. 跑一次 PageSpeed Insights，針對它建議的項目（圖片壓縮、未使用的 CSS、轉譯阻塞資源）逐項處理。
2. 追蹤 Core Web Vitals，把不合格的頁面群組挑出來，依 LCP、INP、CLS 分頭優化。
3. 確認全站已上 HTTPS，並把所有 HTTP 網址 301 轉向 HTTPS 版本。
4. 用行動裝置實際瀏覽你的核心頁面，親自感受字體大小、點擊間距、版面位移。這是任何工具都替代不了的一手體驗。

技術性 SEO 是地基，不是裝潢

回到開頭那個場景。深度指南沒被收錄，不能只看文字，也要排查技術原因：它可能被 robots.txt 阻止抓取、躺在沒有內部連結的孤兒頁，或是手機版省略了重要內容。實際原因仍要用 Search Console 與伺服器資料確認，再對症處理。

把技術性 SEO 想成蓋房子。內容是裝潢、反向連結是口碑、品牌是地段，但這一切的地基是結構與管線。地基沒打穩，上面的裝潢再漂亮，遲早會從裂縫開始崩。而且地基這種東西，平時你根本不會注意到它，等到漏水、下陷那天才會發現代價有多高。

你的網站打算活超過三年的話，技術性 SEO 是基本功，不是選配。它不像內容或連結那樣有戲劇性的爆發，但它會在每一個你看不到的地方，默默決定你的內容能不能被看見。這也是為什麼 Google 演算法每一次調整，核心演算法的走向都會更偏向「獎勵真正對使用者友善的網站」，而技術性體驗正是友善的底層證明。

放眼 AI 搜尋的下一個階段，技術基礎仍然重要：重要頁面要可抓取、可索引，內容也要能在 HTML 中被解析。有人開始實驗用 llms.txt 描述網站內容，但 Google 已表示這類檔案不會影響其生成式 AI 功能；其他服務是否採用則要看各自文件（見 Google Search Central 的 AI 內容表現指南）。它不能取代 sitemap、內部連結、索引控制與可讀的正文。

如果你想把站內、站外、技術三塊串起來看全貌，可以接著讀前面提過的 SEO 完整指南。想知道在 AI 搜尋時代，技術性 SEO 該怎麼跟 AI Overviews、GEO 與 AEO 這些新賽道接軌，那兩篇會是好的下一站。想把更多工具一次備齊，SEO 工具推薦 與 Google Search Console 介紹 則是必讀。

地基打好了，接下來的每一篇文章，才會真的有機會被看見。