 All right, welcome, everyone, to today's Webmaster Essential 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 Hours, where people can join in and ask any web search, webmaster-related questions. And it looks like lots of people are joining in, which is cool, we'll see. A bunch of questions were submitted already on YouTube. But as always, if any of you have a burning question on your mind that you really need to get answered as quickly as possible, feel free to jump on in now. If not, OK. Well, that's fine. OK, I'll get started with the questions that were submitted. If anything pops up in between, or if you have any comments, or want further clarifications along the way, just feel free to jump in. Maybe I'll just ask one question. All right. So I figure the BERT stuff obviously has significant impact, according to Google, on the search results. But Danny said on the tweet that there's really nothing to optimize for with BERT. I guess similar to when Google said there's nothing to optimize for with Rangbrain. So this has a similar BERT to Rangbrain in that sense. Is that true? Like, if BERT is really looking at natural language content, not like fake. I mean, if you're looking at what you think about it, BERT's about language and how things are written. If SEOs are writing for machines and then they start writing for BERT, is that better? I mean, let's say why SEOs are confused by that. I see articles left to right. This is how to get your website ready for BERT, and this and that. I kind of want to say this is really you're just wasting your time reading these articles. But is that true? Are you wasting your time reading articles about BERT or these SEO tips around BERT? I just wanted to get your opinion on that in a more long form than just a tweet from Danny's element. I really don't have any insight into BERT, so I haven't looked into that at all. My understanding is it's really just about understanding the natural language better. So that's something. If that's really the primary focus, then essentially the way to optimize for it is to write naturally. So that kind of falls into the camp of, well, there's nothing specific that you need to do to optimize for this. But I haven't really looked into this. Danny's been on top of this. And if he tweets that there is nothing to do, then I would pretty much trust that. OK, we should trust Danny. Got it. Yeah, it's like, believe what he says. If you don't believe me, it's like, at least believe you're closer to the outside world by number of years, I guess. I guess. All right, thank you. OK, all right. So let me jump in with some of the questions that were submitted. And we'll see how far we get. And as I mentioned, if there's anything along the way that you really need to jump in and ask for more clarification on, we're happy to do that. The first one, is there any YouTube signal used by Google to rank a specific content on Google search results? I don't think there's anything specific to YouTube. So in all of the dealings I've had with the search infrastructure teams, we try to treat YouTube like any other website. And there's a lot of content there, but it's not that there's anything specific to YouTube. If someone were to mention a website on YouTube, then suddenly, that would be more important. It's a website like any other. There can be links on there to external content. It can rank in the search results. It's essentially normal pages. New content on a few of my sites, and it's not indexing in Google. Based on when this started, this seems to be related to the August 8 bug in the system. But while it was reported as fixed, it's still an ongoing issue in some of our sites. I reported this in the forum, but had no reply. So I have not had a chance to look at that forum thread. It looks like the question was just posted 13 minutes ago, so not that fast. But in general, if you're still seeing issues from starting around August 8, then that would not be related to that bug. So those kind of indexing issues that we had back then, those will result fairly quickly. And it would not be the case that once I got forgotten in a batch of indexing issues. Instead, what I would suspect is just that your site is seeing some ranking changes there, perhaps, maybe some technical issues on the site itself that have persisted since then. And that wouldn't be related to kind of the indexing bug. That would be essentially something that would happen independently anyway. But I haven't had a chance to look at your thread, so I don't know exactly which site it is and what exactly might be happening there. Search Console shows the number of impressions the site gets at a keyword level. However, keywords at rank number 50 seem to get thousands of impressions, which is confusing. As few visitors scroll to page six of the search results, could you explain how Search Console impressions are calculated? And if the listing needs to be visible in order for an impression to be registered for a keyword. So Search Console is really based on what was shown to users in the search results. And it's done by search results page in the sense that if something is on this page, then we will count that as an impression, regardless of if it's within the viewport of that search results page. So that's something where if you're seeing impressions at that ranking, then that means we're showing those search results to someone. There's a Help Center article about this that goes into much more detail on which items are counted how and how the position is calculated, in particular of the multiple kind of fancy elements on the search results page. It might be that something like position number 15 is actually still on the first page. But that's something you'd need to look at the individual search results page for to see what could all be playing a role there. What also sometimes happens is that sites get an average ranking fairly low, or I guess fairly high position number, which means it's ranking fairly low. And it's just random people sometimes going there, but not a lot of people. So that's something that you would particularly see for queries where you think the competition is very high, where you might be surprised to see your site at all. But if every now and then people go that far down in the search results pages to see your site, then that would still count. Regarding hreflang tags, we have set up sites in a similar fashion to amazon.com and amazon.co.uk, where we have mostly identical English language content for two different geographic audiences through different domain names. We have not developed hreflangs between the URLs currently. Would you advise we spend development time to build this back end functionality or rather put that time into improving the user experience overall? So I guess there are a few aspects here that I'd like to touch upon. First, just because a big site is doing something specific doesn't mean that it's the correct thing to do or that it's the right thing to do for your site in your situation. Most other websites out there won't be Amazon. So if Amazon is ranking really well with one setup, that doesn't mean that you can copy that exact setup and rank just as high as Amazon because you're probably not Amazon. So that's kind of the first thing to keep in mind. And that applies to all kinds of big sites. So we often see that with people looking at Google.com as well, saying, well, Google.com doesn't use this type of structured data or doesn't have an H1 tag or something like that. Therefore, nobody needs this kind of structured data or nobody needs a specific tag. And that's something I would advise not following. Just because a big site is doing something doesn't mean that you should be doing the same or that you should not be doing the same as they're doing. You really need to adjust your strategy for your specific case. So that kind of out of the way with regards to hreflang link annotations, essentially these would link two different pages for either different languages or for different markets together so that when someone is searching and we would show one page, we would be able to swap out the URL against the other one. So that's something that, from my point of view, sounds fairly simple but can be really complicated to set up, especially if you have a lot of languages or a lot of countries. So I think it's good to ask if that makes sense to develop. In general, when talking with the engineers about hreflang in the beginning, they framed it as something, if you're seeing a problem with local search results being wrong, then hreflang might be one way to fix that. If you're not seeing a problem with the search results in the way that they're presented to users, then probably you don't need to implement hreflang because it's already working correctly. So that's kind of one thing to put out there as well. So if you already have your site set up and it's working well on search and users are finding the right version or making it to the right country version as appropriate, then maybe you don't need to do anything fancy for hreflang. Also, hreflang is on a per page basis. So if there are individual pages where you're seeing a problem or individual pages where you really want to make sure that the right version is shown, then you can just implement hreflang on those. So that could be maybe something like a category page or it could be your home page where you say, if people are searching for my brand, I really want to make sure the appropriate local version is shown, then maybe just do it on the home page or on kind of higher level category or article pages or whatever you have. So that's kind of the direction I would head there. On the one hand, if you don't see a problem, then don't see this as something critical. If you want to try it out, try it out on individual pages where you think this could have an effect. And then from there, you can make a decision. Doesn't make sense to expand this to more of the site or not. Another question about BERT, where I really don't have any useful answer. Can you shed some light on whether a website could incur a penalty by adding product schema to the website when that product that we provide to the public is a service? Schema.org includes haircuts as types of products, but it feels like this is a risk area. We have thousands of reviews that are worth showcasing and marking up. And I'm noticing that services schema doesn't tend to show review stars. So that's, I think, an interesting question. There are two things here. On the one hand, if these are reviews about your business in general and not about a specific product that you're selling that anyone else could be selling, then we would probably not show those rich results for your website in the search results. Especially if you're putting review markup on your website for your website or for your business, then that would be, by policy, something we would not want to show. The other thing is if there's a specific schema that or markup type that matches the primary item of this page and you're explicitly using something else to try to get a specific type of search result, then that would also not be OK. So products and services is one thing here. We often see it also with recipes, where you say, well, my blog post is a recipe for success. Therefore, I will mark it up as a recipe and I want to get all of that fancy rich results for recipes. And that doesn't make any sense. So it should really be type of structured data should match what you're actually providing on that page as a primary element. Search Console shows I have 194,000 valid index pages, while on site colon, it just shows 50,000. Which one is correct? I attempted to say neither of these are correct because counting the number of index pages is really hard. But in general, Search Console would be the number to base it on. The site query is something that we optimize for speed. It's not optimized for accuracy. It's not optimized for completeness. And you may see widely different results than from what you see from Search Console or what we actually have indexed for a site. So I would not use the site colon result or the approximate count that is shown there for any diagnostics purposes at all. I would only focus on the Search Console number. And even with the Search Console number, I would tend to be critical when looking at that because that is essentially the total number of pages that we have indexed, which is total number of URLs. And with any larger website, you'll know that there might be several URLs that lead to the same piece of content. So just because you have 194,000 URLs indexed, that might only be, I'm just making up a number, 120,000 pieces of content that you actually have indexed. So that 194,000 number is something that you need to take with a grain of salt because it might not be an actionable number to actually focus on. One way you can make this a little bit more actionable is to use site map files. Because in the site map files, you can explicitly list the URLs that you care about. And in Search Console, you can filter for those site map files and then see of those, I don't know, 40,000 that you have in this group of URLs, this many are actually indexed. And that's a little bit more actionable because then you know these are URLs that I explicitly wanted to have indexed. And of those, most of them got indexed or a small part of them got indexed. And based on that, you can make decisions and say, well, this is a problem I need to focus on or that seems reasonable and there's nothing I need to worry about here. So that's kind of the direction I would head there. Avoid using site colon, use Search Console index counts, or if you want to be more exact and have more actionable information, use site map files. I have one website that is not mobile-first indexed ready. It has a really bad mobile pre-render that's not working well. After September 9, the number of crawl pages per day in the old Search Console for the desktop site dropped by 99% from $6 million a day to $100,000. The m.property usually had about $90,000 per day and spiked to $1.7 million on September 8 and then crashed back down. The site is really big. Site colon shows over 10 million index pages. Server log showed the same thing. Traffic-wise, nothing has changed so far. But this information is really hard to understand. I contacted Gary by email twice and he didn't answer. So Gary's a pretty busy person. And in general, when people have our email addresses, we can't guarantee that we're able to respond. Sometimes lots of things are going on. And sometimes we don't have anything specific that we'd be able to answer back. And it can just lead to a lot of back and forth. That is not very useful for either side. So just because Gary doesn't respond doesn't mean Gary is ignoring it. But things get busy sometimes. With regards to the specific situation, it sounds like our algorithms we're trying to see if mobile-first indexing would work there. And it sounds like it didn't work out. So I wouldn't necessarily worry about that. However, at some point, we will be switching all sites to mobile-first indexing. And that's something that we will announce at some point when that is ready or when we kind of have the dates lined up. But that will happen at some point. So this is something I would personally recommend to make sure that it's actually working a lot better, that the mobile version contains the full content that your desktop version would contain, that the images line up, that the text is there, the internal links are there, the URLs, the structure, all of that works well. On the one hand, we need that for indexing. On the other hand, most users are using mobile devices too. So if your mobile site doesn't work, then that seems like something you should figure out fairly quickly because you're probably losing out on a lot of traffic there. With regards to the mobile pre-render, I don't know maybe if it's a JavaScript website and you're using pre-rendering, then that might be something that users wouldn't see so much. But still, like I mentioned, at some point, we will be switching all websites over. And we have no plans to have any options so that you can opt in or opt out of this. This will essentially happen at some point. So I would kind of get ready for that. When we do announce that, we will give sufficient heads up time so that people can prepare. But it's not something that you can ignore forever. Does non-responsive properties, such as HTML tables, affect the ranking of a page on Google after the shift to mobile-first indexing? No. So that's fairly straightforward in the sense that if a page is not mobile-friendly, that doesn't mean that we can't use it for mobile-first indexing. So if you need to zoom in on different parts to see the content or swipe sideways and things like that to get the content, the content is still there. And we can still index those pages. So in particular, desktop-only pages, kind of the old-school websites that you would make in a text editor before all of the fancy CSS features and responsive design got popular, those work completely fine with mobile-first indexing because there is one version of the HTML and it works for all devices. It's not easy to read on all devices, but it's available. So that works completely fine with mobile-first indexing. What will happen, though, is that we will not see this page as being mobile-friendly. And that can mean that we show it a little bit lower in the search results in general on mobile because if we know that a page is not friendly to mobile users and people are searching on mobile, then it kind of makes sense that we wouldn't rank it above similarly relevant pages. Can you clarify if there's any potential downside to truly comprehensive, every indexable page XML sitemaps on crawl budget? Are there cases where we should simply let PageRank internal links drive the crawling versus asking Google to process a massive XML sitemap with many extra or low-value pages? So I could imagine some situations where a website is very limited in crawling and you'd want Google to focus on some primary pages. But in general, we would do that with sitemap files anyway. So sitemap file doesn't replace our existing crawling, but rather it helps us to crawl a little bit more efficiently. So even for a large website, if we have clear information about last modification dates, for example, then we can focus on those pages and crawl those a little bit more. And for really large websites, last modification dates can be really important, because we don't have to crawl all of the paths that lead to that one or two links that go to this page. We can just recognize, oh, this page we've known about for, I don't know, five years has changed now. We should go look at it the next chance we have. And we don't need to kind of re-crawl everything else. So my recommendation, especially for large sites, is to use a comprehensive sitemap file and make sure that you have all of that in the sitemap file properly, and in particular, that you use a good last modification date on those pages or for the URLs in the sitemap file. John, on that topic, Big has been doing stuff around webmasters submitting content they wanted to crawl versus, and then even going beyond that and saying, send us all your HTML. Have they reached out to Google about potentially doing that with them that you can't talk about, that you want to talk about live on this broadcast so everybody can hear about it? I'm not aware of anything specific happening in coordination there. So we do have the indexing API, but that's, I think, significantly different from what Bing is doing at the moment. And the indexing API is specific to jobs and live stream content, I believe. And for that, you would also submit the URLs. We, I think, every now and then, there are discussions around what can we do to make it easier for sites to submit content, especially large sites that change quickly so that we don't have to crawl them and go through the HTML. But in the past, all of these discussions have ended up with, well, the HTML is actually pretty useful, and it's useful for us to make sure that this content is actually on the page itself. And it requires a lot less unique infrastructure on the side side to actually index the content. So that's something where I don't know if this will never happen, but at least so far, it's been the case that we've said, well, we prefer to be able to crawl pages and to pick up the content from there. All right, thank you. And I don't know if there are any secret discussions happening with Bing in the background where I'm stepping on people's toes, but at least as far as I know, that's the case. More crawl budget questions. I'd love to know how you calculate and plan crawl budget. Is Google planning and calculating or just counting crawl demand and crawl budget on a folder level or, I think, is on a domain level or a web server level or any other option? So I think Gary's blog post from 2017 goes into this fairly detailed. So I would definitely check that out. He has kind of written that up fairly comprehensively. And I believe all of that is still all relevant. In particular, we try to calculate the kind of load that we can put on a server on a per host level, because that's usually the level where we see the kind of the reactions of a server. So not on a folder level, but more trying to understand what the server is. And sometimes that can include subdomains. Sometimes subdomains are different. It kind of depends on what we've discovered over time. And this is something that adjusts itself automatically over time, so it's not that there's any specific setting that you need to make in Search Console to see this happening. Essentially, our systems try to understand that when we crawl like this, your server responds fine. So probably crawling is OK. And when we crawl slightly differently, your server seems to slow down or returns a lot of server errors. So perhaps we should crawl a little bit less like that. And that's something that happens totally automated. Sometimes you can see that happening if you have significant changes in your server infrastructure. So for example, if you move to a CDN, then that might be something where suddenly we can crawl a lot faster. And you'll see kind of this ramp up happening. Or similarly, if there's something on your back end that's slowing things down significantly, then you'll see that step down and the crawl rate happening. And you see all of that in Search Console. So in the crawl stats reports, you can see that. Someone, I forgot the name, just recently made a bookmarklet to export that into CSV files, which I thought was really cool. I don't know if there are plans from the Search Console side around something similar, but I thought that was really neat. That's a neat way to kind of track how things are happening with regards to crawling. You can, of course, also track this in your server logs, because you see the Googlebot requests, and you can kind of compile those together and see how many URLs are being crawled, what kind of URLs, all of that. But in general, this is done on a per server level, because that's the level that your server would react to. Do external links pointing to pages with URL parameters set to crawl none in Search Console URL parameters to hold any value? So if someone is linking to a page on your site that you've basically told Search Console not to crawl with that workout, I think it depends as much as nobody likes to hear that. But the crawl settings tool in Search Console is a way to give us your preferences with regards to crawling. It doesn't block crawling. So if you want something explicitly blocked, make sure to use robots.txt, because that would really block crawling. If you do use robots.txt, we don't know what is on these pages. So we don't know if there are any matching canonicals that we can reuse. So what can happen if there are links to a page on your website that is blocked by robots.txt? We might index that URL without having crawled the content. And maybe we'll take something like the anchor text and show that as a title in the search results. So it's possible that we would show that URL without any of the content in the search results if it's blocked by robots.txt. With the crawl settings tool with the URL parameter tool, where you can also specify that you don't want things to be crawled, usually what would happen here is we would try to determine what the canonical of that page would be. And we would try to forward those links to the canonical URLs. So again, we might crawl. And we might see there's a rel canonical there. And we might be able to use that directly. If we end up not crawling a URL and we think we have a good canonical for that URL, we'll try to use that. Sometimes that makes sense if, for example, there's a session ID parameter. And we know we can just drop that session ID and find a valid page. Then that's something we could do. If we don't crawl that URL and we don't know of any canonical on your site that matches that URL, then that link would go nowhere and essentially be discarded. So on the one hand, you're probably overthinking it if you're looking at this on a per link level. And your site generally collects lots of valid links across all kinds of pages. So probably it's not something you need to kind of over, I don't know, micromanage, essentially. But one way you could double check to see what is happening there is to use the inspect URL tool and just to see if there's a known canonical for that URL. And if there is a known canonical, then that would be where the link goes. If that URL is not known at all, then that link would essentially be dropped. And maybe it makes sense to not use that tool, the URL parameter is handling tool, if you're seeing a lot of links going to pages like that. And instead, using the real canonical directly so that we can crawl, find a canonical, forward the link appropriately. But my suspicion is, for most sites, doing this on a per link level like this is just way too much micromanagement. And you could be spending all of that time focusing on something much bigger on your website. OK, complicated question about click through rate fluctuation, disavow process timeline, and algorithmic penalty recovery. Wow, all of the keywords that bloggers have been waiting for. So in the performance report, a search console impressions and clicks are directly relatable, so fluctuates with the average position. However, those don't alter title tag in the description of a single result. Why does click through rate fluctuation correlate an average position fluctuation drawing the same graphic? I think this is very site-specific in the sense that on some sites you will see clear correlations between any one of these metrics, which could be like, I don't know, the click through rate is pretty stable. And the clicks and impressions are pretty comparable with regards to trends. And on other sites, you might see completely different results or it might be my query or type of page. So I wouldn't assume that anything here is generalizable to all websites, all URLs, all types of queries. So that's something where I try to look at it on an individual level. If 80% of a backlink pool is toxic and assuming all toxic links are marked in disavowed at once, how long does it take Google to get this change into account? So I don't know if you can say that links are toxic. Essentially, toxic in this sense would mean that someone has been building these links over time. Usually, that's my story from old SEOs where someone previously went out and bought a lot of links or set up this crazy link network, set up some kind of a link network, and things kind of you compiled a lot. You collected a lot of bad links to the site. So it's not that the links themselves are toxic, but rather that things that people have been doing to try to promote the site are not really in line with the Webmaster guidelines. And if you recognize a bigger issue like this and you don't have a manual action for your website, then that's something you can use a disavow tool for. And with the disavow tool, you upload a list of links or domains. And essentially, those are taken into account right away. That means the next time we re-crawl any of those links, we will drop those from our link graph, and they will not be used with regards to passing signals for your website. They'll still be shown in the Search Console reports because we show nofollow links there, too. But essentially, they're treated like normal nofollow links. And that happens immediately when you upload the disavow file, and the effect from that takes place over time. So it's not like you have to stage the disavow file or do anything special there. It's really, that's taken into account right away, but the effect you would see over time, and that sometimes just takes a while to kind of be effective. If a site has an algorithmic penalty and assuming all necessary fixes are done at once, submitting how long does it take to recover? So I think there are multiple aspects here for that one. On the one hand, algorithmic penalty, people kind of include all kinds of things in there. So that's one thing where I'd say it's not an algorithmic penalty, but rather we are, algorithms have determined that your site is different in relevance. So that usually doesn't mean that there's something that you need to fix, but rather that we think that the current status of your site, this is how we would find that it's relevant to show in the search results. And to improve that, you don't fix the issue, but rather you improve your website overall. So that's something that is kind of unrelated there. And the other thing is if you see that algorithms suddenly start seeing your site differently and thinking that maybe it's not as relevant as we thought in the past, that's not necessarily something that you can fix and get that old status back, but rather we're taking into account already how we think that it's relevant. So for example, if your site, I don't know, let's take something like keyword stuffing, which is kind of basic. If we look at your pages and we discover that there's so much keyword stuffing here that we can't properly take it into account, then maybe it would be ranking because of all of this keyword stuffing. And when our algorithms notice that keyword stuffing, we would drop it in ranking. But if you fix that keyword stuffing, then that doesn't mean it would go back up again because it was previously ranking in a natural state, essentially. So it's not that you would go back to that previous state because that previous state was probably based on an unnatural situation. So that's something also to keep in mind. In general, when you make bigger changes on your website to improve the website overall, then we have to recrawl and reprocess the pages of your website. Some pages we process a lot faster. Every couple of days, some pages take a lot longer. If we need to reprocess the overall site to get a better understanding of how this whole site stands, then we need to have a significant part of the site, at least reprocessed. And sometimes that can take several months. So that's something where if you see that your site has dropped because of algorithmic changes in our search results, and you significantly improve that website, let's say overnight, you improve everything significantly, then I would still expect to see several months time before our algorithms have recognized that this website has significantly improved and is suddenly significantly more relevant than we had initially assumed. I've seen massive traffic loss on Google Discover since the 24th. Have you been rolling out something or has something changed? I don't know. So I don't know specifically about Google Discover, but in general, we do make changes to various of our algorithms over time, so that that's something that might be just a normal change over time. I haven't heard much from other people around Discover with regards to the 24th, so I doesn't feel like something that is generally kind of an issue that people are seeing. So it's really hard to say there. Also, with Discover, it's not based on the queries themselves, so it's something where sometimes it can be tricky to figure out what you can do to kind of appear well in Discover, to match kind of the interest that people generally have when they see sites in Discover. Since a couple of weeks, we're noticing more and more often this kind of behavior, new and fresh pages, appear to correctly index in Search Console, but we can't find them with a site operator. After a while, usually some hours, they appear in the search results, but usually too late to get traffic, fresh pages and news trend is over. What could be causing it? I don't know. So I believe you also asked this on Twitter and had some sample URLs, so I've passed those on to the team to double check. But from what I've seen, this seems to be something specific maybe to your website. I also haven't seen other people talk about this much externally, so I don't think there's something very generalizable that is there. In general, the things I'd recommend doing with kind of a news website or website that is focusing on really fresh content are things that we've been telling people for a long time, so it's nothing really unique there, working with sitemaps. If you're in Google News, using Google News sitemaps, making it as easy as possible for us to crawl as much as we need from your pages and to be able to extract the information as quickly as possible from your pages. So those are essentially the normal things to do. News website, once something happens, all the news sites will report the same, but in their own style. Most of the content in news website looks like a spun of each other. How does Google or ranking fact work here? Does the content in the long run will be treated as spun or low quality content? So I hear this every now and then, but I think in short, when you're creating news, when you're writing about events, everyone writes things in their own way, and it would be really kind of weird for us if we see exactly the same content on the same event in the sense that that's usually not the way that it works. On the other hand, we do see a lot of websites that are essentially rewriting news content from other websites. And usually that's pretty obvious when you manually look at these pages and you kind of like search across the web. Either, on the one hand, you kind of read through the content. You think this is like weird phrasing. How did this happen? And if you start searching for it, then you notice that actually, sentence by sentence, it's the same as something from some other media. So from my point of view, that's not something where you're reporting on the same thing. Therefore, you write the same thing. It's really you're taking one article and rewriting it. And from my point of view, that is essentially spun content. So that's something where our algorithms, ideally, should recognize this and say, well, this content is not really as valuable. We need to focus our resources, our crawling time, more on this other website that actually produced the original content. So my recommendation there would be really to focus on creating your own unique, compelling, invaluable content and using that primarily. If you need to supplement this with content from feeds, something like, I don't know, from the AP or some of the other bigger press agencies, then that's fine. But you don't need to rewrite that content. That's something you can reuse. But you really need to make sure that the primary, the bulk of your website's content is something that is unique and compelling and something that you've created, not something that you've kind of either manually or automatically written off of someone else's website. And sometimes that means you don't cover exactly the same thing as everyone else. Sometimes that means you need to put in a lot more work to get similar coverage. But that's essentially what users expect. They expect to find unique and compelling content on your site if Google were to send people over to your site. The rich results data for our website is not showing in Google Search Console when our developers removed it accidentally in July. We have added back structured data to all pages in the month of August. The AMP, WebLite, FAQ, and other data is showing however rich results data is still not showing. So not really sure what might be happening there. In general, I believe we would continue to show that report even if most of your pages don't have that structured data anymore because we would kind of see the drop in indexed elements over time. And that would take place over several months. My guess is maybe you just don't use the type of structured data that we would show in that particular rich results report. So I would double check the type of structured data that you use and make sure that it matches what that report would be showing. If we're seeing the other types of rich results, which includes FAQ, then I think you're on track. And there is nothing specific that you need to do differently unless there is really one type of rich result that doesn't seem to be working for your site. Let's see, we have a bunch of questions left. But I assume there were some more things from your site as well, somewhere here in the Hangout. There's some things also in the chat. Let me just run through that briefly. Or if any of you want to get started with a question of your own, feel free to jump on in. Wow, no question. Hey, John, I have a question. OK. OK. My traffic is about since October 8. And even across tech with the Search Console, the crawl stats, the pages crawl per day, even that has dropped. So what are the factors you'd have to consider to improve my crawling? To improve the crawling. So for the crawling, there are two main things that are in play. On the one hand, there is the crawl demand, where we try to figure out how much we need to crawl or we want to crawl from a website. And that's primarily based on how important we think your website is, what kind of content you're providing, how it's doing in general. And on the other hand, there are things that limit the amount of crawling that we would do, which goes into the general category of crawl budget. And there's a blog post from 2017 about crawl budget. I would double check that for all of the details. The short version is that we try to understand when a server is overloaded, which means that the server might be slower or that the server is returning server errors when we try to crawl. And when we see that happening, we will step back with the crawling. However, that shouldn't directly affect how we show the site in search. So it wouldn't mean that we would rank the site lower in the search results. It's just we crawl less, so we have to be more optimized in our crawling. And that might mean we focus on more of the new pages rather than updating the old pages. And even in those cases, we would be able to rank pages properly, even if we can't crawl that much. So more crawling doesn't mean better ranking. Similarly, less crawling doesn't mean worse ranking. But if we can't crawl enough of your website to actually keep up, then that's something that would be problematic. So instead of focusing on the crawling, my recommendation there would be to try to understand better what is happening with the ranking side, with the traffic in general. The usual tips that I have there is to look at this on a query level. So to go into Search Console, look to see which types of queries have less traffic. And then you can also compare that to which types of pages have less traffic. So in Search Analytics, you can compare, for example, this month or this last month. And then you can see the drop in impressions. You can sort by the impressions that change the most. And you can look at the types of pages or the types of queries where these changes happened. And based on that, sometimes you can recognize technical issues where you see, oh, this part of my website used to get a lot of traffic, but now doesn't get a lot of traffic. Maybe there is a technical issue. On the other hand, maybe you can recognize general quality issues as well, where you see that, well, my website used to get a lot of traffic for these types of queries. But actually, maybe my website is not the best result for those types of queries, which could be OK where you say, well, I get less overall traffic, but I get more targeted traffic. And that could be fine too. You could also be getting less overall traffic and less targeted traffic in the sense that, well, I try to target those queries, but I'm getting less traffic for those queries. And that could be a sign that you need to just, I don't know, just as easy to say, improve the quality of your website overall. So that would be kind of the different directions I would take there. And it's hard to have one trick that handles all of this. But I would initially really separate the crawling side from the ranking side and really try to understand what kind of pages, what kind of queries are affected, and then dig in from there to figure out what exactly you could be doing to improve. Hey, John. Hi. Yeah, so I have a question regarding manual penalty. So we got a manual penalty for structured data a couple of weeks back for the content mismatch. And we resolved that issue and asked for reconsideration. But it got failed. So what other thing I should look after to resolve this issue? It's hard to say without knowing your side. So usually what I would recommend doing there is posting in the web match platform because the folks there have a lot of experience with structured data questions. And they can usually help you to figure out what you should focus on next. And the important part there is really to be as upfront as possible about what the initial issue was, what kind of pages perhaps were mentioned in the manual action and in the response to reconsideration request so that someone can really take an honest look at your web pages and say, well, this is something that you need to improve or maybe you accidentally forgot something here to get that honest feedback that you would need there. So just a query. So is there a chance that we have other structured data errors? So could it be because of those reasons, this can be an issue? I don't know. It's hard to say without looking at your side. Theoretically, it could be that there is something technically broken in the structured data on your site that makes it so that what we pick up would be not compliant with our guidelines. Theoretically, that would be possible. I think that's extremely rare, though. So for the most part, I would assume that you're marking something up that, according to our guidelines, should not be marked up like that. And sometimes that's a matter of interpretation. And people who have looked into a lot of these cases can say, oh, in this particular kind of case, Google would see it like this. Therefore, you should make a change like this. OK. And I have one more question. Oh, if you allow me. Sure. Yeah. So I'm trying to get my website for. And in the search bar, basically, in the search result, basically, there is something called search bar, which comes for some branded website. So I'm trying to get that search bar for my website. So I got to know that we have to add the scheme up in my home page related to the search bar. And at the same time, I'm trying to block all the URL parameter, which is coming for the search bar, for internal searches. So will it somehow impact the possibility that I'll come in the search bar? The search bar is coming in the Google result? I don't think that would play a role there. But in general, the site link search box that you're referring to, that's something that is generated algorithmically for the website based on individual queries. And we would only show that when our algorithms think that it's a relevant part of the search results page. So whether or not you have markup there or whether or not you have an internal site search page as well, that wouldn't play a role there. It's really our algorithm think that we should show a site link search box. And in that case, we would either show the one that we generate, or we would show one from your site. And if we have one from your site, then we would be able to show that. But it's not that because you have the markup, we will show the site link search box. So it's also something you could say, well, I will wait until I see this in person. And when I see it in person, then I think about how I want to have it presented. But it's not something that you can force. Got it. Thanks. All right, we're kind of running low on time. But if there is any last question, feel free to jump on in. Hey, John, I have a question. OK. So I posted a comment regarding a real estate site where we changed URLs about two years ago, resubmitted them. And they've been stuck in discovered but not indexed for over two years now. I was wondering if you see any reason why that would be. That's hard to say without being able to take a look at the site. Offhand, my guess would be that maybe these are submitted in a sitemap file but not linked like that within the website. Something that I sometimes see. And in that case, we would know about these URLs. But if they're not used within the website, we might think, well, we have other ones that we can use within the website. And sometimes with sites like real estate sites, that can be tricky because sometimes these sites just have a lookup bar, essentially where you enter an address or a city, and then it goes and tries to pull that information. And for crawling, we need to be able to find links that go there. And we generally wouldn't go to a search field and say, oh, let me try all the cities in the world to see what comes up. We actually have an extensive sitemap submitted and also on-site links for all the pages. Before we changed URLs, everything was working beautifully. After we introduced these URLs, which were probably about 800,000 new URLs, we thought it would take Google a few months to re-crawl them and detect that. But after two years, it still hasn't picked up those changes. OK, so what I would do is find the higher-level pages that are still being indexed and use the inspect URL tool to check the HTML that comes out from those pages so that you can confirm that Google has indexed links to those pages. Because if we know that the links are there, we can kind of flow the signals to those URLs and we can start crawling and indexing those a little bit more. That's kind of, I'd say, the first step there. The second step would also be to double-check that none of these pages are indexed or all of them are kind of like blocked like this. Only about 10% of the sites. So some of them are being indexed in that case? Correct. OK, that makes it more complicated. But that's why it's been very confusing because it's a real estate site, so we publish new pages every day. And 10% get indexed, the rest don't. And there's nothing different on them. If you could drop some example URLs of ones that you could use inside the comments. Yeah, yeah. Ideally, just respond to your own question in the YouTube comments part there. And I can pick that up afterwards and see if I can find something specific there that I can point you at. All right, thank you. Sure. All right, since we're kind of out of time, let's take a break here. There are still more questions submitted, which is a good sign. I have another English Hangout lined up for Friday. Next week, I'll be at the Webmaster Conference in Mountain View. If any of you are there, come and say hi. And I also have a German Hangout lined up on Thursday. And we'll have more English Hangouts, I guess, when I'm back from there as well. All right, so wish you all a great week, and thank you all for joining in. Thank you, John. Bye. OK.