Web on kenji.blog

Hugo Theme Customization: How to Introduce Tailwind CSS

Sun, 13 Sep 2026 03:00:00 +0900

Introduction: The Powerful Synergy of the Static Site Generator Hugo and Tailwind CSS

In modern web frontend development, balancing performance and Developer Experience (DX) is one of the most critical challenges in every project. Combining Hugo, which boasts some of the world’s fastest build speeds among static site generators (SSGs), with Tailwind CSS, which introduced the innovative paradigm of utility-first CSS, can be considered an ultimate answer to this challenge.

Hugo is written in Go and has the astonishing performance to finish building thousands of pages in just a few seconds or even milliseconds. On the other hand, Tailwind CSS accelerates design iterations and eliminates the context switching of jumping back and forth between CSS and HTML files by allowing you to write countless predefined utility classes (such as flex, text-center, mt-4) directly into HTML.

In this article, we will thoroughly and comprehensively explain the steps to introduce Tailwind CSS into a Hugo theme and further build an advanced asset pipeline (Hugo Pipes) using PostCSS, covering everything from the foundation of the architecture to mathematical performance optimization perspectives.

1. The Transition of Utility-First CSS and Component-Oriented Design

Before diving into the Tailwind CSS installation steps, it is highly beneficial to deeply understand the history and evolution of the CSS design philosophy behind why we should use Tailwind CSS.

The Limitations of Traditional CSS Design (BEM and OOCSS)

In past web development, giving semantic class names was considered a best practice. For example, when creating a card component, HTML and CSS were separated as follows:

1
2
3
4
5
6
7


<div class="card">
 <img class="card__image" src="image.jpg" alt="thumbnail">
 <div class="card__content">
 <h2 class="card__title">Title</h2>
 <p class="card__description">Description goes here.</p>
 </div>
</div>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


.card {
 border-radius: 8px;
 box-shadow: 0 4px 6px rgba(0,0,0,0.1);
 background-color: #ffffff;
 overflow: hidden;
}
.card__title {
 font-size: 1.5rem;
 font-weight: bold;
 color: #333333;
}
/* Detailed styles continue below */

While such BEM (Block Element Modifier) based design works when the project scale is small, it tends to cause the following problems:

Naming exhaustion and fatigue: You have to think of new class names every time you create a similar component (e.g., card-news, card-featured).
CSS Bloat: The number of CSS lines continues to increase every time a new feature is added, and once written, CSS is rarely deleted out of fear that “we don’t know where it’s used,” leading to an accumulation of dead code.
Context Switching: Because HTML structure and CSS styles are managed in separate files, the number of times you switch tabs in your editor increases exponentially.

Paradigm Shift by Tailwind CSS

Tailwind CSS solves these problems with the approach of “combining utility classes.” Using Tailwind CSS, the above card component looks like this:

1
2
3
4
5
6
7


<div class="rounded-lg shadow-md bg-white overflow-hidden">
 <img class="w-full h-48 object-cover" src="image.jpg" alt="thumbnail">
 <div class="p-6">
 <h2 class="text-2xl font-bold text-gray-800">Title</h2>
 <p class="mt-2 text-gray-600">Description goes here.</p>
 </div>
</div>

Since the class names themselves represent the specific values of styles (e.g., p-6 is padding: 1.5rem;), you can predict the final rendering result just by looking at the HTML. Furthermore, Tailwind’s JIT (Just-In-Time) compiler extracts only the actually used classes into the production CSS file, reducing the CSS file size to the absolute minimum.

2. Hugo Pipes and PostCSS Architecture

To integrate Tailwind CSS into Hugo, you need to understand the asset processing pipeline called Hugo Pipes. Hugo Pipes is a powerful feature that completes all asset-related processing internally within Hugo, such as compiling Sass/SCSS, bundling and minifying JavaScript, and executing the PostCSS we will use this time.

PostCSS is a tool for transforming CSS using JavaScript plugins. Tailwind CSS itself actually operates as a PostCSS plugin.

AST (Abstract Syntax Tree) Transformation Mechanism by PostCSS

Understanding how PostCSS processes CSS is highly useful for troubleshooting. The following Mermaid diagram shows the pipeline of how PostCSS reads a CSS file, transforms it through plugins, and outputs the final CSS.

