Answer in brief
A migration is a bookkeeping problem before it is a design problem. The inventory of URLs and the tested redirect map are what you are paying for, and a traffic drop is a separate product.
The list of URLs is the thing you are actually buying
Before a migration is a design decision or a hosting decision, it is a bookkeeping problem. Every site that has been running for more than a year or two has accumulated a set of addresses that search engines index, that other people link to, that old newsletters point at, and that one stubborn PDF in somebody's downloads folder still references. Almost nobody keeps that set written down anywhere. It grew one page at a time, and the person who created half of it has usually left the company.
An inventory is not the sitemap file. The sitemap is what the current system is willing to admit exists. The inventory is assembled from several sources at once: the sitemap, a full crawl of the live site, twelve months of server logs, the pages search engines report as known, the landing pages analytics actually recorded, and the addresses that external sites link to. Each source finds URLs the others miss, which is precisely why one source is never enough.
A useful inventory has columns rather than a single list. For each address you want the current response code, whether it is indexed, how many sessions and impressions it earned over the last year, how many external domains link to it, which canonical it declares, and which template rendered it. Those columns are what turn a wall of addresses into decisions a human can make in an afternoon instead of arguing about for a month.
This is why the inventory, and not the new theme, is the artefact worth paying for. Designs get replaced, frameworks get replaced, agencies get replaced. The inventory outlives all of them, because it describes your site as the outside world sees it rather than as your admin panel happens to organise it. Anyone who takes over the project a year later starts from a document instead of starting from a guess.
A redirect map is a two-column table with a decision in every row
A redirect map is, structurally, the least impressive document in the project: old address on the left, new address on the right, response code in a third column. That is all it is. The reason it takes real time is that every row is a judgement call, and a site with a few thousand addresses contains a few thousand small judgements that nobody has ever been asked to make explicitly before.
Rows come in three kinds. Some are one to one: the page exists on both sides and keeps its meaning. Some are merges, where several old pages collapse into one new page because the old separation no longer reflects the business. And some are retirements, where there is honestly no destination, and pretending otherwise only sends a visitor to a page that does not answer the question they arrived with. Wherever possible the first kind is expressed as a pattern rule, and only the exceptions are listed by hand.
The third column is not decoration. A permanent redirect tells search engines to transfer the address and forget the old one. A temporary redirect tells them to keep the old one and check back later. A gone response is an explicit statement that the page is finished, which is not the same as a not-found response, which is merely silence and could equally mean a server hiccup. Choosing between them row by row belongs to the map, not to the implementation.
The map's other property is that it can be tested before anybody sees the new site. You take every address in the inventory, run it against the staging redirect layer, and record what comes back. What you are looking for is loops, chains where one redirect lands on another, redirects that end on a not-found page, and rows that quietly send everything to the home page. A map that has not been run against the full inventory is a draft, not a map.
Planned loss and accidental loss draw the same line on the same chart
Some of the traffic you lose in a migration is traffic you decided to lose. Retiring a whole tier of thin tag pages, dropping a product line you no longer sell, removing a language you stopped supporting: all of those reduce sessions, and all of them were deliberate. The graph does not know that. Two weeks after launch, a planned reduction and a broken redirect produce exactly the same shape of decline in exactly the same report.
The only reliable way to tell them apart is to have written the planned part down beforehand. That is one more column in the inventory: not migrated, with a reason next to it. Fill it in before launch and the first week afterwards becomes arithmetic. You know what you expected to lose, you can see what you actually lost, and the gap between those two numbers is your bug list rather than a debate about whose fault it is.
Without that column, the conversation after launch degenerates predictably. Somebody says traffic is down, somebody else says most of that was intentional, neither can prove it, and the team spends a fortnight re-deriving decisions it already made once. Meanwhile the genuine breakage sits inside the noise, undetected, and stays there long enough to stop being a quick fix and start being a rebuild.
It also changes how you brief the people who will read the report. Announcing in advance that a defined slice of low-value traffic is being deliberately retired is a plan. Explaining the same thing three weeks after the numbers move is an excuse, and it sounds like one even when it is completely true. The column costs an hour to fill in and buys you exactly that difference in credibility.
Why WordPress-to-static sits in the migrations category rather than the rebuild one
The catalogue lists 'Moving from WordPress to static without losing SEO' under Migrations, marked Experienced, at $800 – $3 000 or 35 000 – 90 000 ₽, with a band of 20-40 hours. The description is explicit about what is promised: the same site, loading in half a second, no longer breaking when plugins update, no longer needing paid hosting, and with search positions preserved because all URLs and redirects are transferred one to one.
Read that last clause slowly, because it is where the hours go. WordPress produces whole families of addresses that the editor never consciously created: author archives, date archives, attachment pages, feed endpoints, comment pagination, and the full cross-product of categories and tags. Each family needs a rule in the redirect map, and deciding those rules is inventory work rather than front-end work. The visual layer is frequently the fastest part of the whole job.
You can do the obvious arithmetic on the published band yourself. Twenty to forty hours set against $800 – $3 000 implies a range, and the range is wide because the two ends of the band are different sites rather than different discounts. This is an example of reasoning any reader can perform on the catalogue's own published numbers, not a measurement taken from a particular project, and it should not be read as a rate card.
The other thing that consumes the band is behaviour rather than content. A WordPress site usually carries a handful of plugin-driven features: forms, search, comments, gated downloads, a members area. Each one needs an explicit decision to reproduce it, replace it with a hosted service, or retire it. Those decisions belong in the same inventory as the addresses, because several of those features own addresses of their own.
Leaving Tilda or Wix is an export problem before it is a coding problem
The catalogue's line here is 'Leaving Tilda/Wix for your own code', also filed under Migrations and also marked Experienced, at $500 – $1 500 or 25 000 – 70 000 ₽, with a band of 15-30 hours. The description is equally direct: the same site, without the monthly builder subscription, with full ownership of the code and without restrictions on functions, and it states that the savings on the subscription pay for the work in 6-12 months.
What makes this different from the WordPress case is that a builder does not hand you a list. It hands you a site. Addresses are produced by the platform's own routing, some pages exist in states that appear only inside the editor, and the export you can download is rarely the same set of pages the public actually reaches. The inventory has to be crawled from the outside rather than read from the inside, then checked against analytics and against search coverage.
The ownership clause matters more for the redirect map than it does for the code itself. On a builder, the URL scheme is a feature of somebody else's product; after the move it is yours, which means you can finally decide that products live under one prefix and articles under another, and then enforce it. That decision is exactly the merge-and-retire work described earlier, and it is cheapest to make once, during the move, rather than in a second migration later.
It is also worth noting what the two published bands say when you put them side by side. Leaving a builder is quoted at 15-30 hours and the WordPress move at 20-40, and both carry the same Experienced difficulty. The gap is not a verdict on which platform is nicer to work with. It reflects how many generated address families each one leaves behind for the map to absorb.
The month after launch is inside the migration price, not bolted onto it
The dedicated line for this is 'Site migration without loss of traffic', category Migration, marked Advanced, at $700 – $3 000 or 30 000 – 100 000 ₽. Its duration is stated unusually: 2–5 days of preparation plus a month of support. That second half is the part buyers most often try to remove from a quote, and it is the part that decides whether the first half was worth anything at all.
The preparation days are the inventory and the map. The month is where the map meets the internet. Crawlers rediscover the site at their own pace rather than yours, addresses surface that no source listed because a single external site links to them, and rules that were correct in staging behave differently once a CDN, a caching layer and a hosting-level redirect all sit in the same request path.
The description sets the standard plainly: all URLs matched, redirects valid and checked, and any losses visible on the first day rather than after a quarter. Visible on the first day is an operational requirement, not a promise. It means somebody is watching not-found responses in the logs, watching the redirect chains, and comparing traffic template by template instead of looking at one sitewide number that averages a disaster into invisibility.
Template-level comparison is the detail that makes the month useful rather than ceremonial. A flat sitewide figure hides one page type collapsing while another climbs, because the average swallows both movements and reports the result as calm. Because the inventory already records which template rendered each address, the same document that produced the map also produces the monitoring view at no extra cost, which is a strong argument for building it properly the first time.
A traffic-drop investigation runs the same evidence backwards
The fourth line is 'Traffic drop investigation and recovery plan', category Recovery, marked Advanced, priced at $500 – $2 500 for the diagnostics, with the Russian catalogue stating diagnostics at 25 000–70 000 ₽ and restoration work quoted as a separate project. The duration is 1–3 days for the diagnostics, with the work under the resulting plan handled separately from it.
The structural difference from a migration deserves saying out loud, because buyers routinely order one when they need the other. A migration begins with a known list of addresses and a date you chose yourself. An investigation begins with a curve on a chart and has to recover both of those: which addresses moved, and when the movement started. Everything a migration has as an input, an investigation has as an output.
The description names four candidates: an algorithm update, a technical error, lost pages, or clicks going to AI answers. They are separated by asking which slice of the site moved. A technical fault tends to have a sharp edge and stay inside one template. Lost pages appear as addresses vanishing from coverage. An update moves whole classes of queries regardless of template. Clicks migrating into AI answers change the relationship between how often you are shown and how often you are clicked. That is a method for reading evidence, not a statistic about how often each cause occurs.
The 1-3 day band is a scoping statement as much as a schedule. A diagnosis is supposed to end, and to end with a named cause, the evidence behind it, and an ordered plan with priorities. An investigation that runs for weeks without naming anything has stopped being a diagnosis and become a retainer, which is a different product carrying a different price.
Why the diagnosis is quoted separately from the repair
It looks like an upsell and it is the opposite. The catalogue prices the diagnostics on their own at $500 – $2 500 and states that recovery work is a separate project. The reason is simple: until the cause is named, the repair has no scope. Restoring pages that were deleted, rewriting content an update devalued, and fixing a server rule that started returning the wrong code are three unrelated jobs whose only common feature is the graph that led you to them.
The migration lines can be quoted in advance precisely because their scope is a known list. Someone can count the addresses, look at the templates and estimate the map before signing anything. A drop offers no such list on day zero. Anyone who quotes a fixed recovery price before the diagnosis is either padding heavily against the worst case or guessing, and both of those cost the buyer more than paying for one to three days of diagnostics first.
A diagnosis worth its price hands over four things: what changed, when it changed, which part of the site it changed, and what to do about it in an order where the cheapest reversible action comes first. If the first item on the plan is expensive and irreversible, the diagnosis has not finished. Ordering by risk rather than by ambition is what makes the plan executable by a small team with a normal week.
There is also the case where the diagnosis ends with an answer nobody wants to hear: the drop is real, explained, and not economically worth reversing. That is a legitimate outcome, and reaching it in three days is far cheaper than reaching it after three months of undirected work. It is also, incidentally, the case where the distinction between planned and accidental loss saves the most money.
Reconstructing an inventory afterwards costs more than keeping one
A large share of the work in investigating a post-migration drop is rebuilding the inventory that should have existed before the move. You are trying to establish what used to be there, which is a strictly harder question than what is there now, and you are answering it from partial sources after the original system has already been switched off and its hosting cancelled.
The reconstruction sources are all imperfect. Archived copies of the site are incomplete and undated at page level. Old sitemap files sometimes survive in version control, if anyone ever committed them. Analytics keeps landing pages only as far back as its export window allows. Search coverage reports age out. Each source gives you a fragment, the fragments disagree with each other, and reconciling them is exactly the work a pre-launch inventory would have made unnecessary.
The asymmetry is the whole argument. Building the inventory while the old site is still live is a task with a defined end: the sources exist, they can be queried, and the answer is checkable against a running system. Rebuilding it later is open-ended, because you can never be certain you have found the last address, and the addresses you fail to find are precisely the ones nobody is monitoring.
The practical version of this advice is unglamorous. Keep the inventory and the redirect rules in the same repository as the site, in a format a human can read, and update them whenever addresses change. It is a file, not a platform, and it costs nothing to carry. It survives redesigns, it survives handovers between agencies, and it is the difference between a two-day investigation and a three-week archaeology project run against a system that no longer exists.
Which of the four catalogue lines matches the situation you are in
If you own the CMS and the addresses, and the complaint is speed, plugin fragility or hosting cost, the relevant line is the WordPress move at $800 – $3 000 or 35 000 – 90 000 ₽, 20-40 hours, marked Experienced under Migrations. The addresses are already yours. The work is transferring them one to one and making sure the new build serves every one of them.
If a builder owns your routing and bills you every month, the line is leaving Tilda or Wix at $500 – $1 500 or 25 000 – 70 000 ₽, 15-30 hours, also Experienced under Migrations. The catalogue frames the outcome as full ownership of the code without restrictions on functions, with the savings on the subscription covering the cost of the work in 6-12 months.
If the change itself is the risk, a new domain, a new design or a different CMS on a site whose search traffic matters, the line is migration without loss of traffic at $700 – $3 000 or 30 000 – 100 000 ₽, marked Advanced, with 2–5 days of preparation plus a month of support. You are not buying construction here. You are buying the inventory, the verified map, and somebody watching the result while it settles.
And if the traffic has already gone, none of the three applies yet. That is the recovery line: $500 – $2 500 for diagnostics over 1–3 days, with the repair scoped afterwards as its own project. Ordering a migration to fix a drop rebuilds the site around a fault nobody has identified, and ordering a diagnosis for a move you have not made yet produces a report about a site that will not exist in that form much longer.
Questions and answers
What do I actually receive before the new site goes live?
Two documents and a test run. The inventory of every address the old site exposes, with traffic, external links and template recorded per row, and the redirect map that gives each of those addresses a destination and a response code. The catalogue's dedicated line, site migration without loss of traffic, states 2–5 days of preparation plus a month of support at $700 – $3 000, and the preparation days are where those two documents are produced and tested against staging.
How much does moving from WordPress to a static site cost, and how long does it take?
The catalogue prices it at $800 – $3 000, or 35 000 – 90 000 ₽, with a band of 20-40 hours, filed under Migrations at Experienced difficulty. The description commits to the same site loading in half a second, no breakage from plugin updates, no requirement for paid hosting, and preserved search positions because all URLs and redirects are transferred one to one rather than approximately.
Is leaving Tilda or Wix worth it if the site currently works fine?
The catalogue answers that in money: leaving Tilda or Wix for your own code is $500 – $1 500, or 25 000 – 70 000 ₽, at 15-30 hours, and the description states that the savings on the subscription pay for the work in 6-12 months. The non-financial half of the answer is ownership of the URL scheme, which is what lets you restructure addresses once instead of living permanently inside somebody else's routing.
My traffic dropped last month. Is that a migration job?
No, it is a diagnosis first. The recovery line is priced at $500 – $2 500 for diagnostics over 1–3 days, with restoration work quoted as a separate project, and it begins by separating the four candidate causes named in the description: an algorithm update, a technical error, lost pages, or clicks going to AI answers. Rebuilding the site before naming the cause simply moves the fault into the new build.