Hugo on KnightLiブログ

Hugo aliases の使い方：古い URL の自動リダイレクトと 404 修正ガイド

Sun, 17 May 2026 20:00:17 +0800

Hugo の aliases は、ページの古い URL に対してリダイレクトを作るための機能だ。

記事の URL を変更したとき、ページを統合したとき、ブログを移行したとき、またはよくある誤った URL を救済したいとき、記事の Front Matter に aliases を追加できる。Hugo はそれらの古いアドレス用にリダイレクトページを生成し、訪問者を現在の記事の新しいアドレスへ送る。これにより、古いリンクがそのまま 404 になるのを避けられる。

aliases が役立つ場面

よくある場面は三つある。

一つ目は記事 URL の整理だ。

たとえば、元の記事 URL が次のようなものだったとする。

`1`	`/posts/tech/2023-01-01-hello/`

後から、より短い URL に変えたい場合がある。

/hello/

このとき、新しい記事に古いアドレスを alias として追加する。すると検索エンジン、外部リンク、SNS 上の古いリンクからも内容へ到達できる。

二つ目はページの統合や移行だ。

複数の古い記事を一つの新しい記事にまとめる場合や、Hexo、Typecho、WordPress などから Hugo に移行する場合、古いプラットフォームの URL 構造は新しいサイトと一致しないことが多い。aliases を使えば、それらの古いアドレスを新しいページへ一つずつ向けられ、移行後の 404 を減らせる。

三つ目はスペルミスの処理だ。

URL を過去に誤って書いたり、外部サイトが間違ったパスにリンクしていたりすることがある。その誤ったリンクにアクセスがあるなら、専用の alias を設定して、ユーザーを正しいページへ誘導できる。

基本的な書き方

記事の Front Matter に aliases フィールドを追加するだけでよい。

YAML の例は次の通り。

---
title: "新しい記事タイトル"
date: 2026-05-17T12:00:00+09:00
url: /new-path/my-new-article/
aliases:
  - /old-path/old-article/
  - ../old-version/
---

ここで /old-path/old-article/ はサイト相対パスだ。../old-version/ は現在のページからの相対パスになる。

実際には、/ で始まるサイト相対パスを優先する方が分かりやすい。直感的で、記事ディレクトリ構造が変わったときにも誤解が起きにくい。

url フィールドとの関係

url は現在ページの新しいアドレスを決める。

aliases は、どの古いアドレスをその新しいアドレスへリダイレクトするかを決める。

例：

1
2
3

url: /new-path/my-new-article/
aliases:
  - /old-path/old-article/

ビルド後、ユーザーが /old-path/old-article/ にアクセスすると、/new-path/my-new-article/ へリダイレクトされる。

記事で url を明示していない場合、Hugo はサイトの permalinks 設定、記事の日付、slug などのルールから現在ページのアドレスを生成する。aliases はその最終的に生成されたページを指す。

Hugo のデフォルト実装

デフォルトでは、Hugo は alias ごとに独立した HTML ファイルを生成する。

その HTML ファイルは通常、次のタグを使う。

`1`	`<meta http-equiv="refresh">`

これにより、ブラウザが古いアドレスを開いたあと自動的に新しいアドレスへ移動する。

この方式はシンプルで、プラットフォームを問わず使いやすく、一般的な静的ホスティングに向いている。ただし本質的にはブラウザ側のリダイレクトであり、サーバーが返す 301 / 302 リダイレクトではない。

小規模サイトなら、通常はこれで十分だ。古いアドレスが開けて、最終的に新しい記事へ到達できるなら、目立つ 404 問題は避けられる。

サーバーサイドリダイレクトを検討する場面

サイトを Netlify、Cloudflare Pages、Vercel など、リダイレクトルールをサポートする環境で運用しているなら、サーバーサイドリダイレクトを検討できる。

サーバーサイドリダイレクトには次の利点がある。

中間の HTML リダイレクトページを返さず、より直接的に応答できる。
301 または 302 ステータスコードを明示しやすい。
大量の移行ルールを集中管理しやすく、監査と保守が楽になる。
SEO 移行をより制御しやすい。

