2019 年 3 月 8 日 - Google 幫助環聊筆記

本週，John 回答了一些關於 Page Speed、Anchor Text、Java Script 的好問題。 與往常一樣，可以在下面找到完整的視頻和成績單！

如何處理翻譯的內容？

0:33

我認為有一個這樣的組合網站很好。 我認為對用戶來說，讓它易於閱讀是有意義的，這樣如果你是一個說英語的人並且你訪問你的網站，它就不像俄羅斯、烏克蘭和英語內容的混合體，而是所有的英文內容。 可能不是您擁有不同語言的所有內容，但沒關係。 從 SEO 的角度來看，將翻譯轉化為高質量的內容確實很有意義。 所以不僅僅是使用谷歌翻譯。 翻譯工具在這方面仍然越來越好，但如果你手動翻譯或使用谷歌翻譯版本並將其清理並使其更具可讀性，那就更好了。 這是用戶注意到的，也是我們從算法的角度注意到的。 如果我們能分辨出這是真正高質量的內容，那麼我們會在搜索結果中更好地對待它。

摘要：確保您的翻譯內容可以用其他語言閱讀，而不僅僅是通過 Google 翻譯自動翻譯。 還要確保翻譯質量高，對用戶有價值。

如果我的網站在 Javascript 上運行並且索引時間對內容至關重要，我怎麼知道它需要被索引？

3:10

所以總的來說，第一部分是正確的。 在這種情況下，我們嘗試盡可能快地索引內容，如果我們有一個靜態 HTML 版本，我們可以這樣做，然後下一步是我們嘗試像瀏覽器一樣呈現頁面，我們也會選擇該內容，並且將其用於索引。 這兩件事結合在一起通常可以協同工作，但靜態 HTML 版本不會被延遲（人為）直到 javascript 版本準備好。 所以從這個角度來看，對於大多數網站來說，存在這種差異並不重要，而且我們沒有任何明確的時間適用於開始呈現頁面所需的時間。 這可能會因頁麵類型、我們何時找到它、我們如何找到它以及該頁面周圍發生的事情而有所不同。 例如，如果我們認為這是非常快速地在搜索中顯示的東西，那麼我們將嘗試立即渲染它。 所以有點難以考慮。 那裡沒有固定的數字。 一般來說，我會將此作為粗略的指導來確定您是否需要對客戶端 javascript 內容進行處理。 例如，如果您有需要快速索引的新聞內容，那麼我會確保 Google 可以盡快提取該內容，而無需單獨呈現該內容。 對於新聞站點，尤其是在鏈接到所有新文章的新聞站點的翻頁上，我真的會確保這些頁面完全與提供給搜索引擎的靜態 HTML 一起工作。 所以這就是我的想法，想想我的內容被立即編入索引有多重要，而不是需要多少分鐘，因為沒有固定的時間來確定需要多長時間。

摘要：對於 javascript 網站，Google Firsts 索引頁面，然後需要時間來處理 javascript。 至於需要多長時間，沒有固定的時間。 因此，如果您的內容需要經常更新，最好提供頁面的靜態 HTML 版本。

如果 url 檢查工具和移動友好測試都從實時服務器中獲取頁面，它們的主要區別是什麼？

9:16

所以移動友好測試的想法只是測試這個版本是否是移動友好的，所以這是主要的焦點。 而 url 檢查工具，實時測試工具，更多地是為了查看“這個頁面在索引中的表現如何？”，我認為它會檢查一些事情，比如沒有索引響應代碼，那種通常會適用的事情對於我們是否獲取此頁面並將其放入我們的索引中。 移動友好的測試主要集中在移動端，inspect url 工具就像一把大折刀，具有不同的功能，您可以將其用於不同的事情。

摘要：移動友好測試是查看網站在移動設備上的表現如何，而 url 檢查工具檢查索引是否正常工作，例如沒有索引響應代碼。

我正在考慮在我的電子商務網站上拆分我的產品頁面。 目前，它們可以在一個頁面上配置，並顯示多種變體。 你有什麼建議？

18:00

我認為我會更多關注的方面是將這些產品拆分為單獨的頁面是否真的有意義，因為您所交易的是一個產品頁面，該頁面對該產品和所有變體都相當強大，而不是多個頁面有點必須自己工作並得到自己的支持。 因此，與其為“跑鞋”提供一個非常強大的頁面，不如為“藍色跑鞋”“紅色跑鞋”“綠色跑鞋”等多個頁面進行競爭。 因此，如果有人在搜索“跑鞋”，那麼這些小頁面確實不如您為該主要產品擁有的那個產品頁面那麼強大。 所以我的一般建議是，如果你認為這些變化只是主要產品的屬性，因為人們傾向於搜索主要內容然後說“哦，我想要哪種顏色，就像我找到了產品一樣我想要，但我只需要選擇我想要的顏色。” 然後我會把它們放在一個共享頁面上。 然而，如果人們明確地在尋找這種變化，而這種變化真的很獨特，而且它本身就很突出，人們來到你的網站時不會只是說“我想要跑鞋”而是“我想要這種特定類型的跑步”這種顏色的鞋子”那麼這可能值得作為一個單獨的產品拿出來。

