The homepage review ends with a familiar sentence: “We should probably redesign the site.” The request list is long. Campaign pages take too long to publish, the mobile menu feels clumsy, analytics are hard to trust and nobody is sure who owns the forms.
A redesign sounds like a clean answer because it turns all of that discomfort into one project. There is a start date and a launch date. There is also a fresh set of screens to approve. But many website problems return after launch because the operating problem never changed.
Most marketing websites do not need to be treated as redesign projects. They need ongoing upkeep and focused improvement, guided by measurement. A redesign can be the right move when the structure or platform is blocking the business. It should be a deliberate intervention, not the default response to a neglected backlog.
Why does the redesign idea feel so attractive?
Redesigns create a visible finish line. That helps when a marketing leader needs to explain the work internally, secure a budget or rally people around a date.
The trouble is that a website keeps changing after launch. Campaigns create new pages. Products shift. Tracking requirements change. Browsers and devices keep moving. Search systems change too. A site that was correct on launch day can become harder to use six months later without anyone making one dramatic mistake.
The UK Government Service Standard puts this plainly: services are never “finished.” Its guidance says teams should make improvements throughout a service’s lifetime, and that basic maintenance alone will eventually leave the service behind changing user needs.
That is a useful way to think about a marketing website. Launch is a handoff into live operation. It is not the end of the work.
What usually sits underneath “we need a redesign”?
The word redesign often collects several different problems that should be separated before anyone chooses a solution.
- The site is hard to run. Publishing is slow, routine requests sit in a queue or every change needs a specialist.
- The site is underperforming. Important pages are slow, forms are unreliable or visitors are not reaching the next step.
- The structure no longer fits. Navigation reflects an older business, page types cannot support current offers or the content model fights the marketing plan.
- The platform has become a constraint. Integrations are brittle, ownership is unclear or ordinary changes require workarounds.
Only the last two automatically point toward major structural work. The first two may be better handled through a focused sequence of fixes and experiments.
Google’s Core Web Vitals guidance is a good example. It gives site owners stable measures for loading speed, responsiveness and visual stability. Those measures can be checked page by page and improved without replacing the entire visual system. The current “good” thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, measured at the 75th percentile of visits.
If your checkout is slow, your forms lose submissions or your campaign template is painful to edit, start with those facts. A new color palette will not fix them.
When is a redesign actually the right call?
A redesign is reasonable when the evidence points to a connected set of structural problems. That might mean the information architecture no longer matches what the company sells, the design system cannot support the pages marketing needs or the current platform makes safe change too expensive.
Even then, define the outcome more precisely than “make it modern.” A useful redesign brief might say:
- reduce the number of page patterns editors have to manage;
- rebuild navigation around the current buyer journey;
- preserve search value while changing URLs;
- create a tested base for future campaign and product work.
Those are operating outcomes. They can be checked after launch.
Platform moves deserve particular care. Google’s site-move guidance recommends mapping old URLs to new ones, setting server-side redirects, testing the new site and monitoring traffic after the move. Google also advises changing one major thing at a time when possible. Combining a new domain, a new content system, a full content rewrite and a tracking change makes it harder to tell which change caused a problem.
A redesign should reduce constraints. If it creates a site that still needs a special project for every meaningful change, it has not solved enough.
What does an ongoing website operating rhythm look like?
It starts with one ordered backlog and one person accountable for turning business priorities into safe website changes. That backlog includes upkeep, content requests, performance work and larger engineering ideas. It is reviewed often enough that old assumptions do not become permanent commitments.
The monthly work usually has four lanes:
- Keep the site healthy. Apply updates, review security notices, check forms and watch uptime.
- Ship requested changes. Publish pages, adjust components and support active campaigns.
- Improve measured weak spots. Work on slow templates, confusing paths or pages with clear search and conversion problems.
- Build what the marketing plan needs next. Add integrations, custom features or better editorial tools when they earn their place.
This does not require constant churn. Some weeks call for a visible page change. Others call for cleanup, testing or planning that prevents the next campaign from getting stuck.
The GOV.UK live-phase guidance recommends continuing to improve a live service, testing changes across browsers and devices, checking accessibility and reviewing performance measures. That is a much better model for website ownership than waiting until frustration is high enough to fund another rebuild.
How should marketing and engineering share ownership?
Marketing should own the business priority. Engineering should own the technical path and the quality of the change, including risk and testing. Neither side should have to pretend to do the other’s job.
A useful request explains the outcome and the evidence: “People are reaching the demo page, but the form completion rate fell after the field change.” That gives an engineer room to inspect the form and its tracking, then compare page behavior and integration logs before proposing a fix.
The weaker version is a ticket that prescribes an untested solution: “Move the button above the fold by Friday.” It may be right, but it skips the question of what is actually failing.
Direct technical ownership matters here. When the same senior person understands the backlog, the platform, recent changes and the reason behind the work, small decisions do not need a fresh discovery process every time.
What should you do before approving another redesign?
Take one week and sort the current complaints into four buckets: operational friction, measurable performance issues, structural limits and platform limits. Then attach evidence where it exists.
Use analytics and Search Console for traffic and search behavior. Check representative pages in PageSpeed Insights. Test the forms yourself on a phone. Ask the people who publish content where the process slows down.
Next, identify the smallest set of changes that would improve the situation. If those changes can be made safely on the current platform, do them and measure the result. If the platform blocks the work, you now have the start of a real migration or redesign brief.
This step does not delay progress. It protects the budget from being spent on a broad answer to a narrow problem.
A website should have a next step, not a finish line
Treat the site as a live business system. Keep it secure and measure what matters. Test changes and improve the parts that are getting in the way. Use a redesign when the evidence shows that the underlying structure needs to change.
If your team is carrying a redesign request that may be several different problems bundled together, start a conversation with Growthwright. We can look at the current platform, the backlog and what the website needs to do next, then define a focused project or an ongoing monthly partnership.
Sources
- Continuous improvement throughout a live service: UK Government Service Manual, “8. Iterate and improve frequently” (published May 8, 2019; last updated May 30, 2022).
- Live services need continued improvement, testing and performance review: UK Government Service Manual, “How the live phase works” (accessed October 10, 2026).
- Core Web Vitals definitions and current thresholds: Google, “Web Vitals” (published May 4, 2020; last updated October 31, 2024).
- URL mapping, redirects, staged changes and post-move monitoring: Google Search Central, “Site Moves and Migrations” (last updated August 20, 2026).
Frequently asked questions
How often should a company redesign its website?
There is no useful universal schedule. Review the site continuously and plan a redesign when the structure, platform or design system blocks important business work. Age alone is not a sufficient reason.
Can we improve an old website without replacing it?
Often, yes. Performance fixes, accessibility work, content changes and better editorial tools can all be delivered in stages. A short technical review should confirm whether the current platform can support the work safely.
What should happen before a website redesign starts?
Document the business outcomes, current evidence, content inventory, integrations and URL map. Decide what will be preserved and how success will be checked after launch.
Will a redesign hurt SEO?
It can if URLs, internal links, indexability or page content change without a plan. Google recommends mapping old URLs to new ones, using server-side redirects and monitoring both versions during a site move.
What belongs in ongoing website work?
Routine upkeep, requested content changes, performance checks and measured improvements fit an ongoing rhythm. A platform move or another large one-time outcome usually needs a separately defined project.