Automate a weekly Search Console audit

Automate stable, non-overwritten Search Console snapshots with materiality rules, failure handling, and evidence-based re-audit triggers.

Derived analysis Automatable now Intermediate

A weekly Search Console automation should preserve comparable evidence, identify material exceptions, and make historical changes easy to review. It should not run a generic SEO audit every seven days or reinterpret every small fluctuation as an incident.

The safest design has two separate workflows:

a lightweight weekly history job that records stable data and concise observations;
a deeper re-audit that evaluates a documented implementation or experiment after enough data has accumulated.

Start here: Sign up to SearchConsole.ai for free, connect the read-only MCP server to your preferred AI agent, and complete one manual AI SEO audit before scheduling the weekly workflow.

This guide defines the schedule, stable windows, repository files, task instructions, alert rules, failure behavior, confidentiality controls, and complete starter prompt.

Separate weekly history from a re-audit

The two jobs answer different questions:

Workflow	Question	Output	May implement changes?
Weekly history	What materially changed in the latest stable window?	One non-overwritten snapshot	No
Follow-up re-audit	Did a documented change or experiment work?	A new full audit linked to the previous audit	Only when separately authorized

The weekly job is an exception-finding routine. It records performance, identifies where a material movement is concentrated, and recommends whether to observe, investigate, or escalate. It must not edit SEO content, deploy code, publish pages, or judge a longer-running experiment before its declared evaluation window.

The re-audit reads the exact previous audit report, retrieves fresh comparable evidence, checks implementation status and experiment decision rules, and saves a new audit. Schedule it from the implementation or deployment date, not merely every week.

Keeping these jobs separate prevents routine noise from generating endless content changes and preserves the original experiment baseline.

Confirm the prerequisites

Before creating a schedule, verify:

SearchConsole.ai can list the intended property from the execution host;
OAuth is stored for the same operating-system user that will run the job;
the AI client can read the repository task brief and write only the reporting paths;
the repository corresponds to the Search Console property;
the chosen Search type and business objective are explicit;
query and page confidentiality rules are decided;
the first manual snapshot completes successfully.

A schedule does not solve authentication. Complete browser OAuth interactively before relying on a headless run. Configuration and credentials on a laptop do not automatically exist on a server, runner, container, or teammate's machine.

SearchConsole.ai's Search Console operations are read-only. The scheduled AI client may still have file or shell permissions so it can save the snapshot. Restrict those permissions to the working repository and instruct the job not to modify website code.

Define the weekly measurement contract

Write down the values that must remain stable between runs:

Contract field	Example or rule
Property	Exact `sc-domain:example.com` or URL-prefix identifier
Business objective	Qualified organic signups
Search type	`web`, with other types handled separately
Data state	Stable or finalized daily data
Schedule	Wednesday at 10:00 in a named timezone
Cutoff	Day before Google's `first_incomplete_date`, normally with at least a three-day lag
Primary window	Seven complete days ending on the stable cutoff
Comparison	Immediately preceding equivalent seven days
Context	Current, preceding, and year-earlier 28-day windows
Confidentiality	Full evidence in a private repository or redacted evidence in a public one
Output	Window-end snapshot path and history index

Use the exact same property, Search type, data state, dimensions, filters, and aggregation from run to run. If a definition must change, explain it in the next snapshot rather than silently breaking comparability.

Choose a weekday and time when delayed data is likely to be available, but always discover the stable cutoff from the response. The schedule time starts the job; it does not define which dates are complete.

Calculate stable windows every run

Begin each run with SearchConsole.ai's audit baseline. Request daily data using the data state that exposes incomplete-date metadata, then move the cutoff to the day before first_incomplete_date when necessary.

The weekly job should collect:

Window	Definition	Use
Current 7 days	Seven complete days ending at the stable cutoff	Latest weekly movement
Previous 7 days	Seven days immediately before the current window	Matching-weekday comparison
Current 28 days	Twenty-eight complete days ending at the cutoff	Less volatile direction
Previous 28 days	Immediately preceding 28 days	Recent comparison
Year-earlier 28 days	Corresponding dates one year earlier	Seasonal context when available