flowchart TD
A["Raw CSS (styles.css)"] -->|Parser| B["AST (Abstract Syntax Tree)"]
B --> C["Plugin 1: Tailwind CSS"]
C --> D["Plugin 2: Autoprefixer"]
D --> E["Plugin N: cssnano"]
E -->|Stringifier| F["Compiled & Optimized CSS"]

Parser: Analyzes the inputted raw CSS string and converts it into an AST (Abstract Syntax Tree), a data structure that can be manipulated programmatically.
Plugins:
- Tailwind CSS: Scans template files (HTML or Markdown) and adds the used utility classes as nodes to the AST. It also expands the @tailwind directive.
- Autoprefixer: References the Can I Use database and adds vendor prefixes (such as -webkit-, -moz-) to the AST properties as needed.
Stringifier: Converts the transformed AST back into a browser-readable CSS string and outputs it.

3. Environment Setup and Prerequisites

Now, let’s move on to the actual installation steps. First, we will check if the necessary software is installed.

Prerequisites

Hugo Extended Version: You must have the Extended version, not the regular Hugo, as it includes Sass/SCSS processing capabilities and native PostCSS integration features. Run the following command in your terminal and verify that the version information contains the string extended.
1 2 3

hugo version # Expected output example: # hugo v0.121.2-4146... windows/amd64 BuildDate=... VendorInfo=gohugoio +extended
Node.js and npm: Dependencies like Tailwind CSS and PostCSS run on Node.js. Make sure Node.js (LTS version recommended) is installed.
1 2

node -v npm -v

Installing npm Packages

Initialize npm in the project’s root directory (where Hugo’s configuration file hugo.toml is located) and install the required packages.

1
2
3
4
5


# Generate package.json
npm init -y

# Install Tailwind CSS, PostCSS, and Autoprefixer as development dependencies
npm install -D tailwindcss postcss postcss-cli autoprefixer

[!IMPORTANT] If postcss-cli is not installed, errors may occur when invoking PostCSS from inside Hugo. Because Hugo Pipes internally uses postcss-cli, be absolutely sure to install it.

4. Building Configuration Files (PostCSS & Tailwind CSS)

Once the package installation is complete, create two important configuration files that control the project’s behavior. Place them in the project root directory.

Creating tailwind.config.js

Run the following command in your terminal to generate the default configuration file.

1

npx tailwindcss init

Open the generated tailwind.config.js in your editor and set the content property. This is extremely important. Tailwind analyzes the files at the paths specified here and extracts the classes being used. Precisely specify the layout files and content files according to your Hugo project structure.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


/** @type {import('tailwindcss').Config} */
module.exports = {
 // Specify targets to scan according to Hugo's directory structure
 content: [
 "./content/**/*.md",
 "./content/**/*.html",
 "./layouts/**/*.html",
 "./assets/**/*.js",
 // If you are using a theme, you also need to include the theme's directory
 // "./themes/my-theme/layouts/**/*.html",
 ],
 theme: {
 extend: {
 // Extend custom colors and fonts here
 colors: {
 'brand-primary': '#3490dc',
 'brand-secondary': '#ffed4a',
 },
 fontFamily: {
 'sans': ['Helvetica Neue', 'Arial', 'Hiragino Kaku Gothic ProN', 'Meiryo', 'sans-serif'],
 }
 },
 },
 plugins: [
 // Add official plugins as needed (e.g., Typography plugin)
 // require('@tailwindcss/typography'),
 ],
}

Creating postcss.config.js

Next, create postcss.config.js in the project root, which defines which plugins PostCSS will run and in what order.

1
2
3
4
5
6


module.exports = {
 plugins: {
 tailwindcss: {},
 autoprefixer: {},
 }
}

With this configuration, when Hugo calls PostCSS, it will first apply Tailwind CSS processing and then use Autoprefixer to add vendor prefixes.

5. Building the CSS Asset Pipeline in Hugo

Once the configuration is complete, it is finally time to integrate Tailwind CSS into the Hugo theme side.

5-1. Creating the Entry Point CSS File

Create the entry point CSS file in the assets/css/ directory (create it if it doesn’t exist). We will name it main.css here.

