A site migration is the highest-variance thing an SEO programme ever does. Every other change is incremental; a migration replaces the addresses, the markup, or the platform at once, on a date somebody else picked. This calculator turns the five variables that drive migration outcomes — URL churn, redirect coverage, template change, platform change, and timing — into a single risk score with the specific gaps listed underneath it.
Arb Digital built this because the useful conversation before a migration is never "is this risky". It is always "which part of this is risky, and what would it cost to de-risk that part". A score of 62 tells you nothing on its own. A score of 62 that is driven almost entirely by a 20% redirect shortfall tells you exactly what to spend the next two weeks on. Nothing on this page is a Google-published metric — Google publishes no migration risk index and no factor weights — so every weight here is an input you can see and change.
What This Site Migration Risk Calculator Does
You describe the move across five factors, each scored 0–100, and set how much each should count. The tool turns every factor into a risk contribution, produces a weighted score on a 0–100 scale, and assigns a band from low to severe. It also converts your percentages into absolute counts, so "80% redirect coverage" becomes "546 URLs with no one-to-one 301" — a number a project manager can schedule work against.
The bar breakdown ranks the five factors by how much risk each one is contributing under your weights, which is not the same as which factor scores worst. A perfect-looking platform change carrying 15% weight contributes less than a modest redirect gap carrying 30%, and the ordering makes that visible before anyone starts arguing from intuition.
How to Use It
- Count your indexable URLs. Take the number from a full crawl of the live site, cross-checked against indexed pages in Search Console. Do not use a sitemap count alone — sitemaps routinely omit pages that rank.
- Estimate the share of URLs changing address. A domain change or a move from HTTP to HTTPS makes this 100% by definition, even if every path stays identical.
- Be honest about redirect coverage. Count only mappings that have been written and tested, pointing to the closest equivalent page. A rule that sends a third of the old site to the homepage is not coverage.
- Score template and platform change. Use 0 when nothing changes and 100 when everything does. These are judgement calls; write down your reasoning so the score can be re-created later.
- Set the timing risk last, then adjust the weights to match your situation before reading the band.
The Formula / How It's Calculated
Four of the five factors are already expressed as risk: higher URL churn, bigger template change, bigger platform change and worse timing all increase risk. Redirect coverage runs the other way, so it is inverted before use.
Redirect risk = 100 − redirect coverage %
The overall score is then a weighted mean of the five risk values, divided by the total weight rather than by 100, so your weights do not have to sum to exactly 100.
Risk score = Σ(Riski × Weighti) ÷ Σ(Weighti)
Working the defaults: URL change 65 at weight 30, redirect risk 20 at weight 30, template 70 at weight 15, platform 100 at weight 15, timing 45 at weight 10. That gives (65×30 + 20×30 + 70×15 + 100×15 + 45×10) ÷ 100 = (1950 + 600 + 1050 + 1500 + 450) ÷ 100 = 55.5. The band lands on "high" — and the bar breakdown shows URL change contributing 19.5 points of that total, more than any other single factor, with the platform change second at 15.0.
The absolute counts come straight from the URL total: URLs changing = total × change % , and URLs with no 301 = URLs changing × (1 − coverage %). With 4,200 URLs, 65% changing and 80% coverage, that is 2,730 changing and 546 with no mapping. That second figure is the only output here that is not a model, and it is usually the one that reframes the meeting.
Why Redirect Coverage Deserves the Heaviest Weight
Of the five factors, redirect coverage is where failure is both most likely and most permanent. A template that turns out worse can be iterated on next sprint. A URL that returns 404 for six weeks has already lost whatever signals were attached to it, and recovery is slow even after the redirect is added.
Google's documentation on site moves with URL changes is unambiguous about the mechanism: old URLs need to redirect to the corresponding new URLs, and the closer that correspondence, the better the outcome. Its companion guidance on redirects and Google Search describes how permanent redirects communicate that a page has moved for good. Neither document promises a timeline or a percentage of retained performance, and neither should be read as one — but both make clear that a missing redirect is not a soft failure.
The trap is the phrase "we have a redirect rule". A pattern rule mapping /blog/<slug> to /articles/<slug> is genuine coverage. A catch-all sending every unmatched old URL to the homepage is not: it looks like full coverage in a spreadsheet and behaves like a 404, because the destination has nothing to do with what the visitor asked for. Count only mappings where the destination is a real equivalent.
The Redirect Chain Nobody Budgets For
Sites that have migrated before carry redirects from the last move, and the new move stacks on top. An old URL that already redirects to a 2021 address now redirects again to a 2026 address, and if a third move happens the chain grows again. Every hop adds latency for the visitor and gives the crawler more work to do for the same destination.
The fix is cheap if you do it during the migration and expensive if you do it afterwards: flatten the chains at the source. Take the full list of historical redirects, resolve each one to its final destination, and rewrite the original rule to point straight there. Doing this at migration time is a find-and-replace on a mapping file. Doing it in a year, after the new rules have been edited by four different people, is an archaeology project. The HTTP status code lookup is useful while testing, and the htaccess redirect generator will build the rules once you have a clean mapping.
Where Crawl Budget and Page Experience Fit
Two adjacent tools on this site answer questions that sit either side of this one, and the boundaries are worth stating.
The crawl budget calculator answers how long will it take Google to see all of this. That question only becomes material on large sites, and it becomes material precisely at migration time, because a move creates a burst of newly-changed URLs plus a set of redirecting old URLs that also have to be recrawled. On a 4,200-URL site the recrawl is rarely the constraint. On a 400,000-URL catalogue it can be the difference between a two-week dip and a two-quarter one. Run that calculator when your URL total is large enough that the answer is measured in weeks.
The Core Web Vitals score calculator answers did the new templates get faster or slower. This calculator treats template change as a risk input only — it has no opinion about whether the new template is good. Score the old templates before launch and the new ones after, on the same page types, because a redesign that improves the visual design and regresses layout stability is one of the most common and least noticed migration outcomes. It is also one of the few migration effects you can measure objectively within days rather than guessing at for a quarter.
What Changing Everything At Once Costs You
The score treats template change and platform change as separate factors because they can be separated in practice, and separating them is the single most effective de-risking move available. When URLs, templates and platform all change on the same night, any performance change afterwards is uninterpretable. You cannot tell whether traffic fell because a redirect was missed, because the new template dropped internal links, or because the platform started rendering content in a way that changed how pages are processed.
Splitting the move into phases — platform first on identical URLs and templates, then URL structure, then design — makes each phase individually diagnosable. It costs more engineering time and is almost always worth it where organic search is a material revenue channel. When the business will not accept phasing, record a full baseline before launch: crawl the old site completely, export Search Console performance by page, and store the rankings you care about.
Be explicit about what the score does not include. It has no view on content changes, information architecture, hreflang, or the quality of the QA process. A migration can score 30 and still go badly because nobody tested rendering, and score 70 and go fine because the team was disciplined. The score sizes the exposure; execution decides the outcome.
Reading the Band Without Overreacting
The bands here describe exposure, not expected loss. A high band on a 60-page brochure site with a careful team is a very different situation from a high band on a 400,000-URL marketplace with a fixed launch date, even though the number is identical. Percentages hide scale, which is exactly why the calculator surfaces absolute URL counts alongside them.
Use the score comparatively rather than absolutely. Score the migration as currently planned, then re-score it with the redirect coverage raised to 95% and the template change deferred to a later release. The difference between those two numbers is the value of the de-risking work, expressed in a form that a delivery manager can weigh against the sprint capacity it would take. That comparison is the real output of this tool, and it does not depend on the absolute score being right.
Finally, re-score after launch with what actually shipped. Coverage that was 95% in the plan is often 78% in production, and comparing planned risk to shipped risk is the cheapest post-mortem an SEO team can run.
Arb Digital's SEO team builds and tests the redirect map, baselines the old site before launch, monitors indexation daily through the transition, and reports what moved and why.
SEO Services Talk to Arb DigitalCommon Mistakes to Avoid
- Counting a homepage catch-all as redirect coverage. A redirect to an unrelated destination is a missing redirect wearing a 301 status code.
- Crawling only the new site. The old site's full URL list is the source of truth for what needs mapping, and it disappears the moment you launch.
- Launching on a Friday or in peak season, when the people who can fix a rendering bug are least available and the cost per hour of downtime is highest.
- Forgetting non-HTML URLs — PDFs, images and feeds accumulate links and traffic, and they are the first thing left out of a redirect map.
- Removing the old redirects too early. They are cheap to keep and expensive to reinstate once the mapping data has been deleted.
Related Free Tools From Arb Digital
Before launch, rebuild your submission files with the XML sitemap generator so the new URLs are discoverable on day one, and re-baseline overall site health with the SEO audit score calculator so you have a before-and-after on more than traffic alone. If you need to model the recovery curve for a forecast, the SEO traffic forecast calculator is the right place. Browse the full free online tools hub for more.
Frequently Asked Questions
No. Google documents how to carry out a site move and how redirects are interpreted, but it publishes no risk index and no factor weights. The score here is Arb Digital's model, which is why every weight is an editable field rather than a fixed constant hidden inside the tool.
Any change to the address a page is served from: a different path, a different domain or subdomain, a switch from HTTP to HTTPS, or a change in trailing slash or case handling. A redesign that leaves every address untouched is not a URL change, and it carries a very different risk profile.
Keep them indefinitely if you can. Redirect rules cost almost nothing to maintain, external links to old addresses persist for years, and reinstating a map after the source data has been deleted is far more expensive than never removing it. Flatten chains rather than deleting hops.
If you can avoid it, no. Changing one variable at a time makes any performance change diagnosable. When both change together and traffic falls, you cannot tell whether the cause was a missed redirect or a template that dropped internal links, and you will spend weeks arguing about it rather than fixing it.
It is rarely a good outcome. A redirect whose destination does not correspond to what the old URL offered gives the visitor nothing useful, and Google's own guidance stresses redirecting to the closest equivalent page. Where no equivalent exists, a deliberate 404 or 410 is usually a more honest signal than a homepage redirect.
Early enough to be tested on a staging environment before the launch date, which in practice means it is a deliverable of the build rather than a task for launch week. Maps written under deadline pressure are where catch-all rules get introduced, and catch-alls are the single most common cause of migration losses.
Because percentages hide scale. Twenty per cent of unmapped URLs sounds like a rounding issue until it is expressed as 546 pages, each of which needs a destination chosen by a person. The count is the only figure on this page that is a fact rather than a model, and it is usually the one that changes the plan.
Risk scores and weights here are an Arb Digital planning model, not metrics published or endorsed by any search engine, and they do not predict traffic loss or recovery time.
