Google 爬取與索引教學：頁面沒被收錄，問題通常卡在這幾層

Google 爬取與索引是什麼？先分清三個階段

Google 爬取（crawling）是 Googlebot 發現並下載網頁內容的程序；Google 索引（indexing）則是 Google 分析已下載的內容、判斷標準網址（canonical），再把可用的資訊收進索引資料庫。換句話說，爬取負責把資料搬回來，索引負責決定這份資料是否要保留、保留哪一個版本。頁面要進入搜尋結果，必須先被 Google 知道、能被爬取、能被處理，才有機會進入索引與排名階段。

Google Search Central 把整個流程拆成 crawling、indexing、serving 三個階段：爬取階段會下載文字、圖片、影片等資源；索引階段會分析內容並選定 canonical；最後在搜尋結果階段才依查詢挑出相關頁面。Google 也明確聲明，搜尋引擎不會保證每個頁面都會被爬取、索引或顯示，即使頁面符合所有基本技術要求，仍可能在某一個環節被略過。

為什麼頁面沒流量，不一定是排名問題

許多 SEO 診斷誤判都來自於把「沒流量」直接歸因到「排名差」。實際上一個 URL 從存在到曝光，中間至少有四個獨立檢查點：Google 是否知道這個 URL 存在、能否順利爬取並下載內容、是否認為該頁面值得存入索引並選為標準版本、被索引後是否有機會在對應查詢下曝光。前一步通過不代表下一步也會通過，所以診斷必須一層一層往上查，而不是直接跳到「排名差」的結論。

診斷的順序也有講究。如果先用第三方工具跑「網站健康分數」，分數背後往往混合了效能、結構、連結與爬取多種訊號，無法指出卡在哪個階段。更有效的方式是先看 Google Search Console 的網址檢查與網頁索引報表，先確認網址檢查顯示的是「Google 不知道這個網址」「網址不在 Google 服務中」或「網址在 Google 服務中」，再展開網頁索引狀態與原因，倒推是哪一環出問題。這個由狀態反推卡關點的順序，會比直接從技術設定下手更省時間，也能避免在錯誤的環節浪費排查成本。

想先了解搜尋引擎的整體運作背景，可以參考搜尋引擎從抓取到排名的完整流程，幫助判斷整體流程中哪一段最容易出問題。

爬得到不代表會索引：AK Crawl Index Diagnostic Ladder

爬取索引診斷不能只問「Google 有沒有收錄」。爬得到不代表會索引；AK Crawl Index Diagnostic Ladder 把問題拆成六個可以逐層排除的診斷點：Googlebot 能成功抓取 URL，只表示這頁通過「發現、允許爬取、成功擷取」；能不能出現在搜尋結果，還要繼續通過「完成轉譯、允許索引、可被搜尋結果使用」。因此診斷時不要只看收錄結果，而要逐層確認卡在哪一層。

多層同時失敗時的修復優先序

多層同時失敗時，修復順序要從最早的關卡開始：先解決發現與允許爬取，再確認伺服器能穩定回應 200，然後檢查轉譯後的 HTML 是否包含主要內容與連結，最後才處理 noindex、canonical、重複與內容品質。下層未通過時，上層的檢查結果不可靠；例如 robots 擋住時，Googlebot 根本沒取得網頁，無法判斷 noindex 是否存在，也無法評估內容是否夠豐富。

實際動手時，先用 GSC 的 URL Inspection 看 Googlebot 是否能抓取；若顯示被 robots 或權限拒絕，就修 robots.txt 或伺服器權限，不要急著查轉譯。接著看 HTTP 狀態碼，5xx、軟 404、連線逾時都要先解伺服器與 CDN 設定。這兩層過關後，再用「檢視已檢索網頁」比對 HTML 與使用者看到的內容。最後才檢查 noindex、canonical 與內容品質。

如果已驗證的伺服器記錄顯示 Googlebot 根本沒進來，才回頭查 DNS、robots、伺服器與抓取排程；GSC 的「已發現，目前未編入索引」代表 Google 已知道網址但尚未抓取，不能把它直接歸因於轉譯或索引資格。若狀態是「已檢索，目前未編入索引」，才表示 Google 已抓取但尚未索引，後續再查內容、重複、canonical 與索引資格。修復時不要反覆重送 URL，而要用 URL Inspection 與伺服器記錄把每一層的狀態確認清楚，優先處理仍卡住的最前端關卡。

層級	核心問題	常見工具
發現	Google 是否知道 URL 存在	內部連結、Sitemap、GSC
允許爬取	robots 或權限是否擋住 Googlebot	robots.txt、URL Inspection
成功擷取	伺服器是否回 200，是否穩定	HTTP header、GSC
完成轉譯	Google 是否看得到主要內容和連結	檢視已檢索網頁、HTML
允許索引	是否有 noindex、錯誤 canonical、重複或品質問題	GSC、原始碼、canonical 檢查
可被使用	已索引後是否符合查詢與品質需求	GSC 成效與網址檢查

