Website Redesign
Services

A website redesign agency rebuilds a site that already has traffic, rankings, content, and customers depending on it, which is a different job from building one from nothing. The design is the visible part. The risk sits in everything being carried across.

The honest framing. A new site is a blank page with no obligations. A redesign inherits ten years of URLs, a content library with real search value, integrations the sales team relies on, and a set of habits inside the business. Most rebuilds that go wrong did not go wrong in design review. They went wrong in the handover between the old system and the new one.

The job is mostly inventory, mapping, and verification. Every address the old site answers on, every function the current platform performs, every integration with a credential attached, and every page carrying a link from somewhere else. None of that appears in a design review and all of it decides whether launch week is quiet. A rebuild that skipped it looks finished on the day and starts producing dead links, missing form submissions, and unexplained ranking drops in the second week.

Why clients bring the rebuild to us.

We plan the move before we design the pages. URLs, content, data, and integrations get inventoried and mapped at the start, so the design is made against what actually has to survive the move.

Search protection is a workstream and not a checklist item. Rankings are the asset a redesign most often destroys, so redirects, structure, and benchmarks are handled by the people who do technical SEO and not tacked onto a launch day.

300+ websites designed and launched. Enough rebuilds behind us to know which of the fifty small decisions in a migration are the three that matter.

Every change carries a reason. A redesign that only looks newer is expensive decoration. Layout, navigation, and form changes come out of what the current site's own analytics already show.

Fifteen years of web design experience behind that, and 250+ verified five-star reviews from the businesses on the other side of it. You can look through recent rebuilds and the team who runs them before anything gets scoped.

Five workstreams, run in a fixed order, because each one constrains the next. Skipping any of them is where the horror stories come from.

Website redesign audit. The current site measured against the competitors outranking it and the messaging winning the category. The output is a ranked list of priorities with the business case attached to each. It sets the scope of everything after it and holds its own value if the rebuild gets postponed a quarter.

UX overhaul. The information architecture, page layouts, and forms rebuilt against how visitors actually move through the current site. Every change has a stated reason and a number it is meant to move.

Replatforming. Treated as its own discipline, because changing systems carries risks a design change does not. Every function the current platform performs gets documented and given a confirmed home on the new stack before a move is scheduled.

SEO migration and setup. Every URL inventoried, every redirect mapped one to one, high-traffic page structures preserved unless the data argues otherwise, rankings benchmarked before launch and monitored daily after.

Content migration. An inventory instead of an export. Every page, post, and asset catalogued with its traffic, rankings, and conversions, then assigned a decision, with internal links rebuilt so nothing ends up stranded.

Why the order is fixed. The audit decides the scope, so it cannot come second. Architecture has to be settled before layouts, because a template drawn against the wrong structure gets drawn twice. The platform decision constrains what the build can do, so it lands before the build and not during it. And the content inventory has to exist before redirects can be mapped, since you cannot redirect an address nobody has found yet. Run out of sequence, each of those turns into rework somebody pays for.

Around those sit the parts most redesigns need anyway. Visual design and any identity work the rebuild exposes, accessibility brought to standard while the code is open, analytics rebuilt so the new site is comparable to the old one, and the development itself. Where a rebuild turns out to be a positioning problem wearing a design brief, we say that before the design phase and not during it.

Look at whether the problem is what the site looks like or what the site is built on, because those have very different price tags. Plenty of businesses arrive asking for a rebuild and leave with a smaller job.

Signals a refresh will do. The structure works and the pages convert reasonably, but the visuals have aged. The brand moved and the site did not, which is a design and copy exercise on top of a sound foundation. Two or three templates carry most of the traffic and they are the ones that look tired. Your team can edit the site without asking anybody for help. In those cases we would rather scope a targeted piece of design work than sell a rebuild.

Signals a full rebuild is the cheaper answer over three years. Every new page needs a developer. The platform is a version or two behind and updating it breaks layouts. Mobile behaviour gets patched instead of designed. Page speed problems trace to the theme and the plugin stack instead of to images. Your forms and your CRM are held together by something one person understands. Accessibility fails at a level that cannot be patched at the template layer. Or the content structure has no way to express what the business now sells, which is the one nobody notices until they try to add a service line.

