2019 年 1 月 22 日 - Google 幫助環聊筆記

本週約翰在紐約的大蘋果。 加入 IRL，從左到右，來自 Google 的 Java 腳本團隊的 Martin Splitt、Chris Love、Lily Ray、Marie Haynes、Dave Minchala 和 Quason Carter。 本周有一些關於 Cloudfare、QRG 和新頁面速度工具的好問題。 視頻鏈接和完整的成績單可以在下面找到！

Cloudflare 有時會阻止 Googlebot 嗎？

7:58

“是的，我現在不知道 Cloudflare 是如何設置的，但我知道過去他們曾經阻止過偽造 Googlebot 的人。所以如果你使用，比如你自己的，我不知道，Screaming青蛙之類的——你說，我正在使用 Googlebot 用戶代理，然後他們會阻止它，因為他們可以判斷，例如，這不是一個合法的 Googlebot。我們可以阻止它。但在大多數情況下，我認為他們有足夠的練習來識別正常的 Googlebot 並讓它正常爬行。”

摘要：有時，在測試時，Cloudflare 可能會阻止 Googlebot。 這裡可能發生的情況是 Cloudflare 正在阻止偽裝成 Googlebot 的人。 因此，如果您使用 Screaming Frog 之類的工具並選擇 Googlebot 作為您的用戶代理，您可能無法使用 Cloudflare 抓取網站。

不自然的鏈接仍然會在算法上傷害網站嗎？ 如果是這樣，可以使用拒絕工具幫助嗎？

14:01

“我認為這是一個很好的問題。所以從我的角度來看，我會看到，一方面，肯定是有手動操作的情況。而且，你也想要的情況看到很多手動操作會說，好吧，如果網絡垃圾郵件團隊現在看到這個，他們會給你一個手動操作。你會說，手動操作更多的是時間，而不是有點像它基於已經完成的事情——我不知道——它顯然是在幾年前完成的，而且它有點不是邊界。但是你看到的那種東西並且說，如果網絡垃圾郵件團隊的某個人得到了這個提示，他們會採取手動操作，這絕對是我會清理它並為此拒絕的那種事情。是的，我想很難說是否有具體的時間表。但總的來說，如果網絡垃圾郵件團隊看到這個並說，就像，事情已經發生了。這顯然是 d 幾年前的一個。 這並不完全是惡意的。 那麼他們可能不會為此採取手動操作。 "

我假設您可能無法回答這個問題，但有什麼辦法——比如，假設我們沒有得到手動操作，或者他們沒有得到手動操作。 這些鏈接會在算法上傷害它們嗎？ 因為我們覺得我們在一些網站上看到了一些改進，你知道，在拒絕之後。 所以，再一次，我知道它總是——它從來都不是非黑即白的。

絕對可以這樣。 所以這是我們的算法，當我們查看它時，他們會看到，哦，它們是一堆非常糟糕的鏈接，那麼也許他們會對網站的一般鏈接更加謹慎。 所以如果你把它清理乾淨，那麼算法會看著它說，哦，有——有一種——沒關係。 不算太差。

總結：如果您有專門為 SEO 製作的鏈接，並且有很多鏈接，它們可能會導致 Google 的算法不信任您的所有鏈接。 最好拒絕這種情況。

Google 的算法如何衡量出版商的 EAT？

33:40

“我不知道。我認為這可能很難通過算法計算出來。如果你應該做任何技術上的事情，那麼我們會讓你知道。所以如果有像作者標記這樣的事情，我們在某些時候我們認為對這樣的事情有用，我們肯定會把它帶到那裡。但是很多事情實際上是我們試圖弄清楚的更多的軟質量因素，這不是技術性的東西'要么在做，要么不做。更像是試圖弄清楚用戶可能會如何看待它。所以我不能指出任何具體的東西。“

總結： Google 關注了很多“軟質量因素”。 從用戶的角度看待事物。 此外，作者身份標記可以幫助 Google 更好地理解事物。

如果質量評估者指南中有某些內容，那麼假設 Google 希望將其反映在他們的算法中是否合理？

34:44

我認為，總的來說，以此為目標可能是一種好習慣。 我避免過多地關注谷歌可能使用的算法因素，而是更多地看待它——我們認為這對網絡有好處，因此，我們將嘗試朝著這個方向前進並做這些之類的東西。 所以與其說我在做一個好的網站只是為了讓我排名更高，但我做一個好的網站是因為當我出現在搜索中時，我希望人們有好的體驗。 然後他們會回到我的網站，也許他們會買點東西。 所以這就是我會看到的方向，不是為了排名，而是為了在網絡上建立健康、長期的關係。

總結：想想什麼對用戶最好。 儘管目前 QRG 中的所有內容並未反映在 Google 的算法中，但這些都是朝著提高整體質量邁出的重要一步。

