Skip to content

Monitoring runbook

30-day Google Search Console monitoring runbook

Use this after a WordPress migration, redesign, domain move, or CMS rebuild goes live. It tells the owner exactly which Search Console reports to check, what to export, and when a finding becomes a fix ticket.

Read the monitoring guideDownload CSV log

Citation-ready answer

Monitoring answers to extract during the first 30 days

The runbook is useful when each answer names the report, the failure threshold, and the URL-level next action.

What is a GSC monitoring runbook?

A GSC monitoring runbook is a daily operating log for Search Console evidence after a migration, redesign, or CMS rebuild. It tracks performance, indexing, sitemap, crawl, URL Inspection, and escalation signals.

When it breaks

It breaks when teams only check total clicks, skip URL groups, ignore sitemap read state, or request indexing before the live page is fixed.

Inspect first

Inspect Search results, Pages, Sitemaps, Crawl stats, Manual actions, Security issues, URL Inspection, and the GA4 landing-page trend in the same date window.

Source: Google traffic-drop guidanceRelated: Traffic-drop recovery audit

What should be logged daily?

Each daily row should record the report, URL or metric, baseline, current value, threshold, diagnosis, fix owner, deployment state, and next check date.

When it breaks

Monitoring becomes weak when evidence is scattered across screenshots, messages, and dashboards without a URL-level owner or follow-up date.

Inspect first

Start with P0 URLs, sitemap state, indexing reasons, query or page deltas, and whether the current live page now passes the same check.

Source: URL Inspection helpRelated: Monitoring-log CSV

When is escalation needed?

Escalation is needed when indexed pages drop, priority URLs disappear, sitemap processing is stale, URL Inspection shows canonical or noindex conflicts, crawl stats spike with errors, or lead tracking breaks.

When it breaks

Escalation is delayed when teams wait for ranking recovery without checking whether Google can crawl, index, canonicalize, and measure the new pages.

Inspect first

Compare the failed URL group against redirects, canonicals, robots directives, sitemap inclusion, internal links, and production analytics events.

Source: Google sitemap guidanceRelated: 48-hour recovery checklist
Diagnostic stepQuestion to answerAction when it fails
PerformanceWhich pages or queries lost impressions, clicks, or CTR?Segment the drop before changing content or redirects.
IndexingWhich reasons affect priority URLs?Group by template and fix the shared cause.
SitemapsWas the clean sitemap read and does the count match expected URLs?Repair the sitemap before resubmitting it.
URL InspectionDoes the live test pass after the fix?Request indexing only after the page is crawlable and canonicalized correctly.

Daily checks

Search Console reports to review every monitoring day

ReportCadenceWhat to doEscalation trigger
Performance > Search resultsDaily, then weekly summaryCompare clicks, impressions, CTR, and average position against the pre-launch baseline. Split brand and non-brand queries.Investigate if non-brand impressions drop 20 percent day over day, or 30 percent week over week.
Performance > PagesDailySort by click loss and impression loss. Mark P0 URLs that had traffic before launch and now dropped or disappeared.Escalate if a P0 page loses 30 percent of impressions or no longer appears in the top page export.
Performance > Countries and devicesEvery 2 daysCheck whether the drop is isolated to one country, mobile, desktop, or a template used by one device experience.Investigate if mobile drops while desktop is stable, or one target country loses visibility while others do not.
Indexing > PagesDailyTrack indexed count, not indexed count, and reason changes. Export new noindex, duplicate, soft 404, redirect, and crawled not indexed rows.Escalate if indexed pages fall more than 10 percent, or if excluded priority URLs share the same reason.
Indexing > SitemapsDaily for week 1, then twice weeklyConfirm the submitted sitemap is read, current, and close to the expected URL count. Record last read date and discovered URLs.Resubmit only when the sitemap is fixed and GSC evidence shows stale, missing, or unprocessed sitemap state.
Settings > Crawl statsDaily for week 1, then twice weeklyWatch crawl volume, response codes, file type distribution, and spikes in 404, 5xx, redirect, or robots-blocked responses.Escalate if Googlebot is spending crawl on redirects, 404s, 5xx responses, or old URL patterns.
Security and Manual ActionsDaily for week 1, then weeklyCheck Manual actions and Security issues even when the migration looked technical. Record a screenshot either way.Any manual action or security issue is a P0 incident and should stop routine monitoring until resolved.
URL Inspection10 to 20 URLs per dayInspect rotating P0 URLs. Record availability, indexing state, user-declared canonical, Google-selected canonical, sitemap discovery, and last crawl.Request indexing only after the live test confirms the fixed page is indexable, canonicalized correctly, and in the sitemap.

Source of truth

