• Technical SEO

SEO support for site migration: moving the site without losing search traffic

SEO support for site migration is work around the move, not the move itself. We remove the "before" status, reconcile each old address with the new one, check the new site before the switch and manage it for the first 30 days after it. The volume of work is determined by two numbers: how many addresses the search engine knows and how many of them are actually duplicates. In the stores we measured, the second is four times larger than the first — and it makes no sense to carry this baggage to a new site.

See how it works
Price
after a free audit
Guarantee
30 days after project sign-off
What are we doing?
move-in preparation, compliance map, redirects, 30 days after launch
after a free audit
Price
30
Guarantee

days after project sign-off

move-in preparation, compliance map, redirects, 30 days after launch
What are we doing?
20-60
Period of support

working days, depends on the number of addresses

33,493
The largest map of the site in its own dimension

records for 8,690 unique addresses

3,971
A typical find before moving

sitemap entries for 590 addresses, all in one language

free site slice, 3-5 business days
Before the estimate
preservation of items — the issue is not managed by any contractor
What we do not promise

Free site cut before moving

Moving is the only job where the cost of a mistake is visible a month after launch, when it is already expensive to fix. Therefore, first we record the state "to": how many addresses, which of them are duplicates, with language versions, and speed figures. Without this picture, there will be nothing to compare the result.

What we measure

  • Complete list of addressesFrom the site map, indexing report and archival traces. This is the basis of the future compliance map.
  • Dubs in current conditionHow many entries per unique address. It makes no sense to take duplicates to a new site - close them properly when moving.
  • Language versionsHow many are there, are they all present in the site map, is the language marking correct. The second language is the most common loss when moving.
  • Speed ​​to moveFirst answer, full load, markup weight. To argue with numbers after launch, not with feelings.
  • Structured dataWhat types of markup does the site give now. They must be recreated on a new one, otherwise the issue will not change in your favor.
  • Analytics and rights in Search ConsoleWhether access is available or rights confirmed. Without Search Console, no one, including us, can see the real list of addresses in the index.
  • Payment and deliveryHow many ways are connected now. This list will have to be recreated, and it directly adds lines to the estimate.

What you get

  • Document with status "before": addresses, duplicates, languages, speed, markup, analytics.
  • Estimating the number of rows in the future match map is the main driver of the estimate.
  • A list of what not to bring to the new site.
  • Conversation for 40 minutes on the document.

Timeline: 3-5 working days

Why is it free

Because without these figures, both the estimate and the subsequent conversation about the result are kept at the word. The "before" picture remains with you in any case, even if we will not do the moving.

What's next

Next is a plan for the move with stages and dates, and a separate plan for the first 30 days after launch, when you can see if everything went as it should.

Short form: your contact and site URL

  • Contract, act and 30-day warranty

    Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.

  • Sole proprietor & bank transfer

    The contractor is a registered sole proprietor. Payment by invoice with closing documents.

  • Rights & access — yours

    Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.

  • Client portal instead of email chains

    During the project you get access to a portal: contracts, invoices, acts and project status in one place.

  • European clients

    Among our work — projects for Norway, Bulgaria, Moldova and Spain.

  • Verifiable numbers

    Every case in the portfolio comes with a link to a live site and a technical measurement.

  • Audit first, then pricing

    There is no price list on the site intentionally: the scope of the same work differs multiples between clients.

  • We say "no" when unsure

    If the task isn't ours or the deadline is unrealistic — we tell you upfront.

What affects the price

Why two seemingly identical tasks are priced differently

  • How many addresses does the search engine knowPrime factor. A match map is rows, and each row has to be checked by someone's eyes. The difference between a site with 590 addresses and a directory with 8,690 is a difference in weeks, not a percentage.
  • A share of doubles among themDuplicate solutions do not need to be made individually: they are combined into templates, and one rule is written on the template. But first these patterns must be discovered. In the measured garden tool catalog, there were 3.85 sitemap entries per address.
  • Does the domain change?The same domain — work only with addresses. The new domain adds rights confirmation, address change request, longer monitoring period and special attention to external links.
  • Number of language versionsEach branch multiplies the list of addresses and adds a markup check. Two languages ​​are not twice as much work, but plus a separate layer of reconciliation: are both branches in the sitemap, does the language of the document match the language of the addresses.
  • Who is collecting a new siteWhen a new site is made by another team, an agreement is added: the structure must be agreed before the layout, and the transition rules - before the switchover day. It is not technically more difficult, but it is longer in terms of calendar.
  • State of the output dataThere is access to Search Console and a live site map — the list of addresses is collected in a day. The old site is already disabled - the list is being restored from the archive, it is incomplete and long, and some of the addresses have to be written off.
Who it's for

Situations where this service delivers results

Scenario 1 of 4

You change the platform, the domain remains the same

The most common case and the most manageable. The driver is different, so the address looks different: in categories, in cards, in filter pages. The search engine knows the old look, and each such address must be replaced with a new one before the day of switching. The volume of this work is calculated not by the pages of the site, but by the lines in the correspondence map.

