Is it true that JavaScript can impact your SEO, and how should you approach it?

Why does Google emphasize the concept of control?

When you build a page with client-side JavaScript (CSR), you entrust the browser — and thus Googlebot — with executing the code, loading third-party resources, and generating the final DOM. The issue? You don't control the execution environment.

A third-party script can silently fail, a CDN might be temporarily unavailable, an API could return a 500 error. The result: your content doesn’t display, Googlebot sees nothing, and you may never know — unless you actively monitor crawl logs and multiply rendering tests.

What changes when moving to server-side rendering?

With server-side execution (SSR, SSG, or hybrid), the final HTML is generated before it reaches the browser. You validate dependencies, control errors, and send a usable document directly to Googlebot.

This doesn’t mean SSR is perfect. It introduces server latency, CPU load, and deployment complexity. But you gain predictability: what leaves the server is what will be crawled. No surprises from a JS timeout or resource blocking.

Does Google crawl and index all JavaScript?

Yes and no. Googlebot executes JavaScript, but with time and budget constraints. If your page takes several seconds to display the main content, you’re entering a gray area. The bot might give up before rendering is complete, especially if your crawl budget is tight.

Splitt isn’t saying “avoid JS,” he’s saying “understand the risks.” A well-designed SPA, with fast rendering and an HTML fallback, can be perfectly indexed. A poorly designed SPA, with heavy dependencies and delayed content, will pose problems.

• CSR works, but with a higher margin of error — every external dependency is a potential failure point.
• SSR offers more guarantees: what you control server-side is indexable without client-side execution conditions.
• The choice shouldn’t be dogmatic — assess your stack, your third-party dependencies, and your ability to monitor the actual rendering seen by Googlebot.
• Googlebot executes JS, but not indefinitely — if critical content appears only after 5 seconds, you’re playing with fire.

Is this statement consistent with field practices?

Yes, and it’s even one of Google’s few clear positions on the subject. For years, SEOs have noted that pure CSR sites encounter random indexing issues — some pages get indexed, others do not, without an obvious pattern.

What Splitt confirms here is that these variations are not bugs — they are predictable outcomes of the chosen architecture. When you delegate rendering to the client, you add variables: network performance, API availability, Googlebot timeouts, resource blocking by robots.txt or CSP.

What nuances should be added to this statement?

First nuance: not all client-side JS is equal. A modern framework with partial hydration (Next.js, Nuxt, SvelteKit) offers an interesting compromise — initial SSR, then CSR for interactions. This limits risks while maintaining responsiveness.

Second nuance: the “control” referenced by Splitt primarily concerns third-party dependencies. If your JS code is 100% internal, well-tested, and you’re not making critical external API calls for content, the risk is minimal. The real danger lies when you depend on a third-party widget to display your prices, reviews, or SEO text.

In what cases does this rule not fully apply?

If you’re working on a web application site (SaaS, private platform) with few organic SEO stakes, the CSR/SSR debate becomes secondary. The control issue remains valid for UX, but not for indexing.

Another case: if you’ve set up rigorous monitoring — rendering logs, automated tests with Puppeteer, alerts on JS errors — and you proactively fix failures, you significantly reduce risk. But let's be honest, how many teams have this level of rigor?

What should I do if my site relies on client-side JavaScript?

First action: audit your third-party dependencies. List all external scripts that inject user-visible content — widgets, APIs, third-party CDNs. Each is a potential failure point. Test their availability, response time, and impact on rendering.

Second action: use the Mobile Optimization Test tool or the “URL Inspection” report in Search Console to check what Googlebot actually sees. Compare it with what you see in your browser. If critical content is missing from the crawled version, you have a problem.

What mistakes should you absolutely avoid with JavaScript and SEO?

Never block your critical JS or CSS resources in robots.txt. Googlebot needs to execute JS to see the content — if you block the necessary files, it will only see an empty shell.

Don’t wait for a user event (click, scroll) to display the main SEO content. Googlebot does not always simulate these interactions. If your text only appears after infinite scrolling or a click on a “See more” button, there’s a risk it will never be crawled.

How to gradually migrate to a hybrid or SSR solution?

If redesigning your entire site in SSR is too heavy, start by identifying strategic pages — SEO landing pages, product sheets, categories. Migrate them first to server rendering, even partially.

Modern frameworks allow for hybrid rendering: SSR for initial content, CSR for interactions. It’s a pragmatic compromise that limits risks without sacrificing user experience. Test, measure the impact on organic traffic, then expand.

• List all your third-party dependencies and test their reliability over 7 days
• Check Googlebot's rendering via Search Console for 10 representative pages
• Do not block any critical JS/CSS resources in robots.txt
• Prefer content that is visible without user interaction for SEO pages
• Consider a gradual migration to SSR/SSG for pages with high organic stakes
• Set up monitoring of actual rendering (logs, automated tests)