JOHN MUELLER: All right, welcome everyone to today's Google 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 I do is talk with webmasters and publishers here in the Hangout. We have a bunch of questions submitted again. So thank you all for submitting questions. If there any people here in these Hangouts who haven't been joining the Hangouts regularly and have a question on the mind, feel free to jump on in. Let's get started on the questions. So one thing I did with the questions is I went through and tried to categorize them roughly so that we can look at them in groups that kind of make sense. Most of them we'll try to get through, but if there's anything missing, feel free to add them again to the next Hangout. The topics I have compiled here are crawling and indexing, internationalization, structured data, duplicate content, and pretty much everything else, which we'll see how far we can go. All right, so starting with crawling and indexing. Whoops, let me find the question here so we can actually highlight it. "Is it true that if a page hasn't been crawled recently, it won't rank well or be given less authority. Also, is there any advantage to resubmitting your sitemap weekly or more often?" So it's not true that if a page isn't crawled regularly that it won't show up in rankings at all? In general, we try to do our crawling based on what we think this page might be changing or how often it will be changing. So if we think that something stays the same for a longer period of time, we might not crawl it for a couple months, and that's completely fine. We can still show it in search. So that's not something that see is a direct relationship. Oftentimes, there is a kind of relationship in that when we think something is important, we tend to crawl it more frequently, and that might be also more visible in search, but it's not really the case that you could say from the amount of crawling, this means how important it'll be shown in search. And similarly, it doesn't really make sense to resubmit things in a sitemap file if you're not making new changes. And in addition, most CMS systems automatically submit a sitemap file whenever you make any changes. So you definitely don't need to do that manually. "Are there any crawling indexing limitations when moving from HTTP1 to HTTP2?" So at the moment, Googlebot doesn't support HTTP2-only crawling. So if your website is only accessible via HTTP2, that's the next version of HTTP, then we wouldn't be able to crawl that properly. We're working on that. I suspect it'll be really by maybe the end of this year, early next year, something around that. One of the big advantages of HTTP2 is that you can bundle requests. So if you're looking at a page, and it has a bunch of embedded images-- CSS, JavaScript files-- those things. Theoretically, you can do one request for all of those files and get everything together. So that would make it a little bit easier to crawl pages when we're rendering them, for example. Let's see. So many questions back and forth. "We changed our old domain name to a new domain name, and did some 301s to a completely different domain. Somehow in that redirect chain we got a 302 in that redirection due to a CMS issue. So like an old URL, 302, and then a 301, and then to the final new URL. Are we passing some page value?" Yes, we'd probably see that as a normal site move, redirect, and just processes it like that. So it doesn't really matter if it's a 302 in there, it's not the case that 302s do anything magical to block the flow of page rank. So from that point of view, that's not something you need to worry about. "When a domain change happens with proper 301 and Webmaster Tools, a change of address set up properly, how long does it usually take for the new pages to appear instead of the old ones?" Hard to say. It can be up to maybe hours or a day or so after you've set all of that up. Then we can process that and handle that as a site move. That can happen fairly quickly. But what will probably happen is that for some of URLs on your site, it will take a little bit longer, and for some it will go a lot faster, and that's just from a natural point of view how we crawl a website in that some pages are crawled more frequently. Others are crawled less frequently. And for those that are crawled less frequently, it'll take a bit of time for everything to be forwarded there. So that's something where you wouldn't necessarily, if you do a site query for the old URL and see that these URLs disappear within a day, that probably takes maybe half a year, maybe even a little bit longer. "How does Google measure web speed? How much is first [INAUDIBLE] important in web speed by using Google Speed Tool. I'm getting 90% from my web and 84% from my mobile. But honestly, poor performers are ranked well even though I'm following all of Google's rules." So on the one hand, page feed is something we do take into account, but it's not something that would be a critical ranking factor. If we have equivalent pages, and we see one is significantly slower, then that's something we might take into account. With regards to crawling, we take that time into account as well, and that's probably where you'll see the bigger effect in that if your page is really slow to load-- it's really slow to fetch from a server, then we probably will crawl less from your website and won't be able to pick up all of your new content as quickly. So for that, we look at things like the overall response time, how long does it take for this request to go through, the connection time to the server. We see if there are any server errors that we run across. And all of this comes together and helps us to figure out how many URLs a day we can crawl from the server. And the faster your server is, the better it can respond to these requests, obviously, the more we can crawl from the server. And that particularly plays a role now that we're doing more and more rendering on this page. And so for indexing, we don't just look at the HTML. We try to actually look at what the page looks like in a browser. And that means we have to fetch things like CSS files, JavaScript files, images-- all of that as well. So on the one hand, if your server is really slow already, then all those files will slow it down even more. On the other hand, if your pages are built in a way that require tons of individual URLs that also have to be loaded, then that also slows down how fast we're able to index your content essentially because we have to do requests for all this embedded content, and that takes time as well. "I have to move a DNS zone file, and after 48 hours, we're still getting temporarily unavailable from Fetch as Google-- tried confirming the DNS with DNS Tools. What can I do?" So this probably just means that the old DNS information is still cached somewhere, and that's something that can take a bit of time to actually settle down. I assume since you submitted this question, things have settled down already, or at least, I hope so because at most, I'd see this maybe a day, maybe two, in this case here where you'd see this time. You can prepare for that a little bit by setting your TTL settings in the DNS to say that these DNS settings are likely to change very quickly, for example, maybe setting them to an hour instead of-- I don't know what the default is. And change that back obviously when you've actually made them. "Can you elaborate a bit on the If-Modified-Sense? How does it work? Do we really have to do anything? We're using WordPress?" If-Modified-Since is essentially a way to optimize your crawling in that Google or browsers in general will do a request to a server and say, hey, I really like the contents of this URL if it has changed since this specific date. And sometimes it can help your server by not having to transfer all of that content again. If the server can just say, hey, this file hasn't changed. You don't need to do anything, and then we can just re-use our cached version. So that kind of helps to improve the caching and to make sure that we're not keeping any stale content in our index. That's kind of the technical background there. If you're using a common CMS like WordPress, then that will be handled for you automatically. You don't really need to do anything special there. I guess the good part about these kind of standards that work across the web, that work for browsers as well, is that people implement them fairly quickly, and if you're building on top of an existing platform, then it's a lot easier for you to just focus on your content instead of having to focus on all of these technical details as well. "Search Console is showing our index status with 2000 index pages in Google. However, when I do a site query, I see 350. What's up?" I guess these are different numbers that you're probably looking at there, and they essentially come from the way the numbers are generated. So site query is not meant as a way of comprehensively looking at all the content on the site. It's really not meant for that. So I wouldn't use it as a metric from a webmasters point of view. The index status information is a lot more comprehensive and complete in that it includes everything that we've indexed from your site. However, it also includes things like duplicate content that were probably not showing. So if you have multiple URLs that lead to the same content, we might include those as separate counts in the index status count there. So what I'd recommend doing is instead of focusing on these two very broad numbers, it is looking at your sitemaps index count actually. So if you take all of the URLs that you really care about, you put them in the sitemap file, or even just a text file with all of the URLs listed, you could submit that in Search Console as well, and on a daily basis, we'll give you information on how many of those URLs that you submitted that you really care about are actually indexed. So instead of looking at vague number that kind of fluctuates up and down a bit, you're actually looking at of the URLs that you really care about, how many of those are actually indexed. All right, moving on to internationalization. "My co.uk site returns a .com version on a branded search even though it has a 301 back to the co.uk. How do I fix this, and is this hurting my rankings as the .com is showing a higher PageRank than the co.uk?" So I guess first of all, I wouldn't worry about the PageRank. That's something that we haven't updated in, I think, more than a year now. So looking at the PageRank score in the toolbar is not really going to be that useful. On the other hand, you can do things like use a hreflang markup to let us know about your preference and which URL to show in which location. But this is essentially a hint for us. It's not a clear directive because sometimes people get the hreflang markup wrong, and that's something we have to live with and still show the proper search results. So that's something that you could do there. Sometimes we also see that a different version of the site is actually much more relevant even though the hreflang markup is there. So we'll still show it. And, finally, with regards to rankings, with the hreflang markup, we're essentially just swapping out the URLs. So we're not changing anything in the ranking. So if you're seeing the wrong version of the URL there, then essentially we're just showing the wrong version of the URL. It's not that it would be thinking differently if we were showing the other version. Let's see. "I'd like your opinion on a possible bug that I sent your way. We have hreflang and a 301 redirect in place. Why is it indexed? Often, but not always, the URL is rentalcars.com/gb instead of rentalcars.com/en. " In general, if you're seeing things like this, and these are within normal pages on your site, and you have hreflang markup in place, then probably we're not able to pick up hreflang markup properly. And that can come from various reasons. Some of the most common ones that we see is that you're not using the hreflang markup between the canonical URLs. So in a case like this, and the question here-- you have GB in uppercase and EN in lowercase, for example. If you allow both versions of uppercase and lowercase language codes there, then you have to make sure that we're actually picking the one that you're using for hreflang markup. So you can use a rel canonical for that to really let us know this is the version of the URL that you need to use as a canonical. And we'll use the hreflang markup between those canonicals. So that's one thing to watch out for. The other thing that we often see is that the hreflang is outside of the head section of the page in that maybe there is some JavaScript that's generating a piece of text that's kind of closing the head implicitly. Maybe there's something within the HTML itself. Maybe the head is somehow broken HTML that caused the browser to close the head section at that point. So that's something where maybe this hreflang markup just isn't being picked up properly because it's not really in the right place. And Search Console gives you a lot of information about these kind of errors. So I'd really double check there to make sure that it's in the right place-- that's its being picked up properly-- that you're seeing those backlinks as well-- all of those things. All right, moving on to structured data. One thing to mention before we move on to more of the questions here about structured data is that people are seeing structured data as something that probably isn't based on one of the comments I made in one of the previous Hangouts. We do use it to understand the page a little bit better. But it's not going to be a ranking factor in the sense that your cycles suddenly start ranking positions higher. So this is more of a subtle thing that we're trying to figure out what your page is really about and show it for the right queries. It's not that your site is going to jump in rankings automatically just by implementing structured data. In general, we try to go by the guideline of looking at which pages are actually relevant for the user instead of looking at which pages are implementing any kind of specific technical markup, for example. So that goes with regards to HTML. If a page is valid HTML, then obviously that's a good thing. But it's not that a user is really going to notice that in most cases if it's valid HTML or not. So we're not going to use that as a ranking factor. So moving on to this question here. "I've been told our schema markup hasn't been done correctly even though Google's testing tool says it's OK. Can this affect my rankings?" In general, if the testing tool says it's OK, then that's a good thing. So that's not something that would negatively affect your rankings in any case if it were marked up correctly or not. So at least from the rankings point of view, that's not something I'd worry about. With regards to markup being done correctly, that's sometimes a bit tricky because technically you might be implementing it properly, but from a policy point of view, maybe you're marking the wrong things up. So, for example, one thing we sometimes see is that people use recipe markup, and they use is on a page that actually isn't a recipe. So maybe they have, I don't know, a website that they're reviewing, or a picture of their house, or something like that, and they add the recipe markup with the hope of getting that image shown in search. And technically that might be implemented properly. The testing tool might say that it's implemented properly because from a technical point of view, it is, but from a policy point of view, that's not a recipe. So that's not something that we'd actually show as a recipe in search. Here's another one that goes in the same thing. "Rich snippets help in Google rankings because it's easy for Google to understand the web structures." So again, that's kind of incorrect there in that we do use rich snippet in the structured markup to better understand the page, but your site isn't going to rank higher just because it has structured markup. And specifically, around rich snippets, there are snippets that we highlight in the search results. It doesn't mean that we'll rank it higher if you have rich snippets shown. The question goes on, "So even breadcrumb, rating, webmain all put a bit of a ranking factor or only go for whatever is needed and easy to implement in the web design." So, again, these are things that are ranking factors. They help us to better understand the page, and sometimes we'll show some of that in the snippet in the search results, but it's not that your site is going to rank better by implementing all these technical things. If it were just a matter of implementing things technically correct, I'm sure the search results would look very different, and users would be very unhappy by seeing all of these pages that are technically properly but don't really have great content. So instead of focusing just on these technical aspects, I'd really focus on making sure that your site actually provides something useful and valuable for the user. "If Google sees a link between two sites," so this is, I guess, more in the direction of duplicate content. "If Google sees a link between two sites, for example, two affiliates who have the same manufacturer, but have separate entities and their own content, will you rank both of these sites? Or do you choose one over the other?" Maybe, maybe not. So in general, if this is separate content, unique content that's worth showing separately in search, then we will show separately in search. So regardless of whether or not there's an affiliate relationship there or not, if we can see that this is unique content and valuable content to show to you, we'll try to show it separately in the search results. On the other hand, if this is affiliate content where the description is just copied and everything is the same on these pages, then we'll probably recognize that it's essentially the same thing and fold them together and just show one of these things are in the search results. "Any harm in having a canonical tag that's pointing at the home page?" I guess there is a subtle thing here with this question that might not be directly noticeable in that if you're looking at your home page and you have a canonical tag at your home page, then that's obviously the right thing to do. If you're looking at the whole website and all of the pages on the website have the canonical tag set to the home page, then essentially you're saying don't index all of these pages. Only focus on the home page. So you're losing out on having all of the content that you have elsewhere on the site indexed by us focusing only on the homepage. So that would be-- we'd see that more as a technical issues on the website. And that might be the kind of situation where our systems might say, well, the rel canonical tag is implemented incorrectly here, therefore, we'll ignore it. So if you're talking about the home page, then obviously a canonical tag to the home page is perfectly OK. If you're talking about the whole website, then the canonical tag is always to the home page, then that would be a technical problem that I'd recommend fixing. Let me just find this question. "Can I keep a self-referencing canonical tag while trying to de-index a page using noindex and follow at the same time? Will this send mixed signals to Google and cause any issues?" So if you have self-referencing, canonical tag, you're basically saying this is the canonical version of that page. And if you have a noindex on that, you're basically saying, don't index this page. So that's, I think, that's perfectly fine. I think that would work without the canonical tag as well because we'd just find that page, see the noindex, and process that. It would be trickier if you have one page that has a canonical tag pointing at a different page, and that page has a noindex on it because then we'd see one page without a noindex that has a canonical pointing somewhere else, which tells us don't index this page, but index that one instead, and the other one has a noindex saying, well, don't index this page. So we kind of stuck in the situation of being a little bit conflicted there, and that might be something where you might see different outcomes. "An e-commerce site has pages with similar content except for the color and has URLs like product one in red, product one in blue, for example, 500 products, 5 to 40 different variations. Can this cause a penalty?" No, well, I guess it could cause a penalty if the content is really spammy and problematic. But in general, if this is null content for an e-commerce website, then no this kind of duplication would not cause a penalty. We don't have a duplicate content penalty in that sense. What will probably happen is we'll fold some of these pages together for indexing and show then the search results as one URL instead of all these different variations. But essentially, that's more of a technical issue and not something that would negatively affect your website. "Should all of these pages except one per product be noindex?" I wouldn't use noindex in a case like this because with the noindex, you're essentially saying this page should be dropped from search. That means if anyone is looking, for example, to the blue version of the page, and the red version is the one that doesn't have a noindex, then we would essentially dropping that link, and it would disappear. So that's something where what might make sense is to use a rel canonical and say this is the main page for this product, and I have these different variations. But the canonical is set to the main page. So in a case like that, if anyone were to link to any one of these specific variations, we'd still be able to forward that to the main page. And that also helps us with indexing in that we understand, well, these are different variations we've crawled and indexed them. But, actually, we should fold all of that information to that main product page. So that's one thing that you might be able to do there. I definitely wouldn't just noindex these variations.

