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 发送这些内容，以便我可以在那里收集这些内容理想地工作。