You Can Rank on Google and Still Not Exist in AI Answers

Your next customer already asked ChatGPT who to call. The name that came back wasn't yours.

Buyers have added a step in front of every marketing asset you own. Before they see a homepage — before your ads, your reviews, or your page-one ranking get a chance to work — they put the question to an answer engine: ChatGPT, Claude, Perplexity, Gemini, or Google's AI Overviews. "Who should I call about a slab leak?" "Which company should replace a furnace in my area?" The engine answers in a paragraph, names a handful of businesses, and the shortlist is formed before your website records a single visit.

Here is the thesis of this post: answer engines do not rank ten blue links. They retrieve sources, disambiguate what each source is, and cite the ones that survive both steps. Ranking and being cited are different systems. A business can hold page one on Google and be invisible in AI answers — not because the engines are broken, but because the layer they read was never built. Building that layer is answer engine optimization (AEO) — sometimes called generative engine optimization (GEO) — and two decades of SEO built the first system while almost nobody in the trades has built the second. This post teaches it, stage by stage.

1. The Gap, Measured: Effectively Zero

This began as a measurement exercise, not a marketing opinion — the visibility half of measurement that tells the truth; the attribution half is its own story. NBM built a test harness that captures — prompt by prompt — how a business appears across all five engines: ChatGPT, Claude, Perplexity, Gemini, and Google AI Overviews. We ran dozens of buyer-intent prompts through it: the questions homeowners actually ask the week a system fails, phrased the way real people phrase them, pointed at the trades and the service areas where local businesses live or die.

The baseline finding: across dozens of prompts and all five engines, local-contractor businesses showed effectively zero organic presence. Not underweighted. Not narrowly losing to the shop across town. Absent. The engines answered every prompt with confidence — the answers simply did not contain the local businesses doing the work.

The instinct is to call that a rankings problem and reach for more SEO. It is not a rankings problem, and more of the first system will not build the second. That distinction is the subject of the next section, and it is the most useful idea in this post.

2. Ranking and Being Cited Are Different Systems

Google's classic results page is an ordered list: ten links, sorted by relevance and authority signals, with the user doing the choosing. Everything the industry calls SEO — keywords, backlinks, reviews, site speed — was engineered to win position in that list. That work still matters, and nothing here argues otherwise.

An answer engine runs a different pipeline, and every stage of it does something ranking never did. It retrieves — pulls in candidate sources it can actually read. It disambiguates — resolves what each source is, which business, which service, which city, before trusting it. Then it cites — composes a single answer and names the sources that earned inclusion. There is no list of ten. There is no user paging down to position four.

The engine does the choosing, then shows its receipts.

That pipeline is the framework this post is built on. Call it Retrieve, Disambiguate, Cite: the three things an answer engine does that ranking never did — and, for each stage, a specific layer you build so your business survives it. Fail a stage and the pipeline drops you at that stage, no matter how strong the other two are. The next three sections take the stages one at a time, each with a worked example from a contractor's domain.

3. Retrieve: A Crawlable Site and an llms.txt Manifest

Before an engine can name you, it has to read you. Retrieval systems ingest pages the way a crawler does: they need clean, reachable HTML with the substance of the page in the markup itself. A services page that renders its content through layers of scripts, buries the offer under decorative sections, or locks key details inside images gives a retrieval system very little to hold onto.

The layer here has two parts. The first is the unglamorous one: a site that crawls clean — real text, canonical URLs, service pages that state what they do in the markup. The second is newer: an llms.txt manifest at the site root. It is a plain file that hands any model a map of the domain — the canonical URLs, the primary entities (the business, its services, its service area), and a short site-purpose statement in plain language.

Full disclosure, because this post does not oversell: llms.txt is an emerging convention, proposed by Jeremy Howard, co-founder of Answer.AI, on September 3, 2024, and adopted by documentation-grade sites through 2026. It is a proposed convention, not an official standard — no engine requires it. The case for shipping it anyway is cost against coverage: it is one file, and it states your canon in a format a language model parses without guessing.

Worked example. Picture an HVAC contractor's domain. The retrieval layer means every service page exists as clean, crawlable HTML — and at the root sits a manifest like this:

# [Company Name] — HVAC repair and replacement in [Metro]
> Residential heating and cooling for [Metro] and surrounding
> suburbs: repair, full-system replacement, maintenance plans.

## Services
- [AC repair](/ac-repair): same-week residential AC repair
- [Furnace replacement](/furnace-replacement): sizing, permits, install
- [Service area](/service-area): every city and neighborhood covered

## Company
- [About](/about): licensing, insurance, technician roster
- [Reviews](/reviews): links to third-party review profiles

