SEO 辦公時間，2022 年 3 月 4 日

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

在 schema.org 驗證器與 Google Search Console 中測試架構標記

7:41 “約翰，所以我的第一個問題是，Google Search Console 在所需的結構化數據元素中拋出錯誤 [...]。 但是當我在validator.schema.org 上檢查相同的內容時，它沒有顯示任何警告或任何錯誤。 所以第一個問題是，它是檢查網頁的 AMP 實現的正確網站嗎？ […]“

約翰回答說：“是的，所以這些測試工具的用途略有不同。 這可能就是您看到這種差異的原因。 schema.org 中的測試工具更多的是基於 schema.org 的要求來理解 schema.org 標記，例如總體上。 Search Console 中的測試工具完全專注於我們可以從結構化數據中提取並用於在搜索功能中顯示的內容。 所以它真的專注於那個故事的搜索部分。 在搜索中，我們只使用了 schema.org 標記的一小部分。 有時，我們的要求略有不同，可能我們需要的特定元素比基本 schema.org 標記所需的要多。 這就是為什麼你經常看到這種差異的原因。 schema.org 驗證器用於理論標記，而 Google 驗證器實際上用於實際的 Google 搜索方面。 “

9:20 “[...]基本上，這不是錯誤。 這是 Search Console 中的警告。 當我在 Search Console 中查看詳細信息時，它只是說你做得不對。 那麼是否有可能的方法[解決問題]，還是我的開發團隊應該解決這個問題？

約翰解釋說：“是的，如果這是一個警告，那我就不用擔心了。 它基本上只是說你可以做一些不同的事情。 […]。 如果您想知道到底有什麼區別，我會做的是仔細檢查developers.google.com上的搜索文檔，我們在其中記錄了所有結構化數據以及所有必需和推薦的字段。 可能是推薦或可選字段之一是觸發此警告的原因。”

頁面可能被抓取但未編入索引的原因

14:11 “ [...] 某些頁面沒有被索引的可能原因是什麼，即使它們被多次抓取？ ”

約翰回答說： “這可能發生。 我認為這不是那麼頻繁，因為通常，當我們決定抓取某些東西時，我們也很樂意去索引它。 但是可能會發生這樣的情況：我們抓取一個頁面，然後最終決定，實際上，我們不需要索引它。

[...] 可能發生這種情況的一些常見情況（可能不適用於您的情況）是頁面上是否有錯誤代碼。 我們得先爬取，然後才能看到錯誤碼。 如果頁面上有noindex ，我們也得先爬取，然後才能看到noindex。 如果頁面是我們已經看到的其他內容的完整副本，那麼我們抓取它，我們看到它是重複的，但我們再次關注主頁面。 所以這些是我們會抓取一些東西而不是索引它的正常情況。 但也有可能我們抓取了一些東西，然後，當我們開始索引時，我們決定，哦，實際上，我們想從網站上獲取其他東西。 ”

15:41 “[...] 還有哪些其他因素 [除了已經提到的] 可能會導致 Googlebot 做出決定，哦，我們最後不想將其編入索引？”

約翰說：“我不知道。 我認為整體網站質量肯定在那裡發揮作用，但通常，如果我們不相信網站質量，那麼我們可能不會首先抓取頁面。 所以，我認為，這是一個棘手的情況。 而且，如果您查看 Search Console，我認為，對於每個站點，您幾乎都會有已發現但未編入索引的分組，以及已抓取但未編入索引的分組。 我認為，這在各個網站上都很常見。”

問這個問題的人想知道除了頁面質量和技術問題之外，他們是否應該考慮其他一些問題。 John 建議他們不要過分關注某一頁，“我也認為不要過度關注那個特定的頁面，這一點很重要。 因此，如果您確定，從技術角度來看，一切正常，我不會認為該特定頁面的質量是一個問題，而是網站該部分的感知質量或整個網站本身。 在這種情況下，我會嘗試查看您可以做些什麼來改進事情，不僅僅是沒有被索引的單個頁面，而是該頁面周圍的更大圖景。 ”

刪除電子商務網站上的產品列表會讓您處於劣勢嗎？

21:48 “所以我們運營一個電子商務網站，我們現在正處於一個階段，我們希望對我們的類別頁面進行重大更新。 […] 在一份草案中，我們希望擺脫產品列表。 因此，您擁有帶有分面搜索的產品列表，您可以在其中過濾您正在尋找的產品。 [...] 當我們刪除類別頁面的整個產品列表時，我們是否會在排名中處於劣勢，因為首先，所有其他競爭對手都有這些類型的產品列表？ 其次，我猜這是電子商務頁面的一個既定元素，用戶希望 [...] 對所有產品有某種概述，過濾器讓他們搜索他們想要的產品。 ”

約翰回答說：“從 SEO 的角度來看，我不會看到任何問題。 我認為您需要注意不同的事情，[...] 這樣我們仍然可以找到我們在那裡有乾淨鏈接的所有單個產品。 但是，如果您只是重新設計此類別頁面並使其看起來更像是一個信息頁面，那麼我預計不會有任何問題。 我也不認為我們對搜索中的那些類別頁面做任何特別的事情，所以從這個角度來看，你只是在改變設計，本質上。  

