AMP 狀態報告

這份報告可協助您修正錯誤,讓您的 AMP 網頁順利顯示在 Google 搜尋結果中,並呈現 AMP 特有的功能。

最上層的檢視畫面會顯示 Google 在您網站上找到的所有 AMP 問題網頁,並依據問題分組。只要按一下特定問題,就能查看詳細資訊,包括受該問題影響的網頁示例、問題修正方法的相關資訊,以及通知 Google 您已修正問題的程序。

您也可以前往「狀態」頁面查看相關圖表,瞭解這些問題和修正問題帶來的影響。

為什麼無法列出所有出錯的網頁? 我們會盡可能列出所有受到錯誤影響的網頁,但我們的表格最多只能顯示 1,000 個網址,無法再多;此外,有些受到影響的網頁可能會因故偵測不到或無法計入。

開啟 AMP 報告

 

Search Console 中的 AMP 狀態報告 - Google Search Console 訓練課程

報告重點

在理想的情況下,您應該會在報告中看到以下結果:

  • 您的網站上沒有任何 AMP「錯誤」(「警告」只是建議您改善的項目,並不是錯誤;請參閱下方的「瞭解什麼是警告網頁」)。如果您的網站有任何問題,請參閱「為問題排定優先順序並進行修正」一節。
  • 報告中列出的 AMP 網頁數 (有效 + 警告 + 錯誤網頁) 應和您網站上實際擁有的 AMP 網頁數相同。如果不同,請參閱「AMP 網頁缺漏」一節。

AMP 問題清單

除了標準 AMP 錯誤以外,報告也會列出以下其他問題 (錯誤和警告)。

Google 特有的 AMP 問題
問題 說明
內容不符:缺少內嵌影片 標準網頁有內嵌影片,但 AMP 版本缺少相同的影片。一般而言,最理想的做法是在 AMP 版本和標準網頁中加入完全相同的重要內容資源。請注意,系統會透過網址來偵測影片;如果您在兩個版本中分別使用不同網址指向同一部影片,系統就會顯示這則警告。
圖片尺寸小於建議的尺寸 AMP 中的結構化資料指向的圖片小於建議尺寸。這會導致系統無法在 Google 搜尋中顯示該頁面的任何 AMP 相關功能,而且會讓探索資訊卡無法顯示大型圖片,進而造成網站流量下降與使用者參與度降低。如要進行修正,請依照我們的指南使用較大的圖片。
AMP 網頁網域不符 AMP 網頁和標準版網頁是由不同網域代管。對於使用行動裝置搜尋內容的使用者來說,這會造成他們在搜尋結果中看到其中一個網域的網址,在 AMP 閱讀器中開啟網頁後又看到另一個網域的網址而感到困惑 (不影響網頁的索引和排名)。
找不到網址 (404) 找不到要求的 AMP 網址。瞭解如何修正 404 網頁的問題
伺服器錯誤 (5XX) 要求存取 AMP 網頁時,發生不明 5XX 伺服器錯誤。進一步瞭解伺服器錯誤
遭到 robots.txt 封鎖 要求的 AMP 網址遭到 robots.txt 規則封鎖。
檢索問題 AMP 網頁出現不明檢索錯誤。您可以使用網址檢查工具來排解 AMP 網址的問題。
所參照的 AMP 網址不是 AMP 網頁 標準網頁參照的 AMP 網址其實不屬於 AMP 網頁。瞭解非 AMP 網頁應如何參照 AMP 網頁。
所參照的 AMP 網址是獨立的 AMP 網頁 標準網頁指向獨立的 AMP 網頁。你無法參照獨立的 AMP 網頁做為特定網頁的 AMP 版本。瞭解如何從非 AMP 網頁參照 AMP 網頁。
網址含有「noindex」標記 AMP 網頁遭到「noindex」指令封鎖。Google 無法為遭到「noindex」指令封鎖的網頁建立索引;建議您移除「noindex」指令,或是移除遭封鎖網頁的參照。
這個網頁的「unavailable_after」日期已失效 AMP 網頁含有已過期的「unavailable_after」中繼標記或指令,因此不該繼續顯示在搜尋結果中。建議您將標記更新為未來的日期或是移除標記。
標準網址指向無效網址 標準網頁參照的 AMP 版本網址使用無效格式。瞭解如何正確參照 AMP 版本
amp-story 標準錯誤

