Rendering on the Web – The SEO Version

Last week Google published a handy overview about Rendering on the Web in their developers section. It is aimed at developers needing to make a decision about the architecture they will use for their JavaScript driven applications. The main decision that affects logic within apps is the way rendering is set up. SSR, CSR, Rehydration and prerendering: they describe the different terminology in detail and align the advantages or disadvantages of using the different scenario’s. This overview is resulting in the following handy table:

Rendering and Search Engine Optimization

Both users and search engines are depending on this logic so I am disappointed that the authors didn’t include the perspective of their Organic Search colleagues in their first version. It seems the article was updated (at 08-02-2019) and a short section about SEO impact was included. Besides that, Jason and Addy (Tip: The Cost of JavaScript) are doing great work making developers well aware of some of the consequences of getting more JavaScript driven frameworks and websites. Thanks, the SEO community is thankful for aligning each other’s interest in keeping the web fast.

For optimal SEO results I advice not to take any risk and make the life of Googlebot (and her friends at Bing, Baidu and Yandex 🙂 ) and their render services as easy as possible: server rendering is the way to go. Feed the search engine bots non-cached HTML on the fly. The crawlers don’t want and don’t need JavaScript.

A solution that Google introduced last year and which is also pushed in the article after the last update is Dynamic Rendering: Get Started with dynamic rendering. I do not recommend that due to the different stages where Google needs information for certain tasks. Bartosz Goralewicz shared the risks and issues with setting up dynamic rendering during SMX West: Dynamic Rendering – is this really an SEO silver bullet? The biggest issue I’ve personally had to deal with was the problem with outdated content. Think about rich snippets showing prices, ratings and stock levels.

They also make the conclusion that Google will likely be able to get through your website when the raw HTML found in the mobile friendly test tool will have all the elements. If elements like meta data, textual content and internal links are present there, it should be sufficient. Right, it should be but I have seen so many cases where it harmed the organic rankings of websites that the only way to fix it was going back to serving the bots plain HTML.

There is a number of third party prerendering solutions available and many frameworks are aware of it so they are developing modules to deal with this. Be aware: if you depend on third party prerendering it can cause serious issues if those services are having issues. A power outage, configuration issues or something like that happens and you can’t do anything about it.

Less favourite, compared to server side rendering, solutions to consider are Hybrid Rendering or Static Site Rendering. Hybrid rendering means that the minimal required HTML is first send and then a layer of JavaScript is put on top of it. This also makes that you can save users JS on static pages but can still load interactive elements on the pages where you need it.

Static Site Rendering works well for a small blog but not for complex, dynamic environment since you will generate all HTML files upfront before uploading to the server. That means a single file for every possible URL. That doesn’t sound like a scalable solution, right?

SEO friendly options

Conclusion: keep it simple for search engine bots and use server side rendering and don’t bother bots with JS. The table including SEO Pros and cons:

A number of nice cases where Next.js was used can be found at Next.js showcase

3 Comments

  1. Great follow-up, I like your amended infographic! I agree with the point about Static Rendering being viable for a subset of websites. The heuristic for whether it can work is something like: “does the content change infrequently, and is it a bounded set?”. Some examples of this would be documentation websites or brochure/marketing sites.

    Reply
  2. Thanks for the great article! (and no this is not a robot) 😉

    We have many obstacles to take with our site since we use Angular and CSR. This was an extra eye opener with some room for improvement and debate going on here to consider switching to SSR.

    Reply

Leave a Comment.