Structured data that matches the page.

Separate description from search appearance

Schema.org is a vocabulary for describing entities and their relationships. JSON-LD is one way to express that description in a page. Google uses supported structured data for certain search features, but a valid Schema.org type is not automatically a supported Google rich-result type.

Think of the work as three checks: does the markup describe the page accurately, does it meet the requirements of a relevant search feature, and can Google access and process it? Passing a syntax test alone answers only part of that question. Google’s structured-data introduction explains the distinction between markup and the search features it can support.

At Keyforge, schema work belongs alongside content and technical review in the agreed SEO service scope. If a business name, author or service description is wrong on the page, correct the source information before encoding it in JSON-LD.

Choose a type that fits the content

Inspect the page and the existing output before adding anything. A CMS theme, an SEO plugin and a custom script can all emit structured data. Several script blocks are not inherently a problem, but conflicting descriptions of the same organization or page deserve investigation.

Choose the most specific appropriate type you can support with facts. Do not apply a product template to a consulting page to chase a different search appearance. A field should earn its place through accurate information, not because a generator offers it.

Schema.org’s Service reference describes that vocabulary type. Google’s separate search feature gallery identifies the features for which it publishes requirements.

Keep the business and page identities consistent

An @id is an identifier you can use to connect descriptions of the same entity. For example, a page can refer to an organization identifier when naming its publisher. The value should be stable and unambiguous. It is not a password, certification or shortcut to authority.

Distinguish the page from the business and from the article on the page. They can have related but different identifiers. Prefer references to an established organization entity over repeatedly inventing slightly different names, logos and addresses in each template.

Be careful with authorship and claims

Use an author who is actually responsible for the content. A company-authored guide can name the organization. Do not add a named expert as a reviewer unless that review took place, or invent credentials to fill a field. Keyforge’s SEO team and founder information gives readers a place to assess the people behind the service.

Dates need the same care. A meaningful revision can justify a modification date; rebuilding the template should not manufacture a new publication history. If the original publication date cannot be verified, omit it instead of guessing.

Read a small JSON-LD example

The example below describes this guide as an article, connects it to its webpage and identifies Keyforge as publisher. It uses a modification date for the current revision. It does not claim a rating, a reviewer, a publication date or a guaranteed search feature.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://keyforgeseo.com/structured-data-seo-schema/#article",
  "headline": "Structured data that matches the page.",
  "mainEntityOfPage": {
    "@id": "https://keyforgeseo.com/structured-data-seo-schema/#webpage"
  },
  "author": {
    "@id": "https://keyforgeseo.com/#organization"
  },
  "publisher": {
    "@id": "https://keyforgeseo.com/#organization"
  },
  "dateModified": "2026-10-15"
}

In a complete implementation, the related WebPage and Organization descriptions need to be coherent too. The example shows one entity, not a universal template to paste into every page. Replace it with the facts of your own page and inspect any markup the CMS already generates.

Avoid the promises schema cannot support

Structured data does not guarantee a rich result. Google can choose a different presentation even when a page meets its requirements. It also does not guarantee rankings, voice-search visibility or inclusion in an AI answer. Evaluate whether the implementation describes the page correctly before asking what appearance it might earn.

FAQ content and FAQ rich results are different things

Business websites can publish useful answers to common questions. Google restricts FAQ rich results to well-known, authoritative government and health websites. An agency should not sell FAQ markup as a way to obtain those results. See the current FAQ feature documentation.

Do not manufacture review stars

A testimonial on your own service page is not permission to turn your business into an aggregate rating. Eligibility depends on the specific supported type and review rules. Keep genuine testimonials attributed, and check the requirements before adding review markup. Google’s review snippet policies address self-serving reviews for LocalBusiness and Organization.

Do not describe hidden offers, fabricated authors or unavailable services. Google’s general structured-data policies require relevant, representative content. Misleading markup can lose rich-result eligibility and can lead to a structured-data manual action.

Test syntax, eligibility and the live page

Use a vocabulary validator to examine schema structure and relationships. Then use Google’s Rich Results Test for the supported Google features relevant to that page. These tests have different jobs: the absence of a detected rich-result type is not proof that every piece of Schema.org markup is invalid.

A release check needs more than a pasted code sample

• Parse every JSON-LD block and check the entity identifiers.
• Compare the generated values with the visible business and page information.
• Inspect the intended live canonical URL, including any rendered output.
• Check relevant errors and warnings against the feature requirements.
• Verify that caching, consent tools or a second plugin have not changed the published result.

The Schema Markup Validator helps inspect vocabulary markup. The Rich Results Test checks supported Google search features. Where Search Console access is available, URL Inspection adds evidence about the page Google can access.

A validation warning needs context. It may identify an optional property rather than a reason to add information you do not have. Record the issue, whether it affects eligibility and the evidence needed to resolve it.

Make schema part of template maintenance

Structured data can drift when the website changes. A price changes in the page body while the plugin retains the old value. A new template changes the canonical but leaves an old page identifier. An organization changes its name in one place but not another. These are maintenance problems as much as markup problems.

Assign one owner for the entity facts and identify which system generates each description. On a larger site, sample each page template and the exceptions: unavailable products, articles without a named author, pages with multiple offers and URLs that redirect. Fixing one example does not verify every template.

Measure the result that actually exists

Where Search Console reports a supported enhancement or search appearance, review it alongside the affected URLs and implementation date. Eligibility counts, impressions and clicks describe different things. Do not present a passed test as measured traffic growth.

Access and indexing can still prevent the page from being processed as intended. The technical SEO guide explains those checks. If the problem crosses CMS templates and frontend code, coordinate the work with the website implementation team.

Ask for a usable implementation handoff

A schema review should leave the business with an entity inventory, the relevant page types, the generated properties and the source of each important fact. It should distinguish syntax errors from content mismatches and feature-specific requirements. Include an owner and a way to retest each proposed change.

For agencies commissioning this work, the client’s approval of business facts matters as much as the code. Our white-label SEO delivery can be scoped around those responsibilities. A proposal should identify what will be reviewed, what will be implemented and which systems your team retains.

The objective is accurate, maintainable information. When the page, markup and published response agree, future editors have a much clearer basis for making changes.