SEO 辦公時間，2021 年 11 月 12 日

這是2021 年 11 月 12 日Google SEO Office Hours與John Mueller的最有趣問題和答案的摘要。

Google Search Console 中的無索引頁面

8:16 “ [某些頁面] 被錯誤地設置為 noindex。 這是在幾個月前修復的。 [...] 我們嘗試通過 Search Console [和] 重新提交站點地圖請求索引，但仍然沒有將這些頁面編入索引。 您對可能導致 Googlebot 不聽索引請求的原因有什麼想法，或者 Search Console 中是否存在與索引相關的任何已知問題？”

約翰：“我認為在這方面沒有任何已知問題，但有時我們在提交索引請求方面有點保守，這可能是你在那裡看到的部分內容。 [...] 一方面，如果我們看到一個頁面在較長時間內沒有索引，那麼我們通常會在抓取該頁面時放慢速度。 [...] 這也意味著當頁面變得可索引時，我們將再次開始抓取，所以本質上這是您需要做的一種推送。

另一件事是，由於 Search Console 報告的基本上是我們所知道的網站 URL，因此圖片看起來可能比實際情況更糟。 這可能是您可以查看的內容，例如，查看性能報告並過濾網站的該部分或那些 URL 模式，以查看 Search Console 中的高 noindex 頁面數量是否報告了以下頁面不是很重要，這些部分的重要頁面實際上已編入索引。”

John 還表示“[...] 站點地圖本質上是一個好的開始，但您可以做的另一件事是通過內部鏈接明確這些頁面對網站非常重要，以便我們更快地抓取它們。 這可以是您所說的臨時內部鏈接：在幾週內，我們會從主頁鏈接到各個產品。 […]本質上，當我們發現內部鏈接發生了顯著變化時，通常我們也會去仔細檢查這些頁面。 所以這可能是一種將事物再次推入索引的臨時方法。 使用內部鏈接，並不是說這些是網絡上的重要頁面，而是說與您的網站相關的重要頁面。 因此，如果您顯著更改內部鏈接，可能會發生網站的其他部分（可能只是勉強編入索引）在某個時候退出。 所以這就是為什麼我會在臨時級別上這樣做並說，我想將它們推回系統中，以便它們以正常速度重新抓取，然後我將更改內​​部鏈接，以便一切恢復正常。”

關於向頁腳添加鏈接，John 補充說：“我認為這也可以。 如果我們可以在網站上非常重要的頁面上找到它通常會更好，通常就像在您的主頁上，[...] 您說這對您很重要，因此，我們將仔細檢查該頁面。 ”

規範標籤和備用標籤

14:25 “我正在使用一個 WordPress 網站，並且我正在使用兩個插件。 [其中一個] 會自動將 rel="canonical" 鏈接添加到每個頁面。 […] [另一個是翻譯器插件]，它向 [to] 每個頁面添加一個 rel=“alternate” 鏈接。 它說的是否合乎邏輯：對於那個 URL，它是規範的，但它也是替代的？ 它在爬蟲的某個地方發生衝突嗎？”

約翰說：“不。 我的意思是我不知道這兩個插件到底是做什麼的。 從整體的角度來看，如果您的頁面上有一個 rel=canonical ，那麼您基本上就是在使用一個規範的說法：那裡提到的鏈接是我想要的首選 URL。 如果是同一個頁面，那就完美了，因為它讓我們確認該頁面是您想要編入索引的頁面。

rel="alternate" 基本上意味著該頁面也有其他版本。 因此，對於不同的語言，例如，如果您有一頁是英文的，一頁是法文的，那麼您將在這兩種語言版本之間擁有 rel=”alternate” 鏈接。 這並不是說該鏈接所在的頁面是備用頁面，而是就像這是兩個不同的版本，一個是英文的，一個是法文的。 它們都可以是規範的，因此具有這種組合通常很好。

