SEO 辦公時間，2022 年 7 月 1 日
已發表: 2022-07-19這是2022 年 7 月 1 日Google SEO Office Hours與John Mueller的最有趣問題和答案的摘要。
PageSpeed Insights 或 Google Search Console ‒ 哪個更準確？
0:44 “當我在我的網站上查看我的 PageSpeed Insights 分數時，我看到了一個簡單的數字。 為什麼這與我在 Search Console 和 Core Web Vitals 報告中看到的不符？ 這些數字中哪一個是正確的？”
根據 John 的說法：“[...]在速度方面沒有正確的數字 ‒在了解您的網站如何為您的用戶執行時。 在 PageSpeed Insights 中，默認情況下，我相信我們會顯示一個從 0 到 100 的分數，這是基於許多假設，我們假設不同的事情對用戶來說有點快或慢一點。 在此基礎上，我們計算一個分數。
在 Search Console 中，我們有Core Web Vitals 信息，它基於速度、響應能力和交互性三個數字。 當然，這些數字略有不同，因為它是三個數字，而不僅僅是一個數字。 但是，這些數字的確定方式也有很大的不同。 即，所謂的現場數據和實驗室數據之間存在差異。
現場數據是用戶訪問您的網站時看到的內容。 這就是我們在 Search Console 中使用的。 這也是我們用於搜索的內容。 而實驗室數據是您網站的理論視圖，我們的系統在他們認為的地方有某些假設，好吧，普通用戶可能是這樣的，使用這種設備，並且可能使用這種連接。 基於這些假設，我們將估計這些數字對於普通用戶來說可能是多少。 你可以想像這些估計永遠不會 100% 正確。
同樣，用戶看到的數據也會隨著時間的推移而變化，其中一些用戶可能擁有非常快速的連接或快速的設備，並且在他們的網站上或當他們訪問您的網站時一切都進行得很快，而其他用戶可能不會有那個。 正因為如此，這種變化總是會導致不同的數字。
我們的建議通常是使用字段數據，即您會在 Search Console 中看到的數據，作為了解我們網站當前情況的一種方式，然後使用實驗室數據，即您可以運行的個別測試直接自己，優化您的網站並嘗試改進。 當您對通過新版本網站獲得的實驗室數據感到非常滿意時，隨著時間的推移，您可以收集自動發生的現場數據，並仔細檢查用戶是否認為它更快或響應速度也更快。
因此，簡而言之，當涉及到任何這些指標時，再一次沒有正確的數字。 […] 但是，相反，有不同的假設和不同的數據收集方式，而且每一種都略有不同。”
為什麼 Googlebot 難以為基於 JavaScript 的頁面編制索引？
4:19 “我們有一些使用 Next.js 的客戶頁面，沒有 robots.txt 或站點地圖文件。 理論上，Googlebot 可以訪問所有這些頁面，但為什麼只有主頁被索引？ Search Console 中沒有錯誤或警告。 為什麼 Googlebot 找不到其他頁面？”
John 說，“[...] Next.js 是一個 JavaScript 框架，這意味著整個頁面都是用 JavaScript 生成的。 但是，對於所有這些問題，例如，為什麼 Google 不將所有內容都編入索引，首先要說的是， Googlebot 永遠不會索引整個網站上的所有內容，這一點很重要。 我不認為谷歌會關閉並完全索引所有內容的任何非平凡大小的網站都會發生這種情況。 從實際的角度來看，不可能為整個網絡上的所有內容編制索引。 因此，理想情況是所有內容都已編入索引的假設——我將把它放在一邊，並說您希望 Googlebot 專注於重要頁面。
不過，另一件事變得更清楚了，我認為，當這個人在 Twitter 上聯繫我並向我提供有關他們網站的更多信息時，網站生成指向其他頁面的鏈接的方式是以穀歌無法接受的方式。 因此，特別是使用 JavaScript，您可以獲取 HTML 頁面上的任何元素，並說，如果有人點擊它，則執行這段 JavaScript。 例如，那段 JavaScript 可以導航到不同的頁面。 而且Googlebot 不會點擊所有元素來查看發生了什麼，而是我們會去尋找正常的 HTML 鏈接，這是您鏈接到網站上各個頁面的傳統、正常的方式。
而且，使用這個框架，它不會生成這些普通的 HTML 鏈接。 因此，我們無法認識到還有更多要抓取的內容，更多要查看的頁面。 這是您可以通過實現 JavaScript 站點的方式來解決的問題。 我們在搜索開發者文檔網站上有大量關於 JavaScript 和 SEO 的信息，特別是關於鏈接主題的信息，因為它時不時出現。 有很多創造性的方法可以創建鏈接，而 Googlebot 需要找到這些 HTML 鏈接才能使其工作。 […]”
除了 Google 官方文檔，請查看我們博客上的 JavaScript SEO 終極指南。 “
鏈接到 HTTP 頁面是否會影響您網站的 SEO？
7:35 “如果我的頁面鏈接到外部不安全的網站，是否會對我的 SEO 得分產生負面影響？ 所以在 HTTP 上，而不是 HTTPS。”
約翰說，“首先，我們沒有 SEO 分數的概念，所以你不必擔心 SEO 分數。
但是，無論如何，我理解的問題是：如果我鏈接到 HTTP 頁面而不是 HTTPS 頁面會很糟糕。 而且，從我們的角度來看，這完全沒問題。 如果這些頁面在 HTTP 上，那麼這就是您要鏈接的內容。 這就是用戶期望找到的。 沒有什麼反對鏈接到這樣的網站。 避免鏈接到 HTTP 頁面對您的網站沒有任何不利之處，因為它們很舊或很硬，而且不像 HTTPS 那樣酷。 我不會擔心這個。”
你應該刪除你的拒絕文件嗎？
10:16 “在過去的 15 年裡，我總共拒絕了超過 11,000 個鏈接。 […] 我拒絕的鏈接可能來自被黑網站或來自無意義的自動生成內容。 由於谷歌現在聲稱他們有更好的工具可以不將這些類型的黑客或垃圾鏈接納入他們的算法，我應該刪除我的拒絕文件嗎？ 刪除它有什麼風險或不利之處嗎？”
約翰回答說：“[...] 拒絕鏈接始終是那些棘手的話題之一，因為感覺 Google 可能沒有告訴你完整的信息。
但是，從我們的角度來看，[...] 我們確實努力避免將這些鏈接考慮在內。 我們這樣做是因為我們知道 Disavow 鏈接工具在某種程度上是一種利基工具，SEO 也知道它，但運營網站的普通人對此一無所知。 您提到的所有這些鏈接都是任何網站多年來獲得的那種鏈接。 我們的系統明白，這些不是你試圖做的事情來玩弄我們的算法。
因此，從這個角度來看，如果您確定在這些鏈接方面沒有任何您必須解決的手動操作，我會刪除拒絕文件並 [...] 將所有這些放在一邊。 我個人會做的一件事是下載並製作副本，以便您記錄刪除的內容。 但是，否則，如果您確定這些只是來自 Internet 的正常、硬皮的東西，我會刪除它並繼續前進。 當涉及到網站時，除了否認這些發生在網絡上任何網站上的隨機事情之外，還有更多的時間可以花在網站上。”
用 robots.txt 或 robots 元標記阻止抓取會更好嗎？
14:19 “哪個更好：使用robots.txt阻止或使用頁面上的機器人元標記？ 我們如何最好地防止爬行？”
約翰：“[……]我們最近也做了一個關於這個的播客節目。 所以我會檢查一下。 […]
在實踐中，這裡有一個細微的區別，如果您從事 SEO 並且您使用過搜索引擎，那麼您可能已經理解了這一點。 但對於該地區的新手來說，有時不清楚所有這些線路的確切位置。
使用您在問題中提到的第一個 robots.txt，您可以阻止抓取。 因此，您甚至可以阻止 Googlebot 查看您的網頁。 借助 robots 元標記，當 Googlebot 查看您的網頁並看到該機器人元標記時，您可以執行諸如阻止索引之類的操作。 在實踐中，這兩種方法都會導致您的頁面沒有出現在搜索結果中，但它們略有不同。
所以如果我們不能爬行，那麼我們就不知道我們錯過了什麼。 我們可能會說，實際上，有很多對這個頁面的引用。 也許它對某些東西有用。 我們不知道。 然後該 URL 可能會出現在搜索結果中而沒有任何內容，因為我們無法查看它。 而對於 robots 元標記，如果我們可以查看頁面，那麼我們可以查看元標記並查看其中是否有 noindex，例如。 然後我們停止索引該頁面，然後我們將其完全從搜索結果中刪除。
因此，如果您想阻止抓取，那麼 robots.txt 絕對是您的最佳選擇。 如果您不希望該頁面出現在搜索結果中，那麼我會選擇您更容易實現的那個。 在某些網站上，設置一個複選框表示我不希望在搜索中找到此頁面會更容易，然後它會添加一個 noindex 元標記。 在其他人身上，也許編輯 robots.txt 文件更容易。 [這]取決於你在那裡擁有什麼。”
您可以在多個站點地圖文件中放置相同的 URL 嗎？
16:40 “在您的 XML 站點地圖中包含具有不同屬性的重複 URL 是否有任何負面影響？ 例如，一個站點地圖中的一個 URL 帶有 hreflang 註釋，而另一個站點地圖中的相同 URL 沒有該註釋。”
約翰說：“[……]從我們的角度來看，這完全沒問題。 […] 這種情況時不時發生。 有些人在站點地圖文件中有hreflang註釋，專門分開，然後他們也有一個普通的站點地圖文件。 那裡有一些重疊。
從我們的角度來看，我們會盡可能處理這些站點地圖文件，並將所有這些信息都考慮在內。 在多個站點地圖文件中使用相同的 URL 沒有缺點。
我唯一要注意的是，這些站點地圖文件中沒有相互衝突的信息。 因此，例如，如果使用 hreflang 註釋，您說這個頁面是針對德國的，然後在另一個站點地圖文件上，您會說，其實這個頁面也是針對法國的，[…] 那麼我們的系統可能就像，嗯，這裡發生了什麼？ 我們不知道如何處理這種混合註釋。 然後我們可能會選擇其中一個。
同樣，如果您說此頁面上次更改是 20 年前 [...]，而在另一個站點地圖文件中，您會說，實際上，是五分鐘前。 然後我們的系統可能會說，你們中的一個人是錯的。 我們不知道是哪一個。 也許我們會遵循其中一個。 也許我們會完全忽略最後一次修改日期。 所以這是要注意的事情。
但除此之外，如果它只是提到了多個站點地圖文件，並且信息要么是一致的，要么是一起工作的，因為可能一個有最後修改日期，另一個有 hreflang 註釋，那很好。”
如何防止嵌入的視頻頁面被索引？
19:00 “我負責一個視頻回放平台，我們的嵌入有時是單獨索引的。 我們怎樣才能防止這種情況發生？”
John 回答說：“[...] 我查看了該網站，這些 iframe 包含一個簡化的 HTML 頁面，其中嵌入了視頻播放器。
從技術的角度來看，如果一個頁面有 iframe 內容，那麼我們就會看到這兩個 HTML 頁面。 我們的系統有可能同時索引了這兩個 HTML 頁面，因為它們是單獨的 HTML 頁面。 通常，一個包含在另一個中，但理論上它們也可以獨立存在。
有一種方法可以防止這種情況發生，這是一種相當新的與 robots 元標記的組合，您可以使用indexifembedded robots 元標記和noindex robots 元標記。
在嵌入式版本上，直接在其中包含視頻的 HTML 文件，您將添加 noindex 和 indexifembedded 機器人元標記的組合。 這意味著如果我們單獨找到該頁面，我們會看到有一個 noindex [標籤]。 我們不必為此編制索引。
但是使用 indexifembedded，它告訴我們 [...] 如果我們在一般網站中找到嵌入視頻的頁面，那麼我們可以索引該視頻內容，這意味著單個 HTML 頁面不會被索引。 但是帶有嵌入和視頻信息的 HTML 頁面會被正常索引。 這就是我將在那裡使用的設置。 這是一個相當新的機器人元標記，所以不是每個人都需要它。 因為這種 iframe 內容或嵌入內容的組合很少見。 但是，對於某些網站來說，這樣做是有意義的。”