Introduction
Your website looks great. It loads, it animates, the buttons work, and your developer tells you it's built on a “modern JavaScript framework.” So why does a competitor with an uglier site outrank you — and why does ChatGPT recommend them instead of you?
The answer often comes down to something most business owners have never heard of: hydration, and the rendering strategy behind it. It's the difference between a website that hands Google and AI crawlers a finished page and one that hands them an empty box with some assembly instructions.
This is our home turf. We build Next.js websites for a living, and rendering strategy is one of the first things we evaluate on every project. In this guide, we'll explain what hydration actually is in plain English, how Google processes JavaScript websites, why most AI crawlers never run your JavaScript at all, and how to run a five-step diagnostic on your own site — no engineering degree required.
Key Takeaways
- Hydration is the step where JavaScript “wakes up” server-built HTML and makes it interactive — it adds behavior, not content.
- Google processes JavaScript pages in phases, and content that arrives in the initial HTML is indexed more reliably than content that requires a rendering step.
- Most AI crawlers — including the ones behind ChatGPT, Claude, and Perplexity — do not execute JavaScript at all, so client-side-rendered content can be invisible to answer engines.
- Hydration problems show up in Core Web Vitals, especially Interaction to Next Paint (INP), where “good” means responding within 200 milliseconds.
- Server-side rendering (SSR) and static generation (SSG) put your content in the initial HTML; client-side rendering (CSR) leaves crawlers a nearly empty shell.
- You can check your own site in about 15 minutes with a view-source test, a disabled-JavaScript test, and Google Search Console's URL Inspection tool.
What Is Hydration, in Plain English?
When you visit a modern website, two things have to happen: the page has to appear, and the page has to work. Those are separate steps, and hydration is the bridge between them.
Here's the sequence, as explained in Search Engine Land's hydration guide published this week: the server builds the complete HTML and sends it to your browser, where the content is visible but not yet interactive. Then the JavaScript framework finishes loading and attaches event listeners — the wiring that makes buttons click, forms submit, and menus open. As author Matt Hollingshead puts it, hydration is JavaScript “taking over” the static HTML built on the server, turning it into a page you can actually interact with.
The critical detail for SEO: hydration adds interactivity, not content. The text, images, and layout already arrived from the server. If your website is built with server-side rendering or static generation, everything a search engine needs to understand your page is present before any JavaScript runs.
Contrast that with a client-side-rendered site. There, the server sends a nearly empty HTML shell plus a large bundle of JavaScript, and the browser has to build the entire page itself. Nothing meaningful exists until that JavaScript downloads, parses, and executes. A human visitor on a fast connection may never notice the difference. A crawler — or a visitor on a weak mobile signal — absolutely will.
Think of it like a restaurant. Server-rendered sites deliver a cooked meal; hydration is just handing you silverware. Client-rendered sites deliver a box of groceries and a recipe, and hope whoever's at the door is willing to cook.
How Does Google Actually Handle a JavaScript Website?
Google can run JavaScript — but it does so in a separate, deferred step, and that separation is where rankings quietly leak away.
According to Google's official JavaScript SEO documentation, Googlebot processes JavaScript pages in three phases: crawling, rendering, and indexing. First it fetches your URL and parses the raw HTML for content and links. Then pages get sent to a rendering queue, where a headless version of Chrome eventually executes the JavaScript. Google notes that pages “may stay on this queue for a few seconds, but it can take longer than that.”
That gap creates two practical problems for JavaScript-dependent sites:
- Delayed or unreliable indexing. If your content only exists after JavaScript runs, Google can't index it until the rendering step completes. Content that ships in the initial HTML gets picked up in the first pass — which is why the Search Engine Land piece calls indexing from initial HTML “more reliable than a client-rendered blank shell.”
- Indexing the wrong version. When the server's HTML and the JavaScript-rendered version disagree — a hydration mismatch — Google may read the raw server HTML and index a version of the page that gets discarded the moment JavaScript re-renders it. You end up with content in Google's index that your visitors never actually see.
Google itself is direct about the solution. From the same documentation: “Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.”
That last clause — not all bots can run JavaScript — matters more in 2026 than it ever has. Site structure and crawlability have become a strategic concern, not just a technical one; as a recent Search Engine Land piece on site architecture frames it, architecture now “determines whether your content can be found, understood, and surfaced by search engines and AI systems.” Which brings us to the bots that don't render anything at all.
Why Do AI Crawlers Make Rendering Strategy Urgent?
Google will eventually render your JavaScript. The crawlers feeding ChatGPT, Claude, and Perplexity won't — ever.
Vercel's analysis of AI crawler behavior, based on traffic across its hosting network, found that none of the major AI crawlers execute JavaScript. GPTBot (OpenAI), ClaudeBot (Anthropic), and PerplexityBot all fetch JavaScript files — ChatGPT's crawler spent 11.5% of its requests on them, Claude's 23.84% — but never run them. The only exceptions in the study were AppleBot, which uses a browser-based crawler, and Gemini, which rides on Googlebot's rendering infrastructure.
The scale involved is not trivial. In Vercel's data, GPTBot made 569 million requests in a month and Claude's crawler made 370 million — those two alone added up to roughly 20% of the 4.5 billion requests Googlebot made over the same period. That was measured in late 2024; we've written about how AI bot traffic has continued to surge since then.
Play that forward for a client-side-rendered website:
- Google indexes you, eventually, via its rendering queue.
- ChatGPT's crawler fetches your page, receives a nearly empty HTML shell, and moves on.
- When a potential customer asks an AI assistant who does what you do, you're simply not in the source material.
This is the part that stings for businesses that invested in a slick JavaScript site: you can rank on Google and still be invisible to answer engines. The crawler saw a loading spinner where your services, pricing, and expertise were supposed to be. Vercel's recommendation to site owners is blunt: prioritize server-side rendering for critical content.
We covered the audit-and-fix side of this in depth in our guide to no-JavaScript fallbacks for AI crawlers, and how to manage which bots you let in via robots.txt in the age of AI crawlers. This post is about the layer beneath both: choosing a rendering strategy so there's nothing to patch in the first place.
How Does Hydration Affect Core Web Vitals?
Even when your content is server-rendered and indexable, how much hydration your site does affects how fast it feels — and Core Web Vitals measure exactly that.
The metric to watch is Interaction to Next Paint (INP), which web.dev defines as a measure of how quickly a page responds to clicks, taps, and keystrokes across the whole visit. The thresholds: good is 200 milliseconds or less, needs improvement runs up to 500 milliseconds, and anything above 500 milliseconds is poor — measured at the 75th percentile of real visits. The primary cause of poor INP is long JavaScript tasks blocking the browser's main thread. Hydration is precisely that kind of task.
Here's the trap the Chrome team has warned about for years in its rendering on the web guidance: a server-rendered page with heavy full rehydration “can appear to be loaded and interactive, but can't actually respond to input until the client-side scripts for components are executed and event handlers have been attached. On mobile, this can take minutes, confusing and frustrating the user.” The page looks done — the paint metrics like Largest Contentful Paint (LCP) score well — but taps do nothing until hydration finishes.
Hydration mismatches make things worse. Per the Search Engine Land analysis, a mismatch forces the framework to re-render on the client, which hurts on three fronts: the page feels sluggish (INP), content shifts around (Cumulative Layout Shift), and in the worst cases event listeners fail to attach entirely — buttons and forms silently stop working. Common causes include values that differ between server and browser (like timestamps), content that depends on browser-only storage, third-party scripts modifying the page before hydration, and invalid HTML that the browser rewrites.
The good news: framework design has been steadily shrinking the amount of hydration work a page has to do. Here's how the main approaches compare, adapted from Search Engine Land's breakdown:
| Hydration approach | What hydrates | JavaScript shipped | Example |
|---|---|---|---|
| Full hydration | The entire page | Most | Next.js (Pages Router) |
| Partial hydration (islands) | Only interactive components | Less | Astro |
| Progressive hydration | The page in pieces, over time | Same total, spread out | Angular |
| React Server Components | Nothing, for server-only parts | Less | Next.js (App Router) |
| Resumability | Nothing — hydration is skipped | Least | Qwik |
We compared several of these frameworks head-to-head in our Next.js, Svelte, and Astro comparison, and the broader speed fundamentals are covered in our web performance optimization guide.
SSG vs SSR vs CSR: Which Rendering Strategy Should Your Website Use?
Hydration is one step in a bigger decision: where and when does your HTML get built? There are three base strategies, and for most business websites the choice is clearer than developers sometimes make it sound.
| Strategy | Where HTML is built | What crawlers see immediately | Best for |
|---|---|---|---|
| Static generation (SSG) | At build time, before anyone visits | Complete content | Marketing sites, blogs, service pages — content that's the same for every visitor |
| Server-side rendering (SSR) | On the server, per request | Complete content | Pages that change per visitor or update constantly (search results, dashboards, inventory) |
| Client-side rendering (CSR) | In the visitor's browser, via JavaScript | A nearly empty shell | Logged-in app screens where SEO doesn't apply |
The Chrome team's guidance backs this hierarchy. Static rendering delivers a “consistently fast” time to first byte because the HTML already exists, and both SSG and SSR keep main-thread JavaScript work low, which protects INP. Client-side rendering, by contrast, tends to accumulate JavaScript as the site grows — and the same guidance concludes that full server-rendering-plus-rehydration of everything is “rarely the best option” compared with lighter approaches.
Our recommendation, and how we actually build: every page a customer or crawler should find — home, services, location pages, blog — is statically generated or server-rendered, and interactivity is layered on in small, isolated pieces. In modern Next.js, Server Components make this the default: layouts and pages render on the server and ship zero JavaScript for their static parts, and only genuinely interactive elements (a quote form, a mobile menu, a calculator) become Client Components that hydrate. The Next.js documentation is explicit that reducing client JavaScript this way exists to improve First Contentful Paint and cut the bundle the browser must process.
If you're commissioning a new website, you don't need to memorize any of this. You need to ask your developer three questions:
- “Is our content in the initial HTML response?” The answer should be an unqualified yes for every public page.
- “What's the rendering strategy per page type?” A good answer names SSG or SSR for public pages and reserves CSR for logged-in areas.
- “How much JavaScript ships to the browser, and what hydrates?” A good answer describes small interactive islands, not “the whole app hydrates.”
A developer who can't answer those crisply is telling you something. We keep a longer version of this checklist in our Next.js best practices guide.
How Can You Tell If Your Website Has a Rendering Problem? (5-Step Diagnostic)
You can run this entire diagnostic yourself in about 15 minutes, without touching code.
Step 1: The view-source test. Open your most important service page, right-click, and choose “View Page Source” (not “Inspect” — that shows the rendered result, which hides the problem). Now search the source (Ctrl+F / Cmd+F) for a distinctive sentence from your page — part of your services description, a testimonial, your phone number. If your actual content is there in the raw HTML, you're server-rendering. If you find mostly <script> tags and an empty <div id="root">, you're client-side rendered — and every non-rendering crawler sees exactly that emptiness.
Step 2: The disabled-JavaScript test. In Chrome, open DevTools, press Ctrl+Shift+P (Cmd+Shift+P on Mac), type “Disable JavaScript,” and reload the page. This is the same test the Chrome team suggests for identifying rendering strategy: on statically rendered pages, the content — and most of the experience — survives without JavaScript. If you get a blank page or an endless spinner, that's what GPTBot and ClaudeBot see.
Step 3: Google Search Console URL Inspection. The URL Inspection tool shows you Google's indexed version of a page, a screenshot of the rendered page as Google's crawler sees it, and — under “View crawled page → More info” — the JavaScript output and page resources it loaded. Run a live test on a key page and compare the screenshot and crawled HTML against what visitors see. Missing sections, missing text, or blocked resources here are direct evidence of a rendering gap.
Step 4: PageSpeed Insights. Run your page through PageSpeed Insights and look specifically at INP and Total Blocking Time rather than the headline score. A page that paints fast but posts poor INP is the classic signature of heavy hydration: the content arrived, then the JavaScript made the browser too busy to respond. Remember the threshold: at or under 200 milliseconds is good.
Step 5: Check who's actually visiting. If you have access to server logs or hosting analytics, look for AI crawler user agents — GPTBot, ClaudeBot, PerplexityBot — hitting your pages. If they're crawling you (and at the volumes Vercel measured, they probably are), every one of those requests to a client-rendered page is a wasted opportunity: a crawler that came to read your content and got a shell.
Console warnings during load, content that flickers or shifts as the page settles, or buttons that don't respond for the first seconds are the visible symptoms of the same underlying issues — worth noting for your developer even if you can't diagnose them yourself.
How We Build Next.js Sites That Don't Have This Problem
This entire class of problem is avoidable at the architecture stage, which is why we treat rendering strategy as a first decision, not a retrofit.
Every site we ship — including the ones we build for Northeast Indiana businesses from our office in Auburn — follows the same rules: public pages are statically generated or server-rendered so the full content lives in the initial HTML; interactive elements are isolated Client Components so hydration work stays small and INP stays fast; and we verify the result with the same view-source, disabled-JavaScript, and URL Inspection tests described above before launch. The site you're reading this on is built exactly this way.
If your current website fails the diagnostic — or you're planning a rebuild and want it done right the first time — our web development team can audit your rendering setup and show you specifically what Google and AI crawlers see when they visit. It's usually a short conversation that prevents a long, expensive problem — reach out and we'll walk through your results with you.
Not sure what Google and AI crawlers actually see on your website?
Button Block builds Next.js websites where every public page ships its full content in the initial HTML — and we can audit your current site's rendering strategy, show you exactly what crawlers receive, and scope the smallest fix that closes the gap.
Frequently Asked Questions
- What is hydration on a website?
- Hydration is the process where JavaScript takes static HTML that was built on a server and makes it interactive in your browser — attaching the event listeners that make buttons, forms, and menus work. It adds behavior, not content: the text and layout already arrived from the server. The term matters for SEO because sites that rely on hydration (rather than building the whole page in the browser) deliver their content in the initial HTML, where crawlers can read it reliably.
- Does Google index JavaScript websites?
- Yes, but with caveats. Google processes JavaScript pages in phases: it crawls the raw HTML first, then queues the page for rendering in a headless browser, which can take anywhere from seconds to considerably longer. Content that only appears after JavaScript runs is indexed later and less reliably than content in the initial HTML, and hydration mismatches can cause Google to index a version of the page visitors never see. Google's own documentation still recommends server-side rendering or pre-rendering.
- Do ChatGPT and other AI assistants read JavaScript websites?
- Mostly no. Vercel's analysis of AI crawler traffic found that GPTBot (OpenAI), ClaudeBot (Anthropic), and PerplexityBot fetch JavaScript files but never execute them, so content that requires JavaScript to appear is invisible to them. The exceptions were AppleBot and Google's Gemini, which use browser-based rendering. If your site is client-side rendered, answer engines are working from an empty shell when they decide whether to cite or recommend you.
- Is Next.js good for SEO?
- Next.js is one of the strongest frameworks for SEO when configured correctly, because it supports static generation and server-side rendering out of the box — meaning full content in the initial HTML for every crawler. With the App Router, Server Components render on the server and ship no JavaScript for static parts of the page, which cuts hydration work and helps Core Web Vitals. The caveat: Next.js can also be used to build client-heavy pages, so the framework choice alone does not guarantee good results — the rendering strategy does.
- How do I check what crawlers see on my site?
- Three quick tests: view the page source (not the inspector) and search for your actual content in the raw HTML; disable JavaScript in your browser and reload the page to see what survives; and run the page through Google Search Console's URL Inspection tool, which shows a screenshot and the crawled HTML exactly as Google's crawler processed it. If your content is missing from any of these views, crawlers are missing it too.
- Who builds server-rendered websites for businesses in Fort Wayne and Northeast Indiana?
- Button Block builds Next.js websites from Auburn, Indiana for clients across Fort Wayne, Allen County, DeKalb County, and the broader Midwest — and every public page we ship is statically generated or server-rendered, then verified with the view-source, disabled-JavaScript, and URL Inspection tests described in this guide. If you're vetting any developer, local or not, ask the three rendering-strategy questions from the SSG vs SSR vs CSR section above; the answers will tell you quickly whether hydration and crawlability are part of how they build.
- Should I rebuild my website if it's client-side rendered?
- Not necessarily immediately — it depends on how much of your business depends on organic and AI-driven discovery. If public pages like services, locations, and your blog are client-rendered, you're conceding visibility in both traditional search and answer engines, and the gap widens as AI referrals grow. Some frameworks allow incremental fixes (pre-rendering key pages, migrating routes to server rendering) without a full rebuild. We recommend running the five-step diagnostic first, then scoping the smallest change that gets your content into the initial HTML.
Sources & Further Reading
- Search Engine Land: Hydration and SEO: How it works and why it matters — July 7, 2026
- Google Search Central: Understand JavaScript SEO Basics — 2026
- web.dev (Chrome team): Rendering on the Web — January 5, 2026
- Vercel: The Rise of the AI Crawler — December 17, 2024
- web.dev (Chrome team): Interaction to Next Paint (INP) — 2026
- Google Search Console Help: URL Inspection Tool — 2026
- Next.js Documentation: Server and Client Components — June 23, 2026
- Search Engine Land: SMX Now: Build better site architecture for SEO, AI, and users — July 6, 2026