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

本週，當談到網站的可信度時，John 對我們非常喜歡的 Quality Raters Guide 有了一些深刻的見解。 以下是我們認為對 SEO 最有幫助的精選問題和答案。 完整的視頻和轉錄如下！

當使用 h 標籤而不是 <p> 時，Google 如何解釋頁面？

4:34

我認為這沒有什麼大問題，我的意思是顯然像你一樣，因為你注意到它可能是清理的意義，但並不是我們會說這是一個負面影響，而是你在那裡做什麼通過說一切都很重要，您是在告訴我們這一切都同樣重要。 所以就像一切都很重要，因此沒有什麼特別重要。 所以我們很難理解頁面中的上下文。 所以這就是為什麼我大多會清理它。 我們可以弄清楚哪些部分是真正重要的，哪些部分是普通文本中的一種，這樣我們就可以更好地理解這些頁面。 我不知道您是否會因為修復它而看到直接的排名變化，但它使我們更容易弄清楚頁面的真正含義。 我認為這不會是我們會看到垃圾郵件或會看到有問題的東西，這實際上只是您沒有向我們提供盡可能多的信息，因為您告訴我們這非常重要這是一種正常的內容

摘要：這可能沒什麼大不了的。 但是，John 證實 Google 可以使用 h 標籤來確定頁面上的哪些內容是重要的以及頁面是關於什麼的。

為什麼谷歌有時不尊重聯合內容的規範？

8:56

我認為這總是一個棘手的情況，我們確實會嘗試找出與其中一些查詢最相關的頁面並將用戶直接指向那裡，但如果這些是完全獨立的網站並且他們只是發布同一篇文章，那麼就會有網站其他部分還提供了很多附加價值，這可能是該特定頁面上的信息，它可能是網站其他部分帶來的附加價值，當有人訪問那篇文章時，他們可能會離開並且看看那個網站上的其他東西，否則那也很好。 所以這總是會發生的事情，如果你正在聯合內容，你需要考慮到你聯合到其他網站的內容最終排名高於你的內容的情況，這並不總是完全可以避免的. 所以這些是你必須在那裡查看的權衡取捨這是因為頁面本身可能完全不同。 這可能是這兩個頁面上的文本塊是相同的，但可能是該頁面周圍有很多其他內容完全不同，可能是用戶評論，可能是其餘的網站本身。 因此，這又是一種權衡，您必須考慮通過聯合內容將信息帶給更廣泛的受眾是有意義的，但另一方面，您必須考慮到這些其他網站可能排名靠前您的網站在搜索該特定內容時。

摘要：如果您要聯合內容，Google 可能會選擇在重新發布站點上而不是您自己的站點上為內容編制索引。 如果其中一個頁面上有很多其他內容（例如評論），那麼 Google 可能不尊重規範。

谷歌總是能識別結構化數據標記嗎？

26:58

所以我不知道你對結構化數據組織是什麼意思，但總的來說，我們有算法試圖找出何時將結構化數據顯示為搜索結果中的豐富結果以及何時我們認為它可能沒有感覺或者當我們覺得也許我們對這個網站或結構化數據在這個網站上實施的方式不是百分百確定時，我們會更加謹慎。 因此，如果您提供有效的結構化數據標記，則不能保證它始終會在搜索結果中完全顯示。

摘要：如果結構化數據沒有為您生成豐富的結果（如搜索結果中的星號），則可能是它沒有正確實施。 但是，也可能是因為谷歌的算法決定不顯示它。

谷歌總是能識別結構化數據標記嗎？

53:46

