PostalAddress schema
A physical address, with the country as an ISO 3166 code rather than a name.
Where to use it
Nested inside Organization or LocalBusiness.
A complete example
Valid as written, with every required property and the recommended ones that carry real information.
{
"@context": "https://schema.org",
"@type": "PostalAddress",
"addressCountry": "US",
"streetAddress": "1 Example Street",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78701"
}Properties
| Property | Status |
|---|---|
addressCountry | Required |
streetAddress | Recommended |
addressLocality | Recommended |
addressRegion | Recommended |
postalCode | Recommended |
The three mistakes this type attracts
- 01A country name rather than an ISO 3166 code.
- 02Publishing a home address for a solo business without intent.
- 03Omitting postalCode where the country uses one.
Related types
Where this appears in the playbook
- Structured data: what each type is for and which ones earned their place.
- The schema graph: composing types into one graph with stable identifiers.
- One JSON-LD script per page, holding one @graph
- Stable @id anchors that cross-reference rather than duplicate
- Optional fields are omitted, never emitted as empty strings
Questions
What is the PostalAddress schema type for?
A physical address, with the country as an ISO 3166 code rather than a name. Use it on: nested inside Organization or LocalBusiness.
Which PostalAddress properties are required?
PostalAddress requires one property: addressCountry. It also recommends 4: streetAddress, addressLocality, addressRegion, postalCode.
Does PostalAddress produce a rich result?
PostalAddress does not produce a Google rich result. It is still worth shipping, because its value is entity resolution and answer extraction rather than search result presentation.
What is the most common PostalAddress mistake?
The most common PostalAddress mistake is: A country name rather than an ISO 3166 code.