What Actually Happens During a Full Website Redesign
Most clients hand over their old site and expect a shiny new one back within a fortnight. The reality is that the visible work, the new pages and the fresh layout, only accounts for a fraction of what a redesign actually involves. The stuff that takes longest is mostly invisible, crawling the existing site for problems, mapping content, untangling years of plugin debt, and making sure nothing that ranked before quietly disappears on launch day.
On this page
The Audit That Happens Before a Single Page Is Touched
Before any wireframe gets sketched or a colour palette gets chosen, the work starts somewhere far less visible.
The first thing to look at is what the existing site is doing, technically speaking. That means pulling a full crawl and going through redirect chains, 404 errors, and any pages that are indexing when they shouldn’t be. It means running Core Web Vitals baselines through PageSpeed Insights so there’s a real before-and-after to measure against, not a vague sense that the new build “feels faster”. It means checking the canonical tags, the sitemap, the robots.txt, and whether any pages that rank well have accumulated backlinks that would vanish if their URLs changed without proper handling. A redesign that wipes out six years of link equity because nobody mapped the old URLs to the new ones is a painful thing to unpick afterwards.
Analytics come next. Which pages bring in traffic? Which ones convert? Redesigns have a habit of deprioritising pages that look unimportant on the surface but do a lot of quiet work in search. Spotting those before the build starts means they get carried across properly, not rebuilt from scratch or, worse, dropped entirely. The audit isn’t glamorous work, but skipping it is almost always what turns a straightforward redesign into a six-month recovery job.
Why Content Takes Longer Than the Design
The design is rarely what slows a website redesign down. Nine times out of ten, it’s the content.
Before a single template gets chosen or a colour palette agreed, somebody needs to decide which pages are staying, which ones get cut, and what the surviving pages are meant to say. That sounds straightforward until you sit down and look at a site that’s been patched together over several years, where product descriptions were written by a supplier, half the team pages are out of date, and there are blog posts from years ago that nobody can remember writing. Sorting that out takes longer than most people budget for, and it can’t be rushed. A template built around placeholder text rarely survives contact with the real copy in one piece.
Images cause their own delays. Stock photos can be sourced quickly, but anything that needs to reflect the actual business, a real team, a real product, a real location, has to be photographed or commissioned. That alone can push a project back by weeks if it isn’t planned early.
The practical fix is to treat content as the first task, not something that follows the design. Map every page, decide its purpose, and have the copy drafted before templates are even mocked up. If you’re putting together a brief for the project, a well-structured brief is the right place to capture those content decisions before any design work starts.
Structure, URLs and the SEO You Cannot Afford to Break
A URL change without a redirect plan is one of the fastest ways a redesign wipes out years of organic ranking. Search engines have indexed your old pages, other websites link to them, and users have bookmarked them. The moment those URLs disappear and return a 404, every one of those signals vanishes.
A product page that has sat on page one for three years does not recover overnight. If the new site launches on a reworked URL structure and nobody has mapped the old paths to the new ones, that traffic is gone the day the site goes live.
This is why the redirect audit happens before a single page template gets built, not after. Every existing URL gets crawled and logged, then matched one-for-one against its new destination. Where the content is moving to a different path, a 301 redirect carries the ranking history across. Where a page is being removed entirely, the nearest equivalent gets found rather than leaving a dead end.
It sounds methodical because it is, and it takes considerably longer than most clients expect. The mapping work for a site with several hundred pages can run to a full day or more, but skipping it to save time is a shortcut that shows up immediately in Search Console as a spike in crawl errors. If you want to understand more about what proper SEO work involves, the detail is there.
What the Build Phase Looks Like Week by Week
Working in staging
Once the design is signed off, the work moves into a staging environment, a private copy of the site that sits completely separate from the live version. This is where plugin selection starts to matter. A contact form plugin, a caching layer, an SEO framework, sometimes a page builder, each one needs to be chosen carefully because they interact with each other in ways that only become obvious once content is loaded and real performance tests are run.
A staging build that looks fine on a blank page can start dragging the moment you add real images, real fonts, and a handful of third-party scripts. That’s the point where the less visible decisions about WordPress configuration tend to have the biggest impact on how the finished site performs.
Where timelines actually slip
Feedback rounds are where most timelines slip, and it’s not because revisions are difficult. It’s because every change to a layout or a colour scheme needs retesting across screen sizes and browsers before it can be called done. One tweak to a header can break the mobile menu. A font swap can shift spacing across six page templates. There’s no shortcut through that process. Each round takes the time it takes to do properly.
Pre-Launch Checks That Most People Skip
Going live is not the end of the project. It’s where a new round of checking begins.
Most people tick off a short list before hitting publish, does the homepage load, do the buttons work, does it look right on their laptop. What gets missed is the unglamorous layer underneath. Every form needs testing end to end, not just a visual inspection. A contact form that appears fine but silently fails on submission is invisible until a real enquiry disappears into nothing.
Mobile rendering needs checking across actual device sizes, not just a browser resize. Schema markup needs validating so search engines read the structured data correctly. Pagespeed scores on the live server can differ from a staging environment, sometimes meaningfully, because server configuration, caching rules, and image delivery all behave differently once real traffic is involved. Broken internal links and unresolved 404s from old URLs are easy to miss too, especially on a site that has been restructured. A run through what a proper SEO audit covers shows how many of these signals feed directly into how a site ranks after launch.
Treat the first two weeks post-launch as an active checking window, not a wind-down. Crawl the site again, recheck scores, watch for any redirect chains that crept in. The build was careful work. The launch deserves the same attention.
After Launch, the Work Is Not Over
What to watch in Search Console
The weeks after a redesign goes live are where a lot of projects unravel, and most clients never see it happening. Google needs time to recrawl the site, process any URL changes, and reassess what the pages are about. During that window, fluctuations in rankings are normal. Ignoring them is not. Search Console should be checked regularly for crawl errors, soft 404s, and any pages that have dropped out of the index unexpectedly.
A common failure here is a redirected URL that resolves correctly in a browser but returns the wrong status code to Googlebot, meaning the old page equity never gets passed through. You have to look at the raw data, not just assume the redirects are working because the site loads.
Index coverage and post-launch review
Index coverage reports often surface problems that the build process missed entirely. A noindex tag left on from the staging environment, or a robots.txt rule that is slightly too broad, can block whole sections of the site from being crawled without anyone noticing for weeks. If you are spending time and budget on a solid SEO foundation before launch, a proper post-launch review is how you protect that investment.
Most clients plan carefully for the build. Very few plan for what comes after it. That post-launch period is where the redesign either holds its ground in search or slowly loses what it spent months trying to earn.