Record every exact start and end date. Search Analytics dates use the America/Los_Angeles time zone, even when the scheduler runs elsewhere. Google's Search Analytics reference documents dataState, first_incomplete_date, and the reporting timezone.

If the cutoff moves between runs because data is delayed, use the newly discovered complete window and record the change. Never fill a missing day with zero. When a date-grouped response omits a day, treat that as missing evidence until confirmed, not proof of no clicks.

For low-volume properties, the seven-day view may be too unstable. Keep it for history, but base alert decisions on the 28-day view or a minimum impression threshold.

Create the repository history structure

Use a predictable layout:

docs/seo/
├── search-console-weekly-history.md
├── search-console-re-audit.md
├── search-console-audit-YYYY-MM-DD.md
└── search-console-history/
    ├── README.md
    ├── search-console-weekly-2026-07-12.md
    └── search-console-weekly-2026-07-19.md

The date in a weekly filename is the stable seven-day window end, not the scheduler run date:

docs/seo/search-console-history/search-console-weekly-WINDOW-END.md

This makes reruns idempotent. If the target file already exists, the agent should verify that the window was recorded and report a duplicate instead of overwriting it.

The history README.md links snapshots newest first. Each snapshot links to the exact previous snapshot and latest full audit when available. Do not use a wildcard such as “find the newest report”; save explicit paths so the next run cannot select the wrong baseline.

Create the reusable task brief

Store the weekly instructions in:

docs/seo/search-console-weekly-history.md

The scheduler should invoke this checked-in brief rather than embedding a large prompt in the scheduled task. The repository file is reviewable, versioned, and can evolve without editing the external schedule.

Start the brief with machine-readable facts:

# Weekly Search Console history task

Property: sc-domain:example.com
Business objective: Qualified organic signups
Repository: /absolute/path/to/website
Search type: web
Data state: all, adjusted to exclude incomplete dates
Timezone: Europe/Madrid
Schedule: Wednesday at 10:00
Confidentiality: redacted
Previous snapshot: none
Latest full audit: docs/seo/search-console-audit-2026-07-20.md
Snapshot directory: docs/seo/search-console-history/

For the first run, Previous snapshot is none. Update it only after a new snapshot has been written and verified. Preserve the latest full audit pointer until a later completed audit replaces it.

The rest of the brief should contain the collection contract, comparison rules, output template, confidentiality mode, failure behavior, and explicit prohibition on implementation or deployment.

Collect the same evidence in a fixed order

Every run should follow one sequence.

1. Validate the connection and property

Confirm that SearchConsole.ai is available, OAuth is valid, and the exact property exists. Stop if the property is missing or the execution account changed.

2. Discover the stable cutoff

Retrieve the baseline, record the first incomplete date, and compute the stable 7- and 28-day windows. Stop if complete windows cannot be established.

3. Retrieve property totals and daily trend

Collect clicks, impressions, CTR, and average position for every required window. Include a daily table for the current seven days.

Use property-level totals for the scorecard. If metrics must be recomputed, calculate CTR as total clicks divided by total impressions; do not average row CTR values. Treat average position as a diagnostic rather than the primary success metric.

4. Retrieve bounded contributors

Collect:

top pages and queries for the current window;
largest absolute page and query click gains and losses;
device and country summaries;
search-appearance summary in a separate request;
relevant Search types in separate datasets.

Use bounded pagination and record returned row count, maximum requested rows, exhaustion state, and coverage warning. Search Analytics returns top rows and does not guarantee every underlying row. Anonymized queries contribute to some totals without appearing as query text.

5. Compare with recorded history

Read the exact Previous snapshot before interpreting the new data. Report whether the current material findings are new, continuing, recovered, or inconclusive. If the file is missing, stop and name the missing path rather than silently comparing with an unrelated snapshot.

6. Check contextual evidence

Review recent releases, migrations, incidents, campaigns, and the latest full audit stored in the repository. Timing is a clue, not proof of causation.

Check Google's Search Console data anomalies page before escalating an unexplained reporting movement. A logging or aggregation issue can change reported metrics without changing actual search performance.

