by Swanandi Deshmukh, a digital marketing intern at Agileana currently pursuing a Bachelor of Engineering degree in Computer Science.
There's a version of this conversation we've had with almost every client who eventually redesigns their site, and it usually starts the same way: someone on their team says the website "looks old and outdated." That's the complaint that gets the meeting scheduled — and honestly, more often than not, they're right. The site does look dated. But that's rarely the whole story.
Once we start digging — pulling analytics, watching a few session recordings, actually trying to complete the tasks a real visitor would try to complete — we usually find the outdated look was never traveling alone. It came bundled with things nobody was watching for: the navigation was built around how the org chart looks internally, not how a visitor thinks about what they need. The content management system (CMS) is so brittle and inflexible that publishing a single news update requires pinging a developer. Accessibility was never really built in, just bolted on after the fact, if at all. Forms that used to convert fine are now steadily losing people on mobile. None of that shows up when you glance at the homepage and think "this needs a refresh." All of it shows up the moment you watch someone actually try to use the site.
That distinction — refresh versus redesign — is the first thing worth getting right, because it changes the whole scope of the project. A refresh is cosmetic: new branding, better imagery, tightened typography, a layout tweak here and there. It works when the bones of the site are solid and people can already get things done, they just want it to look sharper. A redesign is structural — new information architecture, rebuilt templates, sometimes a new CMS entirely — and it's what you need when the problems go deeper than the surface. Confusing "looks dated" with "is broken" is how organizations end up spending a redesign budget on a refresh's worth of change, and the underlying problems are still sitting there six months later.
So how do you actually know which one you're facing? In our experience it's rarely one dramatic red flag — it's usually several smaller ones showing up together. A site that's slow to load and hard to navigate on a phone. Search traffic that's been slipping for reasons that have nothing to do with content quality. A CMS your own team has learned to work around rather than work with. Accessibility gaps that were fine to ignore five years ago and aren't anymore. Maintenance costs creep up year over year because every fix is now a workaround stacked on an older workaround. Any one of these on its own might just need attention. Several of them showing up at once, on the same site, in the same year — that's usually the tell that a redesign, not a refresh, is the right call.
What that actually looks like matters more for some organizations than others, because the stakes aren't the same everywhere. For a government agency, the website might be the only channel someone has for renewing a license or applying for a benefit — accessibility and plain language aren't nice-to-haves, they're the whole point. For an association, it's about whether a member can actually find their certification renewal without calling someone. For a nonprofit, it's whether donating or signing up to volunteer takes thirty seconds or five frustrating minutes. The technical work looks similar across all of these — better structure, better accessibility, better performance — but the reason it matters is different every time, and that's usually the first thing we try to understand before touching any design work.
The part that gets skipped most often, and causes the most damage later, is content migration and SEO. It's tempting to treat "move the old site to the new one" as a mechanical step at the end of a project, but it's often the single largest workstream — and the easiest place to lose years of search visibility if it's rushed. We've seen redesigns that nailed the UX/UI design and the technology and still lost meaningful traffic in the weeks after launch, purely because URL mapping and redirects were an afterthought instead of a plan built alongside the design from day one. The pages worth keeping need to be identified early, mapped to where they're going, and tracked after launch — not scrambled together the week before go-live.
The framework we run projects through exists because of lessons like that one. It starts with actually understanding the goals behind the redesign — not "make it look modern," but the measurable thing the organization is trying to move, like service completions or conversions. From there it's an audit of what's actually happening today, real research instead of assumptions about what users want, and only then does structure and design work begin. At Agileana, we know that the work doesn't stop at launch. The sites that stay good five years later are the ones where analysts keep tracking the data and teams keep adjusting, instead of treating launch day as the finish line.
If any of this is sounding familiar — a site that technically works but is costing you conversions, search visibility, or your team's patience — that's usually the moment worth having this conversation, before the "it just needs a refresh" instinct sends the budget in the wrong direction.
Not sure if you need a refresh or a full redesign? Talk to Agileana — we'll look at what you're actually working with and tell you honestly which one you need.