移行検証が正しい記事を失敗扱いしないために
この記事について
移行作業では、旧ページを非公開にし、対応するリダイレクトを用意し、生成物から旧ページが消えたことを確かめる。検証スクリプトがこの関係を誤って調べると、問題のない移行まで失敗と報告したり、逆に新しく追加した記事を移行対象と誤認したりする。ここでは、リポジトリにある移行検証の実装から、対象の範囲をどう定義しているかを整理する。
この検証器は、移行対象の一覧、リダイレクト規則、記事のfrontmatter、ビルド出力を照合する。特に重要なのは、移行された記事と、その後に新規作成された記事を区別することだ。すべての記事を同じ条件で扱うのではなく、移行を示すメタデータを持つ記事だけを旧記事として検査する。
検査対象を識別する
実装では、legacyWpId または legacyUrl をfrontmatterに持つ記事を移行元記事として集める。新規記事には通常これらの項目がないため、検査対象から外れる。対象の一覧に記録されたIDと、記事の legacyWpId が対応しているか、旧URLに対するリダイレクトがあるかも確認する。移行元記事がまだ公開扱いになっていないことも検査項目だ。
ローカル検査では、一覧とリダイレクト先の件数を比較し、各移行元URLに対して301の規則が存在するかを確かめる。さらに、ビルド後の出力に旧記事のHTMLが残っていないかを調べる。ホームページ、robots.txt、RSS、リダイレクト定義などの必須ファイルが生成されているかも確認する。
移行一覧 ─┬─ 旧URLと転送先の対応
記事群 ─┤ legacyWpId / legacyUrl の有無
_redirects ─┤ 301規則との一致
ビルド出力 ─┴─ 旧ページが残っていないこと
「赤」を信頼できる条件
移行対象を厳密に数えることは、検証器の誤検知を防ぐ一方で、一覧の件数が変わればエラーになるという運用上の制約も生む。現在の実装は、移行一覧・転送先・移行済み記事をそれぞれ20件として照合する。これは任意のサイトに使える一般設定ではなく、この移行の実データに合わせた検査値である。別の移行に転用する場合は、件数をそのまま流用せず、一覧と検証条件をそろえる必要がある。
また、ローカル検証と公開後の検証は分かれている。--live を付けると、各旧URLが301を返すか、転送先が200を返すかをHTTPで確認する。通常の実行ではローカルのファイルとビルド出力だけを調べる。どちらの検査を通したのかを記録しなければ、「検証済み」という一言が何を意味するか曖昧になる。
検証器も変更対象として扱う
このスクリプトの役割は、移行が正しく行われたかを機械的に判定することだ。そのため、検証器自身が新規記事を誤って移行対象に含めないかも、継続して確認する必要がある。検査対象の識別条件、期待件数、リダイレクト規則、生成物の条件は一組で意味を持つ。どれかだけが更新されると、誤った失敗や見逃しにつながる。
機械検証が赤を出したとき、まず対象が本当に移行済みの記事か、次に何を照合して失敗したのかを読む。検証器を無条件に信じるのでも、赤を無視するのでもなく、判定の根拠となるデータと条件をたどる。移行後の確認を信頼できるものにするには、移行データと同じくらい、検証器の対象範囲を明示しておくことが必要だ。
更新履歴
- 2026-10-10: 初稿作成。リポジトリ内の移行検証スクリプトをもとに構成。