How to Get Your B2B SaaS Recommended by ChatGPT, Gemini, and Perplexity: The Playbook

Every vendor blog in this category promises the same thing: get your product into the list when a buyer asks an assistant which tools to use. Almost none of them explain how the list gets built.

That gap matters, because the assumption underneath most of that advice is wrong. The recommendation decision isn’t a ranking contest you win by being loudest. It’s a shortlisting process that runs on at least two independent checks, and a product can fail either one while looking perfectly healthy in every other respect.

Let’s work through how the shortlist gets built. We’ll use the assistants’ and directories’ own documentation. You’ll also get two tools: a worksheet to check whether your positioning uses buyers’ language, and a readiness rubric to find which of the two checks is holding you back.

The shortlist is a verdict, not a ranking

A buyer who asks an assistant “what’s the best field service software for a 40-person manufacturer” isn’t running a search. They’re commissioning an evaluation, and the assistant runs it by gathering sources, reconciling them, and returning a handful of names it’s willing to defend.

Two things follow from that, and they set up everything else.

First, the assistant checks names across multiple retrieved sources. A product that looks excellent in one place and is absent everywhere else gives it little to compare. Second, most of those sources aren’t yours. We’ll deal with that in the corroboration layer below.

What happens when a buyer asks an assistant for software

One question becomes several searches

Google documents a technique called query fan-out: “a set of concurrent, related queries generated by the model to request more information and fetch additional relevant search results to address the user’s query.” The documentation gives a worked example:

if the original user’s query is “how to fix a lawn that’s full of weeds”, fanout queries might include “best herbicides for lawns”, “remove weeds without chemicals”, and “how to prevent weeds in lawn”.

Read that again with a software buyer in mind. A question phrased as a problem (“our technicians are writing up service reports on paper”) fans out into at least one query phrased as a selection (“best field service software”). Google says the same thing about why AI Mode exists at all: it’s “particularly helpful for queries where further exploration, reasoning, or complex comparisons are needed.”

That’s why comparison content can show up in AI answers. The system needs to work out the product category before it can compare options for the buyer’s problem. That gives it a reason to search for comparisons. It doesn’t mean someone chose listicles as the best format.

ChatGPT search does something structurally similar. OpenAI’s help documentation states that ChatGPT “typically rewrites your query into one or more targeted queries that it sends those providers”, and describes the two-stage behaviour explicitly: an initial broader query, followed by “more specific queries to other search providers” after reviewing the first set of results. The help page also notes that if memory is enabled, ChatGPT may fold relevant saved memories into the rewritten query.

Two practical consequences. First, you can’t control the fan-out; you can only control what exists to be found. Second, the query that has to return results isn’t the one your buyer typed, so optimising for your homepage headline is optimising for a query that may never be issued.

The clarification step is where you get filtered

OpenAI’s Deep Research documentation describes a three-stage pipeline for research-mode answers: clarification, then prompt rewriting, then research. The clarification stage runs before any searching, and its job is described as helping “clarify the user’s intent and gather more context (such as preferences, goals, or constraints)”. Prompt rewriting then turns the original question plus those clarifications into “a more detailed prompt” that drives the actual research.

The research agent isn’t starting with your product. It’s searching for the particular problem the buyer described, using their preferences, goals, and constraints. Your product needs to be findable on the dimensions that came out of that clarification step.

That’s why a company with an excellent product and a generic category description tends to disappear. Nothing in its own copy maps onto the buyer’s circumstances, so the retrieval finds it for general queries and not for the specific one that generated the answer.

Eligibility is a switch, not a ranking factor

Before any of this matters, your pages have to be reachable. Each vendor controls search visibility through a distinct crawler token, and the tokens are deliberately separate from training crawlers.

