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

So what I would recommend doing there is if you have a preference with regards to your urls make sure that you're being as clear as possible within your website about what version you want to have indexed. With UTM parameters you're also creating the situation that we'd have to crawl both of those versions so it's a little bit more overhead if it's just one extra version that's probably not such a big deal. If you have multiple UTM parameters that you're using across the website then we would try to crawl all of the different variations which would in turn mean that maybe we crawl, I don't know, a couple times as many URLs as your website actually has to be able to keep up with indexing. So that's probably something you'd want to avoid. So my recommendation would be really to try to clean that up as much as possible, so that we can stick to the clean URLs. To the URLs that you want to have indexed instead of ending up in this state where maybe we'll pick them up like this, maybe we'll pick them up like this, and in your reporting it could be like this, it could be like this. You have to watch out for that all the time. So keep it as simple as possible.

Question 21:56 - Will there be any ability to test and view desktop renders with screenshots in the URL inspection tool in search console?

Answer 22:05 - I get these kind of questions all the time. It's like will you do this in search console or will you do that. And in general we try not to pre-announce things so I don't really have any insight that I can give you there with regards to what will happen in the future. It does seem like something that is kind of a missing aspect of the tool in that it's focusing on mobile at the moment but it might be nice to actually test the desktop version as well. So I'll definitely pass that on to your team to make sure that that's on their radar somewhere.

Question 22:41 - On one website with a couple million pages we have a sidebar which has internal links in it and next to each there's a number which represents how many sub pages that link leads to. Sort of as an information informative visual aid and generating those numbers takes a lot of time is it okay to remove those numbers for the front page when Googlebot is detected?

Answer 23:08 - So Googlebot should be seeing the equivalent version of the page as users would be seeing. So if this is something that's useful for users I'd recommend showing it to Googlebot as well. It's something where if you're talking about the speed that it takes to to render these pages it's worth keeping in mind that we look at speed on kind of a holistic way we don't just look at the speed of a page as Googlebot is fetching that page when it comes to speed with regards to using speed as a ranking factor. For crawling of course having the pages that are available very quickly that helps us quite a bit so that makes sense to kind of make things fast for Google for crawling at least. One thing I'd recommend here though is try to avoid special casing Googlebot if if at all possible because it does mean that maintenance is a lot harder. If you're doing special for Googlebot then it's a lot harder to tell if Googlebot is seeing errors on the page and users are seeing normal content and Googlebot starts dropping those pages from search because of those errors. So ideally treat them a lot the same as users. One way you could do that here is to use some kind of JavaScript to just asynchronously load that extra information. So that's usually pretty easily doable probably less effort than cloaking to Googlebot in a case like this.

Question 24:47 - Does link equity pass through links on canonical pages or is it just ignored and everything flows to the canonical? So I think the question is more that you have one page it has a rel canonical pointing to a different page and the question is will those links on that original page kind of work pass PageRank or will only that pay the links on the specified canonical page pass PageRank?

Answer 25:18 - So from our point of view there are multiple things I've come into play here. I think first of all those pages should be equivalent if you're saying that there's a canonical for that page it should be equivalent to the final page as well. So it shouldn't matter which of these pages is used for forwarding links because you're essentially telling us these pages are the same we can treat them the same. So it shouldn't matter for our algorithms like if we pick up those links on that page or we pick up the links on the other page. So II would also assume there that not always kind of like in the other question with UTM parameters we would pick the URL that is specified as canonical as the one that we actually index. So if those links are different across versions of pages then that's something where we might not pass PageRank in the way that you're expecting. So all of that kind of comes together and from my point of view what I'd recommend there is just really making sure that those pages are equivalent. So that you don't have to worry about from where, which links are passing PageRank. But rather assume that it could be this page, it could be the other page, the rel canonical is a strong signal for us but it's not a directive that prevents us from using that page completely.

Question 26:50 - Is it a good idea to create a website for every country in the world?

