Retest a website readiness fix by replaying the original tasks against a frozen baseline, then comparing the changed release under the same conditions. Record what changed in the website, what changed in the task result and whether the surrounding rules still hold. Use the release record to identify what shipped and the retest evidence to decide whether the intended task works within the tested scope.
Freeze the baseline before judging the fix
Consider an illustrative support website where an authorised editor must move synthetic ticket T-104 from the General queue to Product support without changing its Normal priority. The form has separate queue and priority selectors. In the example baseline, the visible Queue label is not associated with its selector, and an agent cannot reliably identify the intended control. The proposed fix associates that label with the correct selector. These are example conditions and proposed tests, not results from a completed deployment.
Call the example baseline release R0 and the changed release R1. Keep both available in isolated staging with the same server behaviour and synthetic data. Before each attempt, restore T-104 to General with Normal priority. Use the same editor account permissions, queue catalogue, starting URL and task wording. If the second attempt starts with the ticket already in Product support, an agent could report the requested state without performing the move. Resetting the fixture prevents that false success.
Keep a dated run manifest beside the original evidence. It should identify the frontend and server builds, fixture revision, account role, browser and exact version, viewport, locale, time zone, selected agent and model version where exposed, configuration, available tools and prompt. Record session setup and any feature flags. The purpose is to make a difference attributable: a new browser, a different permission or an extra tool could explain a changed result independently of the label fix.
An old screenshot is useful evidence of what appeared on a date, but it cannot recreate the account, data or execution conditions. If R0 cannot be replayed, preserve the original dated records and state which conditions are missing. A successful R1 task can still establish success in its recorded environment. It supports a weaker before-and-after explanation when the original conditions cannot be matched.
Separate the changed component from the completed task
For this example, the change record should show only the Queue label association in R1. W3C guidance on form labels (https://www.w3.org/WAI/tutorials/forms/labels/) explains that an explicit association uses a label whose for attribute matches the control id. If the release also changes the selector options, routing endpoint or permissions, include those differences in the record. Test an isolated build where possible, or treat the combined release as the unit being assessed. Do not assign its entire effect to the label.
Start with a component check: does the Queue label now resolve to the queue selector, while Priority still resolves to its own selector? A browser test can check this directly. Playwright documents associated-label and role locators (https://playwright.dev/docs/locators), while warning that role locators do not replace accessibility audits. This check establishes the intended relationship in the tested page. It does not establish that an agent will choose the right control or complete the business task.
Then give the selected agent the original task wording from the original starting state. Do not add a hint naming the repaired control unless the original task contained it. Retain the agent response, the interaction record and the final ticket state. The decisive evidence is that T-104 is saved in Product support after a fresh page load, with Normal priority unchanged. A success message alone leaves open whether the wrong field changed, the save failed or the page displayed a temporary selection.
Keep the component result and agent task result as separate outputs. A label check can pass while the task still fails later at Save. Conversely, an agent may complete the task through a different route while the intended label repair remains defective. The second outcome establishes success for the route taken, but does not validate the repaired component.
Replay regression tasks, including expected refusals
The original task set is the comparison basis. For the illustrative routing form, use four required scenarios with their expected decisions written before the retest:
- Editor routes T-104 to Product support: the saved queue changes and Normal priority remains unchanged.
- Editor changes T-104 priority to High: the saved priority changes and the General queue remains unchanged.
- Read-only account requests the routing change: the operation is denied, the response does not claim success and neither saved field changes.
- Editor requests an inactive queue: the target is reported unavailable or the operation is rejected, with neither saved field changed.
These scenarios serve different purposes. The first checks the intended improvement. The second checks the neighbouring control that could have been confused with it. The last two preserve meaningful failures: the label repair must not make an unauthorised or invalid change possible. A denial is a passing regression result when denial is the expected decision. Counting every refusal as a failed task would reward the removal of the very rule that the test should preserve.
If the original audit omitted one of these cases, add it explicitly to the protocol and run it against both available releases. Mark it as newly added coverage. Do not describe it as a previously passing regression or manufacture an R0 result. Each comparison row needs its own task, starting state, expected response, expected saved state, R0 observation, R1 observation and links to the supporting records.
For agents whose choices can vary between attempts, declare a repetition count before running either release, use the same count for both and keep every attempt. Reset the fixture and session as specified each time. Separate the results by configuration rather than pooling a browser-only agent with an agent that has additional tools. If a hosted model version cannot be held fixed, record the exposed identifier and date; the comparison then includes an uncontrolled dependency. A favourable attempt must not erase a conflicting attempt.
Retain a browser trace where available, but record state checks separately. Playwright explains (https://playwright.dev/docs/api/class-tracing) that context tracing captures browser operations and network activity without recording test assertions, whereas tracing configured through Playwright Test includes assertions. A useful retest record therefore identifies the assertion that checked the saved queue and priority, rather than expecting a reviewer to infer acceptance from clicks in a trace.
Interpret the differences and close the right scope
Keep distinct retest outputs: a dated environment and change manifest, the component-check result, the paired task ledger, and the saved-state evidence supporting each decision. Finish with a short decision note that identifies the accepted scope and unresolved differences. These records answer different questions. The manifest explains what could have caused a difference; the component check tests the intended repair; the ledger compares behaviour; the state evidence establishes what the application retained.
For the example, acceptance would require the corrected Queue association, successful routing under the declared editor conditions, unchanged priority, and the expected results for every required regression scenario across the declared attempts. A newly permitted read-only change blocks acceptance even if the original routing task now succeeds. A missing baseline, changed agent configuration or interrupted run should produce an inconclusive comparison for the affected row rather than an invented pass. An unrelated failure should be recorded and assessed for release impact, without being attributed to this label change solely because it appeared during the retest.
The decision note should distinguish three conclusions: the component repair is correct, the selected agent completed the task, and the surrounding rules remained intact. Record each conclusion at the strength the evidence supports. Passing this staging protocol would support the named releases, tasks, roles and agent configuration. A production rollout with different permissions, data or agent access needs checks for those differences before the staging conclusion is extended.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. AEO means answer engine optimisation; GEO means generative engine optimisation. ScaleGrowth publishes this guide and provides AgenticReadiness audit services (https://scalegrowth.digital/webmcp-audit-site-ready/). Its team has years of experience in organic growth marketing. For this work, its relevant scope is the repeat of the defined task set and the recording of version differences, with the retest records forming the deliverable.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter 12 of their jointly authored book WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” Applied to this retest, name an owner for the comparison record and report the number of required scenarios meeting their predefined decisions out of the total required. Keep the individual results attached: four successful writes would be the wrong outcome when two scenarios require no change. The count is useful only when the expected decisions and supporting states make clear what was proved.
References
W3C WAI Forms Tutorial: Labeling Controls
https://www.w3.org/WAI/tutorials/forms/labels/
Playwright: Locators
https://playwright.dev/docs/locators
Playwright: Tracing
https://playwright.dev/docs/api/class-tracing
ScaleGrowth: WebMCP audit overview
https://scalegrowth.digital/webmcp-audit-site-ready/
ScaleGrowth: WebMCP services
https://scalegrowth.digital/services/webmcp/
Playwright: Best Practices
https://playwright.dev/docs/best-practices
OWASP Web Security Testing Guide v4.2: Testing for Bypassing Authorization Schema
https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/02-Testing_for_Bypassing_Authorization_Schema/