Schema markup for SEO is structured information that describes a page and the real entities connected to it. JSON-LD is a common way to publish that information in a machine-readable form. It can clarify that a page is an article, that a business publishes a website or that a visible service description belongs to a particular organization.
The important boundary is factual accuracy. Markup does not create a review, an office, an expert or a relationship with a platform. It should describe what genuinely exists and what the reader can find on the page. Valid syntax also does not guarantee a rich result, a higher position or inclusion in an AI-generated answer.
Separate vocabulary, syntax and search features
A vocabulary defines types and properties. JSON-LD provides a format for expressing them. A search engine then decides which features it supports and which pages may be eligible for a particular presentation. These are different layers. A property can be meaningful in a vocabulary without guaranteeing any special display in search.
This distinction helps owners evaluate proposals. “The JSON is valid” is a useful technical check, but it does not prove that the facts are correct or that the page meets a search feature’s current requirements. Ask which type is being used, why it fits the visible page and what has actually been verified.
Google’s introduction to structured data is an official starting point. Feature documentation can change, so consult the current guidance when choosing a search-specific implementation rather than relying on an old screenshot or plugin label.
Begin with the organization and website
A site-wide graph can identify the actual organization and the website it publishes. Use the real brand name and canonical site URL. Add a logo only when the genuine asset is available and appropriate for the field. A text placeholder should not quietly become the organization’s official logo in structured data.
Contact details need the same review. A dummy phone number or provisional email can be useful in a local development setting, but should not be presented to machines as a verified business fact. Store placeholder flags and exclude those fields until the owner confirms real values.
A remote business should not invent a street address to satisfy a local-business template. An accurate organization description and genuine service coverage are more responsible than a fabricated office. Add a physical-address type only when the relevant information and business model have been verified.
Describe the page and its place in the site
A WebPage entity can identify the canonical URL, name, description and relationship to the website. An archive may be better described as a collection page. The type should follow the page’s actual role rather than whichever label appears to promise a search enhancement.
Breadcrumb information should reflect useful navigation. A nested service page can identify the homepage, services hub and current service where those destinations exist. Keep labels accurate and positions sequential. Do not create breadcrumb entries for nonexistent pages just to make a URL structure look more elaborate.
Use consistent identifiers for entities shared within the graph. This lets an article refer to the same organization already described as publisher. Avoid several plugins emitting contradictory versions of the business with different names, logos or contact details on the same page.
Use article markup for actual editorial content
An article entity should match the visible headline, summary and content. Use real publication and modification dates. A draft creation date should not be presented as a public publication date, and a private editorial change should not automatically imply that the live article has been updated.
Authorship needs care. If the organization is the author until a real individual profile exists, state that honestly. Do not create a fictional person, stock portrait, qualification or biography to populate an author box. A real profile can be added when the owner supplies and approves its details.
Feature images, section names and keywords should correspond to the article rather than unrelated promotional material. An original topic diagram can be a legitimate featured image without pretending to show client results. The visible caption and alt text should explain what it actually depicts.
Services, questions and step-by-step material
A Service description can connect a real offer to its provider. It should not include a price, rating or service area that the business has not confirmed. Optional pricing fields can stay empty and hidden. A service page can still explain scope, deliverables and factors affecting cost without inventing a fixed package price.
Question-and-answer markup should match accessible questions and answers on the page. If a section is hidden from the public page, its answers should not remain in the graph as though they were visible content. Search feature availability is a separate question and must not be promised from the existence of valid markup.
Use a step-by-step type only when the material genuinely explains a process with meaningful steps. A list of general benefits is not a how-to. Preserve important cautions, prerequisites and approvals in the visible content instead of reducing a complex task to misleadingly simple machine-readable instructions.
Never manufacture proof with structured data
Ratings and reviews can look persuasive in an editor, but the absence of real evidence is not a technical problem to work around. Do not add AggregateRating or Review entities from a template’s sample data. Keep proof sections hidden until genuine, verifiable content is supplied and reviewed.
A hypothetical example must remain an example. It should not be converted into a client case study with invented numbers, a customer name or a star value. The same standard applies to awards, memberships, years of experience and office locations. Machine-readable claims deserve no lower factual standard than visible sales copy.
Ask a provider to show where every important field comes from. If an answer is “the plugin needs something,” the field should be reconsidered. An on-page review can help align the visible information and structured description before publication.
Validate JSON and output it safely
JSON needs valid syntax, but web output also needs safe encoding. A CMS should validate custom JSON-LD and serialize it with appropriate escaping so a string cannot close the script block and inject executable markup. Do not paste untrusted raw JSON into a template without server-side validation and encoding.
Keep custom schema permissions limited to authorized users and preserve revisions. An SEO editor should not gain unrestricted script execution through a convenient “custom code” box. Tracking integrations should use validated IDs and their own consent-controlled mechanism rather than being hidden inside structured data.
A technical implementation review should check the final served HTML, not only the data saved in an admin field. Caches, multiple plugins and template conditions can produce output different from the editor’s preview.
Test meaning as well as formatting
Parse every JSON-LD block and inspect the graph. Check consistent identifiers, canonical URLs, required real dates and references to entities actually defined. Compare names, descriptions, images and FAQ text with the visible page. A syntax validator cannot tell whether a supplied office or testimonial is genuine.
Test representative content types and states. A published article, a service, an archive, a private preview and a page with an unpublished draft have different requirements. Non-production should remain noindex, and private previews should not load marketing tags even when the production tracking IDs are configured.
Record limits in the result. Passing a local script means those checks passed for that output. It does not establish eligibility for every external feature or prove that a live deployment has the same configuration. Verify the actual production URLs after an approved release.
Make markup part of publishing maintenance
When a headline, URL, service or author changes, review the related structured fields too. Use the live snapshot’s modification time rather than every private save. Invalidate sitemap and page caches when relevant content changes so the machine-readable view does not lag behind the public page.
Keep responsibility clear between the CMS, SEO settings and any third-party tools. One coherent graph is easier to audit than several overlapping outputs with uncertain ownership. If a new plugin is proposed, check whether it duplicates existing markup before enabling it.
Structured-data checklist
- The chosen type fits the visible page.
- Names, contact information and addresses are real.
- Placeholder and unverified proof fields are absent.
- Article dates and authorship reflect actual publication.
- Breadcrumbs and entity references are coherent.
- JSON is validated and safely serialized.
- Drafts, consent states and caches are tested.
- Search-feature claims remain appropriately limited.
Keep a representative release sample with the page URL, visible content state and parsed graph. Check an ordinary page, an article, a service and a private preview after relevant template changes. If an important field is unavailable, omit it and record the missing input rather than substituting a plausible placeholder. This makes the handover easier to audit and reduces the chance that a later theme or plugin reintroduces fictional contact details or duplicate entities.
Use SEO planning to decide what information belongs on the site, then verify the implementation against accurate, owner-approved business facts. A free audit request can help identify mismatches before adding more markup.