OpenAI’s crawler documentation is explicit that the settings are independent: “a webmaster can allow OAI-SearchBot in order to appear in search results while disallowing GPTBot to indicate that crawled content should not be used for training”. GPTBot is for training. OAI-SearchBot is for search surfacing. Blocking GPTBot doesn’t remove you from ChatGPT search answers, and allowing it doesn’t add you. ChatGPT-User is a third token used for user-initiated fetches, and OpenAI states plainly that it “is not used to determine whether content may appear in Search”.

Perplexity draws the same line: PerplexityBot “is designed to surface and link websites in search results on Perplexity” and “is not used to crawl content for AI foundation models”, with Perplexity-User handling user-directed requests. Anthropic uses Claude-SearchBot for search indexing, distinct from ClaudeBot for training and Claude-User for user fetches.

Two operational details are worth more than they look. Both OpenAI and Perplexity state that robots.txt changes take roughly 24 hours to take effect, so configuration changes can’t be validated the same afternoon. And Perplexity publishes explicit Cloudflare and AWS WAF whitelisting guidance, which tells you something vendors rarely admit: plenty of sites block these crawlers at the firewall rather than in robots.txt, where a robots.txt audit will never find them. If you have a CDN in front of your site, check it.

On Google’s side the requirement is different in kind. To be eligible as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to appear in Search with a snippet. The 2025 documentation states plainly that “there are no additional technical requirements”. The newer guide adds a further condition: “a site must be included in Search generative AI features in Search Console to be eligible for display in generative AI features on Google Search.” Treat that as a new gate to check rather than a settled reading, since the two pages differ and the newer one is closer to current.

Finally, the honest caveat from the vendor side: OpenAI’s help page states that “placement is not guaranteed” and warns that “search results and citations can be incomplete, outdated, or incorrect.” Nothing in this guide changes that.

Keeping it current is a separate problem from being allowed in

Eligibility gets you into the pool. Freshness decides whether what is retrieved is the version you still stand behind, and for SaaS pricing and packaging pages that’s a recurring obligation rather than a launch task.

The IndexNow protocol is the main tool here. Participating search engines agree “that submitted URLs will be automatically shared with all other participating search engines”, so a single integration propagates a change notification widely. Microsoft recommends it explicitly for AI answers, on the grounds that “By enabling faster discovery of content changes, IndexNow helps ensure that AI systems reference the most current version of a page when generating answers.”

Two cautions. IndexNow announces that a URL changed; it doesn’t make the change, and it doesn’t repair a page that’s misleading. And it does nothing about the other systems in this guide, which decide eligibility on their own crawlers and don’t document IndexNow support.

The two-source rule

A defensible recommendation needs evidence from at least two of three layers:

1. Your own definitional layer. Pages where you state what the product is, what it does, who it’s for, what it costs, and how it’s deployed.
2. The taxonomy layer. Where you’re filed inside an established software category structure, and how completely your listing satisfies that category’s stated requirements.
3. The corroboration layer. Independent sources - review platforms, integration directories, analyst or community discussion - that describe you without your involvement.

A product strong in layer one and absent from two and three can be findable without being recommendable. That’s the single most common failure state for B2B SaaS, and it’s invisible from inside the company, because everything the team can see lives in layer one.

A Gartner survey of 645 B2B buyers, published in May 2026, supports the multi-source shape of the decision directly. Buyers “reported using an average of seven information sources during a recent purchase”, and 45% said they used generative AI “primarily to gather information on vendors and products.” Seven sources isn’t one source, and it isn’t two.

Layer one - your own definitional pages

Start here because it’s the only layer you control completely, and because it’s where the other two layers source their descriptions of you.

A definitional page answers four questions without requiring the reader to infer them:

• What does this do? (function, not adjectives)
• Who uses it, in what role?
• What does it cost, at what tier, and what is the unit of pricing?
• What does a buyer have to be able to do to implement it?

The most common failure is answering the first question with positioning rather than function. “The intelligent platform that transforms how teams work” tells a retrieval system nothing it can match against a buyer’s query. “Field service management software that dispatches technicians, captures signatures on mobile, and syncs job status to accounting systems” contains three matchable phrases.

