Yeah, Google *can* render JavaScript, but in the real world it’s still not something I’d trust for anything important.
A few practical thoughts from testing this on client sites and my own projects:
– **Yes, Google still has issues with JS-heavy pages**
Especially when content is loaded late, depends on user interaction, or the page is bloated. Google may crawl the HTML first, then render later. Sometimes it never fully gets to the important stuff, or it gets delayed.
– **SSR is usually safer than CSR for SEO**
If the main content is in the initial HTML, you’re in a much better spot. CSR-only pages can work, but it’s more fragile. For money pages, I’d always prefer SSR or pre-rendering. Less risk, less waiting around for Google to “maybe” render it properly.
– **How to test what Google sees**
Best checks I use:
1. **URL Inspection in Google Search Console** → “View Crawled Page” / rendered HTML
2. **Fetch as Google is gone**, so GSC is the main one now
3. **Disable JS in your browser** and see what’s left in the raw HTML
4. **View source vs inspect element** — if the content only exists in the DOM after JS, that’s a warning sign
5. Use **Rich Results Test** or **Mobile-Friendly Test** sometimes, since they show rendered output too
– **React and Next.js are not automatically risky**
The framework isn’t the problem. The setup is.
A well-configured **Next.js SSR or static generation** site can index great.
A sloppy React SPA with thin HTML, lazy-loaded content, and key text buried behind scripts? Yeah, that’s where things get messy.
My general rule: if a page matters for rankings, make sure the core text, links, titles, and internal anchors are in the HTML from the start. Don’t make Google work for it.
I’ve seen plenty of sites lose indexing coverage just because they leaned too hard on JS for basic content. Easy fix in many cases, but people ignore it until traffic drops.
If you want, I can also share a quick checklist for auditing a JS site for crawl/indexing issues.