是否有模式可以幫助網站在語音搜索結果中顯示得更高？

36:10

我不知道。 我什麼都想不出來。 因此，您可以使用可朗讀的標記，這可能是合理的——看看它在頁面上的哪些地方有意義。 我認為我們不會在所有地方都使用它。

總結：可口語標記尚未在所有地理位置使用。 但是，這是一個很好的起點。

贏得精選片段的一些技巧

38:03

但特別是精選片段，我認為我們沒有任何類型的特定標記。 因此，如果您在頁面上有清晰的結構，這對我們有很大幫助。 如果我們可以識別頁面上的類似表格，那麼我們可以更容易地將其拉出來。 而如果你使用花哨的 HTML 和 CSS 讓它看起來像一個表格，但它實際上不是一個表格，那麼我們很難把它拉出來。

摘要：您無法添加任何標記來贏得精選片段。 但是，很好地使用 h 標籤和普通的 HTML 表格真的很有幫助。

是否應將位置模式添加到所有頁面？

50:47

回答 51:42 - 據我所知，它只是主頁。 我不知道。 你們有誰知道嗎？

Liz 的回答 51:4 7 - 通常應該只有一頁，包含組織和公司。 這通常是建議。

MARTIN SPLITT 52:00 - 我想哪一頁都沒有關係——就像不要把它放在你所擁有的每一頁上一樣，我猜是更重要的一點。 我認為這取決於——如果你是一個新聞網站，把它放在聯繫頁面、關於頁面或其他東西中可能是有意義的。 而在商店或餐廳網站中，將其放在主頁上可能是可以的。

JOHN 52:20 - 我也認為，在這種情況下，這對我們來說並不重要，因為我們需要能夠在主頁或聯繫頁面之類的地方找到它。 但是，如果我們在其他地方擁有它，它不會改變我們的任何東西。 因此，不能與之相比的最重要的事情是評論標記，我們有時會看到人們在網站的所有頁面上放置公司評論，希望獲得星星和他們網站上每個頁面的搜索結果。 這對我們不利。 但是聯繫信息，如果你已經標記了，那是 - 我認為這沒有問題。

總結：其實無所謂。 它應該在聯繫頁面上，可能在您的關於頁面和主頁上。 擁有跨站點的位置模式不是問題，但也可能沒有必要。

為什麼基於 Lighthouse 的新 PageSpeed Insights 工具在對網站進行評分時會如此苛刻？

53:05

Marie Haynes：這不是我的問題，但為了提供一些背景信息，新的 Lighthouse 頁面速度數據比 Page Speed Insights 過去更加苛刻。 因此，在 Page Speed Insights 上得分為 80 分的東西在 Lighthouse 上可能是紅色的 29 分。 所以這是一個很好的問題。 這可能會導致 - 因為我們知道在移動設備中，速度非常慢的網站可能會被降級。 那麼，如果我們說，你知道，如果你在燈塔測試中處於虧損狀態，我們真的應該改進一些東西，因為它可能會導致降級，或者是否有截止日期？

回答 54:07 - 所以我們沒有對外部工具和我們用於社交的所有工具進行一對一的映射。 是的，這很難說，但是在搜索中，我們嘗試使用實際的，它是什麼，實驗室測試數據，有點像 Lighthouse 測試，以及 Chrome UX 報告數據，其中本質上是什麼我們正在衡量的是網站的用戶會看到什麼。

MARTIN SPLITT 55:37 - 同樣重要的是要看到 Lighthouse，例如，專門測量中端的 3G 連接——或者像中等性能的手機，是的。 所以，基本上，如果你在最近的 Apple McIntosh 或最近的快速 Windows 計算機上使用非常好的有線連接或非常好的 Wi-Fi 連接在你的辦公室，當然，你會看到兩秒的加載時間，但是在野外使用手機的真實用戶可能看不到這一點。 所以這是其中一種情況，就像讓您的網站更快永遠不會受到傷害，但這真的，真的很難說從內部的角度來看它會是什麼樣子，因為我們使用的是非常具體的指標，不一定將一個映射到一個工具所暴露的內容....當然，解決這個問題很重要，因為您不希望您的用戶永遠等待您的網站。 那會傷害你的。 這會傷害你的用戶。 這只會傷害你的搜索。 但我不付錢——我會說只是看看工具。 如果工具告訴你你做得很好，那麼你不應該太擔心它。 如果工具告訴你你做得不好，那麼我認為花在弄清楚它為什麼說上的時間——比如，如果它說的是相關的，那就浪費了。 您應該著眼於使網站更快。

