Prerendering compared to SSR for SEOJanuary 14, 2020 at 1:47pm (Edited 1 month ago)
Our site is rendered on the server, but then certain pages are mostly a react component. We would like to move towards being completely client rendered but for certain pages we are very much concerned about SEO.
We are aware of solutions such as Next (SSR+CSR), but we aren't keen towards such solutions.
We are considering CSR + dynamic rendering. This means, building pages/routes completely in React, and then serving a pre-rendered page to crawlers. So far SSR was considered the best practice for SEO. Will the same page rendered via pre-rendering be equivalent to that same page rendered via SSR in terms of SEO?
I see no reason it won't be, as the html is the same. Perhaps excluding response time, as non cached pages might take much longer to render using pre-rendering.
January 14, 2020 at 2:13pm
Yeah our team was doing research on prerendering vs. SSR last year, and decided to go with SSR.
We have millions of public pages we want search engines to index for SEO, so we thought relying on prerendering clusters to prewarm CDN every time code changes wasn't a scalable solution.
I believe the 1.0 version of our product used https://prerender.io's library and built our own rendering clusters. And now with 2.0, we use SSR!
January 17, 2020 at 6:49am
First of all, let's be more empirical around if your CSR app has same impact as a full SSR app. Use "fetch as Google" to monitor what the crawler sees. Second, the UA for the Google bot has been updated and it now understands more modern JS. Also, it waits on AJAX calls on the client and then renders. The point with prerendering is you'd not have user context. So if your page is static or user context agnostic then you may pre-render.