How to Migrate a Website Without Losing SEO Rankings

How to Migrate a Website Without Losing SEO Rankings

A website migration can preserve SEO rankings when you plan URL changes, redirects, content, technical settings and post-launch monitoring before switching the site live. The central rule is simple: every important old URL must either remain available or be mapped clearly to the most relevant new URL through a properly tested 301 redirect.

A migration is not only a design or development task. It is a change to the website’s structure, technology, hosting, domain, content, or URLs, and search engines need time and clear signals to understand what has changed.

This guide explains how to plan an SEO migration for a business website, NGO, school, clinic, D2C brand or agency in India.

What Counts as a Website Migration?

Website migration means making a significant change to the website that can affect crawling, indexing, URLs or rankings. Some migrations are relatively low-risk. Others can affect organic traffic across the entire website if handled poorly.

Common types include:

• Moving from one domain to another
• Changing from HTTP to HTTPS
• Moving to a new hosting provider or server
• Rebuilding a website on WordPress, Shopify, WooCommerce or another platform
• Changing the URL structure
• Redesigning the website
• Combining two or more websites
• Moving from a subdomain to the main domain
• Removing or consolidating old content
• Changing international or language folders
• Moving from a custom CMS to a managed platform

A website relaunch may involve several of these changes at once. For example, a company may move from an old domain to a new domain, rebuild the website on WordPress, change its service URLs and replace its content. That is a high-risk migration because search engines must process multiple signals simultaneously.

A change to the visual design alone may not create a major SEO problem if the URLs, content, internal links and technical settings stay consistent. However, a redesign often changes these elements indirectly. That is why every relaunch should include a technical SEO review.

Different migrations carry different risks

The more elements you change at the same time, the more difficult it becomes to identify the cause of a ranking or traffic change.

Start With an SEO Migration Plan

The best time to plan an SEO migration is before development begins. Do not wait until the new website is ready to launch.

Assign someone to own the migration. This could be an internal marketing manager, developer, SEO consultant or agency. The owner should maintain the URL list, approve redirect decisions, coordinate testing and monitor the site after launch.

Define the migration scope

Write down exactly what is changing:

• Domain name
• Hosting provider
• CMS or e-commerce platform
• URL structure
• Navigation and categories
• Page templates
• Content
• Product or service pages
• Blog structure
• Images and media files
• Tracking systems
• Search Console property
• Payment or enquiry integrations
• Language or location folders

Also record what is not changing. This prevents accidental work during the launch and helps the team compare the old and new versions accurately.

For an Indian business, the migration plan may also need to account for:

• WhatsApp enquiry links
• Razorpay, Cashfree or other payment integrations
• GST information and business details
• Product feeds for marketplaces or shopping platforms
• Google Business Profile links
• Regional pages for cities such as Pune, Mumbai, Bengaluru or Delhi
• Indian phone number formats
• Cookie and consent requirements relevant to the organisation
• Donor, admission, appointment or enquiry forms

SEO is important, but a migration must also preserve the actions that matter to the business.

Set up a staging website correctly

A staging website allows the team to test the new build before launch. It should generally be blocked from search engine indexing while it is under development.

Common methods include:

• Password protection
• Server-level access restrictions
• A noindex directive
• A staging environment that is not linked publicly

Do not rely on robots.txt alone to keep a staging website out of search results. A blocked page may still be discovered through links, and search engines may not be able to see a noindex instruction if crawling is prevented.

Before launch, remove the staging restrictions from the production website. This step is easy to miss, especially when the same deployment configuration is reused.

Build a Complete URL Inventory

A URL inventory is one of the most important parts of website migration without losing SEO rankings.

Export or collect URLs from several sources:

• The current XML sitemap
• Google Search Console
• Google Analytics or another analytics platform
• Server logs, if available
• Internal links
• Navigation menus
• Backlinks from important referring domains
• Product or service databases
• Blog archives
• Image and document links
• The current website crawl

No single source contains every important URL. A page may receive search traffic but be missing from the sitemap. Another page may not receive traffic today but may have valuable backlinks.

Record useful information for each URL

Create a spreadsheet with columns such as:

• Old URL
• New URL
• Page type
• Current title
• Current meta description
• Main heading
• Organic traffic
• Conversions or enquiries
• Backlinks
• Current indexation status
• Redirect status
• Notes and approval

The purpose is not to preserve every weak or unnecessary URL forever. The purpose is to make a deliberate decision about each URL.