這個梯子的價值，是把技術問題和內容問題拆開。robots 擋住是爬取問題，noindex 是索引資格問題，canonical 選錯是標準版本問題，內容太薄則是索引與搜尋結果品質問題。混在一起處理，只會一直重送 URL，卻不知道真正卡在哪一層。

發現問題：Google 是否知道這個 URL

站內可爬連結、sitemap 與外部連結是 Google 發現 URL 的常見來源，但不是封閉清單；Google 也可能保留過去抓過的網址，或從其他可用訊號得知 URL。診斷重點是確認 Google 是否已知道網址，以及重要頁面是否有穩定的站內發現路徑。

URL 發現 是爬取前的第一道門檻。如果 Google 沒有從內部連結、外部連結、Sitemap 或其他來源知道某個 URL，該頁就不會進入正常的爬取與索引流程。

Google 官方說明中提到，Google 會透過已知頁面上的連結、sitemap 等方式發現新 URL。對實務網站來說，最常見的問題不是沒有提交 sitemap，而是重要頁面沒有被站內可爬的路徑連到，變成孤兒頁面。

• 新文章是否從分類頁、相關文章或主題頁連得到。
• 商業頁是否只存在於選單外的按鈕或 JavaScript 狀態中。
• Sitemap 是否包含 canonical URL，而不是參數頁或測試頁。
• 重要頁面是否被 robots 阻擋，導致 Google 無法沿連結探索。

Sitemap 可以幫助 Google 發現 URL，但不是索引保證。確認 sitemap 中列出的是 canonical URL，並確認重要頁面沒有被 robots 阻擋，才能讓發現層的資訊一致。

孤兒頁面的形成機制與排除方法

孤兒頁面最常出現於網站改版與活動頁建置。改版時，新的路由可能只接在特定樣板中，舊版的分類連結與頁尾連結沒有同步更新，於是原本由站內連結串起來的頁面，在改版後失去所有入口。活動頁或落地頁則常用獨立工具建立，頁面只有廣告追蹤連結或 QR Code 作為來源，站內沒有任何可爬的連結指向它，Google 只能依賴 sitemap 或外部連結，發現時間相對不穩定。 延伸閱讀：網站改版風險控制。

排除孤兒頁面的核心做法，是替每個重要 URL 建立至少一條純 HTML 的站內路徑。這不是把選單塞滿，而是把頁面放回內容階層：文章掛到分類索引，商品掛到系列頁，活動頁掛到活動總覽。sitemap 可以改善較大、較新或結構複雜網站的 URL 發現，但不保證抓取或索引；重要頁面仍應有可爬的站內連結，讓 Google 與使用者都能從網站結構到達。

第二個檢查點是 robots 與回應狀態。若 robots.txt 擋住入口，Google 即使從 sitemap 知道 URL 也無法沿網頁連結確認；若頁面回應 noindex，連結依然存在，但頁面不會被索引，這需要在索引資格階段判斷。

爬取問題：robots、狀態碼、伺服器先查

爬取發生問題時，先按 robots、狀態碼、伺服器三個層次排查，能快速分辨 Googlebot 根本沒進場、進場後被擋，還是伺服器無法回應。這三層先確認，再去解讀索引層的訊號才有意義。

先看 Googlebot 能不能存取頁面。robots.txt、HTTP 狀態碼、伺服器錯誤、登入權限、DNS 或網路問題，都可能讓 Google 知道 URL，卻無法正常下載內容。Google 的技術文件指出，Google 只會索引回傳 HTTP 200 成功狀態的頁面；client error 或 server error 頁面不會被索引。Search Console 的網址檢查工具也會顯示是否允許檢索、網頁擷取狀態和 Google 上次檢索時間。

現象	優先檢查	處理方向
被 robots.txt 封鎖	robots 規則與路徑	移除重要頁面的 Disallow
404 或 soft 404	URL 是否存在與內容是否足夠	修正路由、補內容或正確回 404
5xx	伺服器穩定性與負載	修復主機、CDN、後端錯誤
需要登入	Googlebot 是否能看到公開版內容	提供可爬的公開內容或不要期待索引

robots.txt 與 noindex 的交互判斷