MALE SPEAKER 1: Hey, John, can I have a follow up on that?

JOHN MUELLER: Sure.

MALE SPEAKER 1: So let's say that person uses rel canonical to fold their thing into a main product page. When you merge all of these things together, what happens when somebody searches for like red version of the product, but the main page doesn't specify the red version. It's only the red separate version that specifies red keyword something like that? Does that affect the ranking or relevance in any way?

JOHN MUELLER: Yes, it can. Yeah. So if the main page doesn't even mention these variations, then we wouldn't be able to take that into account. But in general, you'd have a main page, and it would have a link saying these variations are available like red, green, blue, large, small, or whatever you have. And from that, we know that, well, this word is on that page, we understand that it belongs together. But if there's other content, for example, on a page that isn't canonical-- that has a canonical pointing to a different page, we wouldn't take that into account.

MALE SPEAKER 1: Right. Got it. Thanks.

JOHN MUELLER: All right, so let me run through the other questions. They kind are a mix of different things. One quick thing I noticed is that there were some questions about the local rankings and perhaps not really something I can help with because that's essentially done by the local business people, not something that we do from a web search point of view. Can't try them off hand, but maybe we'll run across some. "What would you say if I put my links to our other branches in our footer? Google will not take kindly to this and see it as spammy?" In general, that's fine, especially if you have a limited number of different branches that you're looking at. If you have handful of sites, and you're putting them together, then sometimes that make sense if you link those individual versions from a footer, for example. On the other hand, if you have hundreds of sites, then probably it wouldn't make sense to link all of those in the footer. On the one hand, that's probably something you'd want to consider folding together anyway just because it starts looking a lot like doorway signs. On the other hand, that's a lot of stuff to put into a footer, and I don't know if that would really be useful to any user. "Can you offer any advice for optimum website architecture? Also, what can you do over internal linking?" In general, for website architecture, I'd make sure that it works for the user that you have a clear context of the individual pages-- that you have a clear structure of the pages-- that they are linked in a way that makes sense. And if we can see those lines-- if we can see all of our content, then that's something we can pick up on and use. One variation that we sometimes see that probably isn't that optimal is if all of your pages are linked from all of your other pages. So especially if you have more than just a handful of pages, and they're all interlinked, then it makes it really hard for us to understand the context of any particular page there. But in general, if users can use the setup that you have there for website architecture, then we'll generally be able to use that as well and be able to handle that fairly reasonably in search. Oh, one type of architecture maybe worth mentioning that we do sometimes see, especially on larger sites on more reference-type sites, which could be things like government sites or sites where you have to do lookups from a large catalog of products is if the main navigation within the site is essentially a search form, then that's something we'll have a lot of trouble crawling through because if we just see that search form, we don't have leads to the individual pages that you're actually showing there, then that makes it really hard for us to even find all of that content. So providing some kind of structured way to navigate through your content definitely makes sense. "Do you take categories into account when providing the search results? So, for example, you don't show only metasearch engines on page one-- have a diversity of different suppliers or portals." We take a lot of things into account when it comes to ranking. I'm not sure if we directly take something like categories into account. But we do try to provide a diverse set of search results so that when someone is searching for something, they don't just see the same thing over and over again so that they actually have a variation there. Otherwise, if it's the same thing or the same type of site over and over again, we might show it once and not show 10 different results. So that's kind of the reasoning behind showing multiple results on a page in that it should be something different so that the user can pick whichever one makes sens for them. "Should we still use PageRank as a benchmark? Is it how Google values a page? Or are there other metrics that are better to use? Is the PageRank algorithm still current even though it hasn't been updated?" So we have updated Toolbar PageRank in, I don't know, maybe a year, maybe two years now. I think the last update we did was even accidental and wasn't really meant to be updated, so I definitely wouldn't use Toolbar PageRank as a metric for a sidebar. I would focus on other metrics, and you know your sites best. You know best what you want people to do-- what you think is a good thing to do for your sites. That could be something like tracking the conversion-- that those kind of things. But PageRank is definitely not one of those metrics that I'd focus on. "I found some old 404s that are still showing PageRank." Oh, my god, everyone is focused on PageRank this time. It's crazy. "So I found some old 404s that are still showing PageRank and should've been 301s . Is it never too late to change them back, and if we do, will we still get the link juice?" So sure, if these are pages that are 404, and we're still seeing traffic to them, then using a 301 redirect is a good way to guide the user in the right direction. Obviously, having a useful 404 page is also a really good thing to do because that also helps users to find that content again. If you are just focused on PageRank, then again, since we haven't updated for such a long time, you're probably looking at a number that doesn't really make sense for these URLs anymore. And if this has been changed a really long time ago, then chances are those URLs are just 404s. They are not actually indexed like that anymore. We don't really do anything with them anymore. So redirecting them just for the sake of getting some search engine value out of it probably isn't the best use of your time. "Is there any link between one's Google+ page showing in local pack and the ranking of another page from your site in a similar search return appearing on page 1?" This kind of goes into the Google+ local search results. So essentially these are done separately from the normal web search, and just because one result is showing in one part of the search results doesn't mean it's automatically shown somewhere else. So I think that's essentially more coincidental that these different URLs from the same business are showing up on the same search results page. "User engagement as a ranking factor is a rising topic. How can it be a reliable ranking factor if there are so many different types of search purposes?" That's a good question. And I don't think we have said that we use that as a ranking factor. So from that point of view, that's something to ask those who are kind of rooting for this as a ranking factor. We do take into account how people react to the search results when be refine our algorithm. So that's on a very broad scale where we say over all of the billions of searches that we see implementing this algorithm or showing it in search has resulted in this kind of change of user behavior. But doing that on a per URL basis is really hard because, like you mentioned, there are things like different intents, people searching for the same thing, but trying to find something completely different-- people who just want very brief news blurb on a specific topic or people who want to find something that they can sit down and read for a couple of hours. So they have very different intents. And combining all that makes for a really, really noisy signal. And I don't think that would really make sense there. "What can we do to get our Google+ pages to appear in the local pack?" I don't actually know about the local search results. So I can't really give you that much information. As far as I know, this is based on the Google My Business page that you have, and on that page, you can also specify URLs. So probably specifying your URL there will help to get that shown there. But I'd probably ask in the Google My Business forums to get advice from people who do actually know what's happening. "Is unique design a real factor in ranking-- using already built templates can hurt search results?" No, that's not something I'd focus on there with regards to ranking. So just because it's a template that other people are using as well doesn't necessarily make the site lower quality or less relevant to users. So that's not something I'd say is a problem there. I think you might see some effects from users if you're using something that's so generic that it doesn't actually look like it's a legitimate website. For example, if you're trying to sell, I don't know, watches, and you use a generic template that 500 other sites are also using, then it might be that users come across that site, and say, whoa, this looks very vague. I don't know if I would this website with my credit card information, for example. And that might be something that you'd want to take a look at from that point of view. But just because it's using a template that other people use as well shouldn't really affect its ranking if it's a general website. So, for example, lots of blogs use the same templates that are available on Blogger or WordPress, and just because they use a default template doesn't necessarily mean that they are lower quality. "Is there any SEO relevance to using the HTML Value tag to increase the number of key words?" This kind of implies that there is such a thing as optimal keyword density, and there isn't really a thing like that. So it's not that you have to hide your keywords on a page or push them using whatever methods like this. That's definitely not the case. So I think we do pull out things like the value or at least the text from dropdowns and take that into account. The value item that you have there is more of an internal thing that's used to maybe generate a URL that's navigated to depending on what you select there. But the text is essentially the part that we look at there. We've also seen people try to use HTML comments to hide keywords on the page. And, again, that's something that's not shown to the user. That's something that we don't even take into account for indexing. And your time is probably much better spent on actually creating something really valuable for the user than trying to sneak your way into the search results like that.

