Alright welcome everyone to another special episode of asking Google webmasters and today, we picked up our t-shirts. Cool dinosaurs, because we like dinosaurs and scary topics like JavaScript. Alright so in the ask google webmaster series, anyone really can submit questions to us using the hashtag a scuba master, and today's topic is all about JavaScript in SEO Minneapolis, so let's get started. Alright, root asks us on Twitter when using the rails asset pipeline for caching what status code do we give the old asset? Googlebot crawls these stale assets which we currently have 404 do, 410 them instead, or do we keep them alive for a couple of months. What do you think? I don't really know what a rail the asset pipeline is marketing Ronnie. Tell us more to be fair and it doesn't really necessarily matter to this specific question because it's pretty much the same for every asset that you've got and that you might update at some point. The way our asset pipeline, however, is a way for rails to process and pre-process and your assets. As you have them in development for the production website, so it's basically like an automatic pipeline of dealing with your assets in your rails application but what it boils down to is you have old assets. You eventually have a new version of your website and then you have new assets like some old JavaScript.

Some previous versions of your CSS and images that you'll no longer have on your page and stuff like that right? So how do you deal with that? Well, you just keep it around for a while until we recrawl your actual HTML content and then we get the new assets and afterward, but because of caching we try to make it so that we can crawl and index your page as quickly as possible, but that might mean that we're

going to keep using outdated URLs and if you fall for them. Then we're just gonna end up with broken renders in between and that's something you probably want to avoid. All right, so better to keep them around for a while and you can use your server logs to figure out. When we stop asking for these assets and then just fully remove them cool. Our next question comes from Michael Michael, is asking if in

pre-rendering can you skip or replace irrelevant content like JavaScript and generated SVG bar graphs or anything else that this Java generated really from my point of view and you should include everything as much as possible so that whenever Googlebot accesses your pages it sees the full content does that kind of match. I'm not really sure like with pre-rendering and do they mean, so they can either. I mean so pre-rendering really is just running your JavaScript on the server-side. Once whenever the content changes and then deploying the static assets to everyone. In this case, you do not skip things, but if you mean dynamic rendering where you would basically just give different content to the users versus crawlers, then even then I wouldn't skip and include everything.

Our next question comes from Graham Graham asks on Twitter. If your site has a chat function that rewrites the title tag for notifications to the visitor, how do you or the app supplier prevent Google from indexing the javascript rewritten, a version of the title tag? I would say no, so as we are rendering the page, we are picking up written titles. So in that case, whoops well could do it, you could hide or delay the chat behind the user to action because Googlebot doesn't interact with things. So, if you have to click on the chat button first and then the chat pops up and then changes the title. I think that would be one way of dealing with this property Michael is asking or asking. Again in the pre-rendering can and I still use JavaScript and inside the rendered output it's like JavaScript that generates minor content or layout changes or like anything that isn't really heavy I ajax. Definitely, so with pre-rendering you're basically regenerating those pages ahead of time and serving. All of that to you and it's perfectly fine to have some JavaScript elements in there, as well and I think from a user point of view that

makes sense anyway because sometimes you can serve content very quickly. If it's pre-rendered and you can use JavaScript to add interactive elements and that's perfectly fine to make sense, so you don't have to strip out all of the JavaScript. If you pre-render your pages,

absolutely it's also, and if you do pre-render and then uses something that is called hydration and that's basically what you are aiming.

You have all the content pre-rendered and then you use JavaScript to enhance it into a single page web app, so for instance that is perfectly okay and it's just about giving the content to the user as quickly as possible. So it sounds like JavaScript and SEO Minneapolis Services are gonna be with us for a while and again, I do think that sounds pretty cool and so, one of the things I keep hearing from people is like pre-rendering or dynamic rendering that ever gonna go away do. I still have to bother with all of that and this question comes up a lot, so fundamentally it will not necessarily go away entirely, maybe except for dynamic rendering is a workaround, so we hopefully do not have to keep that around for much longer but server-side rendering and pre-rendering are actually very fundamentally useful concepts, because they give the users and crawlers the content quicker right. It's HTML, we can pass that as it comes in javascript needs to be parsed and executed to generate the content so we cannot basically stream the content on the browser side and we don't have to. Here's still a lot to do and maybe we should do separate YouTube videos for that and what do you think mine it's a great idea and one we already have. If you are checking out this channels playlist you'll see that we have a series called JavaScript SEO and Minneapolis SEO Company already and it has a bunch of episodes that are covering many different topics already, but we are working on more episodes, so I guess subscribe to this channel to stay tuned for more sounds awesome and feel free to continue submitting your questions using the hashtag Google webmasters. All right, thanks for watching and see you next time.