Last week’s post made the case that your site is the source AI cites when someone asks about your category. The question that follows is implementation: what actually makes a site citeable, and what should you change first?
The short version: most of it is hygiene you already know. Semantic HTML, schema markup, fast static rendering, fresh dates, one clear answer per page. If your site is already doing modern SEO and accessibility well, you are 60 to 80 percent of the way there. The remaining work is small, mechanical, and high-leverage. The compounded payoff is wider every year, because AI Overviews now cite roughly twice as many sources per response as they did in 2024. The citation pool got bigger. The work to get into it did not.
What “citeable” means in practice
Before the changes, the bar. An assistant cites a page when it can do five things:
- Discover the page (sitemap, internal links, indexable HTML).
- Parse the page (semantic HTML, content rendered server-side).
- Extract the answer (clear heading hierarchy, direct answers in the body).
- Trust the source (schema markup, fresh dates, authoritative backlinks).
- Cite the source (canonical URLs, attribution-friendly metadata).
Each of those is one of the work areas below. If your site fails on any of them, that is where to start.
Schema markup is no longer optional: generative engine optimization in practice
The single highest-leverage area. Schema.org markup gives an assistant the metadata to cite confidently. Most sites ship only basic Open Graph tags, which is enough for social previews and well below what AI citation rewards.
The types that earn their place on most sites:
- Organization. Who you are, what you do, where you operate. One per site.
- Person. For authors, founders, named experts. Pairs with Organization for trust signals.
- BlogPosting or Article. Author, publisher,
datePublished,dateModified,mainEntityOfPage. One per post. - FAQPage. Only where the page genuinely is a Q&A. Google fully deprecated FAQ rich results in May 2026, so the markup no longer changes how you appear in Google Search. It still helps AI agents extract structured questions and answers, which is now the reason to keep it.
- BreadcrumbList. Navigation context. Helps agents understand site hierarchy.
- Product or Service. When the page describes an offering with concrete attributes (price, availability, scope).
A minimal BlogPosting object looks like this:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to Make Your Site Citeable by AI",
"datePublished": "2026-05-12",
"dateModified": "2026-05-12",
"author": { "@type": "Person", "name": "Brian Morrison" },
"publisher": {
"@type": "Organization",
"name": "BAM Web Dev",
"logo": { "@type": "ImageObject", "url": "https://bamwebdev.com/favicon.svg" }
},
"mainEntityOfPage": "https://bamwebdev.com/blog/make-your-site-citeable-by-ai"
}
</script>We ship Organization, Person, BlogPosting, FAQPage, and BreadcrumbList on every build. The work is one-time, the lift is structural, and validation is mechanical: paste a URL into Google’s Rich Results Test or schema.org’s validator and the errors are obvious. Schema is the difference between an assistant guessing what your page is about and being told.
Semantic HTML still wins
The work that ages best. Agents read the same DOM screen readers do. A page with proper structure is parseable. A page that wraps everything in <div> and renders content with JavaScript often is not.
The minimum bar:
- One H1 per page that matches the page’s primary intent.
- H2 and H3 hierarchy that mirrors the content structure. Don’t skip levels.
- Semantic landmarks:
<header>,<nav>,<main>,<article>,<section>,<aside>,<footer>. - Lists where things are lists. Tables where data is tabular. Not the other way around.
- Descriptive alt text on meaningful images.
alt=""on decorative ones. - Descriptive link text. “Click here” tells an agent nothing about the destination.
The hard test: can an agent extract your page’s answer from the rendered HTML without running JavaScript? If your site is a single-page app that hydrates content client-side, the answer is often no. The fix is server-side rendering or static generation. This is where Build crosses into Monitor: if the architecture doesn’t pre-render, no amount of schema fixes the problem. Overlay widgets that promise to bolt accessibility on top of a broken DOM fail agents the same way they fail screen readers, and for the same reason.
The overlap with accessibility is direct. Automated tools catch about 30% of WCAG issues; the remaining 70% surface only through manual review. The same proportion holds for AI parsing. The page that fails for a screen reader usually fails for an agent on the same code.
llms.txt and AI-agent robots rules
The emerging-conventions section, honestly framed. As of May 2026 the picture is mixed.
llms.txt is a proposed standard: a markdown file at /llms.txt that tells AI agents what your site is, how it’s organized, and where to find canonical content. Major AI platforms have not formally committed to reading it, and server-log data shows GPTBot fetches it occasionally while most other crawlers ignore it. The developer-tools ecosystem (Cursor, GitHub Copilot, RAG frameworks, and a growing list of dev-tool companies including Stripe, Cloudflare, and Vercel) does read it. Cost to ship is roughly an hour. There is no downside to having one if the standard catches on.
robots.txt for AI crawlers is the more consequential decision. The user-agents to know are GPTBot (OpenAI), ClaudeBot (Anthropic), Google-Extended, PerplexityBot, and CCBot (Common Crawl). The decision is allow versus block. For most B2B and small-business sites, the right answer is allow. Visibility in AI answers is the goal. Blocking is appropriate for proprietary content or sites where scraping is a real cost. Make the call deliberately, not by accepting whatever a CDN preset shipped you.
Performance and freshness still compound
Two boring inputs that keep mattering.
Static-first rendering. Pages pre-rendered at build time. Agents see the full HTML on first request. We use Astro for this site because it ships zero JavaScript by default. The same logic applies to any pre-rendered output regardless of framework.
Fast TTFB and rendered HTML. Performance is a ranking input for traditional engines and a parsing input for AI agents. Slow sites get partial extraction or skipped entirely. Even a 100-millisecond load-time delay can cut conversions by about 7%, and slow load times hurt your standing with the agents deciding which sources to cite. That’s the load-time half of performance; the interaction half is its own Core Web Vital now, which we cover in INP is the new Core Web Vital.
Freshness signals. datePublished and dateModified in schema. Visible publish dates on posts. Recent content in feeds and indexes. Stale sites get demoted across all engines, AI included.
One clear answer per page
The most-overlooked technical SEO mistake is also the worst one for AI citation: pages that try to be a hub for five topics rarely rank for any of them and rarely get cited for any of them either.
- One question per page. The H1 names the question or topic.
- The answer appears early. Don’t bury the lede. Agents prioritize content above the fold and in the first few paragraphs.
- Heading structure flags the answer. H2s split the question into sub-questions; H3s go deeper. The hierarchy is the table of contents.
- Internal links to related pages. Don’t try to cover everything in one place; link to the deeper content.
This is also good UX. A page that answers one question well converts better than one that tries to answer ten.
Where most sites are failing
A scannable list of the highest-leverage gaps we see in audits. Each item is a thing you can check on your own site in five minutes.
- Schema limited to Open Graph tags, no JSON-LD.
- Multiple H1s or skipped heading levels.
- JavaScript-dependent content that doesn’t pre-render.
- Missing or stale
datePublishedanddateModified. - No
llms.txtand no AI-specific robots rules, allow or block. - Generic image alt text (“image,” “photo,” filenames).
- Canonical URL conflicts across versions of the same page.
- Pages trying to answer five questions instead of one.
Most sites have three or four of these. Fixing them is mechanical work measured in days, not weeks. The audit itself takes an afternoon. This is the work Monitor exists to do on an ongoing basis: structured data validation, indexing health, and visibility checks against the engines (AI ones included) that decide who gets cited.
When this is worth doing yourself
Most of this is a checklist a competent dev finishes in a week. Do it yourself if the site is small, the stack is modern (static or server-rendered), and you have someone comfortable with semantic HTML and JSON-LD.
Bring in help if the site is a client-rendered SPA that doesn’t pre-render, the schema work is substantial (multi-language, multi-region, e-commerce with complex product data), or the audit surfaces structural problems: broken heading hierarchy, performance bottlenecks at the framework level, indexing conflicts you can’t trace. The complex 10% is where outside help earns its keep.
The principle
AI citation isn’t a new discipline. It is the same hygiene that’s been good practice for SEO and accessibility for years, applied with one new lens: the rendered HTML has to carry the answer. The lift is small if you are already doing the work. The cost compounds if you are not.
That covers getting cited. Whether it is actually working is harder to see, because most analytics can’t track AI referrals yet. Here’s how to measure it.
If you want a read on where your site stands and what the gap looks like, tell us what you’ve got.