7. Classify and save

Use four dispositions:

Disposition	Meaning
Escalate now	Likely sitewide serving, accidental blocking, security, or manual-action risk requiring immediate human checks
Investigate	Material stable movement concentrated in a valuable scope without an adequate explanation
Observe	Small, early, seasonal, low-volume, or inconclusive movement
Expected	Planned migration, campaign, removal, redirect, or other documented change behaving as intended

The job should describe evidence and the next check. It must not claim “Google penalized the site,” “the update caused the drop,” or another unverified cause.

Use materiality rules instead of noisy percentages

Create thresholds per property and important scope. A useful alert gate is:

material_change =
  data_is_stable
  AND previous_volume >= minimum_baseline_volume
  AND absolute_change >= minimum_absolute_change
  AND relative_change >= minimum_relative_change

Require both absolute and relative thresholds. A change from one click to six is 500%, but it may not matter. A 10% decline on a major conversion page can matter even when the percentage looks smaller.

Add persistence when the site is volatile: require the movement across several stable daily points, the 28-day context, or two completed weekly snapshots before escalating. Do not delay clear serving failures or high-risk losses merely to satisfy a generic persistence rule.

Thresholds should differ by scope:

property-level clicks need a larger absolute threshold;
a critical revenue page may use a smaller but business-sensitive threshold;
query alerts need enough visible impressions and must acknowledge anonymization;
CTR alerts need stable position, device, country, and query mix;
average-position movement alone should rarely page an owner.

Store threshold values in the task brief so a later run does not invent new criteria. When normal volume changes materially, review the thresholds and document the effective date.

Separate pipeline failures from SEO alerts

Operational failures include:

the scheduled run did not start;
OAuth expired or property permission changed;
SearchConsole.ai or the network was unavailable;
no stable cutoff could be established;
a normally active property returned no rows;
pagination failed or stopped early;
the expected previous snapshot was missing;
the target snapshot already existed;
the report failed validation or could not be saved.

These are automation incidents, not SEO performance findings. Report them to the workflow owner and suppress performance alerts until data collection is healthy.

Do not create an empty or partial snapshot after a failed run. Do not advance the Previous snapshot pointer or update the history index until the new file contains every required window and passes verification.

The safe write order is:

collect and validate all required evidence;
confirm the target filename does not exist;
write the new snapshot;
reopen it and verify the property, windows, sections, and confidentiality mode;
add it to the history index;
update the task brief's exact Previous snapshot path;
verify the final diff contains reporting files only.

Keep a small manual Search Console checklist

The public Search Console APIs do not expose every health report. The weekly snapshot should include a short human checklist for:

Manual Actions;
Security Issues;
Page Indexing changes;
Core Web Vitals and HTTPS;
Crawl Stats;
enhancement or shopping report errors;
Search Console messages and annotations.

URL Inspection can sample Google's indexed version of selected URLs, but it is not a complete crawler or a live test. Use it only after performance evidence identifies important pages worth checking.

Do not fail the automated data snapshot merely because the manual checklist has not been completed. Mark those checks as pending and assign an owner when the performance or release context warrants them.

Write a useful weekly snapshot

Each file should contain:

# Weekly Search Console snapshot — WINDOW-END

## Collection contract
## Data quality and stable cutoff
## Current vs previous seven days
## Current, previous, and year-earlier 28 days
## Daily trend
## Largest page gains and losses
## Largest visible-query gains and losses
## Device, country, and search-appearance context
## Comparison with previous snapshot
## Recent releases and known events
## Material findings and dispositions
## Manual checks
## Data limitations and confidentiality
## Links to previous snapshot and latest audit

The scorecard should include exact values:

Metric	Current 7 days	Previous 7 days	Absolute change	Relative change
Clicks
Impressions
CTR			percentage points
Average position

The snapshot is a historical summary, not a lossless data export. It must state row coverage, anonymized-query limitations, data lag, aggregation, and whether evidence was redacted.

Protect confidential search data

Search queries, unpublished URLs, performance metrics, and business classifications can be sensitive. Choose one mode:

