Then, immediately after publishing that post, I discovered my “Tags” page was broken in the exact same way.

When I clicked the “Tags” link in my (perfectly functional) menu, it loaded a page that also had no CSS and contained only a giant “#Tags” title, with no actual tags listed—even though my post was correctly tagged and published.

This was the final, definitive clue.

The Unified Bug Theory

This confirmed the problem wasn’t a series of isolated glitches. It was one, single, catastrophic bug. My chosen theme, hugo-paper, had a fatal flaw.

Its “list” templates (like the homepage) worked perfectly. But its “single” template (for the About page) and its “terms” template (for the Tags page) were both fundamentally broken. They contained code that, for some reason, failed only in the Cloudflare Pages production environment, defaulting all asset paths to localhost.

My local build (hugo server -D) worked perfectly, which had masked this problem for days and led me down a debugging rabbit hole of config files, environment variables, and build flags. None of those fixes worked, because the theme’s engine itself was defective.

The Theme Transplant

The solution was obvious. You don’t fix a broken engine; you replace it.

I decided to perform a “theme transplant.” I ripped out hugo-paper completely. This involved:

1. Running git submodule deinit and git rm to purge the old theme from my project.
2. Choosing a new, robust, and extremely popular theme: hugo-PaperMod.
3. Adding it as a new submodule: git submodule add ... themes/PaperMod.

Of course, this came with its own final hurdles. My brand new Hugo version (v0.150.0) immediately threw an error because the new theme’s config used a deprecated paginate key. After fixing that (it’s now [pagination].pagerSize), the Tags page still showed up empty.

One final search revealed the truth: in our quest to create a “clean” config, we had removed the block that activates taxonomies. The final piece of the puzzle was adding this back to hugo.toml:

[taxonomies]
  tag = "tags"
  category = "categories"

My very first post should have been the “About” page. It’s the standard, simple, “Hello, this is who I am” page that every blog is supposed to have.

But I deleted it. I killed it before this blog ever saw the light of day.

This isn’t a great start, but it was a necessary one.

This Was Supposed to Be Easy

My goal was simple: set up a personal blog using the “golden stack” of modern static sites: Hugo (as the engine), the hugo-paper theme (for the clean look), Git, and Cloudflare Pages (for fast, free, global hosting).

And to be honest, it worked. Mostly.

Except for one, single, impossibly stubborn page.

The Ghost in the Machine

After I pushed my code, a bizarre problem appeared. My homepage loaded perfectly. The /posts/ list page loaded perfectly. They had the correct styles (CSS) and the correct English site title (“Frank’s Blog”).

But the /about/ page was a ghost.

It rendered as raw, unstyled HTML. Worse, every single link on that one page (the CSS file, the link back to the homepage, the footer links) was broken, pointing to an impossible address: http://localhost:1313/.

To make it even weirder, the footer—which was supposed to pull my site’s English title—instead showed an old, non-existent Chinese title: “Frank 的博客”.

My site was having a split-personality crisis. The homepage knew it was an English site deployed to production, while the About page thought it was a Chinese site running on a local test server.

The Debugging Rabbit Hole

So began an epic debugging saga. An AI assistant and I went down every conceivable rabbit hole to fix this. We tried:

1. Fixing the Config File? We triple-checked hugo.toml. We fixed deprecated keys (paginate), corrected TOML syntax, and scoured the file for invisible whitespace characters. The problem remained.
2. A “Ghost” Config? We hypothesized a “ghost” multilingual file (languages.toml) left over from the theme’s example site was forcing the build into a broken state. We hunted it down and deleted the entire config directory. The problem remained.
3. Build Environment Mismatch? The most maddening clue was that hugo server -D on my local Mac worked perfectly. The About page was beautiful. This suggested a conflict with Cloudflare’s build environment. So, we set the HUGO_VERSION environment variable in Cloudflare to match my exact local version. The problem remained.
4. A Build Command Override? We thought maybe Cloudflare was ignoring the baseURL in the config. So we manually forced it in the build command: hugo --baseURL https://frankblogs.com/. The problem remained.
5. A File Structure Problem? Our final theory. Maybe the theme’s “single page” template was buggy, but its “list page” template (used by the working homepage) was fine. We changed the file structure from content/about.md to content/about/_index.md to “trick” Hugo into using the working template. And still, it failed.

The Verdict

After trying every logical configuration fix, the conclusion was inescapable.

The problem wasn’t my config. It wasn’t Cloudflare. It was a deep, unfixable bug in the hugo-paper theme itself—a flaw in its single-page template that, for some reason, fails catastrophically only when built on the Cloudflare Pages environment, defaulting all its paths to localhost. It was invisible locally, but fatal in production.

So I had a choice: spend the next week learning the Go Template language to debug a third-party theme I didn’t write… or just delete the broken feature.

I chose deletion.

This blog is going to be a record of building things that work. The first lesson is knowing when to cut your losses and pick the pragmatic path.

So, hello, world. There is no “About” page here. There is only this “Posts” page.

Because I know for a fact: this part works.