Preparing a rebuild’s ranking handover
Rankings are not migrated on cutover day. They are prepared before the first line of the new site is written, because the decisions that settle them — address structure, the fate of pages that disappear, whether copy is carried over — are taken at scoping and become very expensive to revisit.
What actually carries your positions
Before discussing redirects, you need to know what is worth redirecting. Three inventories are enough, and they belong before the quote.
The first is the complete list of indexed addresses. You get it by crossing the current sitemap, the export of known pages from the search console, and the server logs over several months — the logs reveal the pages genuinely receiving search visits, including ones nobody remembers creating.
The second is the list of pages bringing visits, with the query bringing them. That list decides what must be carried over word for word rather than rewritten for editorial comfort. A product page ranking on a precise technical query has to keep that vocabulary, even if the new style guide prefers short sentences.
The third is the list of inbound links. A link pointing at a page that will disappear must be redirected, otherwise you lose both the page and the recommendation supporting it.
The mapping table, written before development
-
One row per old address
Column 1: the full old address. Column 2: the new one, or an explicit “deleted”. A row with no decision is a forgotten redirect, and a forgotten redirect is a lost page.
-
Handle categories and filters separately
Category pages and faceted navigation pages often carry most of a shop’s traffic. Their address structure almost always changes in a rebuild, and they are what hastily made tables leave out.
-
Decide the fate of discontinued products
A product that will not return redirects to its category, not to the home page. A replaced product redirects to its replacement. Redirecting everything to the home page is equivalent to deleting: search engines treat those redirects as non-existent pages.
-
Check for redirect chains
On a site that already changed once, an old address sometimes points to a second one, itself redirected. Every hop costs. Chains are replaced by a single redirect to the final destination.
-
Budget the quote line
Building, testing and deploying that table is work in its own right, proportional to the number of addresses. A rebuild quote without that line did not plan the work, it forgot it.
Six checks before going live
- The new site answers in staging on an address closed to crawlers, and that block is lifted on cutover day — not forgotten, which is the most frequent and most expensive accident.
- Redirects are permanent, not temporary: permanence is what passes the old address’s value to the new one.
- The new site’s canonical tags point at the final addresses, respecting the protocol and the presence or absence of the subdomain prefix.
- The sitemap is regenerated and no longer contains a single old address.
- Titles and descriptions of the pages that earned traffic have been carried over, not auto-generated by the theme.
- The new site is not slower than the old one on category pages, which receive most search visits.
Related pages
-
Migrating without losing rankings
The general migration method, beyond the rebuild case alone.
-
Keeping rankings through a PrestaShop migration
The specific case of a major version step and its friendly URLs.
-
Rankings lost after a rebuild
The remedial route, when cutover already happened with no redirect plan.
-
301 redirect
What a permanent redirect does exactly, and what it does not do.
Frequently asked questions
When in the project should redirects be handled?
Can we keep exactly the same addresses?
How long should redirects be kept?
Should copy be rewritten during a rebuild?
Should Google be told before cutover?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.