Markdown記事を公開するときは、本文と同じくらい公開後に戻せる状態を確認します。front matterが崩れている、slugが変わっている、画像やリンクが壊れている、公開後に戻せない状態では、サイト運用としては不十分です。

Markdownの良さは、ファイルとして差分を見やすく、人もAIエージェントも同じ構造を確認しやすいところにあります。本文だけでなく、公開URLやfront matterの情報も記事データとして扱います。カテゴリ、関連リンク、公開状態まで同じ構造で持たせることが大切です。

Markdown記事は本文ではなく構造化された記事データとして扱う

Markdown本文は、記事の一部です。公開サイトで記事として機能させるには、本文以外の情報も必要になります。

titleは検索結果や記事ページで内容を判断する材料になります。descriptionは、読者が読むべきページかどうかを決める補助になります。category、tags、related_linksは、一覧表示や関連記事に関わります。draftは公開制御に関わります。

これらを人の記憶で運用すると、記事が増えたときに壊れます。だから、記事ごとに同じ場所へ同じ形で持たせます。Markdown記事では、その役割をfront matterが担います。

ファイル配置、slug、front matterを先に固定する

最初に決めるのは、本文の書き方ではなく、ファイルの置き場所、命名規則、front matterの項目です。ここが揺れると、公開URL、一覧表示、関連記事、検査のすべてが不安定になります。

記事ファイルは決まったディレクトリに置きます。slugは小文字英数字とハイフンで固定します。公開済み記事のslugは、リライトの都合で安易に変えません。URLが変わると、内部リンク、外部リンク、サイトマップ、検索結果からの到達に影響します。

front matterは、最低限次のような項目を持たせます。

---
title: "記事タイトル"
description: "本文固有の答えが分かる説明"
date: 2026-06-03
category: ウェブサイト運用
tags: [Markdown, CMS]
related_links: [website-release-checklist]
draft: false
---

dateは初回公開日として扱い、リライトのたびに安易に変えません。titleやdescriptionも、検索結果で読者へ約束している情報です。本文変更のついでに軽く扱わず、変更が必要な場合は理由を残します。

直接回答を書いてからMarkdown構造へ整える

執筆時には、本文の自然さとMarkdown構造を分けて考えます。最初から見出しの型に流し込むと、記事らしい形にはなっても、答えが弱くなることがあります。

先に、読者の問いに普通の会話として答えます。そのあとで、必要な見出し、表、箇条書き、内部リンクへ整えます。見出しは作業区分ではなく、読者が答えを探すための案内として付けます。

AIエージェントを使う場合も同じです。短いメモを項目ごとに膨らませるのではなく、直接回答、根拠、事実確認、見出し化の順に分けます。Markdown構造は、答えを分かりやすく届けるための形であり、答えの弱さを隠すものではありません。

機械検査と人のレビューは見る対象が違う

公開前には、機械検査と人の確認を分けます。どちらか片方では足りません。

機械検査では、ルールで判定できるものを見ます。front matterの必須項目、titleの禁止記号、draft、リンクを確認します。関連記事、Markdown構文、noindex設定も機械的に検査しやすい項目です。CommonMarkのような仕様に沿って構文を扱えることは、機械検査と相性がよい部分です。

人のレビューでは、問いに答えているか、断定に根拠があるか、既存記事と重複していないか、読者が次に進めるかを見ます。構文が正しくても、読者の判断に役立たない記事は公開対象になりません。titleやdescriptionを直す場合も、検索結果で読者が内容を判断する情報なので、Google検索セントラルのタイトルリンクの考え方を踏まえて軽く扱わないようにします。

公開後に戻せるよう変更履歴を残す

Markdownはファイルなので、どこを変えたかを比較しやすい形式です。この利点を活かすには、公開後に戻せる運用まで考えておく必要があります。

公開後に誤った情報が見つかった、front matterのミスで一覧に出ない、画像パスが壊れた、リンク先を間違えた。こうした問題が起きたとき、いつの状態へ戻すか判断できるようにします。

変更履歴には、いつ、何を、なぜ変えたかを残します。Gitを使う場合も、別のバックアップ方式を使う場合も、戻す判断に必要なのは同じです。差分、理由、公開後の確認結果が分かることです。

URL変更はリダイレクト、内部リンク、サイトマップまで確認する

Markdown記事の運用で特に慎重に扱うべきなのが、URL変更です。slugを変えると、公開URLが変わります。本文を直す感覚でslugを変えると、読者も検索エンジンも古いURLから新しいURLへたどれなくなります。

URL変更が必要な場合は、旧URLと新URLの対応を作ります。リダイレクト、canonical、内部リンク、サイトマップを確認します。noindexやX-Robots-Tagを使う運用なら、robots metaタグの公式資料も確認します。公開後には、実際に旧URLから新URLへ移動できるかも見ます。

公開後に戻す工程まで決めておくと、Markdown運用は安定します。URL変更を伴う場合は、Google検索セントラルのサイト移転ガイドで旧URLと新URLの対応や監視の考え方も確認します。そこまで決めておくと、AIエージェントも人も、同じ構造を見ながら安全に記事を更新できます。