Canonical versioning framework for GEO content

TL;DR

• AI engines treat citations as URL-anchored claims; breaking a URL or its semantic identity erases accumulated citation equity.
• The framework offers three patterns — URL replace (in-place rewrite), new URL with 301 (major reframe), version subpath (parallel canonical) — chosen by the magnitude of change.
• Every version carries a stable canonical_concept_id, a monotonic version, and isBasedOn pointing at the prior version so AI engines can chain provenance.
• Refresh cadence and dateModified discipline drive freshness signals; without them, AI engines reweight to fresher third-party sources.

Definition

A canonical versioning framework for GEO content is the combination of URL strategy, redirect strategy, schema strategy, and frontmatter contract used to ship new versions of evergreen content without losing AI citation equity. AI citation equity is the accumulated trust an article has earned in AI answer engines — it is anchored to the URL that engines have indexed and grounded against. When the URL changes without a clean redirect, or when the schema and dateModified drift out of sync, AI engines re-evaluate the page from scratch, often demoting it in favor of fresher third-party sources.

The framework is canonical because it builds on the existing canonical-URL primitives (Google Search Central, Schema.org Article) rather than inventing new ones. It is versioned because it explicitly models the lifecycle of a GEO article over years — v1, v2, annual refresh, retirement — and gives operators a deterministic path through each stage.

Why this matters

GEO content has a longer cite-life than classic SEO content. An AI engine that cited an article in 2024 may continue to cite it in 2026 if the URL is stable and the page still answers the canonical question. That long tail of citations compounds: each citation is a downstream signal that the page is the canonical source on a topic, which raises the probability of future citations.

This compounding only holds while the URL and the canonical claim remain coherent. The most common failure mode is a well-meaning rewrite that changes the URL (because the new article "is really a different topic") and breaks every existing citation overnight. The second most common failure mode is the in-place rewrite that keeps the URL but changes the canonical question, leaving AI engines holding citations that no longer reflect the article's content. Both are avoidable with a small amount of upfront discipline. The framework also matters for compliance: when an outdated claim is corrected, the audit trail ("what changed, when, why") needs to live somewhere AI engines can see, not in private CMS history.

How it works

The framework has three layers.

Layer 1: Decision tree. When an article needs an update, choose one of three patterns based on the magnitude of change:

Layer 2: Schema and frontmatter contract. Every version carries:

• canonical_concept_id — immutable across versions; it is the topic identity, not the URL identity.
• version — monotonic string ("1.0", "1.1", "2.0"); semver-style for major reframes.
• published_at — the original publish date; never changes after first publish.
• updated_at and last_reviewed_at — refresh on every meaningful edit.
• isBasedOn (Schema.org) — URL of the prior version, so AI engines can chain provenance.
• dateModified (Schema.org Article) — mirrors updated_at; emitted in JSON-LD for AI consumption.

Layer 3: Redirect and provenance discipline. Use 301 (or 308 for non-GET safety) for retired URLs (RFC 7231 §6.4); never 302 a permanent move. Maintain a small redirect map file in the repo so the audit trail is visible to engines that crawl /.well-known/changes or sitemap deltas. For major reframes, publish a public changelog block on the new version explaining what changed and linking back to the prior version.

Practical application

A workable rollout for a GEO content team:

1. Adopt the contract globally. Add canonical_concept_id, version, published_at, updated_at, and isBasedOn to the frontmatter schema for every article in the repo. Backfill via the slug for legacy content.
2. Codify the decision tree. Add a one-page decision aid in the editorial handbook and require every refresh PR to declare which pattern it applies. Reviewers reject PRs that change a URL without explaining the magnitude of change.
3. Automate dateModified and 301s. A CI job rewrites dateModified on any meaningful diff and validates that retired URLs return 301 with the expected target.
4. Annual review cadence. Every article receives a 12-month last_reviewed_at cycle: confirm freshness, decide whether to refresh in place, reframe with a new URL, or retire to an archive subpath.
5. Track citation equity. For high-traffic articles, instrument citation share-of-voice across ChatGPT, Perplexity, and Google AI Overviews before and after each version. A material drop signals that the change broke the canonical claim and needs revision.