File Path: assets/css/main.css

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


/* Load Tailwind's base styles (reset CSS, etc.) */
@tailwind base;

/* Load component classes */
@tailwind components;

/* Load utility classes */
@tailwind utilities;

/* If you need your own custom CSS, you can add it here,
 but it is recommended to handle it in tailwind.config.js's extend as much as possible */
@layer components {
 .btn-primary {
 @apply bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded transition-colors duration-300;
 }
}

5-2. Editing the Layout File (head.html)

Next, we will load the above CSS file from a Hugo template and write the pipeline to process it with PostCSS. Generally, you edit the partial template that defines the <head> tag (e.g., layouts/partials/head.html).

File Path: layouts/partials/head.html

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>{{ .Title }} | {{ .Site.Title }}</title>

 <!-- Get assets/css/main.css -->
 {{ $css := resources.Get "css/main.css" }}

 <!-- Define PostCSS options -->
 {{ $options := dict "inlineImports" true }}
 {{ $css = $css | resources.PostCSS $options }}

 <!-- Asset optimization pipeline for the Production environment -->
 {{ if hugo.IsProduction }}
 <!-- 1. Minify -->
 {{ $css = $css | minify }}
 <!-- 2. Fingerprint (add hash for cache busting) -->
 {{ $css = $css | fingerprint "sha512" }}
 <!-- 3. Output the tag including SRI (Subresource Integrity) -->
 <link rel="stylesheet" href="{{ $css.RelPermalink }}" integrity="{{ $css.Data.Integrity }}" crossorigin="anonymous">
 {{ else }}
 <!-- In the Development environment, output as-is without minifying (prioritize build speed) -->
 <link rel="stylesheet" href="{{ $css.RelPermalink }}">
 {{ end }}
</head>

Pipeline Explanation and Mermaid Diagram Illustration

We will diagrammatically explain the sequence of pipeline processing for how the above Go template code handles the CSS file.

flowchart TD
A["assets/css/main.css"] -->|resources.Get| B["Hugo Memory Space"]
B -->|resources.PostCSS| C["PostCSS + Tailwind JIT Process"]
C --> D{"hugo.IsProduction ?"}
D -- Yes (Production environment) --> E["minify (remove spaces/newlines)"]
E --> F["fingerprint (calculate hash)"]
F --> G["public/css/main.[hash].css (with SRI)"]
D -- No (Development environment) --> H["public/css/main.css"]

resources.Get: Looks for the specified file within the assets directory and loads it as a resource object in memory.
resources.PostCSS: Refers to postcss.config.js in the project root and applies Tailwind CSS and Autoprefixer processing to the CSS source code. In the development environment (hugo server), JIT mode kicks in and rapidly generates only the necessary classes when files are modified.
minify: During production builds (like hugo --environment production), it removes unnecessary whitespace and comments to minimize the file size.
fingerprint: Calculates a SHA hash based on the file’s contents and appends it to the filename (e.g., main.ab12cd...css). This enables “cache busting,” allowing you to utilize strong browser caching while ensuring a new file is reliably loaded when the CSS is updated.
integrity: Outputs an SRI attribute using the hash value calculated by Fingerprint to prevent tampering from CDNs and other sources.

6. Mathematical Performance Analysis in CSS Optimization

One of the greatest benefits of introducing Tailwind CSS is the minimization of the delivered CSS file size. Let’s use a mathematical model to quantitatively analyze how this impacts web performance (especially First Contentful Paint: FCP).

CSS File Size Reduction Model

With traditional CSS frameworks (like Bootstrap), the entire volume is loaded, including unused styles, so the file size $S_{original}$ tends to be large (around 150KB to 200KB). Let $S_{purged}$ be the size after purging unused classes with the Tailwind CSS JIT compiler, and $R_{purge}$ be the reduction rate. This can be expressed as follows:

$$ S_{purged} = S_{original} \times (1 - R_{purge}) $$

In a typical project, $R_{purge}$ reaches close to $0.9$ (a 90% reduction), and $S_{purged}$ fits into just around 10KB to 20KB.

Furthermore, compression by Brotli or Gzip is performed on the server side upon delivery. Assuming a compression rate $R_{compress}$ (usually around 0.7 to 0.8), the final payload size $S_{final}$ flowing through the network is calculated with the following formula:

