Website redesign
A website redesign is the most common way a business destroys its rankings.
Not because the new site looks worse. Because the URLs moved with no redirect map, the copy that was ranking got tidied away, and nobody measured the old site before it was gone. We do the technical SEO and the build, so the new site launches with the traffic the old one earned.
The risk
What actually goes wrong in a redesign.
None of these are exotic. They are the same handful of failures, over and over, and they all happen quietly enough that the drop is blamed on an algorithm update six weeks later.
URLs change with no redirect map
A new CMS or a new information architecture renames everything. The old URLs 404, the links pointing at them stop counting, and the rankings attached to those pages go with them. Where a map does exist it is usually generated from the sitemap, which never included the pages that were already orphaned.
The ranking copy gets tidied up
Someone decides the old pages are wordy and cuts them down to fit the new layout. The paragraph that was answering the query gets deleted because it looked untidy in the mockup. This one is brutal because it is invisible in a redirect check. The URL is fine, the page just does not say the thing any more.
The new template drops internal linking
Contextual links inside body content get replaced by a clean nav and a card grid. Deep pages lose the links that were feeding them, so they get crawled less and rank worse, and nothing in the design review flags it because visually the site looks better.
Canonicals and schema are rebuilt wrong
Or lost entirely. A fresh theme means fresh head output, and the canonical logic, hreflang and structured data get reimplemented by someone who did not know what the old rules were for. Self referencing canonicals become site wide pointers, and the entity graph either vanishes or duplicates itself.
The staging site gets indexed
Staging goes live to the world with a copy of every page on it, and either it competes with the real site or the noindex rule that was protecting it gets pushed to production on launch day. Both happen. The second one is worse.
Speed regresses and nobody benchmarked
The new design is heavier. Bigger hero images, more webfonts, a slider, an animation library. And because nothing was measured before launch, there is no evidence of what changed. You cannot prove a regression you never had a baseline for.
Before launch
The pre-launch work almost nobody does.
This is the part that makes a redesign safe, and it is the part that gets cut when the project runs late. It is not glamorous and it is not expensive relative to what it protects.
Crawl and benchmark the existing site
A full crawl of what is actually there, not what the sitemap claims. Every URL, its status, its canonical, its title, its word count, its internal links in and out. This becomes the reference you check the new site against, and without it you are guessing after launch.
Record current rankings and top pages
Positions for the terms that matter and the pages carrying the traffic, captured and dated before anything changes. If something drops later, this is the difference between knowing what broke and arguing about it.
Build the redirect map from crawl data
Old URL to new URL, one hop, no chains, built from the crawl rather than from a sitemap or a spreadsheet someone maintained by hand. Orphaned pages that still hold links get found here, and they are exactly the ones a sitemap based map misses.
Check parity on every template
Not every page, every template. Does the new product template output a canonical, a title, the schema, the breadcrumbs, the body copy that was ranking? One template checked properly covers a thousand pages. One template missed breaks a thousand pages.
Keep a rollback path
A working copy of the old site, database snapshots at a known point, and an agreed trigger for using them. Tested before launch, because a backup nobody has restored is a hope rather than a plan.
Lock down staging
Authentication in front of it rather than a robots rule, so it cannot be indexed and cannot be scraped. And a check on launch day that whatever was blocking staging did not travel to production with the rest of the code.
Honest advice
Sometimes a redesign is the wrong call.
Worth saying plainly
Your site might not need redesigning. It might need three pages fixed.
A lot of redesign enquiries start with a feeling rather than a problem. The site looks dated, a competitor launched something slicker, or the owner has been staring at the same homepage for four years. Those are real feelings, but they are not always a business case, and a full redesign puts every page you currently rank with at risk in exchange for them.
Very often the actual problem is narrower. Two pages competing for the same search, a service page with copy nobody would finish reading, a template that loads slowly on mobile, a form that does not convert. Those are fixable in days, on the existing site, with none of the migration risk.
On one project the assumption was that a page needed more links. It turned out the page one competitors sat at DR 16 to 32 against the client's DR 72, so authority was never the constraint. The fix was a canonical pointing at a redirect, two pages split apart by intent, the machine spun copy rewritten, and a 25 link block cut to 5 chosen links. Nothing was redesigned. Diagnosis first is cheaper than a rebuild, every time.
So on the first call we will tell you if we think you are about to spend a redesign budget on a content problem. That is a smaller job for us and a better outcome for you, and we would rather say it than take the brief.
Scope
Three different things people call a redesign.
The risk profile is completely different across these, and so is the price. Working out which one you actually need is usually the first useful conversation.
Visual refresh
Lowest risk
Same templates, same URLs, same content structure. New type, colour, spacing, imagery and components. Because nothing structural moves, the SEO risk is close to zero, and the main thing to watch is that the new assets do not make the site heavier than it was.
Template rebuild
Moderate risk
New theme, usually a custom Sage build, with page templates written from scratch. Content mostly stays, URLs mostly stay, but every bit of head output, schema and internal linking is being reimplemented. This is where parity checking earns its money.
Full replatform
Highest risk
New CMS or new information architecture. URLs move, content gets remapped, and the redirect map becomes the most important file in the project. Staged rollout, benchmarks recorded, rollback tested. This is the one that ends badly when it is treated as a design project.
If there is no existing site to protect, this page is not the one you want. See web design for new builds.
Fit
Read this before you enquire.
We are a good fit if
- The site already earns traffic and you cannot afford to lose it
- You have designs already, from an agency or an in-house designer, and need them built properly
- You are on WordPress and want a custom theme rather than a page builder
- The redesign is really about structure, speed and accessibility
- Someone else is doing the redesign and you want the SEO side covered before it launches
- You are replatforming and the redirect map worries you, which it should
We are the wrong team if
- What you want is a brand identity, a logo or art direction. We do not do that work, and the sites in our portfolio are built for structure and speed rather than art directed
- You want a designer to lead and produce mockups as a deliverable. Bring a designer, we will build to their work or sit alongside them
- You want to judge us on how the sites we built look rather than how they perform
- You need a large delivery team thrown at an immovable launch date. That is not how we work
- You want it cheap and fast and are relaxed about what happens to the rankings
To be direct about it: we are developers and technical SEOs, not visual designers. We are strongest when a redesign is about structure, performance, accessibility and not losing rankings. The look is better handled by a designer, and we are happy to work with one you bring.
After launch
What to watch, and when.
Launch day is the start of the risky period, not the end of it. Different things break on different timescales, so watching the wrong metric too early causes as much panic as watching nothing at all.
The first 48 hours
Server logs and status codes. Are the old URLs redirecting in one hop to the right places, is anything 404ing that used to earn traffic, is the robots file correct, is staging still blocked, are canonicals and schema present on every template. Errors here are cheap to fix and expensive to leave.
Watch hourly on day oneThe first two weeks
Indexation and crawl behaviour in Search Console. Pages moving from crawled to indexed, coverage errors appearing, impressions per page against the benchmark. Rankings wobble in this window and that is normal. What is not normal is whole templates dropping out of the index.
Check every couple of daysThe first quarter
Real recovery and real comparison. Rankings and traffic against the pre-launch benchmark, field Core Web Vitals data now that there is enough of it, and conversion rate, which is the only number that decides whether the redesign was worth doing.
Monthly reviewEvidence
Why we are the right people for the risky part.
We have no before and after redesign gallery to show you. What we do have is a record of finding the specific class of bug that redesigns create, on live sites, and proving the cause rather than guessing at it.
Canonicals
A canonical pointing at a redirect
Exactly the bug a rebuilt template introduces. A DR 72 domain was ranking for nothing on a page it should have owned, while page one sat at DR 16 to 32. Authority was never the issue. The canonical was, along with two pages competing for one intent and a 25 link block cut to 5.
Schema
An entity graph fighting itself
Schema loss is a classic redesign casualty. On one site we found a duplicate organisation entity, per item LocalBusiness markup, self serving review ratings and invalid FAQPage markup all live at once. Consolidated to one valid graph and closed the Search Console entity issue.
Diagnosis
Four causes behind one symptom
Pages stale for a day. Missing URLs in a purge list, a meta deletion path with no hook, a dual URL form for locations, and curated pages that query content rather than being archives, so no term based purge could reach them. We proved it was the cache not the file by hitting origin with a cache buster.
Rendering
Features that stay crawlable
A geolocation search tool built server rendered on purpose, so the content exists for a crawler that does not wait for JavaScript. It has a self maintaining geocoding layer, so new locations need no code change. New templates are where sites accidentally hide their content behind rendering.
Infrastructure
Stopping the wrong fix
A brute force attack on wp-login was running at 21,626 hits a day, around 46% of all origin requests. Stopped at 0 in 15 minutes at the Cloudflare edge. Just as usefully, we showed the server was at 7.5% CPU and the attack was not slowing the site, which stopped a pointless hosting upgrade.
Stack
What we build with
WordPress and PHP, custom Sage themes, bespoke templates, JavaScript, CSS and MySQL. WP-CLI, Git and SSH for the work itself. Cloudflare, Cloudways, Nginx, Apache, Redis and OPcache in front of it. Ahrefs and Search Console for the measurement either side of a launch.
How it runs
Benchmark, build, verify, watch.
Look at what you have
A free call and a look at the site. We tell you which of the three redesign types you actually need, or that you do not need one. If it goes ahead, the crawl and the benchmark happen before any design work does.
Reply within one working dayAgreed scope in writing
Templates, content that is moving, URL decisions, the redirect map approach, what is explicitly out of scope, and who is providing the design. Cost agreed before anything starts.
You approve before we buildBuild on locked staging
Custom theme and templates, mobile first CSS, image pipeline, accessibility remediation as we go rather than as a retrofit. Staging is behind authentication the whole time.
Logged as it is spentLaunch and monitor
Parity check on every template, redirects verified one hop, rollback tested. Then the 48 hour, two week and first quarter monitoring against the benchmark taken at the start.
Included, not an extraCost
What a website redesign costs.
We do not publish a redesign price, because anyone who does is either guessing or padding. Development is £90 to £100 an hour, technical SEO and strategy is £90 to £110, and mixed work is billed at a £95 blended rate. Minimum engagement is four hours.
Migration safety review
From £1,200
Someone else is doing the redesign and you want the SEO side protected. Crawl and benchmark, redirect map built from real data, template parity checklist, and a launch day check. The cheapest insurance in the project.
Full redesign
Quoted
Priced after we have seen the site, because the number depends on template count, how much content moves and whether the platform changes. Fixed scope and cost in writing before any work starts.
After the launch
Monthly
Optional. Ongoing technical ownership for the months after a redesign, when things are still settling. A set number of hours against a shared roadmap rather than an open ended retainer.
Time is logged as it is spent and the ledger is open to you, including anything scrapped or reverted. Full breakdown on the rates page.
FAQ
Questions clients actually ask
Will a redesign hurt my rankings?
It can, and it very often does. A redesign is probably the most common way a business loses its search traffic overnight. Not because the design is worse, but because the URLs moved, the copy that was ranking got tidied away, the internal links became a template, and the canonicals and schema were rebuilt from scratch by someone who did not know what the old ones were doing.
None of that is inevitable. It happens because the technical SEO work sits outside the design project, and nobody benchmarks the old site before it disappears. We do the benchmark, the redirect map and the parity check as part of the build, not as a separate invoice afterwards.
We will not promise you zero movement. Rankings wobble for a couple of weeks after any significant change while Google recrawls. What we will promise is that if something moves, we can tell you exactly what changed and undo it.
Are you designers? Can you do the branding as well?
No. This is worth being blunt about. We are developers and technical SEOs. We do not do brand identity, logos, art direction or Figma mockups as a service. We can show you sites we have designed and built, but that is design in the service of structure and speed rather than brand led art direction.
What we are good at is the part underneath. Structure, page templates built from scratch, mobile first responsive CSS, accessibility remediation, image pipelines, killing render blocking and FOUC, and making sure the site comes out of the redesign with its rankings intact.
So if you want a designer to lead the look, bring one. We will build to their designs, or work alongside them. If you already have designs sitting unbuilt, that is close to an ideal starting point for us.
How much does a website redesign cost?
We quote redesigns per project after seeing the site, because the honest answer depends on how many templates there are, how much of the content is moving, and whether the platform is changing. A five page brochure site and a 400 page site with a shop are not the same job.
For reference, development is £90 to £100 an hour and technical SEO and strategy is £90 to £110, or a £95 blended rate where the work mixes both. Minimum engagement is four hours. A pre-launch migration safety review, where the redesign is being built by someone else and you want the SEO side covered, starts from around £1,200.
Should I redesign my website at all?
Maybe not. A fair number of sites that come to us wanting a redesign have three pages with a problem and a homepage the owner has got bored of. Redesigning the whole thing is an expensive way to fix that, and it puts every page you currently rank with at risk for no reason.
We will tell you if we think that is your situation, on the first call, for free. Fixing three pages is a smaller job for us and a much better outcome for you.
Can you redesign the site without changing the URLs?
Usually yes, and it is normally the right call. If the current URL structure is sane, keeping it removes the single biggest source of risk in the whole project. Design and content can change completely on the same URL and Google handles it fine.
Sometimes the structure genuinely needs to change, for example when two sections compete for the same intent or the taxonomy is wrong. Then the URLs move deliberately, with a redirect map built from a full crawl of what actually exists rather than from the sitemap, which is almost never complete.
What if the redesign goes wrong after launch?
There is a rollback path agreed before launch, and we test it rather than assume it. That means a working copy of the old site kept available, database backups taken at a known point, and a clear decision on what would trigger reverting.
In practice most problems after a launch are small and specific, a template missing its canonical, a section that dropped out of the internal linking, a redirect chain nobody spotted. Those get fixed rather than reverted. But the rollback exists because the alternative is finding out in week three that you have no way back.
Keep reading
Related services
Book me
Thinking about a redesign?
Send us the URL and what is prompting it. We will tell you which kind of redesign you need, what it would put at risk, and whether fixing a few pages would get you there instead.