Article Schema: Implement Accurate JSON-LD

Describe the work actually published

Begin with the page’s purpose. An educational article, a news report and an archive listing do different jobs. Choose a type that describes the work rather than the search treatment you hope to receive. The Schema.org Article vocabulary defines properties for an article and its relationships. A blog article can use BlogPosting, while a news report may fit NewsArticle. Do not apply a news label to an evergreen commercial guide just to make the record look more important.

Google’s Article documentation supports Article, NewsArticle and BlogPosting records and identifies recommended properties. The practical goal is a coherent description of the article users can read. A category archive containing summaries should not pretend to be every complete article at once. Keep the structured record aligned with the actual resource delivered at that URL.

Before coding, write down the visible headline, the preferred article address, the actual authoring role, the publisher and the known dates. Locate the representative image and confirm that it belongs to this article. This small field inventory exposes missing or conflicting facts early. It is easier to resolve an unclear byline at the content level than to choose a convenient name inside a JSON object and discover later that the page says something different.

Build a small record with explicit relationships

The example below describes a fictional article from a fictional publication. Its example.com addresses and sample people are teaching data, not facts to copy into a production identity. The record uses a stable article identifier ending in #article; the canonical page URL identifies the web destination. These addresses are related without pretending that a document and the person who wrote it are the same thing. The distinction becomes useful when many articles reference one author or publisher.

The author and publisher are deliberately separate. Maya Chen is the illustrative writer; Field Notes is the illustrative publishing organisation. In your own publication, use the actual responsible parties. An organisation can be an author where that accurately reflects the attribution. Do not list a founder as the personal author of every page merely because the founder owns the brand. The Person schema guide covers the full person record, while Organisation schema covers the shared publisher identity.

A short record is easier to audit than a large object filled with guessed achievements, affiliations or external profiles. Add a property when it expresses relevant supported information. If your data model stores a property once, reuse that value wherever the same fact is needed. This prevents an author’s name or the article’s preferred URL from drifting across the visible page, social metadata and structured data.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/guides/filter-care#article",
  "mainEntityOfPage": "https://example.com/guides/filter-care",
  "headline": "How to Care for a Reusable Filter",
  "image": "https://example.com/images/filter-care.jpg",
  "datePublished": "2026-08-04T09:00:00+01:00",
  "dateModified": "2026-09-02T14:30:00+01:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/maya-chen#person",
    "name": "Maya Chen",
    "url": "https://example.com/authors/maya-chen"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#publisher",
    "name": "Field Notes",
    "url": "https://example.com/"
  }
}

Keep publication history separate from release time

Use the original publication timestamp for datePublished. Use dateModified for a substantive later article update when that information is available. Include a timezone offset or UTC designation so the value describes an actual moment rather than an ambiguous local clock. Google’s publication-date guidance discusses visible and structured dates together. Your implementation should preserve their consistency instead of generating different values independently.

In the fictional example, the guide first appeared in August and was meaningfully revised in September. A later deployment that only changes the footer should not silently rewrite its publication history. Store the dates with the content record. A build process can render those values in a readable local format for people while retaining their precise machine-readable form. If an imported article lacks a trustworthy modification date, investigate the available history rather than inventing a recent revision.

Check the chronology as well as the format. A valid ISO timestamp can still be wrong: modification may precede publication, a timezone conversion may shift the visible day, or an import may have used the migration date for every original article. Keep a small release sample containing the stored values, emitted JSON and visible dates. The content freshness guide explains when an editorial change warrants an update; this implementation must faithfully carry that decision through the page.

Generate JSON without creating a second content system

Construct an ordinary data object from the published article record and serialize it as JSON. Avoid manually concatenating quoted strings around titles and descriptions. A headline containing quotation marks can break that approach even when simple test titles work. If the JSON is embedded in an HTML script element, use a framework-supported safe serialization approach that also handles characters capable of ending that element. JSON validity and safe HTML embedding are related but separate implementation concerns.

Keep the source of truth narrow. The content record should provide the article headline and dates; a shared publisher record should provide the organisation identity. The canonical URL builder should supply the destination. A second hand-maintained schema file containing copies of those facts creates another place an editor must remember to update. The Next.js SEO guide covers how route data and metadata connect in that framework; the same consistency principle applies in other publishing systems.

Inspect for duplicate emitters when a CMS plugin and custom template both generate Article records. Two identical descriptions are usually unnecessary, while conflicting descriptions create a real maintenance problem. Determine which component should own the record and remove or reconfigure the other deliberately. Do not add a third object as an attempted correction. The goal is a dependable public description, not a larger volume of structured text.

Validate the record against the visible article

Run a JSON parser first, then use the relevant structured-data test to inspect recognised types and properties. These checks can expose malformed syntax or an unexpected shape. They cannot establish whether Maya actually wrote the article or whether the image is genuinely representative. Perform a separate factual comparison against the page: headline, authoring role, publisher, dates, image and preferred address should tell the same story.

Check the image URL as an actual resource. It should resolve to the intended visual, rather than a missing file, a login response or a generic logo substituted for the article’s subject. Google’s Article guidance specifically asks for images representative of the content. Keep a missing image from being silently replaced by an unrelated asset merely to populate a field. If your design crops an image differently for cards and article headers, make sure the underlying representation remains appropriate.

Test more than the easiest article. Include a title containing punctuation, an organisation-authored page, an older revised article and a route that does not exist. The missing route should not emit a fabricated Article record using generic defaults. The HTTP status guide explains response semantics, while technical release checks covers verifying the actual production output. A copied example passing validation does not prove that all dynamic routes produce correct records.

Maintain the relationships after publication

An author profile can move, a publisher can rebrand and an article can gain a substantial correction. Treat each change according to what actually changed. Updating an author’s biography does not necessarily create a new person identifier. Moving an article may require revisiting its URL relationships and redirects. Changing the publisher’s displayed name should be coordinated across the shared identity record and visible organisational pages. These are information-maintenance tasks, not reasons to regenerate every field on every build.

Keep a release check that compares the structured article identifier and page URL with the intended destination. Verify that any shared author or publisher reference still identifies the right party. Record the reason for material changes so a future editor can distinguish a genuine transition from an accidental mismatch. In a large library, these relationships are easier to maintain when they come from a few deliberate records rather than repeated free-text copies.

Judge the completed implementation by its accuracy and reliability. The record should parse, describe the published article truthfully, preserve its history and remain consistent after a normal content update. Search systems decide how to use eligible information in their own experiences. Article schema strengthens a clear description of the work; it does not turn an unsupported claim into evidence or replace the useful explanation readers came to find.

Sources and further reading

• Google: Article structured dataDocuments supported article types, recommended fields, author handling and representative image guidance.
• Google: publication datesExplains communicating publication and update dates consistently.
• Schema.org: ArticleDefines the article vocabulary and relationships used in the illustrative record.