Approval replaces hand-finding once a loop detects the issues, triages them, and opens the fixes as pull requests. A crawl finishes overnight. Search Console numbers and rank rows pile onto it. By morning the queue is full of findings, and the choice of what to fix is still open. The loop below turns that pile into a short list of pull requests, each with a reason attached.
Crawlers and data feeds detect the issues. An agent triages by root cause and opens pull requests for the clear fixes. The person's work shifts from finding problems to approving them. A working setup pairs Screaming Frog crawls with Search Console and DataForSEO feeding the data while the agent triages and opens the pull requests.
Detection and Triage
Detection starts with a crawl or a Search Console pull. Group what comes back by type, by severity, and by the potential impact on rankings. A confidence filter holds a fix until it clears a predefined score. What clears that score is what moves forward. Everything else stays in the findings queue.
Tetrate's writeup of its own implementation collects on a weekly schedule. It orders issues by severity and by the size of the opportunity. Scripts pull Search Console for every page and record position along with impressions and clicks. They run Lighthouse audits for performance and SEO scores, and they flag pages missing a call to action. Each report is archived so a later week can be compared with this one. An agent reads the raw table and writes findings, trends, and recommendations tied to those numbers. The aim they name is organic performance across several hundred pages. The writeup gives example findings, where CTR means how often an impression was clicked: "CTR is 0.33%, below the 0.4-0.6% benchmark", and "impressions down 3.5% month-over-month, but CTR up 6.5%".
Proposal, Judge, and the Human Pick
For each item that moves forward, the agent drafts the change. In the manual process Tetrate describes, that change was an improved meta description or title tag, committed in the site repository and opened as a pull request. The workflow they run now is propose, improve, review, publish.
An SEO expert picks the analysis. Tetrate lists four types. Content expansion finds thin pages that already earn high search impressions and proposes how to enrich them. Query-gap analysis finds high-impression queries without matching content. Topic ideation generates new topic ideas for a theme. A topic cluster groups existing proposals into a main page and the pages that support it. The agent writes the proposals. A person decides which to pursue. Editors revise. A language-model judge then scores tone, structure, accuracy, and completeness. The writeup's review queue shows a needs-revision item scored 62, with 16 issues. Content below the threshold goes back for fixes, is set aside, or is rejected. Tetrate reports that generating a content expansion proposal, or auditing a batch of articles, takes seconds instead of hours. In their words, "The agents do the mechanical work. Humans make the decisions."
Both gates stay with people, one when a proposal is chosen and one at review. Tetrate's experts choose which proposals are pursued. Editors own quality before a pull request exists.
The Pull Request Waits for a Merge
An accepted fix opens a new branch and a pull request. Automated checks run on that branch before deploy. A developer or the site owner does the final review and merges.
Tetrate's publish step follows GitHub's ordinary pull-request path: review, discussion, approval, then merge. Their setup uses the GitHub API to create the branch and open the pull request, after a person has already accepted the content.
Crawl, Search Console, and Rank Data
Keep three feeds together.
- A crawler for structure, run on a schedule. Screaming Frog is the crawler in the setup above.
- Search Console beside the crawl: impressions, clicks, and position on the site's own pages, plus CTR. It shows what already happened to those pages.
- Rank data for priority: daily position checks for where each key term stands on the latest pull.
The crawler sees what changed on the site. Search Console shows what moved in search. Rank data decides which change is worth proposing first.
When that choice needs the current Google results for the term, qequals returns live Google SERP results for it. If the Google response fails, the call fails with it, so a proposal cites only results Google returned.
Ledgers, Deploy Windows, and Permission Asks
Tetrate's writeup ends once the pull request is open. Around that moment, the routine to keep is a ledger per loop, fixed deploy windows, a permission ask when the work is out of scope, and a weekly pass that lets a strategist rewrite its own instructions.
In a week-two recap from September 2026, someone describes splitting a single hourly loop in two. An SEO routine runs at twenty past the hour. A code-quality routine runs at forty past. Each keeps its own ledger. That week the account reports 583 pull requests shipped: 196 tests, 174 edits to support docs, 121 code changes, and 92 marketing-page changes, most of them small on purpose. The SEO agent tracks rankings for each key term daily through DataForSEO and uses the positions to decide the work. It found that "timeline templates" was a high-volume term with no page, asked permission because new marketing pages were out of scope, and laid out a couple of ways to build one. The person running the loop had not asked it to look at that term. Deploys go out in two weekday windows, 9am and 2pm, so pull requests land in batches. A change reaches master, the main branch, through a pull request. A local review app lists every change and puts the open items in one place. The account says the setup runs on a $200-a-month Claude Max plan, with nothing beyond the subscription.
An account describes a Hermes setup with one agent per project, scoped to that project, and with canonical skills shared across projects. Infisical, the credential store in that setup, holds the keys those agents share, including DataForSEO and OpenRouter. An orchestrator creates and clones the agents and hands each the tools it needs. When an issue needs sorting, a group chat in bot mode brings that agent together with the orchestrator.
An account of eight products, run through a harness called CRHQ, describes an agent team on every product, covering support, monitoring, SEO, content, development, backlinks, and socials. Agents can message one another and open a one-off session to delegate work. Instructions live in files and folders that the agent can rewrite from what it learns. Clones of the same agent write decision logs into one shared folder. Each agent keeps a status board. The person speaks only with lead agents. A lead agent can approve a simple additive release on its own, and otherwise waits for that person, and it withholds approval until a code-reviewer agent agrees. The SEO strategist can review Search Console, analytics, and DataForSEO once a week, log conclusions, schedule the next week, and rewrite its own instructions when it discovers a new strategy. The account puts token spend at $3,000 a month against more than $40,000 a month in revenue.
Run that routine at whatever scale you have. Keep a separate ledger for the SEO loop and for the code loop so the two histories stay distinct. Land pull requests inside the weekday windows. When the work is out of scope, stop and ask, and attach options. Once a week, have the strategist log what the feeds showed and rewrite its instructions from that log.
Name the calls and a maximum total before the run, and stop for a person at the daily cap on agent calls.
Approve at the two gates this loop already has. Choose which proposals are worth pursuing, and merge the pull request after the checks pass, inside the window you set.