"When entering site:www.domain.com in Google Search Box, is there a random list of that domain or the best pages on top?" We do show them generally in some kind of an order where we try to bring the most important or the top pages on top. But it's not an order that's prescribed or we'd say, well, it has to follow this for a specific pattern. And if your home page isn't the first one on there, that's not something where I'd say it's a problem or anything. So we generally try to show them in an order that we think makes sense for someone who's looking for this website in general, and that's often something like a home page or a higher-level category page, but that doesn't mean that it has to be like that where it's reflective of any internal value that's been shown through the search results like that.

ROBB YOUNG: John, on the search operators, has the Link search operator been retired?

JOHN MUELLER: No, I don't think so. But I have heard reports that something weird is happening there.

ROBB YOUNG: That's what I read that you retired it. And I was like, really? Have you?

JOHN MUELLER: I don't think we retired it. I don't know. I noticed for most sites, it works, but for some sites, it doesn't.

ROBB YOUNG: Yeah, it doesn't.

JOHN MUELLER: I suspect it's more of a technical issue on a site.

ROBB YOUNG: All right, OK.

JOHN MUELLER: "Is syndication content a problem causing punishment?" Whoa, that sounds serious. Not necessarily. So we don't have a duplicate content penalty in that sense in that if you're syndicating content across a small number of sites that this would be any kind of a problem. If your whole website is based only on syndicated content, some content that you're pulling together from other sources, then it probably doesn't make too much sense for us to spend too much time crawling and indexing your content because actually you're just reflecting content that's visible somewhere else already. So if a whole website is only based on syndicated content, that would be something I tend to avoid. But otherwise, this is essentially just duplicate content, and we try to handle that on a technical level. And we don't necessarily penalize a site for using syndicated content like that. "My site has been ranked at the bottom of page 2 for some time now, and nothing that I can do makes it go up. How can I determine what the issue is?" According to Search Console , it has 200,000 links to it from 2,500 domains. So my first thought when seeing a question like this is you're focusing on links, and you're compiling a list of the links that you have pointing at your site and how many domains are that. So it would kind of worry me a bit that you're focusing so much on links and maybe there are things with regards to those links that are causing more problems that are actually helping your site. So, specifically, if you've been building links in a way that would be seen as against our webmaster guidelines, that might be something that you'd want to clean up and resolve. If someone else has been building links for your website like that, that's something you'd probably want to clean up and resolve, and in general, just focusing on the number of links shown in Search Console, probably isn't the best metric for how well a site should be doing in search. So instead of just focusing on links, I'd focus more on the actual content and the value that you're providing to the visitors to your website. "Disavow links and [INAUDIBLE] can hurt already ranked websites. I know which is good to my website, but how can Google judge my links? Is there any criteria that we can follow to disavow only the bad links?" So, in general, I'd use the Disavow Links Tool if you really have bad or problematic links to your website that either you or maybe a previous SEO or previous owner of that site had built up, then using a Disavow Links Tool is a good way to let us know that you don't want to have these taken into account. And it could theoretically cause problems for an existing website if you take all of the links to your website and just disavow them like that because then essentially we'll look at that and say, well, you don't want to be associated with any of the links to your website. So maybe that means we have to kind of rethink how we were ranking your website based on these existing links. So it's really something that I would only recommend the more advanced users to do and really only to use if you know that there's really a problem with regards to your links there. "I've been trying to remove a site link URL by demoting it in Search Console with no success. Why does Google not take my input into account?" So the motion in Search Console is like the name says. It's a demotion. It's not that we're suppressing it completely. But rather that we'll give it less weight while we calculate the site links of the URLs that should be shown as a site link. And that's something that can have a subtle effect sometimes. Maybe it'll go from being the first site link to the last site link that's shown. Or maybe it will go from being a site link to not being shown at all. So that's something where if really don't want this URL to be taken into account for search, then probably using a noindex on it is a better approach. Obviously, that's a really big hammer because that means the URL itself won't be shown in search at all. But that's kind of the range that we have available there. The thing also to keep in mind is that a site link demotion can take a bit of time to be processed, and sometimes that can take several weeks to actually run through the systems on our side. So if you've done that, just recently, then maybe you need to give it a little bit more time to be processed. And finally, if it's something that you really can't get out of the site link, and you're thinking this is really, really a bad choice for the site link, and the page itself is actually useful otherwise in search, then you're welcome to send that our way, and we can discuss that with the site links to see why are we picking the site link in a way that makes absolutely no sense, and what can we do to improve our systems based on this example that you've sent us. "Could we benefit if our product pages have more virtual descriptions than other pages on the web with the same products? Can a lot of the product descriptions that are well-written be considered better?" Longer isn't necessarily better. So it's really a case of do you have something that's useful for the user? Is that relevant for the people who are searching? Then maybe we'll try to show that. And just artificially rewriting content often kind of goes into the area of spinning the content where you're just kind of making the content look unique, but actually you're not really writing something unique up. Then that often leads to just lower quality content on these pages. So artificially re-writing things like swapping in synonyms and trying to make it look unique is probably more counterproductive than it actually helps your website. So instead, I'd really focus on the unique value that you could provide through your website which could be something that's more than just like a slightly re-written description but rather your expert opinion on this product, for example, or the experience that you've built up over time on this specific product that you can show to users that does provide more value to the people on the web.

