A research lab website that doesn't depend on one person
Most lab websites decay because one student built them and then graduated. Split the site into lists that change on their own schedule (people, projects, publications, openings, news), give each a simple form in a dashboard, and let the people closest to each list keep it up to date.
Who visits a lab site
Prospective PhD students and post-docs are the largest group, and they read closely: what the lab works on, who's in it, where alumni went and whether there are openings. Collaborators and funders want the projects and outputs. Journalists want a plain-language summary and a contact. Each of those readers is let down by the same thing: a people page listing someone who left three years ago and a news section that stops in 2023.
Five lists, one owner each
| Collection | Typical fields | Who keeps it |
|---|---|---|
| People | Name, role, start year, research interest, photo, profile link, alumni flag | Lab manager |
| Projects | Title, summary, funder, dates, lead, status | Project leads |
| Publications | Title, authors, venue, year, DOI, open-access link | Each first author |
| Openings | Position, closing date, requirements, how to apply | PI |
| News | Date, headline, short text, link | Whoever has news |
On Anticode each of these is a CMS collection with the typed fields you choose, edited in the dashboard. Collection pages are served at addresses like /people/ and /projects/<slug>, so a project can have its own page that a grant report or a paper can link to. Editing an entry doesn't need a rebuild or any knowledge of HTML.
Letting several people edit
A Team workspace gives the lab a shared space with seats for each person who edits. Roles are owner, admins and members. Members can edit but can't delete projects or take the site down, which suits rotating students; admins can be the lab manager and a senior post-doc. When someone leaves, remove their seat and flip their People entry to alumni rather than deleting it. Alumni destinations are some of the most persuasive content on the site for prospective students, because they show where a few years in the lab tends to lead.
Version history keeps the most recent saves, up to a number set by your plan, so if a well-meaning edit breaks a page, an admin can restore an earlier version.
Openings and enquiries
An openings collection with closing dates keeps adverts honest: remove a post when it closes, and add a line saying the lab welcomes enquiries about fellowships even when nothing is advertised. The contact form asks for a name, email and message. It doesn't take attachments, so ask applicants to send CVs to an institutional address as your process requires. Each enquiry is saved, sealed at rest and can be emailed to the PI or sent to a shared Slack channel through a connector.
Building it
Describe the lab and its areas: "a website for a computational neuroscience lab with people, projects, publications, PhD openings and news". The Architect plans the pages and asks where it matters. Technical (IBM Plex Sans) and Swiss (Inter Tight) are natural fits for science; Organic (Figtree) suits environmental and life-science groups. Publish on an anticode.dev address or connect a domain on a paid plan. For one researcher's site rather than a group's, see the academic website guide.
What to check with your institution
- Whether lab sites must sit under the university's domain or follow its brand guidelines.
- Whether photos of lab members need consent forms; ask each person regardless.
- Whether project pages may name funders and grant numbers.
Where Anticode stops
- No single sign-on with your university. Editors sign in with email, magic link, GitHub or Google.
- No publication import from BibTeX, ORCID or Scholar; entries are added in the dashboard.
- No internal areas. No password-protected pages for lab protocols or data; use your institution's systems for those.
- No file hosting for datasets or PDFs; link to a repository.
Questions people ask
How many people can edit the lab website?
A Team workspace includes a set number of seats, ten by default including the owner. See /pricing for plan details.
Can students edit without being able to delete the site?
Yes. Members can edit projects but can't delete them or take sites down.
Can we export the site if the university wants to host it?
Yes, as a single HTML file or a Next.js project, with no Anticode runtime.