Then there is the case that looks like a redesign and is not. If traffic is flat, the visitors who arrive convert fine, and nothing is broken, the problem is usually demand rather than design, and a rebuild will not create it. That is a content and search conversation. Equally, if the site performs and the objection is that leadership is bored of it, we will say so.

An audit settles the argument with evidence in a couple of weeks, and it costs a fraction of the rebuild it either justifies or prevents. Where the questions are mostly about how the current experience performs, a UX audit answers them on its own.

A focused rebuild of a mid-sized site runs eight to fourteen weeks. A large site with a platform change, real content volume, and multiple stakeholder groups runs four to seven months. Design is rarely the long pole.

Audit and discovery. Two to three weeks. A full crawl and technical review, analytics, competitor comparison, URL and content inventory, integration list, and the ranked priorities that scope the rest.

Architecture and UX. Two to four weeks. Sitemap, templates, key page structures, and forms, signed off before any visual design starts.

Visual design. Three to five weeks, running on the template set instead of on individual pages, which is what keeps a large site from turning into a hundred bespoke layouts.

Build and migration. Four to eight weeks, overlapping design. This is where content moves, redirects get written and tested, integrations get rebuilt, and the redirect map gets run against the live URL list before anybody talks about a launch date.

Launch and the weeks after. Cutover, then daily monitoring of crawl errors, redirect behaviour, rankings, and form submissions for the first month. That month is part of the project and not a separate line, because the problems a migration creates surface in the first three weeks or not at all.

What moves the number. Page count, and more precisely template count, since forty pages on six templates is a smaller job than fifteen pages on fifteen. Whether the platform changes. How much content needs rewriting instead of moving. The number of integrations, because a booking engine, an ERP feed, or a custom quote tool each carry their own scope. Language versions. Accessibility, since WCAG 2.1 AA is the standard most accessibility rules now point at, and bringing a site up to it from a long way below is remediation work with its own hours attached and not a check at the end. And how many people have approval, which is the most reliable predictor of a timeline slipping.

Two things worth knowing before you budget. Content is the most common cause of delay by a wide margin, so if copy is coming from your side, that schedule is the real schedule. And a rebuild with no maintenance plan starts decaying in month four, which is why we scope where the site goes afterward as part of the engagement instead of leaving it as an afterthought.

A redesign is the single most common way a business loses organic traffic, and nearly every case traces to one of six mistakes. All six are preventable, and we treat them as a formal workstream instead of a launch-day checklist.

Where rankings actually go.

Redirects that were never mapped. Old URLs return 404s, or everything gets pointed at the homepage, which passes almost nothing and looks to a search engine like the pages stopped existing. Every URL gets a one-to-one destination, and chains get flattened so no redirect points at another redirect.

URLs nobody knew about. A sitemap does not contain your full inventory. We pull from the sitemap, the crawl, server logs, Search Console, analytics, and the backlink profile, because a page with external links pointing at it is worth protecting even if it gets no traffic.

Page structures rewritten for no reason. Titles, headings, and body content on pages that already rank get preserved unless the evidence says otherwise. Redesigning a page that works is a decision, and it needs to be made deliberately.

Staging settings left in place. A launch that ships with a noindex tag or a blocked robots file is the fastest catastrophic outcome available, and it happens to real companies every month. It is a specific line on the launch checklist and it gets verified after cutover, not before.

Technical regressions. Slower loading, layout shift, broken structured data, missing canonicals, and lost hreflang all cost visibility. We benchmark Core Web Vitals before and hold the rebuild to the thresholds, meaning largest contentful paint under two and a half seconds, interaction latency under two hundred milliseconds, and layout shift under a tenth.

Internal links that vanish. Navigation and body links carry signals, and a new site with a tidier menu often quietly orphans a hundred pages.

