Get Cited by AI: Fix These Six Page-Level Problems

What “get cited by ai” actually requires at the page level

To get cited by AI, a page needs three things at once: a passage that makes sense on its own, structured data that matches what’s actually written, and clear enough attribution that the lifted quote can be traced back to you. Most teams check the middle one — add FAQPage schema, tick the box — and skip the other two, then wonder why an assistant still reaches for a competitor’s page or a third-party review instead. Crawler access and site-wide technical health matter too, but they’re a precondition, not the cause of most misses we see: a page that’s fetched regularly and still never quoted almost always fails on how the passage itself is written, not on whether a bot could reach it.

This is the page-level craft, not the crawler-access settings — those are a separate, earlier layer of work. Here, the assumption is that your site is already reachable and your product feeds are basically sound. The question is narrower and more specific: given a page a model can already fetch, why does the passage inside it fail to get lifted into an answer, and in what order should you go looking for the reason.

Who this applies to, and who should fix something else first

This is written for teams running $3M-$30M in revenue on Shopify Plus or a comparable paid subscription platform, with a product or content team that can edit templates rather than single pages by hand, and a catalogue large enough that a one-page fix doesn’t move anything meaningful. If your site isn’t reliably crawlable yet, or your product data disagrees with itself across pages and feeds, that’s the more urgent problem — page-level extractability work on top of an unreliable foundation just produces a well-written passage a model still won’t trust.

It’s also not for a single landing page you’re trying to get cited once. The six causes below are about patterns across a template, because fixing one page’s wording rarely changes the odds for the four thousand pages built from the same template with the same underlying problem.

The six reasons a page doesn’t get cited, in the order we’d check them

Read this table as a diagnostic order, not a severity ranking — check cause one first because it’s the most common reason we see a fetchable, well-marked-up page still get skipped, then work down the list only if the earlier ones check out clean.

Cause 1: The passage can’t stand alone

This is the single most common reason a page that’s clearly being crawled still never gets quoted. Look at a typical product FAQ answer: “It comes in three sizes and ships within that window too.” Read alone, “it” and “that window” refer to nothing — the sentence only means something once you already know the subject from a sentence written earlier in the same block. A model extracting a candidate passage to quote has to either pull the surrounding context along with it, which makes for an awkward, half-formed answer, or skip the passage entirely and look for a source that states the same fact cleanly on its own.

The fix is mechanical once you see it: name the subject and restate the qualifier in the sentence itself. “The Aria jacket comes in three sizes, ships within 3-5 business days” carries everything a model needs without anything above or below it. This matters most in FAQ answers, spec summaries and any block written to directly answer a named question — the passages most likely to be lifted whole are exactly the ones where this failure is most common, because they were written as continuations of a conversation rather than standalone statements.

Cause 2: Structured data is missing, incomplete or contradicts the page

FAQPage and Product schema tell a model what a block of content claims to be, which lowers the friction of using it. When that markup is missing entirely, a model has to infer structure from formatting alone, which works less reliably than reading a field marked answer or price directly. When it’s present but wrong — an availability field left as “in stock” after a product sells out, an FAQ answer in the schema that doesn’t match the visible text on the page — it’s worse than missing, because a model that catches the mismatch has a concrete reason to distrust the page rather than just skip it.

Check this by comparing your schema output against the rendered page side by side, not by trusting that the template was built correctly once and never drifted. A recurring cause of drift is an app installed later — a reviews widget, an upsell tool, a personalisation script — that injects its own schema block without checking whether one already exists, leaving two conflicting sets of structured data on the same page.

Cause 3: There’s no clear attribution to trace the passage back to you

A fact with no stated source is harder for a model to confidently cite, because citing it well means being able to say where it came from. A brand name mentioned once at the top of a page, an author or organisation named near the content, and a stable canonical URL all give a model something concrete to attribute a lifted passage to. Pages that read as anonymous boilerplate — no brand name in the body text, no author byline, a URL that changes on every deploy — are technically citable but harder to cite with confidence, and a model choosing between two otherwise similar sources tends to prefer the one it can attribute cleanly.

This is inconsistent across most catalogues we’ve looked at: blog content usually carries a byline and an organisation name because that’s a standard CMS field, while product pages generated from a feed often carry neither, because nobody thought of a product description as needing one. The fix is template-level, not page-level — add the brand name and a stable identifier to the product page template once, and it propagates across the whole catalogue.

Multi-brand or multi-region operations add a further wrinkle: if the same product content is republished under more than one storefront name, decide which one is the canonical attribution and say so consistently, rather than letting each storefront claim the same passage under a different brand name. A model that finds the same sentence attributed to two different organisations has no clean way to resolve which one is the real source, and the safer response is often to attribute the fact to neither.

Cause 4: The answer is buried under everything else

Even a well-written, well-marked-up answer loses value if it sits below several paragraphs of brand story, trust badges and cross-sell blocks before the actual fact appears. A model extracting a passage tends to favour whatever answers the question most directly and most quickly on the page, not the technically correct answer that happens to be positioned last. A shipping FAQ that opens with two paragraphs about sustainability commitments before stating the delivery window buries the one sentence a customer actually asked for.

This doesn’t mean cutting the brand content — it means sequencing it. State the direct answer first, in the first sentence under the heading, then add supporting context and caveats afterward. This also serves a human reader scanning the page, which is a reasonable check on whether the fix is right: if a person skimming the page would also prefer the answer up front, the change is good for both audiences at once, not a compromise made for a crawler.

