SEO 辦公時間,2022 年 2 月 25 日

已發表: 2022-03-09

這是2022 年 2 月 25 日Google SEO Office HoursJohn Mueller的最有趣問題和答案的摘要

內容隱藏
1 Search Console 中的鏈接報告
2非上下文頁腳鍊接與網站結構
3所有隱藏文本都違反谷歌的指導方針嗎?
4圖片文件名對網站排名的重要性
5使用相同的關鍵字定位兩個不同的頁面
6索引頁面與非索引頁面的比例是否合適?
7網站內的搜索結果與排名
8桌面上的頁面體驗更新與排名
9未編入索引的翻譯內容

Search Console 中的鏈接報告

05:41 “曾經有一個域名,上面有一個網站,然後 [...] 它被刪除了。 [如果] 在某個時候有一個新網站,那麼到舊網站的鏈接不再計算在內,這似乎很合乎邏輯。 [...] 在 Search Console 中,我確實看到至少一個來自前所有者的鏈接仍然存在。 [它] 是否意味著 [如果] Search Console [...] 顯示此鏈接仍會計數?”

John 回答說:“我不知道它是否會計算在內,但 Search Console 和鏈接報告的重要部分是我們嘗試顯示我們所知道的指向該網站的所有鏈接。 這並不表示我們認為這些是重要的鏈接或它們很重要。 特別是,仍然會列出 nofollow 鏈接、仍會列出拒絕鏈接、仍會列出我們因其他原因忽略的鏈接。 因此,僅僅因為它被列出並不意味著它是該網站的不相關或有用的鏈接。”  

非上下文頁腳鍊接與網站結構

09:13 “我們收購了一個網站,該網站在每個頁面的頁腳部分都有大量內部鏈接。 其中一些鏈接不那麼相關。 [...] 是否會因為鏈接不一定是上下文相關而被 Google 視為有問題? [...] 它們只是在頁腳中混雜在一起,它們只是被插件選中。 我們擔心從數百個頁面中刪除它們可能會破壞網站結構。”

約翰說:“我懷疑大部分情況下不會造成任何問題。 我會看到更多,因為這些頁面上的這些鏈接是正常的內部鏈接。

從這個角度來看:這是否有助於 [...] 為網站上的其餘頁面提供上下文? 例如,如果您有一個更大的網站,並且基本上每個頁面都與其他頁面鏈接,那麼那裡沒有真正的上下文,因此我們很難理解整體結構是什麼,這些頁面中的哪個更重要。 因為如果您要鏈接到所有內容,那麼就好像所有內容都不重要。 這是我要注意的元素。 無論它們是否在頁腳中,在我看來,這無關緊要。 如果它們是由插件生成或手動添加的,我認為這也不重要。 我會從結構的角度注意:擁有這些鏈接是否有意義? 一定數量的交聯是有道理的。 如果您的設置中有交叉鏈接的相關頁面,那麼從我的角度來看,這總是有意義的。 極端交叉鏈接,在我看來,你將每個頁面與其他頁面交叉鏈接,這沒有任何意義。”

11:10 “[...] 如果我們禁用插件並且所有這些鏈接突然 [...] 從頁面中丟失,它會以任何方式影響網站嗎? 或者我們應該嘗試一次從一個頁面中慢慢刪除鏈接?”

約翰:“我的猜測是它會影響它在搜索中的顯示方式,但不可能說它是積極影響還是消極影響。 我認為這是棘手的部分。

我會做些什麼來嘗試了解當前的情況以及下一步是在您的網站上運行爬蟲。 許多現有的網站爬蟲都會生成一個關於您的頁面如何鏈接在一起的圖表。 然後您可以禁用該插件,可能在您網站的臨時版本上,甚至可能在短時間內在實時版本上。 再次爬取,然後比較這些圖表,看看這個爬蟲是否仍然能夠找到所有內容? 看起來那裡的交聯不夠嗎? 如果是這樣,那麼這會讓您更加相信只需禁用插件就可以了。 從我們的角度來看,這些鏈接是自動放置還是由插件放置或機器學習放置都沒有關係。 [...] 它們只是我們在您的網站上找到的鏈接。”

所有隱藏文本都違反 Google 的準則嗎?

13:22 “所有隱藏文本都違反網站管理員指南嗎? [...] 我們在多個頁面中包含一些元素,以及為每個元素內部分配的標識符,因此這些標識符對用戶沒有任何意義 [...],但作為 SEO,它可以讓我的生活更輕鬆。 […]”

