Live Design Testing with GitHub Pages and a Custom Domain

In my previous post, I wrote about using Git branches to test blog designs before committing to them. A few of you asked a natural follow-up question: what if you want to run two experiments at the same time, each at its own live URL, without touching your main blog at all?

I had the same question! And it turns out GitHub Pages has a lovely little feature that makes this possible. The trick is not branches — it is repositories.

How GitHub Pages Handles Custom Domains

GitHub Pages custom domain routing is a hosting feature that maps every repository in an account to its own URL path under one shared custom domain, without any manual server configuration. When you link a custom domain to your GitHub Pages setup, it applies to your entire GitHub account, not just one repository. GitHub distinguishes between two types of Pages sites:

Your user site lives in a repository named exactly yourusername.github.io. A user site is where your main blog lives, and it publishes to the root of your custom domain — domain.com.

Any other repository in your account becomes a project site, and GitHub Pages automatically publishes it as a subdirectory of your custom domain. So a repository called test1 publishes to domain.com/test1, and a repository called test2 publishes to domain.com/test2. No extra configuration needed — it just works.

This dual-site model means you can have your main blog running happily at domain.com while two completely independent design experiments live at domain.com/test1 and domain.com/test2, all at the same time.

How to Run a GitHub Pages Design Test on a Custom-Domain Subdirectory

1. Create a New Repository for Your First Experiment

Go to GitHub and create a new repository. Name it test1 (or something more descriptive, like design-minimal or design-dark-mode — the repository name becomes the URL path, so choose something readable).

Make the repository public. GitHub Pages requires a public repository on the free plan.

2. Copy Your Blog into the New Repository

The easiest starting point is to copy your existing blog into the new repository so you have the same content to work with. Clone it locally:

git clone https://github.com/yourusername/yourusername.github.io.git test1
cd test1

Then change the remote so it points to your new repository instead of your main one:

git remote set-url origin https://github.com/yourusername/test1.git
git push -u origin main

You now have an independent copy of your blog in a separate repository, ready to experiment on.

3. Update the Base URL

This is an important step that is easy to miss. Jekyll uses a baseurl setting to build internal links correctly. Open _config.yml in your new repository and set it to match the subdirectory:

baseurl: "/test1"

Without this, internal links — navigation menus, post links, stylesheet references — will point to domain.com/ instead of domain.com/test1/ and things will break in confusing ways. Save the file and commit the change:

git add _config.yml
git commit -m "Set baseurl for test1 subdirectory"
git push

4. Enable GitHub Pages for the New Repository

Go to your test1 repository on GitHub and open Settings → Pages. Under Branch, select main (or whichever branch you want to publish from) and click Save.

GitHub will build and deploy your site. After a minute or two, your experiment will be live at domain.com/test1.

5. Make Your Design Changes

Now you can experiment freely. Change the theme, edit the CSS, restructure the layout, try a different font — whatever you want to test. Every time you push a commit, GitHub Pages rebuilds the site automatically:

git add .
git commit -m "Try wider content column and new header style"
git push

Refresh domain.com/test1 and see your changes live. No impact on domain.com whatsoever.

6. Repeat for a Second Experiment

Want to test a second design idea at the same time? Repeat the whole process with a repository named test2. You will have:

• domain.com — your main blog, completely untouched
• domain.com/test1 — design experiment one
• domain.com/test2 — design experiment two

You can share these URLs with friends, open them side by side on your own screen, or check them on your phone — a real live preview of each option.

Merging a Winning GitHub Pages Design Back into Main

Once you have decided which design you prefer, copying it back into your main repository is straightforward. The key is to copy only the design files — templates, stylesheets, config changes — and not overwrite your actual blog content (posts, images, pages).

Typically that means copying across:

• _config.yml (with baseurl changed back to "" or your root domain)
• _layouts/ and _includes/ if you modified templates
• assets/ or css/ if you modified stylesheets

Then commit and push to your main repository:

cd ../yourusername.github.io
# copy your design files across, then:
git add .
git commit -m "Apply new design from test1 experiment"
git push

Check domain.com and enjoy your new look!

Deleting GitHub Pages Test Repositories After a Design Decision

Once you are done, delete the test repositories to keep your GitHub account clean. Go to each repository’s Settings, scroll all the way down to the Danger Zone, and click Delete this repository. The subdirectory URLs will disappear within a few minutes.

# Also remove the local copies if you no longer need them
rm -rf test1
rm -rf test2

Error: test1 Subdirectory Shows Broken Styles or 404s

Cause: baseurl in _config.yml does not match the repository name, so Jekyll builds asset and link paths for the wrong subdirectory.

Fix: Open _config.yml in the test1 repository, confirm baseurl: "/test1" matches the repository name exactly, commit, push, and wait for GitHub Pages to rebuild.

GitHub Pages Subdirectory Testing: Key Facts and Limitations

Build times are independent. Each repository builds separately, so a slow build in test1 does not affect your main blog.

The baseurl setting matters a lot. If your experiment looks broken — missing styles, broken links — the first thing to check is whether baseurl in _config.yml matches the repository name exactly.

Keep experiments short. The longer a test repository lives, the more it drifts from your main blog’s content. I try to make a decision within a week or two.

You can have more than two. There is no hard limit on how many project sites you can run from one account. In practice, two is usually enough to make a decision!

GitHub Pages Subdirectory Testing: Key Takeaways

What I love about this approach is how low-stakes it feels. Your main blog is completely isolated from the experiments. Nothing you do in test1 or test2 can affect domain.com. And because the experiments are live at real URLs, you get genuine feedback — from yourself, from friends, or from anyone you share the link with.

GitHub Pages subdirectory testing represents a zero-downtime A/B testing method for static sites, because production and experiment content are served from entirely separate repositories rather than shared build artifacts. This repository-based approach is the closest thing to a proper A/B test that GitHub Pages makes available without any extra tooling or cost, and when you are done, it cleans up completely — no leftover branches, no config changes to undo, no surprises.

Frequently Asked Questions: GitHub Pages Custom-Domain Design Testing

Does my main domain still work while I run a test1 or test2 subdirectory experiment?

Yes. Your user site repository keeps serving domain.com unchanged; project-site repositories like test1 and test2 only publish to their own subdirectory paths and never touch the root domain.

Why does my test1 subdirectory site show broken styles and links?

This almost always means baseurl in _config.yml does not match the repository name exactly. Set baseurl: “/test1” for a repository named test1 and re-deploy.

How many project-site experiments can I run at once?

There is no hard limit on the number of project-site repositories GitHub Pages will publish as subdirectories, though two is usually enough to make a design decision.

How do I bring the winning design back into my main blog?

Copy only the design files — _config.yml (with baseurl reset to “”), _layouts/, _includes/, and assets/ or css/ — into your main repository, leaving posts, images, and pages untouched, then commit and push.

Happy experimenting!

Did you like this post? Please let me know if you have any questions or if there are other GitHub Pages tips you would like me to cover next!