Citation URL Redirects Need Two Records, Not One

AI citation reporting should preserve two records when a cited URL redirects: the URL the answer actually cited, and the destination found when an analyst later resolved it. Replacing the observed URL with its current destination destroys historical evidence and makes citation counts impossible to reproduce.

The rule is simple: observation is immutable; resolution is time-bound enrichment.

Why citation URL redirects create a measurement error

A citation event answers a historical question: which URL did the AI answer expose at the time of observation? A redirect check answers a different question: where did that URL lead when it was tested later?

HTTP keeps those facts separate. The HTTP Semantics standard defines redirection as a response that tells a user agent further action is needed, often through a Location field pointing to another URI. It distinguishes permanent and temporary redirect status codes, including 301, 302, 307, and 308 (RFC 9110). The redirect target is therefore a response discovered during resolution. It is not a retroactive edit to the URL that appeared in the original answer.

This matters because redirect state can change. A URL may point to page B today and page C next month. It may stop redirecting, begin returning an error, or pass through several destinations. If an analytics pipeline overwrites the cited URL every time it resolves the chain, the historical record changes whenever the web changes.

The result is false precision. A report may claim that an engine cited the final destination even though the answer never displayed that URL.

The citation record should separate observation from resolution

A durable citation record needs an observation layer and a resolution layer. The observation layer stores what the answer showed. The resolution layer stores what a later network check discovered.

Field	Observation record	Resolution record
URL	Exact cited URL as displayed or extracted	Final destination reached during the check
Time	Answer observation timestamp	Resolution timestamp
Status	Extraction or citation-presence state	Ordered HTTP status sequence
Identity	Engine, prompt, answer run, citation position	Resolver, user agent, timeout, redirect limit
Canonical data	None unless present in the observed answer payload	Canonical hint found at the resolved page
Mutability	Append-only historical evidence	New version for every later check

This split follows a broader provenance principle. The W3C PROV family treats provenance as information about the entities and activities involved in producing or delivering data, and models derivation separately from the source entity (W3C PROV Overview). In citation measurement, the raw cited URL is the source observation. The resolved destination is derived data produced by a later activity.

The derived record can be corrected or refreshed without rewriting the observation.

A worked citation redirect chain

Consider this explicitly hypothetical answer observed on September 12, 2026:

• Observed cited URL: https://example.org/reports/ai-market-2024
• Answer observation time: 2026-09-12T14:05:00Z
• Citation position: 3
• Engine: Example Answer Engine

An analyst resolves that URL two hours later and records this chain:

1. https://example.org/reports/ai-market-2024 returns 301 with a Location value pointing to /research/ai-market.
2. https://example.org/research/ai-market returns 302 with a Location value pointing to https://data.example.net/ai-market-report.
3. https://data.example.net/ai-market-report returns 200.
4. The final page declares https://data.example.net/ai-market-report as its canonical URL.

The report should not replace the first URL with the third. It should retain the citation event exactly as observed, then attach a resolution event:

Reporting field	Hypothetical value
observed_url	https://example.org/reports/ai-market-2024
resolved_url	https://data.example.net/ai-market-report
resolved_at	2026-09-12T16:05:00Z
status_chain	301 → 302 → 200
redirect_hops	2
canonical_hint	https://data.example.net/ai-market-report
same_registrable_domain	false
resolution_outcome	resolved

RFC 6596 defines the canonical link relation as a preferred identifier among resources with duplicative content (RFC 6596). That makes a canonical link useful enrichment. It does not prove that the observed citation used the canonical URL, and it should not replace the observed URL in the historical row.

Which URL should an AI citation report count?

A report must declare its counting unit before it aggregates redirects. There is no honest universal answer because each unit answers a different question.

Counting unit	What one citation means	Best use	Main risk
Observed URL	The exact URL exposed in the answer	Reproducible answer audits	Splits aliases that resolve to one resource
Resolved URL	The final destination at a stated time	Current destination analysis	Changes as redirect behavior changes
Canonical hint	The page's declared preferred URL	Duplicate-content reconciliation	A hint is not the original citation event
Registered domain	Citation assigned to the domain after normalization	Domain share-of-citation reporting	Hides page identity and cross-domain redirects
Content identity	Multiple URLs grouped after a verified content match	Resource-level research	Requires explicit matching rules and versioning

