Google Search Console should be prepared before a redesigned website launches, not added after traffic changes become difficult to explain. The business needs durable property ownership, a preserved pre-launch record, a validated production release, a clean sitemap, and a small set of representative URLs that can be inspected and followed through Google's reports.

Search Console does not deploy redirects, repair canonicals, make a page useful, or guarantee crawling, indexing, rankings, or enquiries. It reports what Google knows under the scope and timing of its tools. The public website, URL map, server responses, internal links, and content remain the source of truth for the migration.

This guide owns the Search Console handoff and monitoring record for a redesign. The SEO redesign and migration checklist owns the full migration, the canonical URL guide owns individual URL treatments, and the post-launch measurement guide owns the broader path from search visibility to qualified business outcomes.

Classify the redesign before changing Search Console

Write down what the redesign changes. The correct Search Console work depends on whether the public identity of the site changes.

| Redesign class | Examples | Search Console implication | | --- | --- | --- | | Same URLs and same canonical host | New visual system, templates, rendering, content, or navigation | Preserve the existing property and compare representative URLs before and after launch | | URL changes on the same host | New slugs, folders, consolidation, or page removals | Preserve the property, submit the final sitemap, and monitor old and new URL outcomes | | Protocol or hostname normalization | HTTP to HTTPS, www to apex, or apex to www | Verify relevant variants, validate redirects and canonicals, and monitor both source and destination scopes | | Domain or subdomain move | example.ca to example.com, or one domain-level host to another | Verify both sides and determine whether Google's Change of Address tool applies | | Hosting change without URL changes | New server, CDN, platform, or deployment model | Keep the property, then watch availability, crawl behaviour, rendering, and verification continuity |

Do not call every redesign a site move. Do not call a domain move a simple template change. Record the exact source host, destination host, URL-map revision, launch date, and release identifier so later Search Console evidence can be interpreted against the change that actually occurred.

Establish durable property coverage

Search Console has Domain properties and URL-prefix properties. A Domain property covers protocols and subdomains under the verified domain. A URL-prefix property covers only URLs beginning with the exact prefix. The useful setup depends on the business's host structure and access model.

Before launch, inventory:

  • every current production protocol and hostname;
  • the intended final canonical host;
  • any old domain or subdomain that will redirect;
  • existing Domain and URL-prefix properties;
  • ownership-verification methods;
  • verified and delegated owners;
  • full and restricted users; and
  • the business person responsible for recovery and offboarding.

Google requires ownership of both old and new properties for a Change of Address request. Even when that tool does not apply, visibility into source and destination properties can help separate an access problem from a migration problem.

Prefer a verification method the business can retain through provider and staff changes. Google periodically rechecks verification tokens. A verification file removed during deployment, an HTML tag omitted by a new template, or a DNS record deleted during a zone transfer can eventually break access.

Preserve ownership through the release

Treat Search Console verification as a production dependency. Add it to the migration inventory rather than assuming it will survive.

For each verification method, record:

| Field | Required answer | | --- | --- | | Property | Exact Domain or URL-prefix property | | Method | DNS, HTML file, HTML tag, Analytics, Tag Manager, or provider method | | Technical owner | Who controls the file, template, account, or DNS record | | Business owner | Who can restore access after a vendor change | | Launch dependency | What redesign action could remove or invalidate it | | Test | How verification will be confirmed before and after launch | | Offboarding | Which temporary users or methods should be removed later |

Google recommends using more than one verification method when appropriate because one method can fail after a site change. Do not overwrite another owner's verification token. Do not place Google account credentials, recovery codes, DNS-provider passwords, or unrelated environment values in a migration document.

User access should match the work. A person who only needs to review reports may not need ownership. Remove former vendors and staff after confirming that durable business-controlled ownership remains.

Export a pre-launch evidence baseline

Search Console is most useful during a redesign when the previous state has been preserved. Export evidence before launch while the old URLs and property configuration are still available.

Capture at minimum:

  • Performance report totals and tables for an agreed date range;
  • page-level performance for important landing pages;
  • query-level performance for branded, service, and informational themes where data exists;
  • device and country filters relevant to the business;
  • submitted sitemap addresses and their visible processing state;
  • Page indexing categories and representative examples;
  • URL Inspection records for priority pages;
  • manual-action and security-issue status;
  • current owners and users; and
  • any active temporary removals that could affect interpretation.

Record the property, search type, date range, filters, dimensions, export date, and file owner. Search Console reports can use different aggregation rules. Performance tables may omit anonymized queries and can be truncated, while chart totals may include information that does not appear as individual table rows. An export is evidence under those rules, not a complete server log or a complete list of every search.