$$ S_{final} = S_{purged} \times (1 - R_{compress}) $$

Critical Rendering Path and Network Latency

The time it takes for a browser to render the first piece of content on the screen (FCP) can be approximated as the sum of the HTML download time, CSS download time, and rendering time.

$$ T_{FCP} \approx RTT + \frac{S_{HTML}}{BW} + RTT + \frac{S_{final}}{BW} + T_{render} $$

Where:

$RTT$ : Round Trip Time (communication latency with the server)
$BW$ : Network Bandwidth

In environments with narrow $BW$ and large $RTT$ (high latency) such as mobile networks, Tailwind CSS’s approach, which can strip $S_{final}$ down to mere kilobytes, pushes the $\frac{S_{final}}{BW}$ term extremely close to zero, acting as the driving force to achieve phenomenal scores (e.g., Google PageSpeed Insights).

7. Starting the Development Server and Checking Hot Reloading

Once all configurations are complete, start the Hugo development server and check if Tailwind CSS is working properly.

1

hugo server -D

Access http://localhost:1313/ in your browser and verify that the site is displayed. Try opening a Markdown content file or a Hugo template (files under layouts/) and adding some classes.

1
2
3
4
5


<!-- Example of applying Tailwind classes for testing -->
<div class="bg-gradient-to-r from-blue-500 to-purple-600 text-white p-8 rounded-xl shadow-2xl text-center transform transition duration-500 hover:scale-105">
 <h1 class="text-4xl font-extrabold tracking-tight">Tailwind CSS + Hugo is Awesome!</h1>
 <p class="mt-4 text-lg font-medium">Please verify that hot reloading is instantly reflected.</p>
</div>

The moment you save the file, Hugo’s powerful file watcher and Tailwind’s JIT compiler will work together to rebuild the CSS in milliseconds, allowing you to experience the thrill of the browser automatically reloading (hot reloading).

Troubleshooting: When Styles Are Not Reflected

If your changes are not reflected, check the following points.

The content path setting in tailwind.config.js If the scanned file paths are incorrect, Tailwind cannot detect the classes used within those files and will not output them to the CSS. Especially if you are using a theme, make sure the theme directory path is not missing.
PostCSS Errors If an error like Error: failed to transform resource: PostCSS not found appears in the Hugo server logs in your terminal, npm install might not have executed correctly, or postcss-cli might be missing.
Clearing the Hugo Cache Rarely, old CSS remains due to Hugo’s cache. Try stopping the server and starting it with hugo server --ignoreCache, or deleting the OS temporary directory (e.g., /tmp/hugo_cache/).

8. Production Builds and Further Advancements

When deploying your site to a production server (Netlify, Vercel, GitHub Pages, Cloudflare Pages, etc.), you need to set environment variables to run the production optimization pipeline.

1
2


# Example of a production build command
NODE_ENV=production hugo --minify --environment production

By adding the --environment production flag, the {{ if hugo.IsProduction }} block in head.html is executed, and CSS minification and fingerprinting will take place.

Styling Markdown with the Typography Plugin

In blogs and documentation sites like those made with Hugo, you cannot directly add classes to pure HTML elements (<h1>, <p>, <ul>, etc.) generated from Markdown. The official Tailwind Typography plugin is extremely useful in such cases.

Install the plugin

1

npm install -D @tailwindcss/typography

Add it to tailwind.config.js

1
2
3
4
5
6


module.exports = {
 // ...
 plugins: [
 require('@tailwindcss/typography'),
 ],
}

Applying it in templates Simply adding the prose class (and your choice of color or size variants) to the container element that outputs the body of the article will apply beautiful default styles.
1 2 3

<article class="prose prose-lg prose-blue mx-auto mt-10"> {{ .Content }} </article>

This completely eliminates the need to manually write complex CSS selectors (e.g., .article-content h2 { ... }) and perfectly preserves component modularity.

9. Conclusion: Completing a Highly Maintainable Frontend Ecosystem

Great job. You have now completed a perfect web development asset pipeline, combining Hugo’s ultra-fast static site generation engine, Tailwind CSS’s modern styling capabilities, and PostCSS’s extensibility.

