Search Console launch verification checklist after a redesign

Search Console verification is the post-launch routine that confirms search engines can discover, crawl, render, index, and measure the new website correctly. It is especially important after a redesign, Shopify migration, WordPress rebuild, headless launch, domain change, or multilingual rollout.

This checklist is for teams that already shipped the site and now need practical evidence, not a vague feeling that SEO is fine. Use it during the first 24 hours, first 7 days, and first 30 days after launch.

Bad Search Console setup makes every later report confusing. Before checking coverage or clicks, confirm that the right domain property or URL-prefix properties exist, the production hostname is verified, and the people responsible for SEO, development, and maintenance have access.

This matters most when a launch changes protocol, domain, subdomain, locale folder, or CMS routing. If data is split across old and new properties, the team may miss real errors or overreact to expected migration movement.

• Verify the domain property when possible, plus URL-prefix properties for critical subdomains or language folders when the team needs granular views.
• Confirm production uses the preferred protocol, host, trailing slash behavior, and canonical domain.
• Check that staging, preview, and temporary domains are not verified as the main reporting source.
• Add the right owners and restricted users before launch week gets busy.
• Record the launch date, old domain or URL pattern, sitemap URLs, and migration notes in the project handoff.

Sitemap submission is not the whole SEO launch, but it gives you an early signal. Submit the production XML sitemap and confirm that it only contains canonical, indexable, public URLs. Then inspect a short list of priority URLs manually.

Your priority list should include the homepage, core service pages, high-value collections or products, important blog posts, localized pages, and any migrated URL type that changed during the launch.

• Submit the new XML sitemap and record the submission time.
• Check whether submitted URL counts roughly match the launch plan.
• Use URL inspection for 10 to 30 priority URLs instead of waiting for aggregate reports.
• Confirm each inspected page is crawlable, indexable, rendered, and using the expected canonical URL.
• Save examples of passed and failed URL inspections so developers can reproduce problems.

The first reports can look messy. Some old URLs should disappear, some new URLs need time to be discovered, and some excluded URLs are intentional. The work is to separate expected migration behavior from problems that block valuable pages.

Create three buckets: expected, needs investigation, and urgent. A noindexed staging URL may be expected. A core service page marked duplicate without user-selected canonical is not. A spike in not found URLs may be acceptable if every important old URL has a 301 redirect.

• Review indexing status for submitted URLs, indexed URLs, crawled currently not indexed, discovered currently not indexed, duplicate pages, and not found pages.
• Check redirect behavior for old URLs, campaign URLs, trailing slash variants, localized URLs, and removed pages with backlinks.
• Confirm robots.txt and noindex rules are intentional for staging, internal search, filtered pages, and utility routes.
• Compare Search Console examples against your redirect map and sitemap source of truth.
• Escalate immediately when priority pages are blocked, canonicalized incorrectly, returning soft 404s, or missing from the sitemap.

Search Console performance data is delayed, so do not judge a redesign by one day of clicks. Look for directional signals across pages, countries, devices, and queries. The goal is to catch obvious mismatches early while giving the migration enough time to settle.

For multilingual and international sites, segment by country and page path. A launch can look stable overall while one locale loses impressions because hreflang, canonical, sitemap, or internal links are wrong.

• Compare branded queries, non-branded service queries, product queries, and blog queries separately.
• Review page-level performance for the homepage, service pages, collections, products, resources, and localized pages.
• Check country and device filters for unexpected drops that aggregate charts hide.
• Annotate launch day, sitemap submission, redirect fixes, and major content changes in the reporting notes.
• Avoid rewriting titles or URLs during the first few days unless the data points to a specific issue.

Search Console is not a real-time performance tool, but its Core Web Vitals and enhancement reports show whether Google is seeing systemic template problems. After launch, review these reports alongside lab tests and real user monitoring.

Pay attention to template-level patterns. If every product page, collection page, or blog post has the same issue, the fix probably belongs in the theme, component system, image pipeline, or script strategy rather than one page.

• Review mobile and desktop Core Web Vitals separately, especially LCP, INP, and CLS.
• Check enhancement reports for structured data, breadcrumbs, products, videos, FAQ, merchant listings, or other features the site uses.
• Compare Search Console examples with PageSpeed, browser traces, and production monitoring before assigning blame.
• Group issues by template so fixes scale across the site.
• Revalidate fixed issues only after the deployed change is live and tested.