Search Console data needs a fixed interpretation rule

The runbook works because each report has a specific job. Mixing indexed-state evidence, live-test evidence, crawl evidence, and analytics evidence creates false fixes.

Separate indexed data from live-test data

URL Inspection has the indexed view and the live test view. Use the indexed view to see what Google last stored, then use the live test only to prove the fixed page is currently available before a request.

Treat Page Indexing as the coverage trend, not the whole URL list

The Page Indexing report is the best aggregate view of indexed and non-indexed pages, but examples are not a complete export of every affected URL. Keep your own priority URL list from GSC, GA4, sitemap, crawl, and backlinks.

Use Crawl Stats to find crawl waste

Crawl Stats counts actual URLs requested by Googlebot. Redirect chains can show as separate crawl requests, so a rising redirect share points to crawl budget being spent on old paths or chained rules.

Do not force GSC and GA4 to match

Search Console and Analytics process different data. Use GSC for queries, impressions, indexed state, and Google-selected canonicals; use GA4 for landing-page sessions, events, and conversion impact.

30-day cadence

The first month has different jobs each week

Launch day is about proving the new site is crawlable. Week two is about priority URL loss. Week three is about canonical and template patterns. The final week is handoff, not silence.

Day 0 to 2

Launch-state capture

Submit clean sitemap, live test top URLs, confirm GSC property, export launch baseline, and check noindex or robots mistakes.

Day 3 to 7

Discovery and crawl response

Confirm Googlebot is crawling new URLs, compare Pages reasons, watch 404 and redirect spikes, and inspect top pages by old traffic.

Day 8 to 14

Priority URL loss

Compare page/query performance, export top URL drops, run a supporting crawl, and fix redirects, canonicals, internal links, or thin templates.

Day 15 to 21

Canonical and template patterns

Group excluded URLs by template, inspect Google-selected canonicals, check country/device splits, and verify rich-result or schema regressions.

Day 22 to 30

Handoff and escalation

Summarize open issues, final indexed count, performance trend, fixed URL groups, recrawl requests, and whether ongoing Ops monitoring is needed.

Monitoring log

Spreadsheet columns for the daily runbook

Keep one row per finding. A row is not closed until the fix is deployed, the live test passes, the recrawl request is recorded when appropriate, and the next check date is set. Start from the downloadable CSV if the team does not already have a monitoring tracker.

Download monitoring-log CSV

Date checked

Owner

GSC report

Metric or URL

Pre-launch baseline

Current value

Threshold

Diagnosis

Fix owner

Status

Next check

Example rows

How findings should be written before escalation

FindingEvidenceNext stepStatus
Top URL dropP0 service page impressions down 38 percent week over week.Inspect URL, compare declared vs Google canonical, verify internal links, and crawl final status.Investigating
Sitemap not readSubmitted sitemap last read date is still launch day and discovered URL count is below expected.Fetch sitemap, remove redirects/noindex/404s, resubmit after the file is clean.Fix first
Indexed count dropIndexed URLs down 12 percent and excluded rows share duplicate without user-selected canonical.Group by template, check canonical tags, sitemap URLs, and redirect targets for the affected group.P0
Country/device splitMobile impressions down in the primary market while desktop and other countries are stable.Run mobile fetch/render checks, CWV checks, hreflang/canonical checks, and mobile template crawl.P1
Manual action or security issueManual Actions or Security Issues report is no longer clean.Stop routine monitoring, capture evidence, fix root cause, and submit reconsideration only when resolved.P0 incident
Redirect crawl spikeCrawl stats show Googlebot spending a growing share of requests on 301s and old paths.Collapse redirect chains, update internal links, and confirm old URLs land on final canonical 200 pages.P1

Supporting assets

Use the runbook with the right diagnostic page

Post-launch monitoring guide

Use this for the narrative explanation of why the 30-day window matters.

Open resource

48-hour recovery checklist

Use this when the drop is already visible and the first job is evidence preservation.

Open resource

Traffic-drop recovery audit

Use this when the runbook exposes P0 redirect, canonical, indexing, or tracking failures.

Open resource

Redirect map template

Use this when GSC Pages or Crawl Stats points to old URLs, redirect chains, or missing mappings.

Open resource

Canonical issue worksheet

Use this when URL Inspection shows Google-selected canonicals that disagree with your declared targets.

Open resource

WordPress speed test

Use this when device splits or Search Console Core Web Vitals suggest performance regressions.

Open resource

If the runbook finds P0 failures, fix before requesting recrawl

Send the launch date, GSC access, GA4 access, sitemap, redirect map, crawl export, and the runbook rows that failed. The useful output is a fix order, not another dashboard screenshot.

Open recovery audit