SEO 辦公時間 – 2021 年 10 月 8 日
已發表: 2021-10-15這是2021 年 10 月 8 日Google SEO Office Hours與John Mueller的最有趣問題和答案的摘要。
索引頁面數與站點權限
03:52 “因此,您過去曾多次建議大型網站 [...] 專注於較小的頁面集 [...]。 我現在正在處理的網站,我們有 [...] 大約 1,000 個沒有任何流量的頁面,這些頁面很舊,所以我一直建議刪除這些頁面。 但是我們的開發團隊有一個問題,他們的印像是,Google 為您的網站編制索引的頁面越多,它賦予該網站的權限就越高,並且不願刪除任何頁面。 你能解釋一下嗎?”
正如 John 所說, “如果您有更多的頁面被索引,我們絕對不會認為您的網站更好。 [...] 有時,將大量頁面編入索引是有意義的。 有時,它們是一種有用的頁面,可以像這樣被索引。 但這並不是關於被索引的頁面數量的質量標誌。 尤其是如果您談論的是 [...] 1,000、2,000、5,000 頁,這對於我們的系統來說總體上是一個相當低的數字。 我們並不是說 5,000 頁優於 1,000 頁。 對我們來說,這有點像,嗯,它是一個小網站,我們會盡我們所能。 當然,小型網站是相對的。 這不像說它是一個無關緊要的網站。 它可能很小,但可能仍然非常有用 [...]”。
評估網站的主要目的
10:03 “上次我們談到了網站的一些問題 [...] – 這是一個電子商務網站,我們有信息和交易的東西。 [...] 您的建議是將這些內容稍微分為面向事務的頁面和麵向信息的頁面。 所以我對此還有另一個問題。 如果你有,比如說,一個電子商務網站,你有一個巨大的博客,或者雜誌,或者類似的東西,你有大量的信息,但它是一個舊的部分。 另一方面,您擁有所有這些產品頁面和類別等。 那麼這個包含純信息內容的巨大塊是否會給整個網站一種信息觸摸或字符,以便谷歌說,哦,我們不確定這是否是 [...] 人們可以獲取信息而不是購買東西的東西,或者是這個評估是在每頁的基礎上進行的嗎?”
John 說:“[...] 我的理解是,這更像是一個頁面級別的事情。 [...] 很多網站只是混合了不同種類的內容。 然後,您嘗試找出這些頁面中的哪些與搜索者的意圖相匹配,並嘗試對它們進行適當的排名。 […]
我的意思是,你經常在新聞網站上看到這一點。 […] 他們有最近的事件,但他們也有發生的舊事件的部分,或者 […] 對於其他重大事件,他們有一個獨立的存檔部分。 如果您真的想要正在發生的事情,或者您想要某種信息研究,常青類型的內容,那麼這些是非常不同的意圖。
[...]我們必須逐頁查看它,而不是說,哦,這是一個研究網站,因為這裡有一些研究內容”。
鏈接重定向
13:21 “我們看到人們正在鏈接到 [...] 我們的頁面子類別。 問題是 […] 我們的內容來來去去,這意味著有時,某些類別中會出現更多內容。 有時,內容會被刪除。 因此子類別可以創建也可以消失。 我們看到大量來自反向鏈接的推薦,因為它們鏈接到不再存在的子類別。 我的問題是:是否可以將 [...] 這些鏈接重定向到父類別。 如果我們這樣做,我們如何做到這一點——例如 302? 就像臨時重定向一樣,因為將來這個子類別可能會再次填充內容,[...] 這不是永久重定向”。
John 回應說:“因此,如果我們看到這種情況發生在更大的範圍內,並且您重定向到父級別,我們可能會將其視為軟 404。[...] 而不是 404 代碼,您正在重定向,也許這就是對用戶來說更好,但我們將其視為 404。[...] 如果從用戶的角度來看重定向是有意義的,那麼我會選擇它。
[...] 關於 301 或 302,我認為這並不重要,因為我們要么將其視為軟 404,要么將其視為規範化問題。 如果是軟 404,則代碼無關緊要。 如果這是一個規範化問題,那麼它歸結為我們在搜索結果中顯示的 URL。 而且通常情況下,更高級別的信號無論如何都會更強,我們將專注於更高級別的信號。 因此,在這種情況下,是 301 還是 302 都沒關係。
[...] 如果我們將其視為軟 404,[...] 我們會減慢該特定 URL 的抓取速度,因為這裡沒有任何內容 [...]。 如果我們將其視為重定向 [...],我們不需要每天都抓取它,因為我們專注於主 URL。 所以我認為在這兩種情況下,我們都會放慢對該 URL 的抓取速度,直到我們得到新的信號來告訴我們,實際上,這可能又是新事物了。 [...] 這就像內部鏈接或站點地圖文件 [...]。 這將是我們再次爬行的更強信號。 但我認為在所有這些情況下,爬行速度的放緩都是相似的。
[...]我認為僅 [更新] 站點地圖可能還不夠。 我真的會確保內部鏈接也很清晰”。
從核心更新中恢復
18:34 “所以大約一年前,我們看到流量顯著下降。 審核後,[…] 所有信號都表明該站點存在站點質量問題。 我們能夠在今年 2 月之前解決這些問題。 到了 6 月的核心更新,我們看到了一些增長。 但這仍然沒有達到大約一年前下降之前的水平。 所以我的問題是站點質量問題,如果是這樣的話,這是我們可以預期的恢復嗎,或者如果我們認為我們已經解決了所有已確定的問題,我們是否可以期待更多的恢復[...]?”
約翰說:“[……] 我們不會認為這是一種你必須解決問題的情況。 而是 [...] 如果您致力於提高網站的相關性,那麼 [...] 您將擁有一個更好的網站。 所以這並不是說 [...] 我們會將其更改回之前的狀態。 [...] 它與以前不同或不相似,因此期望它更改為之前的狀態會有點棘手 [...]。
[…]通過核心更新,我們不再關注個別問題,而是關注網站整體的相關性。 這可能包括可用性和頁面上的廣告等內容,但它本質上是整個網站。 通常,這也意味著內容的焦點、呈現事物的方式、向用戶明確內容背後的內容的方式,例如來源是什麼 […]。 如果您真的希望 Google 將您的網站視為更好的東西,您可能還需要在內容方面工作。
[...] 想想哪裡可能有低質量的內容,用戶在訪問我的網站時可能會感到困惑。 我們可以通過技術問題和用戶體驗更改來解決這種混亂嗎? 還是我們真的必須改變我們呈現的一些內容?”
來賓帖子中的鏈接
28:24 “[...] 如果 [網站有] 訪客帖子,而 Google 不知道它是否已付費,那麼 Google 將如何確定 [他們應該] 獲取此鏈接或銷毀此鏈接? 答案是什麼,所以我們從各個角度都是安全的?”
根據約翰的說法,“[...]我們對鏈接和訪客帖子的指導是,它們應該是禁止關注的。 [...] 我真的要注意確保鏈接不被關注,這樣您就可以提高意識,您正在談論您在做什麼,您正在製作它以便用戶可以訪問您的頁。 但從本質上講,它是為您的企業投放的廣告。 所以從這個角度來看,我只會讓他們不關注”。
產品價格作為排名因素
32:25 “如果有兩個競爭的電子商務網站銷售完全相同的產品——一個網站以 500 美元的價格提供產品,另一個以 100 美元的價格提供產品,那麼所有 SEO 信號都是相同的。 價格較低的網站是否會有更好的排名機會,因為完全相同的產品存在如此大的價格差異?”。