我認為如果它是一個產品頁面會有所不同，而您要完全改變它，因為我們確實會嘗試識別產品頁面並找出價格在哪裡，可用性在哪裡，諸如此類。 如果你讓它看起來完全不同 [...]，那麼我可以想像這會影響我們如何選擇產品頁面，以及我們是否可以在產品搜索結果中顯示它。 但是，據我所知，類別頁面並沒有對它們做任何特別的事情。 因此，如果您基本上隱藏它們，並確保我們仍然可以找到產品的鏈接[...]，您可以這樣做。 但如果你想通過提供更多關於它們的信息來使它們更有用，我認為這是一個好主意。”

在問題的最後，John 補充說，從用戶的角度檢查變化很重要：“[...] 你提到'用戶會感到困惑'。 我會仔細檢查。 因此，從 SEO 方面來看，我認為這非常好，但從用戶方面來說，這可能是你首先要測試的東西。”

內部鏈接結構的重要性

25:18 “如果您有用於麵包屑設置的結構化數據，內部鏈接對 SEO 仍然很重要嗎？”

約翰回答說：“是的，當然。 這是內部鏈接對搜索引擎優化至關重要的地方。 我認為這是您在網站上可以做的最重要的事情之一，以引導 Google 並引導訪問者訪問您認為重要的頁面。 而你認為重要的是完全取決於你。 你可以決定讓你賺最多錢的事情變得重要，或者你可以讓你成為最強競爭對手的事情變得重要，或者你可能是最弱的競爭對手。 通過內部鏈接，您可以真正將注意力集中在這些方向和網站的那些部分上。 這不是您可以用結構化數據代替的東西。

因此，僅僅因為某個頁面上有結構化數據，我不會將其視為正常內部鏈接的替代品。 即使在結構化數據中，您還提供了 URL，我們使用這些 URL 的方式與我們在頁面上使用普通內部鏈接的方式不同。 所以絕對不是hreflang註釋代替國家版本之間的鏈接，或者麵包屑註釋代替網站不同級別之間的鏈接的情況。 您確實應該在網站的不同部分之間擁有正常的 HTML 鏈接。 而且，理想情況下，您不應該只擁有一組基本鏈接，而是應該以戰略性的方式看待它，並思考您最關心什麼，以及如何通過內部鏈接突出它？ ”

產品列表頁面上的多個產品架構

29:50 “對於一個產品listing頁面，我們可以在產品listing頁面上實現多個產品schema嗎？ ”

John 說：“從我們的政策的角度來看，我認為您不應該這樣做，至少在我上次檢查有關結構化數據的政策時，因為對於產品結構化數據，我們真的希望將其應用於主要頁面的元素。 如果您在一個頁面上有多個產品，那麼其中一個並不是頁面的主要元素。 因此，從這個角度來看，您不應該在一個類別頁面上使用多個產品結構化數據元素 [...]。 ”

如果您創建混合語言頁面，您的排名會受到影響嗎？

30:30 “對於使用混合語言的頁面是否有最佳實踐？ 例如，我們在日本的國際學校為日本和非日本家庭提供服務，但我們將主頁上的大部分信息保留為英文。 我們也在日語頁面上添加了支持。 […] 因為我們在現實生活中的交流是混合語言，所以讓主頁反映這種感覺更自然。 如果頁面是故意混合的語言，我們會在搜索中受到懲罰嗎？”

約翰回答說：“我不一定會說在這種情況下會受到懲罰。 但我們確實嘗試了解頁面的主要語言是什麼，這有助於我們了解我們能夠顯示該頁面的查詢類型。 所以，我認為，在這樣的情況下有點棘手。

我們也可以理解頁面上何時有多種語言。 它只是讓我們更容易真正清楚的是，如果有人用英語搜索，這是向他們顯示的正確頁面。 所以我可以想像像主頁這樣的東西，也許混合或輕微混合是有意義的。 如果您有一個主頁作為初級英語，那麼可能包含一些日語元素。 如果您有另一個主要是日語的版本，並且有一些英語元素，那很好。 但這有助於我們真正理解，在大多數情況下，這是一個英文頁面。 如果有人在用英語搜索日本的特定類型的國際學校，那麼我們可以說，好吧，這裡有一段英語內容，我們知道它符合您的需求，並且與您給我們的查詢相匹配。 因此，從這個角度來看，我不一定會說該頁面受到了懲罰，但它使我們的系統更難弄清楚如何正確地對該頁面進行排名。

您可以在這裡考慮的一件事是在 Search Console 中查看哪些查詢將訪問您的網站或您的主頁。 想想如果 Google 不能正確理解語言，哪些查詢可能會受到影響。 很可能，如果大多數人都在搜索您的名字或您學校的品牌，基本上，那可能根本不會受到影響。 另一方面，如果大多數人正在搜索更廣泛的查詢，更通用的查詢，幾乎就像一個與您主頁上的內容相匹配的句子，那麼我可以想像您在搜索結果中出現的難度會更大一些，只是因為我們不確定您的主頁是否實際上是該查詢的那種語言 [...]。