robots.txt 是阻止爬取，不是穩定的移除索引方法。當 robots.txt 擋住某個路徑，Googlebot 根本無法下載頁面內容，連帶也看不到頁面 head 裡的 noindex meta 標籤；這個時候即使你想讓 Google 不要再收錄這頁，技術上也無法靠 noindex 生效，因為指令從未送達。Google 的 noindex 文件明確提醒，頁面如果被 robots.txt 擋住，Googlebot 可能看不到 noindex。 延伸閱讀：robots.txt 檔案設定指南。

排查時要區分兩個問題：你是不想讓 Google 抓，還是不想讓 Google 收？不想被抓，robots.txt Disallow 是正確手段；不想被收，正確做法是開放爬取、讓 Google 讀到 noindex，再用 Search Console 驗證狀態。常見錯誤是兩種工具混用，對一個想下架的頁面同時 Disallow 與標記 noindex，結果頁面繼續殘留在索引裡，因為 noindex 從未被讀取。當 Search Console 顯示「已探索，但目前未編入索引」時，先確認該 URL 是否同時被 robots 阻擋並帶有 noindex，這兩種狀態對應的處置方向不同。

Cloudflare 或 CDN 擋 AI 爬蟲，要先查有沒有連 Googlebot 一起擋

Cloudflare 已公告：2026 年 9 月 15 日起，新加入的網域在含廣告頁面上會預設允許 Search、阻擋 Training 與 Agent；既有免費客戶若未在期限前調整設定，也會套用公告中的變更。更重要的是，多用途 crawler 會依所有用途套用最嚴格規則，因此當站長選擇阻擋 Training 時，兼具 Search 與 Training 分類的 Googlebot、Applebot 或 BingBot 也可能被阻擋。這是官方規則範圍，不是所有 Cloudflare 網站、所有頁面或所有設定都必然擋 Googlebot。

AK 在 2026-07-05 於 Threads 記錄了這個觀察：「你的站如果套到新預設，或原本就開了 AI 爬蟲阻擋，Googlebot 就可能一起被擋。」同一則貼文也提到：「9/15 後，Cloudflare 會在你的網站頁面，預設阻擋 AI 訓練跟 AI 代理類爬蟲，搜尋爬蟲維持允許。」

這兩句話要分開看待。AK 對誤擋機制的說明不是第一手 Cloudflare 測試；但 Cloudflare 2026 年 7 月公告已確認 9 月 15 日的新預設與多用途 crawler 規則。截至 2026 年 8 月 10 日，該日期仍未到，因此只能寫成已公告、尚未生效的變更。官方範圍是新網域的含廣告頁面，以及未在期限前調整設定的既有免費客戶；Search 預設允許也不代表 mixed-purpose Googlebot 在阻擋 Training 時仍一定獲准。

不管 Cloudflare 最後的預設值是什麼，套用任何 AI 爬蟲阻擋規則前，可執行的判斷是這幾步：

1. 先在 CDN 的 bot management 或 firewall 規則列表，確認規則是依 user-agent 字串比對，還是依已驗證的爬蟲身分（verified bot）比對。
2. 分開檢查 Cloudflare 的 Search、Agent、Training 設定與 mixed-purpose crawler 處置。Googlebot 是實際搜尋 crawler；Google-Extended 是 robots.txt 控制 token，不是另一支可用 user-agent 或 IP 單獨放行的 crawler。
3. 套用規則後，用 Search Console 的網址檢查工具重新測試一次代表性網址，確認 Google 仍能正常擷取。
4. 套用後追蹤一段時間的網頁索引報表與抓取統計資料，比對套用前後是否有異常下滑，而不是只看套用當下有沒有報錯。

套用後追蹤抓取與索引的具體做法

套用後的追蹤目標，是確認規則有沒有在真實流量中誤擋 Googlebot。反證條件很明確：如果實測 Cloudflare 的 AI 爬蟲阻擋規則有正確排除 Google 官方認證的爬蟲，且套用前後 Googlebot 的抓取量與網頁索引報表沒有異常變化，這個「可能一起被擋」的疑慮在你的站上就不成立。因此追蹤的重點不在單一報錯，而在連續趨勢。

先記錄套用前的基準值：在 Search Console 的「網頁索引」報表中記下已編入索引頁數，在「設定」的抓取統計資料記下總請求、回應與 Googlebot 類型，再用同一時間窗做前後比較。檢查頻率由網站規模與更新速度決定；沒有通用的三到七天或兩到四個週期門檻，單靠時間趨勢也不能排除演算法、季節性或網站改動等同期因素。

網址檢查工具與伺服器 log 可以提供更細的線索。當某個重要頁面沒有出現在搜尋結果時，用網址檢查工具看 Google 是否回報「已發現」但「未編入索引」，如果是，再比對伺服器 log 中該 URL 是否有來自 Googlebot 的請求。若 Googlebot 請求完全消失，先用 Google 公布的 IP 範圍或反向 DNS 驗證記錄中的請求身分，再回到 CDN 規則清單確認 Search、Training 與 mixed-purpose crawler 的處置；只比對 user-agent 不能證明請求真的來自 Google。觀察指標以「Googlebot 請求次數是否維持」「索引狀態是否從已編入索引退回已發現」這兩個訊號為主，不需要套用任何固定比例。

