By the LLMReach Research Team · Published 12 August 2026 · Last updated 12 August 2026

In brief

Rendering, in the context of a Contentful site, is the process by which your front-end framework converts structured JSON content fetched from the Content Delivery API into actual HTML that a browser or crawler can read. The critical variable is *when* that conversion happens: on the server before the response is sent, or in the browser after JavaScript executes. That single decision determines whether GPTBot, ClaudeBot, Perplexity, and every other AI crawler that does not execute JavaScript can see your content at all. In our audits of Contentful + Next.

Answer: If your Contentful front-end uses client-side rendering, AI crawlers see an empty HTML shell. GPTBot, ClaudeBot, and PerplexityBot do not execute JavaScript: they read only what the server sends in the initial HTML response. Only SSR and SSG place content in that initial response. The fix is architectural, not editorial. In our experience auditing Contentful sites, the rendering configuration is the first thing to check when a site ranks on Google but generates no AI citations.

What Rendering Means in a Headless CMS

Traditional CMSes like WordPress generate HTML on the server at the moment a visitor requests a page. The page template, the content, and the final HTML are produced together in one step. Headless CMSes work differently. Contentful provides a powerful JSON API through which all content is served. What a front-end framework does with that JSON is entirely the developer's choice.

This decoupling is the defining feature of headless architecture and also a significant source of rendering risk. The CMS itself is not responsible for how content becomes HTML. The front-end layer is. That means the rendering decision belongs to engineers, not to Contentful.

The Three-Layer Architecture

A standard Contentful implementation has three layers:

Content layer: editors create and publish structured entries in Contentful's web app. Content is stored as JSON and served through the Content Delivery API.
API layer: the front-end application queries the API at build time (for SSG) or at request time (for SSR), or the browser queries it directly after JavaScript loads (for CSR).
Presentation layer: a framework such as Next.js, Nuxt, Astro, or Gatsby converts the JSON response into HTML components.

As Fokal's guide to headless CMS SEO notes, headless CMS SEO works differently from traditional CMS SEO because the architecture separates content storage from the presentation layer entirely. That separation gives you precise control over rendering and performance, but it also means search and AI visibility is your responsibility to build in, not something the platform handles automatically.

The Three Rendering Modes in a Contentful Front-End

Every Contentful front-end chooses, explicitly or by default, one of three rendering modes. Each produces a different initial HTML document and a different result for AI crawlers.

Client-Side Rendering (CSR)

In CSR, the server sends a near-empty HTML shell: a <div id="root"></div> and a JavaScript bundle reference. The browser downloads and executes the bundle, calls the Contentful API, and populates the page. From a browser's perspective the result looks complete. From a crawler's perspective the initial HTML contains almost no content.

Contentful's own guide to server-side rendering explains that CSR usually results in slower page loads than SSR because it involves the browser having to download and execute JavaScript files to dynamically render a page. CSR is the cheaper option as you do not have to pay for server resources, but offloading this work to the client can result in slow page load times, particularly for users on lower-spec devices.

The SEO and GEO cost of CSR is more severe than slow page loads.

Server-Side Rendering (SSR)

SSR generates a fully rendered HTML page on the server in response to each request. The server fetches the Contentful content, converts it to HTML using the framework's rendering logic, and delivers the complete document. By the time the response reaches the crawler or browser, all text content is already present in the HTML.

Contentful's SSR guide defines SSR as when web pages are rendered on the server (in response to user requests), with the server generating a fully rendered HTML page that is then returned to the browser as HTML. This is in contrast to CSR, where pages are rendered in the browser instead of on the server.

Static Site Generation (SSG) and Incremental Static Regeneration (ISR)

SSG pre-renders pages at build time. The framework queries Contentful during the build process, generates complete HTML files, and deploys them as static assets. CDNs serve those static files directly on each request, with no server computation needed per visitor.

In our experience working with Contentful + Next.js at scale, ISR is a practical option for content marketing sites: pages are pre-rendered at build time and regenerated on-demand when Contentful publishes new content. The rendering result is the same as SSG (full HTML in the initial response), so AI crawlers see the same complete document that browsers do. For most content marketing sites, SSG with on-demand regeneration is our recommended default for both LCP performance and AI crawler coverage.

Rendering Mode Comparison

