SEO 辦公時間，2022 年 2 月 18 日

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

受產品評論更新影響的網站類型

4:03 “[…] 我的問題是關於產品評論更新[…]。 我想了解 Google 如何識別頁面或網站是否與產品評論相關。 […] 例如，有一個電子商務網站 […]，他們也有一個博客，可以在其中評論自己的產品。 他們確實寫了他們產品的優缺點，比較不同的產品。 […] 谷歌會說 […] 這也是產品評論，可以通過產品評論更新來分析嗎？ […]”

正如 John 解釋的那樣，“[…]我們對產品評論的建議 […] 將與任何類型的產品評論相關。 因此，我不一定會嘗試查看，Google 是否認為我的網站是產品評論網站 [...]。 相反，如果您認為這些良好做法適用於您的內容，那麼只需執行這些良好做法 [...]”。

索引 API 的使用

6:53 “[…] [Google 的文檔] 提到Indexing API應該用於職位發布或廣播事件等頁面。 我們是否可以針對不同類型的內容（例如一些新聞文章或博客內容）嘗試使用此 API？”

約翰回答說：“人們嘗試過。 但本質上，我們記錄的是我們使用 API 的目的。 如果您沒有屬於這些類別的內容，那麼 API 將無法幫助您”。

EAT 和 Google 的算法

10:54 “[...] EAT在 [質量評估指南]中被提及，但我想知道真正的算法是否也 [包括] EAT 因素，如作者的專業知識？”

約翰說：“我會假設已經做了一些間接的工作來嘗試做類似的事情。 […] 我們將其放入指南中，以便我們可以指導質量測試人員仔細檢查這些內容。 如果我們認為這很重要，那麼我會假設搜索質量方面的人們也在努力嘗試以更算法的方式理解這一點。

但我不會看到 [...] [會有] EAT 分數，而且你必須得到五分或類似的分數。 它更多的是試圖理解網絡上內容的上下文”。

未鏈接的品牌提及和用戶生成的內容

12:01 “[…] 我看到人們在談論未關聯的品牌提及 [s] […]。 你認為這對 [Google 的] 算法 […] 也很重要嗎？”

通過未鏈接的品牌提及，此人指的是其他網站提及您的品牌但不包含指向您網站的鏈接的情況。

約翰說：“[...] 我認為這有點棘手，因為我們並不真正知道上下文是什麼。 我不認為這對用戶來說是件壞事 […] 因為如果他們可以通過提及找到您的網站，那麼這總是一件好事。 但我不會假設有一些 [...] SEO 因素試圖找出有人在哪裡提到您的網站名稱”。

12:58 “[...] 用戶評論或評論呢？ 你認為這也是文章或產品的排名因素嗎？”

John 回應說：“[...] 通常，人們會用自己的話來描述該頁面，這為我們提供了有關如何在搜索結果中顯示該頁面的更多信息。 從這個角度來看，我認為評論在頁面上是一件好事。 顯然，找到一種以合理方式維護它們的方法有時很棘手，因為人們也會向這些評論發送垃圾郵件 […]。 如果你能找到一種方法來維護網頁上的評論，這會給你更多的背景信息，並幫助以不同方式搜索的人也能找到你的內容”。

Googlebot 和無限滾動

24:00 “[...] 你知道Googlebot 是否足夠先進，可以處理無限滾動，或者至少是內容不斷構建的東西嗎？”

約翰說：“有一點[…]。

當我們渲染一個頁面時會發生什麼，我們使用一個相當高的視口，就像你有一個很長的屏幕一樣，我們渲染頁面是為了看看頁面會在那裡顯示什麼。 通常，這會在您用來觸發無限滾動的任何 JavaScript 方法中觸發一定數量的無限滾動。 無論最終加載到那裡，這將是我們能夠索引的內容。

[...] 根據您實現無限滾動的方式，我們可能會在索引中有更長的頁面。 可能不是我們擁有適合該頁面的所有內容。 因為根據您觸發無限滾動的方式，您可能只是在加載下一頁。 然後我們可能會在一個無限滾動的頁面上加載兩個或三個這樣的頁面，但不是全部。 [...] 我建議使用[URL] 檢查工具對其進行測試，然後看看 Google 會獲得多少”。

在 Crawl Stats 報告中刷新和發現數據

