WordPressをHTML化した後、トップページが同じように見えても、移行が完了したとは限りません。下層の画像が抜けている、フォームが送れない、古いURLからたどり着けないなど、画面の一部だけでは見つからない問題があります。移行前に比較表をつくり、必要な動作を一つずつ確かめましょう。
比較するページを先に決める
すべてのURLを把握した一覧を用意し、ページ種別ごとの代表を選びます。トップ、サービス、記事一覧、記事詳細、検索、資料、フォームなど、使っている種類を漏らさないようにします。記事が多い場合も、代表だけ見て終えるのではなく、URLや画像の機械的な検査と、種類ごとの目視を組み合わせる方法を検討します。
移行前の状態を記録するときは、本文や画像だけでなく、ページタイトル、説明文、公開状態、転送の有無も残します。未公開の下書きや社内確認用ページを誤って書き出さないことも重要です。表示できるデータをすべて移すのではなく、公開する範囲を明示したうえで、対象件数とURLを照合します。
画像・文書・CSSの参照先を確かめる
HTMLが取得できても、画像、CSS、JavaScript、PDFが旧サーバーやテスト環境を参照していることがあります。画面上で欠けていないかに加え、参照先のURLを調べてください。旧環境が動いている間だけ正常に見える状態を避けるため、移行後も必要なファイルが新しい配置にそろっているか確認します。
大文字と小文字、ファイル名の日本語、末尾のスラッシュなどは環境の違いで問題になる場合があります。PCとスマートフォンで使う画像が別なら、両方を確認します。遅延読み込みの画像は画面を下まで動かして確認してください。資料をダウンロードするリンクは、開いたファイルが正しい版かまで見ます。
URLとHTTP応答を点検する
リンクを押して開くことに加え、正しいHTTP応答かも技術担当者に確認してもらいます。存在しないページでも成功扱いを返す状態や、不要な転送が続く状態は、見た目だけでは判断しにくくなります。MDNのHTTPステータスコード資料で応答の基本を確認できます。
古いURLを維持できるなら同じ場所で表示し、変える場合は新旧の対応表に従って転送を確認します。無関係なトップへ一括で飛ばすと、元の情報を探す人が困ります。存在しないURLも試し、案内の内容と応答が適切か確かめましょう。意図した移転とリンク切れを分けて記録すると、修正の優先順位をつけやすくなります。
フォームは入力から受信まで試す
静的なページに入力欄が見えていても、送信の処理が正しく残っているとは限りません。必須欄の未入力、メール形式の誤り、正常送信、完了表示、担当者の受信を確認します。自動返信がある場合は、その送信も別に試してください。添付や外部の受付システムを使う場合は、それぞれの仕様も検査対象です。
試験は関係者へ知らせ、実際の顧客の相談と混同しない入力で行います。テスト環境でメールを止めていた場合、本番で必要な設定が反映されているかも確認します。反対に、本番用の送信先へ検証中の通知を大量に送らない準備も必要です。どこまで試したか記録し、画面の表示だけで完了と報告しないようにします。
検索と共有に関わる設定を見る
タイトル、description、canonical、robotsメタ、X-Robots-Tag、robots.txt、XMLサイトマップを確認します。テスト用の検索除外やアクセス制限が本番に残っていないか、実際の未ログインのHTTP応答で見てもらいましょう。公開サイトに下書きのURLやテスト環境のURLを含めないようにします。意図して検索除外するページは、通常の公開ページと区別します。
Googleのサイト移転資料も参考に、新旧URLと公開後の確認を計画します。URLが同じでも、内容や設定を大きく変えると検索への影響を別に観察する必要があります。OGPの画像やタイトルを設定している場合は、共有時に必要なファイルも移っているか確認してください。
検査表を実際の行動へ変える例
確認表の「フォーム正常」という欄は、入力、エラー、送信、完了、受信へ分けます。「画像正常」は、最初の画面、下部の遅延画像、スマートフォン用画像、資料の表紙などへ分けます。曖昧な合格基準を細分化すると、作業者が変わっても同じ確認をしやすくなります。すべての技術項目を列挙するより、自社のサイトで必要な行動を基準にしてください。
記事が多数ある場合は、件数とURLの照合で漏れを調べ、代表的な構造を目視で見ます。長文、画像、箇条書き、特殊な埋め込みなどがある記事を選ぶと、共通テンプレートだけでは見えない問題を発見しやすくなります。ただし代表の合格だけで全件が同じとは断定できません。リンクやファイルの検査を組み合わせ、確認した範囲を記録します。
資料のURLは直接開いて確かめます。ページからのリンクが正常でも、以前のURLから資料を探す人がいる場合があります。新しい資料だけを残すのか、旧版への案内が必要かを内容担当者と決めます。PDFのファイル名と紙面の版が一致しているか、古い価格や担当者が残っていないかも確認してください。ファイルの取得成功だけでは内容の正しさは分かりません。
外部に埋め込む地図や動画などは、新しいURLや設定で利用できるかを確認します。見えている枠だけをコピーしても、許可するドメインや接続条件が変わる場合があります。外部の契約や仕様による制約は、移行側だけで解決できないこともあります。必要なアカウントと確認先を先に整理し、公開直前の未確認事項を減らしましょう。
本番切り替えと切り戻しの判断例
公開日時を決めたら、直前までの更新をどこへ反映するか決めます。移行作業の途中で本番に記事が増えた場合、その差分が書き出しへ入っているか確認します。古いデータから作った静的ファイルを公開すると、最近の情報を失ったように見えることがあります。最終データを確定する時点と、その後の更新方法を担当者間で共有してください。
切り替え直後に重大な問題が出たら、どの条件で旧構成へ戻すかを決めます。問い合わせが受け付けられない、主要ページが取得できないなど、業務への影響を基準にします。小さな見た目の差と、利用できない問題を同じ扱いにしないようにしましょう。判断者と技術担当者が連絡できる時間を含めて、公開作業を予定する必要があります。
戻す場合は、旧環境が現在も安全に動くか、切り替え中に受け取ったデータを失わないかを確認します。新旧のフォームが別の保存先を使うなら、記録が分散する可能性もあります。公開側のファイルだけを戻せばよいとは限らないため、移行の範囲に合わせて復元情報を用意します。不要な全体コピーを増やすより、対象と手順を明確にすることが大切です。
公開後に一定期間観察する項目も決めます。検索で見つかった古いURL、受付の動作、定期的な更新など、直後だけでは確認できないものがあります。確認が残る場合は、その内容を明示して引き継いでください。移行を完了したという報告には、対象件数、試した機能、残る管理環境、未確認の条件が分かる記録を添えると、後の運用へつながります。
更新と切り戻しを最後に試す
移行後の構成で、文章や画像を一つ変更して公開まで試します。編集元から再出力する方式なら、公開先に正しく反映され、別の手動修正を消さないかを確かめます。元のWordPressを残す場合は、その保守とアクセス制限も管理対象です。移行が終わったからと、古い管理画面を無管理で残さないようにします。
公開日時、切り戻しの担当者、問題が起きたときに戻す範囲を決め、更新前の必要なデータを保全します。保守・管理サポートへ相談するときは、比較表と残す機能を共有すると、確認の範囲が明確になります。HTML化の完了は、見た目と業務と公開設定がそろって初めて判断できます。
