The problem this solves
Every technical SEO audit ends the same way: a document full of findings lands in a channel, everyone agrees it is important, and the findings enter the backlog to die. The gap between finding and fix is where audit value evaporates, because the person who ran the audit and the person who can edit the codebase are different people with different queues. Metadata gaps, robots problems, and structured-data omissions are individually small tickets, and small tickets lose every prioritization contest they enter.
The translation cost is the real killer. An audit finding says the product template is missing canonical tags; turning that into a fix means locating the template, understanding the framework's conventions, writing the change, and explaining it well enough to pass review. Multiply by thirty findings and the audit has generated weeks of unglamorous work that arrives on the engineering board with no advocate. Six months later the same audit finds the same issues, and the ritual repeats.
The way out is to close the gap in the deliverable itself: the audit arrives as a pull request. Findings become concrete diffs against your actual codebase, organized by fix class, each commit explaining what it fixes and why. Engineering's job shrinks from translate-and-implement down to review-and-merge, and the merge stays entirely human, because nothing merges itself and nothing should.
How the mission runs
- Audit the live site. Site Audit crawls the domain and catalogs the technical findings: missing or malformed metadata, structured-data gaps, robots and indexation problems, canonical inconsistencies. Each finding is recorded with the affected URLs, so every change in the eventual PR traces back to observed behavior on the live site.
- Map findings to the codebase. The agent connects each finding to its source in your GitHub repository: the template rendering the affected pages, the config generating robots directives, the component emitting metadata. Findings that cannot be confidently mapped are excluded from the PR and reported separately rather than guessed at.
- Write the fixes, grouped by class. Fixes are authored as changes to the actual code: one commit per fix class - metadata, structured data, robots - so the history stays reviewable and any single class can be discussed or reverted independently. Each commit message states what it fixes, which audit findings it resolves, and why the change is safe.
- Open the pull request. The PR opens on GitHub with a description linking every change back to its audit finding, organized so a reviewer can work through it class by class. It is a normal pull request in every respect: your CI runs, your review process applies, and it waits for a human.
- Hand off for review and merge. The mission ends at the open PR. Nothing merges itself; your team reviews, requests changes, and merges on its own judgment and timeline. Unmapped findings ride along in the PR description as a residue list, so the full audit picture stays visible even where automation stopped.
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
An open pull request on your repository that resolves the audit's mappable findings: metadata, structured-data, and robots fixes as real diffs, one commit per fix class, each explained and linked to the finding it resolves. Findings that could not be confidently mapped to code are listed in the PR description for human follow-up. Review and merge remain entirely yours, which is exactly where they belong.
Make it yours
- Scope the first run to one fix class, such as metadata only, so the team can calibrate trust in the diffs before accepting broader PRs.
- Schedule it monthly as a standing health patrol: most runs find little, and the ones that find something arrive with the fix already written.
- Pair it with the preview-verification playbook so each PR's deploy preview is checked against the original findings before anyone spends review time on it.
Frequently asked questions
Can this merge anything on its own?
No. The mission's terminal state is an open pull request; merging requires a human with write access following your normal review process. Your branch protections, CI checks, and review requirements all apply unchanged, because the PR is a standard PR that happens to have been authored by an agent.
What if the agent misreads our codebase?
The failure is contained by design: a wrong fix is a visible diff in review rather than a change on your site. Findings the agent cannot confidently map to code are excluded and listed instead of guessed, and the one-commit-per-class structure means a bad commit can be dropped without discarding the rest.
How do we know each change is justified?
Every commit message names the audit findings it resolves and the affected URLs, and the PR description carries the full mapping. The reviewer can check any change against the live behavior that motivated it, which makes this PR more traceable than most human-authored ones.