我認為這總是有點棘手，通常涉及兩個方面。 一個是更多的問題，尤其是對於網站名稱或公司名稱更像是通用查詢的較新網站。 因此，例如，如果該網站的名稱是“匹茲堡最佳律師”或類似名稱。 然後一方面可能是公司名稱，另一方面如果有人將其輸入到搜索中，我們可能會假設他們不是在尋找該特定公司，而是他們正在尋找該查詢的信息. 因此，尤其是對於我們不時看到的新公司而言。 我們看到論壇或那裡的人說，哦，我不是為我的域名排名，然後他們的域名就像我不知道最好的 VPN providers.com 一樣，它是一個域名，但它沒有'這並不意味著您將為該查詢排名。 因此，當涉及到已經存在的更成熟的網站時，這是一回事，通常這更多地表明我們不再真正信任該網站。 因此，我們可能會認識到實際上人們正在搜索這家公司，但我們覺得公司網站本身可能不是最相關的結果，也許我們覺得有關於該公司的輔助信息，這比用戶更重要首先看看哪裡可能導致這樣的事情發生。 通常這更多的是在搜索結果的前一頁或前兩頁上來回移動。 很少有這樣的事情會導致網站在搜索結果的前幾頁都沒有出現。 我認為這就是您在問題中強調的內容，這是我認為很好的地方，即使我們不再那麼信任這個網站，那麼我們至少應該在搜索結果中的某個地方找到它，因為如果我們能告訴如果有人明確地在尋找該網站，那麼根本不顯示它對用戶來說是一種傷害。 就像對於一般查詢，人們可能會爭辯說這可能不是完美的結果，但如果我們可以告訴他們他們真的在尋找那個網站，至少我們應該讓用戶也有機會看到那個網站。 所以這就是為什麼我接受它並說好也許我們應該更好地抓住這一點，我不知道我們的算法是否正確地理解了你的網站會有多值得信賴。 我不知道這個網站，所以這對我來說真的很難判斷，但即使我們認為它根本不值得信賴，也許我們仍然應該在第一頁的搜索結果中的某個地方顯示它。 如果您還沒有這樣做，那麼您可能需要查看的另一件事是查看我們擁有的質量評估指南，那裡有很多關於可信度的信息。 其中一些值得一提，並不是我們採用這種一對一的方式並將其用作排名因素，而是其中有很多想法，尤其是當您談論一個話題時那是一種法律網站或醫療網站，那麼向用戶展示你為什麼要提供這些信息為什麼他們應該信任你是有意義的。

摘要：如果您的新品牌恰好在品牌名稱和網址中包含關鍵字，這並不意味著您應該自動為這些關鍵字排名。 但是，如果 Google 的算法不信任您的網站，那麼它的排名就不會很好。 John 向我們指出質量評估者指南以獲取更多信息。 我們的註釋：這裡還有關於我們如何認為最近的算法更新與信任相關的很好的信息。

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

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

完整的視頻和成績單

約翰福音 0:33 的註釋 - 在我們繼續討論問題之前，我只想簡單談談一件事。 正如您可能已經看到的，我們寫了一篇關於搜索控制台的博文，介紹了搜索控制台中即將發生的一些變化。 去年我們開始在搜索控制台中遷移到一個新平台，對於我們搜索控制台團隊來說，這是他們已經工作了很長時間的事情，這是我們或多或少必須完成的事情最遲年底。 因此，我們在博客文章中的一些即將發生的變化的目標是確保我們儘早通知大家。 因此，當事情以我們認為可能影響您的方式發生變化或消失時，我們希望儘早讓您知道。 我認為更改總是有點麻煩，尤其是當您擁有運行良好的流程並且有人離開並更改工具或更改工具中提供的數據時，這總是有點令人沮喪。 因此，我們無法避免其中一些變化本星期。 所以我意識到有時這有點令人沮喪，但我們希望我們會有一條相當不錯的前進道路，我們希望儘早通知您並讓您儘早嘗試，這樣當事情發生變化時您不會太驚訝。 我們也確實有很多非常整潔的東西，通過轉移到新平台並刪除一些舊功能，團隊有更多的時間來實際前進並創造新的和花哨的東西。 如果您對某些正在消失或丟失的東西或您希望在新工具中看到的某些東西有強烈的感覺，那麼您可以在那裡做，請確保在搜索控制台中使用反饋功能，不要只是去在那裡說我真的想要這個，而是給我們一些關於你想從中看到什麼的信息，比如你想通過擁有這個新功能或擁有與舊功能相同的東西來實現什麼在新的版本中，因為給我們更多的信息可以幫助我們弄清楚我們需要如何優先考慮這是我們可能錯過的一些我們應該儘早考慮的事情。 這是不是我們可以提供一種更好的方式來為您提供該信息或幫助您做那件事，而不是我們在舊工具中所做的事情。 因此，請務必進入反饋工具 向我們發送信息 就您認為您希望看到的不同內容向我們提供反饋 其中一些我們將能夠完成其中一些可能需要更長的時間，因為我們確實需要首先清理我們多年來收集的所有這些舊東西，並將所有東西轉移到新平台上。 所以對於其中的一些，我喜歡一點耐心，但如果有什麼你覺得非常強烈的事情，也可以用聲音告訴我們，所以不要太害羞。