MALE SPEAKER 1: Hey, John, regarding descriptions, is it a good idea to include descriptions like small descriptions on categories to increase the relevance of a page since, for example, for categories of products, usually the category page just starts just as a cycle and then starts listing products? Would including maybe a paragraph or something like that-- a short description. Would it improve the relevance of the page for Google?

JOHN MUELLER: Sure. Sure. That can makes sense. Sure.

MALE SPEAKER 1: I know that Matt Cutts mentioned in one of his previous speeches that-- it's probably not the case anymore. For example, a USB drive can be referred in many terms based on the user's location and things like that. So maybe you have a USB drives category page, and maybe the description could say that you look at our collection of thumb drives and maybe they fit your use. I don't know. If Google is probably better now with using synonyms and with all the new updates, it's probably better identifying user intent and things like that. But I don't know.

JOHN MUELLER: Yeah. So with synonyms specifically, that's something we're pretty good at. Obviously, there are some cases where we don't pick that up properly. But for the most part, where we do see problems is when the text on the page doesn't have anything to do with that what you're trying to target at all. So I see that a lot with small businesses that maybe it's a baker, and they have some really nice pictures of bakery items on their home page. But actually, they don't actually mention that they are a baker or which city they are a baker in on those pages. So stating the obvious definitely makes sense on these pages, but I wouldn't go so far as to compile a list of synonyms and put them in there because it goes towards that direction of the typical SEO joke like how many SEOs does it take to change a light bulb? You know? Those things. So I wouldn't just artificially include all of thee synonyms on a page just to make sure that you've included all of the variations and all of the different texts there. But putting a little bit more text on a category page, I see no problem at all with that.