Now the honest part. Even a clean migration can show two to six weeks of fluctuation while search engines recrawl and reassess. We tell you that in advance, we benchmark rankings and traffic before launch so the comparison is real, and we monitor daily afterward. If something drops, the redirect map and the crawl data tell us why within hours. Where a site's visibility problems predate the rebuild, that is search work in its own right, and increasingly it also means checking what AI assistants say about the business, since those answers get assembled from sources a rebuild does not touch.

The platform question gets answered by who edits the site and what it has to connect to, not by which system is fashionable. Answer those two honestly and the shortlist usually writes itself.

What we ask first. Who publishes, and how technical are they. How often does the site change. What has to integrate, meaning CRM, marketing automation, booking, inventory, ERP, payment. Are there language versions. Does anything about the business require self-hosting or a specific data location. And what is the appetite for maintenance, since some stacks trade lower build cost for permanent upkeep.

Then the shortlist. Webflow suits marketing sites where a non-technical team publishes often and design control matters. WordPress suits large content libraries, complex editorial roles, and cases where a specific plugin ecosystem is doing real work, with the understanding that it needs actual maintenance. Shopify suits stores where checkout reliability outweighs layout freedom, and WooCommerce suits stores that need to sit inside an existing content site or handle unusual product logic. Headless setups solve real problems for a small number of businesses and create permanent developer dependency for everybody else, so we only recommend one when the requirement is genuinely there.

Replatforming itself is a documentation exercise before it is a build. We list every function the current platform performs, including the unglamorous ones. Form handling and where submissions go. Every integration and its authentication. Editor roles and permissions. Scheduled publishing, redirects already in place, gated content, search, and any custom field somebody built in 2019 that a landing page still reads from. Each item gets a confirmed home on the new stack before a move gets scheduled, because discovering a missing function during launch week is how launch weeks become launch months.

Two rules we hold to. Your team keeps every editing right it had, plus the ones the old platform never gave you. And you own the accounts, the code, and the domain, not us. Where a build needs custom functionality beyond what a platform offers, that is development work scoped separately so you can see what it costs.

Content moves on an inventory, and the inventory starts with what each page is worth. An export moves everything including the material that has been hurting you for years.

Every page, post, and asset gets catalogued with its organic traffic, ranking keywords, conversions, inbound links, and last meaningful update. Then each one gets one of four decisions.

Keep. It performs, so it moves with its URL, structure, headings, and metadata intact. The temptation to tidy the URL is where trouble starts, so keeping it is the default.

Improve. The topic earns attention and the page underdelivers. It moves and gets rewritten, usually the highest-return content work in a rebuild because the demand is already proven.

Consolidate. Four thin pages competing for the same query become one strong page, with the other three redirected into it. This is the single most common finding in a content audit of an older site and it usually lifts the survivor.

Retire. No traffic, no links, no conversions, no strategic purpose. It goes, and it gets redirected somewhere genuinely relevant instead of the homepage.

A typical mid-sized site with 400 pages ends up somewhere near half kept, a fifth improved, a fifth consolidated, and a tenth retired. Seeing that split is often the moment a leadership team realizes the rebuild is a content project with a design phase attached.

Two things get rebuilt alongside the pages. Internal links, since consolidating and retiring pages breaks the links pointing at them and a broken internal link structure quietly strands the pages you kept. And the media library, which on most older sites is carrying thousands of unused files and oversized images that have been slowing the site down for years.

There is also a freeze to plan for. Content edits pause for a short window during the move so the two versions do not diverge, and we schedule that window with your team instead of announcing it. Where the inventory shows the real problem is coverage rather than presentation, the finding routes into content strategy work after launch, and where the writing itself is the gap, we scope it honestly instead of moving weak pages across and calling it done.

The current site has been recording the answer the whole time, so a UX overhaul starts by reading it instead of guessing. Behavioural data from a site with traffic is more useful than any opinion in a workshop, including ours.

