SEO 辦公時間，2022 年 5 月 6 日

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

您可以在您的網站上使用 Web 組件嗎？

3:08 “使用 Web 組件進行 SEO 有什麼問題嗎？”

John 回答說：“[...] 在 SEO 方面，[...] Web 組件是使用各種形式的 JavaScript 實現的，而在涉及 Google 搜索時，我們幾乎可以處理大多數 JavaScript。 雖然我想說只是盲目地支持一切，但你可以測試它，你應該測試它。

最好的測試方法是在 Search Console 中 - 有URL 檢查工具。 在那裡，您可以插入您的 URL，您將看到 Google 將為該頁面呈現的內容，即 HTML。 首先，您可以在屏幕截圖上看到它，然後也可以在您也可以查看的呈現的 HTML 中看到它。 您可以仔細檢查 Google 能夠從您的 Web 組件中獲取的內容。

如果您認為重要信息在那裡，那麼您可能已經準備就緒。 如果您認為缺少某些重要信息，那麼您可以深入研究並嘗試找出卡在那裡的原因是什麼？ 現在我們有很多關於 JavaScript 網站和網絡搜索的文檔，所以我會仔細檢查一下。 […]”

是否可以在頁面的不同部分使用常見問題解答模式？

5:18 “是否可以使用常見問題解答模式來標記出現在博客文章不同部分中的問題和答案，這些問題和答案未格式化為傳統常見問題解答列表？”

約翰回答說：“我仔細檢查了官方文檔[...]，看起來沒問題。

一般來說，關於常見問題解答片段和結構化數據的重要部分是內容應該在頁面上可見。 因此，當有人訪問該頁面時，問題和答案都應該是可見的，而不是隱藏在頁面的某個部分中。 但是，如果問題和答案在頁面上可見，即使它們位於頁面上的不同位置，那也很好。

要記住的另一件事是，與所有結構化數據一樣， FAQ 片段不能保證顯示在搜索結果中。 從本質上講，您使您的網頁有資格顯示這些常見問題解答片段，但不能保證它們會顯示。

因此，您可以使用測試工具來確保一切都正確實施。 如果測試工具說沒問題，那麼您可能走在正確的軌道上。 但是您可能仍然需要等待，看看 Google 如何解釋您的頁面並處理它們以查看搜索結果中顯示的內容。

對於結構化數據，我認為常見問題解答就是這種情況，但至少對於其他一些類型，Search Console 中也有特定的報告，可為您提供有關已找到的結構化數據和顯示的結構化數據的信息搜索結果，以便您可以粗略地衡量，它是按您希望的方式工作，還是按您希望的方式工作？

對於這樣的事情，我建議您嘗試一下並在您的網站上製作一個測試頁面，看看搜索結果中的結果如何，仔細檢查它是否是您想要做的，然後開始實施它您網站的其餘部分。”

如果您對常見問題解答架構有更多疑問，請閱讀我們博客上的文章，其中包含有關常見問題解答豐富網頁摘要（也稱為豐富搜索結果）的常見問題。

是否可以抄襲您的內容？

7:37 “Google 同意出版商抄襲自己的內容嗎？”

根據約翰的說法，“[…] 看起來如果你在重複使用自己的內容，這並不是抄襲。 […]

從 Google 的角度來看，如果您從自己的網站中獲取內容並在頁面的某些元素發生更改的情況下再次發布，這基本上取決於您。 這就是 [...] 只是複制現有文章並更改其中的一些文字並沒有提供很多價值的地方。

所以 […] 從戰略的角度來看，你可能更適合為這些主題寫一些獨特且引人注目的東西，或者創建一篇涵蓋這些不同變化的文章。 但是 [...] 從政策的角度來看，我認為沒有什麼特別的方式可以讓您獲取個別文章然後復制一些文章。 [...] 但我的建議是 [to]少寫一些實際上非常好的文章。

如果您 [...] 強烈複製自己的內容，可能會出現的一種極端情況是，您最終會創建門口頁面。 這本質上就是取一個內容，然後用不同的詞創造出很多很多的變化。 這違反了我們的網站站長指南。

[...] 這也是您為您的網站創建大量 [...] 垃圾頁面的地方，而這些頁面基本上 [...] 總體上並沒有提供任何獨特的價值。 而不是像那樣稀釋您網站的內容，我建議您專注於使您網站的主要內容更加強大。 […]”

如果您的網站在關閉 JavaScript 後對用戶不友好怎麼辦？

10:24 “如果關閉 JavaScript，我們的網站就不是很友好。 大多數圖像未加載。 我們的彈出菜單無法打開。 但是，其所有菜單鏈接中的 Chrome 檢查功能位於源代碼中。 我們對 JavaScript 的依賴可能仍然是 Googlebot 的問題嗎？”

