真實目的地 – 揭開 Google Search Console 覆蓋報告中用於重定向的令人困惑但通常準確的真實目的地網址的神秘面紗

如果您在 Google 將重定向報告為其他類別時感到困惑，例如“被 robots.txt 阻止”、“軟 404s”、“noindexed”、“404s”等，則可能是 Google 默默地跟踪重定向並報告而是真正的目標網址。 我的帖子詳細介紹了這種情況，並提供了這種情況在野外發生的例子。

在從 SEO 的角度對網站進行大量分析時，您無疑會發現自己深入 Google Search Console (GSC) 報告。 GSC 包含直接來自 Google 的大量數據，可以幫助網站所有者和 SEO 獲得關鍵見解。 也就是說，了解 GSC 報告所涉及的細微差別以及 Google 如何確定其在這些報告中提供的信息非常重要。 在採取行動改進 SEO 時，清楚地了解數據顯示的內容很重要。

在 GSC 的索引覆蓋率報告（和 URL 檢查工具）中，沒有比用於重定向的可怕的真實目標 URL 更好的 GSC 數據混淆示例了。 我從客戶那裡收到了很多關於這個的問題，所以我決定寫這篇文章，這樣我就可以在這裡指出人們，而不是一次又一次地解釋它。

所以，加入我的 GSC 冒險之旅，我們將揭開真正目的地 url 的秘密。 你們中的一些人可能已經知道這一點，但我知道有些人不知道。 對於那些不這樣做的人，這一切很快就會變得有意義。 您可能對它的工作方式不滿意，但至少您會理解為什麼在 GSC 中以某些方式（以及通過 URL 檢查工具）對 url 進行分類。

GSC 中可怕的真實目標 URL 情況是什麼？
當在 GSC 中查看被重定向的 url 的索引狀態時，Google 會報告真實的目標 url （即使該 url 在您自己的站點之外）。 例如，如果您將一個 url 重定向到另一個 url，並且該 url 由於某種原因不可索引，則 GSC 將默默地跟踪重定向並報告最終目的地的狀態。 對於不知道正在發生這種情況的網站所有者和 SEO 來說，這可能會讓人非常困惑。

是的，這意味著您可以看到 url 顯示為“被 robots.txt 阻止”、“noindexed”、“soft 404”、“404”等（當您檢查的 url 實際上是重定向時）。 可以想像，當許多網站所有者知道 100% 的 URL 正在重定向時，當他們看到“被 robots.txt 阻止”時，他們會感到困惑。

Google 的 John Mueller 曾多次被問及這個問題，他回答了我上面解釋的內容（並且承認這可能有點令人困惑）。 此外，Barry 根據 John 的評論寫了一篇文章，介紹了 URL 檢查工具是如何發生這種情況的。 儘管這已被記錄在案，但我發現對於許多網站所有者和 SEO 來說，這仍然是一個非常令人困惑的情況（這就是我寫這篇文章的原因）。

這是我的一條推文，其中包含指向 John 的鏈接，解釋了 Google 如何默默地跟踪重定向（以及它如何在 GSC 中顯示）：

既然您知道這種情況正在發生，您可能想知道這在 GSC 中實際上是什麼樣子。 接下來，我將通過在野外發生這種情況的示例來介紹這一點。

Google 靜默跟踪重定向並在 GSC 中報告真實目標 URL 狀態的示例：
下面，我將提供示例，其中包含 Google 報告真實目標網址與重定向的屏幕截圖。 同樣，這是由於某種原因最終目標 url 不可索引的時候。

被 robots.txt 阻止：
該 url 在站點外部被重定向到一個被 robots.txt 阻止的 url。 Google 將重定向 url 報告為“被 robots.txt 阻止”，因為最終目的地實際上是不允許的。

被 robots.txt 阻止的一個轉折點：
此網址首先重定向到被 robots.txt 阻止的跟踪網址。 最終目的地未被阻止，但由於不允許，Google 無法按照第一個重定向找到最終目的地網址。 它只知道鏈中的第一個 url 被阻止並在 GSC 中報告。 在下面，您可以看到第二步顯示該 url 實際上被 robots.txt 阻止（這就是 GSC 中報告的內容）。

軟404：
url 重定向到軟 404 頁面（產品不可用）。 Google 報告重定向 url 是軟 404（因為真正的目標 url 被視為軟 404）。

這是 url 重定向到的頁面（產品“當前不可用”）。 因此軟 404：

無索引：
是的，你猜對了。 url 重定向到沒有索引的頁面。 Google 在覆蓋率報告中將重定向的 url 報告為 noindexed：

已爬網，未編入索引：
乍一看，您可能會認為重定向被報告為“已抓取，未編入索引”。 不對！ 它是未被 Google 索引的最終目標網址。 谷歌正在報告真實目標網址的“已抓取，未編入索引”。

最終的目標 url 確實沒有被索引：

404：
Google 如何將重定向視為 404？ 它沒有。 這是 404 的真正目標 URL，這就是 GSC 中報告的內容。

404與域名更改：
這只是 404 情況的一種變體，用於解釋更改域名時它是如何工作的。 舊域上的 url 重定向到新域名上的 url，但 url 從未遷移（它 404s）。 所以穀歌報告重定向 url 是 404。

抱歉，重定向更加混亂：
當 url 重定向到使用 200 標頭響應代碼解析的頁面並被索引時，URL 檢查工具會準確報告重定向（並說初始 url 是重定向而不是索引），但 Google 將規範顯示為真正的目標網址（重定向指向的位置）。 談論令人困惑的事情，尤其是基於我上面解釋的所有其他示例，其中重定向 url 被報告為與重定向不同的東西……

GSC 中一個可能的解決方案來消除混亂：
那麼，這怎麼能更直觀呢？ 我認為，如果 GSC 確實提供了一條消息，表明它正在報告真實的目標網址，它可以消除網站所有者和 SEO 的困惑。 下面，我模擬了 GSC 中的樣子。 如果 Daniel Waisberg 正在閱讀（我希望你正在閱讀），請添加此內容！

摘要：清除重定向和目標 URL 報告的混淆。
我希望這篇文章能幫助您了解 Google 如何默默地跟踪重定向並報告 GSC 中的真實目標網址。 我知道對於許多網站所有者和 SEO 來說，這是一個令人困惑的話題，我相信它已經導致了許多令人頭疼的時刻。 請記住，截至目前，當 url 重定向時，GSC 會報告真實的目標 url。 因此，當您在 GSC 的覆蓋報告中發現其他類別的重定向時（或使用 url 檢查工具時），請不要感到驚訝。 誰知道呢，也許 GSC 產品團隊會實施我在上面模擬的那個消息……

GG