網頁錯誤參照 amp-story 網頁做為其 AMP 版本。我們不允許這種情況發生,因為從定義上來說 amp-story 網頁本身是獨立的,因此必須使用 <rel="canonical"> 標記指向自身,且無法顯示為其他網頁的 AMP 版本。

Signed Exchange 問題

AMP 狀態報告和網址檢查報告都會針對使用 Signed Exchange 通訊協定的 AMP 列出 AMP 相關問題。

查看問題的 Signed Exchange 詳細資訊

您可以在許多地方找到與 AMP 相關的 Signed Exchange 資訊:

  • 在「網址檢查工具」中,按一下「AMP 版本詳細資料」下方的問題。
  • 在「AMP 狀態報告」中,按一下問題詳細資料表格中的網址。

查看 AMP 是否使用 Signed Exchange

如何查看 Google 是否針對 AMP 偵測到任何 Signed Exchange 標頭或酬載:

  1. 檢查 AMP 網址 (使用網址檢查工具檢查特定網址,或在 AMP 狀態報告的問題詳細資料表格中,點選網址旁邊的「檢查」圖示 )。
  2. 點選結果頁面中的 [查看已檢索的網頁],開啟內含更多資訊的側邊面板。
  3. 按一下 [更多資訊] 分頁標籤。
  4. 系統會在「Signed Exchange」標籤下顯示狀態,指出 Google 是否已偵測到該 AMP 的任何 Signed Exchange 元件。

Signed Exchange 問題清單

您的 AMP 使用 Signed Exchange 通訊協定時,可能會發生下列問題。

Signed Exchange 無效

HTTP 回應是不符 Google AMP 快取規定Signed Exchange。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

造成這項錯誤可能的原因包括:

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager

  • 請確認您執行的是最新版的 AMP Packager。
  • 如果您已使用最新版 AMP Packager,請回報錯誤

Signed Exchange 酬載包含剖析錯誤

HTTP 回應是內含「酬載」(主體) 的 Signed Exchange,但該酬載不符 Google AMP 快取規定。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

造成這個錯誤的可能原因如下:

  • 請確認 HTML 中沒有無效的 UTF-8 編碼。如果 $URL 發生錯誤,請執行 curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null,並檢查是否有任何錯誤訊息 (例如「輸入序列不合法」)。如果系統顯示錯誤訊息,請確認文件是否採用正確的 UTF-8 編碼。英文以外的文字和空格是多位元組字元的兩個常見來源。
  • 確認 HTML 中不含會造成 HTML 剖析錯誤的 U+0000 NULL 或 Unicode 字元。
  • 確認 HTML 在呼叫 transform -config NONE 後沒有異動。造成 HTML 異動的兩個常見原因如下:

Signed Exchange 酬載的「header_name」標頭包含無效值

HTTP 回應是內含已簽署回應標頭的 Signed Exchange,但該標頭不符 Google AMP 快取的其中一項規定。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager

  • 請確認您執行的是最新版的 AMP Packager。
  • 如果您已使用最新版 AMP Packager,請回報錯誤

Signed Exchange 酬載缺少必要的「header_name」標頭

HTTP 回應是缺少指定標頭的 Signed Exchange,這個指定標頭是 Signed Exchange 規範或 Google AMP 快取規定要求的必要條件。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager

  • 請確認您執行的是最新版的 AMP Packager。
  • 如果您已使用最新版 AMP Packager,請回報錯誤

Signed Exchange 使用無法剖析的簽名標頭

HTTP 回應是內含簽名標頭的 Signed Exchange,但該標頭並不符合 Signed Exchange 規範的正確格式。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager

  • 請確認您執行的是最新版的 AMP Packager。
  • 如果您已使用最新版 AMP Packager,請回報錯誤

Signed Exchange 簽名標頭中的「parameter_name」參數無效

HTTP 回應是內含簽名標頭的 Signed Exchange,但該標頭的指定參數值有誤,不符 Signed Exchange 規範的要求。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager

  • 請確認您執行的是最新版的 AMP Packager。
  • 如果您已使用最新版 AMP Packager,請回報錯誤

