How can an AI application keep extracted facts accurate when its source webpages change frequently?

Establish the source of truth before using a model

Start with an explicit source registry. For every fact family, record the authoritative organization, allowed hostnames, canonical URLs, preferred data format, owner or contact, expected update pattern, and the consequence of serving a wrong answer. A model cannot infer this governance reliably from a URL.

For example, a Philippine health-registration application should whitelist the official PhilHealth domain and select pages according to the user's member category. PhilHealth's official formal-economy registration page describes a procedure for employees, while its informal-economy page describes a different route. Those are examples of why an application must not blend instructions from two pages into one generic answer without first establishing applicability. Formal-economy procedure Informal-economy procedure

Use a source hierarchy for each field, not just for each website:

This hierarchy prevents a common failure: a search result or a well-written old PDF appears more specific than the current official page, so the model selects it. The correct conflict rule is not "use the most detailed text." It is "use the highest-authority, currently applicable source, or say that the fact is unknown."

Retrieval helps, but does not own freshness

Gemini can make web-grounded answers more useful. The URL Context tool accepts supplied public URLs and returns URL citation annotations tied to ranges in response text, as well as retrieval status metadata. Google Search grounding can access real-time web content and return inline URL citations. These capabilities are useful for analysis, synthesis, and UI citations. Gemini URL Context response metadata Gemini Grounding with Google Search

They do not replace an application retrieval record:

• URL Context first attempts an internal index cache and falls back to a live fetch when necessary. Its retrieval status is useful evidence, but the application does not control which route was used or retain an auditable raw representation merely by calling the tool.
• URL Context processes only the URLs supplied to it, not nested links. A current procedure may depend on a linked form, notice, or category page that must be independently registered and fetched. Gemini URL Context best practices
• URL Context has documented limits, including public accessibility, a maximum of 20 URLs per request, and a per-URL content limit. A client-side or server-side fetcher is still needed for a complete source inventory, redirects, error handling, and scheduled recrawls. Gemini URL Context limitations
• Google Search can return an authoritative result, a stale result, or an unofficial result. Search is helpful for discovery and corroboration, not for choosing the official source when a service has already established one.

For a Gemini application that needs controlled retrieval, fetch the allowed URLs yourself, create versioned source records, and pass only accepted chunks to the model. On Vertex AI, Grounding with your search API is one way to let Gemini query a curated search endpoint: the endpoint returns snippets and source URIs. The same architectural idea works without Gemini. Grounding with your search API

Capture a verifiable source version

Each fetch should produce an immutable source version. Do not overwrite the prior body or extracted facts.

Capture at least:

• Requested and final canonical URL, redirect chain, HTTP status, content type, and fetch timestamp in UTC.
• HTTP ETag, Last-Modified, Date, Cache-Control, and any relevant language or content-negotiation headers.
• Raw response bytes or a securely retained artifact, plus a SHA-256 hash of those bytes.
• A normalized-text hash after stripping irrelevant boilerplate, so a changed cookie banner does not look like a changed registration rule.
• Parser version, extraction prompt or configuration version, source language, and any rendering method used for JavaScript-generated content.

ETag is an opaque validator that identifies a selected HTTP representation. A client with a stored ETag can send If-None-Match on a later GET; if the tag matches, the server can respond 304 Not Modified rather than retransmit the body. Last-Modified and If-Modified-Since are useful fallbacks, but the HTTP specification notes that dates are weaker validators than an entity tag. RFC 9110 ETag RFC 9110 conditional requests

Headers are hints about the representation, not evidence that a fact remains true. An agency can update a page without an ETag, send a weak or unchanged ETag, or use a CDN that behaves unexpectedly. Periodically perform a full fetch even after repeated 304 responses, retain a body hash, and alert if headers, parsing behavior, or the normalized content change unexpectedly.

A compact source-version schema