Answer 26:58 - So the short answer there is no that's a terrible idea. Especially if you don't really have content that's unique to every country in the world. In particular if you're using hreflang between the different country and language versions. You need to keep in mind that hreflang does not make those pages rank higher in those countries it just swaps out those URLs. So you still have to be able to rank in those individual locations. Which means if you have one piece of content and you split it up across every country in the world and multiply it by every language then you'll have diluted your contents significantly across a large number of URLs. Which means that any piece of content there will have a lot more trouble being shown in the search results. Because instead of one strong page that we could show potentially worldwide, we have a ton of different pages that all show more or less the same content and none of them are particularly strong. So that's something where when it comes to an internationalization strategy I would strongly recommend getting help from people who have done this successfully for other websites. So that you can really weigh kind of the pros and the cons there. On the one hand you have the advantage of being able to target individual countries and languages with content that's really uniquely kind of specialized for them and on the other hand you have to weigh that if you're diluting the content too much then all of those versions will have a lot harder time to be visible in search. So on the one hand targeting well on the other hand kind of making sure that the versions that you do have available are strong enough to actually be be visible in search and my general thought there is to err on the side of using fewer versions rather than using more versions. So unless you have a really strong use case for having content specifically targeted for individual countries and I err on the side of well maybe one global website is better rather than splitting things up.

Question 29:25 - Can we use both rating schema and question-and-answer schema for question answers

Answer - 29:33 - Sure I don't see offhand why not. The main thing to keep in mind is that the structured data should be focused on the primary content of the page. So I don't know how exactly you would kind of combine the rating and the QA schema on a page but maybe it's something like you have questions and answers to a product and you have ratings at that product as well. That might be an option there but in general it's not that these types of markups are exclusive and you can only use one type you can combine multiple types of markup.

Question 30:41 - So our site had maybe like 5,000 Google visitors per day for several months now we're down to under 500. This was due to a sudden, just happened in one day, we think it's due to an automatic security penalty that we got removed within one business day and we just haven't seen any change within three weeks. So I'm wondering how long was something like that it might take to recover from and if there's anything else that would cause just a sudden one day drop like that?

We got a message in search console that social engineering content was detected. It turns out that was due to our email service provider there click track my software was was automatically flagged because I guess another clients was using it so we were we got a manual review and within a business day and they said it was ok but you know.

Answer 31:48 - Ok so if there was a manual review then that would be resolved. So it's not that there is kind of a hold back after manual review that says, oh we have to be careful with this website, but that should be resolved there. I know It's kind of hard to say just in a general case with regards to a site like that there there are sometimes algorithmic changes that happen that roll out we're bigger change happens with within a day or so. So that might also be playing a role here it might also be that there's something else kind of playing in with the site there. So what what I generally recommend doing is maybe starting a thread in the webmaster help forum with the URL of your site and some of the queries where you're seeing changes. So not just like we had this many queries and now it's like down to this but rather like people are searching for our company name they're still finding our company name but for this particular kind of query we're no longer visible anymore. So that that kind of thing is it's really useful to post in the webmaster help forum and usual also when when people can't find an answer for that, the experts there are able to escalate that on to us so that we can take a look at that as well.

Question 33:24 - So they have multiple sites in German for different countries and they have the a hreflang setup. It sounds like instead of properly. So this is just what the example URLs, it's hard to say but they're saying that they're not seeing a lot of indexing of these URLs across the different country versions so what what could be happening here?

