Read Search Console and act on the month

When to use

The scheduled monthly read of search performance for a site the company controls. Not for first-time setup — Search Console must already be verified; use tech.connect-search-console. Not for a new site with almost no data — use growth.launch-website first and start this playbook once a full month of data exists. Not for competitor research — that is growth.competitor-scan.

Before you start

• The previous month is complete — do not run on the 1st against a partial month.
• Last month's report is at hand, so comparisons are month over month, not from memory.
• The owner has said what the site is for this quarter (leads, sales, brand) — it decides which findings matter.

What a run requires1

The trail8 steps

1. S1

   Pull Search Console data for the last full monthagent

   Export queries, pages, clicks, impressions, average position and CTR; pull the same range for the previous month.

   Done when both months' exports exist with identical date ranges.

2. S2

   Pull site analytics for the same rangeagent

   Sessions, top landing pages, sources, conversions if tracked.

   Done when the two data sets cover the same dates.

3. S3

   Name the findings, each with a numberagent

   Look for: queries where the page sits at positions 4–15 (near-page-two), queries with impressions but CTR below ~2% (weak title/description), pages that lost clicks month over month, pages that gained, indexing errors or coverage drops in Search Console.

   Done when there are at most five findings, each written as "page/query, number last month, number this month, suspected cause".

   ⛔ A finding without both months' numbers is not a finding — cut it or go get the numbers.

4. S4

   Draft the one-page reportagent

   Three parts: what changed (top 5 by movement), the findings from S3, proposed actions — one concrete action per finding (rewrite a title, add a section to a page, fix an indexing error, build internal links).

   Done when the draft fits one page and every proposed action names the page and the change.

5. S5

   Pick the actionsownerneeds approval · owner

   Approval · S5 · owner — the run stops until a named person records the decision

   Read the report; approve, change or reject each proposed action. Content that goes live must be approved here.

   Done when each proposed action is marked do / do-not, and do-actions have an owner and a due date.

6. S6

   Execute the approved on-page changesagent

   Apply title, description, content and internal-link changes in the site module. These are reversible — keep the previous text in the change record.

   Done when each approved on-page change is live on the site and the old text is saved.

7. S7

   Record what was done and what waitsagent

   Log the run in the monthly SEO log: findings, actions executed, actions deferred with their tasks (bc tasks add for each deferred action, linked to the goal with bc goals add if one exists).

   Done when the log row exists and every deferred action has a task with a due date.

8. S8

   Send the report to the owneragent

   Three lines: the biggest mover, the chosen actions, what waits. Link the report and the log row.

   Done when the owner has received it and the log row is linked.

Checks — how we know it worked

• Every finding in the report shows both months' numbers — read two findings back against the exports.
• Date ranges of S1 and S2 are identical and cover the full previous month.
• Every approved action from S5 is either executed (S6) or has a task with a due date (S7) — none are untracked.
• The log row links to the report and to the tasks.

If it goes wrong

What each step leaves behind

1. S1both months' exports exist with identical date ranges.
2. S2the two data sets cover the same dates.
3. S3there are at most five findings, each written as "page/query, number last month, number this month, suspected cause".
4. S4the draft fits one page and every proposed action names the page and the change.
5. S5each proposed action is marked do / do-not, and do-actions have an owner and a due date.
6. S6each approved on-page change is live on the site and the old text is saved.
7. S7the log row exists and every deferred action has a task with a due date.
8. S8the owner has received it and the log row is linked.

Evidence to keep

Both months' Search Console exports · analytics export · the one-page report · the owner's S5 decisions (who, when, what was changed) · the SEO log row · saved old titles/descriptions from S6.

How this playbook improves

After every 6 runs ask: did actions from a month show up in the next month's numbers (if never, the actions or the measurement is wrong)? How many findings were later proven wrong? Did any approved action slip more than one month? A new version changes the step that produced the misses, and says so in its change note.