Run an AI SEO audit using Search Console data

Run a reproducible AI SEO audit from stable Search Console windows through evidence-backed repository changes and post-deployment validation.

Derived analysis Automatable now Intermediate

An effective AI SEO audit starts with a business objective, stable Google Search Console evidence, and a defined execution boundary. It does not begin with a generic checklist or a request to “improve SEO.”

Search Console can show which pages, queries, countries, devices, and search-result types changed. An AI agent can connect that evidence to the website and its repository, but it must distinguish what Google reported from calculations, interpretations, and unproven causes.

Start here: Sign up to SearchConsole.ai for free, connect it to your preferred AI agent, and use the audit prompt near the end of this guide. SearchConsole.ai provides a hosted, read-only connection, so you can begin with evidence instead of building Google OAuth and Search Console API infrastructure.

This workflow produces a prioritized report, a small set of supported actions, safe repository changes when authorized, and an exact measurement plan.

Understand what this audit can answer

Use the audit to answer:

What should this site do next to improve qualified organic traffic and the business outcome it supports?

SearchConsole.ai can retrieve:

clicks, impressions, CTR, and average position;
stable daily trends and equivalent-period comparisons;
rows grouped by page, query, device, country, date, or search appearance;
the queries associated with an exact page;
submitted sitemap status, warnings, errors, and content counts;
Google's indexed-version evidence for selected URLs.

Search Console does not report conversions, qualified leads, revenue, profit, or customer value. It also cannot prove why a ranking changed. If business metrics are unavailable, the audit should use a clearly labeled proxy—such as transactional query intent—and identify the missing conversion evidence.

Several Search Console UI reports are not available through the Search Analytics, URL Inspection, or Sitemaps APIs. Confirm manual actions, security issues, Page Indexing totals, Crawl Stats, and property-wide Core Web Vitals in the Search Console interface when the evidence points in those directions.

Define the audit contract

Give the agent a short contract before it retrieves data:

Input	What to specify
Business objective	Qualified clicks, signups, leads, sales, subscriptions, or another measurable outcome
Property	Exact `sc-domain:` or URL-prefix property returned by Search Console
Scope	Whole site, directory, template, market, product line, or named URLs
Search types	Web first; image, video, news, Discover, or Google News separately when relevant
Known events	Releases, migrations, redesigns, outages, campaigns, seasonality, or content removals
Execution mode	Recommend only, propose then execute, or execute safe repository changes now
Confidentiality	Whether query and page details can be saved in the repository

Do not silently choose a property when several are available. A Domain property such as sc-domain:example.com and a URL-prefix property such as https://www.example.com/ can cover different traffic. The exact property identifier belongs in the report.

Choose the execution mode explicitly:

Recommend only: analyze and report without editing files.
Propose then execute: present the supported changes and wait for approval.
Execute now: implement safe, non-destructive changes in the open website repository, then test and report them.

SearchConsole.ai remains read-only in every mode. Repository editing, testing, publishing, and deployment are separate capabilities controlled by the connected agent and its approvals.

Stage 1: establish a stable baseline

Ask the agent to read the SearchConsole.ai SEO analysis playbook and retrieve the audit baseline before choosing opportunities. The baseline should determine a stable cutoff rather than assuming yesterday's data is complete.

SearchConsole.ai normally excludes at least the latest three days and checks Google's first_incomplete_date. If Google reports an earlier incomplete date, the baseline moves the cutoff to the previous complete day. Record both the requested and actual cutoff.

Use these windows:

View	Current window	Comparison	Purpose
Primary	Latest complete 90 days	Preceding 90 days	Smooth noise and show material direction
Short-term	Latest complete 28 days	Preceding 28 days	Detect recent movement
Seasonal	Current 90 days	Same dates one year earlier	Check recurring demand and seasonality
Trend	Daily data within the current 90 days	Releases and known events	Find drops, spikes, or change points

Use longer windows for low-volume properties. A seven-day comparison can help investigate a high-volume incident, but it should not replace the 28- and 90-day context.

Google documents that fresh Search Analytics data may be incomplete and can expose first_incomplete_date when the request uses the appropriate data state and date grouping. Daily Search Console dates follow the America/Los_Angeles time zone, which can differ from analytics or business reporting time zones. See the official Search Analytics query reference.