問題 4:34 - 我們找到了一個客戶網站，他們建立網站的方式沒有段落文本，都是 h1 h2 h3 h4 標籤。 所以這些使用標題 4 標籤而不是 P 標籤。 他們網站的主要內容他們使用標題4標籤作為網站的主要內容。 這對他們的排名有負面影響嗎？

回答 4:40 - 我看不出有什麼大問題，我的意思是顯然像你一樣，因為你注意到清理它可能是有意義的，但我們並不是說這是一個負面影響，而是什麼你在那裡說一切都很重要你告訴我們這一切都同樣重要。 所以就像一切都很重要，因此沒有什麼特別重要。 所以我們很難理解頁面中的上下文。 所以這就是為什麼我大多會清理它。 我們可以弄清楚哪些部分是真正重要的，哪些部分是普通文本中的一種，這樣我們就可以更好地理解這些頁面。 我不知道您是否會因為修復它而看到直接的排名變化，但它使我們更容易弄清楚頁面的真正含義。 我認為這不會是我們會看到垃圾郵件或會看到有問題的東西，這實際上只是您沒有向我們提供盡可能多的信息，因為您告訴我們這非常重要這是一種正常的內容

問題 7:03 - 我們在搜索控制台中不斷收到隨機斷開的鏈接我想知道我們應該在那裡做些什麼來重定向它們或讓它們保持原樣？

回答 7:15 - 我不知道您在那裡看到哪些隨機斷開的鏈接，這些鏈接可能會在論壇上發布以獲取一些建議，但一般來說，如果您看到指向您網站的鏈接沒有'根本不起作用，那麼為不存在的 URL 返回 404 就可以了。 這就是 404 狀態碼的用途，也是我們的系統可以很好地使用的東西。 因此，如果有一個從不存在的 URL 返回 404，那很好。 另一方面，如果您發現有指向您網站的鏈接指向您的其他地方，您可以猜到它們的意思，也許它們只是有一個錯字或末尾有一個額外的點或類似的東西，那麼這些可能是有道理的重定向，尤其是當您看到人們通過這些鏈接時，因為這似乎是某事或有人試圖推薦您的網站，但他們並沒有完全正確。 因此，將它們重定向到正確的頁面可能是有意義的。 我認為對於這兩種情況，如果很多人訪問這些 URL，您還可以通過這些 URL 稍微查看一下流量，然後不知何故這是令人鼓舞的，因為人們想要訪問您的頁面，那麼這可能是有道理的找出一種方法來確定此鏈接的含義以及我可以將它指向哪裡，我可以將人們重定向到哪裡。

問題 8:56 - 哪些因素可能會導致在合作夥伴網站上聯合發布的內容排名良好。 儘管規範已設置為我這邊的原始內容並且已經存在了幾個月，但這是事實。 它是網站、利基或權威的問題。 我們可以在那裡做什麼？

回答 9:19 - 我認為這總是一個棘手的情況，我們確實會嘗試找出與其中一些查詢最相關的頁面並直接將用戶指向那裡，但如果這些是完全獨立的網站並且他們只是發布同一篇文章，那麼網站的其他部分也有很多額外的價值，這可能是該特定頁面上的信息，它可能是網站其餘部分帶來的額外價值也許他們會去看看那個網站上的其他東西，否則那也很好。 所以這總是會發生的事情，如果你正在聯合內容，你需要考慮到你聯合到其他網站的內容最終排名高於你的內容的情況，這並不總是完全可以避免的. 所以這些是你必須在那裡查看的權衡取捨這是因為頁面本身可能完全不同。 這可能是這兩個頁面上的文本塊是相同的，但可能是該頁面周圍有很多其他內容完全不同，可能是用戶評論，可能是其餘的網站本身。 因此，這又是一種權衡，您必須考慮通過聯合內容將信息帶給更廣泛的受眾是有意義的，但另一方面，您必須考慮到這些其他網站可能排名靠前您的網站在搜索該特定內容時。

