JavaScript SEO: Detect Rendering Problems and Make Content Crawlable

Modern websites often load content only after the page has opened in the browser. For users, the page may look perfectly fine. For crawlers, it may still be almost empty.

This is exactly where the RankScan insight “Content visible only via JavaScript” comes in.

The insight indicates that important content, links, metadata or structured dataSchema markup is code that describes a page's content in a structured way, so search engines understand it not just as text but as clearly classified information.Open glossary entry → are generated only after JavaScript has run. This is especially critical when this information is not already available in the initial HTMLHyperText Markup Language (HTML) is the markup language for web pages. It defines the structure and content of a page, such as headings, paragraphs, links and images.Open glossary entry → (Hypertext Markup Language, the markup language for web pages).

For classic search engine optimization (SEO)Search Engine Optimization (SEO) covers all measures that help a website become more visible in unpaid (organic) search results.Open glossary entry →, this means: Google does not only need to crawlCrawling is the process by which a search engine bot fetches a URL and downloads its content. It is the first step before a page can be indexed.Open glossary entry → the page, it also needs to renderJavaScript rendering is the process by which a browser or crawler executes JavaScript code to build the final, visible page. Content that is not already in the delivered HTML only appears after this step.Open glossary entry → it.
For artificial intelligence (AI) visibility, it means: Many AI crawlers may only see the raw HTML — and therefore not the actual content.

The important distinction is this:

JavaScript is not bad for SEO. JavaScript becomes problematic when important content is created only on the client side and is not reliably available to crawlers.

In this article, you will learn how JavaScript SEO works, which rendering strategies make sense, how to check what crawlers actually see, and what you should do after a RankScan finding.

What Does JavaScript SEO Mean? #

JavaScript SEO includes all technical measures that ensure JavaScript-based websites can be processed correctly by search engines.

Google explains in its own documentation that Google Search processes JavaScript and that site owners should ensure that content, links and metadata are accessible to Google.
Source: Google Search Central – Understand JavaScript SEO Basics

JavaScript SEO is especially relevant for:

• single-page applications,
• React, Vue or Angular websites,
• headless content management system (CMS)A content management system (CMS) is software for creating, managing and publishing web content, usually without programming knowledge. Well-known examples are WordPress or Shopify.Open glossary entry → setups,
• shop frontends,
• product filters,
• documentation,
• SaaS websites,
• interactive landing pages,
• websites with content loaded after the initial page load,
• pages with client-side generated metadata.

What Does “Content Visible Only via JavaScript” Mean? #

The RankScan insight “Content visible only via JavaScript” means that relevant content or SEO elements appear only after JavaScript execution.

This can affect:

• H1The H1 is a web page's main heading. It names the central topic, is visible to users and should generally appear only once per page.Open glossary entry → headings,
• main body content,
• product information,
• prices,
• categories,
• internal links,
• canonical tags,
• title tags,
• meta descriptions,
• JSON-LD,
• breadcrumbsBreadcrumb navigation shows a page's path within the website hierarchy. It improves user orientation and complements internal linking.Open glossary entry →,
• FAQ content (Frequently Asked Questions),
• pagination,
• filter links,
• navigation.

Not every use of JavaScript is problematic. Often harmless examples include:

• animations,
• tracking,
• menus,
• small interactions,
• form validation,
• cart interactions,
• personalization after login.

It becomes critical when the core content of the page is created only in the browser.

Why JavaScript Rendering Is Risky for SEO #

Search engines have to do more with JavaScript websites than with classic HTML pages.

With a classic page, the crawler receives this directly:

<h1>SEO Consulting for SMEs</h1>
<p>We support companies with technical SEO, content and monitoring.</p>
<a href="/contact">Get in touch</a>

With a pure client-side app, the crawler may receive only this:

<div id="app"></div>
<script src="/app.js"></script>

The actual content is created only after JavaScript has loaded, executed and fetched data from application programming interfaces (APIs).

This is risky because:

• rendering requires additional resources,
• JavaScript can fail,
• APIs may be blocked or slow,
• content may be recognized late,
• internal links may become visible only later,
• crawlers do not always behave like real browsers,
• AI crawlers often do not render at all.

How Google Processes JavaScript #

Google can process JavaScript. Nevertheless, it is sensible to make important content available as early and as simply as possible.

Google explains that Google Search crawls, renders and indexes pages. JavaScript can be processed, but site owners should ensure that content is visible in the rendered HTML and that resources are not blocked.
Source: Google Search Central – Understand JavaScript SEO Basics

Important in practice:

