Free Place Schema Generator

Why many location pages underperform

How SwiftSchema helps

How it works

What is Place structured data?

Place represents physical locations—venues, landmarks, campuses, stadiums, parks, cultural sites—regardless of whether they offer commercial services. It focuses on core location identity: name, address, geo coordinates, phone, maps, and official profiles. Use Place for general venues; use LocalBusiness for locations that provide services with hours and offerings.

Address schema: how PostalAddress works

Most “address schema” questions are really about PostalAddress, the schema.org type for a mailing or street address. It is not a page type of its own. You nest it inside the entity that has the address: Place.address, LocalBusiness.address, Organization.address, or the location of an Event.

The PostalAddress fields, and how to fill them:

• streetAddress: street number and name, plus suite or unit (200 SW Naito Pkwy, Suite 4).
• addressLocality: the city or town (Portland).
• addressRegion: the state, province, or region, as a full name or its standard abbreviation (Oregon or OR). Pick one form and use it everywhere.
• postalCode: the ZIP or postal code as a string, so leading zeros survive ("02108").
• addressCountry: the two-letter ISO 3166-1 country code (US, GB, DE).
• postOfficeBoxNumber: only when mail goes to a PO box.

Pair the address with geo (GeoCoordinates latitude/longitude) when you know the exact point. The address tells people where to go; the coordinates pin the location for maps and remove ambiguity between places with similar names.

A few rules keep address markup trustworthy:

• Match the page. The address in JSON-LD should read the same as the address visible on the page.
• One address per entity. For a business with several locations, give each location its own page and its own markup rather than listing every address in one block.
• No public address? Don’t invent one. Service-area businesses can describe coverage with areaServed on LocalBusiness instead of publishing a home address.

The generator below builds the full PostalAddress block for you; see the “Place with full PostalAddress” example on this page for the finished shape.

Eligibility & Status

Place markup improves map confidence, disambiguation, and local understanding but doesn’t produce a specific rich result on its own. It complements LocalBusiness, Event, and Organization schema.

Why place markup matters

• Navigation accuracy: Geo coordinates and addresses reduce misrouted directions.
• Multi-campus clarity: Museums, universities, or parks with multiple entrances can describe each one precisely.
• Official verification: Linking to authoritative profiles (city listings, tourism boards) reduces spoofing.
• Event support: Events referencing a Place inherit accurate location data.

Essential properties to include

• name.
• address (PostalAddress with street, locality, region, postal code, country).
• geo (GeoCoordinates with latitude and longitude).
• telephone: International format when available.
• url: Canonical landing page.
• hasMap: Link to an interactive map (Google Maps URL or custom map).
• image: Photos of the location.
• sameAs: Official listings (city tourism, Wikipedia, social).

Preparing place data before generating schema

1. Gather NAP data: Pull from city records or your location directory to ensure accuracy.
2. Confirm coordinates: Use a GIS tool or mapping service to capture precise lat/long.
3. Collect imagery: High-quality photos of the venue, entrance, or notable features.
4. List map links: Choose the map URL you want to promote (hasMap).
5. Document contact info: Phone or general inquiries email (if public).
6. Record official profiles: City directories, tourism sites, social channels.

Implementation workflow inside SwiftSchema

1. Select Place in the generator.
2. Enter name, canonical url, and PostalAddress.
3. Add geo coordinates and telephone.
4. Provide hasMap and sameAs links for official profiles.
5. Include image URLs if you have photos.
6. Export JSON-LD, embed it on the location page, and validate via the Rich Results Test.

Troubleshooting & QA

• Missing country: Always include addressCountry.
• Swapped coordinates: Latitude is first; ensure values are in decimal degrees.
• Multiple locations on one page: Create individual pages (or use PlaceList) so each Place has its own JSON-LD block.
• Business vs Place: If the location offers services/hours, use LocalBusiness or the appropriate subtype.

Maintenance and governance

• Update schema when addresses, phone numbers, or maps change.
• Audit seasonal or temporary locations to ensure closures/removals are reflected.
• Keep lastReviewed metadata current and assign ownership for location schema.

Common Errors & Fixes

• Missing country: include a two-letter country code (US, CA, etc.).
• Swapped coordinates: ensure latitude and longitude are correct.
• Multiple locations on one page: give each location its own page and JSON-LD.
• Business pages marked as Place: use LocalBusiness when hours/services apply.

On-page parity checklist

• Location name and address on-page match name and address.
• Phone numbers match telephone and use international format.
• Map embeds or links on-page match hasMap URLs.
• Coordinates displayed (if any) align with geo decimal degrees.
• Images on-page are the same assets referenced in image URLs.

Content depth ideas (avoid thin location pages)

• Provide directions for car, transit, and accessible routes; mention parking rules or fees.
• Describe landmarks or entrances to reduce confusion for large venues.
• Add hours or access notes if relevant (gate times, seasonal closures).
• Include safety/accessibility info (ramps, elevators, lighting, restrooms).
• Link to upcoming events or services that use the Place so users can take action.
• Share brief history or significance for notable venues to add context.
• Include contact options for rentals or inquiries if the venue is bookable, and align them with contactPoint when used.
• Mention policies (bag checks, ticketing requirements) when the Place hosts events, and keep them aligned with event detail pages.
• Add short photo captions to clarify entrances or parking locations; ensure those images are represented in image.
• If the Place has multiple entrances or buildings, consider using containsPlace or adding clear on-page maps and descriptions for each access point.
• Add inLanguage for multilingual pages and ensure localized contact numbers or hours match the locale presented.
• If you embed booking widgets for tours or rentals, ensure they don’t inject conflicting schema and that any contact info matches your primary Place data.
• Keep lastReviewed updated after address, map, or branding changes.

QA and governance

• Verify coordinates against authoritative GIS sources and monitor for drift after site migrations.
• Revalidate after changing map providers or URL parameters.
• Audit quarterly to retire closed locations and update renamed landmarks.
• Keep lastReviewed current and log ownership for maintaining location data.
• Keep an internal registry of locations with @id/URL mappings so Events or LocalBusiness entries link to the correct Place.