 All right, welcome everyone to today's Webmaster Central Office Hours Hangouts. My name is Joe Mueller. I'm a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do are these Office Hours Hangouts, where webmasters and publishers can join in and ask about their websites in search. Since it's a bit of a holiday, I guess maybe there won't be that many people, but we'll see how it fills up. A bunch of questions were submitted already on YouTube, so we can run through some of those. But before we get started with them, maybe one of you has something on their mind that they really want to kind of talk about in the beginning. If not, that's OK too. Nick, you're also welcome, of course, to jump in in between. Hello, John. Oh, hi. Hi. Do you take question about Google My Business? I can't really help much with Google My Business. OK. Is it specific to Google My Business, or does it relate to Shown and so on? It was about the maps. For example, we got an issue with people creating fake, positioning fake, listing around main establishment. And they are doing it multiple times. We are trying to remove them by doing the reports. And every time, after a little bit of time, we see something appearing with false images, false address. Do you know if there is a solution for this too? I don't know. So I would recommend, on the one hand, using the tools that you have available there. And on the other hand, maybe checking in with the help forum for Google My Business to see if the folks there have some more information. OK, thank you. All right. Any other questions around web search that maybe I can help with? Otherwise, I'll just get started with what was submitted. And like I mentioned, feel free to jump in if there's something that you want more information on, or if you have related questions, any of that. All right, fairly long question. Let me see if I can simplify it a little bit. In Search Console, it's written that the unexpected 404 errors might be generated by Googlebot trying to follow links in JavaScript, flash files, or other embedded content. For example, some Google Analytics link. In Search Console Help, it's also written that this error has no effect on crawling and ranking of your site. Is this always true? I'm asking because we have on our site many cases like this, specifically related to image files, checking our logs related to Googlebot image. We see that last October, Googlebot image requested more than 3,000 resources. And we know for sure that these requests are related to 404 URLs generated by Googlebot trying to follow links in embedded content. Could this be a problem? Could it be affecting Googlebot image's ability to crawl our actual images? So I guess the one thing that you don't have mentioned in the question here is, are your images otherwise being indexed normally? And if your images are being indexed normally, then this is not something that I would worry about. What can sometimes happen is that sites embed their own images with a wrong URL. And then when users look at those pages, those images don't work. And then when we try to crawl and index those images, we can't get to those images either. So that would be the kind of situation where I'd say that's something that you'd need to fix. However, if it's just the case that in addition to all of the images that we have crawled and indexed on your website, we try out a number of URLs that return 404, then that's absolutely not a problem. For the most part, especially when we're crawling images, a 404 error is something that we can process really quickly. It doesn't distract us from processing the images that are really on your website. So in that regard, I would not worry about this. But I would really double check if you're already looking at your server logs, double check that we're actually crawling the URLs that you do care about. And if we're not crawling the URLs that you do care about, then double check why Googlebot might be missing out on those. We're looking to incrementally modernize our WordPress website with some modern web frameworks like React. Since the site is PHP WordPress, we currently don't have the infrastructure to server-side render JavaScript and React code. So we're thinking about possibly foregoing server-side rendering in favor of just server rendering of structured data like JSON-LD for the short term. Our long-term goal is to move away from WordPress. So this would mean that a site's HTML would only be client-side rendered, but there would still be some server-side rendered structured data. Is this feasible? Would this cause significant SEO hit? How does Google consider structured data in search results and in rankings? The alternative would be dynamic rendering. However, we're wondering if we can get away with not managing puppeteer clusters. So there's a lot packed into this question. And I feel if I just say yes or no, it's probably not going to be a great answer for you. In practice, these kind of changes can have a significant effect on your SEO. In particular, what you're essentially doing is changing the layout of your website and moving from something that is pure HTML to something that has a different layout and that uses a different technology, namely client-side rendering JavaScript, which means along that path, there are a lot of small changes that add up, and they can have a significant effect on how Google indexes your pages. On the one hand, layout changes can have an effect, especially if you're making changes that would affect the internal navigation of a website or the URL structure of the website. That's something that can have a significant effect. That's even without looking at the trickier problem of moving to a JavaScript framework. So that's something that can definitely have an effect. The JavaScript framework part is something where I would be kind of cautious taking that on in the sense that it can definitely work. It's not something that by design would not work, but it's also something where you need to make sure that you're implementing it in a way that does actually work for search. So what I would recommend doing there is setting up a bunch of test pages, either on your website or on kind of a testing website, and using the various tools and the documentations that we have available, really double check to make sure that everything on those pages is actually indexable. And then that's something where you could step by step try to take that and see how does this react within my normal website. So in particular, what I usually recommend doing is taking some pages where you see enough traffic from search that there are things that you can measure there, and then converting those to your new setup, maybe kind of splitting that up depending on how you have your server setup, and really double checking to see what is kind of the mid-turn effect from changing those pages over to the new infrastructure that you have, the new frameworks that you're using, the new layouts that you're using, and really double checking that those changes are OK for you. So I wouldn't just see is it indexable or not, but I would kind of leave it running for maybe a month or so to see where does it actually settle down. Because especially when you make bigger changes, you will see some fluctuations for kind of the short term. And the question here I think is more in the long term, will these fluctuations kind of settle down at a state that are similar to what we have before? And that's something that you can really only test. So from that point of view, I wouldn't take this as something like, oh, I will just swap out the whole back end and add some JSON-LD structured data to these pages. And we'll see what happens. But I'd really try to take this on in a controlled way so that you know along the way where things go wrong, where things are actually working out well. And as always, with any kind of site redesign, it's not always the case that the changes that you see will be negative. It's very possible that you do a revamp of your website. And that results in Google understanding your content a lot better in Google being able to crawl and index your pages a lot better. And then kind of the ultimate effect, being more visible in search. So changes alone are not something where I would say that would be a problem. It's really a matter of like, where do these changes go? OK. And then I have my website is getting thousands of links from a porn site through some domain where it's kind of redirecting through an error page, apparently. What is happening? And what's the best solution for this problem? Is my website being penalized due to this? So these kind of links from spammy sites are really common. I wouldn't necessarily worry about that. One thing I did notice looking at your website is that it's built on an expired domain. So there used to be completely different content there. And that, I think, is probably the bigger effect that you'd be seeing. Not so much kind of the links from adult content sites. But really, it's like, well, your website is not what it used to be. There's like a really big change there with regards to the way that the content used to be and what you have there now. So on the one hand, I wouldn't expect that your current website ranks the way that the old domain used to rank. I would expect that things are slightly different. And on the other hand, if you're building on an expired domain, then obviously all of the things that this domain has collected over the years, they're still around there, too. So it's not that you can just say, well, there are some random adult content links linking to my website, and I don't know what the effect is. But rather, you're building on a very shaky foundation already, and whether or not those particular links are the problem or like the whole shaky foundation, that's kind of the question. For new websites that have been internally scored well enough to be given a chance for head keywords, I've seen Google continuously test the pages by giving them small bursts of traffic a few days or weeks apart. Is this part of the testing signals? It's collected over time on those pages, sort of like Google saying, you're new, and you're good, and I want to trust you, but I want to take my time. I'm not aware of any particular system on our side that would be saying, well, we need to kind of double check how these pages work, and we will send them some sample traffic from time to time. But in general, with new websites, it is something where we don't have a lot of signals. So if we don't have a lot of signals, we have to guess sometimes. And our algorithms might end up trying things out. Our algorithms might end up kind of guessing to see what the stable state could be. And then over time, over a couple of months, you'll see that things settle down into something more stable. And this is something that can go both ways in the sense that maybe our algorithms will guess in the beginning that this is actually something that is really, really important, and we need to show it a lot more visibly. And later on, we realize maybe it's not that critical. And similarly, it can happen that we look at it and say, well, we're not really sure how to show this in search. And over time, we learn that this is actually something that is really good and worth showing a little bit more visibly. So it can go up. It can go down. But especially in the beginning, it's something where it's a little bit of an unclear situation for us. Now that Google can index JavaScript, we're thinking of using more JavaScript to increase our website's performance. At the moment, all of our content is in the initial HTML. IT says, loading the content using JavaScript would decrease page loading time. If we made this and also implemented dynamic rendering so that our content would be indexed faster, what could happen? Is it a terrible idea? Or should it be fine? Is it better to leave it as is? This is kind of, I guess, similar to the previous question where someone wanted to swap out WordPress against some React setup. In general, this is something that you can do in a way that works well. It's also possible to do it in a way that causes trouble. So like with the previous question, I would be cautious in kind of going down this direction. But I wouldn't say that it's impossible to do that. There are lots of speed improvements that you can do with static HTML. Sometimes there are really cool improvements that you can do with JavaScript as well. So I would try these things out, test them out, test them out with your actual pages. Like if you can do something like an A-B test where you have some set of pages where you know you're getting good traffic from search enough that you can measure it, swapping those out, and seeing what the reaction is over maybe a course of a month or so. Some questions regarding AMP. My website is in WordPress. Oh my gosh, so many WordPress sites. And I've enabled AMP for it. Please give me a hint about native AMP and how Google sees it as there will be no canonical URL. Also, I want to ask how Google ranks AMP pages. Is there any specific criteria for AMP pages or is it the same as a normal web page? So I don't know which AMP plugin you used. I know Google has been working on one, which it seems to be working out really well. If you're using native AMP, I assume you don't have the legacy HTML pages anymore, but rather you switch completely to AMP. In general, that's kind of the approach that I recommend because then you just have one URL and you don't have this problem of having an AMP URL and a normal kind of HTML URL. If you can switch completely to AMP, then I think that makes a lot of sense. Obviously, not all sites are really suitable to switching completely to AMP. So that's something you have to figure out. If it's mostly a content site and it's hosted on WordPress and it's more a matter of using a plugin to just turn it on and off, then that seems like a pretty easy approach. We rank AMP pages the same as we rank any other pages. So there is no inherent advantage to using AMP. There is no ranking boost from AMP. Some search features do require AMP pages so that we can show them properly because of the pre-caching and all of that. But otherwise, there's no ranking advantage from using AMP. Obviously, AMP pages can be a lot faster than the legacy HTML pages. You can make really fast HTML pages, too. So it's not that you need to use AMP to have a fast page, but they can be quite fast. And speed for us is a ranking factor, especially on mobile. So all of these things kind of add up. But ultimately, I'd say if you think that it works well for your website to have AMP pages and you can go to a pure AMP setup, then I don't see any problems with that. I just wouldn't expect any magical boost to the top of the search results from just switching to AMP. Hey, John, you want to take a question on APIs? Sure. So in Discover, sometimes our website shows AMP pages, and sometimes mobile pages show up. The template is the same, the speed is the same, the story are different. But sometimes mobile pages showing up, and sometimes AMP pages are showing up. Also, sometimes bigger images are showing up, and sometimes smaller images are showing up. So the reason for the images part is because it has a direct impact on the CTRs. So do you see any logic there, like why AMP site not AMP, while the speed is pretty much same in both the templates? I don't know. My hunch would be that it's more a matter of us having discovered and recognized the AMP version of those pages. So if we do know there is an AMP version of the page and it's properly connected with the canonical back and forth, then that's something where we would try to show the AMP version as much as possible on mobile devices where that would be compatible. So it's not something, at least as far as I know, it's not that there is any kind of heuristic that would say, oh, in special cases, only then show the AMP version, otherwise show the kind of traditional mobile version. So it feels to me it's more a matter of timing and maybe proper understanding of those two pages that we can actually understand. This is the HTML version, this is the AMP version. Or do you consider the first crawled page type as one of the source to rank in APS instantiate? Meaning when you picked up the AMP site first because I'm in mobile indexing and then you didn't even hit my AMP site, then you suddenly picked up and then showed up there. Because when we looked at this page type, there's no error. Everything is perfect. And fortunately, what happens is the first page AMP site and the second link is, again, AMP page. So there is no correlation that we are not at all coming there as an AMP, but the same category, same folder, one in AMP site, one in AMP site. So you have basically desktop pages, AMP site version, and the AMP version? Or do you just have kind of responsive and AMP? No, we have three different versions. OK. Yeah. So what I would make sure there is that from the mobile version, you also have a link to the AMP HTML version so that if we get a copy. Yeah? OK. I guess the thing that I'm not completely sure about there as well is from the AMP version, would you have a link back to the M.version or to the desktop version? We have both. Canonical. We have desktop. We have both. I can only tell you some questions. Yeah. I could see maybe that might be something that's confusing us. But I'd need to double check with the team on that. Yeah. I can push to that URL. And second question is like, for the videos, the image always goes in the smaller icon than the bigger icon. Yeah. And that has a direct impact in graphics. That's something. So for AMP pages, we can show the bigger preview image in Discover. And what you can also do is use the meta tag for what is it, max image size, I think, where you can specify large to let us know that for this particular page, we can also use a large preview image. So that's something that would also need to be on, I guess, on the mobile and on the desktop page. So for videos, what we have noticed is all the websites are showing only mobile pages. Earlier, it used to be AMP pages. But now, not only us, but competitors also, all websites, even YouTube, any video that shows up in Discover are mobile only. Never it is AMP since last couple of months. OK. That's weird. If you can send me some examples, I'm happy to take a look at that with the team. Sure. Sure, we will do that. Also, one last question on APIs is that, I mean, they're multiple. But what we're generally seeing in India is that the cache rate or the refresh rate of APIs is pretty bad, right? So in the morning, we see yesterday articles, which I thought which is OK. But in the afternoon, I'll see like, Sanna Sego article, which is not based on the real time. So do you see any cache issue that is happening? Or is that something we have to do with that? I'm not aware of anything specific. But I haven't heard from other people either about this. But I'm happy to take a look at that, yeah. OK. Hey, John, I have a question. Sure. Yeah, hi. So being a news publisher, we can see most matters the most, right? So being a news publisher, we publish all the news in real time. But in Google News Carousel or AMP Carousel, generally I see three weeks ago article, two weeks ago article, 14 hours ago, 20 hours ago. And there are some news publishers, as you know, there are domain crowding where only two or three publishers are coming. But everybody is contributing to Google. So I don't understand what is the reason that the old articles are there and only two, three publishers are ranking for every query. It's something I can't really say in general, because it really depends on the query and the timing there. But it's definitely not the case that we would say we try to show older content in kind of the past story. I completely agree with the timing on the point. But I just want to understand why we are showing like in the morning, there was some big news in the parliament, in the Indian parliament. And if I search for Google, I can see articles two weeks ago, one week ago. And it's like four hours ago, when the news breaks. I don't know, that seems suboptimal. Yeah. I think John, to add to that, in India, basically, this is the biggest problem we always see is that the timestamps don't generally get updated, especially when you have an event, right? It goes really for a toss. This is something, it's a common feedback. I think we already shared once. But I think this is pretty much what we are living today in the search. OK, so the timestamps in particular are not, don't match the article or? Yeah, I mean, while the article updates, Google still shows that six hours ago is six hours ago. But interestingly, sometimes what happens is that the article title that is still showing in Google is like the latest one. But the timestamps still shows six hours ago. OK. Interesting. OK. If you all can send me some examples, I'm happy to take a look at that. Sure, we can share some examples with you. Cool. All right, so a completely different question. My competitor is sending fake traffic to my website using a bot in huge amount. How does Google see it? Will I get penalized for that? What do I do? With regards to SEO, this has absolutely no effect at all. So you can ignore it. You can block it, whatever you want. If I use the same website template to create multiple websites, will Google consider it plagiarism and does it affect SEO? So using the same template itself is not so much of a problem. But using the same content on multiple websites essentially means that you kind of dilute the value of your content. So it makes it a lot harder for us to recognize this is actually something really good and important if you're saying, well, it's across all of these different websites, it's all the same content. Then when it comes to trying to rank things, we might say, well, something else looks really important. And this is kind of like each of these individual pieces has a little bit of value, but not enough to actually be shown like competitively in the search results. So that's something where just using the same template is no problem. Using the same content across multiple sites, that's generally just kind of a bad practice. Does AMP increase direct traffic? So direct traffic is when people come to your site directly by entering a URL or kind of like using the bookmarks. And that's not something that AMP really directly affects. I mean, indirectly, maybe, in the sense that if you have a really great and fast website, that could be something where people might say, oh, I like this. I'll continue coming back. But directly, there's definitely no effect on direct traffic for AMP pages. I have a site that supports multiple languages. Sometimes we have content in four or five languages, but you can still see a page in untranslated content. We're being flagged as having an issue with reciprocal hreflang tags. So I think the general issue is you have multiple language versions of your website, and you don't have all of the content in all of those language versions. So in general, that's kind of OK in the sense that you can have hreflang for those pages anyway, because probably the template of the website is translated. So for example, if you don't have a piece of content in Korean in this case, but the template of the website is in Korean, then that's still a useful page to point Korean users to. So the hreflang there would still be OK. At the same time, you could also say, well, I don't have this page in Korean. I don't even want to send Korean users to the English version of the article on a Korean templated website, then that might be something where you say, well, I just won't use the hreflang on that Korean page. So from my point of view, you can do it either way. Either include that page in the hreflang set or don't include that page in the hreflang set. The other thing to keep in mind here is that hreflang is handled on a per page basis. So if we can recognize that, like say, three or four of the five hreflang links that you have on a page are OK, then we will just use those. And if we can recognize that that one is not OK, then we will just skip that one. It's not that there is a negative effect on the hreflang set for that piece of content. It's also not that there is a negative effect on the website itself if one of the hreflang links does not work. So from that point of view, it's not going to be critical if you know that this page is kind of iffy with regards to translation and the hreflang set up for that particular page is not OK. My main service page is not ranking, even in the first 100 pages of Google, where all other pages are performing well. I doubt this is due to duplicate URLs as I couldn't find any old URL in the different file format and different protocols. This might have happened when the website was converted to WordPress and the page is redesigned long ago. I've redirected, 301, redirected all these URLs to the present service page. How will I inform Google to recheck the URL for duplication or if the issue is solved? So I don't completely follow what has happened here and what is happening with your pages at the moment. But you can use the Inspect URL tool to let us kind of reindex a specific page. So if you're worried that maybe something shifted along the way and maybe the content isn't really what or the content has been updated and you want to make sure that Google has kind of taken a new version into account, then using the Inspect URL tool and submitting that to indexing is definitely something that you can do. I wouldn't be shy about using something like that. That's kind of what it's meant for. With regards to changing website structures, like I mentioned with the other cases, you can make website structure changes. And sometimes these just take a while to be reprocessed. So depending on what you mean with these pages were redirected long ago, that might be something where maybe it's still being processed. If it was, I don't know, a couple of weeks ago or maybe they're already processed and already kind of in that stable new state. If you made this change, say several months or maybe even years ago. What's the best course of action? If you have a website, pages drop completely out of search index and you've received no manual action notifications. Hard to say. So I think, first of all, it's worth saying that we don't index all pages. That can be completely normal. Sometimes with the new features in Search Console where you have the coverage report, it can be tempting to focus on some of the issues there and say, I need to fix this problem. I need to get all of these URLs indexed. When in practice, it's just, well, we've indexed a lot of pages from your website. And at the moment, we don't feel that it's worthwhile to index even more. And that's not something where there's a technical reason involved. It's more that, well, we're not sure if it's really worthwhile to spend so much time on these things. So that could be, for example, if you have a ton of different URLs on your website and they're all kind of similar. If you have, I don't know, a directory of all businesses in your country and their phone numbers and we've crawled through one third of those and we're like, well, these are all things that we've seen before. Do we actually need to index all of these or not? So that's kind of one aspect there. The other aspect could also be that maybe there is a technical issue involved, that it's actually worthwhile to kind of dig into those individual pages to see what exactly has been happening there. So that's kind of the general split that I would try to focus on is first, try to get kind of some rough understanding of is this perhaps just the case that Google is indexing as much as it feels is necessary for my website and maybe some of these other things would be worthwhile to kind of rework in a way to really prove to Google and to users that this is really important content. That's something where maybe it's worthwhile to have a second pair of eyes look at these issues with you and really give you some more honest feedback if possible. And on the other hand, if you feel that these are actually really good and important pages for your website and for some reason they're just dropping out, then that's something where I would try to dig in for technical reasons and try to figure out why these particular pages are not being indexed is maybe another version of that content being indexed is maybe there's something weird happening with my server that I could look into all of those more technical questions. Are attachment pages bad for SEO? Will Google penalize a website if its attachment pages are indexable? So assuming these attachment pages are for attachments that you have maybe on a blog and these are reasonable things on a reasonable website otherwise, then there's nothing against having the index. So there's definitely not a penalty on our side where we would say attachment pages are indexable. Therefore, we will demote the website. That's definitely not the case. The general question I'd say is more are these attachment pages valuable for your website? Is there something of value that you're providing on these pages that when users go there, they say, oh, this is really fantastic website. I will stay and I will look around a little bit more. I will recommend this to my friends. Or are these attachment pages essentially just kind of placeholders where when people go there, they're like, how did I end up here? And what do I need to do next? And why did Google send me here? Then that's the kind of pages where I'd say probably not worth getting those indexed. But that's not an issue of attachment pages or not, but rather what content do you want to have indexed. And that's something where you can decide this is a good use of my time or a good use of my visibility in search or maybe this is something where I'd rather have people actually go to different pages within my website. John, if you have one minute to explain about why YouTube brands much higher is the general question you would have faced many times, but do you think you can spend some time to explain that what factors are, why the search is so much part with YouTube for an intent of a query which is about a video, right? And it has a mix. I'm not saying it's only YouTube, but historically the way we are seeing is that YouTube is actually taking up the entire listing because I'm sure it's a Google product, but do you want to throw any light around that to give us some indication that on videos, why is YouTube so important than a original publisher who actually has the video? I don't actually know how much we're showing YouTube, so that's kind of tricky. But in general, we spend a lot of time to make sure that we don't give any of our own services any preferential treatment in search in that regard. So YouTube pages or video pages like any others, they obviously work to try to make these pages work well. I think in particular, YouTube almost has a little bit more challenging than other video pages in the sense that most users on YouTube probably go to the app. So that's where they put most of the content. And kind of the mobile version of their pages is not really that well suited for search. And with mobile-first indexing, we try to index the mobile version of those pages. So that's something where they struggle with SEO just as much as any other website. So from that point of view, I don't think there is any inherent bias to say, we should show more YouTube content in search than anything else. But there is a lot of content there. And they have a lot of good content. So from that point of view, I think it makes sense to show some things from there. But obviously, there are lots of other video sites too. And we need to make sure that we can show their content as well. Over the years, I've been in touch with a number of these video sites. And sometimes they do things really well. And sometimes they also struggle with SEO, like anyone else. And especially for really large websites where you have a lot of content that is in video form, where it's hard for us to recognize what is actually in the videos if we don't have any text around that, then that can be sometimes really tricky to crawl and index really large sites like that. But that's something where everyone struggles with SEO. And especially bigger sites, they also have the inherent organizational challenges that come together with any bigger business in that you want to make some changes on these pages because there's something technically wrong, then it just takes a really long time until you have all of those permissions. So I don't know. From that point of view, I don't particularly believe that we have any inherent YouTube bias, that we show more content from YouTube in search. But they do a lot of things well. There's a lot of good content there. Other sites do well too. And we really need to make sure that we're showing kind of a balance mix of sites. I think we'll share some samples where the publisher, first publishers, and then goes to YouTube and to take the advantage of YouTube as a YouTube.com maybe bigger in terms of ranking the domain. Maybe it is taking up the first slot and then the publisher comes. There would be reasons, but we'll share the samples with you to dig in separately on that. OK, I'm happy to take a look. I think the other aspect is also tricky if you have a video that you host on YouTube and you also put it on your own pages, then that's something where our algorithms try to figure out which is the best landing page to show there. That's always kind of a tricky situation. But happy to take a look at some examples. And second question, follow up to the video, says that when you search for a query, generally the tradition of search results starts with like news and then videos. But these days we are doing a lot of field wherein even if you search for, let's say, Indian news as a query, then the videos are coming first and then the AMP news stories coming at the somewhere at the bottom of the page. Do you see any foresee changes that are going to come in search? Is it something like a test, or do you really see that it's going to be the case now? So kind of forward looking, I would always expect to see changes in search. I don't think that really helps you at the moment, but I know the team is always working on trying to find the right balance there. And that's something where generally what happens is we have a number of algorithms that try to determine which of these kind of search results blocks to show above the others. And essentially they're trying to determine what is the most relevant for users for those specific queries. And sometimes it can happen that videos are shown on top, sometimes images, sometimes a news block. That's something where I think we generally get the mix fairly well, but sometimes maybe we don't. And in particular, I could imagine for non-English content, it might be even trickier for us to understand what specifically is being searched for with this query. Are they looking for more kind of up-to-date news? Or are they looking for background information? Are they looking for images or videos on this topic? Sometimes there are also videos that are indexed that are very kind of news friendly in the sense that they're really fresh. And it's also worth showing kind of together with news content. But this kind of mix is something that I know the teams work really hard on. And it's really tricky to get right, because I don't think there is one answer that always works. Yeah, I agree with that. But I think are you guys seriously taking the publisher's feedback as well? Like what is the impact on that at the end? That is the content that is going to surface on the search results, right? So do you see that it should be open forum to the publisher also, because the reason this question comes because we're lost in the traffic, right? So do you see that as a feedback? There's a channel to that. It's good to do an experiment. We're happy to see the experiments, but there should be a give and take. Yeah, I mean, we do take that kind of feedback seriously. But it's also important from our side that these search results work well for users. So kind of having feedback from publishers saying, I want my content to be shown on top rather than someone else's content. That's something where, OK, we can kind of have a reasonable discussion about that. But ultimately, what's important for us is that users get the search results that are relevant to them at the time when it is relevant for them. And sometimes publishers see these kind of issues a lot clearer than maybe users would be able to formulate them. So that's always useful to have. But sometimes it's also kind of just that conflict between publishers would like to have more visibility in search. And we think that maybe there are other things that are also important to be shown in search. Yeah, I think it's not something like we have one publisher wants to rank better. But because of this click, YouTube is something which is getting benefited, right? So it's always like the YouTube videos ranks first, and then the YouTube always takes the slot completely. So that is the kind of question that's why I asked you to spend some time to talk about the YouTube. Because I mean, Google is benefiting, but not the publisher, but the YouTube is taking the benefit out of it. So that's where I think the feedback is a question, not to rank between the publishers. But the news versus videos and videos takes advantage. If that is the case, then YouTube is taking 90% share. Yeah, I don't know. I could also imagine situations where maybe some fairly fresh videos are really kind of comparable to news content. So it's, I don't know the specific queries that you're looking at. Sure. Yeah. All right. And a question relating to kind of one of the previous office hours. So some websites are copying their content, and they're using a piece of JavaScript that kind of adds a link back to the website with a hash after a fragment identifier. And the general question is, is this a problem, or is this not a problem? From our point of view, that's perfectly fine. If you have JavaScript that includes kind of a link when people copy and paste content from your site, then that's something that kind of makes sense. The fragment identifier at the end of the link is something that we would drop, because we try to use the normal kind of URL instead. So with the path and the file name and the fragment identifier, we would drop. So that's something where we would see that as a normal link to that normal URL. Would Google consider these to be natural links? I think there are two aspects here. On the one hand, if these are scraper sites that are copying and pasting content from your website, then probably those links are not something that we would value that much anyway. So it's not something that would be high on our radar. On the other hand, if people are putting content on their website and linking back to you as a source, then that seems like a normal natural link to me. So I wouldn't necessarily worry about this. But kind of how I mentioned there, on the one hand, these are probably not going to be that useful links for your website anyway. So on the one hand, I wouldn't worry about this as being a kind of natural or unnatural link, because they're not valued that much. But also, I wouldn't expect to see any positive effect from these kind of links, because probably those sites are not going to be things that we, say, are kind of useful references for a website. Sure, hi. Yes, hi. So we are a new publisher, and we have a business news website, which happens to follow all the Google guidelines, the news guidelines, and everything. The sitemaps are working perfectly fine. The feeds are working perfectly fine. We are getting indexed. We are getting indexed in Google News as well. But somehow, we are not appearing in the top box. So we have raised this query multiple times on Google support and to the Google team. But we have never got a satisfactory response. We have never received any message in our search console about what is happening and what is the issue. So can you please enlighten me something about it, what is happening here, and what is the exact issue? So the, what is it called, the kind of the box on top there, that's something that is, from our point of view, is an organic search feature. And it's not something where news publishers automatically show up. It's not something that's limited to news publishers. Yeah, that is a thing. But the thing is that we used to appear in the top box. But it's been a one and a half year that somehow we got disappeared from there. Without getting any notice in the search console or something, we never, never, ever appear for a single query in the top search. We get appeared in the search results, but never in the top box. So we don't have anything, as far as I know, we don't have any kind of manual action that would block a site from appearing in the box. I forgot what the official name is. But from that point of view, it's not that there is kind of a setting for your site or anything like that where we would say, this site should never show up. But rather, this is some top stories. Yeah, top stories. That's what I meant. So from that point of view, it's not that there is any setting or anything like that, which will be blocking it. But rather, we see this as an organic search feature. And over time, our algorithms evolve. And it can happen that a site is visible in Google News and does not appear in the top stories section. So from that point of view, it's not that I'd say this is particularly kind of a bug on Google's side or something that you're doing incorrectly. But rather, we try to show the appropriate results in the top stories section. And sometimes that includes some sites. Sometimes that doesn't include other sites. But it's not the case that we kind of like block sites from appearing there. So that's from that point of view, it's kind of tricky to say. I understand your point. But we have other websites as well, other English websites in the website and regional websites. They do appear for search queries in the top box. But for a business website, there's not even a single query. Not even a single query that appears in the top box. So I can understand that it happens sometimes. One website shows and the other one doesn't show. But it cannot happen in every day's business that not even a single news is getting picked in the top story. Right? It can happen. But you know what? I don't know your website. So it's really hard to say if that's something that I would expect for your website. But it can certainly happen that a website is not a one month or one week old thing. It's been quite two years. And despite of writing multiple queries on this webmaster search forum and the Google people and asking them in these seminars, I have not got any response that could actually relate to the issue or what I can do on my part to solve this problem. Because I have seen everything that everything is getting followed, all the guidelines, all the schemas, speeds, everything is working fine. Still, it does not appear. That can happen. I mean, on the one hand, the technical things are things that are always useful to follow. But it's not that there is a technical requirement where we say, you need to do this. And then we will show you there. But rather, there are lots of also quality issues that are involved there with regards to trying to figure out what type of website to show there. And it can certainly happen that a website exists for a longer period of time. And it is even indexed in Google News. But we still think, well, we're not convinced that it makes sense to show this website in the top search, top story section. So that's something where I wouldn't say, offhand, it's impossible that any new website is able to show up in there. Because new websites show there all the time. But it's also not the case that it's a sign that there's something specifically wrong with a website when we don't show it in the top story section. Because it's an organic search feature. And the criteria to be shown there from an algorithmic point of view, we have a lot of things that play into that. And it's not guaranteed that we would always show a site there or that we would ever show a site there. Does BERT affect the ranking of websites which have content in other languages than English? So I struggle a lot with all of these BERT questions when they come up. Because from our point of view, BERT is a way of understanding text better. And we use that, on the one hand, to understand queries better. So to better understand when someone writes something complicated into the search box. And on the other hand, to understand pages a little bit better. So from that point of view, it's something, even in English, when we use things like BERT to understand the pages and the queries a little bit better, it's not that you'd have to do anything particularly different with regards to your pages. But rather, we're just trying to understand your pages better. We're trying to understand which queries better fit to your pages. Especially things where the queries, for example, might be kind of complicated, where people are asking things that we can't map one to one on a keyword basis, where we have to understand what it is that they actually mean. So from that point of view, it's something where, when we do use BERT, it's not that you need to change anything on your website. When we don't use BERT, it's also not something that you need to do anything different on your website. So when we kind of try to expand our understanding of queries in English, often that's kind of one of the places where we start, because we have a lot of people that are active in English. And also, there are lots of research that's being done in English. So maybe we'd start there. But we do try to apply this technology to other languages. And for other languages, for other language content, it essentially means that we have to do a lot of research to try to make sure that we're understanding things correctly. We have to do a lot of testing to make sure that we're actually improving things overall and that we're not causing more confusion in the search results. That's something that, in English, we did spend a lot of time to really test these algorithms to try to fine tune them. So that's something where I could imagine it just takes a lot longer for us to get that done in a way that is easily transferable to other languages. And then even there, we'd still have to test that significantly. So my guess is, over time, we will learn to understand a lot more content, a lot better, understand queries a lot better. But there is nothing specific that you need to do on your pages to make them compatible with BERT or to make them work better with BERT. But rather, if you're creating good content, if you're creating content in a way that is easily understandable to users, then that's what we're looking for. We're not looking for new meta tags to try to find things a little bit better, but rather, we're trying to understand your content a lot better. Let's see. We're kind of out of time. There's still a few questions left, but it feels like these are kind of tricky ones that need a lot of time to kind of go through. Maybe I'll just switch over to more questions from you all if there's anything specifically on your mind that you'd like to talk about. I've got a question, John, if you have the time. So last time we met, I mentioned about a website where certain commercial pages were doing really bad, average position 70 to 80. So worse than it would be just competition there. Looks like there might be something else going on. You mentioned let's just try switching the URL, see what happens, see if it kind of wiggles it around. So we did that, but the issue is the old URL is now 404, and we did a new URL, which is the exact same content for that page. It's just a different URL. But when I go to Search Console and do a URL inspection on the old URL, it doesn't show it as a 404. It shows it as Google selected canonical to the new URL. So I think that kind of defeats the whole purpose of switching it and 404ing the old one, because Google doesn't consider it 404, it just migrates all the ranking signals and possible issues to the new URL as well. So it doesn't really validate the experiment I guess. I totally don't remember what the context was. So it's hard for me to say. So you're not seeing any positive effects in short? No, but one of the reasons that I think I'm not is because Google doesn't see the old URL as a 404, and the new URL is a brand URL. It just sees the old URL as a canonical to the new URL. And I don't know how to make it kind of see that one is a 404. Using the test live URL, it does show a 404. But doing the normal URL inspection and just show that Google selected canonical is now the new URL instead of a 404. No. So I don't know how to push it to kind of re-crawl it and take the 404 into account. I could imagine our systems are doing that on purpose to help people who aren't doing redirects properly. So maybe that's a case where we're being more helpful for you than you want us to be. Yeah, quite. Because if we can tell that the content is the same and it disappeared one URL and it reappeared somewhere else, then I could imagine our system saying, well, you're kind of shifting the canonical from one to the other. So that's something. I guess the approach there could be to make sure that the content is significantly different. But then your experiment is getting more and more complicated. Yeah, so it's kind of a product page. So can't really change much of the content. There is just a description of some of the features of the product. Yeah. I don't know. Yeah, tricky one, I guess. Tricky, yeah. And the new URL seems to have inherited the keyword positions from the old URL, which is, again, 70 to 80 average position for any keyword, which is very dubious. OK, I mean, maybe that's just the normal ranking that we would see there. That might also be. I mean, nobody wants to hear it. Sure, yeah. Have you started? Sorry. OK, let's take a break here. I'll pause the recording. I still have a bit of time. So if any of you want to stick around and just chat, that's fine as well. All right, so thank you all for joining in. Thanks for watching the recording, I guess. Thanks for submitting so many questions. I'll set up the next batch of Office Hour Hangouts, probably also in two weeks, where we also have the Webmaster Conference in two weeks. So not quite sure how the timing will work out, but we'll try to figure something out. We also have Webmaster Conferences in Japan and Korea happening the next couple of weeks. Next week there's one in Tel Aviv, and then two weeks in Zurich. So lots of things happening here. So yeah, hopefully we can catch up there. All right, so with that, let me pause here. Thanks again, everyone, and see you in one of the future Hangouts.