How to Be Successful With Dynamic Rendering and SEO

Dynamic Rendering

JavaScript web pages make SEO, an already tricky field, ten times more complicated than usual.

SEO is one of the more technical fields within the digital marketing space. It’s like the popular circus act where the juggler spins three plates on poles.

Technical SEO is like doing that on a tightrope. JavaScript SEO is lighting the tightrope, the plates, and yourself  on fire.

It’s a tricky balancing act. Not only does your website need to be formatted in a way that makes it easy for search engines to process it, but it needs to perform better and load faster than your competitors’ websites.

However, it’s not entirely a lost cause. For all of its nuances and complexities, technical SEO is one of the few ranking factors that you have direct control over.

How do you make your JavaScript website easy for Google to read and understand, while giving your visitors a good web experience at the same time?

The solution can be contained in two words: Dynamic rendering.

We’ll break down what dynamic rendering is, why it’s important, why it’s beneficial for your website’s SEO health, and how to implement it.

What Happens When Google Visits Your Webpage

Google uses an automated program, known as a bot, to index and catalogue every web page on the Internet.

Google’s stated purpose is to provide the user with the best possible result for a given query. To accomplish this, it seeks to understand what content is on a given web page, and assess its relative importance to other web pages about the same topic.

Most modern web development is done with three main programming languages: HTML, CSS, and JavaScript.

Google processes HTML in two steps: crawl and index. First, Googlebot crawls the HTML on a page. It reads the text and outgoing links on a page, and parses out the keywords that help it determine what the web page is about. Then, Googlebot indexes the page.

Google, and other search engines, prefer content that’s rendered in static HTML.

With JavaScript, this process is more complicated. Rendering JavaScript comes in three stages:

  • Crawl
  • Render
  • Index

Google has to process JavaScript multiple times in order for it to fully understand the content in it. This process is known as rendering.

When Google encounters JavaScript on a web page, it puts it into a queue and comes back to it once it has the resources to crawl it.

This is important to understand. For your visitor to search for your website on Google, your web pages have to rank. For your pages to rank, they need to be indexed. For them to be indexed, they need to be rendered.

Here’s why that’s a problem for you.

The Problem With JavaScript SEO

HTML is considered standard in web development. Search engines can render HTML-based content easily.

JavaScript, by contrast, has historically not done well in search. It’s much more difficult for search engines to process. It’s resource intensive. It requires search engine bots to crawl it multiple times.

What this means is that web pages based in JavaScript eat up your crawl budget.

Google states that its web crawler can process JavaScript, although this hasn’t yet been proven. It still requires more resources from Google to crawl, index and render your JavaScript pages. Other search engines such as Bing and DuckDuckGo are unable to parse JavaScript at all.

That means that JavaScript eats up your crawl budget more quickly. Because search engines have to render your JavaScript pages multiple times in order to index them, it’s likely that many elements of your page won’t get indexed at all. Google and other search engines could pass over your metadata and canonical tags, which are vital for the SEO health of your website.

This is a problem in particular for large, or JavaScript-heavy websites.

The thing is, your users expect you to use JavaScript. JavaScript is the reason why you’re able to make flashy websites that make your users go “Wow, that was so cool!”

How do you make a modern web experience that impresses the user while maintaining your website’s visibility so that people are able to find you?

Most developers accomplish this with server-side rendering.

What’s the Difference Between Client-side and Server-side Rendering?

Most web developers solve for the user, and don’t often consider search engines when building websites.

Most JavaScript frameworks such as Angular, Vue, and React default to client-side rendering. They wait to fully load your web page’s content until they can do so within the browser on the user’s end. In other words, they render the content for the human seeing it, rather than on the server where search engines could see it.

Client-side rendering is cheaper than other alternatives. It also reduces the strain on your servers that it would take to render your JavaScript content without adding more work for your developers.

However, client-side rendering carries with it the chance of a poor user experience. It adds seconds of load time to your web pages, during which time users will likely get frustrated and bounce off the page.

Client-side rendering affects bots as well. Googlebot uses a two-wave indexing system. It crawls and indexes the static HTML first, then crawls the JavaScript content once it has the resources to do so. This means that your JavaScript content might be missed in the indexing process.

That’s bad. You need Google to see that content if you want to rank higher than your competitors and to be found by your customers.

So what’s the alternative? For most development teams, it’s server-side rendering: configuring your JavaScript so that content is rendered on your website’s own server rather than on the client-side browser.

This renders your JavaScript content in advance, making it readable for bots. SSR has performance benefits as well. Both bots and humans get faster experiences, and there’s no risk of partial indexing or missing content.

So, Why Doesn’t Everyone Just Use Server-Side Rendering?

If server-side rendering were easy, then every website would do it and JavaScript SEO wouldn’t be a problem. But, server-side rendering isn’t easy.

SSR is expensive, time-consuming, and difficult to execute. You need a competent web development team to put it in place.

It also tends not to work with third-party JavaScript. Websites that use server-side rendering often require external JavaScript libraries or plugins that are difficult to configure, and don’t always work.

This is the case with Angular, which requires the Angular Universal Library to enable server-side rendering. Enabling SSR with Angular requires a lot of moving parts, and if just one is put out of place it could confuse web crawlers and lead to a drop in your search results.

React, another popular JavaScript framework, makes use of the Next.JS library to enable server-side rendering. That requires you and the development team to maintain an additional server at an extra cost.

Therein lies the problem: how do you make both your customer and search engines happy?