Googlebot 的時間都花在哪？用資源組成證據卡查，不要套固定比例

資源組成證據卡：沒有一個「健康的 HTML 佔比」可以套用在任何網站上。任何「Googlebot 花多少比例在 HTML／JS／圖片」這類主張，都必須附上分子、分母與時間窗三件事，缺一件就不能拿來當診斷依據。

證據卡怎麼建、怎麼讀：從 log 拆資源到判斷結論

建立證據卡的第一步是確定「你要量的是什麼」。常見的選擇有兩種：請求次數（同一個時間窗裡 Googlebot 各類資源的命中次數）與位元組數（Googlebot 實際抓走多少 KB）。兩者會得出完全不同的結論，HTML 檔案通常請求次數高但位元組小，圖片與 JS 套件則相反。沒有預先選定分子，事後切換單位會讓你無法做前後比較，這也是為什麼證據卡第一欄必須先寫清楚度量單位。

第二步是把 server log 或 CDN log 依資源類型分組。實務上可以從副檔名與 Content-Type 兩個欄位交叉判斷，把 HTML、CSS、JS、圖片、字型、JSON、SVG 各自歸進獨立桶子；副檔名不可信的場景（例如副檔名被剝掉、或資源走的是帶 query string 的 CDN 路徑），就以 Content-Type 為主。桶子切完後，可先用 Googlebot user-agent 篩選候選請求，再用 Google 公布的 IP 範圍或反向 DNS 驗證來源；user-agent 很容易被冒用，單靠字串不能把請求稱為真正的 Googlebot 流量。

第三步是解讀。單一時間點的比例不能證明瓶頸；較可用的方法，是在同一網站、固定分子與分母下，記錄調整資源或伺服器設定前後的趨勢，再看 HTML 請求、回應時間與新頁面發現速度是否一起變化。對內容量不大、更新不頻繁且新頁很快被抓的網站，Google 的官方指引並不要求進行 crawl budget 優化。比例上升但新頁面發現速度沒動，代表資源組成不是瓶頸；比例沒動但新頁面發現速度變慢，則要回頭查伺服器回應時間與抓取需求評等，而不是改資源載入策略。

AK 在 2026-06-23 於 Threads 提出的觀察是：「Googlebot 來你網站後，大部分時間很可能都浪費在外掛檔案、JS 腳本、字型、SVG、JSON 和 RevSlider 等資源上，真正該讀的 HTML 內容卻只分到一點點。」同一則貼文接著提出機制假說：「Googlebot 每天在你網站上的爬取預算有限，它花越多資源在 HTML 文件上，就越有機會發現新的主題頁面、重新評估實體關係、判斷內鏈的上下文價值、理解整個主題地圖的連接脈絡，最後才會逐步提高對你網站的爬取需求。」

這兩句都是 AK 的一手觀察與解釋，不是 Google 公開證實的爬取預算分配公式，也沒有附上特定網站的原始請求記錄。要把它變成可以用在你自己網站的判斷，得先做一張證據卡，把模糊的「大部分時間」換成實際數字：

欄位	內容
證據狀態	Hypothesis（假說，尚未附上可驗證的請求記錄）
站點／來源類型	依你自己的網站類型填入；本觀察未指定特定站別
觀察窗口	建議至少 7 到 28 天的 server log 或 CDN log，避免單日波動誤導判斷
樣本／分母	該時間窗內所有被辨識為 Googlebot 的請求總數（或總位元組數）
變更槓桿	若做前後比較，需明確記錄改了什麼（例如移除某個外掛、延遲載入某類資源）
觀察結果	依你的分子除以分母計算出的實際比例，不是套用他人文章的數字
AK 判讀	非 HTML 資源佔比過高，理論上可能排擠 Googlebot 花在 HTML 內容上的請求量，進而影響新主題頁面被發現的速度
替代解釋	伺服器回應時間、快取策略、資源檔案大小、網站既有的抓取需求評等，都可能同時影響結果，不能只歸因給資源組成
什麼情況會推翻此推論	若記錄顯示 HTML 請求佔比與新頁面被發現的速度沒有穩定關聯，或大量非 HTML 資源請求並未拖慢新內容被爬取，這個假說就不成立
來源／出處	Threads @darkseoking，2026-06-23
最後查核日	2026-08-10

