in SEO

JavaScript SEO: Avoiding the Pitfalls of Server-Side Rendering

Wack oder Top?

Note: This Post was originally published at 6th of November 2019, on the Searchmetrics Blog

JavaScript SEO is currently one of the hot topics in the SEO industry, as the modern web evolves and more and more websites relaunch or are built on JavaScript-based web applications, mostly on React or AngularJS. With this, more complexity is added to SEO, as we need to make sure that Google is able to render JavaScript effectively, so that the pages can be indexed and ranked correctly. This can be achieved using server-side rendering. However, this doesn’t come risk-free. In this article, I go through five server-side rendering mistakes and explain how you can avoid them.

What different kinds of server-side rendering exist?

Pre-rendering your website for Google on your server (server-side rending, SSR) is one option for ensuring that your JavaScript website is Googlbot-friendly. In this way, you can deliver the pre-rendered HTML version of your website to Google, while the user gets the normal (not-yet-rendered) browser version.

how-dynamic-rendering-works

However, when it comes to server-side rendering, there are also different ways to render, as you can see from the next chart, which has been helpfully provided by Google, with some useful additions from Jan-Willem Bobbink.

rendering-on-the-web-seo-version
Source: (https://www.notprovided.eu/rendering-on-the-web-the-seo-version/)

There are three main ways for of setting up and executing server-side rendering:

1. Server-side rendering with dynamic HTML

Server-side rendering creates a rendered HTML version of each URL on-demand.

2. Static rendering with static HTML

Basically, this creates a pre-rendered (static) HTML version of a URL ahead of time and stores it in the cache.

3. Server-side rendering with (re)hydration with dynamic HTML and JS/DOMs

The server provides a static HTML version of the URL and the client (browser etc.) that already includes a structured Document Object Model (DOM) mark-up. The client takes this and turns it into a dynamic DOM that can react to client-side changes and makes it more interactive.

Google published a great overview of rendering the web, with all pros and cons, plus a deeper explanation if you are interested.

Pitfalls when rendering JavaScript websites via the server

We recently came across some SSR issues with one of our clients. They run their website on Angular JS and render it with Rendertron via a Headless Chrome.

They use a static SSR render approach, which means that they render a page and cache the rendered HTML on the server (ahead of time). The cached HTML will not be replaced automatically but is based on the rendering logic. The following are five issues that we encountered working on this website. I’m sharing them with you here, so that if you have similar challenges, you’ll have an idea how to deal with them. However this is can be considered as an unfinished/expandable list.

1. When you do nothing

When you don’t care and don’t pay any attention to how Google renders you page, then let me show you how Google renders (actually sees) your page. This is based on a website that is built on a Single-Page Application (SPA) using a JavaScript framework, without server-side rendering.

javascript-disabled

This doesn’t look particularly promising, does it? Which is exactly why it’s important to use SSR, because then it looks like this:

Javascript-Website-with-SSR

2 . Pagination

How to deal with your paginated pages when it comes to rendering?  Well, especially in publishing, paginated pages can still be a good thing to serve Google with your (most recent) articles while Google is crawling them. If you take a look at your log files, you’ll see how Google is accessing your pagination, so that you know where it makes sense to provide a prerendered version (Spoiler: You don’t need to provide 399 URLs with a rendered version)

As our client renders with a static SSR approach, they just rendered the first page and mirrored the cached version of Page 1 up until page 10. Without any rendered version from page 11 and onwards. Here are two screenshots that show the problem quite well, with exactly the same content from page 1 also provided on pages 2-10.

 

Screenshot of JavaScript paginated site with same content as page 1

This means that you give Google 10 Pages with the same content and articles. Ideally, you want Google to render all pages as unique with correctly paginated articles.

3 . Renew rendered version of category pages after new article/product is published

Our client has increased its ranking in almost every Google News property pretty significantly, such as AMP Carousels, Google News Boxes and Mobile News Boxes, with Publisher Carousels the exception. We started to investigate this and it turned out that our client did not update their cached version when there was a new article published. We found out that they renewed their cached version of main categories a week later:

javaScript-rendering-Issue-on-SSR

and on subcategories even a month later.

javascript-rendering-issue-on-serverside-e1570810168251

 

This led to the fact that they still had an old article on the topic of Brexit in their pre-rendered version, but they didn’t have all new articles published on the topic. Our assumption here is that, because of this issue, there were not enough fresh articles for Google to populate a carousel and this had a big negative impact on their performance. We are still investigating the impact of the change.

4 . Rendering can cause duplicate content and the wrong canonicalization

Providing a pre-rendered version of a URL can cause system-based problems. As our client delivered pre-rendered pages, each with its own URL created by the render engine, these URLs had the parameters “p=1; render=1” and were fully indexable:

google-serp-parameters-render-1

There was even a new canonical set up by the SSR engine for that URL. Pretty spooky, huh?

screenshot-search-console-mit-canonicals

 

Ideally, you want to exclude these parameters from Google crawling.

5 . Page title change when rendering

We also found out that current page titles were rendered through JavaScript. This was done in a way that meant the HTML meta title always showed the brand name when JavaScript was disabled. And when the user agent is not Googlebot, it only renders the HTML page title. See the following two examples below. The first shows the URL with JavaScript disabled. The second is the same URL, but with JavaScript enabled.

screenshot-javascript-disabled-1
URL with disabled JavaScript in the browser showing a different (just the brand name) title.

 

screenshot-javascript-enabled
Same URL with enabled JavaScript showing correct HTML Title.

To ensure that metadata is always correctly rendered, you should include it in the non-rendered (JavaScript) version of the URL.

Conclusion

Server-side rendering can’t be used as a cookie-cutter approach for rendering singe-page applications. Special attention is needed for static approaches where you just provide a snapshot. As you can see from our client’s example, you need to make sure that the SSR engine always provides an up-to-date version of the URL, otherwise Google won’t be seeing and capturing your most recent articles, and you’ll be missing out on valuable traffic.

Before relaunching from an HTML-based website to a JavaScript-based framework, ensure that server-side rendering is included and that is is always dynamically serving!

The following two tabs change content below.

Björn Darko

Director Digital Strategies Group bei Searchmetrics
Vater von Superman & Batman! Director Digital Strategies bei Searchmetrics. Vorher Head of SEO im Medienhaus Ringier AG, sowie Head of SEO bei ricardo.ch.Ausserdem auf www.hackenteer.com unterwegs. Norddeutscher mit Herz für St.Pauli und allem was dazugehört!