The brilliance of this architecture is that “you only have to configure it once.” Once the pipeline is built, developers never have to open a CSS file; by simply writing intuitive utility classes into HTML or Markdown templates, they can build complex UIs at astonishing speeds.

Moreover, because the output CSS size is always minimized, it directly contributes to improving Core Web Vitals scores and works very advantageously from an SEO perspective.

The combination of Hugo and Tailwind CSS will remain one of the “best choices” for every project, from personal tech blogs to large corporate websites. Please take advantage of this powerful toolchain and enjoy a comfortable web development life!

Introduction to Static Site Generators with Hugo (Migration Guide from WordPress)

Sun, 13 Sep 2026 02:00:00 +0900

In modern web development and blog management, site loading speed, security, and maintainability have become extremely crucial factors. For a long time, “WordPress” has boasted an overwhelming market share as the foundation for blogs and corporate sites, and is loved by many users for its flexible plugin ecosystem and intuitive admin interface. However, because it involves communication with a database and dynamic page generation on the server side (processed by PHP), it also faces challenges such as vulnerability to sudden traffic spikes and display delays (latency).

Therefore, “Static Site Generators (SSG)” have been rapidly gaining popularity in recent years. In this article, among the many SSGs, we will delve deeply into “Hugo”, which is developed in Go and known for its overwhelming build speed. We will thoroughly explain everything from the technical architecture comparison with dynamic CMS (Content Management System) like WordPress, to specific migration procedures, performance evaluation using mathematical models, and Hugo’s unique directory structure and template lookup order.

1. Technical Differences between Dynamic CMS (WordPress) and Static Site Generator (Hugo)

In the mechanism of delivering websites, WordPress and Hugo take fundamentally different approaches.

1.1 WordPress Architecture (Dynamic Generation)

WordPress is a prime example of a dynamic CMS that assembles pages on the server side every time a request is made. When a user (browser) accesses a page, the web server (Apache, Nginx, etc.) executes PHP scripts and issues queries to a relational database like MySQL (or MariaDB). It combines the content fetched from the database (article data, categories, tags, site settings, etc.) with template files, generates the final HTML, and returns it to the client.

This mechanism has the advantage of being able to generate different content in real-time for each visitor (e.g., e-commerce carts, pages exclusive to logged-in users), but unless caching mechanisms (reverse proxies, plugins, etc.) are properly designed, it aggressively consumes server resources.

1.2 Hugo Architecture (Pre-generation at Build Time)

On the other hand, Hugo, as the name “Static Site Generator” suggests, generates content not at “request time” but at “build time”. Content is maintained not in a database, but as local “Markdown files” version-controlled by Git, etc. When a developer executes the command (hugo), Hugo reads the Markdown files, pours the data into specified HTML templates (layout files), and generates a collection of completed, pure HTML/CSS/JS files.

The generated files (static assets) can be delivered simply by placing them in a “static hosting environment” such as Amazon S3, Cloudflare Pages, Netlify, Vercel, or a simple Nginx server. Since neither a database nor a server-side language (like PHP) is required, security risks (like SQL injections and PHP vulnerabilities) are dramatically reduced, and delivery speed is maximized by being cached on edge nodes of a CDN (Content Delivery Network).

Below, we show the differences in each architecture using a Mermaid diagram.

flowchart TD
subgraph WordPress["Dynamic CMS (WordPress)"]
direction TB
Req1["User Request"] --> WebServer1["Web Server (Nginx/Apache)"]
WebServer1 --> PHP["PHP Processor"]
PHP <--> DB["Database (MySQL)"]
PHP --> HTML1["HTML Generation"]
HTML1 --> Res1["Return Response"]
end
subgraph Hugo["Static Site Generator (Hugo)"]
direction TB
Dev["Developer / CI/CD"] --> HugoBuild["Hugo Build Process"]
Markdown["Markdown Files"] --> HugoBuild
Templates["Templates (HTML)"] --> HugoBuild
HugoBuild --> StaticFiles["Static Files (HTML/CSS/JS)"]
StaticFiles --> CDN["CDN / Static Hosting"]
Req2["User Request"] --> CDN
CDN --> Res2["Return Immediate Response"]
end

