Map article metadata to facts a reader can verify

1. Separate a vocabulary from a search feature

Schema.org defines ScholarlyArticle as a subtype of Article. This describes the kind of content. Google’s Article feature documentation separately lists Article, NewsArticle and BlogPosting and its supported properties. Do not assume that every Schema.org property or subtype has a dedicated Google feature. Choose truthful semantics, then verify the consumer’s documented requirements rather than claiming that a type name guarantees special treatment.

An editorial blog post about research is not automatically a published research article. Likewise, a public abstract page can describe a scholarly work without making its full text freely available. Decide which entity is being described: the work, its web page, an author or the journal. Keep those distinctions in the specification so that a site-wide publisher object is not accidentally reused as every article’s author.

Reference: Schema.org: ScholarlyArticle · Google Search: Article structured data

2. Freeze the facts used in the example

Our fictional article is “Documentation of inhaler technique in two clinics”. It has two approved authors, a complete public English abstract and first publication on 15 July 2026. A correction to an affiliation display was approved and published on 10 September 2026. The article’s public record describes that change. Its DOI and author ORCID identifiers have not been supplied for this exercise; neither can be filled from a plausible pattern.

An Arabic summary is available on a separate localized page, clearly labelled as a summary rather than an independently published study. The team has not yet agreed how that summary will be represented in machine-readable metadata. Preserve that open design decision. It would be misleading to label the English article body as Arabic simply because the navigation around it has been translated.

3. Write a field map before writing JSON-LD

The table is a specification for a fictional implementation, not a production snippet ready to paste. A developer must still choose the complete object structure, serialize it correctly and check the actual page. A field can be omitted when its value is unknown. An empty string, a made-up identifier or a link to the wrong person does not become useful because it satisfies a local presence check.

Google’s Article documentation distinguishes first-publication and modification dates and provides author-name and identity-link guidance. Its general structured-data rules require a faithful representation of the page. Apply that principle to every row: a value should have a source, an editorial owner and a visible counterpart or clearly documented role. Do not expand the abstract’s conclusion when creating a shorter machine-readable description.

Reference: Google Search: Article structured data · Google: structured data guidelines

On small screens, scroll the table horizontally, or focus it and use the arrow keys.

4. Test a plausible but wrong object

Suppose a fictional staging page passes a JSON parser, but its metadata says datePublished is 10 September, has three authors and describes a randomized trial. The visible record says 15 July, two authors and an observational report. These are content failures even if the markup is technically well formed. Send the differences to the responsible editor and developer rather than merely rerunning the same syntax test.

Correct the source of the values so that the next page build does not recreate the mistake. For example, an update timestamp should not feed the first-publication field. If the author array comes from a cached prior article, repair the record association. Rebuild and compare the final page’s embedded object with the visible article; inspecting a source-code template alone cannot prove what the deployed page contains.

5. Review multilingual identity without duplicating a study

Decide whether a localized page contains a complete translation, an abstract translation or a short editorial summary. Tell readers which it is, retain the link to the authoritative work and check titles and author names in both languages. Do not assign a new article identifier just because a translated page has a different address. Ask the publishing and metadata owners to resolve the representation before releasing it.

For this example, the English article specification can proceed independently while the Arabic-summary metadata remains an open item. The Arabic page may still provide a clear visible summary and citation, but its markup must not invent a full translated article. A bilingual reviewer should check that uncertainty, numerical denominators and study design survive the translation; matching page layout is not evidence that the scientific meaning matches.

6. Record what each validation step establishes

Use a local parser for syntax, a vocabulary-aware validator for type and property questions, and an editorial comparison for identity and meaning. Google recommends its Rich Results Test and URL Inspection for its own features. A tool may report that it recognizes no supported feature while the underlying Schema.org description is meaningful; investigate the exact message instead of treating all validators as interchangeable.

Keep the tested URL, date, relevant output and unresolved issues. Do not report a Search Console inspection that nobody performed. Google also says that AI-search inclusion has no additional technical requirements and is not guaranteed. For the publisher, the defensible completion statement is that a particular deployed page was checked against its approved record and selected documentation. Appearance in search, citation by an AI system and later readership require separate observations.

Reference: Google Search: Article structured data · Google: AI features and websites

Questions for a practical final check

• Article, page, journal and author entities distinguished
• Every field traced to the approved record
• Publication and correction dates preserved separately
• Unknown DOI and ORCID values omitted
• Localized summary described accurately
• Syntax, semantic comparison and provider inspection recorded separately