MALE SPEAKER 1: OK, and since is we're on synonyms, I wonder how does Google understand characters-- words with characters in languages that have accents. So for example, in Romanian, there are a few letters that don't exist in the English alphabet, and they have accents and, of course, in other languages as well. But users usually don't use these letters when searching in Google. So far, Google seems to be good at identifying that it's about the same thing. But how exactly does it identify? Does it take it as a synonym? Or what exactly is the process?

JOHN MUELLER: We usually pick that up as a synonym. So that's something where if we see a lot of people searching for these different variations, and we see, actually, they are trying to search for the same thing, then we'll try to take that into account. For some languages, it works better than others. I imagine most of the European languages are easier to pick up. But for others, it's a bit trickier. And sometimes it gets really complicated when people search in a transliterated way, for example, in Hindi, that's something that I've seen where the content is actually in Hindi and uses the appropriate scripts for that, but people search using the Latin characters instead. So they type what it would sound like if someone were to say with English characters. And that makes it really for us to connect what they're searching for with what's actually on the web because it's not just that the words are kind of similar. Essentially, they're searching for something completely different, but expecting the same thing to show up.

MALE SPEAKER 1: Yeah, excellent. Thanks.

JOHN MUELLER: All right, we have a few minutes left, maybe I'll just open it up toward question from you all. What's on your mind?