2. Performance Evaluation using Mathematical Models

One of the greatest benefits of migrating from WordPress to Hugo is the improvement in performance (load speed). To understand this quantitatively, let’s express it with a simple mathematical model.

The time until page loading is complete (Load Time: $T_{load}$) is broadly divided into the server response time (TTFB: Time To First Byte) and the rendering/resource fetching time by the browser ($T_{render}$).

$$ T_{load} = T_{ttfb} + T_{render} $$

In the case of a dynamic CMS (WordPress), $T_{ttfb}$ is the sum of the following factors: network latency ($T_{network}$), server-side script execution time ($T_{php}$), and database query processing time ($T_{db}$).

$$ T_{ttfb\_wp} = T_{network} + T_{php} + T_{db} $$

Under heavy access conditions (high load), $T_{php}$ and $T_{db}$ increase non-linearly, and the entire system can become a bottleneck. Expressed as a formula, we see the following deterioration in response time relative to the number of requests ($N$) ($k$ is the processing overhead coefficient).

$$ T_{php}(N) \approx O(N^k), \quad T_{db}(N) \approx O(N^k) \quad \text{where } k > 1 $$

On the other hand, in an architecture combining a static site generator (Hugo) and a CDN, there are no server-side dynamic processes (PHP or DB queries). Because the content is cached on edge servers distributed globally, $T_{ttfb}$ purely depends on the network latency ($T_{edge}$) from the client to the nearest edge server.

$$ T_{ttfb\_hugo} = T_{edge} $$

As a result, $T_{edge} \ll (T_{network} + T_{php} + T_{db})$ holds true, and TTFB is dramatically reduced to just a few milliseconds to tens of milliseconds. Moreover, even if the number of requests $N$ increases, the response time remains almost constant ($O(1)$) due to the load-balancing capabilities of edge servers.

$$ \lim_{N \to \infty} T_{ttfb\_hugo}(N) \approx \text{Constant} $$

This is the mathematical basis for why Hugo (static sites) is extremely robust against traffic spikes (e.g., when content goes viral).

3. Basic Structure and Operating Principles of Hugo

To master Hugo, it is essential to understand its unique directory structure and the concepts of “Front Matter” and “Template Lookup Order”.

3.1 Detailed Explanation of Directory Structure

When you create a new Hugo project (hugo new site mysite), the following directory structure is generated.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


mysite/
├── archetypes/ # Templates when creating new content (Front Matter blueprints)
├── assets/ # Files to be processed by Hugo Pipes (SCSS/Sass, JavaScript, etc.)
├── content/ # Actual site content (Markdown files). This acts as a DB replacement.
├── data/ # External data and settings used across the site (JSON, TOML, YAML, CSV, etc.)
├── layouts/ # HTML templates that determine the site's appearance (using Go html/template)
├── public/ # Where generated static files are output after running the build command
├── static/ # Static files published as-is (images, favicons, robots.txt, etc.)
├── themes/ # Third-party or custom theme directories
└── hugo.toml # Site-wide configuration file (config.toml was mainstream previously)

In WordPress, content is stored in the wp_posts table of MySQL, but in Hugo, everything is managed as text files (mainly Markdown) in the content/ directory. This makes version control (Git) of content easy.

3.2 Content Management: Markdown and Front Matter

Each article file in Hugo has a metadata block at the very top called “Front Matter”, followed by the body text (Markdown) below it. Front Matter can be written in TOML, YAML, or JSON, but YAML is widely used.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


---
title: "Understanding Hugo Taxonomy"
date: 2026-09-13T10:00:00+09:00
draft: false
categories:
 - "Technical Guide"
tags:
 - "Hugo"
 - "Go"
aliases:
 - "/old-category/hugo-taxonomy/"
---
The body text starts here. Written in **Markdown**.
We will explain the powerful features of Hugo...

What’s noteworthy here is the aliases key. When migrating from WordPress, if permalinks (URLs) change, it causes a significant negative impact on SEO. By using Hugo’s alias feature, you just specify the old URL, and Hugo will automatically generate an HTML file for redirection (forwarding via meta refresh). This is very convenient as it eliminates the need for server-side redirection settings (like .htaccess).

3.3 Template Lookup Order

