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

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

垃圾郵件反向鏈接與核心更新

  00:47 “我們在瑞士擁有三個在線藥店。 […] 對於 [其中一個]，我們收到了很多垃圾郵件反向鏈接。 [...] 據我所知，通常 Google 可以管理這些類型的反向鏈接，但在 7 月份 Google 核心更新之後，我們的知名度受到了嚴重傷害，特別是對於我們收到垃圾郵件反向鏈接的那個 [one] 商店。 [...] 我想听聽您對此的建議——我們可以做些什麼來解決我們遇到的技術問題。 到目前為止，我仍然認為這是因為垃圾郵件反向鏈接而發生的，但 [我] 不確定。”

John 說：“一般來說，對於核心更新，如果你看到那裡的變化，通常這與試圖弄清楚網站的整體相關性更相關，而與垃圾鏈接等內容的相關性較低。 這就是我不希望在基於訪問您網站的隨機垃圾郵件鏈接的核心更新中做出任何反應的地方。

此外，通過核心更新，您可以進行增量更改以隨著時間的推移在整體質量方面改善您的網站，這將逐步提供幫助，但如果這是一個非常強大的核心更新調整，那麼您可能需要等待直到下一次核心更新才能看到這些變化。 [...] 這是我們試圖弄清楚網站的整體相關性的問題，而這幾乎取決於整個網站的質量。

我想如果您有多家非常相似的商店，這將很棘手。 [...] 其中一個可能不是壞的 - 其他的真的很好。 但它可能仍然是你可以使用用戶研究來弄清楚你可以做些什麼來明確這個網站特別相關的東西。 我認為，特別是對於像藥店這樣的網站，我們的算法可能會嘗試變得更加關鍵。 [...] 這不是一個有故事和有趣圖片的隨機網站，它就像涉及人們的健康一樣。“

John 補充說：“特別是關於 404 頁面和與核心更新無關的技術問題。 核心更新更多地是關於了解您網站的整體質量及其相關性，而不是技術問題和垃圾郵件。”

JavaScript 內容索引

  05:11 “我在一個網站上工作 [...] Core Web Vitals。 我們有一個功能，我們將 Youtube 視頻放在頂部，這成為了 LCP 元素。 它比我們剛剛擁有的要重，就像普通的圖像一樣。 所以我們正在嘗試一種動態注入它的方法。 […] 因為它不在折疊內容之下，所以我們不會延遲加載它，而是使用外觀，然後在用戶單擊播放按鈕時動態注入 <iframe>。 我現在意識到這些文章基本上沒有被頁面上的視頻內容索引，所以如果我搜索頁面並轉到視頻搜索，它不會出現在那裡。 所以我想知道用頁面索引該內容的最佳方法是什麼。 […] 像 <noscript> 或結構化數據之類的東西是要走的路嗎？ 這有什麼最佳實踐嗎？”

約翰：“取決於你設置你在那裡提到的外觀的方式，你基本上點擊一個圖像或一個 <div>，然後它在後台加載視頻，我們可能不這樣做'當我們查看頁面時，它會自動將其作為視頻拾取。 我收到了視頻搜索團隊的反饋，告訴我們我們不應該告訴人們這樣做，因為它會導致這樣的問題。 本質上，最好的方法是確保使用結構化數據，我們可以判斷那裡仍然有視頻。 我相信您可以添加一種專門針對視頻的結構化數據。 視頻站點地圖在這方面本質上非常相似，因為您在此頁面上告訴我們有一個相關的視頻。 這就是那裡的兩種方法。

我懷疑隨著時間的推移，Youtube 嵌入會變得越來越好，而且你必須做這些技巧的問題就會減少。 但我認為目前，它仍然有意義，並且仍然可以對頁面的 Core Web Vitals 產生很大影響。 所以從這個角度來看，我很傷心。 如果視頻團隊告訴我你應該直接放，而另一個團隊說你應該快點，那麼很難找到中間立場。 但我認為至少要確保我們能夠識別視頻的存在，這非常重要。”

類別頁面

  13:35 “我們正在銷售 [...] 金屬型材，我們有許多不同類型的這些型材。 我們有很多精簡的內容，因為我們有相同的變化。 […] 我們在這些 URL 中有數千種變體 […]，我不知道如何處理。 我應該規範化這些嗎？ 但話又說回來，我們鏈接到他們 [這些 URL]，所以我不想在我的頁面內創建糟糕的內鏈接或質量差的鏈接。 我應該不索引 [這些 URL] 還是阻止機器人訪問 [它們]？ [...] 我們不需要人們來訪問那些變體頁面。 我們只想在類別頁面上創造出良好的品質。”

