A rebuild loses rankings for four reasons, and all four are prepared beforehand. The inventory of addresses, the redirects that actually matter, the two weeks of watching, and the line below which you go back.
by Nadia Maar ·
The new site is faster, reads better on a phone and finally looks like the company. It has been live for three weeks. Visits arriving from search are a little over half what they were, and they are not climbing back.
At this point the sentence is always the same: «Google needs time to settle». It is true for the first ten to fifteen days and stops being true after that. Past that point what you are looking at is not settling: it is a list of addresses that no longer exist, and nobody wrote that list down before switching the old site off.
This piece is that list, and the three things to prepare alongside it. It is not a guide for people who rebuild sites: it is what is worth asking the people rebuilding yours, while there is still time to ask.
Search does not rank a site: it ranks pages, one at a time. Each has an address, and that address is what has accumulated everything else over the years — the links others pointed at it, the clicks it received, the history telling a search engine that this page answers that question.
A rebuild almost always changes the addresses, and almost never out of carelessness: the platform changes, the catalogue is reorganised, the language goes into the path. «/prodotti/scarpe-uomo» becomes «/it/catalogo/uomo/scarpe», and to a search engine that is not the same page moved: it is one page gone plus one new page with no history.
Four causes follow from this, and in practice it is always these four.
The last cause deserves its own paragraph. During development the staging site must be kept out of the search engines, and that is done with a disallow rule in robots.txt or a «noindex» header. Two lines. If on launch day one of the two reaches production — and it happens more often than it sounds, because staging is what gets copied — the site is formally asking to be removed from the index, and it is removed. It is not a fault: everything responds correctly, the site is perfect, and it simply disappears from the results. It takes ten seconds to check, on launch day itself, and nobody checks.
Before touching anything you need one list, and it is not the list of pages on the new site: it is the list of what the old site is bringing in right now. It has to be made while the old site is still running, because afterwards some of this cannot be recovered.
The last number is what changes the nature of the project. It is not about moving four thousand pages: it is about guaranteeing that thirty-eight addresses land exactly where they must, and that the six hundred and ten have a destination chosen by someone rather than by chance. That is a morning's work, and it replaces six weeks of anxiety.
A redirect tells whoever lands on the old address where that page went. Adding one is easy; adding one that actually works is where the traffic is lost. These are the six cases you meet every time — tap a row for the diagnosis.
| Today's address | Where it lands | Outcome |
|---|---|---|
| /prodotti/scarpe-uomo | /it/catalogo/uomo/scarpe | fine |
| /scarpe-uomo | /prodotti/scarpe-uomo → /it/catalogo/uomo/scarpe | chain |
| /listino-2024.pdf | /download | elsewhere |
| /blog/come-scegliere-un-avvitatore | — no destination — | lost |
| /promo-primavera | / | to the home |
| /chi-siamo | /it/azienda | fine |
The only case that needs no attention after launch. The old address answers with a permanent redirect, the destination answers with the real page, and the content genuinely is the equivalent: same category, same products. The signal built up over years passes through almost intact.
Every rebuild leaves its layer of redirects, and the new one is stacked on top of the old rather than replacing it. Technically it works: you do arrive. But every hop costs time for someone on a phone, and long chains are followed less consistently. The fix is rewriting the map from the original source to the final destination: one hop, always, even when it takes three to work out.
The redirect leads to a listing page instead of the file. To an automated check everything is fine: no errors, no red line in any report. To someone arriving from a search it is a page that does not contain what they were looking for, and they leave. This is the case nobody discovers, because it shows up nowhere except in the decline.
It was from 2021 and looked old. It was also the page with the most inbound links on the whole site, and the first door in for people who did not know the company yet. Dated content gets updated, not deleted: the address is the thing of value, the text inside can be rewritten in an afternoon.
Redirecting everything to the homepage is the automatic fallback of many migration plans, and it has roughly the same effect as doing nothing: it is read as «this page has no equivalent», which is exactly what you were trying to avoid. If there genuinely is no equivalent, saying so openly is more useful: it closes the matter instead of leaving it open for months.
The most common case and the least risky. It still goes in the map, because «obvious» and «done» are two different things, and the difference between them is always discovered after the old site has been switched off.
One rule holds the six cases together: one hop, to the page that answers the same question. Where that page does not exist, saying so beats faking it.
After a migration, search traffic falls. It nearly always does, even when everything was done properly: the engines have to work through the new addresses, and meanwhile some pages are temporarily out. The fall is not the problem. The problem is that without a band agreed BEFOREHAND, every single day becomes an argument — Monday you panic over an expected dip, Thursday you ignore a serious one because «we have been falling for a week now».
| % | |
|---|---|
| d1 | 88 |
| d2 | 84 |
| d3 | 80 |
| d4 | 79 |
| d5 | 74 |
| d6 | 68 |
| d7 | 66 |
| d8 | 79 |
| d9 | 83 |
| d10 | 86 |
| d11 | 88 |
| d12 | 90 |
| d13 | 93 |
| d14 | 96 |
First full day on the new site. A dip here says nothing yet: the engines have barely started. You only check that the site responds and that robots.txt and the headers are the production ones, not the staging ones.
Still inside the band, but the fall has not stopped. This is the day you stop waiting and check the sample: the thirty-eight addresses carrying the bulk, one by one, by hand. By hand because an automated tool tells you they respond, not that they respond with the right page.
Below the threshold. Here the rule written in advance says what to do and takes the argument out of the worst possible moment for arguing: you go through the redirect map looking for chains and wrong destinations. In this case it was twenty-two product pages all landing on the category instead of the product.
The bottom, and it arrives the day AFTER the fix. The twenty-two destinations had been corrected twenty-four hours earlier: time passes between the correction and the moment the engines see it, and that time looks a great deal like things getting worse.
The climb starts. This is the most useful thing to know in advance: someone expecting an immediate effect makes a second change on top of the first, and from then on nobody can tell which of the two worked.
Back inside the band. From here you stop looking every day and go back to looking every week: checking a fluctuating figure daily is the best way to take a wrong decision about noise.
The band's numbers are not universal: they depend on how much the structure changes, how many pages move, and how often the engines come round. You set them by looking at your own site's history, and you write them down before launch — not after, when any number looks justifiable.
The last question to ask whoever is rebuilding your site is the uncomfortable one: if after ten days the numbers have not come back, what do we do? It needs an answer written in advance, because after launch nobody is in the right state of mind to improvise one.
And it is worth saying right after explaining how to prepare for it. Past day ten, returning to the old site means a second migration carrying the same risks as the first, done in a hurry and with everyone tired. What the rollback plan actually buys is not the return: it is the calm to fix forward knowing a way out exists. In practice it gets used once in twenty times, and in the other nineteen it is the reason nobody made a rushed decision.
In the audit we run the second section's inventory on your domain: how many addresses you have, how many actually bring visits, how many have inbound links from outside, and which few carry the bulk. You end up holding the list to hand to whoever rebuilds your site — and it holds regardless of who that turns out to be, us included.
If the rebuild has already happened and traffic dropped, the same half hour works out which of the four causes applies to you: it usually shows up in the first twenty addresses checked by hand.
Technical SEO and AI search optimization
There is nearly always a dip, even when everything was done properly: the engines have to work through the new addresses and for a few days some pages are out. The difference between a prepared migration and an improvised one is not the dip, it is the recovery: the first is back to previous levels within three weeks, the second stays down for months because nobody went looking for the cause — addresses with no destination, redirects to the homepage, deleted pages.
It tells whoever lands on the old address that the page has moved permanently, and it exists to pass on the value built up over years. Sending them all to the homepage wipes that out: a search engine reads it as «this page has no equivalent», which is the same message as a deleted page, just with a step in between. The rule is one hop, to the page that answers the same question; where that page does not exist, saying so openly is more useful.
Two to three weeks for a normally sized site with the redirects in order. «It takes time» is a true answer for the first ten to fifteen days and stops being true after that: if traffic is still down on day twenty-one, nothing is settling, and it is worth checking by hand the twenty addresses that used to bring the most visits. In most cases the problem shows up right there.
Four things, all while the old site is still running: the inventory of addresses that currently bring visits, inbound links and enquiries; the redirect map, one by one, to the equivalent page; the drop considered normal and the threshold below which you act; and the rollback plan, with a date and a number written down. The check to run on launch day itself is that robots.txt and the headers are not the ones left over from staging.