SEO 辦公時間 – 2021 年 12 月 24 日

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

付費內容和偽裝

00:49 “關於帶有付費專區內容的付費專區數據。 […] 我們有一個網站。 我們寫了很多文章，Google 可以訪問所有內容。 我們想在那裡添加一個付費牆，但 [...] 僅 [...] 向 Google 顯示付費牆內容以及您擁有的結構化數據片段。 它被認為是隱身嗎？

所以，我檢查它是否是 Googlebot，然後只 [然後] 顯示 [...] 結構化數據 - [...] 付費牆數據。 但是對於普通用戶 [...]，我不顯示結構化數據，可以嗎？”

約翰沒有看到這個解決方案的問題：“沒關係。 從技術上講，它仍會被視為隱身，因為您展示的是不同的東西，但根據我們的政策，這是可以接受的。 因為用戶會 [...] 如果他們通過付費牆， [...] 會看到您向 Googlebot 展示的內容。”

潛在的索引問題

03:38 “我發布了高質量的內容，我提交了站點地圖，有時還從 Google Search Console 請求索引。 但是我在索引新內容時仍然遇到問題，或者它被索引[延遲]。 [...] 是來自 Google 的錯誤，還是新的算法更新？”

約翰回答說：“在這方面，我們這邊沒有錯誤。 […]我們只是不索引所有內容，有些網站會生成大量內容。 如果我們不對所有內容進行索引 [...]，那也可以。 但是也許您希望所有內容都被索引，而我們不能一直做所有事情。

棘手的部分 [...] 是，在過去，[...] 很多網站在技術上並不是那麼好。 哪種內容沒有被編入索引更清楚了。 如今，網站在技術上還可以，而且 [...] 就像質量標準有點高 [...]。 任何人都可以發布理論上可以被編入索引的內容，但是 [...]我們必須確保我們正在編入對用戶真正有用和相關的正確內容。 所以我們有時不得不留下一些未編入索引的東西。”

產品評論更新——受影響的語言和國家

14:01 “關於產品評論更新。 […] 即使更新只影響英語網站，我也看到德語搜索中的一些變化。 我想知道此產品評論更新或任何類型的 [...] 是否也會對其他語言的網站產生影響？”

正如 John 所說，“我的假設是這是全球性的並且跨越所有語言[...]。 但通常，我們會嘗試推動工程團隊對此做出決定，以便我們可以在博客文章中正確記錄它。 我不知道產品評論更新是否發生了這種情況。 […] 這似乎是我們可以用多種語言做的事情，而不僅僅局限於英語。 即使最初是英語，它也感覺像是全面相關的東西，我們應該嘗試找到方法隨著時間的推移將其推廣到其他語言。 所以我對你看到德國的變化並不感到特別驚訝 [...]。”

在得知谷歌博文只提到影響英語網站的更新後，約翰進一步闡述：

“通過這種更新，我們嘗試從一種語言或一個位置開始，看看我們需要調整什麼，然後我們從那裡擴展。 [...] 對於與內容更相關的內容，通常需要更長的時間才能擴展到不同的語言 [...]。”

英語國家的本地化頁面

17:53 “你知道其他方法可以為不同的英語國家本地化同一組頁面嗎？ [...] 我們有幾個帶有 .jo 頂級域的子域，比如可能來自澳大利亞、新西蘭的子域，我們在 JSA 後端設置了國家，並且還在頁面級別使用了 hreflang。 [...] 我們想不出其他方法來幫助我們本地化這些子域。 你有什麼好的方法或者我們可以改進的方法嗎？”

以下是約翰討論這個話題的方式：

“我認為你涵蓋了主要的內容。 這就是 Search Console 中的地理定位和 hreflang 設置。

地理定位適用於子目錄或子域級別，所有頁面都在其中。

Hreflang 是基於每頁的。 如果您有一個國家/地區的主頁和同一國家/地區的不同產品頁面，那麼這些頁面中的每一個都需要與 hreflang 交叉鏈接。