To give them both what they want, the solution is dynamic rendering. 

What is Dynamic Rendering?

Solution, client-side rendering and server-side rendering are all less than ideal. Client-side rendering provides a better user experience but has massive SEO drawbacks. SSR is much better from an SEO standpoint, but it’s not a sustainable solution for startups or small businesses with limited resources.

There is a better alternative: dynamic rendering.

Dynamic rendering is the process of serving content based on the urgent agent requesting it.

Essentially, it’s a hybrid solution that gives the best of both worlds. It provides static HTML for bots, and dynamic JavaScript for users. It gives bots a machine-readable, stripped down, text-and-link-only version of your web page that’s simple for them to scan and parse. It gives your human users the fully-rendered, fully-optimized, intended web experience that gets them to interact with your website longer.

How Do You Implement Dynamic Rendering?

Broadly speaking, implementing dynamic rendering is a three-step process.

First, you install a dynamic renderer (let’s say Prerender), to transform your dynamic content into static HTML that’s easy for crawlers to read and consume.

Then, you choose the user-agents you think should receive static content. In most cases, this includes search engine crawlers like Googlebot and Bingbot. There might be others, such as LinkedInbot, you wish to include as well. 

When taking this step, if your prerendering service slows down your server or your HTTP requests go up, consider implementing a cache to store content.

Next, determine if your user-agents require desktop or mobile content. You can use dynamic serving to give them the appropriate solution.

Finally, configure your servers to deliver static HTML.

Verifying Your Configuration

Ok, so now your website implements dynamic rendering. All well and good, but now you need to make sure that it’s working properly.

A few things you may want to check for:

Mobile-Friendly Test: This is a function of Google Search Console’s suite of tools. Google made the switch to mobile-first indexing for all websites in September of 2020. That means that Google looks at the mobile version of your website first, before the desktop version, which means your website needs to be optimized for a mobile-first experience.

URL Inspection Tool: So far so good. But now, you need to make sure that your website is being properly crawled and indexed, and hopefully by now it should be. The URL Inspection Tool will tell you whether a URL on your website has been indexed.

Fetch as Google: This is what you will use to determine the effectiveness of your dynamic renderer. It allows you to make sure that individual URLs are properly submitted for indexing.

Structured Data Testing Tool: If you’re using schema markup in your website (about 31.3% of all websites do), then you’ll want to use this to make sure that your new dynamic renderer isn’t messing it up.

When Should You Use Dynamic Rendering?

Dynamic rendering is an ideal way to fix your JavaScript SEO problems in most situations. It eliminates any issues related to your crawl budget while being cost-effective.

It’s not perfect, though. Many marketers lack the technical SEO know-how to implement a dynamic rendering solution, and it requires an advanced web development team to be put into place. 

So when should you use dynamic rendering?

Dynamic rendering is a good solution if your website is large and has lots of pages with content that changes frequently.

If that’s the case, then your website requires quick and frequent indexing. Dynamic rendering will make sure that all of your web pages get indexed and displayed properly in the SERPs.

It’s also a good solution if your website has rapidly-changing content (i.e., if your website is an eCommerce store with a constantly-revolving inventory). 

Dynamic rendering is also good for websites that rely on social media sharing, like those with embeddable social media walls or widgets. 

Is Dynamic Rendering Cloaking?

Short version: no.

Longer version: still no, and the reason for that is semantical.

Dynamic rendering effectively serves the same content to both search engines and human users. It’s just presented differently according to the format preferred by each.

Cloaking is the practice of serving markedly different content to search engine bots and humans. This is considered a black hat SEO tactic. While the short-term benefits of cloaking may be tempting, the potential risks are not worth it.

To reiterate: dynamic rendering is not cloaking, as long as it serves the same end content to both crawlers and human users. It’s only cloaking if you serve completely different content to each.

In fact, prerendering is actually the JavaScript SEO solution recommended by both Google and Bing, the two biggest search engines. Not only that, but Google recommends Prerender in their official documentation on dynamic rendering.

Wrapping Up

Technical SEO is never easy, JavaScript SEO even less so. But there are things you can do to make it easier, and reduce the burden on yourself, your web development team, your website and your budget.

To summarize what we covered:

  • Google processes HTML and JavaScript very differently. JavaScript takes more time and resources for Google to render, and needs to be crawled multiple times to be rendered and indexed. It thus uses up your crawl budget quickly. 
  • JavaScript web pages default to client-side rendering, which has substantial SEO drawbacks. It leads to missing elements and content, which puts you at a competitive disadvantage.
  • Most web developers solve for this by using server-side rendering, but this is complicated, expensive, and isn’t a good solution for every online business.
  • A better solution is dynamic rendering: serving the right kind of content according to who is accessing it. JavaScript for people, HTML for web crawlers. 
  • To implement dynamic rendering: install the appropriate middleware; determine which user-agents are served static, mobile or desktop content; and configure your servers to deliver static HTML.
  • Dynamic rendering is a good choice for large or slow websites, websites that use a lot of JavaScript, or websites with frequently-changing content. 
  • Dynamic rendering is not the same as cloaking because it effectively delivers the same content to both human users and bots. In fact, dynamic rendering is the JavaScript SEO solution recommended by both Google and Bing.

If you want a dynamic renderer that solves all of your JavaScript SEO problems, look no further than Prerender. All you have to do is install our middleware, and the rest takes care of itself.

Your website will load fast, get indexed reliably, and will attract more visitors in no time.Try Prerender today. Get Google to finally work with you rather than against you.