内容確認を終えたMarkdown記事があっても、そのファイルを置くだけでは公開準備が整ったとはいえません。どのメタデータをCMSが読み、どのURLへ表示するのかを確かめる必要があります。問題が起きたときに戻す版も、公開前に特定しておきます。
この記事で扱うのは、slugと公開URLを変えない一記事の更新です。元ファイルから実URLまでの対応を記録し、ソースと表示結果を別々に検査します。戻す版を識別し、必要なファイルを取り出せることが復旧の準備になります。実際に戻ったかどうかは、復旧後の公開ページで判断します。
slugや公開URLを変える場合や、共通テンプレートまで触る場合は影響範囲が広がります。そのときは、Webサイト公開前後のチェックリストで変更全体の中止条件と戻し方を決めます。
Markdownだけでは記事の公開仕様は決まらない
Markdownが定めているのは、見出しやリンクなどをどのような記法で表すかです。記事の公開状態やURLまで決める共通仕様ではありません。
CommonMarkは、Markdownのブロック構文とインライン構文の解析方法を規定しています。一方で、記事冒頭に置くメタデータ領域であるfront matterは規定していません。---で囲まれた部分が常にfront matterとして読まれるわけでもありません。
front matterの形式と項目の意味は、利用するCMSやサイトジェネレーターによって変わります。Jekyllはファイル冒頭のYAML front matterを扱います。HugoはYAML以外のメタデータ形式にも対応しています。同じ draft や日付に見える項目でも、処理系が違えば公開条件まで同じとは限りません。
たとえば、このサイトの記事URLはMarkdownのファイル名から決まります。front matterへ別のslugを書けばURLが変わる仕組みではありません。メタデータも独自の簡易処理で読み取っており、YAMLで書けるすべての形式に対応しているわけではありません。
使っているCMSがどの場所のファイルを読み、どの項目を公開条件に使うかで検査対象が決まります。日付の未設定や下書き指定がどう扱われるかも、そのCMSの仕様に沿って判断する必要があります。
一記事の変更範囲と公開URLを先に固定する
公開作業を始める前に、今回変える一記事と、変えないものを分けます。対象が曖昧なままでは、検査が通ってもどこまで確認したのか分かりません。
対象ファイルと公開URLの対応を残すと、別の記事を検査したまま公開する取り違えを防ぎやすくなります。画像も同時に差し替えるなら、その画像まで今回の変更に含まれます。本文だけの更新と、表示の仕組みまで変える更新では、確認する範囲も戻すファイルも異なります。
ファイル名がslugになる仕組みでは、ファイル名の整理もURL変更につながります。URLを変える必要が生じた場合は、この記事の更新手順から切り離して移行を設計します。旧URLからの転送先や内部リンクを含む確認が必要になるため、本文の差し替えだけでは完了しません。
タイトルも自動的な変更対象にはしません。意味を明確にする軽微な修正であっても、変更前後と理由を記録します。中心となる問いまで変わるなら、同じURLの更新として進めない判断が必要です。
ソースではCMSが読む内容を検査する
Markdownファイルから判断できることと、HTMLへ変換した後にしか分からないことは別です。確認項目を一つにまとめると、構文が正しいだけで公開へ進みやすくなります。
ソースの検査では、CMSがfront matterを読み取れることに加え、公開状態や日付が予定と合っているかを調べます。項目が存在していても、CMSが認識しない形式なら期待した設定にはなりません。関連記事のslugや画像の参照先についても、文字列が書かれていることと、実際に参照できることは別です。
raw HTMLの扱いも処理系に依存します。CommonMarkはraw HTMLを構文として扱いますが、公開時に許可するか、無害化するかはレンダラー側の設計です。外部から受け取った内容を扱う場合は、使用中の処理でどのように出力されるかを確かめます。
表示結果では公開URLに出る内容を確認する
表示結果では、原稿の内容がHTMLへどう変換されたかを見ます。本文や見出しだけでなく、ページのtitleとdescriptionも照合の対象です。画像の読み込みやリンク先は、原稿を読むだけでは見落とすことがあります。
たとえば「料金を見る」というリンクが、誤って会社概要ページを指しているとします。Markdownのリンク構文は正しく、リンク先も存在するため、それらの検査だけでは意図の違いを見つけられません。表示されたリンクを開き、料金の説明へ進めるかまで確かめる理由はここにあります。これは検査の違いを示す仮定例です。
関連記事や一覧ページがfront matterを使うなら、記事詳細だけでなく、その掲載結果まで確認します。canonicalや構造化データを出力する仕組みでは、期待する公開URLと一致しているかも見ます。
AdRegionでは記事単体と公開記事群を分けて検査する
このサイトでは、記事単体の検査と、公開記事群の検査を別々に実行しています。これはMarkdownの共通仕様ではなく、AdRegionの現在の実装です。
記事単体のlintでは、front matterの存在と一部の項目を文字列として検査します。front matterの構文や型を完全に検証するものではありません。公開状態やカテゴリのほか、タイトルの表記と見出し直下の文章を確認します。
公開記事群の検査では、関連記事からの入口や参照先を調べ、サイトマップに含まれる記事数も照合します。ただし、件数が合っていることだけでは各URLの正しさまで保証できません。Markdownソースに検索除外の指定であるnoindexを付ける処理も検査対象ですが、コード内の指定を読む検査と、本番のHTTP応答で実際の指定を見る検査は別です。
記事単体の検査を通っても、公開記事群の検査で存在しない関連記事や公開数の不一致が見つかることがあります。反対に、サイトマップへURLが入っていても、本文が読者の問いに答えている保証にはなりません。機械検査の役割を分けると、通過した検査の意味を取り違えずに済みます。
公開する版と戻す版を同時に決める
復旧に備えるには、「履歴がどこかにあるはず」という認識では不十分です。公開する版と、異常時に戻す版を識別でき、必要なファイルを実際に取り出せることが前提です。
Gitを使う場合は、必要なファイルが記録されたコミットやタグなどを指定します。Gitでは、ステージした変更をコミットに記録します。未追跡のファイルや、まだコミットしていない変更まで、その版に自動的に保存されるわけではありません。
記事の画像が別の場所にあるなら、その画像も戻せるかを確かめます。外部サービス上の素材や、CMSの外にある設定は、Markdownファイルを戻すだけでは復旧しません。今回の一記事に必要なものを版管理へ含めるか、別のバックアップを対応付けます。
Gitを使わない運用でも、変更前のファイルと必要素材を取り出せるバックアップがあれば復旧元にできます。大切なのは製品名ではなく、戻す版の識別子と保管場所を公開前に確かめることです。確認できなければ、復旧可能とは記録しません。
記録は元ファイルと公開URLの対応を残す
既存の公開履歴や変更管理の記録があれば、別の長いチェックシートを作る必要はありません。対象ファイルと公開URLに、公開した版と戻す版を対応付けておくと、不具合が出たときに変更の範囲を追えます。検査結果には、ローカルの表示を見たのか、本番URLの応答まで見たのかも残します。
「変更前の版」と「戻す版」は同じになることが多いものの、必ず同じとは限りません。変更前の状態に既知の問題があれば、正常と確認できた別の版が候補になります。ただし、その後に追加された必要な内容まで失わないかを含め、戻す範囲の判断が必要です。
戻すファイルを取り出せなかった場合は、その不足を記録へ残します。「バックアップあり」という名前だけで、復旧の準備ができたことにはできません。
実URLでソースどおりに表示されたか確かめる
プレビューが正しくても、本番の実URLが同じ結果になるとは限りません。公開後は、対象ファイルに対応するURLを直接開きます。
ページが正常な内容を伴う応答を返しているかが、本番確認の出発点です。Google検索の技術要件でも、ページが正常に動作し、インデックス登録可能な内容を持つことが前提とされています。ただし、条件を満たしたからといってインデックス登録が保証されるわけではありません。
プレビューとの照合では、本文の変更箇所に加えてtitleとdescriptionが同じ内容になっているかを見ます。本番で初めて画像の読み込みやリンク先に問題が出ることもあるため、表示と遷移も確認の対象です。宣言したcanonicalは、期待する公開URLと比べます。
canonicalは検索エンジンへの強いシグナルですが、命令ではありません。Googleのcanonicalに関する説明でも、最終的に別のURLが選ばれる場合があると示されています。ここで確認するのは、サイト側の宣言が設計どおりかどうかです。
一覧や関連記事に出る設計なら、その入口から同じ記事へ移動できるかも確かめます。異常が見つかった場合に修正を続けるか復旧するかは、公開チェックシートの条件に従います。判断結果と対象となった版を公開・復旧記録へ戻します。
復旧後も同じ実URLをもう一度確認する
戻す版を配置しただけでは、復旧は終わりません。ソース、表示結果、実URLの順にもう一度確かめます。
復旧したファイルの検査が通ったら、レンダリングした表示と同じ本番URLを照合します。キャッシュや生成物が残る仕組みでは、元ファイルだけが戻り、公開ページは変わっていない場合があります。画像も変更していたなら、本文だけを戻しても変更前の表示は再現できません。
同じURLへ内容を戻しても、検索結果の表示まで直ちに元へ戻るとは限りません。検索エンジンによる再取得や処理は別に進みます。復旧完了は、まず自社が管理できるソースと公開ページの対応で判断します。