One of Hugo’s powerful features is its flexible template discovery mechanism (Template Lookup Order). When rendering a specific page, Hugo searches directories and filenames in a specific order to find the most appropriate template.

For example, when rendering a single article (Single Page) like content/post/hello-world.md, Hugo looks for the layout file in roughly the following order:

layouts/post/single.html
layouts/post/list.html (Not an error, but usually for lists)
layouts/_default/single.html
themes/<THEME_NAME>/layouts/post/single.html
themes/<THEME_NAME>/layouts/_default/single.html

Developers can override theme templates simply by creating a file with the same name in their project’s layouts/ directory, without directly modifying the theme’s source code. This allows you to apply your own customizations without hindering updates to the base theme.

3.4 Taxonomy

The classification system corresponding to “Categories” and “Tags” in WordPress is called “Taxonomy” in Hugo. Hugo supports categories and tags taxonomies by default, but you can freely add custom taxonomies (e.g., series, authors, etc.) by editing hugo.toml.

1
2
3
4
5
6


# hugo.toml example
[taxonomies]
 category = "categories"
 tag = "tags"
 series = "series"
 author = "authors"

This makes it possible to organize and list content along diverse axes.

4. Migration Process from WordPress to Hugo (Migration)

The key to a successful migration from WordPress to Hugo is how to cleanly convert dynamic content in the database into static files (Markdown + Front Matter) while maintaining the existing URL structure.

Below is the flow of a typical migration pipeline.

flowchart LR
WPDB["WP Database"] -->|Plugin| Exporter["Export Tool"]
Exporter -->| Extracts Text, \nMeta, Images | ZipFile["Zip / Folder"]
ZipFile -->|Unpack| MarkdownFiles["Markdown Files \n(content/)"]
ZipFile -->|Unpack| ImageFiles["Images \n(static/wp-content/)"]
MarkdownFiles --> Formatting["Review & Format \n(Fix Shortcodes)"]
Formatting --> Git["Commit to Git"]

4.1 Data Extraction and Markdown Conversion

To output WordPress data for Hugo, using a dedicated plugin is the easiest and most reliable method. Here are a few typical approaches.

Using the Jekyll Exporter Plugin Since Hugo has a very similar data structure to Jekyll, another SSG, it is a common practice to use the “Jekyll Exporter” plugin for WordPress. When you install and run this plugin, all posts and static pages are converted into Markdown files with Front Matter, and can be downloaded as a ZIP file along with image files.
Custom Script utilizing the WordPress API This is a method of writing a script in Python, Node.js, etc., that calls the WordPress REST API (/wp-json/wp/v2/posts), parses the JSON data, and generates Markdown files yourself. It is effective for sites that heavily use complex custom fields (like ACF) that plugins cannot fully handle.
Utilizing the wp2hugo Tool There is also an approach using CLI tools written in Go, etc., to convert directly from WordPress export XML files (WXR) to Hugo format.

4.2 Maintaining Permalink (URL) Structure

To carry over your SEO evaluation, it is extremely important to maintain the URLs from your WordPress era. If you had permalink settings like https://example.com/2026/09/13/my-post/ in WordPress, you specify the permalink structure in Hugo’s hugo.toml.

1
2


[permalinks]
 post = "/:year/:month/:day/:slug/"

Alternatively, you can forcibly fix the URL by specifying the url parameter directly in the Front Matter for each article. Furthermore, for pages where the URL changes, set up redirects using the aforementioned aliases.

4.3 Converting Shortcodes

WordPress-specific shortcodes (e.g., [gallery], [caption], proprietary codes of various plugins) often remain as raw strings when exported, so they need to be addressed. These can be bulk-deleted using a replacement script (sed or Python), or migrated so they are rendered properly on the Hugo side by utilizing Hugo’s powerful custom shortcode feature (creating custom layouts in layouts/shortcodes/).

5. Hugo CLI Tools and Build/Deployment

Once the migration work is complete, it’s finally time to build the site using Hugo and publish it to the world. Hugo, provided as a Go binary, boasts astonishing speed, completing builds in just seconds even for sites with thousands or tens of thousands of pages.

5.1 Starting the Local Development Server

When writing articles or adjusting designs, you start a local server.

1
2


