SEO audit that opens a pull request
Audit a site for search and answer-engine issues weekly, and let the routine raise a reviewable GitHub change.
This is the first routine most teams give write access to, so it is worth building carefully. The audit reads; the pull request is the one action it may take, and a pull request is reviewable by construction.
What you get: an evidence-backed audit of technical SEO, structured content, internal linking, and answer-engine discoverability — plus a pull request you can read, amend, or close.
Prerequisites
- A GitHub connection with the
reposcope. - A tool-capable model.
- A repository where an unreviewed branch costs nothing.
Configure it
Start from the template
Routines → New routine → Weekly SEO and AI-SEO audit. Suggested schedule:
0 10 * * 1.
Set the siteUrl variable to the public site you are auditing, for example
https://example.com, and reference it as {{siteUrl}}.
Separate finding from fixing
Write the instructions in two explicit phases:
- Audit. Read the site and the repository. Produce ranked findings with evidence and expected impact.
- Propose. Turn only the findings that are safe to automate — metadata, structured data, internal links, sitemap and robots entries — into a single pull request. Everything else stays a recommendation in the result.
Say what must never be changed automatically: content copy, pricing, legal pages, redirects, and anything requiring judgement about the business.
Grant write access deliberately
Discover tools on the GitHub connection. Enable the read tools the audit needs, then enable exactly one write path — creating a branch and opening a pull request.
Automatic execution is a second confirmation on top of enabling the tool.
The dialog names the tool and states that it may read or change connected data.
Granting it is the moment to decide you are comfortable; MCP annotations such
as readOnlyHint are shown as context but are supplied by the remote server
and are never treated as authorization.
Never grant merge
Enable the tool that opens a pull request. Do not enable tools that merge, force-push, or delete branches. The value of this routine is that a human still says yes.
Prove it against a throwaway branch
Run it manually. Read every tool_call step in the trace before you look at
the pull request itself, then read the diff. If the routine changed something
you did not intend, tighten the instructions and disable the tool until you
have re-proved it.
Tuning
- Pull requests that are too large. Cap them: "at most eight files per pull request, ranked by impact." Reviewers reject big automated diffs.
- The same PR every week. Have the routine check for an existing open pull request from a previous run and update it rather than opening another.
- Answer-engine coverage. Ask explicitly for the things classic SEO tools skip: whether key pages state their answer in the first paragraph, whether structured data matches visible content, and whether the site is legible to a crawler that does not execute JavaScript.