There’s a published standard for this that has nothing to do with AI. Zapier’s integration publishing requirements tell vendors what the listing description must look like, and they’re unusually blunt about it. Descriptions must “leads with your app name in the form of <Integration Name> is a...”. The document gives a positive and a negative example:

Trello is a team collaboration tool to organize anything on a kanban board., not Trello is the best project management tool.

Then the instruction that matters: “Focus less on selling the application, instead, provide a clear explanation of what your application actually does.”

That’s the industry-standard listing convention telling vendors, in its own implementation rules, that superlatives aren’t merely unhelpful but non-compliant. Hold onto that, because section on the rubric below scores against it.

The same document also constrains naming: enter your application name “exactly as it appears in your core branding”, and don’t include “trademark or copyright identifiers like a TM suffix or words like ‘app’ or ‘integration.’” G2’s categorisation methodology draws a parallel rule for product profiles: the name “should contain no additional keywords, marketing language, or copyright/trademark symbols.”

Two other definitional-page habits are worth building in now. Keep pricing on the page, in text, with a stated date - Google’s helpful content guidance (last updated 5 October 2026) explicitly flags “changing the date of pages to make them seem fresh when the content has not substantially changed” as a warning sign, and stale pricing pages are exactly where vendors are tempted. And keep deployment and integration requirements stated plainly, because those are the dimensions a buyer volunteers during the clarification stage, and they’re the dimensions most often missing from a homepage.

Layer two - the taxonomy you are filed under

If you sell B2B software, your category placement isn’t a marketing choice. It’s a controlled classification, and the rules are published.

G2’s categorisation methodology states the governing principle plainly: products are categorised “based on the functionality of the software or service, i.e., the product’s features, and not based on what it is used for or who uses it.” Many products get used for things they weren’t designed for, and G2’s stated position is that this “does not change the categorization of the product.”

That single sentence is the most useful thing in this entire guide, and it runs directly against how B2B SaaS companies describe themselves. Buyers and sellers both describe software by use: “for agencies”, “for healthcare practices”, “for manufacturers”. The directory that your category placement depends on files by feature set. If your category selection was argued in terms of your vertical rather than your feature set, you’re likely filed somewhere unhelpful, or filed nowhere.

Three further structural facts from the same page:

• Categories have mandatory inclusion criteria. Each category carries a definition plus feature requirements, and “a product needs to meet all the feature requirements to be added into that category.” Partial fit doesn’t count.
• “Other” categories are a trap, not a placement. If a product doesn’t qualify for a defined category it lands in a relevant “Other” bucket, and “Other” categories are designated only for products that can’t be listed elsewhere.
• You usually can’t invent your way out. G2 evaluates a new category proposal against a minimum of ten qualifying competing products and “will not create a category for a ‘market of one.’” Its quick-start guide defines categories as “a set of core features or ‘jobs to be done’ that all products in that group must provide.”

That last phrase is worth pausing on, because it puts G2’s definition of a category and Christensen’s definition of a job to be done very close together. A G2 category is a cluster of shared jobs; your listing needs to satisfy the features that define that cluster.

G2 also publishes the arithmetic that governs whether you appear at all. From the quick-start guide:

• Grid placement generally requires 10 or more approved, recent reviews.
• “The G2 algorithm heavily weights the recency of user feedback.”
• A Segment Grid - the Small Business or Enterprise cut - requires at least 10 reviews specifically from users in those company sizes.

Forty reviews don’t make a profile strong if the newest is fourteen months old. With recency weighting, that profile loses ground to a competitor with twelve fresh reviews. Keep reviews coming in. The flow matters as well as the total.

Layer three - the corroboration layer

This is where the advice in most of this category goes wrong, because it usually means “get reviews” or “get mentioned”. Both are necessary and neither is sufficient, and one of them has a documented downside.

Start with what the vendors themselves say about manufactured mentions. Google’s AI optimization guide has a section headed “Mythbusting generative AI search” that addresses this directly:

