 All right, welcome, everyone, to today's Google Webmaster Central Office Hours Hangout. My name is John Mueller. I'm a webmaster trends analyst here at Google in Switzerland. And part of what we do are these Office Hours Hangouts with a bunch of fantastic webmasters, publishers, SEOs who drop in every now and then, lots of people who ask questions. And we try to get through as much as we can. As always, if there are any of you who are live here in the Hangout that want to get started with the first question, feel free to jump on in now. I've got a question, John, if you don't mind. All right, go for it, Don. Well, this is about voice search, yeah. OK, so last summer, I attended a lecture. That's part of the European Summer School of Information Retrieval, and Enrique Antel Alfonsoeco, Alfonsoeco from the voice search team in Zurich at Google, lectured on conversational search. Obviously, it was really interesting. But one of the things that he did point out is that with voice search, there is no paraphrase. In that, naturally, the queries kind of not moved around as such. And he said that that's something that's very different to other areas of search. Can you expand on that a little? I don't have any context on that. I don't know. Sounds interesting. So effectively, what he was saying is this. With normal queries, there is sometimes expansion, so relaxation and expansion to include more results. Because obviously, people can interact more with the screen, and then there's query refinement. And it might doesn't necessarily have to be entirely accurate, if that makes sense. Because people can give feedback, and there's 10 results to choose from. Whereas with voice, you need to be as accurate as you can be. And you can't just expand out to say, well, let's include this as well, because this may also be relevant. Does that make sense? Yeah. I totally expect the way people interact with search to change over the year. I think that's completely normal. Also with normal search, that's something when you look at the next generation of people go online and search for things, they search in a very different way. So these kind of changes, I think, are kind of natural. I don't really know the specifics around voice search in that regard. See how people might search differently when it comes to voice. Yeah. It also is something where I've noticed just from watching people, they often tend to be a lot more polite on voice search. I don't know if that affects how search behaves as well. People say, please and thank you. It's, I don't know, it's kind of interesting. Yeah. No, I just wanted to understand whether it was because with to paraphrase, when you look it up, it means that you have to be able to fully understand the meaning of the original query and the meaning of the content in the pages that you're going to return. Because if you get it wrong, you can completely mean something else, if that makes sense. Yeah. Also tricky with voice in general, because you just have like one result in most cases that reads like a whole page of 10 search results to you and you get to pick which one you want to actually find out more. It's like, that was really, my point was it around whether precision is more important than recall in this instance, rather than was it to do with the fact that the meaning isn't understood. So it was that though. No. OK. All right. That's kind of clarified it a little bit. Cool. You get to go to all of these fascinating conferences. Really jealous. That was amazing, that one. I learned so much. Cool. All right. Any other questions before we get started? Yeah, one from me. OK. Hi, John. I have the following case before a few weeks. One of our clients win very authority and popular award in Bulgaria. We tried to publish some press release with some provider. And I was expect to win a few backlinks. And I mean a few, three, four maximum. And my task to them was, and my recommendation was this. But after a few days, I received the report of them with 400 press release, with 400 backlinks, and same anchor everything. It's the same. First, I worried about this 400 press release with absolutely same content, duplicate content. This is normal for press release, but 400 is very big number. And second is my number of backlinks. And final, maybe 90% of them is not relevant. I think first to dissolve 99% of them or all of them, what do you have any idea what will be the best practice in this case? I don't know. So first off, I would say that this sounds like things went well. It's not that things went badly for you in this case. If people are writing about this, I think that's a good thing. I don't think that's something that you need to jump in and disavow, especially if these are essentially natural links based on these press releases. Obviously, a lot of the press release content and the press release links that we find we ignore because we see them as something that the webmaster kind of helped to bring this press release out. So we probably shouldn't be treating that link with the same weight as some other natural link that we find outside. But it's not the case that we would say, oh, this website is spamming. It's like they won this prize, and now they're spamming. I think when someone manually looks at that to kind of see what is happening there, I don't think that there's anything problematic in a case like this. OK, thank you. I have a question, John. Sure. All right. I've got a partial match domain name. It's very suitable. It fits. It makes sense. It's very brandable. It's not really purchased as like an SEO play. But a lot of the anchor text that points to specifically my home page, when people mention me in articles, is partial match. And I was wondering if there's any sort of danger in that, or if I should take any sort of action to prevent that sort of, I guess, for lack of a better term, over-optimization of the anchor text. Even though I'm not really the one instigating it or controlling it, it's certainly, I guess, it could look manipulative to Google. So I was just wondering if there's anything I should do, or if I should not worry about it, or what I should do. I don't see a problem with that either. I think that that can happen, depending on how you have your website set up in the beginning, maybe you choose a domain name like that. I think that's a reasonable strategy. I don't think it's always the best strategy to have it like that. Because in a lot of cases, especially if you're in a competitive market, if your domain name is essentially a combination of your keywords, then it's going to be hard to even rank for your domain name. Because if someone is searching for those keywords, then they'll be in this big competitive field where lots of other people are trying to rank for those keywords as well. So that's something where if you were to roll back time and say, well, I can choose between this keyword keyword type domain name and something that's more of a brand or a personal thing, then I generally tend to recommend more of be yourself and not your keywords. That also makes it easier for you to expand over time, where if you say, well, this part of my business is going really well, I want to expand to something completely different or slightly different, then if your domain name is just those two keywords, it would be weird to suddenly add a different section of your website to those keywords, essentially. But that's something where if you set this up years ago, then that's already passed. It's not like you can just say, well, I need to switch my domain name so that I have something more of a personal brand rather than just a combination of keywords. So I guess it depends on how far you are down the road there. Right, and I guess I'm talking more specifically about anchor text if there's any danger in that. I hear what you're saying, though, yeah. I mean, because if I'm not influencing them, if I'm not saying, hey, use this anchor text. But effectively, I guess I'm just thinking some black hat SEOs might say, well, look. John Mueller said, it's not a big deal. And then I'd be like, well, I don't know what to say about that. Is it the intent? Is it the, what is it about anchor text that's good or bad? Yeah, I mean, we look at a number of factors there. And that's something where what we essentially try to do is figure out if these links natural or not. And if these are natural links, then people link in whatever way that they want. And sometimes they just link with a domain name or the name of the business. And if the name of the business are your keywords, then that's how it ended up. So that's something where we try to look at the bigger picture instead of individual links and saying, well, in this case, they link with these two keywords. They just happen to be the same keywords as in the domain name. But is that good or is that bad? Instead, we try to look at the bigger picture and see how that looks there. Cool, thank you. All right, let me run through some of the questions that were submitted. And as always, if you have comments in between, feel free to jump on in. And we'll try to have some time towards the end for any more additional questions that might come up. So the first one is from Max, I think. I saw you here somewhere as well. Looking at our server logs, we can see Google is crawling URLs that are disallowed in our robots text. Why? So the first one is Echo. So in general, I see these kind of questions from time to time around Googlebot crawling things that are disallowed. And every time I look into them with the team, it seems that actually this is either an issue on the server side in that the robots text file is set up incorrectly or that the logging is such that different kinds of URLs are actually logged on the server as being like that. So depending on how you have URL rewriting set up, that might be a case there. But I've never run across a situation where Googlebot knows about a robot's text file and explicitly ignores it. So that's something where I would try to look more into the details of what is actually happening there. Double check that the robots text file is really set up properly with the robots text tester that we have in Search Console. And double check that there is nothing on your server that is logging URLs as being kind of accessed in one way but actually requested in a different way. So especially if you have something special around URL rewriting in there, then that's something that can sometimes play a role there. I don't know. Are you here? Right? OK. I'm happy to take a look at that more in detail, if you like. If you can send me the URLs or some of the URLs that you're seeing being crawled, and then I can double check to see what is happening on our side there, and maybe give you some tips on what could be changed in the robots text file there. Sometimes some of the tricky aspects of the robots text file are when you have different levels of detail where maybe you disallow a path, and then you allow a longer URL combination that also matches the same URL. And in cases like that, we try to find the most specific rule and just follow that. Another kind of complicated situation is when you have multiple user agents that you specify in the robots text file, including the asterisk kind of default user agent. And Googlebot will follow the most specific rule there as well. So if there is one section for Googlebot that allows a lot of crawling and one more general section that disallows a lot of crawling, then Googlebot will follow that more specific section and not the more general section. So those are some of the common things I've run across there. We're also seeing a massive increase in 404s being reported in Search Console. We only see 40,000 404s in our server logs for the same date. Why would Google be reporting so many more? This is something that is confusing in the sense that the number that we reported in Search Console is based on our current index. So if we're saying we know about 100,000 404 pages from your website, that doesn't mean that we've crawled today 100,000 404 pages from your website, but rather over the period of time where we've started kind of collecting data for the index. We've seen 100,000 pages that are still kind of known by us and that have, when they last were crawled, seen a 404 result code. So that's something where this number goes down as the 404 results code kind of get resolved. And we can re-crawl and see the lower number. But it's not the case that you can map directly from your log files this time period to that time period and compare those numbers. Another thing maybe to mention with 404 errors is that they don't affect the rest of your site's ranking. So if there are lots of 404 errors on your site and these are pages that you don't want to have indexed, that's perfectly fine. That's not something that you need to fix or need to change in any way. That's perfectly normal for us. That's the way to set up a website so that it does have 404 errors when we try to crawl your outside shouldn't exist. John. John. Yeah. Sorry. Can I just ask a quick question? It's kind of around this topic, and it's around crawling. Do you remember the other week when we talked about the pages that are no index follow? Yeah. And actually, you'd given a talk somewhere and you'd said that actually, over time, what happens is Googlebot doesn't know follow anyway, even though it's initially follow. Is that because they're still crawled from time to time, but it's the actual page rank that doesn't follow? Or is it just that over time, their download is just reduced, reduced, reduced increasingly? Yeah. If we see a page that has a no index on it, at some point, we'll see it as a soft 404 page and we'll treat it like any other 404 page that we know about. So you wouldn't treat it as kind of a shortcut within a site to get to the discovery? No. Yeah. So for instance, if you wanted to build a navigational page that was there for people to find different things within the site, but you didn't necessarily want that indexed, that wouldn't have any value at all for discovery. So for instance, say you didn't want to output every one of 500 counties or towns within a hotel listing site in the UK on one page because of page load and one thing and another. Actually having then a separate page that is an indexed, which allows people to find further information and via location, wouldn't have any value. And actually, Googlebot wouldn't use it for discovery. Or does it depend on the type of page? If it's clear, it's a navigational page. So what usually happens in a case like that is in the beginning, we do see it as a normal page. We see the noindex on there. We see all of the links. And we try to follow the links as we see them. But over time, if this is a persistent noindex, then we'll tend to see it as a soft 404 page. And then the links there are basically not used at all. Are they crawled? Or are they crawled? Is that page crawled? Because everything gets crawled periodically, doesn't it, seeing if anything changes? Let's get crawled. But if we see it as a soft 404 page, we essentially drop the links that are on that page. So we don't take them into account. So in actual fact, you'd be better off then indexing and then letting Google, letting you decide whether you're indexed or not. Yeah. So that's an interesting. OK. All right, thank you. Yeah, this is something that I think there have been misconceptions around this for quite some time. And I double checked with the team to make sure that it's really the way that I was thinking here and to make sure that we try to bring some of this information out as well. Because on the one hand, it seems to work perfectly fine with us just dropping these pages as soft 404s. But I think it's more useful for people to actually understand that they don't actually have to spend that much time creating these no-index pages to try to circumvent the normal crawling. It's better to just focus on what you really want to have crawled in index and just make sure that that part of the website is linked appropriately. Yeah, I suppose not now. I won't carry on for too long. But the point is, there's a lot of massive science out there now. And sometimes they don't necessarily want to have everything, so they just all get spread out for users. So these navigational pages, if you like, almost beneath the initial surface, not being hidden, but just they're there, but they're literally there for information architecture as much as anything else. Yeah. They're really important, aren't they? I think for cases like that, I focus more on the type-map trial where you can kind of let us know about all of the URLs on the website in a more neutral way and try to find ways to kind of cross-link related topics together so that if we crawl one product, we find kind of the related products. And from there, we can kind of spread out and crawl the rest of the website normally. All right, let's see. One question from the chat. Which image placement is better using the image tag or using CSS kind of background image? So from our point of view, for image search, we would use the image tag with the source attribute pointing at the image. And as far as I know, we don't use CSS images at all for image search. So for normal web search, it doesn't matter. You can use whatever works best for you. If you want to have these images indexed in image search, then I would definitely use a normal image tag for that. Let's see. More questions that were submitted. We're making changes to the mobile version of our site and wondering if text hidden behind dropdowns or tabs is being discounted at the moment and will it be when a mobile index comes out? With the mobile index, we will kind of take this into account normally. So that's something where it definitely will count naturally. If you're making kind of like you're saying here, if you're making changes to the mobile site, that sounds like you have a desktop site as well, either on separate URLs or a desktop version of the same content. And in a case like that, at the moment, we will focus on the desktop site anyway. So we'll use a desktop site at the moment. And as we shift your site to the mobile first index, we'll use your mobile site. And in a case like that, we would be fine with some of the content being hidden behind dropdowns and tabs like that. If we were to show some of our product descriptions on category pages to help boost those landing pages, then how would this get treated if the same detail is repeated on a product description page? Would this work? And the category landing pages rank get an improvement? Or would both the landing pages and the product pages get demoted for doing this? How should you do this? So what generally happens in a case like that is we find the same text snippet on multiple pages on your website. And that's perfectly fine. That's perfectly natural. What will however happen is when someone is searching for something just in that text snippet, then all of these different pages are kind of competing against each other in the search results. And we're trying to pick one of these pages to show and try to figure out which one is the most relevant in a case like that. So that could be that maybe your category pages seem more traffic, but that would kind of come at the cost of your product detail pages seeing less traffic. So that's something which you essentially can decide on. And think about for your website, for yourself to see, does it make sense to kind of bring more information at a higher level within the website at the cost of those higher level pages ranking more when people are actually searching for detailed information? Or does it make sense to kind of separate that out and clearly say, well, this is detail information and this is kind of more general higher level information? So that's something that you essentially can pick and choose and figure out what works best for your website. It's also something where if you're not sure, which one of these is best, usually you can kind of A-B test this as well, where you take some of your categories or some of the products and you kind of try this out. You let it run for a couple of months and you compare it to some categories where you have it set up differently. And you see where users are reacting differently. Are they coming to your site? Are they doing what you expect them to do? Or are they bouncing? Are they going back? Are they looking for something else? Do they end up browsing to the detailed pages anyway? And maybe you can shorten that and just send them directly to the detailed pages. But that's something you can definitely test. For Branch Finder, would it be better from an SEO point of view if all the branch pages were visible on the Branch Finder page and not behind any dropdowns? So I guess there are multiple things kind of coming together here. On the one hand, it sounds like you have multiple locations all on one page and you have kind of a dropdown that selects one of these locations. And depending on how you have that set up, if you have multiple pages actually for the individual locations where you select one location and it navigates to that other location, then that's something that doesn't really matter from our point of view how you kind of give us that link to the detailed location. On the other hand, if this is something where you have to select something in a dropdown and then it does an Ajax call or something to the server and gets information and displays it on the same page, then it's important to keep in mind that Googlebot isn't going to be clicking on any of these dropdowns and it's very possible that some of the content that would be kind of pulled in from your server on demand would not be seen by Google. So depending on how you have this set up, that's something where you can test with the Fetch as Google tool to see if this content is actually visible when Googlebot goes there and if this content is actually in the HTML when Googlebot goes there. If it's just a matter of highlighting things that are already loaded on a page, then that's obviously less of a problem. But if it's really the case that you're pulling content from the server on demand based on something that's selected and the URL stays the same, it's very possible that we wouldn't see that. I'd like to understand what's a good ratio of search pages and product pages for an e-commerce website. So I guess category pages and secondary category pages, how much inventory is a good thing. I'm worried that the same shoes might appear on different pages and cause duplicate content problems or that a user might not find sufficient inventory and leave unsatisfied. I think this is also something that you kind of need to work out for yourself and that you probably would find a lot more input on from users directly. So instead of looking at this as an SEO problem, like how many of these type pages should I have, how many of that kind of pages should I have, I'd say that for the most part, Google Search will be able to deal with any kind of site like this. And especially if you're talking about a site that's selling 100 different shoes, then that's something where it's not an infinite number of URLs that we're talking about. You might have 1,000 products and maybe 2,300 product category pages. And that number of pages is something that we can easily crawl, regardless of how you have that set up. On the other hand, if you have 10 million products and you're talking about maybe 5 million different category pages, that's something from a technical point of view that's quite a different problem. That's something where you want to kind of dig into that and figure out how crawling and indexing is expected to work for such a large site. But again, if you're starting out with an e-commerce site, you have a limited inventory, I would almost focus more on doing user studies to see how they want to navigate a site like that rather than focusing on SEO issues. A question about AMP and canonical. Suppose a web page is desktop friendly, but not that good on mobile, so the AMP page is used together with that. But the canonical URL on the AMP version remains that of the desktop version. AMP will improve the mobile user experience, but how is Google going to treat the mobile page from mobile friendliness since the canonical URL is a desktop one? So what I would almost recommend doing in a case like this is saying that the AMP page is actually your mobile URL. And then just applying the normal markup that we have available for separate mobile URLs. And you can tell us the AMP page is the real alternate mobile version. And on the AMP page, you have the well canonical link back to the desktop page. So when we look at that overall, we see your desktop page. We see the desktop page points to the AMP page as the mobile version. And also it points to the AMP page as the AMP version. So we can show the AMP page both for mobile search normally and as well as when we would show the AMP page itself. So that's kind of what I would recommend doing there. Another approach might be to think about what you can do to actually move to a responsive design so that you don't have to have a separate mobile URL so that actually when someone visits your main URL with a mobile device that they actually see the full content and have a good mobile experience there, regardless of AMP or not. We have multiple sites, some pages with cross-domain canonicals. The mobile variations are on their own subdomain. For mobile-friendly implementation, should the mobile canonical tag on mobile domain A point to the desktop domain page A or desktop domain page B, which is a true canonical? Let's see. Trying to wrap my head around the setup that you have there. It sounds like you have multiple domains, but you actually have one domain which you want to have as the canonical. In a case like that, I would just point all of the canonicals to your actual preferred canonical rather than to chain them separately. So if you have a mobile page on one domain, then I would make that canonical link really directly to the mobile page or the desktop page that is the true canonical for this page rather than to have it point to one desktop page and that have a canonical to the other desktop page. I would just go directly. The closer you can go directly, the more likely it is we'll be able to follow that properly and to be able to use that accordingly. Any time you add additional steps in between, it just means that something can break or something can take a bit longer for it to be processed. And usually, you want to keep it as simple as possible to make sure that even when something goes subtly wrong, it doesn't break the whole chain. Can we submit a single category in Google News? For example, domain.com is a blog page, and we want to submit a category domain slash news and not the other categories. I don't know. I would recommend going to the Google News Publisher forum and asking the folks there. They're a pretty experience, and they can give you a lot of information on what it takes to actually be listed in Google News. I know they have a reasonably high bar with regards to content that they support within Google News. So I'd make sure that you have all of the information and that you can mark off everything that's required and that you really have a fantastic website before you focus too much on getting listed in Google News. I'm running a site about physics in Spanish, and I've been trying to solve a problem for months now with the index status reports. And let's see. Some forum threads that you probably need to look at. So it sounds like the website was hacked. And no, wait. Googlebot detected an increase in server errors from the website. And let's see. The index status number after fixing those errors has gone up to 3,500. Is that a problem or what might need to be done there? I'd probably need to take a look at the forum threads there to actually know a bit more about what you've done and what you're looking at there. In general, if the index status report shows a higher number than what you expect, that's not necessarily a sign that something is completely broken. That can happen for various technical reasons. Usually that settles down over time as well. Over a couple of months, we figure out, oh, these URLs are actually duplicates, or these URLs are actually errors, and we can fold them together. And then the index count goes down a bit. It's definitely not the case that the index count will always be the total number of pages on your website. I think that's a really rare exception that we would index everything from a website. And it's really, really common for us to recognize a ton of other URLs that actually lead to the website but have essentially the same content. And because of that, the index status count can easily be quite a bit higher. And especially if you're talking about a number between 1,000 and 3,500 there, that's something I personally wouldn't worry about. Finding a couple thousand pages on any random website is easy to do. And Googlebot crawls a lot of links on a website and can easily discover a lot of different URLs. And knowing about 1,000, 2,000 more URLs for a website, that's not going to cause any problems. You've said in the past, Googlebot mostly crawls from the US, and speed is a ranking factor. Wouldn't hosting a website outside of North America hurt its ranking due to increased latency and slower internet speeds? So I think there are two aspects there that are subtly being kind of mixed. And I see this come up time and time again. There are two aspects here. On the one hand, the crawling and indexing of a website. On the other hand, recognizing the speed. And these are usually quite different aspects. So for crawling and indexing, it definitely helps that we can crawl as quickly as possible. But we can deal with a number of websites. And we don't have to crawl every website with the highest speed possible. If you don't have millions of pages that you're putting out every week, then we don't need to crawl millions of pages every week. We can just crawl a handful of pages and make sure that we're still up to date with our index. On the other hand, with regards to speed, we do try to figure out what a user would see there. And we try to take that into account rather than what Googlebot specifically sees. There are really practical reasons for this. One is that it's really common for websites to use content delivery networks, which means that your website is no longer hosted in one specific location, but rather in a lot of different locations. And in a case like that, the speed that Googlebot sees, which might be fairly quick because maybe there's a location near, I don't know, California somewhere. But that doesn't mean that what users would see when they go to your website is really quick. So that's something to keep in mind, that these are very different things. And also when it comes to the speed that we try to understand from a user point of view, it's not just the speed of accessing a page from your web server. It's really, to a large part, also the speed that it takes to load the whole page, which means the images, the CSS, the JavaScript, all of that needs to be processed and rendered in a browser. And usually, that takes a significant longer time than just accessing the HTML page for a one-time fetch for Google indexing. Back in March, we migrated our website from a Yahoo store to Magento. And since then, organic traffic has dropped in a major way. We're trying to figure out what happened here. What can we do? So I took a quick look at the website before the Hangout. And one of the things that I noticed there is that a lot of the older URLs that used to get a lot of traffic, they all lead to 404 pages. So it seems that you migrated your business to a different CMS, from Yahoo stores to Magento. But you kind of didn't set up those redirects from the old URLs to the new URLs. And that's one of the things that definitely does cause problems with website migrations, in that what happens here is we know about all of these old URLs that we thought were really awesome. And we were showing them to people in the search results. But they all don't work anymore. So Googlebot drops those old URLs from the index. And we don't show them in the search results anymore. And it takes a significant amount of time for us actually to figure out what the new website looks like and to figure out, is there any mapping from the old content to the new content? And if we don't have any mapping from the old content to the new content, we essentially have to treat that website kind of like a new website. And then you're almost like starting fresh, not completely fresh, because obviously people are probably still linking to your home page. And we kind of know this is a reasonable website. But you are starting with a real problem there, in that all of the things that we used to think were really awesome on your website, we don't find them anymore. So setting up those redirects now would probably still be a good thing. I mean, if you made this change in March or when I was looking at the logs, it looked more like around July. That's still a pretty long time. But I think those redirects would still help. The other thing that I noticed is the setup on Magento seems to be in a somewhat suboptimal way, in the sense that all of the URLs that I accessed, they get redirected to URLs with a session ID attached in the URL. And for us, that means that if we blindly follow that session ID, it looks like every page that we request is a new page, a completely new page that's not associated with anything else on the website. And that's something that can take a bit of time for systems to learn that we can actually ignore the session ID in the URL and we can just focus on the rest of the URL instead. So I think the two main things that I ran across when I looked at this, on the one hand, the migration was done in a way that you're essentially starting over instead of starting with the basis that you had before. And on the other hand, with the new setup, you're essentially doing some things that are technically set up in kind of a bad way. So both of those things are probably still worth fixing. What I would also do is maybe go to the Webmaster Help Forum and just see if other people are able to find other issues that can be resolved as well. My worry is always that when I run across these kind of basic SEO issues that probably there are a lot of other things as well that were neglected that could be done with a small amount of work and you probably still have a pretty big impact from that. For me, looking at this, like moving from this kind of default setup on Yahoo! Stores to your own custom setup, it also kind of shows that a custom setup isn't always the best solution here or the easiest solution in the sense that a lot of these kind of pre-built e-commerce setups or pre-built CMSs, be it Wix or WordPress or anything like that, they're sometimes set up in a way that actually work fairly well. They have a lot of experience running these. And if you shift to your own custom setup, then you really kind of have to know what you're doing to be able to get a significant advantage out of that. Is it considered plagiarism? If I use text from my blog as a script for YouTube videos and vice versa, so I don't know. Plagiarism sounds like something where you're almost asking a legal question, so I don't want to kind of say what is plagiarism or not. But with regards to duplicate content, when it comes to SEO, I think that's perfectly fine. If you have content on your blog that you would like to use in a YouTube video, that seems like a good thing to do. And sometimes people like to consume content on YouTube instead of consuming that on a blog. Sometimes it's easier to create content on YouTube. Sometimes it's harder to create content on YouTube. That's definitely, I think, a reasonable strategy to say, I'll try both of these out or take some of the content that worked well on the blog and use that somewhere else. Since escape fragment is deprecated, can we use push states for loading inner tabs content? This will create separate tab pages as well. For example, this other website's hotel landing pages uses tabs, and they implement push state on the same. What will that help with SEO ranking? So essentially, what you're doing with push state is navigating to a different URL without loading the new pages content. So that's something where, essentially, push state is the same as a link on a page when implemented like this. And links on a page to load different content within different tabs on separate URLs. That's totally up to you. That's not something I'd say you should do or you shouldn't do or that you'll have any kind of significant SEO advantage from that. It's one way to provide a fairly good user experience in that the page doesn't have to reload, but you can still swap out the content for the content that a user would see when they would navigate to that URL directly. For months, Google hasn't displayed news of our sports website on the top story section. Sometimes when typing in the name of the website in search, news are displayed, but there's a delay of two or three days on the search's top stories in the news section. We produce about 100 stories a day. We're sure it's not a quality problem as all of our information is high quality journalism. And even some of those news are labeled by Google as highly cited. I don't really know what specifically to do there. That's something where it would probably be useful to have more detailed information on what specifically you're seeing there. In general, the top story section is an organic part of the search results. And sometimes when you show more sites there, sometimes we show fewer sites there. That's not something where you include a special meta tag when you get featured there. It's really a matter of our algorithms trying to figure out what makes sense, what doesn't make sense to show there. So that's not something where I would expect the website always to be showing there. And it can definitely happen that we don't show a website there in some cases. So this is kind of the normal organic search results. We have URLs on our website that display localized content for users in different US cities. Does the main Googlebot crawl from different locations within the US and take this into account? No. Googlebot crawls from one location. I guess technically speaking, it's probably different locations. But I assume the IP address is all mapped to the same location. And in general, what happens then is we only see the content that is shown to maybe users in California, for instance. So what I generally recommend for more localized, personalized content is to make sure that you have a significant part of your main landing page actually show generic content that is valid for users in all of these locations. And then just have one section that is actually localized where we can kind of understand that this is localized content. And we will probably show that in the search results as well like that. But where users in other locations still are able to kind of find your website based on that more general content there. And this is really more of an issue on maybe the category pages or on the home page of the website. And usually what happens is from those pages you link out to the more localized versions. And those localized versions, they tend to have the same content for anyone who's accessing them. So if I'm in California and I search for, I don't know, shoe store in Dallas, then I'll get kind of that localized content for Dallas on your site, perhaps. Whereas if I just search for the shoe stores and go to your website, then maybe I'll get the localized content for my location. I feel like it's made it a little bit more confusing than it actually needs to be. But in general, I just recommend making sure that you do have enough generic content on these pages that are more generic as well so that we can figure out that this is actually kind of generic piece of content, too. Let's see. A bunch of questions. Do, do, do, do, do. OK, I think there is one question about a hacked site somewhere. So someone added a bunch of hacked pages. We removed it with 404s and 410s after a couple of days. And nothing has been working since then, essentially. So it dropped in rankings. And it looks like we're still showing the hacked content there. So I took a quick look at that site. And it feels like there are still some hacked issues that are on that website when I took a quick look at that. But what is sometimes a bit confusing is that when we recognize that a part of a website is hacked, we tend to remove that from the search results ourselves. So that if you do a site query for the hacked content, it'll look like that content is actually gone. And you might not dig for that content itself. So that's something where I would double check your server logs to make sure that really all of the hacked content is actually returning 404s and not that it's actually still there and just not being shown in Google Search. And then you're kind of not aware that this content is actually still around. So that's kind of what I would do there. What I would also definitely do in a case like this is go to the Webmaster Health Forum because the folks there have a lot of experience with hacked sites. And they have kind of various tricks and tools that they use to look into a website to see where there might still be issues with regards to hacked content or where there might still be some things that you could actually clean up in addition. And maybe they have some tips there or can point you at some pages that are maybe still on your website from that original hack or maybe from an additional hack that happened afterwards. Also, they're able to escalate these type of issues where if they can't find anything at all and it looks perfectly clean, that one of us from the Webmaster team is able to take a look and kind of double check that everything from an algorithmic point of view is working as expected to. Let me just run through some of the other questions. Or maybe I'll just open up for more questions from you all. John, can I ask something? Sure. John, now my next question is, we have some websites very popular again in the niche. And everything is normal now, but donors start to migrate the website to new design. With new design, they include all services, all them services with new user experience. Everything will be better. But before this period, they was have another website only for one services. They have connection with these services, but they have another website for these services. Now, in new websites, they will input all content for these services, and they will present these services in the new web design. What will be the smart way in this case? Because now, first duplicate content, another domain, maybe we can connect them to present with another website to these services, or we must redirect the second website to the new web design, the big branch. Yeah, so I think the two kind of cleanest options would be to either choose a canonical if it's the same content or the same service, essentially, on different URLs, to say I will choose a canonical one between these two, maybe have a strong feeling on which one you prefer to have shown in search. And you can use a rel canonical for that. A redirect is also an option where you actually redirect people to the other version. But that also means that people wouldn't be able to access the other version or the redirecting version directly under those URLs. So that's something which is sometimes worth looking into. Also, you could just say, well, I will just merge these two websites into one website. It makes it easier for maintenance in the long run. It makes it easier to promote the whole business because it's one clean brand, one clean website. That's usually what I would recommend doing there. I mean, sometimes there are technical or policy reasons why you want to have this on multiple websites. Maybe you have offline advertising that's running where you want to have those old URLs also shown, and you want to make sure that when people go there, they can stay on those old URLs as well. Those are all considerations as well. I think if you're talking about one big website and you have this small other one that you want to either migrate or copy, then that's less of an issue. Whereas if you have two websites that are essentially the same order of magnitude from a size point of view, then that's a little bit trickier when it comes to migrating or using rel canonical because then you have really big parts of a website that need to be kind of re-understood. If it's really one big site and one small chunk, then you can kind of do it in whichever way you think makes sense without worrying too much. If you have two that are kind of the same, then the effect, depending on which one you choose, will be very visible, I suspect. OK, thank you. Perfect. John, I have a question. All right. I actually submitted it in the Google Plus, but you probably didn't notice it. So if we have a multilingual website, so we are thinking about how to annotate it with the link role alternate HF lang. And so we have several questions about this approach. One of the questions is whether we need to indicate the rel canonical alongside rel alternate. Should there always be a rel canonical? I think that's usually a good practice. Where should this rel canonical lead to? Is it just a self-referential rel canonical? Yes, yes. Is there any rationale behind this rel canonical? What is it telling Google bots? If we find multiple versions of that page, then we know which one you actually want to have indexed. So for the rel alternate HF lang link, it's important for us that the links that you specify in the HF lang kind of setup that these are the actual ones that are indexed like that. So for example, if you have a URL with slightly different upper and lower case or with dub dub dub or non dub dub dub, then these normally lead to the same content. And normally, we could look at that and say, well, we will just pick one of these. It doesn't really matter. But if you have a rel canonical on there, then that's a sign for us that actually you do care. You do want this specific version indexed like this. And that's important for the HF lang set, where we kind of try to link those specific versions and not roughly the same pages together. OK, then the next part to the question is if the different language versions of the site have just minor differences, like differences in the menu, in the navigation, and the main content of the page is the same, would Google bot consider this as duplicate pages? Although we would use the rel alternates, or would the rel alternates tell Google bot that these are not duplicates? These are actually different language versions. Are they in different languages? Well, the main content may be in the same language. But in our case, we are offering books. And the annotation of the book and the title of the book would be on the page. They would be in the same language for different language versions. But the menu would be different. The navigation would be different. So the minor portion of the web page would be different. Would Google bot be OK with that? Or would it consider it duplicates? Yeah, that's fine. I think that's a very common setup, where you have the main content in one language and sometimes the rest of the website changes. And things like maybe the comments of people leave comments that are in different languages, that's kind of normal. I think in an ideal case, the main content is also in the same language as the rest of the website. But when you're talking about books, book titles, when you have user-generated content, that's not something that you can choose. You can't take a forum entry that someone wrote and translate it manually into all of the different languages that is kind of not possible. OK. And the third part to the question is whether the hreflang x default should always be present. Like, are there any situations when you cannot honestly choose which language version is the default version? Would it be OK for Google bot to just have the alternates without the x default? Yeah. Having the alternates without x default is perfectly fine. The x default makes sense when you have a strong opinion about which one you want to have as the default version. Or when you have something like a language picker page or an auto redirecting home page, then it makes sense to have the x default there. But if you just have different language versions and you're saying, well, this English version is my preferred main page, then you can set an x default. If you say, I don't care which page people go to, if it's the closest match for their language, that's fine. Wonderful. Thank you. Hi, John. Can I please look at this question from this chat session? So I just want to. All right. Let me check. Is it better to have one page on one topic with all the related topics or split the topic into different pages? For example, best weekend, get away in your city. Should we just stick with popular destination near that place? Or does it make sense to include other topics there as well? I think this is totally up to you to decide and to figure out what makes sense for your website, for your users. Sometimes really comprehensive pages perform really well with users. Sometimes users get overwhelmed by the amount of information on a really comprehensive page. That's something you can test and try it out and see how it works well with your users. In general, from a search point of view, if it works well for users, we can make do with it in search as well. So that's something where I would primarily test this with users and see what their honest thoughts are on the amount of information that you can provide on a single page or if they prefer to have it split up into separate pages. All right. Thank you. All right. Any last questions before we head out into the weekend? In the new Search Console, where's the download button? It's coming. I talked with the team about this as well. They said it should be there soon. So I assume, I don't know, next week or so, next couple of weeks. It's good to see that some people already have the new Search Console. For my private account, I'm still waiting for it. So a lot of you are kind of seeing the new things happening, but not yet for my website. So I have to be patient as well. How long ago did a big job before it's rolled out everywhere? I expect just to take a couple of weeks. So maybe, I don't know, end of January, mid-February, I don't know. It's hard to say. It kind of depends on what happens in between. If the rollout is really smooth, then maybe they can speed things up a little bit. If they run into hitches along the way, then maybe they need to slow down and figure those out first. Is there an order to it? Is it e-commerce? Because one of my clients has just got it. It was an e-commerce site. No. I think it's just, I don't know, they take a hash of the URL and just use it like that. Something kind of more generic. I've also heard from people saying that we gave them access to the new Search Console on their HTTP site. They migrated to HTTPS last year and was like, I don't have any data. Oh, remember, I switched domains and then changed it back. And they put it on the new one, but not the old one. And then when I switched back to the old one, I lost it. Yeah, I don't know. Maybe that's a tactic to kind of like verify as many versions of your site as possible so that you have a chance of getting one of those in with the new data. I don't know. Maybe it's just easier to just wait a couple of weeks. Yeah. All right. So I think there's still a handful of questions left. If there's something on your mind that you really need to have answered, I'd recommend copying that into the next Hangout. Or if you need to have an answer a little bit earlier, either ping me on Twitter or just go ahead and post into the Webmaster Help Forum. The folks there are really good at finding these kind of questions and figuring out what it could take to help solve whatever problem that you're running into. So I'd definitely give that a shot. All right. So otherwise, let's take a break here. Thank you all for joining. Thanks for listening in, for watching, for submitting questions. And I wish you all a great weekend. Bye. Have a good weekend, all. Bye. Thanks, John. Bye. Bye, everyone. Bye, bye. Bye, John. Bye.