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 goes wrong in a redesign.
None of these are exotic. They are the same handful of failures, over and over, and they all happen with so little noise that the drop is blamed on an algorithm update six weeks later.
URLs change with no redirect map
- A new CMS or architecture renames every URL
- Old URLs 404, taking their links and rankings
- Sitemap based maps miss the orphaned pages
The ranking copy gets tidied up
- Wordy pages cut down to fit the new layout
- The paragraph answering the query gets deleted
- Invisible to a redirect check, since the URL survives
The new template drops internal linking
- Contextual links swapped for a nav and card grid
- Deep pages crawled less, ranking worse
- Missed in design review, because it looks better
Canonicals and schema are rebuilt wrong
- Fresh head output, written without the old rules
- Self referencing canonicals become site wide pointers
- The entity graph 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
- What is there, not what the sitemap claims
- Status, canonical, title and links for every URL
- The baseline the new site is checked against
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, one hop, no chains
- Built from the crawl, not a sitemap or spreadsheet
- Catches orphaned pages that still hold links
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 not a plan. It is a hope.
Lock down staging
Authentication in front of it instead of 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.
Second thoughts
Sometimes a redesign is the wrong call.
The cheaper possibility
Your site might not need redesigning. It might need three pages fixed.
A lot of redesign enquiries start with a feeling, not 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 64, 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 need is usually the first useful conversation.
Visual refresh
Lowest risk
- Same templates, URLs and content structure
- New type, colour, spacing and imagery
- SEO risk near zero, if the page stays light
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
- URLs move and content gets remapped
- The redirect map becomes the key file
- Staged rollout, recorded benchmarks, tested rollback
- Ends badly when run 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 earns traffic you cannot afford to lose
- Designs ready for a custom WordPress theme
- Another team redesigning, SEO covered before launch
- A replatform, and the redirect map worries you
We are the wrong team if
- Brand identity, a logo or art direction
- Designer led mockups as the deliverable
- A large team for an immovable launch date
- Cheap and fast, whatever happens to 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, with no guesswork.
Canonicals
A canonical pointing at a redirect
- The bug a rebuilt template introduces
- DR 64 domain beaten by DR 16 to 32
- Two pages competing for one intent
- 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 served a day stale
- Purge gaps, unhooked deletions, dual URL forms
- Proved it was the cache by hitting origin
Rendering
Features that stay crawlable
- Geolocation search, server rendered for crawlers
- Locations added with no code change
- New templates are where content gets hidden
Infrastructure
Stopping the wrong fix
- Brute force on wp-login at 21,626 hits a day
- Around 46% of all origin requests
- Stopped at 0 in 15 minutes at the Cloudflare edge
- Server at 7.5% CPU, so no 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 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, so nothing needs retrofitting. 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. There is no 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 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, and we will be blunt about it. 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. It is not 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 price 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 needs to change, for example when two sections compete for the same intent or the taxonomy is wrong. Then the URLs move, but only with a redirect map built from a full crawl of what exists, because the sitemap is almost never complete.
What if the redesign goes wrong after launch?
There is a rollback path agreed before launch, and we test it before we need 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 on the live site, with no need to revert. 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.