SEO Copilot

The SEO Copilot is a weekly briefing on your search traffic: what happened, why it happened, and what to do about it. Once a week Lyra reads your Google Search Console data and your own posts, writes the week up in plain language, makes the fixes she safely can as a pull request, and asks you before anything that would move or remove a page. This page covers how the report works and how to use it, step by step.

The Copilot is for anyone running a blog who wants to know whether the search work is paying off without reading Search Console's raw tables themselves.

Prerequisites

• Google Search Console connected. The Copilot reads your search data from Search Console. Connect it from the Analytics page under Google Search Console. Until you do, the Copilot page stays on "Connect Search Console and Lyra starts reporting". See Analytics.
• Your Claude key set. The weekly write-up and your questions run on your own Anthropic key, the same key that powers writing. See Add your Claude key.
• A connected repository, recommended. With a repo connected, Lyra turns the safe fixes into a pull request automatically. Without one, the same fixes arrive as step by step instructions you can follow by hand. See Connect your repository.

How a week works

The Copilot runs once a week on a schedule. Each run pulls the completed week of search data, works out what changed, and writes the report. The week it reports on ends a few days before the report goes out, because Search Console only finalises its numbers late. The page says so under the headline, so a quiet tail never reads as your site going quiet.

For each week, Lyra:

1. Pulls the week's Search Console data: clicks, impressions, position, and the queries and pages behind them.
2. Measures your posts against that data. She checks whether pages lost or gained traffic, sit just off page one, get seen but never clicked, compete with each other for one query, fail to be indexed by Google, or sit in your repo unloved and unlinked.
3. Covers what could not be Google's fault: a title cut off in results, a missing description or social card, thin pages, broken links, orphan posts.
4. Writes a headline, a plain-language explanation, and a ranked set of findings and fixes.

Read the briefing

1. Open SEO Copilot from the left rail under Pipeline.
2. Read the strip at the top: the week's dates, the headline, and the four numbers, Clicks, Impressions, CTR, and Avg position. Each number shows its change and a sparkline for the shape of the week, so you can see whether a drop happened on one day or across all seven.
3. Open Weekly briefings in that strip to switch to an earlier week.

The headline is the one-line takeaway. The four numbers are the shape of the week.

Work through the findings

Beneath the strip, the findings list is under "What I found · N findings". Each finding is one thing worth knowing about, with its own verdict: Biggest loss, Needs a decision, Worth fixing, Cheapest win, or Dead weight.

Each finding card shows the pages and searches involved and, behind a Why button, the reasoning and the numbers underneath it. Nothing is filled in to square off a table; each measurement shows only the numbers actually taken.

To dig into a finding:

1. Click the finding to open it.
2. Click Why to see the reasoning and the evidence.
3. Click Ask to question it directly, or tap one of the suggested questions.

Ask the Copilot

Not content to take the report on faith? Ask. The Ask drawer answers from the week you are looking at, every earlier weekly report for the site, what Lyra already fixed, what you declined, and, when a repository is connected, the pages themselves. She only reads when she answers. She never changes anything.

1. Click Ask on a finding, or Ask about this week above the findings list.
2. Type a question or tap a suggestion. Common ones: Why is this the fix?, What happens if I ignore it?, Which pages are affected?, Which fix should I do first?, Why did my traffic change?, Is any of this seasonal?, and What is already in the pull request?.
3. Watch her work as she answers, then read the reply. An answer takes a minute or two. When the answer arrives, the working-out folds away behind "How she worked this out", and you can reopen it on any earlier answer.

Questions are capped per day, since each one runs on your own key. When you are out, the page says so and points to an upgrade. See Plans and pricing.

Decide on the actions

Lyra sorts fixes into two kinds:

• Safe fixes she makes on her own. Titles and descriptions (metadata), wording (content), internal links (links), and refreshing pages whose facts have gone stale (refresh). These go ahead automatically and land in one pull request for the week.
• Destructive fixes that wait for you. Consolidation folds an older page into a newer one and keeps the traffic by redirecting the old address. Removal deletes a page, and only when a redirect target exists. These come with Approve and Decline buttons at the top of the page under "Your decision this week".

A page is never removed without somewhere for its readers to go. If no safe forwarding address exists, Lyra leaves the page alone and says she skipped it. She suggests merging or removing a post only when two posts really cover the same ground, not because they share your blog's vocabulary.

A fix that covers several posts is made on every one of them, each tracked on its own card. A fix Lyra already made, or one you declined, is not proposed again as if it were new. It shows as not proposed again, with the week it was decided.

Refreshes

When a page loses traffic because its facts have gone stale, Lyra proposes a Refresh. She researches the topic on the web, rewrites the page with current figures, and quotes every figure from the source she took it from. She then reads her draft back against those sources and rewrites until it holds up. A post running thinner than the pages that rank on your site gets a full refresh with new sections, not a one-passage rewrite.