33:32 “在 Search Console [ Crawl Stats ] 報告中，97% 的爬蟲請求是刷新，只有 3% 是發現。 如何優化這一點，讓 Google 發現更多頁面？”

John 回答說：“[...]對於 [...] 一個較老、更成熟的網站來說，進行大量刷新爬網是很正常的，因為我們會查看我們所知道的隨著時間的推移而增長的頁面數量。 並且進入的新頁面的數量往往相當穩定。 這是很常見的，特別是對於一個已經建立並且只是緩慢增長的網站，有這樣的平衡，大部分的爬取都是在刷新爬取上，而不是在發現爬取上。

我認為，如果您有一個網站 [...]，您會收到很多新文章，而舊內容很快就會變得無關緊要，這會有所不同。 然後我認為我們會傾向於更多地關注發現。 […] 如果你有一個類似電子商務網站的東西，你只是在緩慢地增加你擁有的內容的數量，並且大部分舊內容仍然有效，[…] 刷新爬取的數量 [is] 可能會高一點”。

減少對網站的抓取

35:09 “在過去的幾周里，我注意到抓取統計數據大幅下降，從每天 700 次下降到 50 次。 有沒有辦法從 Search Console 報告中了解導致這種下降的原因？ 可能是源頁面加載嗎？ 如何正確讀取抓取請求細分？”

John 詳細解釋了 Google 如何抓取網站以及影響抓取的因素： “[...] 我們所做的抓取量涉及到一些因素。

[...] 我們試圖弄清楚我們需要從網站抓取多少內容才能使搜索結果中的內容保持新鮮和有用。 這取決於了解您網站的質量，以及您網站上的情況如何變化。 我們稱之為抓取需求。

另一方面，我們從您的服務器、[...] 網站、 [...] 網絡基礎設施中看到的限制是我們可以在網站上抓取多少。 我們試圖平衡這兩者。

並且這些限制往往與兩個主要方面相關：[…] 對請求的總體響應時間

到網站，以及 [...] 我們在抓取過程中看到的 [...] 服務器錯誤的數量。 如果我們看到很多服務器錯誤，那麼我們將減慢爬網速度 [...]。 如果我們看到您的服務器變得越來越慢，那麼我們也會減慢爬行速度 [...]。

速度方面的困難在於我們有兩種 […] 不同的方式來看待速度。 有時，當您查看抓取速度時，這會讓人感到困惑。 特別是對於抓取速度，我們只看，我們可以多快從您的服務器請求 URL？

您可能遇到的速度的另一個方面是圍繞核心 Web Vitals的所有內容以及頁面在瀏覽器中加載的速度。 它在瀏覽器中的速度往往與我們在網站上獲取單個 URL 的速度沒有直接關係。 因為在瀏覽器中，您必須處理 JavaScript、拉入所有這些外部文件、渲染內容、重新計算頁面上所有元素的位置。 這與僅獲取該 URL 所需的時間不同。

[...] 如果您試圖診斷抓取速度的變化，那麼不要查看頁面呈現需要多長時間。 [...] 看看從服務器獲取該 URL 需要多長時間。

另一件事 […] 是 […]我們試圖了解網站的託管位置[…]。 如果我們認識到一個網站正在將主機從一台服務器更改為另一台服務器——可能是不同的主機提供商，[...] 移動到 CDN，或更改 CDN [...]——那麼我們的系統將自動回到某些安全率，我們知道我們不會造成任何問題，然後一步一步地再次增加。

每當您對網站的託管進行更大的更改時，我都會假設抓取速度會下降。 然後在接下來的幾週內，它將恢復到我們認為可以安全地在我們的網站上抓取的任何內容。 這可能是您在這裡看到的。

另一件事是，我們確定如何對網站和服務器進行分類的算法 [...] 也會不時更新。 [...] 即使您沒有對託管基礎設施進行任何更改，我們的算法也會嘗試找出 [that] 該網站託管在該服務器上，而該服務器經常超載。 我們在抓取本網站時應更加謹慎，以免造成任何問題。 隨著時間的推移，這種情況也會自動穩定下來，通常需要幾個星期 […]。

