JavaScript SEO: Get Google to See Your Pages

JavaScript SEO means rendering content so crawlers see it without running your scripts: pick server rendering, check the raw HTML, and avoid client-only routes.

بقلم Jeremy Zavaبمساعدة الذكاء الاصطناعي، راجعه Ibrahem Helalنُشر في 29 سبتمبر 2026قراءة 6 دقائق

JavaScript SEO means making sure a page's content, links and metadata exist in the HTML a crawler can read, not only in what a browser builds after running your scripts. Get the rendering method right and JavaScript stops being a risk. Get it wrong and pages exist for visitors but not for search or answer engines.

That is one piece of a wider technical SEO checklist: the rest covers speed, indexing and markup once rendering itself is not the blocker.

في هذه الصفحة

What actually goes wrong with JavaScript and SEO?

Content that only exists after a script runs is content a crawler might never see. Googlebot can render JavaScript, but it does so in a second pass, separate from the first crawl that reads the raw response [1]. Other crawlers, including the ones behind most AI answers, fetch the page once and do not run scripts at all.

That gap causes three recurring problems: pages indexed with an empty title and description because the metadata was set client-side, internal links that never get followed because they are onClick handlers instead of anchor tags, and content that shows up days after publishing because it waited for the second render pass.

None of this means avoid JavaScript. It means decide, per route, where the render happens.

The cost is not evenly spread either. A marketing page that renders late might lose a few days of visibility while it waits in the second-pass queue. A large catalog or listings site multiplies that delay across thousands of URLs, and a crawler that gives up part way through a slow render simply never sees the rest of the page. The bigger the site, the more a rendering decision made once, early, is worth getting right the first time rather than fixing route by route later.

Which rendering method should I use?

Whichever one puts your content in the first HTML response. In the App Router, that is server components by default, static generation for pages that rarely change, and client components only for the interactive parts that do not need to be indexed on their own.

Rendering methods and what a crawler gets on the first request
Method	What ships in the first response	Best for
Server-side rendering	Full HTML, built per request	Pages with data that changes often, like search results
Static generation	Full HTML, built at deploy or on demand	Marketing pages, blog posts, docs
Incremental static regeneration	Full HTML, rebuilt on a schedule or a trigger	Catalogs and listings that update but not per request
Client-side rendering	An empty shell; content arrives after a script runs	Logged-in dashboards nobody needs indexed

The rule of thumb: if a page should ever appear in search or be cited by an assistant, it should not depend on client-side rendering for its main content. Reserve that mode for the parts of the app behind a login.

How do I check what a crawler actually sees?

Look at the response, not the rendered page. Open DevTools, go to the Network tab, and inspect the raw HTML of the first document request. If the heading, main copy and primary links are already there, you are in good shape. If the body is mostly empty divs, the content is arriving late.

Fetch without a browser
Run curl or a plain HTTP client against the URL and read the response. What is missing here is missing for anything that does not render.
Use Search Console's URL Inspection
The rendered HTML tab shows what Googlebot's renderer produced, which catches problems a raw fetch alone would call a false alarm.
Disable JavaScript in the browser
Reload the page with scripts off. Any content or link that disappears is a content or link a non-rendering crawler will not have.
Check response time under load
Server-side rendering that queries a slow database on every request can time out under crawl load even though it passes when you test it once.

Do this on a template basis, not page by page. One broken layout usually explains hundreds of missing pages at once, and one fix clears all of them together.

What common mistakes hide content from crawlers?

A handful of patterns account for most of what we find in an audit.

Links rendered as <div onClick> instead of <a href> do not get followed by any crawler, rendering or not, because there is no href to discover. Any navigation element meant to be crawled needs a real anchor tag underneath, even if you style it to look like a button.

Infinite scroll with no paginated fallback traps content behind a scroll event a crawler will never fire. If a listing spans multiple pages, give it real /page/2, /page/3 URLs a crawler can request directly; our guide on pagination SEO covers how to structure that.

Metadata set only in a useEffect after the component mounts is metadata a non-rendering crawler never sees, and one Googlebot only picks up on its second pass. Title and description belong in generateMetadata, run on the server, not in client-side state.

How does JavaScript SEO interact with page speed?

The render method you pick for indexing is the same one that decides your Core Web Vitals. Server-rendered HTML arrives with content already painted, which helps Largest Contentful Paint. A client-rendered shell has to fetch, execute and paint before anything shows, which is slower by construction.

