SEO website migration services, planned and built by one person
Most migrations are split between two companies. A developer builds the new site, an SEO agency checks it afterwards, and the redirects fall into the gap between them.
I do both. The person mapping your old URLs is the person writing the new routes, so what the old site earned in search comes across with it.
Most migrations lose their traffic between the developer and the SEO agency
The usual setup has two parties. The developer moves the site and an SEO agency audits it once it's up. The redirect map arrives as a spreadsheet the developer didn't write, and the problems arrive as a report after launch.
Here there's no second party. I write the redirect map, the routes and the templates, so a URL can't get lost between the person who planned it and the person who built it.
Redirects written by whoever writes the routes
I map every old URL while the new routes are being built. Nobody has to reverse-engineer the map from a crawl once the site is live.
Problems fixed before launch, not reported after it
An audit after go-live can only tell you what broke. Most of what it would find never gets built in the first place.
One person answers for the traffic
If something drops, nobody has to work out whether it was the build or the SEO. It's mine either way.
What a website migration is, and which kind you're planning
A website migration is any change big enough that Google has to relearn your site: a new platform, new URLs, a new domain or a new language. Most projects are two of these at once, and the risk sits in the combination.
Moving to a new platform
WordPress to Webflow, Framer to Next.js, a page builder to a headless CMS. The design can stay. The URLs, templates and content model usually change, and every one of those changes needs a redirect or a reason.
Changing your URL structure
Renaming sections or merging old blog categories. It looks like housekeeping and behaves like a migration, because a changed URL starts again from nothing unless something tells Google where it went.
Moving or merging domains
A rebrand onto a new domain, or two sites becoming one. The redirect map gets bigger, and the canonicals and the Search Console setup have to change with it.
Adding a second language
Language-prefixed URLs, hreflang and a canonical for each version. This site runs in English and Finnish, so I've done this one on my own traffic.
What an SEO website migration includes
Six things, in the order they happen. Skip one and a migration that looked fine on launch day can still turn into a traffic drop a few weeks later.
A baseline before anything moves
Impressions, clicks, positions and top pages exported from Search Console while the old site is still live. Without it, nobody can say what the migration did.
A redirect map, one row per URL
Every old URL points to its closest new equivalent with a permanent redirect. No chains, and nothing dumped on the homepage.
Internal links pointed at the new URLs
Links inside the site go straight to the new addresses, so visitors and crawlers aren't bounced through a redirect on every click.
Canonicals, hreflang and sitemaps that agree
One canonical per page, language versions that point at each other, and a sitemap that lists only the URLs you want indexed.
Analytics and Search Console carried over
Tracking moves with the templates. On launch day I verify the Search Console property and submit the new sitemap.
A 30-day read after launch
I compare the 404 report, crawl errors and impressions against the baseline, page by page, until the numbers settle.
What happened when I migrated this site
When I moved this site off Framer, the old blog lived at /articles/. I gave every one of those URLs a permanent redirect before launch.
Over the 28 days from July to August 2026, 27 percent of this site's impressions were still landing on the old URLs, about 860 of them. Google keeps old URLs in its index much longer than most people expect, which is why I treat redirects as permanent rather than something to tidy away after launch week.
In the next 28 days the move finished. My Next.js structure guide went from 155 impressions at an average position of 17.1 to 487 at 7.8, and the old URLs fell from 865 impressions to 89. I hadn't rewritten anything in between. Google had started honouring the redirects.
While writing about it I also found a two-hop chain in my own redirects, which is about the quietest way a migration can leak. The full write-up is in my post on keeping your rankings through a redesign.
How a website migration runs, from baseline to the 30-day read
Weekly sprints, with a staging link from the first week, so you can check the new URLs before Google does.
- I take the baseline and inventory every URL the old site has, along with what each one earns, then draft the redirect map against the new structure.
- Templates, content and internal links go onto staging, with canonicals, hreflang and tracking already in place when we launch.
- On launch day the redirects go live, and I submit the new sitemap and check Search Console before the day ends.
- For the next 30 days I compare the site against the baseline and fix what comes up.
A move that keeps the design usually takes two to three weeks. If the design changes too, it's a redesign with the migration built in, and my website redesign service covers that.
Before you move your site
These are the questions that decide whether a migration needs planning at all. If yours isn't here, ask on the call.
It's a migration where search visibility is planned for instead of checked afterwards. The old URLs get inventoried and redirected, internal links and canonicals get updated, tracking moves with the templates, and the result is measured against a baseline taken before launch. Without those steps, it's just a move.
Send me the site you want to move
Thirty minutes, and before we hang up you'll know what has to be redirected and about how long the move will take.