There is no right interval for a website redesign, so our approach is to diagnose your need by signals rather than the calendar. Typically, a refresh fixes how your site looks and performs, while a redesign fixes how it is built: findability, audiences, content model, and platform. The clearest signal is your own project conversation, because if it keeps drifting toward navigation and page types, you need a redesign, whatever you are calling it.
Someone at your institution is going to ask whether it is time for a redesign. Maybe a new VP arrived and the site feels dated to them. Maybe a peer institution just launched something impressive. Maybe the CMS contract is up for renewal and the question is riding along with it.
Do you need one? The truthful answer is: it depends. And yes, that answer is only useful if you know what it depends on. So let’s diagnose your needs together.
A website refresh versus a website redesign
Stakeholders tend to use these words interchangeably. They are not interchangeable, and the gap between them is where budgets go wrong.
A refresh updates the surface of the site: visual design, typography, color, imagery, component styling, performance tuning, and content updates within the existing structure. The information architecture, the page types, the content model, and usually the CMS stay as they are.
A redesign changes the structure: how the site is organized, who it is organized for, what kinds of pages exist, how content relates to other content, and often the platform underneath all of it. Navigation, templates, content models, governance, and migration are all on the table.
In our experience across three decades of higher ed web projects, an enterprise redesign is typically a 12 to 18 month effort and a six-figure investment. A refresh typically runs 4 to 6 months at roughly a quarter of the cost. And that is before counting the internal cost institutions feel most: the stakeholder alignment, content work, and governance decisions a redesign demands from people who already have full-time jobs.
It is important to try to understand what needs to be fixed. A refresh applied to a structural problem just makes a confusing site prettier. A redesign applied to a surface problem spends two budget cycles rebuilding what was not broken. Let’s dig into the details.
Problems a refresh can fix
These are surface problems. If your situation matches this list, a refresh is likely the right tool for you:
- The site looks dated, but users can still find things. Your analytics show healthy task completion: program pages get found, applications get started, search is not the dominant navigation method. The complaint is aesthetic, not functional.
- Performance is the complaint. Slow pages, poor Core Web Vitals, heavy images. These are fixable within the existing structure.
- The brand evolved but the audiences did not. New colors, new photography, new voice, same prospective students looking for the same things in the same places.
- Content is stale but the content model still fits. The pages need rewriting, not restructuring. (If you are not sure which, a content audit settles the question with evidence.)
- Accessibility issues live at the component level. Contrast, focus states, alt text, form labels. Real problems, addressable without touching the architecture.
A refresh applied to a structural problem just makes a confusing site prettier.
The refresh that isn't always that simple
Before we get to the second list, a caution, because this is where refreshes can sometimes go sideways.
A refresh is still a project, and it still needs strategy behind it. What is the goal, who is it for, what should someone feel and do on the new surface: the why-before-how questions apply at every scale, not just the big one. A refresh scoped as “make it look current” with no brief tends to produce a site that looks current and performs exactly as it did before.
There is also a technical reality that surprises teams: themes and architecture are coupled. The templates you are restyling were built around the page types, navigation, and content model underneath them. Changing the surface of an existing site without touching its structure is harder than it sounds, because the structure shows through. Components assume certain content lengths, certain page relationships, certain menus.
If the refresh conversation keeps drifting into navigation, page types, and “while we’re in there,” you may actually benefit from a redesign.
If every design review turns into an information architecture debate, the surface was never the problem.
Problems that require a redesign
These are structural problems. A refresh cannot fix them:
- Users cannot find things, and analytics prove it. Site search has become the primary navigation method. Visitors pogo-stick between pages without completing tasks. Program pages with healthy demand get no traffic because nothing leads to them.
- Your audiences changed. Adult learners, online programs, transfer students, graduate populations the original architecture was never built to serve. You cannot bolt a new primary audience onto an IA designed around a different one.
- The content model is the problem. Program pages that cannot hold structured data. No defined relationships between programs, outcomes, faculty, and stories. Every page a one-off. This is also what blocks entity clarity and AI search readiness: if the structure cannot express what things are and how they relate, no amount of content work on top of it will.
- The platform blocks the team. CMS end-of-life, security exposure, or a system so difficult that content updates queue behind one overloaded person.
- Accessibility problems live in the architecture. Navigation patterns, document structure, and interaction models that fail users of assistive technology no matter how the components are styled.
One more reality of the structural path: the CMS question travels with the redesign question. A redesign is usually the moment to decide whether your platform carries forward, gets replaced, or gets migrated to a current major version. And the reverse is just as common: a major-version CMS migration is often a redesign-scale project wearing an upgrade label, because themes, templates, and content models typically have to be rebuilt rather than carried over. If a platform migration is on your horizon, it is worth folding into the redesign conversation early. Running them as separate projects usually means doing the same template and content work over again.
The last two lists are the diagnosis. The next question is the one higher ed adds on top.
A major-version CMS migration is often a redesign-scale project wearing an upgrade label.
The higher ed complication
At an institution, this is never purely a technical decision. As Pete Gaioni, our VP of Strategy and Account Services, puts it: “A true redesign is 50 percent digital communication and 50 percent change management.” Shared governance means the structural questions, who the site is for, whose content gets prominence, what gets retired, are political questions wearing technical clothes. Budget cycles rarely align with the moment the signals appear. And the scars from the last redesign shape the appetite for this one, sometimes for a decade.
This is why a phased path is a legitimate strategy and not a failure: a clearly scoped refresh now, while building the governance, content model, and stakeholder alignment a redesign will need. Sometimes the refresh is also the politically viable answer in a year when the redesign is technically right. Naming that openly, with a plan for the structural work, beats pretending the refresh solved problems it did not.
"A true redesign is 50 percent digital communication and 50 percent change management."
A five-question diagnostic
Want to know which conversation you are really having? Run this in a meeting. It will not replace discovery, but it will point you in the right direction.
- Can users complete their top tasks? Check analytics and site search data before checking opinions. If task completion is healthy, you are likely in refresh territory.
- Have your audiences changed since the last redesign? New populations, new programs, new enrollment realities. If yes, the architecture question is open.
- Does your content model support structured data and content relationships? If your program pages cannot express what they are to a search engine or an AI system, that is structural.
- Is the platform serving the team, or is the team serving the platform? A CMS that blocks the people maintaining it is a structural problem with a deadline.
- When you discuss the project, where does the conversation go? If it stays on look and feel, refresh. If it keeps drifting to navigation, page types, and audiences, you are describing a redesign, whatever the project is called.
If you have mostly refresh answers: scope a refresh, and give it a real brief. If you have mostly redesign answers: it is time to start the discovery conversation, because a refresh will not hold.
And what if it is a split? Consider the phased path, and be explicit about which problems the refresh is deferring rather than solving.
A phased path, starting with discovery and research, is a legitimate strategy.
Whichever you choose, protect your search equity
Redesigns, and refreshes that touch URLs or templates, are where search rankings go to die when redirect mapping and content migration are afterthoughts. Years of your accumulated authority can be lost in a launch weekend. Make SEO continuity an explicit line in the project scope: a full URL inventory, redirect mapping, preservation of the pages that earn traffic and AI citations, and structured data carried forward or improved. If you are writing an RFP, put it in the RFP, so vendors compete on it.
So, when should I do a redesign?
There is no correct redesign interval. A site with a sound architecture, a workable platform, and stable audiences can run on refreshes for a long time. A site whose structure no longer matches its audiences is due, whatever year it is.
That diagnosis is what discovery is for, and it is the first thing we build with institutions before anyone debates a homepage. Figure out which problem you have, and the rest of the decision follows from it. If you are not sure, that is exactly the kind of question we like to work through together.
Would you like to talk further about navigating your next steps? Just reach out to us, we would love to help.
Frequently asked questions about website redesigns and refreshes
There is no fixed interval. A website with sound information architecture, a workable CMS, and stable audiences can run on periodic refreshes for many years. A redesign becomes necessary when structural signals appear: users cannot complete tasks, audiences have changed since the architecture was built, the content model cannot support structured data, or the platform blocks the team maintaining it. Diagnose by signals, not by calendar.
A refresh updates the surface of a site: visual design, typography, imagery, component styling, performance, and content, within the existing structure. A redesign changes the structure itself: information architecture, audience definitions, page types, content model, and often the CMS. The scale difference is significant: an enterprise redesign is typically a six-figure investment over 12 to 18 months, while a refresh runs roughly a quarter of the cost over 4 to 6 months, and a redesign requires substantially more internal work: stakeholder alignment, content decisions, and migration.
When the problems are structural. The clearest signals: analytics show users cannot find or complete what they came for, your audiences have changed since the architecture was designed, your content model cannot express structured data or content relationships, accessibility failures live in the architecture rather than the components, or your CMS has reached end-of-life. If the problems are visual or performance-related and task completion is healthy, a refresh is usually the better tool.
For higher education institutions, a full redesign typically runs 12 to 18 months from discovery through launch, depending on site size, governance complexity, content work, and whether a CMS migration is included. A refresh typically runs 4 to 6 months. Institutional factors, stakeholder review cycles and content readiness above all, drive timelines more than technical work does.
Not always, but the two decisions travel together. A redesign is the natural moment to evaluate whether your platform carries forward, gets replaced, or gets migrated to a current major version. The reverse also holds: a major-version CMS migration often requires rebuilding themes, templates, and content models, which makes it a redesign-scale project even when it is scoped as an upgrade. If a platform migration is on the horizon, fold it into the redesign conversation early to avoid paying for template and content work twice.
It can, significantly, in either direction. A redesign that mishandles URL changes, redirects, or content migration can lose years of accumulated search authority at launch. A redesign that improves site structure, page speed, and structured data can improve visibility in both traditional and AI search. The difference is whether SEO continuity is an explicit part of the project scope: full URL inventory, redirect mapping, and preservation of high-performing content.
