How to protect SEO during a website migration

You can reduce the SEO risk of a migration. You cannot promise that traffic or rankings will remain unchanged.

The practical work is to preserve the important content and addresses, prevent avoidable technical changes, and check what search engines and visitors encounter after launch.

Establish what is changing

A hosting or framework change can keep the same URLs. A domain move, path change or content consolidation changes more signals at once. Google provides separate guidance for moves with and without URL changes.

Document the intended changes. Keeping the design and content stable can make comparison easier, but a simultaneous redesign is not inherently impossible. It requires separate decisions and clearer acceptance criteria.

Build the URL inventory from several sources

Combine the crawl, CMS records, sitemaps, existing redirects and available search, analytics or request data. Do not assume one source is complete.

For every important address, record whether it will remain, change or be retired. Include assets and historical paths when people or search engines still use them.

When an address changes, map it to the relevant replacement and test the final destination. Keep existing addresses where they still fit. Do not add a redirect to a URL that is not changing simply to make every row look alike.

Preserve meaning as well as addresses

Compare the main content, headings, internal links, titles, descriptions, canonical URLs and relevant structured data. Keep intentional changes visible in the migration record.

Check image and file references. A migrated article that loses its diagrams, downloads or author relationship is not equivalent merely because its URL still responds.

Use automation to cover broad sets of routes, then review important templates and difficult content cases manually. Record exceptions rather than assuming that a successful build proves equivalence.

Check the production release, not only staging

Before launch, confirm the production domain, certificate, environment configuration and indexing rules. Protect staging appropriately, then make sure staging-only restrictions do not remain on production.

Validate the final sitemap and check representative pages as a visitor and through the available search-inspection tools. Submit the new sitemap where appropriate. A domain or subdomain move may also require Google's Change of Address process; a same-domain path change does not.

Preserve the ability to recover, and agree who makes the decision if important checks fail during cutover.

Monitor against a baseline

Record search and conversion baselines before launch. Afterward, compare landing pages, queries, devices and other useful segments rather than reading one total in isolation.

A reporting change can come from indexing, redirects, changed content, demand, tracking or consent. Google's traffic-drop guidance describes several possible causes, so a fall in clicks should trigger investigation rather than an automatic diagnosis.

Correct confirmed technical problems promptly. Do not wait through a supposed recovery period when the live site has a wrong canonical or an important redirect fails.

Do not promise a recovery calendar

Search engines need to process the move, but the timing and outcome vary. Avoid promising a first-week dip followed by recovery in a particular month.

Keep redirects and monitoring responsibilities beyond the initial launch period. Google recommends keeping redirects for at least a year in a URL-changing move; retaining useful redirects longer can also support people following older links.

The first week of developer aftercare and the full search-monitoring period are different commitments. Assign both deliberately.

Build a URL decision sheet the team can test

A URL sheet should describe the intended outcome for each address, not merely record that it appeared in a crawl. Add the source of the address, the content it represents, its business importance and the result expected after launch. That makes the sheet useful to developers, editors and the person reviewing search performance.

An illustrative set of decisions looks like this:

Do not send every retired page to the homepage. The destination should make sense to somebody following the original link. Where there is no equivalent content, record that decision instead of inventing an unrelated replacement simply to eliminate every error response.

For query parameters, distinguish campaign attribution from parameters that change the content. A campaign parameter may need to survive a redirect for measurement, while a filter or pagination parameter may represent a different view. Test the behavior you actually need rather than applying one rule to every parameterized URL.

Compare content at the template and record levels

Template checks catch repeated errors: a canonical using the staging hostname, a missing article heading, or a metadata field omitted from every page. Record checks catch exceptions: a particular article with an unusual embed, a missing author, or a download that was never copied.

Use both. A successful template does not prove every record is complete, and manually checking several articles will not reliably reveal a shared configuration error. Select representative records with long titles, old content, optional fields, unusual assets and different publication states.

An evidence table can contain the old URL, intended new URL, title, main heading, canonical, indexability, primary image and content identifier. Add a review state and an explanation for intentional differences. This helps separate accepted editorial changes from defects introduced by the migration.

The purpose is not to preserve every typo indefinitely. It is to know which changes were deliberate. If a migration also improves content, record those improvements as a separate part of the scope so search changes can be interpreted with the right context.

Diagnose a post-launch drop in a useful order

Start with access and routing. Can the affected pages be requested successfully, and do old links reach the intended destinations? Next inspect indexing signals: production restrictions, canonicals, sitemaps and internal links. Then compare important content and metadata. Only after those checks should you assume the explanation is normal search processing.

Measurement needs its own check alongside this sequence. If analytics fell but search clicks and destination conversions did not, examine tracking and consent behavior. If impressions remain similar but clicks fall, inspect the affected queries and search appearance. If both fall, investigate the pages and demand patterns rather than treating the whole site as one case.

Keep the investigation specific. “Organic traffic is down” is a starting observation. “The resource template has a staging canonical on all article pages” is a fixable finding. Each confirmed issue should have an owner, a correction and a follow-up check.

Create a monitoring schedule with named responsibilities

The intensity of monitoring can change after launch without disappearing. During cutover, check critical routes and business journeys immediately. In the following days, inspect errors, submissions, deployment health and the highest-value landing pages. Continue search review beyond the operational handover as the move is processed.

This is an ownership model, not a claim that every site needs a daily meeting. A small site can use a short shared report. A larger site may need automated alerts and a more formal incident process.

Questions to settle before approving the launch

These questions turn SEO preservation into work that can be assigned and reviewed. They also keep the promise realistic: the team can verify implementation and respond to problems, while search rankings remain an observed outcome.

For the wider release process, use the Webflow-to-Astro checklist. For examples of apparently successful systems that lose data, read what breaks in a migration.

What a migration can responsibly promise

The deliverable is a documented inventory, implemented URL decisions, checked content and metadata, and evidence of the launch checks. It is not a guaranteed ranking position.

That distinction makes the work more useful, not less. It separates the parts the team can verify from the outcomes that need ongoing observation.

Use the full migration checklist to connect SEO checks to content, forms, analytics and handover.

Sources

• Google: Move a site without URL changes. Checked September 18, 2026.
• Google: Site moves with URL changes. Checked September 18, 2026.
• Google: Debugging drops in search traffic. Checked September 18, 2026.