Migrating a Site Without Losing Search Visibility

What counts as a migration

A site migration is any significant change that affects how search engines find, read or understand your site. Common types include:

• Domain change. Moving from one domain name to another, or merging two sites.
• Platform change. Switching content management systems or e-commerce software.
• Structure change. Reorganizing sections or rewriting URL patterns.
• Protocol change. Moving from HTTP to HTTPS.
• Redesign. A new template that changes headings, menus, content or code.

Some migrations are small and some are large, and many involve several at once. The more things you change together, the harder it is to tell what caused a problem. Where possible, separate big changes in time.

Be realistic about risk

Even careful migrations commonly cause temporary dips in search traffic while search engines process the changes. Nobody can promise a particular outcome or recovery time. The aim of a good checklist is to reduce avoidable losses, such as broken pages and lost links, not to guarantee nothing changes.

Also ask whether the migration is necessary. A move done for a good reason is worth the effort. A move done on a whim is a risk without a payoff.

Phase 1: Before you touch anything

1. Record the current state. Crawl the existing site and save the full list of addresses, titles, headings and key settings. This is your reference for everything that follows. Save traffic and search report figures as well, so you can compare afterward.
2. Identify your most valuable pages. Note which pages bring visitors, earn links from other sites or support sales. These get extra attention.
3. Take full backups. Backups and recovery plans matter before any large change. Make sure you can roll back.
4. Decide what is staying. A migration is a chance to merge or remove weak pages through content pruning, but doing too much at once adds risk. Be deliberate.
5. Set the scope and owners. Decide who does what, and what counts as success.

Phase 2: Build the address map

The address map is the heart of the project. It is a spreadsheet with one row per old address and the new address that replaces it. Rules of thumb:

• Map each old page to the most relevant new page, not simply to the home page.
• Keep addresses unchanged wherever you can. The safest URL is the one that does not change.
• If a page is being removed with no replacement, plan a clear “gone” response instead of sending everyone to unrelated content. Redirecting many unrelated pages to the home page is often treated as a soft error.
• Include images, documents and other files that have their own addresses and may be linked from elsewhere.

Phase 3: Build and test on a separate copy

Build the new site in a staging area that is closed to the public and to search engines, usually behind a password. If a staging site is open to crawlers by accident, you can end up with duplicate content indexed. Then test thoroughly:

• Do all mapped addresses redirect correctly?
• Are titles, headings, descriptions and structured data carried over?
• Do internal links point at new addresses, not at old ones that need redirects?
• Are canonical tags pointing at the right version?
• Does the robots file allow crawling on the live site? A staging block copied to production is a classic mistake.
• Does the site work on phones and meet basic speed expectations?
• Is HTTPS set up properly, with no mixed content?

Phase 4: Launch

Pick a quiet time and have people available to respond. At launch:

1. Put the redirects live as permanent redirects, one hop from old to new. Avoid redirect chains.
2. Confirm the new site is crawlable and not blocked by the robots file or noindex tags.
3. Submit the new XML sitemap and, for a domain move, use the official change-of-address process offered by search engine tools if one is available.
4. Update links you control: social profiles, business listings, email signatures and advertising.
5. Check a sample of old addresses by hand, then crawl the whole list.

Phase 5: Monitor afterward

Watch closely for several weeks, and longer for large sites.

• Crawl the new site for broken links and error pages.
• Check search reports for crawl errors and for pages dropping out of the index. Compare against the indexing gaps you noted beforehand.
• Compare traffic by page group against your saved baseline, allowing for seasonal change.
• Look for old addresses that still show up and are not redirecting.
• Keep redirects in place for a long time, often at least a year, and longer if the old addresses still earn links.
• Keep a change log of what was changed and when, so any later drop can be traced to its cause.

Common causes of lost visibility

• Missing or wrong redirects, or temporary ones used where permanent were needed.
• Leaving a no-crawl or noindex setting from staging in place.
• Changing content and titles heavily at the same time as the address change.
• Dropping pages that had links or traffic.
• Forgetting to update internal links, which leaves many pages relying on redirects.
• Changing too many things at once and having no baseline to compare.

A migration is a project, not a switch. With a full inventory, an accurate map and careful monitoring, the process is much less likely to cause damage you cannot trace.