How to relaunch a website without losing traffic

A relaunch is a migration, even when the domain stays the same

A company can keep its domain and still carry out a risky migration. Service URLs, catalog structure, rendering technology, copy, internal links, and loading speed may all change. For search engines and users, this is a new website configuration that must be correctly matched to the old one.

Traffic is not lost because of the new design itself, but because signals are broken. A popular page disappears, an old URL begins returning a soft 404, several resources are redirected to the homepage, important content becomes available only after a complex script runs, or a staging indexing restriction is accidentally carried over to production. These mistakes can be prevented before the switch.

Step 1. Create an inventory of the current website

Do not rely on the navigation alone. Search results may contain pages that have long been absent from the menu: old articles, PDFs, service pages, campaign URLs, and parameterized addresses. Build the list from several sources and merge the results by normalized URL.

• An export of all discoverable internal links and the sitemap.xml file.
• Pages receiving impressions and clicks in search engine tools.
• Landing and conversion pages from the analytics platform.
• URLs targeted by backlinks, advertising, emails, and partner materials.
• Utility URLs, files, images, and pages with parameters.
• Current response codes, canonical tags, robots directives, and metadata.

For every page, record its purpose, core content, search intent, traffic, inquiries, inbound links, and future URL. These numbers are not intended to produce a mechanical ranking: a page with modest traffic may still matter as proof of a service or as the customer's final decision step.

Step 2. Map the content, not just the URLs

A redirect takes the user to a new URL, but it does not replace the content. If a detailed old service page redirects to a general catalog containing a single paragraph, the original intent is no longer satisfied. A migration map therefore connects not only the URLs but also the heading, key questions, important sections, documents, and internal links.

A redesign is a good opportunity to remove repetition, but pages should only be merged with a clear rationale. Two pages can become one when they answer the same intent and the new version covers both subjects in full. Pages for different services or regions should not be redirected to the homepage in bulk simply to avoid visible errors.

• Preserve or improve the page's ability to answer the query on its own.
• Transfer verified case studies, tables, FAQs, and documents.
• Avoid changing both the meaning and the URL unless necessary.
• Update internal links to point directly to the final URLs.
• Preserve important passages referenced by other materials.
• Review pages that generate inquiries separately, even when they receive few views.

Step 3. Prepare a permanent redirect map

If an address has changed permanently, the server should return a permanent redirect to the most relevant new page. Prepare the map before launch and test it automatically. Every old URL should lead directly to its final destination without a chain of intermediate redirects.

• Old and new protocols, www and non-www variants all resolve to one canonical host.
• Rules account for letter case, trailing slashes, and actual historical variants.
• Parameters are preserved only where they are necessary and safe.
• Removed pages do not receive an arbitrary redirect to the homepage.
• Internal links, the sitemap, and canonical tags use the new URLs immediately.
• Redirects remain available long enough to serve users and external links.

An unknown route should return a genuine 404 status together with a useful navigation page. A visually polished error page that returns status 200 tells the search engine that the nonexistent URL is a normal document.

Step 4. Test the new build before switching over

The staging version must be protected from accidental indexing in a way that still allows the team to test real scenarios. Add the removal of temporary restrictions to a separate pre-launch checklist. Many production websites have inherited a noindex directive or robots.txt restriction because the review focused only on the homepage's appearance.

1. 01

   Compare the URLs

   Every row in the migration map has an implemented final route or the correct response.

2. 02

   Check the markup

   Every page has a unique title, description, H1, canonical URL, and the required structured data.

3. 03

   Review the content

   There are no placeholders, test contact details, missing sections, or broken images.

4. 04

   Check JavaScript

   The primary public content is available on load and is not hidden behind a mandatory user action.

5. 05

   Test the forms

   Successful, failed, and repeated submissions are displayed correctly and reach the production workflow.

6. 06

   Check the mobile version

   Navigation, tables, forms, and long headings do not overlap.

Step 5. Treat launch as a controlled operation

Schedule the switch for a period when the responsible team can monitor the website and correct a critical error. Back up files, data, and configuration before making changes. The rollback plan should specify concrete actions and the condition that triggers them, rather than saying only “if something goes wrong.”

• Record the current production version and create a backup.
• Check the domain, TLS, CDN, and caching configuration.
• Deploy the new build and apply the redirect map.
• Remove temporary indexing restrictions.
• Check the homepage, key landing pages, forms, and 404 response.
• Publish a sitemap containing canonical URLs.
• Review server logs and asset availability.
• Assign an owner for the monitoring period.

Changing the domain, content management system, structure, and content at the same time increases the number of variables. Where possible, separate changes into testable stages. There is no need to prolong the migration artificially, however: the decision depends on the architecture and the team's ability to maintain one consistent canonical state.

Step 6. Monitor crawling, indexing, and inquiries

Opening the website in a browser is not enough after launch. Search engines need to discover the changes, follow redirects, and update their indexes. The team should monitor response codes, crawl errors, excluded pages, impressions, and clicks for important URLs. The business workflow needs attention as well: confirm that forms work, acquisition sources are retained, and the quality of inquiries has not declined.

Some fluctuation may occur after major changes, so decisions should not be based on a single day or on total traffic alone. Compare groups of pages and queries, look for a technical break, and test the suspected cause. If a loss is confined to one section, rolling back the entire design may be excessive; address the migration issue first.

Common website relaunch mistakes

• Compiling the redirect list manually on publication day.
• Deleting old copy because it “does not fit the new design” without assessing its role.
• Changing every URL for visual consistency.
• Redirecting dozens of unrelated pages to the homepage or catalog.
• Leaving canonical tags pointed at the staging domain or old URL.
• Blocking CSS, JavaScript, or images required to render the page.
• Publishing a sitemap containing old, redirected, or blocked URLs.
• Forgetting to remove noindex after testing.
• Checking only the desktop homepage and failing to test forms.
• Deleting the backup before the monitoring period is over.

It is especially dangerous to treat the absence of an obvious error as proof of a successful launch. The server may return 200 while showing an empty application to a crawler; a form may display success without creating an inquiry; a redirect may work from the browser cache even though the server rule is wrong. Tests should observe the final result of every critical scenario.

A concise checklist for a safe migration

1. 01

   Before development

   Export URLs and data, assess page value, and design the future structure.

2. 02

   Before the design is final

   Map the old content to the new content and approve the permanent URLs.

3. 03

   Before launch

   Implement redirects and check metadata, forms, 404 handling, the sitemap, and indexing restrictions.

4. 04

   At launch

   Create a backup, switch the configuration, test critical URLs, and review the logs.

5. 05

   After launch

   Monitor crawling, indexing, traffic by page group, errors, and inquiries.

The goal of migration is not to preserve the old website unchanged, but to retain useful signals while improving the structure and product. The design, copy, and technology can all change when the team understands the role of each page, maintains meaningful equivalence, and verifies the transition from the old state to the new one.