What we read before touching a layout. Where visitors enter, since a homepage-first assumption is wrong on most content sites. The paths they take and the ones we expected them to take. Where they scroll to and where they stop. Which pages carry high exits without completing anything. Form analytics, field by field, because abandonment usually concentrates in one or two questions. Site search queries, which are visitors typing what they could not find. Device splits, since a layout that works on desktop and fails on a mid-range phone is common and easy to miss. And where the sales team says people get confused, which is qualitative and still evidence.

Then every proposed change gets a reason and a metric attached. Shorter form because three fields drive most of the abandonment, expected to raise completion. Reworked service navigation because visitors are using site search to find pages that exist, expected to reduce that search volume. Restructured pricing page because the average visitor leaves before the answer appears, expected to lift depth and enquiries. A change with no metric attached is a preference, and preferences are fine as long as they are labelled as such.

Where the data runs out, we say so. A new page type with no history has no baseline, so it gets designed on established patterns and tested after launch. Where the stakes justify it we run UX research with real users before the build, which is faster than launching and learning. And on a site with enough traffic, some decisions are better settled by testing after launch than argued about in a review meeting.

The uncomfortable truth about before-and-after comparisons is that a redesign changes many variables at once, so attributing a lift to one change is usually dishonest. What we can do is instrument each change so the direction is visible, and be clear about which improvements are measurable and which are structural. A deeper diagnostic on the current experience is a UX audit, and it can run ahead of the rebuild or on its own.

The old site keeps running until the new one is proven, and the cutover is planned around your operating calendar instead of ours. What counts as disruption differs by business, so the sequence gets shaped around the constraint that actually matters.

A store cannot pause revenue. Product and category URLs get preserved, variants and reviews move with their pages, customer accounts and order history survive the transfer, and checkout gets tested as its own workstream because it is the one place a bug costs money by the hour. Launches get scheduled away from peak trading, which for most retailers rules out the fourth quarter entirely.

A clinic or practice cannot lose the pages patients search for. Location and service pages keep their URLs and structure, booking and intake flows get tested against real submissions before cutover, and anything the local search presence depends on gets verified after launch rather than assumed.

A B2B firm cannot break the URLs its proposals and sales decks cite. Those get inventoried specifically, including gated assets and anything linked from an email sequence or a document sent last year, since a dead link in a live proposal is a credibility problem more than a traffic one.

A lead-generation business cannot lose form submissions. Every form gets tested end to end into the CRM after launch, with a real submission watched through to the record, because a broken form is invisible from the outside and expensive in silence.

The mechanics that make cutover boring. A staging environment that mirrors production, locked so it cannot be indexed. The redirect map tested against the live URL list before launch and rerun immediately after. Time to live on DNS lowered ahead of the switch so propagation is quick. Certificates, caching, and CDN handled in advance and not during. A short content freeze. A rollback plan, which we have rarely needed and always have. And a launch window chosen when your team is available, which is not five o'clock on a Friday.

Where a rebuild is large enough, we ship in stages by section instead of all at once. It is slower and it reduces the blast radius, and for some businesses that trade is obviously correct. Which constraint governs the plan depends on the category, and we scope against the standards of your industry instead of a general template.

You own all of it, and your team should be able to run the site without calling us. A rebuild that leaves a business dependent on its agency for routine edits was built wrong.

Ownership, stated plainly. The domain, the hosting, the platform account, the code, the design files, and the analytics properties are yours and stay in your name. We work inside your accounts wherever possible so nothing needs untangling later. If you leave, nothing is held.

Editing rights. Every role the old platform gave you carries over, and usually more. Page building from a component library so new pages look right by default. Reusable sections. Editable metadata and structured data fields without touching code. Draft, review, and scheduled publishing. Permissions that let a marketing coordinator publish a blog post without being able to break a template, which is the distinction most CMS setups get wrong in one direction or the other.

Handover, which is where rebuilds get abandoned. Recorded walkthroughs of the site's actual components instead of generic platform tutorials. A written guide covering how to add each page type. Live training with the people who will use it. A defined support window after launch for the questions that only appear once real work starts.