MALE SPEAKER 2: Hi, John.

JOHN MUELLER: Hi.

MALE SPEAKER 2: I just had a quick question regarding the comment made on the schema markups.

JOHN MUELLER: OK.

MALE SPEAKER 2: JSON-LD being the most preferred format or being the growth in the acceptance of JSON-LD format, it's becoming more easy for people to just mark up content which is not even present on the web page. And I'm seeing specifically on events, for example, I've seen websites where we have multiple events on a single location. They will repeat the event location, and they just put it in these script tags in JSON-LD. The schema is being accepted by-- it's valid by these structured data tool as well, and it also accepts-- it's actually valid via the policy as well. So how does Google actually take this into, and what's your thought about people using JSON-LD schemas to actually mark up content which is not even on the web page? And by the way, I also sent you an example as well today.

JOHN MUELLER: OK, so from a policy point of view, we do want to have the content visible on the pages when it's marked up. So that's obviously easier with the existing schema markup, the macro formats, those kind of things on a page and harder to double check with JSON-LD because JSON-LD markup is essentially JavaScript that's completely separate from the HTML on the page. So that's obviously a bit trickier there, and I think that's part of the reason why we don't accept JSON-LD markup [INAUDIBLE].

MALE SPEAKER 2: OK, and by the way, it will be great if you can look into the example that I've sent to you earlier.