よくある方法は、Hugo のデフォルト alias ページ生成を無効化し、ホスティング環境が必要とするリダイレクトルールファイルを出力することだ。Netlify では _redirects がよく使われ、Cloudflare Pages でも _redirects やプラットフォーム側のルールを使える。

この方針を取る場合は、Hugo の disableAliases とカスタム output format を確認する必要がある。単に aliases を削除してはいけない。そうすると古いリンクはそのまま 404 になる。

aliases を使うときの注意点

第一に、aliases を URL を気軽に変更する口実にしない。

URL は一度公開されると、検索エンジン、RSS、SNS、ブックマーク、外部リンクに入っていく。頻繁な URL 変更は保守コストを生む。aliases は、パスを頻繁に変えるためではなく、過去の問題を修正するために使うのがよい。

第二に、alias の循環を避ける。

古いアドレスは現在の記事の新しいアドレスへ向けるべきだ。A が B に飛び、B がまた A に戻るような構成や、複数ページが同じ alias を奪い合う構成は避ける。

第三に、多言語サイトでは言語プレフィックスに注意する。

Hugo の多言語サイトでは、言語パスが自動処理されることが多い。ある言語版の記事内で alias を書く場合、/en/ や /zh-tw/ のようなプレフィックスを手動で付けなくてよい場合がある。付けてしまうと /en/en/... のような重複パスが生成されることがある。具体的な挙動はローカルビルド結果で確認する。

第四に、変更後は生成ディレクトリを確認する。

alias を追加したら一度サイトをビルドし、public ディレクトリに古いパスに対応する index.html が生成されたか確認する。さらに、その中のリダイレクト先が正しいかを見る。

実用的な確認手順

記事の Front Matter を編集したら、次の流れで確認するとよい。

現在の記事の新しい URL を確認する。
aliases に古い URL を書く。
Hugo ビルドを実行する。
public ディレクトリで古い URL に対応する index.html が生成されたか確認する。
生成された HTML を開き、リダイレクト先が新しい URL か確認する。
多言語ページでは、言語プレフィックスが重複していないか特に確認する。

これで、デプロイ前に多くのパス問題を見つけられる。

まとめ

aliases は、Hugo で古いリンクを扱うための軽量な仕組みだ。

記事 URL の変更、ブログ移行、ページ統合、誤ったパスの修正に向いている。一般的な静的サイトなら Hugo がデフォルトで生成する HTML リダイレクトページをそのまま使える。サイト規模が大きい場合や SEO 移行をより厳密に扱いたい場合は、サーバーサイドリダイレクトルールへ進むとよい。

大事なのは、新しいリンクをきれいにすることだけではない。すでに存在する古いリンクも守ることだ。古い URL を新しいページへ滑らかに連れていけるサイトは、移行やリニューアルで過去の流入を失いにくい。

参考資料

AI を使用して Hugo の多言語ブログを維持するエージェントスキル

Mon, 06 Apr 2026 10:00:00 +0800

Hugo の多言語ブログを維持している場合、頻繁に次のような問題点に遭遇するでしょう。

中国語を作成した後、英語バージョンと繁体字中国語バージョンを同時に生成する必要があります。
3 つの言語ファイルは一貫した構造を持っている必要があります
前付は翻訳され、Hugo 形式に準拠する必要があります

sync-post-translations は、このシナリオ用に設計されたエージェントスキルです。

このスキルはどのような問題を解決しますか?

sync-post-translations のポジショニングは非常に明確です。

index.zh-cn.mdをソースファイルとして取得します
同じディレクトリ内で index.en.md、index.zh-tw.md を生成または更新します
マークダウン構造の一貫性を保つ
前付に明確なルールを適用する (特に date、slug)

適用可能なトリガーワードの例:

「英語と繁体字の同時通訳」
「この記事を英語と繁体字中国語に同期します」

スキルのディレクトリ構造

.\sync-post-translations\
├─ SKILL.md
└─ agents\
   └─ openai.yaml

コアコード 1: SKILL.md

以下は、このスキルのコアルールファイルです。