Preserve the baseline outside a temporary vendor account. Give files stable names such as:

text 2026-08-01_prelaunch_example-ca_search-performance_pages.csv 2026-08-01_prelaunch_example-ca_search-performance_queries.csv 2026-08-01_prelaunch_example-ca_page-indexing-record.md

Do not put customer contact details, unrelated analytics identifiers, credentials, or private business data into a Search Console migration folder merely because the project also touches marketing systems.

Build a Search Console launch inventory

Do not inspect a random collection of pages. Select URLs that represent the migration's real risks.

Include:

  • the homepage;
  • one primary commercial page for each important template or intent class;
  • one retained URL whose content changed substantially;
  • one redirected high-priority old URL and its final destination;
  • one newly created canonical page;
  • one consolidated or removed URL;
  • one resource or article template;
  • one page with important structured data;
  • one page with a form, booking tool, or essential integration; and
  • the sitemap and robots file.

For each representative URL, store the old URL, intended new URL, expected status, redirect count, intended canonical, index state, sitemap state, internal-link source, page owner, and reason for selection.

This representative set is an original Nexxen acceptance framework. It is a bounded diagnostic sample, not a claim that inspecting a few pages proves every migration URL is correct. Automated crawls and production tests should validate the complete approved URL set where practical.

Validate production before asking Google to process it

Search Console should observe a correct release, not substitute for one. Before submitting a sitemap or requesting indexing, validate the public site outside Search Console.

For every indexable destination in the release set:

  • the preferred HTTPS URL returns 200;
  • alternate versions reach it through an approved direct redirect or other intentional treatment;
  • exactly one absolute canonical identifies the correct destination;
  • the robots directive permits the intended index state;
  • meaningful content is present in the delivered and rendered page;
  • internal links point directly to canonical URLs;
  • the page appears in the intended navigation or contextual link path;
  • structured data matches visible content;
  • forms and essential actions complete their real downstream path; and
  • the sitemap lists the canonical destination rather than redirect sources or error URLs.

For removed or merged pages, verify the approved redirect, 404, or 410 outcome. A redesign is not ready because its new homepage looks correct. The URL inventory must tell one consistent story.

Submit the final sitemap deliberately

A Search Console sitemap submission tells Google where the site declares important URLs. It does not force crawling or indexing and does not override redirects, canonicals, noindex, unavailable pages, or weak internal discovery.

Before submission, fetch the production sitemap and verify:

  • it returns 200 without authentication;
  • every <loc> is an absolute canonical URL on the intended host;
  • URLs use the final scheme, hostname, case, path, and trailing-slash convention;
  • each listed URL returns the intended successful response;
  • redirect sources, errors, utility pages, staging routes, and parameter variants are absent;
  • lastmod, when supplied, reflects a meaningful page update; and
  • the sitemap reference in robots.txt, when used, points to the same production inventory.

Submit the final sitemap under the matching property. Record the exact sitemap URL, property, submission date, visible status, and next review date.

Do not delete the old sitemap merely to make a report look cleaner. During a URL-changing move, an old sitemap can provide a record of source URLs while Google processes their outcomes. Follow the approved migration plan and Google's current site-move guidance. The final sitemap should remain the maintained inventory of canonical destinations.

Inspect representative URLs in two views

Search Console URL Inspection can show information about Google's indexed version of a URL and can run a live test against the current public version. Those views answer different questions.

Indexed view

Use the indexed view to record what Google last processed, including the indexing verdict, last crawl information where available, referring sitemap, user-declared canonical, Google-selected canonical, and reported enhancements.

Live test

Use the live test to check whether Google can currently retrieve and evaluate the public page. It is useful after a fix, but it does not test every indexing condition and does not prove that Google has replaced its indexed version.

For each inspected URL, record:

| Evidence | Indexed view | Live view | | --- | --- | --- | | Timestamp | When the evidence was reviewed and the reported crawl date | When the live test ran | | Availability | Google's stored result | Current retrieval result | | Canonical | Declared and selected canonical where reported | Current declaration, with live-test limits noted | | Index state | Whether the URL is indexed and why | Whether the tested page appears eligible under tested conditions | | Next action | Wait, investigate, or correct | Deploy a fix, retest, or request processing |

Do not report “indexed” because a live test passed. Do not report “broken” merely because the indexed view predates the deployment. Compare the evidence dates with the release timestamp.

