Planning a new website? How to cut the risk of losing rankings and enquiries in a redesign

A new site on Friday, silence on Monday

The scenario always plays out the same way. After years, a company changes its website. The design is finally modern, the photos sharp, the loading fast, the owner happy. Two weeks later they call to say the phone isn’t ringing and that the page people had been coming to from Google for years is returning a 404.

The design isn’t to blame. Three things done alongside it are: the page URLs got a new structure, the texts were shortened to fit the layout, and the noindex rule from the staging version stayed switched on in production.

A redesign is one of the few routine projects that can strip a company’s visibility overnight. It’s also one where the risk of loss can be cut substantially — as long as you know about it in advance. This article describes what to watch before you commission the work, what to test before launch, and what to track in the first weeks afterwards.

What a search engine actually sees in a redesign

New colours, a different typeface or a more modern template mean nothing fundamental to a search engine. The problem starts the moment the URLs, text, navigation, CMS or measurement change at the same time.

Then it’s no longer a new coat of paint on the same site. Google sees different pages at different URLs and has to work out again what the company offers. A page that spent a year building rankings for “accounting services Brno” disappears, and in its place comes a new URL nobody knows and nothing links to.

From the business owner’s point of view, a redesign therefore has three goals that come before looks:

• keep the findable pages and the content that brings people to them,
• get the visitor to the right service even after the URLs change,
• verify that the forms, click-to-call and enquiry measurement work.

Only then does it make sense to deal with animations and the shade of a button.

Before you commission a new site: make an inventory

First you need to know what works on the current site. Not what you like — what brings in people and enquiries. Those are two different things, and usually two different sets of pages.

Before the redesign, save from Search Console:

• the pages with the most clicks and impressions,
• the queries people arrive through,
• the indexing status and the errors found,
• the URLs Google knows about and reports as excluded,
• the submitted sitemaps.

Do the export sooner rather than later: the performance report holds data for the last 16 months and the window keeps moving. Six months from now, when you go looking for how a page performed before the migration, the data may already be gone. If you’re opening Search Console for the first time, the Search Console guide for business owners shows you around.

In analytics, list the landing pages and the recorded conversions — for a small company typically submitted forms and clicks on the phone number and the email address. And add what analytics can’t see: if people call after reading a particular service page, that page has commercial value even if no conversion is credited to it.

Then complete the list of URLs technically — from the CMS, from sitemap.xml or with a crawler such as Screaming Frog SEO Spider, whose free version crawls up to 500 URLs. Crawling on its own isn’t enough, though: it won’t reveal old URLs that nothing on the site links to any more but that another website still links to or that Google still knows. That’s why the technical list gets merged with data from Search Console.

The result should be a single table: the URL, its performance, and the decision about what happens to it on the new site.

What the new site has to take over

Not every sentence and not every subpage has to survive. But for everything that brings in people or helps produce an enquiry, there has to be a decision — not an accident.

For every important page, your supplier should be able to tell you why they’re keeping, changing or removing it. “There’s no room for it on the new site” is not an answer.

URLs and redirects: where it breaks most often

The safest thing is to leave established URLs alone. If a page works at /accounting-for-business/, there’s no reason to turn it into /services/bookkeeping/ just because that’s how the new menu structure came out.

Sometimes the change can’t be avoided, though — typically when moving to a different system. WordPress with dates in the URLs (/2021/03/article-name/) gets converted to a cleaner /blog/article-name/; Shopify forces the /products/ and /collections/ prefixes; moving to a modern frontend raises the question of whether URLs end with a trailing slash or not. In all of these cases the same rule applies: the old URL must return a permanent 301 redirect to a specific new page.

A redirect map should look like this — one line per old URL:

/old-service/            → /new-service/
/advice/old-article/     → /blog/updated-article/
/contact-us/             → /contact/

Four mistakes that get made over and over:

1. Everything to the homepage. The visitor doesn’t find what they clicked for and leaves. On top of that, a redirect to the homepage isn’t a replacement for a page that no longer exists, it’s a dead end.
2. Redirect chains. Old URL → interim URL → new one. Especially when the site is migrated a second time and the old map is left running alongside the new one. A redirect should lead straight to the final target.
3. A canonical tag instead of a redirect. rel="canonical" is a hint about duplication, not a move. It doesn’t deal with a removed page.
4. Old URLs blocked in robots.txt. If Google isn’t allowed to crawl the old URL, it will never learn that it leads somewhere else. The redirect is then useless.

If a page has no sensible replacement and its content no longer applies, it can end as a 404 or a 410. But make that decision only after checking the traffic, the links and the commercial value — not because it didn’t fit into the new navigation.

One more thing that gets confused: the Change of Address tool in Search Console is meant for a move to a different domain. It doesn’t cover a change of URL structure within the same domain — there, only redirects do the work.

Text: the quietest loss in the whole redesign

A redesign tends to be the excuse for replacing specific text with three airy marketing sentences. The site then looks better and stops answering the questions people were choosing you on.

For every service page, check that the new version still explains:

