GEO for Industrial Specifications with Units and Test Conditions

Industrial specifications need unambiguous measurement records: identify the characteristic and variant, retain the applicable unit, distinguish documented references from missing information, and preserve the value type supported by the source. This guide addresses mixed specification rows and unit vocabulary without claiming that markup guarantees AI interpretation, citation or indexing.

Why a value and a unit are not yet a specification

A specification page can show a number and a unit and still be read as an unconditional figure. The reason is that the number and the unit are only part of what makes the figure meaningful.

Schema.org defines a QuantitativeValue as "A point value or interval for product characteristics and other purposes." That definition is deliberately narrow. It covers the value and, where relevant, the interval. It does not, by itself, carry the condition under which the value was obtained or the limitation that bounds its use.

That gap is where misreading happens. A summarizer that lifts the value and the unit can produce a sentence that looks complete while the condition and limitation sit in a different paragraph, a footnote, or a linked PDF. The reader then treats a conditional figure as if it applied everywhere.

Schema.org’s own notes show how much context a bare value can lose. For fuel consumption, the documentation states: "Note 3: Often, the absolute value is useful only when related to driving speed (\"at 80 km/h\") or usage pattern (\"city traffic\"). You can use valueReference to link the value for the fuel consumption to another value." The value is real; its usefulness depends on the condition attached to it.

The vocabulary already anticipates that missing context. The valueReference property is described as "A secondary value that provides additional information on the original value, e.g. a reference temperature or a type of measurement." In other words, the vocabulary permits an applicable reference condition; that is not a mandatory requirement for every quantity.

For a condition-dependent performance claim, review the following parts together:

1. Value — the number itself.
2. Unit — what the number is measured in.
3. Measurement condition — the state, method, or reference under which the value holds.
4. Limitation — where the value stops applying, or what it excludes.

Ask which conditions and limitations actually affect this particular figure. Do not invent a test condition for a quantity that does not depend on one; a dimensionless value should be identified as such rather than assigned a made-up physical unit. The next sections deal with the labeling decision, the placement rule, and the vocabulary that labels a unit without promising that a machine will interpret it correctly.

For a related treatment of how conditions belong next to a conclusion in answer passages, see How to Write GEO Answer Passages with Conditions and Evidence.

References: 1.

Nominal versus tested: an editorial labeling decision

Once the four-part unit is clear, the next decision is what kind of value you are publishing. This is an editorial labeling decision, not a schema property. The cited unit and reference-value definitions do not substitute for a visible explanation of how this particular figure was obtained.

Label the value type explicitly. Common labels include nominal, rated, tested, and typical. Each one tells the buyer something different about how much confidence the figure deserves. Use the label and meaning supported by the manufacturer’s specification or test record, rather than converting a nominal designation into a tested result or a typical figure into a guarantee. If you publish a nominal figure without the label, a buyer can reasonably read it as a tested result, and that is a misreading you created.

Where a test method exists, name it next to the value. Schema.org’s notes on engine power make the reason plain: "Note 1: There are many different ways of measuring an engine’s power. For an overview, see http://en.wikipedia.org/wiki/Horsepower#Engine_power_test_codes." The same numeric value can mean different things under different measurement methods, so the method is part of the specification, not an optional footnote.

Schema.org also points to a mechanism for linking a value to how it was determined. The valueReference property is described as "A secondary value that provides additional information on the original value, e.g. a reference temperature or a type of measurement." That is a vocabulary hook for the condition, and it is useful only if the condition is also visible to the reader.

The same logic applies to values that depend on a usage pattern rather than a single test. Schema.org’s fuel consumption note states: "Note 3: Often, the absolute value is useful only when related to driving speed (\"at 80 km/h\") or usage pattern (\"city traffic\"). You can use valueReference to link the value for the fuel consumption to another value." A consumption figure quoted without its speed or traffic condition is the same kind of unlabeled value as a nominal rating quoted without its label.

A fictional wording comparison using placeholders, not actual product values or test results:

Weak labeling	Stronger labeling
"Pressure rating: [value] [unit]"	"[Manufacturer-supported value type]: [value] [unit], under [applicable condition], within [documented limitation]"
"Power: [value] [unit]"	"[Documented value type]: [value] [unit], established by [actual method], with [documented tolerance, if applicable]"

The right-hand column is longer, and that is the point. The extra words are the part that prevents a bare number from being quoted as unconditional.

For how specification questions map to procurement evidence more broadly, see Manufacturing GEO Query Map from Specifications to Procurement.

References: 1.

Matching each specification row to its unit and reference

Before comparing two values, check what each row measures. As an editorial practice, identify the characteristic and product variant first, then associate the unit and any applicable reference with that particular measurement. A unit in a table heading should not be copied to a row describing a different quantity. Do not silently convert units or infer missing test conditions.

Hypothetical example (fictional, for illustration only). A datasheet row is recorded as [characteristic], [variant], [value], [applicable unit or dimensionless designation], [documented reference], [source record]. A different row must be checked independently; an empty reference cell means unknown, not that the reference from the previous row applies.

For a range, record which characteristic the lower and upper limits describe. For a condition-dependent value, verify whether the reference belongs to that row, a named group of rows, or a particular test record. If the record does not establish that relationship, mark it unresolved rather than borrowing a neighboring row’s condition. These are publishing recommendations, not evidence that a particular AI system interprets tables correctly.

The relevant documented vocabulary is narrower than this editing decision:

The valueReference property is "A secondary value that provides additional information on the original value, e.g. a reference temperature or a type of measurement."

Schema.org’s fuel consumption note states: "Note 3: Often, the absolute value is useful only when related to driving speed (\"at 80 km/h\") or usage pattern (\"city traffic\"). You can use valueReference to link the value for the fuel consumption to another value."

