Place schema

A physical place, location, venue, or geographic entity.

• The page represents a place that is not better described by a more specific subtype
• The location data is visible and accurate

• @id
• name
• url
• address
• geo
• map
• image

{
  "@context": "https://schema.org",
  "@type": "Place",
  "@id": "https://example.com/locations/example/#place",
  "name": "Example Place",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Example City",
    "addressRegion": "WV",
    "addressCountry": "US"
  }
}

• Selecting the type only because a search feature is desired.
• Publishing facts that are not visible or supported by the site.
• Creating conflicting copies of the same entity instead of using a stable @id.
• Failing to update markup when the visible page or source data changes.

Schema.org defines the vocabulary. Search platforms publish separate documentation for the structured-data features they currently support.

Use Place only when the page visibly represents the corresponding entity or relationship. Begin with the page purpose and the entity graph, then select the most specific supported type. Do not let the available vocabulary dictate claims the page does not make.

• Syntax validation, type/property validation, consumer testing, and post-deployment inspection.
• Record the page template, generator, source fields, responsible owner, and release reference.
• Avoid publishing properties that are unsupported, hidden, stale, or inconsistent with visible content.
• Parse the deployed json-ld, validate the graph, compare it with visible content, and test any target consumer requirements.
• Schedule review when visible content, offers, ownership, locations, products, or consumer documentation changes.

Search visibility and user value improve when place answers the real questions people bring to the page. For business owners, marketers, seo practitioners, and developers, that means covering the decision context, observable signals, implementation boundaries, and proof that the result works in production—not repeating a keyword or publishing a longer version of the same incomplete explanation.

Use the page as part of a connected topic cluster. Link the broad concept to focused implementation guides, definitions, checklists, examples, and the Asuruas workflow that can identify affected URLs. The goal is to help a reader move from discovery to a confident next action while giving search systems clear entities, relationships, and page purpose.

• Inspect entity type and page purpose.
• Inspect required and recommended properties.
• Inspect identifier relationships across the JSON-LD graph.
• Inspect agreement between markup and visible content.