When a crawler arrives at that domain, nothing about it is a guess. Shipping that file was part of the method NBM built — and an identical one sits at the root of our own domain today.

4. Disambiguate: Schema That States Exactly What You Are

Retrieval gets you read. Disambiguation gets you understood — and this is the stage where most trades websites quietly fail. An answer engine resolves entities before it attaches a name to an answer: which business is this, what exactly does it do, where does it do it. Retrieval reads structured data to know what a page is. When the structure is missing, the engine is left to infer from prose — and a source it has to guess about is a source it can skip.

Consider how much ambiguity an ordinary contractor site carries. A page titled "24/7 Emergency Service" could belong to a plumber, a towing company, a restoration firm, or a locksmith. A human resolves that in half a second from the logo and the photos. A retrieval pipeline does not browse your photography.

The layer here is JSON-LD structured data, written in schema.org vocabulary and validated before anything ships. Four types carry most of the load: Service schema declaring the service type, the provider, and the area served; Article schema on every post; FAQPage schema on real buyer questions; and BreadcrumbList schema placing each page in the site's tree. This was the second move NBM built — schema patches across the domain, every block run through a validator before ship, because an invalid block is not a partial win; it is noise.

Worked example. Take that "24/7 Emergency Service" page on a drain-cleaning company's site. The patch adds Service JSON-LD stating the service type (emergency drain clearing), the provider (one canonical business name, address, and phone), and the area served, listed city by city. FAQPage markup captures the questions buyers ask before calling: after-hours pricing, response time, what counts as an emergency. BreadcrumbList locates the page under Services, then Drain Cleaning. To a human visitor, nothing visible changes. To the pipeline deciding whether it knows what this page is, everything changes — the page now declares what it is in the exact format retrieval reads.

5. Cite: Citation-Worthy Depth Inside a Coherent Topical Cluster

The final stage decides whose name appears in the answer. An engine composing a recommendation cites sources that give it something to say — specifics it can compress into an answer and stand behind with a link. Hold the average trades website against that bar. "Family-owned and operated." "All your plumbing needs." "The trusted choice." There is not one fact in those lines an engine could quote. The gap is not that contractors do bad work; it is that their websites hand an answer engine nothing to cite. And because almost nobody has built this layer, the lane is, for now, nearly empty.

What earns the mention is citation density inside a coherent topical cluster: pages deep enough to answer a real buyer question on their own, connected tightly enough that the domain reads as the place where answers on this topic live. One deep page floating alone reads like an accident. Six deep pages interlinked around one topic read like a source. This was the third move NBM built: six citation-bait pages, each mapped to a question buyers actually ask — questions, not keywords.

Worked example. The buyer query: "tankless or tank water heater for a family of five?" The page built to be cited answers it with substance — sizing logic tied to household demand, tradeoffs stated plainly (recovery rate against endless hot water, upfront cost against operating cost), what permitting involves in the service area, and the cases where keeping a tank is the right call. Around it sits the rest of the cluster: failure warning signs, replacement timelines, what installation day involves, how the major brands differ. Interlinked. One topic, covered end to end. That cluster is what a citable source looks like to an engine assembling an answer about water heaters — and it is the difference between content that fills a blog and content built to be quoted.

6. The Answer Engine Optimization Sprint: Baseline, Ship, Re-Audit — in Writing

Here is the part most posts in this category get wrong. You might expect a wall of results right about now, and there will not be one. NBM has published no AEO outcome numbers, and no one who understands these engines will promise you placement inside them — the engines do not sell it, and nobody outside them controls it.

What replaces the highlight reel is structure, and the structure is the point. The method is public; this post is most of it. For a client's domain, the work will run in the same order you just read. The five-LLM mention audit will run first — dozens of buyer-intent prompts across all five engines — to establish your baseline in writing. Then the build will ship: schema patches validated before they go live, the llms.txt manifest at your root, six citation pages mapped to the questions your buyers ask. Then the clause that makes it accountable: a 30-day re-audit written into the contract. The same harness, the same prompts, the same five engines will run again at day 30, and you will hold the before and the after in the same document. If the needle moves, you will see exactly where. If it does not, you will see that too. The before and the after, in the same document — receipts either way.

One more thing worth weighing: NBM runs this same playbook on its own site. The deliverable is the discipline we already operate, pointed at your domain.

The question has already moved. It gets asked in five engines before it ever reaches a homepage, and right now — for your trade, in your city — the answer that comes back is assembled from whatever those engines can retrieve, resolve, and cite. Ranking is the system you spent twenty years learning to win. The citation layer is the system almost nobody has built. Build it while that sentence is still true.