lab-website-template turns a Jekyll site into a lab's public face

A site for a group, not a page for a person

The stated purpose is narrow and practical. Spend less time worrying about managing a website and citations, and more time running your lab. That framing tells you what the template is optimised for. A lab site has recurring sections that an ordinary static site does not, a people page that changes when someone graduates, a publications list that has to render correctly with authors and venues, a projects section where the current work differs from the finished work, and a blog for lab notes. The repository layout shows the same structure as directories, with _cite/, _members/, _posts/, _data/, _includes/, _layouts/, _plugins/, _styles/ and _scripts/ holding the machinery, and blog/, contact/, projects/, research/ and team/ holding the pages a visitor sees, alongside index.md, testbed.md and a 404.md. The topics are just lab, template and website, and the primary language is recorded as HTML because the site output is HTML even though the build is Jekyll. The template is published with a DOI, 10.5281/zenodo.17228741, which is the convention labs use for citing software and is the sort of detail the audience would expect to be there.

Citations from identifiers, not from bibliography files

The feature that distinguishes the template is automatic citation generation from simple identifiers. You write a reference as an identifier such as doi:1234/5678, and the citation is expanded into the title, the authors, the publisher, the date and the rest. The README names the tool doing the work, Manubot, and the identifier types it accepts, including DOI, PubMed, ORCID and many more. That is a real design decision rather than a convenience, because a bibliography in a static site is normally maintained by hand or by a script that scrapes a reference manager export, and both approaches rot. Deriving the citation from an identifier means the reference is as stable as the identifier, and the metadata is fetched from the source of record. The _cite/ directory in the repository is where that machinery lives, and the format is documented in the repository's own documentation rather than in the README, which is worth knowing before you start. The other side of the same idea is the team page, where _members/ holds bios, roles and social media links, so a new member is a file rather than an edit inside a layout.

Previews come from pull requests, not from a staging server

The preview mechanism is listed as automatic pull request previews, and it fits the Git-centred design of the whole project. Because the site is based on Git, GitHub and Jekyll, a branch can be built and served as a preview, which means a change to a citation, a member bio or a blog post can be reviewed like code before it goes live. There is no separate staging environment to keep in sync, and the review of a pull request is the same event as the review of the content, which is a sensible fit for a group where the people editing the site are also the people reviewing each other's work. The repository carries a .github/ directory and a Gemfile with a lock file, which is the Ruby and Jekyll build being pinned, and a CHANGELOG.md alongside CITATION.cff, so the software citation metadata for the template itself is maintained in the same way the template asks you to maintain yours.

The component suite is where the template earns its keep

The README describes a comprehensive and flexible suite of pre-made components for structuring and styling the site, and it lists what is in them. There are formatted tables, code blocks, figures and other basic elements, citations with thumbnails and other rich details, and the ability to list large sets of data with flexible filters and components, followed by an ellipsis for the rest. That last item is the honest one, since the actual catalogue lives in the documentation rather than in the readme. The filters matter more than they sound, because a lab's data is usually a table of publications, datasets or instruments, and a static page that lists hundreds of rows in a fixed order is worse than one that lets a visitor narrow the list. The other components are the same in kind, a citation rendering with a thumbnail, a table with formatting, and code blocks that match the style of the papers. Everything is configured rather than hard coded, the README lists easy and automated configuration as a feature, and _config.yaml is where that configuration lives.

What is in the tree and what the documentation does not say

The repository is a Jekyll site laid out as a set of underscore-prefixed content directories plus the rendered pages, with a _docker/ directory for a containerised build, a Gemfile and Gemfile.lock pinning the Ruby dependencies, a LICENSE.md, and the site itself at greenelab.github.io/lab-website-template/. The documentation is the interesting omission. The README links it as Documentation on GitBook, at greene-lab.gitbook.io/lab-website-template-docs, and the template's own description calls it an easy-to-use, flexible website template for labs, with the deployment quick start and component catalogue living in that GitBook rather than in the repository. That is a sensible choice for keeping the readme short, and it is also a dependency you should account for before you commit: the setup instructions, the component reference and the upgrade path are one service away from the code. The README also points out the things it does not do, and there is no tutorial in it. A first-time user should plan to read the GitBook from the beginning rather than trying to assemble a site from the directory names.

Where the template is the wrong choice

Three limits. The first is that this is a lab site, not a general purpose static site generator, and the components, the citation workflow and the preview mechanism are all built around a research group's needs. If you want a personal blog, a documentation site or a company landing page, you would be fighting the component set rather than using it. The second is the toolchain. Jekyll on Ruby with a pinned Gemfile, a container build path and a Manubot step means your publishing pipeline is a Ruby project, and a lab that would rather not maintain Ruby tooling will feel the weight of it even though the site itself is plain static output. The third is the dependency on the external documentation, which for a template that others fork and modify means the instructions drift from the code at the pace of a third party site. The maintenance picture is reasonable rather than brisk. The last push was on 2026-08-03, matching the v1.4.0 release, and the recent history shows v1.3.9 in June 2026 and v1.3.8 in November 2025, so the project ships patch and minor releases on a steady schedule with no sign of abandonment. An alternative worth naming is a general purpose Jekyll theme with a citation plugin, which leaves you to build the member pages and the preview workflow yourself, and which is the right trade when your site is not shaped like a lab's.

Editorial conclusion

Adopt the lab-website-template if you are a research group that needs a credible site with citations, member pages and a blog, and you are willing to work inside a Jekyll and Manubot toolchain. Skip it if you want a general purpose static site generator, because the component suite, the citation workflow and the preview mechanism are all built around a lab's needs. Before you publish, note that the documentation is hosted on GitBook rather than in the repository, so read it there, and remember the site is a Git repository, which means the site's history is part of its credibility.

Frequently asked questions

Official sources

1. greenelab/lab-website-template on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases