Which website structured data should your business approve?

Approve website structured data when it accurately describes useful pages and comes with evidence that it meets the relevant requirements. It can help Google interpret your content and make qualifying pages eligible for supported search features. It cannot buy a particular search appearance or guarantee better rankings, enquiries or revenue. Your acceptance decision should concern accuracy, accessibility and maintenance—not a screenshot of a promised rich result. [1][6]

What structured data can—and cannot—do

Structured data is machine-readable markup embedded in a webpage. It labels the meaning of information: this is the business name, this is its address, and these are its opening hours. Google recommends JSON-LD, a format that keeps those descriptions together in a script. The script itself does not need to appear as readable page text. [1]

Schema.org provides the vocabulary, but Google supports only particular uses of that vocabulary in Search. A valid Schema.org type does not automatically qualify for a Google feature. Ask suppliers to identify the current Google guide supporting their proposal. A rich result is an enhanced search presentation; eligibility means a page may qualify, not that Google will display it. [1][5]

Choose markup that fits the page

Start with the content you actually publish, rather than a supplier’s list of available schema types. These common options serve different purposes. Adding more types increases the facts and templates you must check; it does not establish more eligibility. A small, accurate implementation is usually easier to accept and maintain than a site-wide bundle of poorly understood markup.

Organization and LocalBusiness are not rival packages. The first describes business identity; the second suits an actual physical business location. Likewise, Product markup has distinct implementation paths. Product snippets can cover non-purchasable product pages, but each page must still meet the relevant requirements. Do not invent a price or offer to make a quote-only page pass a test. [2][3][4]

Mark up visible facts you can keep accurate

The JSON-LD script can remain out of sight, but the information it describes must be available to readers on the page. Google requires structured data to reflect the page’s content and remain current. A hidden claim about an unavailable service, obsolete opening hours or a price customers cannot find is not rescued by technically valid markup. [1][6]

Our practical recommendation is to keep visible content and markup tied to the same business records wherever possible. Name someone who owns changes to addresses, hours and availability. Omit optional details you cannot verify. This sacrifices completeness on a test report, but reduces the risk of publishing conflicting facts. Missing optional information is preferable to fabricated coordinates, qualifications or prices.

Do testimonials and FAQs earn search extras?

Google does not allow the business-review star feature for self-serving reviews on Organization or LocalBusiness pages. This includes reviews about the business displayed through an embedded third-party widget when the business controls their placement on its own site. Genuine testimonials can still help readers, but marking them up does not create an entitlement to review stars. [7]

Google’s documentation updates state that FAQ rich results stopped appearing on 7 May 2026; removal of the documentation was recorded on 15 June 2026. The former FAQ guide redirects to those updates. The explicit announcement—not the redirect alone—is the evidence for retirement. Keep helpful FAQs, but do not approve FAQ markup on the expectation of expanded Google search results. [8]

Separate validation, eligibility and actual display

A green test result answers only part of the approval question. Google’s tools cannot establish every quality requirement, and a page can pass technical checks without receiving an enhanced appearance. Use four separate checks so that a supplier’s evidence does not quietly turn a technical milestone into a search-performance promise. [6]

Resolve critical errors for the intended feature. Treat non-critical recommendations individually: they are not automatically eligibility blockers, and they never justify invented facts. After publication, use URL Inspection in Search Console to check how Google accesses the page. An error-free Rich Results Test does not override access problems, content policies or Google’s eventual display choice. [6]

Hypothetical example: a Chennai restaurant

Example Chennai Kitchen is fictional, not a client case study. Assume its location page visibly shows that name, a complete Chennai address, a menu link and Monday–Saturday hours of 09:00–18:00. Every value below is either an assumed example or an explicit replacement placeholder. Restaurant is an appropriate LocalBusiness subtype, and Google’s guide covers address, hours and menu information. [3]

The following short JSON-LD pattern illustrates the decision; it is not production-ready or a live-tested implementation. The example.com addresses are placeholder URLs. The name, city, region, country, days and times are hypothetical assumptions, not verified business facts. Before use, replace or confirm every value against the visible location page and test the published result.

Deliberately leave out ratings, price ranges and coordinates because none has been established. Do not add aggregateRating for the restaurant’s own testimonials as a route to business-review stars. Nothing here implements reservations, payments or booking functionality. The useful outcome is a consistent description of the assumed location page, not a richer-looking bundle of unsupported claims. [3][7]

What to request before accepting the work

Our recommended acceptance process starts with one representative page or a small group of pages. This limits the cost of correcting a mistaken template before wider release. Agree the evidence below with your supplier in advance. Wider commercial scope belongs in Website performance and technical SEO support; this checklist concerns the markup itself, not a complete search audit.

1. Identify the intended type and Google feature, with the current official guide supporting the choice.
2. Compare marked-up facts with visible page content; remove placeholders, contradictions and unsupported claims.
3. Record Rich Results Test findings and resolve critical errors for the intended feature.
4. Explain remaining recommendations and why optional fields were supplied or omitted.
5. Inspect published URLs in Search Console to check access and the deployed output.
6. Agree who updates business facts and who rechecks markup after relevant changes.

Keep the implementation useful after launch

Recheck after changes to business facts, page templates, themes or markup-generating plugins. Monitor relevant Search Console reports where available, without treating their absence as proof of failure. Keep the original acceptance evidence alongside the responsibilities described in Keep control of the website after launch. This makes later discrepancies easier to investigate without promising any particular search presentation. [6]

Next, audit one representative page with your supplier. Agree its purpose, the appropriate markup, the supporting Google guidance and the person responsible for factual updates. Approve the work when the description is accurate, accessible and maintainable—not when someone promises stars, expanded listings or commercial improvement.

This research-assisted guide uses the primary sources linked above. Examples are illustrative unless explicitly identified otherwise. Check original documentation when implementing changes.