Mode	When HTML is generated	Key text in initial HTML	Contentful API called by
CSR	In the browser, after JS executes	No (empty shell)	Browser (client-side)
SSR	On the server, per request	Yes	Server
SSG	At build time	Yes	Build process
ISR	At build time, refreshed on schedule	Yes	Build process + revalidation

This table captures the architectural difference that matters for AI visibility. Everything in the "Key text in initial HTML" column traces back to whether content reaches the raw HTTP response or stays locked inside JavaScript execution.

How AI Crawlers Actually Fetch Your Pages

The gap between what a browser renders and what a crawler receives is the rendering failure that drives AI invisibility on Contentful sites. Understanding the mechanics is not optional: if you cannot explain what GPTBot receives when it hits your URL, you cannot fix what it fails to see.

The diagnostic question is simple: does your critical page content appear in the raw HTTP response, or only after JavaScript executes? That question has a yes/no answer for every page on your site, and the answer directly determines whether each AI assistant can cite you.

The Gap Between Google and AI Crawlers

Vercel's analysis of crawler behavior is direct: most AI crawlers don't execute JavaScript. They tested the major ones, including ChatGPT and Claude, and the results were consistent: none of them render client-side content. If your Next.js site ships critical pages as JavaScript-dependent SPAs, those pages are inaccessible to the systems shaping how people discover information.

This is not a temporary limitation. As Mintec's technical analysis explains, GPTBot, ClaudeBot, PerplexityBot, Bytespider, and Meta-ExternalAgent do not execute JavaScript. This is a design decision, not a bug: running JavaScript at scale would cost prohibitive amounts of compute per crawled page, and for language models, only the textual content matters.

Googlebot is different. Datagum's analysis explains that Google's crawlers execute JavaScript so Gemini can see client-rendered content. ChatGPT's OAI-SearchBot, ClaudeBot, and PerplexityBot mostly rely on static HTML. The same page can be fully indexed by Google and be completely invisible to ChatGPT.

BrainDo's VP of GEO and Media Strategy puts it plainly: most AI crawlers, including those behind ChatGPT, Perplexity, and Claude, fetch raw HTML only and do not render JavaScript. The exceptions are Google, which renders, and Microsoft Copilot, which runs on the Bing index and inherits Bingbot's JavaScript rendering.

The practical framework for a Contentful site is a two-column audit: one column for "Googlebot sees" (includes JS-rendered content) and one for "AI crawlers see" (initial HTML only). If you have only done Google-focused technical SEO, you have probably never built the second column. That is where the citation gap lives.

What a CSR Page Looks Like to GPTBot

Anglera's guide on LLM crawler behavior describes what happens at the HTTP level. The three most active AI crawlers, OpenAI's GPTBot, Anthropic's ClaudeBot, and Perplexity's PerplexityBot, are conventional HTTP clients, not browsers. They send a request with an identifiable user agent, read the response body, and parse whatever HTML is in it. None of them run a JavaScript engine as part of that fetch. Any JavaScript files downloaded during a crawl are read as raw text, not executed.

The practical result: a Contentful site built as a pure client-side React app delivers a page that looks like this to an AI crawler:

<!DOCTYPE html>
<html>
  <head><title>My Page</title></head>
  <body>
    <div id="root"></div>
    <script src="/bundle.js"></script>
  </body>
</html>

The body contains nothing. Every word of content you carefully wrote in Contentful is invisible.

The Ghost Content Problem in Contentful Implementations

According to SEODiff's research based on a 1,000,111-domain crawl, pure client-side rendered applications exhibit a median ghost ratio of 97%, meaning nearly all visible content vanishes when accessed by GPTBot, ClaudeBot, or PerplexityBot. SEODiff calls this pattern "ghost content": web page content that exists only in JavaScript memory and is invisible to AI crawlers.

Quantifying the Visibility Gap

The data across independent sources is consistent:

SEODiff's research finds pure CSR apps have a median ghost ratio of 97%. SSR implementation reduces ghost ratio to below 5%.
Mintec's production data states that if your site depends on client-side rendering, 50 to 80 percent of your content is invisible to AI.
Adobe's LLM Optimizer documentation is categorical: AI agents can only cite content they can access. When key content is hidden behind client-side rendering and dynamic loads, AI agents miss it entirely, leaving valuable content invisible to the systems that could be citing it.

Why This Is an Architecture Problem, Not a Content Problem

