Pre-Migration Search Risk Assessment

What a migration puts at risk

A migration is any change that alters the address of a page: a new platform, a new domain, or restructured URLs on the same domain. Search engines and AI engines have spent years building a picture of the site at its current addresses. Change them without saying so, precisely and one by one, and that picture is discarded.

The losses are specific and each is preventable. Rankings attach to URLs, so a page at a new URL without a redirect starts from nothing. Backlinks point at old URLs, and a link to a 404 passes nothing. Indexed pages disappear overnight when a staging robots.txt or noindex tag is copied to production. Structured data and answer-first structure are lost when templates are rebuilt, and with them the AI citations they earned. Crawl budget is wasted on redirect chains and orphaned pages the new platform generates. Search Console history is severed when a domain changes without the change of address being registered. None of it is inevitable; all of it is common, because it is nobody's job on launch day.

What the assessment delivers

It starts with a baseline of record: a full crawl of the current site and an export of Search Console data, so that after launch there is something exact to compare against. From that comes an inventory of every URL that carries traffic, rankings, backlinks or AI citations, because those are the URLs that must survive.

The redirect map is the core deliverable: every URL in the inventory mapped one to one to its new home, in a file your developer can load rather than a spreadsheet to interpret. Where a page has no equivalent, the map says so and names the nearest relevant page, because a redirect to the home page is only marginally better than a 404. The risk register lists what the migration stands to lose, ranked by severity, with the action that prevents each item, written for the person running the project.

If a staging build exists, we review it the way a crawler will: canonicals, robots directives, the XML sitemap, structured data on each template, and raw against rendered HTML. Rendering matters more on a migration than anywhere else, because a move to a JavaScript-heavy platform can leave content invisible to bots that do not execute scripts. The technical SEO guide covers why each check exists.

What moves the price

The price is from $2,800 + GST. The number of URLs that need mapping is the biggest factor, and a crawl before quoting settles it. The kind of change is next: a URL restructure on the same platform is simpler than a platform move, and a domain change adds registration and history work. Whether a staging build exists to review is the third. Sites with multiple domains or hundreds of thousands of URLs are a different engagement, and we say so at the first conversation.

Launch day, after, and who does the migration

You receive two checklists. The launch-day list covers the first hours: redirects resolving in one hop, robots.txt and noindex correct on production, the sitemap submitted, the Search Console change of address registered if the domain moved, and structured data present on live templates. The post-launch list names the metrics to watch in the following weeks, indexed pages, crawl errors, rankings for the inventoried URLs and AI referral traffic, so a problem surfaces in the first week rather than the first quarter.

Whoever is building the new site runs the migration; the assessment is deliberately separate from the build so the plan is not written by the party with an interest in declaring launch a success. If you want us alongside your team, migration support is available as a project from $3,000 + GST for clients on a retainer, most often within the Growth retainer. Where the new site is a Launch Website Build of ours, the map and the checklists become part of the build and its test suite, and the broader technical SEO service picks up anything post-launch verification surfaces. Everything produced is yours and usable by any developer.