Publishing the new website is not the end of a migration. In many cases, it is the point when the most important checks begin.
A site can look perfectly normal to visitors while something underneath has gone wrong. Old URLs may be redirecting to the wrong pages. A staging noindex tag may have reached production. Analytics may have stopped recording purchases. Canonical tags may still reference the previous domain. A handful of these problems can quietly affect hundreds or thousands of pages.
That is why the first few days after a migration should be treated as a verification period rather than a celebration that the project is finished.
This post-migration checklist focuses specifically on what to inspect after the new site is live, including redirects, crawling, indexing, internal links, analytics, performance, structured data, conversions, and search visibility.
| When | What to check | What you are looking for |
|---|---|---|
| First hour | Site availability and HTTPS | Important pages load normally without certificate or server errors |
| First hour | Robots and noindex rules | Search engines are not accidentally blocked |
| First few hours | Redirects | Old URLs reach the correct new URLs |
| Launch day | Analytics and conversion tracking | Pageviews, events, leads and transactions are being recorded |
| Launch day | Canonical tags | New pages reference the correct live URLs |
| Launch day | XML sitemap | Sitemap contains the new canonical URLs |
| First 24 hours | Internal links | Navigation and contextual links go directly to new URLs |
| First 24–48 hours | Search Console | No unusual spike in crawl or indexing problems |
| First week | Organic traffic and landing pages | Important sections remain discoverable and traffic patterns make sense |
| First few weeks | Indexing | New URLs increasingly replace the old URLs in search |
| Ongoing | Performance and conversions | The new site has not introduced speed, UX or revenue problems |
The order matters. A broken redirect or accidental noindex is more urgent than a small change in page speed.
One of the easiest migration mistakes to make is also one of the most damaging: carrying staging restrictions into production.
Development environments are often protected with rules such as:
Disallow: /
or:
<meta name="robots" content="noindex">
Those controls make sense while a replacement site is being built. They do not belong on important production pages once the migration is complete.
Google specifically warns site owners to remove temporary noindex directives and robots.txt blocks after a site move.
Start by checking the homepage, several category or service pages, a few articles or product pages, and any important templates.
Do not only open them in a normal browser. A page loading for you does not necessarily mean a search crawler can access and index it.
Use Google Search Console's URL Inspection tool on representative pages and confirm that Google is allowed to crawl them.
Pay particular attention to template-level mistakes. If every product page uses the same template, one incorrect robots directive can affect the entire product catalogue.
If URLs changed during the migration, redirects deserve immediate attention.
A redirect should normally take an old URL to the closest equivalent new page.
For example:
example.com/services/web-design
might become:
example.com/web-design-services
The old page should lead directly to that replacement.
What you do not want is:
Old URL → temporary URL → category → final page
That creates unnecessary redirect hops.
You should also avoid sending hundreds of unrelated deleted URLs to the homepage simply because there is nowhere obvious to send them. Google warns that mass redirects to an irrelevant destination can be treated as soft 404s. If an old page has genuinely disappeared and there is no reasonable replacement, returning a real 404 or 410 can be more appropriate.
Test more than the homepage.
Check URLs that previously received organic traffic, pages with backlinks, top product or service pages, important editorial pages, campaign landing pages, image or media URLs where relevant, and a sample of lower-traffic pages.
For a large website, automated crawling is far more reliable than checking URLs manually.
Google recommends keeping permanent redirects in place for at least one year after a move so its systems have enough time to recrawl old URLs and transfer signals. From a user perspective, there can be value in maintaining useful redirects even longer.
A redirect is useful for visitors and crawlers arriving through an old URL. It should not become the normal way your new website navigates internally.
Suppose an article contains this link:
oldsite.com/pricing
and clicking it redirects to:
newsite.com/plans
The visitor eventually reaches the correct page, but the site is still relying on an unnecessary redirect.
Update navigation menus, footer links, breadcrumbs, contextual links, product recommendations and other internal references so they point directly to the final URL.
Google's migration documentation specifically recommends updating internal links after a move rather than leaving them pointed at the old addresses.
This is also a useful time to look for orphan pages. A page may have migrated successfully and return a 200 status code, yet no longer receive any internal links because navigation or category relationships changed during the rebuild.
Those pages are easy to miss if you only test whether the URL works.
Canonical tags frequently break during CMS changes and redesigns because they are generated by templates rather than entered manually.
After migration, open several representative pages and inspect their canonical URLs.
A normal new page should generally reference its preferred live URL rather than the staging environment, old domain or an unrelated page.
For example, this would be suspicious on the new site:
<link rel="canonical" href="https://oldsite.com/product-a/">
when the live replacement is:
https://newsite.com/product-a/
Google treats redirects and rel="canonical" annotations as strong canonicalization signals. Sitemap inclusion is another, weaker signal. Sending contradictory signals makes it harder for search engines to understand which URL you actually want indexed.
Pay extra attention to ecommerce filters, pagination, international pages and sites that generate URL parameters. Migrations sometimes change how duplicate URLs are created even when the visible page appears unchanged.
Search Console's URL Inspection tool can also show the canonical URL declared by the site and, after processing, the canonical selected by Google.
Your post-migration sitemap should represent the site that exists now, not the site that existed before the migration.
It should contain the canonical live URLs you want search engines to discover.
Check for old-domain URLs, redirected URLs, 404 pages, staging URLs, duplicate parameter URLs and pages intentionally marked noindex.
Then submit the updated sitemap in Google Search Console.
A sitemap is especially useful after a site move because it gives Google a clean list of URLs to discover. However, submitting one is not a command to index every page. Google describes sitemap submission as a hint rather than a guarantee that every submitted URL will be crawled or indexed.
That distinction is important. Seeing “Sitemap submitted successfully” does not mean the migration itself is healthy.
You still need to monitor what happens to those URLs afterward.
Search Console becomes particularly useful once Google starts revisiting the site.
Look at the Pages or indexing reports for changes in URLs classified as not found, blocked by robots.txt, excluded by noindex, duplicate pages, soft 404s and pages where Google selected a different canonical.
A few errors are not automatically evidence of a failed migration. Old, intentionally removed URLs can continue appearing while Google processes the change.
What matters more is the pattern.
If hundreds of previously valuable pages suddenly become 404s, investigate.
If an entire directory is blocked, investigate.
If your important new pages are appearing as duplicates with old URLs selected as canonical, investigate.
Individual high-value URLs can then be checked using URL Inspection.
Avoid reacting to every small fluctuation. Google states that significant site moves can cause temporary ranking changes while URLs are recrawled and reindexed. For a small to medium-sized website, processing much of a move can take several weeks; larger sites may take longer.
The more useful question is not “Did traffic move today?” but “Are Google and users successfully reaching the replacement pages?”
A post-migration traffic decline is meaningless if measurement broke during the migration.
Before comparing old and new traffic, confirm that analytics is collecting data correctly.
Load several pages yourself and test the actions that matter to the business: form submissions, purchases, signup completions, calls, downloads, add-to-cart actions or other key events.
For GA4, Realtime reports and DebugView can be used to verify whether events are being collected as expected. Google specifically recommends DebugView when troubleshooting event implementations.
Also check whether the migration changed URL structures in a way that affects reports.
For example, /blog/article-name/ becoming /resources/article-name/ can make before-and-after comparisons misleading if reports are still filtered using the old directory.
Similarly, a new checkout platform, subdomain or payment gateway can change referral and session behaviour if cross-domain tracking is not configured correctly.
Do not diagnose an SEO problem until you know your measurement system is working.
Technical SEO is only one part of a successful migration.
A page can be indexable, fast and perfectly redirected while the contact form silently fails.
Walk through the website as a customer would.
Search for a product, open a category, move through navigation, add an item to the cart, submit a form, complete a test purchase where practical, register an account, use site search, request a quote, download a file and check confirmation emails.
The exact journey depends on the site.
The point is to test outcomes, not simply pages.
CMS or framework migrations can change form handlers, API connections, payment integrations, cookie behaviour and JavaScript events without producing an obvious visual error.
If the website generates leads or sales, these checks are more important than watching ranking graphs during the first few hours.
A migration should preserve more than URLs.
Compare high-value pages against the old version or your pre-migration crawl.
Look for changes to page titles, meta descriptions, H1s, body content, image alt text, internal links, canonical tags, structured data and indexability.
This is especially important when content was transferred automatically between content management systems.
A migration script may successfully create every page while losing secondary fields that were stored differently in the old CMS.
Imagine a product page where the main description survives but specifications, FAQs and schema markup disappear. Technically the URL migrated. From the user's perspective, the page became worse.
Do not assume matching URL counts mean matching content.
Structured data often sits inside themes, plugins or templates. Changing any of those can remove or alter the markup without changing what a visitor sees.
Test important templates using Google's Rich Results Test.
Google recommends validating deployed structured data and then using URL Inspection to see how Google accesses the live page.
Check the types relevant to your site, such as Product, Breadcrumb, Article, Organization, Recipe or other supported markup.
Do not simply compare the number of schema blocks.
Confirm that properties still reflect the visible content. Product prices, availability, author names, images and breadcrumbs should not be inherited incorrectly from the old setup.
A redesign can make a website visually better while making it substantially heavier.
New themes, JavaScript libraries, consent tools, tracking scripts, fonts, videos and image components can all affect performance.
Run important page templates through performance testing rather than checking only the homepage.
Google's current Core Web Vitals focus on Largest Contentful Paint for loading performance, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. Google's recommended “good” thresholds are an LCP within 2.5 seconds, INP under 200 milliseconds and CLS below 0.1.
Do not treat those numbers only as SEO targets.
A migration that makes product filtering sluggish, causes buttons to jump while loading or delays checkout interactions has created a user problem even if search traffic initially remains stable.
Lab tests are useful immediately after launch. Real-user Core Web Vitals data takes time to accumulate, so keep monitoring after launch rather than making a one-time check.
Do not assume that a desktop QA pass covers mobile.
Open the site on real phones where possible and test the areas most likely to fail: navigation menus, filters, forms, tables, cookie banners, popups, accordions, checkout screens and sticky elements.
Look for content hidden behind overlays, horizontal scrolling, buttons that are difficult to tap and elements that shift after loading.
Some migration problems only appear at specific breakpoints.
If mobile makes up most of your traffic, a migration can technically succeed while degrading the experience for the majority of visitors.
Looking only at total organic traffic can hide important problems.
Suppose total search visits fall by 5%, but your blog remains stable while product pages lose 40%. That tells a very different story from an even decline across the website.
Break post-migration performance down by page type or directory.
Compare product pages with product pages, articles with articles, location pages with location pages and service pages with service pages.
Then examine your most important landing pages individually.
This helps separate migration issues from normal changes in demand.
Google's own traffic-drop guidance recommends analysing affected pages and queries and considering external factors such as seasonality and changing search interest rather than assuming every decline is a technical problem.
A migration date should be recorded in your reporting so future analysts know exactly when the site changed.
Not every migration failure produces a 404.
Watch for 5xx server errors, timeouts, unusual response times and resource failures.
Google notes that crawling can temporarily increase after a migration because its crawler needs to revisit both old URLs and new destinations. The new server therefore needs enough capacity to handle additional crawling as well as normal user traffic.
Server logs can be particularly useful on larger sites because they show what search crawlers are actually requesting rather than only what you expect them to request.
They can reveal old URL patterns that were missing from your migration map, repeated server errors or crawler activity concentrated on areas you did not anticipate.
This step applies only to certain migrations.
If the website moved from one domain or subdomain to another, Google recommends using the Change of Address tool in Search Console after the redirects are in place and both properties are verified.
For example:
oldbrand.com → newbrand.com
Google says the tool is intended for domain or subdomain moves. It is not required for an HTTP-to-HTTPS change, switching between www and non-www on the same domain, or simply moving pages into different folders on the same domain.
Do not use the tool as a substitute for redirects. It works alongside a properly implemented migration.
Your redirects can continue handling old links, but links you control should eventually point directly at the new destination.
That includes social media profiles, Google Business Profile links where relevant, email templates, paid advertising landing pages, affiliate profiles, partner pages and important directory listings.
For valuable backlinks from other websites, it may also be worth asking the publisher to update the destination directly.
Google recommends updating both internal links and high-value external references after a move.
Do this selectively. Spending hours chasing every low-value backlink is unlikely to be productive.
Prioritise links that generate real referral traffic, come from important partners or point to commercially important pages.
There is no universal point at which every migration is “finished.”
Google processes site moves URL by URL. It needs to discover old URLs, follow redirects, crawl replacements and update its understanding of the site. Google says small to medium-sized sites may take a few weeks for most pages to move, while larger sites can take longer.
A practical monitoring pattern is to check critical functionality immediately, inspect crawling and indexing closely during the first days, and then compare search and business performance over the following weeks.
Do not declare failure because rankings moved for three days.
At the same time, do not dismiss a sustained decline as “Google still processing the migration” if your checks show broken redirects, blocked pages or missing content.
The technical evidence should guide the diagnosis.
A healthy migration does not necessarily mean every metric remains perfectly flat.
Some search volatility is expected when URLs change.
What you want to see is a coherent transition: important old URLs resolve to appropriate replacements, the new pages are crawlable, new URLs begin appearing in search, the old URLs gradually disappear, analytics continues recording users, and important conversion journeys still work.
Traffic on the old domain should decline while activity on the new domain increases in a domain migration. Google describes this movement as an expected part of the process.
Problems become more concerning when several warning signs appear together—for example, organic traffic drops sharply while important old URLs return 404s and replacement pages remain blocked from indexing.
That is no longer normal migration volatility. It is a technical problem that should be fixed.
The migration mistakes that cause the most trouble are often ordinary ones: staging restrictions left on production, missing redirects, old URLs left in internal links, canonicals referencing the previous site, analytics tags disappearing, XML sitemaps containing outdated URLs, structured data being lost during a CMS switch, and forms or checkout flows no longer working.
What makes them dangerous is that many are invisible from the homepage.
A migration should therefore be audited by sampling different templates and user journeys, not by opening the new homepage and deciding that everything looks fine.
A successful website migration is not measured by whether the new design launched on schedule.
It is measured by whether users and search engines can move from the old site to the new one without losing access to the pages, information and actions that mattered before.
Start with the issues that can cause immediate damage: crawlability, redirects, analytics and conversions. Then work through canonicals, sitemaps, internal links, structured data, performance and indexing.
Finally, compare actual business and search outcomes over the following weeks.
The goal is not to prevent every temporary ranking movement. Google itself warns that some fluctuation can occur during a substantial site move. The goal is to make sure those fluctuations are caused by search engines processing a legitimate change not by technical mistakes that were left unnoticed after launch.
Related guides and breakdowns from the same category.
Join the conversation
No comments yet
Start the conversation on Post-Migration Checklist: What to Check After a We....