約翰的回答是: “我認為這不會有問題。 從我們的角度來看,隱藏文本在實際上是在欺騙搜索引擎以了解頁面上的實際內容時更成問題。 所以極端的例子是,你有一個關於鞋子的頁面,裡面有很多關於奧運會的隱藏文本 […],然後你的鞋子頁面突然開始為這些奧運術語排名。 但是,當用戶去的時候,奧運會什麼都沒有,從我們的角度來看,這將是有問題的。

我認為我們在識別隱藏文本並試圖避免這種情況發生方面做得很合理,但這就是我們在網站管理員指南中包含此元素的原因。 從我的角度來看,用它來展示你不一定想欺騙任何人的東西是非常好的。 此外,可訪問性是頁面上隱藏文本的常見原因,在該頁面上,您設置了點擊目標,您可以點擊它們,然後您的屏幕閱讀器會對此進行說明。 但它們不能直接在頁面上看到,這也很好,所以我不會擔心或懷疑你描述的設置是否有效。”

圖片文件名對網站排名的重要性

24:56 我們正在使用智能 CDN 提供商,它一直在用唯一的數字替換圖像文件名。 我們注意到 Search Console 中的所有圖像都是 404。 禁用 CDN 會顯著降低網站的整體性能。 如果沒有適當的文件名和標題,圖像替代文本和標題是否足以讓 Google 理解?”

根據約翰的說法, “這裡有兩件事我會看。 一方面,如果這些是您需要在圖像搜索中建立索引的圖像,那麼您應該確保您的圖像具有穩定的文件名。 這是這裡最重要的元素。

您沒有提到這些數字或這些 URL 會發生變化,但有時這些 CDN 本質上為每個圖像提供了一個基於會話的 ID。 如果每次抓取時圖像 URL 都會更改,那麼本質上,我們將永遠無法正確索引這些圖像。 這主要是因為對於圖像,我們在抓取和索引方面往往會慢一點。 因此,如果我們曾經看到一張圖片並說我們應該看看這個,然後我們嘗試在稍後的某個階段再次抓取它,並且到那時數量已經改變,那麼我們將從搜索結果中刪除該圖片,從圖像排名。 本質上我們會說,好吧,我們認為在這裡的這個圖像不再在這裡了。 這裡最重要的部分是弄清楚你是否關心圖像搜索? 如果是這樣,您需要確保所有這些圖像都有一個穩定的 URL。 它是數字還是文本或類似的東西都沒有關係。 它應該是穩定的。 這是這裡最重要的部分。

您提到的另一部分是圖像替代文本和標題,這表明您對網絡搜索感興趣,而不一定是圖像搜索。 對於網絡搜索,我們不需要能夠抓取和索引圖像,因為我們本質上是查看網頁本身。 因此,諸如替代文本、任何標題、頁面上的標題之類的東西,所有這些都有助於更好地理解這個頁面。 對於網絡搜索,這就是我們所需要的。 例如,如果所有圖像一直是 404 或被 robots.txt 或網絡搜索阻止,我們仍然會將該頁面視為完全一樣,就好像我們能夠為所有這些圖像編制索引一樣。 在圖像搜索本身中,我們需要能夠為這些圖像編制索引,並了解存在 [​​有] 穩定 URL 並了解它們如何與您網站的其他部分連接。”

使用相同的關鍵字定位兩個不同的頁面

29:36 “一個 [page] 是一個功能頁面,另一個是關於該功能的信息片段。 在這兩個不同的頁面上定位相同的主要關鍵字可以嗎?”

John 說: “首先,定位任何你想要的關鍵字是完全可以的。 從我們的角度來看,我們不會阻止你。

我要注意的是,你是在和自己競爭嗎? 這幾乎是一個戰略問題,而不是一個純粹的 SEO 問題,而不是我們說有指導方針不應該這樣做的問題。 但更重要的是,如果您有多個內容對具有相同意圖的相同查詢進行排名,那麼您實際上是在稀釋您在多個頁面中提供的內容的價值。 他們正在相互競爭,這可能意味著這些單獨的頁面本身在與其他人的網站競爭時並不那麼強大。 所以這有時是我要注意的。

如果您有兩個頁面並且它們都針對相同的關鍵字,並且它們具有非常不同的意圖,那麼從我的角度來看,這似乎是合理的,因為人們可能會在搜索該關鍵字時為一個意圖添加額外的文本和額外的為其他意圖添加的文本。 它們本質上是獨特的頁面。 它們都出現在搜索中或最匹配的一個出現在搜索中是有意義的。 [...] 就像我說的,這不是我們需要的,也不是可以的,也不是可以的。 這是您希望如何在搜索中出現的戰略定位問題。”