{
  "source_version_id": "srcv_2026_09_01_001",
  "canonical_url": "https://agency.example.gov/registration/formal-members",
  "authority": {
    "organization": "Example agency",
    "allowed_host": "agency.example.gov",
    "rank": 2
  },
  "retrieval": {
    "fetched_at": "2026-09-01T10:15:31Z",
    "http_status": 200,
    "etag": "\"abc123\"",
    "last_modified": "Mon, 01 Sep 2026 08:02:11 GMT",
    "raw_sha256": "sha256:...",
    "normalized_text_sha256": "sha256:..."
  },
  "parser": {
    "version": "html-procedure-v4",
    "rendering": "server-html"
  }
}

This schema is not tied to Gemini. It is the evidence record that lets a later reviewer answer a precise question: "What did the authorized page say when the application gave this answer?"

Version chunks and facts separately

A webpage version is too coarse for safe answers. Parse it into stable chunks, normally by semantic heading, list, table, form section, or explicitly labeled notice. Give every chunk an immutable ID that includes its source version. Preserve the exact source excerpt and a location pointer such as heading path, list item index, table row and column, or page number for a PDF.

Then extract field records from those chunks. A field record should never contain only a value.

{
  "fact_id": "registration.formal.required_action",
  "value": "Submit the member registration form to the employer's HR department",
  "status": "fresh",
  "validity": {
    "source_version_id": "srcv_2026_09_01_001",
    "fetched_at": "2026-09-01T10:15:31Z",
    "fresh_until": "2026-09-01T16:15:31Z"
  },
  "provenance": {
    "url": "https://agency.example.gov/registration/formal-members",
    "chunk_id": "srcv_2026_09_01_001#registration-procedure#item-2",
    "locator": "Registration procedures > newly hired employee",
    "excerpt": "Submit the form to the employer's HR department"
  },
  "extraction": {
    "schema_version": "registration-facts-v3",
    "review_state": "accepted"
  }
}

The value in this example is illustrative. The live application must derive it from the stored current official version, not from this article. In the real PhilHealth formal-economy page, the procedure and audience are stated on the source itself, which must be cited to a user at answer time. Official PhilHealth formal-economy procedure

Use a strict extraction schema. For a registration fact, require a field name, normalized value, applicability conditions, source version, chunk ID, confidence or review state, and a status. Reject a model output that invents a missing requirement, omits its evidence reference, or mixes conditions from different categories.

Define fresh, stale, and unknown before launch

Freshness is a policy decision based on the fact's consequence and expected update rate. It is not an inference from how plausible the sentence sounds.

For high-consequence fields, stale is often operationally equivalent to unknown. A benefits amount, eligibility rule, registration deadline, or health-service instruction should not be paraphrased as current merely because the last successful fetch was recent. Show the official link and a clear unable-to-verify message instead.

One workable policy is to fetch current deadline, eligibility, and payment facts before answering or from a very short, monitored freshness window. Use scheduled recrawls for low-consequence directory content. Shorten a field's window after a detected change, a scheduled policy announcement, a source error, a redirect, or a failed validation. The specific interval must be set by the service owner with knowledge of the policy risk and source update cadence.

Change detection from fetch to published answer

flowchart LR
    A[Approved source registry] --> B[Conditional fetch]
    B --> C{Changed or fetch issue?}
    C -->|304 and within policy| D[Refresh checked time]
    C -->|200 changed| E[Archive immutable source version]
    C -->|Error or inaccessible| F[Set stale or unknown]
    E --> G[Segment into versioned chunks]
    G --> H[Schema-constrained extraction]
    H --> I[Deterministic validation]
    I --> J[Compare fields with prior version]
    J --> K{High impact or uncertain?}
    K -->|Yes| L[Human review and conflict resolution]
    K -->|No| M[Accept new field version]
    L --> M
    D --> N[Answer only from accepted facts]
    F --> N
    M --> N
    N --> O[Display status, timestamp, and field citations]

The recrawl step

