7 min read
How do you replace a website without losing your Google rankings?
This is the most expensive mistake in web projects, and it is rarely visible until too late. A new site goes live, it looks better, and three months later enquiries have halved. The reason is almost always the same: the URLs changed and nobody told Google.
What actually goes wrong
Google remembers every URL on your site and how well each one performed. When a page that lived at /thjonusta/bokun suddenly lives at /solutions/booking, that is a brand new page as far as Google is concerned. The old URL returns a 404, and all the history it built up over years starts again from zero.
It also happens when a site moves between platforms with nothing deliberately renamed, because many platforms silently add or remove a trailing slash, lowercase the path, or insert /blog/ where there was nothing before. Each of those small changes creates a new URL.
The URL map comes before the design
Before a single page is designed, there should be a list of every URL that exists today, how much traffic each one gets, and which URL takes it over on the new site. It is an ordinary two-column document, and it is the most important document in the whole project.
You get that list from Google Search Console and from your sitemap.xml. If whoever is building the site does not ask for that document, or does not know what you mean, that alone is reason enough to look elsewhere.
What has to come with it
URLs are the biggest part but not the only one. Page titles and descriptions, structured data, images at the same paths, and internal links all have to come across. Internal links are the ones most often forgotten: if the old site linked to thirty pages and the new one links to ten, twenty pages have lost the support that was holding them up.
When you are allowed to change a URL
You can, and sometimes you should. A URL that is meaningless or wrong deserves fixing. The rule is simple: every old URL must point at its new one with a permanent redirect, a 301. That carries the history across instead of losing it. A temporary redirect, a 302, does not, and that distinction is the most common technical mistake in a migration.
Those redirects should live on indefinitely. They cost nothing to keep, and they keep delivering traffic from links somebody pointed at your site seven years ago.
How you verify it worked
Take a copy of your Search Console numbers the week before the new site goes live: impressions, clicks and average position. Compare four weeks later. A small dip in the first fortnight is normal while Google re-crawls. A sustained drop is not, and it should be traceable straight to a URL that was missed.
Export your list of URLs from Search Console before anyone touches the site. If you do not have it when the project starts, you cannot prove afterwards what was lost.