BrainDo documents a pattern and it matches what we see: pages that rank well in organic search yet are invisible for relevant prompts in ChatGPT. The content was strong, but just loaded through JavaScript. It hit the top of Google's search engine results page yet couldn't make a dent into one of the main large language models.

This is the central diagnosis that a rendering audit has to deliver. The root cause is not content quality, not keyword targeting, and not page structure. The root cause is architecture: the framework is assembling the page in the browser, after the crawler has already left. A full rewrite of your content strategy will not fix a CSR rendering configuration. Only a change to where and when HTML is generated will.

We structure this as a three-cause diagnosis when we audit a Contentful site:

Configuration cause: the framework defaults to CSR (Create React App, Next.js Pages Router without getStaticProps) and the team never changed it.
Component cause: the framework uses SSR globally but specific components (including the Contentful Rich Text renderer) are wrapped in 'use client', moving their output back to the browser.
Schema cause: the body is server-rendered but JSON-LD is generated client-side, making the page readable but untyped for AI systems.

Each cause has a distinct remediation. Treating all three as the same problem leads to incomplete fixes that show improvement in some AI assistants but not others.

Rich Text Field Rendering: A Hidden Risk

Contentful's Rich Text field is a common choice for storing long-form content, and it has a rendering characteristic that many teams overlook.

How Contentful Delivers Rich Text

Contentful's technical documentation on rendering linked assets is explicit: the Contentful Rich Text field response is returned as pure JSON rather than HTML. This is a fundamental design choice. The API delivers a document node tree, not a rendered HTML string.

This means the framework is responsible for taking that JSON document and converting it to HTML. If that conversion happens in the browser, the rendered paragraphs, headings, lists, and embedded entries are ghost content. If it happens on the server or at build time, the rendered output is part of the initial HTML response and AI crawlers can read it.

The Crawler's View of an Unrendered Rich Text Page

Consider a Contentful blog post with 2,000 words in the Rich Text field. The API returns a JSON object with dozens of node objects representing paragraphs, headings, and links. If the React component that calls documentToReactComponents() (the standard Rich Text renderer from @contentful/rich-text-react-renderer) runs client-side, then:

The crawler receives the empty HTML shell.
None of the 2,000 words are in the initial HTML response.
The page is 100% ghost content for GPTBot, ClaudeBot, and PerplexityBot.

Moving that same component to a Next.js Server Component, or pre-rendering via SSG, places all 2,000 words in the initial HTML with no code changes to the Rich Text renderer itself.

Schema and Structured Data on a Contentful Site

Structured data is how AI systems verify and classify content. JSON-LD injected into a page's <head> gives crawlers unambiguous signals about what type of content is on the page, who authored it, and what questions it answers. On a Contentful site, schema has two rendering failure modes that we treat separately because they have different causes and different fixes.

Where JSON-LD Lives in the Rendering Pipeline

Contentful's schema SEO guide describes schema as markup that pairs information with data values to help search engines categorize and better understand content. The guide distinguishes page-level schema (FAQ, HowTo) from site-wide schema (Article, Product, Event).

In a Contentful + Next.js implementation, JSON-LD is injected through a <script type="application/ld+json"> tag. The rendering decision for this tag is entirely separate from the rendering decision for the page's body content. A page can be SSR with server-rendered body text but a client-rendered JSON-LD block, or vice versa. We audit both independently.

According to Google's guidance on optimizing for generative AI features, the way Google Search finds and processes your pages remains the core of how our AI systems access your data. Technical clarity ensures your content is ready for discovery and indexing. In our analysis, this applies to JSON-LD as directly as it does to body text: a schema block that only exists in JavaScript memory is not technically clear to the crawler.

When Schema Gets Left Out of the Initial HTML

A failure pattern we document frequently: a team builds FAQ schema using a client-side component that reads FAQ entries from Contentful and dynamically constructs the JSON-LD string in the browser. The page looks correct in DevTools, and the structured data testing tool (which renders JavaScript) shows the schema. But an AI crawler fetching raw HTML sees no schema block because the JavaScript that generates it never runs.

BeCited's technical foundations guide makes the consequence clear: pure client-side rendering is the highest-risk pattern. The text the model needs has to be in the initial HTML response, not assembled by JavaScript on the client. This applies equally to body content and to JSON-LD.