On each scheduled run, request the canonical URL with If-None-Match when a stored ETag exists, otherwise If-Modified-Since when a stored Last-Modified value exists. Follow redirects only if the destination remains on an allowed official host. A 304 updates the checked-at time, not the source body. A 200 response creates a new source version even if the visible text later proves equivalent.

Use content hashes at two levels. The raw hash detects byte-level changes that might affect auditability or parsing. The normalized-text or structured-data hash distinguishes likely semantic changes from formatting changes. A changed cookie notice should not trigger a policy alert. A changed list item, table cell, linked form, eligibility condition, or notice should.

The extraction and validation step

Give the model only the retrieved, versioned chunks and ask it to propose schema-valid facts with chunk IDs. Then run deterministic checks before publishing:

• Required fields and citations exist.
• Values match allowed types, dates, currencies, and controlled vocabularies.
• A field's audience and conditions come from the same source version or an explicitly allowed relationship.
• A fact does not combine formal and informal procedures, or a current page and an archived PDF.
• A date is internally valid and not already past when the source claims it is a deadline.
• Every displayed fact has a source URL, source version, location, and fetch time.

An LLM can help classify prose changes and draft an explanation. It should not decide alone that a changed eligibility criterion is harmless. A numerical amount, deadline, required document, eligibility phrase, or emergency instruction is a high-impact change and should enter review.

Comparison and conflict handling

Compare fields by meaning, not only raw string. For each field, classify the result as unchanged, formatting-only, new, removed, value changed, applicability changed, or source conflict. Store both the old and new provenance.

When two official sources disagree, do not average them, choose the more convenient one, or hide the disagreement in fluent prose. Apply the field's authority hierarchy, effective date, user category, and jurisdiction. If that does not resolve the conflict, mark the field unknown and route it to an authorized reviewer. The user-facing answer can say that the application found conflicting official information and provide the relevant official links.

Citations that a user can actually audit

Display citations as first-class data rather than a decorative list at the bottom. For each material statement, show:

• The agency or custodian.
• The canonical official URL.
• The exact source section, form field, table row, or PDF page.
• The source version or retrieval timestamp.
• The fact state and, for stale material, the last successful verification time.

Gemini's inline URL citation annotations are useful for associating synthesized text with URLs. Preserve them if you use URL Context or Google Search grounding, but also keep your own field-level provenance. The Gemini annotation answers "which URL supported this output segment." Your source record answers "which exact fetched version and location supplied the displayed fact." Gemini URL citations

Avoid citations that merely link to a homepage when a direct page, form, or notice exists. If the source is a PDF, cite the document and page. If a fact comes from a current official API, cite the endpoint or a stable public representation, subject to the agency's access and privacy rules.

Provider-independent fallback

The safe design works even without URL Context, Google Search grounding, or any LLM:

1. Register official URLs and field owners.
2. Fetch them with conditional HTTP requests and retain immutable versions.
3. Extract known fields with a parser or rules where possible.
4. Validate, compare, and review changes according to impact.
5. Serve only accepted facts with source locations, status, and a verification timestamp.

An LLM then becomes a constrained explainer. Give it only accepted facts and allowed chunks, require it to preserve source IDs in structured output, and render the final answer through a deterministic citation layer. If it cannot cite an accepted field, it should return unknown. This division of labor protects the source of truth even if the model changes.

Common failure modes

Boundaries for public-service information

This approach improves traceability and change response. It does not certify legal eligibility, medical coverage, enrollment success, benefit entitlement, or the completeness of an agency website. Privacy-sensitive registrations also require data minimization, secure retention, access controls, and compliance with the applicable agency terms and law.

For health, benefits, deadlines, and eligibility, the safe default is conservative. If the application cannot verify a fresh official source, it should not manufacture a helpful-sounding answer from training data, an old cache, or an unofficial page. It should explain the verification problem, show the last verified time if one exists, and send the user to the official service.