內容寫得再好，只要 Googlebot 進不來、看不到、收不進索引，這篇文章就不會出現在搜尋結果裡。技術 SEO 稽核要解決的就是這件事：把網站從「機器讀取」的角度檢查一遍，確認搜尋引擎能順利走完每一步。

問題在於，大多數稽核清單把幾十個檢查項攤平成一張表，robots.txt、Core Web Vitals、結構化資料全混在一起。實際排查時你會發現，這些項目之間有嚴格的先後關係——Google 必須先能抓取一個頁面，才能渲染它；渲染完成才能判斷要不要編入索引；進了索引才談得上排名。順序錯了，你可能花一週調圖片壓縮，結果頁面根本卡在 robots.txt 被擋的階段。

這篇用「抓取、渲染、索引」三層的順序，帶你把 WordPress 網站從頭稽核一遍。每一層都會說明該檢查什麼、用哪個工具看、WordPress 上最常見的症狀長什麼樣，以及對應的修法。

為什麼技術 SEO 稽核要照抓取、渲染、索引的順序排查

技術 SEO 稽核最有效率的做法，是按照 Google 處理頁面的真實流程逐層往下檢查。Google 把一個網址送進搜尋結果，要經過抓取（crawl）、渲染（render）、索引（index）三個前置階段，最後才進入排名（rank）。這四步是單向依賴的：抓不到就不會渲染，渲染不出來就難以正確索引，沒進索引就完全談不上排名。

照這個順序排查，好處是能快速定位問題卡在哪一層，不會白做功。舉個常見情況：一篇文章在 Google 搜尋不到，你直覺以為是內容不夠好或關鍵字沒做對，於是埋頭改內容。但若它其實是被 robots.txt 擋在抓取層、或頁面標了 noindex 卡在索引層，那內容改得再好都沒用——問題根本不在排名階段。

逐層排查的另一個價值，是讓你知道「什麼時候不必往下查」。抓取層全綠之前，不需要煩惱 Core Web Vitals；索引狀態確認正常之前，不需要糾結內部連結權重的分配。先把地基確認穩固，再往上走，是技術稽核省時間的核心邏輯。

WordPress 站長尤其需要這套順序。WordPress 預設會自動生成大量頁面——標籤彙整、作者彙整、日期彙整、附件頁、站內搜尋結果頁、各種分頁——這些頁面在抓取與索引兩層都容易出狀況。沒有一套分層的檢查框架，很容易在一堆自動生成的低價值頁面裡迷路。

抓取層稽核要確認 Googlebot 進得來、不浪費爬蟲資源

抓取層的稽核目標只有一個：確認 Googlebot 找得到、進得去你的重要頁面，而且沒有把時間浪費在不重要的頁面上。這一層出問題，後面全盤皆輸，所以它永遠排在稽核的第一順位。

先檢查 robots.txt 有沒有誤擋。 robots.txt 控制的是「能不能抓取」，不是「能不能索引」，這個區別很關鍵——被 robots.txt 擋住的頁面，Google 連頁面上的 noindex 標記都讀不到，反而可能因為外部連結而被收錄成一個沒有內容描述的網址。WordPress 上最危險的誤擋有兩種：一是測試或搬站時留下的 Disallow: /，整站封死；二是擋掉了 /wp-content/ 或 /wp-includes/ 底下的 CSS、JavaScript 檔，這會直接破壞渲染層（後面會講）。修改後務必用 Search Console 的 robots.txt 測試工具驗一次，這類設定不會主動報錯，可能默默擋掉關鍵頁好幾個月。

確認 XML Sitemap 乾淨且已提交。 Sitemap 是一份「我希望 Google 優先看這些規範網址」的清單。WordPress 用 Yoast 或 Rank Math 都會自動生成 sitemap，但要檢查裡面有沒有混進不該收的頁面——標了 noindex 的頁、帶參數的重複網址、附件頁。Sitemap 裡只放你真正想被索引的規範網址，Google 才會把抓取資源花在對的地方。提交位置在 Search Console 的「Sitemap」報表。