# Command to start the development server (-D to include draft articles)
hugo server -D

Running this command allows you to preview the site at http://localhost:1313/. Hugo has a powerful built-in “LiveReload” feature; the moment you edit and save a Markdown file, template, or CSS, the browser screen is automatically and rapidly updated. This makes the writing and development experience far more comfortable than the WordPress admin interface.

5.2 Production Build and Performance Optimization

To generate static files for deploying to a production environment, simply type hugo.

1
2


# Execute production build. --minify option minifies HTML/CSS/JS
hugo --minify

This command outputs the entire site’s files to the public/ directory. By adding the --minify option, unnecessary line breaks and spaces are removed, further reducing file sizes. This directly contributes to reducing the network latency ($T_{network}$) in the mathematical model mentioned earlier.

5.3 Automating Deployment (CI/CD)

Generating static files locally on your PC every time and uploading them via FTP, etc., is inefficient. In modern SSG operations, the best practice is to build a CI/CD environment that automatically builds and deploys triggered by pushes to a Git repository (like GitHub).

For example, the basic structure of a configuration (YAML file) for deploying to Cloudflare Pages or GitHub Pages using GitHub Actions looks like this.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


# Example of .github/workflows/hugo.yml
name: Deploy Hugo site to GitHub Pages

on:
 push:
 branches: ["main"]
 workflow_dispatch:

permissions:
 contents: read
 pages: write
 id-token: write

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v3
 with:
 submodules: recursive # If themes are managed as submodules
 fetch-depth: 0

 - name: Setup Hugo
 uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: 'latest'
 extended: true

 - name: Build
 run: hugo --minify

 - name: Upload artifact
 uses: actions/upload-pages-artifact@v2
 with:
 path: ./public

 deploy:
 environment:
 name: github-pages
 url: ${{ steps.deployment.outputs.page_url }}
 runs-on: ubuntu-latest
 needs: build
 steps:
 - name: Deploy to GitHub Pages
 id: deployment
 uses: actions/deploy-pages@v2

By configuring this, just the action of “writing an article in Markdown and pushing it to GitHub” completes an automated pipeline where the latest site is published to the production environment in a few minutes.

6. Post-Migration SEO and Operational Benefits

Site operators who have completed the migration from WordPress to Hugo often experience the following three prominent benefits.

6.1 Dramatic Improvement in Site Speed and Core Web Vitals

As a result of eliminating database queries and server-side rendering, page load times are reduced to milliseconds. This directly leads to a significant improvement in “Core Web Vitals” (LCP, FID/INP, CLS) scores, which are Google ranking factors. A decrease in user bounce rate and an improvement in SEO evaluation can be expected.

6.2 Freedom from Security Threats

Because WordPress is widely used worldwide, it is constantly a target for attacks. It is always accompanied by risks such as defacement exploiting plugin vulnerabilities and login breaches via brute-force attacks. However, static sites generated by Hugo do not have a database, PHP environment, or even an admin screen (login form). There is no room for hackers to invade the server and rewrite the database, and security risks approach absolute zero.

6.3 Maintenance-Free Operation

Operating WordPress requires constant maintenance work, such as updating the core, updating plugins, and keeping up with PHP versions. You must constantly fear the risk of your site breaking due to compatibility issues. With Hugo, you only need to update the tool itself as necessary, and since the site’s code itself is an independent set of text files, there is an overwhelming sense of security that “it won’t break even if left alone”.

7. Conclusion

In this article, we thoroughly explained the migration from a dynamic CMS like WordPress to the powerful Go-based static site generator “Hugo”, covering everything from technical architecture differences and performance proofs using mathematical models, to specific migration procedures.

While migrating to a static site generator requires an initial learning cost (Git operations, Markdown syntax, executing CLI commands from a terminal, understanding template engine specifications, etc.), it brings returns that more than compensate for it: “overwhelming display speed”, “robust security”, and “maintenance-free” operation.

If your website does not require frequent design changes or complex dynamic processing (such as member-only features or advanced e-commerce functions) and is mainly intended for information dissemination (blogs, media, corporate sites), migrating to Hugo will be one of the most effective technical investments you can make. By all means, use this article as a reference to take your first step towards next-generation website management with Hugo.