問題 11:24 - Google 將我們的過期產品頁面報告為軟 404，因為這些 URL 重定向到相關的替代產品，並顯示他們想要的產品不可用的消息。 重定向是導致軟 404 還是重定向頁面的內容？

回答 11:47- 我懷疑這裡發生的事情是我們的算法正在查看這些頁面，他們看到此頁面上可能有一個橫幅說該產品不再可用，他們認為這適用於頁面用戶結束了。 所以這有時不是真的可以避免的。 如果您真的要用另一種產品替換一種產品，那麼重定向可能是有意義的。

問題 12:32 - Google 需要多長時間才能識別 Hreflang 標籤？ 谷歌是否有可能首先從瑞士索引並顯示德國 TLD 下網站的 CH 版本？

回答 13:02 - 所以我們實際上並不首先索引來自瑞士的內容，我們的爬蟲和我們的系統更多地位於美國而不是瑞士。 因此，我認為我們不會優先考慮瑞士內容而不是其他內容，但通常使用 hrefLang 鏈接發生的事情是一個多步驟的過程。 首先，我們必須抓取和索引這些不同版本的頁面。 然後我們必須使用您在 hreflang 標記中指定的相同 URL 對它們進行索引，然後我們需要能夠在頁面的不同版本之間遵循該 hreflang 標記，為此我們還需要返回該確認. 因此，這確實比普通的爬網和索引需要更長的時間，我們必須了解這些不同頁面之間的網絡，這些頁面都應該是這組 hreflang 頁面的一部分。 所以這對我們來說可能是正常的，我不知道，可能比我們僅僅抓取和索引單個頁面的時間長兩到三倍，以便我們可以理解 hreflang 版本之間的鏈接。 再說一次，與歐洲其他國家相比，瑞士並沒有偏愛，我認為從某種利己主義的角度來看，這對我個人來說是件好事，但在一般的全球範圍內，這是沒有意義的。 我們確實嘗試對所有網站一視同仁。 因此，僅僅因為一個網站有一個 CH 版本並不意味著它會自動排名高於德語版本。 因此，hreflang 的另一件事是在大多數情況下它不會改變排名，它只是換掉 URL。

問題 15:12 - 我最近將我網站的域從這個更改為另一個 301 重定向。 已開始更改地址，但我仍然看到舊 URL，並且已經超過三週了，這正常嗎？ 我遇到了一些問題，即 301 在遷移發生後一周內不活躍，但它們現在處於活躍狀態。 對於某些查詢，舊網站和新網站都會顯示在搜索結果中。 我在這裡可以做些什麼不同的事情？

回答 15:46 - 所以 301 重定向確實是您應該注意的。 對我們來說重要的是 301 重定向是基於每頁的。 因此，所有舊頁面都重定向到新網站上的同一頁面。 我們在幫助中心的網站移動信息中涵蓋了所有這些內容，因此我會仔細檢查並逐步檢查 URL，甚至查看這確實以應有的方式工作. 要記住的另一件事是我們單獨抓取和索引 URL。 所以我們不會一次爬取整個網站然後切換，我們一步一步地做，其中一些頁面在幾個小時內很快被爬取和索引，其中一些需要更長的時間才能重新-爬網和重新索引，這可能需要幾個月的時間。 所以這也可能在這裡發揮作用還有一些我們已經在新版本上看到的。 這也可能在這裡發揮作用，特別是如果您正在查看三到四個星期的時間，那將是正常的，最後還有什麼也起作用的是 SEO 和網站管理員發現真正令人困惑的事情即使在我們處理了該重定向之後，如果有人明確查找舊 URL，我們也會向他們顯示舊 URL。 所以這有點令人困惑，我們的系統試圖在這裡提供幫助，並且說我們知道這個舊 URL 曾經存在並且我們在這裡有新內容，但我們會向您展示它，因為這可能是您正在尋找的內容。 因此，例如，如果您對舊 URL 進行站點查詢，甚至可能在您進行站點移動之後在這裡，我們仍然可以通過站點查詢向您顯示舊網站中的一些 URL，即使我們已經處理了這些 URL 的重定向. 因此，例如，當您更改站點名稱時，您會在站點查詢中看到舊 URL 和此處提到的新站點名稱，並且從我們的角度來看，這是按預期工作的，我們正在努力幫助正在尋找 URL 的普通用戶。 對於剛剛進行網站遷移的網站管理員來說，這有點令人困惑。 所以我不知道這是否是我們會改變的東西，但總的來說我認為這是有道理的。