需要注意的一個地方是規範不應該跨語言。 因此，在您的法語頁面上，您不應該將規範設置為英文版本，因為它們本質上是不同的頁面。 但是法語頁面可以是規範的，英文頁面可以是規範的，並且您在兩者之間有備用鏈接，這本質上是一個很好的集合。”

規範化或無索引標籤

16:49 “我們有一個網站，其中包含一個電子商務商店，其中包含許多產品變體，內容稀少或重複。 我列出了我們想要編入索引的所有 URL […]，但我們不想編入索引。 [...] 我不確定哪個更好：規範化還是無索引？”

John 說，“我認為對於另一個頁面我應該使用 noindex 還是 rel=”canonical”這個一般性問題可能沒有絕對的答案。 [...] 如果你為此苦苦掙扎，你不是唯一一個喜歡的人，哦，我應該使用哪一個？ 這通常也意味著這兩個選項都可以。 所以通常情況下，我會看到你真正強烈的偏好是什麼。 如果強烈的偏好是您真的不希望在搜索中顯示此內容，那麼我會使用 noindex。 如果您的偏好更多，我真的希望將所有內容組合在一個頁面中 [...]，那麼我會使用 rel=”canonical”。 最終效果是相似的，您正在查看的頁面很可能不會在搜索中顯示，但使用 noindex - 它肯定不會顯示，而使用 rel=“canonical” - 它更有可能不會顯示。 ”

約翰總結道：“你也可以兩者都做。 例如，如果外部鏈接指向此頁面，那麼將它們都放在此處有助於我們弄清楚，您不希望該頁面被編入索引，但您還指定了另一個，所以也許一些信號我們可以就往前走。”

移動優先索引和抓取

28:26 “[...] 我們相應地優化了我們的網站 [用於移動優先索引]。 至於配置，谷歌推薦兩種方式。 第一個是響應式網頁設計，第二個是動態服務。 因為第一種方式對我們來說通過我們的技術環境實現起來有點困難，所以我們使用第二種方式。 但我們仍然看到，如今，每天有超過 20 萬次爬入我們的移動域。 這是正常現象嗎？ [...] 我們有 m-dot 域，然後我們將其重定向到主域。”

約翰回答說：“有一些像那樣的爬行是正常的。 即使在重定向之後，我們的系統也需要很長時間才能完全停止對域的抓取，所以我不認為這是一個問題。 我們的系統有時對此類事情有很長的記憶，如果您將網站從一個域移動到另一個域，或者如果您使用子域進行這種移動更改，有時需要數年才能完全停止爬行。”

網絡技術與排名

36:00 “使用普通 HTML、CSS、JS 和另一種——PWA 製作的網站的排名是否有任何關係或影響？ [...] 我們的一個主要競爭對手最近採用了它，我們注意到他們的 SERP 排名有了巨大的飛躍。”

John 說：“這些是製作網站的本質不同的方法，您可以製作具有許多不同框架和格式的網站。 在大多數情況下，我們將這些視為普通的 HTML 頁面。 因此，如果它是基於 JavaScript 的網站，我們將對其進行渲染，然後像處理普通 HTML 頁面一樣對其進行處理。 如果一開始就已經是 HTML，我們可以這樣做。 [有] 不同的框架和 CMS 背後。 通常，我們基本上忽略了這一點，只是說，好吧，這是一個 HTML 頁面，我們可以處理它。

因此，您的一個競爭對手已經從一個框架轉移到另一個框架，並且在搜索方面有所改進，從我的角度來看，框架的變化不會對此負責。 但更確切地說，也許他們現在有了一個更新的網站，以及框架的變化。 也許較新的網站有不同的內部鏈接，不同的內部內容，[它] 明顯更快或更慢，用戶真的很喜歡它，或者他們在網站啟動時進行了營銷活動。 所有這些東西都在其中發揮作用，而且這些東西並不局限於你正在使用的框架。”

Google PageSpeed Insights 與 Lighthouse

37:39 “Google PageSpeed Insights 中的實驗室數據結果與我的 Chrome 瀏覽器中的 Lighthouse 結果相同嗎？ 他們使用相同的公式嗎？”

