 All right. Welcome, everyone, to today's Google Webmaster Central Office Hours Hangouts. 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 where webmasters, publishers, people who put content online can join in and ask questions about websites and web search essentially. As always, if any of you want to get started and ask the first question, feel free to jump on it now. Can I? Hi, John. All right. Sounds like we have two people, so maybe one after another. And then we'll do both of you. Please go ahead. All right, go for it. Actually, I saw something in the answer box, like the image is only black background, nothing else. The image is a black background. Yeah. I don't know. That can happen, I guess, if we pick up an empty image at some point. OK, I just want to know that any algorithm update for the answer box? No, anything specific there. But I know this is something that people are always working on, so I wouldn't be surprised if things change there over time. OK, fine. Thank you. Can I ask a question? Sure. OK, I have some questions about the better add standards, if it's possible, if you can help me with that. Maybe. I can try. I've just been in touch with them on the side, so I don't have all of the detailed information on what all is happening, but maybe I can. OK, so basically, we own an affiliate network and we have a lot of problems lately with our publishers because they received a lot of messages with recording videos from you guys, showing that some banners are not OK, even if they are, I don't know, mobile 300 for 100 is not too big. But they were flagged as inappropriate. Can I? I can't remember. I can't understand why. That's my problem, basically. What I would do is go in the help form that they have set up for that. I think it's called the form for ad experience report and post about that specifically there. I've seen people from the team have been regularly replying to the threads there. Sometimes they can give specific information. Sometimes it's more a general kind of thing where we don't have specific numbers to share, we can say like 400 pixels is OK, 405 pixels is too much. Sometimes that's not the granularity at which these are defined. Yeah, according to the rules, I saw the banner must not go over 30% of the screen. And that's OK, but as far as I understood, you have problems also with the banners that have blinking buttons or something like that. Is this possible? I don't know. I would ask him in that help form. Thank you. OK, let's hope we can get back from other people there if the person from Google can't give you exactly what you're looking for. Sometimes they can point you at some similar things, too. OK, thank you very much. Sure. Hi, John. I've got a question. I dropped you a line the other day around elastic search. And we feel probably one of our competitors has done something against one of our sites where it's found a loophole in the elastic search to allow it to generate URLs. And we feel that they've been somewhat how indexed by yourselves. We don't have it in our site map. They don't kind of exist in our URL structures. It was about 6,000 URLs. And because of the URL parameters, it's very similar to our pagination. We can't kind of say, on robots.txt, to block that URL structure. Is there any way that you can think of how we can try and get rid of these 6,000 URLs from the index, please? That's kind of tricky if the URL pattern is very similar. So what you might be able to do is to server the index with your own code on the end in your CMS. That might be an option. But the difficulty with using no index there is that it means we're still going to crawl these URLs. So if crawling, like part of your search pages is a problem by itself, like maybe it crosses a big load on your server and everything slows down, then that won't really solve that problem. Then that's something you almost need to find some combination of robots.txt parameters that can catch this. So sometimes you can do that with wild cards where you can say parameter equals a, asterix, for example, and kind of go through the letters where you're seeing these problems to make sure that the pagination versions of those parameters are still crawlable. And just those specific patterns are kind of blocked. But that's really kind of tricky when the URL pattern looks very similar to URL patterns that you do want to have indexed. Yeah, I think also the issue is then of going through your search console to bulk remove these pages is a rather problem because obviously it only allows individual removal. And that's our next thing. So we kind of have an idea of the URL structure in these 6,000 pages. But then how do we then remove them from your index? Because it's kind of affecting us as seeing it as duplicate content, for instance. I wouldn't worry too much about the index part. If you have the longer term plan figured out with like new index or robots.txt or something, then that will settle down on its own. It's not something that you'd need to urgently remove from the index. The urgent removal tool from in-search console actually doesn't remove it from the index. It just hides it in the search results. So that probably wouldn't be what you're actually looking for. It will look like it's OK, but actually it's still in our index until we've actually reprocessed it normally. What you could do is perhaps set up a sitemap file with those URLs and submit that with a new change date for those URLs once you've added the noindex tag to them. And we'll go off and re-crawl them, see that the noindex tag is there, and then drop them from our primary index. OK, perfect. Thank you. All right. Let me run through some of the questions that were submitted. And as always, I'm sure there'll be more time for your comments and questions along the way. And we'll try to keep some time towards the end as well. Since I announced this fairly shortly a couple of days ago, we don't have millions of questions yet. So maybe we have a good chance of making it. We're trying to improve our product pages by adding FAQs, videos, and manufacturers documentation basically to make it as informative for the user as possible. Would we get some benefit from the Panda algorithm if we do this to improve our pages? So just generally stepping back, I would not worry about the Panda algorithm in a situation like this. If you're really improving your pages for your users, then that's something that we hope to pick up across the board from our algorithms. And it's not something that you'd need to do just to make the Panda algorithm happy. Essentially, if you make your users happy, then that's something we'll try to understand as well. So I would mostly focus on the user part and figure out what it makes sense to really provide for users that makes your pages significantly better than everything else out there. And that could be by adding these kind of information. And if you focus on the user, then usually that kind of algorithmic part settles down on its own as well. Some websites constantly change their landing page content every time you refresh the page and use these blocks of content to share amongst their pages to make them look unique at every refresh. This technique seems to allow them to outrank other pages. What are your thoughts on this? So first off, this is something that a lot of websites do not specifically for Google in the sense that a lot of pages are very dynamic. And they set up their site in a way that kind of automatically creates something new every time people view it. From our point of view, that's not necessarily a good thing, though. Because if you're changing the internal architecture of your website every time we look at your pages, that makes it really hard for us to figure out which of these pages are important, which of these pages are higher-level category pages, kind of things going up, and which of these pages are related to the current page you're on that are kind of further down in the hierarchy of the website. So from my point of view, this is not something that I would say really profits a website. Because every time we look at it, it looks different. And that can be pretty confusing sometimes. So from that point of view, that's something I personally wouldn't just recommend following blindly in the hope that you too can outrank everyone else. Sometimes there are other reasons why a website ranks, despite doing these techniques like this, that actually kind of hinder a page more from being recognized for the content on the page and to understand the context of this piece of content within your bigger website. If we 301 a page, can we take that content and reuse it on a new page where the 301 is going to? Yes, definitely. You can do that. So 301 is a really common use case is when you're moving content from one URL to another one. You let us know that this has permanently moved to the new URL. And in that case, you do take the content from one page and you put it on a different page. And the 301 tells us, focus on the kind of redirection target page instead of the original page. That's perfectly fine to do. Can the placement of internal links on a page have an effect on how the destination page is ranked? In general, kind of where you put the links on a page is less important than that we actually do find links on a page that are pointing at other parts of the website. So that's something that we've sometimes run across websites where we do have a problem that we can't crawl them properly because the internal navigation just isn't available. Sometimes what happens is they have a big search section on the website, and you can search for that content, and you can find it through search. But it's not actually linked internally with the internal navigation. And that makes it really hard for us to find all of this content. Because Google Cloud can't go in there and just search for all variations that it thinks there might be potential content out there on this website for. So we kind of have to try to find a way to crawl through that. So instead of worrying too much where you place those internal links, I would just make sure that you do have internal links on those pages. And to test the internal linking and the crawlability of a website, there are lots of really cool tools out there that can help you to figure that out or to try it out, kind of similar to how Googlebot might do that. One tool I know of is Screaming Frog. That's really popular. I haven't used that myself, so I can't vouch for that. But that's something that I've heard a lot of people do use for this kind of testing of a website to make sure that it's actually crawlable. And I think that's a really important thing to do. Even if you feel your website is actually pretty good with crawlability, then that actually makes it a lot easier for you to kind of understand what search engines might be doing when they come to a website. And then you see, oh, these internal links are actually set up in a bad way, or they're linking to different URL variations, and suddenly you have a giant mess of URLs on your website when this crawler goes through there. That's something that you might not have kind of this intuition initially when you look at your website. And having a crawler run through that and you watching what the crawler actually does, that can be really insightful. We just recently disappeared from the Knowledge Graph on the side. This happened since replacing old content with new content on approximately 1,000 pages and using 301s. Is there anything we can do to correct this? So the Knowledge Graph, the Knowledge Panel on the side is something that's generated algorithmically. That's not something that we can guarantee that a website will always be seen there. So that's something where sometimes it takes a bit of time for things to settle down. If you're reorganizing your website, restructuring your website with new URLs, with redirects, with content kind of moving around, then that's kind of normal to take a bit of time to actually be understood by our systems. And there's a chance that we pick up the right information to show in a Knowledge Graph again on the side, but it's not guaranteed. So this is something I definitely give a time. And if after the time you notice that it still isn't picking up the way that it was before, I might double check that you actually do have the same information on those pages, that it can still be found, that information on your pages, that you're using the right kind of structured markup, if that's available for your setup, that we can actually extract that information easily. And if all of that is OK and you still can't figure it out, I would go to the Webmaster Help Forum, where people have a lot of experience with kind of digging through website issues in general. And sometimes they're just general issues that are in the way of us picking up the information in an optimal way. So that's kind of the approach I would take there. Oh, gosh. What would you recommend for 2018 if you had to pick three things to concentrate on to improve rankings? I don't know. That's kind of tricky. I don't know what three things I would focus on there. Let's see. So I guess the kind of turning around and looking at the topics that we're currently looking at for 2018, which might kind of fold into what you could be looking at for 2018. On the one hand, it's trying to make sure that JavaScript sites work really well in search. That's still something that we find a bit challenging from time to time. And understanding how JavaScript works, how rendering works, that's a topic that I think will be pretty important for this year, because more and more sites are using these modern frameworks and making sure that they work in search is something that, as an SEO, you have a chance of playing a role there. On the other hand, if you just go and say, oh, it uses JavaScript, I can't help you with that, then you might be missing a big opportunity there. So that's one thing I would focus on. Mobile is definitely also still something that's really, really important, essentially making sure that all of your page's content is available completely and all functionality is available completely on mobile devices in a really good user experience. So not just taking your desktop pages and mapping them one to one to mobile, but really making sure that they're really fast, that they have all of the information that is needed on there, that they have all of the information that you need to be visible in search, like what you want to be found for, that they have all of the functionality of your desktop pages so that people don't have to kind of bookmark this URL and then send it to them by e-mail and look at it on a desktop computer a little bit later. Chances are they'll forget about that. And they won't convert if they have to go to a desktop computer to actually convert. So that's one thing that I would also focus on. And the third thing is something that we've also been talking about for a while now, everything around structured data. I think that's something that is still kind of hit and miss for some websites where working together with a web designer and making sure that you mark up the right things, that you're using JSON-LD, mark up on pages where that makes sense, all of those things combine, can play a role in how we pick up the content. And sometimes that's not mapping directly to rankings. Sometimes that might be mapping to different ways of appearing in search, which could be that maybe Google Assistant is able to extract more information about your business thanks to the structured data market that you have on those pages, and through that is able to recommend your business in ways that a normal web search engine might not be able to do. So those are the things that I would be focusing on there. Whether or not all of these improve your rankings, I think is kind of short-sighted thinking, because that's making the assumption that everything around search will stay the same, and it's just a matter of sites shifting up and down in the search results. And that's pretty much guaranteed not to be the case. There are almost certainly bigger changes in search happening where it's not just a matter of things shifting slightly up and down, but rather of things being used completely different. So that's kind of my take on that. All right, let's see. If a product is no longer in stock, what would you recommend doing? So this question comes up fairly often, and I think my recommendation would be that we should write a blog post about this so that people have something to actually look at in documentation kind of point of view. Journal's options here are let the page stay indexable, but have structured data to indicate the product is no longer in stock. 302 redirect the product page to a nearly identical variant. Let the page stay live, but set meta no index. Let the page stay live, but have a canonical pointing to a nearly identical variant. So what I would do in a case like this, before we actually have our documentation set up that you can follow, is kind of differentiate between situations where a product is permanently out of stock and never going to be in stock again and nobody is going to care about this product anymore in the future and the situation where the product is kind of temporarily out of stock and might be back in stock at some later point. And I guess a third variation might be that the product will never be in stock again, but you want to keep something as a reference. So with, let's see, those three situations in mind, if something is really permanently out of stock and never going to come back and you have a replacement product that's pretty identical, I would just redirect to that replacement product. That seems like the easiest solution there. From a search point of view, it might even make sense to just reuse the old URL and say, well, this is the URL of the new product instead. That helps you to kind of build on the existing URL rather than to have to worry about all of these redirects going to old versions and this 2011 version of the product redirects to 2012, 2013, 2015, 2018 version of the product, all of those redirects are a big hassle to maintain. So if you can keep the URLs and just replace the content, that's probably the ideal situation. If it's temporarily out of stock, then essentially that's up to you. I would probably keep that page as it is and maybe use structured data markup to indicate that it's no longer available at the moment. That way, we can keep indexing that page. We can keep crawling that page. And once you change the markup to say it's available again, we can pick that up and show that again. So nothing really changes there. If it's something that is moved to an archive situation where you say, well, we once had this thing and we want to have a placeholder for the documentation and the support material, all of that, I might consider moving it to an archive section of a website and just keeping it there as something that's not a part of your normal shop, not normal e-commerce setup, but kind of like a place where you keep kind of old documentation, old things together and just redirect to that page instead. So those are kind of three variations. I hope that covers the more common ones. And again, we should probably write this up at some point to make it a little bit easier to figure out what the options might be. From late December, different language versions of a site were canonicalized into one. It's shown in the new Search Console report. For example, de.example.com and en.example.com goes to en.example.com. And in the cache is the version of the German page shown as the English one. Has Google changed something from multi-lingual sites? Is it a problem with thin content or some issue with hreflang, canonical, or redirects? Hard to say exactly what is happening in this specific situation. When you say they were canonicalized into one, were they redirected to one URL or not? In general, when you make bigger changes with canonicalization with redirects, that can take a bit of time for things to settle down on our side, especially if it looks like these pages are not exactly identical. Then we might not be sure of which one to actually use and to show as a canonical one in the search results. So that's something where I suspect, since you're talking about the new Search Console report, this is fairly recent. And maybe it's just a matter of time until it actually settles down in the situation that you've provided there. And one thing I would just make sure to do there is if you have a preference regarding the canonical URL, then be as explicit as possible about that. So set up redirects from the old URL to the new one. Use the rel canonical. Make sure that all of the internal linking goes to the preferred version that you want. Make sure that the sitemap file points at the preferred version. All of these signals kind of add up for us. And the more we can clearly say this is the one that you want, therefore we'll show that one, the more likely we'll be able to pick that up. On the other hand, if the signal say a bit here and a bit here, and we're like, well, we need to make a decision, then maybe it'll go this way or maybe it'll go that way. And that kind of isn't really what you're looking for. What does duplicate content mean? Content copied from other websites or original content that's duplicated within a website? Which one to avoid most? Can a website be demoted if original content duplicates within website pages? So that's a complicated question, actually. So we have different types of duplicate content that we look at there. From our point of view, there are lots of technical reasons why within a website you might have the same content on multiple pages. And from our point of view, we try to help fix that for you as much as possible. So if we can recognize that these pages have the same content on them or the same primary content on them, then we'll try to fold that into one and make sure that all of the signals we have focus on that one page. On the other hand, if this is content copied from multiple locations, then that gets to be a bit trickier for us, because then we have the situation that this website has this content on it. Another website has the same content on it. Which one is actually the one that we need to show in search? That makes it a lot harder, because then it's not a question between which one of your pages we want to show, but which one of these pages by different people or on different servers do we want to show. And there might be strong opinions by both sides saying I want to have my version show. So that makes it a little bit trickier. The trickiest one or the one where maybe it's not trickiest, the one where you really need to watch out for with regards to duplicate content is if within your content, the majority of the content is copied from other sources or the majority of the content is kind of rewritten, repurposed from other sources. Then when our algorithms look at your website, they're like, well, I've seen everything from this website before. There's nothing of value essentially here that we would miss if we didn't index this website, because all of this content is based on something that's available on different parts of the web. And in a case like that, it can happen that our algorithms say, we need to kind of ignore this website completely. We don't need to focus on it in search. The manual web spam team might even come in and say, actually, it's a waste of our resources to even look at this website, because it's just pure copies of all of these other websites. Maybe slightly rewritten, but there's nothing unique here. And in those cases, we might remove a website completely from search. So that's kind of the one that you really need to watch out for. If it's really just a matter of your content on your website in multiple URLs, then from a technical point of view, you can improve that slightly by kind of having fewer copies on the website, but that's not something that you really need to watch out for. John. Yes. If someone copy content of our website, the DMCA, can you protect us? Can protect you. So I need to be clear that I can't give you legal advice. So I can't say you can use the DMCA to do this, or you should use it, or it's the right approach here. That's something where you need to have kind of legal advice from an advisor on your side first. The DMCA process is something that we do follow. So if you submit content to us and say, this was illegally copied from our website, then we will follow the right steps with the DMCA approach to kind of take whatever action is necessary there. And one thing to keep in mind here is that this is on a per URL basis, so it's not that you can come to us and say, well, this website copied a lot of our content. Do what you need to do, Google. But rather, you need to tell us explicitly, this URL on their website and this URL on our website, this is where the problems are, and Google needs to figure out what it needs to do there from a legal point of view. So that's kind of what you need to watch out for. But again, I can't give you advice on when to use this or where you need to use this. It's really something where you should get some legal help first to make sure that you're doing the right thing there. If you go off and do the DMCA complaints wildly without any kind of reason behind that, it's also possible that this backfires because it is a legal process. OK, thanks. John, off the back of that in my conversation earlier with you, we've got a similar issue. And actually, within this competitor, they've actually created a directory in the name of our website. So they've obviously sectioned off the whole area. And we can see where they basically duplicated all our URLs and our content, which they don't possess. Is there an easy way to go instead of going through a legal route to present this to Google? As far as I know, you need to go through the normal process there. So there is no bulk review or Google does a review kind of process. You really need to follow the steps on a per URL basis. OK, thank you. Hi, John. Hi. So I was about to ask you something about related to how Google calculates the quality of a piece of content. So what is the importance of the metrics like fresh reading, quite the length of paragraphs, the paragraphs after hearings, and the passive voice tone, or, for example, how difficult the text is written, and something like this in this direction? So from an SEO point of view, it's probably not something that you need to focus on in the sense that, as far as I know, we don't have these basic algorithms that just count words and try to figure out what the reading level is based on these existing algorithms. But it is something that you should figure out for your audience. So that's something where I see a lot of issues come up in that a website will be talking past their audience. So maybe you're making a common example as a medical site. You want to provide some medical information for the general public because you know they're worried about this. And all of your articles use these medical words that are 20 characters long. Yeah. It's something where, technically, it's all correct. And you could calculate the reading level score of that content. You come up with a number. But it's not a matter of Google kind of using that reading level score and saying this is good or bad, but rather it doesn't match what the people are searching for. If nobody's searching for those long words, then nobody's going to find your content. Or if they do find your content, they're going to be like, I don't know what this means. Does anyone have an English translation for this long word that I don't understand? And they go somewhere else to either convert or to read more or to find more information. So you don't have any specific algorithms which calculates these metrics or something like that? At least we don't have anything public that we say this is what we do and this is what happens there. It's something that I know the team is still working on this. So it's not like a one-time algorithm thing. And we figured it out. And now it's working forever. I know there are people here in Zurich that are still working on trying to understand the quality of pages better and to figure out where pages are good, where pages are bad, and when to show them where they're relevant. Thank you. Thank you, John. Sure. All right, let's see. Some more of the questions that were submitted. Is your guidance about infinite scroll from 2014 still good guidance to follow? Or would you offer any updates? From my point of view, that's still pretty relevant. So having something that changes the URLs in a way that they remain valid URLs that can be crawled and accessed directly, that's good. Having some kind of pagination links as well, I think that's really good as well, because that way, even if any search engine doesn't do this infinite scroll kind of action or event on a page, they can still crawl through those pages. So from that point of view, I think that guidance has aged surprisingly well. I haven't actually checked the sample site that we put up in a long time. Maybe we should double check to make sure that it's actually still working, but that's more a matter of kind of normal maintenance of a website. The second part of the question is any additional thoughts on how to help Googlebot crawl links loaded on scroll in spa build in Angular? So spa is a single-page app set up in Angular. I think that's a complicated topic. Lots of things to talk about there. I would recommend taking a look at the blog posts that we did for rendering. I think that was last fall. And also, at Google Developer Days in India, we did a presentation on making PWAs more indexable. Those are good places to start and probably help you kind of get started there. We also have a smaller Google Group set up specifically for JavaScript sites, where if you have specific questions around your site or kind of a design pattern in general, you can go there and get advice as well. I try to stay up to date with the threats that are happening there. So you might even get an answer directly from me there, or you definitely get an answer from one of the other people who have been working on trying to figure this out. So there are some things you do need to keep in mind. You can't just take any random JavaScript framework website and kind of assume that it works for Google. You do have to kind of watch out for some gotchas to make sure that nothing crazy happens when we render the pages. I'm curious as to how long you think it would take for a large sitemap of 301s to start showing degraded index rates of URLs contained in the sitemaps. I know 301 sitemaps are improper, but it's a technical question, our curiosity. I don't think we have any number that we have for this. So it really depends a lot on the website itself. And on some sites, we crawl millions of URLs every day. And then 10,000 URLs more or less is like, nobody cares. It's like, in the noise. And we can pick that up fairly quickly. On the other hand, on other sites, maybe we just call a couple thousand URLs every day. And then 10,000 URLs more, that does mean a significant amount more to kind of process and spread over time. So that could take a lot longer there. So there's no real kind of time point of view where I could say, this is how long it should take and this is how long it shouldn't take. From a rough order of magnitude point of view, I don't think this really helps, but I'm thinking with somewhere between a couple of days for a website where we do crawl and index a lot of content to maybe four, five, six months for pages where we don't crawl a lot of content, where it takes a long time between crawls for us actually to get through everything. So that's a pretty big time frame to keep in mind there. And finally, one thing that makes this a bit tricky is if you're using site queries to look this up in Google Search, so not in Search Console, then it might even be that after this period of time, we tell you a number for the site query that is still significantly higher. And the reason for that is that we still understand this mapping of the old URLs to the new URLs. And if it looks like you're explicitly searching for the old URLs, we'll try to be helpful and show them to you. So you might do a site query for a site that moved to a new domain maybe a year or two ago, and you might still see results there. And that's not a sign that something is broken. It might just be our algorithms trying to say, hey, this person is looking for these old URLs. I know about these URLs, so I'll be helpful and bring them to the user, even though we've moved all of the content to the new URLs in any time. A quick question about GPS coordinates in schema, is it essential using GPS coordinates within code or via schema for a website business focusing for its clients based in different locations or states in a country? As far as I know, we don't use GPS coordinates in that regard. So if you have addresses on a page, then that's something I would mark up. But as far as I know, we don't use GPS coordinates. So this year, if your business is located in a place where there is no actual postal address, I don't know what we would do in a case like that. If that's the situation for you, then I would love to find out more. So feel free to maybe contact me on Twitter or on Google+, and I'll try to figure out a little bit more with the schema.org folks on our sign. If it's really a matter of different business locations and you do have addresses, then I would focus on addresses and not GPS coordinates. Just around that, John, obviously you're getting better image recognition. Are you using at all any of the EXIF data within images? Or is there any benefit when you're talking about local image search, for instance? Because obviously when you're using something like Tinypng or something like that, to optimize it often strips out the EXIF data. And is there any benefit to keep some of the EXIF data in images to help with local image SEO, and so forth? So the last time I checked on this was a couple of years ago, and we did use some of the EXIF data there. But that was specifically for image search. So I don't know if that's so useful in a case like yours. So if someone is searching for a location in image search and we have this information about the location for the images, then that might be useful for us to actually show those URLs in image search. But it's not the case that we would use the EXIF data in images and apply that to the ranking of the web page itself. So those are kind of different situations. Sure. Sure. Thanks. But I should really double check with the image team to see what the current status is with regards to EXIF. And maybe there is something we should document a little bit better to kind of make sure that if we are using it that people are aware of that and they don't use tools that strip out this information without adding it back in at the right time. Thanks. In the EU, we must add a cookie policy page. This is something we add by default on every site that we create. The content is obviously the same. Is this considered duplicate content? Hard to be creative on that matter. That's perfectly fine. If this is kind of a div on your website that you have across all of your sites, that's the way it is. And for the most part, we should be looking at these pages and saying, well, this is kind of copied across the board. And we know it's the same everywhere. But there's actually unique content elsewhere on this page. And we'll try to focus on that unique content. So that's something that, from our point of view, should be no problem. The important part for us is that we can still render these pages. So if your cookie policy page is actually a redirect that goes somewhere and sets a cookie and redirects back, then that's something that could potentially block us from actually crawling and indexing your content. On the other hand, if it's like a subtle banner on the bottom or something on top or like a box somewhere, and we can still see the rest of the page when we render that content, then that's perfectly fine. Canonical A to B, then after one month, we do a no index on A. Does page B drop in ranking? Because the related signals from A are not transferred anymore. I don't know. That's interesting kind of setup there. In general, when you have a canonical from one page to the other one, and we have a canonical because we see that it's kind of a confirmed thing in that the same content is both on both of these pages. You have the internal links also pointing to your new canonical. Then usually, we kind of treat that as a redirect. So if there's a redirect in place, then we do forward those signals. If after some time, the redirect drops out and a lot of the signals are still applying to the old URL, then that could be a bit of a problem. On the other hand, if you've moved all of those signals to the redirect target already, then if the original page drops out, then it's gone. It doesn't really have any role anymore because there's nothing attached to that original URL anymore. We are storing additional website information in Google Docs, which spiders don't pick up. Would it be found and credited to the web page if linked to a blog or is there a better platform? So we can index some content from Google Docs, but I believe you have to set it public to everyone, of course, so that we can actually look at that content. But it's sometimes tricky for us to pull out the content from Google Docs with all of the formatting options and everything. It can look pretty complicated to a search engine. So if this is critical content for your website, then I would make sure that at least the critical part is also on your pages so that we can find your web pages for that critical content. You can have a link to the Google Docs page there as well. And users can go to the Google Docs page to get detailed information, kind of like you would go to a PDF file to get a detailed document on that topic as well. But at least we'd be able to find your web page and rank that appropriately based on the content that you have on the web page as well. Let's see. Four questions. With the new Search Console data, we can see 16 months of data for a single domain property. Will this look-back window also be available to property sets? As far as I know, property sets are also on the horizon. So that's something that should be happening. If a website rewrites a URL but doesn't return 300 status code, can Crawler figure that out that the URL has changed? For example, you request one URL on the server. It turns a different one with 200 OK. So if the server returns a different URL, then that sounds like there's actually a redirect happening. And if that's the case, then that's fine. If you're just returning the content of a different URL and kind of making both of these URLs available, then it's a matter of us figuring out canonicalization. And sometimes that can go one way, sometimes another way. So again, make sure that all of the signals are aligned. Two websites with similar content, each representing a branch in a different city. We're seeing one site's pages in Google Cache and snippets for the other one. Can we take any steps beyond canonicalization to prevent this? Usually this happens when large portions of the website are copied across both of these sites. Then we assume that, actually, the whole website is kind of a copy of another, and we try to help you by just picking one and showing that. So if you don't want that to happen, then make sure that these pages are really unique, that the whole website on its own can stand on its own is not seen as mostly a copy of another website. And let's see, final question here. Google is rewriting our meta descriptions even after we've optimized them. So what can we tell Google to stop doing that? We do change the snippets and the title of pages we show in Search. And that's not really something that you can control. It's also something that depends on the query that people use. So that's something where provide good titles, provide good descriptions, if you try to use them, but we can't guarantee that. I don't think it's going to work. I don't think it's going to work. Ah, but I think it's going to work. Of course, I have suggested that search console data is unreliable. Can this data be trusted to make important business decisions? For example, if click-in impressions data is only showing half the story, can it be trusted as proportional, even if it isn't showing us all the data? So I don't know specifically what is mentioned in this blog post. It mentions Webmaster Tools, so that sounds like it's pretty old. For the most part, the data that we do show in Search Console is not absolutely complete. It's something that is, however, a significant portion of the information that we have for our website, and it's meant to be as representative as possible. So for example, when it comes to clicks and impressions, we do figure out things that only happen very rarely. We filter them out primarily for privacy reasons, so that these one-off searches can't be linked back to specific users. But that's something that, overall, across a bigger website generally ends up being somewhere in the noise. And the other aspect there is that it's sometimes really hard to actually measure what a website is exactly getting for traffic. So sometimes, even if you're looking at analytics data, which is generally pretty good, there's lots of reasons why that data might not be complete. That could be that people are using ad blockers and blocking some of these scripts. And then you see some data here and some data here, and you're like, this isn't lined up. So that's something where, if you look at different sources of data, you will always see differences. I don't think there's ever a case, unless you've blocked the website completely from the internet, that you will see the same data when looking at very different ways of tracking kind of that data. We created a booklet PDF with good information on government disability regulations, and we want to make it freely available. Much of the content in these documents is taken from articles from our website. The PDFs are text documents, not image documents, contain no text anchors. Will duplicate content in the PDF document harm our website's ranking or other websites that choose to host it? Nope, definitely not. If the PDF is hosted on another good quality website, can links in the document pointing to our website potentially improve our websites ranking? So from what I understand, links in PDFs we do try to pick up. But as far as I know, we treat them similar to links in text files that we don't pass in signals through those links. So that's not something where you probably see any change in rankings due to other people hosting your PDF. What will also probably happen with these PDFs is that we'll recognize that these are the identical PDFs, and that's something that's a lot easier with PDFs because you do copy them one to one. And we'll generally try to pick one of these PDFs on one location and try to index it there. So what you can do if you want to have your version as the index version is use the rel canonical header, which you can specify as an HTTP header as well for PDF files and tell us that this is actually the canonical version. That can help us there, but it's still not guaranteed that we always pick the PDF that you host on your website because sometimes there might be reasons to actually pick it up somewhere else. And from a general point of view, if you're trying to spread this information, if this PDF has information about your company, links back to your website with more information, then it probably doesn't really matter which one we index because people will find this document. They'll find a way to go back to your website to get more information. And that's probably what you're kind of looking for. So that should just kind of work out. Can you tell me scenarios due to which my US site gets ranked in all regions, Google Search, but not the local site for that specific region? We have hreflang in place, site links are displayed for US Google Search, but not for all local sites. So this is completely normal. We do try to have local rankings when we think that people are searching for something local and just because there is one big site in one country doesn't mean that it automatically ranks number one in all other countries. And that's essentially completely normal. That's kind of the way that the web works in that we try to figure out which of these URLs is relevant in which of these locations. And then we have to kind of take all of that into account and figure out how that lines up. A quick rendering question. Google Search Console fetch and render shows very odd rendering for all URLs of a client site, almost a CSS broke. Same for search regions as well as users. No priority block resources reported. This is a WordPress site. Mobile usability report is also showing an increase in mobile errors. What could be happening there? So I don't know. I'd have to take a look at the screenshot and maybe look at the site of what's happening there. What I would recommend doing in a case like this is talking with other people as well and either posting in the Webmaster Help Forum or specifically in the JavaScript Sites Forum if you suspect that it's due to something from the JavaScript side. But either of these sources might be able to help you kind of figure out what specifically to watch out for. Why can't Google Reps answer questions on malware? Even if we don't see malware on our website or in Search Console, they ask us to remove the malware. So what is sometimes really hard with malware is that sites can be hacked in ways that are really hard to figure out and in ways that are essentially cloaking specifically to Google or to Google's users. And figuring that out can be really hard if you don't have experience with that. So my recommendation, if you can't work this out on your own, is to go to the Webmaster Help Forum and check with the experts there, or if this is something that you rely on and it's being flagged as malware to go directly to a consultant maybe who specialized on malware issues because they have practice kind of looking at ways that hackers try to hide malware on a website. And in the meantime, they're sometimes really good at hiding malware so that you as a webmaster don't even notice that it's hacked. But when users come to the site, they get redirected to crazy hacked content. All right. Oh, wow. Time-wise, I think we're almost on time. I need to head on out fairly soon. But maybe there's time for one more question from one of you. John, I'd like to ask a question. If the new regulatory factor for the Site-B is going to be the main ranking factor for all including desktop and mobile. The main ranking factor. I don't think it will be the main ranking factor. I think in our blog post, we also talked about this a little bit in that it is a ranking factor that we take into account, but we still take relevance into account as well. So just because the site is slow doesn't mean it'll never be visible in search. So you will only be counting as the mobile site-B won't be calculated by it. The desktop will have different algorithms. Yeah, this is only specific to the mobile version of the search results pages. When using the Page-B inside, the ranking factor will be considering the score in the Page-B inside, or you will considering the user experience in the Chrome browser. So I don't think we've kind of specified exactly what we're looking for when it comes to speed. There are lots of different ways of figuring out what the theoretical and what the kind of practical speed aspects are there. We want to keep this open a little bit so that we can make sure that our algorithm reflects more what a user would actually see, even if that sometimes means that it doesn't reflect exactly one-to-one one of our existing tools. So we think our tools map fairly well to that, but it's not like we take this number and multiply it by the number here internally, and we come up with a ranking factor. All right, I need to head on out. I'll be setting up probably a hangout in Mountain View next week, so if any of you are watching and want to join in in person from Mountain View, I'll be putting that on Google Plus as well. I think the one on Friday I need to cancel because I'll probably be busy with lots of other things, but maybe we can catch up next week in person, and we can do a normal hangout then as well. All right, thank you all for joining. Thanks for all of the questions so far, and if anything else is on your mind, feel free to jump on in the help forums to kind of bring some more information there as well, and hopefully I'll see some of you again next time. Thank you, John. Thanks, John. Bye. Bye.