移動性能對於您的用戶以及其他一切都是一個非常重要的因素。 所以我想說確保您的網站在現實條件下表現良好。 甚至可以買一部便宜的手機，時不時地嘗試一下這個網站，如果——那是我喜歡做的事情，而且在我加入谷歌之前，我曾經和我一起工作的開發團隊一起做。 我想，看，你想在這部手機上使用這個網站嗎？ 就像，哦，這太可怕了。 我想，嗯，是的，所以也許我們應該做點什麼。

JOHN - 在 Chrome 中，您可以設置它並嘗試不同的連接速度。 移動模擬器。 我認為這是非常值得一看的東西，而且，看看你的用戶群。 如果您發現人們僅使用高端 iPhone 使用您的網站，請查看您的分析數據，那麼與您看到人們從隨機的農村連接連接到您的網站相比，這可能不是問題，這是慢，而且他們有低端設備，那麼也許更多。

總結： Lighthouse 測量 3G 連接的速度，因此對於大多數會話來說，大多數站點的運行速度比此處顯示的要快得多。 注意：在本次視頻群聊結束後，Martin 繼續說，對於潛在的排名降級而言，這是最重要的“第一次有內容的繪畫”。

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

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

視頻和完整成績單

問題 1:32 - 我想知道您是否有任何更多的指導或更多的觀點來測試 SEO 可以用來更精確和更有信心向業務報告的方式。 我們嘗試了這個東西，它產生了影響。 我們以一種肯定的方式做到了，就像谷歌推薦的那樣。

回答 3:20 -所以從我的角度來看，我嘗試將更多技術類型的東西與質量類型的變化分開。 因此，任何真正明確的技術事物，您幾乎可以測試它是否有效或無效。 這不是一種工作或不起作用的問題，而是很多這些技術性的東西，尤其是當你在看渲染時，或者當你在看 Google 是否真的可以索引這些內容時，那就是一些有效或無效的東西。 它變得棘手的地方是它所涉及的一切——它被編入索引，但它是如何出現在排名中的呢？ 而且我認為在很多方面，沒有絕對的方法可以真正測試它。 因為如果您在孤立的情況下進行測試，例如創建一個測試站點，並根據您的建議進行設置，您不能真正假設測試站點的運行方式與普通網站相同。 有時有一些簡單的事情，比如如果它是一個測試站點，那麼也許我們不會進行完整的渲染，因為我們認為在這個和這個上花費這麼多時間是沒有意義的，因為就像沒有人看它一樣。 它從來沒有出現在搜索結果中，我們為什麼要費心把這麼多資源放在後面呢？ 然而，如果你在一個普通的網站上這樣做，那將有很大的不同。 所以我對你應該做什麼或不應該做什麼沒有任何明確的指導。 它看起來更像是您查看您看到該網站出現的總體趨勢，您看到這些查詢的排名變化，並嘗試在那裡應用最佳實踐的那種事情。

問題 5:21 -所以也許如果—— 一個具體的例子，你可以用它來—— 也許這會有所幫助，比如標題標籤測試，對吧？ 如果你這樣做——如果有的話，我們應該尋找什麼？ 或者有什麼可以解開的——這是由於我們的測試，還是由於服務器、算法、競爭動態的某些變化？ [笑聲] 假設我們正在做其他事情來看待這些外部性。

回答 5:56 -我認為標題標籤更改實際上對我們來說非常複雜，因為 Google 是否使用您實際提供的標題標籤，一方面，用於排名，另一方面，用於顯示在搜索結果中。 就像桌面和移動一樣，我們有不同的空間，所以我們可能會顯示略有不同的標題標籤。 用戶可能會以不同的方式對此做出回應。 因此，您可能會以相同的方式進行排名，但用戶可能會認為，哦，這是一個很棒的頁面。 我會把它顯示得更高——或者我會在搜索結果中點擊它，因為它看起來像一個很棒的頁面。 然後你有更多的流量。 但排名其實是一樣的。 那麼這是一件好事嗎？ 大概吧，我猜。 如果你只是看排名，那麼看起來，你沒有改變任何東西，我們只是獲得了更多的流量。

但這就是其中有很多不同方面的地方。 所以我認為，作為一名 SEO，一方面，對發生的事情有技術上的理解是有用的，而且對用戶如何對變化做出反應有更多的營銷和質量理解，什麼是我們可能會影響用戶的長期變化，您如何推動它以確保在人們搜索與之相關的內容的情況下我們的網站被視為最相關的網站。 我認為這真的很難測試。 就像，即使在他們已經進行了多年實踐的傳統營銷中，也很難測試，例如，這是否真的有很大的影響？ 這是他們最終著眼於大局或進行用戶研究的事情，您也可以作為 SEO 來做這些事情。 對不起。 [笑聲]

