A migration cannot be done so that nothing at all changes in Google. Google itself writes that on a medium-sized site it takes weeks, and on a large one longer, before new addresses start showing instead of old ones, and that fluctuation in rankings is normal during reindexing (Google Search Central documentation on site moves with URL changes).
The question, then, is not whether something will move. It is how deep and how long that movement will be, and how you tell a normal course from a fault. This article describes the work that makes the difference between those two.
A URL map is built from four sources, because each one alone lies
A 1:1 map means that for every existing address on the old site there is one target address on the new one. Not a category, not the home page, one specific page.
The list of old addresses cannot be taken from one place. Each source sees a different part of the site and all four have to be merged:
- A crawl of the old site. Gives you what is linked from within the site. It will not see pages nothing links to any more, which Google still has in its index.
- Search Console, the Pages report. Gives you what Google actually knows, including addresses you forgot about.
- Analytics for the last 12 months. Gives you where people actually go, including seasonal pages you would not see in another period.
- Backlinks. Give you addresses that are valuable even if two people a year visit them. Those get redirected first.
The merged list is usually a third longer than the crawl, and the difference is made up of exactly those addresses whose loss only shows a month later.
Parameters, pagination and filters: three decisions, not three problems
This is where the 1:1 map stops applying, and that is fine as long as it is a decision.
Pagination (?page=2) redirects to the first page of the new listing. After a migration the second page of a category usually holds different goods, so redirecting to ?page=2 of the new site is a coincidence, not a match.
Filters and sorting (?barva=cerna&razeni=cena) redirect to the category without parameters, unless the new site has the same filters with the same values. Whether filters should have their own indexable addresses is a separate decision, made before the migration rather than during it.
Search and tracking parameters (?q=, ?utm_source=) are not redirected one by one. They are handled by a rule that drops the parameters and processes the rest of the address.
Redirect straight to the target, not through an intermediary
Googlebot will follow up to 10 hops in a chain, but Google explicitly recommends avoiding chains and redirecting straight to the final address.
This matters on a site that has already been through one migration: the old redirect from the previous move stacks with the new one and a chain appears without anyone intending it. So what is tested before launch is not that an address responds, but how many hops it took to respond.
Use a permanent redirect with status code 301 (or 308). A 302 says "I will be back", and Google behaves accordingly: it does not pass the signals the way you need.
Leave redirects in place for at least a year. Google says so directly, and it is cheap: a few hundred lines of configuration against the risk of finding out in ten months how many other sites linked to you.
A redirect map is an asset that has to be maintained
Here is what nobody expects: a redirect map decays on its own, even if nobody touches it.
In one migration whose map we went through there were 4,721 entries, and 49 of them pointed at a broken target. The breakdown by cause is more instructive than the number:
| Cause | Count | What happened |
|---|---|---|
| Target is a product draft | 25 | somebody withdrew the product |
| Target does not exist | 11 | somebody deleted the page |
| Target is an unpublished page | 3 | page awaiting approval |
| Redirect chain | 10 | a second redirect was added |
Not one of those causes arose during the migration. All of them arose after it, through ordinary day-to-day work: somebody retired a product, somebody renamed a category. That makes the redirect map a list to be checked regularly, not a file you upload once and forget.
What disappears in a migration is not addresses but text
Everybody looks at URLs. What is lost more often, and almost never checked, is page content.
Comparing an old site with a new one on a single project, we measured a 53 % drop in the amount of text across eight commercial pages, from 13,389 to 6,275 words, and 63 to 75 % on service pages. The main technical term the site had long targeted fell from 89 occurrences to 25.
The mechanism is banal, which is why it gets missed. The new site is built from blocks, cards and benefits in a grid. A parameter table, a summary of standards or a paragraph on what the method cannot do does not fit into a grid, so it is left aside during the move. The site's total volume may even grow, so the loss is invisible.
What follows in practice: before the migration, list the content that will not fit the new template and decide about it deliberately. Not from a drop three months later.
The Change of Address tool only applies to a domain change
Time gets wasted here regularly. The Change of Address tool in Search Console is used only when you move from one domain or subdomain to another, that is example.cz to example.com. It does not apply at all to a change of URL structure within the same domain, nor to a move from HTTP to HTTPS.
Submit the new sitemap to Search Console; the old one can be removed afterwards.
The first 30 days: what to watch and in what order
Not everything at once. Each week has a different question.
Launch day. Check a sample of addresses rather than the whole list: the ten most visited pages, the ten with the most backlinks, and ten at random from deep in the catalogue. For each, verify the status code and the number of hops.
Week one. The question is "does Google see the new site at all?". Watch the Page indexing report: the number of indexed new addresses rises and old addresses appear under Page with redirect. That is the correct state, not an error.
Weeks two and three. The question is "has anything disappeared entirely?". Compare the list of pages with clicks in Search Console before and after the migration. What matters is not positions but addresses that dropped out of the listing completely.
Week four. Only now does it make sense to look at click and impression totals. Not earlier, because Google has not finished reindexing and the number describes the process rather than the result.
What is a normal course and what is a fault
The difference shows in the shape, not in the size of the drop.
Normal course: impressions fall, the number of indexed old addresses declines, the number of new ones rises, old addresses answer 301 in a single hop. Sites return to their original scale gradually; with a larger catalogue it takes longer.
Fault: 404 errors accumulate in Search Console, the report shows Duplicate without user-selected canonical, or old addresses answer 200 instead of redirecting. The last case is the worst and at the same time the most common: the old site is still running and competing with itself.
What cannot be promised in advance: by how much and for how long. Anyone promising that is promising on Google's behalf. Instead of a promise we give you a map, a checklist and numbers you can verify the process with yourself.
Six questions for a migration supplier
They work on anyone, not just on us.
- How many sources do you build the list of old addresses from, and which?
- Who decides about parameters, pagination and filters, and when?
- How do you test the number of hops in a redirect, not just that it exists?
- How long will the redirects stay in place?
- Who checks the redirect map after launch, and how often?
- Who compares the content of old and new pages paragraph by paragraph?
A migration is not judged on launch day, nor a week later. It is judged after a month, and judged by comparing a list of addresses, not by how a graph feels.
You want the map before you decide to move
We can produce the URL map and a risk estimate before the platform decision is even made. We need access to Search Console, an export of addresses from the old site, and to know how much of the catalogue is staying.
What we build and what we migrate to is described on the e-shop development page. The speed of the new site we handle on the site audit and speed page - Core Web Vitals change after a migration, and it is one of the few things fully under your control.
Write to info@lamapixel.com or call +420 775 599 009.