約翰說:“所以純粹從網絡搜索的角度來看,不。 我們不會嘗試識別頁面上的價格並將其用作排名因素。 因此,我們不會說我們會選擇更便宜的並排名更高[...]。
但是,其中很多產品也以產品搜索結果的形式出現,這可能是因為您提交了提要,也可能是因為我們識別了這些頁面上的產品信息。 還有產品搜索結果,不知道是怎麼排序的。 可能是他們考慮了價格或可用性等因素[...]。
所以從網絡搜索的角度來看,我們不考慮價格。 從產品搜索的角度來看,這是可能的。 我認為棘手的部分是,作為 SEO,搜索的這些不同方面通常組合在一個搜索結果頁面中,您會在其中看到正常的網絡結果,也許您會在旁邊看到一些產品結果,或者也許你會看到一些混合的[…]”。
在站點地圖之間移動 URL
34:04 “如果我們有 200 個站點地圖文件,並且每周有 20% 到 30% 的 URL 從一個文件跳轉到另一個文件,那會有多糟糕? 還是我們應該永遠嚴格地將我們的 URL 保存在同一個文件中?”
“[...]我們的建議通常是在同一個站點地圖文件中保留相同的 URL 。 主要原因是我們以不同的速率處理站點地圖文件。 因此,如果您將一個 URL 從一個站點地圖文件移動到另一個,可能是我們的系統中有來自多個站點地圖文件的相同 URL。 如果您對這個 URL 有不同的信息——例如不同的更改日期——那麼我們將不知道實際使用哪個屬性。
所以從這個角度來看,如果你總是把它放在同一個站點地圖文件中,那麼我們就更容易說,哦,我們在這裡有這個 URL 的信息,我們可以相信這些信息,因為它只在那裡。 所以這就是我試圖避免 [...] 這些 URL 隨機移動的地方。 但與此同時,它通常不會中斷對站點地圖文件的處理。 而且它絕對不會對您的網站產生排名影響。 所以在我們的站點地圖系統中沒有任何東西可以映射到網站的質量”。
多區域內容
38:13 “我在新聞垂直行業工作。 我的團隊正在尋求擴大我們的國際影響力,並已完成建立多區域子目錄的工作。 在大多數情況下,不同多區域版本的頁面看起來是一樣的。 主頁和部分頁面(如政治或生活方式)將具有相似的內容,但會減去該地區獨有的一些內容。
文章很棘手。 在具有相關鏈接的模塊之外,我們無法區分多區域子目錄,這讓我們擔心重複內容問題。 Google 如何處理新聞空間中的重複內容? [...] 內容保持不變,但模板的元素不同。 所有多區域網站都應該只有一個規範嗎?”
John 的回答是:“[…] 聽起來這些是同一個國家的不同地區,而且是相同的語言內容。 […] 如果這些是不同的國家,那麼你就有了地理定位方面的問題,如果這些是不同的語言,它就會發揮作用。 因此,如果你在歐洲工作,並且覆蓋德國、法國、意大利或其他地方,那麼你也會有不同的語言。
[...] 但是,如果您在同一個國家/地區談論相同的語言內容,那麼 [...]會更容易一些,因為您不必擔心所有這些技術聯繫。 但另一方面,重複內容問題更加明顯。 而當涉及到重複內容時,像這樣的網站上的棘手方面是你最終最終會與自己競爭。 如果您在 [...] 五六個不同的區域網站上發布一篇新聞文章,那麼所有這些不同的區域網站都會嘗試對完全相同的文章進行排名。 這可能會導致該文章的排名不如其他情況。
因此,我建議嘗試為這些單獨的文章找到規範的 URL,這樣你就可以真正地說‘好吧,我在我的五個區域網站上有一篇文章,但這是我希望看到的首選版本搜索'。 然後我們可以將所有的精力、所有的信號集中在一個更喜歡的版本上,我們可以嘗試對那個版本進行更好的排名。 它不必總是相同的版本。 因此,絕對可以有一篇新聞文章在一個區域內是規範的,而另一篇新聞文章對於另一個區域更規範。 如何選擇哪個區域作為規範完全取決於您。 [...] 通常,您會嘗試找出最相關的地方,然後選擇那個作為規範版本。 這是針對個別文章本身的。
對於類別、部分和主頁,似乎內容更獨特,更具體到各個地區。 因此,我會嘗試將這些索引級別分開。 因此,如果您有五個不同的區域網站、它們的主頁、它們的類別部分,它們都會被單獨編入索引。 新聞文章本身將映射到這些不同區域之一。 這就是我們推薦的一種方法 […]。
這種方法也 [...] 適用於不同的域名。 因此,如果您在各個地區有不同的域,但它們都是同一個新聞組的一部分,您仍然可以在不同版本之間進行這種規範轉換。 如果您在具有子目錄的同一域中執行此操作,那也很好”。
網站移動中的重定向
44:34 “當您必須 301 將所有 URL 重定向到一組新 URL 時,最好的做法是什麼? 頁面數量將超過一百萬,您想最小化沙盒效應嗎? 如果有沙盒效應,能持續多久? 我們會失去可能永遠無法恢復的排名嗎? 我們計劃進行一對一重定向,並已請求批量重定向,但這是不可能的,因此頁面、圖像、URL等必須同時翻轉”。
正如 John 所說:“對我來說,這聽起來像是傳統的網站遷移情況。 您從一個域移動到另一個域,並將所有 URL 從舊站點重定向到新站點,我們必須處理這個問題 […]。 在站點移動方面,我們絕對沒有任何定義為沙盒效應。 因此,如果您必須進行站點移動,請進行站點移動,並重定向您的所有頁面。 通常最簡單的方法就是一次重定向所有頁面。 我們的系統也對此進行了一些調整,以嘗試識別這一點。 因此,當我們看到一個網站開始將所有頁面重定向到不同的網站時,我們會嘗試更快地重新處理它,以便我們可以盡快處理該網站的移動。 我們絕對不會說,哦,他們正在做一個網站遷移,因此,我們會放慢速度[...]”。
API 和爬取預算
46:13 “我有一個網站,它連接到客戶端的 API 以獲取數據。 這些網址是否包含在抓取預算中? 如果您禁止這些 URL,[...] 會產生任何問題嗎?”
“[...] 如果在呈現頁面時包含這些 API,那麼是的,它們將包含在抓取中,並且它們將計入您的抓取預算,本質上是因為我們必須抓取這些 URL 以呈現頁面。 如果您希望它們在渲染期間不被抓取或不使用,您可以通過 robots.txt 阻止它們。 如果您喜歡這樣做,完全取決於您。 尤其是如果您有一個維護成本高或占用大量資源的 API,那麼有時這是有道理的。
我想,棘手的部分是,如果您禁止抓取您的 API 端點,我們將無法使用有關 API 返回的任何數據進行索引。 因此,如果您的頁面內容純粹來自 API,並且您禁止抓取 API,我們將不會有該聯繫人。 [...] 如果 API 只是對頁面做一些補充,比如繪製地圖或 [...] 您在頁面上擁有的數字表格的圖形,[...] 那麼也許該內容是否是無關緊要的'不包含在索引中。 另一件事是,有時,當 API 被阻止時,頁面的運行方式並非易事。 特別是,如果您使用 JavaScript 並且 API 調用因為 robots.txt 而被阻止,那麼您必須以某種方式處理該異常。 並且根據您在頁面上嵌入 JavaScript 的方式、您對 API 所做的操作,您需要確保它仍然有效。 因此,如果該 API 調用不起作用,然後頁面的其餘部分渲染完全中斷,那麼我們就無法索引太多,因為沒有任何東西可以渲染。
但是,如果 API 調用中斷,我們仍然可以索引您頁面的其餘部分,那麼這可能非常好。 [...] 我認為如果您為其他人運行 API 會比較棘手,因為如果您不允許抓取,那麼您就會產生這種二階效應,即其他人的網站可能依賴於您的 API。 取決於你的 API 做什麼,突然間,他們的網站沒有可索引的內容。 他們甚至可能沒有註意到,因為他們沒有意識到你突然在那裡添加了一個不允許。 這可能會導致類似的間接影響 […]”。
JavaScript 和谷歌緩存
49:36 “所以有兩個頁面來自同一個域。 URL 有點不同,它是相同目錄結構的一部分。 而且 [...] 它們是由 NextJS 生成的。 所以 NextJS 是一個服務端渲染的 React 框架。 它們正在被索引,但我在 Google 緩存中看到一頁,而第二頁不在 Google 緩存中。 無論我如何生成頁面 [...],我都會看到相同的模式。 我的大部分頁面都在 Google 緩存中,但現在我很擔心,因為我目前正在從生成所有這些頁面的基於 Java 的技術堆棧轉移到 Google NextJS。 [...] 當我調試時,我發現這也是我們使用的舊 Java 堆棧的問題。
所以問題是兩個部分。 基本上,為什麼會有這種行為? 其次,這種行為會影響我的排名嗎? 我看到那些出現在搜索結果中的頁面不在 Google 緩存中”。
John 回答:“[...] 緩存頁面與我們索引的內容完全分離。 所以有沒有緩存頁,排名都無所謂,索引也無所謂。 有時,我們沒有緩存頁面是有技術原因的。 有時,我們只是沒有單個 URL 的緩存頁面。 另一件事是,如果頁面使用 JavaScript 框架,那麼 JavaScript 是否在緩存頁面上運行有時會很棘手,因為緩存頁面託管在 Google 域上。 根據您擁有的 JavaScript 類型、將 JavaScript 文件拉入的位置,有時 JavaScript 無法在 Google 域上運行。
[…] 緩存頁面不是渲染頁面。 它本質上只是我們請求的 HTML 文件,以及它的副本。 如果 HTML 文件顯示了某些內容,那很好。 如果它使用 JavaScript,並且 JavaScript 因為它是緩存頁面而無法運行,那同樣可以。 您只是在緩存頁面中看不到它。 所以如果緩存頁面沒有顯示,我不會擔心。 這不是任何問題的跡象。 通常,[...] 你無法控制是否有緩存頁面。 我會忽略這一點”。
https://www.youtube.com/watch?v=Vd0rEQrwHDc
