Structured data without content drift.

Model the publication before the vocabulary

Describe the domain rather than one consumer’s schema. An Article owns canonical path, headline, description, author, publication and modification times, image, body, evidence boundary, and indexability. A Product owns identity, offer state, price and currency, availability source, and review policy. JSON-LD serializes those facts.

Validate at ingestion or build: parse and order dates, pair amounts with currency, enforce unique canonical paths, check assets, and retain stable identifiers across deployments. Optional fields should mean absent facts, not missing data in a renderer.

Preserve date precision as well as value. An editorial date known only as July 19, 2026 should not acquire an invented midnight timestamp or timezone during serialization. Schema.org accepts Date or DateTime for dateModified. A visible day and a machine value should agree under the record’s declared precision; a genuinely timed event also needs its timezone policy. dateModified types.

Give shared entities stable identities

A page graph can connect WebPage, Article or Product, author, publisher, organization, breadcrumb, image, and dataset. Stable absolute IDs let those entities reference each other without divergent copies. A profile can maintain the Person while articles point to it.

Base IDs on the production origin and enduring routes or fragments—not hashes, random values, preview deployments, or environment-specific hosts. Domain changes need deliberate identity migration and, where appropriate, preserved equivalent public relationships.

Similar labels do not establish sameAs, authorship, or membership. Support those connections with maintained records and visible content. Extra connectivity cannot compensate for unreviewed assertions.

• Use canonical absolute URLs for public entity identifiers.
• Keep one identifier per enduring entity role.
• Reference shared entities rather than emitting divergent copies.
• Separate current identity facts from dated historical claims.
• Validate that every internal @id resolves within the generated graph.

Generate schema from validated records

Generate schema where validated records become public output, rather than inside a component with only fragments of the data. A pure function of record and site configuration produces a repeatable JSON-compatible object for snapshots, property tests, and output comparisons.

Choose the most specific applicable type after defining the page’s purpose. Its main entity should match visible, representative, current content, consistent with Google’s guidance. Hidden or unrelated claims remain defects even when a validator accepts their properties.

Keep consumer adapters separate. JSON-LD supplies serialization, schema.org supplies vocabulary, and individual search features impose eligibility rules. A consumer change should update its adapter without corrupting the domain record.

Shared generation prevents accidental divergence, but it can also publish the same wrong fact everywhere. If the source record misidentifies the author or invents an availability date, HTML/schema agreement will pass. Add provenance and an editorial check against the supporting source at ingestion; output consistency and factual correctness are separate tests.

function articleJsonLd(article: ArticleRecord, site: SiteConfig) {
  const url = new URL(article.canonicalPath, site.origin).href;
  return {
    "@context": "https://schema.org",
    "@type": "Article",
    "@id": `${url}#article`,
    mainEntityOfPage: { "@id": url },
    headline: article.headline,
    description: article.description,
    datePublished: article.publishedAt,
    dateModified: article.modifiedAt,
    author: { "@id": `${site.origin}/about#person` },
    image: new URL(article.artwork.socialSrc, site.origin).href,
  };
}

Compare the built outputs

Vocabulary validation may miss an h1/headline mismatch, an image returning 404, or sitemap dates changing on every build. Add invariants that compare generated outputs with their source record.

Parse built HTML to extract canonical, visible heading, date labels, image references, and JSON-LD. Resolve URLs against production, locate the main entity, and compare normalized values. File-check or fetch assets at the appropriate stage.

Test failure cases too: reject missing requirements before emission and future publication times unless scheduling is supported. Keep noindex routes outside the canonical sitemap. Reject shared unique entity IDs unless the pages intentionally describe the same entity.

For an illustrative revision, change an article’s current body while retaining its original publication day and historical research cutoff. The visible updated label, Article dateModified, feed and eligible sitemap lastmod should reflect the substantive edit. The original datePublished and dated source observations should survive. A rebuild with no content change should not advance any of those editorial dates.

Trace warnings back to the owning record

Date feature guidance and isolate vocabulary or consumer changes in tested adapters. Do not refresh historical publication facts to make markup look current. Apply a documented significant-change policy to modification dates.

Fetch representative production routes after middleware, caching, tag managers, and client execution can alter them. Parse delivered head and body, verify JSON-LD, and compare the public sitemap. If rendering changes schema, preserve source and DOM separately and reject contradictions.

Reproduce consumer warnings before editing. They may reflect optional fields, page types, or stale retrieval. Map a current warning to its domain field and change the source or adapter once. Agreement matters more than eliminating every validator warning.

• Document which changes qualify as dateModified and sitemap lastmod updates.
• Pin validation fixtures to representative page types.
• Store the built JSON-LD artifact used by release checks.
• Re-fetch production after cache and middleware layers.
• Route consumer warnings back to the owning domain field.
• Recheck source guidance before adopting newly recommended properties.

Test agreement, not just valid syntax

One maintained record reduces independent copies of facts. Compare its visible and machine-readable outputs after delivery as well as at build time. Coherence and feature eligibility do not promise a rich result, ranking change, or indexing outcome.

Sources

1. W3C JSON-LD 1.1 Recommendation

   Verified Jul 19, 2026

2. Google Search: introduction to structured data

   Verified Jul 19, 2026

3. Google Search: general structured data guidelines

   Verified Jul 19, 2026

4. Schema.org documentation

   Verified Jul 19, 2026

5. Google Search: build and submit a sitemap

   Verified Jul 19, 2026

6. Schema.org dateModified: Date and DateTime

   Verified Oct 16, 2026

   Checked allowed value types; preserving known precision is the author’s modeling recommendation.

Read next