我一直嘗試推薦的另一件事是製定某種備份計劃，[...] 類似於基於 JavaScript 的橫幅，當您識別出用戶訪問了錯誤版本的網站時，您可以顯示該橫幅。 例如，如果來自澳大利亞的用戶最終訪問了來自英格蘭的頁面，您可以顯示一個 JavaScript 橫幅，上面寫著：“嘿，我們這裡有這個頁面的澳大利亞版本。 你可以直接去那裡。 基於 JavaScript 的橫幅的優點是您可以使用 robots.txt 阻止它，這樣從索引的角度來看，它不會出現。 如果您不自動重定向，[...] [搜索引擎] 將能夠獨立處理這兩個版本。

如果這些頁面本質上是相同的，那麼我們可能會將其中一個頁面視為規範版本。 例如，如果您有新西蘭和澳大利亞的頁面，並且整個內容相同，唯一略有不同的是頁面上的貨幣，那麼 [...] 我們將這些頁面折疊在一起並選擇其中一個作為一個規範，並將其用作搜索的基礎。

如果您也有 hreflang，那麼在這些頁面上，我們仍將使用 hreflang 來顯示正確版本的 URL。 但索引內容將僅來自規範版本，並且 Search Console 中的所有報告都將針對規範版本。 這有時會有點棘手，特別是如果您有一個更大的網站，並且 [...] 不同國家/地區的內容相同。”

向頁面添加動態內容

25:0 “我的網站有數百萬個頁面，例如類別、子類別以及產品、電子商務 [...] 頁面。 我們添加了動態內容，因為 [with] 數百萬頁 [...] [它] 很難在每個頁面上添加單獨的內容或 [...] 獨特的內容。 我們在類別頁面、子類別頁面和產品頁面上添加了 [...] 基於模板的內容。 […] 這對我們的網站性能有沒有好處，還是我們應該更新每個頁面的內容？ […]”。

以下是約翰的回應：

“將相關內容動態添加到頁面[...]是有意義的，因為 [...] [它] 本質上只是在 [...] 進行數據庫查找並在此基礎上添加內容。 [...] 這真的取決於你是如何設置的。

我要避免的主要事情是，您會遇到人為地將內容添加到頁面的情況，只是希望該頁面對您人為添加的關鍵字的排名更好。 […] 當用戶去那裡時，他們會想“為什麼這些隨機關鍵字出現在這個頁面上？” [...] 確保您實際上擁有與這些關鍵關鍵字相關的良好內容，這才是我更關注的 [...]。”

當另外被問及是否有必要為每個頁面編寫相關內容以便谷歌將頁面視為提供價值時，約翰說：

“它應該是頁面上相關的內容。 如果它是一個類別頁面，那麼您在那裡列出的產品是非常相關的 [...] 並且通常，您有該類別的描述。 ...

渲染和索引 JavaScript 文件

28:28 “我的網站 [...] [使用] React 與客戶端渲染，[...] 當我們關閉 JavaScript 和瀏覽器時，我的頁面完全空白。 這可能是排名較低的原因，也可能是網頁性能不佳的原因？”

約翰的回答是：“不應該。 [...] 對於搜索，我們進行渲染，並處理頁面上的 JavaScript。 如果它在普通瀏覽器中可見，並且您沒有做任何特別糟糕的事情，那麼我們將能夠正常索引這些頁面。 您可以使用 Search Console 中的Inspect URL 工具仔細檢查，以查看當 Googlebot 嘗試呈現頁面時內容是否實際可見，如果內容可見，那麼您應該一切就緒。”

通過在網站內搜索生成的索引 URL

30:11 “我們已經在我們的網站中添加了一個搜索框，所以用戶來到我們的網站並在那裡搜索，它會為每次搜索生成一個唯一的 URL。 這些 URL 應該是可索引的還是不可索引的？”

正如約翰所說，“通常不會。 [...] 有兩個主要原因。

一方面，很容易導致您有另外一百萬個 URL 只是不同的搜索，這對您沒有任何價值。 我們稱之為無限空間[…]。 這是你要避免的事情。