Our diagnosis separates these two failure modes:

Type A (body only): body content is SSR, but no JSON-LD block at all. The page is readable but untyped for AI systems.
Type B (body and schema): body is CSR and JSON-LD is client-rendered. The page is both unreadable and untyped. This is the full ghost state.

The commercial risk of Type B is disproportionate to the engineering effort to fix it. Moving a JSON-LD block from a client component to a server-rendered layout component is a single-file change in Next.js App Router. The risk of leaving it in place is that AI citation systems cannot verify the page type, author, or question-answer structure, which reduces the probability of appearing in AI-generated answers.

How to Diagnose a Rendering Problem on Your Contentful Site

Diagnosing a rendering gap does not require specialized tooling. It requires comparing what a human sees in the browser with what an HTTP client receives from the server.

The Three-Minute Manual Check

Oversearch's troubleshooting guide provides a reliable procedure:

Open your page in a browser and identify a distinctive sentence from your main content.
Right-click and choose "View Page Source" (not Inspect, which shows the rendered DOM).
Use Ctrl+F or Cmd+F to search for that sentence in the raw source.
If it is missing, the content is client-rendered only.

You can repeat this with curl -sL https://yoursite.com/your-page | grep "distinctive phrase" to replicate what an HTTP client (and thus an AI crawler) receives.

What to Look For in the Raw HTML

When you view source, check for these specific signals:

A body that contains only <div id="root"></div> or <div id="__next"></div>: strong CSR signal.
<script> tags that reference bundles but no visible text content in <p>, <h1>, <h2>, etc.: CSR signal.
<script type="application/ld+json"> blocks present in the source: schema is server-rendered.
Full article text present in <p> tags or similar markup: SSR or SSG.

Algorythmic's LLM visibility scanner describes the same principle: AI crawlers fetch the raw HTML response from your URL and analyze it for client-side rendering signals such as empty root divs, SPA frameworks without SSR, and minimal body content.

In our audits at LLMReach, we use the ratio of body text characters in the raw HTML source to the body text characters visible in the browser as a primary signal. A ratio below 20% consistently indicates a rendering architecture that will fail AI citation. We combine this with a direct check of the JSON-LD blocks and metadata tags to get a complete picture of what AI crawlers see versus what the browser renders.

What to Fix and in What Order

Once you have confirmed a rendering gap, the fix order matters. Start with changes that produce more AI-visible content, then layer on schema and performance improvements.

Move Critical Content to SSR or SSG

For marketing pages, blog posts, and resource pages: our recommended default is SSG with on-demand revalidation via Contentful webhooks. Vercel's headless CMS guide describes how on-demand revalidation through webhooks delivers content freshness without sacrificing static delivery. In that pattern, each Contentful publish triggers a targeted cache invalidation, and only the changed page is regenerated.

For pages with user-specific or frequently changing data, SSR is the appropriate choice. The trade-off is server compute per request, but for pages that need to appear in AI answers, it is a necessary cost.