問題 7:58 - 我有一個更直接的問題。 因此，您知道，我們的許多網站都在使用 Cloudflare，我們注意到它們直接阻止了 Googlebot，對吧？ 但這對我們的排名、知名度等並沒有太大影響。 所以想弄清楚你們是如何使用另一個機器人直接在 Googlebot 之外抓取索引的，當 CDN 竭盡全力阻止機器人時，我們應該如何考慮這一點？

回答 8:33 -是的，我目前不知道 Cloudflare 是如何設置的，但我知道過去他們曾經阻止過偽造 Googlebot 的人。 所以如果你使用，比如，你自己的，我不知道，Screaming Frog 什麼的——你說，我在使用 Googlebot 用戶代理，那麼他們會阻止它，因為他們可以告訴，比如，這不是合法的谷歌機器人。 我們可以阻止它。 但在大多數情況下，我認為他們有足夠的練習來識別普通的 Googlebot 並讓它正常爬行。

問題 9:02 - 是的，這很有趣。 因為聯繫了其他機構的一群同事，他們甚至在自己的網站上也複製了類似的情況。 就像，Cloudflare 中有一張支持票，當我試圖直接從 Googlebot 或 Googlebot 智能手機進行渲染時，它也被阻止了。

回答 9:21 - 好的，是的。 好吧，我們沒有任何變通辦法。 就像，如果網站阻止了我們，我們就會陷入困境。 但通常如果像 Cloudflare 這樣的服務默認阻止我們，那麼這會影響很多網站。 我們會注意到這一點。 我們可能會就類似的事情聯繫 Cloudflare。 可能是他們有不同的服務層。 因此，如果您處於較低級別，那麼它就像一項免費服務，但我們對流量有限制。 我不知道他們有沒有類似的東西。 這是我在其他一些主機上看到的情況，如果你設置了免費的默認主機，那麼有時他們只是有流量上限，他們會阻止事情。

MARTIN SPLITT：您可能不會立即從您的排名等統計數據中看到這一點。 因為基本上，如果我們有您的內容，並且基本上，該網站不是-- 取決於被阻止的內容，在這種情況下，意味著因為我沒有看到那個。 我在 Cloudflare 後面運行了幾個網站，我沒有遇到任何問題。 但話又說回來，我沒有龐大的網站或喜歡大量的流量，因為我是免費計劃的。 那是 - 但如果您沒有在我們這邊遇到錯誤，它 - 可能只是我們保留了我們上次看到的內容。 這只是排名很好，沒關係。

回答 12:09 - 是的，所以我認為在像你這樣的情況下會發生什麼，我們會減慢爬行速度。 我們會嘗試保留我們可以在索引上獲取更多內容的內容，並且我們會重新抓取更長的時間。 但這也意味著，如果您在您的網站上進行更改，我們將需要更長的時間來處理。 如果我們必須重新抓取大量內容，例如，我不知道，AMP，或者您在整個網站上添加一些這樣或那樣的內容，那麼這一切都需要更長的時間。 因此，如果您確實經常看到我們無法使用普通的 Googlebot 進行抓取，那麼我會與主機商聯繫，以便我們查看。

問題 14:01 - 太好了。 所以我有一個關於拒絕工具的問題。 因此，我們一直都有希望我們進行鏈接審核的人。 自從 Penguin 4.0 以來，2016 年 9 月，Gary Illyes 說過，我想你也說過，就像，谷歌非常擅長忽略不自然的鏈接。 所以我當時的想法是，好吧，我們不應該使用拒絕工具來要求 Google 忽略他們已經忽略的鏈接，除非您對非自然鏈接進行了手動操作。 因此，我們只向那些積極建立鏈接、試圖操縱事物、非自然鏈接的網站推薦它。 但我認為網站管理員之間存在很多困惑，因為我一直看到人們，你知道，收取大量資金進行審計——否認那些只是——我知道他們被忽略的鏈接。 因此，如果我們能再澄清一點，我會很高興。 所以也許我可以給你舉個例子，比如，如果有一個企業主，幾年前，聘請了一家 SEO 公司，而那家 SEO 公司為鏈接做了一堆客人發帖，你知道的，是一種中等質量，如果你知道我的意思，不是超級垃圾郵件，我們可以確信谷歌忽略了這些鏈接嗎？ 還是我們應該進去否認？

回答 15:22 - 我認為這是一個很好的問題。 因此，從我的角度來看，一方面，我所看到的絕對是手動操作的情況。 但是，如果您還希望看到很多手動操作，那麼如果網絡垃圾郵件團隊現在看到這個，他們會給您手動操作。 在某些情況下，您會說，手動操作更多是時間問題，而不是基於已經完成的事情-我不知道-顯然是在幾年內完成的以前，這是一種邊界不是。 但是，如果你看到它並說，如果網絡垃圾郵件團隊的某個人得到這個作為提示，他們會採取手動操作，而這絕對是我會清理並做的那種事情就像對此的否認。 是的，我認為很難說是否有特定的時間表。 但總的來說，如果網絡垃圾郵件團隊看到這個並說，事情已經發生了變化。 這顯然是在幾年前完成的。 這並不完全是惡意的。 那麼他們可能不會為此採取手動操作。