實際做法是先從自己的 server log 或 CDN log 依資源類型（HTML、JS、CSS、圖片、字型、JSON 等）分組，計算每一類在同一個時間窗裡的請求數或位元組數佔比，再看這個比例隨時間怎麼變化。單一時間點的比例沒有意義，能拿來判斷的是同一個站在調整資源載入方式前後的變化趨勢，而不是跟其他網站比較數字。不同 CMS、快取策略與頁面複雜度會改變比例，因此跨站數字不能當成通用健康門檻；若要參考，也必須先對齊資源分類、時間窗與網站規模。

轉譯問題：Google 看得到主要內容嗎

Google 能不能看到主要內容，取決於轉譯是否成功。所謂轉譯問題，指的是 Googlebot 能成功取得 URL，但在執行 JavaScript 之後，仍然看不到使用者真正看到的主要內容、內部連結或產品資訊。這種情況在重度使用 JavaScript 的網站、採用延遲載入的頁面、登入後才顯示內容的區域，以及內容由 API 晚到的頁面特別常見。 延伸閱讀：內部連結策略怎麼做。

Google 的搜尋運作文件指出，爬取期間 Google 會使用類似瀏覽器的方式轉譯頁面並執行 JavaScript，因為網站常依靠 JavaScript 把內容帶到頁面上。問題是，能執行 JavaScript 不代表所有內容都能穩定、即時、完整地被看見；轉譯失敗與轉譯延遲是兩種不同狀態，前者會讓內容直接消失，後者會讓內容較晚才被索引，需要的排查方法也不一樣。

• 主要文字是否存在於初始 HTML，或至少能在轉譯後被看到。
• 內部連結是否是可爬的 HTML 連結，不是只靠按鈕事件切換。
• 重要內容是否需要登入、地區、Cookie 或互動後才出現。
• 延遲載入圖片、表格或 FAQ 是否有可索引的文字替代。

如果懷疑是轉譯問題，先用 GSC 的「查看已檢索的網頁」檢查 HTML、畫面截圖與載入資源，再讓開發者比對使用者版與 Googlebot 版的差異。這份資料可以初步判斷內容是根本沒進入原始 HTML，還是轉譯後才出現。

JavaScript 轉譯延遲的排查方法

轉譯失敗是 Web Rendering Service 執行 JavaScript 後仍看不到必要內容；排隊延遲則是頁面先進入 render queue，等資源可用後才轉譯。Google 沒有承諾固定等待時間，也沒有保證同一次抓取會進行多次轉譯。可用網址檢查或 Rich Results Test 查看 rendered DOM、已載入資源與 JavaScript 錯誤，再配合索引版本的抓取時間判讀。

在網址檢查或 Rich Results Test 中查看 Google 測試得到的 rendered DOM、截圖、已載入資源與 JavaScript 錯誤，再與瀏覽器收到的 HTML 和使用者畫面比對。單次測試看到主要文字，只能證明該次擷取與轉譯成功，不能排除間歇性 API、地區、Cookie 或資源載入問題；若主要內容依賴 JavaScript，還要確認關鍵 JS、CSS 與 API 沒被 robots.txt、權限或非 200 回應擋住。

常見的延遲來源包括第三方腳本阻塞主執行緒、內容 API 回應時間過長、伺服器端太晚輸出內容。如果主要內容的 API 回應過慢、失敗或需要互動，該次轉譯可能抓不到區塊；Google 可能在之後重新抓取與轉譯，但沒有一個保證發生的「第二次轉譯」佇列，也不能只靠『索引內容比線上版舊』反推出單一原因。最後用「測試現場網址」重新抓取目前版本，比較即時原始碼與 GSC 儲存的原始 HTML：如果線上原始碼含有主要內容而 GSC 的原始 HTML 沒有，代表抓取當下內容尚未產生；如果兩者都沒有主要內容，問題就不在轉譯，而在頁面根本沒有輸出內容。把出現延遲的資源網址與回應時間附給開發者，會比只說「Google 看不到內容」更容易定位是哪一支腳本造成。

索引資格：noindex、canonical、重複與品質

索引資格是 Google 已經能處理頁面後，判斷它是否應該進入索引的階段。noindex、錯誤 canonical、重複內容、低品質內容、空頁、錯誤語系或大量參數頁，都可能讓頁面可爬但不被索引。先確認頁面有沒有資格，再談排名，否則驗證時只會看到「Google 已檢索頁面，但沒有收錄」。

noindex 與 canonical 不要當成有固定優先序的組合

noindex 是排除索引的指令，必須讓 Googlebot 能抓到 meta 標籤或 X-Robots-Tag 才能生效；canonical 則是針對重複或高度相似頁面提供標準網址偏好的訊號，Google 仍可能選擇其他 canonical。Google 沒有公布兩者同頁時可依賴的固定處理先後，因此不要把衝突設定寫成『noindex 必然先於 canonical』。