Signed Exchange 的日期無效

HTTP 回應是內含簽名標頭的 Signed Exchange,但該標頭的 dateexpires 參數值有誤,不符 Signed Exchange 規範或 Google AMP 快取規定的要求 (簽名在擷取時尤其必須有效,且至少在未來 4 天內皆須有效)。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager,造成這個錯誤的可能原因如下:

  • 請確認您的前端反向 Proxy 快取 Signed Exchange 回應的時間是否過長。使用 curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' 對該網頁執行多次要求,並在各個回應中搜尋「date=」,確認每次的後續數字皆不同。
  • 請確認您執行的是最新版的 AMP Packager。
  • 如果您已排除以上所有可能原因,可能是 AMP Packager 發生錯誤,此時請回報錯誤

Signed Exchange「cert-url」參照無法剖析的憑證鏈結

HTTP 回應是內含「cert-url」的 Signed Exchange,但該「cert-url」不符合 Signed Exchange 規範的正確格式。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager

  • 請確認您執行的是最新版的 AMP Packager。
  • 如果您已使用最新版 AMP Packager,請回報錯誤

「cert-url」參照對 Signed Exchange 無效的憑證鏈結

HTTP 回應是內含「cert-url」的 Signed Exchange,但根據 Signed Exchange 規範規定,該「cert-url」無效。因此,使用者看到的網頁將不會顯示任何簽署相關資訊。

對您網站的影響:

網頁會以 Google 網址顯示在 AMP 檢視器中,而非原始網址。

後續步驟:

您可以選擇是否要處理這項錯誤;出現此錯誤的網頁在 AMP 檢視器中仍然可以正確顯示。不過,如果您希望這個網頁能透過已簽署的網址顯示,請繼續往下閱讀。

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用 AMP Packager,可能會因不同的原因而造成這個錯誤。因此,請檢查以下事項:

  • 確認您的 CertFile 未含分葉憑證和中繼憑證的完整清單。
  • 確認 AMP Packager 並非藉由 -development 或 -invalidcert 標記啟動。在實際生產模式下,AMP Packager 會針對憑證的數個面向進行驗證
  • 確認您的前端反向 Proxy 快取 /amppkg/cert/ 網址的時間未超過網址 max-age 所設定的時間。
  • 確認您的前端反向 Proxy 並未修改快取標頭,因為這項操作可能會導致上游 Proxy 快取這些憑證鏈結的時間過長。如要測試,請在內部封裝程式網域中找出對應的 /amppkg/cert/ 網址,然後擷取包含回應標頭的網址 (舉例來說,包含 curl -i),並將回應標頭與前端伺服器傳回的回應標頭進行比較。
  • 確認您的憑證是否包含 SCT,舉例來說,您可以使用 openssl x509 工具進行驗證。如果憑證不含 SCT,請洽詢您的憑證授權單位。
  • 確認您執行的是最新版的 AMP Packager。
  • 如果您已排除以上所有可能原因,可能是 AMP Packager 發生錯誤,此時請回報錯誤

系統無法剖析 Signed Exchange

HTTP 回應的內容類型為 application/signed-exchange;v=b3,但系統無法擷取回應主體。這可能是因 HTTP 回應未符合該類型的高階需求規定,或是因 HTTP 回應酬載的 Merkle 編碼不當所致。

對您網站的影響:

如果該網頁有相應的非 AMP 網頁,Google 搜尋會改為替這類網頁建立索引。如果沒有,該網頁就可能完全不會出現在 Google 搜尋中。

後續步驟:

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager,造成這個錯誤的可能原因如下:

  • 請確認您的前端反向 Proxy 沒有更動封裝程式傳回的回應。如果網址發生錯誤,請在內部封裝程式網域中找出對應的 /priv/doc 網址,然後使用 dump-signedexchange 來測試網址。如果內部封裝程式回應是有效的 Signed Exchange,但外部前端回應不是,那麼前端設定可能有誤。
  • 確認您執行的是最新版的 AMP Packager。
  • 如果您已排除以上所有可能原因,可能是 AMP Packager 發生錯誤,此時請回報錯誤