JOHN MUELLER: Sure. I'll look into that.

MALE SPEAKER 2: All right, thank you so much.

MALE SPEAKER 1: John, I have one more question. This is actually a client-specific one. There seems to be a WordPress plug-in that helps users log certain data into Google Analytics by adding a few parameters to the URL. This is one example of such URL. The problem that I see is that for robots, including Google. So Fetch as Google shows this. It shows us being redirected to the non-parameter URL. But for users, it's accessible. So it shows a 200 result code. And is this a problem? I assume that a rel canonical tag would be better fitted here. So I'm not sure why the plug-in does this. Why does it redirect for robots but not for users?

JOHN MUELLER: I think a rel canonical would probably make it easier here because that would also let it be cached properly. But I don't see any big problem with redirecting it like this. I suspect there are probably other ways to track this information in Analytics that wouldn't require URL changes, and maybe that would make things a little bit easier because you don't have to put all this logic onto the server. You can just keep the HTML pages as they are and do the tracking with JavaScript without modifying the URL.

MALE SPEAKER 1: Right. But there's no problem regarding the fact that we're doing something for Google that's not being done for users?

JOHN MUELLER: From purely a theoretical point of view that would be cloaking. But from a practical point of view, I don't see a big problem with doing something like this. I think the issues are more subtle. And any time you're doing this kind of a cloaking, there's always a danger of having something go wrong that you don't actually see. So if something is breaking with a redirect, for example, and it's only being done for Googlebot, then diagnosing that is really, really tricky because you have no idea what's actually happening behind the scenes. So as much as possible, I would really recommend not doing cloaking. But in a case like this where you're essentially just cleaning up URLs, I don't find it that problematic.

MALE SPEAKER 1: OK, yeah, thanks, good to know.

ROBB YOUNG: John, I have an Analytics question that you may not know the answer to. Why when you're within Analytics, why can't you update on the same day notations? So if I do some work on the site today, and I want to notate the disavow file or I've done this , that, or the other, I have to come back tomorrow. It won't let you say--

JOHN MUELLER: I have no idea. That's a good point. I don't know.

ROBB YOUNG: There's no option to choose today's date ever in notations. It seems a little bit strange.