如果目標是讓某頁不出現在搜尋結果，允許抓取並使用 noindex；如果目標是整併重複版本的訊號，則保持候選頁可索引並使用一致的 canonical、內鏈與 sitemap。不要同時送出相互衝突的 noindex 與 canonical，再假設 Google 會按固定順序解讀。完整設定可參考 Canonical 標籤設定指南。

實務上先確認頁面的預期狀態：要排除就只用可被讀取的 noindex；要整併重複頁就移除 noindex，並檢查 canonical 目標、內鏈、sitemap、轉址與內容相似度是否一致。Google 選到非預期 URL 時，應檢查這些訊號是否互相矛盾，而不是依靠一個未公開的優先序。

1. 想讓頁面索引：不要放 noindex，確認 robots 沒擋，canonical 指向自己或合理標準頁。
2. 想讓頁面不索引：允許 Google 爬到頁面，再放 noindex。
3. 想處理重複版本：用 canonical、內鏈、sitemap 和 URL 結構一致強化標準頁。
4. 想處理品質問題：補足主要內容、搜尋意圖、獨特資訊和內鏈，不要只重送索引。

「抓取率」這個詞，log 和 GSC 算的常常不是同一件事

抓取率分母口徑：同樣叫「抓取率」，如果一個數字來自 server log，另一個數字來自 GSC 的抓取統計資料報表，兩者的分母很可能不一樣。log 算的是網站端接收到的請求，GSC 算的是 Google 端彙總後的要求數，混著比較容易得出錯誤結論。任何跨資料源的抓取比例，都要先確認分子、分母、時間窗三者一致，再拿來下判斷。

log 抓取率的分母由網站端自己定義

Server 或 CDN log 的抓取率，分母通常是由網站端自行定義的「該時間窗內所有被辨識為 Googlebot（或其他特定爬蟲 UA）的請求數」。分子則依想看的問題而定，例如特定資源類型的請求數、特定狀態碼的請求數，或特定路徑的請求數。這組分母與分子的定義，完全由 log 格式與篩選規則決定，換一套篩選條件，數字就會跟著變。

正因為分母由自己掌握，log 抓取率適合用來觀察網站端實際接收到的爬蟲請求，也能看出不同資源類型或狀態碼的分布；但這個數字反映的是網站端的接收與回應，不是 Google 端彙總後的處理結果。要拿它與 GSC 比較，得先確認兩邊的口徑能否對齊。

GSC 抓取率是 Google 彙總後的每日要求數

GSC 的抓取統計資料報表提供 Google 記錄並彙總的總抓取要求，並可依回應、檔案類型、抓取目的與 Googlebot 類型分組；它本身不是一個預先定義好分母的『抓取率』。網站端看到的是彙總後的圖表，拿不到 Google 內部的完整原始請求記錄；這組資料的時間窗定義、是否含重試請求、是否含快取回應，都不一定與網站自己的 log 一致。

要交叉比較兩組資料前，先確認三件事再下結論：兩邊的時間窗是否重疊、分母是用請求數還是位元組數、雙方是否都只計算真正的 Googlebot 流量而非所有宣稱自己是爬蟲的請求。任何一項對不齊，就先分開各自看各自的趨勢，不要跨來源相減或相除，也不要把某篇公開文章給的比例當成網站該達到的標準。

如果手上有自己的 server log，比較穩妥的做法是先在自己的資料裡把分子與分母的定義寫清楚並固定下來，之後每次比對都沿用同一套規則。定義固定了，log 與 GSC 各自呈現的抓取趨勢才有參考價值；隨意套用別人的數字，只會把抓取率變成無法解釋的單點數值。

用 GSC 判讀網址檢查與網頁索引報表

GSC 的判讀要拆成兩個層次：網址檢查工具看單一 URL 的發現、爬取、轉譯與索引狀態；網頁索引報表看整批 URL 已收錄與未收錄的數量與原因分布。兩者分開看都只回答一半，把單一頁面的結果放回整批分布裡交叉比對，才能定位問題到底是卡在發現、爬取權限、索引資格還是標準網址選擇。

單一 URL 與整批分析的交叉判讀

網址檢查工具提供 Google 已建立索引版本的資訊，也能測試 URL 是否可被建立索引；官方列出的常見用途包含查看索引狀態、檢查線上 URL、要求建立索引、查看轉譯版本，以及排解網頁缺漏問題，可參考 Google 網址檢查工具說明。但它呈現的終究是單一頁面在某次抓取時間點的結果。例如同一頁顯示「Google 選擇了不同的標準網址」，單靠這個結果無法判斷是網站 canonical 指向錯誤、內容重複，還是另一頁真的更適合收錄；應回到網頁索引報表觀察重複與 canonical 相關原因是否集中，再抽取代表性 URL 核對 canonical、內鏈與內容；報表數量同時上升只能指出整批模式，不能單獨證明根因。