Seeking inauthentic “mentions”: … seeking inauthentic “mentions” across the web isn’t as helpful as it might seem. Our core ranking systems focus on high-quality content while other systems block spam; our generative AI features depend on both.

And from the same guide, on content built at scale across a network of sites, the helpful-content page is blunter. It asks whether content “is mass-produced by or outsourced to a large number of creators, or spread across a large network of sites, so that individual pages or sites don’t get as much attention or care”, and separately defines low effort as content where “automatically generating pages from feeds or using generative AI to produce large amounts of text without manual oversight or curation represents little to no effort.”

The B2B SaaS comparison market has a distinctive structure that makes this warning concrete. In my experience of this vertical, “best X software” listicles are commonly monetised through affiliate commissions and paid placements, which means a meaningful share of the comparison content a buyer - or an assistant retrieving for a buyer - encounters is produced by parties with a direct commercial interest in a specific ordering. Google is describing precisely that shape of content, and describing it as a liability.

The same guidance tells you what the credible version looks like. On product reviews:

it can build trust with readers when they understand the number of products that were tested, what the test results were, and how the tests were conducted, all accompanied by evidence of the work involved, such as photographs.

Methodology disclosure, sample size, and evidence. That’s the bar. A page that ranks six tools in a fixed order with no stated criteria isn’t a corroborating source in any useful sense; it’s a ranking assertion.

Google also constrains the manufactured-expert route explicitly: “avoid using deceptive authorship information. Fabricating creator profiles (such as by using AI-generated headshots, made-up names, or false credentials to make content appear as if it was written by human experts) is a form of deception.”

For layer three, I’d focus on a few sources with a clear method. Each should contribute something you can’t establish yourself: a usage pattern, a comparison criterion, an implementation constraint, or a failure mode. Two well-substantiated independent sources give the assistant more to work with than twenty thin mentions. Thin sources add little when it checks claims across sources.

The positioning-language worksheet

Everything above reduces to one question: does your language match the language your buyer would use to describe the problem?

The convergence is what makes it worth using. HBS Online summarises Christensen’s definition of a job to be done as “a ‘circumstances-based description of understanding your customers’ desires, competitive set, anxieties, habits, and timeline of purchase’”, with statements captured as “Help me…”, “Help me avoid…”, and “I need to…”. Separately and independently, OpenAI documents that the clarification stage gathers “preferences, goals, or constraints” before rewriting the query. A business-school framework and an engineering specification, written for different purposes decades apart, both land on circumstances rather than attributes.

Fill one row per candidate phrasing. Eight to twelve rows is a realistic target.

Field	What to enter
Verbatim buyer sentence	Actual words from a sales call, a lost-deal debrief, a support ticket, a community post. Not a marketer’s paraphrase.
Frame	Which Christensen frame it fits: Help me / Help me avoid / I need to.
Function it names	The feature set doing the work, not the outcome it claims.
Directory category it maps to	The G2-style child category whose feature requirements you actually meet.
Persona	Economic buyer, practitioner, IT/security, procurement/compliance.
Dimensions it captures	Company size, budget band, deployment model, required integrations, industry or regulatory constraints.
Your page that proves it	One URL. If there isn’t one, that is the finding.
Independent source	One URL you do not control that says the same thing.

Three rules for filling it in honestly.

Get the buyer sentences from transcripts, not from the founder. The failure mode here is subtler than laziness: the people writing positioning copy inside a company are extremely fluent in the category vocabulary, so their recollection of what buyers say is contaminated by their own language. Sales call recordings, lost-deal reasons, and community threads are worth more than internal workshops.

Expect persona splits to be real. Gartner’s survey found reps remain the most important information source at three distinct points: “researching a business problem or need, identifying a preferred supplier and securing internal support, and finalizing the purchase.” Those are different people asking different questions, and the dimensions they volunteer during a clarification step will differ. A worksheet with one persona row isn’t finished.