John 回答說：“通常我們建議的是，如果您希望以獨特的方式找到獨特的項目，那麼您要確保它們具有唯一的 URL，並確保它們是規範的 [並且] 它們”沒有被 noindex 阻止。 但是，如果您不關心那些單獨的 URL，如果您更關心更高級別的類別，或者如果您擁有更廣泛的產品或類別，而這本質上是查找內容的最重要方式，那麼您可以規範化到該頁面，如果需要，您可以不索引其他版本。 因此，您基本上可以在那裡做任何您想做的事情，以便我們將所有信號集中在您關心的主頁上。

[...] 我想像你提到的工業產品，你有這麼多不同的尺寸和變化，關注總體佈局並說所有這些不同的選項本質上是主要產品的一個屬性可能是有意義的，我們應該只專注於主要產品。”

John 補充說：“設置規範時要記住的是，我們將嘗試為您提到的規範頁面編制索引。 因此，如果非規範頁面上有任何獨特之處，那麼我們將無法找到它，因此本質上是任何關鍵的東西——確保在規範頁面上也提到了它。”

在 Google Discover 中排名

18:31 “在 Discover 中，我們或多或少有兩個不同的搜索結果頁面。 我們有第一頁，然後您可以點擊更多結果，然後您有第二頁。 是不是涉及到排名，讓某篇文章出現在第二頁，還是更新時間的問題？”

約翰說：“可能有一種排名感，但我認為它與傳統的網絡排名不一樣。 Discover 是如此個性化，所以我認為傳統的概念是沒有意義的像那樣。 […]

甚至個性化排名方面也有很多事情要做。 我想可能還有不同方面的地理定位和不同格式的網頁，更多的視頻或更少的視頻，更多的圖像 - 更少的圖像。 但老實說，我不知道具體是什麼。”

John 還建議遵循Google 的建議，並補充說：“特別要注意我們說不要做這種或那種事情的方面。 我也會在 Twitter 上環顧四周——有少數人幾乎專門研究 Discover。 [...] 我會檢查這些東西，但因為從我們的角度來看，這是一個非常個性化的提要，所以你不能努力提高你的排名。 這不是人們正在搜索的關鍵字。 所以這很好，這裡有一些我們認為可能會有趣的東西給你。”

301 重定向

22:23 “我知道您應該使用 301 進行永久重定向，以盡可能最好、最快地通過 PageRank。 但是，我們的開發團隊不喜歡實現 301，因為它們可能永遠存儲在瀏覽器中。 他們說，如果重定向配置錯誤，人們可能永遠無法丟失不正確的 301 重定向。 谷歌是否像某些瀏覽器那樣存儲 301 重定向？”

根據 John 的說法，“整個爬網和索引系統與瀏覽器本質上是不同的，因為它們針對不同的事物進行了優化的所有網絡端。 在瀏覽器中，緩存內容更有意義，緩存時間更長。 但本質上，從我們的角度來看，在抓取和索引方面 [...]，我們不會將抓取和索引視為瀏覽器。 從某種意義上說，我們像瀏覽器一樣渲染頁面有點奇怪，但是將內容輸入我們系統的整個過程是非常不同的。 您有時會在渲染頁面或看到頁面被渲染時看到這一點，並且它使用非常舊的 JavaScript 文件只是因為我們已經能夠緩存它們一段時間，這可能在瀏覽器上不會發生，但本質上是不同的。”

緩存控制標頭

23:59 “ Google 是否會接受帶有“Cache-Control: no-cache”、“Cache-Control: max-age=[time]”或“Expires: [date]”標頭的 301 重定向，以便我們獲得兩全其美？”

約翰說：“是的，這完全沒問題。 如果是 301 重定向，我們將其視為 301 重定向。 除此之外，您還添加哪種緩存標頭都沒有關係。 所以從這個角度來看，如果這是一個對您的開發團隊和您自己都有效的解決方案，為什麼不呢。 [...] 另一件事是 302 重定向也可能是一個選項，如果這對您的開發團隊更有效。 302 重定向在 SEO 中名聲不好，我認為這是不正確的，因為它們也與普通重定向一樣工作。 並不是說他們沒有通過任何類似的 PageRank，如果您從長遠來看有 302 重定向，我們仍然將它們視為 301 重定向。 因此，如果您無法弄清楚它如何與 301 重定向一起工作，那麼 302 重定向也許也是一種選擇。”

識別質量改進

31:25 “如果通過頁面體驗更新提高頁面質量對谷歌很重要，為什麼谷歌需要這麼長時間才能認識到這些改進？ 如果 SEO 不得不犧牲幾個月的搜索排名和流量，他們承諾做出真正的改變來改善 Web 體驗似乎是違反直覺的。”