For every old URL, choose one of these actions:

1. Keep the same URL.
2. Redirect it to the corresponding new URL.
3. Redirect it to the closest relevant replacement.
4. Return a proper 410 or 404 status if there is no useful replacement.
5. Consolidate it into a stronger page after reviewing its content and links.

Do not redirect everything to the homepage

Redirecting every deleted page to the homepage is a common migration mistake. It creates a poor user experience and does not clearly communicate the relationship between the old page and the new destination.

For example:

• An old “school admission process” page should go to the new admission page.
• An old “women’s health clinic in Pune” page should go to the relevant clinic service or location page.
• An old product URL should go to the same product, its replacement, or the closest category.
• An expired event page may go to a related events or programme page if that is genuinely useful.

If there is no relevant replacement, a proper 404 or 410 may be more honest than an irrelevant redirect.

Plan and Test 301 Redirects

A 301 redirect tells browsers and search engines that a page has moved permanently. It is the normal redirect type for a permanent URL change.

A 302 redirect generally indicates a temporary move. It may be appropriate in limited situations, but it should not be used as the default for a permanent website migration.

Create a redirect map

A redirect map connects each important old URL with its approved new destination.

Examples:

• /about-us.html → /about-us/
• /services/web-design → /services/website-development/
• /blog/old-article-title → /blog/updated-article-title/
• http://example.in/page → https://example.in/page
• www.example.in/page → example.in/page

The exact redirect implementation depends on the server and platform:

• Apache may use .htaccess or server configuration.
• Nginx uses server block rules.
• WordPress can use a redirect plugin or server configuration.
• Shopify has built-in URL redirect tools.
• Cloud platforms may use edge or hosting rules.
• Custom applications may require redirects in the application or web server.

Ask the developer to confirm that redirects return a single 301 response and do not create a chain.

Avoid redirect chains and loops

A redirect chain happens when:

Old URL → Temporary URL → New URL

A better structure is:

Old URL → Final new URL

A redirect loop occurs when URLs point back to each other and the page never loads. Both problems can affect users, crawlers and page speed.

Test redirects for:

• HTTP to HTTPS
• Non-www to www, or the reverse
• Old URL to new URL
• Trailing slash variations
• Uppercase and lowercase versions
• Old category and product structures
• Deleted or merged pages
• Mobile URL variants, if they existed
• Query parameter versions where relevant

Preserve URL intent where possible

If the new site changes a page’s wording or structure, preserve the original search intent where it still matches the business.

For example, if an NGO has separate pages for education programmes, livelihood programmes and donation options, those pages should not be collapsed into a generic “Our Work” page without careful review. Search engines and users may see the pages as serving different needs.

Redirects are not a replacement for content planning. The new destination should be useful, accessible and reasonably related to the old page.

Preserve On-Page and Technical SEO

A website migration can lose rankings even when the redirects are correct. This often happens because important page-level and technical signals are missing from the new site.

Check titles, headings and descriptions

Compare the old and new pages for:

• Title tags
• Meta descriptions
• Main headings
• Supporting headings
• Body content
• Image alternative text
• Internal links
• Breadcrumbs
• Structured data
• Canonical tags

Do not copy every old page without review. Some content may be outdated, repetitive or inaccurate. But do not remove useful content simply to make the new website shorter.

A service page for website development, for example, should still explain the service clearly, identify the intended customer, describe the process and provide a sensible enquiry path. A vague page with only a heading and a contact button may be attractive but less useful for visitors and search engines.

Check canonical tags

A canonical tag indicates which URL should be treated as the preferred version of similar or duplicate pages.

After migration, confirm that:

• Canonicals point to live, indexable URLs.
• They use the correct HTTPS and domain version.
• They do not point back to the old domain.
• They are not accidentally set to the homepage on every page.
• Category, filter and pagination behaviour is intentional.
• Canonical tags agree with redirects and internal links.

A canonical is a hint, not a substitute for a redirect. If a page has permanently moved, implement the appropriate 301 redirect.

Check robots.txt and XML sitemaps

The production robots.txt file should allow search engines to crawl important areas of the site. It should not accidentally block:

• Main pages
• CSS and JavaScript files required for rendering
• Images
• Product or service pages
• Important folders
• The new sitemap

The XML sitemap should contain the preferred, indexable URLs of the new website. It should not include old redirected URLs, blocked pages, duplicate URLs, or pages with a noindex directive.

