[ad_1]
如果您沒有使用Google Search Console索引覆蓋率報告，就不能稱自己為技術SEO。
這是了解以下內容的寶貴工具：
- 哪些網址已被Google抓取並編入索引，哪些沒有。
- 而且，更重要的是，為什麼搜索引擎對URL做出了這樣的選擇。
該報告似乎比較容易遵循其交通信號燈配色方案。
-
紅色（錯誤）：停止！頁面未編製索引。
-
黃色（有效並帶有警告）：如果您有空餘時間，請停下，否則，踩油門繼續前進！頁面可以被索引。
-
綠色（有效）：一切都很好。頁面已建立索引。
問題是，有一個很大的灰色區域（已排除）。
而且當您仔細閱讀細節時，道路規則似乎是用外語編寫的。谷歌
因此，今天，我們將把「索引覆蓋率報告」中的狀態類型轉換為SEO操作項目，您應該採取這些措施來改善索引編製和提高自然績效。
這裡是特定違規行為嗎？隨意使用快速鏈接：
- 已發現–當前未建立索引
- 已檢索-目前未編入索引
- 沒有用戶選擇的規範重複
- 重複提交的網址未選擇為規範網址
- 重複，Google選擇了與用戶不同的規範
- 找不到提交的URL（404）
- 重定向錯誤
- 伺服器錯誤（5xx）
- 抓取異常
- 已被robots.txt阻止，但已被索引
需要進一步考慮：根據您的SEO策略，這些操作可能會或可能不需要採取措施。
- 已編製索引，未在站點地圖中提交
- 被robots.txt阻止
- 提交的網址被robots.txt阻止
- 提交的網址標記為「 noindex」
- 提交的URL返回未經授權的請求（401）
- 提交的網址存在抓取問題
- 提交的網址似乎是軟404
- 軟404
索引覆蓋率報告中的SEO影響問題
不要只專註於糾正錯誤。通常，較大的SEO勝利實際上被掩埋在排除的灰色區域中。
以下是對SEO真正重要的「索引覆蓋率」報告問題，並按優先順序順序列出，因此您知道首先要解決的問題。
發現-當前未索引
原因：該URL通常是通過鏈接或XML網站地圖被Google知道的，並且位於抓取隊列中，但是Googlebot尚未能夠對其進行抓取。這表明抓取預算問題。
解決方法：如果只有幾個頁面，請通過在Google Search Console中提交網址來手動觸發抓取。
如果數量很多，請花時間對網站架構（包括URL結構，網站分類法和內部鏈接）進行長期修復，以從源頭上解決爬網預算問題。
已檢索-目前未編入索引
原因：Googlebot抓取了URL，發現不值得包含在索引中的內容。這最常見的原因是質量問題，例如內容稀疏，內容過時，門頁或用戶生成的垃圾郵件。如果內容值得，但沒有被編入索引，則很可能會因渲染而被絆倒。
修復方法：查看頁面內容。
如果您了解為什麼Googlebot認為網頁內容的價值不足以建立索引，請問自己第二個問題。該頁面需要存在於我的網站上嗎？
如果答案為否，則URL為301或410。如果是，請添加一個noindex標記，直到可以解決內容問題為止。或者，如果它是基於參數的URL，則可以防止使用 最佳實踐參數處理。
如果內容看起來質量可以接受，請檢查沒有JavaScript的呈現方式。 Google能夠對JavaScript生成的內容建立索引，但是它比HTML更為複雜，因為每當涉及JavaScript時都會產生兩次索引。
第一波基於來自伺服器的初始HTML為頁面編製索引。這是您右鍵單擊並查看頁面源代碼時看到的內容。
第二個索引基於DOM，該DOM同時包含HTML和客戶端提供的JavaScript。右鍵單擊並檢查時，將看到此內容。
挑戰在於將第二次索引編製工作推遲到Google具有可用的呈現資源之前。這意味著索引依賴JavaScript的內容要比僅HTML內容花費更長的時間。從抓取到幾天到幾周的任何時間。
為了避免索引編製的延遲，請使用伺服器端呈現，以便所有必需內容都出現在初始HTML中。這應該包括您的英雄SEO元素，例如頁面標題，標題，規範，結構化數據，當然還包括您的主要內容和鏈接。
沒有用戶選擇的規範就重複
原因：Google將該頁面視為重複的內容，但沒有用明確的規範標記。 Google決定此頁面不應該規範，因此已將其從索引中排除。
修復方法：使用rel = canonical鏈接，為網站上的每個可抓取網址明確標記正確的規範。通過檢查Google Search Console中的URL，您可以了解Google選擇了哪個頁面作為規範。
未選擇重複的，提交的URL作為規範
原因：與上述相同，除了在這種情況下，您明確要求將此URL編入索引，例如，通過在XML網站地圖中提交該URL。
修復方法：使用rel = canonical鏈接，為網站上的每個可抓取網址明確標記正確的規範，並確保XML站點地圖中僅包含規範頁面。
重複的Google選擇了與用戶不同的規範
原因：頁面上有rel = canonical鏈接，但是Google不贊成這一建議，並選擇了其他URL進行索引作為規範。
修復方法：檢查網址以查看Google選擇的規範網址。如果您同意Google的意見，請更改rel = canonical鏈接。否則，請研究您的網站架構，以減少重複內容的數量，並向您希望成為規範的頁面發送更強的排名信號。
找不到提交的URL（404）
原因：您提交的URL（可能是通過XML網站地圖）不存在。
如何解決：創建URL或將其從XML網站地圖中刪除。您可以按照以下說明系統地避免此錯誤 動態XML網站地圖的最佳做法。
重定向錯誤
原因：Googlebot重定向出現問題。這最常見是由重定向鏈導致的，這些重定向鏈的URL長度超過五個或更多，重定向循環，空URL或URL長度過長。
如何修復它：使用調試工具（例如Lighthouse）或狀態代碼工具（例如httpstatus.io）來了解破壞重定向的原因以及如何解決重定向。
確保301重定向始終始終直接指向最終目的地，即使這意味著要編輯舊的重定向。
伺服器錯誤（5xx）
原因：伺服器在無法載入頁面時返回500 HTTP響應代碼（又稱內部伺服器錯誤）。這可能是由伺服器問題引起的，但通常是由短暫的伺服器斷開連接（阻止Googlebot抓取頁面）引起的。
解決方法：如果這是「一次入月」，請不要緊張。一段時間後，錯誤將自行消失。如果頁面很重要，則可以通過在URL檢查中請求建立索引來將Googlebot調回URL。如果錯誤再次發生，請與系統工程師/技術負責人/託管公司聯繫以改善伺服器基礎結構。
抓取異常
原因：某些原因阻止了URL的爬網，但是即使Google也不知道其確切含義。
修復方法：使用「 URL檢查」工具獲取頁面以查看是否返回了4xx或5xx級別的響應代碼。如果沒有任何線索，請將URL發送給您的開發團隊。
索引，儘管被Robots.Txt阻止
原因：將robots.txt視為在解鎖門上的「禁止進入」標誌的數字等效形式。儘管Googlebot確實遵守這些說明，但它遵循的是法律條文，而不是精神。
因此，您可能有robots.txt中明確禁止的頁面顯示在搜索結果中。因為如果被阻止的頁面具有其他強有力的排名信號，例如鏈接，則Google可能會認為它與索引有關。
儘管尚未抓取頁面。但是由於該URL的內容對於Google來說是未知的，因此搜索結果看起來像這樣。
解決方法：要明確阻止網頁出現在SERP中，請不要使用robots.txt。您需要使用noindex標記或禁止使用auth匿名訪問頁面。
知道帶有noindex標記的URL也會被較不頻繁地爬網，並且如果存在時間很長，它最終也會導致Google也跟蹤頁面的鏈接，這意味著它們不會將這些鏈接添加到爬網隊列和排名信號中不會傳遞到鏈接頁面。
需要進一步思考
許多Google Search Console索引覆蓋率報告問題是由指令衝突引起的。
不是一個人是對的，另一個是錯誤的。您只需要明確目標，並確保所有站點信號都支持該目標。
已編製索引，未在站點地圖中提交
原因：該URL可能是通過鏈接由Google發現的，並已建立索引。但這不是在XML網站地圖中提交的。
措施：如果這些URL與SEO相關，則將它們添加到XML網站地圖中。這將確保快速索引新內容或更新現有內容。
否則，請考慮是否要為URL編製索引。 URL並非僅根據自身優點進行排名。 Google索引的每個頁面都會影響質量演算法評估域名信譽的方式。
將網頁編入索引，但未在站點地圖中提交網頁，這通常表明該網站正在遭受 指數膨脹 –過多的低價值頁面已納入索引。
這通常是由自動生成的頁面引起的，例如過濾器組合，歸檔頁面，標籤頁面，用戶配置文件，分頁或惡意參數。索引膨脹會損害域對所有URL進行排名的能力。
被Robots.Txt阻止
原因：Googlebot無法抓取該網址，因為該網址已被robots.txt阻止。但這並不意味著該頁面不會被Google編入索引。當您開始在「索引覆蓋率報告」中看到「已被robots.txt阻止但已被編入索引」警告時。
怎麼辦：要確保網頁未被Google編入索引，請刪除robots.txt塊並使用noindex指令。
提交的網址已被Robots.Txt阻止
原因：您的robots.txt文件也阻止了您可能通過XML網站地圖提交的URL。
怎麼辦：如果不希望對XML站點地圖中的URL進行爬網和編製索引，或者從robots.txt文件中進行阻止規則（如果這樣做）。如果您使用的主機服務不允許您修改此文件，請更改網路主機。
提交的網址標記為「 Noindex」
原因：您可能通過XML網站地圖提交的URL通過漫遊器元標記或在HTTP標頭X-Robots標記中被標記為noindex。
怎麼辦：如果不希望對XML站點地圖中的URL進行爬網和建立索引，則可以將其刪除；或者，如果您希望這樣做，則可以刪除noindex指令。
提交的URL返回未經授權的請求（401）
原因：Google無權檢索您提交的URL，例如受密碼保護的頁面。
怎麼辦：如果沒有理由保護內容不被索引，請刪除授權要求。否則，從XML網站地圖中刪除URL。
提交的網址存在抓取問題
原因：某些原因導致抓取問題，但即使Google也無法為其命名。
怎麼辦：嘗試使用「 URL檢查」工具調試頁面。檢查頁面載入時間，阻塞的資源以及是否有不必要的JavaScript代碼。
如果仍然無法獲得有用的結果，請採用老式的方式在移動設備上載入URL，然後查看網頁和代碼中發生的情況。
提交的URL似乎是軟404
原因：Google認為您可能通過XML站點地圖提交的URL是軟404，即伺服器響應200成功代碼，但頁面：
- 不存在。
- 幾乎沒有內容（又稱瘦內容），例如空的類別頁面。
- 重定向到不相關的目標URL，例如主頁。
怎麼辦：如果該頁面確實不存在並且被有意刪除，請返回410以加快索引編製速度。確保向用戶顯示自定義的「未找到」頁面。除非另一個URL上有類似的內容，否則在這種情況下，請執行301重定向以傳遞排名信號。
如果該頁面似乎包含很多內容，請檢查Google是否可以呈現所有這些內容。如果確實存在內容薄弱的問題，或者頁面沒有理由存在，則為410或301，如果沒有，則將其從XML網站地圖中刪除，以免引起Google的注意，添加noindex標記，然後在更長的頁面上工作長期解決方案以增加有價值的內容。
如果存在到非相關頁面的重定向，則將其更改為相關頁面，或者如果不可能，則將其更改為410。
軟404
原因：與上面相同，但是您沒有明確要求將頁面編入索引。
怎麼做：類似於以上內容，請向Google顯示更多內容（適當時顯示301或410）。
指數覆蓋率報告中的自然狀態
目標是不要為您站點的每個URL都建立索引，也就是有效，儘管該數目應隨著站點的增長而穩步上升。
目標是獲取與SEO相關頁面的規範版本的索引。
將許多頁面標記為「索引覆蓋率」報告中排除的頁面不僅對SEO十分自然而且有益。
這說明您很清楚，Google會根據所有編入索引的網頁來判斷您的域名信譽，並已採取適當的措施來排除您網站上必須存在的網頁，但這些網頁不需要納入Google對您的內容的考慮之列。
提交並建立索引
原因：您通過XML站點地圖，API或在Google Search Console中手動提交了頁面，並且Google已對其進行索引。
無需修復：除非您不希望這些網址包含在索引中。
具有正確規範標籤的備用頁面
原因：Google成功處理了rel = canonical標籤。
無需修復：該頁面已正確指示其規範。沒有其他事情可做。
被「 Noindex」標記排除
原因：Google對該網頁進行了爬網，並使用了noindex標記。
無需修復：除非您確實希望這些URL位於索引中，否則請刪除noindex指令。
帶有重定向的頁面
原因：您的301或302重定向已被Google成功抓取。目標URL已添加到爬網隊列，並且原始URL已從索引中刪除。
Google抓取目標網址並確認目標網址具有相似的內容後，將會傳遞沒有稀釋度的排名信號。
無需修復：隨著重定向的處理，此排除項會隨著時間的推移自然下降。
找不到（404）
原因：Google通過XML網站地圖以外的方法（例如，另一個網站的鏈接）發現了該URL。對其進行爬網時，頁面返回了404狀態代碼。因此，隨著時間的推移，Googlebot抓取網址的頻率會降低。
無需修復：如果由於故意將其刪除而導致該頁面確實不存在，則返回404沒什麼問題。對於收集404代碼，Google不會受到任何懲罰。那是個神話。
但這並不是說它們始終是最佳做法。如果URL有任何排名信號，這些將丟失到404 void。因此，如果您有另一個內容相似的頁面，請考慮更改為301重定向。
被頁面刪除工具阻止
原因：URL刪除請求是在Google Search Console中提交的。
無需修復：刪除請求自然會在90天後過期。在此期間之後，Google可能會重新編製頁面索引。
總結一下
總體而言，預防勝於治療。經過深思熟慮的網站架構和機器人處理程序通常會生成清晰明了的Google Search Console索引覆蓋率報告。
但是，由於我們大多數人繼承別人的作品，而不是從頭開始，它是一種寶貴的工具，可以幫助您將注意力集中在最需要的地方。
請務必每月檢查一次報告，以監視Google在抓取您的網站並將其編入索引方面的進度，以及 記錄SEO變更的影響。
圖片積分
特色圖片：作者創作，2020年2月
作者截圖，2020年2月