CMS移行のテスト方法｜見た目が同じでも、裏側だけ壊れていたことがある

「移行が終わりました」という報告を見て、実際にページを開き、見た目に問題がないことを確認して安心する。
これだけで完了にしてしまうと、あとで痛い目を見ることがある。
私が何度か経験したのは、画面にはまったく異常がないのに、裏側の情報だけが壊れているケースだった。
見た目のテストと、移行のテストは、実は別物だと思う。
今日はその違いを、実際にあった2つの不具合をもとに書いておきたい。
どちらも派手な事故ではなく、気づかれないまま静かに続いていたタイプの不具合だった。

見た目が正常でも、移行が終わったとは言えない理由

ブラウザで開いて表示が崩れていないか、リンクが切れていないかを確認するのは、移行テストの入口でしかない。
ページの裏側には、canonicalタグやog:type、構造化データのように、ユーザーの目には触れないが検索エンジンやSNSのクローラーだけが読んでいる情報がある。
この部分は画面を100回眺めても気づけない。
HTMLのソースを開いて、該当のタグを1行ずつ確認しないと、壊れていることにすら気づけない種類の不具合だからだ。
移行作業のチェックリストに「表示確認」としか書いていない現場は、実は少なくないと思う。
特に会社のサイトを移行するときは、公開直前の数日はデザインや文言の確認に手も目も取られがちで、こうした裏側の情報は後回しになりやすい。

実例1：ページ送りのcanonicalが、13ページとも1ページ目のURLになっていた

以前、検索コンソールで「重複しています」という申告が並んでいるのを見つけたことがある。
調べてみると、一覧ページの2ページ目から14ページ目まで、canonicalタグの中身が全部1ページ目の入口URLを指していた。
原因は、canonicalを組み立てる処理がページ番号のクエリを丸ごと落としてしまい、常に1ページ目のURLだけを返していたことだった。
つまりGoogleからすれば、13ページ分がそれぞれ独立したページではなく、「1ページ目の重複」として届いていたことになる。
画面上ではページ送りは普通に機能していて、2ページ目を開けば2ページ目の記事一覧がちゃんと表示される。
だから運用担当も、記事を書いている側も、誰も気づかないまま長い期間が過ぎていた。
実際に気づいたきっかけは、2ページ目を開いてソースコードのcanonicalタグを1行ずつ目で追ったときだった。
見た目の動作確認だけをどれだけ丁寧にやっても、この不具合には最後までたどり着けなかったと思う。
いつから13ページ分が重複扱いになっていたのか、正確な期間までは分からない。
ただ検索コンソールの申告件数から逆算すると、少なくとも数か月は気づかれずに動いていたはずだ。

実例2：og:typeがトップと記事ページで逆になっていた

もう一つ、長く気づかれなかった例がある。
本来はトップページがwebsite、個々の記事ページがarticleになっているべきところ、実装ではこの2つが逆になっていた。
この状態のまま、本番環境が長期間動いていた。
SNSでシェアしたときのカード表示や、検索エンジンがページの種類をどう認識するかに関わる部分だが、普段の閲覧では絶対に目に入らない情報だ。
ページを開いて見出しや画像が正しく出ていれば、誰も疑わない箇所でもある。
このバグも、トップと下層の両方でog:typeの値を実際に見比べて、初めて存在が分かった。
1つのページだけを見ていたら気づけず、複数のページ種別を横並びで比較して、ようやく「逆になっている」という違和感にたどり着いた。
この差がどれだけ検索順位やシェア数に影響していたのかまでは追い切れていない。
それでも、気づかないまま放置していい種類の違いではないと思う。

なぜ「見た目のテスト」だけでは気づけないのか

ブラウザで表示を確認する作業は、人間が見る画面が正しいかどうかしか教えてくれない。
canonicalもog:typeも構造化データも、人間向けではなく機械向けの情報だ。
見た目のテストを何度繰り返しても、この種類の不具合は検出できない。
むしろ「表示は正常だった」という安心感が、裏側を確認しないまま公開してしまう判断を後押ししてしまうことすらある。
私はこの経験をしてから、「表示されているか」と「正しい情報が出力されているか」を、はっきり別のチェック項目として扱うようにしている。

私が実際に見ている検証項目

いまは移行やデータ投入のたびに、次の5つを必ず確認している。
1つ目は、新旧のデータ件数が一致しているかという単純な数の確認。
2つ目は、複数のテーブルに同じ内容を書き込む処理があるとき、その内容が完全に一致しているかをMD5でハッシュ比較すること。
3つ目は、実際にページをHTTPで取得して200が返ってくるか、本文が二重にエスケープされて「

」のような記号がそのまま画面に表示されていないかの確認。
4つ目は、生成した文章にハングルやキリル文字といった想定外の文字が混ざっていないかを、全文を対象に機械的に検査すること。
5つ目が、canonicalやmeta robotsといった、画面には出てこない情報を実測で確認する作業になる。
どれも地味な作業だけれど、この5つを通すのに実際にかかる時間は、1件あたり5分もかからない。
毎回すべてに引っかかるわけではないが、5つのうちどれか1つでも省くと、そこが次の見落としになる。
この5つは特別な機会だけでなく、毎日の記事投稿のたびに欠かさず通していて、これまでに数百件単位のデータをこの手順で確認してきた。
件数が積み重なるほど、たまにしか起きない見落としも、いずれ必ず1回は起きるものだと実感するようになった。

検証を増やすと移行は遅くなるのか

最初はこの手順を面倒に感じていた。
でも実際に数字にしてみると、5分の確認と、13ページ分のcanonicalを後から直す作業とでは、かかる時間も影響範囲もまったく釣り合わない。
気づかれないまま数か月動き続けたバグを直すほうが、検証の手間よりずっと高くつくと今は思っている。
移行やデータ投入の作業に検証の時間を組み込んでおくのは、作業を遅くするための工程ではなく、あとで払う代償を先に小さくしておく工程だと考えている。
急いで公開して1週間後に気づくより、公開前の5分で気づいたほうが、結局は早く終わる。

移行のテストで最後に見ておきたいこと

移行の直後にすべてが正しく見えても、それで終わりにはしていない。
数日から1週間ほど経ってから、実際にクロールが来ているか、インデックスの状態がどう動いているかも合わせて確認したい。
表示・データ・裏側の情報・その後の検索エンジンの反応という4つの段階で見ていくと、移行のあとに気づかれないまま残るものはかなり減らせると思う。
逆に言えば、この4段階のどこか1つでも省略すると、今回のような不具合が同じように紛れ込む余地が残ると思っている。
移行という作業は、公開した瞬間にゴールではなく、公開後の数日間まで含めて初めて終わるものだと、今は考えるようにしている。

CMSの移行やデータの引き継ぎで、どこまでサポートできるか気になる方は、
CMS移行支援のページも見てみてほしい。