From invisible to cited: AEO infrastructure for a venture-backed AI startup

The challenge

The company had a genuinely good website: fast, secure, served from a CDN, clean to look at. By every traditional measure it was healthy. But the people they most wanted to reach were no longer arriving only through a blue-link search results page. They were asking ChatGPT, Claude, Perplexity, Gemini, and Google's AI Overviews, and getting synthesized answers that named other companies.

When I diagnosed the site through the lens of AI answer engines rather than a human browser, the problem was plain: the site was structurally invisible. There was no JSON-LD schema telling a machine what the company was, no llms.txt index pointing AI crawlers at the pages that mattered, and no explicit rules telling those crawlers they were welcome. Performance is not discoverability. A site can be technically excellent and still be a blank page to the systems now deciding which companies get cited.

The brief, once I had framed it, was not "rank higher." It was "become something an AI answer engine can read, trust, and quote."

The approach

I treated AI-discoverability as an infrastructure problem, not a content-rewriting problem. The pattern is small files, big unlock: a handful of machine-readable signals that, added correctly, move a site from zero to legible.

1. A diagnosis first. Before touching anything, I audited the site exactly the way an AI crawler experiences it: what schema exists, what an llms.txt would point to, which AI crawlers are allowed in, and where the live content and the machine signals would agree or drift. That gap analysis is the deliverable that tells you what to build, and in what order.
2. A curated llms.txt index. Not a mirror of the sitemap. A short, deliberate index of the highest-value pages, the file AI crawlers increasingly check first to understand what a site is actually about.
3. An explicit AI-crawler access policy. Clear permissions for the major AI crawler families (the ChatGPT, Claude, Perplexity, Gemini, and Bing lineages, among others) so the site signals intent rather than leaving access to chance, and stays robust as bot-management tooling grows more aggressive about blocking agents it does not recognize.
4. A structured-data layer. A coordinated set of JSON-LD schema describing the organization, the site, the product, the FAQs, and the articles, generated so it stays locked to the visible content and cannot drift out of sync. This is the single highest-impact move for the engines behind Google AI Overviews, Gemini, and Bing Copilot, because it hands them the facts in the format they consume.
5. A staged, additive deploy with a safety gate. Every change shipped through a preview build and went out in verified stages, each independently reversible. Because these are additive signals on a site that had none, the worst realistic case is "no change yet," never a regression. That property is what makes the work safe to ship on a live revenue surface.

The exact schema design, the crawler rules, the llms.txt selection logic, and the data-reconciliation discipline that keeps it all honest are the part I build inside a paid engagement. The principle is portable: give the machines a clean, accurate, structured account of who you are, and remove every reason for them to ignore or distrust it.

The impact

• From structurally invisible to machine-readable. The site moved from zero AI-facing signals (no schema, no llms.txt, no crawler rules) to a coordinated structured-data foundation with explicit AI-crawler permissions.
• The work began surfacing in AI assistants. After the entity and schema foundation shipped, AI assistants started picking up and surfacing the company's work in answers, where before there was nothing for them to find. This is early and directional, not a guaranteed ranking, but it is the signal that the foundation is doing its job.
• A discoverability foundation the team owns. The schema, the index, and the crawler policy live in the team's own codebase and deploy pipeline, not in a tool subscription that stops working when the invoice does.
• Shipped safely on a live site. The staged, additive, per-stage-reversible deploy meant the company never traded its existing stability for a shot at AI visibility.

The cost of the work was small relative to a single missed mention in an AI answer that a competitor got instead. This is foundational infrastructure: it compounds as the AI answer engines mature and as more buyers start their research by asking a model instead of a search box.

How this transfers to your team

This is what I mean by building infrastructure you keep. AI-discoverability is not a one-time submission or a tool you rent. It is a structured account of your business, living in your own codebase, that the answer engines can read every time they crawl. Once it is in place, it keeps working as those engines mature, and it keeps working after I leave the room.

The shift is already underway: more of your buyers are starting their research by asking a model, not typing into a search box. If those models cannot read your site, you are not in the answer, no matter how good the site looks to a human. Closing that gap is foundational, it is safe to ship additively, and the earlier you do it the more it compounds.

If your site is technically excellent but invisible to AI answer engines, that is an architecture gap, not a content problem. That is the kind of gap I take apart.