Product also has a hasMeasurement property whose expected type is QuantitativeValue, described as "A measurement of an item, For example, the inseam of pants, the wheel size of a bicycle, the gauge of a screw, or the carbon footprint measured for certification by an authority. Usually an exact measurement, but can also be a range of measurements for adjustable products, for example belts and ski bindings."

Google’s guidance lists "Making sure your structured data matches the visible text on the page" among the SEO fundamentals that remain worthwhile.

The fuel-consumption note illustrates a condition-dependent quantity, not a requirement to add operating conditions to every measurement. The product-measurement definition allows measurements and ranges; it does not prove that every range needs an invented test condition.

A practical acceptance check is to read one exported row without its neighbors: can you identify its characteristic, applicable unit and source, and distinguish known references from missing information? Then compare that record with the corresponding structured fields. For the separate question of answer-passage wording, see conditions and evidence in GEO answer passages.

References: QuantitativeValue, Product, Google AI features.

unitCode and unitText: vocabulary, not proof of understanding

unitCode and unitText are vocabulary for labeling a unit. They are not a mechanism that makes an AI system understand your specification, and they are not a requirement you must invent.

unitCode is defined as "The unit of measurement given using the UN/CEFACT Common Code (3 characters) or a URL. Other codes than the UN/CEFACT Common Code may be used with a prefix followed by a colon." So the property expects a short code, or a URL, or a prefixed code when you are using something outside the common list.

unitText is the fallback: "A string or text indicating the unit of measurement. Useful if you cannot provide a standard unit code for unitCode." When no standard code fits, you write the unit as text.

Schema.org’s own notes show that the fallback is not rare. For fuel consumption: "Note 1: There are unfortunately no standard unit codes for liters per 100 km. Use unitText to indicate the unit of measurement, e.g. L/100 km." So unitText is not a lesser option; it is the correct option in documented cases where no standard code exists.

What these properties do not do is guarantee that any particular system reads them, or that a system that reads them will interpret the specification correctly. Do not assume a particular AI system reads these properties; verify actual answers and citations separately from the quality of your published data.

Google’s guidance is explicit on the markup question: "You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add." So adding unitCode or unitText is a labeling choice you make for consistency and clarity, not a gate you must pass.

The practical conclusion: use unitCode where a standard code exists, use unitText where it does not, and put your effort into the visible passage, because that is what a reader and a summarizer will actually quote.

References: 1, 2.

What Google actually requires, and what it does not promise

The platform-level requirements are narrower than the marketing around them suggests, and the non-guarantees matter as much as the requirements.

What Google documents as required: "To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements. There are no additional technical requirements." That is the eligibility bar. It is about being indexed and snippet-eligible, not about any specification-specific markup.

Google also states that "The best practices for SEO remain relevant for AI features in Google Search (such as AI Overviews and AI Mode). There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary." So there is no separate optimization track for specifications.

On markup specifically, Google is explicit: "You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add." Adding unitCode or unitText to a specification does not create an eligibility advantage, and it does not guarantee that any system will read the unit correctly.

What Google does not promise: "Just because a page meets all requirements, best practices, and complies with the policies, doesn’t mean that Google will crawl, index, or serve its content. Indexing and serving isn’t guaranteed." Meeting the bar is necessary, not sufficient.

Google documents query fan-out; the possible loss of a qualification described next is an editorial risk inference, not a measured result or a claim that this happens on every answer. "Both AI Overviews and AI Mode may use a \"query fan-out\" technique — issuing multiple related searches across subtopics and data sources — to develop a response." When a system issues several related searches, it may retrieve your value from one passage and a related condition from another source, or from no source at all. That is a reason to keep the four parts together in one visible passage, not a guarantee that doing so will be reflected in any answer.

The honest position for a specification publisher: make the page indexed and snippet-eligible, keep the value, unit, condition, and limitation in one visible passage, keep the structured data consistent with the visible text, and treat any AI-feature appearance as an outcome you cannot promise.

For the measurement limits that apply to any GEO outcome claim, see GEO Rankings: Measurement Limits and Reliable Signals.

References: 1.

A buyer’s reading checklist for a specification with a condition

The publishing guidance above has a buyer-side counterpart. When you read a specification, work through the four parts in order and stop when one is missing.

1. Find the value. What number is being stated?
2. Find the unit. What is it measured in? Check the applicable unit, or whether the quantity is dimensionless; do not invent a physical unit.
3. Find the measurement condition. Under what state, method, or reference does the value hold? Schema.org’s definition of QuantitativeValue covers "A point value or interval for product characteristics and other purposes," and its notes on fuel consumption show that the absolute value is often useful only when related to a condition such as driving speed or usage pattern. Where the value depends on an operating or measurement condition, ask for that missing condition before relying on it.
4. Find the limitation. Where does the value stop applying? A limitation can be a temperature range, a load range, a tolerance, or an exclusion.

Then check the label. Is the value presented as nominal, rated, tested, or typical? If the page does not say, treat the figure as unlabeled and ask. Schema.org’s note that "There are many different ways of measuring an engine’s power" is the reason the label and the method matter: the same number can mean different things under different measurement methods.

When the condition is a reference value rather than a test method, look for it explicitly. Schema.org describes valueReference as "A secondary value that provides additional information on the original value, e.g. a reference temperature or a type of measurement." If the page provides a reference temperature or measurement type, check that it matches your own operating situation before you rely on the figure.

Finally, check whether the condition matches your own operating situation. A value that holds under the stated test condition may not hold under yours. For a condition-dependent figure, missing conditions are an unresolved boundary, not evidence of unconditional performance.

For how specification questions feed a broader procurement evaluation, see Machinery GEO: Specifications, Selection, and Evidence.

References: 1.