網頁索引報表顯示 Google 知道的 URL 中，哪些已建立索引、哪些未建立索引，以及未收錄的各項原因分布；官方也提醒，不是所有未索引都需要修，有些是 robots、noindex、重複頁或不適合索引的頁面，可參考 Google 網頁索引報表說明。反過來看，當報表裡某一類原因大量集中，例如數十條 URL 都標為「已檢索但未建立索引」，就不該把報表當成逐條重送的待辦清單。從中挑出三到五個代表性 URL，逐一用網址檢查核對伺服器回應、轉譯結果與 noindex 設定，若問題落在同一層級，修正一次就會反映在整批資料上。

兩個工具的時間視野也不一樣：網址檢查對應的是 Google 最後一次抓取該頁的快照，網頁索引報表則顯示各日期下 Google 已知 URL 的索引狀態總量與趨勢，不是網站歷來 URL 的累計清單。因此當某個 URL 昨天還在索引中、今天從報表消失，用網址檢查查看索引版本並測試現場網址，可以確認當前可抓取與部分可索引條件；單次結果不能判定問題是暫時或永久，仍要依原因分類、後續抓取與報表趨勢決定修復或移除。GSC 不是一個每天按「要求建立索引」的按鈕，真正有價值的用法是讓每個狀態對應到診斷階梯上的某一層，修完該層之後再觀察整個批次的變化，而不是重複重送同一批 URL。 延伸閱讀：網站已收錄卻沒有流量。

你看到的訊號	代表的層級	下一步
Google 無法辨識的網址	發現	補內鏈、sitemap、重要頁入口
robots.txt 封鎖	爬取權限	調整 robots 規則
noindex	索引資格	確認是否故意排除
Google 選了不同 canonical	標準網址	檢查 canonical、內鏈、內容重複
已索引但沒流量	搜尋結果使用	回到查詢、內容與排名診斷

修完後怎麼驗證與重送

索引修正驗證的第一步，是確認問題已在 live URL 消失，再要求 Google 重新爬取。重送索引不是加速收錄的捷徑，它只負責在你已修好重要問題後，提醒 Google 重新檢查這條 URL。若根本問題還在，重送只會讓 Googlebot 重複走同一條失敗路徑。

實務上，修正後不要只看 CMS 裡的頁面狀態。你要比對伺服器回應、原始 HTML、robots 指令、noindex、canonical、GSC 即時測試，以及一段時間後的索引狀態。Google 文件也指出，即時測試不會涵蓋所有可能的索引條件，所以即時可索引不等於一定會進搜尋結果，需要保留觀察期。

驗證的實作順序

將上述檢查拆成明確順序，可以避免「以為修好、實際沒修好」的誤判。建議依序執行：

1. 先用瀏覽器和 header 工具確認 URL 回 200。
2. 檢查 robots.txt 沒擋重要頁面。
3. 檢查原始碼沒有意外 noindex。
4. 確認 canonical 指向預期 URL。
5. 用 GSC 測試線上網址。
6. 問題已修正後，再要求建立索引或驗證修正。
7. 幾天後看網頁索引報表和 GSC 成效，不要用當天結果判斷成敗。

這七步中，第二步與第四步最容易被忽略。robots.txt 擋住的是整層路徑，canonical 改動影響的是多頁合併訊號，兩者都不會反應在單一頁面的編輯器狀態中。你需要用瀏覽器直接開啟線上 URL，再以檢視原始碼比對。

整批 URL 的處理原則

如果問題牽涉整批 URL，例如分類參數、重複頁、伺服器錯誤或錯誤 URL pattern，就不要逐頁重送。逐頁重送只會讓 Google 重複檢查同一種錯誤模式，真正的修復應在模板、路由、內鏈和 sitemap 層級完成，再讓 Google 重新理解整個結構。

URL pattern 本身的設計會直接影響 Googlebot 的分工方式，可延伸看 URL 結構設計對爬取與索引的影響。

如果爬取與索引這一層已經排除，剩下的問題會變成「這個網址還值不值得留著」，這已經是內容盤點與去留的決策問題，不再是爬取索引問題，可以接著看 SEO 審計方法論的判斷法。

重送後的觀察與下一步

如果你已經確認頁面本身可以被爬取與索引，下一步要檢查 Google 是否能穩定發現重要 URL。可延伸閱讀 Sitemap 網站地圖提交教學，把 XML sitemap、GSC 提交、robots.txt 宣告與 IndexNow 分成可驗證的提交流程。