We'll review your situation in a free audit
What's included

Complete list of work and what you get as a result

  • Snapshot of the "before" status with the date of measurement: addresses, takes, language versions, the first server response, markup, analytics - so that in a month there will be something to compare with
  • Match Map: Each old address gets a specific new page, not the main page - an "all to main" redirect reads almost like a 404
  • Revision of the structure of the new site before switching: addresses, headers, canonical, site map - editing here costs hours, after launch, the same editing costs weeks
  • Permanent redirects without chains, implemented at the server level and verified by running the address list
  • Migration of structured data with validator checking - so that the snippet in the output does not change due to the markup that was forgotten to migrate
  • Language versions: hreflang markup, presence of both branches in the sitemap, coincidence of the language of the document with the language of addresses
  • Transferring analytics and rights to Search Console without breaking a series of data - otherwise "before and after" comparison becomes impossible
  • The old site map, left available for the transition period: the bot uses it to access old addresses and see redirects faster
  • Monitoring 30 days after launch: crawl errors, indexing of new addresses, redirect behavior, re-measurement of speed
  • Written report "before and after" with the same metrics that were taken at the start
  • A list of pages that will not be transferred to the new site is agreed in writing
When this service isn't right

What's not included — so there are no surprises at delivery

  • The development of a new site itself is a separate work and a separate estimate
  • Transfer of content and goods if there is no machine export
  • Guarantee of preservation of items: the issue is not managed by any contractor
  • Advertising that compensates for the traffic failure during the transition period
  • Continuation of the old domain and hosting: the bills remain on your side
Process steps

Transparent stages with approval at every step

Total duration:20–60 days

  1. A slice of the "before" state

    3-5 working days

    List of addresses from the site map, indexing report and archive. Counting doubles, composition of language branches, measurement of the first answer, inventory of markings and counters. Everything with a measurement date is a basis for comparison.

  2. Map of correspondence of addresses

    5-15 working days

    Each old address is merged with the new one. Separately - a list of what does not move: here we need your decision, because this is a business decision, not a technical one. Duplicates do not enter the map, they are closed when moving.

  3. Revision of the new site before switching

    3-8 working days

    We look at the new site through the eyes of a search engine while still on the test circuit: address view, canonical, headers, sitemap without duplicates, hreflang, structured data. Edits at this stage are the cheapest for the entire project.

  4. Switching and redirects

    1-2 working days

    Transition rules are implemented on the server, after which we run through the list of old addresses and look at the response code for each. Chains with two or more transitions are rewritten to a straight line. The old site map remains available.

  5. First 30 days after launch

    8-30 working days

    Scan errors, rate of indexing of new addresses, behavior of redirects, re-measurement of speed and markup. The work is distributed by month: most of the problems come out right here and are fixed cheaply.

Did not find your case?

Describe how it works on your side — we will tell you whether “SEO support for site migration” fits and what it means in your situation. No brief and no call: one question, one answer.

Cases

Tasks and results in numbers — all metrics measured by us

online store of professional tools, catalog of over 6,000 items

Task
Check in which state the site is suitable for structural changes.
Solution
Running the chain of transitions from the bare domain, traversing the site map with the calculation of unique addresses, comparing the language composition of the map with the default language.
Result
The sitemap was found only by a directive in robots.txt, lies on a non-standard path and takes 34.2 seconds to generate. It contains 25,537 records for 6,857 unique addresses: 6,486 product cards and 361 categories. All the addresses in the map are in one language, while the site defaults to another. Separately, a critical login defect was found: a secure root address gives a switch to an unsecured language version. Measured on 07/31/2026.

official online store of garden tools, catalog of about 8,600 cards

Task
Estimate how many rows the correspondence map will fill when changing the structure.
Solution
Touring the site map with a breakdown into category nodes and leaf pages, measuring the first response taking into account the login redirect, checking language branches.
Result
8,690 unique addresses — 81 category nodes and 8,609 leaf pages — with 33,493 entries in the 8.57 MB sitemap: 3.85 entries per address. The second language version is announced in the markup, but it was not included in the map at all. The first response is 789.4 ms, and these milliseconds include the transition to the language branch. Measured on 07/31/2026.

a brand of natural spices with its own online store

Task
Record the indexing status before working with the structure.
Solution
Counting entries and unique addresses in the site map, checking language marking, inventory of analytics counters.
Result
3,971 records for 590 unique addresses with a catalog of about 580 products. All 590 lead to the same language version, although the language of the document is declared different. The analytics are duplicated: a live counter next to the system turned off in 2023, plus a third-party counter, which is a separate reputational issue for the Ukrainian site. The first response is 428.4 ms with 264.1 KB of markup. Measured on 07/31/2026.
Technologies & integrations

What we build on and what it connects to