The baseline must state:

property and Search type;
exact start and end dates;
data state and stable cutoff;
clicks, impressions, CTR, and average position for each window;
absolute and percentage changes where mathematically meaningful;
daily trend and known event dates;
whether year-over-year data was available.

Do not interpret a percentage change from a zero or tiny baseline as a major opportunity. Rank material movements by absolute click and impression difference first, then use percentages as context.

Stage 2: segment the evidence

Property totals reveal direction, not cause. Retrieve bounded comparisons by:

page;
query;
device;
country;
search appearance;
relevant Search type.

Keep Search types separate. A Web Search conclusion should not silently include image, video, news, Discover, or Google News data. Keep searchAppearance as the only grouping dimension in its request, then compare its result with page or query evidence through separate calls.

Interpret the metrics together:

Pattern	What it establishes	What it does not establish
Clicks changed	Organic visits from Google results changed	Why the change happened or whether visits converted
Impressions changed	Search visibility or demand changed	Whether ranking, demand, indexing, or query mix caused it
CTR changed	Clicks per recorded impression changed	That the title alone caused it
Average position changed	The average topmost position changed	A fixed rank for every user and query

Google recommends focusing more on clicks and impressions than absolute position. Search results vary by time, location, device, and user context. Use position diagnostically and compare like with like.

Check row coverage before drawing conclusions

The API returns top rows rather than a guaranteed complete dataset. A request can return up to 25,000 rows, and additional rows can be requested with offsets, but successful pagination still does not prove that Google exposed every underlying row.

SearchConsole.ai can perform bounded pagination for page and query samples. Record the requested maximum, returned row count, whether pagination was exhausted, and any coverage warning. Do not call the sample a complete export.

Some low-frequency, personal, or sensitive queries are anonymized. They contribute to unfiltered chart totals but do not appear as query rows, and applying a query filter can remove anonymized contributions from totals. Google's Search Console data documentation also explains why table sums can differ from chart totals and why Search Console can differ from analytics.

Separate branded and non-branded demand

When the brand and common variations are known, compare branded and non-branded query groups. This prevents strong navigational demand from hiding changes in discovery traffic.

Query filters and classifications are not lossless because of anonymization and truncation. Treat the split as an analytical view, not an accounting reconciliation. If the brand is ambiguous, ask rather than placing unrelated queries into the branded group.

Stage 3: identify winners, losses, and opportunities

Start by comparing pages and queries across the exact stable windows. For each row, calculate:

click and impression differences;
click and impression percentage changes when the earlier value is nonzero;
CTR-point difference;
average-position difference.

Sort losses by absolute lost clicks. A 20% loss from 10,000 clicks usually deserves review before a 100% loss from two clicks. Also identify meaningful winners: a new or growing page can reveal a successful topic, format, internal-link path, or search appearance worth extending.

Use the following diagnostic matrix as a hypothesis generator:

Observed pattern	Plausible explanations	Next evidence
Impressions down; position stable	Lower demand or seasonality	Year-over-year query trend and external demand evidence
Clicks down; impressions and position stable; CTR down	Search-result presentation or intent mismatch	Device, search appearance, title, snippet, and query-page fit
Position, impressions, and clicks down broadly	Technical, quality, competitive, or ranking-system change	Affected page groups, indexing evidence, releases, and Search Console UI checks
Decline isolated to one template	Template, metadata, canonical, content, or internal-link change	Compare affected and unaffected URLs using that template
Impressions up while average position falls	Visibility expanded into more lower-ranking queries	Newly appearing queries and their relevance
Mobile declines while desktop holds	Mobile rendering, UX, parity, or result-page difference	Mobile pages, templates, Core Web Vitals, and device query mix
Search appearance disappears	Eligibility, markup, or reporting change	Structured data, affected URLs, and enhancement reports

Google's official traffic-drop debugging guide also points to algorithmic changes, technical issues, security issues, spam actions, seasonality, changing interests, and site moves. These are investigation branches, not causes the agent should assert from a graph alone.

Stage 4: build the search opportunity map

Top rows are normally sorted by clicks, so they can hide high-impression queries with few clicks. Retrieve a sufficiently large bounded query sample, then re-sort it locally.

Shortlist opportunities in this order:

Find high-impression relevant queries and intent clusters.
Compare their clicks, CTR, and position with the previous equivalent period.
Identify the current page or pages receiving impressions.
Separate likely CTR opportunities from weak-ranking or intent-alignment problems.
Prioritize positions roughly 4–15 as a useful heuristic, not a Google rule.
Drill into the exact page to retrieve its leading queries.
Confirm that the query matters to the stated business objective.

Do not use a universal CTR benchmark. A query at position 30 normally earns fewer clicks than one at position 5, and device, country, brand, and search appearance can change expected CTR. Compare related rows under similar conditions.

Group close query variations by intent instead of recommending one page per keyword. Then choose one path:

Decision	Use it when
Improve existing page	A relevant canonical page already receives impressions and can satisfy the intent without losing focus
Create a distinct page	Demand is persistent and valuable, the intent is materially different, and the site can provide genuinely useful information
Consolidate or clarify targeting	Substantially overlapping pages serve the same intent and repository evidence confirms redundancy
Monitor	The movement is small, temporary, low confidence, or already performing well

Multiple pages appearing for one query do not automatically mean “cannibalization.” They may serve different intents or result formats. Recommend consolidation only after inspecting both the page-query evidence and the actual content.

Stage 5: verify indexing, sitemaps, and implementation

Use URL Inspection for a representative sample rather than every URL:

important pages losing clicks;
high-impression opportunity pages;
newly published strategic pages;
URLs suspected of canonical, robots, fetch, or indexing problems.

Check the verdict, coverage state, last crawl, page fetch, robots state, user-declared canonical, Google-selected canonical, and supported enhancement evidence. Google's URL Inspection API reference states that the API reports the version in Google's index. It is not a live URL test.

An excluded URL is not automatically broken. Redirects, duplicates, parameter URLs, and alternate canonicals may be intentionally excluded. The question is whether each important canonical page has the intended state.

Review submitted sitemaps for status, last download, warnings, errors, and content counts. The API describes what Search Console knows about a submitted sitemap; it is not a live crawl of the file. SearchConsole.ai's Search Console operations do not submit or delete sitemaps.

Then inspect the actual website or repository:

route and canonical URL generation;
title, visible heading, and meta description logic;
indexability, robots rules, redirects, and status codes;
structured data representing visible page content;
sitemap generation and last-modified behavior;
internal links and anchor text;
content alignment with the supported query intent;
releases or template changes matching the observed dates.

Google can form title links from multiple page and link signals, not only the <title> element. Treat title and snippet changes as experiments, never guaranteed CTR gains. Follow Google's title-link guidance and avoid vague, duplicated, excessively long, or keyword-stuffed titles.

For canonical issues, align redirects, rel="canonical", sitemap URLs, and internal links. Do not point different canonicalization methods at conflicting URLs. Google's canonicalization guidance explains the relative signals and common conflicts.

Prioritize supported actions

Score recommendations using the affected demand, business value, evidence confidence, implementation effort, and reversibility. A useful internal heuristic is:

priority = potential qualified click gain × business value × confidence ÷ effort

This is not a Google metric and should not be presented as one. When conversion data is missing, label the business-value assumption and ask the site owner to validate it.

Every major recommendation should contain:

Finding: what the data shows.
Evidence: property, exact dates, page or query segment, and metrics.
Interpretation: a clearly labeled explanation or hypothesis.
Action: the smallest concrete change justified by the evidence.
Priority: critical, high, medium, or low.
Impact: expected KPI direction without unsupported traffic promises.
Effort: small, medium, or large.
Confidence: high, medium, or low.
Validation: post-change window and decision rule.

Return five to ten actions only when the data supports that many. Fewer evidence-backed actions are better than a long generic checklist.

Implement safe repository changes

When execution is authorized and the correct website repository is open, the agent should inspect existing patterns and complete safe, evidence-backed work such as:

descriptive title or meta-description improvements;
heading and content alignment using known product facts;
useful internal links between relevant existing pages;
corrections to canonical or structured-data generation;
sitemap-generation fixes supported by indexing evidence;
a distinct page only when intent and source facts are sufficient.

The agent must not invent product claims, testimonials, prices, policies, or expert evidence to fill a content gap. Missing facts, brand decisions, CMS access, credentials, or risky changes belong under Needs input or access.