Full: exact query and page evidence in a private, appropriately controlled repository.
Redacted: aggregate or hash sensitive queries, generalize private URLs, and preserve only enough evidence for review.
No repository persistence: send the report to an approved private destination instead of saving it with code.

Never store OAuth credentials, access tokens, browser cookies, or authorization callback URLs in task briefs or snapshots. Review repository visibility and access whenever a new teammate or external automation is added.

Markdown history is appropriate for reviewable summaries on small and medium sites. If the requirement is durable, complete, row-level retention at scale, use an approved database or Google's bulk data export and keep Markdown as the human-readable monitoring layer.

Create and test the schedule

Prefer a scheduling feature in the connected AI client when it can open the correct repository, use the authenticated SearchConsole.ai connection, and write the reporting paths. Otherwise, use a controlled scheduler that starts the chosen client with the repository task brief.

The scheduled task needs only a short instruction:

Open the configured repository, read docs/seo/search-console-weekly-history.md, and execute that weekly history task exactly. Do not implement SEO changes, deploy, publish, commit, push, or mutate external systems. Report the created snapshot path or the exact failure.

Configure:

weekday, local time, and timezone;
absolute repository working directory;
execution account and environment;
notification destination for success and failure;
maximum runtime and overlapping-run behavior;
least file and shell permissions needed;
retry policy for transient failures.

Ask before creating the external schedule because it is a persistent mutation. Test the first run manually, then run the scheduler once on demand. Confirm that both produce the same stable window and that the duplicate guard prevents overwriting.

Use a complete weekly task prompt

Put this instruction beneath the configuration block in docs/seo/search-console-weekly-history.md:

Use SearchConsole.ai to create the weekly Search Console history snapshot for the exact configured property. Read the SearchConsole.ai SEO analysis playbook first. Retrieve fresh data and discover the latest stable cutoff, excluding every date on or after Google's first_incomplete_date and normally keeping at least a three-day lag. Compare the stable current and preceding seven-day windows and the current, preceding, and year-earlier 28-day windows. Preserve the configured Search type, data state, filters, and aggregation. Include daily totals for the current seven days; bounded top pages and visible queries; largest absolute click gains and losses; and separate device, country, and search-appearance summaries. Record pagination coverage, anonymized-query limitations, data lag, exact windows, collection time, and confidentiality mode. Read the exact Previous snapshot and latest audit paths from this file. Label material movements as new, continuing, recovered, expected, or inconclusive without claiming causation. Apply the configured absolute, relative, baseline-volume, and persistence thresholds. Save a new docs/seo/search-console-history/search-console-weekly-WINDOW-END.md file using the stable window-end date, never the run date. Do not overwrite an existing snapshot or create a partial file after an API failure. Only after verifying the new file, add it to the history README.md newest first and update this brief's exact Previous snapshot path. Do not edit website code, implement SEO changes, deploy, publish, commit, push, spend money, or mutate an external system. Return the snapshot path, stable windows, material findings, pending manual checks, confidentiality mode, and any failure.

This task is intentionally conservative. A material finding should open an investigation or trigger the separate re-audit, not cause an unattended website change.

Review and maintain the automation

Review the job monthly at first and quarterly once stable. Confirm that:

OAuth and property access still belong to the intended account;
stable cutoffs and exact windows are correct;
the task brief and last snapshot point to real files;
scheduled runs do not overlap or overwrite history;
thresholds still match normal property volume;
reports remain redacted appropriately;
Search types and business priorities have not changed;
manual health checks have an owner;
the snapshot is still useful enough to justify its review cost.

Google recommends comparing similar periods, examining pages and segments, and considering seasonality when debugging traffic drops. Use the official traffic-drop debugging guide when a weekly exception becomes a deeper investigation.

Next step

After the first three or four snapshots, review whether the thresholds correctly separate noise from meaningful movement. Adjust them once with an effective date rather than changing the rules every time an alert feels inconvenient.

When a completed SEO experiment reaches its declared stable evaluation window, run the separate re-audit against the exact saved audit—not the weekly summary alone.

Connect SearchConsole.ai for free and give your AI agent stable, read-only Search Console evidence for every scheduled snapshot.