摘要：除非產品變體單獨突出並且人們會搜索該特定變體，否則最好將它們全部放在一個強大的頁面上。 這樣，產品頁面的不同變體就不會相互競爭。

速度對於您網站的移動版本重要嗎？

21:00

所以好的部分是我們有很多排名因素，所以你不必總是把所有事情都做到完美。 但這也意味著你會遇到這樣的情況，你會說“谷歌說速度很重要，但這裡的頂級站點沒有那麼快，所以它一定不重要”。 對我們來說，這絕對是重要的，但這並不意味著它凌駕於其他一切之上。 你可以想像你能想到的最快的頁面可能是一個空頁面。 但是，如果您正在搜索非常具體的內容，那麼空白頁面將是一個非常糟糕的搜索結果。 它真的很快，但那裡沒有內容，所以用戶不會高興。 所以我們必須平衡所有這些因素、內容、鏈接和所有這些信號，並嘗試找出如何根據我們擁有的不同因素的組合來進行排名。 它也會隨著時間的推移而改變，它可以很快改變。 例如，如果某件事目前確實具有新聞價值，那麼我們可能會選擇向稍微不同的網站展示更多是研究的、常青的話題。

摘要：速度只是 Google 使用的排名因素之一。 僅僅因為熱門網站可能不快並不意味著它對您的網站不重要。

如果我們使用 JSON 或微數據、微格式，哪種類型的模式標記更適合 Google。 哪個更可取？

22:30

我們目前更喜歡 JSON-LD 標記。 我認為大多數新類型的結構化數據首先出現在 JSON-LD 中，所以這是我們更喜歡的。

摘要： JSON-LD 是 Google 的首選。

錨文本有多重要？

25:10

所以我認為首先，我不會太擔心谷歌的專利，我們申請了很多不一定適用於網絡大師需要做的事情。 所以我認為看到我們的工程師正在努力很有趣，但這並不一定意味著我們會立即受到影響。 關於一般的錨文本，我們確實將它用於文本。 這是我們確實接受的東西。 這是為我們提供有關鏈接的上下文的好方法。 特別是在您的網站中，如果您的鏈接僅顯示“單擊此處獲取更多信息”，這對我們來說不是很有用。 你在哪裡有一個鏈接，上面寫著“你可以在這個產品頁面上找到更多信息”，並用那個產品的名稱鏈接到那個頁面，那麼這告訴我們這個頁面可能真的是關於這個產品的。 因此，我肯定會繼續查看您使用的錨文本，尤其是在您的網站內部，並嘗試確保您提供的錨文本非常有用，並為頁面上鍊接的內容提供上下文。

摘要：錨文本非常重要，因為它為 Google 提供了有關頁面內容的上下文。 諸如“單擊此處獲取更多信息”之類的錨文本不會為 Google 提供太多信息，但諸如“您可以找到有關此產品頁面的更多信息”之類的錨文本告訴 google，此頁面是關於此產品頁面的。

我們的注意事項：如果您正在製作自己的鏈接，如果您獲得人工審核，那麼有太多的關鍵字鏈接可能會提示垃圾郵件團隊。

Google 如何直觀地看到您的頁面？

39:00

我們確實嘗試從視覺上查看頁面，但主要是關於首屏上方的實際內容還是首屏空間只是一個巨大的廣告。 這就是我們所關注的，同樣關於移動友好性，我們嘗試對頁面進行可視化映射，看看這個頁面是否可以在移動設備上運行良好。 為此，我們必須繪製頁面，如果某些元素不可讀，只要它們在移動設備上工作，就可以了。 如果這些鏈接在那裡，它們的大小合適，人們可以點擊它們，那很好。 如果你正在做一些花哨的 css 轉換來把它變成 3d 文本，那完全取決於你。 重要的部分是文本本身在頁面上是可見的，並且您沒有做太多花哨的標記來拆分該文本。 舉個例子，如果你在舊系統中有一個標題，你有一個基於表格的佈局，並且你想在頂部拆分治療，我似乎人們將單獨的字母放入單獨的表格單元格中，從我們的角度來看，這使得幾乎不可能看到這實際上是一個詞，因為您使用標記將其拆分為不連貫的塊。 從解析頁面的角度來看，這真的很棘手。

摘要： Google 主要嘗試查看實際內容是否在首屏，而不僅僅是一個巨大的廣告。 就移動友好性而言，谷歌試圖了解是否存在相同的鏈接、所有內容的大小是否正確以及人們是否可以點擊這些鏈接。 最重要的是文本本身是否在頁面上可見。

你能用 Javascript 換掉一個 URL 嗎？

43:00

