Writing pages that answer questions directly

Rules of thumb for pages that search features and AI answers can quote: question headings, short answers, lists and tables, figures, authors, and dates.

Some pages are easy to use when someone arrives with a question. The question is a heading, the answer sits right under it, and the details follow. Steps are a numbered list, prices are written out, and it’s clear who wrote the page and when.

These checks look for those habits. They’re rules of thumb, not requirements, and a page can be excellent without any of them.

What SignalDNS checks

Answer readiness is its own group in the audit. Its suggestions are named in the summary, but never counted as problems. It only runs on English pages: pages whose lang starts with en, or, without a lang, whose title and H1 are plain ASCII. See the lang attribute.

Google says there’s nothing special to do for its AI features. Its page on AI features says the usual SEO best practices still apply, and that there are “no additional requirements” to appear in AI Overviews or AI Mode. Its guide to generative AI search adds that you don’t need to break content into small chunks or write in a special way for AI. So we don’t claim any of these checks improves rankings or the chance of being quoted or cited. They’re here because they make a page quicker to read.

From the HTML, before JavaScript runs, we read:

  • headings from H2 to H6, and the paragraph that comes straight after each one
  • lists (ul and ol) and tables outside navigation, headers, footers, and asides
  • figures in the first 4,000 characters of text
  • the author and publication date, from JSON-LD and meta tags

The page has no question headings

A heading phrased as a question, such as “How long does delivery take?”, tells readers they’re in the right place. It uses their words, so it’s easy to spot when scanning, and it works well as a link in a table of contents.

We count an H2 to H6 as a question when it:

  • ends with a question mark,
  • starts with what, why, how, when, where, who, whom, whose, or which, followed by a verb such as is, can, or does, or by much, many, long, often, far, or soon, or
  • starts with one of those verbs followed by a subject, as in “Can I change my order”, even without a question mark.

“How to bake bread” is a title, not a question, unless it ends with a question mark.

No question headings is a note, not counted: a product page or a home page often doesn’t need them. When the page has some, we report how many and check what comes after them.

How to use them: where a page answers questions people ask, use the question as the heading, in the words they’d use:

<h2>How long does delivery take?</h2>
<p>Orders placed before 2 p.m. ship the same day ...</p>

Google’s guide to generative AI search says people appreciate pages organized into sections, with headings that give a clear structure. Don’t turn every heading into a question, though. A heading should describe what’s under it.

Question headings have no short answer

Under each question heading, we look at the first paragraph, if nothing else comes first: no list, table, or other text. Our rule of thumb is that it should be 25 to 75 words, a complete answer in a few sentences, with the details after it. When fewer than half of the question headings have one, SignalDNS marks it as needing attention, as a suggestion that isn’t counted.

The range is ours, not Google’s. Google gives no minimum length for a featured snippet, says you can’t mark a page as one because its systems choose, and says there’s no ideal page length. The reason for a short first answer is the reader, who gets it without scrolling and can stop there or read on.

Common reasons a heading has no short answer:

  • The answer starts with a list or table. Put one sentence before it that answers the question.
  • The first paragraph is long. Put the answer first and the background after, in a second paragraph.
  • The text isn’t in a paragraph. Text in a div or span instead of a <p> doesn’t count.
  • The answer is “it depends”. Say what it depends on in the first sentence.

How to write one:

<h2>Can I change my order?</h2>
<p>Yes, until it ships. Open the order from the link in your confirmation
email and choose Edit. Orders usually ship within a day, so change it soon.
After it ships, you can return the item instead.</p>

That answer is 36 words.

The page has no lists or tables

Steps, options, and comparisons are easier to follow as a list or a table than as a paragraph. When the page has neither, SignalDNS marks it as needing attention, as a suggestion that isn’t counted. We count ul and ol lists and table elements outside navigation, headers, footers, and asides, so a menu doesn’t count.

Use real HTML: ol for steps in order, ul for items in any order, and a table with header cells for values compared across rows and columns. Lines that start with a dash, or a picture of a table, may look the same, but they aren’t a list or a table to the browser. Assistive technology uses a table’s header markup to give each cell its context, as the W3C’s tables tutorial explains.

<h2>How to return an item</h2>
<ol>
  <li>Open the order from your confirmation email.</li>
  <li>Choose Return and pick a reason.</li>
  <li>Print the label and take the parcel to a drop-off point.</li>
</ol>

Not every page needs one. Don’t break prose into bullet points just to have a list.

Few specific figures near the top

Specific numbers answer questions precisely: “£4.95 delivery, free over £50” says more than “low delivery costs”. We look for figures in the first 4,000 characters of the page’s text: amounts with a currency symbol, numbers with a percentage or a unit such as kg, hours, days, or GB, and large numbers such as 12,000. Three or more is OK, and fewer is a note. It’s never counted.

Use figures where they’re true and useful, such as prices, sizes, opening hours, delivery times, and limits. Keep them current. Write them as text, not only in an image: Google’s AI features guidance lists making important content available as text among its basic best practices.

No author is named

A named author tells readers who wrote the page, so they can judge it. We find one in a <meta name="author"> tag, an author on an Article, NewsArticle, or BlogPosting in JSON-LD, or a Person object anywhere in the page’s JSON-LD. Found is OK. Not found is a note, “Not named” for an article and “Not an article” for other pages, and it’s never counted.

Google’s guidance on helpful content asks whether pages carry a byline where readers would expect one, and encourages accurate authorship information. Its Article markup recommends author, with each author as a separate object with a name, and a url for a page about them. Google’s question is about pages where a byline would be expected, so a pricing page is fine without one.

How to add one: show the byline on the page, and mark it up:

<p>By Jane Doe, head of support</p>
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to return an item",
  "author": [{
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://www.example.com/about/jane-doe"
  }]
}
</script>

The article has no publication date

On an article, a date tells readers how current it is, and Google can show it in results as the byline date. When the page has Article, NewsArticle, or BlogPosting markup without datePublished, and no article:published_time meta tag, SignalDNS marks it as needing attention, as a suggestion that isn’t counted. Other pages get a note, “Not an article”.

Google says it estimates a page’s date from several signals. It recommends a visible date, labelled with words like “Published” or “Last updated”, and datePublished or dateModified in the markup, in ISO 8601 format, with a time zone if you give a time. The visible date and the markup should match, and neither should be in the future.

<p>Published 29 September 2026. Last updated 30 September 2026.</p>
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to return an item",
  "datePublished": "2026-09-29T09:00:00+01:00",
  "dateModified": "2026-09-30T14:30:00+01:00"
}
</script>

Change dateModified only when the content changes. Google’s helpful content guidance warns against changing dates to make a page look fresh.

Setting it up in your CMS or framework

What we can’t tell from outside

We can count words and find headings, but we can’t tell whether an answer is right, clear, or what the reader needed. We read the HTML before JavaScript runs, so content a script adds isn’t counted. The question patterns work for English only. And whether Google shows a featured snippet, or cites the page in an AI Overview, is decided for each search, out of our view.

Sources

Last reviewed .