Website redesign without losing SEO: a migration checklist

Treat the redesign as a migration

A redesign can change URLs, navigation, content, HTML, rendering, speed, structured data, and measurement at the same time. To a visitor, it looks like a new interface; to a search engine, it may look like a different website. Losses occur when the team treats SEO as a final check, after the architecture and copy have already been replaced.

The realistic objective is not a promise that no ranking will move. Fluctuations can occur even during a well-run migration. The objective is to preserve valuable signals, limit ambiguity, and identify the cause of a problem quickly. That requires a comparison baseline, URL-by-URL mapping, and automated checks.

Before the redesign: build the inventory

Begin before approving the new sitemap. You need a list of the existing pages and the role of each one: organic traffic, conversions, backlinks, customer support, campaigns, or legal obligations. If the inventory is created after development, the new structure will reflect only what the team remembers, not what actually exists.

Collect URLs from several sources

No single source is complete. The sitemap may omit old pages, traffic analytics may omit pages without recent visits, and a crawl will not find orphan URLs. Combine the data, normalise the protocol, domain, trailing slash, and parameters, then remove duplicates carefully.

• The current XML sitemaps and robots.txt file.
• A complete crawl of the public website, including canonicals, status codes, and internal links.
• Page exports from the CMS, store, or relevant databases.
• Landing-page exports from analytics and Search Console, where legitimate access is available.
• URLs receiving backlinks, from the tools available to the company.
• Campaigns, landing pages, downloadable files, subdomains, and URLs frequently shared by sales teams.

Save a measurable baseline

Before launch, retain enough data for comparison: indexable pages, titles, descriptions, H1s, canonicals, status codes, structured data, internal-link counts, and performance metrics for the main templates. Export traffic and conversions by page separately, without assuming that every fluctuation follows the same seasonality.

• Record the date range and source of every export; otherwise, later comparisons become ambiguous.
• Keep screenshots or HTML for high-stakes pages, not only values in a table.
• List current events and conversions so the new implementation does not break measurement.

Create the URL map before development

The migration table is the contract between content, development, and SEO. For every old URL, record its current status, the page’s role, the new URL, the required action, and the reason. The technical team turns it into redirect rules, while the content team uses it to verify that intent has been preserved.

• Keep the URL when the page and its intent remain the same. This is the lowest-risk option.
• Use a 301 redirect to the closest equivalent when the URL changes permanently.
• Consolidate pages only when the new destination honestly covers the subject and the user’s need.
• Retire content without a redirect only when it has no useful replacement; choose the appropriate response deliberately and remove it from internal links and the sitemap.
• Keep campaign URLs that are still in use, or redirect them to a relevant destination rather than the homepage for convenience.

Avoid redirect chains. If /old already led to /intermediate and the new destination is /final, update the rule so /old reaches /final directly. Keep older rules that still receive traffic or links; a redesign is not a reason to delete them automatically.

Protect each page’s content and intent

A more spacious design does not justify removing the information that helped a page answer a search. Compare the old and new versions of every important page: which question it answers, which service or product it describes, what evidence it provides, and what action it enables. Copy can be rewritten, but it should not be thinned accidentally until only a slogan remains.

• One clear H1, followed by a logical hierarchy of H2 and H3 headings.
• A unique title and meta description aligned with the actual page, not copied across services.
• Content, images, alternative text, and important files are migrated in full.
• Internal links point directly to final URLs and keep important pages connected.
• Breadcrumbs, pagination, language variants, and relationships between pages remain coherent.
• Structured data describes visible, genuine content; markup that is no longer valid is not carried over automatically.

If two pages are merged, combine the useful information before redirecting. If a page changes subject radically, keeping its URL does not automatically preserve relevance. Technical continuity and continuity of intent must exist together.

Technical checklist for the staging environment

The staging environment must be protected from indexing, but that protection must not reach production. At the same time, blocking the staging crawler completely can hide rendering and linking problems. Use controlled access, run an authenticated crawl, and then verify explicitly which configuration will be active at launch.

