SEO feedback should become bounded engineering work

Google Search Console is good at telling me that something changed. It is not good at deciding what my team should do next.

That gap is where useful automation starts. I built a scheduled producer that reads Search Console data, checks the most suspicious URLs, and turns actionable findings into GitHub issues. The point is not to build an agent that edits the site whenever a number moves. The point is to give an existing engineering workflow a small amount of well-shaped work.

This follows the same split I use in my agent-driven CLI-first workflow: let automation handle bounded execution, while a human keeps control of direction and judgement.

A report is not a workflow

SEO reports tend to stop at observation. A page lost impressions. A URL is not indexed. A sitemap has an error. Someone is expected to open the dashboard, work out whether the finding matters, find the relevant code or content, and create a ticket.

That last part is where most monitoring systems become expensive. The data arrives, but the work never enters the queue.

The Search Console producer has three phases. It compares the current 28-day search window with the previous 28 days, using thresholds for impression drops, click-through-rate drops, and worsening average position. It then sends the worst candidates through URL Inspection, which can reveal coverage, indexing, mobile usability, and rich-result problems. Finally, it checks registered sitemaps for errors, warnings, pending submissions, and downloads that have gone stale.

The analytics phase is deliberately not an issue generator on its own. A fall in impressions can be a trend, a seasonal change, or a search result moving around. It is useful evidence, but it is not automatically a defect. The workflow uses those changes to choose what deserves a more expensive inspection. That small distinction prevents a traffic report from becoming a backlog of false emergencies.

The queue has a budget

The producer has limits because external APIs and human attention both have limits.

Search Console data is delayed, so the comparison windows end before the current day instead of pretending that today's numbers are complete. URL Inspection has a daily quota, so the workflow caps inspections at the worst 20 candidates. Issue creation has its own cap of 25 findings per run. Titles stay stable so repeated runs can detect an existing issue instead of filing another copy with slightly different metrics.

The schedule matters too. A weekly job collects the source data. The implementation workflow checks for suitable issues hourly. When there is no work, or the open pull request limit has been reached, that hourly run exits without making noise.

None of these limits makes the system clever. They make it safe to leave running. A scheduled job should have a predictable failure mode when the data is noisy, delayed, incomplete, or more plentiful than the team can review.

An issue needs a recipe, not a warning

An issue that says “Google found a problem” is barely better than an email alert. The useful part is the next step.

Each finding includes what the state means, where to look in the repository, what action is available, and how to verify it. A canonical problem points the implementer towards the page metadata, the shared SEO component, the markdown source, and redirect rules. A missing page points towards the content file, route, and redirect history. A sitemap finding points towards the workflow and generated sitemap rather than asking someone to start from a blank dashboard.

This is the difference between giving an agent a task and giving it a mystery. The agent still has to read the repository and make a change, but the issue tells it which evidence is relevant. That keeps the work small enough to review and gives the resulting pull request a clear reason to exist.

Automation needs an explicit stopping point

The hardest design decision was not how to call the API. It was deciding which findings an agent could handle without asking me a question.

The workflow labels findings by autonomy. Mechanical work is marked afk, so the implementation loop can pick it up. Work that contains a quality or product decision is marked hitl, so it waits for a person.

That boundary is specific. A sitemap error is usually a mechanical pipeline problem. A page blocked by noindex can be fixed if the page is meant to be public. A URL that is “Crawled - currently not indexed” needs a judgement about whether the content is substantive enough to deserve indexing. The agent can gather evidence, but it should not quietly make that editorial decision.

Some boundaries became clearer as the implementation gained better recipes. A 404 can often be classified by reading git history and checking whether the deletion was deliberate. A duplicate canonical can be investigated through the page's metadata, redirect chain, content depth, and internal links. The important part is that the system earns more autonomy by gaining a concrete way to decide, not by loosening the label because the queue is inconvenient.

Why I chose GitHub issues

The natural temptation was to build a separate SEO dashboard. That would have produced another place for me to check, another status model to maintain, and another handoff between observation and implementation.

GitHub issues already have the properties this workflow needs. They can be deduplicated, labelled, assigned to an existing implementation loop, discussed when the evidence is unclear, and closed with a pull request that records the fix. The issue becomes the boundary between external data and repository work.

It also preserves a useful human habit: review the proposed change, not just the alert. Search Console can say that Google selected a different canonical. The pull request must show whether the redirect, metadata, or source content actually changed. That is a much better review surface than a green dashboard tile.

What I would not automate

I would not give an agent permission to rewrite canonical URLs, remove content, or change indexing directives without a repository-level reason and a reviewable pull request. Search data is useful, but it is also delayed and partial. A single observation does not contain enough context to decide what the site should be.

The producer therefore stops at bounded work. It gathers evidence, applies thresholds, writes a recipe, and creates an issue. The existing implementation workflow can then handle the mechanical cases. A human can answer the questions that depend on content quality, intent, or business context.

That is a more useful form of continuous SEO. The site gets regular attention without turning every fluctuation into a task, and agents get work they can actually finish. The goal is not autonomous SEO. It is a queue that stays useful after the novelty of automation wears off.