In reality, most sites where SEO matters for the pages probably should not be rendered on the client, or at least not on the client only. The web is designed around servers generating html, and unless you have a strong reason not to, it’s better to fall in with that paradigm by default.
So then, there are two ways React can still be valuable, even when rendering on the server. The simpler way is to just use React as a server side templating language. I’ve been doing this on a current project, and it works quite nicely. JSX is handled on Node by compiling your server code with the Babel cli. Now, certain frequently-used features for front end that are normally handled by Webpack don’t have great support and can be much more of a pain to setup (css-modules, file/image imports), but if you just treat React like any other templating language (e.g., Pug), it’s not really any worse, and I prefer it personally.
The other option is using hydrated React SSR. Frequently this is just referred to as “React SSR” or even just “SSR”, but I try to explicitly saying “hydrated” here because “SSR” simply stands for Server Side Rendering, which nominally describes basically anything that isn’t client-side rendered.
Hydrated SSR means you share React components on the server and client, render on the server for the first request, the client code runs and “hydrates” it (the client renders a second time, ensuring it matches what the server rendered and attaching event listeners), and then client routing and rendering take over from there.
So, the progressions of what usually makes sense to use, starting with lower complexity web sites, and progressing to high-interactivity web apps:
|web site/app type||examples||likely best way to implement|
|Simple static websites||“postcard” sites, marketting landing pages||Just generate static html. Static site generators are great tools, and there are quite a few to fit tastes.|
|Simple dynamic content websites||blogs, forums, some ecommerce||Render html on the server using a templating language, do minor UI enhancements with JS on the client.|
|Dynamic content with complex interactions||Social media, some ecommerce||Render html on the server where possible, replace functionality on the client with JS (React can be a useful tool).|
|Highly interactive content||Maps, chatrooms, games, some admin interfaces, dashboards||Render base html on the server, maybe static if no extra data is needed, render significant parts of the UI on the client (React is great for this).|
If you look at the progression here, you’ll notice that the likely importance of SEO generally goes from high to low as you move down the table. This works out, since the html generated by the server for the earlier entries will be more SEO friendly.