Definition
"Attribute" is the catalog and PIM word for a field defined inside your own system; "property" is the vocabulary word for a characteristic modeled in a published, external standard such as schema.org. They frequently describe the same real-world characteristic, but they belong to two different layers with two different owners — one you define, one you conform to. In ordinary English both words simply mean "a characteristic of a thing," which is exactly why the two layers get collapsed. A third usage runs the other way and is worth naming up front: many PIM and commerce platforms reserve "attribute" for the standardized fields defined on a category and use "property" for the looser, ad hoc key-value extras hung off an individual product. That is the sense used in the summary at the top of this page, and it is the opposite of the published-vocabulary sense used below it — so always establish which of the three a colleague means before agreeing on anything.
Key points
- An attribute is internal: your category schema names it, your team owns it, and you can rename it tomorrow.
- A property is external: a published vocabulary fixes its name and its expected value type, and you do not get to change either.
- The two are related by a mapping, not by identity — and the mapping is a real, maintained artifact.
- Most internal attributes have no matching standard property at all, which is a normal outcome, not a modeling failure.
Where does the two-word confusion cause real bugs?
Take one characteristic named both ways. A PIM holds an attribute called Material with values drawn from a controlled list; schema.org publishes a material property on Product that expects text or a URL. That one maps cleanly. Now take Screen Size. There is no screenSize property in the vocabulary, so it has to be emitted as an additionalProperty holding a PropertyValue with its own name, value, and unit code. Teams that treat the words as synonyms skip that step, publish an invented property name straight from the PIM field label, and produce markup that validators quietly ignore — no error, no eligibility, no obvious cause.
Common pitfalls
- Emitting internal attribute labels directly as vocabulary property names, producing terms no consumer recognizes.
- Assuming a standard property exists for every internal attribute, instead of routing the remainder through a generic property-value construct.
- Keeping the mapping only in code or in someone's head, so a PIM field rename silently breaks published markup.
FAQ
How does this relate to a product attribute schema?
Your attribute schema is the internal side of this pair — it declares which attributes exist and what they hold. The vocabulary is the external side. The mapping between them is the integration layer, and it is exactly what disappears when the two words are used interchangeably.
Do the two words ever genuinely mean the same thing?
In conversation, yes, and no harm follows. The distinction only becomes load-bearing at the point of publishing structured data, where "property" stops being a synonym and starts being a specific term with a fixed name and an expected value type that a consumer will check.
Source
The external side of this pair is the schema.org Product vocabulary, which lists the properties a product may carry and the value type each expects — including the generic additional-property construct for characteristics with no dedicated term. The internal, feed-level side is illustrated by Google's Merchant Center product data specification, which labels every field it defines "Required," "Optional," or "It depends" — the last meaning the field is needed only for certain products or certain countries.