Letting the crawlers in is the easy half. Plenty of sites with a perfect robots.txt still never get cited, because an answer engine does not quote a page. It retrieves a passage, and then decides whether that passage can stand on its own in front of a reader who never saw the rest of your site.
1. The content has to exist before JavaScript runs
Some crawlers execute JavaScript. Many do not, and the ones that do give it a lower priority and a smaller budget. If your page ships an empty div and fills it on the client, a meaningful share of retrieval traffic sees the empty div.
Test it the way a crawler sees it. Fetch the raw HTML and look for your actual text:
curl -s https://example.com/your-page | grep -c "a distinctive sentence from your page"If that returns 0, your content is invisible to anything that does not run a browser. Server rendering or static generation fixes it. This is the single highest-leverage change on the list because it gates everything else.
2. Paragraphs have to survive being extracted alone
Retrieval pulls a chunk. That chunk arrives without the heading above it, without the sentence before it, and without the page title. A paragraph that opens with "This means you should..." is useless on its own, because the antecedent stayed behind.
Write so each paragraph names its subject. Compare:
- →Weak: "It costs $20 per month and includes unlimited seats." Retrieved alone, nobody knows what it is.
- →Strong: "The Pro plan costs $20 per month and includes unlimited seats." Retrieved alone, it still answers a question.
The same rule applies to the sentence directly under each heading. If a heading asks a question, answer it in the first sentence below, in full, before you add context. That one habit does more for retrievability than any markup.
3. Schema has to be the kind that can be quoted
Almost every site has JSON-LD now, and almost all of it is Organization, WebSite and BreadcrumbList. That markup is valid, it parses, and it tells an answer engine nothing about your content. It describes the container.
The types that change what an assistant can do with your page are the ones that carry an answer inside them:
| Type | Use it when | What it enables |
|---|---|---|
| FAQPage | A page answers discrete questions | Question and answer pairs lift straight into responses |
| HowTo | A page gives ordered steps | Steps get reproduced in order, with your attribution |
| Article / BlogPosting | Editorial content | Author, publish date and body get parsed reliably |
| Product with Offer | A page sells something | Price and availability answer buying questions |
| TechArticle | Developer documentation | Signals depth and technical scope |
A useful check: if your only schema types are Organization, WebSite and BreadcrumbList, you have valid markup and zero quotable markup. That distinction is worth points in our score and, more importantly, worth citations.
4. The page has to say when it was last updated
Answer engines prefer recent sources, and they need a signal to know what recent means. A page with no date is not treated as fresh. It is treated as unknown, which in practice ranks below dated content of the same age.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "What makes a page quotable",
"datePublished": "2026-08-16",
"dateModified": "2026-08-16"
}
</script>A visible "Last updated" line in the page body helps too, and it helps human readers, which is the better reason to add it. Keep dateModified honest. Bumping it on every deploy without changing anything trains nobody to trust it and eventually gets ignored.
The order to do this in
Server rendering first, because nothing downstream matters if the content is not there. Self-contained paragraphs second, because it is the change that most improves what gets retrieved and it costs nothing but attention. Quotable schema third. Dates last, because they are a ten-minute job you can do any time.
Our check scores all four across every page it analyzes, so you can see which sections of your site clear the bar and which do not. Usually the homepage is fine and the documentation is not.