I run a decently established website (20k monthly users, already indexed by Googlebot, etc) that has been built on Django a year and a half ago. The vast majority of traffic on my site comes from the SEO that has been built up over the last year.

Recently, the codebase has been becoming harder to maintain, and the hosting bill has been rising on Heroku.

I'm planning to switch to React.js hosted on Firebase, however, I can't justify using a React SSR framework such as Next.js due to scalability.

My current migration plan is a banner on top of my website that leads to a subdomain of the current site (eg: beta.website.com), in order to get Googlebot to begin using their two-wave crawling process for javascript. Once I am comfortable to release the new site from beta, completely remove the old site and replace it with the new CSR site.

Now, with the knowledge that Googlebot now has a 'two-wave' JS rendering/crawling process, would my website be drastically affected by this change? Would I be better off using an SSR framework, even though my website has already gained some traction through SEO? Is a largescale upgrade like this (entire front-end re-write) enough to degrade the SEO I've built upon?


  • Wow, that's quite a huge set of questions. Maybe you can slice this post into pieces? I see three main topics: 1. how does Google treat SSR content differently from CSR content. 2. How does your subdomain strategy affect your page, as it sounds like creating a 1:1 duplicate. And 3. What are best practices for JS frameworks that rely on CSR. - to make it as short as possible for now: I would not recommend using CSR for any SEO critical content.
    – Seb
    Commented Nov 28, 2019 at 7:17
  • Thanks @Seb, given the advice so far I think CSR is the wrong way to go. I'm going to research a bit more into SSR and integrating it.
    – Recon
    Commented Nov 28, 2019 at 8:11

2 Answers 2


What is a crucial at the upgrade you are making is to make sure that your structure remains the same and when not possible use 301 redirects from your current pages to the new ones. Doing that should not affect your page's rankings. Avoid 404s at all cost.

That being said, the difference of the two-wave crawling and indexing is the speed. If your site's content must be indexed ASAP and shown as quick as possible to the SERPs (ex. like news sites), then I wouldn't choose client side framework. If this is not the case then you are good to go.

I suggest watching this for more understanding on your topic. Deliver search-friendly JavaScript-powered websites

  • Thanks! I'm thinking on it a bit more and I think I might just have to fold and use an SSR framework, I've been researching and discussing the topic for a little and it seems to make more sense.
    – Recon
    Commented Nov 28, 2019 at 8:10

You refer to the two stage crawling of Googlebot that has been problematic for getting JS powered websites indexed in a timely fashion. The good news is that Google says that the render stage usually takes place within seconds and rarely more than minutes after then initial crawl. Reference: Google Says The Median Time For GoogleBot To Render Is 5 Seconds

That might alleviate many of your concerns, however this report says that Google still has indexing delays of a month or more for some JS content: JavaScript Indexing Delays Are Still an Issue for Google. They tested against news websites that are constantly putting up fresh content powered by JavaScript and found that some sites get content indexed in 30 minutes and some have indexing problems. It probably comes down to some combination of how the sites are built and how much reputation they have to get Googlebot to crawl them frequently.

When you move to an SPA you need to make sure that it mimics traditional static sites in a few key respects:

  • Each piece of content is assigned its own URL. When a user lands an a deep URL, you need to ensure that the correct content is loaded.
  • Bots need to be able to discover normal <a href links in your site with URLs that lead bots to other content. You can't implement navigation as just clicking on <div>s for users. You still need to put in old fashioned links.
  • So that users don't need to refresh the page every time they click on a link, you can intercept link clicks for users, load the appropriate content, and change the URL without leaving the page using pushState.

I don't know React, so I don't know how easy or hard it is to make all that work under that particular framework.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.