是的，我們可以把它撿起來。 我認為重要的部分是在頁面加載後需要換掉 URL。 當用戶執行特定操作時，不應將其換出。 因此，例如，如果用戶將鼠標懸停在鏈接上，然後您使用 JavaScript 換出我們不會注意到的 URL，或者如果用戶單擊鏈接，然後您使用 JavaScript 換出 URL，那麼也不會是我們會注意到的。 但是，如果頁面加載，然後您執行一些 JavaScript 來清理 URL，以便它們鏈接到正確的規範版本，這非常好，就像我們在開始時談到渲染時談到的那樣，有時這需要一些時間時間。 因此，我們不會立即選擇我們可能會選擇的東西，或者我們很可能會選擇這兩個版本，包括您在那裡擁有的原始鏈接以及 JavaScript 版本。 因此，舊版本不會完全退出。

摘要：如果在頁面加載後換出 URL，Google 可以獲取。 唯一需要注意的是確保當用戶執行特定操作時 URL 不會被換出。

如果你喜歡這樣的東西，你會喜歡我的時事通訊！

我和我的團隊每週都會報告最新的 Google 算法更新、新聞和 SEO 技巧。

問題 0:33 - 關於翻譯的問題。 我知道，如果我將英語內容翻譯成俄語或烏克蘭語，大多數人只使用谷歌翻譯並輸入內容。 但是，如果您以母語人士的身份閱讀，則其中 90% 的內容需要更正。 我對兩點感興趣。 如果我想為我的網站製作其他版本或其他語言，例如英語、俄語或烏克蘭語，可以嗎？ 第二個，我發現一篇關於我的利基的有趣文章，我想翻譯它，這好還是不好？ 我需要讓它適應國內讀者嗎？

回答 1:38 - 我認為有一個這樣的組合網站很好。 我認為對用戶來說，讓它易於閱讀是有意義的，這樣如果你是一個說英語的人並且你訪問你的網站，它就不像俄羅斯、烏克蘭和英語內容的混合體，而是所有的英文內容。 可能不是您擁有不同語言的所有內容，但沒關係。 從 SEO 的角度來看，將翻譯轉化為高質量的內容確實很有意義。 所以不僅僅是使用谷歌翻譯。 翻譯工具在這方面仍然越來越好，但如果你手動翻譯或使用谷歌翻譯版本並將其清理並使其更具可讀性，那就更好了。 這是用戶注意到的，也是我們從算法的角度注意到的。 如果我們能分辨出這是真正高質量的內容，那麼我們會在搜索結果中更好地對待它。

問題 3:10 - Google 分兩步抓取和索引內容。 首先是服務器端渲染，其次是客戶端渲染，根據之前的說法，這個過程可能需要幾天或幾週才能完成。 對於使用 Javascript 的網站，如果索引時間緊迫，他們可能會遇到嚴重的問題。 我怎麼知道需要多長時間？

回答 3:46 - 所以總的來說，第一部分是正確的。 在這種情況下，我們嘗試盡可能快地索引內容，如果我們有一個靜態 HTML 版本，我們可以這樣做，然後下一步是我們嘗試像瀏覽器一樣呈現頁面，我們也會選擇該內容，並且將其用於索引。 這兩件事結合在一起通常可以協同工作，但靜態 HTML 版本不會被延遲（人為）直到 javascript 版本準備好。 所以從這個角度來看，對於大多數網站來說，存在這種差異並不重要，而且我們沒有任何明確的時間適用於開始呈現頁面所需的時間。 這可能會有所不同，具體取決於頁面的類型、我們何時找到它、我們如何找到它、該頁面周圍發生了什麼。 例如，如果我們認為這是非常快速地在搜索中顯示的東西，那麼我們將嘗試立即渲染它。 所以有點難以考慮。 那裡沒有固定的數字。 一般來說，我會將此作為粗略的指導來確定您是否需要對客戶端 javascript 內容進行處理。 例如，如果您有需要快速索引的新聞內容，那麼我會確保 Google 可以盡快提取該內容，而無需單獨呈現該內容。 對於新聞站點，尤其是在鏈接到所有新文章的新聞站點的翻頁上，我真的會確保這些頁面完全與提供給搜索引擎的靜態 HTML 一起工作。 所以這就是我的想法，想想我的內容被立即編入索引有多重要，而不是需要多少分鐘，因為沒有固定的時間來確定需要多長時間。

問題 6:17 - 現在我們有一個很長的問題，關於理解搜索控制台中的標記類型，例如當我們將某些內容標記為“重複 Google 選擇與用戶不同的規範”或“重複提交的 URL 並且未選擇為規範問題”時.

[用戶提示] 這是一個 Javascript 頁面。 它是預渲染的，所有內容都在靜態 HTML 中，但谷歌仍在嘗試執行該頁面。 我們在這個電子商務環境中發現，這些具有獨特描述和有意義內容的獨特產品頁面被標記為 Google 重複內容。 我們假設這歸結為某種 JavaScript 渲染失敗，Googlebot 一直看到相同的錯誤頁面或類似的東西，因此認為它們是重複的 - 我們如何理解 Web 渲染服務最終是什麼可能會導致內容看起來與 Google bot 重複。

回答 7:43 - 我將不得不看一些實際的例子，所以如果你能給我一些非常有用的例子。

問題 8:00 - Google 是否意識到一個持續存在的問題？

回答 8:00 - 不……我從一些網站那裡聽到的抱怨比其他網站更多，所以如果您發送一些有用的示例。

