Technical SEO
One page identity for metadata and dates
Generate the title, canonical, author and structured data from the document, preserving the precision of its dates.

A page can validate as JSON-LD while naming the wrong essay. I use the document record to generate the visible identity, metadata and dates, then compare those outputs. Syntax checks alone miss that disagreement.
Method & limits
The retained source sample is dated July 16, 2026; the worked canonical/Open Graph case is illustrative and dated October 22. Google’s canonical guidance and RFC 6596 were checked October 25, 2026 for content equivalence and the limits of graph agreement. Other guidance retains its July 19 and October 16 cutoffs. No site-wide graph, delivered repair, Google-selected canonical or ranking outcome was newly measured; code and examples remain design methods.
JSON-LD is another projection of the document
The same problem appears inside a page. An h1 can name one essay while Article JSON-LD names another; an updated label can preserve the old date while the sitemap claims today. Syntax validation can accept every output. It never checked whether they agreed.
Model the publication before the vocabulary. The article record owns its headline, author, dates, image and canonical identity. A pure serializer projects those validated facts into JSON-LD, while stable absolute IDs connect the WebPage, Article and shared author. Preview hosts, random values and build hashes are poor foundations for an enduring public entity.
Vocabulary and consumer rules also need different owners. JSON-LD defines serialization, Schema.org defines terms, and a search feature has eligibility requirements. An adapter can track a consumer change without distorting the article record. Hidden or unrelated claims remain wrong even when their vocabulary validates.
The generator below removes independently edited headlines and dates from the output path. That protects agreement, while leaving a common source of error: a wrong author in the record now appears correctly serialized everywhere. Compare outputs with the manuscript and its evidence as well as with one another. A second projection of the same mistaken input is not an independent check of the fact.
The function receives validated content, including the author’s maintained absolute authorId, and emits no independently maintained facts.
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": article.authorId },
image: new URL(article.artwork.socialSrc, site.origin).href,
};
}A day should not acquire an invented instant
If the source says July 19, 2026, keep that precision. Serializing an invented midnight and timezone makes the data look more exact while adding a fact nobody supplied. Schema.org accepts Date or DateTime for dateModified; timed events need a declared timezone policy, while a known editorial day can remain a day. Allowed date values.
A substantial edit can change the visible updated label, Article dateModified, feed and eligible sitemap lastmod. Keep the publication date and historical source cutoff: a better explanation today does not make the research newer. A rebuild with unchanged content should advance none of those dates.
Amounts need currencies, images need reachable assets, and shared entity IDs need uniqueness or an intentional equivalence. These are domain invariants that belong before output, followed by comparisons of the built representations.
| Invariant | Inputs compared | Failure prevented |
|---|---|---|
| title agreement | h1, title, JSON-LD headline | Conflicting page identity |
| URL agreement | route, canonical, @id, sitemap loc | Competing canonical records |
| date agreement | visible label, JSON-LD, sitemap lastmod | False or stale freshness |
| image integrity | visible image, schema URL, built asset | Broken or unrelated media claim |
| indexability alignment | robots directives, route policy, sitemap | Noindex URL nominated as canonical |
| entity uniqueness | @id set across built routes | Accidental identity collision |
Sources
- Google Search: canonical URL consolidationVerified Jul 19, 2026
- Google Search: redirects and canonical signalsVerified Jul 19, 2026
- Google Search: build and submit a sitemapVerified Jul 19, 2026
- Sitemaps XML protocolVerified Jul 19, 2026
- RFC 6596: The Canonical Link RelationVerified Jul 19, 2026
- RFC 3986: Uniform Resource Identifier generic syntaxVerified Jul 19, 2026
- W3C JSON-LD 1.1 RecommendationVerified Jul 19, 2026
- Google Search: introduction to structured dataVerified Jul 19, 2026
- Google Search: general structured data guidelinesVerified Jul 19, 2026
- Schema.org documentationVerified Jul 19, 2026
- Schema.org dateModified: Date and DateTimeVerified Oct 16, 2026
Checked allowed value types; preserving known precision is the author’s modeling recommendation.
- Retained Quotes to Scrape source-capture manifestJul 16, 2026
Two source captures; this does not include a measured browser render.
- Open Graph protocol: basic metadata and og:url object identityVerified Oct 22, 2026
Social object identity is distinct from Google’s documented canonicalization signals.