If you’re looking for support in the technical optimization of your website, then why not set up a non-binding appointment with our Digital Strategies Group consultants and find out where they can help you?
What different kinds of server-side rendering exist?
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.
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.
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
This doesn’t look particularly promising, does it? Which is exactly why it’s important to use SSR, because then it looks like this:
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.
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:
and on subcategories even a month later.
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:
There was even a new canonical set up by the SSR engine for that URL. Pretty spooky, huh?
Ideally, you want to exclude these parameters from Google crawling.
5 . Page title change when rendering
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.