It’s important to keep in mind that while how all of this works is rooted in code and is rather technical, you don’t need to know exactly how everything fits together and works. All you need to know is how it works at a high level, what the potential problems are, and how to solve these issues. The actual work that’s required and the implementation is something that the developers can handle. You just need to provide them with a guideline for how to take care of it. Let’s break it down.
Common Frameworks, Terms and how it Works
- Server-Side Rendering (SSR)
- Client-Side Rendering (CSR)
Server side rendering means that all content is rendered on the server side. The client simply hits the page and the content is all there. They don’t have to do any heavy lifting.
Client side rendering means that all of the content is rendered by the client. This means that the client will do the heavy lifting and process all of the code. The end result is of course the content.
Here’s an example of code from a site that uses Server-Side Rendering
Here’s an example of code from a site that uses Client-Side Rendering.
We’re looking at the source code for both of these sites. Notice how there is more code displayed on the Server-side rendering example? By contrast, the Client-Side rendering site looks like it has very little.
When the user hits the SSR site, the content is ready to go. When the user hits the CSR site, their browser has to load in all of the content and process it.
In general, one approach is not better than the other for users. There are reasons for both and they have their uses. The reason it impacts SEO is because of how Googlebot (and most other Search Engine bots) crawls and processes the site.
The two terms you need to be familiar with are:
- Dynamic Rendering
Prerendering is where the content on a CSR site is prerendered for the user. This means that while the site uses CSR, the server can do the heavy lifting of processing all of the code ahead of time, and give the user the already completed page. The browser doesn’t need to handle this on it’s end.
Dynamic rendering is the method used to identify which users should get which content. This means that the server identifies types of users by user-agent and then decides whether to give them content that’s already been prerendered, or let them render the content themselves.
Note: The user-agent is the string that identifies what is visiting the site, allowing servers to determine browser types, bots, etc.
In order to avoid issues that would result in lost rankings, you need to serve a prerendered version of the page to Googlebot.
Here’s the simple version of how this works.
User A comes to the website. The server knows that User A is using Chrome because of the user-agent. There are no directives setup that say Chrome user-agents should receive prerendered content. The server delivers the regular page, which uses client-side rendering. User A’s browser renders the content.
Googlebot comes to the website. The server knows that Googlebot is Googlebot because the user-agent identifies it as such. The server has a directive that dictates that Googlebot user-agents should receive the prerendered page instead of the client-side rendered version of the page. The server gives Googlebot the prerendered page and Googlebot immediately has access to all of the content on the page. The WRS does not need to be utilized in order to load all of the content.
If dynamic rendering and prerender are not used, Googlebot would get the regular client-side rendered version of the page and would need to wait for the WRS to render the content in order to understand the page.
What do I tell my developers?
Simply put, the solution is to provide a prerendered page to Googlebot and other search engine bots that is delivered through the dynamic rendering method to ensure that the page is fully understood without having to wait for the content to render.
Have them read through Google’s guide on Dynamic Rendering, and they’ll have a better understanding of what needs to be done, and you can rest easy until it’s time to test things out to make sure everything is working smoothly.
Here’s a couple extra things to keep in mind:
- It’s not considered cloaking because the same content is served to bots and users. The method of how the content is processed is all that changed.
- All users do not need prerendered content, mainly bots.
- Because prerendering on the fly can be intensive, the content can be cached. However you should be careful because if the content changes and the cached prerendered content is old, you’ll be missing out on anything new.
- You should use a verification method (https://developers.google.com/search/docs/advanced/crawling/verifying-googlebot) to make sure that only legitimate bots are receiving prerendered content.
That’s a lot to read, but don’t let it overwhelm you! Remember, this will feel daunting at first, but you can work through it. The main issue I see is this whole topic feels out of reach. It’s not and you’re more than capable of tackling it. One time we did not cover is how to test for issues once a framework is implemented. You can head over to our other articles to understand how to tackle that.