Rebuilding a website without losing its Google rankings

The most expensive moment in the life of a website is not when it is built. It is the week the new one replaces the old one. A site that has been online for years has earned something it never paid for directly: positions in Google for thousands of searches, built up one page at a time. A rebuild can throw that away in a weekend, and the business usually notices a month later, when the orders slow and nobody can say why.

It is almost never the design's fault. Google does not rank a website as a whole; it ranks addresses. Every product, category, article and page sits at a URL that Google has crawled, evaluated and placed. When the new site launches with new addresses and nothing connecting them to the old ones, those positions do not move across. As far as the search engine is concerned, the old pages have vanished and some new, unknown pages have appeared.

So the first rule of a rebuild is the least glamorous: before anything is designed, make a list of every address the old site has. Not the pages in the menu — every address. The sitemap is a start, but it is rarely complete. Search Console shows the pages that actually receive impressions. The server's logs show what is being requested. On older platforms, the same product often lives at two or three URLs at once, and all of them may have links pointing at them from elsewhere on the internet.

The second rule: keep what you can. If an address works and means something, the cheapest redirect is the one you never need. A new site does not have to change its URLs just because the platform changed. Where the old structure was sensible, the new one can reproduce it exactly, and nothing has to move.

The third rule: everything that does change gets a permanent redirect to the page that replaces it — a 301, page to page, not everything to the homepage. Sending every old URL to the front page is the most common shortcut in a migration, and Google treats it, reasonably, as if the old pages had simply gone. A product goes to the same product. A category goes to the same category. A product that is no longer sold goes to the category it belonged to, which is where a visitor looking for it would want to be anyway, rather than to an error page.

This is mapping work, and on a store it is large. When we moved Topharmakeio.gr off OpenCart, 3,175 search-friendly addresses were redirected to their new pages, plus every index.php link — the older form of address that OpenCart produces and that Google had also indexed. When we moved Rellas Jewellery, a Patras jeweller, from an older OpenCart where every product lived at an index.php URL, more than 1,600 old addresses were redirected so that the shop kept the positions it had earned. Neither list was written by hand. Both were generated from the old database, matched to the new one, and checked before launch.

The fourth rule is to test the redirects before the switch, not after. Take the full list of old addresses and request every one of them against the new site on its staging address. Each should answer with a single permanent redirect to a page that exists. Chains — an old address redirecting to another old address that then redirects again — waste crawl time and leak value. Loops break pages entirely. A redirect that lands on a 404 is worse than having no redirect at all, because it confirms to Google that the page is gone.

The fifth rule concerns what the new pages say about themselves. Each needs its own title and description, a canonical address that points to itself rather than to a staging domain, and structured data where it applies: Product on a product, Article on an article, the organisation on every page. The robots rules need checking too. A staging site is rightly closed to search engines, and a remarkable number of launches carry that block straight into production.

Then the launch day itself. Publish the new sitemap, submit it in Google Search Console and Bing Webmaster Tools, and notify search engines of the changed addresses. IndexNow, which Bing and several other engines support, lets a site tell them directly that a URL has changed instead of waiting for a crawler to find out. Google does not use IndexNow; for Google, the sitemap and Search Console remain the route. Keep the old domain and its redirects alive indefinitely if the domain itself changed — removing them after a few months undoes the work.

Expect some movement afterwards. Even a careful migration usually wobbles for a few weeks while search engines recrawl and re-evaluate the new pages, and anyone who promises no change at all is promising something they do not control. What a good migration prevents is the cliff: the permanent loss of positions that comes from pages that simply disappeared. Watch Search Console for the first weeks for addresses reporting 404, fix them as they appear, and compare the queries that brought traffic before and after.

There is a quiet upside, too. A rebuild is the moment to fix what the old site did badly: addresses with real words in them instead of index.php and a number, pages that arrive as finished HTML rather than being assembled by JavaScript, pages generated for the searches people actually make. Done carefully, the new site keeps what the old one earned and starts from a better place. Done carelessly, it starts from zero, with a better design that fewer people see.