メインコンテンツへ移動
Boletolibre

イベントサイトを新しいCMSへ移す前のコンテンツ監査

CMSの変更では、運営チームがイベントサイトを編集する場所が変わります。ドメインと公開URLを維持しても、日時、会場、言語、ファイル、ページ同士の関係が新システムで違う形に保存される場合があります。トップページのコピーだけでは、過去のプログラム、現在のチケットへの導線、過去回の記録が残ったとは言えません。インポート前にこの監査を行ってください。対象はコンテンツと編集上の引き継ぎであり、ホスティングやDNSの切り替え計画ではありません。

Boletolibre編集部

公開日

既存のイベントページの記録を確認し、新CMSの項目に対応付け、公開ページで検証する流れを示す独自の図。
新しい公開ページを承認する前に、記録とその関連付けを確認します。

移行範囲と公開の境界を決める

旧CMS、新CMS、対象サイト、現在の開催回、イベント情報の承認者を記録します。ドメイン、URLのパス、チケット販売事業者、メディアの保存先をそれぞれ「維持」「変更」「未確認」に分けます。CMSだけを変え、DNS、決済、メールは従来の担当者が管理することもあります。それらも変更するなら、別の計画と責任者を置き、一枚のチェックリストに複数の切り替えを隠さないようにします。

コンテンツを取得する時点を決め、その後の変更記録を始めます。エクスポートから公開までに、入口案内の修正、販売開始、セッション時刻の変更が起こり得ます。公開済みの変更ごとに根拠、承認者、新CMSへの反映方法を残します。差分記録がないと、プレビューが完成して見えても直近の訂正を元に戻す恐れがあります。最終的な棚卸しと未解決事項を誰が承認するかも決めます。

ページ、ファイル、関係を棚卸しする

公開URLごとに一行、複数ページに使われるCMSレコードごとに一行を作ります。シリーズの恒久ページ、現在と過去の開催回、日程とセッション、登壇者、会場と交通、FAQ、スポンサー、開催後の記録、配布資料、実際に存在する翻訳ページを含めます。メニューにないページでも、メール、QRコード、検索から来場者が開けるなら対象です。CMSの書き出しだけを全体像と考えず、公開ナビゲーション、サイトマップ、配信済みリンクとも照合します。

各行には旧URL、用途、開催回、言語、公開状態、管理者、最終承認、元のレコードID、テンプレート、画像や資料、外部への導線を書きます。登壇者とセッション、プログラムと日、道案内と入口などの関係も記録します。同名のポスターでも別版かもしれないため、承認済みの版と掲載場所を分けます。例外を一括インポート前に見えるようにすることが目的です。

引き継ぐ内容を個別に判断する

各項目を「検証後に移す」「承認済み情報で更新」「日付付きの記録として残す」「同じ目的のページと統合」「承認した行き先を決めて終了」に分類します。アクセス数だけで削除を決めないでください。駐車場やアクセシブルな到着案内は閲覧が少なくても重要かもしれません。過去回のレポートは記録として有用でも、現在の購入ページへ直結させるべきではありません。現行の事実はプログラム、会場、チケットの担当者に確認します。

例外ごとに次の行動と判断者を残します。セッション名だけが承認済みで部屋が未定なら、昨年の部屋を流用せず未承認と記します。スポンサーの旧ページを終了する前に、そこへのリンクを調べます。現在と過去の開催回を混ぜず、それぞれの日時と文脈を保ちます。未解決事項が解決済みか、公開対象から明示的に外れた時点で監査を完了します。

旧CMSと新CMSの項目を対応付ける

URL一覧とは別に、コンテンツ型と項目の表を作ります。旧型ごとに用途、新しい保存先、データ形式、必須かどうか、言語ごとの扱い、他レコードとの関係、変換規則を記します。自由記述の日時を日付・時刻・タイムゾーンに分ける、文字列の登壇者名を登壇者レコードへの参照にする、といった変化は編集判断でもあります。表示文とタイムゾーンは承認済みのものを使い、書き出しデータから推測しません。

単純な現行イベント、複数日程、翻訳ページ、延期またはアーカイブされた回、特殊なメディアを持つページで対応表を試します。追加項目や手作業がなければ表現できない部分を明示します。旧サイトにEvent構造化データがあれば、日付、場所、状態、チケットリンクを表示内容と照合します。Googleはこれらのプロパティを説明していますが、すべてのCMSが自動生成するわけではありません。題名が移っただけで記録全体を完了扱いにしないでください。[2]

公開URLと外部サービスを分けて扱う

同じ内容を示す公開パスは、可能なら維持します。変更が必要なら旧URL、新しい行き先、理由を公開前に記録します。Googleは旧URLから対応する新URLへの対応付け、内部リンクの更新、実際のURL移動時のリダイレクトを案内しています。すべてをトップページへ送っても、必要な情報の代わりにはなりません。キャンペーン、QRコード、登壇者紹介、過去回への公開済みリンクも確認します。

CMSが管理する内容と外部の行動を分けます。チケットボタン、地図、フォーム、カレンダー、配信は別アカウントに依存する場合があります。担当者、正確な行き先、閲覧設定、代替手段を記録し、自動で移るとは想定しません。画像や配布資料のパスが変われば参照ページを確認します。翻訳ページは各言語に適した行き先へ対応付けます。編集担当が行き先を承認し、技術担当がURLの動作を実装・検証します。[1]

公開前に実際の来場者経路を試す

トップページだけでなく、棚卸し表から試験経路を選びます。古いブックマークや検索、招待メール、シリーズページ、スマートフォン幅から入ってみます。現在の日時、タイムゾーン、会場、入場条件、次に行う操作を承認済み情報と照合します。購入を完了せず、公開チケットリンクの引き継ぎ先まで確認します。過去回のページが説明なく現在の決済へ送る状態は避けます。

各ページ型と言語の例を旧サイトおよび承認済み資料と比較します。見出し、読める表、画像、説明文、ダウンロード、モバイル表示、キーボード操作、リンクを確認します。W3Cは画像の目的に合う代替テキストを勧めています。ファイルだけコピーして役立つ代替テキストが欠けたなら見直します。Event構造化データがあった場合は表示内容との一致を適切な検証ツールで確認します。URL、期待する事実、結果、担当者、再確認状況を残します。[3][2]

インポートを照合し、承認を残す

公開前に元と先の件数をページ型、開催回、言語別に比べます。件数は網羅性の目安にすぎず、会場ページ一件の欠落が無害な下書き数件より重大です。例外と取得後の変更を確認し、イベント責任者に事実、CMS担当に項目対応、ウェブ担当にリンクと公開状態を承認してもらいます。その判断に使った棚卸し表の版を保存します。

公開後は新しいブラウザセッションで予定したURLを開き、現行ページ、アーカイブ、ダウンロード、外部サービスを確認します。URLが変わった場合はリダイレクト、内部リンク、サイトマップ、Search Consoleを継続して見ます。Googleによる移動の処理はURLごとで、完了日を保証できません。重要な事実や導線に誤りがあれば、記録した修正・差し戻し担当に渡し、影響URLを残します。この監査表を次回開催にも引き継ぎます。[1]

CMSコンテンツ監査・項目対応表をダウンロード(英語のMarkdown)

出典と参考資料

  1. How to move a siteGoogle Search Central · 確認日
  2. Event structured dataGoogle Search Central · 確認日
  3. Images TutorialW3C Web Accessibility Initiative · 確認日