Interaction to Next Paint has the opposite trap: heavy hydration on a server-rendered page can leave the main thread busy for a moment right when a visitor tries to tap something. Our Core Web Vitals guide covers the fixes for that once rendering is not the cause of the failure.

Treat rendering and speed as one decision, not two. A page that indexes well but loads slowly is still losing to a faster competitor with equal content.

Does this change for a site with more than one language?

Yes, in one specific way: the language and region tags on a page have to exist in the same first response as the content, or a crawler can read the English content while missing the signal that a translated version exists elsewhere. Client-side locale switching that swaps text without a full navigation often drops this.

Each locale route needs its own server-rendered response with its own metadata, not one shell that swaps strings after load. If your hreflang tags are already correct on paper but pages still cross-rank in the wrong language's results, check whether the render method is the reason; our guide to fixing hreflang errors walks through the rest of that diagnosis.

A related mistake shows up in the <html lang> attribute. If it is set by a client script after hydration rather than rendered on the server, the first response a crawler reads still carries the wrong language declaration even though the visible page looks correct once the script runs. Set it in the root layout on the server, once, per locale route, and it stops being something you have to remember on every deploy.

What about redirects and canonical tags rendered by JavaScript?

They do not count. A canonical tag injected into <head> after the page has already loaded is a canonical tag a crawler that stopped at the first response never read, and a client-side redirect executed by a script is invisible to anything that does not run it. Both belong in server-rendered output: canonical tags through generateMetadata, and redirects through an actual HTTP redirect rather than a router.push call on mount.

This matters most during a migration, when redirect mapping is doing the heavy lifting of preserving rankings. A JavaScript-only redirect will work for a visitor and do nothing for a crawler, which is one of the more expensive rendering mistakes to make at exactly the moment a site can least afford it.

How do I test this before shipping, not after?

Add a render check to your release process, not your audit calendar. A staging deploy that gets fetched without JavaScript and diffed against the current production HTML catches a regression before it reaches a crawler, which is cheaper than catching it in a drop in impressions three weeks later.

Keep the check simple: one script that fetches five to ten representative URLs per template, strips scripts, and compares the extracted text against a saved baseline. It does not need to be clever. It needs to run on every deploy and fail loudly when the content disappears.

This is exactly the kind of check we build into a client's pipeline as part of a technical SEO engagement, because the fix that matters is the one that stops the regression from shipping again, not just the one that repairs today's version.

أسئلة يطرحها الناس

Does Google really render JavaScript before indexing a page?
Yes, in a second wave after the first crawl. Googlebot queues the page, renders it with a recent Chromium build, then indexes what that render produced. The delay between the two passes can be seconds or days on a large site, which is why content that depends on rendering shows up late.
Is client-side rendering always bad for SEO?
No, but it puts every page on the slower, second render queue and gives no guarantee for other bots that never render at all. Server rendering or static generation puts the content in the first response, which is the safer default for anything you want indexed quickly.
How do I know if my Next.js site has a JavaScript SEO problem?
Fetch a page with JavaScript turned off, or view its source instead of the rendered DOM, and compare it with what a visitor sees. If the heading, body copy or links are missing from that plain fetch, a crawler that does not render sees the same gap.
Does hydration affect SEO?
Not the ranking signals themselves, but a slow or broken hydration can hurt Interaction to Next Paint, which is part of page experience. A page that renders correctly on the server but takes seconds to become clickable is still a page experience problem.
Do I need to block AI crawlers from JavaScript-heavy pages?
No. Most AI crawlers fetch raw HTML and do not run scripts at all, so a page that depends on client-side rendering is often invisible to them even when Googlebot eventually renders it. Server-rendered content fixes both problems at once.

المصادر

JavaScript SEO basics — Google Search Central (checked 22 September 2026)
Fix Search-related JavaScript problems — Google Search Central (checked 22 September 2026)
Rendering on the web — web.dev (checked 22 September 2026)

Not sure what Googlebot actually sees on your site?

احجز استشارة مجانية مدتها 30 دقيقة مع إبراهيم وجيريمي. ننظر في موقعك أثناء الحديث، وتخرج بخطة مرتّبة حسب الأولوية.

احجز استشارة مجانية مدتها 30 دقيقة

من كتب هذا

Jeremy ZavaCo-founder

Leads growth and client partnerships.

يعمل على: CRO, SEO

راجعه قبل النشر Ibrahem Helal، Co-founder.

مقالات Jeremy Zava