 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 webmaster office hour Hangouts, where people can join in, ask a bunch of webmaster web search related questions, and we can try to get some answers back to people. As always, if there's anyone who's kind of new to these Hangouts that wants to get started with the first question, feel free to jump on in now. If not, I'll just jump to the questions that were submitted. Come on. I've got one question. So this is really around. I know there's been a lot of talk of late about doorway pages. Seems to be doing the rounds a bit, again, and location pages. So there's a little bit of gray area between what actually is a doorway page and what is a location, a valid location page for, say, a site with a directory that's got lots and lots of different services, et cetera, listed in there. So this is a scenario. Say, for instance, because of mobile now, historically, you might have had all the areas where the services are available listed. But obviously, that means that on mobile, that page could become huge and unwieldy, et cetera. It's not a good experience. If you add a kind of a dropdown and, say, view all areas, but then links through into a page, which has all the areas, but then you no index that page, so actually it isn't just there for the purposes of spewing out potential links through to all the others. And it's really more from a user experience perspective and navigation. And then you link out from there into the areas. That isn't perceived as a doorway page if it's no index, is it? Or is it? Well, the doorway page would be if you have a large collection of pages where you're just tweaking the keywords on those pages for that. If you have one page that links out to a bunch of other pages, then that's, I don't know, just kind of a site map page, something like that. But that's just a good navigation experience, potentially, isn't it, to make sure that actually people can then go off and find the area that they want rather than. There just seems to be quite a lot of confusion around this area thing and doorway pages. And I saw that Shaun did a post. Shaun Anderson did a post. Oh, Shaun, yeah, I think he is. Did a post around location pages. And I know it's quite a difficult area to get me, because today it's worth reading, actually. OK, I know it's a funny one. And I know that in the past, there's been a lot of sites that have just literally just had the odd keyword here and there changed. And they're literally just spinning out the same content. But with just the location name, no added value. So it's that, really. And there's obviously the danger that you're worried about doing that. I think if you focus on a clear purpose for the page that's outside of just I want to rank for this specific variation of the keyword, then that's usually something that leads to a reasonable result. Whereas if you're just taking a list of keywords and saying, I need to make pages for each of these keywords and each of the permutations that might be for two or three of those keywords, then that's just creating pages for the sake of keywords, which is essentially what we look at as a doorway page. OK, thank you. All right, Barry, you have a question. Yeah, so you guys came out with this selfie video thing where you do a search on mobile and celebrities sometimes give you these answers. And obviously it's partner-based. But is there a bigger picture to that? Like if you ask an SEO question, your face will come up and answer it. I'm not aware of that. I mean, I saw the video stuff coming out. But I don't know what the details are behind that. And I don't have any plans on being visible as a question answering service in the search results. But I don't know. Maybe that's something that will come up in the future. Cool. And is TLS version 1 versus version 1.2? Obviously, the deadline for all the payment processes are coming up very soon. Is that something you just recently started sending out, those notifications in Google Search Console? And has Google updated them, their older properties, to TLS 1.2 that you're aware of? I'm pretty sure we have everything on TLS 1.2 or whatever the most recent version is. We sent out, I think, for a bunch of different HTTPS-type issues where people have the configuration wrong, we sent out these kind of messages. I don't think it's just like you're using an obsolete version number. But as far as I know, also like variations of the certificate you have it set up wrong, or you're using it wrong, these kind of issues. And we've sent out some of those in the past. But I believe we added a bunch of new messages just to kind of make sure we have all of the common issues covered. And these have no impact on your rankings. It's just a notification to webmaster to say, hey, you should be aware of this. Exactly, yeah. So since it's technically still a valid HTTPS page, we would probably still index it as HTTPS. So you would have the normal ranking, the normal URL in the search results. You're just serving it in a way that is not really secure. So it's something that you could improve on. All right, let me see what we have lined up with the questions that were submitted. Can I ask you one more question, please? All right, go for it. Thank you. Recently, I've noticed I work as an SEO specialist for a web development company. And regarding our clients, I've noticed in the last maybe two or three months, whenever we make a change to page titles, whether it be a new page title or domain change, or whenever Google notices a change that affects page titles, it will automatically add brands of the website, whether it be the domain or the brand itself, at the end of the page title with the dash and then the title, the brands. Even though the title includes the brand, usually behind the pipe, the vertical line. So I know that Google has been doing it for some time now. But it's been on and off. I don't know. I've noticed it a couple of times, but nothing continues. But now, anytime we make a change, Google adds the brands. And so we don't really want to do whether it's something that's going to stay or just some testing phase. If you could give me some info about it, please. That would be awesome to know what to do next. I'd love to see some examples like that. OK. So send you the URL of the website into the chat. Yeah, so of the website or search results pages, where we're really kind of seeing that. I think with a site query, you have to be careful, because a site query is kind of artificial. And the titles there aren't really representative of what we've shown normal search results. OK. But if you have something like a normal generic search and we're showing your brand name twice, like in the site query where you see the changement and dash. Name of our brand. If you search for this, this is our company website. So the second message, the app from digital, if you search for this, you'll see that there's a brand behind the pipe and then there's dash and there's a different brand. That's not even ours. It's just the name of the website. It's BD. I think you should find it. All right. I'll take a look at some of those. So that's something. I know the titles team is working on that to try to improve the speed and the quality of the titles. And when we get it wrong like that, usually it's a matter of waiting until things settle down. But it would be nice to kind of catch these a little bit ahead of time and to avoid a situation where you kind of have this bad title and the search results. Because the first website I sent you, we changed the page titles in September, I think. And so then we noticed after like two or three weeks that there were additional brands, brand names. So I tried to request a re-indexing in Search Console, which did nothing. I hope it could result things. We even checked whether it could be like a CMS thing. It's not because the titles, the brand and the titles are at its manually. So it's not given the title. Yeah. OK, I'll take a look at those. OK, then we'll put you back. Thanks. All right, let me. Don, sorry, do you know on that point? Do you know on that point? And I don't want to try and say something. Sorry, I didn't know what that chat's name was. I didn't catch his name, the one who was just. Oh, is it me? OK, I'm Nick. Hey. Hi. I don't, obviously, I just know that a lot of CMSs automatically add the brand at the end of the URL, even if when you, I know, I'm sure you know that anyway, but it's just like lots of Drupal and WordPress. And a lot of them literally just add it on anyway, just regardless of what you enter into the page title build. But I'm just. What we thought was happening at first, but we took a look at it and we thought, well, this is not it because we disabled all the rules that would add brands towards the end. And even then, it's a different brand that it would do CMS ads because it's not even the name of the company or anything. Ah, OK. All right, I'm just thinking. I don't think I'm trying to say what you're doing because you don't. I think part of the problem is also the umlaut and that you don't have that in the domain name. But that's something that we should get right. That's not something that you need to artificially tweak. Yeah, and not just this website, it's usually, well, I think it was like four or five websites in the last two or three months that we made any changes on. So it scared us a little bit because it's not something we have control over and so I'd like to. OK, cool. I'll take a look. Thanks. All right. So let me run through some of the submitted questions. And I see there are some questions in the chat as well. I'll have more time for kind of the live questions during or towards the end as well. So the first question is, we migrated from HTTP to HTTPS and everything looked OK and now suddenly it looks like the number of index pages dropped significantly. What could be the problem there? OK, it also mentions that they had the wrong sitemap file submitted for a while. So usually this is something that is more of a technical issue with regards to how we count the index pages. So especially if you're looking at the index status report in Search Console, that can kind of be misleading a little bit in the sense that we include everything that we know from this website. And over time, as we reprocess all of those URLs, we recognize that some of those URLs are actually duplicates that we don't need to keep them all. So that's kind of a normal transition where you move from one domain to another or to HTTPS and we index a whole bunch of pages. And then over time, we reprocess everything when we recognize, oh, actually we don't need to have all of these pages indexed separately. So we just index like one version of this page. So that's something where you kind of expect to see a little bit of a bump there as things settle down. The better way to look at the number of index pages is to use the sitemap file like you've already been setting up there and to see what kind of changes happened there. And with the sitemap file, you can also go granular. You can say, well, for different parts of my site, different logical sections, I'll set up separate sitemap files. And then you can see for these individual parts how the indexing there actually works. And with the new Search Console that's coming out or that some people already have access to, you also see a little bit more information there and you can also look at it per sitemap file. So stay tuned for that. Our robots.txt file disallows all our sort pages. However, all of these pages don't have a no index on them. And they do have a canonical tag. Are we wasting our crawl budgets? Or is there anything that we need to do? So if these URLs are blocked by robots.txt, we don't look at them at all. So we don't know if you have a no index tag on there or a rel canonical or anything. So from that point of view, what you have on these pages is actually irrelevant for us. I don't know if it's the best practice in your situation to actually block all of these pages. For some sites, it makes sense to block these kind of faceted navigation pages for other sites. It makes sense to let us crawl through those and use the rel canonical to find the right ones or to use the parameter handling tool in Search Console to explicitly tell us these parameters are irrelevant. So that's something where I double check what you're doing with your specific case and double check the help center for information on faceted navigation, which might give you some tips on what you could be doing there. In general, this is not something that would be a critical issue if we can still crawl your normal kind of paginated pages with all of the content. And I think that goes into your next question, which is kind of on the same note. We're showing a list of our products. We use rel next and rel previous and rel canonical to a view all page, kind of like we recommended. So obviously, you're finding our documentation, which is great. But we think it would be better user experience instead of a view all page to kind of point to the first page in the list. So from my point of view, that's something that you can decide. The important part for us when it comes to kind of these listing pages is that we can find all of your products through some form of crawling through your website. So if all of your products are linked in individual categories on the first page of these individual listing pages, then we can probably find links to those products, and that's probably OK. On the other hand, if you have one giant listing page, and that's where you list all of your products, and some products are only listed on page 2 or page 3, and you have a rel canonical to page 1 from there, then probably we're not going to find that link to those individual products because the rel canonical keeps telling us, ignore all of these page 2, page 3, page 4 pages, and only index the content and the links from page 1. So depending on how you have your website set up, that might be OK or it might be problematic. And that's something you'd probably want to double check on your end. You said in a previous Hangout that spam reports get ignored. So what's the point in highlighting offenders to Google? We have competitors who are spamming, and yet you don't take them out of the index. Kind of rephrase slightly. From our point of view, we do take spam reports into account. We do try to process them as much as possible. We can't guarantee that we kind of look at and take action on every single one, though. So that's probably what you've kind of heard there. It's not that we ignore them completely. It's more that we try to figure out which ones of these spam reports are actually ones that are critical that someone manually reviews and takes action on them. And when it comes to taking action on sites with regards to web spam, it's not always the case that we remove sites completely from the search results. If we can isolate the spammy behavior and just take that out of account, then I think that's a generally good approach to take. So what might be happening in your situation is that your competitors are ranking despite doing all of these spammy things and not because of all of these spammy things. And that can definitely happen, that a website that's otherwise really good, that we'd love to show really high in the search results, does all of these spammy things, which we start to discount, which we don't take into account. But overall, it's still good enough that we say, actually, it's a pretty good result just based on the useful signals that we have from this website. So we'll continue to show it in the search results, maybe even fairly high in the search results. So from my point of view, what I would recommend doing there is definitely submit spam reports. If you run across issues that you think might be problematic, the web spam team does appreciate these reports. They do take action on reports that they find are critical to take action on. But pass that, avoid focusing too much on your competitors and instead think about what you can do with your site and what you can do with your site to significantly move it forward. So that would be my advice there. It's not as easy as kind of going to Google and saying, hey, can you take out my top competitor so that I can rank in their place? You really need to put in that work as well on your site to make sure that your site is significantly better than those other sites that are out there. We added a no-index tag to pages with thin content for better search engine performance. But we're not sure if it should have no-index, no-follow, or no-index-follow in the meta tag. What should we do here? So in general, if you're aware of low-quality content on your website, our first advice is actually to try to improve that content. So you put that content out on your website for some reason. So instead of just saying, well, I didn't manage to put something useful together the first time, I'll just have search engines ignore it. Maybe it makes sense to actually think about what you initially thought you wanted to put out there and actually make sure that you have something useful out there. Because we prefer actually having something useful and great for your website than not having anything at all. So that's kind of my first advice there. If you do choose to put no-index on these pages because you know you can't improve those pages and you feel you don't want to remove those pages completely for maybe user experience reasons, then a no-index is essentially a sign that tells us to remove this page from our index. And with that, over time, we'll also remove any of the links that are associated with this page from our link graph. So whether you have no-follow on it or follow, essentially in the end, it comes out to the same thing. We remove that page from our index. And with that, we drop all of the links that are on that page. John, can I ask a question on that point? Sure. I'll be quick. You know, when people just no-index, no-follow a page that maybe has had quality issues historically, yeah. I was reading quite a bit of stuff recently and based on a few things that you've said about historical quality signals building up over time, yeah. And I kind of have this theory that maybe things are based on a rolling average of, you know, each time crawling happens, maybe it's various scores and link graph, everything gets added up. And maybe the score goes up for this URL, yeah, a little bit. I know it's not as simple as that, but it seems like there's a kind of these rolling scores that either get worse or better over time when you've got an aged URL. So if somebody no-indexes, no-follows, that score of that URL effectively can't change. It can't go better. It can't kind of go worse, but it could. But so it's actually, there's no benefit to all from literally just blocking. Is that right? Or does that kind of sound sensible? Everything's constantly being updated, isn't it? With averages. It just feels like there's like this rolling average that goes up or down for a URL. I don't know if you could simplify it like that, but these are signals for a large part that need to be collected over a bigger period of time and that need to be aggregated together somehow. So it's not like, I don't know, an average of everything that we've seen so far is really a matter of collecting a whole bunch of signals and trying to fold that to individual pages. I'm talking about compared with, you know, you've got the historical data for a URL, yeah? I'm talking about a URL and it's singularly compared with the last crawl, yeah? So effectively, signals of, oh, this is getting better or this is getting worse or this is just still rubbish, yeah? If it's kind of no index, no followed, that can never change then. You can't sort of, you can't pass any positive or negative signals, but still, you see still an overall bad quality associated with the site, if you look at a site. Oh, okay, I see what you mean. So basically, if you remove low quality pages, does that actually have an effect? What I'm saying is if you block low quality pages but the signals have already passed historically and you then don't allow them to be crawled, yeah? How can the positivity of that be passed as such? So positivity of the page not existing anymore. I mean, this is something that happens as we recalculate, reprocess, essentially, all of the signals for the web, which is something that happens on an ongoing basis. So if we look at the overall picture and we start to see that overall, this website is actually pretty good, because overall, the picture that we know now is actually pretty good and we don't know about this part that was actually problematic, then that's a good sign. So it's not the case that you're stuck with a bad website just because you had some low quality content on it. It's really a case that as we can reprocess the whole website and see what is really on this website, what is indexable on this website, then we can take that into account for the website in general. So that's something that it's not that it's passing a negative signal and you remove the page and therefore that negative signal is kind of like within all of these signals that are flying around. It's really something where when we reprocess things overall, then we don't know about this bad page anymore because it's been out of our index for a while, then it doesn't cause any problems anymore. Okay, so no indexing, no following kind of cuts it off effectively after a period of time. Yeah. Okay, yeah, okay, thank you. All right, so here's an interesting question. Are there any best practices regarding an ad block deactivation banner? So for example, when a user visits a site and they use an ad blocker and they get a banner that tells them to deactivate the ad blocker so that they can look at the site in order to not look like cloaking should Googlebot see the banner or not? I think this is a kind of a tricky question to answer because in general, Googlebot won't load ads either because they're blocked by robots text. So depending on how you're trying to recognize an ad blocker, you might think that Googlebot is also using an ad blocker because it's not loading those ads. But from a practical point of view, you also don't want Googlebot to load those ads because then suddenly the click-through rate on your ads will be really low and that might be a bad sign. So that's sometimes a bit tricky. In general, when it comes to what Googlebot sees or doesn't see, we expect that Googlebot sees what the average user, when they first visit your website, sees as well. So if the average user sees a big banner on top that's saying we don't accept people who are using ad blockers, then that's something that Googlebot should see as well when it renders a page. So that's kind of the general point of view that we have there. I suspect for most sites it's not the case that the average user has an ad blocker and therefore Googlebot would need to see this as well. But it's something to kind of keep in mind. In general, when it comes to these kind of banners or kind of interstitials that you have there, if you're uncertain if Googlebot might see this and you really want to make sure that your content can be indexed normally, I'd recommend using a kind of a banner on top rather than blocking the whole page so that you can be sure that Googlebot can at least see the rest of the content there and use that for indexing as well. And another thing to do there is instead of redirecting to kind of an interstitial page, a common interstitial page, and then redirecting back to somewhere else, it probably makes sense to kind of put this interstitial or banner or something on the same URL so that you don't have the issue of Googlebot being redirected to this other page and then thinking, oh, all of the pages on your website are actually this interstitial page. Therefore, we'll only index this interstitial page and drop the indexing of all of the other pages. So those are a few things that can kind of come together there. That's something which I think for some sites might be kind of tricky to implement and double check. So if you're interested in setting up this kind of a banner and ultimately, that's your decision, I'd really make sure that you have the technical details right, using tool like Fetch as Google to render your pages and double check what Googlebot actually sees and ideally also monitoring what is actually happening there so that you don't accidentally run into a situation where you're showing Googlebot only your interstitials and none of your content is actually indexable anymore. How often does Google crawl a sitemap and does it crawl the entire sitemap? Once it starts, we're launching a new sitemap for our site which will contain 2 to 3 million URLs and we want to make sure that the sitemap won't take all of our crawl capacity. So a sitemap file helps us to understand which URLs on your website are new or have recently changed. So in the sitemap file, you can specify a last modification date. And with that, we can kind of judge as we need to crawl next to make sure that we're not behind in keeping up with your website's indexing. So if you have an existing website and you submit a sitemap file and the sitemap file has realistic change dates on there, then in an ideal case, we would look at that and say, oh, we know about most of these URLs and here are a handful of URLs that we don't know about. So we'll go off and crawl those URLs. It's not the case that submitting a sitemap file will replace our normal crawling. It essentially just adds to the existing crawling that we would normally do. There's a lot of talk about expanded meta descriptions, but people are split on whether or not SEOs should update existing metas or let Google expand them for us. What's your take? So I saw some discussion around this. I don't know what people have been discussing. So in general, one of the things we've been experimenting with are showing longer descriptions in the search results. And I believe that's something that more and more people are seeing. So for the descriptions that we show, we try to focus on the meta description that you provide on your pages. But if we need more information or more context, based on the user's query, perhaps, then we can take some parts of the page as well. Essentially, from a purely technical point of view, these descriptions aren't a ranking factor. So it's not the case that changing your descriptions or making them longer or shorter or tweaking them or putting keywords in there will affect your site's ranking. However, it can affect the way that users see your site in the search results and whether or not they actually click through to your site. So that's one aspect there to keep in mind. And with that aspect, sometimes it does make sense to make sure that the description that you're providing to search engines that's perhaps being shown to users when they search for normal things on your website, that that description is something that explains what your service is, what your page offers, maybe the unique proposition that you have on your page that kind of encourage people to click through to your page. That probably makes sense for a lot of cases. And sometimes it makes sense to say, well, I know how to describe this best. Therefore, I'll write it up in the description. And if Google can show this, then I hope that people will see my site as being clearly superior to all other ones and click on my site rather than some of the other ones that are ranking in the same search results page. So with that in mind, it's not a ranking factor. It can affect how your site is visible in the search results. So with that, I definitely see it as something legitimate where you might say, well, I want to make sure that my proposition is out there in full. And therefore, I'll try to write something a bit longer and show that in my meta description. One thing to kind of keep in mind there is that we adjust the description based on the user's query. So if you're doing a site query and seeing this in the search results for your site, that's not necessarily what a normal user would see when they search as well. So make sure to check in Search Console and Search Analytics what the top queries are that are leading to your pages. And try those queries out. See what your site search results look like. And if you want to change the snippet that's shown for your site, for individual pages on your site, then all means go off and do that. John, very quickly on that point, if for instance, I've seen a lot of e-commerce sites that obviously have had issues in the past. So for instance, with too many indexed pages and they wanted to shorten click paths, and they are canonicalizing subcategories to categories. And then often, it's just the subcategories items it's very difficult to always get the category itself to rank because the meta description doesn't get the click through because there's not enough relevance to all the products and subcategories in there. So that actually might be a case where Google might pick up on the fact that there's a lot of these subcategories are included in this category. And whatever somebody then looks for, if it's included in the page, that may become part of the meta description. So say somebody's looking for red shoes or red high heel shoes, and they've been included in the shoes. Somebody types in red high heel shoes and it's there in a big massive category page. That may be then almost dynamically included in a meta description auto-generated. That is that the kind of scenario? Yeah, yeah. And that's something that can happen. And if you look at the search results page and you're saying, well, this is a terrible snippet and like nobody's going to click on my site because it looks like, I don't know, it doesn't make sense or it's anything like that. Or even if it's just like you're saying, well, this is not the way that I want to represent my site in the public, then that's something that you can change with the meta description on the page. And obviously with e-commerce sites or with kind of these auto-generated listings pages, that can be really tricky in that you can't like handcraft meta description for every possible variation that you might have on your site. Sometimes you just need to bite the bullet and say, well, I can't craft it here, but I can do it on my product pages. And maybe depending on which pages actually get traffic from search, you can kind of pick and choose and say, I'll focus on this, or maybe you'll realize that actually fixing this in the code for my CMS would have a big effect on my traffic to my site because these pages get a lot of impressions and really low clicks, then maybe that's something that you want to kind of invest developer time in and say, well, I need to find a better way to provide descriptions so that they can actually be shown in search. And a lot of pages now rank for hundreds of keywords compared with historically, don't they? Because they add a lot of content. Generally, there seem to be like a trend towards bigger pages, flatter architectures, et cetera. So I should imagine a bigger method description gives an opportunity for a lot of those different options to be found as such by you. And to match queries as such, really, if they are dynamically populated. Now, I mean, it's really something you have to look at the search results directly for your site and think about where you want to spend your time. And again, this is not a ranking factor, but it can affect how people click through to your site. And that's something you kind of have to judge. And you have to think about, well, I'm already ranking number one and everyone's clicking on my search results. Like, why do I need to spend time crafting an even better meta description? But maybe there are other pages on your site where you're seeing I'm ranking number three or four and I have a really terrible click-through rate, then maybe improving that click-through rate will get you more traffic. And even if you stay at the same ranking position, then that's kind of a win. OK, yeah, I can see it. Yeah, thank you. All right, let's see what we have in the questions. If a website has a long history of being a media publisher, is it difficult for them to cross over to transactional intent pages? Meaning if a website has established a long history of informational and is bucketed into that space, can they cross over and expect a ranking boost from their authority? Or must they prove their transactional content is worth outranking other transactional websites in its space? So in general, we try to look at the website overall. And that's something where we see all of the current status. We see what we've indexed over time. And we try to take that all into account. And it's not the case that Google will say this is purely an informational website and this is purely a commercial website. And we'll never kind of mix queries across those two. Sometimes that happens. Sometimes that changes. Kind of topics within a website. They shift over the years. And that's perfectly normal. That's not something where I'd say you need to kind of close the old website down and start a new website out, just because you're going away from pure informational to maybe providing some products for sale as well. So from my point of view, that's kind of a normal change in a website over the years. And these kind of shifts, they happen all the time. Google seems to like pages that give the visitor the ability to jump to further, maybe deeper information. However, there are archive pages that may list an excerpt of pages, which most of the people said just to set to noindex. I wonder if it would be good to have JSON-LD saying it's a collection instead of setting it to noindex. I think this is probably something where you can't, by default, always say these kind of archive pages or tag pages need to be set to noindex. That's something you might want to look at on a case-by-case basis and think about how you want your content to bubble up in search. So particularly if you have a blog and you have a lot of comments on your blog, then the individual article pages will be, on the one hand, your article. On the other hand, all of the comments that are available there. And all of this comes together as one piece of content. And if your archive page shows your own article, then that's kind of like a part of the full content. It's not actually the full content. And especially if your archive page shows an excerpt from your actual article, then that's an even smaller part of your page. And from that point of view, those pages are very unique and very different. And from my point of view, I wouldn't necessarily always just set them to noindex. That's something where maybe it makes sense to keep those indexed. Maybe, maybe not. It really depends a bit on your website and how you have that set up. With regards to noindex versus JSON-LD or schema.org markup saying it's a collection instead of a page, noindex is really a strong signal for us telling us that this page should not be indexed. So it's essentially a directive telling us when we process this noindex, we should take this page out of our index and not show it to users. So that's kind of a really black and white signal that you're telling us there. Whereas, if you're using JSON-LD schema.org markup to say, well, it's not a page, it's a collection, then that's essentially telling us it's a normal web page. And we need to figure out how we want to rank this in general. So that is very different things. You can't compare just setting a schema.org kind of type for a page to a noindex. They're very different things. So that's something where I would think more of, do you want this content index or not? And if you do want it indexed, then maybe just let it be indexed. Or if you can provide additional context through schema.org markup and you want something indexed, then that might make sense to put on there as well. I suspect we wouldn't treat collection pages or markup with collection information on them in any way different than normal HTML pages. So that's kind of, I guess, a different, almost more philosophical question, like how we should treat schema.org markup when we see if it's flagged as a web page or as a news article or as a collection. I think that's kind of tricky. Hi, John. Hi. I want to ask you about AMP. How should I link from an AMP page? Should I link out to other versions of AMP other pages? Or should I link to canonical version of the internal pages? What's the best practice here? Yeah, so you can do both. You can pick one, at least, and maybe not both at the same time. But pick one and go with that. From our point of view, it's really more a question of a user experience than anything else, because the AMP page has a rel canonical set to the desktop or whatever your canonical page is. And for us, we focus on crawling and indexing the canonical version. So the canonical one is the one where we look at the links form. And the AMP version, the links that you have on there, they're essentially just how users interact with your page. And maybe you have a really good AMP setup on your website, and you want them to stay within the AMP pages, that's fine. If you say you're not really sure or you prefer to have them kind of go to your mobile site where you have, I don't know, maybe a different navigation or other ways of monetizing or whatever, then linking to the other mobile pages is also fine. What I wouldn't do is link to the desktop pages from the AMP pages, because that kind of is a bit confusing for people if they go to a really fast and sleek mobile friendly page, and you link them to your desktop page, which is kind of problematic on a mobile device. So that's essentially up to you there. OK, thanks. Sure. All right, can having geolocation specific content or using it on mobile help with your Panda score if it helps improve the user experience? I'm not really sure how you mean geo-specific content. So some sites, what I've seen them do is try to recognize where the user is and to display something additional that's specific to that location. So you could imagine, for example, a weather site saying, well, it looks like you're in Zurich, therefore I'll show you the Zurich weather by default. And from our point of view, that's perfectly fine. That's something you can do. That could be something that adds value to your pages, so it might be a good thing. The thing to keep in mind is Googlebot generally crawls from California, from the US. So if you replace all of your content with that geo-specific content, then Googlebot will always see the weather, in that case, for California and will never realize that actually you have a global website that offers the weather for all places worldwide. And that might be a problem with regards to ranking, because suddenly you always show up number one and you snip it and your title and everything kind of matches California weather. And that might be a bit of a confusing state to kind of be in. And you wouldn't be able to rank for maybe the other locations because you only see the California weather when Googlebot crawls. So the general advice there is to have a significant part of your site that's general. That's something that's valid for users everywhere, which is something that Googlebot would also see. And then some part of your site that is specific to the user's location if you want to do something kind of user-specific. And that way, Googlebot will always have this kind of general part to fall back on, in addition to perhaps the California weather as well. But at least it'll have this general block of content that's valid for all users worldwide. And that way, we can kind of make do with some of the localization work that you do there as well. And with regards to the quality of the website overall, that's essentially up to you. If you feel kind of providing more local information to users, add significant value to your pages, then by all means do that. That's something I wouldn't hold you back on. And the same applies there for personalization. That's right, isn't it, John? So for instance, if somebody served personalized content based on last visit, blah, blah, blah, you need to have a significant section, a portion, that is more general and targeted at your theme overall. Exactly, yeah. I'm just needing some clarity around connecting apps to web pages. So web pages, deep link to equivalent app pages, AMP pages, canonical to the web pages. Does AMP also get deep link to the app pages? So I assume these are the mobile app deep links. I don't know what they're called nowadays, but with app indexing via Firebase, as far as I know, I don't know for sure on this. So what I would do in this case, if this is really with regards to the Firebase app indexing linking, I would first off go to Firebase. They have a support section where you can submit support questions and try to get an answer directly from them so that you're sure you have the official answer. From my point of view, as I understand it, everything kind of rotates around the canonical page. And the AMP page is tied to the canonical page. And these app pages are also tied to the canonical page, but it all rotates around the canonical page. So the AMP pages have a rel canonical back to the canonical. The canonical has a rel AMP HTML to the AMP page. The app page also canonicals back to the canonical. And has a link from the canonical page back to the AMP page so that we know these pages belong together. So it kind of all rotates around the canonical and that everyone links to the canonical and the canonical kind of confirms that link back. So it wouldn't be the case that you would also kind of need to tie AMP into that, because we already know through the canonical that this app page is connected to the canonical page and then from there is connected to this AMP page. So that would essentially kind of build that connection between those pages as well. You wouldn't need to do that manually. Some sites choose to go AMP only in that they have all of their canonicals also AMP pages, and that's perfectly fine as well. In a case like that, of course, the AMP page is the canonical page, and then the app would have the canonical back to the AMP. They all sound so similar. I hope that was not as confusing as me saying it. All right, cached versus fetch and render. I have a couple of pages that rely on JavaScript to fully render. It looks perfect in Search Console, fetch and render. However, the cached page shows an incomplete page. What's up with that? Which page do I trust? So the cached version of the page is essentially the HTML page that we have picked up from crawling. It's not the rendered page. And what sometimes happens is we can process JavaScript on the cached page when it's in the context of this cached URL. So it's, I think, on Google user content.com. When it's in context of that, we can still process some of the JavaScript with regards to the cross-site scripting rules in the browser. And we can process some of that, but we can't necessarily process everything. So especially if you're doing requests to your server, then it might be that the browser says, oh, this is a different domain, and I won't allow this request to go through. And in cases like that, that JavaScript doesn't get processed. So in short, the cached version is the HTML page. It's not necessarily the rendered page. So if you want to see what a page looks like in our indexing, then definitely use fetch and render to see what this page looks like when we render the page, not just the raw HTML page. Another thing you can do is, once the page is indexed normally, is to just search for a snippet of text and see if your page comes up. And if it comes up, then obviously we will have found that and we're indexing the page with that content as well. John, can you explain what the situation is with fetch and render? When you have a big image, you were talking about the Google crawls, the certain length of something on Twitter the other week, 900 pixels or something. You said, and sometimes images, for instance, like slider images or top carousel images, end up huge. And it looks like that's all that can be seen. How does that work? That's not actually a reflection of what Googlebot can see, is it, or what you're indexing? I mean, is there a limit to it? We index more. But I think that the render that we do for fetch as Google is limited to, what is it, 9,000 pixels or something like that? I don't know. Someone did a test and found that out. And what happens is we render the page with a viewport that high and some CSS rules say, I want this image to be stretched to match the full viewport. And obviously, if you have that kind of a CSS rule in there and we're rendering it with this high viewport, then that image will be stretched to those 9,000 pixels. So that's essentially what people are seeing there. And that's something where if you want to leave it like that, that's perfectly fine. The difficulty is you don't see what's below this image, below kind of the first viewport page. You can't easily double check that we can actually render the normal textual content on the page. So my general recommendation there is to just tweak the CSS to make it so that it actually does render normally in Google, that it has like a max height or something like that. And if you do that, then you can render the page normally and you can kind of confirm that your content is actually visible there. For the most part, you also notice this when you look at searches for your site anyway. Because there you kind of can see, if Googlebot can see the normal content or not, that's reflected in how we actually show your pages in the search results. OK. Thank you. All right. Looks like we just have a few minutes left. Maybe I'll just open it up for more questions from you all. What else is on your mind? I have a question if you can hear me. OK. OK. So I know you talked a little bit about JavaScript today. I'm still kind of confused about when JavaScript gets rendered. And correct me if I'm wrong. If is it safe to say that if the text or the content is displayed none in the CSS, but is in the HTML when it's loaded, Googlebot can render that. But if it requires pulling that content after some sort of click from outside of the page, Googlebot cannot render that. Exactly. Now, if it requires any interaction before that content is actually pulled into the page, then we usually can't see that. Where to click? It's like a user will look at a page and say, oh, that's a tab or that's a button and click on it. And then the server does something back and forth and shows content. But Googlebot doesn't know what you're trying to show. OK. So it's safe to say that if the display is set to none and an ordinary user couldn't see that text, but it's in HTML. If you did a view page source on the browser window, you would be able to see it, but it's displayed none. That would be rendered. That would be part of the crawl. Yeah. I mean, you could just like. Because that would still require you to use your interaction to be able to open it up to see it. Yeah. If it's in the DOM of the page, then we should be able to use that for indexing. Even if, OK, got it. Cool. Thank you. All right. One question. Can I ask one final question, John? I don't come here very often now. So I know I've hogged everything into apologies to everybody. I was reading something recently that was talking about contextual search and user modeling. Now, I know that actually we can't have things that they clearly identify the individual user, because privacy, blah, blah, blah, et cetera. But say, for instance, I fit into a certain type of persona as a browser. Yeah. And I like, you know, homeraniens. And people who also like homeraniens also like something else. When I get to return search results, am I also likely to get served things and suggestions based on other groups of people with similar demographics to me who also like homeraniens based on user modeling in the future? Or now, is that like a roadmap, like a recommendation based on groups? I don't know. I don't know. So I think, I mean, there is some amount of personalization that obviously happens. But I don't know what the details are there. It's not even personalization. It's not personalization. It's modeling of user types. So certain people, just persona modeling, if you like. Someone else needs this room. So I need to head out. Sorry to cut off here. Thank you all for joining. And hopefully, I'll see you all again in the future as well. OK. Thanks. Bye, everyone. Thanks, Paul. Bye. Bye-bye.