01The Direct Answer
How do I build a specification table AI can understand?
Direct Answer
Write each specification as a labeled pair — field name, value, unit — inside a real table, and repeat nothing important only in a place a row can be separated from.
A language model, when asked about a product, often extracts one row of a table at a time rather than reading the whole page as a block. If the unit lives only in the column header and the row is lifted out on its own, the number arrives without its unit. Writing the unit inside every value cell protects the fact from that kind of extraction, and it costs nothing in readability for a human either.
02The Most Common Mistakes
Four habits that make a table unreadable to a machine
Check Your Own Table Against This
1. Merged cells
Two specifications glued into one string, like "220V / 60Hz", separated by a slash a machine has to guess how to split.
→
2. Unit only in the header
A column titled "Weight (kg)" with bare numbers below, which lose the unit if the row is read alone.
→
3. Table built with spacing
Text visually aligned into columns using spaces or line breaks, with no real table markup underneath.
→
4. Vague field name
"Spec 1", "Spec 2" as row labels, which tell a machine nothing about what the value means.
Any one of these four, alone, can make an otherwise correct specification unreachable to extraction — even inside a page that is technically indexed.
03The Anatomy of a Good Table
Field, value, unit — every single row
A specification table that survives being read one row at a time follows the same pattern from top to bottom: a clear field name in the first column, one value in the second, and the unit attached to that value rather than isolated in the header. Applied consistently, the whole table reads correctly whether a machine parses it row by row or as a full block.
This same discipline is what makes a schema markup on top of the table straightforward afterward, since a well-labeled row maps directly onto a named property instead of requiring guesswork about what each number means.
04Units and Ambiguity
A number without a unit is a guess, not a fact
Industrial specifications are full of numbers that mean different things depending on the unit: a pressure rating in bar versus psi, a torque value in newton-meters versus pound-feet, a diameter in millimeters versus inches. Repeating the unit in every value, not just once at the top of the column, removes the single most common source of a wrong fact reaching a buyer or an AI answer.
Where the company sells in more than one market, keep both units in the same cell rather than in two separate tables, so neither version depends on the reader finding the other one.
05One Table, Rewritten
From ambiguous to extractable, in the same table
Before
"Power: 5.5" — no unit, no context
A machine, and a person outside the original document, cannot tell if this is kW, HP, or something else entirely.
After
"Motor power: 5.5 kW (7.4 HP)"
Named field, value, unit, and the second market unit in the same cell. Extractable whether the row is read alone or with the rest of the table.
Applying this pattern across the whole catalogue is a rewriting job, not a redesign, and it is worth doing on the HTML page format described in datasheet in HTML or in PDF, with the full method in optimizing the technical catalogue.
06FAQ
FAQ
How do I build a specification table AI can understand? +
Write each specification as field, value and unit in the same row of a real HTML table, and put the unit next to the number instead of only in the column header. That structure survives being read row by row, which is how a language model often extracts a fact.
Why does the unit need to repeat in every cell? +
Because extraction often pulls one row out of the table at a time. If the unit lives only in the header, a row read on its own arrives as a number with no unit, which for an industrial spec is close to arriving with no information at all.
Is a table built visually with spacing a real table? +
No. Text aligned into columns using spaces or line breaks has no table markup underneath, so a machine reads it as a single block of text rather than as rows and columns. Real table markup is what makes each cell individually addressable.
Should I avoid merged cells entirely? +
Avoid merging two different specifications into one cell, like combining voltage and frequency into a single string. A merged header spanning a section title is less harmful, but a merged cell that hides a second value is the one to remove.
What should the field name in the first column look like? +
Specific and human-readable, like "Operating temperature" or "Maximum load", never a generic label like "Spec 1". A vague label tells a machine and a buyer equally little about what the value means.
Does this table structure help with product schema markup too? +
Yes. A well-labeled row maps directly onto a named property in a schema markup, while an unstructured paragraph or a merged cell requires guessing which property a given number belongs to.
Should I keep two units for two markets in the same table? +
Keep both units in the same value cell when the company sells to more than one market, rather than maintaining two separate tables. That way neither version depends on a reader finding the other one.
Where should I apply this first? +
On the specification table of the product with the most search traffic or the most quote requests. Rewriting one table well teaches the pattern the rest of the catalogue can then follow.
Find the tables an AI system cannot parse today
The diagnosis checks specification tables field by field: named row, single value per cell, unit attached.
