By Rahul Saini, Author at Search Counsel Co. Last updated [JULY] 2026.

1) What actually changed

Between December 15 and 18, 2025, Google made three edits to its JavaScript SEO documentation. They landed within a few days of each other and they share a theme: how Google handles your indexing signals when a page depends on JavaScript. Crucially, none of these describe new behavior. Google’s rendering systems already worked this way. What changed is that the behavior is now written down, which matters because plenty of sites had been building on assumptions that turned out to be wrong.

The updates were part of Google’s steady stream of documentation work through 2025 (it averaged around two significant updates a month), and they followed Google moving its crawling documentation to a new home in November 2025 that now covers many Google products, not just Search. The rest of this guide takes each change in turn, with a fix and a way to check your own site.

2) Change 1: a noindex tag in the raw HTML can stop rendering

Google’s clarification here is blunt: if there’s a chance you want a page indexed, don’t put a noindex tag in the original page code. When Google sees a noindex in the raw HTML, it may skip rendering and JavaScript execution altogether. That means any JavaScript meant to remove or change that noindex may never run.

The fix is to stop using noindex conditionally in the raw HTML. Control what gets indexed with proper server responses instead: return a 200 for live pages and a real 404 or 410 for pages that are gone. Reserve noindex for pages you never want indexed at all, like checkout or account areas, and set it reliably. This overlaps with the rogue-noindex problems covered in our guide to fixing indexing problems.

3) Change 2: keep canonicals consistent before and after rendering

Google added a section on canonicalization for JavaScript, and the reasoning is the important part: canonicalization happens both before and after rendering. Google reads the canonical in your raw HTML, then reads it again after running your JavaScript. If those two disagree, you’ve handed Google conflicting signals, and it may index a URL you didn’t intend or split your ranking signals across versions.

Google’s guidance gives you two clean options. Set the canonical to the same URL in both the raw HTML and after rendering. Or, if you must use JavaScript to set it, leave the canonical out of the raw HTML entirely and have JavaScript set exactly one value. What you must not do is put one canonical in the raw HTML and then use JavaScript to change it to a different URL.

The most reliable path is to put the correct canonical in the initial server response, which server-side rendering frameworks like Next.js make easy. This is also why independent web-data studies have flagged a small but real share of pages whose canonical changes between the raw and rendered HTML: exactly the mismatch this clarification is warning about. For the full picture, see our guide to canonical tags and duplicate content.

4) Change 3: non-200 pages may skip rendering

The third clarification is the shortest and the most technical. Pages that return a 200 HTTP status code are sent to the rendering queue. Pages with a non-200 status, a 404, a server error, or a redirect, might not be. So Google may never run the JavaScript on an error or redirect page. It sees the raw HTML and the status code, and that’s it.

This bites hardest on single-page applications that handle routing in the browser. If a non-existent URL returns a 200 status with a JavaScript-rendered “not found” message (a soft 404), or if you rely on client-side JavaScript to fire a redirect or set a canonical on an error page, that logic may never execute. Google is left looking at your empty app shell and a misleading 200 status.

The fix is architectural: handle error states and redirects on the server or CDN, so the correct status code reaches Google before the response ever gets to the browser. A missing page should return a real 404 from the server, not a 200 that JavaScript later dresses up as an error. Soft 404s and redirect handling are covered further in our guide to finding and fixing crawl errors.

5) The one principle behind all three

Read together, these three clarifications are really one idea repeated three ways: get your indexing signals right in the raw HTML and at the server, because Google may act on the raw response before it renders your JavaScript, or instead of it. Your status code, your canonical, and your noindex all need to be correct in what the server sends, not patched in afterward by a script Google might never run.

6) How to check your site

You can audit for all three issues in an afternoon. Work through them in order:

• 1. Check for noindex in your raw HTML. View the page source (not the browser inspector) or fetch the URL with curl, and search for “noindex” in both the HTML and the HTTP response headers. Pay special attention to any page type that toggles noindex with JavaScript. A crawler like Screaming Frog can flag every noindex across the site in its Directives view.
• 2. Compare your canonical before and after rendering. Look at the canonical in the raw source, then check the rendered canonical using URL Inspection’s Test Live URL in Search Console. If they differ, fix it. Screaming Frog in JavaScript-rendering mode will flag pages where the rendered canonical doesn’t match the raw one.
• 3. Test your error pages’ status codes. Request a URL that shouldn’t exist and confirm the server returns a real 404, not a 200. Use curl, your browser’s network tab, or an HTTP header checker. For single-page apps, verify that client-side routing produces genuine 404 responses for missing pages.
• 4. Watch Search Console. Check the Pages report for a rise in soft 404s, “Excluded by noindex tag,” or duplicate and canonical statuses, which are the symptoms these issues produce.

7) What this means for AI crawlers

Everything above is about Google, but it points at a bigger rule. Most AI crawlers, the ones behind ChatGPT, Claude, and Perplexity, don’t render JavaScript at all. So a canonical set by JavaScript, a noindex removed by JavaScript, or a redirect fired by JavaScript is invisible to them by default. Google might catch these on a later render. AI engines won’t.

That makes the raw-HTML principle even more important than this update alone suggests. If your indexing signals and your content live only in your JavaScript, you’re not just risking a rendering delay with Google, you’re excluding yourself from AI answers entirely. Serving correct signals and real content in the initial response is what keeps you eligible on both surfaces. Our AI search optimization guide and the technical SEO pillar go deeper on the AI side.

8) Sources used for this guide

This guide is based on Google’s own documentation and changelog, plus the technical trade coverage that reported the update.

FAQ: Google’s December 2025 rendering update

Conclusion: fix the signals, not the symptoms

Google’s December 2025 rendering update didn’t change how your site ranks. It clarified three ways JavaScript can quietly break your indexing signals: a noindex that stops rendering, a canonical that changes after rendering, and an error page that never renders at all. The through-line is simple. Your status codes, canonicals, and noindex tags need to be right in the raw HTML the server sends, because Google, and every AI crawler, may act on that response before your JavaScript ever runs.

That completes the rendering side of technical SEO. For the foundation this all rests on, read our guide to JavaScript SEO and SSR vs CSR, and see the technical SEO pillar for how rendering fits with crawling, indexing, and site speed.