If you've been working with Next.js lately, you've probably seen the use client directive pop up in components. It's just one line at the top of a file, but it raises an important question: does it affect SEO?
Short answer: No. Client components don't hurt SEO. Let me explain why.
What use client actually does
In Next.js 13 and above, components are server components by default. When you add use client to a component, you're telling Next.js this component needs client-side features like:
- State (useState, useEffect)
- Event handlers
- Browser-only APIs (like window or localStorage)
- Animations or heavy interactivity
Here's the key thing: Client components are still pre-rendered on the server and included in the initial HTML. Search engines see them immediately, exactly the same as server components.
The difference is that client components are also bundled and sent to the browser for hydration—making them interactive.
Why people think use client hurts SEO (and why they're wrong)
There's a common misconception that client components aren't server-rendered. This isn't true.
Both server components and client components appear in the initial HTML that gets sent to the browser. From a crawler's perspective, there's no difference. Google sees the content immediately either way.
So putting an <h1>, product description, or blog content in a client component is totally fine for SEO. The content is there in the HTML from the start.
What actually matters for SEO
While use client itself doesn't hurt SEO, there are two things that DO matter:
1. Don't hide content behind interactivity
This is the real SEO risk. If content only appears after a user clicks a button, opens a tab, or submits a form, crawlers won't see it.
Crawlers load the page and run JavaScript, but they don't interact with it. They don't click buttons or switch tabs.
Bad for SEO:
- Product details hidden behind a "Read More" button
- Pricing shown only after selecting a tab
- Content that requires form submission to view
Fine for SEO:
- Interactive components that render content immediately
- Client components with state that shows content on load
- Animations that don't hide initial content
2. Be mindful of performance
Client components increase your JavaScript bundle size. If you're overusing use client across your entire app, you can end up with a bloated bundle that slows down your site.
Performance affects SEO indirectly through Core Web Vitals and page speed rankings. But this is a holistic concern about your app's architecture, not a per-component decision.
You shouldn't avoid putting an <h1> in a client component just because it's an <h1>. If that component needs interactivity, use use client. The performance cost comes from the component being in the bundle, not from what content it contains.
The actual decision tree
When deciding between server and client components, ask yourself:
Does this component need client-side features?
- State management?
- Event handlers?
- Browser APIs?
- Interactivity after page load?
Yes? → Use use client
No? → Keep it as a server component
That's it. It's about functionality, not SEO.
How to use use client correctly
DO use use client for:
- Forms with validation
- Interactive widgets
- Modals and dialogs
- Tabs (as long as content is visible on initial render)
- Animations
- Any component that needs state or browser APIs
DON'T worry about:
- Whether the component contains an
<h1>or important text - Search engine indexing—crawlers see client components just fine
- Per-component performance decisions based on content type
DO worry about:
- Hiding content behind clicks, tabs, or interactions
- Overall bundle size if you're using
use clienteverywhere - Whether you actually need client features or just defaulted to
use clientout of habit
The bottom line
use client doesn't hurt SEO. Both client and server components appear in the initial HTML that crawlers see.
The choice between them should be based on whether you need client-side features, not whether the content is important for SEO.
The real SEO concerns are:
- Hiding content behind interactivity that requires user action
- Overall app performance from excessive JavaScript bundles
Get those right, and you can use client components wherever you need them without worrying about SEO.
Note: An earlier version of this post incorrectly stated that client components aren't server-rendered and recommended against putting SEO-important content in them. That was wrong. Thanks to the Vercel and Next.js team for the corrections.
Top comments (2)
More like
Here's a more, React point of view take, github.com/reactwg/server-componen...
So even though a module might be
use client, it'll be part of the SSR pass, and its output will be present in that first initial HTML frame sent from the server to the client. (of course as long as it is discoverable during SSR)On the browser, the client component code is downloaded to handle interactivity and what not. This is a key difference really, Server Component code is not bundled for browser usage. Client Components are packaged to be sent to the browser.
A good take would've been, don't hide content behind interactivity. AFAIK, crawlers don't interact with the page, beyond loading it and running JavaScript. They don't even follow links in an SPA fashion, rather they store them in a queue and do a direct visit layer.
This is a great addition, thanks for sharing! You're absolutely right on all counts.
The "Pages Router component" framing is spot-on, use client is really just marking components as traditional React components that need hydration, not fundamentally changing whether they're server-rendered or not.
And you've hit on what I think is the real SEO principle here: don't hide content behind interactivity.
That's the actual risk. Not whether something is a client component or server component, but whether critical content only appears after user interaction, like behind a button click, form submission, or tab switch.
Crawlers load the page and run JavaScript, but they don't click around. So if your product description only shows up when someone clicks "Read More," that's a problem. If your pricing is hidden behind a tab that defaults to closed, that's a problem.
But if you have a client component that renders content immediately on page load? Totally fine. It's in the initial HTML, crawlers see it.
The Pages Router vs App Router mental model you mentioned is really helpful. In Pages Router, everything was "client components" and SSR still worked. App Router gives us Server Components as a new primitive, but use client components still behave like the old default.
Thanks for the React WG link too, that's the kind of deep dive that helps clear up these misconceptions. Appreciate you taking the time to share this context!