約翰：“從我的角度來看，[...] 我會測試它。 [...] 而且，我可能會假設如果您以合理的方式使用 JavaScript，如果您沒有做任何特別的事情來阻止頁面上的 JavaScript，那麼它可能會起作用。 但是你最好不要相信我，而是使用測試工具來嘗試一下。 [...] 因此，我會仔細檢查我們關於 JavaScript 和 SEO 的指南，並考慮嘗試一下，確保它們以您想要的方式工作，然後將其用於整體改進您的網站。

你提到了關於 JavaScript 的用戶友好性。 因此，從我們的角度來看，我們擁有的指導本質上是非常技術性的，從某種意義上說，我們需要確保 Googlebot 可以從技術角度查看內容，並且它可以從技術角度。 它主要不關心用戶友好性。

但是，當然，您的用戶關心用戶友好性。 這就是做更多的事情是有意義的，這樣您的用戶確實可以確保在您的頁面上獲得良好的體驗。

這通常不僅僅是一個簡單的測試工具的問題，而是你可能需要做一個小的用戶研究，或者採訪一些用戶，或者至少在你的網站上做一個調查來了解在哪裡做他們卡住了？ 他們面臨著什麼樣的問題？ [...] 可能是文本太小，或者他們不能正確點擊按鈕，那些不符合技術問題但更多的是用戶端的東西。

[...] 如果你能改進這些，如果你能讓你的用戶更快樂，他們會留下來，他們會回來，他們也會邀請更多的人訪問你的網站。”

單擊此處進一步閱讀我們博客上的 JavaScript SEO。

索引問題是否取決於所使用的網站技術類型？

13:08 “我們的靜態頁面是用 HTML 構建的，我們的博客是用 WordPress 構建的。 我們的大多數博客文章都在 Google 中遇到索引問題。 我該如何解決？”

約翰：“首先，重要的是要知道這些只是不同的平台。 本質上，使用所有這些平台，您正在創建 HTML 頁面。 以及最終創建這些 HTML 頁面的網站的背景或後端，這是 Googlebot 不會查看的內容。 或者至少，這是 Googlebot 不會嘗試評估的東西。

因此，如果您的頁面是用 HTML 編寫的，並且您在編輯器中編寫它們，然後將它們加載到您的服務器上，並且它們就是這樣服務的，那麼我們可以看到它們是 HTML 頁面。 如果它們是基於 WordPress 或您正在使用的其他平台中的數據庫在您的服務器上動態創建的，然後它會創建 HTML 頁面，我們會看到這些最終的 HTML 頁面，我們基本上會使用這些頁面。

因此，如果您在抓取、索引或排名等方面發現網站整體存在問題，並且您可以排除其中的技術元素，即 Googlebot 能夠看到內容，那麼通常剩下的就是事物的質量方面。

這並不依賴於您用於創建這些頁面的基礎架構，而更多的是關於您在那裡提供的內容以及您在網站上提供的整體體驗。 因此，如果您看到某些內容，例如，您的博客文章沒有被 Google 收錄或在 Google 中排名不佳，而您的靜態 HTML 頁面在 Google 上表現良好，那並不是因為它們是靜態 HTML 頁面他們在谷歌上表現不錯，而是因為谷歌認為這些是它應該推薦給其他用戶的好內容。

在那個層面上，這就是我要看的地方，而不是過多地關注基礎設施，而是關注您提供的實際內容。

在內容方面，不僅僅是頁面的主要部分的文本。 就像整個網站周圍的一切都在發揮作用。 所以這就是我會嘗試退後一步，看看更大的圖景的地方。 如果您沒有從大局的角度看一些質量問題可能存在或您可以改進的地方，我強烈建議您進行用戶研究。

為此，可能會邀請少數與您的網站沒有直接關聯的人，讓他們在您的網站上執行一些任務。 然後問他們一些棘手的問題，比如他們認為本網站可能存在問題的地方，或者他們是否會信任本網站，或者關於了解網站質量的任何其他問題。 我們的一些博客文章中有很多這樣的問題，您也可以從中獲得靈感。 [...] 將他們的答案銘記於心，並思考如何整體改善您的網站。”

為什麼 Google 不尊重規範標籤？

17:12 “我在五個頁面上設置了規範 URL，但谷歌也在第三頁上顯示它。 為什麼它不僅顯示我為其設置了規範的 URL？”

約翰說，“[...] 釋義，聽起來你在網站的五個頁面上設置了一個 rel=”canonical”。 您網站上的其他頁面還沒有設置 rel=”canonical”。 谷歌正在展示所有這些頁面，這些頁面基本上以各種方式被索引。

我認為要記住的是rel=”canonical” 是一種指定一組重複頁面中的哪些頁面要像這樣索引的方式。 或者本質上，您想使用哪個地址。 因此，特別是，如果您有一頁，文件名可能為大寫，另一頁的文件名為小寫，那麼在某些情況下，您的服務器可能會顯示相同的內容，從技術上講，它們是不同的地址。 [...] 但是從實際的角度來看，您的服務器顯示的是同樣的東西。

