A WordPress redesign goes wrong in one of two ways. Either it becomes a visual exercise that changes how the site looks without touching why it was underperforming, or it launches cleanly and quietly destroys six years of search rankings because nobody mapped the old URLs to the new ones.
Both are avoidable, and the thing that avoids them is the same: a proper audit before anyone opens Figma. This guide walks the whole sequence, from working out what your current site actually does well through to launch day and the weeks after it. I have run this process on client sites for 14+ years, and the order below is the order that keeps projects out of trouble.
What a WordPress Redesign Actually Involves
A redesign is not repainting. It is a decision about four separate layers, and you can change any of them independently.
There is the visual layer, meaning typography, colour, spacing and imagery. The structural layer, meaning your navigation, page hierarchy and URLs. The content layer, meaning what each page actually says and whether it answers the question someone arrived with. And the technical layer, meaning the theme, the plugins, performance and how the site is built underneath.
Most people asking for a redesign are describing the visual layer and experiencing a problem in one of the other three. A site that looks dated but converts well has a different problem from one that looks beautiful and loads in six seconds. Working out which layer is actually failing is the entire point of the audit phase.
Refresh, Redesign or Rebuild?
These get used interchangeably and they are very different amounts of money.
| Refresh | Redesign | Rebuild | |
|---|---|---|---|
| What changes | Colours, fonts, imagery, some copy | Layouts, structure, templates, content | Everything, including the technical foundation |
| URLs | Unchanged | Often change | Usually change |
| Theme | Same theme, restyled | New or heavily modified | New, usually custom |
| SEO risk | Very low | Moderate, needs redirect planning | High without careful migration |
| Typical timeline | Days | Weeks | Weeks to months |
If your brand has changed but the site works, you want a refresh and you should resist being sold anything larger. If the site is slow, hard to edit and fighting you every time you add a page, no amount of restyling fixes that, and a rebuild is the honest answer.
Signs You Need a Redesign, and Signs You Don’t
Worth a redesign: your traffic is steady but conversions are not, your site is unusable on a phone, your team cannot add a page without asking a developer, your content no longer matches what the business sells, or the design predates your current brand by several years.
Not worth a redesign: you are bored of looking at it. That sounds flippant, but it is the single most common reason people start, and boredom is not a business case. Your visitors see the site once, not four hundred times.
Also not a redesign problem: thin traffic. If nobody is arriving, a prettier site gives you a prettier page nobody visits. That is a content and search visibility problem, and redesigning first just delays finding out.
Phase 1: Audit What You Already Have
You cannot improve what you have not measured, and you cannot safely replace what you have not inventoried. This phase is unglamorous and it is where redesigns are won.
Pull the traffic and ranking data first
Export your top pages by traffic from Analytics and your top queries from Search Console, covering at least the last twelve months so seasonal pages show up. These pages are now protected. Whatever happens to the design, those URLs keep working and that content does not quietly disappear.
This one export prevents the most expensive redesign mistake there is, which is deleting a page that was bringing in business because nobody on the project knew it existed.
Inventory every page
Build a spreadsheet of every URL on the site with its traffic, its purpose and a decision: keep, merge, rewrite or retire. A redesign is the best opportunity you will ever get to delete the twelve pages nobody has read since 2021, but delete them deliberately rather than by accident.
Audit your plugins and add-ons
List every active plugin and ask what each one does, whether anything still uses it, and when it was last updated. Most sites I audit are running somewhere between five and fifteen plugins that nothing depends on any more, each adding queries, scripts and update surface.
WordPress add-ons are where redesign scope quietly doubles. A plugin that was installed for one campaign in 2022 is still loading on every page. Carrying that forward into the new site means paying to maintain it for another three years. Decide now.
Measure speed honestly
Run your key templates through PageSpeed Insights and record the numbers before you change anything. Without a baseline you cannot tell whether the redesign helped, and “it feels faster” is not a metric. If the current site fails Core Web Vitals, write down which metric and by how much, because that becomes a requirement for the new build rather than a hope.
Phase 2: Set Goals You Can Measure
“Modern and professional” is not a goal, it is a mood. Goals a redesign can actually be judged against look like: increase enquiry form submissions, reduce bounce rate on service pages, cut mobile load time below two and a half seconds, or let the marketing team publish a case study without a developer.
Write down three. Agree how each is measured and what the current number is. If you skip this, the only available verdict at the end is whether people like the colours, and that conversation never ends well.
Phase 3: Map Structure and URLs Before Anyone Designs
This is the phase most projects skip, and the one that determines whether the redesign is safe.
Decide the new navigation and page hierarchy first. Then build a redirect map: a two-column sheet of every old URL and the new URL it should point to. Every page from your audit needs a destination, even if that destination is a parent category because the page is being retired.
Where you can keep a URL unchanged, keep it. Changing URLs for tidiness is a cost with no return. The best redirect is the one you did not need to write. When URLs genuinely must change, the principles are the same ones that apply to moving a site without losing SEO, and they are worth getting right once.
Phase 4: Choose How It Gets Built
This decision shapes your costs for years, not just this project. Broadly there are three routes.
A premium theme, configured and restyled. Cheapest and fastest, and genuinely fine for a straightforward brochure site. You inherit the theme’s assumptions and its page weight.
A WordPress page builder such as Elementor, Divi or Bricks. Your team gets drag-and-drop control, which is the main attraction, and the site carries builder overhead on every page. The thing to understand before committing is that builder content is often stored in builder-specific markup, so leaving later means rebuilding pages by hand. I have compared the main WordPress builders and, separately, builders against custom code.
A custom build, meaning a hand-coded theme with structured fields. Highest upfront cost, lowest page weight, and your content stays portable. This is the right answer when the site has real content structure or when performance is a business requirement rather than a preference. The full reasoning is in my guide to custom WordPress development.
One honest note: if your team’s main complaint is that they cannot edit anything, that is solvable in all three routes. It is a content-modelling decision, not a builder decision, and plenty of custom builds are easier to edit than builder sites because the fields are labelled and the layout cannot be broken.
Phase 5: Decide Who Does the Work
A redesign usually needs two different skill sets, and conflating them is how projects stall. Designers decide how it looks and how people move through it. Developers decide how it is built, how fast it loads and whether it survives a plugin update. Some people genuinely do both, but fewer than portfolios suggest, and it is worth reading the difference between a WordPress designer and a developer before you brief anyone.
The common patterns are: hire a designer and a developer separately and manage the handoff, hire an agency that covers both, or hire one specialist who handles the whole thing for a smaller site. If you already have finished designs from a previous project or an in-house designer, converting them into a pixel-accurate WordPress build is a well-defined piece of work that can be fixed-priced.
Phase 6: Design, Then Write the Content
Design around real content, never lorem ipsum. Every project that designs first and writes later ends up either stretching thin copy to fill a layout or cutting good copy to make it fit. Both produce worse pages than designing around what you actually need to say.
Get the templates agreed rather than every page: home, service page, blog post, landing page, contact. Sign those off, including their mobile states, before development starts. Approving layouts in design costs minutes. Changing them in code costs hours.
Phase 7: Build on Staging, Never on the Live Site
The new site gets built on a staging environment that is blocked from search engines and from the public. This is not optional and it is not a nicety. Rebuilding a live site in place means your customers watch you work, and a half-finished page is worse than an old one.
Staging also gives you the thing that makes launch day calm: the ability to test the complete site, with real content, before anyone outside the project sees it.
Phase 8: QA Before You Launch
Work through this on staging, not after going live.
- Every template on real devices, not just a narrowed browser window.
- Every form submits, and the notification actually arrives in the inbox it should.
- Speed tested against the baseline you recorded in Phase 1.
- Accessibility basics: keyboard navigation, contrast, alt text, heading order.
- The redirect map implemented and spot-checked, including a few deep pages nobody remembers.
- Analytics and Search Console tracking present on the new templates.
For the full pre-launch sweep I keep a separate advanced launch checklist that goes deeper on the technical side.
How to Redesign Without Losing Your Google Rankings
This deserves its own section because it is the single most expensive thing a redesign can get wrong, and it is entirely preventable.
Implement 301 redirects for every changed URL, pointing to the closest equivalent page rather than dumping everything on the homepage. A redirect to the homepage tells Google the old page is gone and its relevance evaporates.
Keep your title tags and meta descriptions on pages that were already ranking. Designers change page titles for visual balance all the time, not realising those titles are why the page ranks.
Make sure the new site is actually indexable at launch. The staging site was blocked from search engines, and the number of redesigns that go live still carrying that block is far higher than anyone admits. Check the robots settings and the noindex flags on launch day, before you celebrate.
Preserve your content. If a page ranks because it answers a question thoroughly, cutting it to three lines for visual elegance will cost you the ranking. Design around the content that earns traffic.
Finally, expect a short dip. Even a well-executed redesign often sees a few weeks of fluctuation while Google recrawls and reprocesses. Plan for it so nobody panics in week two and starts reverting things.
Phase 9: Launch, Then Measure
Launch when you can roll back. That means a full backup of the old site taken immediately before the switch, and a tested way to restore it. Avoid Friday afternoons for the obvious reason.
Immediately after going live, submit the updated sitemap in Search Console, crawl the new site to catch broken links and redirect chains, and confirm forms still work in the production environment rather than assuming staging behaviour carries over. My post-launch checklist covers the full sequence.
Then actually measure against the goals from Phase 2 at thirty and ninety days. A redesign nobody evaluates is a redesign nobody learns from, and the ninety-day number is the one that tells you whether it worked.
What a WordPress Redesign Costs and How Long It Takes
Cost tracks scope rather than page count. The things that move the number are how many distinct templates you need, whether content is being rewritten, whether the build is a theme, a builder or custom, and how much integration work sits behind the forms.
A focused redesign of a small business site is usually a matter of weeks. Add a full content rewrite, a migration, or integrations with a CRM and it extends. I have broken down realistic figures in what a WordPress website costs, and the same ranges apply to redesigns of comparable scope.
The two things that actually delay redesigns are not technical. They are content that has not been written and feedback rounds without a single decision-maker. If you want it to finish on time, sort those two out before the build starts.
Redesign Mistakes That Cost the Most
Skipping the audit, then discovering after launch that a retired page was responsible for a third of enquiries.
Redirecting everything to the homepage because the redirect map was built at 11pm on launch night.
Designing around placeholder text, then squeezing real content into layouts that were never sized for it.
Carrying every old plugin across because auditing them felt like a side quest, which means the new site inherits the old site’s weight on day one.
And launching without a rollback plan. Everything else on this list is recoverable in an afternoon. That one is not.
Where to Start
Start with the audit, even if you are certain you know what the problem is. Export your top pages and queries, list your plugins, record your current speed numbers. That half-day of work tells you whether you need a refresh, a redesign or a rebuild, and it protects the pages that are already earning you money.
If you would rather hand the whole thing over, that is what I do: WordPress redesign and custom build work with a fixed, itemised quote after a short discovery call, including the redirect mapping and the launch sequence rather than treating them as extras. If the current site is mainly slow rather than dated, speed optimisation is usually the cheaper fix, and I will tell you so.
Send me your current site and I will tell you honestly which of the three you actually need.