Request indexing only for priority pages

URL Inspection can request indexing for an individual page. Use that capability for a small number of important new or substantially changed URLs after public acceptance passes.

Do not request indexing repeatedly for every URL in a redesigned site. A sitemap, crawlable internal links, redirects, and reliable server responses are the scalable discovery system. A request does not override a conflicting canonical, noindex, robots restriction, soft error, manual action, policy issue, or substantially duplicate content.

Record the URL, request date, reason, requester, public preflight, and next review date. Describe the action as “indexing requested,” not “submitted and indexed.”

Use Change of Address only for an eligible domain move

Google's Change of Address tool applies to certain moves from one domain or subdomain to another. It is not the correct tool for every redesign.

Google says not to use it for:

  • an HTTP-to-HTTPS change;
  • moving only some pages within a site; or
  • ordinary path changes on the same host.

Before using the tool:

  1. Complete and test the domain move.
  2. Implement approved permanent redirects from old canonical URLs to their corresponding new URLs.
  3. Verify ownership of the required old and new properties with the same Google account used for the request.
  4. Confirm that the source and destination meet the tool's property requirements.
  5. Validate all relevant old host variants and subdomains separately.
  6. Submit from the correct old property only after critical prechecks pass.
  7. Record who submitted it, when, from which property, to which property, and what the tool reported.

The Change of Address request complements the migration implementation. It does not create the redirect map, preserve missing content, or make an unrelated destination equivalent.

Keep the old domain and redirects operational

A domain move continues after the new site launches. Google recommends maintaining redirects for at least 180 days and retaining control of the old domain for at least a year. User and referral needs can justify keeping valid redirects longer.

Monitor:

  • old-domain registration and DNS authority;
  • TLS certificate health for old HTTPS URLs;
  • redirect status and destination accuracy;
  • redirect chains and loops;
  • requests reaching retired URLs;
  • old URLs still shown in Search Console reports; and
  • new URLs selected as canonical destinations.

Do not remove the old site, domain, DNS, or certificate simply because the Change of Address notice appeared. Google processes moves per URL and needs to fetch source and destination addresses.

Triage Page indexing by intended URL outcome

The Page indexing report groups URLs by Google's observed state. “Not indexed” is not automatically a defect. Redirect sources, deliberate duplicates, removed pages, and noindex utilities can be correct non-indexed outcomes.

Review each category against the approved URL map:

| Reported or observed condition | Correct when | Investigate when | | --- | --- | --- | | Page with redirect | The source is intentionally retired and reaches its approved destination | The page should remain canonical, the redirect loops, or the destination is wrong | | Alternate page with canonical | The duplicate is intentionally available and equivalent | The page owns a distinct reader decision or points to an unrelated canonical | | Not found | The old resource has no suitable replacement | The URL should exist or has a mapped destination | | Excluded by noindex | The reachable page is intentionally private from search | A commercial or resource page should be indexable | | Crawled or discovered, not indexed | Processing or selection is unresolved | Important pages remain unresolved after technical and content checks | | Duplicate with different selected canonical | Google found a stronger equivalent | The selected URL conflicts with the intended owner |

Filter by the submitted sitemap when useful, then inspect representative examples. Search Console may list up to a bounded number of example URLs even when report totals are broader. Keep the complete migration crawl and URL map as separate evidence.

When a category changes after launch, ask whether Google processed the new state, whether the production implementation is correct, and whether the category is expected. Do not chase a zero in every non-indexed category.

Watch crawling and server health together

The Crawl Stats report can show request volume, response categories, file types, purposes, and host information for eligible properties. It reports actual URLs requested by Google, and redirects in a chain can appear as separate requests.

Use it to look for patterns after a redesign:

  • increased server errors or timeouts;
  • repeated requests to broken assets or retired paths;
  • unexpected hostnames;
  • excessive redirect chains;
  • reduced access to important page classes; or
  • capacity pressure during a large move.

Correlate Search Console with uptime monitoring, CDN or server logs where lawfully retained, deployment records, and the URL map. Search Console is not a real-time infrastructure monitor. A stable crawl chart does not prove forms work, and an availability monitor does not prove Google selected the intended canonical.

Read Performance changes conservatively

After a redesign, compare equivalent periods and annotate the release date in the operating record. Segment by page, query theme, device, country, and search type where the data supports a useful decision.

Remember:

  • most Performance data is assigned to canonical URLs;
  • table data and chart totals can differ because of aggregation;
  • anonymized queries are omitted from query tables;
  • tables can be truncated;
  • recent data can be incomplete; and
  • external events, seasonality, competition, and demand can change alongside the website.