內部酬載的網址與 Signed Exchange 的要求網址不符

HTTP 回應是內含 fallbackUrlSigned Exchange,但 fallbackUrl 與要求網址不符 (兩者的位元組須相同)。因此,Google 搜尋不會信任該回應是要求網址的代表。

對您網站的影響:

如果該網頁有相應的非 AMP 網頁,Google 搜尋會改為替這類網頁建立索引。如果沒有,該網頁就可能完全不會出現在 Google 搜尋中。

後續步驟:

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。可能的解決方法包括更改網頁網址,以免在常見的網址剖析器中發生錯誤。舉例來說,您可以嘗試刪除 percent-encodedreserved 字元,或是沒有任何參數的 ? 等異常查詢字串編碼。

如果您使用的是 AMP Packager,造成這個錯誤的可能原因如下:

  • 請確認您的前端反向 Proxy 是否正確重寫網址。如果網址內含 percent-encodedreserved 字元,會特別容易出現問題。舉例來說,nginx 的重寫指令proxy_pass 指令的無路徑形式皆會發生問題。如要執行測試,請將部分測試要求傳送至前端,並與 AMP Packager 記錄至其 stdout 的網址進行比較。
  • 確認您執行的是最新版的 AMP Packager。
  • 如果您已排除以上所有可能原因,可能是 AMP Packager 發生錯誤,此時請回報錯誤

Signed Exchange HTTP 回應的「header_name」標頭包含無效值

HTTP 回應的內容類型為 application/signed-exchange,但回應標頭在其他某些方面無效。舉例來說,content-type 可能缺少 v=b3 參數,導致 Google 無法辨識這個格式,因而無法擷取回應主體。

對您網站的影響:

如果該網頁有相應的非 AMP 網頁,Google 搜尋會改為替這類網頁建立索引。如果沒有,該網頁就可能完全不會出現在 Google 搜尋中。

後續步驟:

如果您使用的服務來自 Signed Exchange 服務供應商,請向對方尋求協助。

如果您使用的是 AMP Packager,造成這個錯誤的可能原因如下:

  • 請確認您的前端反向 Proxy 沒有更動 content-type 標頭。如果網址發生錯誤,請在內部封裝程式網域中找出對應的 /priv/doc 網址,然後擷取包含回應標頭的網址 (例如包含 curl -i)。如果內部封裝程式回應與外部前端回應的標頭不同,這可能就是錯誤的來源。如果是 content-type 以外的標頭不同,請對照這份說明文件回報錯誤,以利更新規定清單。
  • 確認您執行的是最新版的 AMP Packager。
  • 如果您已排除以上所有可能原因,可能是 AMP Packager 發生錯誤,此時請回報錯誤

為問題排定優先順序並進行修正

  1. 在 AMP 摘要網頁上將警告過濾掉,先專心處理錯誤。根據預設,問題的排序依據是嚴重性、驗證狀態和受影響的網頁數;建議您根據預設的順序解決錯誤。請先解決由常見因素導致的錯誤 (例如不良範本),然後再修正每個網頁特有的問題。
  2. 瞭解錯誤總數之所以會增加,是否大多是因為特定某項錯誤數量增加:在表格中尋找是否有任何單一問題數量突然變多。
  3. 參閱下方資訊,瞭解如何為突然增加的錯誤偵錯,以及如何解決 AMP 網頁缺漏問題。
  4. 在表格中點選任一資料列,查看錯誤詳細資料頁面:
    1. 詳細資料頁面會提供受影響網址的示例。由於系統最多只能顯示 1,000 列資料,這份清單不一定會列出所有網址,而且也可能不會包含十分近期才發現的錯誤個案。
    2. 如有任何語法錯誤,請按一下 [瞭解詳情],以取得正確語法的正式說明文件。
    3. 按一下檢查圖示,為受影響的網頁執行有效性測試;這項測試不但能精確找出所有錯誤 (不僅是最近的問題),還會在程式碼瀏覽器中醒目顯示錯誤,並提供詳細資訊。畫面上可能會列出實際網頁中已修正的錯誤,這是因為系統尚未進行重新檢索;如果發生這種情形,請在修正該問題的所有個案後要求進行驗證。
  5. 將您網站上該項問題的所有個案都修正完畢後,請進行測試,並確認您實際網頁上的問題皆已修正。
  6. 返回問題詳細資料頁面,然後按一下 [驗證修正後的項目] 按鈕,開始進行驗證程序。這項程序不會立即生效,如要進一步瞭解驗證程序,請參閱「關於驗證」一節。
  7. 繼續修正其他錯誤。
  8. 將所有錯誤都修正完畢後,請移除警告的篩選器,決定是否要修正警告。有些警告和選用結構化資料標記的缺漏有關,這類標記能為具有相關內容的網頁啟用新的搜尋功能。

