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

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. This 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 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.

Step by Step

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.

Bringing the Winner into Your Main Blog

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!

Tidying Up

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

A Few Things Worth Knowing

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!

Why I Like This Pattern

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.

It is the closest thing to a proper A/B test that GitHub Pages makes available to us 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.

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!