AI Search Readiness guide · Chapter 6
Keeping it fixed: every prompt can undo the fix
Builder sites are rewritten with every session. Watching the live site after each push is the only way to know a fix survived.
Why regressions happen
A builder regenerates files from the prompt history. A metadata export you edited by hand, a robots.txt you wrote, a canonical tag you corrected: the next prompt that touches the page can replace them with the template default. It is not a bug in the builder; it is what generation means.
The common regressions we record: canonical tags reverting to the preview host, titles reverting to the project name, robots.txt reverting to a generated blanket rule, and Open Graph tags disappearing when a layout is regenerated.
Watch the site, not the repository
A watcher re-checks the live site on a schedule and ninety seconds after every push to the linked repository, compares every finding with the previous check, and records what got worse and what got fixed, as a share of pages affected so one extra page is not a regression. Each regression that a repair can fix links straight to a new pull request.
The repair loop
Audit, merge the pull request, watch. When the builder undoes a change, the watcher reports it and the repair reopens it. Over time the prompt history itself starts carrying the fix, because you asked the builder to keep it, and the regressions stop. Until then, the loop is cheaper than finding out from a customer.
Checks in this chapter
Canonical correctness · Preview host leaks · Regression watch · Repair eligibility
Run these on my site