您要避免的另一件事是人們在搜索框中做垃圾郵件並嘗試將這些內容編入索引，這可能類似於搜索他們的電話號碼和 [...] 他們的業務類型 [...]。 突然，您網站的搜索頁面為此類業務排名並顯示他們的電話號碼，即使您沒有任何與這些查詢匹配的內容，[...] 他們這樣做是為了試圖在搜索結果中可見。 我會用 robots.txt 阻止這種搜索頁面。 這樣您就可以確定我們無法為任何內容編制索引。”

SEO網站作為YMYL

31:55 “SEO 公司會被歸類為Your Money or Your Life網站，還是僅與醫療和財務建議網站有關？”

根據約翰的說法，“[...] 我不認為 SEO 網站對人們的生活至關重要。 顯然，如果您在一家 SEO 公司工作，那麼您就與此有關，但這並不是說該網站本身就是您的金錢或生活類型的網站。 [...] 並非每個銷售商品的網站都屬於這一類。

我在這裡建議的是，不要盲目地嘗試查看“這種類型的網站是否屬於這個特定類別？”，[...] 閱讀這個類別的來源，即質量評估指南，並了解更多谷歌試圖理解這些不同類型的網站。 [...] 這將為您提供有關實際情況的更多背景信息 [...]。”

實現麵包屑結構化數據

39:56 “當涉及到麵包屑結構化數據時，它是否必須與訪問者在頁面上看到的麵包屑完全相同？ 我有時會在頁面上看到精簡版的麵包屑，而結構化數據是完整的麵包屑路徑。 兩種選擇都可以接受嗎？”

正如 John 所說，“[...]我們嘗試識別結構化數據是否在頁面上可見。 如果不是 [...]，我們必須弄清楚“在搜索結果中顯示它仍然有意義嗎？ ”

如果您要在頁面上顯示較短版本的麵包屑，而我們無法匹配，那麼如果我們真的拿起麵包屑標記並使用它，它可能會有點命中註定。

如果您正在獲取單個麵包屑或 [...] 麵包屑列表中的單個項目，而您只是顯示其中的一些而不是全部，則可能是我們只選擇了這些。 可能我們仍然會選擇其餘的，因為我們看到 [...] 很多麵包屑匹配。

如果您沒有在頁面上顯示完整的麵包屑標記，我們無法保證我們能夠獲取並使用完整的麵包屑標記，這與其他類型的結構化數據類似。

我認為主要的例外 [...] 是 [...]常見問題標記，您有問題和答案，其中 [...] 重要的部分是問題實際上是可見的，答案可能類似於折疊部分頁面，但 [...] 至少必須是可見的。”

僅翻譯網站上的某些頁面

44:00 “我們運營的網站只有不到 300 個英文索引頁面。 我們希望將其中大約一半的頁面翻譯成西班牙語，這些頁面將放置在同一域的子目錄中，例如 /ES，並標記為英語內容的替代語言版本。 是否可以只翻譯部分頁面內容，或者我們應該翻譯所有內容以完全反映英文網站並在其他位置獲得最佳排名機會？”

約翰說：“只翻譯網站上的一些頁面就可以了。 我們分別查看頁面的語言。 如果您有一些西班牙語頁面，當有人用西班牙語搜索時，我們只會查看那些西班牙語頁面。 我們不會說：'這裡的英文頁面比西班牙文頁面多得多。 因此，西班牙網站不太重要。 [...] 這些是西班牙語頁面，它們在西班牙語中的排名很高。 […] 對於用戶來說，有時翻譯盡可能多的內容是有意義的。 但通常情況下，隨著時間的推移，你會逐漸改進，從一些頁面開始，很好地本地化它們，然後添加更多頁面[…]。

hreflang 註釋也是基於每頁的。 如果你有一些英文和西班牙文的頁面，並且你鏈接了它們，那很好。 如果你有一些頁面只是西班牙語，那很好——你不需要hreflang。 有些頁面只有英文，這也很好。 從這個角度來看，這似乎是一個合理的開始方式。”