共用報表

你可以將涵蓋範圍報告或強化報告當中所列問題的詳細資料與他人共用,只要按一下頁面上的 [共用] 按鈕 即可。這個連結只會將目前問題詳細資料頁面 (以及這個問題的所有驗證記錄網頁) 的存取權授予知道連結的使用者,而不會授予其他資源網頁的存取權,也不會讓共用對象對你的資源或帳戶執行任何動作。如要撤銷連結,你隨時可以停用這個網頁的共用設定。

匯出報表資料

許多報表上都有 [匯出] 按鈕 ,可讓使用者匯出報表資料 (包括圖表和表格資料)。報表中顯示為 ~ 或 - (無資料/非數字) 的值,在下載的資料中一律為零。

錯誤網頁數量突然增加

確認錯誤網頁數量之所以會增加,是否因為部分網頁的錯誤嚴重性變換而導致:

  1. 如果發現錯誤網頁數量增加的情況,請查看其他狀態 (錯誤或有效) 的網頁數量是否相對下降。
  2. 如果發現的確有相對下降的情況,請確認是否是同樣的網址。
  3. 如果網址發生狀態變換,請檢查您進行的哪些變更可能導致這種情形。

錯誤網頁數量增加最常見的原因,是網站中多個網頁使用的範本有了新的錯誤。

排解 AMP 網頁缺漏問題

如果報告中列出的 AMP 網頁數 (有效 + 警告 + 錯誤) 比您網站上實際擁有的 AMP 網頁數少,請根據下列可能原因執行相關操作:

  • 確認您的標準非 AMP 網頁是否正確連結至 AMP 網頁。
  • 確認您的 AMP 或標準網頁並未受到 robots.txt 檔案封鎖或使用「noindex」中繼標記,或者受到驗證/登入機制的保護。
  • 在 Google 搜尋標準網頁的網址,檢查您的 AMP 和標準網頁是否已在索引中。如果搜尋結果未列出這些網頁,即代表未編入索引
    • 如果搜尋結果列出了標準網頁,請確認標準網頁已正確連結至 AMP 網頁。
    • 如果搜尋結果未列出標準網頁,請提交該網頁以建立索引
  • 是否有其他網頁連結到您的 AMP/標準網頁?Sitemap 中是否列出了這些網頁?如果您只要為少量 AMP 網頁建立索引,請針對標準網頁使用網址檢查工具;如有大量 AMP 網頁,則需使用 Sitemap (您僅需在 Sitemap 中列出標準網頁)。您可以考慮使用 Sitemap 報告提交 Sitemap。
  • Google 可能需要幾天的時間,才能找到並檢索缺漏的網頁,時間長短須視您向 Google 通報新網頁的方式而定。
  • 這份報告可能不會包含索引涵蓋範圍報表列出的部分有效 AMP 網頁。這是因為索引涵蓋範圍報表必須提供較全面的資訊,才能協助您對該報表中的索引問題進行偵錯。另一方面,為了方便您對網站上的特定 AMP 問題進行偵錯,AMP 狀態報告會列出關聯性較高的網頁並提供更詳盡的資訊,因此整體網頁數量可能較少。如要確認 AMP 網頁是否已編入索引,請透過網址檢查工具瞭解確切情況。

瞭解什麼是警告網頁

如果您的 AMP 網頁顯示警告,系統仍會為這些網頁建立索引,也會將這些網頁顯示在 Google 搜尋結果中,但可能無法呈現所有 AMP 功能 (例如顯示在焦點新聞輪轉介面中)。換句話說,這些網頁可能只會顯示為普通的藍色連結搜尋結果。