索引頁面與非索引頁面的比例是否合適?

31:26 “高流量排名頁面的位置是否會受到許多(比如說 50%)未編入索引或已編入索引但未接收流量的域總頁面的影響?”

約翰回答說: “我想問題更多的是圍繞我有一些非常受歡迎的頁面和很多不太受歡迎的頁面。 這描述了您擁有各種內容的普通網站,其中一些非常受歡迎,而有些則不那麼受歡迎。 所以,從我們的角度來看,這完全沒問題。

此外,只有大量頁面是一個誤導性指標,因為很容易有很多頁面沒有被看到是非常重要的,然後它們在搜索中不會出現很多,這可能很好。 如果您有五頁這樣的頁面或一百 [...] 或一千頁,[並且] 如果它們沒有出現在搜索中,它們也不會造成任何問題。 從這個角度來看,查看大量頁面與搜索結果中顯示的頁面有時會很棘手。

另一件事,也許還要記住這樣的問題,有時將更多的精力集中在更少的頁面上以獲得戰略優勢,即擁有更少的頁面更強大,而不是擁有很多頁面'本質上是在稀釋價值。 就像如果你有一千頁,它們每一個都提供了大圖的一小部分,那麼這千頁可能很難搜索。 然而,如果您可以將其中的很多內容合併到 [...] 也許十頁中,那麼這十頁將包含大量信息,並且相對於您網站的其他部分而言可能具有很多價值,並且可能更容易排名圍繞該主題的更廣泛的搜索詞。”

網站內的搜索結果與排名

37:49 “我正在努力確保我們的 SEO 排名在我們推出新的搜索結果頁面時不會受到影響。 [...] 我們的搜索可以產生 10,000 個結果,並具有過濾和排序功能。 Google 如何處理網站內的這些搜索結果頁面 [以及] 這些搜索結果如何影響網站的整體排名? 僅提交站點地圖以進行排名就足夠了嗎,還是我們應該考慮其他因素來幫助 Googlebot 收集可訪問的 URL?”

約翰回答說: “[...]我不會依賴站點地圖來查找您網站的所有頁面。 站點地圖應該是提供有關您網站的其他信息的一種方式。 它不應該是提供[關於]您網站的信息的主要方式。 因此,特別是內部鏈接非常重要,您應該注意這一點,並確保當有人爬取您的網站時,無論您如何設置,他們都能夠找到您的所有內容,而不是他們依賴於站點地圖文件來獲取所有這些東西。

從這個角度來看,我認為能夠進入這些類別頁面並能夠找到各個類別中的所有產品是非常有用的。 能夠通過分類頁面爬取到產品也很重要。 搜索結果頁面是一個獨特的區域,因為某些網站使用的類別頁面本質上類似於搜索結果頁面,然後您處於搜索結果頁面本質上類似於類別頁面的情況。 如果您是這種情況,我會注意您對類別頁面所做的一切。

搜索結果頁面的另一件事是人們可以輸入任何內容並蒐索某些內容,而您的網站必須完成所有工作才能生成所有這些內容。 這很容易導致理論上可以在您的網站上找到無限數量的 URL,因為人們可以通過多種不同的方式進行搜索。 因為這會在您的網站上創建這組無限頁面,所以我們試圖阻止我們將這些搜索結果頁面設置為noindex或使用robots.txt阻止對這些搜索結果頁面的抓取,以便我們可以專注於正常的網站結構和正常的內部鏈接。 我認為這些是那裡的主要方面。

如果您確實希望將搜索結果頁面編入索引,那麼我的建議是確保,一方面,您將一個主要的排序順序和過濾設置設置為規範。 因此,如果您選擇按相關性提供頁面,那麼如果您有按價格上漲或下跌的排序過濾器,那麼我會將這些過濾器的 rel=“canonical”設置為您的主要排序順序。 同樣,對於過濾,我可能會刪除帶有 rel=”canonical” 的過濾器。 這樣做,確保我們可以更多地關注頁面的主要版本並正確抓取它們,而不是讓我們被搜索結果頁面的所有這些變體分心。

