 All right. Welcome, everyone, to today's Webmaster Central Office Hours Hangouts. My name is John Mueller. I am a webmaster trends analyst here at Google in Switzerland. And part of what we do are these Office Hour Hangouts where webmasters and publishers can jump in and ask questions around their website and web search. As always, looks like a bunch of questions were submitted. If any of you want to get started, though, with the first question, feel free to jump on in now. Well, John, I'll take a stab at it. My name's Tom Goreng. I have been doing this for about 15 years, just a hobby. And my niche is the Navy, the United States Navy. And as an example, one search term, Navy PRT standards, I just put it in the chat. It delivers the first or one page for the first seven results. And that's not common that I see that, but it does happen. In a few areas of my niche that has tabular data or charts that are being delivered. And what I'm seeing more and more of now is a number of sites creating a page for each small little bit of information. So in this particular case, he's got, well, it's actually more than seven, but you return seven to describe one thing. I'm seeing this more and more is it haven't pages? Is it something Google wants us to do is to break one page up into multiple pages to make it look like we have more content than what probably needs to be delivered on one page? Or is one page a better? I think you probably know what I'm asking. Yeah, I think there's no absolute answer there. So on the one hand, we recently rolled out an update to make sure that there is a bit more diversity in the search results. So for the most part, we'll limit it to two search results entries per site. There are some cases where we do show more. So some really, I guess, obvious cases are if we can tell that someone is really looking for one specific website, we'll obviously try to show more content from that website because that matches what we think the user is looking for. With regards to whether or not you should split things up or combine things into fewer pages, ultimately, that's always a balancing act. On the one hand, by splitting things up, you have more pages on your website, which might be better focused. But on the other hand, those pages individually have less value. So if you have, I don't know, 10 value for your website overall, and you split that across 100 pages, then each of those pages is going to get a lot less than if you just have 10 pages. So that's kind of what you end up balancing there. And some sites say, well, we have a lot of detail information. We'll split things up, and we'll try to rank for those kind of niche terms. And other sites kind of focus more on the head terms and say, well, we'll combine more of our information on fewer pages and make those really strong pages within our website so that they rank really well for these more generic terms. So that's something that is almost like a strategic decision on your side. My general recommendation to kind of the average website is always to reduce the number of pages rather than to increase them. So if you have the choice between making more pages or making fewer pages that are better and you're kind of torn, like which way should I go, then I'd recommend focusing more on fewer pages, making those fewer pages a lot stronger. And then over time, as you see that you really have kind of the ability to make individual more niche pages, then maybe that's something to expand on over time. But definitely in the beginning, instead of creating all of these millions of pages that I don't know, millions, or lots of pages focusing on individual pieces of a problem, then you're usually better off by just having fewer pages that are a lot stronger in search. Thank you. Hello, John. I have another question if you let me, I want to ask. Sure. OK. It is about multi-language websites. I have a website with seven other languages. And I want to join in Arabic market. And I wonder if I choose Arabic language as default language of my website. This will change my rankings on Arabic countries or not. I assume you have the different languages on different URLs. Yes. And I want to focus on Arabic language. And if I choose Arabic language as default of my website, this will boost me or not in Arabic queries. So by default, do you mean the X default in the hreflang setting or original language, home page language? Home page language. Maybe. I don't know. It's hard to say. It's not totally obvious that that would always work. Usually if you're not translating the home page, and the home page is one of the pages usually which are linked the most from the external web, then the home page has a little bit more weight. So if you have the home page in Arabic, then probably we'll be able to pick up. It may work. OK. But especially if you have the home page also translated, and with the hreflang links between the translated versions, then for us, they're kind of a cluster of pages that we would treat similar to the home page. So it might help, but I don't think it would be like a secret recipe for no one. It's not a major factor, as I can understand. May I ask another question? Sure. OK. It is about internal links. And let's say I have a page with seven internal links, and I take them with no follow tech. I wonder this will affect my link to this or not? I'm in the link power of that page. Yeah. So with the hreflang follow on the links, you're basically telling us not to pass any signals to that page that you're linking to. So it doesn't affect. So it wouldn't help those pages. And also it doesn't decrease the power of that page, the link power of that page. I don't think it would work that way, yeah. OK. OK. Thank you very much. And also I have other questions, but I need to stop in here, and I will take some later with writing. Thank you. OK, cool. OK, let me jump through some of the questions that were submitted. And if any of you have questions later on or more comments along the way, feel free to jump on in. And let me just mute you, because there's a little bit background noise. We have a bunch of URLs with non-Latin characters. Would you recommend that we change the characters or can Google crawl these URLs with no problem? We should be able to crawl those URLs with no problem. That's something I think we've been doing it for a really long time. That should just work. What are the webmaster guidelines on meta description tag? What's the ideal length? Does Google penalize pages with long meta descriptions? You can make meta descriptions as long as you want. There is no ideal length that we recommend. There is no maximum length. Make them long, make them short. If they're very long, then we will tend to cut them when it comes to showing them in the search results. If they're very short, we might take pieces of text from the page itself and show those in the snippet as well. But there's no penalty for any of that. As far as I know, there is no ranking effect at all from the meta description within the page. Question about the rich results in a search performance or search appearance report, we're seeing that since May 21, the rich results account goes to 0. This is for a job site. So I'm just paraphrasing the question a little bit. I looked into this a bit with the team to figure out what was happening here. I'm not sure which site this involves, but I did see it on one of the other job sites as well. And essentially, what kind of happens here is we see different kinds of job listings as potentially also being seen as a rich result type. And depending on how we're showing those job listings, they might be counted for one or the other or for both. And I think looking into another site that had a similar problem like this, or problem that saw a similar change at least, we essentially just didn't count that as a rich result anymore because we already counted it as a job listing or job detail entry. So it doesn't make sense to kind of count that twice for different types. So I suspect that's kind of what happened there. Can I ask you to follow up on that? Sure. So are you saying that rich results is sort of a catch all at this point? And then perhaps later on, you'll parse out different types of rich results, and they'll be counted uniquely, and which is also maybe double-counting some of them for now. Yeah, I think at the moment that might be happening. That's something that I'm always in discussion with the team with regards to how we should count different results types. And I have definitely seen that happening, where if you look at the rich result count and you look at a specific type as well, then the counts are very similar. And that, to me, points to us kind of double-counting those as different types. So if you look at it overall, then that's not visible. But if you look at it by search appearance type, I think it's called, then you would see that. Thank you very much. And I think that's pretty confusing. I wish we could make that a little bit clearer. And I'm not quite sure which direction will go there because it's similar to something that we've touched upon before in the past in that, on the one hand, we want to make it possible for you to have a quick overview of kind of the bigger picture, where something like a rich result type would be useful to see. On the other hand, we also want to make it possible for you to dig in and say, like, for this specific type of rich result, what were my results there? And finding kind of the balance and which result type goes where is sometimes a bit tricky. We have a DIY e-commerce site and many of our blog how-to articles are now de-indexed from Google. From looking, I think this has something to do with EAT, rating guidelines. So these articles are written by builders and people with DIY experience. How can we show this to Google? Do we set up an author or biography page for each article? All of these things. So I think, first of all, it might just be a matter of kind of phrasing it. But one of the things you mentioned there on the one hand is you said that these pages are de-indexed by Google. That's kind of the first thing I would double-check. If you're not seeing traffic to those pages, I would double-check to see if these pages are actually still indexed by Google or if they're not indexed by Google. Mainly because if a page is not indexed by Google, then most likely it's more of a technical issue, that maybe there is no index there or there's a redirect or rel canonical or something that's blocking indexing of that page. And those issues are usually pretty easy to kind of narrow down and to fix. So if you're really seeing that this is an indexing issue, then I would look for technical issues. You can tell if it's an indexing issue by taking the URL and just searching for that URL directly, then you'll see right away, is this page found in search or not? If it's found in search, then it's not an indexing issue. If it's not found in search, then it might be an indexing issue, and that's something, like I said, with the index coverage report, you can probably drill down and figure out where that's coming from. If it's not an indexing issue, so if these pages are actually indexed and they're just not ranking as well, then all of the things you've talked about, I think, are good steps to take. So anything that you can really do to increase the quality of your website overall, that's something that you could work on, that you could work to improve. So that could be things like explaining where these authors are from, where this content is from, how your content could be seen as trustworthy or not. In general, with something like a DIY blog or a DIY e-commerce site, I suspect that the EAT guidelines are not that critical for your site because it's not that you have to have like a PhD in DIY to be a trustworthy source on how to, I don't know, paint something. So from that point of view, I'd caution against kind of going too deep too quickly and trying to find ways that you can just generally improve the quality of your website overall. And this is sometimes easier said than done. It's really something where if you've been working on your website for a long time, then you'll feel like my website is fantastic, how dare anyone come and say my website needs to be improved in quality. But sometimes getting input from other people who also run websites or getting input from people who are interested in the topics of your website but not associated with your particular website, that can be really useful to kind of get that feedback and think about ways that you can kind of really take things to the next level. The question about event markup, we have one customer who marks up events with structured data markup, but their event-rich snippets don't show up in search. Their competitors have exactly the same markup, but their rich results kind of show up. What could be happening here? So when it comes to rich results, we have multiple things that need to align in order for us to show them. On the one hand, it has to be technically implemented properly. You can see that by using a testing tool, the rich results testing tool or a structured data testing tool to see if it's properly implemented. If it's set up in exactly the same way as other people have it set up, then probably the technical thing is a quick check that you can see and see that it works. The second thing is it needs to comply with our policies. And the policies are in the developer documentation. I double-check those. And the third thing, which is kind of the tricky one, is we need to be sure that the page or the website is of high quality overall so that we can really trust this particular markup and highlight that in the search results. So if technically everything is OK, if you're OK with the policies, then it's probably worth taking a step back and thinking about quality overall, which is similar to the previous question as well. So sometimes that's kind of tricky. And another question about EAT. A question possibly relating to EAT, we have a customer whose product pages are well optimized and contain both brief information about products and the ability to purchase. These pages rank number one for informational queries, but frequently don't rank at all for purchase intent queries, while their competitors with similar but less optimized pages do. Is it possible that the portion of the site, after the add to cart link has an effect on ranking for purchase intent queries? Their add to cart leads to a different subdomain, and the cart page shows a 403 error to bots and can't be accessed directly to prevent abuse. Could this be a factor? So we don't need to be able to crawl the add to cart pages, so from that point of view, if you're blocking those with the robot's text, if you're blocking those in other ways, that's perfectly fine. That's up to you. When it comes to evaluating the quality of a website overall, we evaluate the pages that we can index. So anything that is crawlable, that returns content, that is not blocked by no index, that's something that we can take into account to evaluate the quality of the website. And that's something that primarily plays a role in kind of how we rank those pages for individual queries. So with that said, I think you don't need to worry about the add to cart section kind of being blocked on a different subdomain. That's perfectly fine. That's totally up to you. It might make it harder for things like other complete, but ultimately, that's something you kind of have to work with with regards to usability and is not something that would play a role with regards to SEO. With regards to ranking for purchase intent queries, that's really hard to say without knowing some examples of what you're seeing. So in general, we would kind of see these as being similar queries. And we try to match the keywords and the synonyms to see which of these pages belong together. And usually, e-commerce sites are pretty obvious in that these are things that you can buy. And there's information about kind of how to buy it, how to get it delivered, all of that to tell us that this is an e-commerce site. So it feels a bit weird that we wouldn't be able to pick that up properly. So what my recommendation here would be is maybe to go to one of the Webmaster forums and chat with some peers to see how they would see it. Is there anything specific for individual queries that is not working well that might be escalated maybe to us directly so that we can take a look at specific queries and specific results on your site? Question about XML sitemaps. If you generate a dynamic XML sitemap for your website, that's always up to date with new modified and deleted URLs. Let's see. If you, in addition, keep the correct date and timestamp for each single URL when added or modified, will that help Google to faster read and index new and modified content on the website compared to not using XML sitemaps? Yes, definitely. So within an XML sitemap, you can list all of the URLs that are on your website that you want to have indexed. There are different attributes that you can specify for each individual URL in the sitemap file. The one that we care about the most is the last modification date. So with that last modification date, if you tell us this page has significantly changed on this particular date, we can double-check our records and say, oh, we haven't crawled that page since that date. And you're telling us it has just recently changed, so we should go and crawl that as quickly as possible. So an XML sitemap file definitely helps us there. When it comes to really small websites, we can generally re-crawl the whole website fairly quickly, so that's less of an issue. But especially for larger sites where maybe some product on your site has changed and that's linked through different levels of categories, then us finding that product will take a bit of time. So we wouldn't be able to find that change as quickly as we might otherwise. And with a sitemap file, you can tell specifically that product back there has changed. Go check it out. So definitely the last modification date is the one that we watch out for. The change frequency and the priority in sitemap files we currently don't use at all for web search, just because we found that it's not really as useful as we initially thought when we worked on the sitemap standard. At the moment, we're using five IPs for five SSL domains. We're switching to a new system where we can serve all five domains on one IP. Do you see any problem? That's perfectly fine. You can serve SSL certificates or TLA certificates for different websites on the same IP address. That's certainly possible. I don't see any problem at all with regards to Google for that setup. Lots of sites do that. Then a question. So I look into, I think this is a site that has pinged me on Twitter as well and posted on Reddit a bunch of details. So there's a site that dropped heavily in rankings after subdomain had been hacked. And they fixed it. And they're still kind of dropped in rankings. If that could be something due to Google's pirate algorithm or kind of one of the other algorithms there. I took a look into that a little bit to see what was specifically happening there. And it is really rare. But sometimes it happens that a website is hacked in a way that we think this website has significantly changed. And when that hack is resolved, it still takes quite a bit of time for everything to settle down again. And I think that's what's happening here. It's not that there's anything exotic happening with this website, anything kind of manual that you need to unhook. But more that our algorithms are just kind of in this cautious role of like, oh, it changed in a really bad way. And we need to be sure that the current change to kind of back to a good website is actually a stable change. And sometimes that takes a bit of time. It's pretty rare nowadays. It used to be more of an issue in the past. And nowadays we're able to recrawl and reprocess the site after it's been hacked fairly quickly. But it looks like it's still a bit slow here in this particular case. I also passed this on to the team to take a look to see if there is something that we could do to improve kind of the speed of our algorithms in cases like this. Then a question about manual actions, reconsiderations. Does the domain history affect the priority of reviewing the request for removing manual action for unnatural incoming links? So there's a little bit more kind of details there. The general answer is no. It's not the case that we look at the domain history and say, oh, they were doing sneaky things five years ago. Therefore, we will be slower, or we will be more critical when they do a reconsideration request now. However, if we see that a site kind of goes back and forth regularly, like, for example, with unnatural links, they build a whole bunch of unnatural links. They get a manual action. They disavow all these links. We resolve the manual action. Then they remove the disavow file and keep building unnatural links again and kind of repeating this cycle multiple times. Then that's something that the web spam team will look at and say, well, come on. It's like you're playing games with us. So that's not something where it's worth our time to kind of prioritize focusing on your website over all of the other kind of legitimate sites that are kind of accidentally running into spammy issues. So that's kind of the situation where I would imagine the web spam team would be a little bit more critical and perhaps take a bit more time to really make sure that actually this issue is resolved completely, and it won't just be another back and forth again. But overall, if there was a manual action a while back and you have a new one now because of something accidental that happened, that's not going to affect it. It's not the case that we will look at the history of the site and say, oh, this site was on our blacklist kind of five, six years ago, and therefore we need to be really kind of critical with it this time. That's not how we do it. A question about Google Search on Workday Jobs. So I think this is also kind of specific. It kind of goes into, well, these jobs are listed on multiple sites. Why do you choose to show someone else's site instead of my site for this particular job listing? And essentially, what happens here is like with lots of things in Search, we often see the same listing on multiple sites. And we have to pick which ones we show in Search. And there are lots of factors that we use in kind of determining the ranking of individual sites. And similarly, when it comes to the same job listing, we try to pick one of these job pages to show. In particular, if we can tell that the listing is exactly the same, then it doesn't make sense to show that listing multiple times in the search results because users have already seen one of those. So that's kind of, I'd say, working as intended in that we recognize these are duplicates, so we'll filter all of them out except for one of them. Can images loaded via a lazy load script be added to structured data and the sitemap without causing any issues? Yes, of course. So if you're using lazy loading to load images, so lazy loading is a way of embedding images on a page so that by default, when you open the page, they're not loaded. But when you scroll to that part of the page where the image is embedded, it'll be loaded then, which makes the page load a little bit faster. If the images are embedded in a way that we can recognize that they're there, so there are different ways to do lazy loading. And if you do that in a way that Googlebot can pick up, then you can use them like any other image on a page. So that can be within structured data. If you have, for example, article markup and you highlight this image as the primary image for the article, you can use image sitemaps to tell us this image is located on this landing page. All of these normal uses of images, they're all possible. Regarding our unnatural link penalty, from the last video, we haven't received any sample links. So can you tell the team to take a look again? I took a quick look and also sent it on to the team to double check that I'm not seeing anything specific there. So from what I noticed there is that this site was building a lot of links using expired domains, where essentially the old content of the domain was loaded back and links were added to those domains. And sometimes we see this happening at a really, really large scale, where there'll be thousands or tens of thousands of expired domains where these links are kind of embedded and used in various sneaky ways. And what sometimes happens, I don't know if this is specific to your site. But what I've sometimes seen is that the WebStream team will say, well, we're seeing that this website has been building links in this particular really sneaky way. And Search Console shows a sample of those links. But we assume that based on this sample, the webmaster can recognize that this is a pattern that applies to their website. And they can go off on their own and find other sites that they've built or other links that they've built in a similar way. So for example, with expired domains, when we see that happening, we don't have to show you all of the expired domains in Search Console. You kind of know where you've built these expired domains or where your SEO has probably been keeping track of all of those expired domains, where they're kind of putting up similar to old content and just adding links to that. So that's something where you can use other tools as well to dig into more details and really clean that up completely. Again, I don't know if this is specific to your website. It is something that we have seen in very similar cases. So that's one thing where I'd recommend going past a little bit just what's available in Search Console and thinking about the patterns that you found there. What kind of links are you seeing there that are problematic, that need to be cleaned up? And where might you find other similar links as well that you could clean up kind of proactively to make sure that it's really cleaned up? I've also pinged the Web Spam team to double check to make sure that you're really kind of in this state and not that there's something where maybe something from manual review got missed, and we should actually kind of resolve this already. Do stock photos have an impact on SEO rankings for your blog? Do original photos have an impact? What are the best practices regarding stock photos? So stock photos are perfectly fine. With regards to normal web search ranking, we don't take into account kind of the photos that you put on your pages and apply those for the normal web search ranking, where people are searching for text and we show kind of the textual search results. You can use stock photos to improve the quality overall of your web pages. That's perfectly fine. When it comes to image search, we do try to recognize when the same photo is used across multiple sites and try to just pick one of those and use that for indexing. So that's something where stock photos probably don't make much of a difference with regards to image search because we've already seen those stock photos somewhere else on the web, and we're probably showing those other places in the image search results. And for the most part, I think that's kind of to be expected. If you're taking a stock photo and putting it on your pages, then why would we highlight your pages as the one landing page for that particular stock photo? That doesn't really make that much sense. On the other hand, if you have original photos, then we can definitely show those in image search. But I think ultimately it comes down to what it is that you want to achieve. And if image search is not a priority for your website, if you're using these images to kind of make your pages look better, then you're primarily ranking in web search. And for that, that might be perfectly fine. I'm running into issues where the Search Console robots text testing tool is showing that I have URL parameters blocked that are getting crawled by Googlebot. I started a thread in the forum. I took a quick look at this briefly with the team. And one of the things I noticed here is you have a really complex URL structure and you have a really complex robots text file. So the example URL that you specified there is one that we did not crawl. So I suspect perhaps your server is logging certain requests in certain ways. For example, if you're using URL rewriting in specific ways, then often the server will log these under a different URL in the server logs. And maybe you're seeing that. But I think my number one feedback there would be to make a significantly simpler robots text file. So you have multiple parameters. You have multiple wildcards in a lot of these directives. And that makes it really, really hard for you to debug what is actually happening. And I really recommend trying to find a way to significantly simplify the robots text files because they're misleadingly complex sometimes, where you think it's just a collection of text lines, how complicated can be to understand. But robots text, especially with complicated long URLs, it can get really tricky. So I focus more on making things simpler and double check the way that you're logging the crawling to make sure that you're really looking at issues that are real issues that you need to worry about and not something that essentially is just confusing because of a complicated URL structure that is logged in a slightly different way that doesn't map exactly to the robots text line that you're expecting. Is the HTML CSS validity of a document a ranking signal? No. I don't know for sure, but I would imagine that most pages on the web have invalid HTML from a theoretical point of view. And they work well in a browser. They work well for users for the most part. And I don't think it would make sense for our algorithms to say, well, you're not following these strict guidelines with regards to HTML validity. Therefore, you will be ranked lower. Because from a user point of view, they might match their needs perfectly. The canonical bug is still at large. So I double check with the team on this as well. So just kind of, I guess, in the background, this is something that is not that canonical bug that we had. What was it in May at some point? But rather, something kind of unique with regards to these websites. But I've checked with the team as well to see what we can do to make that a little bit clearer. I think what is probably happening here is you have different kind of car dealerships and they're sharing inventory. And our systems are probably looking at that and saying, well, this page or this specific entry that you have here is available on a bunch of other domains. So maybe these domains are essentially the same, which is not the case because these are individual dealerships. But our algorithms might be looking at that from a bigger picture view and saying, well, a lot of these pages are the same as the pages here. Therefore, maybe the whole websites are the same. But I'll definitely see with the team to see what we can do to make that a little bit clearer to kind of split these sites up and make them indexable individually again. Let's see. Question about the last update date. Some parts of my content are updated automatically twice a day. Essentially, should I use the last update date for that? You can use that. I don't think you would see much of a change with regards to search, like crawling, indexing, or ranking wise if you change the date or the time stamp on a page on a regular basis. For example, weather report page is probably updated every couple of minutes or every hour at least. But that doesn't mean that these pages suddenly rank a lot better if they have the date stamp that matches the last change that they made on the page. For users, that probably makes a lot of sense. But I wouldn't expect this to play a role in search. Our website has subscription-only content, which we want to expose in full to Google and show unlimited extract to non-subscribe users. The rich results tests and mobile-friendly tests use the same user agent as Google. The IP addresses also resolve to the same Googlebot domain using reverse DNS lookup. Is there any way to allow Googlebot to crawl our site but block these tools? In short, no. In particular, we explicitly made these tools to use the Googlebot infrastructure so that you can test exactly what Googlebot would see. So that's kind of the goal of these tools to test exactly how Googlebot would see. So there is no particular way to differentiate between, say, one of these testing tools and a generic Googlebot request. I don't see that happening in the future, though I don't know. That might be something where if you see a lot of requests for this, then maybe that will change. But I don't see that happening in the future because we want these testing tools to access a page how Googlebot would access the page. And if, by design, these requests were different, then you wouldn't be able to debug any more of what Googlebot would be seeing. There seems to be an artificial 50,000-row limit to the Search Console API with regards to, I think, the Search Analytics API. Is this working as intended or is there a way to get more data? I think this is working as intended. There is a limit to the amount of data that we have available in Search Console in general. And that's probably visible. And the API, fairly visibly, if you kind of iterate through all of these rows that we have available for individual days. I don't know, Mihai probably has a bunch of tips on how to get more data out of the API. I don't know, maybe splitting it up by day or splitting up into site pieces. I don't know, what's your experience? So it kind of depends on how you group the data, whether you're getting it by day, by query, by page. So the more granular you want to go, sometimes you'll notice it's a small paradox. The more dimensions you add to your query, sometimes you'll actually get less data because you're basically asking for more private data, so to speak, more user, one user-focused data. So that's sometimes where you'll see you're getting less rows versus something more broader query. But the only bug I know of is that when you're just using for a specific day, you're using a certain query for just one day and you're kind of hitting a 5,000 rows limit. I don't know if that's, I haven't tested it. That's still the case or not. But other than that, yeah, the more specific you go, the more you run into certain limitations to kind of protect user privacy and limit the amount of information you might be able to get. Okay. That sounds kind of in line what you're seeing there, Kizushi, in that case. If people can use community forums to kind of post API queries with more information, I can replicate them and see if there's anything that maybe some discrepancies with a UI or anything like that. Okay, cool. Sounds like something to do. Cool. All right, infinite scroll. Do the old recommendations kind of still play a role? Yes, they continue to work, surprisingly. The only thing that in those recommendations that you can ignore nowadays is the rel next and rel previous, of course, but otherwise they continue to work. So in particular, having the depaginated links on the bottom, that helps. Having URLs that update as you scroll through, that helps us. So those things continue to be pretty good. I'm kind of torn about updating the code to remove rel next and rel previous because we have it in the blog post as well, but maybe it makes sense to do a new blog post and then update the code to match kind of the current state of things. John, can I have a quick follow-up on that? Sure. So work to the website where they weren't able to implement the recommendations for infinite scrolling, exactly as they were in the documentation due to some technical limitations. So what they did instead is they were able to implement a standard navigation like with page equals two, page equals three, and so on, but they hit it, so it's a display none or something like that, and would Google still be able to use that? Because so that users can use the infinite scrolling, but that doesn't really update the URL or does anything, and Google used the actual page equals something URLs, even though they're hidden from the users. That would probably work. I don't think from a usability point of view it's perfect, but it would probably just work. OK. All right, question about image URLs when internationalizing content. When there's an image URL embedded in a properly Atreflang international URL, say Japanese and English, I'm thinking Google image indexing will be able to annotate the image with both languages, enabling the image to appear in the search results for both language locale pairs. Is that correct? Yes. So at least as far as I know from all of the things that I've seen. So one of the things that happens here is we will see that this image is being used on multiple pages, and we will try to match the best landing page for the query. So it's not so much a matter of you're doing this fancy Atreflang linking between different pages, but more like we notice this is the same image. So we can pick that up for image indexing once, and we have multiple language pages that are associated with this image. So for specific queries, we'll try to find the best landing page for that query. And if someone is searching in Japanese, then obviously we can match the Japanese query with the Japanese text on the page, and similarly for English and English. I suspect it's trickier when it comes to different countries and the same language. I don't know if we would use Atreflang in Google images. So that's something we're not 100% sure about, but definitely when it's different language content, then that's kind of easy for us to match this text goes to this page and this text goes to the other page. How do you deal with a site owner that creates a fake persona for their site? So apparently a competitor is doing this and they're kind of wondering, is this against Google's guidelines? Would this lead to manual penalty? Curious to know what mechanisms you have to catch those out. Is there anything that we should or could do about this? So from my point of view, or at least from what I've seen with regards to the Webmaster guidelines, I don't think this would be against our Webmaster guidelines, but this would be something that we'd probably just pick up indirectly and try to figure out in other ways in that we'd recognize, well, maybe this site is not the best result for these kind of queries and it's not so much that we'd have algorithms that would say, oh, the person that is specified on this page does not exist or is someone else, but more, it's like, well, in general, we don't think this is a good result for these queries. So it's not that you could go to the web spam form and kind of report that and say it's like, this person is wrong. It's more something that we would try to pick up indirectly with regards to our quality algorithms overall. Ooh, I think we made it through the questions. And we have 10 minutes time, wow. How do we do that? I'm sure a bunch of more new questions are added as well. Let me see, oh, just three. We use the Search Console API, have been noticing a loss of data and UI discrepancies. Is there a timeline or any information about this data issue? Is there a way to get that data back? I'm not sure which parts you're referring to. In general, the API should match what we show in the UI. We did have some indexing issues, I think in April, and for a period of, I don't know, two weeks maybe. Not sure. We don't have data for the index coverage report and that's visible in the UI as well. And that's something that would be visible in the API as well. But otherwise, it should be the case that there'd be significant differences with the UI and the API. They both use the same underlying data. It might make sense, like Mihai mentioned, to post some of the details of what you're looking at in the Webmaster Help Forum so that others can take a look there and escalate that if necessary. I think that's what I'll be doing. It's about two weeks of data in March 3rd, February 17th or 18th, that's just sort of missing. And otherwise, the rest of the API seems to be bringing the data exactly as we would expect. So it's just sort of a bizarre, like wondering if it's an upstream issue, some sort of little bump in the road. Which data are you looking at there? Is that the performance? So should we look? Yeah, that'd be performance. Keywords, pages, country. It's basically like every field seems to just be gone right there. And as best as we can tell, the ETL set up completely correctly to pull that data. So it's a little bizarre. Okay, I don't know. It'd be useful to kind of have the details there. What I've also sometimes seen is that we switch the canonical URL to a different site sometimes. So for example, it might switch between the dub dub dub and the non dub dub dub version. And depending on how you're pulling that data, like you might be pulling the dub dub dub version of the data out. And for a certain period of time, if you switch to the other version and track the data there, then that wouldn't be visible in the version that you're tracking. But that's something that should be pretty rare and should be visible in the UI as well. Okay, thanks. I'll be following up with Mihai about this one. Cool. All right. Does Google punish sites if they find your political preferences based off of your Gmail or search history is not the same as Google employees? No, no. I don't think that would ever make sense. So I mean, we don't use things like Gmail when it comes to search anyway, but essentially there are sites out there for all kinds of weird things. And that's kind of what makes the web unique and valuable in that people can just publish content. And it's out there and you can write about what you want, what you believe. And I think that kind of makes search kind of like a magical place and that you can find all of these things if you look for them and you can publish them like that. There's like nothing where we would manually say like we will, I don't know, place a manual action on a site that we don't like. All right, what else is on your mind? Don't tell me we have everything answered. I can cancel the rest of the sessions. I did notice like YouTube just sent me an alert before when I started the Hangout that these Hangouts are going away apparently. So I need to figure out some other ways to do these offers I was hanging out because I find them really useful. So we will have to figure something out. It might, the setup might be a little bit different. Hopefully it doesn't get too complicated but we'll figure something out. Now I got a question related to the first one about the duplicating my same content. We're not the same content, the same top layer, you use different angle then they're publicizing the same domain. What if I separate into the subdomain like block.abc.com, two articles with different angle and will that probably will show into result? That time, yeah. I just put it in the same domain. What are you like? With regards to the number of results that we show from the same site, it's a bit tricky because sometimes we see subdomains as a part of the same site and sometimes we see them as different sites. So that's something that our algorithms try to figure out algorithmically. For example, if you look at a shared hosting provider like Blogger for example, all of the subdomains are completely separate sites and sometimes if you look at a site where they'll use subdomains for different themes or different parts of the same site, that's where we would recognize like the whole domain is one site. So it's not that straightforward to say if it's in a subdomain, we'll treat it like this and if it's in a sub directory, we'll treat it like this. And I think that's also where the whole kind of discussion about subdomains versus subdirectories kind of goes in that like sometimes we treat it as one site, sometimes we treat it as different sites. Both of those situations can happen. And this kind of discussion will be like pop out again. It was like, is it any answer? Oh my God. The original question is like, if I have the same domain and I want to separate into subdomain, I think the subdomain will be, the Google will be treated as a brand new domain, right? Like authority and blah, blah, blah, then it will be like counting as a brand new. And so the original article and move to there, with 301, will the ranking drop or will it pass over like 100% of the segment over there? It's hard to say. I think offhand, if it's a new subdomain and you haven't used subdomains before, then we will probably treat that as a separate site. And it'll probably be such that the same content when moved to a subdomain on its own, will probably struggle a little bit more than if you had it within the same content. So that's kind of like you're taking one small piece out and putting it on an island of its own, then that island content has a little bit harder than if it's seen as a part of this big picture that you already have created. All right, I'll just need to try out, see how it goes. Of course, yeah. I mean, these things are easy to try out. And the only thing that I would caution against is sometimes when you set up test sites for these kind of things, a test site is a bit of an artificial construct in that you might see one result with a test site that doesn't match what would happen with a normal website when you do something similar. So that's kind of one thing to keep in mind. Cool. Cool, okay. So I need to head out a little bit earlier as well. So it's kind of cool that we made it all the way through. We have the next Hangout in English lined up for Friday and the German one on Thursday. And if any of you have ideas on how to run these office hours Hangouts outside of this YouTube setup, then send them my way. I probably end up trying different things until we figure out exactly how it works. But thanks for joining in. Thanks for all of the comments and questions that were submitted. I hope this was useful and see you one of the next times. All right, John, thank you very much. Thank you so much. Bye-bye. Bye, John.