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

How a medical site recovered from the Google Medic / EAT updates

  • Put all EAT related To-do’s on the backlog
  • Have a meeting with the developers
  • Developers are extremely busy with real improvements
  • Google will put the site back due to EAT-related To-do’s being present in the backlog
  • Happy holidays, Merry Christmas!

SEO Quick wins: finding meta data optimisation opportunities with Data Studio

Many of my clients have great content teams working on optimizing websites. Sending them a spreadsheet of data with some fancy click through ratios for keywords or URLs that perform better or worse than other datapoints will not get them enthousiastic at all. Sending them a fancy interactive graph in Data Studio will get them to work (not a 100% success ratio!) on boring things like optimizing meta descriptions and titles. So how can you spend 5 minutes of your time on Data Studio and make your life as a marketer much easier? Follow the instructions below.

Continue reading

Trick: Solving HTTP/2 Server Push caching issues with Service Workers!

When a browser requests a page, the server is sending the HTML as a first response. Then the browser starts working and parses the HTML to find all kinds of embedded assets like JavaScript and CSS. The browsers needs to go back to the server again and ask for these files. Server Push allows the server avoid this round trip and push the files directly together with HTML so no valuable time is lost. Many cloud hosting providers like Cloudflare start supporting HTTP/2 Server Push already: Announcing Support for HTTP/2 Server Push

Sounds great right? There is only one small problem: caching doesn’t work properly since Server Push is not aware of previous visits and will not check cached resources.  Server Push always tells the browser that it is should receive the files from the server, whatever happened before.

Continue reading