Stack

  • 301-redirect by nginx or .htaccess rules: one rule per address template. A rule that is too broad catches too much — that's why we check the sample with our hands
  • Table match map: row for each old address. It is not built automatically, decisions on disputes are made by a person
  • Screaming Frog crawls both sites and crawls the list. Does not see what is not in the sitemap or in the links
  • Search Console is the only source of the actual listing in the index. Data comes with a delay of several days
  • Wayback Machine - when the old site is already disabled. The archive is incomplete, some of the addresses cannot be restored
  • sitemap.xml: we leave the old one available for transition, we generate the new one without duplicates
  • hreflang — language versions; works only when both branches are actually in the site map
  • JSON-LD — we transfer the markup of what is on the page; markup non-existent carries the risk of sanctions, not an advantage

Integrations

  • Google Search Console
  • Bing Webmaster Tools
  • GA4
  • Google Tag Manager
  • Cloudflare
Separate relocation support against "the developers of the new site will do everything themselves"

How this option differs from the alternative

Where does the list of old addresses come from?from the sitemap, Search Console and archive - before the new site is assembled
Duplicates of the old siteappear as templates and close when moving
"before" shotmetrics are recorded with a date, there is something to compare with in a month
After launch day30 days monitoring of scanning and indexing errors
What we need from you

We can't start without this — best to prepare in advance

  1. Access to the current site, or at least to its site map — it starts the list of addresses.
  2. Access to Search Console for both old and new resources: no one, including us, can see the real listing in the index without it.
  3. The date of switching agreed in advance. Launching on Friday night is a special kind of risk: no one watches the first day.
  4. Access to the server of the new site or a person on your end who will implement the transition rules.
  5. One person with the right to make decisions about pages that will not be on the new site.
  6. A list of what changes consciously: merged categories, removed sections, new filter pages.

If something is missing — let us know, we'll help you gather it or do it as a separate task.

FAQ

Most frequently asked questions — with concrete answers

Is it possible to move at all without subsidence?

No. Who promises otherwise - either did not move, or did not measure the result. A short slump after a structure change is normal: the search engine needs time to go around the new addresses and see transitions from the old ones. The controlled part here is the depth and duration of this period. It is affected by the completeness of the match map, the absence of chains of two or three transitions, and whether the old site map remains available.

When to start - before or after the new site is put together?

To. The correspondence map is built on the structure of the new site, and if this structure has already been fixed without looking at the list of old addresses, part of the decisions will have to be redone together with the layout. The best moment is when the appearance of the new addresses is known, and the directory is not yet full. The worst is when the site has already been switched, and the question is formulated as "return the traffic".

What is lost most often when moving?

Second language version. In the three stores that we measured, the site map held only one branch out of the two announced: Ukrainian was included in the garden tools section, and all 590 addresses in the spices section were in Russian, while the language of the document was uk. Moving does not create such a thing, it inherits it and fixes it in a new place. Therefore, we check language branches before switching, and not after a complaint about missing traffic.

We are also changing the domain - what is added?

Confirmation of rights to a new resource, a request for a change of address, a longer transition period and special attention to external links: they lead to the old domain and work just as long as the redirects live. The set of works is the same, the observation tail is longer. And let's talk about payment right away: the old domain must remain renewed for at least a year, otherwise the transitions disappear with it.

How long to keep the old site up?

Our recommendation is at least 30 days after the switch, and the domain itself should be renewed for a year. At the same time, we leave the old site map available: the bot uses it to access old addresses and see transitions faster. When the old site is extinguished on the day of launch, there is nowhere to put redirects, and the list of addresses has to be restored from the archive - incomplete and for a long time.

How to understand whether the move was successful?

By comparing the same figures that were taken before it: the number of unique addresses in the site map, scanning errors, the first server response, the composition of structured data. Therefore, the first stage is a "before" picture with the date of measurement. Without it, the exchange of impressions remains after a month. There are no items in this list on purpose: they are not managed by any contractor, and it is unfair to include them in the acceptance criteria.

We have duplicates in the site map - should I transfer them too?

No, moving is the cheapest time to close them. In the garden tool store, we counted 33,493 records for 8,690 unique addresses, in the spice store - 3,971 records for 590 addresses. Duplicates do not receive a transition, a new sitemap is generated without them. The side effect should be known in advance: the number of pages in the index after cleaning drops for some time, and this is expected, not a deterioration.

Who implements redirects - you or our developers?

As is more convenient for you. We prepare the compliance map and rules, your team implements them on the server - or you give access and we implement. What does not change in any version: after implementation, we run through the entire list of old addresses and look at the response code for each one, and not selectively for ten. Chains are rewritten to a direct transition, because each extra link eats up part of the signal.

Send the address of the current site and the date on which the new one is planned to be launched.

In response, how many addresses will have to be redirected, how many of them are duplicates, what with language versions and a plan for stages with dates. If you have already moved, let's put it bluntly: then another job is needed - analysis of the consequences.

From measured casesThe sitemap was found only by a directive in robots.txt, lies on a non-standard path and takes 34.2 seconds to generate

View cases
  • Reply within 2 hours
  • No commitment
  • We work under a contract

There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.