Watch for the use-case/feature-set trap in the “category it maps to” column. If you can’t name the directory child category whose feature requirements you meet, that’s the answer - and it usually means your listing is sitting in an “Other” category or in the wrong one.

The recommendation readiness rubric

Each dimension scores 0 to its weight. Total 100.

1. Crawler eligibility - 15 points

Score	Condition
15	All search crawlers allowed in robots.txt and verified past CDN/WAF. Search Console generative AI features includes your site.
8	Robots.txt correct, CDN/WAF unverified.
0	Any search crawler blocked, or site blocked at the edge.

Check the firewall, not just robots.txt. Perplexity publishes WAF guidance precisely because this layer fails silently.

2. Category placement - 15 points

Score	Condition
15	Claimed profile in the correct child category, meeting every stated feature requirement, plus any Segment Grid you qualify for.
8	Correct parent category, missing a segment or a requirement.
0	Unclaimed profile, or sitting in an “Other” category, or wrong category.

An unclaimed G2 profile is the most common zero here. Per G2’s own documentation, vendors submit a product submission form, have the research team verify eligibility and categorisation, then claim the approved profile.

3. Evidence density - 20 points (the largest single weight)

Scores 0 to 20 against the worksheet: 1 point per dimension row where you have both a page that proves the claim and an independent source that corroborates it. Rows where you have only your own page score zero. Rows where you have only an independent source score zero and are flagged separately - that pattern usually means someone else has described you better than you have, and the worksheet tells you what to write.

This dimension is weighted highest deliberately. It’s the only place where both a definitional and a corroborating source are required for the same claim, which makes it the cheapest proxy for “would this survive reconciliation”.

4. Review currency - 15 points

Derived directly from G2’s published rules.

Score	Condition
15	10+ approved reviews, median age under 90 days, and segment-qualifying reviews if you target a segment.
8	10+ reviews but a median age over 90 days.
0	Fewer than 10 approved reviews.

Recency weighting means a stalled review flow is a ranking problem, not just a social-proof problem.

5. Integration and directory listings - 15 points

Score 3 points per item met, counted across all directories combined and capped at 15:

• A claimed listing (not merely submitted)
• A current, integration-specific description that passes the platform’s naming and description rules
• A live, public setup documentation link
• Listing pricing that matches your own published pricing
• Evidence of real usage that clears the platform’s threshold

The usage thresholds are published, which removes the guesswork. Per HubSpot’s listing requirements, a listing needs “at least three active, unique installs”, defined as successful app activity within the past 30 days from unaffiliated production accounts. HubSpot also requires that “the pricing plan in the listing must match the pricing information published on your website” - a rule that makes price staleness a listing defect, not just an SEO one. Zapier requires documentation “covering all API endpoints” and rejects superlative descriptions.

Because the cap binds quickly, clearing all five items in two directories that matter to your buyers is effectively what full marks require. One perfect listing is a rounding error.

6. Machine legibility - 10 points

Score	Condition
10	Pricing, integrations, deployment model, and security/compliance facts stated in crawlable text under descriptive headings.
5	Facts present but behind tabs, collapsed sections, or in images.
0	Core facts only in PDFs or gated behind a form.

Microsoft’s AI search guidance warns specifically against hiding key information in tabs or expandable menus because “AI systems may not render hidden content”, and against relying on PDFs for core information since they “often lack the structured signals (like headings and metadata) that HTML provides.”

7. Measurement - 10 points

Score	Condition
10	You run a fixed, repeated prompt panel across assistants with recorded results and a change log.
5	Ad-hoc checking, no baseline.
0	No measurement.

Full marks here are achievable today even though native tools are incomplete. See the measurement section below for why you can’t outsource this.

Reading the total

Band	Score	What it actually means
Blocked	0–34	You cannot be recommended. Fix dimension 1 first; nothing else matters until you are reachable.
Findable	35–59	Eligible and findable. You are losing at reconciliation - dimensions 3 or 5 are almost certainly the gap.
Shortlist-capable	60–79	You survive shortlisting when your category is queried. Losing on segment or freshness cuts.
Defensible	80–100	You survive shortlisting and validation, which is where Gartner’s 69% figure bites: reps are still asked to confirm what the assistant produced.

