There’s a pattern that shows up almost every time a research unit’s website comes up for review, two or three years after it launched.

The build itself was done properly. There was a brief, a proper design phase, sign-off from the right people, a launch everyone was pleased with. Then the project closed, the invoice was settled, and the website quietly became someone’s responsibility in theory and nobody’s responsibility in practice.

This isn’t a story about bad websites. It’s a story about good websites that were never given anywhere to go after launch.

A quick distinction, because it matters

Not every unit controls its own website. Many departments sit on a shared university platform. They use a template and a shared content system, and are hosted and governed centrally. This approach has real advantages: consistency, security, IT support that doesn’t depend on one person. But it also tends to come with a cost that’s rarely discussed: those platforms are usually built for consistency across hundreds of pages, not for the specific features a research-heavy unit actually needs, and they leave little room to move quickly when funders or collaborators expect something current.

If that’s your situation, most of what follows won’t be actionable, because the platform decision usually isn’t yours to make. If you’re one of the units that operates with some independence: grant-funded, externally hosted, and running your own site because the work needed room a shared platform couldn’t give it, this is written for you.

A website is a deliverable. Infrastructure isn’t.

Most research units budget for a website the way they’d budget for a report or a conference poster. The site is seen as a defined piece of work with a start, an end, and a sign-off. That’s the right way to budget for the build, but it’s the wrong way to think about what happens next, and how to extend the value of this deliverable past the project end date. In other words, how to ensure the website becomes infrastructure, not just a deliverable.

A report doesn’t need to stay current once it’s published. A website does. The moment it goes live, it starts falling out of step with the unit it represents: new outputs, new team members, new funding partners, new collaborations. That is, unless there is a process and person keeping it in step, deliberately.

What website decay looks like

It rarely looks dramatic. It looks like a team page still listing someone who left eighteen months ago. A publications list that quietly stops at a certain year, not because the unit stopped publishing, but because updating that page was never anyone’s job. Links to partner institutions or archived studies that now return an error. Contact details for a grant administrator who’s moved on.

None of these individually looks like a crisis. Together, they tell a visitor something the unit almost certainly doesn’t intend to say: that nobody is currently minding this.

For a research unit, that’s a strange thing to communicate by accident, given how carefully everything else — the methodology, the ethics clearance, the data management plan — tends to be maintained.

Why this costs more in a research context specifically

Commercial businesses can sometimes get away with a static website for a surprisingly long time. A grant-funded research unit generally can’t, because the thing the website represents doesn’t stand still. A three-year grant cycle produces new outputs, new staff, new partnerships, and sometimes a real shift in focus, every single year it runs.

A website frozen at launch actively misrepresents the current state of the work to the people most likely to be checking it: funders considering renewal, potential collaborators doing due diligence, and journalists or policymakers looking for a current contact.

There’s also a quality and standards problem that’s easy to miss. Accessibility guidance doesn’t stay still either — WCAG standards are revised, and a site built to meet these standards at launch can drift out of compliance simply by staying unchanged.

Hosting keeps a site online. It doesn’t keep it accurate.

This is where the confusion usually sits. Most research units do have something in place: hosting, a security certificate, the odd plugin update. That keeps the site running. It does nothing to keep the site true.

Hosting and maintenance solve different problems. Hosting is infrastructure that keeps the lights on. Maintenance is the discipline of someone actually looking at the site on a schedule, checking that it still reflects reality, and making the small, unglamorous updates that stop the gap from opening in the first place.

Without that second piece, even a beautifully built site starts working quietly against the unit behind it.

Where to start

The fix isn’t a bigger rebuild every few years. It’s building a maintenance relationship into the original scope, the same way a research unit budgets for ongoing data management rather than treating it as a one-off task.

It’s useful to have this conversation at two points: when a site is first being built, so maintenance is planned for rather than bolted on later, and for any unit whose site hasn’t been properly looked at in over a year, regardless of how it was built or by whom.

A website that’s actually maintained compounds in value the longer it runs. One that isn’t starts working against the unit the moment nobody’s watching it — quietly, and usually for longer than anyone realises.