Reviewing and Adding Structured Data to Existing Pages

Start with the page itself

Structured data should describe information that is genuinely represented by the page. Begin by reading the page as a visitor would and identifying its purpose.

Ask a few foundational questions:

• What is this page primarily for?
• What is the page’s main subject?
• Which people, organizations, places, services, products, events, or creative works does it identify?
• Which facts are visibly supported by the page?
• Who created, published, maintains, or is responsible for the content?
• Is the page describing one primary entity or several related entities?

This examination helps prevent a common mistake: selecting a schema type because it is available rather than because it accurately describes the content.

A local service page, for example, should not automatically receive the same markup as an article discussing that service. The pages may mention similar entities, but they perform different functions and represent different relationships.

Distinguish the webpage from its subject

A webpage and the thing described by that webpage are related, but they are not necessarily the same entity.

An informational article may involve several distinct entities:

• The webpage delivered at a particular URL
• The article contained on that page
• The person or organization credited as the author
• The organization responsible for publication
• The subject discussed by the article

A business page may similarly involve the webpage, the business, its location, the services it provides, and the organization operating the site.

Keeping these entities distinct makes their relationships easier to describe. It also reduces the likelihood of assigning a page-level property to an organization, treating an author as a publisher without evidence, or presenting the subject of an article as though it were the article itself.

For a deeper explanation of this distinction, see Understanding Entities and Their Relationships on the Web.

Inspect existing structured data before adding more

Do not assume that a page lacks structured data because no one remembers adding it manually. Modern publishing systems frequently generate markup automatically.

Potential sources include:

• The content management system
• A theme or child theme
• An SEO or structured-data plugin
• An ecommerce, events, directory, or recipe plugin
• A reusable page template
• A tag manager or JavaScript application
• A custom field or settings panel
• JSON-LD inserted directly into the page
• Microdata or RDFa embedded in the HTML

Inspect the published page rather than relying only on what appears in the editor. A settings field may show one block while the theme or another plugin generates additional markup elsewhere in the delivered document.

Useful inspection methods include viewing the page source, examining the rendered document with browser developer tools, and testing the public URL with an appropriate structured-data tool.

If the markup is generated with client-side JavaScript, it may appear in the rendered document even when it is absent from the original source response. That difference is worth documenting because it affects how the implementation should be tested and maintained.

Identify where the markup is maintained

Finding a problem does not necessarily mean that the current page is the correct place to fix it.

Determine whether the structured data originates from:

• A field unique to the current page
• A reusable content block
• A post-type template
• A sitewide plugin configuration
• A theme function
• A custom integration
• Several systems contributing separate descriptions

A missing fact on one article may be appropriately corrected in that article. A malformed publisher description appearing on every article probably belongs to a shared template or plugin configuration.

Page-level review should generally stop before an uncertain local edit begins competing with a shared implementation. When the source is unclear, record the affected URL, the observed output, the suspected source, and the change that may be needed. The person responsible for the template or integration can then investigate without losing the original finding.

Evaluate types, properties, and relationships

Once the existing output is understood, compare it with the content and with the documented meaning of the vocabulary.

Schema.org provides a shared vocabulary of types and properties. Individual search engines and other platforms may support only portions of that vocabulary or apply additional requirements for particular features.

Check the type

The selected type should accurately describe the entity. A more specific type can be useful when it is supported by the facts, but specificity is not valuable when it makes the description less accurate.

For example, a general organization should not be labeled as a particular kind of local business unless the organization and page genuinely support that classification.

Check each property’s meaning

A familiar property name may not mean exactly what its everyday wording suggests. Review its documented definition and the kinds of values it expects.

This is especially important for relationships involving:

• Authors and contributors
• Publishers and copyright holders
• Organizations and their locations
• Businesses and services
• Products, offers, and sellers
• Events, organizers, and performers
• Pages and their primary subjects

A statement can be factually reasonable in ordinary language while still being expressed through an incompatible property or value type. Accuracy of intent and compatibility with the vocabulary are separate checks.

Describe actual roles

Authorship, contribution, publication, editing, ownership, and technical assistance are not interchangeable. Do not place every participant or tool into the same property merely to ensure it appears in the markup.