Directory mechanics: the copy rules your competitors already follow

There’s a free diagnostic hiding in the integration-directory documentation, and it’s more useful than most paid tools in this category. Read the listing requirements of two or three directories your buyers use and check your own listings against them literally.

The rules converge remarkably tightly across platforms, and the convergence itself is informative:

• Name: exact core branding, no trademark suffix, no generic type words (Zapier), no marketing keywords (G2).
• Description: one definitional sentence in the form “Name is a…”, no superlatives, no mention of the host platform, integration-specific rather than general product copy (Zapier and HubSpot, independently).
• Documentation: a live, public, integration-specific setup guide is a mandatory field (HubSpot); comprehensive current API documentation is a publication requirement (Zapier).
• Pricing: must match your own published pricing (HubSpot).
• Proof of use: minimum real installs (HubSpot: three active unique installs).

Each item tells a machine what your product does and whether it works. The directory needs that information to evaluate your listing. The retrieval system needs it to match your product to a buyer’s question. You’re answering both with the same work.

One consequence deserves emphasis: these directories verify their claims. HubSpot states that listing URLs “will be verified using HubSpot’s SEO tools to crawl pages associated with the listing”, and asks vendors to allowlist the HubSpot crawler user agent. Your listing is only as good as the pages it points at, which makes directory listings a forcing function for documentation quality rather than a separate chore.

Documentation as a retrieval surface

Documentation gets treated as a support cost centre. It’s actually one of your best- structured surfaces for retrieval, and three published sources say so.

OpenAI’s documentation for its research tooling shows that a web search action can be search, open_page, or find_in_page. A find_in_page step means the system is attempting to locate a specific passage within a document it already fetched. Whether that succeeds depends heavily on how the document is organised: whether the fact sits under a heading that names the thing being searched for, rather than buried in a paragraph that happens to contain the word.

Microsoft’s guidance converges from a different direction: “Clear headings, tables, and FAQ sections help surface key information and make content easier for AI systems to reference accurately.” Bing’s AI Performance tool documentation adds that pages cited for particular grounding phrases “often reflect clear subject focus and domain expertise”.

Zapier, of all things, makes documentation a hard publication gate - APIs must have “clear, accurate, up-to-date documentation covering all API endpoints”, with links supplied in the publishing submission.

The practical list for a B2B SaaS documentation set isn’t long. One page per buyer-named job, titled with the buyer’s words. One integration page per connector, stating what syncs and in which direction. One page stating deployment model, supported environments, and what “does not work yet”. One page stating security and compliance facts in plain text. Each under headings that name the thing rather than the company’s internal name for it.

The vendor contradiction you have to plan around

Google and Microsoft publish directly conflicting guidance on how content should be structured for AI systems.

Microsoft says, in its AI search inclusion guidance, that assistants parse content “into smaller, structured pieces that can be evaluated for authority and relevance”, which are then “assembled into answers”, and therefore recommends Q&A blocks, bulleted lists, comparison tables, concise self-contained sentences, simple punctuation, and specific caution about overusing em dashes.

Google says the opposite in its AI optimization guide. Under “chunking” content: “There’s no requirement to break your content into tiny pieces for AI to better understand it. Google systems are able to understand the nuance of multiple topics on a page and show the relevant piece to users.” Under rewriting: “You don’t need to write in a specific way just for AI systems.” Under structured data: “Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add.”

These aren’t reconcilable as a single “AI writing style”. A page optimised for both must be good prose with clean descriptive headings, and it shouldn’t be contorted into either extreme.

What survives the conflict is the intersection, and it’s smaller than either document alone suggests: accurate, specific, self-contained claims, under headings that describe the subject, with the important facts in crawlable text. Both vendors’ guidance agrees on that much. Everything else is vendor-specific, and if you optimise for one you may be neutralising yourself on the other.

