Reusable Documentation Template with Jekyll

Asset	How to Leverage
Personality	Show authentic self
Story	Share journey authentically

Asset

How to Leverage

Personality

Show authentic self

Story

Share journey authentically

Most documentation sites share a similar structure: homepage, category filters, search, navigation, and content pages. Rather than rebuilding this from scratch for every new product or internal tool, you can create a reusable Jekyll template that you only need to configure — not re-code.

This approach allows you to:

Standardize UX across projects
Reduce maintenance effort
Enable non-devs to deploy new documentation by editing YAML

Core Architecture of a Reusable Jekyll Template

The modular documentation system will be composed of:

Collections for structured content (e.g. guides, FAQs, changelogs)
Data files for UI strings, categories, access levels
Layouts for each content type
Includes for reusable interface blocks
Configurable filters (category, type, tags)
Multilingual support via folder structure and data binding

Step 1: Create Modular Collections

In _config.yml, define your base structure:

collections:
  guides:
    output: true
    permalink: /:collection/:name/
  faqs:
    output: true
    permalink: /:collection/:name/
  changelogs:
    output: true
    permalink: /:collection/:name/

Then, store your content in:

_guides/
_faqs/
_changelogs/

Each item can use shared front matter:

---
title: "How to install"
lang: en
type: guide
tags: [setup, install]
categories: [getting-started]
visibility: public
---

Step 2: Modular Layouts with Includes

Break your layout into includes that can be reused:

_includes/
├── header.html
├── footer.html
├── filter-controls.html
├── content-grid.html
├── lang-switch.html

Your default layout file might look like this:

{% raw %}
<!DOCTYPE html>
<html lang="{{ page.lang | default: site.default_lang }}">
  <head>...</head>
  <body>
    {% include header.html %}
    {% include filter-controls.html %}
    {% include content-grid.html %}
    {% include footer.html %}
  </body>
</html>
{% endraw %}

Step 3: Use Data to Configure UI and Metadata

Allow each site to define its own branding, structure, and labels with YAML files:

_data/
├── site.yml
├── ui.yml
├── categories.yml

site.yml can define branding and routes:

title: "Docs Hub"
logo: "/assets/logo.svg"
collections:
  - guides
  - faqs
  - changelogs

ui.yml will hold text labels and multilingual content:

en:
  search_placeholder: "Search articles..."
  filter_label: "Filter by"
id:
  search_placeholder: "Cari artikel..."
  filter_label: "Saring berdasarkan"

Step 4: Build Content Grid with Filters

The dynamic content grid pulls items from all collections:

{% raw %}
{% assign lang = page.lang | default: site.default_lang %}
{% assign ui = site.data.ui[lang] %}
<h2>{{ ui.filter_label }}</h2>

<ul class="content-grid">
  {% for collection in site.collections %}
    {% assign items = site[collection.label] | where: "lang", lang %}
    {% for item in items %}
      <li class="doc-card" data-type="{{ item.type }}">
        <a href="{{ item.url }}">{{ item.title }}</a>
      </li>
    {% endfor %}
  {% endfor %}
</ul>
{% endraw %}

Step 5: Parameterize the Build

Let every new documentation project define its own data in a project folder or branch. For example:

projects/
├── my-saas-tool/
│   ├── _data/
│   ├── _guides/
│   ├── _faqs/
│   └── index.md
├── internal-wiki/
│   ├── _data/
│   ├── _guides/
│   └── index.md

Use a GitHub Actions matrix or manual branch switch to deploy each subfolder as a separate GitHub Pages site.

Step 6: Custom Themes via Config

Allow theming per project with variables in _data/site.yml:

theme:
  primary_color: "#2233aa"
  font: "Inter"
  button_radius: "12px"

Then use it in your CSS or SCSS:

:root {
  --primary: {{ site.data.site.theme.primary_color }};
  --font: {{ site.data.site.theme.font }};
  --radius: {{ site.data.site.theme.button_radius }};
}

Step 7: Easy Deploy via GitHub Pages

Each documentation instance can be published as:

org.github.io/my-saas-docs/
org.github.io/tools-wiki/

GitHub Actions can build each variation and push it to its own branch or repo. Every user now has access to a plug-and-play documentation system.

Use Case: Documentation Factory for a SaaS Studio

A SaaS company managing multiple products set up a "documentation factory" using this method. By cloning the base template, they spun up 8 documentation portals — all with consistent UI, language switching, custom branding, and search — simply by editing YAML.

Conclusion

Jekyll isn't just for static blogs. With collections, data files, and modular Liquid templates, it becomes a powerful tool for managing scalable, multilingual, and user-friendly documentation systems — all without any backend or JS frameworks.

This article concludes our deep-dive series on building knowledge base systems with Jekyll and GitHub Pages. You now have a complete, reusable system — searchable, multilingual, access-controlled, and modular — ready for production.

The Solopreneur's Reality

Leveraging Your Personal Brand

Simple Ladder Structures for Solopreneurs

The 3-Rung Ladder

The 4-Rung Ladder

Products That Scale

Systems for the Solo Operator

Community and Collaboration

Protecting Your Energy