How Do You Avoid Losing SEO in a Site Migration or Redesign? A Checklist

To avoid losing SEO in a site migration or redesign, crawl the site before the move and record every URL and performance figure, build a one-to-one 301 mapping between old and new addresses, verify canonical, sitemap and robots settings, and monitor Search Console for several weeks after launch.

Redesign and migration projects usually start with visual and functional goals; SEO comes to mind in the last week. Yet the most frequent causes of traffic drops are not design but technical details: missing redirects, a noindex left on by mistake, changed URLs, lost content and broken internal links. An honest warning: even when done right, temporary fluctuation can occur, and no checklist guarantees that traffic stays the same. The aim is to minimise loss and be able to find quickly what caused what.

What types of migration and redesign are there, and what is the risk of each?

There are four basic migration types: domain change, CMS or infrastructure change, URL structure change and a move from http to https. They can also be done together. The more that changes at once, the more risk and sources of problems; where possible, splitting into phases makes diagnosis and fixing easier.

• —Domain change: all pages move to a new domain; the highest risk, since all signals need to transfer to the new domain.
• —CMS or infrastructure change: same domain and URLs, different system; the risk is that the template produces meta tags, structured data or content differently, and speed differences.
• —URL structure change: page addresses change; the risk is missing or wrong redirects.
• —https move: from http to https; the risk is mixed content, redirect chains and canonical mismatches.
• —Design refresh (same URLs): the look changes; the risk is loss of content, titles and internal links, or lower speed.
• —Merge and split: combining two sites or splitting one; content mapping is the most complex type.

Knowing from the start which type you are doing decides which items of the checklist are critical for you. For example, if you only refresh the design and keep URLs the same, your redirect load is low but preserving content and heading structure is the priority. If you change the domain, redirects and Search Console must be monitored step by step.

Why is crawling the site and building a URL inventory necessary before a migration?

Crawling the site before migration gives you a recorded inventory of all current pages, their titles, redirects and internal links. Without it you cannot know which page has been lost or which old address needs redirecting. The inventory is the foundation of every later step in the migration.

• —Full crawl: run a crawler across the site and export all URLs, status codes, title, description, h1, canonical and noindex data.
• —Sitemap and Search Console: add addresses that are in the sitemap or known to Google but do not show up in the crawl.
• —Orphan pages: identify pages that receive no internal links but get traffic or backlinks.
• —Pages with external links: flag valuable pages; their URLs should be preserved or correctly redirected.
• —Media and files: also record the addresses of PDFs, images and downloadable files.
• —Redirects: export existing 301 and 302 rules; they need to be preserved in the new system too.
• —Keep the crawl record: back it up with a date label for comparison after launch.

How do you build a performance baseline before the migration?

A performance baseline is a record of traffic, rankings, conversions and speed metrics before the migration. If a drop occurs afterwards, it is the only reference you will compare against. Exporting Search Console and analytics data with a date label is one of the most valuable and most often forgotten jobs before a migration.

• —Search Console: export page and query level impressions, clicks, CTR and position for the last 12 to 16 months.
• —Analytics: organic sessions, top-traffic pages, goal and conversion data; with the same period last year if possible.
• —Key query list: current positions of the 20 to 50 keywords that earn you business.
• —Speed and Core Web Vitals: current measurements for the main templates, so you notice if the new site is slower.
• —Index status: the number of indexed pages in Search Console and the error reports.
• —Conversion paths: a test record showing that form, phone and WhatsApp clicks work.
• —Seasonality note: do not schedule the migration in the middle of peak sales season; read the baseline together with the season.

How do you prepare a URL mapping table and set up 301 redirects?

A URL mapping table is a list showing the new equivalent of every old address and forming the basis of redirects. Each old URL should be 301-redirected in a single step to the new URL with the closest content equivalent. Redirecting everything to the homepage is often treated by Google like a soft 404 and loses value.

• —Table columns: old URL, new URL, status (stays the same, changes, merges, removed), redirect type, note.
• —One-to-one mapping: to the closest content; if there is none, to the relevant category page, and as a last resort the homepage.
• —Single step: do not build chains from A to B and B to C; redirect the old address directly to the final one.
• —301 is the permanent redirect; do not use 302 unless the situation is temporary.
• —Do not forget old addresses with query parameters or trailing-slash variations.
• —Removed pages: ones with truly no content and no equivalent may return 404 or 410; but no page with traffic or links should be silently deleted.
• —Redirect testing: before launch, test the whole list with a tool in staging, not a sample.

