Google Search Console With Claude Code: Complete SEO Workflow

Let the data choose the work

The common failure in SEO with an AI assistant is not bad writing. It is writing the wrong thing enthusiastically — publishing a dozen more articles because publishing is what the tool makes cheap, while the pages that already have demand sit at position 50 with nobody touching them.

Search Console fixes that, because it tells you what Google already associates with your domain. The loop:

Search Console  →  real queries and positions
      ↓
Analysis        →  which pages have demand and where they sit
      ↓
A short list    →  three to five specific changes
      ↓
Deploy          →  one at a time
      ↓
Measure         →  four to six weeks later, same report

This guide is about the middle. For what to check on the site itself, that is the Claude Code SEO workflow; for running the audit and submitting what changed, that is the technical SEO audit guide. Neither covers reading the performance data that comes back, which is the whole subject here.

What the four metrics actually mean

Average position is not a ranking. It is not a number you hold. One impression at position 6 and one at position 60 average to 33, describing a state the page was never in. Two consequences follow, and both matter more than they sound:

A row with a handful of impressions has an average position that is essentially noise. Set a floor — roughly ten impressions — below which you read a row as a hint rather than a finding. And a movement from 51 to 44 is usually the query mix changing, not the page improving.

Queries against pages, both directions

Two questions, and most people only ever ask the first.

Query → page. For this query, which URL does Google show? If it is not the one you intended, you have either a cannibalisation problem or a page that has been misunderstood.

Page → queries. For this URL, what is it actually being shown for? This is where the surprises live. A page written about one thing frequently earns impressions for an adjacent thing it barely mentions — and that is the clearest content signal Search Console produces.

A worked example from this site. The most-shown page was the guide on Claude Code skills, with 335 impressions in a month. Reading its queries rather than its position revealed that roughly a third were about installing a skill someone else wrote — "how to add skills to claude code", "how to download skills in claude code", "how to import skills to claude code" — an intent the article did not address anywhere. The fix was not a new article. It was three sections added to the page Google was already showing.

Windows, comparisons, and a new site

The default comparison is the last 28 days against the previous 28. It smooths weekday effects and is long enough that one odd day does not dominate.

A site move is the other reason to save windows before you need them. The migration SEO checklist starts with a twelve-month export from this report as the baseline, and explains what the Pages and URL Inspection tools can and cannot tell you afterwards.

Two adjustments worth knowing:

Data is not final immediately. Search Console finalises with a lag of roughly two days, so the most recent rows are provisional. In the API this is explicit: dataState takes final (the default) or all, and only the latter includes fresh data. If a report shows a cliff at the right-hand edge, check whether you are looking at incomplete days before concluding anything fell.

A young site has no 28-day comparison. Do not manufacture one. With three weeks of history the honest window is the whole of it, and the honest statement is that there is no trend yet. Say so in the report rather than presenting a comparison against a period of zeroes.

Position bands, and what to do in each

Positions 1–3 — leave alone. Editing a page that already ranks is the easiest way to lose the position, and there is little headroom above it. Protect these.

Positions 4–10 — optimise. The highest-value band. The page is already on page one and Google already considers it relevant. Gains here come from title and description alignment, a clearer answer in the first screenful, and internal links. This is the smallest work for the largest return.

Positions 11–20 — strengthen. Close, but Google is preferring something else. The cause is usually a genuine gap in coverage rather than metadata. Read the queries the page earns, find the sub-question it does not answer, and answer it.

Positions 21–40 — read as signal. Not close, but informative: Google associates your domain with this topic. Usually a content decision rather than an optimisation, and often the right answer is to wait for more data.

Past 40 — do not optimise. This is the band most people waste time on, because it is where the impressions often are. A page at position 55 does not reach page one through metadata. That distance is an authority problem, and rewriting the title will not close it.

CTR opportunities

The pattern to look for is respectable position, meaningful impressions, poor click rate. All three conditions, or you are chasing noise.

A rough expectation by band is enough to spot outliers — position 1–3 in the tens of percent, 4–10 in the low single digits, past 20 fractions of a percent. Use it to flag rows that fall well below their band, then look at each one by hand.

Two firm rules. A low CTR past position 20 is not a title problem; nobody scrolled that far. And never make a title more clickable than the page is accurate — you win a click and lose the visitor, and the pogo-stick back to the results is not a signal you want to send.

When there genuinely is no qualifying row, the correct output is "no CTR opportunities in this window". On a young site that will be the answer for months, and inventing rewrites to fill the report is how good pages get damaged.

Content gaps, and when not to write

Impressions on a query your page barely covers mean Google has associated your domain with a topic you have not properly served. That is the cheapest content signal available, and it comes with a decision:

The default should be the first row. A new page starts from zero; an existing one starts from wherever Google already put it.

The query-to-page table

The artefact worth producing. One row per query/page pair, sorted by whatever score you choose:

Those are real rows from this site. Note that none of them is in a band where optimisation reliably moves position — which is itself the finding, and the reason the actions are about serving the intent properly rather than tuning a title.

A simple score keeps the sort honest. Impressions carry the weight, because they are the only evidence demand exists; proximity multiplies rows in the 4–20 band where a gain is cheapest; commercial relevance breaks ties. Resist elaborating it. A score is a sort order, not a forecast, and a complicated one invites you to believe it.

