Article Schema: Authors, Headlines and Honest Dates

Confirm that the resource is an article.

Article describes an editorial work. A detailed resource can fit this role, but length alone does not turn a product catalogue, business profile or service offer into an article. A WebPage is the containing page; an Article node identifies the editorial work it presents.

Choose the subtype that fits the work and the intended consumer. Schema.org includes editorial subtypes, while Google’s Article feature documentation specifically describes Article, NewsArticle and BlogPosting. A vocabulary subtype’s existence does not establish a separate Google feature.

Gather the approved headline, visible byline, author identity route, publisher record, publication history, revision record, canonical URL and relevant images before planning fields. A missing record is a missing input; it is not a reason to invent a plausible author or date.

Distinguish author, reviewer and publisher.

The author created the work; a reviewer checked it; the publisher released it. One person or organization may perform more than one role, but the relationship must be supported. Do not silently assign authorship to the site owner or the most prominent person in the navigation.

Match the marked author to the visible byline and a stable Person or Organization identity as appropriate. Use a specific identity route where available, particularly when names could refer to different people. Different genuine authors can be represented separately instead of squeezing a list into one invented person.

Keep the publisher distinct from the author and the WebSite. Reference an accepted organization identity rather than generating a new publisher node for every resource. Do not add credentials, employer relationships, awards or external identity links without evidence. A generator’s default author is not evidence of authorship.

Report editorial events rather than template activity.

datePublished records when the work was first published; dateModified records a real modification. A scheduled rebuild, new footer, automatic timestamp or daily cache refresh does not establish an editorial revision. Preserve the original publication event where it is known.

Use the editorial log to identify what changed, when, who approved it and if the visible date should change. Correcting a technical instruction or adding a detailed explanation differs from changing a navigation colour. Do not change dates to create an impression of current research that did not happen.

Keep displayed dates and machine-readable fields consistent. If a timestamp is known, preserve its timezone; do not invent an exact hour from a date-only record. If the publication date is unknown, hold or omit the unsupported assertion rather than copying the file creation time.

Match the headline, images and page relationship.

The headline should identify the editorial resource the reader sees. A short title variation can serve a legitimate context, but a keyword-filled headline unrelated to the visible work misdescribes it. Keep the article’s page relationship tied to the approved canonical address.

Use images that belong to and help explain the article. Confirm relevant image URLs, crawlability and rights before using them as structured data. Do not substitute a corporate logo for a documentary article image merely to fill a field or copy unrelated image URLs from another resource.

Schema.org Article supplies the vocabulary; the current platform resource governs its own consumer requirements. Google currently recommends applicable Article properties rather than declaring a universal required-property list. That does not make unknown author, date or image assertions acceptable.

Worked annotation: a documented teaching resource.

This example is a fictional editorial record, not a claim about a real person or a Semantec publication. The imaginary resource “Reading a Source Record” at example.com/guides/source-record/ visibly names Ada Example as author and Example Learning Press as publisher.

Its fictional publication log records first release on 1 September 2026. A second entry records that Ada corrected the version-selection explanation on 12 October 2026 and the editor approved that correction. A footer template change on 20 October does not change the editorial record.

The planned Article uses the resource’s visible headline, Ada’s documented author identity, the publisher’s accepted organization ID and the two supported editorial dates. mainEntityOfPage connects the work to its WebPage. These example.com identities are teaching placeholders, not production graph assertions.

The review record does not identify a second author, an award, a rating or an image with cleared rights. Leave those assertions out. If the live byline disagreed with the log, hold author finalization and resolve the contradiction before publishing a graph.

Review the whole output after a change.

Compare the graph with the visible headline, byline, date labels, publisher and canonical. Check plugin and template output together; contradictory duplicate Article blocks cannot be fixed by testing only the new block in isolation.

Use a vocabulary validator for type/property structure and a supported-feature test for the intended Google consumer. Later inspect the live rendered page and technical access. Parsing successfully or passing a test does not guarantee indexing, ranking, selection or an richer result.

Keep the evidence record, owner, accepted fields, omissions and next review trigger. Reopen the record when authorship is corrected, the work is meaningfully revised, the canonical changes or consumer guidance changes.

Carry the editorial record into the page graph.

Return to the structured data overview or learning overview. Review page, site and breadcrumb identities when the work and its containing page have been confused.

Google’s general structured data guidelines require truthful correspondence with content. The Schema.org data model explains types and property relationships; it is separate from feature selection.