回答 33:54 - 所以通常當我看到這樣的問題時，它歸結為我們的算法查看這些頁面並說這些頁面本質上是彼此重複的。 所以我們可以索引其中一個版本，我們可以向用戶展示那個版本，因為它都是一樣的。 因此，特別是在德語中，這是我看到的很多東西不同國家。 所以這裡發生的事情是從索引的角度來看，我們可能會，至少有可能，將這些 URL 折疊在一起，以便多個德語版本我們選擇一個德語版本，並說這是帶有 hreflang 標記的德語版本的規範我們' d 仍然能夠顯示其他 URL。 因此，我們可能會索引瑞士德語版本，如果我們正在搜索德國的用戶，我們將能夠在搜索結果中將該 URL 替換為德語版本。 但是在搜索控制台的索引報告中，您只會看到該 URL 被索引為瑞士版本，這是我們選擇的規範版本。 因此，對於德語版本，您不會看到這一點，實際上，如果這些頁面確實完全相同，那是可以的，因為我們正在交換 URL，用戶正在使用正確的版本，這幾乎可以，但困難可能是如果您在標題中有內容，或者如果您在這些頁面上有價格或其他結構化數據，這可能會使用戶感到困惑，因為德國的用戶可能正在搜索我們顯示德語 URL 但在片段中它有瑞士貨幣作為某處的價格。 所以這可能會讓人們感到困惑，所以通常有兩種方法，一方面你可以採取這種方法並說將這些 URL 折疊在一起很好，這讓這些歐元對我來說有點強，沒關係。 然後你可能會進去說好，我會確保這些頁面是通用的，跨越所有德語版本，這樣對我來說，哪個 URL 被實際編入索引並不重要。 另一種方法是確保這些 URL 被清楚地視為前導單獨的 URL。 因此，請確保不同語言版本的內容確實存在顯著差異，以便我們的系統在查看這些頁面時會說，這是一個德語頁面，這是一個不同的德語頁面，這兩個頁面之間有一個 hreflang 鏈接所以我們可以換掉這些 URL，但它們是唯一的頁面，它們需要自己單獨索引。 所以這些是兩種方法的一種，一方面你可以把東西折疊在一起，另一方面你可以說，我希望這些明確分開。

問題 37:00 - 如果一個品牌在國際上有影響力，並且一旦在某些地區關閉，你有什麼建議。 如果他們重定向主站點，您會如何處理針對其他國家/地區的站點？

回答 37:14 - 從本質上講，這是一種站點遷移情況，我想如果您有一個國家/地區站點，並且您說這個站點不再可用，我會將其重定向到我自己的另一個版本。 這是你可以做的事情。 您實際上不能做的是在搜索中指定告訴我們我們不應在特定國家/地區顯示此站點。 所以你可以把你的德語版本折疊在一起，然後說像德國奧地利瑞士他們都應該是一個很好的德國網站，但我不想向瑞士的用戶展示我的網站，但你不能。 沒有元標記可以告訴 Google 不要在瑞士顯示我的網站。 因此，您最多只能阻止該國家/地區的用戶訪問該網站，但您不能告訴 Google 不要在該國家/地區的搜索結果中顯示它。

問題 38:18 - 這是我的問題。 我們的網站是英文的，我們有不同國家的獨特內容。 因此，由於業務決策，他們有點關閉某些地區。 因此，如果我們對網站進行一些重定向，是否會影響我的主網站，是負面影響還是正面影響？ 我的意思是我們目前在所有具有公共頁面的子集上都有這個hreflang，我們可以看到就像我的意思是我們在一個特定國家提供一種產品，在另一個國家提供具有不同內容和所有地區本地內容的單一產品。 所以我想知道這些頁面會發生什麼？ 如果我將這些頁面重定向到我的主站點，我的主頁面是否會針對這些特定區域進行排名？

回答 39:19 - 這可能會發生，但我再說一遍，這不是你能真正控制的事情。 因此，如果您在這些頁面仍然存在的情況下重定向這些頁面，那麼它們也可能在這些位置排名，您不能說沒有元標記，或者您可以說我的網站應該被索引但不顯示在這個特定的國家。

問題 39:50 - 谷歌有這本你的 UX 手冊，用於最佳實踐，以取悅不同領域的用戶。 這些是否被視為排名的一部分，或者您可以對此提供一些見解嗎？

回答 40:02 - 因此，據我所知，那些 UX 手冊是由廣告團隊推出的，這更多的是，這些是 UX 最佳實踐和在網站上做的好事，不一定是我們的事情。 d 說，這些對排名有影響，但很明顯，如果你製作了一個對用戶很好的網站，那麼你肯定會間接地看到排名的影響。 但這並不是說我們會說看看這些用戶體驗手冊並專門將它們用作排名因素。