---
name: sync-post-translations
description: 将 Hugo 文章从简体中文源文件（`index.zh-cn.md`）同步翻译为英文（`index.en.md`）和繁体中文（`index.zh-tw.md`）。当用户提出“en 繁体”“同步翻译英文繁体”或要求同时生成/更新两种语言版本且需保持 front matter 与 Markdown 结构一致时使用。
---

# 同步文章翻译

使用此技能为同一篇文章生成或更新多语言版本。

## 工作流程

1. 在目标文章目录中定位源文件 `index.zh-cn.md`。
2. 读取完整 front matter 与正文内容。
3. 在同目录创建或更新 `index.en.md` 与 `index.zh-tw.md`。
4. 确保三语结构对齐后执行 Hugo 构建检查。

## 翻译规则

1. 严格保留 `slug` 原值。
2. `date` 统一规范为 Hugo 常用带时间格式（RFC3339），示例：`2026-04-05T10:00:00+08:00`。
3. 自然翻译以下 front matter 字段：`title`、`description`、`tags`、`categories`。
4. 保持 Markdown 结构不变：标题层级、列表形态、代码块、链接与命令行示例。
5. 技术标识符保持原样：文件名、CLI 参数、模型名、设备名、URL、包名等。
6. 若 YAML 的 `title` 含有 `:`，必须加引号，避免解析报错。
7. 在不改变语义前提下，使用目标语言自然标点与表达习惯（`en`、`zh-tw`）。

## 输出约定

1. 仅在源文章同目录写入目标文件。
2. 汇报变更的文件路径。
3. 条件允许时执行 `hugo --source . --destination public`，并反馈通过/失败；失败时给出关键报错行。

## 质量标准

1. 全文术语前后一致。
2. 避免机器直译感，优先可发布文风。
3. 章节内容完整，不省略示例、注意点与总结。

コアコード 2: エージェント/openai.yaml

このファイルは、エージェント側のスキルの表示とデフォルトのプロンプト単語を定義します。

interface:
  display_name: "同步文章翻译"
  short_description: "生成或更新 EN + ZH-TW 翻译稿"
  default_prompt: "使用该技能在同一 Hugo 文章目录中，从 `index.zh-cn.md` 生成或同步 `index.en.md` 与 `index.zh-tw.md`，保留 `date` 与 `slug`，保持 Markdown 结构一致，并执行 Hugo 构建校验。"

実際の通話例

1) 人間指向の自然言語トリガー

1
2

请把 content/post/2026/04/06/index.zh-cn.md 同步翻译成英文和繁体，
要求 date 用 RFC3339，slug 不变，最后跑 hugo 校验。

2) 期待される出力

已更新：
- content/post/2026/04/06/index.en.md
- content/post/2026/04/06/index.zh-tw.md

构建校验：
- hugo --source . --destination public
- 结果：PASS

これらのルールが重要な理由

slug は変更されず、URL と過去の外部リンクを安定させることができます。
date RFC3339 (タイムゾーン付き) を統合して、時間解像度における Hugo/トピックの曖昧さを回避します。
Markdown 構造は変更されないため、翻訳されたディレクトリ、コードブロック、ショートコードのレンダリングの位置がずれることを回避できます。
技術識別子は翻訳されないため、「コマンドが使用できない/ファイル名が一致しない」問題が大幅に減少します。

よくある落とし穴と回避策

