Content & Answer Pages · 8 min read · September 24, 2026 · Hafsa Tariq, gaash.ai
Product data for AI: a product page that answers every condition
A product page answers a buyer's question when every attribute the buyer filters on is written on it as text: what the item is and is for, what it is made of, its measurements, the sizes and what it fits, the price with its currency, whether it is in stock and where it ships. Keep those facts in one product record, so page, feed and markup never disagree.
What turns a product page into an answer page
A buyer's question is a set of conditions, and an answer page meets them in words a reader can lift. A product page built only for the person already on it has a gallery, a price, a size selector and a button; the facts that decide a match sit in the photographs, in a tab a script opens, or in the supplier's PDF. An AI crawler reads the HTML the server sends, usually without running scripts, and has only what is in that text. Google renders JavaScript, but as a separate, deferred step.
So the page carries three layers in one place. The first paragraph says what the item is and the need it meets, in the buyer's words. Below it, a facts block states every attribute with its unit. Below that come the answers to the questions buyers ask before they order. Writing to be cited covers the passage itself; this article covers what a product page has to contain.
The attributes buyers filter on, written as sentences
Write each attribute as a line of text with its unit and its exact term. A badge, an icon or a swatch is fine for the eye, as long as the same fact is also in the words.
| Attribute | State it like this | Not like this |
|---|---|---|
| What it is and for | "A [capacity]-liter backpack for day hikes in heavy rain, with a roll-top closure" | "Your new adventure partner" |
| Material | "Outer: [material]; lining: [material]" | An icon of a leaf |
| Measurements and weight | "[height] x [width] x [depth] cm ([inches] in), [weight] g empty" | Measurements only in a photograph |
| Capacity | "Fits a laptop up to [n] inches and a [n]-liter water bladder" | "Room for everything" |
| Size and fit | "Runs small: between sizes, order the larger one" | A size chart image |
| Compatibility | "Fits [model], [model] and [model]; does not fit [model]" | "Universal fit" |
| Care | "Wipe clean; do not machine wash" | A care symbol on its own |
| Origin | "Made in [country]; ships from [city, country]" | A flag icon |
| Certifications | "Certified to [standard], certificate [number]", only for ones you hold | A logo with no name or number |
| In the box | "Backpack, rain cover, detachable hip belt" | Nothing, so buyers email to ask |
| Price | "[price] [currency], including [tax] for [market]; duties paid by [whom]" | A price with no currency on a site that ships abroad |
| Availability and delivery | "In stock; ships in [n] business days; [n] to [n] days to Canada" | A grayed-out button |
Where you sell to buyers who measure differently, give both units: centimeters and inches, grams and ounces. And state the price the way each market will pay it. Whether a displayed price must include tax is a rule of the buyer's market; the page's job is to say plainly what the shown price includes, for every market you ship to.
Page, feed and listing: one set of facts, three copies
A shop that sells on more than one channel keeps each product's facts in several places at once: the page, a product feed for a shopping channel or a marketplace, the markup, the marketplace listing and the packing slip. When the page says in stock and the feed says sold out, or the listing still shows last month's price, a reader has two answers and no way to know which is current. An answer built from one copy and a buyer reading another will disagree at your checkout.
The fields that drift are predictable. Prices drift during a sale, when the banner changes and the feed does not. Availability drifts per variant, when one size sells out. Attributes drift when a product is revised and the old description stays on a listing. Shipping costs drift when a carrier's rates change and only the checkout is updated.
Keep one record per product and make every copy from it: the page template reads it, the feed exports it, the Product markup is generated from it. Where a channel has to be edited by hand, note that in the record so a change reaches it. Then compare the copies once a month on the lead lines at least, field by field; who owns each field is set out in a GEO strategy for an online shop.
Variants: say which one is which, in text
Sizes and colors are where product pages lose facts to scripts. A selector that swaps the price, the stock and the photo when a buyer picks a variant can leave the HTML a crawler receives describing only the default one. Put a short table of variants in the page itself: each size or color, its own measurements where they differ, its price where it differs, and whether it is in stock.
If each variant has its own URL, choose which address is the main one and say so with a canonical tag; Google's page on duplicate URLs describes how a preference is stated. Google's product documentation supports variant markup for product snippets and for merchant listings alike, so the variants in the table can be grouped in the markup too, as schema.org for online shops shows.
Availability a fetcher can read
State availability in words, per variant, and update it the day it changes: in stock; ships in [n] business days; made to order in [n] weeks; available for pre-order, shipping from [date]; sold out, with a restock month if you know it or a plain statement that there will be none. A grayed-out button tells a person with a browser something, and may tell a fetcher nothing.
Keep a sold-out page up while the product is coming back, with the restock line in the text. When it is gone for good, say so and point to the nearest replacement, and when the page is finally removed, send its address to that replacement with a 301 redirect. A page that disappears takes its facts with it, and an answer that still names the product has nowhere of yours to send the buyer.
Size, fit and compatibility, answered on the page
Size and fit are what buyers email about, and the answers belong on the page. Put the size chart in the HTML as a table, with the body or item measurement each size corresponds to, in each unit your buyers use. In our audit of 9,483 small business websites, 2.1% kept their real content, such as a price list or a service menu, in a PDF; a shop's version is a size chart that exists only as a file. The PDF trap covers why a chart as an image or a PDF gives a fetcher nothing, and the HTML standard's table element is the form a chart already has: rows, columns, a header and a caption.
Then write the fit in sentences: how the item runs against its label, what to order between sizes, what changes after washing or wear. For compatibility, list the models it fits by their exact names, and list the ones it does not fit, which answers "will it fit my [model]" as surely as the first list. Photographs keep their place for the eye; give each one alt text that says what it shows, and keep the facts in the text.
Checking a product page in ten minutes
- Open the page with scripts turned off and find the price, the currency, the sizes and the shipping line in the text.
- Read the first paragraph aloud. If it does not say what the item is and what need it meets, rewrite it.
- Compare five facts on the page with the same product in your feed and on your marketplace listing: price, currency, availability, one size, one material.
- Pick a variant that is out of stock and check that the page says so in words.
- Search the page for a condition buyers type about this product, such as a destination, a fit or a material, and add it if it is missing.
- A month later, ask an assistant a question with that condition and read which page it cites. The overview for online shops lists the other pages a shop needs.
Common questions
Our theme puts product details in tabs. Can a crawler read them?
It depends on how the tabs are built. If the text of every tab is in the HTML and the tabs only hide and show it, a fetcher receives all of it. If a tab loads its content with a script when someone clicks, the HTML holds an empty panel. View the page source, search for a sentence from the second tab, and you have your answer.
Do we need a question-and-answer section on every product page?
On the pages you lead with, yes: three to five questions buyers ask before ordering, each answered in a few sentences in the HTML. In our audit, 61.5% of the sites had no question-and-answer content of any kind, so a short section is already more than most of the sampled sites carried. Write the questions from your customer emails, not from a keyword tool.
Our size chart comes from the supplier as an image. Is that enough?
Not for a fetcher that reads text. Type the chart into the page as an HTML table, with a caption naming the product and the unit, and keep the image beside it if it helps people. Check the supplier's numbers against a sample while you type them: a chart that is wrong in text is quoted wrong, which is worse than an image nobody could read.
How do we show a product is out of stock without losing the page?
Keep the page, change the availability line in the text and in the markup on the same day, and say what happens next: a restock month, a pre-order date, or a replacement you link to. Remove the page only when the product is gone for good, and then redirect its address to the closest replacement.
Sources
The percentages are this site's own, from the audit named below; they describe all 40 trades in the sample, not shops alone. What Google renders and how it treats duplicate URLs and product variants is from its documentation, linked where it is used.
Sources: our audit of 9,483 small-business sites, with its method · Google, product structured data · Google, consolidating duplicate URLs · Google, JavaScript SEO basics · HTML Standard, tables
Read on