問題 40:38 - 會員鏈接與針對敏感主題的內容混合時會產生什麼影響。 我們知道，激進的貨幣化可能會帶來問題，尤其是在未向用戶披露附屬鏈接以及關注貨幣化比向用戶提供優質內容更重要的情況下，但我想知道這對於健康、醫療、金融等主題有何作用ETC。？

回答 41:05 - 所以總的來說，據我所知，我們沒有明確進入該網站並說，有些鏈接看起來像附屬鏈接，因此我們會將這個網站視為質量較低的網站。 一般來說，我看到的關於附屬網站的主要問題是它們往往只是質量較低的網站。 因此，與其說是結賬流程在哪裡，不如說是整體內容通常質量低下，並且由於低質量的內容，我們的算法可能會接受並說，這可能不是搜索結果中顯示的最相關的結果，並且可以有真正高質量的附屬網站。 因此，與其說有沒有附屬鏈接，不如說是網站的其他部分怎麼樣？ 這是與向用戶展示相關的東西還是那裡可能存在問題？ 我認為，至少據我所知，這將全面適用，因此網站的特定主題領域是什麼並不重要，但總的來說，有一些非常好的附屬網站，有些非常糟糕附屬網站。 所以更多的是一個網站好還是一個網站糟糕？

問題 42:35 - 隨著舊搜索控制台棄用 fetch 和 render 並取而代之的是 URL 檢查工具，UL 檢查工具是否會更新，以包含 Googlebot 如何查看頁面與用戶如何查看頁面的並排視覺比較看他們？

回答 42:53 - 我不知道與其他問題一樣，我們盡量不預先宣布事情，因此我無法具體說明未來會發生什麼。 我也很高興將此傳遞給團隊，以查看優先級。 從實際的角度來看，我一直覺得這種比較現在已經不太有用了，因為大多數網站都非常擅長確保可以為搜索引擎呈現頁面。 至少我看過的網站往往是好的一面。 因此，特別是在網站不那麼習慣於搜索引擎實際上試圖呈現一個很大的頁面但現在我不知道這是否真的是一個如此大的問題時，例如 javascript 是否被阻止robots.txt，我覺得這些年來發生了很大變化，但我很樂意將其轉交給團隊，他們可能會仔細檢查是否真的存在我們需要解決的問題。

問題 44:12 - 可以鏈接拒絕提升排名嗎？

回答 44:17 - 哦，天哪，這是一個很大的問題。 因此，理論上，如果您的網站因您購買的鏈接或隨著時間的推移為您的網站購買的其他人而手動操作而降級。 也許是以前的 SEO，也許是在您與該公司合作之前設置的東西，然後您可以使用拒絕工具從我們的系統中刪除這些鏈接，然後您可以使用重新考慮請求表讓我們知道此更改然後人工垃圾郵件小組會查看並仔細檢查當前狀態是否正常。 如果當前狀態是乾淨的，那麼他們將解決該手動操作，並且通常您的網站將能夠再次自然排名。 因此，在許多情況下，網站可能會上升一點，在某些情況下排名也可能是這些不自然的鏈接在開始時不自然地支持網站。 因此，通過刪除這些鏈接，這種支持可能會消失，這是一種自然狀態。 所以我想更簡短的答案是這裡沒有是或否，因為鏈接拒絕確實改變了我們所看到的指向您網站的鏈接，這可能會對您的網站產生積極或消極的影響。 因此，如果您對鏈接進行手動操作並且無法刪除這些鏈接，或者如果您在查看鏈接時意識到，那麼我通常對拒絕工具的建議是使用它可能是兩年前，網絡垃圾郵件團隊沒有註意到，但也許是時候清理我們的行為並清理它了，那麼使用拒絕工具是有意義的。 我不會隨意使用它並說這些是奇怪的鏈接，我不想與它們相關聯我希望谷歌可以更好地對我的網站進行排名，因為當我刪除這些鏈接時，這不太可能發生。

