Start getting comfortable with JavaScript rendering

Nik says: "Everyone is very aware, all around the world, that we are coming out of a pandemic. The foot traffic from the streets is moving online and everyone's looking at their websites and thinking about how they're going to make the most of that. A lot of site owners and web developers have been busier than ever creating new sites, and as a technical SEO a lot of my job has been around site migrations.

This is only going to continue, and I'm seeing a massive influx of developers wanting to develop sites using JavaScript libraries. This is absolutely fine, but there are some important caveats that we, as SEOs, need to be able to understand, and communicate to different parties for project management."

Is JavaScript likely to be better or worse for SEO, or does it depend on how you use it?

"It's a library that you can use, like anything else. The mission is often to get a site to load super-fast. You hear from everybody at the moment that site speed is really important, and it's considered a 'ranking factor'. To oversimplify things, people create a really fast site, hoping that everything else will fall into place. That seems to be the general understanding of most site owners. They go to a web developer and give a brief that just says to make the site as fast as possible. In the web development world, JavaScript is seen as the hero that is leveraged to be able to do that. JavaScript will take parts of HTML and parts of CSS and be able to combine that into simpler forms of JavaScript which is far fewer lines. Therefore, it's far less to crawl and perceive.

However, when it comes to rendering (the process whereby Googlebot retrieves the pages, runs the code, and assesses your content), Google understands the layout and structure on the site differently compared to what is seen by you. The information that Google collects during the rendering process is used to rank the quality of the page - against the content and against other pages trying to rank for those keywords. That needs to be part of the conversation in the planning process, and it's often completely excluded.

I have seen a massive influx of sites being launched that are purely client-side rendered. All JavaScript is client-side rendered by default. As Martin Splitt said, 'If you use a JavaScript framework, the default is client-side rendering. This means you send the bare-bones HTML over and then a piece of JavaScript, and the JavaScript fetches and assembles the content in the browser.' When JavaScript sites are being produced, that's part of the message that gets lost.

Client-side rendering has two main downsides. First, it can increase the likelihood of a poor user experience, because JavaScript can add seconds of load time to a page. That's counterintuitive and puts a burden on the website visitor. Secondly, it affects search engine bots. For example, Googlebot has two waves of indexing. In the first wave, they crawl and index the HTML of the page. In the second wave, they come back and render the JavaScript when those resources start to become available. That two-phase approach means that sometimes JavaScript content can be missed, and not included in Googlebot's index. That's a big thing that SEOs need to understand, and look for, going into 2022."

What common aspects can't be completely rendered, and are often missed by search engines?

"It depends on how much is actually being written in JavaScript. For example, if you're using native server-side rendering in Shopify, and use a language like React on top of that, it's like having jQuery added to a website instead of having it on the server. It means you can't server-side render because everything's been client-side - you're not going to be able to communicate with the server at all. It's not interacting in a way that can produce all the resources that were intended for that page.

A quick way to test this is to go to your site - literally copy out a bit of the text on the page, right-click, go to View Source, open the DOM (the HTML that user agents use to crawl and parse), and try to find some of the text on there. Google relies on the text and the HTML a lot of the time, to be able to parse and understand the context of a page. If it's not able to see that, it's not going to have any context for the other elements on the page. That's your canary in the mineshaft to figure out what's going on with your site, and whether it is client-side or server-side rendered. You need to know if the basic elements on the page are reflected in the HTML that user agents are able to crawl and see.

If you're using a pre-rendered solution, which can be really awesome, you're probably not going to be able to see it. You might have to reverse-engineer it through Cloudflare Workers, but that's a whole other topic."

How does an SEO communicate with the developer to make sure that everything's done the right way?

"It's all about relationships. If you want to work with developers, from a project management standpoint, you have to consider that they have a very set idea of how they want to build a site. You're there to help guide them down the pathway. To use a bowling analogy: you want to guide them down the lane to hit the pins, and not go into the gutters on either side. It's important to have a set list of questions. I've made a template structure for site migrations for my entire team because we need to have specific things.

You obviously need to understand their business workflow, but also ask whether they're changing the CMS, or the URLs of any of the pages. You want to know if they're keeping the same titles and meta descriptions or if they're planning to get rid of any pages or content as part of the migration. Also, you need to start asking if there are any technical considerations that you need to note. Be aware of who you're asking, it might be the owner - who may not know exactly what they've been told to do, or why.

Ask those exploratory questions about the technology stack - how it's going to be done, if it's going to be a custom site, if it's going to be written in Angular or React, etc. After asking those sorts of important questions you need to let them know that if you are going down this pathway, you need to be aware of how it renders. Often, they've got a directive, and the rendering part of the conversation is not even thought about. You need to introduce that as part of the planning process, and make sure that people are mindful. Then throughout the process, you can keep testing and re-evaluating those areas. There are so many different ways to server-side render JavaScript.

It's really important that you ask these questions, then you can change the methodology of how you deliver those recommendations. Developers will appreciate that you're aware of their workflow alongside your directive with the project. The whole goal is to have a successful site, and you can agree on that core principle."

What percentage of websites nowadays are using JavaScript like this, and is it increasing?

"I don't know the exact percentage. I think the growth of this will be exponential because a lot of this stuff is very new. It's new for a lot of SEOs and it's even new for Google. Martin Splitt has been a wonderful resource to the SEO community and is doing a great job of helping people to understand these new changes as it's been rolling out.

It is changing. From listening to Google, and having conversations with people on Twitter, their aim is for their user agents, tools, processes, and browsers to help you understand all different types of languages. At the same time, like everything, it is a constantly evolving process. It is using another language that needs to be compatible across systems rather than just understood. It is definitely an area that you need to be very aware of."

Is it something that only needs to be of concern during a new site design, or should JavaScript rendering be done on a regular basis?

"As soon as it's done, it's good. However, if you are using third party tools, it's always important to see what resources are loaded into that. When you're looking at how many resources it takes to load a page there might a third-party plugin, for example, that doesn't render at all. That can be detrimental. A tool might insert an iframe, and then nothing after that iframe will render properly. It's always important to be aware of what you're looking at.

Remember, when it comes to JavaScript, it does obey HTML5 protocol. There are lots of great things that you can do outside of that. You can provide caching that gives Google a little snapshot to save on your crawl budget, or, if there are render-blocking resources, you can defer it with something asynchronous, which is great. There are tonnes of opportunities. Google's PageSpeed Insights, and Lighthouse as well, are a great way to, again, be the canary in the mineshaft with that stuff."

How can SEOs save time, to free them up for finding out more about JavaScript rendering?

"There are so many amazing tools out there - Google gives you a whole suite of different tools to test how pages are being perceived by their user agents. Search Console is great and, if you don't have it, the Mobile-Friendly test is also useful. You can see the rendered HTML, and you can see the screenshot of what Google is able to see. PageSpeed Insights is awesome as well, and so is Lighthouse.

Search Console is your one-to-one way of seeing what's being discovered, but not indexed, and why. You can see the referring pages and how Google is able to find those pages. If you're not using Search Console regularly, why not? Google has made an awesome free resource for any site owner to unpack and reverse-engineer how these things are happening, and why it's happening as well."

You can find Nik Ranger over at dejanmarketing.com.