Website Redesign and Migration: What Must Be Protected

A website redesign is usually discussed in terms of what will change: the design, navigation, platform, page templates, performance or content.

A business also needs a clear record of what must not be lost.

An established website may already contain search-visible URLs, links from other websites, working forms, analytics history, indexed content, conversion paths, legal pages and customer information that the business depends on.

A new design can be successful visually while still damaging those assets.

The safest way to evaluate a redesign or migration is therefore to treat continuity as a business requirement, not as a technical detail added near launch.

Not every redesign is the same kind of change

Several projects are commonly described as a “website redesign,” even though their risks differ.

Visual redesign

The design and templates change, but the domain and most URLs remain the same.

The main risks are usually:

• important content being removed;
• navigation or internal links changing;
• forms or tracking breaking;
• technical search settings changing unintentionally.

Platform or CMS rebuild

The visible website may remain similar, but the underlying system changes.

This can affect:

• URL formats;
• structured data;
• canonicals;
• redirects;
• forms;
• analytics;
• page speed;
• how content is rendered.

Hosting or infrastructure move

The domain and visible URLs may stay the same while the website moves to a new server, hosting provider or content delivery setup.

Google treats this differently from a move in which URLs change. Its hosting-move guidance emphasizes preparing and testing the new infrastructure, preserving Search Console verification where necessary, removing temporary crawl blocks at launch and monitoring the transition. [1]

URL or domain migration

The domain or page addresses change.

This creates the highest search-continuity risk because old URLs need clear destinations.

Google recommends preparing a mapping between old and new URLs and using permanent server-side redirects from the old URLs to the corresponding new ones. [2]

A business owner does not need to implement these systems personally.

The important point is to know which type of project is being approved, because the continuity requirements are different.

Begin with an inventory of what the current site already owns

Before the old site is replaced, the business should have a record of its important assets.

At minimum, that inventory should include the following groups.

Existing URLs

The current set of indexable pages should be recorded before launch.

This matters even if the plan is to “simplify the site.”

A page can have value because it:

• ranks for useful searches;
• receives links from other websites;
• receives direct or referral traffic;
• supports another page through internal links;
• contains information customers still need.

A page should not disappear merely because it is absent from the new navigation mockup.

Content with business value

The inventory should identify content that must be preserved, rewritten or deliberately retired.

Examples include:

• service descriptions;
• important local information;
• case studies;
• client evidence;
• pricing or process information;
• guides;
• legal or compliance content;
• frequently referenced resources.

The objective is not to preserve every sentence.

It is to avoid deleting useful business information by accident.

External links and established URLs

Other websites may already link to specific pages.

If those pages move, the business should know where those links will lead afterward.

Google recommends permanent redirects from old URLs to the corresponding new URLs and warns against redirecting many unrelated old pages to one irrelevant destination such as the homepage. [2]

If several old pages are legitimately consolidated into one stronger replacement, a redirect to that consolidated page can be appropriate. [2]

Forms and customer actions

A redesign should inventory every important action a customer can take.

Examples include:

• inquiry forms;
• quote requests;
• appointment requests;
• phone and email links;
• downloads;
• account or ecommerce actions;
• newsletter signup;
• lead-routing or notification logic.

A page that looks complete but sends inquiries to the wrong place is not a successful launch.

Analytics and measurement

The current measurement setup should be documented before launch.

A replacement site should preserve the measurements the business still needs, including:

• Analytics installation;
• Search Console verification where applicable;
• conversion or inquiry events;
• campaign parameters;
• referral information;
• consent behavior;
• server-side or CRM connections where they exist.

Historical data cannot be recreated after the fact if the new site stops collecting an important signal.

Preserve useful URLs unless there is a reason to change them

A redesign does not automatically require new URLs.

If an established page still performs the same job and its address is sensible, keeping the URL can reduce unnecessary migration work.

Changing URLs creates additional requirements:

• old-to-new mapping;
• permanent redirects;
• updated internal links;
• updated sitemap entries;
• updated canonicals;
• monitoring for broken or missing destinations.

Google recommends direct permanent redirects to final destinations where possible and advises avoiding redirect chains. [2]

For a business owner, the decision test is straightforward:

What business or architectural benefit justifies changing this URL?

If there is no clear answer, the change may be unnecessary.

A URL map should exist before a migration is approved

When URLs do need to change, the project should have a documented old-to-new map.

Each important old URL should have one of three outcomes:

KEEP
The URL remains the same.

MOVE
The old URL permanently redirects to a clearly equivalent new URL.

RETIRE
The content is intentionally removed and no equivalent replacement exists.

The third outcome should not be hidden by redirecting everything to the homepage.

Google specifically warns that unrelated mass redirects can confuse users and may be treated as soft 404 behavior. [2]

This makes the URL map useful beyond SEO. It forces the project to explain what will happen to each part of the old site.

Temporary staging protections must not become production settings

During development, a staging site may use controls that are correct for a private environment but wrong for launch.

Examples include:

• noindex;
• crawl restrictions;
• staging canonicals;
• password protection;
• temporary hostnames.

Google’s migration guidance explicitly warns site owners to remove temporary noindex or robots restrictions when the new site is ready to launch. [1][2]

This should be part of the launch checklist, not something left to memory.

Search settings are only one part of continuity

A migration can preserve every redirect and still fail operationally.

The launch review should also confirm that:

• forms submit correctly;
• notifications reach the right destination;
• phone and email links work;
• privacy and consent behavior still works;
• important scripts load;
• analytics receives data;
• navigation and internal links point to final URLs;
• mobile pages remain usable;
• error pages return correct status codes;
• sitemap and canonical URLs match the new site.

The business does not need to review each line of code.

It does need evidence that the release has been tested as a complete business system.

Some change in search visibility can still occur

Even a well-planned site move can create temporary search fluctuations while Google crawls redirects, processes new URLs and updates its systems.

Google notes that this can happen during URL migrations and that processing can take time. [2]

That is different from accepting preventable errors.

A temporary fluctuation after a correctly mapped migration is one thing.

Missing redirects, accidental noindex, broken forms or a sitemap full of obsolete URLs are another.

The project report should distinguish between normal transition effects and actual defects.

What a business owner should require before launch

A useful pre-launch handover should answer these questions.

What is changing?

The proposal should identify whether the project changes:

• design only;
• CMS/platform;
• hosting;
• URL structure;
• domain;
• forms;
• analytics;
• major content architecture.

What current assets were inventoried?

There should be evidence that existing URLs, important content, forms and measurement systems were reviewed before replacement.

Which URLs are changing?

If URLs change, the business should receive an old-to-new map or equivalent release record.

How are removed pages handled?

The project should distinguish legitimate consolidation from unrelated redirects.

What was tested before launch?

The release should include checks for search settings, forms, navigation, analytics, mobile behavior and key customer actions.

What will be monitored afterward?

The post-launch plan should identify:

• crawl/indexing issues;
• broken destinations;
• traffic changes;
• inquiry behavior;
• server or hosting problems;
• any important business functions that require observation.

A redesign should improve the site without erasing its history

A successful rebuild is not simply a new website placed where the old one used to be.

It is a controlled transition from one business system to another.

The project should know what the existing site already owns, decide deliberately what should change, preserve what still has value and document the parts that move.

Our Website Design & Development service follows that principle: visual improvement, technical quality and continuity should be planned together rather than treated as separate projects.

Sources

1. Google Search Central - Changing your hosting
   https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes
2. Google Search Central - Site moves with URL changes
   https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

Website Design & Development Library