AI Visibility

AI visibility is whether AI assistants can reach and read your site at all. It's the technical foundation beneath Answer Engine Optimization (AEO), sometimes called Generative Engine Optimization (GEO). Before an AI can cite, summarize, or recommend you, it has to be able to fetch and read your pages. Many modern sites quietly fail this first step while looking perfect to human visitors.

The problem: AI crawlers don't run JavaScript#

When a person visits your site, their browser downloads your HTML, runs your JavaScript, and paints the page. AI crawlers mostly skip that last part. ChatGPT, Claude, Perplexity, Google's AI Overviews, and the link-preview bots behind Slack, iMessage, and social platforms fetch your page over plain HTTP and read the HTML the server returns, before any JavaScript runs.

If your content only appears after JavaScript executes in a browser, those crawlers receive an empty shell. Your page works flawlessly for humans and is invisible to the machines that increasingly decide what gets recommended.

How to think about it: three gates#

A page is AI-visible only when it clears three independent gates. Fail any one and the page is effectively invisible, no matter how good the content is.

1. Discoverable: can a crawler find your URLs? (a sitemap, clean internal links)
2. Allowed: does your robots.txt permit the crawlers that cite you?
3. Readable: does the server return real content, or an empty shell that needs JavaScript?

The gates are independent: a perfectly readable site that blocks AI crawlers in robots.txt is invisible, and a site that allows every crawler but ships an empty shell is invisible. You need all three.

Client-side rendering: the readable gate#

The readable gate is where modern stacks most often fail, so it's worth understanding in depth, especially when you're choosing a stack.

A single-page app (SPA) built with a client-rendering setup (Create React App, Vite + React or Vue, and similar) ships a near-empty HTML document: a <div id="root"></div> and a JavaScript bundle. The browser fills in the content by running that bundle. A crawler that doesn't run the bundle sees exactly that empty <div> and nothing else.

Titles and meta may still be read#

A nuance worth knowing: many SPAs still set the <title> and meta tags server-side (or via the host), so a crawler may read those even when the body is empty. That's why a client-rendered site can look half there to AI: it knows your page exists and what it's called, but not what it says. For being cited and summarized, the body is what counts.

This is a stack-selection decision#

If you're building a marketing site, docs, or any content you want discovered, choose a stack that renders on the server from the start:

• Astro: excellent for content and marketing sites; ships static HTML by default.
• Next.js (App Router): server components return real HTML, which is great when the same project also needs marketing surfaces.
• Other SSR/SSG frameworks (Remix, SvelteKit, Nuxt, Hugo) work well too.

If you already have a client-rendered app, you don't have to rewrite it, but the pages you want AI to read should be server-rendered or statically generated. A common, healthy pattern: keep the app client-rendered, and build the marketing and content site on a server-rendered stack alongside it.

Crawler access: the allowed gate#

Even a perfectly readable site is invisible if its robots.txt turns the crawlers away. Two kinds are worth separating:

• Citation crawlers (OAI-SearchBot, ChatGPT-User, PerplexityBot, Claude-User, Googlebot, Bingbot, and friends) fetch pages to answer questions and cite sources. Blocking these means you can't be surfaced in AI answers, which is rarely what you want.
• Training crawlers (GPTBot, ClaudeBot, CCBot, Google-Extended, and friends) collect data to train models. Allowing or denying them is a legitimate preference, entirely separate from whether you can be cited.

The common footgun is a leftover User-agent: * / Disallow: / (often from a staging config) that blocks everyone. If you want to be cited, allow the citation crawlers; training is your call. Allowing them only gets you into the running, though. Whether AI actually cites you is your AI answer presence.

Discoverability: the discoverable gate#

Finally, crawlers have to find your URLs. A sitemap.xml (plus clean internal linking) is how they enumerate your pages. Missing a sitemap isn't fatal, since crawlers can follow links, but it's the cheapest way to make sure nothing important gets overlooked.

How Rampify surfaces this#

When Rampify crawls your site, it checks all three gates the same way an AI crawler would, over plain HTTP without running JavaScript, and reports the result on your project's Website page as an AI Visibility card:

• Readable: Rampify classifies each site's render mode (server-rendered vs client-rendered) from the homepage's server HTML.
• Allowed: it parses robots.txt against a known list of citation vs training crawlers.
• Discoverable: it checks for a sitemap during the crawl.

When a site is client-rendered, Rampify raises a high-priority finding, your site is invisible to AI crawlers, with the page-source self-check and remediation above, instead of burying you in per-page SEO issues that don't matter until the page is readable in the first place.

Beyond visibility: AI Answer Presence#

Being readable is necessary but not sufficient. Once AI can read you, the next question is whether it actually cites and recommends you, your AI Answer Presence. That's the outcome side (mentions, citations, recommendations), covered on its own page. This page is about the foundation: clearing the gates so you're in the running at all.