問題 21:46 - Google 搜索機器人如何查看網站個性化？ 我們有一個新的產品層，該網站允許基於行業位置進行個性化，甚至對單個公司也如此，這使我們能夠真正調整內容。

回答 22:12 - 我想我們上次也看過這個，但只是為了在這裡快速回答一下，重要的部分是 Googlebot 主要從美國抓取。 因此，如果您向不同的國家/地區提供不同的內容，Googlebot 可能只會看到美國版本的內容。 我們將無法為不同位置的不同版本的內容編制索引。 因此，如果您希望將某些內容編入索引，請確保它位於您網站的通用部分中，以便 Googlebot 能夠獲取該內容。 歡迎您使用個性化在整個頁面中添加其他信息，但如果您希望將某些內容編入索引，則它應該位於與個性化無關的頁面部分。

問題 22:59 - 我想知道 web.div 中非常低的性能率對網站的 Google 排名有多大影響？

回答 23:06 - 我不知道。 所以 web.dev 是一個非常酷的工具，它匯集了我們在燈塔中進行的不同測試，並為您提供這些測試的分數，並指導您完成提高這些分數的過程。 因此，當談到加快速度時，您需要注意您可以嘗試的事情，並且隨著時間的推移，它會跟踪您網站的進度，以及當您瀏覽該工具上的不同內容時。 所以我認為這通常是一個很好的做法，可以通過和努力完成，但這些也是可以遵循的很好的做法，但這並不意味著它們會自動獲得更高的排名。 同樣，如果您在這裡得分較低，這並不意味著您的網站排名非常糟糕，因為它沒有遵循最佳實踐。 因此，一方面，如果您的網站非常糟糕以至於我們根本無法正確索引它，這可能是一種情況，例如燈塔中的 SEO 分數非常低，我們無法訪問 URL 或此頁面上沒有 URL，它只是一個 JavaScript 外殼，我們無法為其處理 JavaScript。 我可能會對您的 SEO 產生嚴重影響，但另一方面，如果這只是您的網站有點慢或沒有得到完美優化的問題，我不知道這是否會對您的網站產生重大影響。 因此，我在這裡的建議是查看 web.dev 等工具中提供的建議，並考慮您可以實施什麼考慮您認為對您的網站很重要的部分，當然，如果您是搜索引擎的話另一方面，在這裡也為您的用戶提出這個問題，因為最終，如果您正在為您的用戶做一些改善事情的事情，那麼這也會對您網站的其他部分產生一種長期的涓滴效應。

問題 26:58 - Google 能否決定是否顯示結構化數據組織的信息。

回答 27:05 - 所以我不知道您對結構化數據組織的意思是什麼，但總的來說，我們有一些算法試圖找出何時將結構化數據顯示為搜索結果中的豐富結果以及我們何時認為可能這沒有任何意義，或者當我們覺得也許我們對這個網站或結構化數據在這個網站上實施的方式不是百分百確定時，我們會更加謹慎。 因此，如果您提供有效的結構化數據標記，則不能保證它始終會在搜索結果中完全顯示。

問題 28:31 - 關於網站結構和多語言多區域配置的問題，在搜索控制台中按文件夾將域拆分為單獨的服務時，我是否應該擔心 URL 參數配置。