If the vocabulary does not clearly support a proposed relationship, do not force the relationship into a convenient field. It may be better to describe the role in visible editorial information, use a better-supported relationship, or leave it out of the structured data.

Statements about authorship and responsibility should also remain consistent with the page’s visible byline and editorial record. Document provenance provides broader context for preserving origin, history, and responsibility.

Reuse identifiers when descriptions refer to the same entity

Structured data may describe the same person, organization, page, or work in more than one place. Stable identifiers help connect those references.

Before introducing a new identifier, look for an existing one already used by the site. Reusing a consistent identifier can help clarify that separate references point to the same entity.

Review identifiers for:

• Consistency across relevant pages
• Accurate association with the intended entity
• Stable URL construction
• Conflicting types or names attached to the same identifier
• Different identifiers that appear to describe the same entity

An identifier is not helpful merely because it looks unique. It should participate in a coherent description and remain stable enough to support later maintenance.

Multiple structured-data blocks are not automatically a problem

A page may contain several structured-data blocks. One might describe the webpage, another the article, and another the publishing organization. Separate blocks can complement one another when they describe distinct entities or connect through consistent identifiers.

Review overlapping output by asking whether the blocks:

• Describe different but related entities
• Describe the same entity consistently
• Repeat harmless information
• Create disconnected copies of one entity
• Assign conflicting names, types, dates, URLs, or relationships
• Come from systems likely to overwrite or contradict one another later

Duplication becomes more concerning when two systems describe the same entity differently or when no one knows which system should be treated as authoritative.

Do not remove a block solely because an entity appears elsewhere. First determine whether the descriptions can be coordinated, whether one is redundant, and which implementation layer should own the information.

A bounded article review

Consider an existing informational article opened during a routine editorial pass.

The visible page includes a title, publication date, updated date, byline, article body, and publisher identity. Inspection shows that an SEO plugin already generates an article description along with information about the author and publisher.

The review might proceed as follows:

1. Confirm that the visible title, dates, byline, and publisher information are accurate.
2. Inspect the markup delivered on the published URL.
3. Determine that the plugin, rather than the page editor, generates the article description.
4. Compare the generated types, properties, and values with the relevant documentation.
5. Check whether references to the author and publisher reuse the site’s established identifiers.
6. Look for additional markup generated by the theme or another plugin.
7. Correct only the bounded issue that has been verified.
8. Retest the published page after caches and generated output have updated.
9. Record what was changed and where the implementation is maintained.

This review may conclude that the existing output is already accurate. That is a successful result. Inspection has established what the page contains, where it comes from, and why no additional block is needed.

A service page would require a new review rather than a copied version of the article markup. Its main entity, relevant relationships, visible evidence, and platform requirements may be different.

Structured data does not replace semantic HTML

Structured data provides an additional machine-readable description. It does not repair a page with unclear headings, missing labels, inaccessible controls, misleading visible content, or poorly organized document structure.

Schema markup and semantic HTML perform related but different work:

• Semantic HTML communicates the role and organization of content within the document.
• Structured data supplies explicit descriptions of entities and relationships through a separate vocabulary.

A well-maintained page should keep both layers aligned. The structured description should not make claims that visitors cannot reasonably verify from the page or its supporting context.

Separate syntax, vocabulary, and search-feature checks

No single test establishes every aspect of structured-data quality. Different tools answer different questions.

The Schema Markup Validator can help inspect Schema.org vocabulary usage. Google’s Rich Results Test evaluates supported markup for Google search features. Google also publishes separate structured-data documentation and feature requirements.

A successful result should be interpreted according to the tool’s scope. Passing a rich-results test does not guarantee that a search feature will appear. It also does not verify every real-world fact expressed by the markup.

Similarly, a Schema.org property may be valid vocabulary without being supported for a particular search feature. Vocabulary compatibility and platform eligibility are related but separate matters.

This interpretive distinction is part of broader web standards quality assurance: running a test is useful, but understanding what the result establishes is the more important step.

A practical workflow for reviewing an existing page

1. Read the page

   Identify its purpose, main subject, visible facts, and responsible entities.

2. Inspect the published output

   Look for JSON-LD, microdata, RDFa, and structured data inserted through rendered JavaScript.

3. Map the implementation sources

   Determine which plugin, template, theme, custom field, or manual edit produces each relevant block.