Ask before publishing, deploying, changing an external service, performing destructive work, or spending money. After editing, run relevant tests and inspect the final diff. Never describe a recommendation as implemented unless the files actually changed and verification ran.

Define SEO experiments and validation

Turn high-priority changes into focused experiments. Record:

exact baseline dates, page, query cluster, and metrics;
the single primary hypothesis;
changed files or settings and the deployment date;
primary KPI and expected direction;
stable evaluation window;
rule for supported, rejected, or inconclusive results.

For a high-volume page, a 14-day check can be an early signal, but use at least one complete 28-day post-change window for the main decision. Low-volume pages may need six to eight weeks or a predefined impression threshold. End every evaluation window before Google's incomplete-data boundary.

Do not run overlapping changes against the same page and query segment when their effects cannot be separated. SEO outcomes are affected by demand, competitors, crawling, and ranking systems, so even a well-timed improvement remains evidence of association rather than perfect causal proof.

Save a reproducible audit report

Save the report using the repository's documentation convention or:

docs/seo/search-console-audit-YYYY-MM-DD.md

Use this structure:

# Search Console audit — YYYY-MM-DD

## Executive summary
## Scope, property, business objective, and execution mode
## Exact windows and data-quality notes
## Performance snapshot
## Winners and losses
## Search opportunity map
## Technical and indexing findings
## Prioritized actions
## Implemented now
## Needs input or access
## SEO experiments
## Measure later
## Files changed and verification
## Data limitations

The performance snapshot should use a table:

Metric	Current period	Comparison period	Change
Clicks
Impressions
CTR
Average position

Record whether the report contains full or redacted evidence. Query strings, unpublished URLs, and business performance can be confidential. Do not commit credentials or sensitive Search Console evidence to a public repository.

Use a complete starter prompt

Use this prompt for an execution-oriented audit:

Use SearchConsole.ai to audit my SEO and identify the highest-impact opportunities. Read and follow the SearchConsole.ai SEO analysis playbook before analyzing data. Confirm the exact property and business objective, then retrieve a stable audit baseline before drilling down. Compare complete 90-day, previous 90-day, year-over-year, current 28-day, and previous 28-day windows where available. Preserve the baseline's Search type, data state, and cutoff. Analyze bounded page, query, page-query, device, country, and search-appearance evidence; state pagination coverage and data limitations. Rank material losses by absolute impact, re-sort high-impression query opportunities locally, group variants by intent, and distinguish facts, calculations, and hypotheses. Inspect relevant indexing, sitemap, website, and repository evidence before recommending changes. Implement every supported safe, non-destructive improvement that can be completed in the current website repository, run relevant tests, and save docs/seo/search-console-audit-YYYY-MM-DD.md. Ask before publishing, deployment, destructive work, paid actions, external-system mutations, or creating a schedule. Include implemented work, blocked actions, experiments, and a stable validation plan. Do not produce a day-by-day implementation plan or promise rankings or traffic.

For analysis only, replace the implementation sentence with:

Recommend only. Do not edit the repository or create files.

For proposal-first work, use:

Show the evidence-backed proposal and wait for my approval before editing.

Review the audit before accepting it

Reject or revise the report if it:

guessed the property or dates;
used incomplete recent data without labeling it;
combined different Search types;
treated returned query rows as complete;
ranked tiny percentage changes above large absolute losses;
treated low CTR without considering position or query intent;
called page overlap cannibalization without inspecting both pages;
described indexed-version inspection as a live test;
treated every excluded URL as an error;
confused clicks with conversions or analytics sessions;
claimed causation or guaranteed traffic;
proposed a long generic checklist without exact evidence;
said files, reports, deployments, or schedules existed without verifying them.

Google's Performance report documentation explains metric definitions, aggregation, preliminary data, and why chart and table views can differ. Use those limitations as part of the audit contract, not as an excuse to avoid clear recommendations.

Next step

After changes are deployed, schedule a re-audit based on the implementation date and required stable measurement window. Preserve the original report so the next run can compare the new evidence, implementation status, and experiment results with the exact baseline.

Separately use the weekly Search Console audit guide to maintain dated, non-overwritten history. A weekly snapshot detects movement; a post-change re-audit judges the specific hypotheses recorded here.

Connect SearchConsole.ai for free and run this workflow with read-only Search Console evidence in the AI agent where you already work.