您還可以做的一件事，[...] 是讓您的主頁成為這種雙語版本 [...]，但要另外為單個語言創建單獨的頁面，以便如果有人正在尋找有關國際學校的長格式信息，例如這樣，他們仍然可以找到那些純英文或主要是英文的頁面，然後從那裡過渡到您網站的其餘部分 [...]。

移動版和桌面版的內容差異

34:20 “如果手機版和桌面版的內容有差異，是谷歌會懲罰網站，影響網站排名，還是說谷歌bot在手機版能找到，但贏了'不能排名？ ”

John 說：“因此，在大多數情況下，我們將大部分索引轉移到移動優先索引，這意味著我們只會在這種情況下查看網站的移動版本。 因此，從本質上講，如果網站的桌面版本有一些細微的不同，我們在大多數情況下甚至不會將其用於搜索。 所以我們並不是因為不同而懲罰一個網站，而是，就像，我們只看網站的一個版本，我們甚至不知道另一個版本上有什麼不同的對待它.  

而對於少數仍在桌面索引中的網站，情況正好相反。 當然，如果移動版本中有 [...] 某些東西不在桌面版本上，並且您正在被桌面爬蟲索引，那麼我們就不會真正看到。 我們會不時抓取備用版本，但我們不會抓取它來獲取更多信息，而只是為了確認桌面 URL 和移動 URL 之間存在這種聯繫。 ”

您可以在雲中託管您的站點地圖嗎？

46:20 “我們有一個非常大的頁面，其中包含數百萬個 URL，並且 [...]站點地圖目前正在翻新。 我們的 IT 團隊正在考慮將 [...] 新站點地圖文件存儲在我們的雲服務中。 這意味著從 example.com/sitemaps 到 cloud.com/sitemaps。 我們想知道，如果我們將站點地圖存儲在雲中會不會有問題？ 如果這不是問題，我們是否還應該為這個 example.com/sitemap 的舊 URL創建一個永久重定向，或者我們應該如何計劃移動？ ”

John 說：“絕對可以將站點地圖文件託管在其他地方。 有兩種方法可以做到這一點。 一種是，如果您在 Search Console 中驗證了這兩個域，那麼就可以了。 另一種方法是，如果您使用 robots.txt 文件提交它，您可以在其中指定“站點地圖：”，然後指定站點地圖的 URL。 這也可以轉到不同的域。 [...] 我也會將舊站點地圖文件重定向到新位置以保持乾淨，但可能即使您只是刪除舊站點地圖 URL 並確保正確提交新的，那麼這應該可以正常工作。  

可能有點棘手的是我不知道 Search Console 將如何直接在 UI中顯示，特別是如果站點地圖文件位於不同的位置，如果 Search Console 會在索引報告中顯示站點地圖信息，例如。 但這是一個報告問題。 這不依賴於站點地圖文件的功能。 這實際上只是 Search Console 沒有正確顯示它。 而且，也許它確實如此。 我只是不是 100% 確定。 ”

域的歷史會影響您的網站嗎？

49:40 “[…]所以 [在之前的 SEO 辦公時間] 我們提出了關於具有護送服務提供商歷史的域的問題。 [...] 該域歷史悠久，因為該網站的第一個快照是從 1997 年開始的。[...] 我們於去年 6 月重新啟動了我們的網站 [...]。 我們遇到的主要問題是 [...] 我們仍然被標記為 [作為成人內容]。 此外，我們有這個問題 […] – 已爬網，目前未編入索引。 我們正在嘗試了解域的歷史是否真的會影響我們在索引方面遇到的問題。 [...] 我們確實相信我們發布的內容質量很好。 它是內部鏈接的，我們嘗試建立一個高質量的網站。 我們目前掙扎的地方是頁面性能，因此目前正在為此進行優化。 但是我們使用prerender.io ，所以我們為 Google 展示的已經是預渲染版本。 所以當談到我們的燈塔分數時，一切都很好。 [...] 我們可以改進或尋找什麼來理解為什麼我們沒有被索引？ 我也很高興分享 URL。 “

約翰表示他可以稍後再看一下這個網址，然後他回答說：“通常情況下，事物的索引方面與之前網站上是否存在成人內容無關。

如果之前的內容非常垃圾，索引方面可能會受到影響。 因此，從索引的角度來看，這可能需要一段時間才能弄清楚，哦，這個新網站實際上根本不是垃圾郵件。

但如果純粹是以前那裡有成人內容，那麼我可以想像我們的安全搜索過濾器在識別這一點方面可能有點慢。 我確實知道我們已經採取了一些措施來加快速度 [...]，或者安全搜索上可能還有其他一些東西有點堅持。

如果您進行站點查詢，然後打開和關閉安全搜索，您可以檢查安全搜索端。 您應該能夠看到 SafeSearch 是否發生了某些事情。 但是，您在索引方面看不到這一點。 但我可以稍後再看一下，我們可以看看是否有一些非常明顯的事情我可以讓你知道。 ”