Observed-URL counts should be the base ledger. Every normalized view should be derived from that ledger and should name the normalization rule, resolution time, and version.

This avoids a common denominator error. AI citation rate measures how often a source is cited across a defined set of answer runs. Share of citation compares cited-source incidence within a defined market or prompt set. Neither metric is interpretable if the reporting system silently changes source identity after collection.

A domain-level report may reasonably group old and new URLs under the same domain. A page-level report may not. A cross-domain redirect requires even more care because the observed publisher and the current destination owner are different facts.

Redirects, canonicals, and source ownership are separate signals

Redirect targets and canonical hints can help reconcile duplicate or moved pages, but they should not be treated as interchangeable truth.

Google's current Search documentation describes redirects and rel="canonical" annotations as strong canonicalization signals while noting that Google may still choose a different canonical URL (Google Search Central). That documentation governs Google's indexing choices. It does not establish how every AI answer engine records, displays, or values a cited URL.

An AI visibility system should therefore store at least three identities when available:

1. Observed identity: the URL shown in the answer.
2. Resolved identity: the destination reached at a specific time.
3. Declared identity: the canonical hint asserted by the destination page.

Those values may match. They may also disagree. The disagreement is useful evidence, not a data-cleaning nuisance.

For example, an observed URL on a publisher domain may redirect to a vendor's owned site while the destination declares itself canonical. A domain-normalized dashboard could assign the citation to the vendor. A historical answer audit should still show that the engine exposed the publisher URL. The first view describes current destination ownership. The second describes the actual answer surface.

A reporting convention for citation URL redirects

A practical convention can be expressed in five rules.

1. Never overwrite observed_url. Store the exact extracted string and the answer timestamp.
2. Append resolution events. Each check gets its own timestamp, status chain, final destination, and resolver settings.
3. Version normalization rules. A change from full URL to domain grouping should create a new report version, not mutate old totals.
4. Expose unresolved states. Distinguish timeout, blocked request, redirect loop, missing Location, extraction failure, and terminal error.
5. Name the counting unit beside every metric. Use labels such as observed URL citation rate, resolved-domain share of citation, or canonical-resource count.

The fifth rule is the one readers can verify. A percentage without a source-identity rule is not an audit trail. It is a dashboard preference disguised as measurement.

Machine Relations needs provenance, not just citation totals

Machine Relations treats AI visibility as a source system: brands become legible through retrievable pages, third-party corroboration, entity clarity, and evidence that answer engines can reuse. Redirect reconciliation belongs in that system because a citation is both an answer event and a claim about source identity.

The measurement layer should preserve what the machine exposed before it interprets where the link leads now. That makes historical citation data defensible when sites migrate, publications consolidate URLs, tracking parameters disappear, or ownership changes.

The operating standard is narrow: keep the observed link, record the resolution separately, timestamp both, and state which one the report counts.

FAQ

Should a citation redirect count for the original URL or the destination?

Count the original observed URL in the base citation ledger. A report may also count the resolved destination or domain in a derived view, but it should name that normalization rule and the time when the redirect was checked.

Is a canonical URL the same as a redirect destination?

No. A redirect destination is reached through an HTTP redirection response. A canonical URL is a preferred identifier declared through a canonical link relation or selected by a platform. They may match, but one should not be inferred from the other without evidence.

How often should citation URLs be resolved again?

There is no universal interval. Resolution frequency should follow the report's purpose and risk tolerance. Each check should create a new timestamped resolution event so analysts can compare changes without rewriting the original citation observation.

What should happen when a citation URL enters a redirect loop?

Record the observation as valid if the URL appeared in the answer, then mark the resolution outcome as a loop with the observed status sequence and redirect limit. Do not convert the event to an uncited answer or guess a final destination.