Submit the new sitemap in Google Search Console after launch. If the domain changes, verify the new domain property as well as the old one.

Check structured data

Structured data may be used for relevant content such as:

• Organisation information
• Local business details
• Products
• Articles
• Events
• Courses
• Frequently asked questions
• Breadcrumbs
• Reviews, where the implementation follows the relevant guidelines

Do not add structured data simply to create more markup. Ensure it matches visible content and remains valid after the redesign. A school, clinic, NGO or local business should be particularly careful with name, address, phone number and service information.

Test the New Website Before Launch

A staging review should cover more than whether the pages look good on a laptop.

Crawl the staging website

Use a crawling tool or a custom review to identify:

• Broken internal links
• Missing pages
• Redirects
• Incorrect status codes
• Duplicate titles
• Missing headings
• Missing meta descriptions
• Canonical errors
• Orphan pages
• Blocked resources
• Unwanted indexable pages
• Very large images
• Mixed HTTP and HTTPS resources

If staging is password-protected, the crawler may need access credentials. If that is not possible, inspect the site using the development team’s tools and run a full crawl immediately after launch.

Check mobile and performance

Most Indian users access websites through mobile devices and variable network conditions. Test the website on common mobile screen sizes and on more than one network where practical.

Review:

• Layout shifts
• Font readability
• Tap target sizes
• Menu behaviour
• Form usability
• Image loading
• Web font loading
• JavaScript errors
• Core Web Vitals
• Checkout, donation, admission or appointment flows

Do not remove important content merely to make pages lighter. Instead, compress images, reduce unnecessary scripts, improve caching and review third-party tools.

Test forms and business journeys

A website migration is unsuccessful if visitors can find a page but cannot complete the intended action.

Test:

• Contact forms
• WhatsApp buttons
• Phone links
• Email links
• Donation forms
• Admission forms
• Appointment forms
• Product search
• Cart and checkout
• Payment gateway callbacks
• Thank-you pages
• CRM or email notifications
• Spam protection
• Consent checkboxes

For businesses operating in India, confirm that payment and communication integrations work after the domain or hosting change. Also check whether payment gateways, Meta Pixel, Google Analytics, Google Tag Manager and CRM systems require the new domain to be added to an allowlist.

Compare old and new content

Use the URL inventory to compare important pages manually. Prioritise pages with:

• Organic traffic
• Leads or sales
• Donations or applications
• Strong backlinks
• Brand importance
• Local search relevance
• Seasonal or campaign value

A migration does not require every sentence to remain unchanged. It does require the team to understand what the old page was doing before replacing it.

Launch the Migration Carefully

Choose a launch window when the team can monitor the site. Avoid launching immediately before a major campaign, admission deadline, sale, fundraiser or public holiday if technical support will be limited.

Before switching the site live, take a final backup of:

• Website files
• Database
• Media library
• Redirect rules
• DNS records
• Current sitemap
• Analytics configuration
• Important exports and forms

Use a final pre-launch checklist

Confirm that:

• The domain points to the correct server.
• HTTPS works correctly.
• The preferred domain redirects consistently.
• Staging restrictions have been removed from production.
• The new robots.txt is correct.
• The new XML sitemap is accessible.
• Redirects are active.
• Canonical tags use the new URLs.
• Internal links point to the new URLs.
• Tracking codes are present.
• Forms and payments work.
• The old website backup is available.
• Search Console access is available.
• The development and marketing teams know who is monitoring the launch.

If a domain is changing, do not cancel the old domain or hosting immediately. The old domain must remain available for redirects. The period required depends on the migration, backlink profile, brand usage and the number of old URLs. The team should review the situation rather than remove redirects on an arbitrary date.

Monitor SEO After the Migration

SEO migration work continues after launch. Search engines need to crawl the new URLs, process redirects and update their understanding of the website.

Monitor the first few days

Check several times during the initial launch period:

• Website uptime
• Homepage and key pages
• Server status codes
• Redirects
• Robots.txt
• XML sitemap
• Search Console messages
• Forms and payment flows
• Analytics data
• Organic landing pages
• 404 reports
• Crawl activity

Use a sample of old URLs from the redirect spreadsheet. Do not test only the homepage.

Compare trends, not isolated fluctuations

Traffic and rankings can move for many reasons, including search demand, competition, seasonality, content changes and tracking errors. A single day of lower traffic does not identify the cause.

Compare the new site against the pre-migration period while accounting for:

• Weekdays and weekends
• Campaign periods
• Festival or holiday seasons
• Admission and application cycles
• Product launches
• Paid advertising changes
• Tracking configuration changes
• Changes in brand demand

Look at landing pages, impressions, clicks, conversions and indexed pages separately. A traffic decline may be caused by analytics not loading, while a ranking decline may be caused by lost content or redirects.

Review Google Search Console

Important areas include:

• Indexing or page indexing reports
• Sitemaps
• Page experience
• Core Web Vitals
• Manual actions
• Security issues
• Performance by page and query
• Crawl statistics
• Redirect and server errors

Search Console is useful, but it may not reflect every change immediately. Combine it with server logs, analytics, crawler checks and direct testing.

Fix problems by priority

Prioritise issues in this order:

1. Sitewide blocking or noindex errors
2. Domain, DNS, HTTPS or server failures
3. Missing redirects for important old URLs
4. Incorrect canonical tags
5. Broken internal links
6. Missing pages with traffic or valuable backlinks
7. Content and metadata gaps
8. Performance and usability improvements

Do not change the website architecture repeatedly while the first migration is still being diagnosed. Make controlled fixes and record what changed.

Common Website Migration Mistakes

Launching without a URL map

If the old URL list is not documented, important pages and redirects are easily missed. This is especially common on older websites with blog posts, PDFs, campaign pages and multiple URL formats.

Blocking the live website

A staging noindex directive or disallow rule can be copied to production. Check the source code, HTTP headers and robots.txt after launch.

Changing URLs without a business reason

A new URL structure may look cleaner, but changing URLs creates work and risk. Change them when there is a clear benefit, not only because the CMS makes it easy.

Deleting content that still serves users

Shortening a website may be useful, but removing pages with traffic, backlinks or important information can reduce its search coverage. Review the data before deleting.

Forgetting non-HTML files

PDFs, images, downloadable brochures and old documents may have backlinks or search visibility. Include them in the inventory and decide whether to retain, redirect or remove them.

Failing to update internal links

Internal links that still point to old URLs may rely on redirects and create unnecessary crawling and user delays. Update menus, footers, breadcrumbs, related content and body links.

Changing domain and tracking together without testing

A domain change may affect Analytics, Tag Manager, advertising platforms, payment gateways, CRM tools and conversion tracking. Verify each system independently.

Removing the old domain too soon

If the old domain is no longer controlled, the redirects disappear. Keep ownership and access until the migration has been reviewed and important external references have been updated.

Frequently Asked Questions

How long does SEO migration take?

The planning and development work depends on the website’s size, platform, number of URLs and type of migration. A small brochure website may need a simpler process than an e-commerce store, school portal or NGO website with many programme pages. Monitoring should continue after launch because crawling and indexing do not happen all at once.

Can a website migration cause temporary ranking changes?

Yes. Search engines may need to crawl redirects, process new URLs and reassess the website. Temporary movement is possible, but major or prolonged losses often indicate technical errors, missing redirects, content changes or tracking problems.

Are 301 redirects enough to protect SEO?

No. 301 redirects are important when URLs change, but they are only one part of SEO migration. The new site must also preserve useful content, internal links, canonical tags, indexability, performance, structured data and accurate analytics.

Should all old pages redirect to the homepage?

No. Each important old URL should redirect to the most relevant new page. If no useful replacement exists, a correct 404 or 410 response may be better than sending visitors to an unrelated homepage.

What should I do if the domain name is changing?

Prepare a complete old-to-new URL map, keep the old domain active, implement sitewide and page-level 301 redirects, verify both domains in Google Search Console and submit the new sitemap. Update important profiles, listings, social accounts, email signatures and external references where possible.

Can I redesign and change the URL structure at the same time?

You can, but the risk and testing effort are higher. If possible, make changes in controlled stages. If a single launch is necessary, document the current website thoroughly and test the redirect map, page content, technical settings and business journeys before release.

Where to Start

Begin by exporting the current sitemap, reviewing Google Search Console and analytics, and creating a complete list of important URLs. Then document the proposed new structure, map old URLs to new destinations, prepare 301 redirects and test the staging website before launch.

For a WordPress, Shopify, custom or e-commerce migration, include SEO checks in the development scope instead of treating them as a last-minute review. If you need help assessing the migration plan or implementation, talk to the Govindani Infotech team on WhatsApp; project scope and pricing are confirmed there, with applicable GST considered separately.