處理 WordPress 自動生成的頁面膨脹。 這是 WordPress 站最容易被忽略、也最值得做的一項。WordPress 預設會替每個標籤、每位作者、每個日期區間生成彙整頁，還有每張圖片的附件頁、?s= 開頭的站內搜尋頁、/feed/ 訂閱頁。一個只有兩百篇文章的部落格，實際生成的網址數可能輕鬆破千。這些頁面多半內容單薄又彼此重複，Googlebot 每天能花在你網站上的抓取量有限，全耗在這些頁面上，真正的文章反而被晾著。處理原則：用 SEO 外掛把作者彙整（單一作者站尤其沒必要）、日期彙整、標籤彙整中價值低的、站內搜尋結果頁，全設成 noindex；附件頁設定重新導向回媒體檔案或文章本身。

找出孤立頁面。 孤立頁是指站內沒有任何連結指向它的頁面，像一座沒有橋的孤島。Googlebot 主要靠連結探索新頁面，沒有內部連結指向的頁面很可能長期不被抓取，或被判定為不重要。用 Screaming Frog 之類的爬蟲工具全站爬一遍，比對 sitemap 與實際被連結的網址，就能撈出孤立頁。值得保留的頁面，就從相關的文章或分類頁補上內部連結。

要確認 Google 到底有沒有在抓你的站，看 Search Console 的「檢索統計資料」報表，裡面有抓取頻率、回應狀態碼的分布；要查單一頁面，用「網址審查工具」；想看最完整的抓取行為，分析伺服器日誌，能看到 Googlebot 實際在哪天、請求了哪些網址。

渲染層稽核要確認 Googlebot 看得到頁面的真正內容

渲染層的稽核目標，是確認 Googlebot 抓回頁面後，能正確「畫」出這個頁面、看到使用者實際會看到的內容。抓得到不等於看得到——如果關鍵內容靠 JavaScript 才生得出來，而 Googlebot 沒成功執行那段 JS，它眼中的頁面可能是一片空白。

渲染是 Google 在抓取之後、索引之前的一道處理。Googlebot 用的是與 Chrome 同源的 Chromium 渲染引擎，會執行 HTML、CSS 與 JavaScript，試著還原頁面在使用者瀏覽器裡的樣子。問題在於，渲染需要額外運算資源，Google 對 JavaScript 的處理通常會延後一波執行，較複雜的 JS 結構也可能渲染失敗。內容越依賴前端 JS 動態生成，這一層的風險就越高。

檢查關鍵內容是不是非靠 JavaScript 不可。 用 Search Console 網址審查工具的「測試實際網址」功能，看 Google 渲染後的截圖與 HTML，這是判斷渲染層最直接的方法。如果渲染後的內容跟你在瀏覽器看到的明顯不同——主文不見了、商品列表空了、選單塌了——就代表那部分內容卡在 JS。WordPress 上常見的渲染陷阱包括：用 JS 控制的頁籤（tab）或手風琴（accordion）把大段內容預設折疊在 JS 事件後才載入、無限捲動的商品或文章列表讓 Googlebot 看不到後段連結、以及某些頁面建構器（page builder）生成的肥大 DOM 拖慢甚至卡住渲染。

別讓 lazy-load 把主要內容藏起來。 圖片與 iframe 的延遲載入對速度有幫助，但要用對。如果首屏的主視覺（LCP 元素）也被延遲載入，反而會拖慢載入指標；如果整段文字內容都靠捲動觸發的 JS 才插入 DOM，Googlebot 可能根本不會捲動，也就看不到。原則是：首屏與主要文字內容要在初始 HTML 就存在，lazy-load 只留給折疊線以下的非關鍵圖片。

確認 CSS 與 JavaScript 沒被 robots.txt 擋住。 這條接回抓取層——如果渲染需要的 CSS、JS 檔位在 robots.txt 不允許抓取的目錄，Googlebot 拿不到這些資源，就無法完整渲染頁面，可能把版面判讀成壞掉的、或看不到該有的內容。WordPress 早期常見的錯誤就是擋掉整個 /wp-includes/，現在 Google 明確建議放行渲染所需的資源。

避免靠 cookie 才顯示的關鍵內容。 Googlebot 基本上不帶 cookie 抓取，也不會通過登入或同意彈窗。如果頁面的主要內容要等使用者點了 cookie 同意、或登入後才出現，那 Googlebot 看到的就是還沒顯示內容的版本。會員專屬內容本就不該期待被索引，但一般文章若被同意彈窗遮住或延後載入，就是白白讓內容渲染不出來。

