I run several blogs. All powered by Hugo, all hosted on GitHub Pages. It’s a clean setup—until you try to manage them at scale.
Each site uses the same Hugo theme. So every time I tweak the theme or change the configuration, I need to update every repo manually. It’s tedious. Multiply that by three or four blogs, and you’ve got a recipe for lost time.
That’s where this post comes in.
TL;DR
👉 Use hugo-multisite-manager to manage multiple GitHub Pages blogs from a single Hugo install.
The Spark: Solving Hugo Multisite Workflow
While hunting for a better workflow, I came across this forum thread. The suggestions there were solid, but I added my own flavor: using Git submodules to keep each site in its own repo—perfect for GitHub Pages.
This approach keeps each blog independently deployable while letting me maintain shared configs and themes in one place.
An Easier Path
To save time for others, I scripted the whole thing and open-sourced it as hugo-multisite-manager.
If you just want a working setup—start there.
If you’re curious how it works under the hood, keep reading.
The Manual Setup (If You Like to Tinker)
GitHub Pages requires one repo per website. So if you’re managing multiple sites, you’ll need a way to sync them with Hugo while keeping deployments clean.
1. Set Up a Base Hugo Project
Create a new Hugo site that will act as the container for your blogs:
Quick start instructions here
Inside this base project, add a new folder:
mkdir websites
This folder will hold each individual blog using Git submodules.
2. Add Existing Blogs as Submodules
For each existing blog:
git submodule add -b main <repo-url> websites/<blog-name>
git submodule update --init websites/<blog-name>
At this point, your folder structure should start to come together.
3. Clean Up the Submodule Structure
Since all my blogs use the same theme, I deleted everything inside the submodule except:
content/public/config.toml
This makes each submodule light and focused. Here’s what it looks like:
This is what the base Hugo project looks like with multiple websites added as Git submodules. Each site lives under the websites/ folder, with its own content, public, and config.toml. This structure keeps things isolated but manageable.
4. Update Config Paths
Each blog still needs its own config.toml. But now that content and public directories are nested under the main project, we need to tell Hugo where to find them.
Update each blog’s config like this:
contentDir = 'websites/<blog-name>/content'
publishDir = 'websites/<blog-name>/public'
Running Your Blogs
To run a blog locally:
hugo server --config=websites/<blog-name>/config.toml
To build the static site:
hugo --config=websites/<blog-name>/config.toml
That’s it.
Once built, you can push updates back to the submodule’s repo and deploy however you like—GitHub Pages, Netlify, your own server—totally up to you.
Final Thoughts
Managing multiple Hugo blogs doesn’t have to be a copy-paste marathon. With the right structure, a few submodules, and a clear strategy, you can keep your blogs consistent without losing your weekends to config updates.
I built hugo-multisite-manager to help with this. If it saves you even a few hours, I’d love to hear about it.
Let me know if you run into edge cases—or if you find a better way. This setup works for me. Yours might need tweaks. But either way, automation wins over repetition every single time.