Final URL or canonical URL: which address an LLM should cite

A fetched page arrives with an address, and that address is metadata the model uses. It decides what the model cites, it often tells you which country's version of the page you read, and it is the cheapest way to spot duplicates before they cost input tokens. For a fetched web page there are usually three candidate addresses, and they are often different strings: the URL you requested, the URL the request ended at, and the URL the site says is the real one.

Requested URL: the key for your logs and stored copies

The requested URL is what your code asked for. It is the right key for your own logs, retries and stored copies, because it is the input you control. Key stored copies by requested URL and country, since the same URL can return a different page from another country. It is not always what a reader should open: it may be an old address, a tracking link or a short link.

Final URL: the version you actually read

Servers move pages with redirects. MDN groups them by intent: permanent ones (301, 308) say the resource has a new home; temporary ones (302, 303, 307) say "look over there for now". A fetch follows the chain and reads the page at the last hop.

That last address is the honest citation. It is where the content in your context came from, and it is where a reader who clicks the citation will land. It also carries information the requested URL hides:

• Country and language. A redirect to /de/ or fr.example.com shows which localized version was served. Pass it with the content, so the model does not answer a US user from a German page. The guide on web pages by country covers why the served page changes.
• Age. With temporary redirects, the next fetch may end somewhere else. Store the fetch time next to the final URL, so the citation says when it was true.

Canonical URL: what the site prefers

A page can declare its preferred address with <link rel="canonical" href="…">. RFC 6596 defines this link relation for pages whose content is duplicated or very similar at several URLs. Google's guidance treats it as a strong signal for choosing among duplicates, not as an order it must follow.

For an LLM app that makes the canonical URL useful in one place: grouping. If three fetched pages declare the same canonical, they are probably one source. Sending all three to the model costs input tokens three times, and the model may count them as three independent confirmations. Drop the copies before you build the prompt.

A rule you can apply

• Pass to the model the final URL, the fetch time and the country, next to the content.
• Log and key stored copies by the requested URL and the country.
• De-duplicate by the canonical URL when the page declares one, and fall back to the final URL when it does not.

The Markdown, text or HTML guide covers the other metadata worth passing to the model with the content.

How this maps to Live Web Data API

Each result carries results[].id, the URL you requested, and results[].url, the final URL after redirects. countryCode sets the country the page is read from, and statuses[].fetchedAt records when it was read. The canonical link is not a separate field; set html: true and results[].html carries the page HTML as served, so you can read the rel="canonical" link from it when you need to group duplicates. You can compare the fields on your own pages in the playground once your plan is active.