 All right, welcome everyone to today's Webmaster Central Office Hours Hangouts. My name is John Mueller. I'm a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do are these Office Hours Hangouts where webmasters and publishers can jump in and ask their questions around web search. I don't know, do you want to get started with anything in particular? No, I'm going to say no. OK. Let me just mute you because there's a bit of background noise there. But feel free to unmute otherwise. All right, let's take a look at the questions that were submitted. As always, if anything pops up in between, feel free to add more questions or jump in in between. The first one is about cleaning up old, thin kind of old article content and with regards to how websites could be ranking them. So I think kind of summing it up, it's a news website. Over 10 years old, they have a lot of articles on there and they estimate maybe 10% of these articles would be considered thin content and are hard to reach by users. They don't know if they should invest time to clean that up. I think that's a great question. There are always multiple factors that kind of play into that. On the one hand, one thing I would avoid is just likely going in there and saying, these pages don't get a lot of traffic from Google. Therefore, they must be bad and I would believe them. Just because pages don't get a lot of traffic sometimes is totally fine. It might be just that something is kind of reasonable, but people don't search for it that often so it doesn't get a lot of traffic. Perfectly fine. The type of issues I would watch out more is when a significant part of the website is really thin and low quality content. That's kind of the area where I would see problems. If you have a gigantic website and you know that there's some parts that aren't that great, usually that's not a big problem. If you can work out where those kind of thin parts are and either kind of flesh them out more, add more information, maybe combine multiple pages into one page, then that's certainly a good idea. I think for the general use case where it's a really large website and you have a little bit of thin content here and there, that's not something I would see as kind of a critical activity to clean that up. Obviously, going forward, it might make sense to think about how you want to maintain content in the long run. If there are any processes that you can implement to kind of improve the lower quality content before you actually go in and publish that, those are things that you might want to look at. But for general use case, a large news website, there are going to be weird articles in there. There are going to be weather reports that you keep for a long time. And there might be someone who like 10 years later decides to research that and is happy to find these kind of thin articles that they do have something unique that otherwise isn't found on the web. My CMS is auto-generating image variants for proper delivery. When an editor changes the display size, the image name will change too, which is bad for Google, but the original source image that remains publicly at the same URL. Can I use an image site map to tell Google about this or a source image, even if it's not used on the page? So if that source image is not used on that page, then probably we're not going to do much with that source image and you'll still have that problem that the images that we would show in image search change URLs. And when images change URLs, that's really, from our part of view, a bit tricky because we're used to images not changing that often, so we don't recall them that often. So when we find a new HTML page that refers to a new image file, that's something that can take a bit of time to be processed. So especially when it comes to images, make sure that you at least set up redirects from the old URLs. And ideally, I would really try to find a way to prevent the image URLs from changing regularly. It sounds like, when you say when an editor changes the display size, that sounds like something that doesn't happen too often. So maybe that's not a big problem, but for example, if your CMS would automatically generate new image URLs every day or for every session, then that would make it very hard for us to index these URLs properly for image search. If you don't care about image search, if you're sure that nobody is searching visually for your content, then maybe that's not a critical thing to worry about, that's kind of up to you. We're getting structured markup errors and search console on one side, but when we test using the structured markup tool and the Chrome tool, we get contradictory results, which is Google's canonical correct answer. So I'm not sure exactly which Chrome tool you're referring to, so that's kind of tricky there. I'm not really sure what you're comparing. In general, the common source of kind of irregularities across these tools are with regards to some of the requirements that are for specific types of rich results that we would show. So if there's a specific type of rich result that you're aiming for, then I would double check the developer site to make sure that you have all of those requirements covered. That's something that can vary a little bit. So for example, if you're trying to aim for this type of rich result, then you might have to fulfill some more requirements, but technically the structured data might be valid in the sense that you're specifying the baseline required structured data attributes and values there, and that might be okay. So for this type of result, you'd need a little bit more and for a different type of rich result, maybe you'd need a little bit less and that's also sometimes a source of confusion. So I'd really try to kind of compile that backwards from what you're trying to do and double check in the developer site which attributes are actually required for that particular type of rich result that you're aiming for and then use the testing tools to make sure that you really have those attributes all specified properly. I started working for a company that is using Cloaking. They have landing pages that contain lists of reviews and show different sort of reviews to bots and users. In order to limit duplicate content on multiple landing pages, might otherwise load the same sort of reviews. Are there types of cloaking that aren't a big deal in the eyes of Google? So I don't know exactly what these pages are doing, so it's kind of hard for me to tell. The reason that I'm kind of unsure here is that it's not so much about cloaking but sometimes more about personalization in the sense that you can personalize your content to different users. So in particular for users in different locations. So for example, if you have a general landing page, a home page and you have a whole bunch of events on that landing page, for example, then it might make sense to personalize the events that you show there based on the user's location. And that could result in Googlebot, which is generally based in the US, seeing a different set of content than a user would when they're based maybe in a different country. So that difference is something that, from our point of view, is more around personalization rather than cloaking and that's essentially fine. The thing you just need to worry about there is that obviously if you're showing users in the US completely different content, that's the content that will get indexed. And if the content that you would show users in the UK, for example, is very different, then that content might not get indexed. So it's more a matter of what you need to have indexed and that's something that kind of plays into the personalization side there. With regard to that, our general recommendations is to have a sizable part of the page as something that remains static for all users. So regardless of where the users come from, what cookie settings they have, they would see the same content. That's also something that you'd be sure would be indexed in Google. And if you have other sections on that page which are more personalized, then that's something that you might not worry about so much with regards to which of these versions are actually indexed because you know that static chunk is really the part that contains everything that you need to have indexed. So that's kind of, I guess, drifting off into personalization rather than cloaking. If on the other hand, what the company is doing there is really serving Google about something very unique that no other users are seeing, then that would be considered cloaking. So it's more a matter of are you doing personalization for users in a specific country or a specific region or are you doing personalization essentially for just for Googlebot? And that would be a problem. In particular with structured data, if the web spam team looks at your pages and they see that the structured data that you're supplying to search engines is significantly different than what users would see on that page, that's something they would flag. And that's something that they might apply manual action for with regards to structured data. So what would happen there is we would just stop showing structured data for your website until you resolve this issue. Just make a difference for Google. If the domain is not always reachable via the same IP address, no, that's perfectly fine. A lot of content delivery networks have IP addresses all around the world. And depending on the user's location, they might get a different IP address. And that's perfectly fine. Even without a content delivery network, it's very common that you have a set of servers that are responding to user requests and you're kind of dynamically advocating the users to those servers with regards to IP address. And that's perfectly fine. Can the software for status of a page be passed on to another page by canonical or 301 redirect? I'm not quite sure how you mean this question, but in general, if we see something as a 404 or a soft 404, then that applies to that URL. And then from there, we don't follow it. So in particular, this is kind of more obvious with regards to clear 404s. If you're returning a 404 status code and you have some content on that page, we would ignore that content completely. And similarly, if we think that this is like a 404 page, even though it doesn't return a 404, then we would also ignore that page completely. We would not kind of use the content on there and drop that URL from the search. John, can I ask, what about if you do a canonical to a noindex page? Let's say you have a page, you want a noindex it, but that page maybe has some parameters that can be applied and those have canonical to the non-parameter page. How would Google do that? Just have a canonical to a noindex. So kind of a general situation where you have a normal web page and it has a real canonical set to a noindex page? Yep. I think we would be confused and what would probably have, so what always happens with regards to canonicalization is we have all of those different factors that we take into account. And we would probably run into a situation where some factors are saying, well, we should canonical to this page and other factors are saying, well, this page is a noindex so maybe we should not canonical to it. So that's something where I wouldn't be able to say we would always do it like this or always do it like that. I suspect what it comes down to is what the other canonicalization factors would say. Are there internal links that are going to this noindex page? Then maybe that's a sign that actually you do want the noindex page to be seen as the one. If there are internal links going to the normal page then maybe we might say, well, maybe the canonical is wrong. But what would not happen is that we would index the noindex page because it becomes. So if it has a noindex, that's a clear sign you don't want that page indexed. Okay, and since we're talking about indexing regarding your, well, Google's message about relnextroprev being retired. There was a lot of talk about how Google mentioned that the use case of using it for articles in multiple parts, which is not always the case that relnextroprev might be used in that scenario. At least from my experience, it's mostly used, especially in e-commerce websites with categories with pagination. What would be, if relnextroprev gets retired, what would be the next best thing to do with the pagination pages and categories and things like that? I will just do them normally as you're doing them now. So that's, I think kind of the thing that we wanted to bring across. And I think we didn't bring it across that smoothly. But essentially this, it's been the case for quite some time now that we don't use the relnextroprevious. That's something we just recently realized when reviewing things with the team. And essentially, for the most part, I have rarely seen any SEO as kind of run into problems with pagination. So if the pagination is working for you now, then you're doing it right. In fact, there's nothing that you need to change there. It's definitely not the case that you need to remove all pagination and make one giant page. Essentially, you paginate the way that it makes sense. You link between the paginated versions and that you have kind of the next and forward and back links. Some people have jump links that they say, like, from like five pages further or 10 pages further. That kind of depends on how much content you need for pagination. In general, I'd also recommend making sure the paginated pages can kind of stand on their own. So similar to category pages where if users were to go to those pages directly, there would be something useful for the users to see there. So it's not just like a list of text items that go from zero to 100 and links to different products. It's actually something useful, kind of like a category page where someone is looking for a specific type of a product. They can go there and they get that information. So that's something where, from my point of view, people are doing it right. I don't see a lot of problems with regards to the way that they're doing it. So we just wanted to make sure that everyone was aware that we were not using that anymore. And like I said, I think we could have brought that across a little bit smoother, but we did want to get it out as pretty much as soon as we realized that we were telling people things that are kind of unnecessary to do. So do you require anything else to kind of, so webmasters can point you in the direction this is a set like a pages, like a pagination series, maybe a page parameter or something like that. Do you use certain things to kind of gauge whether this is a part of a set of pages of the same category, let's say? Not so much. I mean, we use the internal links, which for the most part, that pretty much makes it clear. The other thing, maybe to mention with regards to Relnex and Relprevious it's something that not just Google uses. So just because we don't use it doesn't mean like you should go off and like rip it out because it'll cause problems. It definitely won't cause problems for Google. Some browsers use it, for example, for prefetching. Other search engines might use it. You might use it for other purposes. It's part of the HTML spec. So it's not like something that would break anything. So it's not that you need to go off and like tear it out and it'll cause problems. Otherwise you can leave it in there or you can continue to use it. It's just, we don't use it for indexing. Okay, I'm just asking because a lot of, I'm assuming a lot of e-commerce sites would be worried that if you're not using anything to identify this kind of pagination series, people might get anxious since all paginated pages have the same title usually or something like that, that wouldn't be a problem. Should they start using noindex maybe on page two and three and so on, things like that? That's kind of up to them. I think using noindex sometimes makes sense. It sometimes makes sense to kind of filter out the filters and the sorting parameters if you want. You can use the URL parameter handling tool in Search Console to tell us more about how you want these pages to be crawled. The other one, Search Console. Yeah, well, it's still there. We have to hold it out. I think there are a bunch of features that are going away next week, which is kind of sad, but I hope that makes room for new stuff. Like all of these things still apply. I think especially with regards to e-commerce, what I would recommend doing is trying things out with a local crawler. So it's tools like Screaming Frog, Deep Crawl. I don't know how they're all called, but there are a lot of really good tools that will crawl your website and tell you can you find all of the product pages? And that's kind of the important part for us, especially for e-commerce sites, that we can go to these listing pages and somehow discover all of the individual product pages. And you can help with that by having related products linked, by linking individual products in different categories. For example, all of that helps. But if we, for example, need to go down to page 25 of a linked list in order to find those products, then that's going to be really tricky for us. So that's something I think, especially in the recent couple of years, there are some really awesome tools out there where it definitely makes sense to test your website with, especially if you have an e-commerce site and you're worried about the pagination and the filtering. Like, is Googlebot getting lost in a sea of endless URLs? Or is Googlebot able to find it? OK. And one last thing regarding indexing. You just mentioned linked lists. I think that would be a better term for pagination, I guess. So without real next world prep, do you still, does Google still identify that is it a linked list or is it just individual pages that Google doesn't care whether it's a page? We do a variety of cool things to try to figure out how these pages fit into the context of the website. But I doubt it's the case that we would say, well, this is a paginated page. Therefore, we need to treat it differently. I think for the most part, we can just treat it as normal pages. We can understand that it's this kind of rough part of the context of a website. But I don't think we explicitly need to have an attribute saying pagination or not. No, I just wonder, because some of the documentation I think used to mention set of pages, this definition of set of pages with regards to pagination. So I'm just wondering if you're still keeping that, if you still have that knowledge, whether it's a set of pages or just any pagination pages, just like a normal page, and we don't really care. I think we picked that up through the internal linking. OK. OK. Cool. All right. Hi, John. Hi. I have a few questions. The first one is, one of our client websites has a blog post. So today, I got a message from Google Search Console that the page we submitted on one of the blog posts is not mobile-friendly. They show a lot of issue. So when I tried to visit the page from my mobile, I found this working properly. Everything's fine. There is no issue. But I'm not sure why Google is only for that blog post. I check that blog post and other blog posts and take other pages, all showing fine. But only that blog post, why Google? I tried to believe it. But when I click on the button, they say, oh, it's still you pages, the issue. So I'm a little bit confused. Why is Google showing the issue? It's hard to tell without knowing the URL. But I would test with the live mobile-friendly test. And if it works there, then I think you're OK. But what sometimes happens is if we can't fetch the CSS or the JavaScript of the page, then sometimes the layout looks very different. So that might have been something where we said, well, we rendered the page and the CSS didn't work. And then it resulted in a page that didn't work well on mobile. So maybe that was just a temporary glitch rather than a real problem. And another client, they have a page with some parameters. So we added no index so that Google does not index this page. But we have got a message that Google indexes those pages. So we got a message that the robot file mentioned not index that page, but Google index that page. OK. So is that in the robots.txt file? Yes, in the robots.txt file. OK. So in the robots.txt file, you can tell us which URL is not to crawl. That's something that is really useful for us. And it's something we stick to strictly for Googlebot. But that doesn't mean that URL can't be indexed. So in particular, what can happen is if we see a lot of links to that page, we'll try to crawl it. We can see we can't crawl it. But we have all of these links that's saying this is actually a good page. So we will index that URL and maybe use a title from some of the links that we found and show that in the search results when it looks like someone is explicitly looking for that. Obviously, showing it in the search results is really hard when we can't look at the page and see what is actually there. So in many cases, what ends up happening is we index the URL. But we pretty much never show it in the search results because we don't have enough signals to know where we should show it. And an exception there could be, for example, if you set your whole home page or your website to disallow crawling, then we still have a lot of information about when to show your home page in the search results. So we'll try to kind of tide you over there until we can crawl again. Or until we're sure that this page is really gone forever. OK, the last question. Another client has two websites, one for Australia and another one for New Zealand. So he has a blog on the both website. So sometimes we post the same content on the both website, but we use a hreflang tag so that Google can understand this for Australia, this for New Zealand. And sometimes we post a specific blog post, which is only for Australian audience. We don't post those content on New Zealand website. Now my question is, if we post like some contents are different, some blog posts are different, some blog posts are same. If there will be any problem, if we post the same content sometime? I think that's fine. Yeah, that's my problem. OK, thank you. Sure. Let me run through some of the questions that were also submitted. And then we should have more time for things from your side as well. The next one was a question about pagination. I hope we got that covered. Then tips for SEO-friendly metered paywalls. What I would look at there is our guide for flexible sampling. So I think we have that in the developer center, developer help center, kind of the documentation of what you need to do there with regards to flexible sampling, where you can do something like, first click free, and that some users, if you want to, you can show them the content right away. And after a couple of clicks within your website, you would show something like a paywall. Or I mean, that's kind of like the metered paywall here that you're talking about. And we have the markup in the developer site with regards to what you can do there, and kind of what the requirements are from outside. We notice a huge part of the pages on our site doesn't get indexed, even though we made them part of our sitemap. Search console says they found, get not indexed. And for other pages, we get a soft 404, or it couldn't be indexed due to crawl anomaly. We have the impression that these problems are caused by the fact that the pages are loaded by JavaScript. Should we use dynamic rendering or not? So I think dynamic rendering might be an option here with regards to making this content easily accessible to search engines that don't use JavaScript. But in general, from looking at the website a little bit, I'm kind of worried that you have a ton of content that you're providing on this website that is not significantly valuable for us. So not specifically for us, but for our users. In the sense that what it looks like is you have a giant combination of different locations and different places and different types of content for different locations. And that's primarily driven through aggregate content from other websites, be it from Maps providers or kind of user-generated content sources that are out there like Wikipedia. And this compilation of content is something that can be kind of useful. But if you just put that out there on a website and all of these different variations, then we will see millions of URLs. And we'll notice that the URLs that we crawl and index are not really that unique, valuable, and compelling for our users. And then what will probably happen is we'll slow down crawl, slow down indexing of new content there, until we can make sure that what you're providing is actually significantly unique, compelling, high-quality content. So my recommendation here would be not to focus too much on the technical side. Obviously, the technical side needs to be well done as well, but to really kind of rethink what it is that you're providing on these pages and to think about what it is that would differentiate your website from all of the other websites that are out there that also have some kind of mapping or location-based information. And that's sometimes, I think, the hard part to do. Often, it's easy to say, I found these different sources. I can compile them and turn them into a website that covers all permutations of all of these variations. But kind of the next step from there is like, so what does this change for the web and how can you show that you're something that really, like when talking with the search engineers, they would say, yes, we absolutely need to have all of this content indexed. Otherwise, we're doing our users a huge disservice. So that's kind of the direction I would take there. So dynamic rendering is certainly something you can look into. I don't think that would solve the general issue of Google going up and indexing everything. How does Google treat images that redirect to pages? So for example, if we have an infographic and it's been transferred to HTML, do those image embeds pass Patrick? As far as I know, there's no Patrick being passed in a case like this. So in particular, if an image is embedded within a page, then that's something we'll try to pick up for image search. If we can't pick up the image from that image URL, then we generally won't index that image for image search. But we also won't kind of transfer a redirect from the image URL to a web URL and use that for web search. So that's something where you really kind of need to think about what it is that you're trying to do ahead of time. And instead of turning an image into an HTML form, maybe think about the long-term plan for your content and start off with an HTML form. And kind of work your way through that. But redirecting an image URL to an HTML page, for the most part, I don't see that working in a way that maybe an HTML page redirecting to another HTML page would work. Can you talk about duplicate content in e-commerce? What's the best practice when it comes to filtering pages, adding no index, no follow, and blocking where a robot's text? Wow, OK. I think this is one of those topics that we need to do a whole session on at some point. So I think the short answer here is really you need to make sure that the pages that you're providing can stand on their own. That's kind of our general guidance here. So when you're looking at different category pages and especially pagination, filtering, sorting, all of that, I would think about what you want to have indexed and make sure that everything kind of lines up with what you want to have indexed. So if you have different sorting and filtering options, then make it so that we can pick one version of that and use that for indexing, which could be with a real canonical. It could be that you link with a no follow, maybe internally to the filtering variants. All of those things are options that you can look into. But this is also something where there's no one size fits all solution. So maybe for smaller sites, it's fine to have all of these variations indexed because you don't have hundreds of pages of content for all of these categories. Maybe you just have a handful of pages. And that's something we can deal with. That's not something where we would get stuck. The other thing I would mention here is, like I mentioned to Mihai before, there are lots of tools that are out there that will crawl your website and give you an overview of what is findable from crawling. And that's definitely something that I would look into, especially with an e-commerce site, so that you're a little bit aware of what Googlebot might be running into. Because Google's view is something that you will see aggregated over a couple of weeks. And if later on during those couple of weeks or a month or so later you look at it, you think, well, I wanted to have something otherwise indexed, then that makes it really hard to kind of iterate on improving things for indexing and crawling. So using some of these crawling tools is something that makes it a lot easier for you to recognize what the structure of your website would look like to a crawler more or less immediately. How does Google treat keyword-stuffed title tags when the first word in the title tag is useful? So we do try to recognize keyword-stuffing in titles. And usually what happens here is we just rewrite the title for the search results. We recognize keyword-stuffing in general across pages, and we try to treat that appropriately. So I don't think you would see any big positive effect from keyword-stuffing title tags. On the downside, you would almost certainly see that we rewrite the titles in the search results, essentially the links to your pages. And that might be something where you have, I don't know, a different opinion with regards to how you would like to have your pages linked from search. So the more you can make your titles short, compelling, and useful, the more likely you will be able to use those and show those in search, which is probably what you would like to have done. Then URL parameter handling tool. Like I mentioned, we still use this. It's very useful for us for crawling, especially larger websites. So I'd recommend checking that out for smaller websites. And in particular, if you're not sure what these parameters do, I would recommend just leaving it in the default site. We do occasionally run into situations where sites shoot themselves in the foot by saying, these parameters are irrelevant. And then we end up not crawling all of those URLs, and then suddenly important pages drop out of search as well. So that's something where you really need to be careful how you use this tool. Any thought about delisting the names of sites once they've been disavowed in the Search Console? I always torn about this. On the one hand, we want to give people information about what what we found, that is links. On the other hand, I realized some sites in particular have a lot of trouble with the links that are coming to their site. And it would be useful to not see those in Search Console. I believe there is a browser extension that someone made that removes these from the list. But I don't think from the Search Console side we would be investing a lot of time to filter those things out. Because the primary reason here is that for the most part, for really the largest number of sites that are out there, they don't need to use a disavow tool. And any more highlighting that we do of the disavow and it's like, we are filtering these out here in this report, any kind of highlighting that we do more in that regard encourages them that maybe they should be using it. Because Google keeps mentioning this disavow tool. So maybe I should be using it as well. And for the most part, sites really don't need to waste their time with the disavow. So that's kind of why we're saying we'd rather not put so much visible weight on that so that people don't get confused and start doing things that they don't need to do. And instead, can focus more on things that actually make a difference for Search. Hey, John. In addition to that, disavow file. So my question is clear. Suppose I disavow some good links, which has a good maybe interlink, which is kind of authentic at links. And we kind of have disavowed those links. And later we got to know these are the good links and we have removed from the disavow file. So Google will consider that later, or maybe how much time it will take Google to again consider that those set of links. So I just want to understand. Yes. Yes. If they're removed from the disavow file and we recrawl those URLs, we will see those as normal links. So how much time it will take altogether to recall those links? There is no fixed time. That's always tricky. But depending on how important that we think those pages are, how often we feel we need to refresh them, that could be a matter of days, weeks, it could be a matter of months. So for example, if you disavow one really deep link within a very large website, and that's something that's rarely referenced within the website, then that could easily take a half a year or longer for us to recognize that this page has changed and we need to kind of pick that up again for the disavow file. The good part there is also that if you add or remove a link like that to the disavow file, the effect will be almost nothing. Because if we don't think it's important enough to kind of regularly look at, then that link is not going to have any positive or negative effect on the site. But somehow that links are very useful for us. It was from good domains or good reported domain, you can say that. So in that case also, it will not be having any diligence between the links. I mean, if it's a link from a home page from a website and we think that's a fantastic website, then we'll be looking at that home page more often. So we'll pick that up really quickly. I think the tricky part is also there's no indicator of when that link is kind of updated again. So that's not something that you can track at the time. That's kind of in general, we assume for most websites, there are always links out there that we can pick up on. And having one link, more or less, that's not going to kind of affect the website as well. So here, I'm not talking about a single link. Maybe some set of links. Yeah, I mean, essentially, the same thing applies. Like, if there are multiple URLs, then there's a chance we might be calling them a little bit faster, a little bit slower. But it's not something that we can guarantee at this specific time. Sure, thank you. All right, let's see. My website started ranking for pharmaceutical terms that I don't have content for. When I do a site query for my brand, there are a bunch of results that match. When I click those results, there's no reference to my brand. But when I click on Google's cash version, I can see them. Could this be the reason why Google thinks we're relevant for these pharmaceutical terms? Could be. So I'm not exactly sure what you're searching for there. But it sounds a lot like maybe there's hack content or maybe there's some cloaking from a hacker on your website or there was. And it's something where if you look at the pages directly, then the hacker will filter that out and kind of show the normal content. But when Googlebot looks at it, the hacker might be showing the special pharmaceutical content. So one thing you can do there to test those URLs is to use the inspect URL tool to see what is actually shown to Googlebot when those pages are requested. I would double check both the desktop and the mobile versions because we're switching to mobile first indexing. So there might be a difference there. But that's essentially what I would aim for. Also, if you recognize that this is happening to your website and you're not aware of fixing anything on your website, then I would assume that that vulnerability is still on your website somewhere. So I double check with anyone who's working on your website on the back, maybe your hoster or anyone else from your technical team just to really make sure that nobody went off and resolved kind of this hacking situation. And oftentimes we'll see that a hoster will fix hacking for a client and say, oh, I fixed this and I hope they don't notice because it's embarrassing that we got hacked. But I think it's worse if you don't know something was fixed or not. So it's really important that you double check and make sure that someone actually fixed those vulnerabilities so that this hacking doesn't return again and again or get worse and worse. As a tour operator for ski holidays, we offer accommodations as products on our website. For the accommodation where you're currently using the schema.org markup product, is product useful for this or is a schema markup hotel better for our offers? I suspect hotel would be better for this. I don't know what the exact requirements are for product markup, specifically with regards to how we would treat products differently in search. So I would double check the developer documentation for this type of markup. I assume with using the markup hotel, you would definitely be on the safer side because it matches a bit more what it is that you're actually on. Is it normal for Googlebot to crawl a lot of JavaScript when the site is using server-side rendering and the whole content is already in HTML? What's the best solution there? So I'm not really sure what the configuration here is. My suspicion is you're using server-side rendering, but the JavaScript is still all referred to within the page. So what happens is Googlebot will go off and look at these pages and assume that the JavaScript is still relevant here and try to execute that. Things that you could do to make it a little bit easier here is to use pure JavaScript files. So in particular, if you use versioning in the URL in a JavaScript file, you have thousands of different versions of the same JavaScript scripts. Then reducing that and compiling that into one JavaScript file would probably help quite a bit. So instead of having to fetch all of these different JavaScript files separately, we can fetch one file. That could help. Another thing is to make sure that you're using the normal caching setup on the website to tell us that these JavaScript files can be cached, and we can keep them for longer. Another thing that you could be doing if you're using server-side rendering is really to render the page completely so that you don't have references to the not-needed JavaScript within the HTML. So those are some directions I would add there. If you continue to see this happening so that we're crawling a lot of JavaScript and not your normal content, I'd recommend posting in the week we set up a small working group on Google Groups for JavaScript sites. I'd recommend posting there with the details so that we can take a look to see what it is that we're actually crawling and maybe for others to double check to see that your server-side rendering setup is set up correctly. The date shown in web search results is sometimes wrong, saying nine hours for articles that were just published now is Google grounding the published dates and times. No, as far as I know, we would not round these dates and times, especially for recent things. But what we have seen in the past is that sometimes websites offer inconsistent data with regards to dates. Especially when you're looking at something nine hours off, that sounds a lot like a time zone issue. So we've seen this quite often that a website will specify a date and a time in the visual part of the page. And they'll use structured data as well to tell us the date and time. But they use maybe GMT as a time zone in the structured data. And then for us, it's a tricky situation because we see one time there. And we assume that this time refers to the local time of the website in the visual part. And we see the GMT time zone within the structured data. And then our algorithms have to figure out which of these dates and times is the correct one. And that's sometimes really tricky. So we did a blog post on this fairly recently, maybe a couple of weeks ago, on the ways that you can tell us about your date and time. And in particular, things to watch out for with regards to the formatting of the date and time and structured data, with regards to time zones and consistency, all of those things. So that's kind of the direction I would head there, especially if you're seeing this happening for your website. There's still various kind of edge cases that we've seen where things get picked up incorrectly, even though you specify them properly. If you do see that happening, I'd love to get some examples. So maybe take some screenshots, give them the URLs and the times that you're seeing there so that we can pass it on to a team to kind of fine tune our algorithms there. All right, I think we pretty much made it through those questions. Can I please jump in to ask one? Sure. Thank you. So we have a health website that dropped in August and then went back up and now down again. And notice that only the public websites are winning. They don't have any ads. And we added a lot of ads recently. So I have two questions. One, can you say if we have like no shot in competing against the public websites that make no money from it? Or if, or yeah, can I ask that first? I wouldn't say you have no chance. I think that's something where we do try to offer like various search results that match there. And sometimes the more official sites are things that we find are more wanted by people, but it's not the case that commercial sites have no chance. Okay, thank you. And the second question is the ad experience report that you have in the old Google Search Console. Can you request a new crawl there to see if, because we added a lot of ads since the last report that we got in July to see if we have like too much that will be like considered annoying or overwhelming for there. I don't think you can request specific crawls. So I think you can only request a review if you've already been flagged as being too problematic. Okay. But I know the team is continuing to work on that. So it might be that kind of as a next step, they will be able to increase the frequency of those reviews, but I don't think you can request a review manually. You can only do that, like I said, if you've been flagged as having too many hours. Okay, because I feel like we have too many ads that it's annoying for the readers because some part of the article you see like the full screen is a big ad. So I feel like it's not good, but then without any concrete things, I cannot really argue with the ad department because they want to make money, so. Yeah, I know that's always conflicting, but I think if you already feel that it's too much, then it's probably too much. What you could also do is do a small user study and maybe invite a handful of people to your office and ask them, like, do you give them a task to complete and show them different websites and ask them what their feelings are? Specifically with regards to some of the points that we mentioned in the original Panda article from, I don't know, 2012 or so from Amit Sengal with regards to like how much would you trust this website? Yeah. And things like, I think the ad experience is something that can flow into that as well. And really trying to use like explicit user studies where you're saying, well, these are neutral people. They didn't come to the office because they agree with me, but they came to the office because they wanted to give us some information. Then that I think is sometimes useful. So especially internally, I found that extremely useful when talking with the product team, even if it's a small group of people that we bring in and they tell us like, oh, this partner in search council is totally confusing, then the product team will look at that and say, well, okay, we will treat this with more priority because random people are saying this and not just John. Okay, great, thank you. So in addition to that, about the ad site, so what about the pop-ups? Like some website has the pop-up which is blocking complete user to see the content at all. So it's just getting everything in and showing the pop-ups. So do you think it will somehow hamper the ranking in that sense? Sure, yeah. So especially on mobile, that's something that we've explicitly called out. Where we said if there are intrusive pop-ups on mobile or interstitials, then we would flag that as an issue on mobile. And most users are using mobile now, so that will be something that is more and more visible with regards to the text in search. Sure, I have one more question. So let's suppose our website is kind of blocking the Google bot and it's kind of, in a month it happened two to three times since last month. So how Google sees it in term of ranking of the website or maybe crawling to a particular site, so how Google sees it? How do you mean blocking Google bot? So it's just we are using some kind of CDNM it's kind of throwing four, not three, four within link when Google bot is trying to visit the page because they have maybe visited so many times or they have come to the page a number of times. Okay, so if it's a 503 error, that for us is a temporary thing. And if within a day or so you resolve that so that we can crawl again, that's no problem. If it were 500 errors, which would be server errors, then that would also be less of a problem, but it would result in those pages dropping out of search. And if we see a lot of 500 errors when crawling then we would slow our crawling down because then we would assume that maybe Google bot is the reason why your server is having problems. So we will try to crawl less frequently so that we don't cause as much problem. But if you have a very large website and we crawl less frequently, then maybe that would be an issue for you. So 500 errors are definitely something I would take seriously, 503 errors they sometimes happen. It's 403 basically. 403, 403 is similar to a 404. So we would drop those pages from search. So it's not that we would crawl less but we would maybe drop those pages temporarily from search. So it's temporarily, right? So I'm asking this question because it happened already in a month, three or four times. So I think it will impact the overall ranking of the website, too. No, so if it's a 403 then what will happen is those URLs that return that status code they will be dropped from search but it won't affect the rest of the website. So but it is the overall website. It's not a set of pages which is going forward or 403 at that moment of time. Okay, if it's the whole website that's returning 403 then that sounds like a problem that you want to avoid. That's because then we would look at that and say, oh, the whole website disappeared. Maybe we shouldn't be indexing it anymore. So it's not a ranking problem. Directly it's more a problem of like, do we keep all these URLs in our index? So I have another question. So we have this something called offer table in our pages. So our product pages basically. And it's kind of, we show different layout for desktop and the mobile. And the mobile version of the table is more cleaner and more appealing than the desktop. So will it somehow impact the ranking of the site? So what will probably happen over time is we'll use mobile first indexing for that and we'll index the mobile version which it sounds like the better version anyway. And then I think that should be fine. One more last question. Okay, one last one. Yes. So in this offer, which I'm talking about, so we load around maybe 30, 40, or maybe 50 offers in a page, in a single page. But the catch is key, we load maybe 10, 15 offers, you know, without JavaScript or maybe without adjuncts and the rest of the offer will load with the adjuncts. So is it a good idea to use this kind of scenario or what you are suggesting that? You can test that with the inspect URL tool to see if we can pick up the full content. And if we can pick up the full content with JavaScript or not, then we can use that content. That should be fine. Cool. All right, maybe for you other guys here, or Lena, if you have any more questions. Gentlemen, can I do a quick follow up on something I asked you a while ago? It's also related to indexing and canonicals. Let me just give you a URL. So it's a URL that all the internal links point to. It's the URL that's in the sitemap. And the all canonicals point to it, yet Google decides to index a version of this URL with the limit all, limit equals all parameter. Even though that parameter isn't used in internal linking or canonicals or anywhere else. So I was wondering why would Google not choose my canonical and it's not a big problem here but I'm guessing in a category page with a lot of products, with a limit all parameter that might overload the server quite a bit and make it load a lot slower. I don't know. Click to see if I can find something immediately. Sometimes it's possible to see something off hand but a lot of times it's a trigger. I've been trying to diagnose the issue but I'm just not sure why Google keeps picking the parameter URL, even though all signals point to this one. I guess there's not a lot of products there but if there were that would become an issue. Yeah, I don't know. I don't see anything off hand. Okay, sorry. Hey, that's fine. Well, if you can talk with the team and. Okay. Yeah. Okay. All right. No last questions. That's fine too. I have five last questions. Okay. No, no, no. Well, I have one. Okay. If you have time for one more. So for one of the news publisher websites, the journalists are adding up a bunch of tag to each article so the same article is posted on a lot of different subject pages. I would recommend that we will create fewer, like stronger subject pages that will be more relevant for each article. Can you either confirm or say that I'm wrong for not posting the same articles on like say 10 different subject pages? What is your take? I think that definitely makes sense because the different tag pages or category pages are pages that you want to have stand on their own and if they're a collection of all kinds of vaguely related things then they're not really strong category pages. So I try to limit that to whatever reasonably fits in with that article. Okay. Well, thank you. That was awesome. That was great. Great. Cool. Okay. Then I will wish you all a great weekend. Thank you all for joining in. Thanks for submitting all of the questions and hope to see you again one of the next day. Thank you. Have a good weekend. Thanks. Bye. Yes, bye.