Keeping redirects for at least a year is recommended; keeping them permanently is even safer. Old addresses can still receive links from outside and sit in users' bookmarks. Removing redirects too soon puts at risk all the signals you carried over during the migration.

How do you verify canonical, hreflang, sitemap and robots.txt?

On the new site, canonical tags should point to their own page, hreflang should be reciprocal and correct, the sitemap should contain only addresses you want indexed that return 200, and robots.txt should not block important sections. These four settings are the technical elements most often broken after a migration and should be tested one by one before launch.

• —Canonical: each page points to its own new address; no leftovers pointing to the old domain or the staging address.
• —Hreflang: reciprocal checks on a multilingual site; language folders and alternates updated with the new addresses.
• —Sitemap: contains only new, canonical, 200-returning addresses; remove the old sitemap and submit the new one to Search Console.
• —robots.txt: no restrictions left over from staging; important folders not blocked; the sitemap location is stated.
• —Meta robots: leave no noindex or nofollow leftovers at template level.
• —Structured data: make sure template markup works with the new addresses and correct information; validate sample pages with the Rich Results Test.
• —Pagination and filter pages: review canonical and index policy in the new system.

Why is forgetting to remove the staging noindex such a common disaster?

Staging, the test environment, is protected from search engines by noindex or a robots.txt block. If these settings are not removed when the site goes live, the new site is not indexed and rankings can disappear fast. This is one of the most common and most preventable migration mistakes and deserves its own item on the checklist.

To prevent it, manually verify three things on launch day: the page source has no noindex in the meta robots tag, the robots.txt file has no Disallow: / line, and the HTTP header has no X-Robots-Tag: noindex. Checking a few important pages in Search Console's URL Inspection tool to see an “eligible for indexing” status is also a good verification. Do not forget the reverse either: a copy still live on the old site (old domain) and the new site must not create duplicate content; a redirect must be set up.

• —Launch morning: check the source code and HTTP headers on the homepage, a service page and a blog post.
• —Open and read the robots.txt file in the browser.
• —Run a live URL test with Search Console URL Inspection.
• —Add password protection to the staging environment so it cannot be indexed by accident.
• —After launch, check that the staging environment does not appear in search results.

How do you use Search Console's Change of Address tool in a domain change?

In a domain change, after the 301 redirects are in place, Search Console's Change of Address tool tells Google that you have moved from the old property to the new one. This tool applies only to domain changes, not to moves where only the URL path changes. Both domains must first be verified as properties.

• —Old and new domains added and verified as properties in Search Console.
• —301 redirects from the old domain to the new one working for all pages.
• —Submit the new domain's sitemap.
• —Open the Change of Address tool in the old property's settings and select the new property.
• —Keep the old domain and redirects alive for a long time; remember to renew the domain registration.
• —Where possible, ask owners of external links from the old domain to update them to the new address.

The tool does not replace redirects; using it without redirects in place is pointless. Also, traffic and rankings may fluctuate temporarily during this kind of move; it takes time for Google to fully process the new domain. During the migration you need to monitor the old and new properties together.

How do you protect analytics, tags and conversion tracking during a migration?

After migration you need to test on launch day that analytics, the tag manager, ad conversions and form tracking codes work correctly on the new site. These codes can disappear with the template; if unnoticed, weeks of data are lost and measuring the impact of the migration becomes impossible.

• —Analytics code: confirm with real-time reports that it works on the new site.
• —Tag manager and ad tags: test that conversion tags fire.
• —Phone, WhatsApp and forms: verify with a test submission that click and submit tracking works.
• —Search Console property: make sure a property is verified for the new domain or https.
• —Cookies and privacy: the consent mechanism should behave the same on the new site.
• —Goals and filters: internal traffic filters and goal definitions in analytics should match the new URLs.
• —Notes: mark the launch date as an annotation in analytics.

What should the post-launch monitoring calendar look like?

