Why is an agent still reading an old price after you updated the page?

You change a public price, refresh your browser and see the new amount. An assistant still reports the old one. Before changing the page again, find out which document the assistant used and whether it fetched that document now.

A stale answer can start in your CDN, a separate Markdown export, an old regional page or a previously retrieved source. HTTP headers can help diagnose your own delivery path. They cannot force every external search system to refresh its stored information.

Establish the exact mismatch

Save the assistant's answer and any cited URL. Compare that destination with the page you edited. A citation to an annual plan, another currency or an archived announcement may explain the difference without any cache bug.

Write one expected fact for the investigation, such as "the public monthly price for this plan is now the amount shown on the current plan page." Record its source and change time. Avoid mixing a list price with a customer-specific quote or tax-inclusive checkout amount.

Fetch the cited URL in a clean client and save both body and headers. Repeat from the public hostname rather than relying on your local development server. If the returned body is current, the next question is where the assistant obtained its older evidence.

Understand the policy you are testing

Cache-Control: no-cache permits storage but requires revalidation before reuse. no-store tells caches not to store the response. A freshness lifetime such as max-age permits reuse while the response remains fresh under that policy. These directives express different choices. MDN Cache-Control reference.

For a public page that changes often, choose an explicit policy matching how much stale information your product can tolerate. Do not paste an arbitrary short lifetime onto every asset. A versioned script and a frequently edited price page have different requirements.

Private account responses also need a deliberate policy. Keep them outside this public-page experiment; inspecting a public plan page should not require capturing a customer's billing details.

Compare the edge with the authoritative content

Capture a normal public response:

curl -sS -D /tmp/price.headers \
  https://example.com/pricing -o /tmp/price.html

Inspect the price in the body, then review cache-related headers such as Cache-Control, Age when present, and any cache status your provider documents. Save the timestamp. One header rarely identifies every layer that participated.

Compare this with an authorized origin inspection or your deployment's generated content. If the origin contains the new value and the public edge contains the old one, investigate the provider's purge and cache-key configuration. If both are old, the content may not have deployed to the route you tested.

A request for revalidation is a diagnostic input, not a universal cache purge. Do not claim that adding a random query parameter proves the canonical URL is repaired. Test that canonical URL again after the intended fix.

Verify validators after a content change

An ETag identifies a version of a resource. A client can send it in If-None-Match; if the server determines that the representation still matches, it can return 304 Not Modified without the body. MDN ETag reference.

Save the old validator before a controlled update in staging. After the update, send the old validator and check whether the server supplies the changed representation. An incorrect unchanged validator can make clients reuse old content even when a new body exists elsewhere.

Test the representation you care about. An HTML page and a Markdown export need validators that accurately reflect their own content. Do not assume a validator generated for one representation describes every version of the resource.

Compare all public statements of the price

Check the plan page, structured data, public documentation and any alternate text export. Use a small table of URLs and observed values in your issue tracker. Identify which system owns each copy so the same mismatch does not return at the next pricing change.

Keep this review focused on consistency. It cannot establish that any particular assistant uses your structured data or text export. The integration's observed request is the evidence for that claim.

Dedica's free readiness checker reports public-site findings and evidence. It can support a broader site review, but it cannot purge an external assistant's memory or guarantee a fresh citation.

If the live response is correct while the assistant still cites an older source, record those as separate findings. The next step is to investigate that client's retrieval behavior, with the exact URL and answer date available.

Sources

• Cache-Control, MDN.
• ETag, MDN.