抓取預算和自動生成的 URL

46:12 “我所說的網站是一個 WordPress 網站。 它會自動生成多個不需要的 URL。 [...] 有沒有辦法阻止爬蟲找出這些 URL？ 我知道我可以“noindex”它，而且這些都是沒有索引的 URL。 但是，我可以在 Search Console 的 Excluded 部分下看到它們。 [...] 這是一個新聞網站，我們有數千個 URL。 [...] 它會影響爬行預算嗎？”

約翰詢問了網站的大小，並被告知它有 5,000 到 10,000 個 URL。

鑑於此，約翰說：“我不會擔心爬行預算。 [...] 我們可以相當快地爬取這麼多頁面，通常在幾天內。 另一件事 [...] 是“noindex”是頁面上的元標記。 我們必須抓取頁面才能看到元標記，這意味著您無法避免我們檢查“noindex”頁面。 [...] 如果我們看到頁面上有一個“noindex”，那麼通常隨著時間的推移，我們會減少對這些頁面的抓取頻率。 我們仍然會不時地仔細檢查，但我們不會像其他被索引的普通頁面那樣檢查。 另一種方法是使用 robots.txt。 使用 robots.txt 文件，您可以完全阻止對這些頁面的抓取。 缺點是有時 URL 本身可以在搜索結果中編入索引，而不是頁面上的內容 [...]。”

約翰還舉了一個例子：

“如果您 [...] 有一個足球新聞網站，並且您有一些被阻止的文章和一些允許抓取的文章，那麼如果有人在搜索足球新聞，他們會找到您頁面的可索引版本，並且是否有其他頁面被 robots.txt 阻止並不重要。 但是，如果有人明確對這些被阻止的頁面進行站點查詢，那麼您將能夠在搜索中看到這些 URL [...]。 在像你這樣的情況下，[...] 我不會擔心抓取預算。”

John 還補充說：“從實用的角度來看，'noindex' 和 robots.txt 都是等價的。 [...] 該內容可能不會出現在搜索結果中，如果有“noindex”，我們仍然需要抓取它，但數字太小了，它們並不重要。 如果它們被 robots.txt [...] 阻止，我們可能仍會使用 URL 對其進行索引。

關於首選方法，John 說：“我會選擇對您而言更容易實施的方法。 如果 [...] 您有 WordPress，並且您可以在帖子上添加一個複選框，上面寫著“此頁面的 noindex”，那麼這可能是最簡單的方法 [...]。”

使用參數抓取 URL

54:25 “我們在我們的日誌文件中看到，並且還通過 IEP 證明它是 Googlebot，從有機 bot 到 UTM 參數 URL、Google 展示和通用應用廣告系列的大量爬網。 [...] 我們沒有看到任何來自任何地方的鏈接到這些 URL。 [...] 你知道這可能發生在哪里或為什麼會發生嗎？”

John 回應說：“我們還使用 Googlebot 抓取您在廣告活動中列出的頁面 [...] 的一個地方是產品搜索。 如果您設置了產品搜索 Feed 或Merchant Center Feed [...]，那麼我們還將為 Googlebot 抓取這些頁面，以確保我們可以為 Merchant Center 提取它們。 如果您在其中標記了 URL，[...] 我們將保留這些標記的 URL 並重新處理它們。

也可能是其他人能夠提交此類產品，[...] 提交它們的不一定是您，而是代表您工作或有權這樣做的人。

如果我們在某處找到這些頁面的鏈接，我們將嘗試抓取它們。 如果您在網站內標記了內部鏈接，我們仍會嘗試提取並抓取該鏈接。 如果您在 JavaScript 中設置了一些東西，也許您在某處設置了帶有這些參數的跟踪 URL，並且當我們處理 JavaScript 時，它看起來像是指向這些跟踪 URL 的鏈接，我們也可以處理它。 [...] 在我看來，這不是個別案例 [...]，而是大量此類 URL，感覺很像 Merchant Center 方面的事情。”