Post-launch monitoring runs as hourly checks on day one, daily checks in the first week and weekly checks in the following weeks. The aim is to separate problems from temporary fluctuation and fix real errors quickly. A calendar decides in advance who looks at what and prevents decisions based on panic.

• —Launch day: staging noindex check, redirect samples, sitemap submission, analytics and conversion test, 404 and error page check.
• —First week (daily): Search Console coverage and crawl errors, 404 and 5xx in server logs, redirect chains, number of indexed pages.
• —Weeks 2 to 4 (weekly): organic traffic against the baseline, positions of target queries, duplication and canonical issues, Core Web Vitals field data.
• —Months 2 to 3 (fortnightly): ranking recovery, lost pages, falling query groups, internal link and content gaps.
• —Month 6: year-on-year comparison, review of permanent redirects, closing remaining issues.

How long does temporary fluctuation last after a migration, and when should you worry?

Even after a correctly done migration, temporary fluctuation in organic traffic and rankings can occur; it takes time for Google to recrawl, process and transfer signals to the new addresses. The duration varies with the size of the site and the type of migration. Giving a precise number of days would not be right, but recovery within a few weeks is commonly expected.

To judge whether to worry, look at these signs: is it a continuous decline rather than fluctuation? Has a specific group of pages vanished? Are coverage errors, “not indexed” pages or 404 counts rising in Search Console? Is there a noindex, a missing redirect or a canonical error on the new site? If any of these is present, act immediately rather than waiting. If no problem is visible and traffic fluctuates then recovers, bulk changes made in a panic usually make things worse.

• —May be normal: fluctuation in impressions in the first weeks, temporary position changes for some queries.
• —Needs investigation: important pages dropping from the index, a rise in 404s, redirect chains, canonical mismatches.
• —Urgent: the whole site dropping out of the index, a noindex or robots block, server errors (5xx).
• —Wait and watch: no errors found, fluctuation visible; assess the weekly trend.
• —When intervening: make changes one at a time and record each.

What are the typical disasters in migrations and redesigns?

The most common disasters are: old URLs with no redirect, a noindex left on the live site, lost or shortened content, broken internal links, bulk redirects to the homepage, wrong canonicals and forgotten tracking codes. All can be prevented with a checklist; the common cause is design-led work leaving SEO to the final stage.

• —No redirects: old addresses returning 404, losing link and ranking value.
• —Noindex leftover: a staging setting carried over to live.
• —Content cutting: deleting service and guide text in the name of a “simpler” design.
• —Title and meta loss: the new template giving every page the same title or an empty description.
• —Internal link loss: menu and in-content links missing in the new structure.
• —Bulk homepage redirect: sending all old pages to the homepage.
• —JavaScript content: important content produced only on the client side and not crawlable.
• —Speed loss: a heavy, image-led new design worsening Core Web Vitals.
• —Tracking loss: analytics and conversion codes deleted along with the template.
• —Mobile difference: desktop and mobile versions carrying different content.

Every disaster has a preventive checklist item. That is why preparing the list at the start of the project, sharing it with the design team and developer, and holding an “SEO sign-off” meeting before launch is the cheapest insurance for a migration.

What is the summary checklist for migration and redesign?

The summary checklist has three phases: before, crawl, URL inventory and baseline; at launch, mapping table, 301s, canonical, sitemap, robots and noindex checks; after, analytics verification, Search Console monitoring and weekly comparison. Each phase should end with an owner and a sign-off.

• —Before: full crawl and URL inventory; Search Console and analytics baseline exported; most valuable pages identified.
• —Before: URL mapping table ready; content, titles and internal links planned to be preserved in the new design.
• —Before: staging noindexed or password-protected; go-live day and owners set.
• —Launch: all 301 redirects tested, no chains or loops.
• —Launch: canonical, hreflang, sitemap and robots.txt verified; no noindex leftover.
• —Launch: analytics, tags and conversion tracking working; phone, WhatsApp and forms tested.
• —Launch: new sitemap submitted; Change of Address tool used if it was a domain change.
• —After: daily Search Console and traffic monitoring in the first week, weekly in the following months.
• —After: 404s, crawl errors and index coverage checked regularly; issues fixed one by one and recorded.
• —After: redirects kept for at least a year, preferably permanently.