A better-looking website can become an expensive investment if old URLs, internal links, and indexing are handled incorrectly. These requirements will help you protect organic traffic before, during, and after launch.
A redirect list based solely on the old XML sitemap may miss the URLs that generate the most business value, such as discontinued product pages that still receive organic clicks, convert visitors, or have strong backlinks. This makes an SEO migration more than a technical change of design or CMS: changed addresses, incorrect redirects, and content rendered only through JavaScript can wipe out valuable rankings overnight. In 2026, this loss is particularly costly when lost leads must be replaced with paid advertising while search engines are still trying to understand the new website. This article helps SME owners and marketing managers demand the right documentation, checks, and acceptance criteria from their web agency before, during, and after launch.
An SEO migration starts with a verifiable baseline
Before development begins, the agency must provide a consolidated URL inventory using sources such as Screaming Frog, Google Search Console, GA4, XML sitemaps, backlink data from Ahrefs or Semrush, and server logs where available. The inventory must also capture orphan pages that are missing from the navigation, older campaign URLs, parameter URLs, and discontinued products that still have clicks, impressions, conversions, or backlinks. For every business-critical URL, the documentation should show the page title, H1, canonical, index status, HTTP status, organic traffic, most important search queries, average position, backlinks, and completed conversions.
Request at least twelve full months of historical data for each organic landing page, as comparing performance only with the previous month can easily confuse migration issues with holidays, peak seasons, campaigns, or changes in brand demand. The baseline report must be dated, version-controlled, and locked before the first changes are made so that, after launch, both the client and the agency can measure deviations by URL and page type instead of debating a single total traffic figure.
Every old URL needs a defined destination—not just the homepage
Require a complete redirect matrix in which every known indexed URL, URL with traffic, or externally linked URL has a new destination, a planned status code, a justification, and a test result. If a page about industrial cleaning in Gothenburg is removed, for example, it should redirect to the equivalent service in the same location or to the closest relevant geographic page, because redirecting it to the homepage loses both search intent and conversion context. A permanent server-side 301 redirect, or a correctly implemented 308, must point directly to the final destination in a single hop without passing through HTTP, another www variant, an old directory, or an intermediate address.
The agency must test the matrix automatically in staging or a separate redirect environment and report both the actual status code and the Location header, including how domain, protocol, and trailing-slash variants are handled without loops or chains. URLs without a relevant replacement must receive a deliberate decision—retain the content, create a relevant category page, or return a 404 or 410—because broad redirects to the homepage may be treated as soft 404s and can also send potential customers to a page that does not address their needs.
Stop the launch if indexing, canonicals, or internal links point to the wrong place
The SEO review must examine actual HTTP responses, the HTML source, and the rendered page because a correct value in the CMS interface does not prove what Googlebot actually receives. The signed launch protocol should therefore serve as a pre-launch SEO checklist covering robots.txt, meta robots directives, X-Robots-Tag, canonical tags, hreflang, the XML sitemap, internal links, status codes, and structured data. Deployment to production must be stopped if priority pages are blocked in robots.txt, retain the staging environment's noindex directive, or use canonicals pointing to the test domain, even if the website looks correct in the browser.
In WordPress, errors can be introduced by templates or SEO plugins that generate canonicals and sitemaps, while a React-based solution must also be reviewed after rendering to ensure that important text and standard href links are available without scrolling, clicking, or other user interaction. Acceptance must require internal links, canonical tags, hreflang references, and the XML sitemap to point directly to indexable URLs returning a 200 status, not to addresses that redirect, return a 404, or display essential content only after a JavaScript request that search engines may struggle to discover.
Define measurable acceptance criteria and an action plan for the first few weeks
The contract should distinguish between technical acceptance on launch day and traffic outcomes that must be monitored over time because search engine crawling, indexing, and reassessment do not happen simultaneously for every URL. Technical acceptance criteria can include tested destinations for 100 percent of priority old URLs, zero critical noindex or canonical errors, zero internal links to 4xx responses, and no redirect chains among migrated addresses. Anyone seeking to redesign a website without losing rankings must also monitor organic landing pages, search queries, and conversions separately for branded and non-branded traffic, because increased clicks to the homepage could otherwise conceal a significant decline on a profitable service page.
Schedule checkpoints on day 0, day 1, day 3, day 7, and day 28 using Google Search Console, GA4, and server logs to show whether Googlebot reaches the new URLs, follows the redirects, and encounters unexpected 404 responses. A named incident manager, an agreed SLA, and daily checks during the first week reduce the time between discovery and resolution. If a priority page generates hundreds of leads per month, a delay of just a few days could otherwise result in lost sales and an immediate need for additional advertising budget.
The criteria that determine whether the migration is ready
Assess the migration plan based on verifiable documentation, clear stop criteria, and named responsibility for follow-up. If any of the following is missing, the launch should be postponed until the risk has been documented and addressed.
Require a documented SEO baseline
Before URLs, content, or structure are changed, the current state must be documented with organic traffic, search queries, average positions, indexed pages, conversions, and priority landing pages. The data must be available by URL or page type and include enough history to distinguish a migration-related loss from normal seasonal variation. Without that level of detail, it is impossible to demonstrate objectively whether a revenue-generating page has recovered.
Signal: A good provider presents a dated, version-controlled baseline report with named data sources, a prioritisation model, and metrics by URL—not just a screenshot of the website's total number of sessions.
Verify a defined destination for every old URL
Every existing URL must be mapped to the most relevant new page, retained unchanged, or deliberately removed with the correct status code. The mapping must also include addresses missing from the XML sitemap that still have backlinks, search traffic, or conversions. Broad redirects to the homepage reduce relevance and make it more difficult to preserve both visibility and the user's path to purchase.
Signal: Check that the redirect matrix has one row for each old URL, including the destination, status code, justification, owner, and an automatically verified test result from the environment where the rules will actually run.
Set technical stop criteria before launch
The website must not be published if important pages are blocked from indexing, canonical tags point to the wrong domain, or internal links lead to old, redirected, or broken URLs. The review must cover mobile rendering and actual server responses, particularly in solutions where React or other JavaScript technologies build links and content in the browser. A successful test in the CMS is not enough if the delivered HTML says something different.
Signal: Consider it a warning sign if the provider lacks a completed pre-launch crawl, a comparison between the source code and rendered HTML, and formal approval of indexing, canonicals, status codes, and internal links.
Define measurable acceptance criteria
Approval must be based on predefined thresholds, such as zero critical indexing errors, complete redirect mapping coverage, and no broken internal links on priority pages. Any accepted deviations must also be documented with their scope, business risk, owner, and final resolution date. This makes the decision to launch or postpone a verifiable quality assessment rather than a negotiation under time pressure.
Signal: A good project plan specifies exactly which tests must pass, which minor deviations may be accepted, what evidence must be provided, and who has the authority to stop the launch.
Secure a time-bound post-launch action plan
The first few weeks must include frequent monitoring of traffic, search queries, conversions, indexing, crawl errors, redirects, and priority URLs. The plan must also specify response times and an escalation path when a decline exceeds agreed thresholds, taking the day of the week and normal seasonality into account. An indexing error on a core service page must not enter the same queue as a minor editorial adjustment.
Signal: Check that the follow-up plan includes fixed checkpoints within the first 24 hours, daily checks during the first week, and continued monitoring for at least four weeks, and that the responsible person can initiate technical corrections without a new purchasing process.
Prioritised action plan for an SEO-safe website migration
-
Require a complete URL and redirect plan before launch
Export existing URLs and their traffic data using Screaming Frog, Google Search Console, and Google Analytics 4, and supplement the inventory with XML sitemaps, backlinks, and available server logs. The provider must map every important old URL to the closest equivalent new page and document when an address should instead be retained or return a 404 or 410. Approve the matrix only when every priority row has been tested with a permanent server-side redirect pointing directly to a working destination that returns a 200 status.
-
Document the current state and set measurable SEO requirements
Save at least twelve months of data on organic clicks, conversions, search queries, positions, and indexed pages from GA4 and Google Search Console, along with backlink data from Ahrefs or Semrush. Also document metadata, content, structured data, and Core Web Vitals for priority templates so that changes in metrics such as LCP, INP, and CLS can be linked to the new technical solution. Set separate targets for technical coverage and subsequent traffic performance because an agency can guarantee that tests have been completed, but not exact search engine rankings.
-
Test the new website technically in the staging environment
Crawl the staging website with Screaming Frog and check status codes, internal links, canonicals, metadata, heading structure, image alt text, hreflang, and structured data. Run both a standard crawl and a JavaScript-rendered crawl if the website is built with React or a headless CMS, and verify in WordPress projects that templates and SEO plugins generate the same intended signals. PageSpeed Insights and Rich Results Test should supplement the crawl, and the outcome must be a closed issue list in which blocking problems have been retested rather than simply marked as resolved.
-
Conduct a controlled launch with immediate quality assurance
Immediately after deployment, verify that robots.txt, the XML sitemap, canonical tags, and redirects work on the public domain. Check a representative sample of priority URLs with Google Search Console's URL Inspection tool, submit the new sitemap, and run a complete production crawl to identify 404 errors, chains, loops, and pages that cannot be indexed. Compare the results with the signed protocol before the launch window closes so that critical issues can be corrected while developers and operations staff are still available.
-
Monitor and correct SEO deviations for at least eight weeks
Create a weekly report in Looker Studio using data from GA4 and Google Search Console covering organic clicks, conversions, search queries, indexing, and performance by priority landing page. Supplement this with server logs or equivalent evidence of Googlebot requests, as well as reports on 404 traffic, redirect hits, and the performance of new URLs. The web provider must investigate clear declines according to an agreed SLA, report the likely cause, and verify every correction, while performance is measured against the baseline rather than only against the previous week.
Include all activities, metrics, data sources, response times, and acceptance criteria in the contract with the web provider before the project begins. An experienced team or independent partner approaches the work as a measurable change-control process in which every URL, risk, and deviation has an owner, rather than as a check added the day before publication. An SEO migration should not be approved as complete until the redirect plan has been verified, critical technical errors have been resolved, and organic performance across priority landing pages has stabilised.