• Google can execute JavaScript.
• Google must be allowed to fetch the resources.
• Google must be able to load APIAn application programming interface (API) is an interface through which software systems communicate and exchange data. It defines how requests are made and answered.Open glossary entry → content.
• JavaScript errors can make content invisible.
• Rendering is an additional step.
• Initial HTML remains important for fast and robust discovery.

The old idea of a strictly separated “two-wave indexing” logic is often presented too absolutely today. In practice, the key point still holds: JavaScript rendering is more complex and more error-prone than HTML delivered server-side.

AI Crawlers and JavaScript: Plan Conservatively #

The situation is less consistent for AI crawlers than it is for Google.

OpenAI documents various crawlers and user agents, including GPTBotGPTBot is the crawler documented by OpenAI that typically fetches content for training future models. It can be specifically allowed or blocked via robots.txt.Open glossary entry →, OAI-SearchBotOAI-SearchBot is the crawler documented by OpenAI for ChatGPT Search. It fetches content so that public websites can appear as a source in ChatGPT summaries, snippets and answers.Open glossary entry → and ChatGPT-UserChatGPT-User is the user agent documented by OpenAI for user-triggered retrieval. It fetches a page when a user enters a specific URL or query in ChatGPT.Open glossary entry →. They serve different purposes and can be controlled via robots.txt.
Source: OpenAI Platform – Overview of OpenAI Crawlers

However, the OpenAI documentation does not state that these crawlers render JavaScript like a browser. For AI visibility, you should therefore not assume that client-side loaded content will be read reliably.

In 2024, Vercel published an analysis of AI crawlers and JavaScript rendering. According to this analysis, major AI crawlers such as OpenAI, Anthropic and Meta do not render JavaScript like classic browsers.
Source: Vercel – The rise of the AI crawler

For RankScan, this means:

If important content is created only through client-side rendering, it is potentially invisible to many AI crawlers.

This is not proof that every AI system will ignore your page. But it is a strong technical risk.

Client-Side Rendering, Server-Side Rendering and Prerendering #

The rendering strategy determines when and where HTML is created.

Client-Side Rendering: When It Becomes Problematic #

Client-side rendering (CSRWith Client-Side Rendering (CSR), the server delivers only a nearly empty HTML shell. The actual content is generated in the browser by JavaScript.Open glossary entry →) means rendering in the browser: The server delivers only a basic shell. The browser loads JavaScript and creates the page from it.

Example:

<!doctype html>
<html>
  <head>
    <title>SaaS Tool</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/bundle.js"></script>
  </body>
</html>

For users, this can work perfectly. For crawlers, it is risky.

CSR is especially problematic when:

• the H1 is missing from the initial HTML,
• the main content is missing from the initial HTML,
• product data is fetched only via API,
• internal links are generated only by JS,
• metadata is set client-side,
• canonicals are set client-side,
• JSON-LD is injected client-side,
• content loads only after scrolling, clicking or user interaction.

Server-Side Rendering: The Robust Solution #

Server-side rendering (SSRWith Server-Side Rendering (SSR), the server generates the finished HTML before delivering the page to the browser or crawler. Content is therefore present in the source immediately.Open glossary entry →) means that the server creates the finished HTML before sending the page to browsers or crawlers.

Example:

<h1>JavaScript SEO: Detect Rendering Problems</h1>
<p>This guide explains how content remains visible to Google and AI crawlers.</p>
<a href="/contact">Get in touch</a>

Advantages:

• content is immediately present in the HTML,
• crawlers see core content without browser rendering,
• metadata is directly available,
• internal links are crawlable,
• structured data can be output server-side,
• a better basis for performance and Core Web Vitals.

SSR is especially useful for:

• SaaS websites,
• shops,
• product pages,
• categories,
• guides,
• documentation,
• news,
• important landing pages.

Static Site Generation and Prerendering #

Static site generation (SSG) creates finished HTML files at build time. This is particularly suitable for content that does not change with every page view.

Well suited for:

• blog articles,
• guides,
• documentation,
• glossaries,
• marketing pages,
• help centers,
• landing pages.

Prerendering creates HTML versions of pages in advance or on demand. It can be a useful transitional solution if an existing CSR app cannot immediately be migrated to SSR.

Important:

• prerendered HTML must match the visible content,
• do not deliver outdated snapshots,
• canonicals and metadata must be correct,
• internal links must be included,
• the bot version and user version must not contradict each other in content.

Dynamic Rendering: Why It Is Only a Workaround #

Dynamic rendering means: Users receive the normal JavaScript app, while crawlers receive a rendered HTML version.

Google describes dynamic rendering as a workaround for websites where JavaScript-generated content is not available to search engines. However, Google also states that dynamic rendering is not a recommended solution because it requires additional complexity and resources.
Source: Google Search Central – Dynamic Rendering as a workaround