title に : があっても引用符がない場合、YAML は解析に失敗します。
--flag、URL、パッケージ名を変換すると、サンプルコマンドはそのまま無効になります。
3 つの言語のタイトルレベルは一貫性がなく (たとえば、中国語の ## は英語の ### になります)、ディレクトリアンカーの位置がずれます。
前付を加工せずに本文だけを翻訳すると、ページ一覧やSEO情報が異常になります。

Hugo ショートコードの練習: バンドルファイル (複数言語のファイルと添付ファイルは同じページバンドルディレクトリに配置されます)

Sun, 29 Mar 2026 00:00:00 +0000

多言語サイトでは、記事の本文に同じ添付ファイル (PDF、設定ファイル、スクリプトなど) が含まれることがよくあります。ダウンロードリンクが言語バージョンごとに手動で管理されている場合、後でリンクの不一致やファイルの損失が簡単に発生する可能性があります。

この記事では、この問題を解決するために、直接再利用可能な Hugo ショートコード bundle-file を提供します。

ターゲット

同じ記事の多言語ファイルと添付ファイルを同じページバンドルディレクトリに配置します。次に例を示します。

content/post/2026/03/09/01/
  index.zh-cn.md
  index.zh-tw.md
  index.en.md
  demo.pdf
  script.sh

これにより、リソースの再利用を最大限に高め、重複コピーを減らすことができます。 Hugo がそれを HTML に変換すると、コピーを繰り返すことなく、複数の言語が同じ添付ファイルをポイントできることが期待されます。

ショートコードの実装

ファイル:layouts/shortcodes/bundle-file.html

{{- $name := .Get "name" -}}
{{- $text := .Get "text" | default $name -}}

{{- $res := .Page.Resources.GetMatch $name -}}
{{- if not $res -}}
  {{- range .Page.AllTranslations -}}
    {{- if not $res -}}
      {{- $tmp := .Resources.GetMatch $name -}}
      {{- if $tmp }}{{ $res = $tmp }}{{ end -}}
    {{- end -}}
  {{- end -}}
{{- end -}}

{{- if $res -}}
<a href="{{ $res.RelPermalink }}">{{ $text }}</a>
{{- else -}}
<span>Missing file: {{ $name }}</span>
{{- end -}}

bundle-file の動作は単純です。

現在のページのリソースからのファイルの検索を優先します。
現在の言語が見つからない場合は、他の翻訳ページに移動して、同じ名前のファイルの検索を続けます。
見つかった場合はダウンロードリンクが出力されます。見つからない場合は、見つからないファイル名を入力するよう求められます。

パラメータの説明

name: 添付ファイル名、必須。
text: リンク表示テキスト、オプション。送信されない場合は、デフォルトで name が表示されます。

使用例

`1`	`Missing file: demo.pdf`

text が渡されない場合:

`1`	`Missing file: demo.pdf`

公開前に確認してください

添付ファイルは記事と同じページバンドル内にあります。
name は実際のファイル名とまったく同じです (大文字と小文字を含む)。
リンクをクリックしてローカルでプレビューし、アクセスできることを確認します。

要約する

bundle-file は、多言語記事の添付リンク管理を「パスの手動管理」から「ルールに従った自動検索」に変更します。ナレッジベースや技術ブログの長期メンテナンスの場合、これによりリンクエラー率が大幅に削減され、リリース前のトラブルシューティングのコストが削減されます。

Hugo の Markdown で複雑なテーブルを使用する

Sun, 15 May 2022 00:00:00 +0000

Markdown 構文自体には複雑なテーブルの挿入が含まれていないため、HTML 構文を使用して実現できます。

Hugo で HTML サポートを有効にする

config.yaml
 
markup:
  goldmark:
    renderer:
      unsafe: true

unsafe:
デフォルトでは、Goldmark は生の HTML と潜在的に危険なリンクをレンダリングしません。インライン HTML や JavaScript が大量にある場合は、これをオンにする必要があります。

html構文

複雑なテーブルと単純なテーブルの間には、水平セルの結合と垂直セルの結合という 2 つの大きな違いがあります。 HTML 構文を通じてこれら 2 つの操作を実現する本質は、冗長な空白セルを削除し、特定のセルの Colspan 属性と rowspan 属性を使用して塗りつぶしを拡張することです。

水平方向のセルの結合: 1 つのセルが複数の列のスペースを占めている場合でも、colspan 属性に基づきます。垂直セルの結合: 1 つのセルが複数の行のスペースを占めている場合でも、rowspan 属性に基づきます。

行を結合する

<table>
    <tr>
        <td>列一</td>
        <td>列一</td>
   </tr>
    <tr>
        <td colspan="2">合并行</td>
    </tr>
    <tr>
        <td colspan="2">合并行</td>
    </tr>
</table>

表示効果:

列一	列一
合并行
合并行

列を結合する

<table>
    <tr>
        <td>列一</td>
        <td>列二</td>
   </tr>
    <tr>
        <td rowspan="2">合并列</td>
        <td >行二列二</td>
    </tr>
    <tr>
        <td >行三列二</td>
    </tr>
</table>

表示効果:

列一	列二
合并列	行二列二
行三列二

行と列を結合する

<table>
    <tr>
        <td>列一</td>
        <td>列二</td>
   </tr>
   <tr>
        <td colspan="2">合并行</td>
   </tr>
   <tr>
        <td>列一</td>
        <td>列二</td>
   </tr>
    <tr>
        <td rowspan="2">合并列</td>
        <td >行二列二</td>
    </tr>
    <tr>
        <td >行三列二</td>
    </tr>
</table>

表示効果:

列一	列二
合并行
列一	列二
合并列	行二列二
行三列二

Hugo パーマリンク設定と中国語 URL、スラッグ、SEO の最適化

Sun, 03 Apr 2022 00:00:00 +0000

中国語の URL が SEO に与える影響

現地言語を URL (Uniform Resource Locators) として使用することに関して、John Mueller (Google ウェブマスタートレンドアナリスト) はかつてこの問題に関するビデオを公開しました。

したがって、URL に中国語を使用できますが、中国語の URL は UTF-8 で翻訳されますが、翻訳後の URL 構造は非常に長くて見苦しくなります。例: 中国語の「これは例 1」は、トランスコード後は「%E8%BF%99%E6%98%AF%E4%B8%80%E4%B8%AA%E4%BE%8B%E5%AD%901」になります。

中国語のタイトルを URL として使用する

現在、この方法を使用する人が多くなっていますが、この方法には次のような欠点があります。

タイトルに特殊文字が含まれている場合、Hugo はエラーを報告します。特殊文字を含むファイルを作成できない (「.」文字を含むタイトルなど、Windows 環境でよくある)
タイトルが長すぎる場合、hugo はエラーを報告します。生成されたディレクトリが長さ制限を超えています
検索エンジンが長い中国語のタイトルを解析するとき、意味のない中国語の文字 (「和」、「的」などの漢字、および一部の句読点) が除外されます。したがって、タイトルを URL として使用するのは適切ではありません。

Hugoのパーマリンク設定

config.yamlで設定します

1
2

permalinks:
post: /:year/:month/:day/:slug/

パーマリンクで年、月、日を設定し、スラッグを使用して URL を指定できます。

フロントマターにスラッグを設定する

スラッグを設定すると、Hugo は通常、仕様への準拠をさらに高めるためにスラッグをさらに最適化します。

すべての文字を小文字に変換し、
すべてのスペースを置き換えるには - を使用します
すべての特殊文字を削除します

スラグ最適化の原則

Slug は URL の重要な部分を占めており、これを最適化する必要があります。最適化の原則は次のとおりです。

「和」、「的」などの意味のない漢字や句読点の使用は避けてください。
for、and、if、or などのストップワードの使用は避けてください (検索エンジンによってフィルタリングされます)。
最終 URL はできるだけ短く、スラッグの長さは 3 ～ 5 ワード以内に保つようにしてください。
スラッグにコンテンツのキーワードを含めて、適切なキーワードを選択します

スラグ最適化の利点

検索エンジン結果ページ (SERP) でのランキングを向上させる
ユーザーがページのコンテンツを簡単に予測できるようにします。
観客にとってはより魅力的に映るでしょう。
簡潔な URL によりコンテンツ情報が伝わりやすくなり、SEO にも役立ちます。

検索エンジンは、短くてキーワードが豊富なスラッグを好みます。

検索エンジンは、「for」、「and」、「if」、「or」などの特定の単語を検索結果から除外します。それらはストップワードと呼ばれます。検索エンジンは検索結果を探すときにそれらを重要とはみなさないため、貴重なリソースを消費する URL にそれらを含めても意味がありません。

この記事のスラッグ設定:

`1`	`slug: Hugo permalinks 中文URL slug SEO优化`

Hugo 記事 (MD ファイル) のディレクトリ構成

Fri, 25 Mar 2022 00:00:00 +0000

Hugo の通常のディレクトリ構造

一般的な例は次のとおりです

content/
└── post
    ├── chinese-test
    │   ├── florian-klauer-nptLmg6jqDo-unsplash.jpg
    │   ├── helena-hertz-wWZzXlDpMog-unsplash.jpg
    │   ├── hudai-gayiran-3Od_VKcDEAA-unsplash.jpg
    │   ├── index.zh-cn.md
    │   └── luca-bravo-alS7ewQ41M8-unsplash.jpg
    ├── emoji-support
    │   ├── index.md
    │   └── the-creative-exchange-d2zvqp3fpro-unsplash.jpg
    ├── markdown-syntax
    │   ├── index.md
    │   └── pawel-czerwinski-8uZPynIu-rQ-unsplash.jpg
    ├── math-typesetting
    │   └── index.md
    ├── placeholder-text
    │   ├── index.ar.md
    │   ├── index.md
    │   └── matt-le-SJSpo9hQf7s-unsplash.jpg
    └── rich-content
        └── index.md

上に示すように、md ファイルは content/post ディレクトリに保存されます。各記事にはディレクトリがあります。記事内で使用されている画像とMDファイルは同じディレクトリに配置されています。記事数が少ない場合にはこの構造でも大きな問題はありませんが、ブログを書く時間が長くなり記事数が増えてくると、投稿ディレクトリ内のディレクトリが多くなり、探すのが面倒になってきます。次のディレクトリ構造が使用できます

時間ごとに分割されたディレクトリ構造

content/
└── post
    ├── 2020
    │   ├── 1.zh-cn.md
    │   ├── 1.zh-tw.md
    │   └── 2
    │       ├── 1.jpg
    │       ├── 2.jpg
    │       ├── 3.png
    │       ├── index.zh-cn.md
    │       ├── index.zh-tw.md
    │       └── 4.png
    ├── 2021
    │   ├── 1.zh-cn.md
    │   ├── 1.zh-tw.md
    │   ├── 2.zh-cn.md
    │   ├── 2.zh-tw.md
    │   ├── 3.zh-cn.md
    │   ├── 3.zh-tw.md
    │   ├── 4.zh-cn.md
    │   ├── 4.zh-tw.md
    │   ├── 5.zh-cn.md
    │   └── 5.zh-tw.md
    └── 2022
        ├── 1.zh-cn.md
        ├── 1.zh-tw.md
        └── 2
            ├── 1.png
            ├── 2.png
            ├── 3.png
            ├── 4.png
            ├── 5.png
            ├── 6.png
            ├── 7.png
            ├── 8.png
            ├── 9.png
            ├── index.zh-cn.md
            └── index.zh-tw.md

上に示すように

post ディレクトリの下に、まず年に基づいてサブディレクトリを作成します。もちろん、更新頻度が高い場合は、年/月または年/月/日に基づいて第 1 レベルのディレクトリを作成することもできます。
画像のない記事は年月日ディレクトリに直接保存されます。
画像がある場合は、追加の第 1 レベルのディレクトリを作成します。 md ファイルの名前は、index.lang.md です (他の名前のファイルを使用すると、画像は表示されません)。画像は同じディレクトリに配置されます。
さまざまな言語の MD ファイルがまとめられ、index.zh-cn.md、index.zh-tw.md などのさまざまなindex.lang.md によって区別されます。

WordPress から Hugo に移行する方法

Wed, 23 Mar 2022 00:00:00 +0000

移行する理由

wordpressのWeb MDエディターは機能が比較的弱く、使用中に問題が発生しやすく、編集内容が失われやすいです。 Hugo では、より効率的な独自のローカル MD エディターを選択できます。
WordPress イメージは、最初にアップロードしてから、md ファイル内で参照する必要があります。 Hugo はディレクトリに配置することで直接参照できます。
WordPress はデータベースと PHP をインストールする必要がありますが、サーバーに高い要件があり、メンテナンスが面倒です。

移行プロセス

Hugoをインストールする

https://gohugo.io/getting-started/quick-start/ インストールして初期設定を完了する

ワードプレスのMDファイルをエクスポートする

この https://github.com/SchumacherFM/wordpress-to-hugo-exporter エクスポートを使用します

WordPress プラグインディレクトリ wp-content/plugins/ に、「WordPress to Hugo Exporter」のソースコードを直接クローンします。

1
2
3

$ git clone https://github.com/SchumacherFM/wordpress-to-hugo-exporter.git
$ cd wordpress-to-hugo-exporter
$ php hugo-export-cli.php

このコマンドは、hugo-export.zip ファイルをローカルに生成します。

ファイルを解凍すると、主に次の部分が含まれます。

config.yaml: Hugo の設定ファイル、これを書き換えます
photos: このディレクトリにはすべてのブログ投稿があります。全てMDファイルです。ファイル名には日付が付いているので、日付順に並べ替えることができます。
wp-content: このディレクトリは主にアップロードディレクトリであり、以前にアップロードされたすべてのメディアファイルが含まれます。 WordPress は年と月ごとに分けて保存されます。他のページも作成している場合は、他のページ名のディレクトリがあり、そこには MD ファイルも含まれています。

MD ファイルを表示すると、記事のタイトル、作成者、作成時刻、URL アドレス、分類、タグ、その他の情報を含む YAML 部分が先頭に表示されます。概要情報もありますが、通常、Hugo テーマは「抜粋」概要を認識しません。これを「説明」に変更すると、この部分が Web サイトのページヘッダーの「メタ説明」のコンテンツになります。これでエクスポート作業は完了です

MDファイルをインポートする

通常、エクスポートされたファイルは /content ディレクトリに配置されます。詳細については、テーマのドキュメントを参照してください。テーマの選択は https://themes.gohugo.io/ です。

ウェブサイトを生成してアップロードする

1
2

hugo
rsync -azv public/ root@youre_server_ip:/your/folder/

Hugo on KnightLiブログ

Hugo aliases の使い方：古い URL の自動リダイレクトと 404 修正ガイド

aliases が役立つ場面

基本的な書き方

url フィールドとの関係

Hugo のデフォルト実装

サーバーサイドリダイレクトを検討する場面

aliases を使うときの注意点

実用的な確認手順

まとめ

参考資料

AI を使用して Hugo の多言語ブログを維持するエージェント スキル

このスキルはどのような問題を解決しますか?

スキルのディレクトリ構造

コアコード 1: SKILL.md

コアコード 2: エージェント/openai.yaml

実際の通話例

1) 人間指向の自然言語トリガー

