Rank on ChatGPT: Why Citations Aren't Rankings

Why “rank on ChatGPT” is the wrong question

If you type “rank on ChatGPT” into a search bar, you’re already borrowing a model that doesn’t apply. A Google ranking is a position: page three today, page three tomorrow, movable only through a fixed set of levers a crawler can index and a results page can display. An AI assistant doesn’t hold a position for you. It generates an answer on the spot, drawing on a mix of training data, live retrieval where that’s enabled, and whatever the model decides is relevant to that specific phrasing, in that specific session, at that specific moment. Ask the same question twice and you can get two different answers, with two different brands named, or none at all. There is no page three to climb out of, because there is no fixed page to begin with.

That distinction isn’t a semantic quibble. It changes what you spend engineering time on. Chase “rank on ChatGPT” the way you’d chase a keyword ranking — one canonical page, a target position, a monthly rank check — and you’ll be optimising for a snapshot that was already gone by the time you took it. A Shopify Plus team we’ve watched do exactly this spent a quarter rewriting a single category page for “AI visibility,” checked it against one prompt each Friday, and concluded the work wasn’t paying off when the Friday answer stopped mentioning them. Nothing about the page had regressed. The sample had simply landed somewhere else that week.

What a citation actually is, if not a ranking

A citation is a sample, not a slot. Each time someone asks an assistant a shopping question, the model draws on whatever it has access to for that query — some of it indexed from the web recently, some of it baked into training data, some of it retrieved live if browsing is active — and composes an answer from whatever combination looks most relevant at that moment. Your brand appearing in that answer is closer to a weighted lottery draw than to holding a ranked spot: the weighting shifts with model updates, with how the question is phrased, with what else has been published recently, and with details of the user’s own session that you’ll never see from outside.

Illustrative example: imagine asking the same product question in ten separate sessions, spread across a week. Suppose your brand appears by name in four of the ten answers, a named competitor in three, and no brand at all in the remaining three. A four-in-ten appearance rate isn’t a ranking you hold — it’s a sampling result from that week, with that phrasing, on that model version. Run the same ten questions again the following week, with nothing changed on your end, and you could reasonably see six citations, or two. Nothing about your site moved. The sample did.

This is why a single check — ask the assistant once, see if you’re mentioned, conclude you’re “ranking” or “not ranking” — tells you almost nothing. One draw from a weighted lottery doesn’t tell you the weighting behind it.

What changes between two sessions, and why you can’t fix it directly

Several of the variables that decide a given answer sit entirely outside anything on your site. Model version is one: a provider ships an update, and the same prompt that reliably surfaced you last month reaches for different sources this month, with no announcement you’ll see. Session context is another — a user who has been asking about budget alternatives for the last three turns of a conversation gets a different answer than one who opened with “best premium option,” even if the underlying product question is identical. Whether browsing or live retrieval is even switched on for that mode of the assistant changes the pool of sources available at all; a chat-only response drawing purely on training data behaves differently from one actively fetching current pages.

None of that means the work in this article doesn’t matter. It means the work changes your odds of being in the pool the model draws from, not your position within a list that doesn’t exist. Treat every setting below as improving the chance you’re sampled, not as buying a guaranteed outcome — and be wary of anyone who promises the second thing.

What determines whether you show up, and what doesn’t

Read the two columns together: everything you can influence sits in the “yes” or “indirectly” rows, and the whole strategy in this article lives there. Nothing in the “no” row is worth spending a sprint on, because there’s no setting on your side that touches it.

Who this is for, and who should stop reading here

This is written for teams running $3M-$30M in revenue on Shopify Plus or a comparable paid subscription platform, with a product catalogue large enough that manual, one-off fixes don’t scale, and an engineering resource that can touch robots.txt, structured data and a CDN configuration. If you’re pre-$3M, running on a free or entry-level platform, or don’t have anyone who can edit server configuration, the return on this work is thin. Put the same hours into product data hygiene and a working email programme first, and come back to this once the catalogue and traffic justify the maintenance load.

