"Google can't render JavaScript" hasn't been true for years, but JS-rendering risk in SEO hasn't disappeared — it's just shifted from a blanket capability question to a set of specific implementation details that still commonly go wrong.
The outdated claim, and what actually replaced it as a concern
Google's rendering engine has reliably executed JavaScript for a long time now, using an evergreen, modern rendering engine rather than the older, more limited version that originally justified "Google can't handle JS" advice. That specific claim is no longer the risk. What remains genuinely risky is a set of more specific implementation patterns that interfere with rendering succeeding correctly, or succeeding in time.
Rendering is a second wave, and that costs time
Google's crawling and indexing process for JavaScript-heavy pages generally happens in two passes: an initial crawl of the raw HTML, followed by a separate rendering pass that executes JavaScript to see the fully-rendered page. This second pass doesn't happen instantly alongside the first — it's queued separately, and can introduce a delay of anywhere from a few days to considerably longer before JS-dependent content is actually seen and indexed, compared to content already present in the initial HTML response.
For most evergreen content, this delay is a minor cost. For time-sensitive content — news, limited-time offers, anything where being indexed quickly genuinely matters — relying on client-side rendering for the core content introduces a real, measurable disadvantage relative to content available immediately in the initial HTML.
Interaction-gated content generally isn't seen at all
Crawlers execute JavaScript and can see content that loads automatically as part of page rendering, but they don't simulate arbitrary user interactions — a click to expand a section, a hover to reveal a tooltip, a manual trigger to load more results via infinite scroll. Content that only becomes present in the DOM after one of these interactions typically isn't crawled or indexed at all, because the crawler never performs the interaction that would load it.
The practical implication: content you want indexed should be present in the page's rendered DOM without requiring a user action first. "Load more" pagination that requires a click, for instance, should also be reachable through a crawlable link (a real URL for page 2, not just a JavaScript-triggered content swap) if that content matters for indexing.
Blocked resources break rendering silently
A robots.txt rule blocking JavaScript or CSS files — sometimes leftover from an old, overly broad disallow rule, or added for an unrelated reason like blocking a third-party script — prevents the rendering engine from executing the page the way a real browser would, sometimes resulting in an incomplete or visibly broken rendered version getting indexed. This is a surprisingly common issue on sites that have accumulated robots.txt rules over time without auditing whether they still make sense; confirm that no CSS or JS resource paths needed for correct rendering are blocked.
Client-rendered metadata is a frequent, subtle failure
Title tags, meta descriptions, and canonical tags that get set or modified via client-side JavaScript rather than present in the initial server response are a common source of inconsistent behavior — sometimes captured correctly by the rendering pass, sometimes not, depending on timing and how the rendering pass handles the specific implementation. Metadata this important is safer set server-side, in the initial HTML response, rather than relying on client-side JavaScript to set it reliably every time.
Server-side rendering remains the safer default for content-critical pages
For pages where being indexed quickly and reliably genuinely matters, server-side rendering or static generation — where the content-complete HTML is present in the initial response, with JavaScript enhancing rather than being required for the core content — remains the most reliable way to sidestep JS-rendering risk entirely rather than depending on client-side rendering to execute correctly every time, for every crawler, on every visit. This doesn't mean avoiding client-side JavaScript altogether — it means not making it a single point of failure for content that needs to be reliably crawled and indexed.
