Schema cannot make an empty page authoritative.

First inspect the markup the site already publishes. Themes, plugins and custom code can describe the same page differently. Choose the applicable schema, match it to visible content and validate the result before adding another block.

Describe the page accurately

Markup has a modest but important job: describe the page consistently. It becomes a problem when a publishing system gives it a more impressive identity than the visible content supports. An old author, a fresh date on unchanged copy or conflicting article descriptions can all survive a basic syntax check. Match the data to the actual page first. Then validate the applicable requirements. Neither step supplies the experience, evidence or originality the writing itself needs.

Google’s structured-data introduction explains how markup helps describe page content and eligibility for applicable search features. Eligibility does not mean a feature will be displayed.

Start with the page, then choose the markup

For an article, identify the real headline, author and publication information. For an organisation, use the actual name and relevant identity details. Do not label a service page as a product review or invent ratings because a plugin offers those fields.

The test is simple: could a reader find and understand the information represented in the markup? If not, review whether the markup belongs there and whether the visible page needs improvement.

Audit what your tools already output

WordPress themes, SEO plugins and custom templates can each produce structured data. Adding another snippet without checking the existing output can introduce conflicting names, dates or descriptions.

Inspect representative pages rather than assuming a global setting works everywhere. A template change may leave an old author, a default organisation name or a publication date that does not match the article.

A practical release checklist

A validation pass catches structural problems. It does not certify that the underlying claims are truthful or that the page deserves to rank. Those are editorial responsibilities.

Keep expectations proportionate

Google’s AI features guidance states that no special schema is needed for its AI search features. My priority would be correcting inaccurate markup and improving useful information before purchasing an elaborate “AI schema” package.

Other systems may process structured information differently. That uncertainty is a reason to make the data clear and accurate, not a reason to promise a secret universal format.

For broader visibility decisions, start with GEO without the hype. If the page is not discoverable or indexed, diagnose that through the technical SEO audit before adding more markup.

Make maintenance part of publishing

When a headline, author detail or page address changes, review the corresponding structured data. When you update an article substantially, ensure any date change reflects real work rather than an automated freshness signal.

A reliable template saves effort. It should expose the fields you need, avoid invented defaults and make the output easy to inspect. Good implementation becomes ordinary infrastructure rather than a recurring sales pitch.

Mark up the article you actually published

For an article page, start with the facts already visible: headline, actual author, publication date and the current page address. The structured version should agree with them. If the page names Amine as author, do not substitute an invented editorial team because it sounds larger.

I would validate the markup, compare its values with the rendered page and inspect the deployed source. Passing a syntax check is only the first gate. A technically valid description of the wrong content is still wrong.

Do not add ratings, reviews, prices or product claims just because a markup generator offers those fields. They need to describe eligible, genuine page content and meet the applicable requirements. Choose the type based on what the page is.

Repair a weak answer before polishing its markup. Structured data should accurately describe the expertise and evidence actually present.

Catch duplicate markup before adding another plugin

Inspect the deployed article’s structured-data blocks. List which template, plugin or application produces each one. Compare the headline, author, publication date and page URL across the outputs.

When two blocks describe the same article differently, resolve ownership instead of adding a third version. Keep the implementation that accurately represents the visible page and meets the applicable requirements. Do not remove unrelated entity descriptions simply because multiple blocks exist.

Repeat the check after a substantive edit and after a template change. A correct validator result does not establish that the author or date is truthful. The acceptance test includes agreement with the published content. Assign one owner for that agreement so conflicting values do not return on the next release.

Create a field-ownership sheet

For each important property, identify its source and who updates it. The headline may come from the article title, the author from a profile and the publication date from the CMS. If the field is entered manually in several places, document how consistency is maintained.

This sheet makes handover easier. The next editor should not need to reverse-engineer a custom snippet to understand why the page describes the wrong person or address.

Validate in layers

First, validate the format and syntax. Next, check the properties against the visible page. Then inspect representative published URLs and any applicable search-tool feedback. Each layer answers a different question. Valid JSON does not establish accurate authorship, and correct authorship does not guarantee a displayed search feature.

Test more than the best-looking example. Include an older article, a recently updated one and a page with a different template. If the site offers multiple languages, check how the identities and URLs appear on those versions too.

After a template release, repeat the relevant checks. A shared component can change dozens of pages, so the acceptance process should include the output it generates, not merely whether the website loads.

Avoid three common shortcuts

The first shortcut is adding review markup to claims that are not genuine reviews. The second is describing content with a type that does not fit, hoping it will earn a more prominent result. The third is treating a special “AI schema” package as a substitute for clear information. Each turns implementation into appearance management.

A better approach starts with the truth of the page. If you want stronger author information, improve the genuine profile and connect it consistently. If you want a clearer service description, rewrite the visible offer. Markup should represent those improvements, not stand in for them.

Two valid descriptions can tell different stories

A theme and a plugin can both output valid article data while disagreeing about the author, date or preferred page. Syntax validation will not decide which description is true.

Compare each output with the visible content and identify the responsible producer. Resolve the disagreement at its source. More than one block is not automatically wrong; competing descriptions of the same entity need attention.

After the correction, repeat the check on a deployed page and a recently edited article. Keep the original publication date intact and use modification dates for actual updates. The maintenance task ends when the page and data agree, not when a validator has stopped showing errors. That standard survives the next template change.

Settle who owns the company description

A B2B website can have several correct descriptions of the same business: the company profile, the offer page and the author biography. That does not mean they should be interchangeable. Agree which record owns the company name, URL, contact information and commercial description. Use that source in the page templates. An article author should describe the person responsible for the work; an offer page should describe the service being considered. A plugin does not make that editorial choice for you.

Keep a simple change register when a service is renamed or its scope changes. Identify the visible pages, structured fields and template owner that need updating. Check the rendered result after release, including older articles using the same component. The purpose is consistency, not making every page repeat the homepage promise. A specific implementation guide can still have a specific title and description while using the same accurate company identity.

A release check that a nontechnical owner can follow

Choose one commercial page, one article and one author page. Save their URLs and the expected descriptions. Ask the implementer to show the relevant structured fields alongside the visible content. The reviewer can then check whether the names, descriptions and links refer to the same things. Record missing or conflicting values as tickets with an owner, rather than silently adding another layer of markup.

The technical validation is still needed; this check does not replace it. It adds the editorial question that a validator cannot settle: does the field accurately represent the page and the business? A valid description of an outdated service remains an outdated description. A correct author record does not make an unsupported article claim credible.

After a template change, repeat the sample check and confirm that old markup has not remained alongside the replacement. Keep the result with the release record. If the business later changes its positioning, the next owner can see where the company description comes from and which checks need to be repeated. That is a more durable output than a screenshot showing that a single page passed once.

Markup, eligibility and realistic expectations

Should every article have FAQ schema?

Only use markup that applies and follows the relevant feature guidelines. Visible FAQs can help readers without a promise of a search enhancement.

Does valid schema mean our SEO is healthy?

No. It is one check. Content relevance, access, internal discovery and user experience still need separate evaluation.

Sources and further reading

Google Search Central: Article structured data: Article properties and validation requirements.

Google Search Central: structured data overview: Markup purpose and eligibility limits.

Google Search Central: AI features and your website: Google AI eligibility and reporting boundaries.

References checked 9 October 2026. Sources support the documented facts and tool behaviour; the recommendations and worked examples explain how I would apply them.