 Always weird. OK, 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 is talk with webmasters and publishers like the ones here in the Hangout and the ones that submitted a bunch of questions. We did a series of Hangouts on specific topics in December. And this is currently the last one that's scheduled. We'll set up new Hangouts maybe for next week if people are around, otherwise for next year again, of course. Today's topic is Search Console. So a bunch of questions were submitted. I also have very brief summary of some tips that I run across that I send people every now and then in the form of a presentation. I'll try to run through this fairly quickly so that we have enough time for questions that were submitted or questions from you all here in the Hangouts. If you're seeing this live and you need more time to digest what's on the slide, feel free to pause the video or wait for the recording on YouTube afterwards. All right, let me find the right tab. And then we can get started. So, big Search Console topic. I figured I would start with the most obvious. Should you use Search Console or not? Because sometimes we see people kind of come in and say, oh, I never used Search Console before. And I thought this would be a very simple way to get started. So if you have a website, of course, use Search Console. There are a bunch of reasons why some of them I'll get into with the rest of the presentation. Some of these are not completely obvious, such as URL removals. So if you have a website and you put content online and you need to remove something quickly, then having it verified in Search Console is a great way to start. Great way to get that content out as quickly as possible. So one topic that comes up every now and then is how do you best handle verification. One thing that I usually recommend is to figure out a strategy that works for you, for your website, so that you can systematically kind of work with Search Console. One suggestion we have is to use one account to combine all of the variations of your site and to delegate access from there. And for that account, if that's the main account that you're using, make sure you're using two or more unrelated verification methods. So that if one of them fails, the other one will definitely still be there. So a common possibility could be to use DNS and file-based verification, so that if DNS fails, then obviously your website won't be available. But the file-based verification, if your server kind of loses that file, if you drop out, if the server is returning errors for some reason, then of course, the other one will be able to back you up. When you're using multiple people, or using the same site in Search Console, I'd recommend using company domain name accounts so that you can easily recognize who these people are that have access to your site. So don't take random Gmail accounts and just add those, but rather use them from your domain. And as much as possible, use read-only access unless you really need read-write access. Sometimes we see this happen that people accidentally change something in Search Console. And until somebody notices, it can take a bit of time. So ideally, just use read-only access. A common complaint I hear is it means I have to add so many different sites. So first off, one thing that I see from smaller and larger sites all the time is they have a ton of different subdomains for essentially the same content. So I had a big European airline recently that pinged me and said, they don't really know what's happening in Search Console. And one thing I noticed is they have all of these different subdomains. And they're serving very similar content on these subdomains, which means you have to add all of these subdomains to Search Console, combine all of that data, and then look at the combined view before you can really understand what's actually happening here. So fewer sites is a lot easier. In your main account, verify all of the different site variations, but only delegate access to the preferred version. So instead of delegating access to www, non-www, and all of these variations, just pick the one that you really want to have indexed and grant access to that. Make sure you're collecting all the email that comes in, regardless. Maybe set up some filters to make sure that the important emails you get through Search Console actually reach someone. So one thing that you can also do if you have a bunch of different sites and you can't easily just clean them up because sometimes it's not as easy as it sounds. You can use a property sets feature in Search Console. So this is a great way to get one view of multiple sites at the same time. I use this, for example, when looking at our help forums because we have HTTP and HTTPS kind of semi-randomly indexed because we never managed to clean that up properly or on the forum side. And you want to look at the overall picture so you need to combine all of these versions into a single entry and look at it like that. So they're not all reports support property sets, but more and more reports do. Some important things to keep in mind is that this is per user. They can't be shared. You need to be verified for all of the variations that you include in there. And it doesn't backfill the data. So if you decide, in January, you'd like to see a combined view of the data from December, then you can only do that if you've set up property sets already. So make sure to set those up early. And one thing that's sometimes confusing when you're looking at search analytics, the data is aggregated for this set. So if you're looking at impressions per keyword, per query, pages per query, those kind of things, then keep in mind this is for the whole set. So if you have multiple sites and they're ranking independently for the same keywords in search, then we will pick one of those and count that one as impression. And we will pick the top one as the average top ranking for that query. So it's not the case that you can just add up the individual sites and see the combined view. This is essentially doing something pretty smart that helps you understand how much visibility do you have overall, not per site or per URL. One thing that also comes up all the time is how aggregate reports work. And the important thing to keep in mind here is that these are based off of indexing. They're not based off of your current site. They're based off of what we found when we crawled and indexed your site. So if you make significant changes on your site, then it's normal that it will take some time to settle down again. So in this case, there was a test run here. And you can see some of the URLs dropped. This was, I think, the index pages report. Then they moved to HTTPS completely. They did the full move on this date. But you can see that's a lot of the URLs dropped out fairly quickly because they're now on the HTTPS version. But for the rest, it takes quite some time to actually settle down completely. And this is not something that you need to force, not something that you need to manually tweak to make them go away. This is essentially the normal crawling and indexing. And you'll see the same thing if you fix an issue with structured data, if you change your AMP implementation, you'll see a fairly sizable chunk of the URLs move fairly quickly. And the rest just takes some time to happen. Data spikes. So this is something people sometimes freak out about, which is understandable, because if you see changes that you don't really understand, it can be confusing. We like to flag that in Search Console as much as possible. So we'll add this kind of line here, which is barely visible. And we'll put a note here, either I think we change it now to say note, thanks to feedback from Barry, for example. You should just say update. You can click on this. And you can go to the Data Anomaly page to get information about this specific change. A lot of these changes are just based off of our internal crawling and indexing systems. And they don't affect how your site is visible in Search overall. So this is something, don't panic if you see spikes. Don't panic if you see this note annotation in Search Console. It's just telling you something internally changed. You might see some effects of that in the graphs, but that's completely normal for the most part, not something you need to worry about. In this case, I think we moved some of the site over. And you see this kind of rise here in the index information. So some of these changes are based off of things that you do. And sometimes we just make internal adjustments that also affect the graphs here. All right, so going over to Search Analytics. So Search Analytics is a great feature within Search Console to understand how your site is visible in the search results. But before you kind of dig into what we show you there, I strongly recommend that you look at the Help Center article that we have on impressions, clicks, rankings for Search Analytics. You can find that by searching for impression Search Analytics. Fairly easy. It goes through the different visible elements that we show in the search results and how we count them for ranking, for impressions, for clicks. So I think that's really an important thing for you to kind of go through if you're relying on Search Analytics and maybe go through that every now and then, because some of these things are not trivial. It's really something where you kind of need to understand what this data is actually showing you in order to make a good decision based off that data. Another common mistake I see quite often is when a site has just very few impressions for queries. And the webmaster wants to know, how do I improve my rankings? Or how do I improve the clicks? Or what does this mean? Essentially, if you're seeing that the site has very low impressions for individual queries and you assume this is a fairly popular query, then that means your site is just occasionally ranking. Or it's just shown in the personalized search results. Or maybe it was just shown once on one day in the last month, but not regularly. So this is something where you need to keep in mind that this low number of impressions means that the data that you're looking at is probably not representative. It's probably not something that you can repeat yourself when you look at the search results yourself. So this is one of those things to kind of keep in mind. Usually what happens when I see weird things in Search Console or with regards to a total traffic to my site, I see changes, then I kind of help people to drill down for the details to figure out what specifically changed. Was it like a section of your site that's not being shown so much in Search anymore? Was it accidentally removed? Was there maybe a technical issue on your side with regards to this part of the site? Is this something quirky that's happening for just individual countries? So for example, the Webmaster Central blog sometimes ranks for the query Google within Canada and within no other country. So we sometimes see big jumps in the number of impressions for the blog, which actually don't really indicate that the viewers or the normal searchers that we're trying to target have changed their behavior or our site is ranking in a fantastic way. It's essentially just showing that, well, Google was showing your site for something that's probably not so relevant, but it made a big impact. And the only way you can figure these things out is by drilling down for the details. So the type of search query that's shown, the location, and really figure out what happened here. And finally, one thing that I recommend is to try to save the data that you get in Search Analytics. You can either save that to Google Spreadsheet, or you can use the API and pull it down on your site. There are also a bunch of really fantastic tools that pull down the data with the API. There's a neat browser plug-in or Google Spreadsheets plug-in that pulls in the data into Google Spreadsheets directly. Essentially, what you want is kind of a longer term, over time, view of your site's visibility. And Search Analytics at the moment just has three months of data. So if you want to look further, if you want to look at the whole quarter or whole year, then that's something you need to collect on your side. And you need to collect that from time to time. You can't think of this at the end of the year and say, oh, if only I had the data for the rest of the year, because then it's too late. So kind of drop a calendar reminder in your calendar and make sure you download that data whenever you need to collect it for the long term. So another question I often get is what do the number of URLs index mean? How can I improve them? I want to get more URLs indexed. And from our point of view, usually the number of indexed URLs doesn't matter so much. It's better to focus more on the impressions than the indexed URL count. So the sitemaps count is usually better than the index status report in the sense that the sitemaps count tells you of the URLs that you specified which ones are indexed, so the number-wise, at least. Then index status reports includes things like duplicate content or a complicated navigation structure that you might have on your website. So that's still better than just doing a site colon query in the search results, but it's not really what you want to focus on. And even better than that is looking at the impressions and thinking about which URLs are actually being shown in the search results and am I covering the range of the search results that I think my site should be covering. Another big topic in Search Console that webmasters often don't think about and that people often don't think about when they're setting up a new website is urgent URL removal. So maybe you accidentally index something that was actually private data, and you need to get that removed as quickly as possible. Then by having your site verified, you can do that essentially as fast as we could if you kind of contacted us with a legal document that you got from court saying Google needs to remove this page from the search results. So this is something you can do as quickly as we can, essentially, if you have your site verified. So the thing to keep in mind here is that this hides the URL from the search results. It doesn't remove them from the index. So they're essentially still indexed. You might still see this data in Search Console, but they're not shown in the search results, which is kind of what you're trying to do. The thing to kind of keep in mind here is that this tool covers all of the different variations or the common variations, HTTP, HTTPS, dub, dub, dub, non-dub, dub, dub. So it's not a fix for canonicalization. If you use it for trying to take out the HTTP version after a site move, then you're going to take out both HTTP and HTTPS, which is almost certainly not what you want to do. We recommend using this only for urgent issues, not for site maintenance. So if you take a page out of your site and you just want Google to kind of reflect that over time, then that will drop out automatically as we recrawl and re-index those pages. You don't need to use this tool. The verified version, so if you have your site verified, is faster, and you can do directory subdomain removals as well. So moving on to mobile-first indexing. This is something that we recently announced that we're going to start doing towards next year once we have everything kind of ironed out, where we'll start indexing the mobile version of a page instead of the desktop version. And when that gets closer, we think you'll probably want to use some of these tools within Search Console to help you get that right. So the fetch-end render tool is a great way to check to see how Googlebot renders your smartphone pages. I definitely take a look at that for your important page types so that you can see that we're actually picking up all of the content that you want to have shown in Search. The mobile-friendly testing tool is another way to get a screenshot of your site from a mobile point of view in the AMP test. Make sure that if you're using AMP on these pages that you're doing everything right and flag some of the issues there. When mobile-first indexing starts happening, which we don't have a date at the moment, I don't see that happening like the next couple of weeks. It's definitely more longer term, so don't panic there just yet. But when that starts happening, make sure that you're monitoring your kind of metadata dashboards within Search Console. So structured data, rich cards, hreflang reports, all of these things that are not immediately visible to users, those are the kind of reports I'd recommend monitoring to make sure that you don't have crazy things happening there. Like all of your structured data disappearing because you forgot that this also needs to be on your mobile-friendly pages. All right, so coming to the end, if you have more questions, we have the Help forums, which is a great place to go. We have the blog where we announce new things around Search Console. We have a testers group that you could join if you wanted to. At the moment, we don't have any tests running, but I'm sure we'll have more tests in the future as we try new things out and want to get advice from the field, from webmasters and SEOs like you, or of course, you can just ask in future hangouts. All right, so with that, I kind of came to the end of the presentation. Do any of you have any questions specifically about these topics before we move on? John, just out of interest, what percentage or I don't know if you know the answer, what percentage of websites actually use Search Console? Oh, wow, I don't know if we have a number for that. So the difficulty there is sometimes when we look at metrics like that, is when you say web percentage of websites overall use Search Console is kind of hard for us to judge. We look more at the percentage of sites that use Search Console that are shown in the search results to kind of see where it actually makes sense to use Search Console, because there are lots of domains out there that are not used. And with those count or not, that's hard to say. But of the sites that are shown in Search, we do have a significant percentage that are using Search Console. Or at least that are verified in Search Console. It's hard to say if they're actually always using it or not. Because to some extent, we also think that if nothing is wrong, you don't need to do a lot in Search Console. That's fine. Just out of interest, do you have any numbers on that? I'll just be interested to hear, because there's so much important stuff that when things go wrong, Search Console mails you. And it's just kind of interesting to know how many people have real sites and real search results, and don't get any of those notifications at all. I don't think we have any numbers to share or not. OK. Thanks. Can I have a quick couple of questions regarding the API mostly? Since I built that Google Sheets add-on that lets you request and backup data from Search Console, I've seen some small issues with it, specifically one regarding property sets. It doesn't seem that it's really supported in the API. I mean, at least not from what I've tried. I mean, I can get data when I query with a URL, but not with a property set ID, as it seems to be the only way they're referenced in the API. So for Search Analytics, that should actually work. I tried that out in the beginning, but maybe something changed. I don't know. I haven't tried it in the past two months, I think, but it didn't seem to work with the ID of the set. Instead of the URL, it just returned an error, I think. So what I do there is I list the sites, and then I take the ID that's shown in that list of sites and just use that. Yeah, yeah. That's what I use, but it didn't work at the time. I'll retry it and let you know if it works. One other thing was there seems to be a bug that's been reported by quite a few people when we use the same start date and end date. And there's more than 5,000 results. Even if you try to paginate it, it will always show you 4,999 for some reason. So that doesn't seem to be any page 2. So it's just 4,999 results. So I tested with multiple sites. And whenever it's the same start date and end date, this seems to happen. And there's certainly more data. It just seems to bug out, I guess. OK, I don't know. I'll have to take a look at that. It seems like the API is one of those things I need to get back up to speed on and double check with the team what's all happening there. Well, I can send you those. Sure. Yes, that sounds great. Also, not necessarily regarding the API, but it would be useful since when you're grouping by query, even in the web interface, you're only shown a certain results are being excluded due to privacy reasons. There's nowhere that is really being stated. So it would be useful for users to see a message. We did exclude some queries for our privacy rules or something like that, because users need to go to the help page to actually figure out that this is why if they do the sum between the impressions or the clicks, it's not the same as the total amount that's being shown. Yeah, yeah, that's. So at least a message that I've heard a few times, yeah. At least a message that we are filtering some data out, so just so you don't freak out why it's. That's a good point, yeah. Kind of like an info link to that. Yeah. John, any plans to perhaps have less of a capture requirement on the fetch and render? I think people have asked that a few times before, but just wondering if there's any updates on it? I don't know what the specific plans are there. So one of the things that I think is coming is with the recapture, there's the invisible recapture where the recapture is kind of done without you having to solve anything. So I suspect that's something that would be happening. But I don't know what the timing on that invisible recapture actually is. OK, cheers. Anything else that there is to an answer to in terms of any upcoming changes? Or is that not really for this hangout? Changes, you should know from me that I try not to pre-announce things too much. OK. Yeah, I don't know of anything specifically happening with Search Console just now. We just updated the AMP report with regards to making it clear which parts are critical, which parts are not critical, but I don't know of anything specific that should be happening. I assume also there'll be kind of like a pause over the holidays anyway with regards to launches so that people don't have to kind of keep catching up. OK, thanks. All right, so let me run through some of the questions that were submitted. And we can follow up with more open questions from you all afterwards. Can you differentiate between a user searching for some topic and the user wanting to go to a website that's the exact match domain of that topic? Probably not, at least not in Search Console. You essentially just see the query. Is there any data in Search Console that can help us determine which part of a website users think is high quality? Not directly, but of course indirectly you can look at things like which queries people are coming to your site for, which pages they're landing on, and then within Google Analytics maybe see how people are staying on your site or if they're bouncing. So kind of in the combination, that's something that could be useful there, but not in the sense that we have a quality report. Would that show you URLs that are high quality or low quality? Can we expect more search queries data in Search Console maybe for a whole year? You're not the first person to ask for that. And as far as I know, the team is working on doing that, but it takes a bit of time to kind of get all of that lined up with regards to having the right data. And we need to make sure that the UI is actually usable. If you have a year's worth of data, then the UI needs to probably be slightly different than what we have now. Is the average position in Search Console based on personalized search results? Yes, it's based on whatever was actually shown to the user. So it's not a theoretical ranking that your site would be ranking for this query at this position, but it's really based on what we've shown in the past to users for those queries. Again, there's more about this in the Help Center with regards to kind of like clicks impressions and ranking. Search Console is showing us 1,000 pages in Search Analytics. What criteria do you use to decide which pages to show? The API shows 10,000 is a way to get all of these URLs. As far as I know, the criteria is essentially the number of impressions. So that's what we filter the pages on within Search Analytics. And if you're seeing more in the API, then I would just use that. I don't think there's a way to get all of the URLs, especially for really large sites. You can reduce the time frame that you're looking at to get more data that you can aggregate yourself. So if you're using the API, then sometimes that's something that's more easier to automate than if you had to do that manually. But apart from that, I don't think we would be increasing the limit too much in the UI just because it makes things so much more complicated to kind of review as a user as well. But if any of you have great ideas to how the Search Analytics UI should look to show more data over a longer time frame or more pages, feel free to create some mocks and send them to us. I promise to show them to the Search Console team and to discuss them with the folks that are working on these reports. Any update on getting voice search statistics in Search Console? No, no updates on that. It does include in sitemap.xml and robots.txt within a site-wide redirect to a new domain, have any negative effect on ranking. No, that shouldn't provided we can actually still crawl those URLs. So if your new robots.txt file blocks all URLs from being crawled, then obviously we can't crawl any of the old URLs either because your new robots.txt file is kind of the source of the content for the old domain as well. But if you're just moving everything one to one, then that's definitely an option. Any advice on how to use hreflang on a mobile subdomain using canonical links pointing to the desktop domain? Is it enough to mention the hreflang links on desktop and include a rel alternate? So at the moment, for desktop indexing, that's the right way to do it. You have the hreflang links on the canonicals and between the canonicals. With the mobile-first indexing change, we're looking into what the easiest approach is to do there. So ideally, from my point of view, we'd be able to just reuse the same hreflang links on the mobile-friendly pages. But I need to make sure that this is actually something that would work well within our indexing system. So we'll get back to you on that for the mobile-first changes. If you get a URL-type reason, severity of Google Ad Services message when using fetch, which prevents a complete render, does this have any negative effect of Google's interpretation ranking of the page's content? Usually not. So we list URLs like that in search, in fetch and render, because sometimes JavaScript files include more content on a page. In this case, this sounds like a script that just tracks conversions or just tracks clicks. And doesn't change any of the content on the page. So if it doesn't change any of the content on the page, then that's something you can probably ignore. Fetch as Google, you said regarding re-indexing, Google first looks at the HTML, then the rendering. Our mobile site is built on Angular. Nothing shows in fetch as Google HTML view. It links to some scripts. But the render shows the images and the content. Developers think this is all good, but I'd rather see the content in HTML. Are you able to confirm that this is normal with Angular? Yes, this is normal. So the fetch as Google, the HTML view only fetches the raw HTML as it comes directly from the server. We did that primarily so that you can diagnose any issues within the raw HTML view. The fetch and render view is the one where you actually see the HTML process, the JavaScript executed, the CSS loaded, all of the images loaded. And you can see what the page would look like when Google bot renders a page. If you can see all of your content there, then you should be OK. Then everything should be fine. If you don't see your content there, then probably something is broken or blocking. So I did a session at a conference Angular Connect a while back that recorded it on a YouTube video as well with regards to what to watch out for if you have an Angular website. And there are things like if you require a service worker for the page to actually load, then this is something where you should have kind of a safe fallback so that when Google bot, which doesn't support a service worker or any other browser that doesn't support a service worker, goes to that page that they'll still be able to see the rest of the content. So that's something I definitely watch. That also covers the Fetch as Google kind of difference that you're seeing here. Also, if you look at the Cache version of a page, if you require rendering for the page, then you will still just see the HTML view on the Cache page. You won't see the rendered version. But that's completely normal. A quick way to double check this as well is to do a site query for your site and some of the keywords that are only in the rendered view. And then you'll see, is Google bot able to pick that up for indexing or not? We'd like to use the URL parameter function to save crawl budget, but we found different opinions on the web. For example, we have a shirt in different sizes and colors with the same content. What should we do there? So the URL parameter tool is fantastic for something like that. Different parameters, if you can set it up for that, then that's a great way to do that. It's not the same as blocking with robots text, though. So it's not a guarantee that we'll never crawl those URLs or never index them. But if we can confirm from spot checking that we don't actually need those URL parameters or depending on how you have them set up, then we'll follow that. John, when it comes to those URL parameters, for example, if you choose that this parameter paginates something, is that the equivalent of relnext and relprev? Do you not need relnext and relprev anymore? Relnext and relprevus is probably still better because we see the direct connection between those URLs. OK. So I'd definitely keep that if you have that set up. OK, got it. Would Google consider addering a crawl snapshot that shows how many pages of your site that Googlebot managed to crawl naturally rather than how many were submitted via sitemap or index like that? We want to make sure that all of the pages are naturally reachable as well. I don't think we'd be able to have a stat on that because we collect URLs in a variety of ways. And it's not always a definitive mapping of this or that. Sometimes it's a combination. Sometimes it's a combination of multiple factors that lead to that. What I would recommend doing there is using a third-party tool to crawl your website on your own on your side because that's the fastest way you see this happening. So there are some fantastic tools out there that let you crawl your site. Screaming Frog is one of them that I've heard a lot about, that people really seem to love. And they seem to do updates all the time, including stuff for rendering as well now. So that's one I should check out and see if that works for you. Google announced that starting in January, intrusive interstitials may not rank as highly on mobile. My site closes every weekend with a modal dialogue. Will this be a problem? So we make exceptions for legal dialogues when it comes to interstitials. And we would include this as well when we see that happen. So from the interstitials algorithm point of view, that's less of an issue. However, I would recommend also making sure that this doesn't cause problems for search. And the easiest way to make sure that it doesn't cause problems for search or for the interstitials is that you return a 503 result code for these pages when that situation is live. So returning 503 tells us this is temporarily not available. We won't index any of the content that you show, that you show to users, and we'll come back after whatever time you specify and double check to see that we can actually index some content again. So this way, you can tell us to skip that interstitial day and to come back a bit later. There's a limit to the time frame that you can use a 503 before we think it's a permanent error, but that's more on the order of a week than a day. So if you do this one day a week, then that's essentially fine from our point of view. John, may I have a question? Sure. I was asking you about chat, but we didn't really came to a conclusion. So if I have HTTPS dot, dot, dot domain, and when I have a property is HTTP dot, dot, dot, HTTPS non-dot, dot, dot, dot, HTTP non-dot, dot, dot. All of them are redirected to HTTPS dot, dot, dot. Free properties should only show if there are any errors or penalties or things like that. But no other data is based on what to release URLs appear in Google. And they would not appear if they are redirected, right? Usually, yes. So we show the data for the canonical. And usually, we follow things like the redirect and the rel canonical for that. Sometimes there are differences. So if you mess up the redirect or if you just recently redirected, then sometimes you will still have some data on the other version. But no, no, I mean from a brand new site which was redirected from start. Yeah, that should be fine. So those I just keep and check for errors and nothing else. Yeah. OK, and another one, because nobody asked for now, it's about the backlinks of a Google console that are reported. Can you please tell a bit what kind or what person or what kind of things I can find there? Because I am using them to find the backlinks to a domain that was no longer used, a subdomain which was no longer used. And I kind of want to know if checking those links, I would probably find all or most sites linking only a fraction or can you please tell a bit what appears and what not? We don't have any strict guidelines on what's shown there and what's not. Essentially, it's a sample of the links. So for smaller sites, it's probably more closer to all of the links. For larger sites, it's definitely a sample where we try to show the ones that are more relevant. It doesn't take things out that are no follow. It doesn't take things out that are in the disavow file. So it's more a matter of we know all of these links exist to your site and here's what we think is a relevant sample for you. Are you sure that it doesn't show no follow because it was showing me some of those no follow links? It doesn't remove no follow. Sorry, I said that wrong. It doesn't hide the no follow links. It doesn't hide the disavowed links. So it shows all of them or. OK, so you said for the smaller site, it would show almost all. Define the smaller sites. So a few thousands, a few hundreds, a few tens of thousands. I don't know where we would draw the line there. But it's something where we have a limited storage available for these links within Search Console. So at some point, they just get cut off. OK, thanks. John, what is the if you had to sum it up, what is the reason for showing site owners links to their site? You mean you shouldn't? No, well, I asked you. No, I'm saying you should. But it seems interesting that it's in the kind of ranking section of Webmaster Tools. Or how your site appears on the web. But if you're strictly speaking showing no follow links, it seems a little suspicious that you even found them if you're or found the site. If you're going through them anyway and therefore ignoring the no follow. So that would suggest it's probably not about ranking. But what does Google think the website owner benefits from seeing those links? What are they going to go and find out? What's the benefit or purpose of it? Yeah, so I see people like it in case there's bad ones. Yeah, I mean, on the one hand, there is a situation where you did something crazy and you hired an SEO to build links in a really sneaky way. And you want to clean that up. So that's, I think, the one way to kind of get diagnostics information there. The normal case is more a matter of these are people that are linking to your site, that have you referred to your site. You kind of see how your site is evolving within the context of the bigger web over time. So that's kind of the original thought behind that. There were also ideas of turning that into something like a timeline where you see the links over time, how your site has evolved over time. But it's something where we think this is more useful with regards to these are sources of traffic to your site rather than you need to optimize these to improve your site's ranking. John, is there any kind of priority in that case? So I mean, when we kind of analyze all those links, there are certainly a lot of the really spammy ones that are a lot of the XYZ domain type of stuff. They're not there at all. It almost does seem that it's not just a random decision as to what links you show and what you don't show. It kind of does appear that there's almost like a conscious decision that's being made to show the important ones, good or bad, versus links which are clearly just nonsense. Is there something like that going on in that case? Yeah, I mean, we try to show a sample of the relevant ones. So we think these are the ones that might be interesting to look at. And that's kind of what we showed it. So I could imagine some of the really spammy domains end up dropping out, at least for larger sites, for smaller sites that might only have links from some of those spammy domains because they just happen to get included in some pretty spam run. We will still show those. OK, and just to confirm something else, we had an email conversation about this a while ago, but just to confirm, a lot of people would look at the data in the links to your site and kind of think that it's quite out of date or it's not quite right. But just to confirm that that is actually an accurate representation of what is in the index or in your link graph at the time. And yes, if pages get removed and they have links to your site, it can sometimes take a while for those to actually generally be removed from the index or from the link graph. But if they're shown in Search Console, they really are actually being considered by Google at the time. And they might get like a low relevance if they've kind of been removed or they've been 404 and Google's kind of just waiting a bit of time to make sure they don't come back again. That is the situation still, isn't it? Yes, that's correct. Thanks. All right, let me just see. There seems to be some discussion happening in the chat with regards to HTTP and HTTPS when the sites are not the same. Is that cleared up pretty much? Or otherwise, yeah. This was a discussion whether other reports than Search Analytics in the case where you have HTTPS version with the HTTP using a canonical to the HTTPS version, whether other reports than Search Analytics will show differences. And from what I know, for example, like crawl information would show a difference. It would show many less pages being crawled than the canonical property in Search Console. So it's not going to be the same everywhere. I know penalties are being shown the same everywhere, but things like errors and crawl information are particular to that specific property regardless of canonical. I don't know for sure. That's a good point. I think some of the reports do combine it, like you said, like the manual action section. And some of them split it out separately. I don't think we have that clearly flagged in the UI to make it possible to kind of like, no, I'm looking at only HTTPS, and the HTTP version is completely separate. But that's a good point, yeah. Well, I know that in my Search Console account for my site, it does show different values. I'm using a redirect, not a canonical, and the HTTP version is showing many less pages being crawled than the HTTPS, which is the canonical one. So I assume that's why. That's good. Perfect. Is that because you're using a redirect, not a canonical, or redirect and a canonical? It's probably when we switch to the canonical URL. So we'll try to focus on the canonical versions for crawling and regardless of how we pick that up. And just to clarify something I said in the chat, are you for HTTPS, are you really only considering that any kind of ranking factor if it's redirected rather than canonical, or is it either now? Because I know previously you said if it's forced, then it's more likely to be. We focus on the URL that's shown in the search results. So if the URL in the search results has HTTP, then it has that thing. And that doesn't matter if we pick that up just because we happen to find a link to that version or if it has a canonical or a redirect. Kind of the reason why we index that is irrelevant for us. By the way, John, do you recommend any tool for that automatic backup? Or? We have a nice tool. Yeah, I think you should check it out. I don't know. So I have my own Python scripts that I kind of jumbled together that run every now and then. But there are some other tools as well where you can kind of include search console data within a bigger view of your site. But I don't have any details of something that I could share. That might be something where if you know of a tool like this, maybe drop a link in the Google Plus post for the event so that people can take a look there as well. I mean, but nothing officially recommended or supported by Google. Well, nothing officially supported by Google. I mean, it might be using the API in an official way. And that's perfectly fine for us, but not in the sense that we would say this is created by Google and supported by Google. So from that point of view, it's not something that we have like a list of the API tools that are available. OK, so let's take with me. Yeah, I think he just has the advantage of joining these Hangouts. And that's how I know about this. All right, we've come to the end. Can I ask a quick off-topic question? Sure, go for it. I have a Google news site. And in mid-November, a lot of us started noticing some really strange things going on. We don't show up in the search results page on desktop, but we still show up in mobile and things like that. And I was just wondering if you had any insight into what might be going on there. I don't know how Google News handles that. So the Google News algorithm is separate from the normal web search algorithm, so I don't know what they would be doing there. OK, all right. All right, so we're kind of out of time. I think someone else needs this room afterwards, so I need to cut off here. I'll set up the next Hangouts as well. I might set some up for next week as well if any of you are around or anyone else is around. For sure we'll be around. It's important you to be around. OK, great. Then maybe I'll set one up for next week. That sounds like a kind of fun holiday distraction in between. Remove what may be, and we have a deal. All right, OK, so with that, thank you all for joining. And we'll see you all again in one of the future Hangouts. Bye everyone. Thank you for hosting us. Thank you.