而谷歌，當它看到這一點時，它說，好吧，索引兩個具有相同內容的地址是不值得的。 相反，我將選擇其中一個地址並使用它來索引該內容。 使用 rel=”canonical”，您可以向 Google 發出信號並告訴它，嘿，Google，我希望您在索引此內容時使用地址的小寫版本。 您可能已經看過大寫版本，但我希望您使用小寫版本。 這基本上就是 rel=”canonical” 所做的。

這不能保證我們會使用您在此處指定的版本，但這對我們來說是一個信號。 它可以幫助我們找出所有其他條件相同的情況，您真的更喜歡這個地址，所以我們將嘗試使用該地址。 […]

當我們認識到您的網站上有同一內容的多個副本時，它就會發揮作用。 對於其他所有內容，我們將盡力將其編入索引。 這也意味著對於您有 rel="canonical" 的頁面，有時它會遵循您給我們的建議。 有時我們的系統可能會說，我想你可能搞錯了。 您應該使用其他地址作為規範。 這可能會發生。 這並不意味著它的排名會有所不同，或者它會在搜索中變得更糟。 只是，谷歌系統正在選擇一個不同的系統。

對於您網站上的其他頁面，您可能根本沒有設置 rel=”canonical”。 對於那些，我們將嘗試自己挑選一個。 這也很好。 在所有這些情況下，排名都會很好。 索引會很好。 只是搜索結果中顯示的地址有所不同。

因此，如果您在某些頁面上設置了規範集，但在其他頁面上沒有，我們仍會嘗試為這些頁面編制索引，並在搜索中顯示這些頁面時找到用於這些頁面的正確地址。 因此，在您的頁面上使用 rel=”canonical” 是一個很好的做法，因為您試圖控制這種可能會顯示不同地址的模糊可能性。 但是，rel =“canonical”並不是絕對必要的。

如何擺脫垃圾郵件反向鏈接？

20:56 “如果我們有數千個垃圾鏈接不斷作為反向鏈接放置在惡意域上，我們該怎麼辦？ 它們包含垃圾關鍵字並在我們的域上導致 404。 我們發現這些垃圾鏈接與我們在 2021 年垃圾郵件更新後受到的懲罰之間存在很強的相關性。我們否認了所有垃圾鏈接，並報告了被列為垃圾鏈接來源的域。 我們還能做什麼？”

約翰回答說：“[...] 在這個特殊情況下，我認為有兩件事很重要。 一方面，如果這些鏈接指向您網站上返回 404 的頁面，那麼它們實際上是鏈接到不存在的頁面，那麼我們不會考慮這些鏈接，因為沒有任何關聯它們在您的網站上。 從本質上講，人們正在鏈接到一個缺失的位置。 然後我們會說，好吧，我們可以用這個鏈接做什麼？ 我們無法將它連接到任何東西，所以我們將刪除它 [...] 就像其中很多可能已經被刪除一樣。

第二部分是您提到您否認了那些垃圾郵件反向鏈接。 尤其是如果您提到這些來自少數域，那麼您可以使用拒絕反向鏈接工具中的域條目來做到這一點。 這基本上也將它們從我們的系統中取出。 所以我們仍然會在 Search Console 中列出它們，你可能仍然會在那裡找到它們並且對此有點困惑。 但本質上，它們根本沒有任何作用。 如果他們被拒絕，那麼我們告訴我們的系統，不應該以積極或消極的方式考慮這些。 因此，從實際的角度來看，無論是從 404 方面還是從拒絕方面來看，這些鏈接可能對您的網站沒有任何負面影響。

如果您在 Google 搜索中看到您的網站發生了重大變化，我不會關注這些鏈接，而是更進一步。 這可以在您自己的網站內更好地了解您在那裡提供的價值。 就您為用戶提供的巨大價值而言，您能做些什麼來超越所有其他網站？ 您如何使搜索引擎盡可能清楚？ [...] 你可以否認他們來自的整個域，然後繼續前進。 在那裡你絕對不需要做任何事情。 尤其是如果它們已經鏈接到 404 頁面，它們就已經被忽略了。”

如何在沒有 App Indexing 的情況下讓您的應用被索引？

26:51 “ [...] 如果 App Indexing 不再有效，如何讓您的應用在 Google 上排名？”

John 回答說：“[...] 對於任何應用程序，您可以做的一件事是，[...]您可以為其創建主頁。 這就是可以像其他任何東西一樣在搜索中顯示的東西。 而對於很多智能手機應用程序，Play Store 或 App Store 上也會有一個頁面。 [...] 但通常，它們就像也存在的登錄頁面，它們是也可以出現在搜索中的普通網頁。 當人們在您的應用周圍搜索某些內容時，這些內容可能會出現在“搜索”中。

[...] 尤其是當涉及到您自己的網站時，您可以為您自己的網站做我們談論的所有關於 SEO 的事情。 所以我不會說應用索引不再像 10 年前一樣。 [...] 相反，您有很多機會以不同的方式在搜索中可見。 你不需要只依賴一個特定的方面。”