Yeah, Google can still be a bit flaky with JS-heavy pages. In theory it renders a lot of JS, but in the real world I’ve seen plenty of pages where the important stuff either gets delayed, partially rendered, or just never makes it into the index the way you expect.
My take from site work:
– **SSR is usually safer than CSR for SEO**
– If the content matters for rankings, I’d rather have it in the initial HTML.
– CSR can work, but it adds another layer where Google has to fetch, render, and interpret everything correctly.
– For money pages, I don’t like betting on that.
– **Google still has rendering limits**
– It’s not that Google “can’t” render JS, it’s more that it **often doesn’t render it immediately or consistently**.
– Crawl budget, script complexity, lazy loading, blocked resources, and rendering delays can all mess things up.
– I’ve seen pages indexed with thin or incomplete content because the core text was only injected client-side.
– **How to test it**
– Use **Google Search Console → URL Inspection → Test Live URL**
– Check the **rendered HTML** and screenshot, not just the raw source.
– Also compare:
– `view-source:` in browser
– rendered DOM in DevTools
– what GSC says Google sees
– If the important text is missing in the rendered HTML in GSC, that’s a red flag.
– **React / Next.js**
– React alone isn’t the problem. The issue is **how it’s implemented**.
– **Next.js with SSR or static generation** is way better than pure CSR for SEO.
– But even with Next.js, I’d still watch for:
– content loaded after interaction
– hidden tabs/accordions
– lazy-loaded internal links
– JS that blocks critical content from appearing in the initial render
Real-world advice: if a page needs to rank, make sure the main content, title, H1, internal links, and key copy are in the initial HTML or server-rendered output. Don’t make Google work for the basics.
If you want, I can also share a simple checklist for auditing whether a JS page is safe to index.