問題 16:43 -我假設您可能無法回答這個問題，但有什麼方法可以 - 比如，假設我們沒有獲得手動操作，或者他們沒有獲得手動操作。 這些鏈接會在算法上傷害它們嗎？ 因為我們覺得我們在一些網站上看到了一些改進，你知道，在拒絕之後。 所以，再一次，我知道它總是——它從來都不是非黑即白的。

回答 17:03 - 絕對可以。 所以這是我們的算法，當我們查看它時，他們會看到，哦，它們是一堆非常糟糕的鏈接，那麼也許他們會對網站的一般鏈接更加謹慎。 所以如果你把它清理乾淨，那麼算法會看著它說，哦，有——有一種——沒關係。 不算太差。

問題 17:24 - 基本上拒絕只是為了防止手動操作仍然很好，對嗎？

回答 17:29 - 我認為，如果您確實很清楚網絡垃圾郵件小組會根據當前情況為您提供手動操作，那麼我會拒絕這樣做。

問題 17:37 - 所以，像在 Google 那樣思考是件好事——就像 Google 垃圾郵件小組中的某個人只是想，你知道，如果他們看到這個，他們會怎麼做？

回答 17:47 - 是的。

問題 17:48 - 但問題是，大多數人不知道。 我的意思是，一般企業主不知道網絡垃圾郵件團隊會使用哪些鏈接——我的意思是，有指導方針，但它非常——你知道，很難解釋這些。 所以我認為——我的意思是，我有幾個擔憂，但我主要擔心的是有人在我認為不值得的鏈接審計上花費大量資金。 另一方面，我們可能不會進行鏈接審核並拒絕某些可能從中受益的網站。 所以我很樂意，你知道，我認為你所說的幫助很大，所以我們會 - 你知道，這很好。

回答 18:22 - 是的，我認為對於絕大多數網站來說，這些網站都有正常的組合，就像你過去聽了一些不好的建議，就像你繼續前進，現在事情很自然，那麼他們真的不必那樣做。 這就是所有這些的目標，這就是為什麼拒絕工具不像 Search Console 中的主要功能。 你有點明確地尋找它。 這一切都是故意的，因為對於大多數網站，您真的不需要那麼關注鏈接。 不過，我喜歡拒絕工具的一點是，如果您對此感到擔心，您仍然可以去那裡並說，好吧，我知道我們做了幾年的一些事情以前，我真的很擔心。 然後，在我看來，否認它們不是問題。 我不會出去專門搜索所有這些東西。 但是，如果您知道它，並且您真的很擔心它，那麼您可以照顧它。

問題 19:27 - 我對我們的一個客戶網站有疑問。 所以他們有俱樂部——他們在新南威爾士州的三個城市都有俱樂部。 每個俱樂部在網站上都有一個子域。 現在，當他們將任何頁面添加到他們的網站時，他們會為每個子域創建頁面。 所以最近，他們添加了一個關於他們的俱樂部活動的頁面，並且他們已將此頁面添加到他們的所有子域中。 所以這意味著所有的子域都有相同的內容，除了頁面的標題不同。 因為當他們添加到悉尼時，他們會在標題標籤中添加他們的位置名稱。 當他們為紐卡斯爾添加它時，他們在標題標籤中添加了紐卡斯爾，但頁面上的其餘內容是相同的。 那麼會不會有問題，因為他們有 50 個子域，並且他們創建了 50 個頁面，除了標題之外的內容相同嗎？

回答 20:36 - 我猜這聽起來有點低效。 所以我的意思是，你已經提出來了，有點像是說，這似乎可以用不同的方式來做。 我認為，如果您有 50 個子域都具有相同的內容，而您只是更改標題標籤，那麼您可能沒有為我們提供很多真正有用的內容。 所以這就是我要說的情況，結合事物並製作真正強大的頁面而不是在更多子域中稀釋事物更有意義。

問題 21:44 - 創建一個頁面然後使用規範 URL 到其他位置頁面怎麼樣。 我只想創建一個頁面，我們將討論他們的活動，我將使用該鏈接作為其他位置頁面的規範 URL。

回答 22:10 - 位置 - 是的。 我認為這可能是有道理的，因為那時你又將事物結合起來了。 然後你正在製作一個強大的頁面，而不是一堆稀釋的頁面。

問題 22:20 - 因為當有人訪問該網站時會發生什麼，並且他們選擇了他們的位置，他們會自動將該人重定向到他們指定其特定位置的子域。 這就是他們需要該子域上的頁面的原因。 因此，我認為這就是為什麼如果我們保留一個頁面並添加規範 URL，那麼這就是我們目前唯一的選擇。