A related conflict is worth naming explicitly because it’s actively marketed to you. The llms.txt specification describes itself as v2, claims that “thousands of sites publish an llms.txt file”, and asserts that “Chrome’s Lighthouse audits sites for one as part of its agentic browsing checks”. Google’s AI optimization guide addresses it under the heading of things you can ignore: “You don’t need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn’t use them.”

For Google Search, the vendor that publishes the AI optimisation guidance has stated plainly that it doesn’t use it. If someone is selling you an llms.txt package as an AI search requirement, that’s a verifiable claim they should be able to source, and they can’t.

The same “ignore it” list from Google includes pursuing inauthentic mentions, chunking, AI- only rewriting, and special schema. If your current plan rests on several of those, it’s worth re-reading the source list.

Testing the way your buyer actually asks

Most prompt testing is theatre. It uses your homepage headline as the query, which is a query your homepage was written to match, and then reports that you did well.

The mechanics above imply a different protocol.

Generate the fan-out yourself. Take your worksheet’s verbatim buyer sentences and write the selection-shaped version of each one. For every problem-shaped phrase, produce the “best X for Y” and “X alternatives” variants. Google’s own worked example goes from a how-to question to “best herbicides for lawns” in one step; do it deliberately.

Run the persona set. One query per persona row on the worksheet, with the dimensions that persona would supply. The economic buyer’s query and the security reviewer’s query shouldn’t return the same list, and if yours do, you aren’t testing two personas.

Run multi-turn, not just single-turn. Bing documents that Copilot Search results carry clickable related topics that support exploration “without losing context in a multi-turn experience”. The realistic B2B path is a first question, a follow-up narrowing by company size or budget, and a third question about a risk. A single-turn test misses the turn where a product is usually eliminated.

Record the sources, not just the presence of your name. The useful output is which URLs appear alongside you. Those URLs are your actual competitive set in the retrieval layer, and they’re almost never the competitors your sales team names.

Log the negative results. Absence is the signal that matters most, and it’s the thing teams discard. When a prompt you should win returns three other names, the useful question is which of the three layers those names are strong in that you aren’t.

What you can and cannot measure

Native tooling has improved substantially and is still incomplete. Being clear about the edges is what keeps you from making bad decisions off it.

Google. The Generative AI performance report in Search Console rolled out worldwide as of 31 August 2026 and reports impressions in AI Overviews and AI Mode, with dimensions for pages, countries, dates and devices. Three limits matter. It reports impressions, not clicks. It’s hidden entirely when a site “hasn’t received enough impressions in generative AI features”, which describes most B2B SaaS sites at any given moment. And it doesn’t expose the queries that triggered appearance - the documented dimensions don’t include them. Separately, Google’s AI features documentation notes that AI feature traffic is reported “within the ‘Web’ search type” in the Performance report rather than separately.

Bing. AI Performance in Bing Webmaster Tools is more revealing in one specific way: it exposes Grounding queries, described as “the key phrases the AI used when retrieving content that was referenced in AI-generated answers”. It’s also refreshingly honest about limits - the post repeatedly disclaims that these figures “do not indicate ranking, authority, or the role of any page within an individual answer”, and that citation counts reflect “how often pages are cited, not page importance, ranking, or placement”. Microsoft is telling you not to over-read its own dashboard, which is a good sign.

The practical conclusion: native tools tell you whether you’re being surfaced and which pages are working. They won’t tell you why. The prompt panel remains the only way to close that gap, and Bing’s Grounding queries are the best available hint at what a promising general panel should look like.

What goes wrong

Optimising the homepage for a query that’s never issued. Fan-out means the selection- shaped query, not your brand or headline, is what retrieves you.

Describing by vertical. G2 files by features, explicitly not by use. If your category argument was about your industry rather than your feature set, the placement is wrong.

Treating a large, stale review base as an asset. Recency weighting means forty reviews with a fourteen-month median loses to twelve fresh ones.

