 Hello, and welcome to another JavaScript SEO Office Hours. My name is Miles Schlitt. I work for Google. I am in the search relations team, same as John Miller and Gary Eish. And yeah, thank you so much for submitting your questions, and thanks to everyone who joined. These Office Hours are currently done in a weekly basis. There's one in the earlier time slot for me and one in the later time slot, so you can figure out which one works better for you. We announced them at youtube.com slash Google webmaster slash community. So keep an eye out for these. If you want to join these recordings, I'll post the links in the threads that I create there where you can also submit your questions. So I'll start with a few other questions. We have a bunch of really good questions this week. I'll look through them real quick and we'll pick one that is relatively easy to start with. And then I'll give the audience, the live audience, an opportunity to also ask. So is Googlebot still crawling the sites in the second wave or has this been updated to include in the first wave? Ah, that's a famous question. And I fear this question every time it comes up because the first wave, second wave has been a simplification that we use to illustrate how Googlebot processes things. And a lot of stuff happens in parallel inside Googlebot. So it is relatively hard to explain this properly and show this properly. The second wave, as such, wasn't really a thing. It is basically we process, we crawl, which means we make the HTTP request to get your HTML content and the resources. And then we process the HTML that we see. And then while we are processing at the same time, we are also queuing for rendering and then render the page, which means executing the JavaScript. And then we process the rendered HTML again. That means there isn't really a big concern. The concern has been that, oh, the second wave takes up to a week or longer. But we looked at the data last year and we found that the median time in queue is five seconds. So between rendering and between crawling and rendering, there's on in the median case, there's five seconds delay, 90th percentile is minutes. So you shouldn't really worry about that. All websites go through rendering anyway. So you don't have to worry about that either. And there is no such thing as rendering budget just to get all these out. So the second wave has been a simplification to explain a very, very complex concept and process that we are no longer using. The metaphor we are no longer using because it is a little misleading. And we haven't found a better metaphor of saying this. But fundamentally, what we try to say is if your content is in the server-side rendered HTML, that's what we already look at. So you can, for instance, make sure that we find important links a little quicker, like we discovered them quicker by having it in the processing right after crawling. But it's not that huge of a difference for us if it's only in the content after we render. Makes no big difference these days. Cool. Another question that I get a lot of times is when I view a source on a client's website, I see that content is contained within some sort of JavaScript object. But if I view the page in developer tools, I see that the function has done something with it and turned it into HTML. Am I right in assuming that that's OK? Yes. Short answer is yes. If you would look into the dev tool, sorry, the testing tools that we have, like mobile-friendly tests, your inspection tool, which results test, you see a rendered HTML tab. And if the content is in the rendered HTML, you're good. That's absolutely not a problem. It's very normal that the view source is basically what the server sends. So it's normal that if you use client-side rendering, that the content isn't in the HTML when you use source it. But once the JavaScript executes, it actually injects it into the DOM as proper HTML, and then everything's fine. So that's not an issue. All right, before I go through more questions from YouTube, any questions from the live audience? OK, if there is no live question, then another YouTube question. With dynamic rendering, dynamic rendering means you serve a pre-rendered non-JavaScript version to bots, but give the normal client-side rendered or whatever version to users. With dynamic rendering, we're looking to serve Googlebot a version of a page with navigation accordions fully expanded with individual hrefs. But users will land on a version where it's not. Likewise, we plan to not pre-render cookie constant banners for search engines version that's having it for users. Is there a quantifiable threshold guideline, be it in this encoder pixels where dynamic rendering could mistakenly be considered cloaking? No. There's no threshold guideline. Cloaking detection is complicated. And for obvious reasons, we don't want any of this to be gambled with. So we don't really say much about this. The thing is, as long as you are having a use case like this where just auxiliary content like content banners or accordions are different from what Googlebot sees and the actual user sees, it's not really an issue. That being said, it shouldn't even be a real big issue to begin with. Even if you wouldn't dynamic render for Googlebot, that should not be a big problem. Because we are seeing things that are invisible as well. We might just consider them slightly differently, but that normally isn't hurting you or is causing a problem. So that's a very good question. Generally speaking, just don't mislead the users. And if you are tricking the user to believe something, if you trick the user into clicking on something that they didn't intend to do through Googlebot. So if you tell Googlebot, hi, my website is about kittens. And then on the website, when the user lands there, it's about, I don't know, boats. That's not great. But generally speaking, making these adjustments for dynamic rendering is not a problem. Would you recommend dynamic and or server-side rendering above using NoScript tags for showing JavaScript content to Googlebot? Yes. And actually, looking at dynamic rendering or server-side rendering, I would recommend server-side rendering. Because server-side rendering generally tends to produce faster results for faster websites for users. So I would consider that over the edit complex. Like both of these things, the server-side rendering and dynamic rendering are complex. They are not easy to implement. If you take the effort onto you, then definitely do the thing that also benefits your users, which is server-side rendering. So do that instead of dynamic rendering unless you can't for whatever reason. But I would definitely prefer that over NoScript. Definitely. Can you please expand a bit on the loading spinner from the last Hangout? Oh, I think, aha. Right. If, for example, I see the spinner in the mobile-friendly tool, but on the HTML view in the tool, I see the content in the dump is there an issue. Last time, there was a website that had a specific question. It was like, why is Googlebot not indexing? Or why is Google not indexing this particular page? And why does it think it's the same page as this other completely unrelated page? The issue there was that the HTML content, actually, including the spinner, was the same on both pages. And a page with just a spinner isn't fantastically interesting in terms of content. So we thought, hm, all of these pages, because they were all just displaying a spinner, are the same because they are just containing markup for the spinner, markup being HTML. And then the page that we ended up picking as the canonical from the set of pages, it's just a spinner. So what we put in search results? Why would we put a page with just a spinner into search results? If you do see your content in the HTML, you are more or less well off. I would still inspect and investigate why we are just seeing a spinner. Why don't we see the actual content? Is there something going wrong? It normally isn't a big issue, especially if we see it in the content. We can index it and understand that these pages are different from each other. But I would still wonder, why is it showing a spinner? There can be legitimately harmless reasons, like, I don't know, we can, for some reason, get to the content quick enough or one specific thing somehow specifically failed in Googlebot. It doesn't fail for users. As long as the content is there, we can see it. We can index it. But I would try to understand why you see a spinner in the previous screenshot. Also, the previous screenshot is an approximation, so don't worry too much if that's not 100% accurate. Cool. Any questions in the audience in the meantime while I'm scrolling on YouTube? I've got a quick one. Is that service I drend in? I'm, really, because I guess I'm a client-side rendered thing to some extent. And I believe you can serve a side render. Is there much benefit to that from a Google perspective or is AMP well understood enough as a framework that it's kind of more of a performance thing that you need to worry about? It is pretty much a performance thing, really. So there's not an inherent benefit. AMP is just one way of making sure that you build a fast website. And you can actually, hilariously enough, you can use AMP in ways that make it not as great and fast as possible. So it is a technology. It is developed by Google, but that doesn't mean that it brings you big benefits, really. The core of that vitals is a project to actually widen the understanding of what makes a fast website. And AMP is trying its best to basically give you a default path to a fast website. But that's pretty much it. So as long as you make your website fast and nice for users and have good content, then AMP or no AMP doesn't make that much of a difference. One more YouTube question. I have a new site in which each article comments are enabled by users. The comments are grouped with a JSON LD called comment. I've seen that Google does not cache those comments as part of the HTML of the page. Are you looking into the Google cache? Because that's not a good testing tool. I wouldn't worry about that, to be honest. I would check with the testing tools if this shows up in the HTML. If it doesn't, then it's a little tricky, because the JSON LD on a page should augment the page content, which means it should describe what is on the page anyway. If you have JSON LD that doesn't match anything on the page, might not give you as much benefit as you wish. So tricky, tricky. What else do we have here? Does Googlebot recognize that select sections of a page content, of a page's content can be hidden by show and hide buttons and therefore decrease the priority or value of that page content based on the fact that it can be hidden? Now, the words to Googlebot assume that because the developer created the content such that it can be hidden by the user, therefore it must not be, no. We don't even click on things. So if it's visible by default, we wouldn't even know that you can hide it. Also, if you choose to hide it, that doesn't mean that we completely ignore it. It just means that we might think, OK, so this is apparently not the most important piece of content here as it is not visible, so we might decide to look at it slightly differently. But generally speaking, that's not an issue, really. I have JavaScript links to related products in my web store. Is it convenient or should they be in HTML? Well, I asked the clarifying question, what do they mean by JavaScript links? And what they look like in rendered HTML and the answer I got is yes. So I'm not 100% sure, but there is documentation for this. If it is a normal AHRF URL, then yes, we can see it. It's fine. If it is anything else, like a button, or a diff, or a span, or something on click, or even an A on click without an AHRF or an empty AHRF or something like that, then no, that's not good. So there's two pieces of documentation that are helpful in this case. One is the webmaster guidelines on making links crawlable, and the other document is the JavaScript SEO basics guideline where this is being called out. So as long as the links are proper links, they are fine. Even if they are JavaScript-generated links. Anyone else with a question from the audience? Martin, my agency is building a lot of PWAs right now. And what resources could we use to make sure that those sites are so crawlable and there's no rendering issues? That's a good question. So we do have the JavaScript SEO basics guide that explains a bunch of stuff that you should probably have a look at. There is even a code lab linked from that guide that shows you what to look out for in single-page applications. And for us, PWAs are basically first and foremost websites. So we don't really care if it's a PWA or not. If you want to test how Googlebot sees this, you can use the mobile-friendly test. You can use the rich results test. If you have it somewhere online where you have a domain authorship verified already, you can use Google Search Console and the URL inspection tool to see how we're seeing the content. And Search Console also shows you if there are problems indexing certain pages or views of your progressive web app. So definitely use the testing tools available from our site to check the rendered HTML. That's the most important bit. Does that help? Yeah, it does. Thank you. Awesome. Great. What else do we have here? Then we have a question where I'm not 100% sure what to say without looking at the site. So there's one question saying, if you're running a single-page app and it was set to render client-side and the HTML preview shows a blank page, what would be the best way to fix this? The answer to that question is it depends. When you say by HTML preview, what you mean is the rendered HTML in any of our testing tools, then look at potentially there is a problem with us fetching the JavaScript resources. If they are robot-ed, for instance, or if there is a robots issue with one of the APIs that you have to fetch to actually render the page, then that might incur an issue. Generally, check if the HTML content is entirely blank, or if there's just a display issue if you are looking at the screenshot. But it really depends. There's no general answer, but I would definitely look close at the testing tools. Also, look at the resources loaded. If there is any 500s or robots issue or some resources not going through, then that's something that you want to check on. I know that some CDNs apparently sometimes do cause us to either see outdated JavaScript or to see some sort of warning because they think we are a bad bot or something like that. I've heard stories of this. I've never actually seen or experienced that, so it's a tricky one. But definitely use the testing tools to dig deeper into why we are not seeing your HTML. Right. Any question from the live audience? I'm running low on questions from YouTube. Just a quick clarifying one. I see a lot of people sometimes try and use the Google cache from the web thing, from the web search to diagnose them. My understanding is that it's probably a pretty poor measure anyway, but is that the initial HTML? That's not the rendered HTML, is it, that's shown in there? It often is just the, so sometimes it is the rendered HTML, sometimes more. Most of the time it is the initial HTML. A bunch of times it's even like an older version. The Google cache is a convenience feature in case a website goes down. It has been built many, many moons ago, and I don't think it's actually actively being maintained. So as the indexing infrastructure keeps changing, it doesn't really change with it because there's no one attached to it, as in like there's not a Google cache team that works to keep this feature going. Because as it works, it works reasonably well, and it's meant as a fallback for a website going down. It's not meant as a way to find out if Google sees your content or it's not a debug tool. I know that there is a Help Center article that makes it sound like it is. I'm actually working with the team behind that Help Center article to figure out if we can clarify the wording and actually point to the right debugging tools, but don't use it as a debugging tool, yeah. Tom, I got your question on the recent core update, but I don't comment on ranking. And I actually don't know about the core update because that's not my area of expertise. So I won't say yes or no to this because I don't know. Good question. I don't know. Then there's like a question 11 minutes ago, Nicholas asked, is it normal to see sometimes the headline tags only visible with JavaScript? Is it a best practice to have headline tags in a JavaScript? I mean, if your content is client-side rendering, then you would see all of your content only when you actually run JavaScript rendering and crawling, so that's fine. If your content is there but the headlines are not there, that's weird, I would say. That's a really weird use case and I would definitely ask the developers why the headlines are not loading as part of the rest of the content. But if all the content only loads with JavaScript enabled, then that's okay too, that's not a problem. But it's not a normal thing to just load your headlines with JavaScript and the rest of the content is there. You should not do that. You should always have your HTML in a good shape, be it either coming from JavaScript, that's fine or having it static, that's fine too. There's a question about a really large React.js website. The site was launched in January, but as of today, there's only 37,000 indexed pages out of 550,000 or more. Every couple of days, 800 pages get indexed. I have tried to speed this up by not limiting Googlebot crawling. So we are now at 512,000 pages apparently, but yeah, it apparently takes a long time for us to index. Well, first things first, I don't know how you got to 550,000 good URLs with interesting content for your users, but I would say I have a feeling that a few of these URLs might not be as relevant. So maybe make sure that we don't spend time on them crawling and indexing. And yeah, there's no guarantee. That's just the thing, like there's neither a guarantee that we will crawl and index all these pages in URLs. There's no speed guarantee, sorry. You'll have to see and wait. But I think like if we already have discovered 500,000 pages since January, that's a relatively good rate. But the other thing is like indexing doesn't mean that it's showing up and it doesn't mean that it's useful. So you shouldn't like hunt these metrics down without thinking. If I have a page that is indexed, but no one ever sees it in search results and no one ever clicks on it, then what have I gained? Not really much. So think about a user's perspective or from a user's perspective, try to understand what are the pages that you really, really care about. And I have a hard time believing that it's a half a million pages that you really, truly definitely care about that are for the masses. Try to get the main vectors into your website index and because they probably have those, try to get those pages indexed that have a high chance of actually driving traffic and then the rest is maybe not so important. So indexing and indexing and ranking is not necessarily the same thing. But that's something that I hear a lot of times. Then there's another question 23 minutes ago from Roshan. My crawl rate is very low. It only crawls 20K to 40K URLs. That's actually not too bad. Could it be why I lost all my discover traffic in September last week? And in September last week, what has been on decline since then 90% drop since September? Discount, no. Crawl rates has nothing to do with either indexing or ranking. If not much happens on your page, then a low crawl rate is perfectly fine. If we have seen all your content and have put it in the index, then why would we continue to crawl? The other thing is discover is an organic feature and that can always come and go. More websites come in, interests keep shifting happens. And then for instance, if you are a travel blogger, you'll probably see less traffic now than you usually see. That just happens. That's how organic traffic works. But there's nothing inherent to like, oh, crawl rate is an indicator for, no, it's not. It's not an indicator for quality. It's not an indicator for demand or traffic or whatever. So no need to worry about that. Hello, what is the best way to clean unused JavaScript code on a website? That's a good question. Generally speaking, I think the Google Developer Tools show you unused code. And that's probably the best for developers because they can see which part of the code is actually unused when they go to certain websites as they have the unlimited and like unminified sources available to them. I think looking at web page tests to see like where's the biggest amount of code that we have is probably a good starting point to see where you need to dig a little deeper. If you use things like Webpack, they usually have a sort of like bundle analyzer where you can see like what kind of dependency or where does the size of my bundle come from or my JavaScript come from. You can do tree shaking. So your developers can write code in a way that if they take in an entire library but only use like five functions out of a hundred that the rest of the code is actually split off automatically. If you want to learn more, there's a bunch of really good stuff around web.dev slash fast for instance and more resources on web.dev in general. So I would like look into those. There's a whole huge topic on its own. All right. Any further questions from the audience? Why audience today? Let's see, maybe I missed the question here. I've got another quick one, if that's okay. A lot of the advice around speed and performance always used to be about basically stitching all your JavaScript files into one big giant file. Is that still really the case with things like HTTP2 and things like that? That's a good question and it's a tricky one. So HTTP2 does make that a little less important but still I would say first things first, Googlebot still uses HTTP 1.1. A bunch of browsers might fall back to it in certain cases. Not every web server is configured to use it. So there's still a bunch of people that are not looking at HTTP2 and its possibilities. But generally speaking, even if we ignore HTTP2, the idea of stitching the entire bundle in one is and has become an it depends kind of situation because as we build larger applications, a single bundle is definitely greater than like a bazillion small JavaScript files because as they have to like get over one by one, I think even multiplexing has some sort of limit, I guess. Even if it doesn't, then still it means like a lot of data needs to be going over the wire that you might not need. If you imagine there, you have a huge website with like a blog and a forum and a shop and you have one big bundle, then that's not exactly fantastic because if I just come for the shop, why would I need the JavaScript for the blog and the forum and all that kind of stuff? So if you can split your bundles along reasonable boundaries, I would say. So try to get the bundle to bundle up as much as you can but try to split it as reasonably as you can because if you really, really care for the traffic to your blog, then don't make people download the bundle for the rest of the website when they don't need it. You can pre-fetch these things so that you can speed things up a little bit. You can use a service worker in the background to fetch these things in the background. That's a much better practice than having everyone download like a huge bundle. The other downside with one huge bundle is caching. If you have this huge website that has a bunch of stuff and one JavaScript file like the app.js file, the browser caches it, great. But then I change something in the blog and everyone, even those who never visit the blog, need to actually download the entire app.js again. If I have a blog.js, let's say like common.js and I have a shop.js, then if I make a change to the blog, only the app, sorry, only the blog.js needs to actually be re-downloaded and the rest can stay in the cache. So the answer is it depends and it needs a lot of measuring and trying things out. There's no one size fits all and HTTP tool makes that even more complicated because you then have to ask yourself like, okay, so how can I make the best use of the multiplexing in the connection? But realistically, even without HTTP in the equation, you have to measure things for yourself and try to make a reasonable call as to where to cut your JavaScript so that it fits the main avenues of your application or website. Just to follow on that as well, is it, I've kind of heard of this one I'm kind of a bit torn about is that obviously if you're serving the blog JavaScript, might be a break in there for allowing things like interactivity, but it seems maybe a bit of a fudge that it doesn't seem a predictable way. It isn't that, yeah, it isn't really that predictable and it's tricky and there's no easy answer at this point, really. And tooling does help with it a lot and I know that you can configure most bundlers to give you different bundles and then catch them separately, but yeah, it is tricky. I'm not saying I have easy answers. Unfortunately, sometimes there isn't a nice and easy answer. Oh, there's a question I haven't seen. Using Angular 9 with server side rendering on my website, as I add more features to the website, my overall JavaScript file size increases, yeah. Following is a page speed inside for one of my features, okay. You can see that the field data for that page in origin is not looking good. I want to know the magnitude of the impact that can, I mean, there isn't an easy formula or something, but seeing like a 70% drop in traffic over two-ish, three-ish weeks, I doubt that that's exclusively because of performance also, because you actually have a relatively good performance score. Your first contentful paint is in 2.3 seconds, sure that can be done better, but that's not like the worst thing ever. You have a first input delay of 300 milliseconds. You have a maximum potential first input delay of 290 milliseconds. That's not really a problem. I guess you can improve caching a little bit according to this audit, but I don't think this is the biggest thing that you need to look at. Traffic drops can happen. That's something that just organic traffic is tricky. It is seasonal. It is a little unpredictable because other websites might come up. It might have to do something with the core update. It might have, like it can be anything really, just try to understand what still works, where the traffic is coming from, what traffic you are no longer getting, and then try to find out why you're not getting that traffic anymore. But I don't see performance as the reason for this. Good. Any more questions from the audience? I'll annoy you again with another one. If nobody else wants to. Go for it, no, yes, sure. Do you, does the web rendering stuff ever take notice of the cash control header, or is that pretty much always ignored? We pretty much always ignore the cash control header because so many resources are undercached that it would make our rendering a lot, but it would put a lot of more load on our crawling and rendering infrastructure. So cash control isn't the best way of telling us to actually redownload something. That's why I am rallying for using versioned URLs as in like app.somehash.js, so that when you change the content, you change the file name because then we have to download it because it's a new file name. But we do look at it like sometimes, but it's not a guarantee. We might ignore the cash control header, which is unfortunate sometimes, but generally speaking, it is too unreliable to signal, unfortunately. Right, so last chance for the audience to ask a question if there are no further questions, and we'll wrap this up. And three, and two, and one. All right, thank you so much for joining. I hope that this was helpful and a little bit of fun, maybe as well. I was looking if the sheep that the neighbors have are showing up, but unfortunately, there's no sheep to show you. If there were, I would show you the sheep. But thank you so much for joining this. Stay healthy, stay safe, have a fantastic time, and see you next time. Goodbye. Bye.