How I Rebuilt My GitHub Pages Blog After 3 Months Away (Without Breaking Anything)

Three months ago, I set up a GitHub Actions workflow to publish blog posts to GitHub Pages.

Then I walked away.

When I came back, I remembered none of the details—only that it worked and that I was slightly afraid to touch anything.

This post documents how I reverse-engineered my own setup, confirmed everything was still healthy, and published a new Markdown blog post without breaking the pipeline.

If future you is reading this: you’re welcome. :)

The Problem: “I Know I Did This Before… But How?”

I didn’t remember:

• How the site was deployed
• What triggered the build
• Where blog posts were supposed to live
• Whether I used Jekyll, Pages, or some custom magic

What I did know:

• The site was live
• I had pushed posts before
• GitHub Actions was involved

So instead of guessing, I treated this like a troubleshooting exercise.

Step 1: Find the Source of Truth (The Repo)

First, I identified the repository that actually powers the site.

This was either:

• username.github.io, or
• A repo with GitHub Pages enabled under Settings → Pages

Once I found it, I stopped worrying about memory and started trusting the repo history.

Step 2: Confirm How GitHub Pages Is Deploying

In Settings → Pages, I checked the Source.

Seeing “GitHub Actions” immediately answered a big question:

Okay, I didn’t manually deploy this. A workflow does it for me.

That meant:

• I don’t need to run commands locally
• A git push is all it takes
• If something breaks, the answer will be in Actions logs

Step 3: Inspect the GitHub Actions Workflow

Next stop: the Actions tab.

I opened the most recent workflow run and then the actual workflow file under: .github/workflows/

Key things I verified:

• The workflow triggers on pushes to main
• It builds the site
• It deploys to GitHub Pages

At this point, I knew:

If I commit the right files to the right place, the rest is automatic.

Step 4: Confirm This Is a Jekyll Blog

To avoid posting content in the wrong format, I checked the repo structure.

Seeing these files made it clear:

• _posts/
• _config.yml
• Gemfile

This is a Jekyll-powered GitHub Pages blog.

That answered another critical question:

Blog posts must go in _posts/ and follow Jekyll conventions.

Step 5: Reverse-Engineer a Past Post

Instead of guessing the format, I opened an existing blog post.

Things I noted immediately:

• Filename pattern: YYYY-MM-DD-title.md
• YAML front matter at the top
• Layout name (post)
• Date format

That old post became my template.

This is a highly underrated move: let your past work tell you what’s required.

Step 6: Create the New Markdown Post

With confidence restored, I created a new file: From there, it was just writing Markdown. No tooling. No local preview. No overthinking.