Buying listicle placements as a volume play. Google’s guidance names mass-produced, network-distributed content as a liability, and says review content builds trust only when the testing method is disclosed. If you buy placement without controlling whether the method is disclosed, you have paid for something that may not survive scrutiny.

Treating llms.txt, chunking or special schema as requirements. Google says it doesn’t use the first and needs neither of the other two. Optimise to one vendor’s structural theory and you may neutralise yourself on the others.

Confusing structured data for AI answers. Google supports SoftwareApplication markup, requiring name, offers.price and one of aggregateRating or review. That’s for classic Search rich results. The same vendor’s AI guide says structured data “isn’t required for generative AI search”. Don’t spend a quarter on schema and assume AI citation followed.

Chasing measurement before eligibility. If any crawler is blocked, no metric tells you anything. Fix dimension 1 of the rubric first.

Over-reading native dashboards. Bing explicitly disclaims that its citation figures indicate ranking or importance. If a chart can’t answer a question you care about, it probably isn’t measuring the thing you want.

A 90-day sequence

Days 1–15 - eligibility and diagnosis. Verify every search crawler in robots.txt and past the CDN/WAF. Confirm your Search Console generative AI features status. Fill in the positioning worksheet with real transcripts. Score the rubric and find your lowest dimension. Don’t start content work in this window; the diagnosis has to land first.

Days 16–40 - layer one and layer two. Fix category placement against the actual feature requirements, and claim your profile if you haven’t. Rewrite the definitional pages against the “Name is a…” convention: function first, audience second, pricing and deployment stated in text. Audit where pricing, integration and security facts live and pull them out of tabs, images and PDFs.

Days 41–65 - layer three, deliberately. Build the documentation set your worksheet rows demand. Then go after three to five independent sources with a stated method - review platforms, integration directories, analyst evaluations, substantive community discussion. Track review flow against the 10-review and recency thresholds. Fix the pricing-match rule in every directory listing you occupy.

Days 66–90 - measure and iterate. Stand up the prompt panel: worksheet sentences, selection-shaped fan-out variants, one query per persona, multi-turn sequences. Record sources alongside names. Use Bing’s Grounding queries as a reference point for phrasing. Re-score the rubric quarterly and fix the lowest dimension, not the easiest one.

Sources and References

• Google’s Guide to Optimizing for Generative AI Features on Google Search - last updated 2026-07-10
• AI Features and Your Website | Google Search Central - last updated 2025-12-10
• Creating Helpful, Reliable, People-First Content | Google Search Central - last updated 2026-10-05
• Software app (SoftwareApplication) structured data | Google Search Central - last updated 2026-09-08
• Generative AI performance report | Search Console Help
• Searching the web with ChatGPT | OpenAI Help Center
• Overview of OpenAI Crawlers | OpenAI Platform Docs
• Deep research | OpenAI API Docs
• Perplexity Crawlers | Perplexity Docs
• Does Anthropic crawl data from the web? | Anthropic Support - dated 2026-04-07
• G2 Research Categorization Methodology
• Anatomy of a category | G2 Quick Start Guide
• Finding or listing a product on G2 | G2 Documentation
• Integration publishing requirements | Zapier Developer Docs
• App listing requirements in the HubSpot Marketplace - last modified 2026-10-15
• Introducing AI Performance in Bing Webmaster Tools | Bing Webmaster Blog
• Optimizing Your Content for Inclusion in AI Search Answers | Microsoft Ads
• Introducing Copilot Search in Bing | Bing Blog
• Gartner Survey Finds 69% of B2B Buyers Turn to Sales Reps to Validate AI-Generated Insights - 2026-05-20, n=645, fieldwork Aug–Sep 2025
• The Jobs to be Done Framework Explained | Harvard Business School Online - updated 2026-05-19
• IndexNow Documentation
• The /llms.txt file, v2 - community proposal; cited only to report the conflict with Google’s stated position