2) 期待される出力

これらのルールが重要な理由

よくある落とし穴と回避策

Hugo ショート コードの練習: バンドル ファイル (複数言語のファイルと添付ファイルは同じページ バンドル ディレクトリに配置されます)

ターゲット

ショートコードの実装

パラメータの説明

使用例

公開前に確認してください

要約する

Hugo の Markdown で複雑なテーブルを使用する

Hugo で HTML サポートを有効にする

html構文

行を結合する

列を結合する

行と列を結合する

Hugo パーマリンク設定と中国語 URL、スラッグ、SEO の最適化

中国語の URL が SEO に与える影響

中国語のタイトルを URL として使用する

Hugoのパーマリンク設定

config.yamlで設定します

フロントマターにスラッグを設定する

スラグ最適化の原則

スラグ最適化の利点

検索エンジンは、短くてキーワードが豊富なスラッグを好みます。

この記事のスラッグ設定:

Hugo 記事 (MD ファイル) のディレクトリ構成

Hugo の通常のディレクトリ構造

時間ごとに分割されたディレクトリ構造

WordPress から Hugo に移行する方法

移行する理由

移行プロセス

Hugoをインストールする

ワードプレスのMDファイルをエクスポートする

MDファイルをインポートする

ウェブサイトを生成してアップロードする

AI を使用して Hugo の多言語ブログを維持するエージェントスキル

Hugo ショートコードの練習: バンドルファイル (複数言語のファイルと添付ファイルは同じページバンドルディレクトリに配置されます)