For URL-changing migrations, compare old and new page groups using the approved mapping. A source URL losing reported clicks while its equivalent destination gains them can be consistent with migration processing, but it does not prove causation by itself. Investigate missing destinations, unexpected canonicals, indexing exclusions, server errors, and query-intent changes before rewriting pages.

The post-launch measurement guide explains how Search Console evidence fits alongside website analytics, call systems, forms, CRM delivery, lead qualification, and business outcomes.

Use removals as an emergency control, not a migration tool

Search Console's Removals tool can temporarily hide qualifying URLs from Google Search. It does not delete content from the website, create a permanent search removal, or replace correct status codes and index controls.

Do not submit the old redesign inventory for removal merely because URLs moved. Permanent redirects, correct canonical destinations, updated links, and sitemaps communicate the move. For content that must be permanently unavailable, remove or restrict it at the source and use the appropriate public response or access control.

Before a domain move, check for active removals left by a previous owner or administrator. During a redesign, record any new removal request with its exact scope, reason, requester, approval, start date, expiry implications, and permanent remediation.

Use a staged review cadence

A redesign monitoring plan needs named review points, not constant refreshing.

Launch day

  • confirm property access and verification;
  • save the release identifier and launch time;
  • validate the public URL set, sitemap, and robots file;
  • submit the final sitemap;
  • inspect the representative URL set;
  • request indexing only for approved priority pages;
  • submit an eligible Change of Address request when required; and
  • assign every failed check.

Early stabilization

  • compare live and indexed inspection dates;
  • review sitemap processing and Page indexing changes;
  • test redirect samples and important destinations again;
  • review server and crawl errors;
  • confirm that forms, calls, booking, and analytics still work; and
  • correct implementation defects before repeating submission actions.

Ongoing migration review

  • monitor old and new URL groups;
  • review unexpected indexing categories;
  • compare relevant Performance segments cautiously;
  • check old-domain and redirect health;
  • preserve verification and user access;
  • document fixes and processing dates; and
  • reduce review frequency only when the migration evidence is stable.

This cadence is a project-control framework, not a promise about how quickly Google will crawl or index a particular site.

Create a redesign launch register

Use one record to connect the migration implementation to Search Console evidence.

| Field | Required record | | --- | --- | | Release | Launch timestamp, commit or deployment identifier, and owner | | Change class | Same URL, path changes, host normalization, domain move, or hosting-only move | | Properties | Old and new properties, types, and verified owners | | Baseline | Export locations, filters, date ranges, and export timestamps | | URL map | Approved revision and responsible owner | | Public acceptance | Status, redirects, canonicals, robots, content, links, schema, and actions | | Sitemap | Exact URL, property, submission time, and observed state | | Representative URLs | Selection reason and old/new expected outcomes | | Inspection | Indexed evidence, live evidence, dates, and next action | | Change of Address | Applicable or not, submission evidence, and reason | | Indexing triage | Expected categories, exceptions, and assigned fixes | | Crawl health | Server patterns, affected hosts, and corroborating evidence | | Performance | Property, view, filters, comparisons, and limitations | | Access | Business owner, technical owner, users, and offboarding date | | Outcome | Deployed, verified, submitted, crawled, indexed, shown, visited, and converted kept separate |

This Nexxen register is an original operational framework. It does not represent an unverified client migration or promise a search result. Its purpose is to stop “Search Console is set up” from hiding missing ownership, missing baselines, contradictory URL outcomes, or unresolved production failures.

Complete the handoff

The Search Console portion of a redesign is ready for handoff when:

  • the business retains verified ownership;
  • approved users have the minimum access they need;
  • temporary access has a removal date;
  • pre-launch exports are stored in a durable business location;
  • the final sitemap is submitted under the correct property;
  • representative URLs have dated inspection records;
  • the URL map and public acceptance evidence are available;
  • an eligible Change of Address request is documented;
  • unexpected indexing and crawl issues have owners;
  • reports separate implementation, Google processing, visibility, and business outcomes; and
  • the next review date is assigned.

Search Console should make a redesign more explainable. It should show which property was observed, which URL Google processed, when the evidence was collected, and what action follows. It should never turn a submitted sitemap, passing live test, or indexing request into a claim the evidence does not support.

For Canadian businesses that need URL mapping, redirect implementation, crawlable rendering, production acceptance, and accountable search monitoring through a redesign, Nexxen's website redesign service is the commercial owner for this resource.