問題 8:24 - 如果一個 url 被標記，是否有任何關於在分析時發生的渲染的信息。 無論如何，是否可以查看索引中發生的資源加載錯誤？ 您在搜索控制台中沒有該 UI，或者至少我無法使用它。 或者是否有任何地方可以讓我們在索引器和/或重複檢測查找器查看內容時看到內容的實際樣子

回答 8:41 - 目前沒有。 這是一件很有意義的事情。 對於大多數站點來說，這並不重要。 但在這種情況下，這將是有用的。

問題 9.16 - 下一個問題。 移動友好測試。 在理解索引器如何查看內容方面，您已經引用了幾次。 但是，我們發現在加載資源時標記了許多其他錯誤，並且這些錯誤發生的速度似乎因域而異。 所以第一個問題，我們在移動友好測試中看到的錯誤是否代表了服務在索引期間會遇到的錯誤？ 或者 MF 測試是否有不同的資源分配？

回答 10:04 - 所以我認為您專門指的是為測試而引入的嵌入式資源，對嗎？ 像JS文件CSS不同響應之類的東西？ 我認為目前有點複雜的方面之一是，與普通的谷歌機器人相比，我們對移動友好測試有不同的優先級。 我們嘗試盡快從實時服務器中提取資源，並且在索引期間我們緩存了大量資源並僅獲取頁面的緩存版本。 因此，您在移動友好測試中可能會看到，我們嘗試盡可能快地呈現此頁面，並且我們可以獲得大量此類資源，但對於其中一些資源，我們基本上會超時，基本上有能力從中提取此內容服務器。 這在很大程度上是您在移動友好測試中看到的一些錯誤。 我也相信，在檢查 url 工具中，如果您使用實時測試，我們會嘗試實時提取所有內容，有時這只是無法實時進行。 對於索引，我們有更多、更長一點的時間可供使用。 因此，如果我們看到需要這些資源，我們將拉取它們，緩存它們，並在嘗試進行渲染時嘗試使它們可用。 所以這是我們不需要做 iot live 的事情，所以如果需要更長的時間來做這件事，我們會耐心等待所有這些都在一起。 仍然存在時間的一個方面，即這些資源都無法緩存它們（例如會話 ID 和所有 JS URL），這使得我們真正需要保留緩存的版本和稍後重用它，那麼那些我們可能，我不知道，出於某種原因，無法獲取索引。 簡而言之，我認為很難診斷出這樣的問題，尤其是在您擁有大量嵌入式資源的情況下。 我通常從工程團隊那裡得到的指導方針是，我們應該告訴人們擁有更少的嵌入式資源，他們往往不會遇到這個問題。 這並不總是那麼容易，所以，但總的來說，我會做的是將移動友好測試作為一個粗略的指導，所以如果它在 MTF 中有效，那麼你肯定是安全的。 如果您確實看到其他一些事情因其他錯誤而超時，那麼在大多數情況下，我們仍然可以將其用於索引。

問題 12:57 - 我猜你已經觸及了它，切線地，我們是否應該知道 Web 渲染服務渲染的任何硬超時或任意超時。 如果 Googlebot 在渲染服務中渲染頁面需要很長時間，是否有明確的實際使用內容。 它是否只是放棄並使用最初存在的頁面html內容？ 我們是否清楚您最終可以在渲染過程中走多遠？

回答 13:45 - 大多數情況下，如果出現問題或超時，我們只是在當時和那裡拍攝快照。 所以是的......我認為在你的情況下，如果你正在預渲染內容，那麼那裡不應該有問題，因為內容就在那裡。 我們有時在電子商務網站或使用非常模板化框架的網站中看到的是，在實際測試 URL 之前，我們會遇到假設存在重複內容的情況。 例如，如果我們看到一個 url 模式，就會發生這種情況。 例如，如果我們訪問一堆具有不同模式或不同參數的 url，並且我們看到所有這些 url 都指向相同的內容，那麼我們的系統可能會說“好吧，這個參數與網站不那麼相關”全部”，然後我們傾向於刪除這些 url，我們會說“這組 url 可能與我們已經抓取的另一組 url 相同。 所以特別是如果你有東西讓我們看看，我見過很多的一個例子是，如果你有很多不同的電子商務網站並且它們都銷售相同的產品 - 所以整個路徑在產品部分之後大量域中的 url 是相同的 - 然後我們的系統會說“所有這些 url 都是相同的，它們都指向相同的產品”，因此我們不妨只索引這些域中的一個而不是全部這些域中。 我不知道這是否適用於您的情況，所以我不知道這是否有用，但這是我們的系統嘗試針對我們在網絡上找到的內容進行優化的事情之一，我們假設其他人在網絡上也犯錯誤，我們試圖解決這個問題。 我們看到“所有這些人都在創建重複項，但我們不需要抓取所有這些重複項”，因此我們可以專注於我們認為的實際網址。

問題 16:22 - 了解移動友好測試和 url 檢查工具上的實時測試。 在移動友好測試中，Googlebot 嘗試從實時服務器中獲取頁面，那麼它與具有此功能的 url 檢查工具有何不同？ 明智的渲染或獲取頁面和資源有何不同

