Treat an offer change as a regression risk
After changing a service package, test whether an assistant can still answer the buyer's practical questions correctly. Check price, currency, exclusions, delivery timing, and the boundary between assessment and implementation. A correct headline price does not rescue an answer that promises work the package excludes.
Google's AI guidance describes browser agents using rendered pages, the DOM, and accessibility information. It does not prescribe the evaluation below. This is a proposed maintenance method for the offers your site presents, not an AI-ranking technique.
Write the expected answer before asking the agent
Keep an approved offer record with version, effective date, currency, tax treatment where applicable, inclusions, exclusions, eligibility, and source URL. Separate a fixed package price from a starting price and a bespoke quote. Name the person who approves a change.
Use fictional values when testing the method publicly. For example, Package A might be a EUR 600 assessment that produces a recommendation but no implementation; Package B might start at EUR 1,800 for a scoped build. These are illustrative offers, not JQ prices.
Test comparisons that expose hidden assumptions
- “Which package includes implementation?” Expected: identify the build and explain the assessment boundary.
- “Is the assessment fee automatically deducted from the build?” Expected: only say yes if the approved terms say so.
- “Is the starting price the final quote?” Expected: preserve the distinction.
- “Can I receive this service outside the stated eligibility?” Expected: identify the restriction or uncertainty.
- “Which price applies after the effective date?” Expected: use the current version and name any conflicting source.
Define critical errors before testing. A wrong currency, invented discount, or false implementation promise should fail the run. Do not let a high average accuracy score hide an error that would mislead a buyer.
Separate source extraction from open-web discovery
First give the evaluator the current approved page or record. This checks whether the offer is understandable from its intended source. Then run a separate open-web observation to see what an assistant retrieves independently. The two tests diagnose different problems.
For each run, retain task, model, date, tool mode, response, cited URLs, expected answer, and result. Repeat important tasks to observe variation. A stale directory listing, contradictory FAQ, inaccessible page, and reasoning mistake each need a different repair.
Retest the change and its neighbours
When a price changes, inspect related service pages, comparison tables, FAQs, downloads, and structured data. Update only the approved offer facts, then rerun the affected tasks. Preserve the previous results so the team can see whether the repair actually helped.
The useful output is a defect list with owner, severity, evidence, and next check. Start with one frequently misunderstood offer. A focused assessment can identify whether the problem is content consistency, retrieval, or the agent workflow before a larger system is built.
Link Map
Sources and editorial review
Sources reviewed on 14 September 2026. The practical workflows and illustrative examples are JQ AI SYSTEMS analysis unless explicitly attributed.
- Google Search Central: Optimizing for generative AI features (Updated 10 July 2026; reviewed 14 September 2026).