• who the service is for and what problem it solves,
• exactly what the customer gets,
• how the work proceeds,
• what affects the price and what range it falls in,
• what the customer has to supply,
• what the next step is.

When you shorten a page, throw out repetition and out-of-date passages — not concrete information just because it doesn’t fit the layout. The full structure of a page like that is covered in How to write a service page that brings in enquiries.

Sort older articles into four piles: move, update, merge, delete. How to decide is covered in Old articles: update or delete?. For a redesign only one thing matters — no page that gets traffic may disappear without a decision and without a redirect.

If the company doesn’t have the capacity to move and rewrite the text (and that’s the most common reason content gets skimped on), we can take this part over — from the list of what moves across to rewritten service pages.

What to test on the staging version

Protect the staging site with a password or an IP restriction. A rule in robots.txt is not protection — the URLs get out anyway, for instance through a link in an email or in analytics.

Before launch, go through at least this:

• the important old URLs return the right status code and point at the right target,
• internal links go straight to the new URLs, not through a redirect,
• no important page has noindex,
• canonical URLs point at the live domain, not the staging one,
• no links or images from the staging environment are left in the content,
• sitemap.xml contains only new, indexable URLs,
• every page has its own title, main heading and description,
• images load and have meaningful alt text,
• the mobile menu, buttons and forms work,
• the form really does arrive in the company inbox,
• measurement records form submissions and clicks on the phone number,
• a custom 404 page offers a route to the services and to the contact details.

With the form, don’t rely on a “Sent” message. Check the delivery, the sender, the subject, how the spam filter behaves and the confirmation to the customer. A redesign after which enquiries land in spam looks technically flawless and is the most expensive mistake possible. What a form should contain and what to cut from it is covered in An enquiry form people actually submit.

Launch and the first weeks

Schedule the launch for a time when both a developer and someone who can check the content, redirects and measurement are available. Friday afternoon before a holiday is a bad slot.

Immediately after going live:

1. Remove the protection and the noindex from the live site — and verify it in the source code, not in the admin. In WordPress the most common culprit is the ticked Discourage search engines from indexing this site in Settings → Reading.
2. Check robots.txt and sitemap.xml, and submit the sitemap in Search Console.
3. Go through the most important old URLs and their redirects.
4. Send a real test enquiry and confirm that it arrived.
5. Check that conversions are being measured.
6. Run a crawler over the site and look at the 200, 301 and 404 status codes.

Keep the old site and its database in a verified backup — one you can actually restore from, not a file nobody knows is complete.

Then keep watching, ideally on launch day, a few days later and regularly after that: a rise in 404 pages, URLs newly excluded from indexing, a drop in clicks on specific landing pages, the number of enquiries, and whether the staging domain has accidentally been indexed. Short-term fluctuation after a migration is normal. But don’t excuse a sharp drop on one specific page by saying “Google needs to get used to it” — check the redirects, indexability, content and internal links first.

What SEO oversight of a redesign should cost

The price should follow the number of URLs and the scale of the changes, not the number of design templates. A site with twenty pages and unchanged URLs is a different job from a site with hundreds of articles, a new system and a rebuilt structure. For a smaller company website, reckon on a few working days for the analysis, the map, the check of the staging version and the check after launch.

A quote should list separately: the export and evaluation of the current pages, the content migration plan, the redirect map, the check of the staging site, the measurement setup, and the post-launch check including fixes. A line item reading “SEO for the new website” with no list of deliverables is suspicious — and so is a promise that the redesign will preserve specific rankings. The risks can be managed; nobody can guarantee positions in the results.

Warning signs that nobody is going to keep an eye on the migration:

• content is only to be dealt with after the design is approved,
• nobody has asked for access to Search Console,
• old URLs will “somehow be redirected”,
• all removed pages are to point at the homepage,
• there’s no named person responsible for the check after launch,
• the original site is to be deleted without a verified backup,
• success is judged only by looks and speed.

If you don’t feel up to the oversight and your supplier doesn’t offer it, an initial analysis will produce the list of URLs and the decisions before the new site is even commissioned, and after launch it will check what actually made it across.

When traffic has already dropped after the redesign

Don’t start writing new articles. That’s the most common reaction and the most expensive mistake — new content gets poured into a broken path and goes down the same hole.

First compare the old and the new site. Reconstruct the list of original URLs from the sitemap, Search Console, analytics or a backup, check their status codes and match them to the new pages. Then check what survived of the text, the titles and the internal links. Add the missing 301s and submit the sitemap again — and if you need Google to reach the redirects faster, it can help to leave the old sitemap in Search Console for a while as well, so that it crawls the old URLs again.

If important text has disappeared, bring it back or work it into the new pages. And if the site has traffic but the enquiries aren’t coming, that’s not a migration problem but a problem with the path from page to contact — that’s the subject of Why your website isn’t producing enquiries even though you have traffic.

A redesign doesn’t end at launch. It ends the moment old URLs lead where they should, the text answers the same questions as before, and a test enquiry lands in the inbox. Until then it’s just a prettier website.