For any Next.js project, migrating page components from 'use client' to React Server Components (or from getStaticProps patterns to the App Router's default server rendering) moves the content assembly to the server without requiring a rewrite of the component logic. The Rich Text renderer can remain unchanged; it just needs to run in a server context.

Inject JSON-LD During Server Rendering

Schema must be present in the initial HTML. In Next.js App Router, place JSON-LD blocks in the page's server-rendered layout or page component, not in a client component. For Contentful-driven FAQ schema, fetch the FAQ entries from the Content Delivery API at render time, construct the FAQPage JSON-LD object, and inject it via a <script> tag in the <head>.

Contentful's technical SEO guide describes the design goal: keep the editorial experience as simple as possible for editorial teams while ensuring the necessary outputs and structures that search engines expect. A well-structured content model that populates schema automatically at render time achieves both goals.

Check Your Sitemap and llms.txt

Contentful's technical SEO guide describes XML sitemaps as structured data files that help search engines index and understand content. Google describes XML sitemaps as a file where you provide information about the pages, videos, and other files on your site, and the relationships between them, so that search engines can crawl your site more efficiently.

Beyond the sitemap, adding an llms.txt file at the root of your domain signals to AI crawlers which pages and resources are most relevant. Mintec notes that Google published its official optimization guide for AI Overviews and AI Mode with the core message that schema markup, llms.txt, and AI-specific rewriting matter far less than having real content in the initial HTML response. Fix rendering first. llms.txt is a secondary signal.

Priority Fix Order

Here is the sequence we recommend for a Contentful site with confirmed rendering gaps:

Audit which pages have the highest AI-citation potential (informational content, FAQs, comparison content).
Move those pages to SSR or SSG first.
Verify the fix with View Page Source before deploying.
Add or fix server-rendered JSON-LD on those same pages.
Test structured data with Google's Rich Results Test.
Add sitemap.xml and llms.txt if absent.
Audit remaining pages and repeat.

The Commercial Risk of Getting This Wrong

The rendering problem is not theoretical. It produces a specific and measurable commercial consequence: content that earns strong Google rankings but generates zero AI citations.

BrainDo's case data documents exactly this: clients whose pages rank highly in organic search but are invisible for relevant prompts in ChatGPT, simply because their content loaded through JavaScript. The organic traffic kept arriving, but the AI-referral opportunity was completely absent.

Siteimprove's analysis extends this further: pages that pass every Lighthouse check can still disappear from AI search results, not because the content is thin, but because the content isn't there when an AI system is looking. Speed and stability aren't just performance goals anymore. They're the price of admission for AI search visibility.

We operate on the assumption that AI assistant citations are becoming a material source of brand discovery. A Contentful implementation that renders content only in the browser cannot contribute to that channel regardless of how well the content model is structured.

If you want to understand which of your pages are at risk and what the citation gap looks like across ChatGPT, Claude, Gemini, and Perplexity, start with a free AI visibility audit. We will show you which pages are server-rendered, which are ghost content, and where the citation gap is largest.

What LLMReach Looks for in a Contentful Audit

At LLMReach, our GEO audit practice focuses specifically on AI crawler visibility. We have developed this methodology across Contentful implementations of varying sizes, from single-market B2B sites to multi-locale enterprise deployments. The framework below reflects what we have found to matter in practice: rendering failures represent a material share of AI citation gaps in the implementations we have audited, and the technical fix is often quicker to deploy than a content restructuring effort.

When we audit a Contentful site, we work through a framework that separates rendering failures from content failures. A page cannot be cited if it cannot be read. That is the first gate in our audit framework, and it is the first thing we check before recommending any content-layer changes.

Our standard Contentful rendering audit covers seven checks:

Raw HTML content ratio across a sample of pages (the ratio of text characters in source HTML to visible browser text).
JSON-LD presence and validity in the initial response (separate check from body content).
Whether <title>, <meta name="description">, and canonical tags are server-rendered or JavaScript-injected.
Rich Text field rendering context (server vs. client component).
Sitemap completeness and robots.txt configuration.
Whether published Contentful content updates immediately appear in the static HTML (our webhook revalidation coverage check).
Bot access configuration: whether robots.txt blocks GPTBot, ClaudeBot, or PerplexityBot, and whether there is an llms.txt file with correct permissions.

The diagnosis typically reveals one of three configurations: a pure CSR site with near-total ghost content, a hybrid site where some pages are server-rendered and others are not, or a fully server-rendered site where the only remaining gaps are in schema and structured data. We have found that hybrid configurations are the hardest to diagnose without systematic tooling, because the pages that rank well in Google are often the ones that were migrated to SSR early, leaving informational content and FAQ pages on CSR.

In our experience across Contentful + Next.js projects at varying scales, moving a CSR page to SSG is typically a one-to-three day engineering task per page type. The rendering change takes effect as soon as the deployment goes live, because there is no browser-side rendering queue to wait for: the content is in the raw HTML from the moment the server responds. The delay between the technical fix and measurable citation improvement reflects re-indexing cycles at each AI platform, not any crawl or rendering delay on your end.

We acknowledge the limits of what our audit can determine remotely: we can measure what is in the initial HTML response, but we cannot determine how each AI training pipeline weights recent crawls against historical data in its index. What we can state from experience is that pages with zero ghost content and valid server-rendered JSON-LD score measurably better on the citation metrics we track across ChatGPT, Claude, Gemini, and Perplexity, compared to the same site's pages that still have ghost content issues.

For enterprise GEO programs, rendering is almost always the first layer of the work. Winning AI citations and content engineering can only improve visibility for content that crawlers can reach. Getting cited by ChatGPT, Claude, Gemini, and Perplexity requires server-rendered content as a prerequisite, not a nice-to-have.

You can also review our guides on how to get cited by ChatGPT, get cited by Claude, get cited by Gemini, and get cited by Perplexity for the content-layer signals that matter once your rendering foundation is sound.

Frequently Asked Questions

Does Google index my Contentful site if I use React?

Yes. Google's web crawler Googlebot executes JavaScript. Contentful's JavaScript SEO guide documents this clearly: Google now has a two-step process for rendering and indexing content using JavaScript. First, Google crawls the static HTML layer. When it discovers JavaScript and other resources, it adds these to a rendering queue for processing to index the page's content and links. This is why a CSR Contentful site can have strong Google rankings while being invisible to AI assistants: Google renders client-side content, AI crawlers do not.

Do GPTBot and ClaudeBot execute JavaScript?

No. Anglera's guide on LLM crawlers confirms that GPTBot, ClaudeBot, and PerplexityBot are conventional HTTP clients, not browsers, and none of them run a JavaScript engine as part of a fetch. Any JavaScript files they download are read as raw text. This means a page that relies on JavaScript to assemble its content will deliver an empty HTML shell to these crawlers, regardless of how much content it shows in a browser.

What is "ghost content" and how do I know if my site has it?

SEODiff defines ghost content as web page content that exists only in JavaScript memory and is invisible to AI crawlers. You can detect it by right-clicking a page in Chrome, selecting "View Page Source," and searching for a sentence that you know is visible to a human visitor. If the sentence does not appear in the source, that content is ghost content from the perspective of GPTBot, ClaudeBot, and PerplexityBot.

How do I check whether my AI-visible content is server-rendered?

Oversearch's troubleshooting guide recommends comparing View Page Source output with what appears in the browser. You can also use curl -sL https://yoursite.com/your-page on the command line. If your main content appears in the curl output, it is server-rendered. If the curl output is an empty HTML shell with script tags, the content is client-rendered only. Google Search Console's URL Inspection tool can also show you the rendered vs. raw HTML difference.

Does Contentful's Rich Text field affect AI visibility?

Yes, significantly. Contentful's documentation explains that the Rich Text field response is returned as pure JSON rather than HTML. The front-end framework converts that JSON to HTML. If that conversion happens in a client component, all Rich Text content is ghost content for AI crawlers. If it happens in a server component or at build time, the rendered text is present in the initial HTML response.

What rendering mode should I use for a Contentful + Next.js site targeting AI citation?

For content marketing pages (blog posts, resource articles, landing pages): SSG with on-demand revalidation via Contentful webhooks. This delivers fully pre-rendered HTML to crawlers and regenerates pages automatically on each Contentful publish. For pages with personalization or frequently updated data: SSR. Avoid pure CSR for any page you want to appear in AI-generated answers. Contentful's edge and server-side rendering documentation covers how to handle personalized content at the server or edge layer without falling back to client-side rendering.

Can I fix a rendering visibility gap without rebuilding the entire site?

In many cases, yes. In Next.js App Router, removing 'use client' from a component that has no browser-only dependencies moves it to server rendering immediately. Rich Text rendering components typically have no browser-side dependencies and can be made server-rendered without any functional changes. Schema injection is often the simplest fix: moving a JSON-LD block from a client component to a server-rendered <head> is a one-line change. A full rebuild is rarely necessary for rendering fixes specifically.

How long does it take to see AI visibility improvements after switching to SSR?

Unlike Google's rendering queue, which can delay indexing by days or weeks, AI crawlers read whatever HTML is in the initial response immediately. BrainDo's analysis notes that because rendering is a technical fix, you may see the impact in weeks rather than months. The delay is not in the crawl but in the re-training cycles and index refreshes of each AI system. In our experience, Perplexity and ChatGPT Browse tend to reflect server-rendered content changes within two to four weeks of deployment.

Next Step

Rendering is the first gate in any AI visibility program for a Contentful site. If the content does not appear in the initial HTML response, no amount of content quality work will produce AI citations.

The fastest way to know where your site stands is a structured audit. We map which pages are server-rendered, which are ghost content for AI crawlers, where schema is absent or JavaScript-injected, and what the citation gap looks like across ChatGPT, Claude, Gemini, and Perplexity for your target queries.

Request a rendering gap assessment to get your specific configuration mapped. If you want to discuss an ongoing GEO program, book a call with our team.

For more on what happens after rendering is fixed, see our guides on content engineering for AI citation, enterprise AI visibility tracking, improving visibility in AI answers, and the ROI of AI visibility.

Sources

Ghost Content: How Client-Side Rendering Erases Pages from AI — SEODiff Whitepaper — seodiff.io. https://seodiff.io/research/csr-ghost-content (accessed 8 August 2026).
Technology and features | Contentful Help Center — contentful.com. https://www.contentful.com/help/faq/technology-and-features/ (accessed 8 August 2026).
Headless CMS SEO: Rendering, Schema, and AI Citation for Decoupled Sites | Fokal Guides — fokal.com. https://www.fokal.com/platform-seo/headless-cms-seo/ (accessed 8 August 2026).
What is server-side rendering? A complete guide with code examples | Contentful — contentful.com. https://www.contentful.com/blog/what-is-server-side-rendering/ (accessed 8 August 2026).
How AI is changing SEO: lessons from a billion crawler requests - Vercel — vercel.com. https://vercel.com/i/how-ai-is-changing-seo (accessed 8 August 2026).
AI Crawlers Don't Read JavaScript — Why SSR and SSG Are Now Essential for Content Sites | Mintec Blog — mintec.co. https://mintec.co/blog/ai-crawlers-javascript-ssr-ssg-spa/ (accessed 8 August 2026).
Why Gemini Sees Your JavaScript Content and ChatGPT Doesn't | Datagum Blog — datagum.ai. https://datagum.ai/blog/javascript-rendering-ai-crawlers (accessed 8 August 2026).
Rendering Visibility: Can AI Crawlers Actually Read Your Site? - BrainDo — brain.do. https://brain.do/blog/geo-rendering-visibility/ (accessed 8 August 2026).
How LLM crawlers fetch pages — and why client-rendered data is invisible — anglera.com. https://www.anglera.com/blog/how-llm-crawlers-fetch-pages (accessed 8 August 2026).
Recover Content Visibility | Adobe LLM Optimizer — experienceleague.adobe.com. https://experienceleague.adobe.com/en/docs/brand-visibility/using/dashboards/opportunities/recover-content-visibility (accessed 8 August 2026).
Rendering linked assets and entries in the Contentful Rich Text field — contentful.com. https://www.contentful.com/blog/rendering-linked-assets-entries-in-contentful/ (accessed 8 August 2026).
Schema SEO & Structured Data | SEO guide | Contentful — contentful.com. https://www.contentful.com/seo-guide/schema-seo/ (accessed 8 August 2026).
Optimizing your website for generative AI features on Google Search — developers.google.com. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide (accessed 8 August 2026).
Technical Foundations for AI Search: Site IA, Entity Mapping, Crawlability, Rendering, Performance | BeCited AI Search Guide — becited.io. https://becited.io/ai-search-guide/technical-foundations (accessed 8 August 2026).
Server Rendered Content | Troubleshooting Guide | Oversearch — oversearch.ai. https://oversearch.ai/resources/troubleshooting-guides/a01-fix-server-rendered-content/ (accessed 8 August 2026).
LLM Content Visibility Scanner | Algorythmic — algorythmic.co. https://algorythmic.co/llm-content-visibility-scanner/ (accessed 8 August 2026).
How to choose a headless CMS in 2026 - Vercel — vercel.com. https://vercel.com/i/how-to-choose-headless-cms (accessed 8 August 2026).
Technical SEO Elements | SEO Guide | Contentful — contentful.com. https://www.contentful.com/seo-guide/technical-seo/ (accessed 8 August 2026).
How Rendering Speed and Stability Affect AI Search Visibility — siteimprove.com. https://www.siteimprove.com/blog/how-rendering-affects-ai-search-visibility/ (accessed 8 August 2026).
4 best practices to ensure your JavaScript is SEO friendly | Contentful — contentful.com. https://www.contentful.com/blog/javascript-seo-best-practices/ (accessed 8 August 2026).
Edge and Server Side Rendering | Contentful Docs — contentful.com. https://www.contentful.com/developers/docs/personalization/edge-and-server-side-rendering/ (accessed 8 August 2026).

How Contentful Renders Content: What AI Crawlers See and Why It Matters