Then aftercare, and there are three honest options. Your team runs it with the training and documentation and we are available when needed. We handle updates, backups, security, performance, and accessibility monitoring on a maintenance arrangement. Or the site becomes part of an ongoing program where design, search, and content improvements keep compounding after launch. Most clients start with the second and grow into the third.

What decays without a plan. Platform and plugin versions, page speed as pages get added, accessibility as new content arrives, and internal linking as the library grows. None of that requires a large retainer, but it does require somebody's name against it. If nobody in the business owns the site after launch, say that out loud during scoping so the arrangement gets built around it. And if what you really need is a wider view of where the site sits in the marketing picture, that is a consultation and not a rebuild.

Four things from your side, and one of them causes most of the delays in this industry. Being candid about capacity at kickoff is worth more than optimism.

What we need. Access, meaning the platform, hosting, DNS, analytics, Search Console, tag manager, and any integration credentials, gathered early because chasing a login from a former employee is a genuine schedule risk. Decisions, meaning a named person who can approve without a committee. Content, meaning copy, images, product information, and anything legal has to clear. And your subject expertise, because nobody outside the business can describe what it does as accurately as the people doing it.

Four things slow rebuilds down, in order of frequency.

1. Content, by a wide margin. A site cannot launch with placeholder text, and copy written by people who already have full-time jobs takes longer than anybody plans for. There are three ways out. We write it, you write it against a schedule with real dates, or the launch scope shrinks to what is actually ready. Choosing early is the difference between eleven weeks and five months.

1. Review by committee. Six people with equal veto produces a design that offends nobody and moves nothing. One decision-maker with named advisors is faster and produces better work.

1. Late scope. A new microsite, a second language, or an integration remembered in week nine costs more than the same thing scoped in week one, and we would rather price it honestly than absorb it and rush.

1. Legal and compliance review. In regulated categories this is real work with real timelines. It goes in the schedule at the start.

The version of this that goes well looks like a weekly working session, one person who can decide, a content plan with dates against it, and a launch target with a small buffer. Where the brand itself is unresolved and the rebuild keeps stalling on what to say, the honest answer is that it is a positioning problem and no amount of design review will settle it. That case sometimes points at a rebrand before a build, and we would rather tell you in week one.

By capturing the baseline before anything changes, because after launch it is too late to know what you had. Half the redesigns in the world cannot be evaluated for exactly that reason.

What gets recorded before cutover. Organic traffic and rankings by page, conversion rate by template and by device, form completion rates field by field, top entry pages and their behaviour, page speed and Core Web Vitals, revenue or enquiry volume by channel, and the analytics configuration itself so events are comparable across the move. That last one is quietly important. A rebuild that ships with a fresh analytics setup and no mapping to the old one produces a site nobody can measure against its predecessor, and the old data does not come back.

Then the reporting runs in windows, because different things move at different speeds.

The first two weeks are technical health. Crawl errors, redirect behaviour, indexation, broken links, form submissions landing correctly, and no unexpected drop in tracked events. Nothing here is about success. It is about confirming nothing is quietly broken.

Weeks two to six are stabilization. Rankings recover from migration fluctuation and page-level behaviour becomes readable. Engagement signals are usable in this window. Search performance is not settled yet, and we will not present it as if it is.

Months two and three are performance. Conversion rate against the recorded baseline, template by template. Organic visibility compared to the benchmark. Enquiry or revenue volume, with the seasonality and any paid spend changes noted alongside, since a rebuild that launched into a strong quarter can flatter itself easily.

Beyond that it becomes ordinary reporting, and the useful question stops being whether the redesign worked and becomes what to improve next. That is what the audit backlog is for, since a ranked list of priorities never gets fully built in one phase and the leftovers are usually the best return available in the following two quarters.

One thing we will not do is claim causation from a coincidence. If organic enquiries rise 40 percent in a quarter where the rebuild launched and a competitor exited the market, we say both. Reporting that only ever confirms our own work is not reporting. Where the next gains are clearly outside the site itself, we point at search and marketing work instead of proposing another build, and the fastest way to see how that has gone for other businesses is the case studies.