關於驗證

修正您網站上特定問題的所有例項後,您可以要求 Google 驗證您所做的變更。如果所有已知個案均已不存在,我們就會在狀態表格中將問題標示為已修正,並且排到表格最末端。Search Console 會追蹤整體問題的驗證狀態,以及各個問題個案的狀態。當所有問題個案均消失時,我們就會將問題視為已修正 (實際記錄的狀態請見問題驗證狀態例項驗證狀態)。

進一步瞭解問題生命週期...

問題的生命週期會從我們在您網站上首次偵測到該問題的個案時起算,延續到您網站上最後一個個案標示為已修正後的 90 天為止。如果該問題在這 90 天內沒有再次出現,就會從報告紀錄中移除。

問題的首次偵測日期是指在問題的生命週期中,我們第一次偵測到該問題當天的日期,這個日期不會變更。因此:

  • 如果問題的所有個案均已修正,但 15 天後出現新個案,我們會將問題狀態標示為開放,且「首次偵測到」的日期將維持不變。
  • 如果同一個問題在最後一個個案修正 91 天之後出現,由於先前的問題已結案,因此會記錄為新問題,首次偵測到的日期則是「今天」。

基本驗證流程

針對特定問題點選 [驗證修正後的項目] 後,驗證程序大致如以下所述。這項程序需要幾天才能完成,您將收到進度通知電子郵件。

  1. 當您點選 [驗證修正後的項目] 後,Search Console 會立即檢查一些網頁。
    • 如果仍有網頁包含目前的例項,驗證程序就會結束,驗證狀態將維持不變。
    • 如果取樣網頁不含目前的錯誤,系統會繼續進行驗證,程序狀態為「已開始」。如果在驗證過程中找到其他不相關的問題,系統會將這些問題計入其他問題類型,並繼續進行驗證。
  2. Search Console 會檢驗受到這個問題影響的已知網址清單。我們只會逐一重新檢索含已知問題個案的網址,而不會重新檢索整個網站。Search Console 會在驗證記錄中記載所有檢查過的網址,您可以透過問題詳細資料頁面查看。
  3. 網址經過檢查後:
    1. 如果找不到問題,例項驗證狀態將變更為「通過」。如果這是開始進行驗證後所檢查的第一個例項,問題驗證狀態將變更為「沒有問題」。
    2. 如果網址已無法存取,個案驗證狀態將變更為「其他」(非錯誤狀態)。
    3. 如果個案仍存在,個案驗證狀態將變更為「失敗」。如果這是由一般檢索程序找到的新網頁,系統會將其視為這個現有問題的其他例項。
  4. 當所有包含錯誤和警告的網址都經過檢查,且錯誤數為 0 時,問題狀態將變更為「通過」。重要事項:即使受影響的網頁數降為 0,且問題狀態變更為「通過」,系統仍會顯示原始的嚴重性標籤 (「錯誤」或「警告」)。

即使未點選 [開始驗證],Google 仍可偵測到問題個案已修正。如果 Google 在執行一般檢索作業期間偵測到問題的所有個案均已修正,則會將報告中的問題狀態變更為「不適用」。

我們何時會將特定網址或項目的問題視為「已修正」?

滿足下列「其中一項」條件時,我們就會將特定網址或項目的問題標示為已修正:

  • 網址經過檢索後,系統在網頁上已找不到該問題。如果是 AMP 標記錯誤,這可能表示您修正了相關標記,或是相關標記已移除 (如果是非必要的標記)。在驗證程序期間,系統會將狀態變更為「通過」。
  • 如果 Google 因故無法存取特定網頁 (網頁遭到移除、標示了 noindex、要求驗證等等),則會將該網址的問題視為已修正。在驗證程序期間,這種情況屬於「其他」驗證狀態。

重新驗證

驗證失敗後,如果您點選 [重新驗證],系統會重新開始針對所有驗證失敗的個案進行驗證 (同時也會驗證透過一般檢索作業找到的所有新個案)。

建議您在驗證程序結束後在提出另一項驗證要求,即使您在目前的程序期間修正了一些問題亦然。

