WordPressからHugoへ移したあと、デザインを詰める段になって手が止まりました。表示するデータが入っていないと確認できない画面があるからです。
デザインを詰めるにはダミー記事が要ります。ただし content/ へ置けば本番のビルドにも出るので、消し忘れれば公開されます。注意して運用するのではなく、消し忘れても公開されない形にすることにしました。
この記事では、確認用のダミー記事を本番のコンテンツと別の場所へ置き、確認するときだけ読み込む形にした過程を書きます。あわせて、本番のビルドに混ざっていないことを実際に確かめる方法もまとめます。確認したのはHugo v0.164.0（2026年7月時点）です。
「Hugo移行記」のうち、移行後のデザイン確認環境を扱う記事です。先行記事を読まなくても、この記事だけで分かるように書いています。
まず全体像
データが入っていないと確認できない画面がある
デザインを組んでいて判断できなかったのは、次の4つです。
- トップページの記事カードが並んだときの間隔
- 記事一覧が複数ページにわたったときの見え方
- ショート欄に投稿が積み上がったときの高さ
- タグで絞り込んだときの結果の見え方
どれも、そこへ表示するデータがないと決められません。実際のコンテンツが揃うのを待つ方法もありますが、それでは待っている間デザインを直せません。確認用のデータを自分で用意することにしました。
ダミーを content/ に置かないと決めた
最初に考えたのは、content/posts/ にダミー記事を作り、draft: true を付けておく方法です。これなら本番のビルドには出ません。
やめた理由は2つあります。
-
公開状態をフォルダの場所で決める方針にしていたことです。このブログでは、記事に
draftフラグを書かず、content/drafts/からcontent/posts/<年>/へフォルダを移すことで公開します。ダミーのためだけにフラグを併用すると、公開状態を表す仕組みが2つになります。 -
フラグの付け外しが手作業になることです。ダミーはデザインを詰めている間に何度も書き換えるため、そのうちの1回でフラグを消せば本番に出てしまいます。仕組みではなく注意力に頼ることになります。
そこで、mock/ というフォルダをサイトのルート直下に作り、ダミー記事もダミー用の部品もすべてそこへ入れました。ダミー記事もダミー用の部品も、content/ の中には最初から存在しません。
確認するときだけ重ねて読む
Hugoには、起動時に選ぶ環境ごとに設定を分ける仕組みがあります。config/mock/ に設定を置き、--environment mock を指定したときだけ読む形にしました。
config/mock/hugo.toml の中身は、これだけです。
[module]
[[module.mounts]]
source = 'content'
target = 'content'
[[module.mounts]]
source = 'mock/content'
target = 'content'
[[module.mounts]]
source = 'assets'
target = 'assets'
[[module.mounts]]
source = 'mock/assets'
target = 'assets'
module.mounts は、実際のフォルダをHugoから見た位置へ割り当てる設定です。ここでは content と mock/content の両方を、Hugoにとっての content として重ねています。CSSとJavaScriptを置く assets も同じ形で重ねました。
確認するときは、環境を指定して起動します。
hugo server --environment mock
通常の hugo server や本番の hugo では config/mock/ の設定を選びません。そのため、mock/content と mock/assets は読み込み対象にならず、ダミー記事の側へ公開除外の設定を書かなくても本番から外れます。
執筆中の下書きも一緒に見たいときは、下書きを生成対象へ加える -D（--buildDrafts）を足します。この指定は content/drafts/ の未公開記事にも効きます。
公開予定日が未来の記事も見る場合は、未来日付を生成対象へ加える -F（--buildFuture）も必要です。ダミーだけを見たいときは、どちらも付けません。
ダミー記事の本文には、冒頭に「※これはデザイン確認用のダミー記事です。」と書いています。画面で見たときに実物と取り違えないためと、あとで説明する検査の目印にするためです。
混ざっていないことを実際に確かめた
設定で分けただけでは、意図どおりに動いているか分かりません。両方の生成を行って中身を比べました。
空の出力先を2つ用意し、通常と確認用を分けてビルドします。
New-Item -ItemType Directory ../public-normal-check, ../public-mock-check
hugo --destination ../public-normal-check
hugo --environment mock --destination ../public-mock-check
最初に、ダミーの目印を含むHTMLがあるか調べます。
$marker = '※これはデザイン確認用のダミー記事です。'
$normalMarker = Get-ChildItem ../public-normal-check -Recurse -Filter *.html -File |
Select-String -SimpleMatch $marker
$mockMarker = Get-ChildItem ../public-mock-check -Recurse -Filter *.html -File |
Select-String -SimpleMatch $marker
[bool]$normalMarker # False
[bool]$mockMarker # True
次に、配色比較用の一時ページと、そのページだけで使うCSSのクラス名 .accent-comparison を調べます。
Test-Path ../public-normal-check/dark-accent-comparison/index.html # False
Test-Path ../public-mock-check/dark-accent-comparison/index.html # True
$normalCss = Get-ChildItem ../public-normal-check -Recurse -Filter *.css -File |
Select-String -SimpleMatch '.accent-comparison'
$mockCss = Get-ChildItem ../public-mock-check -Recurse -Filter *.css -File |
Select-String -SimpleMatch '.accent-comparison'
[bool]$normalCss # False
[bool]$mockCss # True
通常の生成では、ダミーの目印、一時ページ、専用CSSの3つがすべて見つかりませんでした。確認用の生成では、3つとも見つかりました。コンテンツと部品の両方について、mock/ が本番へ混ざっていないことを確認できます。
この比較は、設定を触ったあとに毎回やり直せる形にしておくのが大事だと思っています。混入は、設定を書き換えたときに起きるからです。
一時的な比較ページも同じ場所へ隔離した
mock/ に入れているのは、ダミー記事だけではありません。
ダークモードのアクセント色を見比べるための一時的なページも、mock/content/ に置いています。このページでしか使わないCSSとJavaScriptは mock/assets/ に分けました。先ほどの設定で assets も重ねているのは、このためです。
配色を決めたあと、比較ページは役目を終えます。mock/ の中にあれば、消し忘れても公開されません。一時的なものを置く場所ができたので、比較のために本番側のフォルダへ手を入れる必要がなくなりました。
まとめ
やったことは、確認用のコンテンツと部品を mock/ へ隔離し、--environment mock を指定したときだけ読み込む形にしたことです。
判断の中心は、draft: true を使わなかったところにあります。フラグでも本番から外せますが、外れているかどうかが人の操作に依存します。読み込む場所そのものを分ければ、確認用の設定で起動しない限り混ざりません。
mock/ は今後も残す予定です。新しい画面や新しい一覧を作るたびに、そこへ表示するデータが要るからです。その画面が実際に使われ始めて初めて、本物のコンテンツで確かめられるようになります。