The problem this solves
There is a class of site defect that no crawler and no analytics dashboard will ever show you: the JavaScript error that fires on load, the tracking pixel that silently 404s, the font file that fails and drops the page into fallback rendering. These defects only exist inside a running browser, which means the people most likely to encounter them are your visitors, and the people least likely to encounter them are your team, who work on fast machines with cached assets and ad blockers configured just so.
The cost hides in places you attribute to other causes. A broken analytics request undercounts a campaign and the budget meeting blames the creative. A console error thrown by a third-party script delays interactivity and the conversion drop gets filed under seasonality. Nobody suspects the page itself, because the page looks fine when anyone on the team opens it.
The fix is to make error harvesting a standing patrol: visit the pages that matter in a real browser, on a schedule, and collect what the browser complains about. The browser has been reporting these defects all along; this mission is simply the first one to listen.
How the mission runs
- Build the page roster. The site mapper assembles the sweep list, either the full inventory for smaller sites or the pages you name as critical: home, pricing, top landing pages, the signup flow entry. Each page is tagged with its importance so the final ranking has a denominator.
- Visit each page in a rendered browser. Every page on the roster is loaded in a real headless browser, scripts executing, assets fetching, exactly as a visitor's browser would. The visit is read-only by design: the browser navigates and observes, and never clicks, types, or submits anything.
- Harvest console errors and failed requests. For each page the mission collects every console error thrown during load and every network request that failed, with the URL and status of each failure. A page that loads clean reports as clean, which matters as much as the defects: the sweep produces a health statement per page.
- Rank defects by reach and severity. Findings are graded by where they occur and what they break: a failed script on the pricing page outranks a stale image on an archived post, and a broken analytics request is flagged as measurement damage distinct from user-facing damage.
- File the top defects as tasks. The worst findings become Asana tasks with the page URL, the exact error text or failed request, and the importance ranking, so an engineer picks up a reproducible defect rather than a vague report that something seems off.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A per-page health table for every swept URL, listing console errors and failed requests found or confirming a clean load, plus Asana tasks for the top-ranked defects, each carrying the exact error text and the page it fires on. Rerun on a schedule, the sweep also becomes your regression alarm for third-party scripts.
Make it yours
- Run the sweep in mobile emulation as well, since script and asset failures often differ between the desktop and phone experience of the same page.
- Point it at your top campaign landing pages the morning after every deploy, so a broken tracking script is caught before a week of spend runs against it.
- Route findings to Slack instead of Asana when you want the sweep as a monitoring pulse rather than a ticket generator.
Frequently asked questions
Will this interact with or change anything on my site?
No. The rendered browser is read-only by construction: navigation and scrolling are its only actions, and clicking, typing, and form submission are deliberately unsupported. It observes what any visitor's browser would experience and records the result.
Why do these errors matter if the page looks fine?
Because looking fine and working fine diverge quietly. Failed analytics requests corrupt your measurement, errored scripts delay interactivity and hurt Core Web Vitals, and a failing font or image degrades the page only for the users you never hear from. Each is invisible until someone collects it.
How often should the sweep run?
Weekly is the useful default, with an extra run after significant deploys or tag-manager changes. Third-party scripts are the most common source of new defects, and they change on their vendors' schedules rather than yours, which is exactly why a standing patrol beats a one-time check.