I protect your traffic during a website migration

Q: What if the new website is almost finished?

I can join later as well. First I find out which decisions can no longer reasonably be changed and where we can still lower the SEO risk. The closer the launch is, though, the less room there tends to be for fixes without moving the date.

Q: Is it worth dealing with SEO when the URLs barely change?

Yes. A migration can change templates, internal links, metadata, canonicals, JavaScript, structured data, navigation or the way indexing works, even when the addresses stay the same. Keeping the URLs is not enough on its own to make a migration safe.

Q: Can you handle a migration of several languages, countries or websites at once?

Yes. On international projects I deal with the individual domains, language versions and markets separately, and at the same time I check how they relate to each other. On large migrations it is a mistake to treat every country as one copy of the same website.

Q: What if the launch date moves during the project?

I adapt the checks to the current schedule. What matters is that I know about the change in time, so that we can move the testing and the control steps. Launching a website only because a date was once written in the calendar is a bad decision if serious SEO errors remain.

Q: Can you work directly with our developers?

Yes. I handle the technical requirements straight with the developers, answer their questions and, when needed, work in their ticketing system. You do not have to translate between SEO and development what anyone meant.

Q: What if the migration is already done and traffic has dropped?

Then it is no longer about preparing a migration but about focused diagnostics. I compare the state before and after the launch and look for where the URLs, indexing, redirects, content or technical setup changed. The sooner the cause is found, the sooner the losses can start to be repaired.

Q: Who decides whether the website is ready to launch?

The final decision is always yours. I clearly mark which findings are ordinary loose ends and which represent a real SEO risk. If I see a problem that can damage a large part of the website, I recommend postponing the launch instead of hiding the risk in a report.

If you are changing the platform, the domain, the URL structure or the whole website, I join before the launch. I prepare the migration plan, the specifications for the developers and the checks that help protect the important pages, the traffic and the revenue.

Discuss your migration How it works

What I prepare so that the migration does not threaten your SEO

Before the launch I decide which pages, URLs and SEO signals must not be lost during the migration. Development gets clear specifications and I then verify that the new website took over what worked on the original one.

I watch over all the pages and URLs

I map the whole website, its structure, templates, content and the current state of indexing. For every part I decide what changes during the migration, what has to stay as it is and where technical or SEO problems can appear.

I prepare precise redirects

I map the old URLs to the new ones and set the rules for pages that change, merge or disappear. A bad redirect can throw away years of built visibility in moments.

A check of the website before launch

I check the staging environment, indexing, canonicals, internal links, metadata, structured data and other technical elements. Errors are cheaper to fix before the launch than after a drop in traffic.

I watch over the launch itself

During the move I check whether the URLs, the redirects, the measurement and the important SEO elements behave according to the plan. If something does not match, we deal with it right away.

I verify that the website works

After the launch I run new crawls and follow Google Search Console, analytics, indexing and technical signals. For me a migration does not end with the launch of the website but with the verification that the move went correctly.

Migration oversight: Custom pricing The price follows the size of the website, the number of URLs, the extent of the changes and the complexity of the migration itself.
Scope of the cooperation: According to the type of migration A domain change needs a different scope than a move to a new CMS or a complete change of the website structure.
Preparation before launch: Normally within 7 days After the required access and inputs are handed over. For larger migrations I set the date individually.
Check after launch: Part of the cooperation After the migration I go through the website, the redirects, the indexing and technical SEO again, to verify that the move went correctly.

What I protect and verify during a migration

During a migration I make sure the new website does not lose what the original one spent years building. Findability, traffic, the right URLs, the content relationships and the measurement. I judge every change by what it can do to performance after the launch.

The starting state of the whole website

Before the migration I record the state of the URLs, the traffic, the indexing, the links, the templates and other important SEO elements. That way we know exactly what has to survive the launch.

URLs and redirects

I review the mapping of old URLs to new ones, the merging and the retirement of pages. I also check chains, wrong destinations and other situations that can cause a loss of traffic or positions.

How the new website matches the old one

I compare the technical setup, metadata, canonicals, hreflang, structured data, status codes, robots.txt and sitemaps. I look for what changed or was lost during the move.

Structure, navigation and content

I check the hierarchy of the website, internal linking, the placement of important pages and changes in the content. A new website can look better and still be worse for search engines.

Measurement before and after the migration

I verify analytics, Google Search Console and the other measurement you need, so that after the launch we can compare the new website with the original one and spot a problem quickly.

The state after launch

I separate expected volatility from technical regressions and identify what needs to be fixed first.

A migration does not end with the launch of the new website

The biggest problems often do not appear during the move itself but after it. That is why I follow whether the new website correctly takes over the original URLs, indexing, measurement and other SEO signals, and whether something starts falling apart after the launch.

I check the changes against the original website

I compare the old and the new website and look for differences that can affect findability, content or the behaviour of important pages.

I verify what really changed after the launch

I follow the crawl, the indexing, the redirects, the measurement and the development of organic traffic. I do not only deal with what was supposed to be deployed but with what actually happened on the website.

I catch errors before they spread

When a problem appears in a template, in a redirect or in indexing, it can hit thousands of URLs at once. That is why after a migration I look for systemic errors, not just individual cases.

I close the migration only after stability is verified

I treat the launch as a checkpoint, not the end of the work. I consider the migration finished only at the moment it is clear that the new website works correctly and that no new SEO problems are appearing.

During a migration I watch over your SEO from the preparation to the launch of the website.

I connect the SEO requirements with the work of the developers, the content people and everyone else involved in the migration. I resolve the open questions, check the important changes and, after the launch, verify what actually happened on the new website. The goal is to prevent the errors that can cost traffic, revenue or enquiries, and to catch any problems as fast as possible.

When migration oversight is the right step

The service makes sense when you change the platform, the domain, the URL structure, the templates or the navigation, or when you merge several websites and markets. If you do not know yet what is holding your website back, start with an SEO audit. Individual technical problems without a migration are better handled through technical SEO.

SEO is cheapest to protect before the launch. After a migration you are usually already rescuing traffic, positions and revenue.

You need migration oversight when

You are changing the platform, the domain or the URL structure and you do not want to lose the positions you have built.
The redesign touches the templates, the navigation or the content of important pages.
You are merging several websites, language versions or markets into one solution.
Organic traffic and revenue are too important to you for the migration to be guarded only by a check on launch day.

A different SEO service fits better when

Not sure why organic traffic or positions dropped? Start with an SEO audit.
Dealing with technical errors on the current website without a planned migration? Technical SEO is the better fit.
The migration already happened and performance dropped? First it is necessary to find out exactly what went wrong during the move.
Want to keep developing SEO after the migration and handle further changes over time? Choose SEO management.

Planning a website migration? Get in touch in time.

Send me a link to your website and write briefly what is going to change and when you want to launch the new website. In a free one-hour consultation we go through the main risks and I will tell you what needs to be solved before the migration, so that traffic, positions and revenue do not suffer for no reason.

Book a free one-hour consultation

Questions about website migration

Practical answers before the pressure ahead of the launch narrows the room for changes.

What if the new website is almost finished?

Is it worth dealing with SEO when the URLs barely change?

Can you handle a migration of several languages, countries or websites at once?

What if the launch date moves during the project?

Can you work directly with our developers?

What if the migration is already done and traffic has dropped?

Who decides whether the website is ready to launch?