In case you missed it, Google recently specified that:
- Google recommends using server-side rendering, static rendering, or hydration instead.
Although the official Google documentation sheds light on how we should treat dynamic rendering now, the question that bothers many remains: why exactly should we consider dynamic rendering a temporary solution?
If this question triggers you to look for the answer like me, let’s dig in!
Why is this update important?
To understand why we consider this update vital, let’s travel back to see how Google previously treated (dynamic) rendering.
The dynamic rendering story timeline
Then, in 2019, Bartosz Goralewicz elaborated on dynamic rendering during his presentation at SMX WEST. He aimed to explain why this solution isn’t a silver bullet to all rendering issues.
What is dynamic rendering?
Google complements that definition by specifying:
As the rendering stage, in general, is expensive to be processed by crawlers, dynamic rendering serves Googlebot an easily understandable, lightweight, static HTML version to make your content ready for possible indexing faster.
That’s why Google suggests dynamic rendering can be a trade-off mainly for websites:
- relying on sharing their content through social media or chat applications.
Rendering is a crucial step of the indexing pipeline ‒ how your website gets rendered affects how search engines see your content. And to address the needs of both bots and users, you need to learn about two different approaches: server-side and client-side rendering.
With server-side rendering, bots and users receive your website’s HTML version fully rendered on the server immediately, at the request time. The fact that rendering HTML is handled on the server makes the whole process faster for browsers and generally easier for search engines to pick up the content.
Also, although server-side rendering is a recommended solution, Google underlines that choosing it doesn’t influence your rankings ‒ it only differs from dynamic rendering in terms of setup and maintenance:
How does dynamic rendering work?
Google recommends using the following dynamic renderers:
- Prerender.io (third-party software),
- Puppeteer (open-source software), or
- Rendertron (open-source software).
Having configured any of the recommended solutions, remember to:
- Choose the user agents you want to serve the static HTML version of your website, e.g., “googlebot” or “twitterbot.”
- Set up a cache to enable your website to be served as quickly as possible and avoid timeouts.
- Ensure that the prerendered version of your website serves the device-oriented version. In other words, mobile search engine crawlers should see the mobile version of your site when other crawlers ‒ the desktop one.
- Ensure that your server can serve the static HTML to the chosen user agents.
Regarding implementing dynamic rendering, Google provides its official documentation on implementing and verifying dynamic rendering configuration.
That’s why the crucial step of implementing dynamic rendering is to navigate and verify the potential problems.
Use the Mobile-Friendly Test
The tool allows you to ensure your website’s mobile friendliness and to see the rendered source code of the tested website, along with a screenshot of how Googlebot renders your page on mobile devices.
You may observe some parts of your content missing in the source code ‒ that’s a signal for you that Googlebot wasn’t able to render those resources, and this may be the result of improperly implemented dynamic rendering.
Within the tool, you can dive into the Details section to learn when and by what crawler the page was crawled or even check the HTTP response. If you’re checking your domain, the Mobile-Friendly Test can transfer you into further analysis in Google Search Console.
If you happen to find any issues using the Mobile-Friendly Test, read the article on our blog to learn how to optimize your website for mobile devices.
Use Google Search Console
One of the reports you need to check to make sure you properly implemented dynamic rendering is the Index Coverage (Page indexing) report. It helps you navigate your indexing issues and informs you about which of your pages aren’t indexed and why.
An example of a status that can suggest rendering issues on your website is the “Page indexed without content” status ‒ Googlebot couldn’t see the content because it couldn’t render the page.
Another helpful feature within Google Search Console is the URL Inspection tool. Similar to the Mobile-Friendly Test, the URL Inspection tool allows you to check the status of a tested page and see its rendered version.
As indexing issues may stem from rendering problems, it’s worth analyzing how your website is indexed. You should look at both the number of indexed pages and whether specific sections of those pages get indexed.
To check if a particular fragment of your page is indexed, you can use the site: command together with a text fragment in quotes. But when you have a large website with millions of URLs to analyze, you won’t be able to check them all manually.
ZipTie.dev analyzes indexing together with other data points like word count, titles, headers, meta descriptions, and more. This will help you identify the potential causes of your indexing (and so rendering) problems.
Use the Rich Results test
If you use structured data on your website and care about your rich results, use the Rich Results test to check if the markup is correctly implemented.
The test also shows you the rendered version of your website and outlines how Googlebot understands your markup specifying any errors, their types, and where they appear in the code.
However, just checking off the boxes on the list “How to troubleshoot the dynamic rendering issues” may usually not be enough. The larger and more complex the website, the more difficult it may be to specify what exactly went wrong at first glance.
For example, the error results from the Mobile-Friendly Test may suggest that you have some rendering issues. But, at the same time, the server may have just experienced a temporary glitch and didn’t effectively respond with other resources, such as CSS files. As a result, it influences how the website is displayed, but it may only be a one-time situation.
Troubleshooting (dynamic) rendering will always require general technical SEO auditing and thorough analysis.
Why is dynamic rendering not a long-term solution?
Dynamic rendering uses significant amounts of server resources
Dynamic rendering may significantly slow down your server. A large amount of prerendering requests can make the renderer fail, so as a result, Googlebot will:
Therefore, before you decide on dynamic rendering, it is essential to make a deliberate decision if your website needs it.
Dynamic rendering creates two separate site structures instead of one
Using dynamic rendering, you maintain two versions of your website. It means you need to verify separately that your website is well-optimized for users and for bots.
A dynamically rendered website requires excellent SEO and development teams. And even if you have such teams at your disposal as a website owner, think about how better they could spend their time when not focusing on the dynamic rendering verification instead.
Dynamic rendering worsens the user experience
Dynamic rendering adds an extra layer of complexity when optimizing a website
With dynamic rendering, it’s more challenging to spot and recognize problems generated by it.
Diagnosing such issues and discovering the user agent generating a particular problem requires significant SEO expertise. And you need to be aware that no response to your rendering problems can reflect on your website’s indexing.
What are the better alternatives to dynamic rendering?
When well-implemented, all of the solutions mentioned below may be equally beneficial for your website from an SEO perspective.
However, the effect of implementation relies mainly on the technology you’re using and your development team. Regarding the dev resources, each solution’s implementation cost may differ, but it should be evaluated individually depending on the situation.
It’s one of the most popular solutions you can use instead of dynamic rendering.
From the SEO perspective, the most significant advantage of using server-side rendering relies on maintaining only one version of your website. In contrast to dynamic rendering, you don’t have to verify if the versions for users and Googlebot are identical ‒ all user agents receive the same content.
But watch out: with server-side rendering, users can experience slightly worse Time to First Byte metrics if the server needs to generate static HTML ad hoc, or the server caching the responses is not efficient enough.
And just to clarify: even though the server-side rendering is correctly implemented, SEOs still need to verify all website elements. But all in all, it’s easier to maintain with only one version of a website.
Static rendering (also known as static generation) relies on serving bots and users the static HTML version generated at build time. It means that your website’s code is ready to be processed by crawlers and users just waiting on the server to be downloaded.
Similarly to server-side rendering, you must verify only one version of your website for all user agents while using this solution.
Also, in contrast to dynamic rendering, static rendering improves the page performance as it serves the prerendered version of your website faster ‒ the static files may be cached on users’ devices and used again.
Rehydration also serves only one version of a website to bots and users like the two previous solutions. However, it works in two stages.
Can dynamic rendering ever work long-term?
It may but rarely does. Especially if you have a large website and aren’t tech SEO savvy, don’t take this approach alone.
And remember that even if you aren’t worried about technical SEO, dynamic rendering still will be expensive to maintain.
Here are two examples of when our clients used dynamic rendering for:
In that case, thanks to dynamic rendering, Googlebot could find the links in the source code, but at the same time, the footer links were generated for users and added to the DOM (which represents the state of your page after rendering) once they started scrolling the page. The client decided to implement dynamic rendering to optimize its performance ‒ not all the elements need to be stored in the DOM immediately if users don’t scroll to the end of the page.
Serving client-side rendered list of internal search results to users
The client decided to serve the server-side rendered version to bots (a lighter version of the listings) and client-side rendered versions to users (when the list of products is generated ad hoc and can be personalized).
Whereas dynamic rendering should only be considered as a temporary solution, in some cases, you’ll consider it as a life belt for your website.
If you need to implement dynamic rendering, remember to follow these four steps:
- Plan your updates and deployments. Ensure your development and SEO teams have enough resources to deal with the implementation and maintenance of a prerendered website.
- Make sure the setup is efficient and free of bugs. Develop a way to verify that the setup is working correctly and no key page elements are missing from the version served to bots.
- Remember that, in most cases, dynamic rendering should only be a workaround. Look for opportunities to switch to other recommended solutions, considering your development resources and technology capabilities.