How to Audit Where AI Answers Actually Send Users

An AI answer can mention a brand, cite a source, and still send the user somewhere unhelpful.

The displayed citation may resolve through a redirect. The final page may be an old article, a marketplace listing, a review site, or a URL that no longer works. Some interfaces show a publisher name without exposing the full destination until a click. Others include a brand name but no outbound link at all.

That is why AI visibility needs a destination-access audit in addition to mention and citation counts.

Define the unit of analysis

Use the prompt run as the parent record.

One answer can contain several citations and links, but it is still one visibility opportunity. Store outbound destinations as child records instead of treating every link as a separate answer-level win.

A parent run might contain:

{
  "run_id": "run_2026_08_03_001",
  "prompt_id": "comparison_smb_analytics_01",
  "benchmark_version": "v3",
  "provider": "example_provider",
  "interface": "web_search",
  "collected_at": "2026-08-03T12:00:00Z",
  "response_text": "...",
  "entity_id": "brand_123",
  "mention_role": "shortlisted"
}

Each link record should reference that run.

Preserve four URL states

Do not normalize a citation into one URL and discard the rest. Keep at least four states:

1. Displayed destination: the label or URL visible in the answer interface.
2. Raw href: the exact link attached to the visible element.
3. Resolved destination: the final URL after redirects.
4. Canonical destination: the page's declared or analyst-approved canonical URL.

These fields answer different questions.

The displayed destination shows what the user sees. The raw href preserves the interface output. The resolved destination reveals where the click actually lands. The canonical destination supports deduplication across tracking parameters and equivalent URLs.

A link record can look like this:

{
  "link_id": "link_0042",
  "run_id": "run_2026_08_03_001",
  "display_label": "Example publisher",
  "raw_href": "https://redirect.example/xYz",
  "resolved_url": "https://publisher.example/reviews/product?utm_source=ai",
  "canonical_url": "https://publisher.example/reviews/product",
  "http_status": 200,
  "captured_at": "2026-08-03T12:00:03Z"
}

Never overwrite the raw value with the normalized one.

Classify destination ownership

The final URL should receive an ownership class. A conservative taxonomy is:

• Owned product: a product, service, pricing, or signup page controlled by the entity.
• Owned editorial: an article, guide, documentation page, or research page controlled by the entity.
• Owned profile: an official social, marketplace, or directory profile controlled by the entity.
• Independent editorial: a publisher, analyst, or journalist page not controlled by the entity.
• Independent review: a review or comparison platform.
• Marketplace: an app store, extension store, reseller, or integration marketplace.
• Aggregator: a directory or database that summarizes multiple entities.
• Unknown: ownership cannot be established from the evidence.
• Invalid: the destination fails, loops, or produces a blocked response.

Do not infer ownership only from the displayed publisher name. Resolve and inspect the destination domain.

If a corporate group owns several domains, keep both the registrable domain and the normalized owner ID. That prevents a subsidiary or documentation subdomain from being misclassified as independent.

Record interface accessibility

A link that exists in source data may not be equally accessible to a user.

For every captured destination, record:

• clickable in the captured interface
• visible without an extra interaction
• exposed only after expanding citations
• displayed as a full URL, publisher label, favicon, or numbered citation
• opens in the same tab or a new context
• requires sign-in
• blocked by a warning or interstitial
• available on mobile, desktop, or both

This is not only a technical detail. A brand can have strong citation coverage and weak referral opportunity if users cannot easily reach the owned domain.

Follow redirects carefully

Resolve redirects with a bounded, auditable process.

Recommended fields include:

• redirect hop number
• source URL
• status code
• destination URL
• timestamp
• method used
• error class

Stop on loops, invalid schemes, excessive hops, or destinations outside the allowed protocol set. Do not execute downloaded files or active content just to resolve a destination. A safe resolver should usually limit itself to HTTP and HTTPS requests and apply normal network-security protections.

Keep temporary tracking parameters in the raw chain. Remove them only in the canonicalization layer.

Normalize without over-merging

URL normalization is useful, but aggressive rules can hide meaningful differences.

Safe candidates often include:

