RAG citations from web sources: cite the passage, URL and date

A citation is a promise: "this page, at this address, says this". Readers check citations exactly when the stakes are high, so a wrong one costs more trust than no citation at all. With web sources there are extra ways to break the promise: redirects, edits, removed pages. This guide covers what to cite, how to carry the evidence through the pipeline, and how to check it before and after the answer ships.

Bibliography or attribution: know which one you ship

There are two different features that both get called "citations":

• A source list. "These pages were used to answer." Cheap, and honest if the list is exactly the retrieved chunks. It does not tell the reader which claim came from where.
• Attribution. Each sentence or claim points to the passage that supports it. Harder, and the only kind a reviewer can check claim by claim.

Decide which one your product needs. Support and research tools usually need attribution. A source list is fine for casual Q&A, but then do not format it as if every sentence were attributed.

Cite the final URL, the title and the date

Three fields make a web citation checkable:

• The final URL after redirects. The URL in your source list may redirect to a new path, add a locale or drop a trailing slash. Cite where the content actually lives. Store it at ingestion (see web content ingestion for RAG).
• The page title and the section heading. "Rate limits, in Billing API reference" lets a reader find the passage without scrolling.
• The date your pipeline read the page. Pages change. "Retrieved 27 Oct 2026" tells the reader which version the answer is based on. Keep it separate from any published date the page shows.

Quote-level citations

To support claim-level attribution, carry the evidence, not just the source:

1. Give each retrieved chunk a short ID in the prompt, such as [S3], with its title and URL.
2. Ask the model to put the ID after each sentence that uses that chunk, and to quote the supporting phrase when it is short.
3. In code, map IDs back to chunk records. Never let the model write URLs; it will invent plausible ones.
4. Store the quoted span with a little text before and after it.

That last step follows the W3C Web Annotation model, whose TextQuoteSelector identifies a passage by its exact text plus a prefix and suffix.¹ It survives small edits better than character offsets. For links that jump to the passage, browsers that support URL text fragments (#:~:text=) scroll to and highlight the quoted text; others simply open the page.²

Verifying citations after generation

Models cite incorrectly more often than their confident formatting suggests. The ALCE benchmark (Gao et al., 2023) measured citation recall and precision on three datasets and found that even the best models tested lacked complete citation support about half the time on ELI5.³ CiteFix (2025) proposes correcting citations after generation by matching each claim against the retrieved documents, using keyword, semantic and model-based matching; the authors report a 15.46% relative improvement in overall accuracy on their data.⁴

A practical check that needs no research code:

• For each cited sentence, confirm the cited chunk was actually in the context.
• Confirm the quoted span, if any, appears in that chunk word for word.
• Score whether the chunk supports the sentence, with an entailment model or a small LLM judge.
• If a check fails, re-attribute to another retrieved chunk that passes, or drop the citation and flag the sentence.

Log failures by source. A page that often fails verification usually has chunking problems, such as a table split away from its header row.

Link rot and pages that changed

Between indexing and the moment a reader clicks, the page can change or vanish. Two habits keep citations true:

• Refresh cited sources first. Pages that are cited often deserve a shorter refresh interval than the rest of the index. See RAG index freshness.
• Re-check before high-stakes answers. For legal, policy or pricing questions, re-fetch the cited URL live and confirm the quoted span still appears. If it does not, re-answer from the current version or tell the user the source has changed.

A page that now returns 404 or 410 should be removed from the index, not just hidden from citations, or it will keep shaping answers.

If you use Live Web Data API for the re-check, send the cited URLs (every request is a live fetch; there is no cache), compare the returned Markdown with the stored span, and treat a CRAWL_NOT_FOUND error as a removed page. The API cuts content at text.maxCharacters, 100,000 characters by default, so check results[].textTruncated and raise the limit for any page that hits it; otherwise a quote near the end of a long page looks as if it is gone. A URL that comes back as an error costs 0 credits, so re-checking citations to pages that have vanished costs nothing. The automation docs show batching and retries, and the SDKs wrap the request. The API only fetches; matching spans and judging support is your code.

Showing citations readers trust

Format matters for whether people check:

• Put numbered markers inline and a source list underneath, with title, site name and the date read.
• Show the quoted passage on hover or expand, so the reader can check without leaving.
• Link to the passage with a text fragment where possible.
• Mark sources that were re-checked recently, and say plainly when a source could not be re-checked.

Where to go next

Citations are only as good as the chunks behind them. If verification often fails, revisit chunking Markdown for RAG; if the right chunk is often missing, revisit retrieval for web-sourced RAG.

Request API access. Sign-up is for businesses only. Only Business, Enterprise and Custom sign-ups are reviewed before checkout, usually within 1 business day.

Footnotes

1. W3C, "Web Annotation Data Model", section on TextQuoteSelector. ↩

2. WICG, "URL Fragment Text Directives". ↩

3. Gao et al., "Enabling Large Language Models to Generate Text with Citations" (ALCE), arXiv 2305.14627 (2023). ↩

4. "CiteFix: Enhancing RAG Accuracy Through Post-Processing Citation Correction", arXiv 2504.15629 (2025). ↩