索引層稽核要確認頁面真的被收錄、沒被錯誤排除

索引層的稽核目標，是確認你想被收錄的頁面確實進了 Google 索引，而不想被收錄的沒有占位。「可被索引」和「已被索引」是兩回事——前者是指標記允許它進索引，後者是 Google 真的把它放進去了。這層的主戰場是 Search Console 的「網頁索引」報表。

先掃一遍有沒有頁面被誤標 noindex。 不小心對重要頁面下了 noindex，是稽核中最常撞見的錯誤之一，通常發生在開發或測試環境設了 noindex，上線時忘了拿掉。WordPress 後台「設定 > 閱讀」裡有一個「阻擋搜尋引擎索引這個網站」的勾選框，搬站或重建時很容易誤勾留著。檢查方法：在網頁索引報表裡看「已由『noindex』標記排除」這一類底下的網址，確認每一個都是你刻意要排除的。

排查 canonical（規範網址）設定有沒有打架。 canonical 標籤的作用是在有多個重複或近似網址時，告訴 Google 哪一個是正版、把排名訊號集中過去。常見的故障是互相指定：A 頁的 canonical 指向 B，B 的 canonical 又指回 A，Google 只好自己猜，排名因此搖擺不定。WordPress 上的重複網址多半來自帶參數的網址、分頁、以及商品的多種規格變體。網頁索引報表裡的「重複網頁，使用者未選取規範網址」「Google 選擇的規範網址與使用者所選的不同」這兩種狀態，就是在提醒你 canonical 訊號有衝突，要逐一核對指向。

讀懂兩種最常見的「未編入索引」狀態。 Search Console 裡有兩個訊息經常讓站長困惑：

• 已探索但目前未建立索引：Google 知道這個網址存在，但還沒決定派爬蟲去抓。通常代表 Google 評估這頁的優先度不高，可能是內容單薄、與其他頁高度重複，或缺乏內部連結讓 Google 判斷不出它的重要性。解法是充實內容、補強指向它的內部連結。
• 已檢索但目前未建立索引：Google 抓了，但選擇不收進索引。這多半是內容品質訊號偏弱——內容太薄、與站內其他頁重複、或對搜尋者價值不足。處理方向是合併同質的薄頁、把內容做厚，或乾脆把沒必要存在的頁面移除。

揪出薄內容與軟性 404。 大量內容單薄的頁面會拉低整站的品質評價，連帶影響其他頁的索引與排名。WordPress 上常見的薄頁來源就是前面提過的標籤頁、日期彙整這類自動生成頁。另外要注意「軟性 404」——頁面回傳 200 正常狀態碼，但內容實質是空的或「查無資料」，Google 會把它當成一種品質問題。把同質的薄頁整併成一篇完整的資源頁、刪掉沒有用途的頁面，是清理索引層的標準動作。

頁面被索引卻排不上來時的技術面排查

頁面確認進了索引卻還是沒有排名，問題就從技術稽核的前三層，轉移到內容與權重訊號上——但其中仍有幾項是技術稽核該負責確認的。被索引只代表 Google 願意把它列入候選，排不排得上、排多前面，是另一套計算。

先確認內容有沒有對上搜尋意圖。 排不上最常見的原因，是頁面內容與使用者搜尋該關鍵字時想要的東西不匹配。想找「怎麼做」的人搜到一篇「是什麼」的定義文，Google 自然不會把它排前面。這雖然偏內容面，但稽核時值得把目標關鍵字實際搜一次，看排在前面的頁面屬於哪種類型，再回頭對照自己的頁面是否同型。

檢查內部連結有沒有把權重導到這頁。 一個頁面就算進了索引，若站內幾乎沒有連結指向它，Google 會判斷它在你網站裡不重要，排名自然偏弱。這跟抓取層的孤立頁是同一個根源，但這裡的重點是「權重分配」——重要的頁面應該從首頁、主要分類頁、相關熱門文章拿到較多內部連結。

排查關鍵字自相殘殺。 當站內好幾篇文章都瞄準同一個關鍵字，Google 會不確定該排哪一篇，結果哪篇都排不好，這叫關鍵字蠶食（keyword cannibalization）。WordPress 內容做久了特別容易發生。處理方式是把高度重疊的文章整併成一篇權威長文，或明確區分各篇的主關鍵字與內容角度。