回答 17:04 - 所以移動友好測試的想法只是測試這個版本是否是移動朋友，所以這是主要關注點。 而 url 檢查工具，實時測試工具，更多地是為了查看“這個頁面在索引中的表現如何？”，我認為它會檢查一些事情，比如沒有索引響應代碼，那種通常會適用的事情對於我們是否獲取此頁面並將其放入我們的索引中。 移動友好測試主要集中在移動端，inspect url 工具就像一把大折刀，具有不同的功能，您可以將其用於不同的事情。

問題 18:00 - 在我們的客戶電子商務網站上，一些產品以可配置的形式出售，這意味著產品的多個不同變體在同一頁面上顯示和管理。 我們正在考慮拆分這些頁面，以便它們每個都有自己獨立的產品頁面，並帶有一個全新的 url。 然後，客戶評論將從舊頁面移動到新的簡單頁面。 舊評論的日期早於新創建日期的事實是否可以標記為黑帽 SEO？

回答 18:37 - 所以，我認為評論沒有任何問題，只要您可以繼續向這些產品頁面添加新評論。 我認為我會更多關注的方面是將這些產品拆分為單獨的頁面是否真的有意義，因為您所交易的是一個產品頁面，該頁面對該產品和所有變體都相當強大，而不是多個頁面有點必須自己工作並得到自己的支持。 因此，與其為“跑鞋”提供一個非常強大的頁面，不如為“藍色跑鞋”“紅色跑鞋”“綠色跑鞋”等多個頁面進行競爭。 因此，如果有人在搜索“跑鞋”，那麼這些小頁面確實不如您為該主要產品擁有的那個產品頁面那麼強大。 所以我的一般建議是，如果你認為這些變化只是主要產品的屬性，因為人們傾向於搜索主要內容然後說“哦，我想要哪種顏色，就像我找到了產品一樣我想要，但我只需要選擇我想要的顏色。” 然後我會把它們放在一個共享頁面上。 然而，如果人們明確地在尋找這種變化，而這種變化真的很獨特，而且它本身就很突出，人們來到你的網站時不會只是說“我想要跑鞋”而是“我想要這種特定類型的跑步”這種顏色的鞋子”那麼這可能值得作為一個單獨的產品拿出來。 所以這就是我可能會擔心的區別——我不會太擔心評論部分。

問題 20:36 新的 Search Console 標記架構功能是否與舊版本相同？

回答 20:50 我不知道新搜索控制台在結構化數據功能方面的確切計劃是什麼，但我們確實計劃支持所有這些結構化數據功能。 所以可能會發生的是這些功能最終以稍微不同的方式出現在搜索控制台中。

問題 21:00 移動版速度怎麼樣，綠區速度很重要嗎？如果是，為什麼很多頂級網站仍然這麼慢？

回答 21:20：所以好的部分是我們有很多排名因素，所以你不必總是把每件事都做到完美。 但這也意味著你會遇到這樣的情況，你會說“谷歌說速度很重要，但這裡的頂級站點沒有那麼快，所以它一定不重要”。 對我們來說，這絕對是重要的，但這並不意味著它凌駕於其他一切之上。 你可以想像你能想到的最快的頁面可能是一個空頁面。 但是，如果您正在搜索非常具體的內容，那麼空白頁面將是一個非常糟糕的搜索結果。 它真的很快，但那裡沒有內容，所以用戶不會高興。 所以我們必須平衡所有這些因素、內容、鏈接和所有這些信號，並嘗試找出如何根據我們擁有的不同因素的組合來進行排名。 它也會隨著時間的推移而改變，它可以很快改變。 例如，如果某件事目前確實具有新聞價值，那麼我們可能會選擇向稍微不同的網站展示更多是研究的、常青的話題。

問題 22:30 哪種類型的模式標記更適合 Google，我們應該使用 JSON 還是微數據、微格式。 哪個更可取？

回答 22:48 我們目前更喜歡 JSON-LD 標記。 我認為大多數新類型的結構化數據首先出現在 JSON-LD 中，所以這是我們更喜歡的。

問題 23:00 谷歌在 2 月或 3 月有沒有進行重大更新？

答：23:15 我不知道，我的意思是我們一直在更新。 我不知道你會認為什麼很重。 這可能取決於您的網站。 如果您的網站受到這些更新之一的強烈影響，您可能認為它非常沉重。 如果我們從整體上看網絡，也許它就像經常發生的變化一樣。

問題 23:24。 精簡內容對附屬網站意味著什麼？

回答 23:34 與任何其他網站相比，附屬網站的精簡內容並不意味著任何不同。 我們已經看到，特別是在附屬網站上，有一種只從提要中獲取內容的趨勢，因為它真的很容易做到。 您可以相當快地獲得腳本來為您執行此操作，這很容易，您不需要兩個來做很多工作，它會創建很多 URL。 但是，對於用戶和我們來說，這當然不是那麼有趣，因為您提供的東西與其他人已經擁有的東西一樣。

