A website redesign gets judged three months after launch, when you look at whether quote requests went up or disappeared.
The risk concentrates at launch. That is when page addresses change, links stop working, and a site that ranked well can lose positions built over years. This step can be prepared, and it is the one most projects cut short.
In this article
The three projects the word redesign covers
The word covers three different projects, with different costs and different levels of risk. Confusing them is the first source of bad surprises, because a project that starts as a simple change of look sometimes grows along the way and ends as a full migration, with the risk and the cost that come with it.
The visual redesign
The structure of the site, the page addresses and the copy stay. The look changes: colors, typography, images, layout. It is the lightest project and the safest for your SEO, since nothing search engines have indexed moves.
The technical redesign
The work happens under the surface. New content management system, new hosting, an upgrade of the technology the site runs on. Pages often keep their addresses, but their code changes entirely. The risk moves to performance and to the functions the old system handled that the new one has to take over.
The structural redesign
The structure of the site gets rethought. Pages merge, others split, some disappear, addresses change. It is the project that brings the most value when done well, and the only one of the three that can cost you a large share of your organic traffic when it is not.
Most redesigns sold as visual end up structural, because rethinking pages always ends up moving some. Plan the budget and the timeline for a structural redesign. If yours stays visual, you will have room to spare.
Three projects under one word
The look changes
Colors, typography and layout move. The structure, the addresses and the copy stay in place.
The code changes
The addresses hold. Performance and functions need watching.
The structure changes
Addresses disappear, and that is where traffic gets lost.
In the order of the three types described above. The SEO risk comes from moving addresses.
The signals that justify a redesign
A site that looks dated is not necessarily a site to rebuild. The signals that count can be measured.
You are losing positions you used to hold
Your pages were sliding down the search results before a redesign even crossed your mind. If the cause is structural, page-by-page optimization will not fix it.
Visitors arrive and leave
Traffic is stable but the requests stopped coming. The problem sits in the journey: what a visitor understands in ten seconds, and what they are asked to do next.
You cannot change anything on your own
Every text edit goes through a developer. A site your team cannot make evolve degrades by standing still, whatever its quality at the start.
The technology behind it is no longer supported
Plugins abandoned by their authors, a language version your host will soon drop, a theme bought years ago with a license nobody holds. These situations expose the site to known vulnerabilities.
The site no longer says what you sell
Your offer changed, your customers too, and the site still describes the company from five years ago. It is the only signal on this list that justifies a structural redesign on its own.
When repairing beats rebuilding
A good share of the sites we are asked to rebuild do not need it. Saying so loses us mandates.
The problem sits on a few pages
If your homepage converts poorly while the rest of the site does its job, you have a homepage problem. Rebuilding forty pages to fix one is an expense nothing justifies.
The site is slow
Slowness almost always comes from the images, the hosting or plugins stepping on each other. Those are three measurable fixes, each far cheaper than a rebuild.
The content is thin
Pages of 400 words in a market where the ranking pages run 3,000 suffer from their content, and a new design will not fix that.
What changes the scale of the work
The gap between two redesigns comes down to how many pages need rebuilding, how much content needs rewriting and how much of the old site can be salvaged. A fifteen-page site whose content carries over and a sixty-page site that needs a full rebuild are two different jobs, and the difference shows in the initial audit.
A third option has been circulating for a few years, having the site produced by an automated tool. These AI-generated websites handle getting a basic presence online fast, and leave out the structure, the copy and everything that makes a site rank.
The right question is about the blocker: what exactly keeps this site from producing clients, and how much of what exists today is worth keeping. We start every website design mandate with that reading, because the answer says whether to rebuild everything or just repair.
What breaks during the migration
That leaves the case where the redesign is the right call. From here on, the whole job is protecting what your site has accumulated, and the first thing to know is what gets lost on the way.
Your current site holds an invisible asset: every one of its addresses is known to search engines, cited by other sites, listed in directories and saved in your clients’ bookmarks. That asset does not follow the new site on its own.
Addresses that disappear
A page that lived at /our-services/maintenance/ and moves to /services/maintenance/ is a new page in the eyes of search engines. The old one returns a 404, and everything it had accumulated stays behind with it.
Redirect chains
An old address redirects to another old address, which redirects to the new one. Every extra hop dilutes the signal and slows the load. A redirect must reach its destination in one step.
Orphan pages
The new structure forgets pages that existed. They stay online, nothing links to them anymore, and search engines gradually stop visiting them.
Internal links pointing at nothing
Your copy contains hand-written links to pages of the site. After the addresses change, those links lead elsewhere or nowhere. On a fifty-page site they often number in the hundreds.
Images and downloadable files
PDF documents, spec sheets and the images that ranked in image search have addresses too. A poorly mapped media migration wipes them out overnight.
Three possible endings for the same page
/our-services/maintenance/→404 page not foundlost/our-services/maintenance/→301 to /services/ then 301 to the final pagediluted/our-services/maintenance/→301 to /services/maintenance/keptOnly one of the three lines keeps what the page had accumulated. The other two get decided before launch.
These problems are avoided during preparation. Once the site is live, they surface late, when traffic has already dropped and the cause has to be hunted across a hundred pages.
Why your traffic does not come back the next day
Even with perfect redirects, organic traffic does not transfer instantly.
Search engines have to visit every old address to see that it redirects, then visit the new one, then decide to treat it as the replacement of the old. That decision takes time, because they come back at their own pace, page by page, and more often to your popular pages than to the rest.
During that period a site can behave in a confusing way: old addresses that no longer exist keep showing up in search results and keep sending visitors. That is the normal delay between the moment you change and the moment the index follows.
What organic traffic does after a launch
A sketch of the mechanism, with no scale and no data. The depth and the length of the dip depend on the size of the site and the quality of the redirects.
Count in months. The most visited pages come back first, because they are the ones search engines revisit most often, and the deeper pages follow. A well-redirected site returns to its level, then passes it if the redesign fixed real problems.
The weeks right after launch are no basis for judging the result. Corrective decisions taken too early, on a dip that was expected, often cause more damage than the migration itself.
Building the redirect map
The redirect map is a table matching every address of the old site to its destination on the new one.
Inventory before tearing down
The inventory draws on several sources, because none is complete on its own: the XML sitemap, the list of pages that get visits from search, a full crawl by an exploration tool, and the server logs for the addresses nobody links anymore but that still receive automated visits.
This inventory happens before the old site is dismantled. Once the server is replaced, some of those sources no longer exist.
One destination per address
Every old address gets a precise destination. When a page has no equivalent, pick the closest page by topic. Redirecting the whole site to the homepage cancels the point of the exercise, because a redirect to an unrelated page is treated like a page not found.
Keep the addresses that already work
A clear address that already ranks has no reason to change. Changing an address has a cost, and that cost must be paid back by a real gain: a more logical structure, a hierarchy that reflects today’s offer, readable addresses. Modernizing an address for its own sake is an expense with no return.
What to do with old blog posts
Posts carry over with their addresses when the blog structure stays, or with redirects when it changes. The ones that stopped getting visits years ago deserve an explicit decision: rewrite them, merge them or retire them. Carrying them over by default ships the problem to the new site.
One redirect per address
The destination must be the final address, the one that answers directly. If the new site adds a trailing slash at the end of its addresses, the map must already include it.
Test the map before launch
Every line gets checked: does the old address reach the right page, in one step, with the right response code. The test runs again on launch day, then a week later. It is the only way to confirm the redirects do what you expect of them.
What a redirect map that holds looks like
/old-page/ → /new-page/, one step, code 301good/old-page/ → /interim/ → /new-page/flatten it/old-page/ → / the homepagetreated as a 404The last two lines get fixed in the map before the site goes live.
This work belongs to SEO as much as to development: a redesign that succeeds technically but redirects poorly produces a prettier site that receives fewer visitors.
Planning a redesign
Redesign your website without losing your rankings
Twenty years of rebuilding and migrating websites. Tell us where you stand and what you want to keep.
A bilingual redesign has its own traps
A site serving an English-speaking and a French-speaking clientele doubles each of the problems above.
Each language needs its own addresses
An English page and its French version are two distinct pages, with two distinct addresses. Serving both languages at the same address keeps search engines from ranking either one properly.
Hreflang tags must survive the migration
These tags tell search engines which version to show to which visitor. They get lost easily during a change of system, because they often depend on a plugin that does not make the trip. A bilingual site without hreflang leaves the engines to choose on their own, and they choose wrong.
Your French-speaking customers search differently
Searches do not translate word for word. Your French-speaking customers do not type the literal translation of what your English-speaking customers type, and a French version traced over the English ranks for phrases nobody uses.
The redirect map is double
Each language has its old addresses and its new ones. A map that covers only one language leaves the other half of the site in error, and it is almost always the second language that gets forgotten.
One page that exists in two languages
English
/services/web-maintenance/Declares its French twin in hreflang en-CA.
French
/fr/entretien-site-web/Declares its English twin in hreflang fr-CA, and targets the phrase your French-speaking customers actually type.
Each version declares itself and declares the other. A declaration that only goes one way does not count.
What is specific to a WordPress redesign
After language, the platform. WordPress runs a large share of business websites, and a redesign on it raises questions the general guides skip.
The theme decides what you will be able to change
Many sites rest on a purchased theme that was heavily modified. Those modifications disappear at the theme’s first update, which explains why so many sites run outdated versions: updating them would break the site. A redesign is the right moment to get out of that dead end.
Plugins are a debt
A site a few years old easily accumulates dozens of them. Some no longer serve anything, others are no longer maintained by their author, a few do the same job twice. The plugin inventory is part of the initial audit, because each one is a potential entry point and a slowdown.
Page builders lock the content
Content built with a visual builder is stored in a format specific to that tool. Changing builders means rebuilding every page. It is the main reason a WordPress redesign sometimes costs more than building a site from scratch.
What carries over from an old site
The copy, the images, the blog posts and the product sheets transfer. The layout does not. A project planned on that basis holds no bad surprise in the middle of production.
After launch, WordPress maintenance determines whether the site stays in the state it was delivered in or starts accumulating lag again.
The steps in the order they count
Put end to end, everything above fits in seven steps. The order matters more than the list, because each step produces what the next one needs.
The order counts more than the list
What ranks, what converts, what is broken. It is the inventory of what needs protecting.
The structure of the pages gets decided from what people search for, before any mockup.
Written at the same time as the structure, with the inventory of the old site still at hand.
The copy is written before the design, so the design serves the message.
On a staging environment closed to search engines.
Forms, mobile display, speed, tags, sitemap, redirects.
The work continues through the weeks that follow.
The two highlighted steps are the ones that protect your SEO.
How long it takes depends mostly on two things, and neither is technical: how fast the content gets approved, and how many people must sign off at each step. Timelines almost always stretch on the approval side.
Most projects that go off the rails swapped steps 3 and 4 with step 5, and wrote the content to fill a design already approved.
What to measure around launch
Without a starting measure, there is no way to tell whether the new site does better than the old one.
Before launch
Export your positions on your main queries, the organic traffic per page and the number of requests received per month. Keep the full list of live addresses too. Once the old site is replaced, that data is gone.
Launch day
Check the redirects on the most visited addresses, whether search engines can reach the site, the XML sitemap and the forms. A tag blocking indexing, left over from staging, is the most frequent and the most costly mistake.
The following months
Watch the errors Google reports in Search Console, the newly indexed pages and how positions evolve on the queries exported before the switch. Always compare against the starting point exported before launch.
Before you launch your redesign
Most redesigns that disappoint failed at preparation, because nobody inventoried what was working before replacing it.
If you are considering a rebuild, start by knowing what your site brings you today: which pages get visits, on which searches, and which ones generate requests. We do that reading at the start of every mandate, and it regularly changes the scale of the project.
Our portfolio shows what the result looks like.
Your current website
Get it assessed before you replace it
Send us the address. You will get a reading of what already works and what deserves a rebuild.
