 All right, welcome everyone to today's Webmaster Central Office Hours Hangout. My name is John Mueller. I am a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do are these Office Hour Hangouts with webmasters and publishers, SEOs, anyone who's keen on making their website and making it visible in search. As always, a bunch of questions were submitted ahead of time. But if any of you want to get started with the first question, you're welcome to jump in now. Can I start with one question? Yeah, about translation. For example, I know if I translate English content to Russian or Ukrainian as well, it's not good if I just, a lot of people, they use only Google translation. And at this point, just put the content. But it's like 90% of correction. It's not good. If you read like native speaker. And I'm interested, for example, two points. If I want to make some other version of, I mean, like other language to my website, like English, Russian, Ukrainian. And second one, if I find some interesting article about my niche and I want to translate, is it good or not? Or I need to make like adaptive or domestic readers. I think it's fine to have a combined website like that. I think for users, it makes sense to make it so that it stays easy for them to read. So that if you're an English speaker and you go to your website, it's not like it makes of Russian, Ukrainian, English content. But rather, like this is all of the English content. Might not be all of the same content you have in other languages, but that's fine. From an SEO point of view, it does make sense to turn translations into high-quality content, so not just use Google Translate for that. The translation tools are getting better and better, but it's still, if you translate it by hand or if you take the Google Translate version and you clean that up and you make it more readable, that makes a big difference. And that's something that users notice, and that's also something that we notice from an algorithmic point of view. If we can tell that this is really high-quality content, then we will try to treat it better in the search results. OK. Thank you. All right. Any other questions before we jump into the submitted ones? Now, OK, everyone's a bit tired on Friday morning. That's fine. Maybe more questions will come up over time as we go through the other ones. OK, Google crawls and indexes content in two steps. First is the server-side rendering, and second is the client-side rendering. According to previous statements, it may take days or even weeks before the final version is available. Because of this, websites like US JavaScript can experience serious problems of indexing as time-critical, I think the question kind of goes into how can I tell how long it's going to take? So in general, the first part is correct. It is a case that we try to index content as quickly as possible, which we can if we have a static HTML version. And then as a next step, we try to render the page like a browser would, and we pick that content as well, and we use it for indexing. So those two things combined generally work together. But it's not the case that the static HTML version would be delayed from indexing until we have some noise somewhere. Let me just mute you here. It's not the case that we would delay anything artificially until the JavaScript version is ready. So from that point of view, from most sites, it's not critical that there is this difference. We don't have any explicit time that applies to the time that it takes to start to render a page that can differ depending on the type of page and where we found it, when we found it, what all is happening around that page. For example, if we think that this is something that is really critical to show in search quickly, then we'll try to render that almost immediately. So that's something that is kind of hard to take into account. There's no fixed number there. In general, I would use this as a rough guideline to determine whether or not you need to do something specific with client-side rendered content. In particular, if you have news content that needs to be indexed quickly, then I would make sure that Google can pick that up content up as quickly as possible without needing to render any of the pages. So for news sites, especially for the overview pages on news sites where you link to all of the new articles, I'd really make sure that those pages work well just purely from the static HTML that is served to search engines. So that's kind of how I would see it. And more think about how critical is it that my content is indexed immediately and not in terms of, well, how many minutes does it take? Because there is no fixed time for how long it can take. And then we have a giant long question about understanding kind of the deflagging in-search console when we flag something as duplicate. Google chose a different canonical than the user, or duplicate-submitted URL not selected as canonical issues? Hi. Hi. OK. Sorry about the huge question, the huge introduction. I guess we can ignore that. What it really comes down to is it's a JavaScript page. It is pre-rendered. All the content is in the static HTML. And yet, Googlebot is also trying to execute the page. And we're finding that in this e-commerce environment, a huge number of what appear to be unique product pages with unique descriptions and meaningful content are being flagged by Google as duplicate. We would assume those correspond to some kind of JavaScript rendering failure where Googlebot keeps seeing the same error page or something like that and therefore thinks they're duplicates. But we can find no evidence of that. So we're asking a question specifically about how to understand what it is that the web rendering service ends up with that might be resulting in content-looking duplicate to Googlebot. I need to take a look at the actual examples. So if you can send me some examples, that would be really useful. Absolutely, we can do that. I guess the questions there were, well, I guess the question of, is Google aware of an ongoing problem? That maybe that's not a way of anything ongoing. I need to understand. That's kind of why I think examples would be really useful. I have heard from some sites that were complaining about this more than others, but it's really hard to look at this without knowing specific examples. Understood that. Again, the questions I'm asking hopefully aren't related to examples. So the next question is, if a URL is flagged as duplicate, is there any way of seeing anything about the rendering that happened at the time of that analysis? Is there any way of seeing the resource loading errors that you would be able to see in one that when it was indexed, but you don't have that UI in Search Console, or at least I can't get to it? And or is there any place where we can see what the content actually looks like at the time that the indexer and or duplicate detection finder looks at it? Not at the moment. Understood. Yeah. I think that's something that would make a lot of sense to have. For most sites, it's not critical, but I could imagine in a case like yours that that would be really useful to have. OK. The next one was mobile friendly test. You've referenced it a couple of times in terms of understanding how the indexer would see content. However, we're finding that there's a lot of other errors. Errors labeled other error in the loading of resources. And the rate at which those errors occur seems to vary domain by domain. So first question, are the errors that we see in the mobile friendly test representative of the errors that the web rendering service would encounter during indexing? Or are there different resource allocations for the mobile friendly test? So I think you're referring specifically to embedded resources that are pulled in for the test, right? Yes. Like JavaScript files, CSS, responses, those kind of things. Yeah. I think one of the aspects that's a bit complicated at the moment in the sense that we have different priorities for the mobile friendly test compared to normal Google Cloud. So with the mobile friendly test, we try to pull in resources as quickly as possible from the live server. And during indexing, we cache a lot of these resources, and we just take the cached version of those resources. So what you might see in the mobile friendly test is we're trying to render this page as quickly as possible. We can get to a lot of these resources. We can pull them in. But for some of them, we essentially time out with regards to having the capacity to pull this live from the server. So that's, for a large part, the other errors that you see in the mobile friendly test. Also, I believe in the inspect URL tool, if you use the live test, then we're also trying to pull everything live. And sometimes that this isn't possible to do it live. And for indexing, we have a lot more, a little bit longer, let's see, time that we have available for that. So if we see that these resources are needed, then we will pull them, we'll cache them, and we'll have them available for when we try to do the rendering. So that's something where we don't need to do it live. So if it takes a little bit longer to get all of that, that's perfectly fine. We'll be patient. We'll try to wait until all of this comes together. There is still an aspect of time out there in that if all of these resources are such that we can't cache them, for example, we get a session ID in all of the JavaScript URLs, then that makes it really hard for us to keep a cached version and reuse it later. Then those are ones that we might, I don't know, for whatever reason not be able to fetch for indexing. So in short, I think it makes it complicated to diagnose issues like this, especially if you have a lot of embedded resources. The guidelines I generally get from the engineering team is we should just tell people to have fewer embedded resources, and then they tend not to run into this problem. That's not always that easy. But in general, what I would do is take the mobile-friendly test as a rough guide, where if it works in the mobile-friendly test, then you're definitely on the safe side. If you see some things timing out with this other error, then for the most part, we can still use that for indexing. Okay, interesting. Thank you. You've touched on it, I guess, tangentially. Should we be aware of any kind of hard or arbitrary timeout on rendering by the Web Rendering Service? And is there any clarity as to what content actually gets used if a page takes a long time to be rendered by Googlebot in the Rendering Service? Does it just give up and use the original page HTML content that was there originally, or does it take a snapshot of the DOM at some point in time? Do we have any clarity on how far into the rendering process you can end up? For the most part, if something breaks or times out, then we just take the snapshot as we have it then. Understood. Thank you. How should we provide examples? Let me just... I can just give you my email address in the chat here. Thanks so much. Almost. That's Google.com at the end. There's also the JavaScript Working Group that we set up a while ago where other people with JavaScript-based sites tend to post. I suspect in your case, if you're pre-rendering all of this content, then the JavaScript side shouldn't be causing any problems because then the content should be visible there directly. What we also sometimes see, especially with e-commerce sites or with sites that are using a very templated framework, is that we run into situations where we assume there is duplicate content before we actually test the URLs. So this can happen, for example, if we see URL patterns where we access a large number of URLs with different patterns there or different parameters, for example, and we see that all of these URLs are leading to the same content. So then our systems say, well, maybe this parameter or this part of the URL is not so relevant for the website after all and we tend to drop those URLs then. We say, well, this set of URLs is probably the same as this other set of URLs that we're already crawling. So in particular, if you have things where... Let's see. One example that I've seen quite a bit is if you have a lot of different e-commerce websites and they all provide the same set of products, so the whole path kind of after the product part in the URL is the same across a large number of domains, then our systems might say, well, these patterns are all the same. They're all leading to the same product, so therefore we might as well just index one of these domains rather than all of these domains. I don't know if that would apply in your case. So that's one of the reasons why examples are really useful, but it's one of those things where our systems try to optimize for what we find on the web and we assume that other people make mistakes as well on the web and we try to work around that really well. They're providing all of these duplicates, but we don't need to crawl all of these duplicates. We can focus on what we think are the actual URLs. All right. John? Yes. Hey, good question. You said that while doing this mobile-friendly test, so most people will try to kind of fetch a page from the live server. So how is it different from the URL inspection tool with the live test? This feature itself, like how they're rendering-wise or fetching the pages or the resources. I didn't quite get the test that you're using. Which program was that? The mobile-friendly test and the live test under the URL inspection tool. Oh, OK. Mobile-friendly test and live inspection tool. So the idea with a mobile-friendly test is really just to test for whether or not this version is mobile-friendly. So that's kind of the primary focus. And the inspect URL tool, the live testing tool, is meant more to see how would this page do in indexing. It checks for things, I think, like the no index, response code, kind of the usual things that would apply for whether or not we take this page and we put it in our index or not. So the mobile-friendly test is kind of mostly just focused on the mobile side. And the inspect URL tool is kind of like this big pocket knife with lots of features that you can use for different things. Thank you. OK. On our client's e-commerce site, some of the products are sold as configurable, meaning that multiple different variations of the same product, for example, different color, are shown and managed on a single page. We're thinking of splitting those pages so that they all have their own separate product page with a brand-new URL. The client reviews would then be moved from the old page to the new simple ones. Could the fact that these reviews having an older date than the new creation date be marked as Black Hat SEO? So I don't see any problem at all with the reviews provided you can continue to add new reviews to those new product pages. I think the aspect I would look at more is whether or not it really makes sense to split those products into separate pages. Because what you're kind of trading is one product page that is fairly strong for that product and all of the variations versus multiple pages that kind of have to work on their own and kind of be supported on their own. So instead of having one really strong page for, I don't know, running shoes, you have multiple pages that have to battle it out on their own for like blue running shoes, red running shoes, green running shoes. So if someone is searching for running shoes on all these other small pages, they're kind of like, not really as strong as that one product page that you have for that main product. So my general advice there is to say, if you think that these variations are just attributes of the main product in that people tend to search for the main product and then say, oh, which color do I want? It's like, I found the product that I want. I just need to pick which color I want. Then I would tend to put those on one shared page, whereas if people are explicitly looking for that variation and that variation is really unique and something kind of stands out on its own, that people don't come to your site and say, I just want running shoes, but rather, I want this specific kind of running shoes and this color, then that's something maybe worth pulling out as a separate product. So that's kind of the distinction I would make. I wouldn't worry so much about the reviews part. All right. Now, a bunch of questions. Does a new Search Console kind of remain the same schema markup functionality as any old one? So I don't know what the exact plans are for the new Search Console with regards to structured data features, but we do plan to continue to support all of those structured data features. So what might happen is that these features end up in the new Search Console in a slightly different way. What about speed for the mobile version? Is it crucial to have a speed in the green zone? And if yes, why are a lot of the top sites still so slow? So the good part is we have lots of ranking factors. So you don't always have to do everything perfect, but that also means you run across situations like this where you say Google says speed is important, but the top sites here are not so fast. Therefore, it must not be important. So for us, it is definitely important, but that doesn't mean it kind of overrides everything else. You could imagine the fastest page that you could think of is probably an empty page, right? But an empty page would be a really terrible search result if someone is searching for something really specific. It's really fast, but there is no content there. The user wouldn't be happy. So we have to balance all of these different factors, the content, the links, all of the signals that we have, and kind of figure out how to do the ranking based on this mix of different factors that we have. And the mix changes over time as well, and it can change fairly quickly too, where, for example, if something becomes really, really newsworthy at the moment, then we might choose to show slightly different sites, and we would show if something is more of a kind of a researchy, evergreen topic. What type of schema markup is preferable for Google? Should we use JSON or, I guess, microdata, microformats? Which format is preferable? We currently prefer JSON-LD markup. I think most of the new types of structured data are kind of come out for JSON-LD first. So that's what we prefer. Did Google do any heavy updates in February or March? I don't know. I mean, we do updates all the time. I don't know what you would consider heavy. It probably depends on your website. Your website was strongly affected by one of these updates. You probably think it's pretty heavy. If we look at the web overall, maybe this is just, like, normal changes as they always happen. What does thin content mean for affiliate websites? Thin content doesn't mean anything different for affiliate websites than for any other websites. So it's just what we've seen is, especially with affiliate websites, there is this tendency to just take content from a feed and republish it because it's really easy to do. You can get scripts that do this for you fairly quickly. It's easy to do. You don't have to do a lot of work. It creates a lot of URLs, and all of a sudden you have an affiliate website there. But, of course, for users and for us, it's not really that interesting because you're providing the same thing as everyone else already has. So I think when it comes to thin content, it's not so much that there are different guidelines for affiliate sites than there are for other sites. It's just that a lot of affiliate sites tend to be made in kind of a simple way of, like, I want to do a minimal effort to make a website, and the easiest way to do that is to take a feed from one big provider and just publish it onto your website. And that's how you end up with a lot of thin content. Does hit content in tabs? Is that a problem for indexing? In general, it's not a problem for indexing. It can be a difficulty for users. So if there's content there that you think users really need to see in order to convert, then that would be kind of problematic from your point of view. But with regards to indexing, we can pick up that content and we can show it. So that's less of a problem. Is anchor text still an important ranking factor? In 2019, lots of companies have made studies that they pointed out there's no correlation. So I don't know. And then there's a link to a Google patent. So I think, first of all, I wouldn't worry too much about Google patents. We've patented a lot of things that don't necessarily apply to what webmasters need to do. So I think it's interesting to see what all our engineers and the research team are working on. But that doesn't necessarily mean that you'll be affected by that immediately. So that's kind of one thing off the side. With regards to anchor text in general, we do use anchor text. It's something that we do pick up. It's a great way to give us context about a link. In particular, within your website, if you have a link that just says, click here for more information, then that's not very useful for us. Whereas if you have a link that says, I don't know, you can find more information on this product page. And you link with the name of that product to that page. And that tells us this page is maybe really about that product. So that's actually kind of useful to have. So I would certainly continue to look at your anchor text that you use, especially internally, within your website and try to make sure that you're providing anchor text in a way that is really useful, provides context to what is linked on the page. Can you tell us how the DMCA process works? I cannot tell you how that works because I don't know the details of that. And it's also a legal process. So I can't give you legal advice, which makes everything a little bit trickier there. I would recommend reading up on this online and checking in with your own legal counsel if you feel that there's something that you need to do with regards to the DMCA. How does a content platform like Medium get a 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 simple status for a site like Medium, which has a lot of content. We're also a content platform hosting supermarket catalogs and other PDF publications online generated by users. So I guess the question is, how do we get that status? I don't know. Hi. Basically, to provide some context, the problem we are trying to solve is that our platform allows adding outgoing links in the catalogs. If one specific URL is flagged for going to a bad site, our entire domain is in 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. How do we go about being in this standing? I don't know. So is it mostly with regards to the transparency report or is it with regards to maybe phishing or malware? Originally, it sounded like you just want the status in the transparency report, but with regards to links and the content that's provided that sounds more like it's towards phishing or spam or which part is the important part for you there? We are trying to solve for the risk for the main domain to be blacklisted from phishing and spam and under the hood, we are solving that problem. But the generic solution seems to be something like this because even if individual long tail small number of domains are blacklisted for a certain period of time, our main commercial domain is basically safe. Is that even a good assumption? I don't know how to best attack that. So I think from our point of view there's one thing that you could do. I don't know your website so it's hard for me to say if you're doing this already. One thing that you could do is make it easier to know which parts of your website belong together. For example, if you have different subdomains per user then it's easy for us to say this problem is isolated on this specific subdomain or on this specific sub directory. Then our algorithms can go and focus on that on a subdomain or a sub directory level. If all of the content is within the main domain like a slash and then a number which is the ID for that piece of content then it's really hard for our algorithms to say everything that matches this pattern is maybe phishing or spam that someone accidentally uploaded and that you didn't catch on time or whatever. So the easier you can make it for us to recognize which parts belong together which could be by user if you have users it could be I don't know by type of content depending on how you group the content then the easier it is for us to kind of group that the easier we can say well this kind of manual action applies just to this part of the website and not to the whole website. Okay. Currently it's directories basically group names so that is already the case. And so to answer like the generic question there is no process that you're aware of to basically either apply or get to the status of like content provider and does it actually link to having decreased risk for like whole domain blacklisting? I don't think the two sides are connected so I think that content provider status in the transparency report is something that's specific just to the transparency report and wouldn't apply to kind of the spam handling the abuse handling side. We do have some folks here who are working on creating something more specific for hosters or for CMS providers which I think kind of you fall into there that you're hosting this content for other people to try to give them more information on where we see spam and to better understand kind of the groups the grouping of content that we have with regards to individual websites. I think you had the link in the question right? The side map is there yes. So I will definitely pass that on to the team there to take a look at to see if there's anything specific that they can do there. I don't know I can't really promise anything because I don't know what the status of their work is there but I do know that they look into this to try to make it easier for the hosting providers to provide that platform for users to add content but also to be kind of safeguarded against random users taking down the whole site. Okay, cool. Just one more follow up on this. We were extra cautious because we already went through one process of this. We were blacklisted and based on your SLAs we submitted a report and we were whitelisted again in 48 hours but basically the policy the next step of the policy is that if this happens again which is worrying we wouldn't be whitelisted for another one month. So how long does this let's say probationary period last because one month of basically low availability for our customers is basically a very big commercial risk for our platform. Yeah, I don't know. So I'm not aware of anything specific where we have that kind of one month time. The only time that I've seen something like that talked about with the web spam team is specifically for websites that host spam and then they remove it and then they host it again when the reconsideration request goes through this game of cat and mouse for kind of the content platform sites like yours. Usually that's not a factor but I can take a look at that with the team. Yeah. All right. Thank you very much. Sure. All right. Oh man. So I have this weird echo that is happening now. With the German Hangout as well. I don't know if it'll I don't know if it'll go away. I think you guys don't hear that, right? I don't hear it. Likely your video is also turned on from the live stream in another tab. Maybe. Oh man. Okay. Let me see. So weird. Okay. Maybe okay. Switching it on mute or not. Cool. All right. So let's see. Next questions. Certain queries on Google return a localized search results page where the so-called local pack shows up. Sometimes there are three local businesses listed and sometimes the message is the website mentions whatever the query was. Does this mean that the keyword is listed anywhere on the website or on the exact linked website URL, which is typically a link to a localized landing page? So I don't know how the kind of the maps listings are generated there. So I can't really help you there. My guess would be that this is something that we pick up the content anywhere on that website. Because a lot of times the landing page isn't necessarily representative for all of the things the website does. But what I would do for something like this specifically around the local search results page is to go to the local Google My Business Help Forum and ask folks there because they have most experience about this kind of question. Is it necessary to add hreflang links to paginated pages beyond page one? So it's never necessary to add hreflang links. That's kind of the first thing there. It's not that you will be penalized for not having hreflang links on all pages across your website. The hreflang links help us to better understand which pages belong together. But it's not that we will kind of like penalize a website for not using them on individual pages. Hreflang links work on a per page basis. Links work well between the different homepage versions of your site but not between the product versions of your pages on the website. That's perfectly fine. Use them for the URLs that you think you need to have that connection for the language and country versions. You don't need to do them for everything. So that's kind of my first answer here. The other part is sometimes doing hreflang links properly is really complicated. So especially if you're mixing something like pagination and maybe filtering and hreflang, then that feels like something where you're just adding so much complexity that it's unlikely to end up with a useful result. So I would just drop the hreflang links from pages like that so that you don't have extra noise in Search Console with regards to the page that might not be set up perfectly. So 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 with regards to localization there, then don't worry about the hreflang part. Does Google determine a page's low quality by taking into account what the page looks like visually? I have a site where the elements get 3D rotated when a user taps on them. When I look at this page as Googlebot it sees these elements with the text backwards and it looks pretty weird. So is that a problem or not? From my point of view, that's no problem. So 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 like just one giant ad? That's kind of what we focus on. Also with regards to the mobile friendliness we try to visually map out the 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. It's okay if individual elements are unreadable as long as they work on a mobile device. The links are there and they're kind of at the right size that people kind of click on them but that's perfectly fine. If you're doing some fancy CSS transformation to kind of turn us into 3D text or do something really fancy with that, that's totally up to you. The important part of course 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 maybe had a headline like in the really old systems where you had a table-based layout and you wanted to split like a big headline on top, I've seen people put individual letters into individual table cells and kind of spread that out on top. And from our point of view that makes it pretty much impossible to recognize that this is actually one word that you're using as a headline there because you're using markup to split it up into so many kind of disconnected chunks. Visually, if you look at this page and you see it looks like a heading from a kind of parsing the page point of view that's really tricky there. So using CSS is generally fine to transform things but make sure that the HTML that's behind it is kind of understandable in that we can still pull out the words and understand which of these things belong together. I've heard that changing a title tag for a page will drop the page in ranking temporarily. Is that true? What if I have a number that has just changed on the page title? 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 how we should rank that page based on that title where the title is one of the things that we do look at. We do look at a lot of other things on the page as well. A lot of other signals that are involved with ranking. So just changing a title on its own shouldn't have a big effect overall but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing, 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 number three or number five and expect your page to show up. Maybe there are exceptions but that's not going to be something that would affect your page's 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. 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. 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 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. 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. Let's see, 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? No, I don't think that would be problematic. 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 pretty normal. There's a lot of variation of content out there and some content focuses more on this side of the topic that's completely normal. 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? We do recognize when there are parts of a page that are shared across other pages. 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 part of text is the same as you have across other parts of your website. What generally happens there is if someone searches for something that's in the shared piece of content or that if someone searches for something that's a combination of that content and something else on a page, then we'll try to pull that best matching page. That's the same as what would happen with these quotes pages in 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. For a hundred other people, lots of people have these quotes and we'll try to show that one in the search results. It's not that we would see this page as being in lower quality. It's just that you're competing with a lot of other sites that have the exact same quotes on it. If there's something unique that you're providing on these pages, then I would make sure that that is also very visible there while this page is about this quote but also has a lot of information about other 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. The more you can bring unique value into those kind of pages, the more likely we'll be able to show that in the search results. That's really something that you have to hide. We recognize these quotes. We understand that sometimes they're shared across lots of websites. That's completely normal. Suppose I started a blog. The most follow-up methodology is connecting a sitemap to the Webmaster site from day one. But what if I write 50 posts and then add a sitemap file? Is there any difference? Both of those methods work. So, a sitemap file helps us to better understand new and changed pages on a Web site. It's not a ranking factor, so you won't rank higher just because you have a sitemap file. It does help us to understand which of these pages are available on a Web site, but for the most part, especially for smaller sites, we can just crawl them normally as well. There's no big difference with regards to how a site is shown if we can crawl it normally or if we crawl it with a sitemap file. So, a sitemap file is definitely not critical. For larger sites, if you're changing pieces of content that are sometimes a little bit lower in the site, then obviously a sitemap file helps us to find those changes a lot faster. But if you're just starting a blog, you don't necessarily need to have a sitemap file. We resell hotels in Greece on a Web site. We've developed a good friendly section for hotels. However, we also duplicate content and titles of those hotels as we embed YouTube videos of those hotels. Is that harmful for us? Well, I think this kind of goes back to the other questions we had on duplicate content. They've got... Oops, sorry. They've got duplicate content. Where you really need to kind of focus on making sure that you have something unique on your Web site. If you're really just providing the same thing across a lot of different Web sites, then that makes it really hard for us to say, well, this is actually a Web site that we need to show in the search results. So, that's something where I would recommend taking a step back and thinking about what you could do to make sure that your site is really unique and compelling on its own rather than just the same thing as all of these other Web sites. If a story has been redirected because it was thin content and many years old, do the negative effects of the article kind of get forwarded on with the redirection? No, not necessarily. So, especially when it comes to content, we look at the content that we find on the the ultimate page that we land on. So, if you've removed content, if you've cleaned something up and well, I guess that happens automatically if you redirect that page and the old content is no longer there and we only have the new content, then that's perfectly fine. So, that wouldn't be anything that would kind of be carried on. Is it natural if Search Console reports mobile-friendly errors on a test-up version of a page when we've associated the mobile-friendly version of a page with the link-rel alternate tag? So, usually that means we don't have a clear understanding of which of those pages belong together. So, we for one reason or another, we're indexing these pages individually rather than as a pair where we know this test-up page belongs to this mobile page. So, that would kind of point at maybe a mismatch with the way that you have set up the alternate link or the rel-canonical link on those pages there. So, I'd kind of look into that as well. The other thing, of course, is I would also look into what it would take to move to a responsive design, because especially within a mobile-first index, all of these kind of issues where you have separate mobile URLs, they just make everything so much unnecessarily complicated, whereas if you can move to a responsive design or a design that just uses the same URLs for the test-up and mobile versions, that you save yourself so much trouble. So, instead of kind of following up this kind of issue, maybe take that time to say, okay, I should invest into a plan to move to a responsive design so that I don't have to focus on these issues anymore in the future. All right. Getting kind of close to the end of time, do any of you have any questions? Anything else that we should cover? John, can I jump to the question? Okay, you can continue. Okay, thank you. I'm interested about some niche. There are a lot of fraud in this niche and people don't like to complain about the fraud, about problems in its dating. And they have a client and he usually spends a lot of time to find real people like Ukrainian and Russian girls and provide this information for website and try to find some people in Canada or United States as well and to connect with each other. He has a lot of competitors in big websites and they use a lot of unreal fake photos, I mean like hot girls and it's difficult to compare with them and I know that people don't like to complain about this point because perhaps they don't want to show that they use this service. And what about Google? How Google influence this niche because a lot of big websites with million traffic just cheat people, I'm interested about this one. I have no idea. So I haven't really looked into those kind of websites and how they're handled on Google. I think the general question that you're hinting at is maybe a website that is doing something bad for users but the users are embarrassed for using it so they don't publicly complain about the website. So that I think is always a bit tricky for us to figure out because if there are no public mentions around this then it's really kind of tricky to find. And maybe there are signals that we can pick up that go into the positive direction where we see that actually users are really happy with this other website and we can pick up those kind of signals and use those to kind of promote the better websites in that niche. But I really don't know how that ends up working in practice. So that's an interesting question. Don't most of these sites in my extensive experience of these type of sites, aren't they behind a login? I mean I assume they are. I don't know. I have a lot of experience but in any kind of dating app or site most of this stuff is not public anyway. So this sounds more like a consumer issue than a Google issue unless this is a public facing site. That might be. I don't know. If you want to send me some examples I'm happy to kind of look. I mean if you could send me some examples as well that would be great. I don't know. I mean I'm happy to kind of pass those on to you and double check. But it's always tricky with areas that kind of have this weird aura associated with them where it's like I don't know if I should be debugging this site here but it's still something where users tend to go to these pages or at least some kind of users tend to go there and it makes sense to see should we be doing a better job providing relevant results for those kind of queries or is this something where users have to do their own I don't know. I mean if you have some examples where you can point to me where I can take a look at that and pass it on to your team that might be something that they'd have time to look into I don't know how niche this is in that they would say well it's like all of these sites are terrible and we don't know which one is the least terrible of these sites. It's really hard to tell. If they're producing duplicate photos and duplicate content it follows the same rules as any other niche anyway so presumably just churning out dozens and dozens of duplicate images and descriptions doesn't really help anyone. I have no idea. I seem to have a lot to say on this topic so I should probably probably stop. You know a lot of high quality content on these fraud websites but perhaps they use the same pictures photos and real people and I don't know how Google can handle this point but I'm interested because my client wants to be honest and provide real photos he spends time to find these people not to provide this content but he told me this niche is so competitive and 99% of this website just fraud. They are not any true because they just ask about money and they are not any connection and I wasn't interested at all. I really don't know I mean if you have some examples that would be useful to have and to pass on but I really don't know if the team would have time to take a look at this if this is something that they would see as a priority or if they see like 90% of these sites are all terrible it's not useful for us to focus so much time on finding those 10% that are less terrible I think that's sometimes the case with specific niches that have ended up being electric just so spabby but sometimes they do have time to figure some of these things out and sometimes they can tweak the existing algorithms a little bit better for those kind of sites so feel free to send me some examples I don't want to justice to be here because I see a lot of hot pictures and I don't think that I need to show any examples just type on Google like dating website you can find all of them I can find them but I don't know if they are bad not in the sense that good or bad for me but in the sense that it sounds like you have some background information that is not directly visible on the web and that's kind of the type of thing that would be useful to have where you can say well look this set of companies is all doing this crazy thing and this other set of companies is trying to do the right thing and you can tell the difference but that's the kind of thing that's useful for us to have finding sites that are ranking you know my client because he has some notes he works in this niche 10 years and he made a lot of notes I can ask to send you these notes I mean no pressure or anything just something that if we have more information on these type of things that's useful for the ranking team to look into and it gives them a little bit of incentive to say oh we can find signals that are similar to what these notes say and we can use that to kind of improve the rankings for this it might also be that they say like we don't have time to focus on this I can't promise either way okay hello John I have a short answer questions is it a good idea to add nofollow to Wikipedia link and Google help articles like other external links and how much time taken by data highlighter to take effect in a search okay so adding nofollow to Wikipedia links I don't think that makes much sense unless Wikipedia is paying you to place those links I would add a nofollow to links that you don't want to have associated with your website but otherwise if it's a normal link in the content then I would just link normally so unless Wikipedia is paying you for those links then I would just link normally I guess and for the data highlighter what happens there is kind of an algorithmic process that can take a bit of time in that it's based on the cache pages it learns from the index pages on your website and based on obviously the markup that you do with the data highlighter and then it takes that and applies it to new pages as we re-crawl and re-index them across your website so that's something that takes a period of time it applies to the content as we re-crawl and re-index it on your website so there's no fixed timeline sometimes that's fairly quick for a lot of pages and sometimes it can take a couple of months to be visible so there's no kind of instant on button for that it takes time like any other structure data that you would add to your pages manual okay thanks sure any other questions from any of you all one quick follow up to understand whether there's an easy well whether there's a cause that's clearly associated is Google aware and announcing a substantial change in the way duplicate content started to be treated around the end of November start of December last year or has there been a substantial change in the way the web rendering service goes about its business or the relationship between web rendering and indexing versus crawled indexing around that period because nothing changed in our system and we've seen as I said substantial issues starting then in particular not just for ourselves but we've also noticed a number of other observations of this class of problem around the same period I'm not aware of anything substantial that changed there so the only thing that I think kind of happened around fall or so is that we started adding this feature to search console to kind of highlight those problems and that's I think also where I started seeing more of these reports in that once we highlighted it to users that hey we're dropping these URLs and like there's a graph of them because we think they're all duplicate then of course everyone's like oh this is a new problem but for large part it's basically always been like that we just never talked about it in search console so that's I don't know exactly when we started rolling that feature out in search console but probably like second half of last year something around then okay thank you cool okay so with that I guess we can take a break here I wish you all a great weekend thank you all for joining thanks for submitting all of these questions I hope you found it useful and for those of you with homework for me feel free to send it my way so that I can take a look at that as well thanks a lot bye thanks bye