SEO 辦公時間,2022 年 1 月 21 日
已發表: 2022-01-26這是2022 年 1 月 21 日Google SEO Office Hours與John Mueller的最有趣問題和答案的摘要。
內部鏈接的價值
00:44 “頁眉、頁腳或內容中的內部鏈接值是否不同?”
根據約翰的說法,“這非常相似。 我認為頁面不同部分的內部鏈接沒有任何可量化的不同。 我認為當涉及到頁面不同部分的內容時,我們試圖找出頁面的獨特之處是不同的。 但關於鏈接,我不認為那是什麼。”
抓取問題
03:33 “在 [2021 年 11 月] 之後,谷歌 [Core] 更新了我的網站 [在抓取方面存在一些問題。 有些鏈接[已被抓取,而]有些則沒有。 [...] 我該如何修復 [它]?”
約翰說:“我認為有兩種可能性。 一是可能存在技術問題。 我認為不一定是這種情況 [...] 因為聽起來有些頁面正在正常爬網。
另一個是我們不會一直抓取所有內容。 我們不會將網絡上的所有內容都編入索引,有時我們必須對事物進行優先排序。 [...] 我們試圖了解網站的整體價值是什麼,我們應該在網站上花費多少資源。 這也反映在我們爬了多少。 這可能是您在我們的算法不確定網站整體質量的情況下看到的情況。 幫助提高網站的質量通常最終使我們能夠抓取更多的網站。”
索引頁數下降
05:47 “在過去的一年裡,我們一直在對網站進行大量技術改進,我們的客戶似乎對網站很滿意。 然而,自 10 月底以來,谷歌索引的頁面數量急劇下降了 25% [即] 約 500,000 頁。 我們提交的 […] 下降了 50% 以上。 […] 我們發現 […] 如果產品頁面上沒有評論,架構驗證器會不高興,因為沒有提到評論。 […] 有沒有我們遺漏的東西 […] 或者這實際上足以成為它的核心原因?”
John 回答說: “僅僅因為結構化數據在頁面上不完全有效並不意味著我們會將其從索引中刪除,所以這似乎與我無關。 我想 Search Console 中的報告顯示了所有這些錯誤。 你看著它們,你說,好吧,我不在乎那裡的標記。 這很好。 這並不表示我們認為您的網站不好,因為結構化數據無效。 只是我們想讓您知道,如果您想使用此結構化數據,它不起作用。 但這不會影響抓取、索引或排名。
很難說是什麼原因造成的。 可能是 [...] 我們的系統不確定您網站的整體質量。 當涉及到如此大的網站時,您會在其中查看大量數字,我還會做的一件事是嘗試查看一些示例並嘗試查看,這些數字是否真的反映了實際問題? 還是索引頁面的數量本質上反映了正在清理的技術?
例如,有時,我們會將附加了不同參數(如 Analytics 跟踪參數)的頁面編入索引。 我們很容易突然索引其中的 100,000 個頁面。 它們都已編入索引。 在圖表中,看起來這是一件大事。 但是,如果我們要刪除所有這些頁面,它不會改變您網站的任何內容,因為這些是意外索引的頁面。 所以在圖表中,這可能看起來非常戲劇化,它會上升,所有這些東西都被索引,然後它會下降。 [...] 但可能只是我們的系統正在修復一個不影響您網站其餘部分的索引問題。 我要做的是找出這些問題中的哪些問題正在影響您網站的流量或可見性。 那麼也許索引問題屬於其中,但我會嘗試將其分開。”
09:13 “我們注意到一件事,這是我們第一次看到 Crawled [- current] 未編入索引。 [...] 我們覺得這告訴了我們一些事情,但我們不太確定如何解釋它。”
約翰:“我不認為你可以從中抽離出來。 這兩種狀態,Crawled [‒ current] not indexed 和 Discovered [‒ current] not indexed,它們本質上是等價的,因為我們知道 URL。 我們確認我們已經聽說過它,但我們決定不將其編入索引。 這是我們正在與索引團隊一起尋找解決的問題,這是一個普遍的問題嗎? 因為我們聽到越來越多的關於這方面的報導。 還是它本質上比以前更明顯? 因為即使在過去,我們也只會索引網站的一部分。 但我們從未在 Search Console 中向人們展示過這一點。 我們專注於您獲得的流量,而不是為什麼我們不索引單個頁面。”
已取消索引的頁面與 URL 中的特殊字符
23:56 “我們剛剛發現,從 1 月 13 日開始,我們的索引頁面下降了 90% 以上。 [...] 您能否就我們可以找出哪些方面來確定問題提供一些建議? [...] 當我們檢查樣本時,我們注意到 [Google 抓取的] URL 有一些不尋常的標記,例如問號 [和] URL 中的一些加號,但我們的實際 URL 沒有這些標記。 被發現是一件不尋常的事情。”
John 的回答是:“我認為您可能還想檢查的一個方面是我們是否可以正確抓取它們。 我想你已經調查過了,但在那裡仔細檢查總是好的。”
當談到 URL 中的特殊字符時,John 補充說:“我們總是會發現很多網站的 URL。 如果我們認為它們不重要,我們會將它們保留在我們的列表中,並且在某個時候,我們會嘗試抓取它們。 我懷疑這些只是我們隨著時間的推移發現的隨機 URL。 我們會不時嘗試抓取它們,看看是否有任何我們遺漏的東西,但如果我們還抓取一些隨機 URL,這並不是網站出現問題的跡象。”
談到可能導致這種情況的技術方面,John 說: “通常,主要問題是關於網站的整體質量,這會影響是否為單個 URL 編制索引的決定。 這也是會隨著時間而改變的。 與其說是您網站的質量發生了變化,不如說是我們對網站質量的看法會隨著時間而改變。 這通常是在那裡發揮作用的主要元素。

如果您在短時間內看到這些索引更改發生,那麼可能是我們的系統剛剛改變了我們評估您網站質量的方式,並且突然之間,一切都在一個稍微不同的桶中。 然而,如果您在較長時間內看到它們,那麼 [...] 隨著時間的推移,我們的系統對網站的信心越來越低。”
GSC 屬性和非尾隨索引頁面
33:18 “我們一直在嘗試為我們的一些國家/地區特定文件夾創建 GSC 屬性,以更好地監控它們的性能。 我們不在 URL 上使用斜杠。 所以當新的文件夾屬性添加到 GSC 時,地址會自動添加尾部斜線,對於非尾部版本的索引頁面,不會捕獲並報告任何數據。 有沒有辦法將文件夾添加為 GSC 屬性並捕獲非尾隨索引頁面的統計信息? “
約翰: “不,目前沒有。 從我們的角度來看,末尾沒有斜線的頁面只是一個頁面。 如果它有斜線,那麼它就是一個文件夾,這就是我們用於 Search Console 的模型。 因此,如果您有網站某個部分的主頁並且沒有尾部斜杠,那麼我們會將其視為更高級別網站中的頁面。 在域級別上,您可能會看到所有這些。 如果您希望數據獨立可見,則必須將其從 Search Console 中的更高級別屬性中提取出來。”
從網站的停機時間中恢復
34:29 “我的網站,平均每天大約 200,000 次會話,遇到了技術問題。 就在兩天前,該網站關閉了 14-15 小時。 雖然昨天的流量大致正常,但今天,我們的很多頁面都在 Google 搜索中丟失了。 該網站在過去 8 年中一直很穩定,我們以前從未遇到過這樣的問題。 你有什麼建議嗎? “
John 說:“通常,如果您在短時間內遇到此類技術問題,這些頁面可能會從我們的索引中退出,並且通常它們也會很快重新出現。 通常發生的情況是,我們更經常抓取的頁面可能會首先被拾取並在此技術問題中引起注意。 也許我們在那段時間放棄了它們。 所以你可能會在你的流量中看到這一點,但好消息是這些頁面也往往被頻繁地重新抓取,所以它們[也]應該相當頻繁地重新出現。
防止此問題的最佳方法是確保您有一些系統可以在出現問題時提供 503 結果代碼。 可能是它不會自動觸發,但是即使你可以手動打開這個 503 結果代碼,本質上發生的情況是,當我們在這段時間內抓取頁面並看到 503 時,我們會說有問題這裡。 我們將忽略它,稍後再回來仔細檢查。
本質上,如果您可以在一兩天內提供 503 結果代碼,那麼我們會將其視為臨時故障,並且我們不會從索引中刪除這些頁面,因為我們認為它們仍然存在。 然而,如果您直接提供 404,或者如果您提供一個空頁面或只是一個錯誤頁面,那麼我們可能會假設該頁面已經消失,我們會將其從索引中刪除。
那將是我的建議。 通常情況下,您不能只是在事情出現問題時突然介入並突然想出如何執行 503。所以我會提前準備該系統,以便您可以盡快切換。 [...] 如果您可以提供一兩天的 503,那麼您根本不會在搜索索引中看到任何變化。 如果它更長,那麼顯然你仍然可以,但至少在一兩天內——你受到保護。
如果您不能像在此處那樣執行此操作,我會假設這會自動返回。 我不認為你需要做任何手冊。 我們將重新抓取這些頁面。 我們會再次注意到那裡有很好的內容。 我們將再次對它們進行索引,[...] 拾取我們之前收到的信號。 它本質上應該像以前一樣被索引和排名。 這裡不應該有任何長期問題。”
網站遷移
38:37 “我們希望將一個網站的內容遷移到兩個不同的域並拆分它。 在舊域名的 GSC 中我們應該怎麼做? 我們應該指向哪個域作為收件人? 如何通知 Google?”
John 說:“在這種情況下,您要拆分或合併網站,您不能使用 Search Console 中的地址更改工具,因為它依賴於移動是一對一移動這一事實從一個域到另一個域。 一旦您拆分或合併網站,就不再是一對一的移動,這本質上是必須在每個 URL 的基礎上處理的東西。 因此,對於這些事情,本質上,您要做的只是正確設置重定向。 請遵循我們為網站移動制定的常規準則,並記住 Search Console 的地址更改設置可能不適合那裡。
此外,Search Console 設置將嘗試測試您網站上的一些示例頁面以進行該重定向。 可能看起來一切正常,但我認為如果您要拆分網站,使用該設置仍然是錯誤的。 僅僅因為它可能會稍微混淆信號,我懷疑它會導致問題,但我認為如果您不從一個域移動到另一個域,那麼使用該地址更改工具不會有任何優勢。 ”
內部鏈接和網站結構
51:16 “查看網站重要頁面的內部鏈接是否有意義,看看它們是否有來自其他內部重要頁面的鏈接,以及 [...] 到 [刪除] 到不太重要頁面的鏈接,以便鏈接到重要的頁面更重?”
約翰回答說: “這是你可以做的事情。 這有點棘手,因為我們試圖巧妙地處理內部鏈接。 尤其是一些非常常見的頁面,它們有很多鏈接,比如關於我們頁面或服務條款,它們是從整個網站鏈接的。 但同時,我們理解這是一種正常的模式,並不意味著我們應該為任何正在搜索公司名稱的人對服務條款頁面進行排名。 一方面,您可以控制內部鏈接。 但我不會過分說,好吧,我刪除了指向我認為不重要的頁面的鏈接。 因為當我們引入nofollow 時尤其如此,人們會說,哦,我的服務條款[頁面]——所有鏈接都將指向它。 這不會改變任何事情。 這是很多工作,你必須永遠維護它,但它不會改變你的網站,所以它就像是浪費工作。
但我仍然建議您瀏覽您的網站並嘗試創建一個圖表來說明事物是如何鏈接的。 我認為一些或可能大多數 SEO 工具都有一些能力來抓取網站並創建此圖 [...] 以顯示網站的結構。 當你看到它時,有時你可以第一眼看到它的結構是乾淨的還是完全凌亂的? 如果它完全一團糟,那麼我認為還有空間來清理它並明確結構應該是什麼。
通過制定更清晰的結構,您可以幫助我們了解您認為哪些頁面更重要,因此我會嘗試尋找清理的方法。 我並不是說如果你有一個乾淨的結構你的網站排名會更好,但如果我們了解你的網站應該在這個範圍內排名[以及]這些頁面中哪些是最重要的,那就更重要了。 這就是您在那兒告訴我們的 [...] 並為您帶來價值,並且您正在將人們發送到您關心的頁面。 這當然是我會考慮做的事情。”
55:03 “很容易計算的內部PageRank呢? 您會建議這樣做以查看哪些頁面確實從內部鏈接中獲得最大權重,還是您會說這是沒有必要的?”
John 回答說: “[...] 你無法在其中建模的方面是各個頁面將獲得不同的外部鏈接,這從本質上也會影響內部 PageRank。 如果每個人都鏈接到您的服務條款頁面,那麼它突然之間就會有很多 PageRank。 PageRank 是我們在系統中使用的東西,但我們使用了很多其他的東西。 從技術角度來看,這是一個有趣的小工具,但從實際角度來看,我不會認為它是超臨界的。 你更想弄亂數字和玩圖表——當然你可以計算出來。 我不認為這是在谷歌一對一反映的東西。”
