How to migrate a website while preserving its search signals
Neaptide · October 17, 2026 · 6 min read
Plan URL mapping, redirects and release checks. Neaptide’s audit of six real redirects shows what a technical test can establish.
On this page

A website migration needs a verified map from existing URLs to relevant destinations, consistent signals on the destination pages and monitoring after release. Preserve the content and intent people already find useful. A successful redirect test confirms routing; search visibility must be measured separately over time.
What did our live redirect audit confirm?
On 9 October 2026, Neaptide tested six predefined public routes without a language prefix. All six returned one permanent HTTP 308 redirect to their corresponding English page, followed by HTTP 200. Each destination identified its own URL as canonical.
| Route tested | Observed destination | Result |
|---|---|---|
| /services/web | /en/services/web | One 308, then 200 |
| /services/seo | /en/services/seo | One 308, then 200 |
| /services/geo | /en/services/geo | One 308, then 200 |
| /services/ai | /en/services/ai | One 308, then 200 |
| /blog/saas-seo-agencies-comparison | /en/blog/saas-seo-agencies-comparison | One 308, then 200 |
| /blog/ai-search-prompt-research | /en/blog/ai-search-prompt-research | One 308, then 200 |
The sample was declared before collection. We made GET requests, recorded the redirect chain and saved the returned HTML. A separate check covered the same six page families in six languages: all 36 direct page URLs returned 200 with a matching self-canonical.
This is a current routing audit. It is not evidence of a completed domain migration, retained rankings or traffic growth. The six routes were selected from the site’s actual language-routing arrangement; they do not represent every historic URL the site may have had.
Method and observation records.
Which URLs should be included in a migration map?
A migration map should include existing URLs that have content, search visibility, backlinks or operational importance. Build the inventory from the current site, sitemaps, available search reports, analytics and server records. Keep the origin of each URL so the team can understand why it matters.
Assign each old address an intended outcome: retain it, move it to an equivalent page, consolidate it into a relevant replacement, or deliberately remove it. A redirect to the homepage is not an adequate substitute for deciding what happened to a specific piece of content.
For each destination, record the intended page purpose and language. A technically valid redirect can still take a visitor to an unrelated service or the wrong language. Acceptance therefore needs both an HTTP check and a content check.
What must work on the destination page?
The destination should return the intended content at its final URL and consistently identify that URL. Check the canonical, internal links, sitemap entry and language references together. Also inspect titles, main headings and the content that satisfied the old page’s search intent.
Google’s migration guidance recommends permanent server-side redirects, such as 301 or 308, and updating canonical, language and internal-link signals. It also recommends keeping redirects for at least a year in general. Google’s URL migration guidance.
Keep the release scope manageable. If the platform, URLs, content and commercial offer all change together, interpreting the cause of later changes becomes harder. Where several changes are necessary, record them explicitly rather than attributing the entire outcome to the new platform.
How should the migration be accepted before release?
Use four checks with recorded evidence:
- Mapping: every in-scope old URL has an approved destination or deliberate removal decision.
- Routing: the implemented redirect reaches the intended final URL without an avoidable chain or loop.
- Content: the destination contains the approved page, language and relevant information.
- Discovery: canonical, internal links, language references and sitemap agree with the intended destination.
Test the proposed setup before release wherever possible, then rerun the checks against production. A successful preview does not establish that the public domain uses the same configuration. Keep a recovery plan tied to the specific changes and identify who can act on it.
What should be monitored after the move?
Monitor availability, redirect behaviour and search performance as separate layers. A URL can be technically available before a search engine has processed the change. Google also notes that temporary ranking fluctuations can occur during a move; a routing pass cannot eliminate that uncertainty. Google’s migration guidance.
Compare search clicks and impressions for a defined set of pages and queries over appropriate periods. Annotate the release and other relevant changes. Keep business outcomes, such as received enquiries, alongside search metrics without assuming every movement has the same cause.
Neaptide’s SEO work can cover the inventory, destination map and release checks. The useful starting material is the actual URL list and available search history.