重送完成不代表驗證結束。重新抓取與索引沒有固定時間，可能從一兩天到數週，且不保證一定收錄；整批 URL 的 canonical、路由或模板變更通常更需要持續觀察。你應該在重送後固定時間點檢查網頁索引報表與 GSC 成效，確認修正是否真正反映到曝光與點擊。

重要頁面一直沒被索引，卻不知道卡在哪一層？AK SEO Labs 會從 GSC、robots、canonical、URL pattern、內鏈與頁面品質一起檢查。到服務方案頁面可比較 SEO 策略藍圖（15 萬起 / 一次性）、SEO 成長顧問（10 萬起 / 月）、規模化 SEO 系統（15 萬起 / 月），以及品牌搜尋與 AI 引用布局（客製化 / 需討論）的適用情境，把「Google 不收錄」拆成可修的工程項目。

FAQ

Google 爬取和索引差在哪？

爬取是 Googlebot 存取並下載網頁內容，索引是 Google 分析內容並決定是否把資訊存進索引資料庫。頁面可以被爬取，但不一定會被索引。

頁面已被爬取但未索引，是不是代表內容不好？

不一定。可能是 noindex、canonical、重複內容、soft 404、轉譯問題，也可能是內容品質或搜尋價值不足。要先看 GSC 給的原因，再決定修技術還是修內容。

提交 Sitemap 可以保證索引嗎？

不能。Sitemap 主要幫 Google 發現重要 URL，不保證爬取、索引或排名。頁面仍需要可爬、可轉譯、可索引、有明確 canonical 和足夠內容價值。

robots.txt 和 noindex 要怎麼選？

想阻止 Google 爬取資源，用 robots.txt；想讓頁面不要出現在搜尋結果，通常用 noindex，並且要讓 Google 能爬到頁面讀到 noindex。不要用 robots.txt 當成可靠的移除索引方法。

Google 選了不同 canonical 怎麼辦？

先確認你的 canonical、內部連結、sitemap、內容差異和轉址是否一致。如果多個頁面太相似，Google 可能選擇它認為更代表該內容群組的 URL。

GSC 顯示網址在 Google 服務中，為什麼搜尋不到？

「網址在 Google 服務中」代表有資格出現在搜尋結果，不保證特定查詢一定看得到。還要看查詢相關性、內容品質、競爭頁面、地區、裝置與搜尋結果版位。

修正後多久會重新索引？

沒有固定時間。重要頁面、常更新頁面、內鏈清楚的頁面通常比較容易被重新處理。修完後可用 GSC 要求建立索引，但仍要等 Google 排程爬取與處理。

大量頁面未索引一定是壞事嗎？

不一定。參數頁、重複頁、篩選頁、低價值頁本來就不一定該索引。重點是重要頁面是否能被發現、爬取、索引，並且 Google 是否選到正確 canonical。

PageSpeed 會影響爬取與索引嗎？

效能太差、伺服器常錯誤或資源載入失敗，可能影響 Googlebot 擷取與轉譯。效能診斷可延伸看 PageSpeed Insights 教學，但不是所有未索引都由速度造成。

新網站完全沒有索引，先做什麼？

先確認首頁可被 Google 存取並回 200，重要頁面有內部連結，沒有 noindex 或 robots 阻擋，再提交 sitemap 和用 GSC 檢查代表性 URL。不要一開始就大量重送所有頁面。

有沒有「健康」的 HTML 資源佔比可以當標準？

沒有固定的健康比例。任何 Googlebot 花多少比例在 HTML 上的主張，都要有分子（哪一類請求）、分母（同時間窗全部請求）與時間窗三件事才有意義，跨網站比較這個比例沒有參考價值，只能看同一個站的時間序列變化。

Cloudflare 或 CDN 開啟 AI 爬蟲阻擋，會不會連 Googlebot 一起擋掉？

有可能，而且 Cloudflare 已公告 2026 年 9 月 15 日起，多用途 crawler 會依所有用途套用最嚴格規則；阻擋 Training 時，Googlebot 等兼具 Search 與 Training 分類的 crawler 也可能被擋。這不代表所有網站必然受影響：要檢查網域方案、頁面是否含廣告、目前 Search／Agent／Training 設定與是否已選擇退出新預設，再用已驗證的 Googlebot log、網址檢查與網頁索引報表確認。

Server log 的抓取率跟 GSC 的抓取統計資料可以直接比較嗎？

不建議直接比較。兩者的分母通常不一樣，log 的分母由你自己的篩選規則決定，GSC 的分母是 Google 彙總後的口徑，時間窗與重試、快取的計算方式也可能不同。先確認雙方口徑一致，對不齊就分開各自看趨勢。