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 measure “Little content in the delivered 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 → – check renderingJavaScript 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 →” comes in.

During the 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 →, RankScan reads the delivered HTML (Hypertext Markup Language, the markup language for web pages). RankScan does not run JavaScript. If the delivered HTML of a page contains fewer than 50 words, RankScan reports it. This is a hint at possible client-side rendering, not a rendering measurement. Few words can also have other causes, such as a short page or an error page.

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 crawl the page, it also needs to render 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 do when RankScan shows the measure.

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 “Little Content in the Delivered HTML – Check Rendering” Mean? #

The RankScan measure “Little content in the delivered HTML – check rendering” means: The delivered HTML of the affected pages contains fewer than 50 words of text. The title names the measurement. RankScan only counts the words in the delivered HTML and makes no rendering diagnosis.

Few words are a hint at possible client-side rendering. Other causes are just as possible: the page is simply short, or it is an error page that responds with status code 200HTTP status 200 (OK) means a page was found and served successfully. Only 200 URLs should appear in the sitemap and serve as canonical targets.Open glossary entry →. The test with JavaScript turned off shows which cause applies.

Rating in RankScan: medium severity · medium effort · work type Development.

What RankScan Measures #

• RankScan counts the words in the text the server delivers. RankScan does not run JavaScript.
• It counts the whole text of the page, including navigation and footer.
• If a reachable page (status code 200) has fewer than 50 words, it counts toward the measure.
• Legal, system and confirmation pages do not count, not even in the total of checked pages. On login, account or password pages, JavaScript is correct.
• RankScan determines the page type during the crawl. If RankScan does not recognize a system page, skip it yourself.
• If a page has 50 words or more, this measure does not apply. Depending on the page type, RankScan also reports pages with fewer than 300 words in the main content under “Little text in the main content – check substance”. This includes pages below 50 words.

The measure only counts the words in the delivered HTML. You check JavaScript errors, blocked resources and the difference between source code and rendered DOMThe 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 → with the tests further below. There you also check whether title, canonical, links or JSON-LD are created only by JavaScript.

Little text in the HTML is a hint at possible client-side rendering, but not proof. A short page or an error page without JavaScript also falls under the measure. That is why you first open the pages with JavaScript turned off.

Which Elements Can Be Affected #

From a professional point of view, JavaScript rendering can affect these elements:

• 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

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 #

Current Angular supports server and hybrid rendering through the @angular/ssr package. You set it up with ng add @angular/ssr. Review existing Angular Universal projects according to the Angular version they use.
Source: Angular: Server and hybrid rendering

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 <head> 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 <head> 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 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.

Assessment: Which JavaScript SEO Problems Are Critical? #

The following table is a general professional assessment. RankScan shows a single severity for the measure: medium. The measure is a hint, not proof of a rendering problem.

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 “Little content in the delivered HTML – check rendering”, 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 weigh more because they affect many URLs.

How to Proceed When RankScan Shows the Measure #

The steps follow the measure in RankScan. The technical notes add to them.

Step 1: Skip System Pages #

First check whether a page is a system page: login, account, password or form status. Skip those pages. JavaScript is correct there.

Step 2: Open the Pages Without JavaScript and Note What Is Missing #

Open the remaining pages with JavaScript turned off. Note what is missing:

• 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?

If the page is almost empty even with JavaScript, there is no rendering problem. The page simply lacks text.

Step 3: Pass the List On to Your Developers or Agency #

Pass the list on to your developers or agency. Sort it by page type. Especially important are:

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

Add the rendering strategy of the website, as far as you know it:

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

If SEO-relevant pages are rendered purely client-side, a more robust strategy is usually needed.

Step 4: Have the Content Delivered Server-Side or Through Pre-Rendering #

Have the content delivered server-side or through pre-rendering. Depending on the cause, a quick fix is enough, or an architecture fix is needed:

Step 5: Check and Mark as Done #

After the fix, check:

• source code,
• the page with JavaScript turned off,
• Google Search Console (GSC)Google Search Console (GSC) is a free Google tool that shows how a website performs in organic search, with data on impressions, clicks, click-through rate and average position, plus indexing and technical issues.Open glossary entry → live test,
• cURL,
• logfiles.

Mark the measure as done once the content appears without JavaScript.

Verification: The next full crawl checks all affected pages. RankScan then reports “Fixed” or “Not fixed yet” with the number of pages still below 50 words.

General Checklist: What a Good JavaScript SEO Check Looks For #

This list is a general professional checklist. RankScan measures only one of these points: whether the delivered HTML contains at least 50 words of text. You check the other points yourself, for example with the tests above.

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.

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. But the delivered HTML contains almost no text. RankScan therefore lists the page in these measures, among others:

“Little content in the delivered HTML – check rendering”
“Pages without a main heading (H1)”

Rating of the first measure: medium severity · medium effort · Development

Analysis #

The test with JavaScript turned off and a look at the source code show:

• 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. Check with cURL and the GSC live test.
7. Mark the measure as done. The next full crawl checks the page.

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 impressionImpressions indicate how often a website's search result was shown in Google Search, regardless of whether it was clicked. They are a core Google Search Console metric and reflect a page's raw visibility for given queries.Open glossary entry →, 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?
• Did you skip system pages such as login or account?
• Did you mark the measure as done in RankScan?

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 measure “Little content in the delivered HTML – check rendering” has medium severity, because little text in the HTML is a hint, not proof. It shows pages whose delivered HTML contains almost no text. On these pages, the content may be created only after rendering. The test with JavaScript turned off shows whether this is the case.

The best approach is:

1. skip system pages and 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. check with GSC, cURL and logs,
9. mark the measure as done; the next full crawl checks the pages.

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
• Angular: Server and hybrid rendering