Website URL Migration QA Matrix: Redirects, Canonicals, Links, and Sitemaps

A URL migration succeeds when every important old address has an intentional, tested outcome and every public signal points to the preferred new address. A homepage redirect alone does not protect deep links, indexed pages, bookmarks, campaign URLs, external references, or customer paths.

Use this matrix for a domain change, HTTPS change, subdomain move, platform migration, directory restructure, or large slug revision. Build it before launch, test it in a controlled environment, and keep it active during post-launch monitoring.

What matters most

Create one row for every discovered source URL and preserve where it came from. Useful inputs include:

• current XML sitemaps and CMS exports;
• internal crawls, rendered routes, and server access logs;
• analytics landing pages and conversion paths;
• Search Console pages, indexing reports, and submitted sitemaps;
• backlink and referral reports;
• paid, email, social, QR, print, and partner campaign destinations;
• canonical, hreflang, Open Graph, structured-data, and feed URLs;
• manually maintained downloads, PDFs, image URLs, and application endpoints.

Normalize the inventory carefully without discarding meaningful differences in case, trailing slash, extension, parameters, hostname, or protocol. Those variants may behave differently on the real server.

Assign an explicit outcome

Each source should end in one of these documented states:

• permanent redirect to the closest equivalent destination;
• retained at the same preferred URL;
• intentionally removed with an appropriate non-success response;
• consolidated into a relevant parent or successor resource;
• temporarily redirected for a truly temporary condition;
• excluded from public handling because it is not a real or authorized route.

Avoid sending unrelated removed pages to the homepage. A redirect should preserve user intent, not merely avoid a 404 status.

How to build and test the migration matrix

1. Define the source-to-destination contract

Field	Required record
Source URL	Exact old URL, including meaningful hostname, path, extension, and parameters
Discovery source	Sitemap, log, analytics, crawl, backlink, campaign, manual inventory
Importance	Traffic, conversions, backlinks, revenue, customer support, or legal need
Intended outcome	Retain, permanent redirect, temporary redirect, remove, consolidate, investigate
Destination URL	Final absolute preferred address, not an intermediate hop
Content relationship	Equivalent, successor, broader category, no replacement, or exception
Owner and approval	Content, SEO, engineering, legal, campaign, or business approver
Test evidence	Observed chain, final status, final URL, timestamp, tool, and result

Freeze the approved mapping for launch. If the new site still lacks a destination, mark the row open rather than inventing an unrelated redirect during deployment.

2. Test HTTP behavior

For every critical row and an automated sample of the full inventory, record:

• initial status code and Location value where present;
• every intermediate hop;
• final URL and final status code;
• protocol and hostname normalization;
• query-string behavior where parameters matter;
• response to uppercase, trailing-slash, extension, and legacy-host variants;
• loop, chain, soft-404, and redirect-to-error detection;
• mobile and authenticated behavior if routes differ by state.

Google recommends permanent server-side redirects such as HTTP 301 or 308 when a URL has permanently changed. RFC 9110 defines 301 as “Moved Permanently” and 308 as “Permanent Redirect”; 308 differs by not permitting the request method to change during automatic redirection. Select status codes according to the application behavior, not by label alone.

Keep permanent redirects in place long enough for users and systems to adopt the new locations. Do not remove them immediately after a crawler first discovers the migration.

3. Align the destination signals

On the new site, verify that each indexable page’s signals agree:

• the public URL returns a successful status without a redirect chain;
• the canonical link points to the preferred final URL;
• internal links use the preferred final URL directly;
• XML sitemaps contain preferred URLs and correct modification data where supplied;
• hreflang annotations, when used, reference valid reciprocal preferred URLs;
• structured data, Open Graph fields, feeds, and share links use the intended hostname and path;
• robots directives and robots.txt do not block required crawling;
• old hostnames, staging hosts, and obsolete paths do not remain in templates or content.

A redirect fixes an incoming request, but leaving old URLs in navigation and content forces repeated hops and sends conflicting maintenance signals.

4. Validate complete customer journeys

Test more than informational pages. Start from old bookmarks, search results, campaign links, QR codes, referral URLs, and saved form links. Follow the journey through navigation, form submission, booking, checkout, phone or email action, confirmation, and analytics event.

Use safe test data. Record both the browser-visible outcome and the server or integration evidence. A destination page that loads but loses campaign parameters, breaks a form, or records the wrong conversion is not a complete migration success.

5. Run prelaunch and post-launch crawls

Before launch, crawl the staged new site and test the redirect rules against a non-production host or local ruleset where possible. At launch, capture a baseline crawl and compare it with the approved matrix.

After launch, monitor:

• requests to unmapped old URLs;
• unexpected 3xx chains, 4xx responses, and 5xx responses;
• traffic and conversions by old and new landing page;
• submitted and discovered sitemaps;
• indexing and canonical-selection reports;
• DNS, TLS, crawl availability, and hosting errors;
• important referrals that still use obsolete URLs.

Separate observed facts from interpretation. A ranking or traffic change may follow a migration, but the matrix alone cannot prove its cause.

6. Maintain an exception register

Exception	Evidence	Decision	Owner	Verification
No equivalent destination	Source content and business value reviewed	Remove, recreate, or consolidate	Named approver	Final status and content check
Parameterized URL	Parameter purpose and traffic documented	Preserve, strip, translate, or retire	Engineering/marketing	Request and analytics test
Redirect chain	Full chain captured	Point source directly to final target	Engineering	Header retest
Conflicting canonical	Page source and final URL captured	Update template or page data	Development/SEO	Rendered-source retest
Third-party link	Vendor or partner ownership confirmed	Update request or retained redirect	Business owner	External click test

Do not hide exceptions in crawl totals. An accountable register preserves the business decision and prevents the same question from being rediscovered after launch.

What this matrix cannot prove

Correct technical signals cannot guarantee unchanged rankings, traffic, conversions, or crawler timing. Search engines make independent crawling, indexing, canonicalization, and ranking decisions.

The matrix also cannot establish content equivalence without human review, discover every historical URL, or validate third-party systems that were excluded from scope. Access logs, analytics, crawl sources, and search reports each have coverage limits.

HTTP behavior can affect security, caching, method handling, APIs, and authentication. Application owners should review those risks before applying broad redirect rules.

Put the migration matrix into practice

Assign one owner to the URL inventory and require content, engineering, analytics, and business stakeholders to resolve exceptions before launch. Test critical revenue and lead paths manually, then automate the full redirect and destination checks so they can be rerun after deployment changes.

Keep the approved matrix, rule version, crawl exports, sitemap copies, launch timestamp, test environment, analytics annotations, and issue register together. Compare results at launch, after the first crawl cycles, and after any redirect or platform change.

Mendola.Tech can build the source inventory, design and test redirect rules, validate canonical and sitemap signals, and monitor post-launch customer paths for small-business website migrations.

Official references

• Redirects and Google Search — Google Search Central; accessed 2026-09-01. Describes server-side, meta-refresh, and JavaScript redirects and recommends permanent server-side redirects for permanent moves.
• Site moves with URL changes — Google Search Central; accessed 2026-09-01. Provides migration planning, URL mapping, testing, redirect, canonical, sitemap, and monitoring guidance.
• HTTP Semantics, RFC 9110 — RFC Editor; accessed 2026-09-01. Defines HTTP status-code semantics including 301 and 308 redirection behavior.