Why dynamic rendering is problematic:

• two versions have to be maintained,
• bot detection is error-prone,
• new AI crawlers are often not covered,
• content can differ between the user and bot version,
• cloaking risk if implemented incorrectly,
• complex monitoring.

In most cases, better options are:

• SSR,
• SSG,
• incremental static regeneration (ISR),
• edge rendering,
• clean prerendering.

Hydration: When HTML Becomes Interactive #

Many modern frameworks combine SSR or SSG with hydrationHydration is the process of making server-delivered HTML interactive in the browser via JavaScript. The markup already exists; JavaScript only adds the behaviour.Open glossary entry →.

Process:

1. The server delivers finished HTML.
2. Crawlers can read the content.
3. The browser loads JavaScript.
4. JavaScript makes the page interactive.

This is generally good. Problems arise when hydration fails.

Typical causes of hydration problems:

• server-side data differs from client-side data,
• Date.now() or random values are used during rendering,
• locale output differs,
• API data is not synchronized,
• user state is considered too early,
• components render differently server-side than client-side.

A hydration mismatch can cause content to flicker, disappear or look different in the browser than it did in the delivered HTML.

Framework Notes: React, Vue, Angular, Astro and SvelteKit #

React / Next.js #

Next.js supports SSR, SSG and modern server components. For SEO-relevant pages, content, metadata, canonicals and structured data should be generated server-side.

Important:

• do not load all content only in client components,
• use the Metadata API cleanly,
• output internal links with real <a href> elements,
• embed structured data server-side.

Vue / Nuxt #

Pure Vue can render client-side. For good Vue JS SEO, Nuxt with SSR or SSG is usually the better foundation.

Important:

• use universal rendering,
• set head and metadata server-side,
• load API data server-side,
• output important content in the initial HTML.

Angular #

Angular can render server-side with Angular Universal. Without SSR, pure Angular SPAs (single-page applications) carry the risk that content is created only on the client side.

Astro #

Astro is strong for content-heavy websites because it ships little JavaScript by default. Interactive components can be embedded as islands.

SvelteKit #

SvelteKit supports SSR by default. The important point is not to accidentally disable SSR on SEO-relevant pages.

What Must Be Present in the Initial HTML? #

For SEO and AI visibility, these elements should ideally be present in the initial HTML:

• title tagThe title tag is an HTML element in the page that defines the page title. It appears in the browser tab and can be used as the clickable title in search results.Open glossary entry →,
• meta descriptionThe meta description is an HTML element in the page that briefly summarises the page's content. Google can display it as the description in the search result.Open glossary entry →,
• canonical,
• H1,
• main body content,
• important H2/H3 headings,
• internal links,
• navigation,
• breadcrumbs,
• product name,
• price and availability,
• central images with alt textAlt text is a text alternative for an image, stored in the alt attribute of the img element, describing the content or function of the image.Open glossary entry →,
• structured data,
• FAQ content,
• author information,
• pagination links,
• hreflanghreflang is an HTML attribute that tells search engines the language and region of a page. It links language or regional variants of the same content to one another.Open glossary entry → links.

Not everything has to be perfectly interactive without JavaScript. But the meaning of the page should be understandable without JavaScript.

Real Links Instead of JavaScript Navigation #

Crawlers need real links.

Bad:

<button onclick="goTo('/services')">Services</button>

Better:

<a href="/services">Services</a>

Google recommends using an <a> element with an href attribute so that Google can crawl links reliably.
Source: Google Search Central – Links best practices

This is especially important for:

• main navigation,
• teasers,
• product cards,
• pagination,
• breadcrumbs,
• internal links within content,
• filter pages with SEO relevance.

Set Metadata and Structured Data Server-Side #

Title, meta description, canonical and JSON-LD should not be created only later in the browser.

Problematic:

document.title = 'New page';

or loading JSON-LD only via Tag Manager.

Better:

• output the title in the server-side head,
• output the meta description in the HTML,
• set the canonical server-side,
• set hreflang server-side,
• output JSON-LD directly in the HTML.

Why?

Crawlers and AI systems can then capture the most important signals without rendering.

Lazy Loading, Tabs and Accordions #

JavaScript is not only relevant during the first render. Later interactions can also hide content.

Lazy Loading #

Good for:

• images below the fold,
• videos,
• non-critical modules.

Risky for:

• H1 headings,
• main content,
• product data,
• important internal links,
• prices,
• FAQ content.

Tabs and Accordions #

Usually uncritical if the content is already present in the HTML and is only shown or hidden.

