Nolasīt Search Console un rīkoties atbilstoši mēnesim

Kad izmantot

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.

Pirms sāc

• 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.

Ko izpilde pieprasa1

Ceļš8 soļi

1. S1

   Pull Search Console data for the last full monthaģents

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

   Izdarīts, kad both months' exports exist with identical date ranges.

2. S2

   Pull site analytics for the same rangeaģents

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

   Izdarīts, kad the two data sets cover the same dates.

3. S3

   Name the findings, each with a numberaģents

   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.

   Izdarīts, kad 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 reportaģents

   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).

   Izdarīts, kad the draft fits one page and every proposed action names the page and the change.

5. S5

   Pick the actionsīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S5 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

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

   Izdarīts, kad 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 changesaģents

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

   Izdarīts, kad each approved on-page change is live on the site and the old text is saved.

7. S7

   Record what was done and what waitsaģents

   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).

   Izdarīts, kad the log row exists and every deferred action has a task with a due date.

8. S8

   Send the report to the owneraģents

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

   Izdarīts, kad the owner has received it and the log row is linked.

Pārbaudes — kā zinām, ka izdevās

• 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.

Ja noiet greizi

Ko atstāj katrs solis

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.

Ko saglabāt

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.

Kā šī procedūra uzlabojas

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.