Pre- and post-launch monitoring

Establish a baseline and watch crawling, indexing, canonicals, errors, and performance after a major release.

Directional evidence Partially automatable Advanced

A launch-monitoring plan should distinguish expected recrawl and reporting lag from failures that need rollback or escalation. Search Console is essential Google-side evidence, but it is delayed and sampled in important places. Pair it with synthetic checks, a full crawler, server logs, uptime monitoring, analytics, and the deployment platform.

Identify the launch type

The monitoring plan changes with the release:

Launch type	Main Search risks
New domain/site	Discovery, verification, crawlability, sitemap, initial indexation
Redesign with stable URLs	Hidden `noindex`, rendering, internal links, canonicals, structured data, performance
Hosting/CDN move without URL changes	DNS, firewall, capacity, response codes, robots, retained verification
Migration with URL changes	URL mapping, permanent redirects, canonicals, sitemaps, old/new properties, temporary ranking fluctuation
Large feature/template release	Section-level rendering, status codes, metadata, indexability, result eligibility

Do not combine domain, CMS, design, URL, and content changes unless the business constraint makes that unavoidable. Google recommends changing one major thing at a time and, for large moves, considering a lower-risk pilot section.

Four to six weeks before launch

Governance and access

Verify the current and any new Domain/URL-prefix properties.
Ensure ownership verification will survive the release.
Confirm client/organization ownership, not only vendor access.
Add new properties and associations before they are urgently needed.
Document who can approve rollback, redirects, Change of Address, sitemap changes, and indexing actions.

For a hosting move, copy HTML verification files or meta tags to the new environment. For a domain move, keep old and new properties accessible throughout monitoring.

Inventory and URL mapping

Export the complete current canonical inventory from first-party systems and a crawler. Record:

status code and redirect destination;
canonical and hreflang relationships;
sitemap membership and lastmod;
internal links and click depth;
indexability directives;
structured-data and media types;
historic clicks, impressions, and conversions;
backlinks for high-value URLs from available sources.

For URL-changing migrations, map every valuable old URL to the most relevant new equivalent. Do not redirect everything to the homepage. Test the mapping before launch.

Search baseline

Save at least:

16 months of Performance where available;
high-value page/query/country/device/search-appearance groups;
Page Indexing totals and reasons by sitemap;
Sitemaps status;
Crawl Stats host status and response distribution;
Core Web Vitals, HTTPS, and relevant enhancement reports;
representative URL Inspection evidence;
manual actions, security issues, users, and ownership tokens.

Document seasonality, campaigns, Google incidents, and site releases that affect comparison.

One to two weeks before launch

Test production-equivalent pages for:

crawlable 200 responses;
correct robots.txt and absence of staging-only noindex;
one-hop permanent redirects where URLs change;
self-consistent canonical and hreflang links;
rendered primary content and crawlable navigation;
mobile parity and critical resources;
accurate structured data and visible values;
generated XML sitemaps containing only intended canonical URLs;
analytics, consent, and conversion tracking;
server capacity for users and increased Googlebot crawling;
useful 404 behavior and no soft-404 redirect patterns.

A password-protected or noindex staging environment is appropriate, but those controls must not reach production. Blocking staging only with robots.txt can still leave known URLs indexable without content; use authentication or noindex as appropriate to the environment.

Lower DNS TTL in advance for a hosting move when the infrastructure plan calls for it. Confirm firewalls and DDoS protection do not block verified Googlebot.

Launch window: first hours

Run automated checks immediately after traffic switches:

homepage and critical templates return expected status codes;
robots.txt and sitemaps load publicly;
canonical, hreflang, robots directives, titles, and structured data are correct;
old URLs redirect to their mapped destinations;
CSS, JavaScript, images, and APIs needed for rendering work;
analytics and conversion events arrive;
DNS and CDN behavior is correct across regions;
error rate, latency, and capacity remain within operational thresholds;
new and old server logs show the expected traffic transition;
representative Search Console live tests can fetch production.

Add a Search Console annotation and a durable release record. The annotation is shared, short-lived relative to long audit history, and hidden in comparison/24-hour views, so do not rely on it as the sole log.

Use URL Inspection requests for a small number of critical URLs. For a large launch, submit correct sitemaps; request indexing is not a bulk reprocessing mechanism.

First three days

Monitor multiple times per day:

uptime, DNS, origin/CDN logs, 5xx, 4xx, redirect loops, and latency;
Googlebot access and rendering resources;
Search Console messages and host status;
initial Page Indexing and Sitemap processing changes;
representative indexed/live URL evidence;
analytics traffic and conversion sanity;
24-hour preliminary Performance only as directional context.

Search Console can lag the live site. Operational monitoring should trigger rollback for serving failures before a Search Console graph does.

For a hosting move without URL changes, Google says a temporary crawl-rate drop immediately after launch can be normal, followed by recovery and potentially higher crawling. Keep the old infrastructure until logs show that users and Googlebot have moved successfully.

First four weeks

Review daily, then reduce frequency as the launch stabilizes:

indexed old versus new URL trajectories;
exact Page Indexing reasons by sitemap and template;
Google-selected canonicals;
redirect and 404 patterns;
Crawl Stats host availability, response codes, and response time;
rich-result, video, Shopping, HTTPS, and CWV changes;
Performance by page group, query group, country, device, and search type;
business metrics from analytics/CRM/commerce.

For URL-changing moves, expect temporary ranking fluctuation while Google crawls and processes old and new URLs. A medium-sized site can take weeks; larger sites can take longer. Completion happens per URL and requires Googlebot to visit old and new URLs.

Use Change of Address only for supported domain/subdomain moves where applicable, after redirects and verification are ready. It does not replace redirects, URL mapping, canonicals, or sitemaps.

Rollback and escalation criteria

Define thresholds before launch. Examples:

Signal	Likely action
Sitewide outage, widespread `5xx`, DNS failure	Immediate operational rollback/escalation
Production `noindex` or robots block on critical scope	Immediate fix or rollback
Broken/looping redirects across mapped high-value URLs	Immediate migration escalation
Canonicals point broadly to staging, old, or unrelated URLs	Immediate fix; consider rollback based on reach
Googlebot blocked by firewall/CDN	Immediate infrastructure escalation
Sitemap fetch fails but site is otherwise healthy	Fix promptly; not necessarily full rollback
Temporary crawl-rate or ranking fluctuation with clean technical checks	Observe against expected migration behavior
Performance decline with no confirmed mechanism	Investigate; do not rollback solely on correlation

Search Console Performance data alone is too delayed and causally ambiguous for an hour-one rollback decision.

Launch dashboard

Maintain one view with:

release milestones and owners;
synthetic/site health and server metrics;
old/new URL validation sample;
Googlebot requests and response codes from verified logs;
sitemap and indexation progress;
canonical and enhancement samples;
finalized Search Console Performance plus preliminary data clearly labeled;
analytics and business outcomes;
open incidents, decisions, and next check.

Keep each source's metric definition intact. Search Console clicks do not equal analytics sessions, Crawl Stats requests do not equal unique URLs, and Page Indexing examples do not form a complete URL list.

Closure criteria

Close heightened monitoring only when:

users and Googlebot consistently reach the intended infrastructure;
critical old URLs redirect correctly where applicable;
new intended canonicals are being crawled and indexed without an unexplained systemic block;
error and host-health rates are stable;
Performance has reached an explainable trajectory across complete periods;
old infrastructure can be retired safely;
temporary properties, credentials, and staging access are cleaned up;
the final mapping, baseline, incidents, and lessons are archived.