檢索統計資料報告

檢索統計資料報告會顯示網站的 Google 檢索記錄統計資料，例如 Google 提出的要求數量和時間、網站伺服器的回應，以及是否遇到任何可用性問題。你可以透過這份報告偵測 Google 在檢索網站時是否遇到伺服器問題。

這份報告主要是針對「進階使用者」所設計，如果你的網站網頁數量少於一千，就不必使用這份報告，也不必擔心檢索報告中顯示的眾多資訊。

這份報告僅適用於根層級資源，也就是說，報告中的資源必定為網域資源 (例如 example.com 或 m.example.com) 或是根層級的網址前置字元資源 (例如 https://example.com、http://example.com、http://m.example.com)。

開啟檢索統計資料報告

 

依序按一下「資源設定」圖示 > [檢索統計資料]，即可在 Search Console 中瀏覽檢索統計資料報告。

開始使用

在使用這份報告之前，請務必先瞭解以下資訊：

• Google 搜尋的運作方式 (詳細說明)。
• 進階使用者主題，尤其是檢索、索引和 Sitemap 等主題。
• 與管理網站存取權相關的各種主題，包括如何透過 robots.txt 進行封鎖。
• 如果是網頁數量極多的大型網站，請參考這份指南，瞭解如何管理檢索預算及排解相關問題。

關於資料

• 本報告顯示與計算的所有網址都是 Google 要求的實際網址，而不會將資料歸給標準網址，這點與其他報告不同。
• 如果網址會造成重新導向，則系統會將重新導向鏈結中的每項要求視為單獨的要求。舉例來說，假設 page1 會重新導向至 page2，而 page2 又會重新導向至 page3，那麼如果 Google 要求存取 page1，報告中會顯示三次獨立要求：對 page1 的要求 (傳回 301/302)、對 page2 的要求 (傳回 301/302) 以及對 page3 的要求 (希望能傳回 200)。請注意，報告只會顯示目前網域中的網頁。
• 因無法存取 robots.txt 而失敗的檢索作業會計入檢索總數，但報告中的檢索詳細資料部分不會顯示相關資訊。更多資訊
• 資源和範圍：
  • 報告只會顯示目前選取網域的資料，不會顯示對其他網域的要求。所謂「對其他網域的要求」包括對此網站以外位置代管的任何網頁資源 (例如圖片) 所提出的要求。因此，如果 example.com/mypage 這個網頁中含有 google.com/img.png 這張圖片，那麼在 example.com 網站的「檢索統計資料」報告中，就不會顯示系統對 google.com/img.png 提出的要求。
  • 同樣地，系統不會顯示對同屬網域的要求，例如 en.example 和 de.example。也就是說，en.example 的檢索統計資料報告中不會顯示系統對 de.example 中圖片的要求。
  • 不過，上層網域的報告中會顯示子網域的要求。舉例來說，如果查看 example.com 的資料，就能看到 example.com、en.example、de.example.com，以及 example.com 底下任何層級的所有子網域所收到的要求。
  • 相反地，如果有其他網域的網頁使用了你網站中的網頁資源，報告會顯示與代管網頁關聯的檢索要求，但卻不會顯示系統正在檢索該資源的相關資訊，因為使用該資源的是位於其他網域的網頁。也就是說，example.com/imageX.png 這張圖片的檢索記錄會歸至另一個網頁 anotherexample.com/mypage，所以你不會看到。
  • 檢索資料的範圍同時包含 http 和 https 通訊協定，網址前置字元資源亦然。這表示，http://example.com 的檢索統計資料報告同時包含了對 http://example.com 以及 https://example.com 提出的要求。不過，網址前置字元資源的樣本網址僅限於你對資源定義的通訊協定，也就是 http 或 https。

已知問題：檢索統計資料報告目前能呈現大部分的檢索要求，但基於某些原因，部分要求可能不會列入計算。我們期望未來能逐漸增加涵蓋率，以納入所有要求，在那之前會盡力提供大部分要求的資料。因為這些緣故，網站的要求記錄和這份報告顯示的數據可能會有些許差異，還請見諒。

瀏覽報告

報告會顯示網站的下列檢索資訊：

• 檢索要求總次數
• 下載內容總大小
• 平均回應時間
• 主機狀態
• 檢索回應
• 檔案類型
• 檢索目的
• Googlebot 類型

按一下任一表格項目，即可詳細檢視樣本網址清單等資訊，按一下網址則能取得該次檢索要求的詳細資料。舉例來說，在依照類型分組顯示回應的表格中，只要按一下 [HTML] 列，即可查看網站上所有受檢索 HTML 網頁的匯總檢索資訊，並能針對系統從這些網址中所選的樣本，查看檢索時間、回應代碼、回應大小等詳細資料。

主機和子網域

如果資源位於網域層級 (例如 example.com、http://example.com、https://m.example.com)，並且含有兩個以上的子網域 (例如 fr.example.com 和 de.example.com)，那麼你可以查看包含所有子網域的上層網域資料，或者選擇只瀏覽單一子網域的資料。

如要將報告的範圍限定在特定子網域，請在上層網域報告到達網頁的「主機」清單中點選要檢視的子網域。報告只會顯示最近 90 天內接收流量前 20 名的子網域。

樣本網址

只要按一下回應、檔案類型、目的、Googlebot 類型等任何資料分組類型，即可查看該類型的樣本網址清單。

請注意，樣本網址並非所有網址，只是具代表性的樣本。即使在清單中找不到某個網址，也並不表示我們未對該網址提出要求。此外，系統可能會依照天數進行加權計算，以此決定取樣數量，因此某類要求的樣本數可能會比其他類型多，不過數量的落差應該會隨著時間而縮小。

檢索要求總次數

系統對網站內網址提出的檢索要求總數，無論要求是否成功。如果網頁使用的資源位於你的網站中，那麼這項數據也包含系統對這些資源的要求次數，但代管位置位於你網站以外的資源則不會納入計算。此外，對相同網址提出的重複要求會分開計算。如果發生 Google 無法存取 robots.txt 檔案的情形，這些因故無法的執行擷取作業「也會」計入檢索要求總數中。

以下這些無法成功執行的要求會列入計算：

• 因為無法存取 robots.txt 檔案而從未實際執行的擷取作業
• 因為 DNS 解析問題而失敗的擷取作業
• 因為伺服器連線能力問題而失敗的擷取作業
• 因為重新導向迴圈問題而放棄的擷取作業

下載內容總大小

在指定時間範圍內，系統於檢索期間從網站下載的位元組總數。如果 Google 快取的網頁資源會用於多個網頁，那麼系統只會在第一次時 (也就是在進行快取的時候) 才會要求資源。

平均回應時間

在指定時間範圍內，從網站擷取的所有資源的平均回應時間。如果一項資源連結至多個網頁，每個網頁的回應都會視為不同的回應。

主機狀態

「主機狀態」能說明 Google 在嘗試檢索網站時是否遇到可用性問題。這裡顯示的狀態會是下列其中一個值：

• 
  過去 90 天內，Google 並未在你的網站上遇到任何重大的檢索可用性問題。恭喜你，不必採取任何操作！
• 
  過去 90 天內，Google 曾在你的網站上遇到至少一項重大檢索問題，不過問題發生時間是在超過一週之前。這可能是暫時性錯誤，或者問題已經解決。建議檢查「回應」表格，瞭解問題為何後再決定是否需要採取任何行動。
• 
  過去一週，Google 曾在你的網站上遇到至少一項重大檢索問題。由於這項錯誤才剛發生，建議你嘗試判斷這是否為重複發生的問題。請檢查「回應」表格，瞭解問題為何後再決定是否需要採取任何行動。

報告重點

理想的主機狀態應該為綠色，如果你的可用性狀態呈現紅色，請點擊並查看 robots.txt 可用性、DNS 解析和主機連線能力等可用性詳細資料。

主機狀態詳細說明

系統會根據以下類別來評估主機的可用性狀態，任何類別中只要發生一次重大錯誤就會降低可用性狀態。如要查看詳細資料，請按一下報告中的類別。

報告會針對每個類別顯示一張所選時間範圍內檢索資料的圖表。該圖表會包含一條由紅點構成的線條，如果在某類別中，指標高於虛線 (例如任一天內 DNS 解析失敗率超過要求次數的 5%)，系統就會判定該類別發生問題。報告中顯示的狀態會反映最後一次發生問題的時間。

• robots.txt 擷取
  圖表會顯示單次檢索期間內的 robots.txt 要求失敗率。Google 會經常要求存取這個檔案，如果要求未傳回有效檔案 (無論檔案是否含有任何內容或是空白) 或 404 回應 (檔案不存在)，Google 就會降低檢索頻率或停止檢索你的網站，直到獲得可接受的 robots.txt 回應為止。詳情請見下文說明。
• DNS 解析
  圖表會顯示檢索期間 DNS 伺服器無法識別主機名稱或沒有回應的時間點。如果看到錯誤，請與你的註冊商聯絡，確認網站設定正確，且伺服器已連上網際網路。
• 伺服器連線能力
  圖表會顯示伺服器在檢索期間內沒有回應或未提供完整網址回應的時間點。請參閱這篇文章中的「伺服器錯誤」一節，瞭解如何修正這些錯誤。

其他關於 robots.txt 可用性的詳細資料

以下將詳細說明 Google 在檢索網站時查看和使用 robots.txt 檔案的方式。

你的網站不一定要有 robots.txt 檔案，但是當 Google 要求這個檔案時，網站必須傳回下文定義的成功回應，否則 Google 可能會停止檢索你的網站。

• 成功的 robots.txt 回應
• 下列任一回應皆為成功的回應：
  • 傳回 HTTP 200 代碼和 robots.txt 檔案，且檔案必須為有效、無效或空白。如果檔案含有語法錯誤，Google 仍會將該次要求視為成功，但可能會忽略檔案中任何包含語法錯誤的規則。
  • 傳回 HTTP 403/404/410 代碼，表示檔案不存在。你的網站不一定要有 robots.txt 檔案。
• 失敗的 robots.txt 回應
  • 傳回 HTTP 429/5XX 代碼，表示發生連線問題。

在檢索網站時，Google 會以下列方式要求和使用 robots.txt 檔案：

1. 在檢索網站之前，Google 會先確認過去 24 小時內是否曾有成功的 robots.txt 要求。
2. 如果最近曾獲得成功的 robots.txt 回應，Google 會開始檢索作業並遵循擷取到的 robots.txt 規則。
3. 如果最近不曾獲得成功的 robots.txt 回應，或者最後一次回應為失敗回應，Google 會要求存取 robots.txt 檔案：
   • 如果要求成功，便會開始檢索作業。
   • 如果要求失敗，Google 會停止檢索，並在 30 天內持續要求你的 robots.txt。如果無法在 30 天後獲得成功的 robots.txt 回應，Google 會視情形採取下列動作：
     • 如果能夠存取網站上其他大部分網址，Google 會採用上次成功擷取的 robots.txt 規則，據此進行檢索作業。
     • 如果網站大致上都無法存取，Google 就會停止檢索你的網站。

如果 Google 因為無法存取 robots.txt 檔案而放棄進行檢索，這些放棄的檢索作業「仍然會計入檢索總數」。不過，因為系統從未實際執行這些檢索，因此相關資料完全不會顯示在依照檢索目的或回應等條件呈現的分組報告中。

檢索回應

這張表格會呈現 Google 在檢索你的網站時收到的回應，並依照回應類型分類，顯示該類型在所有檢索回應中的百分比。此處的資料是依據要求總次數計算，而不是網址。假設 Google 對同個網址提出兩次要求，第一次獲得「Server error (500)」回應，第二次獲得「OK (200)」回應，那麼回應資料會顯示 50% 為伺服器錯誤，50% 為成功。

報告重點

除非網站正在重組或遷移，否則大部分的回應都必須是 200 或其他「良好」類型的回應。請參閱下方清單，瞭解其他回應代碼的處理方式。

 

以下是部分常見的回應代碼和處理方式：

良好回應代碼

這些網頁都運作正常，並未造成任何問題。

• OK (200)：在一般情況下，絕大多數網頁都會傳回 200 回應代碼。
• Moved permanently (301)：網頁傳回 HTTP 301 (永久轉址) 回應，且應該是你預期的回應。
• Moved temporarily (302)：網頁傳回 HTTP 302 (暫時轉址) 回應，且應該是你預期的回應。如果這個網頁已永久移至別處，請將代碼變更為 301。
• Moved (其他)：301 或 302 以外的其他 300 重新導向回應。
• Not modified (304)：網頁自上次檢索要求後未變更。

可能屬於良好的回應代碼

傳回這些回應並不代表網頁發生問題，但還是建議進行檢查，確認這是你預期的回應。

• 遭到 robots.txt 封鎖：這種回應通常是刻意設定的結果。不過，建議你再次確認並未封鎖任何你想要 Google 檢索的網頁或資源。進一步瞭解 robots.txt 檔案。
• Not found (404) 錯誤，可能是因為網站內外的無效連結所造成。要修正網站上所有的 404 錯誤非常困難，也不必這麼做。很多時候網頁確實應該傳回 404 代碼，例如當網頁的確已經消失且沒有替代網頁的情況。請參閱這篇文章，瞭解是否該修正以及如何修正 404 錯誤。

不佳的回應代碼

你必須修正傳回這些錯誤的網頁，以改善檢索作業。

• 無法存取 robots.txt：如果一整天都無法存取 robots.txt 檔案，Google 會暫停檢索，直到系統對 robots.txt 提出的要求獲得可接受的回應為止。這項回應與「Not found (404)」不同，系統可以接受伺服器對 robots.txt 檔案要求傳回「Not found (404)」。查看其他關於 robots.txt 的詳細資料。
• Unauthorized (401/407)：請使用 robots.txt 禁止系統檢索這些網頁，或決定是否要解除封鎖。如果這些網頁沒有安全資料，且你也希望 Google 檢索這些網頁，建議將相關資訊移至非安全網頁，或是允許 Googlebot 在不登入的情況下存取。不過請注意，不肖人士有可能假冒 Googlebot，因此允許 Googlebot 存取就相當於移除了網頁的安全措施。
• Server error (5XX)：這類錯誤會造成可用性警告，請盡可能加以修正。縮圖圖表會顯示發生這些錯誤的概略時間，按一下即可查看詳細資料和確切時間點。請依據資料判斷這是暫時性問題，或者代表網站中存在更嚴重的可用性錯誤。如果 Google 正在檢索你的網站，你可以要求降低檢索頻率；如果認為這是嚴重可用性問題的徵兆，請參閱檢索次數遽增的相關說明。請參閱這篇文章中的「伺服器錯誤」一節，瞭解如何修正這些錯誤。
• Other client error (4XX)：此處未列出的其他 4XX (用戶端) 錯誤。強烈建議你修正這些問題。
• DNS 沒有回應：DNS 伺服器未回應 Google 對你網站中網址的要求。
• DNS 錯誤：其他不明 DNS 錯誤。
• 擷取錯誤：因為發生通訊埠號碼錯誤、IP 位址錯誤或無法剖析的回應，而無法擷取網頁。
• 無法造訪網頁：因取得網頁時發生任何其他錯誤，導致要求未送達伺服器。由於這些要求從未送至伺服器，因此也不會出現在記錄中。
• 網頁逾時：網頁要求逾時。
• 重新導向錯誤：提出的要求發生重新導向錯誤，例如重新導向太多次、空白的重新導向或重新導向迴圈。
• 其他錯誤：不屬於上述任何類別的錯誤。

檢索的檔案類型

Google 在要求中收到的檔案類型。報告顯示的各類型百分比值是該類型回應在 Google 收到的回應中所占的百分比，而不是在擷取的位元組中的比例。

可能的類型包括：

• HTML
• 圖片
• 影片：支援的影片格式之一
• JavaScript
• CSS
• PDF
• 其他 XML：XML 檔案，但不包括 RSS、KML 或任何其他以 XML 為基礎建立的格式
• JSON
• 資訊聚合：RSS 或 Atom 動態消息
• 音訊
• 地理資料：KML 或其他地理資料
• 其他檔案類型：此處未列出的其他檔案類型
• 不明 (失敗)：如果要求失敗，則無法得知檔案類型

報告重點

如果發現有可用性問題或回應速度緩慢，請參閱這份表格，瞭解 Google 正在檢索哪種類型的資源，以及為什麼這會減緩檢索的速度。是否因為 Google 要求存取許多應該受到封鎖的小型圖片？或者 Google 要求存取的資源是由其他回應能力低落的網站所代管？只要按一下不同的檔案類型，即可在圖表上查看每個日期的平均回應時間及要求數量，進而判斷該類型中回應緩慢項目突然增加的情況，是否與整體回應速度緩慢或無法存取的項目遽增有關。

檢索目的

• 探索：Google 從未檢索過這個網址。
• 重新整理：重新檢索已知網頁。

如果你經常更新某些檢索頻率較低的網頁，請務必將這些網頁納入 Sitemap。至於更新速度還沒有那麼快的網頁，建議你主動要求重新檢索。理論上來說，如果你最近新增了大量新內容或是剛提交 Sitemap，應該會發現網站的探索檢索次數因此增加。

Googlebot 類型

提出檢索要求的使用者代理程式類型。Google 有多種使用者代理程式，可針對不同原因進行檢索，行為模式也不太相同。報告中會呈現的類型如下：

• 智慧型手機：Googlebot 智慧型手機檢索器。
• 電腦：Googlebot 電腦檢索器。
• 圖片：Googlebot 圖片檢索器。如果圖片是以網頁資源的形式載入，系統會將該圖片的 Googlebot 類型視為「網頁資源載入」，而非「圖片」。
• 影片：Googlebot 影片檢索器。如果影片是以網頁資源的形式載入，系統會將該影片的 Googlebot 類型視為「網頁資源載入」，而非「影片」。
• 網頁資源載入：網頁所用資源的次要擷取方式。在檢索網頁時，Google 會先擷取圖片或 CSS 檔案等重要連結資源，以便在嘗試為網頁建立索引前先進行轉譯，而負責對這類資源提出要求的就是這項使用者代理程式。
• AdsBot：AdsBot 檢索器其中之一。如果發現要求的數量驟增，可能是因為你最近為網站的動態搜尋廣告新增了多個目標。請參閱這篇文章，瞭解檢索頻率上升的原因。一般來說，AdsBot 大約每 2 週會檢索一次網址。
• StoreBot：產品購物檢索器。
• 其他代理程式類型：此處未列出的其他 Google 檢索器。

大部分的檢索要求應該都會來自你的主要檢索器，如果發現檢索次數遽增，請檢查使用者代理程式類型。如果因為 AdsBot 檢索器造成頻率上升，請參閱「為什麼檢索頻率會上升」一節的說明。

疑難排解

檢索頻率過高

Googlebot 會採用演算法來避免過度檢索你的網站。不過，如果你因為某些原因而需要限制檢索頻率，請參閱這篇文章的說明。

以下提供幾個降低檢索頻率的提示：

• 調整 robots.txt 檔案，封鎖不應該呼叫的網頁。
• 你可以在 Search Console 中設定偏好的檢索頻率上限，暫時解決這個問題。不過，我們不建議長期採用這種方式，因為這並未明確表達哪些網頁或資源應該受到檢索，哪些則否。
• 務必確認你並未允許 Google 檢索含有「無限內容」的網頁，例如無限日曆或無限搜尋網頁。請利用 robots.txt 或 nofollow 標記封鎖這類網頁。
• 如果網址已不存在或已遷移，請務必傳回正確的回應代碼：如果網址已不存在或無效，請使用 404 或 410；如果網址已使用其他網址永久取代，請使用 301 重新導向，如果只是暫時取代則使用 302；如果網址因為預訂維護作業而暫時無法使用，請使用 503；如果發生伺服器無法處理的問題，請確認伺服器傳回的是 500 錯誤代碼。
• 如果網站無法負荷檢索要求，需要緊急降低頻率，請參閱下節「為什麼檢索頻率會上升？」的說明。

為什麼檢索頻率會上升？

如果你在網站新增許多新的內容，或者網站提供的資訊相當實用，那麼檢索頻率就可能會高於預期。例如下列情形：

• 你取消了網站中大批內容的檢索封鎖
• 你在網站上新增了大批新的內容
• 你新增了網頁動態饋給或 URL_Equals 規則，在動態搜尋廣告中加入大量新目標

如果你的網站因過度檢索而無法正常運作，可以採取下列做法保護網站：

1. 判斷過度檢索網站的是哪個 Google 檢索器。你可以查看網站記錄或藉由檢索統計資料報告瞭解這項資訊。
2. 可立即緩解這種情況的方法：
   • 如果想採用簡單的解決方案，請使用 robots.txt 禁止 Googlebot、AdsBot 等造成超載的代理程式進行檢索作業，不過這種做法最多可能需要一天的時間才會生效。
   • 如果你能夠以動態方式偵測增加的負載並做出回應，請在接近服務上限時傳回 HTTP 5XX/429。不過，執行傳回 5XX 或 429 的時間請勿超過二至三天，否則可能會使得 Google 長期低你網站的檢索頻率。
3. 如果能存取「檢索頻率設定」頁面，請使用該頁面變更檢索頻率。
4. 二至三天後，當 Google 調整了檢索頻率，你就能移除 robots.txt 封鎖設定或停止傳回步驟 1 的錯誤代碼。
5. 如果過度檢索網站的是 AdsBot，可能是因為你在網站上使用 URL_Equals 或網頁動態饋給建立了太多動態搜尋廣告目標。假如你的伺服器負載量不足以處理這些檢索要求，請限制廣告目標、分批加入網址，或者提高伺服器負載量。請注意，AdsBot 每隔 2 週就會檢索網頁，因此請修正這個問題，否則問題會再次發生。
6. 請注意，如果透過檢索設定頁面限制了檢索頻率，檢索頻率會在 90 天後恢復為自動調整。

檢索頻率太低

除非之前曾經明確降低資源的檢索頻率，否則你無法要求 Google 提高頻率。不過，你可以參閱這篇說明文章，進一步瞭解如何管理極大型網站或經常更新網站的檢索作業。

如果你的網站屬於中小型網站，卻發現 Google 沒有檢索網站的所有內容，請嘗試更新網站的 Sitemap，並確認你並未封鎖任何網頁。

為什麼檢索頻率會下滑？

一般來說，在一週或二週的時間範圍內，您的 Google 檢索頻率應該處於相對穩定的狀態；如果您發現檢索頻率突然減少，可能的原因如下：

• 您加入了新的 (或範圍極廣的) robots.txt 規則。請務必只封鎖需要封鎖的資源即可。如果 Google 需要 CSS 或 JavaScript 等特定資源才能瞭解內容，請確認你並未禁止 Googlebot 檢索這類資源。
• 網頁中出現損毀的 HTML 或不支援的內容：如果 Googlebot 無法剖析網頁內容，可能是因為網頁使用了不支援的媒體類型，或者網頁只是圖片，所以 Googlebot 無法進行檢索。請使用網址檢查工具，以 Googlebot 的角度查看你的網頁內容。
• 如果網站回應要求的速度緩慢，Googlebot 便會調整要求的數量，避免伺服器出現過載的情形。請查看檢索統計資料報告，瞭解網站回應速度是否變慢。
• 如果伺服器的錯誤率增加，Googlebot 便會縮減要求的數量，避免伺服器過載。
• 確認你並未降低偏好的檢索頻率上限。
• 如果網站內含不常變更的資訊，或者資訊的品質不佳，Google 就會降低該網站的檢索頻率。請以中肯的角度評估自己的網站，同時向與網站無關的人士徵詢中立意見，然後思考該如何提升網站整體品質，或者該加強哪些部分。

相對於檢索記錄或檢索詳細資料中的總數，檢索總數高出許多

如果檢索總數的值明顯高於回應、類型等檢索要求詳細資料中的總數，通常是因為 robots.txt 檔案已經太久無法存取，導致 Google 無法檢索你的網站。發生這種情況時，Google 會將 robots.txt 檔案可用時應該能進行的檢索作業計入檢索總數，但實際上，這些檢索作業從未實際執行。請檢查 robots.txt 擷取狀態，確認這是否為造成問題的原因。