The Search Analytics API

The interface is fine for looking. For anything repeatable, the API is better: it returns more rows, it can be diffed between runs, and it can be handed to a script without a manual export.

Practical points from the Search Analytics query reference:

• Dimensions are query, page, date, country, device, searchAppearance and hour, and can be combined.
• rowLimit has a valid range of 1–25,000, defaulting to 1,000.
• dataState is final by default. Pass all to include fresh, not-yet-finalised data.
• The response carries a metadata object with first_incomplete_date, which is how you know where the provisional data begins rather than guessing.
• Google states the API "does not guarantee to return all data rows but rather top ones" — so a query missing from a report is not proof it had no impressions.
• If you group or filter by page, you cannot aggregate by property.

On credentials: a service account with the property added as an owner is the least painful route for a script. Keep the key file outside the repository, readable only by its owner, and never let it reach a log, a commit, or a diagnostic paste. The same rules as any other secret, covered in the security audit guide.

Handing the data to Claude Code

Once the data is a file, the analysis is exactly the kind of tedious sorting an agent does well:

Here is a Search Console export: query, page, clicks, impressions,
CTR, average position.

Produce:
1. Rows at position 4-10 with at least 10 impressions, sorted by
   impressions. For each, one specific change to the ranking page.
2. Rows at 11-20 with at least 10 impressions. For each, the
   sub-question the page appears not to answer.
3. Rows where CTR is under half what the position band suggests,
   AND position is 10 or better, AND impressions are at least 20.
4. Any query where two or more of our URLs take impressions.
5. Queries with real volume whose ranking page only partly covers
   the intent.

Rules:
- Do not recommend a new page where an existing page could serve
  the intent. Say which page and what to add.
- Ignore any row under 10 impressions. Say how many you ignored.
- Do not estimate traffic, difficulty, or volume. You do not have
  that data.
- If a category is empty, say so. Do not fill it.

The last three rules do most of the work. Without the volume prohibition you will get confident invented numbers, because keyword data is abundant in training data and absent from your export. Without "if a category is empty, say so" you get a plausible list either way.

Improve the page that already ranks

Worth stating on its own because the instinct runs the other way.

A page with impressions has something a new page does not: Google has crawled it, indexed it, and decided it is relevant enough to show. Adding a section to it inherits all of that. A new page starts from discovery and, on a young domain, may wait weeks to be crawled at all.

So the order is: improve the ranking page; if the intent genuinely does not belong there, write a new page and link it from the ranking one; only then consider anything else.

Internal links, decided by data

Search Console also tells you where a link would help. Two patterns:

An emerging query on a page that mentions the topic in passing. Link from that mention to the page that covers it properly. You are telling Google which URL is the answer.

A page with impressions that no indexed page links to. On a young site this is the constraint that matters most — a link from a page Google has already indexed is worth considerably more than one from a page it has not yet crawled. Check which of your pages are actually indexed before deciding where to add links, or you may be linking from somewhere Google has never seen.

Indexing states, read correctly

The page indexing report is where the most misreading happens. Google's own definitions are worth quoting rather than paraphrasing:

"Discovered — currently not indexed": "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl."

"Crawled — currently not indexed": "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling."

Two things follow that contradict a lot of received advice. Neither state is an error, and neither is fixed by requesting indexing again. Google explicitly says no resubmission is necessary for the second. Repeated manual requests do nothing except consume your quota.

What does help: making sure the page is genuinely worth indexing, that it is reachable from pages Google has already indexed, that it is in the sitemap, self-canonical, and not accidentally noindexed. Beyond that, on a new domain, the answer is authority and patience.

Do check the mechanical causes before concluding it is patience: an unintended noindex in the rendered HTML, a canonical pointing elsewhere, a page missing from the sitemap, or a page nothing links to.

A weekly routine that survives contact

Ambitious routines get abandoned. This one takes about an hour.

The discipline is in the last two rows. Search results move for reasons that have nothing to do with you, and checking daily converts that noise into work.

What not to do

• Do not track daily rank movement. It is noise, and reacting to it is how pages get edited into worse shape.
• Do not rewrite pages weekly. You destroy the ability to attribute any change to anything.
• Do not create an article per query. That is how a site ends up with forty pages competing with each other.
• Do not request indexing repeatedly. Google says it is unnecessary; it is also rate-limited.
• Do not chase average position without impressions. Position 4 on a query with one impression is not an achievement.
• Do not let an assistant invent search volume or difficulty. If the number did not come from a request, it came from nowhere.
• Do not act on a row with under ten impressions. Write down the floor and hold to it.

Where to go next

This guide covers reading performance data. For what to check on the site itself, read the Claude Code SEO workflow; for running the audit and proving your checks can fail, the technical SEO audit; and on a storefront, Shopify SEO with Claude Code. The wider inspection is in the website audit guide, and the free short forms are the SEO checklist and website audit checklist.

The Search Console workflows here are two of twenty in the SEO & Website Audit Toolkit, sequenced against crawlability and indexation so you are not optimising metadata on URLs that are about to be canonicalised away.

Sources and further reading

• Google: Search Analytics query API — dimensions, row limits, dataState
• Google: page indexing report — the exact definitions of each state
• Google Search Central: getting started with Search Console
• Google: build and submit a sitemap