回答 23:08 - 好的，但我認為如果您有單獨的頁面，出於某種技術原因需要在網站上擁有它們，並且您放置規範，這是一個好方法。

問題 23:21 - 會不會像 - 一家在不同地點擁有多個特許經營權且每個特許經營權本質上具有相同內容的企業會位於不同的城市或鄉鎮，或者其他任何地方，並且從您的點回單頁？

回答 23:34 - 我認為這總是有點棘手，因為您要平衡在特定位置尋找此類業務的人與直接圍繞該業務的信息頁面。 因此，有時將業務分開是有意義的。 有時，在一個中心位置擁有某種一般信息並擁有類似的位置登錄頁面是有意義的，這些頁面更側重於地址、開放時間等。

問題 24:12 - 是的，我有一個關於你提出的規範點的相關問題。 這是我和我的團隊多年來一直存在的問題。 而且我們仍然不完全知道解決方案。 因此，如果您正在處理一個包含許多產品和許多類別的大型電子商務網站。 假設您在一個類別頁面上，該頁面具有許多不同的過濾器和方面以及性質稍有變化的頁面內容，但可能不足以證明擁有自己的 URL 是合理的。 但也許在某些情況下使用某些過濾器，它確實證明擁有站點 URL 是合理的。 那麼在這種情況下你如何處理爬行呢？ 像規範標籤一樣有效嗎？ 僅創建一個已編入索引的頁面是否是一攬子解決方案？ 或者你應該看看，你知道，不索引某些方面和過濾器，或者使用機器人，或者你如何控制大型電子商務網站？

回答 24:57 - 這很棘手。 我認為我們目前對此沒有真正明確的指導。 所以這就是所有這些不同類型的方法都有意義的地方。 一般來說，我盡量避免為此使用 robots.txt，因為我們可能會找到 URL。 我們只是不知道那裡有什麼。 因此，除非您真的看到導致服務器負載過大的問題，否則我會嘗試使用無索引之類的東西，使用 rel canonical。 也許您使用帶有內部鏈接的 rel no-follow 來指向某種漏斗事物，以便更清楚地了解我們應該抓取索引的內容，而不是使用 robots.txt。 但是，關於何時將內容組合到索引級頁面以及何時阻止其編入索引，何時將其溫和地引導至一個規範 URL 的決定，有時真的很棘手。

問題 25:53 - 因為有時如果頁面內容差異太大，規範會被忽略。

回答 25:57 - 沒錯。 如果內容不同，那麼我們可能會說，嗯，這些是不同的頁面。 我們不應該使用規範。 而你可能會說，嗯，這真的是我不想索引的東西。 也許無索引比規範更有意義。 您也可以將兩者結合起來。 我們不建議將它們結合起來，因為我們很難說，嗯，你是什麼意思？ 你是說這些是一樣的，但是一個是可索引的，一個是不可索引的，那麼它們就不一樣了。 但我想，在這一年裡，這將是一些關於在那裡可行的明確指導。 但尤其是對於非常大的電子商務網站，抓取方面可能非常具有挑戰性。

問題 26:46 - 所以最近我一直在嘗試與我的幾個客戶一起弄清楚一個場景。 我們正試圖弄清楚為什麼我們無法從本質上刪除仍在使用 HTTP 且或多或少看起來已被廢棄的網站，因為該頁面已經有一段時間沒有更新了，而且內容又舊又過時，而且通常有點薄，所以我有一些關於它的理論。 部分原因是，我認為，也許它在指數中的時間太長了，以至於你們都對它們建立了信任因素。 而且很難讓他們下台。 That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

問題 42:29 -關於旅行的旅行社網站。 我們選擇內部搜索來顯示動態內容，比如搜索城市中最便宜的 10 家酒店，好嗎？ 所以頁面框架會立即加載。 但是最便宜的前 10 家酒店結果在搜索執行後大約 30 秒內動態加載，因為網站必須在後面執行此搜索，然後比較和優化結果，以便為搜索者列出便宜的前 10 名酒店酒店。 所以列出它們需要一點時間。 所以現在，Googlebot 只能看到頁面的背景。 然後，這 10 個空佔位符是執行內部搜索後稍後加載結果的位置。 因此，既然這是旅遊網站帶來盡可能新鮮和準確的信息的趨勢，我在想，谷歌正在為此做些什麼。 當然，我們可以在這些頁面上列出一些靜態內容，就像現在所有其他網站為 Google 所做的一樣，如果我可以這麼說的話。 但這違背了大多數用戶現在想要看到的新鮮和便宜的目的。