回答 28:52 - 所以我認為，一方面我認為你正在研究這些類型的問題很好，另一方面我有點擔心你會通過子目錄對網站進行不同的配置，因為這聽起來就像您可能沒有在整個網站上使用 URL 配置參數進行清理。 所以這就是其中的東西，我不知道這裡的網站，所以很難說，但聽起來你有不同的參數，意味著不同的東西，或者可以忽略或不應該被忽略，具體取決於您網站中的各種子目錄。 一方面，這應該是可能的，另一方面，如果在某些情況下我們可以完全忽略單個 URL 參數，並且在其他情況下，這些完全相同的參數對內容至關重要，那麼我們應該能夠處理這種情況就像我們的算法可能會感到困惑並說，我們總是需要保留這些參數，或者我們永遠不需要保留這些參數，然後突然您的部分內容丟失或您的部分內容被多次索引。 因此，在這種情況下，使用 URL 參數工具肯定會幫助我們，但在我看來，嘗試清理這些 URL 參數並找到一種為您的網站 URL 提供一致結構的方法可能更有意義，所以算法不必猜測，算法不必弄清楚，哦，在這個特定的路徑中，這個參數很重要，在這些其他路徑中我們可以忽略它。 每當您為網站的抓取和索引添加如此多的額外複雜性時，您就會遇到可能出現問題的情況。 因此，您保存得越容易，保存得越乾淨，就越簡單，並且您可以將其保存在您的 URL 結構中，我們就越有可能無需三思而後行地抓取該網站並將其編入索引，並且一如既往還有其他搜索引擎沒有 URL 配置工具。 我們在那裡擁有的數據，因此他們無法看到，您可能會在其他搜索引擎上造成問題，或者它也可能影響您的內容在社交媒體上的共享方式。 所以所有這些事情都在這裡發揮作用。 我在這裡的一般建議是不要花太多時間嘗試為所有這些不同的子目錄微調 URL 參數處理工具，而是花時間並投入到思考你希望作為 URL 的內容上從長遠來看，結構並考慮獲得更清晰的 URL 結構所需的步驟。

問題 32:17 - 我希望對我發布的與內容相關的問題有所了解，因為重複提交的 URL 沒有被選為規範。

回答 33:04 - 所以總的來說，我認為這裡發生的事情是出於任何原因，我們的算法認為這些頁面是等效的，我們可以將它們折疊在一起，因此我們從其中一個頁面中選擇一個規範，它看起來就像在瀏覽器中手動查看頁面一樣，它們實際上是完全不同的頁面，因此將它們折疊在一起沒有意義，因此從該資產中選擇規範也是沒有意義的。 我過去看到的導致這種情況的一件事是我們無法正確渲染內容。 當我們實際上無法正確訪問內容時，當我們基本上看到我們說的一個空白頁面時，哦，這與我們看到的另一個空白頁面相同，也許我們可以將它們折疊在一起。 因此，這是我會採取的一種方向，以思考谷歌如何認為這些頁面是等效的，是否有可能在移動友好的測試中就像它們沒有實際內容一樣。 可能是我向 Googlebot 意外展示了一個插頁式廣告，並且只有該插頁式廣告被編入索引，這裡可能會發生什麼？ 我還沒有機會在這裡詳細研究它，所以可能是你身邊發生了這樣的事情，也可能是我們身邊發生了一些奇怪的事情，我們需要解決這個問題，但那很好在這種情況下我會採取的方向。

問題 34:41 - 我想在我的網站上更好地導航我的客戶我想確保這不會讓谷歌感到困惑。 我想將我的 URL 結構設置為像域一樣，然後是類別，然後是路徑中的產品，或者我設置不同我應該做什麼，我應該選擇哪個 URL 結構？

回答 35:13 - 從我們的角度來看，您可以使用任何 URL 結構。 因此，如果您正在使用一種非常好的路徑子域子目錄結構，那麼對我們來說很重要的是，我們不會跑到無限空間中。 So if you use URL rewriting on your server that it's not the case that you can just add like the last item in your URL and just continue adding that multiple times and just it always shows the same content but it should be a clean URL structure where we can crawl from one URL to the other without getting lost in infinite spaces along the way. You can use your URL parameters if you want but if you do decide to use your URL parameters like I mentioned in one of the previous questions try to keep it within a reasonable bound. So that we don't again run off into infinite spaces where lots of URLs lead to the same content but whether or not you put the product first or the category first or you use an ID for the category or write out the category as text that's totally up to you. That doesn't have to be a line between your ecommerce site on your blog that can be completely different on both of these. So I think it's good to look at this but on the other hand I lose too much sleep over this and rather define the URL structure that works for you in the long run in particular one that you don't think you need to change in the future. So try not to get too narrow down and pick something that works for you, works for your website.

