The effect on SEO related to React comes from doing client-side rendering only. So this isn’t React specific, any client-side-only view will suffer from this. But yes, SEO explicitly suffers for non-Google search engines which don’t run the JavaScript for a page. Basically, your page is effectively blank. Google does run JavaScript, but their algorithm is intentionally quite complex and takes into account many factors, some of which (like initial render performance) can be affected by using only client-side rendering.
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.
Hydrated SSR sounds great, but realize you get nearly all the downsides and only some of the upsides of doing both client and server rendering. It makes the codebase more complex and heavier. If you aren’t using a Node (JavaScript) backend, then it adds significant complexity. And while it does improve SEO for non-Google crawlers, it doesn’t necessarily improve the performance, and can hurt Time to Interactive. If your site isn’t at least minimally usable without JavaScript on the client at all, it’s not doing much for you. And to make it usable without JavaScript, you need to do more work on the server side for handling forms and such.
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.
Where hydrated React SSR comes in is when you need SEO for dynamic, interactive content in the lower parts of the table. A notable example of a large scale website where they feel the complexity trade-offs are necessary for SEO and accessibility is Airbnb (which is also largely (or fully?) designed to function without client-side JavaScript).