Cause 5: Facts conflict across your own pages

A model weighing two sources on your own domain that disagree — a price on the product page that doesn’t match the price in your shopping feed, a spec sheet that lists a different weight than the FAQ answer — has no reliable way to know which one is current. The safer move for it is often to prefer neither, and reach for a third-party source that at least agrees internally, even if that source is less current than either of yours. Internal contradiction doesn’t just create one bad answer; it can push a model toward not citing you at all for that fact.

This is easiest to check where a product exists in more than one place: on the storefront page, in a shopping feed, on a marketplace listing you also maintain, and possibly in a printed catalogue’s digital version. Whichever of those updates slowest after a price change or a spec correction is usually where the drift starts, and it’s worth knowing which system that is before assuming your storefront is the single source of truth a model treats it as.

International and multi-currency catalogues make this worse, not better. A product priced in USD on your primary storefront, GBP on a regional subdomain and listed again inside a marketplace app can easily show three different numbers if a currency conversion job runs on three different schedules. A model has no reliable way to know which of those three prices a given customer would actually be charged, and treating the US price as canonical because it’s your primary market doesn’t help a model that has no signal telling it which storefront it’s even looking at. If you run region-specific storefronts, state the currency and region explicitly in the page content itself, not just implied by the domain or subdomain, so a lifted passage carries enough context to stay correct wherever it ends up quoted.

Cause 6: The content isn’t there for a crawler, only for a browser

Content that only renders after JavaScript executes, or that sits behind a click-to-expand accordion loaded on interaction, can be invisible to a crawler that doesn’t fully render the page the way a browser does. This produces a strange, specific symptom: a human visiting the page sees the answer clearly, a Rich Results-style validator that does render JavaScript might even pass, but a text-only fetch of the page shows an empty shell where the FAQ block should be. The difference between what a browser renders and what a basic fetch returns is exactly the gap a crawler that doesn’t execute scripts falls into.

Check this directly: view your page’s raw HTML source, not the rendered DOM shown by a browser’s inspector, and confirm the key facts are actually present in the text that arrives before any script runs. If your FAQ answers only appear after a user clicks to expand them, consider whether the collapsed state still includes the text in the markup, hidden by CSS, rather than the text being absent from the page entirely until the click happens — the first is fine for extraction, the second isn’t.

What this looks like on a Tuesday

Picture a mid-sized apparel brand’s return policy FAQ, sitting on a template used across nine hundred product pages. A support lead updates the policy from thirty days to forty five, edits the FAQ block on the main policy page, and considers the job done. The block on each individual product page, though, pulls a cached summary generated at the last full site build, six weeks earlier, because the product template was never wired to read from the same source as the policy page. For six weeks, an assistant fetching a product page instead of the policy page quotes the old thirty-day window, correctly, because that’s genuinely what the page says. Nobody notices, because the pages still look consistent with each other to a human skimming two or three of them by hand.

This is the ordinary shape cause five takes in practice: not a dramatic contradiction anyone would catch on inspection, but a slow drift between two systems that update on different schedules and were never checked against each other. The fix isn’t a one-time correction to whichever page happens to be wrong today. It’s wiring the product template to pull the policy text from the same source the policy page uses, so there’s structurally only one place the number can live, rather than two places that happen to agree until someone forgets to update both.

How to check whether any of this is actually working

Verification here works in layers, because each cause needs a slightly different check. Start with reachability: confirm from your server logs that AI crawlers are actually fetching the page in question at all, since none of the rest matters if they aren’t. Then check structure: run the page through a structured-data validator and compare what it reports against what’s visible on the page, looking specifically for fields that contradict rather than fields that are merely absent. Then read the passage itself as if it had been pasted into a chat window with nothing else around it — does the sentence carry its own subject, or does it lean on something above it that won’t travel with it.

Finally, ask the assistant the actual question your FAQ answers, across a handful of separate sessions, and see whether any of your own phrasing shows up, quoted or closely paraphrased, and whether it’s attributed to your page or to somewhere else. This won’t produce a stable number — a citation is a sampled result, not a fixed one — but it will tell you, over enough tries, whether you’re in the pool at all. A run of sessions that never surfaces your page, even loosely paraphrased, points back to one of the six causes above rather than to bad luck.

Because this is template-level work, checking a single page only tells you about that page, not about the template it came from. Pull a random sample of ten to fifteen pages built from the same template, not just your best-performing ones, and run the same checks across all of them. A template that passes on your flagship product and fails on a mid-catalogue variant usually means the flagship page was hand-edited outside the template at some point, which tells you the template itself still carries the underlying problem for everything else built from it.

What to fix first if you can only fix one thing

If a template can only get one round of attention this quarter, fix cause one: rewrite the highest-traffic FAQ and spec answers so each one names its own subject and states its own qualifier, with nothing left dangling that depends on the paragraph before it. It’s the cheapest fix on this list, because it’s a copy change rather than a schema or infrastructure change, and it’s the cause we see most often when a page is confirmed reachable, correctly marked up, and still never quoted. The other five causes are worth working through in order after that, but cause one is where a fetchable page most often loses the passage it should have won.

Getting cited by AI at the page level is an AI search visibility problem: the six causes above compound across a catalogue built on one template, so a fix made once at the template layer changes the odds for every page built from it, while a fix made on a single page changes almost nothing at scale. That ongoing, template-level work is what AI search visibility as a category covers.