Question 37:43 - We're developing an application for angular Universal with some sections we want to change the appearance of the URLs in the browser but keep it the same on the server side. So for the server it would be luxury goods leather bags but the user would see just leather bags. Is there any problem with this in angular Universal using dynamic rendering?

Answer 38:08- So just from from a practical point of view Googlebot doesn't care what you do on the server you can track that however you want on your server. The important part for us is that we have separate URLs for separate pages that we have links that Googlebot can click on that are in kind of a elements with an href pointing to a URL that we can follow and that we can access these URLs without any history is with them. So if we take one URL from your website we can copy and paste it into an incognito browser and it should be able to load that content and if it loads that content if you have proper links between those pages then from our point of view how you handle that on your server is totally up to you. Using angular Universal with dynamic rendering or if you have something of your own that you set up that's all totally up to you that's not something that we would care about. It's not something we would even see because we see the HTML that you serve us and the URLs that you serve us.

Question 39:18 - My website fetches individual web pages which are not interlinked through an API but no links are displayed through clicks. It has a search box where every individual page shows search results is Google is successfully crawling all links as valid via sitemap does Google see this is a valid practice because links and millions will harm rankings or increase ranking.

Question 39:48 - So there are lots of aspects in this question where I say this sounds kind of iffy there is some things that sound kind of ok. So if Google is already indexing these pages then something is working out right. In general I I'd be careful to avoid setting up a situation where normal website navigation doesn't work. So we should be able to crawl from one URL to any other URL on your website just by following the links on the page. If that's not possible then we lose a lot of context. So if we're only seeing these URLs through your sitemap file then we don't really know how these URLs are related to each other and it makes it really hard for us to be able to understand how relevant is this piece of content in the context of your website, in the context of the whole web. So that's that's one thing to kind of watch out for and the other thing to watch out for. The other thing too watch out for I think is if you're talking about millions of pages that you're generating through an API with a search box and just so many of those via sitemap files. I may be kind of cautious there with regards to the quality of the content that you're providing there. So in particular if you have like product feeds if you're using RSS feeds to generate these pages, if you're doing anything to automatically pull content from other websites or from other sources and just kind of republishing that on your site then that's something where I could imagine our quality algorithms maybe not being so happy with that. Similarly if this is all really completely republished from other web sites I could imagine the web spam team taking a look at that as well and saying well why should we even index any of this content because we already have all of the content indexed from from the original sources. Like what is the value that your website is providing that the rest of the web is not providing. So that's one thing to kind of watch out for. I don't want to kind of suggest that your website is spammy I haven't seen your website but it is something that we do see a lot and it's something where as a developer you go, oh I have all of these sources and I can create code therefore I can combine all of these sources and create HTML pages and now have a really large website without doing a lot of work, and that's really tempting and lots of people do that, lots of people also buy frameworks that do this for you but it doesn't mean that you're creating a good website. It doesn't mean that you're creating something that Google will look at and say oh this is just what we've been waiting for we will index it and ranked it number one for all of these queries. So it might mean that it looks like very little work in the beginning because you could just combine all of these things but in the end you spend all this time working on your website when actually you're not providing anything of value then you end up starting over again and trying to create something new again. So it looks tempting to save a lot of work in the beginning but in the long run you basically lose that time. So it might make more sense to figure out how can you provide significant value of your own on your website in a way that isn't available from other sites.

Question 43:34 - We're facing an issue where lots of resources couldn't load through the to the same page not getting rendered in the snapshot for Googlebot while debugging these issues we couldn't find a solution and Google is marking them as other error. What could that be?

