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

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

文章上線後若在 Search Console 顯示「已檢索，目前尚未建立索引」，代表 Google 已抓取該頁，但尚未將它納入索引；這和「已發現，目前尚未建立索引」不同。原因不能只從這個狀態判定，應用網址審查確認 Google 取得的內容，再檢查重複版本、技術設定與內容是否足以滿足讀者需求。

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

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

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

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

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

本文用「找得到、讀得懂、使用順暢」三個層次整理技術檢查，這是方便排查的教學框架。Google 官方描述的搜尋流程則是檢索、建立索引、提供搜尋結果；爬蟲負責抓取，不會單獨決定排名。

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

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

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

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

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 的分工

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

這裡有幾個容易踩錯的組合。最經典的錯誤，是用 robots.txt 封鎖一個你想 noindex 的頁面：Google 進不去，就讀不到 noindex，可是只要別站連到它，Google 仍可能把它當成「知道網址存在、但沒內容」的條目留在索引裡，搜尋結果可能只有有限的摘要，標題仍可能來自站外資訊；這種差異可參考 robots.txt 與 noindex 的索引控制。要持續維持 noindex，應保留抓取通道，讓 Google 能重新確認指令；需要保密的頁面則應使用存取驗證。

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 月 8 日的文件紀錄中說明，FAQ 複合式搜尋結果自 5 月 7 日起不再顯示；其他版位是否顯示也不保證，更新內容發布在 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 基礎說明）。Google 能處理 JavaScript，使用 JS 本身不代表更難索引；重點是渲染後的重要內容、連結與索引指令是否正確，而不是把流程理解成固定的第二次抓取。

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

• 連結只用 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 完整解析。

PageSpeed Insights 同時可能顯示兩種資料：Lighthouse 實驗室測試可用來重現問題，CrUX 實地資料則反映符合條件的 Chrome 使用者體驗，資料不足時可能無法提供頁面層級結果。Core Web Vitals 的實地評估採第 75 百分位，並區分行動與桌面；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. 先看「網頁索引」報表，查看未索引原因與範例網址，例如 noindex、替代版本、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 與分析工具裡看到的異常，對照下面這張表，多半能直接指向該檢查的技術層與第一步排查動作。

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

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

Search Console 除了索引資料，也有檢索統計資料，可按回應碼、檔案類型與 Googlebot 類型查看抓取趨勢及部分範例。若要逐筆分析自己伺服器收到的網址、時間與回應，則需搭配伺服器或 CDN 記錄檔；兩者資料範圍和彙整方式不同。

記錄檔可用來分析抓取落在哪些路徑、哪些請求回傳錯誤，以及轉址鏈是否增加往返。但伺服器通常看不到由 CDN 邊緣快取直接回應的請求，必須確認記錄來源是否涵蓋整個存取路徑。抓取紀錄也不等於索引結果，仍要與 Search Console 交叉比對。

分析時，先做一件功課：驗證真假 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 已完成。

容易出包的那一面

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

• 外掛載入重複資源或彼此衝突，可能拖慢載入與互動；應依量測找出問題，不能只看數量。
• 佈景主題的程式碼品質參差不齊，有些會輸出多餘的 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 封鎖，這是最常見的「上線第一天流量歸零」原因。

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

技術性 SEO 的五個常見誤解

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

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

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

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

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

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

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

1. 新網址採清楚且穩定的命名；既有參數網址若運作正常，不必只為美觀改址。確需搬動時，規劃對應轉址並同步更新站內連結與 sitemap。
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 是基本功，不是選配。它不像內容或連結那樣有戲劇性的爆發，但它會在每一個你看不到的地方，默默決定你的內容能不能被看見。技術體驗是服務讀者的一部分；若要理解核心演算法的走向，仍應參考官方更新說明，不能假定每次更新都提高技術因素的權重。

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

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

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