根據 John 的說法，“[...] 如果您在網站上進行更大的更改，那麼有時您確實會看到波動，但這並不是我們所說的波動存在的原因，因為您改進了您的網站。 只是當您在網站上進行真正大的更改時，我們必須重新理解一個網站。 但從我的角度來看，你可以在一個網站上進行的許多重組取決於你如何設置它們 […]——你可以通過一種在搜索和這樣它就不會導致您的整個網站消失。”

無索引頁面與網站可爬取性

32:48 “是否有多個頁面因質量問題未被索引會影響網站的整體可爬性？”

約翰：“沒有。 如果您選擇不索引頁面，這不會影響我們抓取您網站的其餘部分的方式。 當然，這裡的一個例外是我們在 noindex 中看到我們必須首先抓取該頁面。 因此，如果您正在創建某些內容，比如說，數百萬頁，其中 90% 是無索引的，而您有一百個可索引的頁面。 我們必須爬取整個網站才能發現這 100 個頁面，很明顯，我們將陷入爬取數百萬個頁面的困境。 但是，如果您的可索引頁面與不可索引頁面的比例正常，[...] ‒ 我認為這不會在可抓取性方面造成任何問題。 這不是 [...] 由於谷歌所說的質量原因，哦不，索引頁面很糟糕。 這純粹是技術問題。 如果我們必須抓取一百萬個 URL，我們必須抓取一百萬個 URL 以查看其中的內容。 這不是我們可以說的，好吧，我們只會爬 50 000，因為有一些沒有索引的頁面。 本質上，這只是一個數字問題。”

302 重定向

34:22 “我們聽說臨時 (302) 重定向不會通過鏈接資產。 我們對此的理解準確嗎？ 更一般地說，我們聽說使用 302 會導致嚴重的 SEO 問題，這讓我們想知道我們是否應該不惜一切代價避免這些，或者是否在特定情況下我們應該使用它們。”

約翰說： “答案是肯定的。 302 重定向對 SEO 沒有負面影響。 我認為當您進行 302 重定向時失去 PageRank 的整個感覺是錯誤的。 它不時出現。 我認為出現這種情況的主要原因是，根據定義，302 重定向是不同的。 [...] 使用 301 重定向，您正在更改地址，並且您希望 Google 系統獲取目標頁面。 使用 302 重定向，您的意思是，這暫時在其他地方，但您希望 Google 系統保留原始 URL。 因此，如果您純粹是跟踪單個 URL 的排名，那麼當然，301 會導致目標頁面被編入索引，而排名和 302 重定向將保留原始頁面的索引和排名。 但是沒有丟失 PageRank 或分配給那裡的任何信號。 […] 有時 302 重定向是正確的做法——有時 301 重定向是正確的做法。 如果我們在較長時間內發現 302 重定向，我們認為，好吧，也許這不是暫時的舉動，那麼我們也會將它們視為 301 重定向。 但是使用 301 重定向和 302 重定向並沒有隱藏的 SEO 好處。 它們只是不同的東西。”

向用戶顯示更少的內容

46:54 “[有]一個客戶有問題。 [...] robots.txt 阻止的許多 URL 也有一個設置在 noindex 上的 HTTP 標頭。 所以我設置打開 robots.txt 以便可以取消索引 URL。 但是客戶端擔心服務器不會先於所有請求而失敗。 所以我說，好吧，如果你把用戶代理看作一個機器人，你可以給出一個空白的 HTML 正文或另一個頁面。 如果 HTTP 標頭設置為 noindex，是否存在因偽裝而受到懲罰的風險？”

約翰回答說： “不，我認為這沒有任何問題。 特別是，如果您向搜索引擎展示的次數少於向用戶展示的次數，那麼關於偽裝的問題就不那麼重要了。 對我們來說更成問題的隱藏部分是，如果您向我們展示一個非常大且有趣的頁面，當用戶到達那裡時，他們會看到非常微小或略有不同的東西。 但是，如果您向我們展示的本質上是一個空頁面，並且說，哦，這裡沒有任何內容您不應該將該頁面編入索引，並且我們將其從索引中刪除，那麼我們不在乎用戶是否看到其他內容。 所以從我們的角度來看，我們想要避免的是我們向用戶承諾他們找不到的東西。 因此，如果我們從索引中刪除一個頁面，我們將無法推薦該頁面，因為我們不再擁有它。 […] 如果我們向人們推荐一個特定查詢的頁面，他們去了那裡，但他們找不到該內容，那麼他們就會感到沮喪，他們認為我們做得不好，這就是我們的隱藏問題來自。 但少展示一點也很好。”