Choose Organization or LocalBusiness truthfully
Structured data helps search systems understand entities and page content, but the type must fit the real business. Use Organization when the site represents a company, brand, nonprofit, or service provider without a customer-facing local location that the page can accurately describe. Google recommends putting organization details on the home page or a single page that describes the organization, rather than repeating conflicting versions everywhere.[12]
Use LocalBusiness—or the most specific applicable subtype—when the page represents a genuine physical business location and can provide the required location facts. Google’s local business documentation centers on a named business location with an address and supports properties such as hours, telephone, geo coordinates, departments, and location-specific URLs.[13] A service area, city keyword, mailing address, virtual office, or desire to rank locally is not a reason to invent a public location.
Type-selection questions
- Does the page describe the overall organization or one real customer-facing location?
- Is the business name shown exactly as customers know it?
- If using
LocalBusiness, is the street address accurate, public, and visibly associated with that location? - Are phone, hours, URL, and service details specific to the entity being marked up?
- Would a visitor reading the page understand the same entity and facts without inspecting the code?
Align markup with visible content
1. Build a verified fact sheet
Before writing JSON-LD, collect the approved business name, canonical URL, logo URL, public contact details, public address if applicable, opening hours, and official profile URLs. Identify who owns each fact and when it was last checked. Leave out optional properties that cannot be verified.
2. Match what visitors can see
Google’s structured data policies say markup must be a true representation of the page and must not describe content hidden from readers.[11] The name, location, service, offer, rating, hours, and other claims in JSON-LD should agree with the visible page. Structured data is not a place to add claims that legal, operational, or content owners would not publish.
3. Do not invent reviews, offers, or addresses
Never create ratings, review counts, testimonials, prices, discounts, inventory, service availability, opening hours, or postal addresses to fill optional schema properties. Google explicitly warns against fake reviews, misleading content, and markup unrelated to the page.[11] If a real offer or review is not visible, current, and eligible under the feature-specific rules, omit it.
4. Use stable identifiers and canonical URLs
Use absolute HTTPS URLs for the entity’s page and logo. If the implementation uses an @id, choose one stable identifier and reference it consistently instead of creating near-duplicate entities. Keep the page canonical, sitemap URL, structured-data URL, and visible business identity aligned.
5. Mark up the page’s primary subject
An article about a business does not automatically become a LocalBusiness page, and a service page should not be labeled as an unrelated rich-result type. Use page-level types such as Article when they describe the page, and connect them to a verified organization only when that relationship is real. More markup is not inherently better.
Validate, test, and review before release
Parse every JSON-LD block as JSON first. Then use Schema.org validation for vocabulary and Google’s Rich Results Test for supported Search features. Google also recommends checking deployed pages with URL Inspection so you can see the page Google received.[12] Automated tools catch syntax and many required-property problems, but they cannot determine whether an address, review, offer, or business relationship is true.
Release gate
- Every
application/ld+jsonblock parses without errors. - The selected type describes the visible page and actual entity.
- Required properties for the chosen Google feature are present.
- Recommended properties are included only when applicable and verified.
- URLs resolve, images are accessible, and the canonical agrees with the entity URL.
- No invented review, aggregate rating, offer, price, address, hours, or location data appears.
- The deployed URL is crawlable and not blocked by
robots.txt,noindex, login, or infrastructure rules. - A human compares each material schema fact with the rendered page and approved source of truth.
Maintain structured data as business data
Assign ownership for changes to branding, phone numbers, locations, hours, offers, and profile URLs. When visible content changes, update the markup in the same release. Revalidate after template edits, CMS migrations, redesigns, or plugin updates, and monitor Search Console enhancement and manual-action reports for relevant issues.
Valid markup creates eligibility, not a guaranteed search treatment. Google states that following structured data guidelines does not guarantee that a feature will appear in Search results.[11] Search systems decide whether and how to display results. The honest goal is consistent machine-readable information that matches a useful page—not a promised rich result.
Related checklist
Sources
These Google Search Central references informed this guide. They are numbered to match the shared research source list.
Need a structured data review?
Share the page and the verified business facts it should represent. I’ll help select a truthful type, align the markup, and define a testable release scope.
Start the conversation