問題 24:40 選項卡中隱藏的內容是否會成為索引問題？

回答 24:50 一般情況下索引是沒有問題的。 這對用戶來說可能是個問題，所以如果那裡有您認為用戶真正需要看到才能進行轉換的內容，那麼從您的角度來看，這將是一個問題。 關於索引，我們可以獲取該內容並顯示它，所以這不是問題。

問題25:10 2019年錨文本仍然是重要的排名因素嗎？ 許多公司進行了研究，他們指出沒有相關性。 然後是谷歌專利的鏈接。

回答 25:30 所以我想首先，我不會太擔心谷歌的專利，我們申請了很多專利，不一定適用於網站大師需要做的事情。 所以我認為看到我們的工程師正在努力很有趣，但這並不一定意味著我們會立即受到影響。 關於一般的錨文本，我們確實將它用於文本。 這是我們確實接受的東西。 這是為我們提供有關鏈接的上下文的好方法。 特別是在您的網站中，如果您的鏈接僅顯示“單擊此處獲取更多信息”，這對我們來說不是很有用。 你在哪裡有一個鏈接，上面寫著“你可以在這個產品頁面上找到更多信息”，並用那個產品的名稱鏈接到那個頁面，那麼這告訴我們這個頁面可能真的是關於這個產品的。 因此，我肯定會繼續查看您使用的錨文本，尤其是在您的網站內部，並嘗試確保您提供的錨文本非常有用，並為頁面上鍊接的內容提供上下文。

問題 27:00 你能告訴我們 DMCA 流程是如何運作的嗎？

回答 27:01 我不能告訴你這是如何運作的，因為我不知道這方面的細節，而且這也是一個法律程序，我不能給你法律建議。

Question 27:30 How does a content platform like medium get its status as content provider? When I check the transparency report for medium the status is, check a specific URL, it's hard to provide a specific status for a site like medium that has a lot of content. We're also a content provider, hosting supermarket catalogs and other PDF publications online, generated by users. So I guess the questions is how do we get that status?

More context from the person who asked the question. Basically the problem we're trying to solve is, our platform allows adding outgoing links in the catalogue and if one specific Url is flagged for going to a bad site, our entire domain is at risk and we have been blacklisted before. Basically it fits the bill because we have a large number of content and all of that is user generated, so how does one go about being in this standing?

Answer 28:48 Um, I don't know. Is it mostly in regards to the transparency report with regards to phishing or maybe malware? It sounded like originally you just want the status that's provided in the transparency report but with regards to link and the content that's provided that sounds more like it's towards phishing or spam?

We're trying to solve for the issue where the domain is blacklisted for phishing and spam. Under the hood we are solving that problem but the generic solution seems to be something like this because even if individual long-tail domains are blacklisted for a period of time our main commercial domain is sage, is that even a good assumption?

Answer 29:50 I don't know how to best attack that. So I think from my point of view, there's one thing that you could do. I don't know your website so its hard for me to say already. Make it so it's easier for us to understand which parts of our website belong together. So for example, if you have different subdomains per user then its easy for us to say, well this problem is isolated on this specific subdomain or subdirectory and then our algorithms can then focus on that on a subdomain level. Where as if all the content is within the main domain and the URL structure is a slash and then a number then its really have for our algorithms to say everything that matches this pattern is maybe phishing or spam that wasn't caught in time. The easier you can make it for us for figure out which parts belong together, which could be by user, or could be by type of content depending on how you group the content then the easier it is for us to kind of match an action that applies just to this part of the website.

Question Continued 31:33 There is no process that your aware of that you can apply or get the status of content provider? And does it actually link to having decreased risk for whole domain blacklisting?

Answer 31:46 I don't think the two side are connected, so I think that content provider status in the transparency report is something that's specific to the transparency report and wouldn't apply to the spam handling. We do have some fold here who are working on something specific for hostess or CMS providers, which I think is kind of what you fall into here. To try to give them more information on where we see spam and to better understand the grouping of content in regards to individual websites.

Question 37:00 Is it necessary to Hreflang links to paginated pages beyond page one?

Answer 37:18 So it's never necessary to add Hreflang links, that's kind of the first thing there. It's not like you will be penalized for having those links on all pages across your website, those links do help us better understand which pages belong together. HReflang links work on a per page basis so if links work well between the homepage version of your site and not between the product pages on your website that's perfectly fine. Use them for the URLs that you think need to have that connection for the language and country versions, you don't need to do that for everything. The other thing, sometimes doing Hreflang links properly is really complicated, especially if your mixing things like pagination and maybe filtering then that feels like something where you're adding so much complexity that it's unlikely you will end up with a useful result and I would just drop the hreflang links so that you don't have extra noise in search console. That's kind of the pragmatic approach that I would take there. Use Hreflang where you see that you have problems and if you don't have any problems in regards to localization then don't worry about the hreflang part.

Question 39:00 Does Google determine a page is low quality by taking into account what the pages looks like visually? I have a site that has elements that get 3D rotated when a user taps on them, when I look at this page as Googlebot, it see's these elements with the ext backwards and looks weird. Is that a problem or not?