JOHN MUELLER: Yeah, I mean, you know what happened today, and you might forget it tomorrow. So the Google Analytics Help Forum just moved to a new platform, and maybe this is your chance to get a question in early while they're still paying attention there.

ROBB YOUNG: Are you trying to get rid of me, then?

JOHN MUELLER: That might be an option there. But I don't know how Google Analytics makes decisions. And maybe it's something they didn't even think about purposely, and giving them that feedback helps them to fix that.

ROBB YOUNG: OK. Because it just doesn't make sense that it would be a deliberate policy as far as I'm aware.

JOHN MUELLER: I don't know.

ROBB YOUNG: OK, then while I'm here, I have another question. In the UK, we had a second site that we were using with a white label partner. So you know the sort things that we do. It was only extreme stuff-- bungee jumping, skydiving, all of the more extreme stuff. And it was on a domain that was essentially via license agreement owned by them, but we controlled. So that license agreement is coming to an end. So for the final three or four months of it, we're going throw all of it over to our main site so we have some kind of transition plan so customers don't suddenly one day disappear. So we're going to throw one. We're going to update or disavow everything. How long after that domain essentially goes back to them will you then consider that a new domain, and if they then put something else on it, as soon as they put something else on it, will you say, OK, well these throw ones are not there, obviously-- we'll lose any of that benefit. Or after say three or four months will all of the benefit be hard-coded into the other domain and you'll start afresh on the new? Or are you just going to say it depends?

JOHN MUELLER: Yes. Most of that we'll probably be able to forward right away. And what we generally recommend with site moves like that is to also update the links to the old site so people are linking to the old site as much as possible kind of encourages them to link to the new version.

ROBB YOUNG: Yeah, we're doing that where we can.

JOHN MUELLER: Obviously, you can't do that for everything. In general, if there are things-- if there are URLs that return a 404 afterwards, then they kind of have to leave with that. And we can still have that forwarded PageRank-- all of that information on those new URLs. So that's kind of a good thing there. It becomes I guess a little bit tricky if they reuse the old URLs for something completely different.

ROBB YOUNG: I can't say that I'm using the exact same URLs for anything. It just wouldn't--

JOHN MUELLER: Yeah, I suspect that probably would make sense.

ROBB YOUNG: It's not going to be until March.

JOHN MUELLER: It's always a bit of a tricky situation. And at least you're looking at ahead of time and setting those redirects up early is definitely the right thing to do there. Doing that after this transition happens is something that is a lot harder. So if you lose your domain tomorrow and you forget to set up redirects, then that's kind of lost. But if you've had a chance to set up these redirects for a while, then you're passing pretty much as much as you can over to a new site, and that's a good thing.

ROBB YOUNG: So it must be at some point in the future if they-- we're not doing it until March. But we're already 301ing. So we'll have a good four months or so of exact URL TRL 301ing. But if they didn't use that domain for, let's say, two years, I assume as soon as they started something new, it would have no effect on us at all. But if they did it after a week, it would. But is the period in between always a bit of a it depends scenario?

JOHN MUELLER: I wouldn't really worry about that. I mean, on the one hand, you can't control that.

ROBB YOUNG: No.

JOHN MUELLER: So those redirects are there, and I suspect some amount of signals will still be associated with the old domain just because for historical reasons, things have been collected there for a while. But that's not something that would have a negative effect on you. Let's put it that way. I think to some extent, there's always a balance on our side between recognizing that a domain is used for something different and recognizing that it's still the same and trying to keep some of that value there that's still the same. And if we recognize that it's something different, really treating it as a new domain. But that's not always something that can split 100%.

ROBB YOUNG: I know a while ago people were asking for a reset button, basically. Has that ever been discussed again? Or is it the same as the real world where if you buy offline real estate, you have to look at the inherent problems with what you're buying?

JOHN MUELLER: Yeah, I think to a big extent, we've gotten a lot better at understanding when something is new to ignore the old signals. But sometimes things still stick around. So I don't know-- we haven't talked about a reset button in a while but only because we probably haven't had any good examples to make a case for a reset button recently. So any of you out there are seeing cases where having a reset button on a domain would have made a really big difference on how you actually use a domain, use a website, and those would be interesting cases to have so that we could take them up to the team and see. It makes sense because of these specific examples or these are just edge cases that wouldn't have helped anyway. But I think examples makes it a lot easier.

MALE SPEAKER 1: John, I'll give you an example right now. This is actually one of my clients who just acquired a new domain. And I talked with you last time regarding the manual penalty disappearing from Webmaster Tools regarding this domain. We actually and disavowed I think it was 98% or 99% of the links. So, yeah, definitely a reset button with the-- yeah, when we bought it, she had no idea that it came with this whole spammy links and everything.

JOHN MUELLER: OK, good. Good. See, good examples. I copied that out. All right, with that, we're pretty much over time already. Thank you all for all of you questions. Thank you all for joining in for the discussions. I hope this was a useful session for you, and maybe I'll see you again on one of the future Hangouts. Have a great weekend, everyone. Goodbye.

MALE SPEAKER 1: You too, John.

MALE SPEAKER: 3: Thank you, John.

MALE SPEAKER 2: Thank you, John. Take care. Bye. bye.