Answer 43:51 - So this is also a fairly common question what is essentially happening here is we're making a trade-off between a testing tool and the actual indexing and within the testing tool we try to get information as quickly as possible directly from your server but at the same time we also want to give you an answer fairly reasonably quickly so that you can see what is happening. What what tends to happen here is if you have a lot of resources on your pages that need to be loaded in order for your page to load then it could happen that our systems essentially timeout and we try to fetch all of these embedded resources but we don't have enough time because we want to provide an answer to you as quickly as possible. So you end up seeing these embedded resources not being pulled and you see an error in the live rendering of the page like that. When it comes to indexing our systems are quite a bit more complex though we cache a lot of these resources. So if we try to index an HTML page we'll know all of these CSS files we've seen before we can just pull them out of our cache we don't have to fetch them again we can render those pages normally and that just works. One thing you can do or maybe they're two you can do to to kind of help improve that for the testing tool and for users in general. On the one hand you can reduce the number of embedded resources that are required on your pages. So instead of having a hundred CSS files you've you kind of throw them into the tool you create one CSS file out of that that's one thing that you can do that makes sense for both users and for search engines. You can do that for JavaScript as well you can minify the JavaScript you can combine things and kind of make packages rather than individual files I think that's a good approach. The other thing is if you're seeing this happening for your pages and you don't have a lot of embedded content then that's kind of a hint that your server is a bit slow and that we can't kind of fetch enough content from your server to actually make this work. So that might be a chance to look at your server your network connectivity and to think about what you can do to make that a little bit faster so that these tools don't time out so that it's also faster for users as well. So in both of these cases the net effect is that users will mostly be seeing the speed improvement but the side effect will also be that you'll be able to use these tools a little bit better because they tend not to time out as much.

So what what I would do there is try to use some other tools to figure out is this really a problem on your side somehow that things are a little bit slow or is this something just on Google side that we we tend not to have as much time to fetch all of these individual resources so what you could do is use the the chrome developer tools what is it the network tab that you have there and to figure out like how many of these resources are being loaded how long does it take you can use webpagetest.org it also creates a kind of a waterfall diagram for your content also listing the the time that it takes for those test URLs and the size of the resources that were to return and by using those two you can kind of figure out is is it the case that it just takes 20 seconds to load my page with all of the embedded content with all of the high resolution images or is it the case that these testing tools say my page loads in 3 or 4 seconds with all of the embedded content therefore it's probably more an issue on Google side I don't have to worry about it.

Question 53:46 - I've noticed as a result of the last several updates that have been coined the the medic update. I've seen some websites that no longer show on the first page of search results for their own company, for their own brand, and I was wondering why in general what would that be?

Answer 54:35 - I think that's that's always a bit tricky there usually are two aspects that are involved there. One is more an issue especially with newer websites where the website name or the company name is more like a generic query. So if for example the the website's name is “ Best Lawyers in Pittsburgh” or something like that. Then on the one hand that might be the company name, on the other hand if someone were to type that into search, we would probably assume that they're not looking for that specific company but rather they're looking for information for that query. So that's especially with newer companies that's something that we see every now and then. We see that the forums or people there saying, oh I'm not ranking for my domain name, and then their domain name is something like I don't know best VPN providers.com it's like well, it's a domain name but it doesn't mean that you will rank for for that query. So that's one thing when it comes to sites that are a little bit more established that are out there already usually it's more a sign that we just don't really trust that website as much anymore. So that's something where we might recognize that actually people are searching for this company but we feel maybe the company website itself is not the most relevant result here, maybe we feel that there is kind of auxiliary information about that company which is more important that users see first where which could result in something like this happening. Usually that that's more a matter of things kind of shuffling around on the first one or two pages in the search results. It would be really rare that that's something like that would result in a website not showing up at all the first couple pages of the search results. I think that's that's kind of what you highlighted there with your question and that's something where I think well, even if we didn't trust this website as much anymore then we should at least have it somewhere in the search results because if we can tell that someone is explicitly looking for that website it would be a disservice for the user to not show it at all. Like for maybe for generic queries one could argue maybe it's not the perfect result but if we can tell that they're really looking for that website at least we should give the user a chance to see that website as well. So that's kind of why I took that and said well maybe we should be catching this a little bit better and II don't know if our algorithms are correctly kind of understanding how trustworthy your website there would be. I don't know the website so that's really hard for me to judge but even if we think that it wasn't trustworthy at all maybe we should still show it somewhere in the search results on the first page. The other thing to maybe look at if you haven't done so already is look at look at the quality rater guidelines that we have and there's a lot of information about kind of trustworthiness in there. Some of that is worth taking with a grain of salt it's not that we take that kind of one-to-one and use that as a ranking factor but there there are a lot of ideas in there especially when you're talking about a topic that's a kind of legal website or medical website then it does make sense to show users like why are you providing this information why should they trust you.