Both are straightforward to automate and neither is likely to move your citations. Our corpus here is every source cited by ChatGPT, Perplexity, Gemini and Google AI Overviews when answering 130 buyer questions about AI visibility tools, so "most-cited pages" means most-cited in that category rather than on the web at large. Checking the 40 most-cited of them on 11 August 2026: the 29 carrying JSON-LD averaged 118.3 citations against 121.3 for the 11 without it. We ran the same test on llms.txt across the 50 most-cited domains and found no effect there either. So automate them because they are cheap to keep correct, not because they are a visibility lever. The mechanism for doing that without a backlog ticket is three steps, and it is under "How do I ship these without a backlog ticket?" below.
We sell the thing that generates and ships these fixes, which is exactly why this needs saying plainly rather than being left for a buyer to discover.
Both datasets are published, including the per-page rows.
Does schema markup correlate with being cited?
Not detectably.

| markup | pages with | mean citations | pages without | mean citations |
|---|---|---|---|---|
| Any JSON-LD | 29 | 118.3 | 11 | 121.3 |
| FAQPage specifically | 16 | 112.4 | 24 | 123.6 |
The medians are where this gets more honest rather than less. For JSON-LD they say the same as the means, 107 against 111. For FAQPage they say the opposite: 110.5 for pages with it against 106.5 for pages without. Mean says negative, median says positive, on 16 and 24 pages.
That disagreement is the actual result. It is not a small negative effect and it is not a small positive one, it is what no effect looks like when a handful of large values pull an average around. We nearly published only the JSON-LD medians, which would have made the picture look tidier than it is.
On the wider evidence, we should be careful about claiming agreement too. We checked 615 pages for FAQ schema and could not establish an effect, though that test's raw figure ran mildly positive before deduplication removed the significance. SE Ranking, across roughly 216,000 pages, reported FAQ schema as slightly negative. So three measurements agree that no effect has been demonstrated, and they do not agree on a direction.
Then why automate it at all?
Because the case for structured data was never citations, and the honest case still stands.
Schema describes your page to anything parsing it. It drives rich results in ordinary search, it is how a machine reader knows your pricing page states a price, and it degrades quietly when someone edits a template. Those are real reasons, and none of them require it to influence an AI engine's retrieval.
The same is true of llms.txt. It is a reasonable place to state canonical descriptions and link your important pages. What it is not, on our measurement of the 50 most-cited domains, is something that correlates with being cited.
The distinction matters because it changes where the work sits in your priority list, not whether it happens. These belong in the maintenance bucket, done once and kept correct automatically. They do not belong at the top of a visibility plan.
How do I ship these without a backlog ticket?
Generate the change as a diff, not as advice, and route it through the same review your other code gets.
The pattern that works is: detect the gap, produce the actual file or the actual JSON-LD block, open a pull request against the repo, and let a human approve it. That last step is the one people are tempted to drop and the one that keeps this safe, because an agent writing structured data unsupervised will eventually describe a page as something it is not.
A coding agent in the editor handles this well because the change is small, local and reviewable. Claude Code and Cursor both work for this, and the mechanism is the same either way: the agent receives the fix as a directive, writes it into the repo and opens the pull request. llms.txt is one file. A schema block is a few dozen lines in a template. Neither needs a sprint, which is precisely why neither should sit in a backlog for a quarter.
This is the part GetIntel does, and the precise division of labour matters. GetIntel drafts the fix and hands your own coding agent, Claude Code or Cursor over MCP, a grounded directive. Your agent is what writes to the repository and opens the pull request; we never touch your repo. Worth being clear about what that buys too: it removes the friction, not the uncertainty about whether the fix helps.
One accuracy note about our own product, since this article is partly about it. Only llms.txt currently goes through that directive-to-agent path. Schema fixes are generated as a paste-ready snippet you apply yourself, which is a meaningfully smaller claim than the one the section above might imply.
What should I check before merging a generated fix?
Four things, and the third is where automated schema most often goes wrong.
- That the markup matches the page. A FAQPage block whose questions do not appear in the visible content is a misrepresentation, and it is the easiest thing for a generator to get wrong.
- That it validates. Malformed JSON-LD is worse than none because it can invalidate a whole block.
- That it does not duplicate what your framework already emits. Most site generators already produce some structured data, and a second conflicting block is a common and silent failure.
- That llms.txt does not contradict your robots.txt. Pointing an agent at pages you have asked crawlers not to fetch is a mixed signal you do not want to send.
What should I do with the time this frees up?
Work on the things our measurements do point at, in preference to the things they do not.
Being present on the specific questions your buyers ask is the one that keeps showing up: 24 of our 60 tracked prompts name us and the pages earning those citations are the ones that answer a tracked question directly. Getting into the sources engines already cite is the other, and in our category that means forums and repositories far more often than vendor pages.
Neither is as satisfying as shipping a file. Both have more evidence behind them than either fix in this article.
What don't these tests rule out?
Forty pages and fifty domains rule out a large effect, not a small one. If structured data lifts citations by a couple of percent, this measurement would look exactly as it does.
We tested presence, not quality. Every page carrying JSON-LD counted the same whether its markup was careful or auto-generated nonsense, and it is entirely possible that good markup helps while bad markup hurts, and that the two cancel in an average like this one.
Both tests are correlational and the sample is our own category, which is unusually saturated with vendors who all do the same optimisations. A category where structured data is rare might show something different.
And we fetched pages as an ordinary browser. Anything served only to a named AI crawler would not have been seen.