回答 44:00 - 所以如果它沒有在那裡加載，那麼我們就不能索引它。 但通常，這更多是因為我們無法處理 JavaScript，或者可能被阻止實際訪問那裡的內容。 所以這是你可以用一種可行的方式來做的事情。 這不是設計使然，它永遠不會起作用。 因此，您可以使用諸如移動友好測試之類的東西來挖掘細節，以查看是否涉及 JavaScript 錯誤、是否被阻止，並從那裡進行改進。 所以這不是不可能的，但需要一些工作。

問題 44:42 - John，我對此進行了深入研究，確保沒有任何內容被 Google 屏蔽。 我們希望谷歌做的唯一一件事就是等待動態內容加載到頁面上，你知道嗎？ 這是下一步，如果我可以這樣說的話，因為雖然這個頁面不像一個無盡的滾動，比如說 Facebook，它是一個有限的 10 個結果頁面。 所以它是有限的。 它是有限的。 問題是谷歌應該等待一些動態內容。 我只是給你一個例子。 但我敢肯定還有很多其他的例子。 並且因為這是人們看到動態內容的趨勢，因為他們以某種方式對事物進行排序並且他們花費的時間越來越少——人們在網站上花費的時間越來越少，他們希望盡快找到完美的結果，如果我可以這麼說的話。 我想知道你們是否正在尋找這種增強功能。

回答 45:55 - 所以我們等待渲染。 但是，如果人們不耐煩，那麼這表明您無論如何都應該更快。 所以無論如何我都會對此進行研究。 但我認為看截圖，所有的項目都被封鎖在灰色的盒子裡。 所以這感覺更像是一個技術問題，而不僅僅是一個超時。

馬丁·斯普利特：是的。 我正要說，我們確實看到很多動態內容可以毫無問題地被編入索引，即使它使用 JavaScript 之類的東西。 因此，如果我們超時，那麼您可能會在搜索需要多長時間方面遇到問題，這實際上也可能反映在其他地方。 我們等了很長時間才能完成內容。

問題 46:48 - 你能給我一個時間框架嗎？ 你等多少？

MARTIN SPLITT ：這真的非常非常棘手，因為基本上——問題是，我們不能給你一個時間框架的原因是因為時間——這聽起來真的很奇怪，請耐心等待我一秒鐘. Googlebots 渲染的時間很特殊，不一定遵循愛因斯坦的原則。 [笑聲] 所以我真的不能說太多。 我能說的是，如果網絡繁忙，網絡是瓶頸，我們可能正在等待，但我們只等了這麼久。 因此，如果您花費 1 分鐘或 30 秒，那麼我們可能會在兩者之間超時。 但沒有什麼難的——如果我告訴你 10 秒，那可能有效，也可能無效。 如果我告訴你 30 秒，那可能行得通，也可能行不通。 所以我寧願不說一個數字。 我想說的是，盡可能快地把它放進去。 如果你不能快速獲得它，那麼嘗試像緩存搜索結果這樣的東西，以便搜索或多或少地在頁面上產生 - 或者在頁面上產生的結果變得越來越多 - 或多或少是即時的。 或者嘗試在您身邊進行動態渲染，這可能是一種解決方法。 您還可以嘗試的是，您可以嘗試將其放在服務器端，並且基本上嘗試在第一遍中生成盡可能多的內容。 這也有利於您的用戶，尤其是當他們使用慢速網絡時。 是的。 抱歉，我沒有任何簡單的答案，但 Googlebot 的時間很時髦。

回答 49:29 - 我認為這可能取決於網站的實際用途。 渲染速度的棘手問題之一是我們可以緩存從服務器發送的大量內容，而不是在瀏覽器中，因為我們可以將索引用於很多這些內容。 因此，有時如果 JavaScript 緩存在我們這邊，我們就不必獲取它。 然後，如果您再次比較時間，那麼它將與用戶看到的不匹配。 它與您在webpagetest.org 中看到的不匹配。 所以這真的有點棘手，對於我們確實知道需要更長時間的部分，我們會更有耐心。 但這使得測試變得棘手。 這就是為什麼我們現在擁有所有這些測試工具，它們會顯示盡可能多的錯誤，以便能夠弄清楚，例如，它根本不起作用嗎？ 它有時會起作用嗎？有時會出現什麼問題？

問題 50:29 - 對於非常大的網站，XML 站點地圖中 URL 的順序是否重要？

回答 50:34 - 不，我們不在乎。 這是一個 XML 文件。 我們提取所有數據。 我們一次處理所有這些。

問題 50:44 - 那麼站點地圖中的優先級參數呢？