It’s also not for a team looking for a one-time fix. Every lever in this article drifts — a platform migration, a new CDN rule, a theme update — and nobody notices the drift until a routine check turns up nothing. If there’s no plan to own this past the initial setup, the initial setup won’t hold its value for long.

Before you touch any setting, confirm the basics

Three things have to be true before any of the following steps do anything. First, your site has to be crawlable by a standard bot at all — if Googlebot can’t render your product pages cleanly, an AI crawler can’t either, and the rest of this exercise is moot until that’s fixed. Second, your product data has to be accurate everywhere it’s published, because a model that finds contradictory prices or stock states across your own pages has a structural reason to distrust all of them, not just the one that’s wrong. Third, someone on your team has to own this work on an ongoing basis, because crawler allowlists and schema drift silently after a platform migration, a CDN change or a theme update, and nobody notices until a routine check turns up nothing.

Step 1: Allow the AI crawlers in robots.txt

Most sites’ robots.txt file was written for Googlebot and Bingbot and never touched again. AI assistants that browse the live web use their own user-agents — OpenAI’s GPTBot and OAI-SearchBot, Anthropic’s ClaudeBot, Perplexity’s PerplexityBot, and Amazon’s Amazonbot among them — and a robots.txt file that’s silent on these doesn’t automatically block them, but plenty of bot-management layers sitting in front of your site do. Add explicit Allow: / rules under each crawler’s own User-agent: line, rather than relying on a wildcard rule that was written years ago to mean something it was never asked to cover.

Test what you’ve actually shipped, not what you think you shipped: fetch your own homepage with each crawler’s user-agent string set explicitly and confirm you get a 200 response rather than a 403 from an edge rule that runs before robots.txt is even read. A robots.txt file that correctly allows a crawler is worth nothing if a CDN rule blocks the same user-agent one layer earlier.

Step 2: Publish an llms.txt file at your root

An llms.txt file, placed at yourdomain.com/llms.txt, is a plain-text summary of your site aimed at language models rather than browsers: what you sell, your core pages, and a short description of what each one covers. It’s a proposal with partial support across assistants, not a guaranteed citation mechanism, and no assistant has committed to reading it on every request. Treat it as a cheap, low-risk addition — a few hours to draft and a standing task to keep current — rather than as a lever you can pull expecting to change outcomes on its own.

Keep it short and factual: a one-line description of the business, links to your main category pages, and a note on how to find current pricing and stock. Anything longer starts to duplicate your sitemap without adding anything a model can use differently.

Step 3: Get your product schema right

The fields that matter most for an assistant trying to answer “does this brand sell X and what does it cost” are the core Product schema fields: name, sku, price, priceCurrency, availability, and gtin where you have one. A missing availability field, or a price that hasn’t been updated after a sale ends, is a structural reason a model treats your page as an unreliable source and reaches for a marketplace listing or a third-party review instead. Re-check your product template after any theme or app change — a single app that injects its own script can silently overwrite or duplicate these fields without changing anything visible on the rendered page.

Multi-location and international catalogues add real edge cases here. If you sell the same product at different prices across regions or currencies, make sure each variant has its own correctly scoped schema rather than one block that only reflects your default storefront. If a product genuinely has no GTIN, because it’s private label or made to order, don’t leave the field blank silently — use mpn alongside brand as the identifying pair, or set identifier_exists: false on the equivalent shopping feed line, so a missing GTIN reads as a deliberate choice rather than an error.

Step 4: Treat third-party pages as part of the surface

Your own domain isn’t the only place a model can find you. Reviews, marketplace listings, comparison articles and forum threads are pages you don’t control but do influence: accurate specs and pricing on your own site tend to get copied into secondary sources faster than errors get caught and corrected there. A comparison roundup or a review thread that cites you accurately becomes another place a model can draw from when your own page isn’t the one it reaches for on a given query.

This is where a Princeton study on generative engine optimisation is directly relevant. Techniques that make content easier for a model to extract and quote — clear structure, direct answers stated plainly, accurate attribution — lifted AI visibility by 30–40% in that study. That lift showed up across the kind of third-party and owned pages a model actually cites from, not only on the domain doing the optimising, which is consistent with treating your own site’s clarity as something that pays off beyond your own site too. It’s a study result, not a promise for any specific catalogue, but it’s a reasonable argument for why clean, extractable product pages matter even on pages you’ll never see cited directly.