當您點選 [重新驗證] 時,我們不會重新檢查已通過驗證 (標示為「通過」) 或已無法存取 (標示為「其他」) 的個案,這些個案會從紀錄中移除。

驗證紀錄

如要查看驗證要求的進度,您可以點選問題詳細資料頁面中的驗證詳細資料連結。

在 AMP 報告和索引狀態報告中,系統會依網址將驗證記錄頁面所含的項目分組。在行動裝置可用性與複合式搜尋結果報告中,系統則會同時以網址和結構化資料項目 (由項目的 Name 值判定) 為依據,將項目分組。驗證狀態適用於您在查看的特定問題。您可以將頁面上的其中一個問題標示為「通過」,而其他問題則標示為「失敗」、「待處理」或「其他」。

問題驗證狀態

特定問題可能伴隨的驗證狀態如下:

  • 尚未開始:有一或多個網頁包含這個問題的例項,而您尚未要求驗證。後續步驟:
    1. 點閱問題,瞭解相關錯誤的詳情。透過 AMP 測試檢查個別網頁,確認實際網頁所含的錯誤示例 (如果 AMP 測試未顯示網頁上的錯誤,這是因為您在 Google 找到錯誤並產生此問題報告後修正了實際網頁上的錯誤)。
    2. 點選詳細資料頁面中的 [瞭解詳情],進一步瞭解問題違反的規則。
    3. 點選表格中的示例網址列,進一步瞭解該特定錯誤。
    4. 修正網頁所含問題,然後點選 [修正驗證後的項目],要求 Google 重新檢索您的網頁。Google 會通知您驗證進度。驗證程序需時幾天至兩週不等,請耐心等候。
  • 已開始:您已要求驗證,而我們目前還沒找到其他問題例項。後續步驟:Google 會繼續進行驗證,同時透過通知給您進一步的指示 (如有需要)。
  • 沒有問題:已開始進行驗證,且目前檢查過的所有問題例項均已修正。後續步驟:您無須採取行動,但 Google 會繼續進行驗證,同時透過通知給您進一步的指示。
  • 通過:問題的所有已知例項均已不存在 (或是受影響的網址已無法存取)。點選過 [修正驗證後的項目] 才有可能變成這個狀態 (如果個案是在您未要求驗證的情況下消失,狀態會變更為「不適用」)。後續步驟:您無須採取其他行動。
  • 不適用:雖然您未要求驗證,但 Google 發現所有網址均已修正該問題。後續步驟:您無須採取其他行動。
  • 失敗:我們在您點選 [驗證] 後發現仍有特定比例的網頁包含此問題。後續步驟:修正問題並重新進行驗證。

例項驗證狀態

您提出驗證要求後,系統會為特定問題的每個例項指派下列其中一種驗證狀態:

  • 待驗證:已排入驗證佇列。Google 上次檢索時這個問題例項仍存在。
  • 通過:(部分報表「沒有」這項狀態) 經 Google 檢查後問題例項已不存在。您必須明確對此問題例項點選過 [驗證],該例項才可能變成這個狀態。
  • 失敗:經 Google 檢查後問題個案仍存在。您必須明確對此問題例項點選過 [驗證],該例項才可能變成這個狀態。
  • 其他:(部分報表「沒有」這項狀態) Google 無法存取代管該例項的網址;如果是結構化資料,則表示在網頁上找不到該項目。這種情況等同於「通過」

請注意,同一個網址上不同問題的狀態可能不同;舉例來說,如果單一網頁同時含有 X 問題和 Y 問題,X 問題的驗證狀態可能是「通過」,而位於同一個網頁上的 Y 問題則可能處於「待處理」狀態。

 

已知問題

以下是 Search Console 中的已知問題,您不必向我們回報,但如果您發現了其他問題,或對任何功能有意見,歡迎透過導覽列中內建的「意見回饋」機制告訴我們。

  • 有些問題的名稱太長,不易理解。
  • 系統將問題加入圖表以及加入表格的時間點之間可能有差距。
  • 如果您網站的問題數量眾多 (不論是否為現有個案),報告只會依重要性列出前 200 個問題。
這對您有幫助嗎?
我們應如何改進呢?