問題 46:27 - John 我可以在這裡提出一個基於拒絕的問題嗎？ 所以我們有時會看到，我猜可能是競爭對手，我們只會看到一個地方向我們的主頁發送了 1.1 或 1.2 鏈接。 完全題外話，愛爾蘭以外的儀器維修站點，顯然與我們所做的無關。 我沒有拒絕所有鏈接的工具或能力，然後最好拒絕該網站嗎？

回答 47:01 - 當然可以。 是的，這就是拒絕文件中的域條目的用途，就像所有這些數百萬或數千個鏈接一樣，您可以從該站點說出所有內容，而我與此沒有任何關係。 通常，在您看到這個完全隨機的網站鏈接的情況下，會發生什麼情況是該網站可能被黑客入侵了，無論出於何種原因，有人決定在黑客入侵網站時將所有這些鏈接都放在那裡，通常我們很擅長撿起它並試圖在他們入侵我們的系統之前阻止該狀態。 所以可能我們已經忽略了這些鏈接，有可能甚至是從以前的網站索引而不是被黑客入侵的內容。 所以這就是我通常不會太擔心的事情，因為這類黑客真的很常見，我們有一些練習來嘗試解決這個問題。 但如果你擔心這個，你知道哦，這真的很瘋狂，我認為樂器維修鏈接可能不是你想說的，哦，如果我與小提琴有關，這會毀了我的網站，也許成人內容是您會更加謹慎的事情，然後我會使用拒絕文件提交，並且您確定不會考慮這些內容。

問題 48:44 - 關於這個 URL 的兩個快速問題，它是一個電子商務網站的類別 URL，它具有一種查看全部參數，基本上我們的問題是 URL 具有不帶參數的版本的規範。 它與整個網站上沒有參數的版本相關聯，它在沒有參數的站點地圖中，但不知何故谷歌決定不這是規範版本，我們所有的信號都指向另一個版本，我認為它的作用不那麼大，但是我不明白為什麼當我們所有的信號都指向同一個方向時，谷歌不選擇我們的版本？

問題 48:24 - 我不知道，很難隨便說。 所以我認為要記住的一件事是它處於移動優先索引之下。 因此，也許移動版本略有不同，也許有一個 rel canonical，也許 JavaScript 的某些東西正在改變我不知道的 rel canonical，但這總是需要牢記的。 因此，當您在瀏覽器中對其進行測試並確保您仔細檢查了移動視圖時，就像之前的其他問題一樣，也有可能出於任何其他原因，我們決定得很好，實際上這是更清潔的版本。

問題 50:33 - 如果它沒有從任何地方鏈接，並且您知道內部鏈接沒有指向它。 它不是站點地圖，它通過對 Google 的 URL 檢查確實看到了正確的規範，我們說它只是 Google 選擇的規範，它仍然是這個而不是我們標記的。 所以我不知道它是否會產生任何影響，我只是擔心我們遺漏的某些東西可能也會影響其他頁面。

回答 51:11 - 是的，我不知道我必須看看。 一般來說，如果它是相同的內容，那麼排名將是相同的。 所以這並不是說那裡會發生任何變化。 我不知道用護髮產品賄賂我是否特別有用，但我不知道。 所以我的意思是，在這種情況下，你有一個查看所有頁面，而另一個版本的頁面可能是我們正在接收一些信號，說這是我們應該保留的查看所有版本那一個而不是另一個，因為它可能是分頁的或類似的東西，但是是的，我不知道是否我必須深入研究它。 另一件可能值得一提的是，我們想整理一些關於電子商務網站最佳實踐的文檔。 因此，如果您遇到此類奇怪的事情，我們在電子商務網站上使用得很好，您通常會擁有這些類別頁面，這些頁麵包含大量內容，並且分頁、過濾和查看所有內容都有些棘手，那麼這就是我很想得到反饋。 所以也許例子可能只是關於電子商務網站的一般問題，所有這些都非常有用。 理想情況下，可以通過 Twitter 發送這些內容，以便我可以在那裡收集這些內容理想地工作。