4. Define a bounded need

   State the specific problem before editing: a missing relationship, inaccurate value, conflicting identifier, unsupported property, or outdated fact.

5. Consult primary documentation

   Review the Schema.org definition and expected values. If a particular search feature matters, review that platform’s current requirements separately.

6. Choose the correct implementation layer

   Make a page-level change only when the issue belongs to that page. Route template-level findings to the person or system responsible for shared output.

7. Make the smallest complete correction

   Avoid rebuilding an otherwise sound description merely to correct one verified issue.

8. Validate in layers

   Check syntax, vocabulary compatibility, factual accuracy, platform requirements when relevant, and the actual published output.

9. Check for unintended effects

   If the change affects a shared template, inspect several representative pages rather than only the page that revealed the issue.

10. Document the change

    Record what changed, why it changed, where the markup is maintained, which documentation was consulted, and which pages were checked.

When to document the finding and ask for help

Some findings are safe to correct during an editorial pass. Others indicate a broader implementation issue.

Consider involving the person responsible for the site’s theme, plugin configuration, or technical maintenance when:

• The same problem appears across many pages
• Several plugins generate competing descriptions
• The source of the markup cannot be identified
• JavaScript changes the output after the initial page response
• A correction requires editing a shared template or application
• Identifiers are inconsistent across the site
• Removing one block may affect ecommerce, event, directory, or other specialized functionality
• The visible content and structured data are maintained by different teams

A useful handoff should include the affected URL, the observed markup, the expected relationship, the suspected implementation source, and the documentation supporting the concern.

When leaving the markup unchanged is the best outcome

More structured data is not inherently better. Leaving the existing implementation alone may be the most responsible choice when:

• The current markup already describes the page accurately
• The proposed addition merely repeats existing information without improving clarity
• The page does not visibly support the proposed claim
• The desired relationship does not fit the vocabulary well
• The change would create a second, conflicting source of truth
• The relevant information is too uncertain or unstable to represent reliably
• The implementation belongs to a shared system that requires broader review
• The only motivation is eligibility for a feature that does not fit the page

Do not invent dates, credentials, affiliations, ratings, prices, services, locations, or other facts to fill available fields. Optional properties are choices, not blanks that must be completed.

The same principle applies to FAQ content. A page should not gain an FAQ section merely to make FAQ markup possible. Questions and answers should be added only when they genuinely help readers, and any associated structured data should be considered separately under current vocabulary and platform guidance.

Keep a small maintenance record

Structured-data changes can become difficult to understand when several systems contribute to the same page. A short maintenance note can preserve enough context for future editors and developers.

Record:

• The page or template reviewed
• The date of the review
• The source of the existing markup
• The issue or question investigated
• The documentation consulted
• The change made—or the reason no change was made
• The validation tools used and what each result established
• Representative URLs checked after publication

This does not need to become a large governance system. Its purpose is to prevent future maintainers from repeating the same investigation or accidentally restoring a known conflict.

Frequently asked questions

Does every webpage need structured data?

No. Structured data is useful when it accurately clarifies entities and relationships represented by a page. It should not be added solely because a type exists or because another page uses it.

Are multiple JSON-LD blocks on one page an error?

Not automatically. Multiple blocks can describe different related entities or contribute compatible information about the same entity. Review whether they complement, duplicate, disconnect, or contradict one another.

Does passing a validation test prove the markup is correct?

No. A test may confirm parseable syntax, vocabulary usage, or eligibility requirements within its scope. It does not independently verify every factual claim, guarantee a search feature, or establish that the markup is the best description of the page.

Should a page-level error always be fixed on that page?

No. If the markup comes from a shared template, theme, or plugin, the appropriate correction may belong at that shared layer. A local override can create duplication or make later maintenance more difficult.

Accurate description comes before additional markup

Reviewing structured data is an editorial and technical task. It requires understanding the page, identifying the entities it represents, inspecting the existing output, and tracing that output to its source.

Only then is it useful to decide whether something should be added, corrected, coordinated, or left alone.

For broader background, see Structured Data: A Practical Guide to Machine-Readable Meaning and Structured Data with JSON-LD. The durable principle remains simple: structured data should describe the page and its relationships accurately, without outrunning the content or the available evidence.