我要注意的另一件事是,您在您的網站上創建了某種允許列表或 [...] 一個系統,該系統與您希望允許被索引或爬網的搜索查詢類型有關。 例如,如果有人訪問您的網站並蒐索“加拿大藥品”或類似內容,而您不是藥品網站,您可能不希望該搜索頁面被編入索引。 即使您沒有與該查詢匹配的任何可用產品,您也可能不希望將其編入索引。 因此,擁有一個您確實允許索引的允許搜索列表會使這變得容易得多 確保您不會意外遇到這種垃圾郵件情況,即有人向您的搜索結果發送垃圾郵件,然後您必須清理數百萬被索引的頁面並以某種方式擺脫它們。”

桌面上的頁面體驗更新與排名

42:20 由於 Core Web Vitals 不佳,我的網站訪問量有所下降。 現在我回到了正軌,但我知道頁面體驗更新現在正在慢慢推出桌面版。 與其他排名信號相比,桌面版的頁面體驗排名是什麼?它有多重要?”

根據 John 的說法, “就像在移動設備上一樣,頁面體驗排名因素本質上為我們提供了一些額外的信息,[關於]這些不同的頁面可能會出現在搜索結果中。 在我們從查詢中有 [...] 明確意圖的情況下,我們可以理解他們真的想通過這個網站進行此操作,那麼,從這個角度來看,我們可以輕鬆地使用頁面體驗作為排名因素。 另一方面,如果搜索結果頁面上的所有內容都非常相似,那麼使用頁面體驗可能有助於了解哪些是快速頁面或就用戶體驗而言合理的頁面,哪些是在搜索結果中顯示的不太合理的頁面。 這種情況對我們有幫助。

關於桌面部署,我相信在大約一個月的時間裡,這將是一個較慢的部署,這意味著你不會從一天到另一天看到強烈的影響,而是你會看到一段時間內的效果。 您還可以在 Search Console 的 Page Experience 和 Core Web Vitals 報告中看到這一點。 例如,您還會在桌面上看到一切都是紅色的,您需要專注於此。 從這個角度來看,隨著桌面排名的變化與移動排名一樣,我不希望在我們推出這一功能時,搜索結果從一天到另一天都會急劇上升。 最多,如果你的網站真的很糟糕,你會看到那裡逐漸下降。”

未編入索引的翻譯內容

53:15我在一個大型多語言網站上工作。 去年 4 月,[...] 我們所有的翻譯內容都從 Valid 變為 Excluded, Crawled – 目前未編入索引並且自 4 月以來一直存在。 [...] 因為這一切都是同時發生的,所以我們認為我們這邊可能發生了一些系統性的變化。 [...] 我們已經清理了我們的 hreflangs、規範、URL 參數、手動操作以及developers.google.com/search 上列出的所有其他工具。 [...] 我不知道發生了什麼,也不知道接下來要做什麼來嘗試解決問題,但我希望將我們的翻譯內容重新納入索引。”

John 的回答是:“[...] 我認為 [it] 有時會很棘手 [if] 您在參數末尾帶有語言代碼。 [...] 從我們的角度來看,可能發生的情況是,當我們認識到有很多這些參數導致相同的內容時,我們的系統可能會陷入困境,好吧,也許這個參數不是非常有用,我們應該忽略它。 對我來說,這聽起來很像圍繞這條線發生的事情。 在某種程度上,您可以使用Search Console 中的 URL 參數工具來幫助這一點,以確保設置了該參數。我確實希望將所有內容都編入索引。 部分地,您還可以做的可能是使用 [...] 本地爬蟲來爬取您網站的一部分,以查看實際獲取的參數 URL ,然後仔細檢查這些頁面是否確實具有這些語言的有用內容。  

特別是,[…] 我在網站上看到的常見 [事物] 可能是您 […] 所有語言都鏈接在一起,而日文版說哦,我們沒有日文版,這是我們的英文版,那麼我們的系統可以說,嗯,日文版和英文版一樣——也許還有其他一些語言和英文版一樣。 我們應該忽略這一點。 有時這是來自網站內的鏈接,有時也是外部鏈接,即鏈接到您網站的人。 如果參數位於 URL 的末尾,那麼很常見的還有一些垃圾附加到參數。 如果我們用這些垃圾抓取所有這些 URL,然後我們說,這不是一種有效的語言,這裡是英文版本,那麼它再次強化了系統說的循環,好吧,也許這個參數不是那麼有用。 如果您有一些垃圾參數可以重定向到更清潔的參數,或者甚至可能顯示 404 頁面並說,好吧,我們不知道您在用這個 URL 談論什麼並乾淨利落地製作確保我們找到的任何 URL 都會得到一些有用的內容,這些內容與我們已經看到的其他內容不同。”