 Oh, he muted himself, that's even better. All right, hello, and welcome to the JavaScript SEO Office Hours, the first Office Hours on Google Search Central, our new rebranded identity. I'm super glad to be here. My name's Malish, but I am from the Google Search Relations team, and I am happy to answer all questions. We'll go through the YouTube submitted questions, and then I'll open the floor to audience questions. I'm really happy to see a bunch of people who are here today in the audience and look forward to the questions. OK, so let's go through the questions. Florin Mihai is asking, they have an old website made with C-sharpened web forms from ASP.net, and they want to build a new one with .NET Core and views that render the HTML using JavaScript and Ajax and extract information to be populated on the web pages from APIs in the back end. It sounds a bit like a mixture of server-set and client-set rendering for me, but I don't know .NET Core and the views system, so I'm not sure how exactly that would work. The question is, will this affect our rankings, and will Googlebot be able to read the content of the website even if it's rendered after the page load event? That's a good question. Generally, it should not break. In Googlebot, it should be able to render it even if it uses JavaScript, but that is something that you can and should test before you launch. You can test this with a more friendly test. You can test this if you have a URL and a domain that is verified in Google Search Console. You want to look at the rendered HTML and make sure that the content in the rendered HTML is the content you would expect. Now, if the structure of your website and the content has changed, that will affect the rankings. If it is a one-to-one copy, it will not necessarily affect the rankings, because if it's really a one-to-one copy of everything the URLs are not changing, then there's no need for us to guard the signals again. If URLs change or the structure changes or the content changes or the way that your page works fundamentally, changes in a way that we need to recollect the signals, then that would have a ranking impact. But that's not necessarily something that you should worry about unless there is a technical problem that we can't see some of your content. That's what you want to test for before you go live. Again, test with mobile-friendly tests. Look at the rendered HTML and see if the content is there that you would expect. Maria Stella is asking two questions. They are using Gatsby and JavaScript and a lot of and have a lot of locale adaptive content on the page. What we do is we check the cookies and the browser language and then the IP in that order to, one, redirect users to the appropriate localized versions. And two, like for instance, basically they check, oh, this is DEDE, so German in Germany, or this is French in France, and so on and so forth. And then they redirect you to that content. They also populate the content on the page using JavaScript to show super localized content for a specific city. And they were wondering how Googlebot perceives this, since they get Googlebot's location through the IP address, which is probably not going to be different or not going to vary that much across the world. Googlebot won't see all versions of the page that users see because Googlebot doesn't crawl from every city around the world. Is this a problem? Is there an alternative solution you would recommend? Yes, to both of us. It is a bit of a problem, because if we don't see the content, then frankly, we wouldn't know it exists. What you should be doing is for the locale content, you should set up hreflang and basically say like, this content is also available under ENUS, ENUK, FRFR, DEDE, and so on and so forth. Basically give us a list of the versions in the different languages so that we understand and cluster them together as one piece of content and then know that there's language variations of each of these. For the different cities and the hyperlocale stuff, make sure that you have URLs and that URLs are discoverable either by putting them in the sitemap or even better, somehow creating a structure where we can use the structure and links in a menu, for instance, to understand where in the structure the different pieces of content belong and how the different cities relate to each other, for instance. So that's two things that you should look into and make sure that we have URLs that we can use and that we find these URLs as well. So discovery will be a challenge as well as giving us hints as to how the information structure looks like. Second question is regarding JavaScript and pre-rendered content. Is it OK to pre-render content for Googlebot but do some personalization for users using cookies? Users may see different content than Google based on their previously selected preferences. Is it cloaking? Again, that is not a super easy answer to that question but fundamentally, if it's just personalization and if I'm on a page for products that say like, I don't know, it's a page for restaurants and I see slightly different restaurants or I see them in a different order, that is fine. If you show me my top used restaurants or something instead of just a generic list of restaurants nearby, that is absolutely fine. It's not cloaking because if I click on the list of restaurants, for instance, in the search result pages and I get to a list of restaurants that are around me, including my top restaurants, that's not surprising, that's not disruptive and that's not that intentioned, I wouldn't call this cloaking. But it's a little blurry. You want to be careful not to give content that completely mismatches from what they might expect from the search result pages. So that's something you want to be careful about. But generally speaking, this would not be considered cloaking. I know you've talked about, so Danielle says, I know you've talked about dynamic rendering and how that's OK. For many, though, bots are only ever shown a non-interactive site that is not rehydrated. How does or will that impact Core Web Vitals? Not at all. Core Web Vitals are coming from real user data, so they would come from people actually browsing your page and that way we wouldn't hopefully not get the dynamically rendered version for bots and then that's not an issue. For lab data measurements, this might be a challenge, but we are not using that data in the Core Web Vitals for now, which might change in the future, who knows. But you don't have to worry about this as of today. Then we have a question from Patrick. Not really a JavaScript question, but more right. Several websites that are ranking Africa and I really want to get the event schema up and running. I've tried JSON with multiple entries. I tried combining the code and using IDs and I also tried switching the data to microdata. Satisfied all requirements, however, the events did not show up in either case. I want to confirm whether the event schema rich snippet is available in Africa. Actually, I don't know unless we are saying it's not available in Africa in the documentation. There's no reason to assume that it's not available in Africa, but it's important to understand that implementing the markup and satisfying all the requirements makes you illegible for potential rich results showing up. That doesn't mean that we guarantee you that you're showing up as a rich result snippet. So it might just be that the algorithm doesn't decide to go with a rich snippet for the query that you are ranking for. And that means that the event schema, even if implemented correctly, would not lead to rich results. So again, it's eligibility. It's not a guarantee that you get the snippets. Then Ankur asked the question here. Not sure if this is something you can answer. We'll find out in a second. We have our website in Vue.js, and we also have an SSR version for Google, so effectively dynamic rendering. How do we measure COVID vitals? Does Google measure results from SSR version? And SpaceSpeed Insights tool will measure it from the CSR version. Again, the answer is similar to the answer I gave previously with us regard to the dynamic rendering question. The COVID vitals are being measured by real user metrics. So basically coming from the Chrome UX report. That means that the results come from real users using your website. They get the client-side rendered version, which means that's where the data comes from. That's where the measurements come from. So that's that. Lab data using a bot user agent, yes. But I had to clarify with the team that what I thought was rolled out is actually currently an internal experiment. The lab data is only used as an experiment internally. It's not actually ready and might actually never happen. So I wouldn't worry about lab data too much. I would focus on real user metrics for the moment, because that's what we'll roll out in May, rather than the lab data measurement. Lab data is mostly useful for testing, really. So you shouldn't worry too much about it. But yeah, if lab data comes in and we do measure that from a bot agent, then that would impact the metrics based on dynamic rendering, which is probably exactly why it's an experimental state and not an actual thing, because we need to figure that one out. Because I don't think it makes sense to give users expectations based on something that comes from the rendered bot version of the page rather than what they would see. So we'll see about that. In general, again, dynamic rendering is considered a workaround. So if you want to make some mid-term, long-term bets and investments, I would not go down the dynamic rendering route. I would figure out the way to basically do SSR plus hydration, as that pretty much gives you the best of both worlds. Even there would be still a discrepancy in the metrics. But again, that's not your problem. That's our problem. We wouldn't use lab data before we figured that one out. Excellent. With that, I think we have exhausted the pre-submitted questions. That means that we are opening up to the floor. Does anyone have questions for me here? Quiet, peace, and quiet. Any tips for the best use of hydration and rehydration? Good question. Basically, whatever is implemented in your framework of choice as long as the render HTML has the content, it doesn't really matter that much. Try to build it in a way that it doesn't basically reload the entire content, but it really just hydrates the interactivity layer on top of it. Because if you have a lot of things going on on the main thread, that might mean that interactivity is hindered and the page starts to feel jaggy and weird. So try to offload as much work as possible from the main thread. Some dumb work has to happen on the main thread, unfortunately, but minimize the main thread time that your JavaScript spends as much as you can. That's general true for JavaScript, which is an interesting position because we haven't fully tested web workers that much. They know of some limitations of our rendering implementation when it comes to web workers. So that's something that we'll have to work on this year and next year. Any other questions or questions? The questions are great today. I love this. Everyone felt quiet. Oh, everyone's submitting questions in the. You can also ask questions a lot in the video, but it's fine to also use the chat. I respect that too. Christian is asking, what happens SEO-wise when there are inconsistencies between rendered and non-rendered HTML of a page, specifically with canonical tags, no index tags, title tags? Does one of the HTML version prevail? That's undefined behavior, actually, which means you shouldn't be running into the situation in the first place. If you do, that's not great. Simply from the standpoint of, what is it that you really want? And some people would say, we want what we sent you in the initial HTML. And other people would say, oh, we actually meant what we have in the rendered HTML. So it is guesswork. Whenever there's guesswork involved, you can't rely on either of the two to be picked. It might flop between the two, or like flip flop between the two, or it might always prefer one or the other. But I can't say which one of it will prefer. Even if you would measure it today, this might change next week. Because again, this is undefined behavior, and this is not something that we would encourage. So I would recommend keeping your versions aligned or leaving out information when you know it to be inconsistent or incorrect. Generally, I would expect the rendered HTML to prevail in most cases. But that's not necessarily the case, especially with canonicalization. It is possible that we might also look at the pre-rendered version, and this might influence the way that the rest of the pipeline works. It might be that you run into really strange behavior, because this might rely on microservice timing, the way that, basically, the indexing pipeline is not one program that just keeps running from A to Z. But it's basically a piece of program that branches out in different services, and then they process information in parallel. And depending on what results, the indexing pipeline gets back from the individual services, and when and in which order it gets them back, you might see different behavior whenever there's undefined behavior. So for instance, indexing generally would wait for rendering to happen. But when we get the initial HTML, we start a few processes at the same time. We, for instance, start duplication, which is fundamentally what canonicalization is part of. So we would try to identify, is this page a duplicate of something else that we have in the index already? We can't make a final judgment call, because the rendering might change the content, and then it might no longer be a duplicate. But we already get preliminary results. If it then says, can I localize this to this other page, then we might, depending on if rendering has finished at that point or is still in progress, we might behave or see a different behavior onwards in the pipeline than if that isn't the case. So that's tricky, and you should avoid that situation in the first place. Then Ankur asks in the SSR version, we have to add a card, add to card, we have an add to card button, which basically does not do anything at this stage. Does Google take this in a negative way? No, we don't click on buttons. At least Google search doesn't click on buttons. For shopping, I don't know, you would have to ask the shopping folks, but for Google search, we don't click on buttons, so it doesn't matter. Then what would be the case if the website is in JavaScript for a Christian's question? I mean, I don't know exactly what that means. If it has nothing in there and then the JavaScript generates the stuff, then that's fine, then we don't have mixed signals. That's okay. If the JavaScript generates a different canonical, as I said, that's undefined behavior, and then you might get either of the responses or results. All right. So it's to clarify the clicking on add into shopping card button. You did clarify, yeah, Google search doesn't directly do that, but like you did say Google Merchant Center shopping might do that in limited cases just to make sure the price is what it is from the shopping page versus the card page. Yeah. And there was a whole big controversy about that when it was written about, I think, in the Wall Street Journal, but it's just for validation purposes, I believe. Yeah, yeah. But again, if you want to learn more about that part, you would have to ask the Shopping and Merchant Center folks because that's a little outside of my area of expertise. It's quite interesting to see that this kind of thing happens and then people get confused about it. So is Googlebot doing this? Then the question becomes, what do you understand as what is Googlebot? Because Googlebot really is a piece of shared infrastructure that different teams at Google may use. For instance, I'm not sure if you ever saw a bot with a user agent speaker, and I think now it's called read aloud or something. That's also Googlebot. It's just a completely different team. So they're using the same crawling and fetching infrastructure, but they're not using any of the rest of the bits. And it's not really the Googlebot that you know for search. So... Right. I mean, the biggest speculation came out when Google started AdWords for ads now, Google Ads. And they have their own Googlebot ads stuff. So, yeah. I thought it was separate. It's kind of, yeah, it's wild. It's kind of interesting. I could write my own version of Googlebot that clicks on all the links if I wanted to. I would have to have the budget for that, and I would have to run through a bunch of approval processes. But if I ever say, like, oh, I want a Googlebot that actually clicks on all your links to see what happens, I could implement that. It still wouldn't be the regular Googlebot, but the infrastructure would allow me to do that. Didn't you guys open source some of that? Um... We do have the robots.txt parser that is open source, which is one of the microservices that we run. We do have the... So Puppeteer is using the Chrome DevTools protocol, which internally used to be called Light Rider, and that's kind of a way to programmatically control Chrome instances. And that's used in a very customized and interesting way in the web rendering service. So a few bits and pieces are at least partially open source, and I am hoping that we would see more stuff moving towards open source because I think a bunch of our components are quite useful for other purposes as well. Ah, there's a clarification on the previous question from Encore. I mean, if the website is built in JavaScript and if the tags are different from... Yeah, that's exactly what I answered for. If the SSR version and the JavaScript versions are disagreeing on things like canonical tag, it's undefined behavior. You might get either us treating the initial version as the real thing or the rendered version. You can't rely on that. You should avoid that situation. All right. I think we have an abstract question. Let's see what I have. So machine learning is used throughout Google search. We know for ranking and other purposes, I know you in the search off the record podcast with Gary spoke a little bit about the duplication process and figuring out the canonical. And there Google uses, puts in the things for machine learning for citing weights to what the canonical page is. In terms of rendering and crawling, is there a lot of machine learning used there as far as you're aware of? For crawling, yes. We do have a bit of machine learning in there as well. As far as I remember, I'm not sure if this is actually live or if this is experimental, but I know that we are using machine learning to identify or to predict the result of a crawl in terms of like, what will we get in terms of quality content? Like, can we predict or it's definitely interesting to try to find out if we can predict what kind of quality we'll get from a given crawl before it happened because that would allow us to schedule crawling more intelligently. The same goes for if we can try to find out, if we can predict freshness as in like, do we know that we have to schedule this website daily or is there like, can we gather signals that tell us not to do this daily and then use machine learning when predicting that for sites that we haven't had as much data for? But again, I'm not sure if we're using this in production or if this is experimental so far. All right, so to clarify, you may be using machine learning for crawling purposes. For one, should I bother crawling this page as enough quality for us to use our resources to actually try to even bother crawling the page? And two, for how fast we should crawl a specific site because of, you know, as in a new publisher and so forth. And generally, I guess in the past, you may not use machine learning to define those things, but now you might be, or you may decide to do so in the future. I mean, we have been in the past gathering signals on this and making decisions holistically on the signals and we might now use machine learning for that to predict this even better and more precisely. But nothing on the rendering side. Not as far as I'm aware, we are not having any machine learning on the rendering side though. Okay, thank you. Welcome. All right. Any other questions? Hi, Martin. I have a question about the web rendering service. So from what we know, the web rendering service is very resilient. So if a fetch, if our rendering fails, it might retry later. So can you specify a bit more about when it's retry if there is like a percentage of fetch that have to fail to retry the render or any other things that file these retry later? So just to the bugs, you know, problem? Yeah. In general, this is something that you shouldn't need to worry about. That's something that we need to worry about. Very basically, like this is out of your hands. This is our problem if a rendering fails. We are pretty good at detecting rendering failures either on the network level when there's a crawling issue with actually fetching the resources, for instance. We might fall back to the cache. If the cache gives us a version that looks okay, then we should be fine. We also try to basically render multiple times and see if the rendering result changes too much because basically the rendering tries to be as deterministic as possible. So we shouldn't see too big of a change except for maybe content, but like even that should not change super much when we render multiple passes in one go. And if we see things like we have signals from a page that has been high quality and now comes out with very few bits and pieces of content, then that would be considered low quality. And then we would assume that this probably is a failure on our rendering side. And then we would retry. We often use the cache to bypass most of the failures because most of the failures are actually network failures. Sometimes we do have a non-responding Chrome that's taken care of by the internals of the web rendering service so that you basically then get immediately rescheduled on a new fresh Chrome instance. But all of that is something that A, you don't see, B, you don't really have to deal with. That's our job to make sure that that's just working. As far as the indexing pipeline is concerned, it says, like, render me this page and then it gets a rendering back. All the failure management is handled inside the WRIS. Okay, thank you very much. You're welcome. Good questions. That's really lovely today. Thank you so much, everyone. Bring on more. Okay, so if, yeah, I have another one. So about CPU usage. So we can use like tools that we have from that tool, so stuff like that to have an idea of the max amount of CPU we can use without the rendering. If the rendering might stop a script that is loading too much, that is using too much CPU. There is a way we can say like, okay, my JavaScript is using 80% of my CPU when I'm loading on my Chrome browser and my DevTools or stuff like that. Obviously, this depends on computer. So on my MacBook is probably different from the Chrome instance machine because they're using different CPU, different RAM. But there is something that we can do like, okay, we can remove the JavaScript memory leak and that's okay. You know, we can have like a profile limit. So we can say, okay, this is the limit. This is the, I can't do much with this. So I have to debug stuff and optimize the JavaScript file. Again, a really good question and there's no easy, hard and fast rule for this either. Again, it's horristically done. And generally speaking, you should not really worry about the CPU consumption. If your JavaScript ends up in an infinite loop, we will cut that off. If you are taking ages, and I mean ages and I'm very specifically saying ages and not a specific number here because there is no specific number thanks to the way that we are actually rendering which is interesting and complicated and unfortunately internal only. You don't really have to worry about that but like if your JavaScript takes ridiculous amounts of time on a reasonable machine and that could be your MacBook, that could be your phone, you should assume that you definitely want to do something not specifically for Google but for your users. So it becomes a problem for your users and your real world performance before it becomes a problem for rendering. Okay, so if the, if the JavaScript file is working on a smartphone or a computer in the render should be, should be fine. Okay, this is something's interesting. Thank you. You're welcome. Happy to help, happy to answer all questions. And again, I know that you probably want to hear like, oh, yeah, if it's this many instructions or this much CPU usage on this machine, that's not how it actually works. Yeah, yeah, yeah, you know, I am a bit interested in how the web rendering service is built but this is something. I'm just waiting for ability to let out more details but I have been asked for holding some bits and pieces back. I'm really excited about that as well because I think our engineering team did a great job there. And I'm more question about this CPU using our broker would work because I already tested it but would also these be useful in the rendering machine because yeah, just to know. Generally, yes, I mean, parallelizing work that can be put in parallel is always great. That's great for your users. That's easier for rendering. Just be careful to test this very, very carefully because especially with web workers, there's so many edge cases that I tested with. I tested a few very simple things and they failed in rendering. Partially because very few people do this and very few people do this in a way that it matters for the content. So I am a little cautious when recommending to put things into web workers because in theory it's great and practice it needs very careful testing. Yeah, I test a bit something that is connected to the timing on the page and yeah, it's not really working very well because obviously you have a different time inside, time inside the rendering machine. That's probably it's fake, those stuff like that. So yeah, it's not working really well there. Exactly, there's lots of bits and pieces. It's also a measure of the way that we detect how the website rendering is progressing is not working super well when there's threads involved. So it's fascinating and there's still a lot of work for us to do in the web rendering service. It's not all done and dusted and perfect yet. Yeah, thank you very much. Thank you very much. You're welcome. Thank you very much, Yakumo. More questions? All right, if there's no further questions, I'll give you five, four, three, two, one. One, last call for questions. No? All right, in that case, thank you all so much for joining the live recording. Thanks everyone who submitted questions in the YouTube thread. I'll just post the thread for the next one in two weeks, which means that's the, oh my, I can't remember when the next one is. I think that would be on the 25th of November. That will be the one on 10 a.m. CET. So I'm trying to like serve all time zones as much as I can. Thank you very much. I'll post the recording later. If you're watching the recording, thanks for watching the recording and have a great time. Stay safe, stay healthy and bye-bye. See ya.