Redesign when the platform still serves you and the problem is how the site looks, reads or converts. Rebuild when the platform itself blocks you: slow, hard to change, insecure, or unable to support what the business needs next. The choice matters because a rebuild carries SEO and data risks that a redesign mostly avoids.
Definitions
A redesign changes the visual layer and often the content structure while keeping the platform. Same WordPress, same CMS, same database, new theme and new copy.
A rebuild replaces the platform or stack. For example WordPress to Next.js, or a site builder to custom code. URLs, templates, hosting and often the editing experience all change.
Many projects are in between. A new theme plus a major plugin overhaul is a redesign with rebuild-sized risk. Name what actually changes, then judge the risk.
Business signals
Pointing toward a redesign:
- Brand has changed, or the site looks dated next to competitors.
- Messaging is unclear, but editors can still publish easily.
- Navigation and page structure confuse visitors.
- Conversion paths (forms, booking, contact) need rework, not new capabilities.
Pointing toward a rebuild:
- You need features the platform cannot do without fragile workarounds.
- Every change takes a developer for days.
- Adding a new product line, language or region requires copying pages by hand.
- The cost of plugin licences, patches and workarounds is rising each year.
Technical signals
Pointing toward a redesign:
- Pages are acceptably fast once images and scripts are cleaned up.
- The CMS content model is sound.
- Updates and security patches are applied on time.
- Developers can still work in the codebase.
Pointing toward a rebuild:
- Performance problems come from the architecture, such as heavy page builders or many stacked plugins, and cleanup does not fix them.
- Dependencies are abandoned or cannot be upgraded.
- No one can safely deploy changes, and there is no staging or version control.
- Accessibility, structured data or rendering issues are baked into the templates.
Checking performance first helps. See Core Web Vitals in Next.js for what to measure.
Decision framework
| Question | Redesign | Rebuild |
|---|---|---|
| Is the main problem visual or messaging? | Yes | No |
| Does the current platform support the next 2 to 3 years of plans? | Yes | No |
| Can editors publish without a developer? | Yes | Not today, and fixing it needs a new stack |
| Are URLs staying the same? | Usually | Often changing |
| SEO migration risk | Low to moderate | Moderate to high |
| Content freeze needed | Short | Longer |
| Cost and time | Lower | Higher |
| Fixes root technical causes | No | Yes |
If most answers fall in one column, that is your direction. If it is split, start with a redesign and plan the rebuild for a later phase, rather than doing both at once.
Risks to plan for
SEO migration
The biggest risk in a rebuild is losing search visibility through changed URLs, missing redirects and thinner content. Google's guidance for site moves with URL changes says to map old URLs to new ones, use server-side permanent redirects (301 or 308), and keep redirects for as long as possible, generally at least a year.
Three things to protect:
- URL changes. Keep URLs identical where you can. Where they must change, build a complete old-to-new map.
- Redirects. Test them in bulk before launch and after.
- Content parity. Titles, headings, body text, internal links, structured data and images should carry over unless you chose to remove them.
The full process for one common path is in WordPress to Next.js migration without losing SEO. Rendering choices also affect crawling: see JavaScript SEO and rendering.
Google also notes that for medium-sized sites it can take a few weeks or more for new URLs to replace old ones in results, and temporary fluctuations are normal. Do not judge the launch in the first week.
Content freeze
A rebuild needs a period when the old site's content stops changing, or you must copy edits twice. Agree a freeze date, or a process for logging edits made after the content snapshot. Redesigns need this too, but for less time.
Analytics continuity
Changing tools or tracking IDs breaks year-on-year comparison. Before launch:
- Record baseline traffic, top landing pages, conversions and rankings.
- Keep the same analytics property if possible, or note the change date.
- Re-implement every event and conversion, then test them on staging.
- Verify the old and new site in Search Console.
Other risks
Forms and integrations quietly breaking, email deliverability if DNS changes, and lost redirects from old marketing links. Put each on the launch checklist.
Practical steps
- Audit the current site: top pages by traffic, performance, content inventory, integrations.
- Write down the problem you are solving in one sentence. If it is not about the platform, redesign.
- Estimate the rebuild's migration work, not just the build.
- Decide what stays the same: URLs, content, analytics property.
- Launch on a quiet business week, with monitoring for the following month.
A rebuild is justified when it removes a cause, not when the site just feels old. If you want an outside view on which one fits, our web team can review it.