• Every page intended to be public returns 200; missing pages genuinely return 404 rather than a 200 page that merely looks like an error.
• Canonicals use the production domain, the correct protocol, and the preferred URL for the page.
• No meta noindex, X-Robots-Tag header, or robots.txt rule remains accidentally on public pages.
• The sitemap contains only canonical, indexable URLs that return 200 and uses credible modification dates.
• Navigation and essential content exist in rendered HTML and remain usable without a fragile JavaScript race.
• HTTP, www/non-www, uppercase variants, and trailing slashes are normalised consistently without loops.
• Filter parameters, internal search, and pagination do not create an unlimited space of indexable URLs.
• Open Graph metadata, social cards, favicons, document language, and shared images are correct.
• Structured data passes validation and contains no invented reviews, addresses, or other facts.
• Forms, cookie consent, and analytics work in every relevant consent state.
• The main pages are tested on mobile for visual stability, interaction, and loading time.

Test redirects as data, not by hand

Turn the migration map into an automated test. For every old URL, verify the expected response, final destination, and number of hops. Run it against the server configuration before launch and against the public domain immediately afterwards.

• Use 301 for permanent moves; do not leave 302 responses from temporary configurations.
• The destination returns 200 and is indexable.
• There are no loops, unnecessary chains, or broad rules that override important exceptions.
• Query strings needed for campaigns or features are retained; meaningless ones are not propagated blindly.
• Files, images, or PDFs with external links are included in the plan if they move.
• Internal links have been updated; redirects are a safety net, not a permanent navigation mechanism.

The right order on launch day

Plan the launch as a reversible and observable change. Assign owners for the application, infrastructure, content, SEO, and analytics, along with the criterion for stopping or rolling back the launch. Avoid launching when the people able to intervene are unavailable.

1. Freeze editorial changes and synchronise the final content version.
2. Create a backup and verify the restoration procedure, not only the existence of the archive.
3. Publish the application, domain configuration, and 301 rules in the documented order.
4. Remove staging protections only from the public environment, then check robots, noindex, and canonicals.
5. Run tests for old URLs, important pages, 404 responses, the sitemap, forms, and conversions.
6. Walk through the website as a user on mobile and desktop, and inspect server logs for errors.
7. Submit the updated sitemap through the available tools and, where the strategy requires it, keep old sitemaps long enough to help search engines discover the moves.
8. Record the time of the change, the released version, and any departure from the plan; these details shorten diagnosis.

What to monitor after launch

The first checks are operational: 5xx errors, spikes in 404 responses, failed redirects, inaccessible pages, forms, and conversions. Then monitor search signals by page and page type, not only the domain total. An average can hide that one category improved while the main service disappeared.

• Compare landing pages, queries, clicks, and impressions with the baseline and known seasonality.
• Check indexing reports, sitemaps, and URL inspection for priority pages.
• Crawl the domain periodically for incorrect canonicals, broken links, orphan pages, and internal redirects.
• Monitor real performance by template and device; laboratory results alone do not represent every visitor’s experience.
• Keep the redirect map after the website stabilises. Old URLs may continue to receive visits and backlinks.

Decide in advance who owns a correction and how quickly it can be published. Monitoring without an owner produces reports, not solutions.

How to diagnose a decline

Do not change titles, copy, and infrastructure simultaneously in an attempt to repair every fluctuation. Segment the problem. Has tracking disappeared, or has real traffic declined? Does it affect the whole domain, a directory, one template, or a few URLs? Have impressions, rankings, or click-through rate fallen? Do old pages redirect? Are the new pages accessible and self-canonical? Is important content still present?

1. Confirm measurement using logs, analytics, and search-engine data.
2. Compare the affected URL list with the migration map and the template in use.
3. Inspect the status, canonical, robots directives, rendered HTML, and internal links for a representative sample.
4. Compare the topic and usefulness of the old page with the new version.
5. Correct the demonstrated cause, publish in a controlled way, and observe the effect before making further broad changes.

A compact checklist for the project owner

• We have archived the complete inventory and pre-launch baseline.
• Every old URL has an action and an owner.
• Valuable content and each page’s intent have been preserved or deliberately consolidated.
• Redirects are implemented and tested automatically, without chains or generic destinations.
• Canonicals, robots directives, noindex, the sitemap, and status codes have been verified in the production configuration.
• Internal links, breadcrumbs, and navigation use the final URLs.
• Analytics, consent, forms, and conversions have documented tests.
• A backup, rollback plan, assigned owners, and an intervention window are in place.
• Monitoring works by URL and template, not only as an aggregated domain report.
• Migration rules and decisions are retained for the next team.

A safe redesign is not a brake on creativity. It is the discipline that lets you change the interface without discarding history, access, or the ability to measure what happened.

Official sources consulted

• Google Search Central — moving a site with URL changes
• Google Search Central — redirects and canonical signals
• Google Search Central — building and submitting a sitemap