• lowercasing the host
• removing a default port
• stripping a fragment when it does not change server content
• removing explicitly approved tracking parameters
• normalizing a trailing slash according to the site's canonical behavior

Risky candidates include:

• deleting every query parameter
• treating HTTP and HTTPS as equivalent without checking
• collapsing product and editorial subdomains
• assuming every locale path is duplicate content
• trusting a canonical tag that points to an unrelated page

Store the normalization-rule version. When a rule changes, reprocess a sample and compare the old and new destination groups before rewriting historical reports.

Check claim-to-destination fit

A successful link is not automatically a useful link.

Compare the answer's claim with the final destination:

• Does the page support the statement associated with the citation?
• Is the content about the named entity or a different product?
• Is the page current enough for the claim?
• Does the destination contain the feature, price, statistic, or policy referenced in the answer?
• Does the link land on the specific evidence page or only on a homepage?

Use a small review taxonomy:

• Supports claim
• Partially supports claim
• Related but non-supporting
• Contradicts claim
• Unavailable
• Not reviewed

Store the evidence sentence and reviewer state. Do not let a classifier silently promote “related” to “supports.”

Calculate destination metrics

Once the records are preserved, useful rates include:

Owned-link rate

Eligible prompt runs with at least one clickable owned destination divided by eligible prompt runs.

Owned-product-link rate

Eligible prompt runs with a clickable owned product or service page divided by eligible prompt runs.

Citation resolution success

Citation links that resolve to a valid final destination divided by citation links tested.

Destination mismatch rate

Resolved destinations whose owner or page type differs materially from the displayed label divided by resolved destinations.

Claim-support rate

Reviewed citation destinations classified as supporting the associated claim divided by reviewed destinations.

Third-party dependency rate

Eligible prompt runs where every clickable destination is independent or marketplace-owned divided by eligible prompt runs with at least one link.

Keep the denominator beside every metric. Do not combine answer-level and link-level records in one rate.

Build a repeatable audit workflow

A practical sequence is:

1. Freeze the prompt set and eligibility policy.
2. Capture the full answer and interface context.
3. Extract visible citations and outbound links.
4. Store the displayed label and raw href.
5. Resolve redirects with bounded safety rules.
6. Capture status, final URL, and redirect chain.
7. Determine registrable domain and normalized owner.
8. Apply versioned canonicalization rules.
9. Classify destination type and interface accessibility.
10. Review claim-to-destination fit for important links.
11. Calculate answer-level and link-level metrics separately.
12. Preserve corrections and rule versions in an audit trail.

Repeat a subset of prompts to learn whether destination behavior is stable. An answer may continue mentioning the same brand while switching its citations or outbound destination.

Example failure patterns

Several patterns deserve separate alerts:

• Mention without access: the brand is recommended but no clickable destination is available.
• Owned source without attribution: an owned page is cited while the brand is not named.
• Third-party detour: the brand is recommended, but the only link points to a review site or marketplace.
• Broken evidence: the citation fails or redirects to an unrelated page.
• Homepage fallback: a specific claim links only to the company homepage.
• Canonical collision: two materially different pages collapse into one normalized URL.
• Visibility-only link: the destination exists in extracted data but is not visible or clickable in the captured interface.

These patterns lead to different fixes. A third-party detour is not the same problem as a broken citation.

Keep destination access separate from recommendations

Recommendation is a semantic role. Destination access is an interface and URL outcome.

A brand can be recommended with no link. It can receive an owned link without being recommended. It can be cited as evidence while a competitor is selected. Preserve each state independently.

A useful report can therefore show:

• named coverage rate
• recommendation rate
• owned-source citation rate
• owned-link rate
• owned-product-link rate
• destination mismatch rate
• claim-support rate

The combination is more diagnostic than a single visibility score.

I’m building Corank around the broader problem of understanding how brands appear in search and AI-generated answers. Destination access is a critical part of that measurement because an appearance and a usable path to the company are not the same thing.

Track what the interface shows, where the click goes, who owns the destination, and whether the page supports the claim. That turns a citation count into evidence you can act on.