Structured data describes what a page already contains in a standardized format. Choose the page's purpose first, model only the relevant entities and properties, then compare the result with the visible content. Never add reviews, prices, people or performance claims merely to make the markup look richer.
Start with the page's purpose
An organization profile, service page, article and contact page perform different jobs. Use a suitable main type and add supporting types only when they describe something real. BlogPosting belongs to a published article. Service describes a specific service. BreadcrumbList should follow visible, working navigation.
More types do not automatically produce better search results. A small, complete and accurate model is easier to maintain than a large graph of half-filled objects. Choose properties from the official documentation for the intended search feature and from schema.org for broader meaning.
Keep visible content and JSON-LD aligned
Google's introduction to structured data says that markup should describe the content of the page it appears on and should not add information that is absent for visitors. Use that rule as the publication boundary.
If a phone number appears in the graph, show it on an appropriate public page. Use a rating only when the underlying reviews exist, are visible and are managed correctly. Add opening hours only when the business has confirmed them and can keep them current.
Give every entity a stable identity
Use a stable absolute @id for the organization, website and important page entities. Let other nodes refer to those identifiers instead of recreating an organization object each time. This prevents several spellings, logos or addresses from appearing inside one site.
Manage the name, URL, logo, contact details and verified profiles from one configuration. Keep page-specific data with the page: title, description, author, publication date and primary image should come from the published item. This separates site-wide ownership from editorial ownership.
Model relationships without repeating claims
A WebPage can be part of a WebSite and published by an Organization. A Service points to the same provider. A BlogPosting points to its page and author. These relationships make the graph clear without copying the complete organization record onto every page.
Use the same canonical URL in metadata, sitemap and @id construction. In a multilingual site, each public route has its own URL and language code while translations can belong to the same content group. Do not mix language versions inside one page entity.
Validate syntax and meaning separately
A parser confirms that the JSON is valid. A schema or rich-result test checks types and required properties. Neither test proves that a claim is true. After the technical check, compare names, URLs, images, authors, dates and business details with the rendered page.
Test production HTML rather than only an object in source code. Templates can create duplicate graphs, incorrect canonicals or development URLs. Put representative routes in the release audit and fail the build when core fields are missing or contradictory.
Manage markup changes as content changes
Assign an owner to site-wide business data and document which fields come from the CMS, plugin or site configuration. Recheck structured data when a template, content model, URL structure or business detail changes. The markup then remains a reliable representation of the site instead of forgotten code.
Use a publication check for each page
On a service page, the visible content may confirm the service name, provider, process, area and contact route. Model only those confirmed details. Omit AggregateRating, Offer, price or FAQ when the page has no genuine review, concrete offer, visible price or question section. An empty or invented object is not an optimization.
Before publication, check for one canonical, one primary page entity, stable @ids, absolute production URLs, the correct language and agreement with the rendered text. Then validate one representative page from each template. Valid markup can help a search engine understand the content, but it does not guarantee a rich result, appearance or higher position.