“Update the website more” isn’t a schedule anyone follows for long. A better question is which events should trigger a change, since those events happen on their own timeline regardless of what a calendar reminder says.
A paper gets accepted
Add it to the publications list the week it’s accepted, not the week it’s published months later. A prospective student or collaborator checking your output shouldn’t see a gap that the CV in your last grant application doesn’t have.
Someone joins or leaves
A new postdoc’s start date and a departing student’s last day are both website updates, not only entries in an HR system. A team page with a name that shouldn’t be there anymore is one of the fastest ways to look unmanaged, and it costs five minutes to fix.
A useful habit: make the website update part of onboarding and offboarding checklists, the same list that covers building access and email accounts. Once it’s on that list, it stops depending on someone remembering separately.
A grant gets funded
New funding belongs on the site the same month it’s awarded, both for the funding acknowledgment and because it’s evidence of an active, supported lab that a future reviewer will check for. Waiting until the annual report season to update this loses months of the “currently funded by” signal doing any work for you.
Before a conference
If your lab is presenting, the site should reflect the version of the work being shown, especially if a talk references a paper still in submission. Reviewers and collaborators who see the talk and look up the lab afterward should find something that matches what they heard minutes earlier.
Once a year, regardless
Even with no specific trigger, block time once a year to look at the whole site with fresh eyes: broken links, outdated photos, a bio that still says “PhD candidate” for someone who defended two years ago. This is the pass that catches the small gaps none of the trigger-based updates above would have caught on their own.
A good time for this pass is right after a slow stretch, like the weeks after a conference season ends or before a new academic year starts, when there’s a natural pause to look at the site as a whole instead of one section at a time.
What happens when nobody owns this
The pattern behind almost every stale lab site is the same: updates were someone’s responsibility informally, that person moved on or got busy, and nobody explicitly picked it back up. The site doesn’t break all at once. It drifts, one missed update at a time, until eighteen months have passed and the gap feels too large to easily fix.
The fix isn’t a better reminder system. It’s naming one person, explicitly, as the owner of the site’s content, the same way a lab names someone to manage the equipment calendar or the shared reagent inventory. Once ownership is explicit, the trigger-based updates above tend to happen on their own.
A system that survives a busy semester
The habits above only hold up if they don’t depend on memory during the weeks when nobody has time to think about the website. A shared document, even a simple one, listing the trigger events and who owns each one, removes that dependency. When a paper gets accepted, the corresponding line gets checked off within the week, not remembered three months later during a slow stretch.
This doesn’t need to be elaborate. A single page with five rows, one per trigger event in this list, and a note on who’s responsible for each, is enough for most labs. The value isn’t in the system’s sophistication. It’s in having something more durable than one person’s memory during a semester when everyone is behind on everything else.
What doesn’t need a trigger
The site doesn’t need a redesign on a schedule. A clean, working site from three years ago that’s kept current on the items above serves a lab better than a site rebuilt last year and left untouched since. Content currency matters more than the age of the design.
Common questions
How often should a lab website be updated?
Not on a fixed schedule. The better approach is tying updates to specific events: a paper accepted, someone joining or leaving, a grant funded, a conference talk coming up. Those events happen on their own timeline regardless of what a calendar says.
Who should be responsible for keeping a lab website current?
One specific person, not 'the lab' in general. Sites that stay current almost always have a single person who treats updates as part of their role, whether that's the PI, a lab manager, or a designated trainee.
Does a lab site need a full redesign periodically?
No. A well-maintained site from several years ago serves a lab better than a recently redesigned site that's been left untouched since launch. Content currency matters more than the age of the design.
What's a simple system for remembering to update the site?
Attach it to something that already happens: the day a paper gets accepted, the week someone starts or leaves, the day funding is confirmed. Tying updates to real events works better than a recurring reminder nobody acts on.