 Hi, everyone, and welcome to today's Google Search Central SEO Office Hours. My name is Jamular. I'm a search advocate on the Google Search Relations team. And part of what we do are these Office Hours hangouts where people can join in and ask their questions all around search and their websites. So many people joining us today is fantastic, cool to see a bunch of new names and faces as well. So that's always neat. And a bunch of things were submitted on YouTube as well. But as always, maybe we can get started with some first questions. And I think what probably works easiest is if you're live in here, just use the raise hand feature. And then I'll try to go through in that order. And wow, OK, lots of people are raising hands already. OK, Praveen, maybe you can get started with your question. Hey, hi, John. How are you? So it's a bit weird and a long question, so please don't mind. There is this website we have, which is a global website. And they have pages in multiple languages, in English and Japanese and Korean. So this website has implemented HRF and tags and all that stuff. And they're doing pretty good in Google in all the local regions. And the problem is that in South Korea, there is a local search engine called Naver. And Naver has a problem with these HRF and tags, like it doesn't understand them. And this website has these languages, like they have used directly system, folder system, for multiple languages. They are not using subdomains or separate domains. And this makes even harder for Naver to understand that this website is in multiple languages. So the solution, what it does is it shows English version to the Korean audience for Korean queries. And that's the problem. The management had decided, why not we should make a separate website for Korean audience in only Korean language? And the concern from Google's point of view is that if we allow that website to be indexed by Google too, can that new website impact performance of the existing global website? Is there a possibility that, because Google can figure out that both these websites belong to the same domain and they are basically targeting the same audience. But that new website won't be just copy paste. It will be a website with new user interface, new fresh content, and everything will be new. The only concern is, can the new website impact performance of the existing website? Because that existing website is doing pretty good on Google. I think if it's a completely separate website, then it's a completely separate website. So that's no concern from that point of view. If it's just on a different domain and it's essentially a part of the same set of pages, you can still use hreflang between those different domains. So hreflang doesn't have to be just within one domain. So that might be another option where you could say, well, they don't understand hreflang, but if it's on a different domain that works for them and Google understands hreflang and can do it between domains as well, then you can combine those two options. We actually don't want to confuse Google with, like, we have so many pages on the system and then one is on the subdomain. So we just want to keep things simple. So the only concern new websites should not impact the performance of the existing website. I think that's clear. Yeah, I think what will happen is you will compete with yourself, with your existing website. And if you're OK with that, that's fine. But it sometimes makes it a bit harder to rank well for some queries, because both of these versions will have some amount of signals and value in Google's eyes. And that means maybe both of them will be kind of mid-range with regards to ranking. But if these are queries where your site is very visible anyway, then probably it doesn't make a big difference. But essentially, that's up to you. It's not that the WebStream team will look at this and say, oh, two websites is too much. Sure. Thank you. Thank you. Sure. Xiao Qian. Oh, may I not pronounce your name? Sorry. Thank you. Thank you. I also type my question here. So my question is, a while ago, I was reading one of Google's guide. They say that do not index internal search results because you generally not search user intent well. I agree with that if it's an informational site because people won't be landing on the page that directly answer your question. However, I'm not quite sure it's also the same for e-commerce site. For example, when you are searching for, for example, slim computer, and the first result is actually Amazon's internal search result page. And as a customer, I won't be happy seeing that because it did provide a lot of options for me to buy. And so my question is just that for very transactional intent keyword e-commerce site, it's also not recommended to index internal search page. So I think that's something where you could argue that these are more like category pages or where you could say, well, it's more like a category page and it's indexable. The tricky part with internal search pages is that it's often an infinite space in that you can enter any random word and it'll create a web page for it. And that's something you kind of want to avoid. But if there are specific topics where you say this is kind of like an important topic, then you can definitely keep that indexed. It's not that the Webstone team is reviewing these and seeing, oh, internal search, it should be spam, kind of thing. It's more a best practice for crawling and indexing that you provide pages that are useful for users. And if these are internal search pages that are more like category pages, that's fine. I see. Thank you so much. So would you recommend only pick some of those internal search pages to index while blocking the majority of them? Yeah, I think if you can do that, that's what I would do. Like take a list of keywords where you're saying these are OK and everything else just block those. Just to avoid the situation that people create random pages for random words or also what I've sometimes seen is people create pages for words that you don't want to rank for. Like, I don't know, maybe they're searching for medical terms and your website is about computer products, then you don't want to rank for that content. I see. Thank you so much. Sure. David, I think you're muted or your microphone is not working. Yes, no, I was muted. Sorry. Thank you. OK, I have a few questions, but I think they're quick. So I'll try to get through them. Number one is, if enhancing core web vitals, let's say it reduces the, we get rid of a bunch of old scripts and reduces the page size in half, would that correlate with an increase of crawl rate budget? Maybe, maybe. So there are two things there. On the one hand, if we can access your HTML pages faster, we can probably crawl more. So that would go into the crawl budget side of things. The other part is, if we can render your pages faster, if there are JavaScript pages, then we can also get through them faster. But it all depends on the demand as well. So for crawl budget, we have the capacity of the website and the demand from our side. Got it. Now, the other question is a little more difficult. Basically, there's the amount of pages that are being indexed by Google in the coverage report. And then if I go to the internal link report in the link section, I see that all the links that are in the header and footer are the top ones with the same number pretty much. So I know that it's collecting those as internal links to report on, regardless of its effect or impact. But the number is a tiny fraction of the total index pages. And when I do a site search in Google, it's somewhere around the range of the total index pages in the coverage report. But then I go to the internal link section, and I'm talking about indexed is 6 million. And in the internal links is 30,000 for all of those header footer pages. And those are on every one of those pages. So what would that hint to me? Nothing really useful, probably. It's just for these reports, we take a sample of the pages from your site. So they're not meant to be kind of on the same level as the index coverage report. Got it. So it's just to get an idea of which internal links are found more often than others. Exactly. OK. And then the next thing is she mentioned it about the URL parameters for search pages. If you're dealing with a site that the search is set up that it auto corrects and redirects to a proper search that we want that's in our site map that's relevant, is that a redirect that will hurt in terms of crawl budget? Because it could be anything. Someone could input anything, even though we'll find the right page, probably the most relevant on the site. Is it going to impact anything? And how would be the best way to implement? How are you redirecting there? I would have to speak to the dev team, but I don't know. They have their own internal link system algorithm. So usually with redirects, we follow, I think, a small number of redirects immediately. And it's kind of seen as a part of the same request. And I think the limit is something like five, something like that, where if there are five redirects in a row, we'll just follow that and look at the final content and treat that as one request. If it takes more than five steps, then we would treat that as separate requests. But usually for something like this, you would have one step. And you'd be kind of on the category page or something like that. And that's perfectly fine. OK. All right. Thank you. All right. Evan. Yeah, so I think I was a little faster on the hand but my colleague, Derek, could probably explain the question more succinctly than I can. Derek, if you want to go ahead. Sure. Can you hear me? Yes. Great. So our question has to do with core web vitals. I'll post it here in the chat. Basically, we want to know how it relates to AMP. So we have enhanced our site for AMP. And 90% of our mobile traffic goes to AMP pages. But now we're addressing core web vitals stuff. But in our core web vitals dashboard, it looks like only 50% of our pages are hitting good marks there for mobile. So we spend a lot of time doing AMP. Are we going to be penalized for the pages that we have that are not AMP that are performing poorly on the web vitals side? I don't think you would be penalized for that in that sense. But I mean, what happens on our side with regards to the core web vitals is we use the Chrome User Experience Report data as kind of the baseline. And we try to segment the site into parts what we can recognize there from the Chrome User Experience Report, which I think is also reflected in the Search Console Report. And based on those sections, when it comes to specific URLs, we will try to find the most appropriate group to fit that into. So if someone is searching, for example, for AMP pages within your site, and you have a separate AMP section, or you have a separate AMP template that we can recognize, then essentially we'll be using those metrics for those pages. It's not so much that if there are some slow pages on your site, then the whole site will be kind of seen as slow. It's really for that group of pages where we can assume that when a user goes to that page, their experience will be kind of similar. We will treat that as one group. So if those are good, then essentially pages that fall into those groups are good. The tricky part, I think, with the AMP Report is that we show the pages there, but we don't really include information on how much traffic goes to each of those parts. So it might be that you have, let's say, 100 pages that are listed there, and your primary traffic goes to 10 of those pages. Then it could look like you have all of these 90% or slow, perhaps if those 90 other pages are slow, and those 10 that people go to are fast, but actually the majority of your people will be going to those fast pages, and we'll take that into account. So two follow-up questions there. One, you mentioned that you segment these results into different sections, right? So when I look in the Search Console, you're right, I can see that they're grouped together, but I see the AMP and the non-AMP pages separately. So will you take into, if you do a search result and I have maybe a site that's not AMP canonical, but you're showing an AMP result for, will it use the results from the AMP section of that page, even if the search result itself is for the non-AMP version, it has the AMP enhancement? Sorry, does that question make sense? I just kind of got confused with that last part. It's like it's an AMP page, but we're showing the non-AMP page? Well, so there's an AMP and a non-AMP version, right? And in the search result, you're showing the AMP version, but it's not AMP canonical, so it is my, if that makes more sense. Yeah, I think what, I kind of have to look at the specific situation. My understanding is we would follow the canonical and use it based on that. Okay, so if usually we would like, yeah, I mean, usually what would happen is we would fold the AMP information, the AMP signals, into the canonical itself. Got it, okay. And then I guess the second follow-up question is, does the AMP results in the Chrome user experience reports take into account the benefits of the AMP caching? Because I can imagine just like going to the AMP page would be much slower than viewing the cached version from that. We, I mean, what we do is we take into account what users see. So if it's a valid AMP page and we can serve it from the cache, then we'll use that. Whereas if it's a kind of not a valid AMP page and it's still an AMP page and pretty fast, but we can't serve it from the cache, then obviously we don't use that. Yeah, totally, I was just asking because the Chrome user experience report I know takes from like just people browsing the internet from Chrome, so I don't know, I wasn't sure if I was able to associate the cached AMP pages with those origins. So that was my question, thanks. Cool, fantastic, next. Hi, John, another AMP related question. If we're changing AMP URLs, do we need to redirect from the old one to the new? So the canonical URLs are staying the same, we're just changing the structure of the AMP URLs. Ideally, yes. In practice, it's not as critical as with normal URLs on a website. Because usually what happens with the AMP URLs is we refresh the cache fairly quickly and we will notice that the canonical URL and the cache page and those URLs change fairly quickly. So it's more something where I'd say you have that time period between when we know about the URL, when we show it in the search, and when we've updated it, which might be, I don't know, a couple days' time. So it's definitely less critical than with the normal pages, but ideally, you would still redirect those as well. OK, and I have a second question for AMP again. So I think it's been stated a few times that there isn't a direct ranking boost, a ranking factor from AMP. However, last year, we removed our AMP pages, we redirected AMP URLs to our canonical pages, and then we saw a decrease in traffic straight away. And over six days, it was 10% decrease in organic traffic. So we redeployed it, we turned it back on because we didn't want to keep losing traffic. Is there an obvious reason why that might happen? I don't know. It kind of depends on the site. So on the one hand, I think there might be an effect of things just kind of like still pointing at the AMP pages and kind of getting lost if you just turn it off. So that's something that would be something more of a temporary effect. That's something you can also try to mitigate by using the AMP cache API, I think, where you can force a refresh so that we can see these AMP pages actually no longer exist kind of thing. I think we have a Help Center article on Disabling AMP, actually, that covers all of those steps. The other effect that you might be seeing there, depending on the type of site, is that for certain search experiences, search features that we show in the search results, we do use AMP. So I think that's in particular the top story section on mobile where we essentially require AMP pages, at least at the moment. And if it's a news website, for example, that has a lot of content that is shown in the top story section when it's on AMP, then you will see that kind of disappear. That's something where with the update that we're doing in May around core web vitals and page experience, we're going to start allowing normal pages as well when they reach that appropriate bar to be visible in the top story section. So that'll be a little bit more mitigated. But it really depends on the kind of site. Like, if it's not a news website, if there's no kind of newsy content on there that would have been featured in the top story section, then it would be kind of weird to see a drop in overall organic traffic. OK, yeah, it's not a direct news website, per se, but it's a medical article website. And we do feature in the carousel, AMP carousel. So yeah, that would be nothing. Yeah, yeah, that could be. Cool? OK, that's good. Mohammed. Hi, John. Hi. I work in an IT company. We put lots of tons of quality content at our website. But recently, we got to know that there are a few websites that have been copying our content and publishing it on their website. In fact, they are not making an effort to change the images. So I just want to know what kind of action we can take or how does Google consider these kind of activities and how we can protect ourselves in future regarding these fraudulent activities? I think the primary action you could take there, depending on the situation, is to look into the DMCA process. The DMCA process is a legal process. So I can't give you legal advice on when it applies and when it would not apply. But that might be something that you could look into. With the DMCA process, you're basically saying, my content is my content, and someone else has copied it. And you're giving Google that information on a per page basis. And based on that, our systems or the legal team, I don't know the details, will review that and take action on that and also inform the other side about that so that if, for example, they were the original source, they would be able to raise a concern and try to find a different resolution for that. But that's, I think, the primary approach that you could take there. The other thing that I would also keep in mind is that if you're regularly seeing other people with copied content ranking above your content, then to me, that points at a situation where maybe the overall perceived quality of your website is something that our algorithms are having trouble with. That could be something where maybe it makes sense to take a step back and think about your website overall and try to find ways to significantly improve the quality of that to make sure that when our algorithms run across your website with the content on it and some random website that they don't know about with the same content on it, that they say, well, actually your website is the one that we should trust. And not so much like some random website is perhaps just as good or even better than this website that we know about that we know we don't want to trust that well. So that's kind of a different thing to think about there. But I would definitely look at the DMCA process first. And also, if you're regularly seeing this, I would really think about what you can do to improve the quality overall. That means that we have a loophole in our own website. How do you mean? Like we are not up to that quality. That's why other websites are copying our content. I don't know why other people are copying your content. I can't say. But if you're regularly seeing that the copied content is ranking above your content, then to me, that would point at some kind of quality worries that our algorithms have. OK, thank you. Sure. John, Darcy. Hi, Oriel. Back in, I think it was mid or late February, a couple of the tracking tools were reporting some drops in featured snippets and the amount of times that those showed up. Judging by your reaction, I don't know if you are familiar with that at all. Just wondering if that was deliberate by any means on Google side to reduce featured snippets from showing up, or if it was maybe for another reason that that might be happening. It's just featured snippets, when you get them, are pretty awesome. And to lose them is pretty disastrous. At least you've been used to riding this wave of traffic that can come with a featured snippet. So to lose it, yeah, just wondering if there's any additional rationale, or if you know of any maybe it was a side effect of another change. I don't know. I don't know. Like the featured snippets and the rich results in general, those kind of things can fluctuate over time. And I know the teams are always working on those features and trying to fine tune the triggering. So when we would show them or when we wouldn't show them, sometimes the triggering changes over time, that we just kind of reduce the threshold overall, or that we change the focus a little bit and say it's less here and more here. Sometimes that happens across geographies or languages. But these kind of changes from our side are essentially normal organic changes in search, how they can always happen. So it's definitely not the case that we say, well, like there's some technical requirement that's missing on these pages, therefore we dropped it. It's more we need to refine which types of results we show over time. So yeah, just more of a balancing act, I guess. Yeah. So would you think that it was a deliberate kind of reduction in featured snippets, or maybe some other change that might have then caused that reduction? Any idea, yeah. I don't know. I don't know. Usually we don't think of it as much as we want to reduce the number of times we show a feature, but rather we want to improve the targeting and the relevance of when we show the feature. And sometimes that does mean overall it's fewer, but it might be that they're fewer here and there's a little bit more here kind of thing. And that's something that it just happens over time. They're always trying to find a better balance of what to show in search and improve that. Gotcha. Cool. Thank you so much. Sure. Clint. Morning, John. My question relates to the mobile index and specifically a responsive design. So if, for example, there is an element on the page which links to, let's say it's a online catalog or something like that, so that component on the page is essentially linking to the catalog. The catalog itself is not mobile friendly. So as a result, under the responsive design, we would basically hide that component, but essentially it's still part of the DOM. So under the new mobile index, will this content still get called an index? Or because it's not rendered on mobile, it's basically not getting called an index? If it's in the DOM, then we would be able to pick that up for indexing. So that would be perfectly fine. I can only show up then on desktop potentially not on mobile. Yeah, yeah. Sometimes what we try to do is figure out which parts of a page are visible and kind of emphasize those with regards to ranking. But especially on mobile, we see that there's a lot more interactivity on a page in that you kind of activate different tabs, you kind of see different things, and actually it's all a part of the same HTML page. And from that point of view, if it's not visible but it's in the HTML in the DOM, then that would work for us. All right, thank you. Sure. All right, SEO team. Hello, everybody. How are you? I am very interested in that. I can talk with you, John. I was waiting for this online session because of a particular reason. I have four more important questions for an execute purpose, but the four questions are somehow big. Then I will ask the first two questions. I wish that I can get sometimes during the session to ask the remaining questions. First of all, for websites that have AMP pages and non-AMP pages, how we can measure the core of vitals to get a general idea about the whole performance of the website? I mean that, do we need to measure the performance of AMP pages alone and the non-AMP pages alone? What is the best practice here? So depending on the way that you have the AMP and non-AMP pages set up, you may be able to see the difference in Search Console or in the Chrome User Experience Report data because that could be split out by URL. So I would double check that. The other thing that you definitely can do is do lab testing, especially if you're modifying pages, if you're trying things out, then I would do lab testing with page speed insights with Chrome directly in the browser to test things, especially to compare different versions of the same page. And when it comes to lab testing for AMP pages, if it's a valid AMP page, then definitely also check it on the AMP cache to see what users would see when they click on a search result. And that's the approach that I would take there. I also recommend when it comes to testing that you set up some kind of a monitoring system on your side to regularly test the important pages on your website for the core web vitals so that you are able to recognize quickly when something goes wrong. But that's more of kind of like the long-term thinking. OK, thanks a lot. Another question is that I found a lot of difference between Google Analytics and Google Search Console data. For Google Organic Traffic, I read a lot about the causes of such a difference. And I know that each tool has its own algorithm in collecting and measuring data. But we are facing a lack in reading our Google Organic traffic, in which we have some articles that get thousands of clicks on Search Console. But Google Analytics shows that it's only have 10 or 20 Google Organic traffic, sure for same date range and the same article. More than that, in Search Console, sometimes we see articles that have an increasing curve for a number of clicks. But Google Analytics show a decreasing curve for Google Organic Traffic. So while we are seeing that and is there any step-by-step guide about how we can solve the big difference in data between Google Analytics and GSC? I don't know. So that's something I would check with the Analytics team and with the Analytics Help Forum to get some input there. The one thing I would kind of suspect, but I don't know how it's implemented on your side, is since you mentioned AMP pages, it's possible that the AMP pages are being tracked separately in Analytics. So depending on how you have AMP set up, it might be that you have a separate property for the Analytics pages, and they're kind of separated out. Whereas in Search Console, we focus on the canonical URL, so we would show all of that traffic together. So that might be one reason, but I would really get some tips from the AMP Help Forum. Yes, yes, Jun. Analytics Help Forum. Yeah. But sorry, sometimes we saw a vice versa data. We saw that Google Analytics show data more than the real data on Google Search Console. Not every time Google Search Console show data more than the number of organic traffic at Google Analytics. Yeah, I don't know. So the tricky part is Search Console can track what happens in Search, but doesn't know what happens on your website directly. And people can go to your website directly with a referrer from Google, and it can look like someone is coming from Google Search. But in Analytics, you can't tell, is it really from Google Search, or is it someone just using the wrong referrer? This kind of weird behavior is pretty common. It just happens on the web. So sometimes you do see some discrepancies, but especially if you see a lot more data in Search Console than in Analytics, then to me, that feels like something in Analytics is tracking wrong. OK, OK, thanks a lot. Sure. I don't know if I'm pronouncing your name right. Hey, Joan, how are you? Hi. Actually, I have a few questions related to schema. Actually, I have implemented schema marker for knowledge panel graph on my website. But still it is not appearing knowledge graph. Please let me know which factors we need to consider to implement knowledge panel graph for a brand. Please let me know. Yeah, I don't think there's any specific markup that you can use to force a knowledge panel to appear for a brand. So what you can do is give some general company information, like the logo, like address, opening hours, things like that. But just because that specified in structured data doesn't guarantee that we will show a knowledge panel entry. Sometimes what you can also do is the Google My Business entry, which also appears in the side similar to a knowledge graph entry. So that's something where you can try different approaches there. But it's not that there's one structured data type that forces the knowledge panel to appear. OK, another question is related to site links. Actually, I need to appear some desired pages as a site link in Google SCRP. But still, I'm trying from last six months, and I have lots of activities. But still, my desired pages are not appearing as a site link in Google SCRP. Please let me know what can I do for this. So site links are generated automatically as well, kind of like with a knowledge panel. And there's nothing specific that you can do to force those. We try to pick up the site links based on your site's internal navigation primarily. So if we can understand how people can navigate your website better, then we have more of an opportunity to show site links. But it's not guaranteed that they will be shown. And for most websites, I think we just don't show site links. OK, OK. And what we can do to appear site links such walks, which appear just. Yeah, the site link search box is something where you can add structured data to your pages too. But the structured data is only used when we show the site link search box. And it's similar to site links in that for a lot of sites, we just don't show the site link search box. I think it's a confusing feature because of that, because you can add markup. But the markup only has an effect if we would already show something for your site. OK, we can't depend on the schema markup for it. Exactly. OK, OK. Thank you so much for the information. Sure. And then Kit, probably pronouncing your name wrong. Sorry, I think you're muted. Now what button? Yes. OK, hello, John. Perfect. Hi. Yes, OK. I have a question. My website has a problem with redirects. Sometimes I make a mistake in the conversation. It's really hard to. My example. Yes. My URL, my website is Ho Chi Minh City, content of HON, HON about information about Ho Chi Minh City, and canonical Ho Chi Minh City. And I have different URL in Ho Chi Minh City and paragraph ID, district 1, Simone content, district 1. And other URL, digital bus URL, canonical, to Ho Chi Minh City. Yeah. Yes. New URL in Ho Chi Minh City and canonical Ho Chi Minh City. OK, district 1. Yes. Bus when I, if I redirect 301 from our URL to new URL. Exactly. I have any problem with my website for Ho Chi Minh City. It has my, I have a problem when I redirect 301, OK. OK, so you're redirecting a part of your website to a different part, is that? Yes, yes, yes. When, yes, to a clean URL, to a clean URL. To a clean URL, OK. Yes. Will my URL Ho Chi Minh City will have battery stored on Google or any problem? OK, you understand? Yes. A little bit. It's hard. But in general, when you redirect from one URL to another, we try to forward all of those signals. So if you have links to the old URL and you redirect the old URL to a new URL, a cleaner URL, then we will forward all of those signals and all of those links to the new URL. So that's, I think if I understand your question correctly, we would pass all of that information to the new URL. The all URL, which parameter? Yes, which parameter, a district one or district two. But it's kind of difficult to just Ho Chi Minh City. If I pass it, it means I redirected Ho Chi Minh City to many URL. Is that right? Yeah. I think, so I'm having trouble understanding exactly the configuration for your website. But in general, if there are parameters with the old URL, that's perfectly fine. We can also forward that. If you have other URLs on your website that you're not redirecting, then that's also perfectly fine to just keep them. So that should, I think, just work. If I understand your question correctly. John, the question is also in the chat. I think it's much more clearer with the structure there. I think it's the case that there are some district-related pages that have canonical to the main city page. But the new structure includes a separate district page as their own pages. So what would happen if those parameter URLs are then redirected to the new district pages if they had a canonical until now to the main city page? OK, so basically taking a set of city pages and redirecting them to one general page, more general page. No, I think there was a general page in the beginning with a few parameters for each district that had all of them had a canonical to the main city page. But now there will be separate pages for each district. So if until now every parameter URL had a canonical to the main city page, and now there are separate pages for each district, if they redirect from the parameter, from those parameter pages to the new district pages, if that will affect the main city page, I think. As I understand it, it's like we would follow these redirects on a per page basis. And if there are individual redirects there that take place where you have multiple pages redirecting to one page, or you have individual like this parameter URL redirecting to one clean URL, and you have other pages that stay the same, we would all look at that on a per page basis. So I think if you're cleaning things up, like for a handful of pages for different sections of your website, that's perfectly fine to do like this. That's workable. It's OK. It's no roll up. Yes, thank you, thank you. I have one question. My website is Classify website. It has 100,000 content. Yes. After two months, this content has over time. It means someone buy a house, someone buy a motorbike. When they boss to my website, just two weeks or one week, they saw this. My question is, if the content is too old, what should I do with it? I delete it in my website, or I keep it on my website. Keep it. Yeah, that's a very common problem. If you have a kind of classified content, then it comes and goes fairly quickly. There are two approaches that people take. And for us, they are very similar. So one is to say, the old product that no longer exists, or the page that no longer exists, redirects to the category page to us that would be seen as a soft 404, which is something we discourage, but for users, maybe it's OK. The other is to just say, this page that no longer exists returns a 404 error, and then we would just drop that page. So in practice, in both of these cases, the old page would drop out of the search results, and we would be able to focus on the rest of the website more. So the only thing I would not recommend doing is for the long run, keeping the old page and just adding a label on top saying, oh, this is obsolete. It's expired. Because then you have a lot of pages on your website that Google has to crawl, and first recognize, oh, there's content here, but it says it's expired, so I can ignore it. So that's what I would avoid. But redirecting or 404 is fine. Oh, OK. Thank you, thank you, thank you so much. Thank you, thank you. All right, Mihai. Hey, John. By the way, regarding the question in the chat, I think a more general, I mean to put it in a more general way is when you have a lot of URLs doing something, like they all have a canonical to a certain page, and then you change it, and all of those URLs no longer have a canonical, but they do something else. Maybe they're just indexable. Maybe let's say you have an e-commerce website, and you have a category page, and all of the filters or something like that, they all have a canonical back to the main category page. But then you decide, OK, I need those filters to be indexed or redirect them somewhere, I don't know. And you break the canonical, and then you use them in whatever other way you want to use them. Does that mean that the main category page starts to lose some of the signals that were, until now, aggregated from all of those filters and things like that? Is it kind of a balance? You kind of gain some, you lose some. Probably. I mean, it depends a little bit on what you mean with signals, because with a canonical URL, when you specify that, we don't take the content itself into account. So if you have a blue car, and the canonical is a green car, then we will index the green car, and we won't know about the blue car. If someone links to the blue car, then we know there's a link that indirectly goes to the green car, but we don't know it's like blue car. Right, but that means that if you start making the blue car indexable or do whatever else with it, that means that the blue car will start gaining maybe in rankings and get traffic, especially if it has links and everything else. But you're no longer canonicalizing to the green car. So the green car kind of loses those ranking signals that came through the canonical until now. So you lose some, but you might get a lot more traffic by being more specific towards certain queries. I think that's always a balance that you have to figure out, like there's no absolute answer where you can say you should always split it up or you should always combine it. Sometimes it makes sense to split. Sometimes it makes sense to keep it separate. I guess it's a lot based on what your users are really interested in. And if they're looking for something more specific and you have a page that could provide a better experience for them, then that might make sense. So I want to ask very quickly about something regarding Core Web Vitals in Search Console, because the Core Web Vitals are taken from the Chrome user experience report. So the data in Search Console is taken from the Chrome user experience report. Yet for, let's say you have a CLS issue with a bunch of your pages, you have the option to validate fix. But that doesn't make as much sense as you would validate fix on a coverage report, because it doesn't matter if Google recroses those pages. The data is not from Google, but it's from the Chrome user experience report. So that's a bit confusing. Yeah. We have that there for consistency reasons, but it's based on, like you said, like the Chrome user experience report data. So it wouldn't be the case that we would be able to say, more people should click on this link, and then we have more data to look at. We basically have to wait for things to update there. So it's just a kind of a display report thing that the validate fix actually helps you just kind of see it. Exactly, yeah. OK, makes sense. Cool. We're running low on time, so let me just go through some of the questions that were submitted that we didn't get to yet. And I'll stick around a little bit longer if anyone wants to chat for more as well. The first one I have on top is about AMP. I think we talked about that, also AMP to ranking factor. Will Google consider the origins field core web vitals data for the whole domain, or will it be ranking on a per page basis? We talked about that a bit as well, kind of the different groupings that we show. How accurate is crawled currently not indexed in Search Console despite being a page with sufficient content, without issues. Many pages are excluded from the site from being indexed. That's fairly common. So for the most part, we don't index all pages that we know about on a website. We have to prioritize a little bit. So that's something where it's less a matter of, like, this individual page is fantastic, but more that we need to understand that there's a lot of value to be gained from showing your website more visibly in Search. And that's something that's more of a long-term process, unless something on a per URL basis, where you can say, this page is good now. For passage indexing rolling out, does passage indexing relate with core web vitals for ranking or indexing factors? No, that's something completely separate. Also, passage indexing is kind of a bad name. I hope the people who decided on calling it indexing don't listen, but it's not based on indexing. So nothing changes with indexing. It's really based on ranking. So understanding what is on a page and how to show that in the search results. Does the URL parameters tool in the old Search console still work? When will the new version go live? Yes, it continues to work. I don't know of any date with regards to a new version. I think that's one where we're talking with a team to figure out what the right approach is there. And it might be that at some point, we decide, well, it still works, but it's not as valuable for all users to actually migrate to the new version of Search Console. And maybe it'll go away at some point. Maybe it'll be migrated in a different way. Maybe it'll be taken over one to one. I don't know. How do the core web vitals interact with AMP site enhancements? I think we talked about this as well. We have two regional sites under different subdomains, one in German for the German region, one English for the US. We kept the URL handle of our products the same for easier forwarding, but this means that the URLs in our US store are in German. Is this a problem for search ranking in the US? No, it is definitely not a problem. We use the words in a URL as a very, very lightweight factor. And from what I recall, this is primarily something that we would take into account when we haven't had access to the content yet. So if this is the absolute first time we see this URL, we don't know how to classify its content, then we might use the words in the URL as something to help rank us better. But as soon as we've crawled and indexed the content there, then we have a lot more information. And then that's something where, essentially, if the URL is in German or in Japanese or in English, it's pretty much the same thing. The only effect where I would worry about this a little bit is that users might be a bit confused if they're copying and pasting your URL, if they're recommending it to other people. Then if the URL is in German and it doesn't make any sense at all to them, then that might be something where they're like, what is this URL actually about? Usually if it has product names in there or descriptions that have very similar words in English and German, then that's less of an issue. But if the URL were in Japanese and the users were in the US, then that could be something where they're like, what am I actually forwarding to my friends here? But that's not an SEO factor. That's more of a marketing issue. I work on a big news site, and some parts of the articles are blocked from the user until they click the Read More button. For the Google user by default, let's say it's not blocked behind a login page when we show Google about the whole article. So in general, I don't think this is really problematic, but it might be worth thinking about whether or not this should be used with the paywall structure data, where you can clearly specify this part of the page is visible by default, and this part isn't. I think probably paywall would be not perfectly suited for this. And probably if this is really something where you just click a link on a page and then the CSS switches over to show more content, then that feels like something where from Google's search point of view, we wouldn't really care. It might be that your users are a bit annoyed by this, but that's more of a usability issue on your side and less of an SEO issue. Does the structured data from YouTube carry through embeds? For example, does the structured data need to be recreated on the page that embeds the video? So if you're using something like an iframe, then we can definitely understand a little bit about what's happening within the iframe and associate that with the page itself, which could be something like the title of the video, for example, on YouTube embed. But I would strongly recommend using normal video structured data on a page as well, because you don't want to rely on this vague Google might be able to figure it out thing, but rather you want to really clearly provide that structured data to Google so that Google can show your pages as proper video landing pages, because it has all of the information that it needs there. So that's something we definitely can carry some things over, but for optimal video implementation, for video optimization in search, I would use the normal video structured data. Why in the crawl stats report and search console, there are also very old URLs that are sometimes crawled for discovery and not for refresh? I don't know. I'd have to take a look at some of the examples to see a little bit more about what actually is happening there and chat with the team, but I wouldn't necessarily worry about this difference. It's something where I think splitting those parts out makes it easier to understand that Googlebot is actually refreshing a lot of your pages and that it's normal for it to access pages that have been the same for a longer period of time, but I wouldn't worry about individual URLs falling into one bucket or the other bucket. Will the ranking boost from core web vitals be based on the mobile or the desktop numbers? We announced that the core web vitals or rather the page experience ranking factor would apply to mobile and not to desktop, at least initially. I don't know what the long term plans are and my guess is at some point, we'll figure things out a little bit more fine grained, but at least the initial announcement that we made is based purely on the mobile side. And that's also where, for the most part, I think the harder barriers are, where users really see things a lot slower than on desktop, because on desktop, you tend to have a really powerful computer and you often have a wired connection. And on mobile, you have this much slimmed down processor with less capabilities and smaller screen and then a slow connection sometimes. And that's where it's really critical that pages load very fast. Search console data question. Data on the Search Console UI is slightly different than from what's pulled from the API. And the data in the UI looks more approximated. Is the data pulled through the API more accurate? So both of these sources are based on exact same databases internally at Google. It's not that we have one set of data for the API and one set of data for the UI, but rather it's the same data. It's available in different ways. And depending on how you query the API, you might see slightly different numbers. But essentially, it's exact same data. If a domain organizes its international sites and subfolders, would Google crawler have an issue with different international sections on a site using different page templates or navigation? Since a site navigation template consistency has been mentioned before as a factor in SEO, that's perfectly fine. So we do try to understand the templates of a page and to understand which parts of a page are the primary content and which parts are more boiler plates, like everything around it, the menus, the footer, the titles, things like that. But we can pick that up for different parts of a website in different ways. So it's not that the whole website has to have exactly the same template, most websites don't. The thing I would watch out for, especially since you mentioned international sites, is if you're using hreflang and you have very different infrastructure across the different language versions, then it makes it really hard to link those pages together with hreflang. It's not so much that Google would have trouble with it, but if you can't specify the hreflang yourself on those pages and you want Google to understand the connection between the language versions or the country versions, then that just makes it a little bit harder. But purely from an SEO point of view, if you can create proper hreflang, if these pages are normally crawlable and indexable, then I wouldn't worry about that. OK, wow, so many questions and so much more left. OK, but maybe I can take a break here, pause the recording. And if any of you want to stick around longer, you're welcome to do that as well. Thank you all for listening in, for watching, for asking so many questions. It's like, wow, so many hands are still up. So many questions still in. It feels like we could do these for hours and hours, but then I would probably, I don't know, fall into the ground or something afterwards, which would be unfortunate on a Friday evening. Cool, OK, let's take a break here. I'll pause the recording. And like I mentioned, if any of you want to stick around, feel free to do so. Otherwise, have a good weekend, and maybe see you in one of the next sessions. Thanks, John. Goodbye. Cheers, John. Bye.