A migration that keeps the addresses you earned
We move your website with direct 301 redirects, controlled indexing, analytics tests, sitemap checks and a complete post-launch read-back.
“I used to have 30 users per day, but suddenly on all my websites I have only 2 or 3, some have zero which is never seen.”
A question owners ask.
Why website migrations lose visibility
A migration changes more than the design. Page addresses can disappear, a service page can be replaced with broader copy that no longer answers the same question, and internal links, canonical tags, structured data and navigation can change at the same time. Missing redirects send visitors and crawlers to error pages, redirect chains force one old address through several stops, and sending every retired URL to the homepage removes the relationship between the old page and its closest replacement.
Staging copies create another risk when indexing controls fail, and tracking can fail while the visible site looks healthy: changed form identifiers, removed tags or new booking steps can stop event recording, so a reporting drop is mistaken for a traffic drop.
The old-to-new address map
| Old address | New address | What happens |
|---|---|---|
| /back-pain-treatment | /services/back-and-neck-pain/ | One direct redirect |
| /sports-injury.html | /services/sports-injuries/ | One direct redirect |
| /our-team-2019 | /about/ | One direct redirect |
| /news/summer-hours-2021 | Retired, nothing replaces it | |
| /old-contact | /contact-us, then /contact/ | A chain, never built |
Every useful old URL is reviewed before the move, found through existing crawls, sitemaps, analytics, search data, internal links and known campaign destinations. Each maps directly to the closest relevant new destination, never a generic homepage, and a retired announcement or duplicate page is allowed to return an appropriate removal response rather than being redirected somewhere unrelated. The redirect file is prepared and tested before launch, so the map is a launch input, not a repair assembled after errors appear.
The launch, in three stages
Before
- BackupCreated or confirmed before production changes
- Staging blockedAccess and page-level controls, reviewed so they do not follow the site into production
- The map loaded and testedSample cases, query strings, old rules, conflicts and chains corrected
- Analytics and forms configuredDelivery, notifications, customer-record handoffs, calls and bookings
Launch
- Redirects live
- Canonicals to production
- Sitemap and robots reviewed
After
- Full crawlBroken links, missing pages, blocked resources, chains, sitemap conflicts
- Read-backEach old address reaches its recorded destination with the expected status, on the live server
- Events retestedA path that worked in staging can fail under the live domain
- MonitoringCrawl errors, indexing, events and performance through the agreed periodA person
How migration risk is communicated
A temporary visibility dip can occur after a migration. Rankings are not guaranteed before, during or after the move; the process reduces avoidable errors, but it cannot prevent every search-system reassessment. Observed changes are dated and reported, and if visibility changes, the review checks redirects, page intent, crawling, indexing, canonicals, internal links and known external changes before assigning a cause.
Correlation is not rewritten as certainty. A ranking change after launch may be related to the migration, a search update, a competitor, demand, or several factors. When the evidence does not establish the cause, the report says that it remains unknown, and monitoring continues through the agreed period.
What to fix first
Come with the project you already have in mind. Before we meet, we review your website, listings and other public-facing material. During the 30-minute session, you show us how the relevant part works today. We check whether the project addresses the real constraint and what it needs to connect to. You can hire us for one part.
Frequently asked questions
- Will changing website platforms hurt my SEO?
- Changing platforms can affect visibility, but a loss is not inevitable. Preserving useful content intent, mapping addresses directly, controlling indexing, and testing the live site reduce avoidable migration risk.
- Does every old URL need a 301 redirect?
- No. Useful pages with a relevant replacement should be mapped, while obsolete or duplicate pages without an honest destination may be retired with an appropriate response.
- How long can a migration-related ranking dip last?
- There is no reliable fixed duration for a migration-related dip. Monitoring should begin at launch and continue through the agreed period, with observed changes evaluated against crawling, indexing, redirects, content, and outside search changes.
- Should the staging website be indexed by Google?
- No, a staging website should not be available for normal search indexing. Access controls and indexing directives reduce discovery, and both staging and production controls must be checked during launch.
- How do you verify that a website migration worked?
- The migration is verified with a production crawl, redirect read-back, canonical and sitemap checks, indexing review, performance checks, and event tests. Forms, calls, and booking paths are tested where configured because technical availability alone does not confirm the customer handoff.
Primarily serves the Market Visibility and Offer Design pillars of the MOSAIC Six.