Risky if the content is loaded via API only after a click.

Infinite Scroll #

Problematic if no crawlable pagination URLs exist.

Better:

• standalone URLs,
• pagination links,
• clean use of the History API,
• content available server-side.

How to Check What Crawlers See #

1. View Source #

In the browser:

Right click → View page source

Search for:

• H1,
• main content,
• product name,
• price,
• internal links,
• canonical,
• JSON-LD.

Important: “View page source” is not the same as “Inspect.” DevTools often shows the already rendered Document Object Model (DOM)The Document Object Model (DOM) is the structured representation of a web page that a browser uses to hold its content and structure in memory. JavaScript can modify the DOM to add or remove content.Open glossary entry →, the structure the browser uses to represent a page.

2. Disable JavaScript #

Disable JavaScript in the browser and reload the page.

Check:

• Is the main content visible?
• Are links accessible?
• Is navigation available?
• Are important texts readable?
• Is the page empty?

This does not perfectly simulate every crawler, but it reveals typical risks.

3. Google Search Console URL Inspection #

Use the URL Inspection tool and the live test.

Check:

• screenshot,
• rendered HTML,
• loaded resources,
• blocked resources,
• indexability,
• JavaScript errors.

4. cURL Test #

Call the page without a browser:

curl -L https://example.ch/

Search the output for the main content.

This test shows what simple HTML clients and many bots receive first.

5. Check Logfiles #

Server logs show which bots request your pages and which status codes they receive.

Check:

• GooglebotGooglebot is Google's web crawler, which fetches web pages to crawl and index them for Google Search.Open glossary entry →,
• GPTBot,
• OAI-SearchBot,
• ChatGPT-User,
• ClaudeBotClaudeBot is the web crawler used by Anthropic. Website owners can control its access via robots.txt and block it if needed.Open glossary entry →,
• PerplexityBotPerplexityBot is the crawler documented by Perplexity, intended to make websites visible in Perplexity search results and link them as a source. According to Perplexity, it is not used to train foundation models.Open glossary entry →,
• status codes,
• response sizes,
• blocked resources,
• 403/429 errors.

Prioritization: Which JavaScript SEO Problems Are Critical? #

The most important rule:

Anything important for ranking, understanding, internal linking or conversion should not be generated exclusively on the client side.

Content Problem or Architecture Problem? #

With “Content visible only via JavaScript,” the issue is usually not the text itself, but how it is delivered.

Content or Component Problem #

Examples:

• FAQ component loads answers only after a click,
• product prices are available only client-side,
• filter links are buttons without href,
• author box is inserted only in the browser,
• JSON-LD is added only through Tag Manager.

Solution: Output the component server-side or statically.

Architecture Problem #

Examples:

• the entire website is CSR,
• marketing pages are in an SPA without SSR,
• headless shop renders only in the browser,
• documentation is built from an API via JS,
• prerendering is missing or outdated.

Solution: SSR, SSG, ISR, prerendering or an architecture change.

Architecture problems usually have high priority because they affect many URLs.

What to Do After a RankScan Finding #

If RankScan reports “Content visible only via JavaScript,” proceed systematically.

Step 1: Identify the Affected Elements #

Check:

• Is the main text missing?
• Is the H1 missing?
• Are internal links missing?
• Is product data missing?
• Is metadata missing?
• Is JSON-LD missing?
• Is navigation missing?
• Is FAQ content missing?

Step 2: Prioritize the Page Type #

Especially important are:

• homepage,
• service pages,
• product pages,
• categories,
• guide articles,
• documentation,
• landing pages,
• location pages,
• FAQ and help pages.

A client-side animation is less critical than a product page without product data in the HTML.

Step 3: Check the Rendering Strategy #

Ask:

CSR, SSR, SSG, ISR, prerendering or edge rendering?

If SEO-relevant pages are rendered purely client-side, you should evaluate a more robust strategy.

Step 4: Choose Quick Fix or Architecture Fix #

Step 5: Test #

After the fix, check:

• source code,
• rendered HTML,
• Google Search Console (GSC) live test,
• cURL,
• mobile-friendly rendering,
• logfiles,
• RankScan recrawl.

What a Good JavaScript SEO Check Looks For #

A good check does not simply report that JavaScript is present. What matters is whether important content is created only through JavaScript.

A good check includes:

• main content in the initial HTML,
• H1 in the initial HTML,
• title and meta description server-side,
• canonical server-side,
• JSON-LD in the HTML,
• real internal links with href,
• crawlable navigation,
• product data in the HTML,
• breadcrumbs in the HTML,
• FAQ content in the HTML,
• difference between source code and rendered DOM,
• blocked JS or CSSCascading Style Sheets (CSS) is the language used to define the layout and design of web pages. CSS controls colours, fonts, spacing and arrangement, among other things.Open glossary entry → resources (Cascading Style Sheets, the language used for page layout),
• JavaScript errors during rendering,
• API dependencies,
• HTTPHTTP (Hypertext Transfer Protocol) is the protocol through which browsers and servers exchange web content. HTTPS is the encrypted, secure variant of this protocol.Open glossary entry → status codes (Hypertext Transfer Protocol) for bots,
• AI crawler access in logs,
• CSR patterns such as an empty div#app.

This turns “Content visible only via JavaScript” into a clear technical website health workflow.

Example: Invisible SaaS Landing Page #

Starting Point #

A SaaS provider runs its marketing site as a pure React SPA.

The source code shows:

<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>

In the browser, the page looks complete. RankScan reports:

“Content visible only via JavaScript”
“Missing H1”
“Missing schema markup”
“Low search visibilitySearch visibility describes how present and findable a website is in the organic search results. It is not the same as traffic, but reflects theoretical findability.Open glossary entry →”

Analysis #

• H1 is missing from the initial HTML,
• service description is missing from the initial HTML,
• internal links are created through button navigation,
• JSON-LD is inserted client-side,
• AI crawlers receive only an almost empty HTML shell.

Solution #

1. Move marketing pages to SSR or SSG.
2. Output H1, main content and internal links server-side.
3. Set title, description and canonical in the HTML.
4. Integrate JSON-LD server-side.
5. Hydrate the app after loading.
6. Recheck with cURL, GSC and RankScan.

Result #

Crawlers receive understandable HTML directly. The page becomes more robust for Google, classic crawlers and AI systems.

Common JavaScript SEO Mistakes #

Mistake 1: Confusing Browser View with Bot View #

Just because the page works in the browser does not automatically mean it is crawlable.

Mistake 2: Checking DevTools Instead of Source Code #

DevTools shows the rendered DOM. For the first bot impression, the raw source code matters.

Mistake 3: Building Internal Links as Buttons #

Without real href links, crawlable paths are missing.

Mistake 4: Setting Metadata Client-Side #

SEO signals should not appear only after JavaScript execution.

Mistake 5: Loading Main Content After Scroll or Click #

Crawlers do not interact like real users. Important content should not require user action to load.

Mistake 6: Using Dynamic Rendering as a Permanent Solution #

Dynamic rendering can help, but it is complex and, according to Google, not the recommended long-term solution.

Mistake 7: Ignoring AI Crawlers #

If you deliver content only client-side, you risk many AI crawlers not seeing the central content.

Checklist: JavaScript SEO Audit #

Use this checklist:

• Is the main content present in the page source?
• Is the H1 in the initial HTML?
• Are title, description and canonical set server-side?
• Are important internal links real <a href> links?
• Is JSON-LD present in the HTML?
• Is product data in the HTML?
• Are prices and availability in the HTML?
• Is FAQ content visible without a click or present in the HTML?
• Does the page basically work with JavaScript disabled?
• Does Google see the main content in the URL Inspection tool?
• Are JS or CSS resources blocked?
• Are there rendering errors?
• Are there empty app shells such as <div id="app"></div>?
• Do server logs suggest that bots receive only small HTML responses?
• Was the page recrawled after the fix?

In addition, semantic HTML and the AI Readiness Score help narrow down the cause and prioritize the next SEO measures.

Conclusion: What Is Not Reliably in the HTML Is a Visibility Risk #

JavaScript is not the enemy of SEO. But content generated purely on the client side is a risk.

For Google, JavaScript means additional rendering effort. For many AI crawlers, it may mean: The content is not seen at all.

The RankScan insight “Content visible only via JavaScript” is therefore a high-priority signal. It does not merely show that JavaScript is used, but that important SEO elements may become visible only after rendering.

The best approach is:

1. check what is present in the initial HTML,
2. make important content and links available server-side,
3. output metadata and canonicals in the HTML,
4. integrate JSON-LD server-side,
5. use real HTML links,
6. fix rendering errors,
7. use SSR, SSG, ISR or prerendering for important pages,
8. retest with GSC, cURL, logs and RankScan.

This prevents JavaScript from becoming a visibility problem and turns it into a stable technical foundation for SEO, website health and AI-readable content.

Sources and Further Reading #

• Google Search Central – Understand JavaScript SEO Basics
• Google Search Central – Dynamic Rendering as a workaround
• Google Search Central – Links best practices
• OpenAI Platform – Overview of OpenAI Crawlers
• Vercel – The rise of the AI crawler