 OK, so moving on to the next one. All right, welcome, everyone. Today's Webmaster Central office hours hangout. My name is John Mueller. I am a Webmaster Trends analyst at Google. And today, I have two guests and maybe more. We'll see. First off, we have Lizzie, who writes a lot of our documentation. So she's the one that makes sure that all of you have, especially the structured data information that you need to make sure that's all aligned and that that works really well. And we have Martin, who's the one that makes sure that all of you have, especially the structured data information that you have an echo, a line, whoops. I don't know, do you want to add an introduction? Sure. What do you do at Google? Hi there. I'm Martin. I annoy Google by coming in and annoying them whenever I possibly can. I'm currently an SEO consultant, but have done seven years of being head of SEO various bits of Expedia. Prior to that, I was head of SEO for Omnicon. So I have some big brand experience, not normally the one complaining about the documentation. So yeah. Uh-oh. Uh-oh. OK. I'll stay in the middle. Cool. All right. So as always, there are a bunch of questions that were submitted. I set this up fairly short term because IO was happening this week, and so many things were happening. I wasn't sure that I'd be able to get to do something like this, but I'm glad we have it running now. So there are some questions submitted, but if any of you who are here live want to ask first questions, feel free to go for it. Well, we'll wait in front of that to John Gay. I will get started with just a first question. I understand you announced that IO this week some cool new features that come to Search Console, specifically around the sites week. I was just wondering if you could talk to that a little bit more when the rest of us are wanting to get it, and specifically what the source of data is that you're using in that. So when is always a tricky question? We obviously wanted to kind of open it up at IO and have it already, but there's still some things that we're working out and where we'd like to get more feedback from people, which is why we set up that trusted tester form. So I sign up there. You're probably the first one to sign up, OK? And Barry is probably you and Barry were probably fighting for the first place. I don't know what we've said specifically about the data. My understanding is it's based on a Chrome user experience report, so making it a little bit easier to get into that. Yeah. OK. Is there any, so are there any other cool things from Search Console that were announced or may have missed? That were announced. Oh, but how to in FAQs? How to in FAQs reports? They're coming to Search Console? True. So similar to the other enhancements that are in there? They're there now. I think they're here. They're there, if you have how to in FAQ on your. Oh, you need to add the markup for us. I have seen another sign, the FAQ markup, so yes. OK, yeah. Cool, that'll be there. Then there are two things that are happening where I don't know exactly when they will come. That we talked about briefly. On the one hand, the opt-in for large images. That's something if you have large images and you want to have them shown in Search, then you can do that. And the other thing is for duplex on the web, there are the settings for that. So in particular, the aim is, so duplex on the web is a way to kind of streamline your checkout flow so that people can go to their Google Assistant and say, I want to buy this ticket from Expedia. And it basically goes off and does everything for you. So I think, I think that's pretty cool. And the setting there is mostly a test account so that you can specify test account username and password that the machine learning system will use to kind of learn the checkout flow. So that's something where I think for both of those, there's still a lot of work that needs to be done. And some of that might change over time. But that's at least what we've announced so far at IEL. John, I was a little bit confused by the duplex being a Google Search console because there's duplex settings in Google My Business also. Like, do you want to get the phone calls? Is that going to move also? Or are you going to have settings for both places in both locations? We specifically have it in Search Console because it's tied to your website. And it's something that could be available directly through Search as well. So that's why you put it in Search Console and not in Google My Business, where Google My Business is more tied to physical business. So for that, it makes sense to have the phone call setting there. But the duplex on the web is really tied to your website, which might or might not have a phone number that you can also call. Right. So you're thinking about making a reservation or ordering food online from a local restaurant. Does it use their online form? Or does it make a phone call or something else to make that reservation? So based on what we showed at IEL, it uses essentially your web checkout flow, which is what the machine learning systems are trying to learn and trying to do it in a way that is almost a higher level auto-complete, and that it goes through multiple steps. Outside of the standard accessibility guidelines, are there any guidelines specifically for forms that you want to be included in this? Or will they be coming? Or is it a matter of wait and see? So the team wants to be able to work with websites as they are. So that's the general goal. I think we obviously have various accessibility guidelines for forms, make it easier to auto-complete them. Those are things to do in any case, but specifically for this feature, we want to work with websites on how they are and not require that they make any specific changes. All right. Any other questions from any of you who are joining here live? Can we talk about Googlebot a little bit? Googlebot. OK. OK, so it went live technically two days ago. Did you do Googlebot? Did you ever read Googlebot? Well, we've been testing it for a while, so it's hard to say it went live because there's always this kind of transition period. So what did it go 100% live, or it's still transitioning? I don't know. I need to have the other martin here. But my understanding is it's 100% live. The only things that are not live yet are the testing tools. So in particular, what is it, the URL inspection tool and the mobile-friendly test, yeah. So I mean, it's a bit weird that those aren't ready yet, but we need to make sure that the normal calling and indexing works for us, and then we switch those over, too. So I expect that won't be too long, but I can't make promises for them. SEOs could expect a little bit fluctuations in the search results just because you're able to index a little bit deeper than you were ever before had? No. I think websites that we could index before, they shouldn't see any change at all. This is really just for websites that are using or focusing on these modern features in browsers that have content which we would otherwise have missed with the older version of Chrome. Well, that's the point. Now you're able to get to other websites or other content that you weren't able to. So maybe those websites are now potentially ranking a little bit higher than pushing down some other websites. So they may have an impact. There may be, or maybe not. I mean, you have these done tests on this, so. Yeah, I doubt you would see a big effect on that. So that's something where a lot of the websites that are already kind of in competitive areas, they already try to make their content so that it works in search anyway. So I could imagine there are some websites that are a bit, I don't know, focusing more on modern technologies. And obviously, those areas, perhaps, things shuffle around a little bit. But for the most part, I don't see that changing anything in any way that people would notice. I think this was announced at IO during part of the announcement, but is it now using HTTP2 exclusively or? No. Any thoughts on when that may or may not happen? So HTTP2 makes a lot of sense, in particular, for browsers, where you have kind of this multiple streams coming in at the same time. And for crawling and indexing, we don't really need it so much because we cache a lot of the content anyway. So it's not the case that we need to kind of do one quick fetch and render of the page with all of its embedded content right away. It's something that we could do independently and keep that content and kind of splice it together when we need it. So it's something we do bring up with the team because everyone's like, oh, but you're saying I should move to HTTP2 or support it, but you don't support it like what's up? But I mean, it's all backwards compatible anyway, so that shouldn't be any problem. And before I'm going to stop after this last question about Googlebot, a lot of people are asking, I see at least on Twitter, about two waves of crawling for some JavaScript web apps, and that's not changing. Could you explain that so people who aren't so technical can understand what that means? People who aren't that technical to explain how JavaScript indexing works. I think that'll be tricky. Yeah. As Martin's there, that's Martin to explain it. Sounds like Boston's here. Someone's coming. Okay, we have one more person joining us. So the, I mean, with JavaScript indexing, one of the tricky parts is we pick up the HTML content initially and we can index that right away and rendering sometimes takes a little bit longer. So sometimes that's a matter of, I don't know, depending on the site, depending on what all is happening, it can take a minute, hours, a few days, and something like that with this kind of delay there. So in particular for news websites, I'd still recommend that you have some kind of static content because we need to be able to index that as quickly as possible. But for any website that's more stable, then kind of this delay of a day or two that won't change much. Okay, I've previously heard it was much longer than a day or two. That's, it really depends. And it's something where the team is working on reducing that to make it as fast as possible, obviously. But it's not the case that you have to wait a month until your content is indexed. It's really kind of more a matter of like somewhere between a few minutes to maybe a couple of days. All right, thank you. All right, let me just take a look at some of the questions that were submitted. Well, big question about thin content. We have a clothing e-commerce site. Let's see, with, I guess, different products that are very similar. And some of these are crawled but not indexed. Would it be a good idea to exclude, I guess, the different variations from crawling and indexing? So in general, especially for e-commerce sites, what we recommend is that you try to focus on making the product pages stand on their own and being really, I don't know, unique products, unique things that people are actually searching for. So if you have different variations, that could be something like sizes or different colors, then I would kind of fold all of those into the same product page. So that we tend to have fewer pages to crawl. They can be more visible in search because it's more concentrated. And then you don't have to worry about the situation where it's my green page also being indexed or not. You just have one product page and it has different variations, different attributes that can apply to that. Specific to that answer and diagnosing it and the actual process of fixing it. Have you got any plans to put the items that are in the coverage part of Search Console into API where we can check this on a page-level basis independently of the front-end? And as a follow-on to that, there's only ever 1,000 lines given in that. When there's a couple of 100,000 pages excluded or crawled but not indexed, it would be really helpful to get more than that 1,000. Plans, I don't know about plans. We do get that question a lot. So that's something where I would love to see more features in the API. I think that helps a lot, especially the larger sites that can pull that data out and work through it. I think that would be really useful, but I don't know what the exact plans there would be. You know? No? No. No. Okay. Good, but I'm not missing out. Okay, my site dropped for most of the queries that it ran for. For some of the queries, non-ranking remains strong. Let's see. Will Google ever look at the moded content that was improved in the meantime to see if it fulfills the user needs better for previously ranking queries? Yes, definitely. So here comes another Martin. So definitely, if something changed on your website and we crawled and re-indexed it, then we'll take that into account. It's not that we're going to stop crawling just because we kind of stopped showing something as visible. So you don't need to know index it. You don't need to block it by robot's text. The general idea is if you have content that you do know you need to improve, then I would just improve it, ideally. Or if you really can't improve it because it's a lot of content that you would say, well, I don't know what to do with this content, then maybe just removing it is fine. But it's not the case that we would not update the website or update the content when we see it as being bad ones. If the user wants to speed up that process, would a fetch and render help for pages where they have? Yeah, so in your all-inspection tool, you can submit for re-crawling or re-indexing. That definitely helps, but that's on a per-page basis. So a segment file would probably help more if it's a broader change. Hi, John. Hi. Regarding content, since we're on that topic, I do have a couple of questions. And the first one I'm hoping is a lot more straightforward. So for all intents and purposes, for the sake of cleaning up or removing thin or low-quality content pages from a website, is no indexing that content basically as effective as just taking the entire page down? Yes. Okay. Modern or index, it's effectively down. I mean, it's still on your website. So in particular, if it's something that you say, you want to keep it on your site because you think users on your site might want to find it when they navigate within your site, then fine. It removes it from the Google index. So we don't show it in the search results. And from there, we don't really care about what is actually on those pages. Oh, great, great. And the second one, let me put my tinfoil hat on here because I haven't really heard of it being spoken of before, but it's the idea of content dilution. So for example, I have a service that I use copiescape basically to check for copies of my content across the web. And I've seen many cases where we'll get absolutely crazy garbage domains. Really, they look really sketchy. PDF files, stuff full of spun versions of my content. Many versions of PDF files, many versions of garbage landing pages that are actually cloaked and will redirect to something sketchy like online drug sales. Anyways, point being is, is it a possible thing that certain content gets spun so much and so many instances of garbage spam that the original content gets mistakenly identified as part of that too, if that makes any sense? I don't see that happening. So that's something, I mean, we've seen that situation over and over again. I think pretty much every popular site is used as a seed for a lot of these spammy sites that basically just scrape and spin content. So I don't see that causing any problems. So there is a way to differentiate the fact that the source content is legitimate and it's not part of the fact that you see it 200 other times in other sketchy or spammy ways. Yeah, I don't see that being a problem. I mean, we look at the website overall as well when it comes to quality. So if overall the website is good, then we should be able to treat that content appropriately. If overall the website is low quality, like these spammy scraped sites, then we should just treat that as spam and handle it like that. Okay, that's good to know. Thank you, because that's certainly a factor out of every web master's control. So yeah, okay. Great, thank you. I think the same thing happens with links as well. A lot of these spammers will basically take links to popular sites and put them on their sites and say like, look, I'm linking to a CNN. Therefore, my content must be legitimate and that doesn't change anything. So if you see random scraped sites linking to your site, that's not really something you need to worry about. Okay, that's a relief. Great, thank you. Cool, all right. Whoa. There's one from Martin just in time. Does the change for Chrome 74 impact Google's ability to trigger infinite scroll on pages? To a certain degree, yes. Basically, there's not a fundamental change in how we're doing it, but as we now support a bunch of features that you might use, such as an intersection observer, for instance, yes, you can now use that without a polyfilm in Googlebot. However, that being said, make sure to test this. I know the testing tools haven't been updated yet, but make sure that the content you care about is indexed, is being indexed. And honestly, if I were you, I would just keep the polyfilm for a couple of more. I don't know how long, we don't have a timeline, but like keep the polyfilm around, there might still be benefits for having it until you can definitely test our testing tools. So. There was also a question earlier, I think, from Barry. Did we switch to the new version of Chrome completely for crawling into Exit? Yes. And when was it? Yes. Yes. So the thing that we do is, as you know, we keep experimenting on new stuff with Googlebot on very, very small sets of URLs, basically. Very small samples, sometimes, just like basically a couple of URLs, really. But we continuously improve or increase the amount of the sites that we would be crawling with Googlebot over the last couple of months, very carefully monitoring what was happening. The things, the issue that we confirmed that happened a couple of months back has nothing to do with rendering. But yeah, so we have been increasing, continuously increasing the sample size of URLs that we were crawling with the new Googlebot and have ramped it up to 100% already. I don't know the exact day when we did, to be honest. I don't have it on top of my head because it just went smoothly and... Was it from like 10% to like 100% or was it like? No, no, no. It was less than 1%, 1%, 10%, 20%, 30%, 15%, 75%, 100%, I think were the steps that I have observed. So if you could send me an email with exact dates and percentages. Sorry? If you could send me an email with exact dates and percentages, that would be use of as joking. I don't know if we have like that much... I'm joking, I'm joking. Previous crawls. But basically it was a pretty rolling thing. I just sampled it at random points in time and checked in with the rendering team. Zoe is in the rendering team. The person that was yesterday with me on stage for that specific session. And I was as excited about it as everyone else was. So Zoe, how are we staying? So I have observed these things, but I don't think I know the dates specifically. But the whole process started a few months ago or a year ago or in terms of the 1% testing? Can we say that? I have no idea. I don't know. So I remember I talked to Zoe in December last year and I think that was November. In November we were at 10%. Okay, interesting. Very nice. And the indexing bugs have nothing at all to do with this at all. We're talking indexing, not rendering. I know, but who knows? Connected in some way. Fair question, but no. Awesome. The caching date has nothing to do with this either. No. Okay. I'm quite surprised how many people can't ask about cache. Cache is like a nice convenient feature that we offer, but it is not related to work. I'm sure you get it a lot, but I get like five to 10 emails a day saying, why is the cache date a Google wrong? Like a month ago, like from a month ago, I'm like. I know. So you're saying the cache date is related to the emails that you get? Yes. Direct call. Do you filter your emails based on the cache date? Okay. Will you sex two emails? No, I'm okay. Okay. Oh yeah. Okay. Totally different question. We're selling variations of Mexican flags. Cool. The variations are linked with Mexican tables, Mexico table flag, Mexico hand waving flag, et cetera. Our preferred page in search is cross linked from the variations with Mexico. Is this anchor text okay, or should we use Mexico flag for our preferred flag? I think you can link either way. We do use the anchor text from links as a way to understand the context of the page a little bit better. But if your whole website is about flags, you don't need to mention flags for every city and every country that we are there. Wouldn't it be the flag type that would be probably your preferred anchor text in that example, table flag, or anything like that? Yeah. Yeah. I mean, it depends on how you have it set up. If you have one page from Mexican flags and from very linked to the different variations, then sure, yeah. All right. The indexing issue or an indexing issues, but stories seem not to be surfacing in a realistically timely manner, particularly for keywords individuals for whom we have very solid rank. Stories are popping up a day or two later or not at all. What we're seeing fairly good outlets surfacing some of the results are several days old or even weeks old in favor of other outlets with more newsy content. Is there some other indexing issue with newsy content? I'm not aware of any issue. You guys know? I can, so this is one of the things I work on every day and there are occasional issues, but nothing wrong now. Okay. It's good. Okay. I mean, it's always good to have kind of a neutral confirmation. Yeah. To be fair, there's an extension to that question though. There is still the outstanding bug of Google picking up incorrect dates on news items. And I'm interested whether or not the new renderings will make any difference to that because my supposition is picking up the incorrect dates from ad containers where it is rendering the contents of them. So I, it may or may not be related to what this question asker is asking, but certainly I have seen examples where a news outlet told you something, the wrong date is picked up and then that news piece may not be able to continue to be answered. So that may be something that that person should look at. So it's what Google is perceiving in the published data. So, I, Michael. Hi, thank you for answering my question. It's just, I think like in the last 48 to 72 hours, like no complaints about sort of the sketchy outlets in my sector surfacing, because sometimes you wonder like, where is this coming from? They're all legitimate outlets, but definitely seeing stories where like there is kind of news in our sector, but there's stuff from like a week ago and then you, as you keep sort of scrolling down, it's like a week, two weeks, a month ago, and you're like scratching your head saying, there is some new stuff going on. And then it does pop up sort of a day later, sometimes not at all though. Yeah. No, I don't know. I mean, sometimes we do have weird fluctuations that happen. So it might be something that's just, something temporarily out of sync. With the dates question, one thing I heard from someone at IO, which I don't know is still the case, is sometimes there's a mismatch between the top stories date and the normal search results date. That's something that I thought we had fixed, but I need to look into if that's still an issue. Great to see how to roll out to the web. I know there's a search appearance filter in Search Console for how to snippets that show in search results, but what about when it rolls out to smart displays? Will there be a way to measure that in Search Console? If so, will the voice query show up? And will the reporting show you how many steps the user got through? I have no idea. Anyone? Any takers? Come on, come on, come on, come on. I have no idea. I mean, a lot of these things where we're still very early stages, so we'll have to see how that works out. I'm curious to see how that ends up working with, especially the smart displays. I can see that being pretty useful. But I don't know how that will show up in Search Console. We'll see. Is crawl budget more a matter of crawl depth or of a volume of pages? So for us, crawl budget is essentially how many URLs we would fetch from a website on a day. So that's kind of the, I guess the volume of requests that we'd be able to get. For most websites, that's not an issue because we can get as much as we want. And for really large websites, it is more of a problem because we feel we're more limited by the server resources and we don't want to cause problems by trying to get all of their fresh content as quickly as possible. And usually the hard part there is not so much finding that limit, but balancing the needs of what we would crawl during that time. So on the one hand, we want to get all of the fresh stuff, so we'd have to look at the home pages regularly, the higher level category pages regularly because from there, the content is linked. Then we need to get that freshly linked content, but we also need to update the existing content over time and kind of make sure that we're not missing anything that otherwise isn't directly linked on the page. And that also includes all of the embedded resources that we pull in from JavaScript, CSS, images, all of that comes into play there too. So it's not crawl depth. Essentially, it's more that the depth we try to pick up by scheduling the different pages. It's really just purely a matter of number of requests that we make to the server so that we try to save a lower number that ends up causing problems for the website. Can I specify something about that answer? You started it by saying we look at the certain number of URLs for each site that we're crawling. You mentioned URLs a couple of times through that. Is that tied to a hard number of URLs or a total transfer size? It is much that if I reduced a website's pages from 10 megs to 300K, would that dramatically increase the number of pages they can crawl? I don't think that would change anything. So it's a pure URL, but request is not the... I mean, what sometimes happens is if you have a large response, then it just takes longer for us to get that. And with that, we'll probably crawl less because we're trying to avoid having too many simultaneous connections to the server. So if you have a smaller response size, then obviously we can get more simultaneous requests and we could theoretically get a little bit more. But it's not the case that if you reduce the size of your pages and suddenly we'll start crawling. It's also that when the response takes a long time, it's not just the size of the response, it's also the response time. Servers tend to respond slower when they're overloaded or are about to be overloaded. So that's also the signal that we're picking up, like, ooh, this takes a really long time till we're getting data on the server. Maybe we should look into the crawl limits, the host load on this particular server so that we're not toppling the server over. But that also kind of a resource on the page that was served potentially by a third party that was being selected in response. Oh, third party? No, no. OK. We look at it on a per server level. So if you have content from a CDN or from other networks, other places, then that would apply to their crawl network, essentially, because how slow an embedded resource is doesn't really affect the rest of the crawling on this site. OK, thank you. Sure. We're trying to clear our sites from being banned on SafeSearch. Some of our pages are now available under SafeSearch in Europe, but not available in the USA. Is geography a part of the factor that determines what is adult content and what isn't? I have no idea. SafeSearch is special. My understanding was that SafeSearch is SafeSearch, and it's not different across different locations. But it sounds like you're seeing something different. So it's hard to say. I don't know. I can ask the team to see if we can figure something out for the next one. Is it ability to pull all Search Console data into Data Studio anywhere on the roadmap, especially page speed and errors? So we don't even have page speed in the UI yet. So that would be a little bit early. But I think, in general, I'd be a fan of having all data available for a different API. But it takes a lot of work to get that there and to maintain all of that. So I don't know. There is a community connector for Lighthouse, at least, for Data Studio. But the Lighthouse team at Google probably could do a better job of integrating that as well. OK. OK. Do you know anyone from Lighthouse? I do. OK. I have to know all that for that particular app. OK. I do. Cool. I'll paint them. Oh, he's going to get by now. Oh, right. Why do you invite me out? If you could just CC me on my website. Oh. Because I'm not a good instance to me, that's OK. OK. Let me just see some questions here live. I've been noticing that content hit under tabs. On the mobile side, it's not showing the same way in the search results as was promised. What gives, Google? So what generally happens with content that is hidden behind a tab is we will use it for indexing. We'll use it for ranking. So that's something from, especially with the mobile first indexing, when we index the mobile version of the page, that's not a problem. So it shouldn't affect ranking. But what will happen is we won't show it in snippet. In particular, the snippet, we try to separate that out because if we show something in the snippet, it feels like we're really promising the user that they'll see this when they visit that page. So if we know that this is hidden by default, then we won't show it in a snippet. But from a ranking point of view, it will rank normally. So that should be fine. I have 300 URLs in robots.txt file with disallowed URL parameter. They also have no index, no follow tag. But in Search Console, they're still shown as indexed. What's up? So you're doing almost too much to make that happen. In particular, if it's blocked by robots.txt, we don't know if there's a no index tag there. So what will happen is we will index the URL without its content. And that's probably what you're seeing in Search Console as the index counter. So what you need to do to prevent those from being indexed at all is to allow problem and instead to only use the no index meta tag on the page. And then as we recrawl those pages, we'll see no index, and we can drop them completely out of the index. And again, just to be clear, it's not that we're indexing the content on those pages that are disallowed from crawling. It's really just we're indexing the URL, and we're picking it up based on links to that page. Maybe we're showing the anchor text as a title for that URL, but the snippet should be like we can't show you anything, and it links to the help page on robots.txt. The Search Console shows different menus to different websites. For example, I have one with a products category, an e-commerce site, and not in another one. Yes. So we try to show you the categories where you have data for. So if you don't have specific structured data types, then it doesn't make sense to show you that report because there's nothing to show. So some sites will have things like products. If they have product structure data that we picked up, or how to, if you have how to information marked up, but other sites won't have that in Search Console. Why doesn't Adobe Reader ring for click here? I don't know. What are you trying to find when you search for click here? That seems like a very weird query to search for. It's a historical reference, too, yes. I should elaborate now. I was just referencing your comments about anchor text and links and stuff. I don't know. I have no idea. I mean, what should we show for click here? It seems like one of those pre-release where you could argue what it should be showing. It's so ambiguous. Yes. You should W3.org, which seems an appropriate answer. Oh, yeah. Some place to click, I guess, yeah. OK. Info operator, it's gone now. Can you confirm that in the site move or page move URL inspection tool, we can expect the new URL to be canonical? Specifically, when the site colon query is showing the viewer. OK, I'm not completely sure what you're asking. But yes, the info colon query operator is gone. I think that's been gone for a while now. We recommend using the URL inspection tool to look at the canonical. If you're using that to look at the canonical, the site colon operator doesn't show you the canonical. So with the site colon, especially if you've done a site move, we'll try to be helpful and say, if you're searching for the old domain, then we'll show you the old domain, even though we've processed that site move already. So that's sometimes a little bit confusing. So with a site colon operator, you tend not to see the canonical. Sometimes, if you look at the cache page, you'll see that we cached the new URL instead, which is also a sign that the site move has gone through. That was a great session at I.O. with Martin. Ooh. Yeah, that one. Oh, that one. Yeah, I really love that session. When testing and landing page URL in the structured data testing tool, it reports error in breadcrumbs. When pasting the source code of the same page, it doesn't show those errors anymore. I checked through the code and can't find what the problem is. I don't know. It sounds like a bug on the other side. That sounds like a bug. Yeah, I'll do that in a second. What you can do is you can post the, if you feel like it, you can post the URL here. It has a, OK, perfect. I'll take a look at the URL and see if I can spot a problem. And if it's a bug in structured data testing tool, I'll be happy filing it accordingly. Cool. And thanks for the feedback on the session. Google is not showing any lazy loaded image alt text. What am I doing wrong? I followed Google's advice on lazy loading, added data alt, and no script to my code. Rendering is fine, and there's a link to a screenshot. OK. OK. That sounds like you want to look at it, I guess, yes. OK. Sorry, the page does not exist. OK. OK, so generally speaking, I am surprised. So if I understand correctly, you're lazy loading the images, which means you have the images in the original source code. And that should include the alt text as well. You don't really lazy load alt text normally. You should have that in the regular HTML. If you have a no script fallback, then that should also just show up. And I'm not exactly sure what's happening. But if you mean like an infinite scroll kind of thing and you load the entire content dynamically, then that can happen. There is only so much that we do in terms of infinite scrolling. We need to improve our guidelines for that one. I agree. We will do that, I guess. Now that you sit next to me and nod, that's probably mean so I have more now. OK. There's little more in the file. So yeah, if it's lazy loading, then that's something that can sometimes go wrong a little bit, especially because we can't just, like, obviously we can't infinite scroll, surprisingly. You can't just take infinite time to do that. But I don't have good guidance on that right now for you here in Prompto. We would have to look at this in more detail. That's what we kind of doing after I go, yeah. Cool. All right, John, can you tell me when Google is going to fix the cache error? Not a single web page is cached at the 30th of April. And it's affecting my rankings as well. So there's a bit more here. So Martin says web pages are being cached. So I've seen this on Twitter a few times, and I looked at some of the sites that do update fairly frequently, and they seem to be cached fairly fine. So I think what you might be seeing is just some side effect of some of the indexing issues that we've had in the past, and maybe it's just taking a little bit more time for the cache to update. But in general, the cache page is not reflected of the index page. So that would not be affecting any ranking. So if you're seeing issues with the rankings, then that would not be from the cache page. We're a news website, and we disappear from the top stories. We think Google is confusing our site with a forum since we have structured data. What can we do? I guess the structured data is news article structured data, so that would be fine. Perform like this Q&A page. I don't know. So in general, I think the important part to know is we don't show all pages in the top stories section. It's an organic search feature, and sometimes we show these pages there, and sometimes we don't show them there. It's not that there is anything manual on our side where we'd say these sites would not be shown in the top stories, just because they also happen to have a forum or some kind of discussion on those pages or in the site somewhere as well. So that's something that would be totally unrelated. I think we've had a question from you a few times about the top story section. It's really, it's an organic search feature. It's not that there's something manual that's blocking your site, in particular, from appearing there. All the cache pages. Oh, no, your cache pages are 404. OK. I think. I'm not saying that, but I have any effect on ranking. What, so I'm just agreeing that I am 7404. The thing that I would like to call out is this question had two parts. And there's like, it's not catching web science, and that's like hurting my rankings. And those two are not related. Completely disconnected, as far as I'm concerned as well. Yeah. OK. Just to make that. OK. I mean, we have seen this from a few people with the cache page. So I know there are people at Google looking into this to see what is happening there specifically. But like I mentioned, the cache page is not reflective of what we have indexed. A pretty direct way to see that is all of the JavaScript-based websites we cache the HTML version of the page. We don't cache the reader version of the page. So those are completely different pieces of content there. We do try to keep the cache more or less up to date so that we can show it to users when they need to look at the cache page. But for the most part, it's really separate from the rest of crawling, indexing, and ranking. Cool. I think we made it through all of the questions that were submitted. Anything else from any of your sides or any of you? From my side, I mean, multiple people have asked it. And I asked it last time I was sat here as well. It's just basically, and I want everything else that's in Search Console available via an API or at the very least, course it across to Data Studio. That's it. OK. OK. Can you ping someone on that, Martin? Yeah. I am just ping this. Again, CCB. Absolutely. I think we're talking with certain console people quite a lot and we forward feedback. We hear from a lot of people that they want more stuff in the API. So we always push for that. It's always tricky because they're limited number of people. So on the one hand, add more features to Search Console, move some of the old features from Search Console to a new one, or should they do more in the API? It's hard to find the balance there. I do have a better question than that. You did announce a couple of months ago, or a month or two ago, the indexing API for jobs and something else. You asked for it? Thank you. But jobs is only one I cared about, so that's why I remembered it. Sorry. Any plans to roll that out any further? I don't know. I think, since it's still fairly new, it's something where I expect the team will be collecting feedback over time to see how it works out, how people are able to implement it or not, and also to see, does this really change the way that we can crawl and index content? Or is it just another complex feature that people have to implement that doesn't actually change things in a way that it affects them? So that's something where I expect for us to collect feedback over a while and then at some point to figure out, can we expand this to other structured data types where it makes sense to get this content fresher? Could we expand it to the general web as well? I don't know. Really hard to say. How's it working for jobs? Well, the concept of it is fantastic. I wouldn't comment as to how well it works or doesn't work because I haven't looked at that, but it would answer a lot of other problems, not specifically the general web, but rapid indexation of news stories is something that any site that's dedicated to that struggles with. I think we all try and give you guys as many signals as possible to come and index something, but then these sites all have tens of millions of pages as well, and I understand that crawl budget on them is a finite resource. So if we had a way of just saying, hey, listen, these are the 1,100 news articles that have been published today, that would be hugely beneficial. Because it'd save us spending inordinate amounts of time experimenting with things like Pub-Site and historically Pub-Site, Pub-Pub, and so on and so forth. OK. So specifically from the news site. Yeah, I don't want to restrict it just to that, but I think anywhere where it's important to have up-to-date of the media information so outside of news, that might be possible, but for me, I'm thinking. OK. Cool. I don't know, Barry, what do you think? Does your content need to be indexed faster? No, absolutely not. Second I post it, it's literally an index within a few seconds. It's amazing. I know, but despite, I mean, Barry produces Yeah, five pieces of content a day. which is phenomenal. But when you get to 1,000 or 1,500, some of them get missed. OK. I'm not a content spammer, so. Don't think there's a challenge, Barry. No. I have a question for you. You were all at I.O., right? All of you? Yeah. Could you tell us, each one of you, tell us what was the most important or most... What announcement was the most exciting for you guys individually? I have a very clear opinion on that one. OK. Well, the Google buy. For me, it was the live captioning videos. Oh, yeah, the live captioning. OK, so it was pretty cool. He said, personally, it didn't have to be... Don't do live captioning. Definitely live captioning. Yeah, that was pretty cool. Like, if we had that now, we wouldn't have to have people captioning these hangouts, right? Sorry. I mean, I love that people are transcribing these hangouts. I think that's fantastic. I think that someone is going to write that at some point of the next 24 hours to get published. Wow. YouTube transcribed them automatically? I think it's really cool, especially the kind of a combination of that with translations. I think that would be really cool. It sounds like a spammer's delight. I don't know. But, you know, another thing about it, I think the most useful was live captioning, and the coolest, I think, was the AR from Search. Oh, the AR. The shark. That was amazing. You think that was cool? Interesting. I would have gone with the podcast. Yeah, I find that cool. Sharks are cool. Yeah, definitely sharks are cool. Sorry? Sharks are definitely cool. Sharks are cool, but also the fact that they use the 3D graphics format that I have been advocating for a couple years back. So that's pretty cool. There you go. I would think the pod for me was probably the podcast audio searching in audio files, which obviously has to be good with transcribing automatically. So that was pretty cool. Yeah, I think the podcast is also really neat. Yeah. I don't know. I think there's lots of cool stuff. What's always, I find it a little bit frustrating with I.O. is that we all try to get as much stuff launched by I.O. as possible. And we do manage to get a lot of stuff launched there, but sometimes it's almost ready, and we want to kind of get people excited about it, but it's not ready yet. And I think the worst ones are the ones like, oh, it's live, and you can have it if you're in the US. Or take a photo of this QR code for this wonderful access. QR codes are cool. OK. Cool. All right. So I think with that, we're pretty much out of time. If more questions come up, feel free to drop them into the next Hangout. I probably have some set up for next week or the week after that. Otherwise, feel free to jump by the Webmaster Help Forum and post there or try to reach us on Twitter where we're all hanging out as well. All right. Thanks, everyone. Bye. Safe flight home. Bye-bye. Thanks.