The pull request lists the sources so you can check any figure in seconds. A refresh she cannot fully stand behind still reaches you, with the open doubts written into the pull request and how serious each one is.

When a fix targets a page Lyra did not write, a pricing page for example, she leaves it to you and gives you a Copy the brief button. It puts the whole issue on your clipboard: what is wrong, what to change, the pages involved, and the Search Console numbers behind it, ready to paste into Claude or ChatGPT.

To rule on a destructive fix:

1. Open the finding and scroll to its actions, or click Review it from the decision card to jump to the first one waiting.
2. Read what the action would do, including the redirect target.
3. Click Approve to ship it, or Decline to drop it.

Approving enqueues the change into the week's pull request. Declining stops it, and Lyra does not propose it again unless the numbers genuinely change and it comes back, in which case she says it came back and what is different.

Review and merge the pull request

With a repository connected, the safe fixes are committed to a branch and opened as a pull request. A status bar above the findings tracks where the week's work stands:

• How many fixes are queued for PR #N.
• How many are being written right now.
• A Check PR #N link, and a Merge PR #N button once nothing is still being written into it.

Lyra opens the PR with a plain-language description, a file by file list of fixes, the sources behind any figures she added, and anything she left for you under "Left for you", with the reason. She keeps the repository in step, updating files that mirror page content such as sitemaps, feeds or tag indexes, and a redirect list when one changes. If you comment on a line, or mention her in a comment on the pull request, she reads it, makes the change, pushes it, and replies, until you merge or close it. Tell her to leave a file alone and she will. A comment that only says it looks good or says thanks does not set her working. Fixes she makes on a later day go into the week's open pull request rather than a second one.

Nothing reaches your site until you merge. See Reviewing and merging.

Follow and stop a run

A run of fixes can take a while on a single page, and you can watch it as it happens. Open the run from Activity to see the searches Lyra runs, the sources she opens, and the parts of each page she changes. A refresh also shows which draft she is writing, why the last one was turned down, and whether the sources backed the finished page up.

To end a run, click Stop. It stops within seconds, nothing is changed on your site, and the fixes stay for her next run. Your website is free again straight away, so anything queued behind it can begin.

When a fix cannot be made

Not every fix works first time. A fix that cannot be made comes to rest with a reason on its card and in the run log, rather than a bare "Failed". Lyra gives a slow page several tries, then leaves it as it is. Nothing is lost: the fix stays on the week's report, and the next week's report offers it again. A run that runs out of time says so.

Work waiting on your Claude usage limit waits it out. Lyra holds it for more than five hours, so it starts itself once the limit lifts.

When trying again could help, a skipped or failed fix has a Retry button. Click it and Lyra picks the fix up straight away, and the card updates as she works. Fixes to your own pages, and changes you already made or declined in an earlier week, stay as they are.

Without a repository

No repo, no dead end. Every fix arrives as a written instruction under "Yours to apply", with the numbers behind it. You can follow them by hand, copy them with the Copy button, or connect a repository later and have Lyra carry the fixes out as pull requests straight away.

Run a report on demand

You do not have to wait for the schedule:

1. Open SEO Copilot.
2. Click Run this week now at the top of the page.
3. Wait a few minutes. The page updates itself when the report is ready.

Each on-demand run reads fresh data and writes a full report, so there is a daily cap on how often you can ask. It counts against the same report allowance as the scheduled run. The button says when a report is already being written, or when a plan's allowance is spent.

Quiet weeks and failures

• A quiet week reads as quiet. The page shows All clear and "Nothing needed doing this week". Lyra does not invent work to fill the page. Ask what I checked shows what she looked at.
• A week that did not finish says so. The page explains that nothing about your site changed and Lyra tries again on the next run, with what went wrong underneath.
• A week Search Console did not fully report says so, so a quiet tail is never described as your site going quiet.

Weekly archive

Weekly briefings lists every report so far: its date, headline, and click change. Open an older week to see whether a past recommendation played out. Lyra reads her own earlier weeks before writing a new one, so she stops suggesting a fix that has already shipped or one you declined.

Usage and plans

The weekly report and your questions count against your plan's allowance. Reports include both the scheduled weekly run and Run this week now.

On paid plans the allowance is per billing cycle, and on Free it is a lifetime total. When a plan has fewer reports than weeks in a cycle, the scheduled run is skipped rather than withheld, so a spent month costs nothing. See Plans and pricing for the full comparison.

What's next

• Analytics: The data behind the weekly briefings.
• Configure your website: Set the keywords Lyra watches.
• Reviewing and merging: How pull requests reach your site.
• Plans and pricing: Report and question allowances by plan.