Step 5: Verify what’s actually happening

Because a citation is sampled, not fixed, verification means running enough trials to see a pattern, not one query and a screenshot. Build a list of ten to twenty real customer questions — the phrasing your support team actually hears, not the phrasing your SEO tool suggests — and run them across multiple separate sessions, ideally spread over more than one day. Log whether your brand or product appears, whether the details quoted are current, and whether the source the model names is your own page or someone else’s.

Alongside that, check your server’s access logs for hits from the GPTBot, ClaudeBot, PerplexityBot and OAI-SearchBot user-agents. If those crawlers aren’t showing up in your logs at all, no amount of schema work downstream will matter, because the page was never fetched in the first place — that’s the precondition every other step in this article assumes is already true. Anyone quoting you a citation rate should show you the method behind it: how many sessions, over what period, with what query set. A single-digit sample dressed up as a percentage is metric to confirm, not a result you can act on.

The step most teams get wrong

The mistake we see most often isn’t a missing schema field — it’s a bot-management setting flipped the wrong way. Plenty of CDN and security platforms ship an option to block known AI crawlers as a default or a one-click toggle, aimed at stopping AI companies from training on a site’s content for free. Turn that on without checking which user-agents it covers, and you can block OAI-SearchBot and PerplexityBot — the crawlers doing live retrieval for answers — at the same time as the training crawlers you meant to stop, while Googlebot sails through untouched on a separate allowlist.

The result looks, from the outside, exactly like a content or optimisation problem: traffic from search is fine, traffic from AI assistants is flat or falling, and nobody thinks to check the bot-management panel because nobody remembers changing it. It’s usually a support ticket from six months ago that nobody closed the loop on — someone asked for “AI bot blocking” to be turned on after a scraping scare, the toggle covered more than intended, and the setting has sat there since. Ask whoever manages your CDN or security layer, by name, whether AI-crawler blocking is switched on, and which specific user-agents it covers. “AI bots” as a single toggle usually bundles several crawlers with different jobs, and turning one off shouldn’t mean turning all of them off by accident either.

What breaks first when nobody owns this

Picture a routine platform migration: URLs move, redirects get set up for the paths Google Search Console flags, and the launch checklist is signed off. Three weeks later, a customer asks an assistant about a specific product and gets an answer built from a cached version of the old URL, because that’s what the model had indexed before the migration and nothing has re-crawled it since. The redirect works fine for a human clicking a stale link. It does nothing for an answer that was generated from content fetched before the redirect existed, on a schedule the model controls, not you.

A ranking model of “rank on ChatGPT” misses this failure entirely, because a ranking problem has a visible symptom: you drop from position four to position nine, and you can watch it happen. A sampling problem has no equivalent visible symptom, since there’s no stable baseline to drop from. The only way to catch this kind of staleness is running the verification checks often enough that a three-week-old cached answer gets noticed before a customer notices it first.

How often should you check this?

There’s no single cadence that fits every catalogue, so pick one that matches how often your underlying data actually changes. If your prices and stock levels update daily, check crawler logs and run your verification query set at least weekly — a stockout that persists in an AI answer for a month because nobody re-asked the question is a worse outcome than the same stockout showing on your own site, where at least your own team would notice it immediately. If your catalogue is stable and changes quarterly, monthly verification is enough, and you can spend the saved time elsewhere.

Either way, this needs a named owner, not a task that lives in a shared document nobody checks. In most teams we’ve seen do this well, it sits with whoever already owns technical SEO, because the crawler-access and structured-data skills overlap almost completely — the AI-crawler work is closer to an extension of that job than a separate discipline requiring a new hire.

Getting cited by ChatGPT instead of ranked by it is an AI search visibility problem, not a one-time technical fix: crawler access, product data accuracy and third-party presence all drift on their own schedule, and none of them stay fixed once you’ve touched them once. That ongoing shape of work is what AI search visibility as a category actually covers, rather than a single project with a defined end date.