這時才輪到 Core Web Vitals。 走到這一層，頁面體驗指標才真正成為值得投入的優化項。Core Web Vitals 用三個指標衡量使用者體驗，Google 取的是真實使用者載入的第 75 百分位數，也就是看的是多數人的實際體驗，不是最理想的那一次。三項的「良好」門檻分別是：

WordPress 上拉低 LCP 的元兇通常是沒壓縮的大圖、阻擋渲染的 CSS 與 JS，以及被延遲載入的首屏主視覺；INP 偏高多半是肥大的外掛塞了過多前端 JavaScript；CLS 不穩則常因為圖片、廣告、嵌入內容沒有預留尺寸，載入時把版面推來推去。改善方向對應得很直接：圖片改用 WebP 並指定寬高、延後非關鍵腳本、精簡用不到的外掛、為動態插入的元素預留空間。Search Console 的「Core Web Vitals」報表看真實使用者數據，PageSpeed Insights 與 Lighthouse 則給你單頁的實驗室診斷。

WordPress 全站技術稽核的執行節奏與優先順序

技術稽核不是一次性的專案，而是要按固定節奏重複跑的流程，因為演算法會更新、網站會長大、外掛會改版，新問題持續冒出來。把它制度化，比偶爾大掃除一次有用得多。

執行的優先順序，就照前面的分層由下往上：

• 第一順位、抓取層：先確認 robots.txt 沒誤擋、sitemap 乾淨已提交、CSS 與 JS 可被抓取、WordPress 自動生成的低價值頁面已設好 noindex 或導向。這層沒清乾淨，往上做都是空的。
• 第二順位、渲染層：用網址審查工具的實際網址測試，確認主要內容在渲染後看得到，沒有被 JS、lazy-load 或 cookie 遮住。
• 第三順位、索引層：在網頁索引報表逐一處理各種排除狀態，確認該收的收了、不該收的沒占位，canonical 沒打架。
• 第四順位、排名與體驗：確認索引正常後，才投入內部連結權重、搜尋意圖比對、關鍵字蠶食整併與 Core Web Vitals。

至於頻率，多數網站適合每季做一次完整的全站爬蟲稽核，期間每月固定看 Search Console 的網頁索引、檢索統計與 Core Web Vitals 三張報表，盯住索引頁數與錯誤率有沒有異常跳動。每次重大改動之後——換版型、升級主要外掛、搬站、改網域——都要在前後各跑一次全站爬蟲對照，這是最容易出大問題、也最該嚴查的時間點。

工具配置可以很精簡。Google 官方的三件套就能涵蓋多數需求：Search Console 看索引與抓取狀態、PageSpeed Insights 測單頁速度、Lighthouse 做整體稽核；需要全站找孤立頁、重複標題、導向鏈、canonical 問題時，再加一支 Screaming Frog 之類的爬蟲工具；想看 Googlebot 最真實的抓取行為，分析伺服器日誌。WordPress 站再配一個 SEO 外掛（Yoast 或 Rank Math）管 sitemap 與各類彙整頁的 noindex 設定，基本的技術稽核就跑得起來。

把抓取、渲染、索引接成一條檢查鏈，排名問題才追得到根

技術 SEO 稽核之所以容易做白工，是因為把幾十個檢查項當成平行的待辦清單在勾，而不是當成一條有先後的鏈在追。Googlebot 處理頁面的順序是抓取、渲染、索引、排名，稽核就該照同一條鏈逐層往下——抓得到才驗渲染，看得到才查索引，收進去了才談排名與體驗。哪一環斷了，問題就卡在那一環，往後的優化全使不上力。

對 WordPress 站來說，這條鏈尤其要從清理自動生成的頁面開始：把標籤、彙整、附件、站內搜尋這些低價值頁面管好，Googlebot 的抓取資源才會花在真正重要的文章上，後面三層也才檢查得乾淨。

把這套分層流程排進每季一次的固定節奏，重大改動前後各跑一次對照，下次再遇到「明明寫得不錯卻搜不到」的頁面，你就能順著抓取、渲染、索引一路問下去，幾步之內定位到它到底卡在哪一層，而不是憑感覺亂改一通。