回答 50:47 - 我們根本不使用它。 所以一開始，我們想，哦，這可能有助於確定我們應該多久抓取一次頁面。 但事實證明，如果你問網站管理員，他們會說，一切都是優先事項。 這是最重要的。 與我認為站點地圖中的更改頻率類似，我們還注意到，就像人們告訴我們，事情一直在變化，但它最後一次更新是在去年。 因此，如果您有更改頻率和日期，那麼無論如何我們都會從日期中獲取該信息。 所以我們忽略了變化頻率。
問題 51:35 - 是否應該將公司模式僅添加到主頁、聯繫頁面或所有頁面？

回答 51:42 - 據我所知，它只是主頁。 我不知道。 你們有誰知道嗎？

Liz 的回答 51:4 7 - 通常應該只有一頁，包含組織和公司。 這通常是建議。

MARTIN SPLITT 52:00 - 我想哪一頁都沒有關係——就像不要把它放在你所擁有的每一頁上一樣，我猜是更重要的一點。 我認為這取決於——如果你是一個新聞網站，把它放在聯繫頁面、關於頁面或其他東西中可能是有意義的。 而在商店或餐廳網站中，將其放在主頁上可能是可以的。

JOHN 52:20 - 我也認為，在這種情況下，這對我們來說並不重要，因為我們需要能夠在主頁或聯繫頁面之類的地方找到它。 但是，如果我們在其他地方擁有它，它不會改變我們的任何東西。 因此，不能與之相比的最重要的事情是評論標記，我們有時會看到人們在網站的所有頁面上放置公司評論，希望獲得星星和他們網站上每個頁面的搜索結果。 這對我們不利。 但是聯繫信息，如果你已經標記了，那是 - 我認為這沒有問題。
問題 53:05 - 我們一直在使用的 Google 網站速度測試記錄的頁面加載時間非常慢，但我們與海外同事進行的獨立測試顯示頁面加載時間非常快。 這種虛假記錄 Google 措施是否會影響我們的網站在 Google 算法中的排名？

Marie Haynes：這不是我的問題，但為了提供一些背景信息，新的 Lighthouse 頁面速度數據比 Page Speed Insights 過去更加苛刻。 因此，在 Page Speed Insights 上得分為 80 分的東西在 Lighthouse 上可能是紅色的 29 分。 所以這是一個很好的問題。 這可能會導致 - 因為我們知道在移動設備中，速度非常慢的網站可能會被降級。 那麼，如果我們說，你知道，如果你在燈塔測試中處於虧損狀態，我們真的應該改進一些東西，因為它可能會導致降級，或者是否有截止日期？

回答 54:07 - 所以我們沒有對外部工具和我們用於社交的所有工具進行一對一的映射。 是的，這很難說，但是在搜索中，我們嘗試使用實際的，它是什麼，實驗室測試數據，有點像 Lighthouse 測試，以及 Chrome UX 報告數據，其中本質上是什麼我們正在衡量的是網站的用戶會看到什麼。

MARTIN SPLITT 55:37 - 同樣重要的是要看到 Lighthouse，例如，專門測量中端的 3G 連接——或者像中等性能的手機，是的。 所以，基本上，如果你在最近的 Apple McIntosh 或最近的快速 Windows 計算機上使用非常好的有線連接或非常好的 Wi-Fi 連接在你的辦公室，當然，你會看到兩秒的加載時間，但是在野外使用手機的真實用戶可能看不到這一點。 所以這是其中一種情況，就像讓您的網站更快永遠不會受到傷害，但這真的，真的很難說從內部的角度來看它會是什麼樣子，因為我們使用的是非常具體的指標，不一定將一個映射到一個工具所暴露的內容....當然，解決這個問題很重要，因為您不希望您的用戶永遠等待您的網站。 那會傷害你的。 這會傷害你的用戶。 這只會傷害你的搜索。 但我不付錢——我會說只是看看工具。 如果工具告訴你你做得很好，那麼你不應該太擔心它。 如果工具告訴你你做得不好，那麼我認為花在弄清楚它為什麼說上的時間——比如，如果它說的是相關的，那就浪費了。 您應該著眼於使網站更快。

移動性能對於您的用戶以及其他一切都是一個非常重要的因素。 所以我想說確保您的網站在現實條件下表現良好。 甚至可以買一部便宜的手機，時不時地嘗試一下這個網站，如果——那是我喜歡做的事情，而且在我加入谷歌之前，我曾經和我一起工作的開發團隊一起做。 我想，看，你想在這部手機上使用這個網站嗎？ 就像，哦，這太可怕了。 我想，嗯，是的，所以也許我們應該做點什麼。

JOHN - 在 Chrome 中，您可以設置它並嘗試不同的連接速度。 移動模擬器。 我認為這是非常值得一看的東西，而且，看看你的用戶群。 如果您發現人們僅使用高端 iPhone 使用您的網站，請查看您的分析數據，那麼與您看到人們從隨機的農村連接連接到您的網站相比，這可能不是問題，這是慢，而且他們有低端設備，那麼也許更多。