[...] 在 [Google] Search Console 中，您可以指定抓取率[...]，這有助於我們了解您的網站有特定的設置 [...]，我們會盡量考慮這一點。 爬行速率設置的困難在於它是一個最大值設置。 這並不是表示我們應該抓取那麼多，而是我們應該最多抓取您在此處指定的內容。 通常，該設置在您需要減少抓取量時更有用，而不是在您想要增加抓取量時。

[...] 您還可以做的一件事是，在 Search Console 的幫助中心，我們有一個鏈接可以報告 Googlebot 的問題。 如果您發現您網站的抓取超出了您的預期範圍，那麼您可以通過該鏈接報告 Googlebot 的問題 [...]”。

Google 如何識別網頁所針對的國家/地區

56:25 “[...] 至於地理定位，除了使用 hreflang 之外，谷歌如何確定您的目標 [國家] [with] 這個特定網站或特定子目錄？”

John 的回答是：“我們嘗試按照我們可以識別的清晰模式對 URL 進行分組 [...]，例如，按子域或子目錄。 如果你在一個路徑的較高位置的子目錄中有國家，那麼我們說起來就容易多了，這條路徑下的一切都是為了這個國家，這條路徑下的一切都是為了另一個國家。

您還可以在 Search Console [...] 中驗證各個路徑，這對我們來說更容易一些。 在實踐中，我沒有聽到很多人說這有很大的不同。

[…] 我會盡量清楚 […] 哪個國家與各個 URL 相關，並在 URL 中提供清晰的路徑。 我認為最後有人提交了一個關於使用國家作為 URL 參數的問題。 從理論上講，你可以做到這一點[...]。 對於我們的系統，識別哪些 URL 屬於哪個國家/地區變得更加困難 [...]。 如果您使用的是 hreflang，那麼這不是問題，因為您可以在每個 URL 的基礎上做到這一點”。

大量 URL 標記為已發現 - 當前未編入索引

58:25 “[...] 我們是一個巨大的電子商務網站，當我們檢查我們的抓取報告時，我們發現 [已發現 - 當前未編入索引部分] [...]中有大量 URL 。 這是否表明 [a] 問題 [on our site] [...]？”

約翰說：“我認為這取決於這些頁面是什麼以及您如何在您的網站中使用它們。 […] 我們在網絡上發現了各種各樣的 URL，其中許多 URL 不需要被抓取和編入索引，因為它們可能只是我們已經知道的 URL 的變體，或者 […] 一些隨機論壇或抓取工具腳本已從您的網站複製 URL 並以損壞的方式包含它們。 [...]有很多這樣的 URL 要么被抓取但未編入索引，要么被發現但未被抓取，這是很正常的，因為網絡上有很多不同的 URL 來源。

[...] 嘗試下載 [...] 其中的一個示例，以便您可以查看各個示例，並 [...] 對其中哪些 URL 是您關心的 URL 進行分類，哪些 [...] 是您可以忽略的。

[...] 您確實關心的那些，我會嘗試找出您可以做些什麼來更好地將這些與您的網站聯繫起來，例如內部鏈接。 因此，如果這些是未找到的單個產品或類別，請嘗試以系統的方式弄清楚您可以做什麼，以確保所有這些 URL 之間能夠更好地鏈接。 [...] 特別是對於較大的電子商務網站，它可能會變得很棘手，因為您不能一直單獨查看每個 URL。

但有時，你可以在你所說的地方做一些技巧：任何屬於第一級類別的東西，我都會從我的主頁鏈接到它。 而且我確保我的第一級類別最多 [...] 可能有 100 個項目或 200 個項目，這樣就你讓谷歌抓取和索引的內容而言，你有一點強制功能。 基於此，您可以更系統地構建它。

[...] 在某種程度上，我只能接受 Google 無法抓取和索引所有內容。 [...] 例如，如果您發現 [...] 單個產品沒有被抓取和編入索引，請確保至少這些產品的類別頁面被抓取和編入索引。 因為這樣，人們仍然可以在您的網站上找到這些個別產品的一些內容 [...]。

看看你是否可以自己爬取你的網站，這樣你就可以更直接地了解如何爬取像你這樣的網站。 那裡有各種爬行工具。 [...] 通過自己爬取網站，您可以看到這些 URL 中的哪些鏈接離主頁很遠，哪些鏈接離您的主頁更近。 在此基礎上，有時您可以稍微調整網站的結構，以確保與主頁的距離相當接近或相當穩定”。