Technical foundations
Make product specifications readable beyond the image
Keep strong product visuals while adding a clear HTML specification table with units, variant context and a repeatable verification process.

TL;DR
- Keep the product image, then publish key specifications as visible text beside it.
- Tie each value to a model, unit and test condition so readers can compare the right product.
- Use accessible table markup and verify the published values against an approved source.
- An llms.txt index can point to the page, but cannot replace missing product information.
A useful product specification table gives buyers the facts they need without asking them to read small labels inside an image. The design can stay visual. Put the details that drive a purchase decision in clear HTML text as well.
Google advises making important content available in text for its AI search features. That supports a readable product page; it does not promise that a table will earn citations. Google's technical guidance.
Choose the facts before choosing the layout
Start with a sales or support question that requires an exact answer. For an industrial light, that might be the operating temperature, battery capacity or mounting range. For software, it could be an integration limit or supported export format.
Ask the product owner for the approved specification sheet and its revision. Match each value to the exact model shown on the page. The highest value across a product range may not apply to that item.
Use a short explanation where a number needs context. “Up to 12 hours” is incomplete if it depends on a dimming schedule, test temperature or battery configuration. If the team cannot verify a claim, resolve it before publication instead of hiding the ambiguity in a footnote.

Worked example: repair a solar-light product page
Illustrative example: the product and values below are fictional.
The current page shows a hero image labeled “Long runtime — all weather.” A PDF lists a 120 Wh battery for model SL-40, while an older image says 96 Wh. The product owner confirms that the item on sale is revision B. It has a 120 Wh battery. The team removes the old image claim and replaces the broad weather claim with the approved operating range.
The finished table gives the buyer a precise comparison point:
| Specification | Value | Context |
|---|---|---|
| Battery capacity | 120 Wh | Revision B configuration. |
| Operating temperature | −10°C to 45°C | Published operating range; storage limits are separate. |
| Mounting height | 4–6 m | Confirm suitability against the installation plan. |
| Runtime | Up to 12 hours | Illustrative test: full charge, 25°C, specified dimming schedule. |
The marketer owns the page copy. The product owner signs off on the values and conditions. The developer makes the table visible in the page response and preserves it on mobile. One person can hold these roles. The approval must still point to a real source.
Acceptance requires more than seeing a table. Compare each row with the approved revision, select and copy the text, open the page without a logged-in session, and inspect the initial HTML. Select each model and check that its label and values change together. Finally, check the old image and PDF so they no longer contradict the page.
Use HTML that explains the relationships
A table needs a clear caption and proper header cells. The W3C table tutorial explains how captions help readers identify tables. Its header guidance describes how header cells and scope make relationships clearer for assistive technology.
Here is a small implementation pattern, using the same fictional product:
<table>
<caption><span>SL-40 revision B specifications</span></caption>
<thead>
<tr><th scope="col">Specification</th><th scope="col">Value</th></tr>
</thead>
<tbody>
<tr><th scope="row">Battery capacity</th><td>120 Wh</td></tr>
</tbody>
</table>
Keep the table usable at narrow widths. Allow horizontal scrolling when needed, keep labels visible, and avoid turning the whole table into an image. Technical facts should remain useful to people who zoom the page or use a screen reader.
Product specifications: common questions
Is image alt text enough?
Use alt text to describe the image's purpose. Do not make it the only home for a long specification sheet. Buyers should be able to read and compare the facts on the page.
Can structured data replace this table?
No. Structured data and visible content have different roles. Keep their claims consistent, and treat the visible page as something buyers can inspect directly.
Should the table link to a downloadable PDF?
A PDF can add diagrams or a full technical record. Publish the core decision facts on the page too, and identify the PDF version so the two stay aligned.
This work connects to the evidence and findability checks in Semanta's service-page audit framework. When product, sales and website records disagree, bring one product URL and its approved specification sheet to discuss a content and implementation review.