Worked example

An article at /geo/what-is-geo originally published in 2024 still answers the canonical question in 2026 but references stale stats. The team chooses URL replace (Layer 1, row 1), updates the body and dateModified, increments version from "1.2" to "1.3", and leaves canonical_concept_id, published_at, and the URL untouched. Citation equity is preserved.

A second article at /geo/aeo-vs-geo-old-frame was originally framed as a head-to-head comparison; the team now reframes it as a strategic-positioning piece with a different audience. They choose new URL with 301 (Layer 1, row 2), publish at /geo/geo-strategic-positioning-framework, set isBasedOn to the old URL, and 301 the old URL permanently. Citations follow the redirect; the old article retires.

Common mistakes

• 302 redirect on a permanent move. AI engines treat 302 as temporary and may continue to cite the old URL indefinitely; use 301 (or 308 for non-GET) for permanent moves.
• Schema drift after rewrite. The body changes but the JSON-LD headline, description, and dateModified are not updated, so engines see contradictory signals and demote the page.
• Stale dateModified on refresh. Editing without bumping dateModified defeats the whole point of the refresh; AI engines treat the page as stale.
• Reusing a slug for a different topic. A new article at an old URL inherits the prior citation equity, but for a different claim. Engines reconcile by demoting both versions.
• No canonical_concept_id on legacy content. Without it, the team cannot cleanly chain provenance across reframes; every reframe starts from zero.
• Hidden changelog. Editorial teams keep a private changelog in their CMS but never expose it in HTML or schema. AI engines cannot infer that the page was carefully updated and may treat it as stale.

FAQ

Q: How is this different from classic canonical-URL guidance?

Classic canonical guidance focuses on duplicate-URL consolidation (parameters, sort orders, mirrors). The GEO versioning framework reuses those primitives but treats canonical URL as one input to a versioning decision over time, not a one-shot deduplication choice. The output is a lifecycle policy, not a dedupe rule.

Q: When should I publish at a /v2/ subpath instead of replacing in place?

Use /v2/ only when both versions need to be citable concurrently — typically standards documents (e.g., a published spec where v1 implementations still exist) or framework articles where downstream content explicitly references the prior version. For most editorial content, in-place replacement or new-URL-with-301 is cleaner.

Q: Does isBasedOn actually affect AI citations?

It is a Schema.org-defined property that AI engines parse from JSON-LD; it provides a machine-readable link from a new version to the prior version. Whether engines weight it specifically is implementation-dependent, but exposing it costs nothing and is the standard signal for provenance chaining.

Q: What about minor edits — should dateModified change for a typo fix?

Use judgment. Trivial typo fixes do not warrant dateModified updates because they do not represent a change to the canonical claim. Edits that change facts, examples, or recommendations should always update dateModified.

Q: How do I version a framework article that I expect to update yearly?

Use version: "1.x" for refreshes (1.1, 1.2) and version: "2.0" only when the underlying framework changes. Refreshes typically use URL replace; 2.0 may justify a new URL if the framework's canonical question shifts.

Q: How do I retire an article cleanly?

Move the URL to /archive/ with a 301 from the original URL. Set status: "archived" in frontmatter and emit a noindex directive. Keep the page accessible (do not 410 immediately) so AI engines can see the archive notice and gradually drop citations rather than experience a hard error.

Q: Can I use this framework retrospectively on legacy content?

Yes. Backfill canonical_concept_id based on the slug, set published_at from version control, and adopt the version field at the next refresh. Do not retroactively renumber existing versions — start from 1.0 at the next change and let history live in git blame.

Q: What metric tells me a version change broke citation equity?

Citation share-of-voice (across the AI engines that cite the article) before vs after the change. A drop greater than the typical week-over-week noise (commonly observed as ~10-15 percentage points for stable pages, based on practitioner reports) signals a regression that should be investigated.