約翰說：“我不知道百分百，但他們的做法完全不同。 [...] 如果您使用在某個數據中心上運行的 PageSpeed Insights，該數據中心具有基本上模擬的設備，我們試圖在其中像普通計算機一樣工作，並且我們有一些限制使其速度變慢。 [...] 在 Lighthouse 中，它基本上可以在您的計算機上通過您的互聯網連接運行。 我認為Chrome 中的 Lighthouse 也有一些限制，它適用於使其看起來可能比您的計算機可能能夠做的慢一點，以確保它具有可比性。

但本質上，它們在完全不同的環境中運行，這就是為什麼你經常會在那裡看到不同的數字。 [...] 如果您使用其他在線運行的速度工具進行測試，您可能 [還] 看到不同的數字。 此外，我們在 Search Console 中看到的用於搜索排名的字段數據也可能是完全不同的數字，因為您的用戶平均可能擁有不同類型的設備或不同類型的互聯網連接。 因此，即使公式相同，這些系統周圍的整個環境也大不相同。”

谷歌發現

47:09 “我們注意到我們網站上的 Google Discover 存在一個大問題。 兩天之內，流量下降了百分之七十。 [...] 所以我們想知道我們是否做錯了什麼？ [...] 你能澄清一下到底發生了什麼，因為它是如此激烈的平局？ [...] 會不會是技術錯誤？”

John 說：“我不知道您的網站具體情況，但我收到很多人的報告，發現流量處於打開或關閉狀態，因為如果我們的算法確定我們的'目前不會在 Discover 中顯示該網站的太多內容，然後基本上所有的流量都會消失。 另一方面，如果我們確實在“發現”中展示了您網站上的某些內容，那麼您會突然再次獲得大量流量。

如果這是一個技術問題，那麼您也會在網絡搜索中看到它，並且您會看到出現抓取問題。 我沒有完全了解 Discover 中到底發生了什麼，但通常，我看到人們談論的問題是一方面是質量問題，可能是網站的質量不太好，以及關於我們為 Discover 制定的個人政策。 特別是，對於 Discover，我們有一些不同於網絡搜索的政策和建議，我認為這些政策在成人內容、點擊誘餌內容方面略有不同。 [...]我們在 Discover 的幫助中心頁面上都提到了這些。 我想很多網站都混合了所有這些東西，有時我懷疑我們的算法發現太多了，然後他們說，哦，我們現在必須小心這個網站。 因此，在不了解您的網站並且不知道 Discover 在那裡所獲取的具體內容的情況下，這就是我要去的方向。 […]

從我們的角度來看，Discover 是我們嘗試向人們展示信息流的地方，因此，我們往往沒有很多詳細信息來說明您需要提供哪些內容才能真正表現出色。 所以有時候看看其他人的想法是有意義的。”

響應時間

50:41 “對於一個新的新聞媒體網站來說，什麼是好的響應時間？”

根據 John 的說法，“響應時間影響我們計算服務器可以進行多少爬網的能力。 通常，從實際的角度來看，響應時間會限製或影響爬網需要多少並行連接。 因此，如果我們想從一個網站上抓取一千個 URL，那麼在一天中將其分散的響應時間可能會非常長。 然而，如果我們想從一個網站抓取一百萬個 URL，並且響應時間很長，那麼這意味著我們最終會與服務器建立大量並行連接。 我認為我們有一些限制，我們不想在服務器上引起問題，所以這就是響應時間與抓取速度直接相關的原因。

對於一個新聞網站來說，與其說是不是新聞，不如說是我們每天需要抓取多少個網址。 所以這就是我要看的角度。 可能在一個新聞網站上，我們一天爬一萬頁，那些重要的新聞文章都被覆蓋了。 可能我們每天必須抓取數百萬篇文章，因為我們總是需要刷新存檔 [...]，那麼顯然響應時間和抓取速度看起來會有所不同。”