Answer 39:20 From my point of view, that's no problem. We do try to look at the page visually but mostly with regards to, is the actual content above the fold or is the above the fold space just one giant ad. That's kind of what we focus on, also with regards to mobile friendliness we try to visual map a page and see, is this a page that would work well on a mobile device. And for that we kind of have to map out the page, its ok if some elements are unreadable as long as they work on a mobile device. If those links are there, they're the right size and people can click on them, then that's perfectly fine. If you're doing some fancy css transformation to turn this into 3d text, that's totally up to you. The important part is that the text itself is visible on the page and that you're not doing too much fancy markup to split that text up. So as an example if you have a headline in the old system where you have a table based layout and you wanted to split the healing on top, I've seem people put individual letters into individual table cells and from our point of view that makes it pretty much impossible to see that this is actually one word because you're using markup to split it up into disconnected chunks. From a parsing the page point of view that's really tricky.

Question 41:26 - I've heard that changing a title tag for page will drop in ranking temporarily is that true what if I have a number that has just changed on the page title?

Answer 41:47 - So it's not true that changing a title will automatically drop a page in ranking I don't think that would make sense. However if you change a title and you put new keywords in there then we obviously need to figure out like how we should rank that page based on that title. Where the title is is one of the things that we do look at. We do look at a lot of other things on a page as well a lot of other signals that are involved with ranking so just changing a title on its own should have a big effect over all but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing there then obviously that does take a little bit of time. So if you're just changing numbers in the title then if people were searching for those old numbers or those new numbers that might be an effect that you would see. In practice people are not going to search for like number three or number five and expect your page to show up. I mean maybe there are exceptions but for the most part that's not going to be something that would affect your your pages ranking. So if you're changing numbers in a title over time I think that's perfectly fine if users are okay with that if that works for everyone.

Question 43:00 - Can Google crawl hyperlinks that we've swapped out the URL with JavaScript we do this as a workaround with our client due to CMS limitations.

Answer 43:08 - Yes we can pick that up. The important part I think is that the URL needs to be swapped out after the page is loaded. It shouldn't be swapped out when a user does a specific action. So for example if a user hovers over a link and then you use JavaScript to swap out the URL that wouldn't be something that we would notice or if a user clicks on a link and then you use JavaScript to swap out the URL then that also wouldn't be something that we would notice. But if the page loads and then you execute some JavaScript that cleans up the URL so that they link to the proper canonical versions that's perfectly fine and kind of like like we talked about in the beginning when it comes to rendering sometimes this takes a bit of time. So it's not an immediate thing that we would pick up we might or it's likely that we would pick up both of these versions both the original link that you had there as well as the JavaScript version. So it wouldn't be that the old versions would drop out completely.

Question 44:20 - Does Google understand related topics for example if I create a page about pets but I don't mention cats and dogs will that make it harder for Google to rank me?

Answer 44:35 - No I don't think that would be problematic. So it would of course make it harder to rank this page if someone searches for cats or dogs but you can create a page about pets that doesn't include all of those different types and I think that's that's pretty normal. Like there's a lot of variation of content out there and some content focuses more on on this side of the topic and some focuses more on a different part of the topic that's completely normal.

Question 45:09 - How does Google understand the quotes page given that they're technically duplicate content. Can Google tell that these are quotes pages and lots of content is also on other websites is that a bad thing or not? How does Google know?

Answer 45:30 - We do recognize when there are kind of parts of a page that are shared across other pages. So a really common situation is you have a footer on your web page that you share across a lot of pages. We can tell that this this part of text is the same as you have across other parts of your website. So what generally happens there is if someone searches for something that's in the shared piece of content we'll will try to pick the most matching page for that. If someone searches for something that's a combination of that content and something else on a page that will try to pull that best matching page. So that's the same as what would happen with these quotes pages and that if someone searches for a specific quote that you have on this page then we'll try to pick one of the many quotes pages that we have that has the same quote on it. It might be yours it might be like hundred other people, a lot of people have these quotes, and we'lll try to show that one in the search results. It's not that we would see this page as being lower quality it's just that you're competing with a lot of other sites that have the exact same quotes on it so if there is something unique that you're providing on these pages then I would make sure that that is also very visible there. So that it's easy for us to tell that well pages about this quote but also has a lot of information about other I don't know, Russian quotes or other German quotes, and we can tell this user is used to searching in Russian or German so we'll bring them to your site rather than to a generic site that has just all kinds of quotes. So the more you can bring unique value into those kind of pages more likely we'll be able to show that in the search results. But it's not necessarily something that you have to hide, we recognize these quotes we we understand that as sometimes are shared across lots of websites that's completely normal.

Question 47:40 - Suppose I started a blog the most following methodology is connecting your site map to the webmaster site from day one but what if I write 50 posts and then add a sitemap file is there any difference

