Introduction—Rebuilding an Author Website with a Static Site Generator

I had more than a decade of experience running WordPress, so when it came time to build my author website about 4-5 years ago, it was a natural choice.

The platform served me well, but over the years, I wanted to reduce the maintenance required to operate a WordPress site — especially as an indie author with limited time for the maintenance of the platform.

I wanted to focus my time differently—on writing, my family, and my other work. The regular maintenance of the site required more ongoing care than I was willing to commit. And, not performing the maintenance was not an option—I did not want someone to successfully hack my website because of obsolete components.

While my hosting provider (Kinsta—highly recommended) handled core updates and server patching flawlessly, I still had to maintain and troubleshoot numerous plugins: Elementor for styling, Advanced Custom Fields for custom content, CDN image offloading, security tools, and more. Each plugin brought its own configuration, maintenance requirements, and occasional headaches. Sometimes, a plugin update would break the site entirely. And, all of this adds cost.

I wanted to simplify. My goal: a site that required zero maintenance once built, until I made structural, new-feature updates. That meant no constant patching, no fragile plugin ecosystem, and full control over my site’s code.

What Conversion of My Author Website Was Designed to Solve

My vision was for a destination site for historical fiction lovers, with different, immersive features that would allow me to present content such as my historical fiction book reviews, my curated list of best historical fiction books, or my historical fiction. These features required different template approaches to present the information how I envisioned it.

I wanted:

  • A very secure, high-performance site served from a CDN edge, so it would load instantly for readers worldwide.
  • A privacy-first approach, collecting only the minimal data necessary to understand which content resonated and to measure advertising performance.
  • Full control over the code, free from third-party scripts that set cookies or added backlinks I didn’t want.

With WordPress, the website author can either write the code to handle the presentation and functionality or opt for third-party solutions—the plugins that I wanted to get away from.

The dynamic, plugin-heavy nature of WordPress was increasingly at odds with my vision.

Data Privacy Concerns

I also wanted to maximize privacy in my engagement with my readers. This is a little more complicated than a few settings.

The issue is that a dynamic website that relies on third-party components has a lot of code that I had very little control over. For example, I found that a lot of the plugins either set cookies or include backlinks to the software maker.

I needed to disclose such activity in my privacy policy (regardless of the legal requirement to do so), and I did not see how that supported my relationship with my reader. But, I either had to accept that intrusion, or write my own plugin code to replace the functionality.

While I still had to write code to create the template for the static site generator, this level of effort is a lot less than writing plugin code.

What a Static Site Is

A static website is a collection of pre-built HTML pages — no database or server-side processing on each request. In contrast, a dynamic site like WordPress assembles each page on-demand from a database.

Static sites have key advantages for an author website:

  • Speed — pages are ready to serve instantly from the hosting platform’s global content delivery network.
  • Security — with no database or dynamic code execution, there’s very little attack surface. Choosing a reputable host all but eliminates this consideration.
  • Simplicity — no plugin updates, no security patching, no server configuration.

This differs from a dynamic website, such as WordPress,

Consider what happens when a dynamically generated web page is requested:

  • On a WordPress website, the content and information on how to present it are stored inside of a database.
  • When someone requests the page, the webserver passes the request to the application, which uses logic to retrieve, assemble, and present the assembled page code to the webserver.
  • The ready html code is then sent by the webserver to the requestor.
  • Though there are ways to reduce this (caching), this requires additional plugins and infrastructure.

An astute reader might ask what the advantage or disadvantage of these architectures is.

A dynamically generated site is critical when the creation of the page is unique to the requestor. Think of an Amazon shopping cart—knowing what items are selected to be purchased is essential.

Alternatively, content that is customized for the viewer (think of what Microsoft Start or other portals do) has to be created dynamically.

For a content-focused author site, the dynamic capabilities of WordPress weren’t essential. All I needed was a beautifully presented library of content.

Why I chose Hugo as a Static Site Generator

After experimenting with several static site generators such as Gatsby, Vue, and others, I gravitated to Hugo. I liked several things about it:

  • It was very fast, though at my scale this makes little difference.
  • The code is straightforward. The content is written in Markdown, and is rendered into pages via templates. The templates are written in a combination of Go and HTML, which are also very easy to understand.
  • The organization of the site’s templates and content is very easy to understand.
  • It required the barest minimum of machinery, none of which I had to maintain. For example, the site is hosted on Amazon Web Services Amplify, which Amazon maintains and secures. While it happens that Amazon’s infrastructure experiences issues, the occurrences were far rarer than an odd update to a plugin disabling my site.
  • The deployment process is automated (Amazon re-builds the site as soon as any change is committed).

My Author Website Conversion Steps

Converting Content to Markdown

There was a good amount of effort to convert the content to Markdown. While the process itself is simple—I had the source text for all of my WordPress posts and pages, and I had all the images, I chose to improve the structure of the site as well so that the content discovery was logical and supported by SEO efforts.

I therefore had to build new directories, categories, and tags to support my vision of how the site would become a destination for historical fiction readers. Sometimes, this required editing and restructuring of content.

As an example, on my WordPress-powered site, I had the opening scene of my historical fiction short story Retribution. While this type of presentation works for a short story, I wanted a richer experience for the reader discovering and exploring my historical fiction novel Sic Parvis Magna which serves as cornerstone content into the opening chapter’s scenes, the characters, and the settings.

Creating Templates to Support the Vision of a Historical Fiction Destination Site

Once the content was converted to Markdown, it was time to design the templates.
In WordPress, the template is created inside of the application in php code, or one uses a GUI tool such as Elementor to create the theme visually.
In a static site generator, the template is broken up into several pieces, each of which performs a specific function. When Hugo builds the site, it assembles all the pieces together into the page, formats the content, and renders the HTML page.

The process sounds straight-forward, but requires getting over a bit of a learning curve to understand how the templates interacted and how the rendered page was actually created—for example, taking my Sic Parvis Magna page, there is page content, a data file that references the characters and settings, and other “parts” of the page that are put together. Understanding the process of how the page is built took me a bit, but I think the result was time-well-spent.

A Historical Fiction Site is History if SEO Data Is Not Transitioned

A site migration can destroy search traffic if not handled carefully. Since I restructured the content, the redirection of old to new had to be planned carefully.

I also wanted to revisit my SEO practices. I rebuilt my metadata strategy, structured data directly into the templates—removing the dependency on WordPress plugins like Yoast.

Effort and Lessons Learned

The migration took about three months and 120–160 hours of work to convert my WordPress-powered author website to be statically generated. This was a part-time effort, which had to fit into my life and around my work schedule.

A good amount of the extra time was taken up by the increased scope of the transition work. Had I done a like-for-like migration without restructuring content or improving templates, it might have been a lot faster (probably ¼ of the time).

But the result is exactly what I wanted: a fast, secure, privacy-focused author website that reflects my vision and serves historical fiction readers worldwide.

Final Thoughts for Fellow Historical Fiction Authors

Designing and implementing (or re-implementing) your author website is a large undertaking. There are a lot of considerations to take into the decision to ensure your vision of providing valuable content to your readers.

To be clear, everything that I built could have been built on WordPress, either with third-party plugins or by building the template code directly. The platform supported my needs for a long period of time. It is just that the required maintenance of the platform no longer fit my wants.

However, if you’re running your author website on WordPress and want an alternative to managing updates and plugins, improving compliance with privacy regulations, securing the site and preventing issues such as hacking and defacement, a static site generator like Hugo may be worth considering.