回答 47:54 - 這兩種方法都有效。 因此，站點地圖文件可以幫助我們更好地了解網站上的新頁面和更改頁面。 這不是排名因素，因此您不會僅僅因為您擁有站點地圖文件而排名更高同樣，如果我們可以正常抓取站點或使用站點地圖文件抓取站點，則站點在搜索中的顯示方式沒有太大區別。 因此，如果您要更改站點中有時稍微低一些的內容，站點地圖文件對於較大的站點絕對不是關鍵，那麼站點地圖文件顯然可以幫助我們更快地找到這些更改，但如果您剛剛開始您不一定需要有站點地圖文件的博客。

問題 48:50 - 我們通過我們的網站轉售希臘的酒店，我們為酒店開發了一個非常友好的部分，但是當我們嵌入這些酒店的 YouTube 視頻時，我們也會復制這些酒店的內容和標題。 這對我們有害嗎？

回答 49:10 - 我認為這可以追溯到我們對重複內容的其他問題。 重複的內容，如果你真的只是在許多不同的網站上提供相同的東西，那麼你真的需要專注於確保你的網站上有一些獨特的東西，那麼這讓我們很難說好這是實際上是我們需要顯示搜索結果的網站。 因此，我建議您退後一步，思考您可以做些什麼來確保您的網站真正獨特且具有吸引力，而不僅僅是與所有其他網站相同。

問題 50:00 - 如果一個故事因為內容稀少且年代久遠而被重定向，文章的負面影響是否會隨著重定向而被轉發？

答案 50:12 - 不一定。 因此，特別是在內容方面，我們會查看在我們登陸的最終頁面上找到的內容。 所以如果你刪除了內容，如果你清理了一些東西，我猜這會自動發生。 如果您重定向該頁面並且舊內容不再存在並且我們只有新內容，那很好。 所以這不會是任何可以進行的事情。

問題 50:45 - 當我們將頁面的移動友好版本與鏈接 rel alternate' 行為相關聯時，如果搜索控制台報告移動友好錯誤是在頁面的測試顛覆中是否自然？

回答 50:57 - 所以通常這意味著我們並不清楚這些頁面中的哪些屬於同一類。 因此，出於某種原因，我們將這些頁面單獨編入索引，而不是作為我們知道該桌面頁面屬於該移動頁面的一對。 因此，這可能與您在這些頁面上設置備用鏈接或 rel 規範鏈接的方式不匹配。 所以我也會對此進行研究，當然另一件事是我也會研究轉向響應式設計需要什麼，因為特別是在移動優先索引的情況下，所有這些問題我們都有單獨的移動URL 他們只是讓一切變得不必要的複雜。 而如果您可以遷移到響應式設計或僅對桌面版和移動版使用相同 URL 的設計。 比你省了這麼多麻煩，所以與其跟進這類問題，不如花時間說，好吧，我應該投資一個計劃來轉向響應式設計，這樣我就不必專注於這些以後還有什麼問題。

問題 1:01:01- 像其他外部鏈接一樣向維基百科鏈接和谷歌幫助文章添加 nofollow 是個好主意嗎？ 好的數據熒光筆需要多長時間才能在搜索中生效？

回答 1:01:16 - Skay 所以將 nofollow 添加到 Wikipedia 鏈接。 我認為這沒有多大意義，除非維基百科付錢給你放置這些鏈接。 因此，II 會為您不想與您的網站關聯的鏈接添加一個 nofollow。 但否則，如果它是內容中的正常鏈接，我會看起來很正常，所以除非維基百科為這些鏈接付費，否則我會認為正常。 對於數據熒光筆來說，發生的事情是一種算法過程，可能需要一些時間，因為它基於它從您網站上的索引頁面中學習的緩存頁面，並且顯然基於您處理數據的標記熒光筆，然後當我們在您的網站上重新抓取和重新索引它們時，它會將其應用於新頁面。 因此，當我們在您的網站上重新抓取和重新索引內容時，這需要一段時間才能應用於內容。 所以沒有固定的時間線，有時對於很多頁面來說相當快，有時可能需要幾個月的時間才能看到。 因此，沒有那種即時按鈕，它需要時間，就像您手動添加到頁面的任何其他結構化數據一樣。

問題 1:02:58 - Google 是否意識到並宣佈在去年 11 月底 12 月初左右開始處理重複內容的方式發生重大變化？ 或者在那個時期，網絡渲染服務開展業務的方式或網絡渲染和索引與爬網索引之間的關係是否發生了重大變化，因為我們的系統沒有任何變化，正如我所說的那樣，我們已經看到了從那時開始的實質性問題特別是不僅對我們自己，而且我們還注意到同一時期對此類問題的許多其他觀察？

答案 - 1:03:47 - 那裡發生了實質性的變化。 我認為大約在秋天左右發生的唯一一件事是，我們開始將此功能添加到搜索控制台以突出顯示這些問題，我認為這也是我開始看到更多此類報告的地方，一旦我們將其突出顯示為用戶，嘿，我們是否正在刪除這些 URL 並且喜歡它們的圖表，因為我們認為它們都是重複的，當然每個人都喜歡，哦，這是一個新問題，但在很大程度上，它基本上一直是這樣的我們只是從未在搜索控制台中談論過它。 所以我不知道我們何時開始在搜索控制台中推出該功能，但可能就像去年下半年一樣。