Webサイト公開前後のチェックリスト：変更別の確認範囲と中止条件

Webサイトの公開チェックは、毎回すべての項目を同じ重さで見るより、何を変更したかで確認範囲を変えるほうが実用的です。文章だけを直したのか、URLを変えたのか、フォームを触ったのか、テンプレートや共通部品を変更したのかで、壊れる場所が違います。

チェックリストでそろえるのは、どこまで見れば安心して公開できるか、どの状態なら公開を止めるかです。作業者の記憶に頼らず、変更内容ごとの確認範囲を先に決めます。

公開チェックは変更した場所から確認範囲を決める

変更内容が違えば、確認すべき範囲も変わります。小さな文章修正とフォーム改修を同じチェックで扱うと、重要な確認が抜けるか、不要に重い確認になって運用が続きません。

最初に、今回の変更がどの種類に当たるかを分けます。文章変更なら、意味、リンク、検索結果での見え方が主な確認範囲です。URL変更なら、旧URLから新URLへたどれるかが中心になります。フォーム変更なら、見た目ではなく送信と通知まで確認します。共通部品変更なら、変更したページ以外にも影響が広がります。計測タグ変更なら、発火条件だけでなく重複や表示速度も見ます。

複数に当てはまる場合は、影響が大きいほうに合わせます。たとえば文章変更に見えても、titleやURLを変えるなら検索結果や内部リンクまで見る必要があります。小さく見える変更でも、壊れる場所が広いなら、公開前に止める条件も広く取ります。

文章変更は意味、リンク、検索結果での見え方を見る

文章だけの変更でも、確認することはあります。誤字を直したつもりでも、意味が変わっていたり、古い表現が残っていたり、リンク先との関係がずれていたりします。

本文の修正では、読者に約束している内容が変わっていないかを見ます。公開済み記事なら、titleやdescriptionと本文の答えがずれていないかも確認します。検索結果に表示される説明と、ページの中身が違って見えると、読者は期待した答えにたどり着きにくくなります。

リンク先も確認します。内部リンクが古い記事へ向いていないか、外部リンクが意図したページへつながるかを見ます。文章変更は小さく見えますが、読者の判断材料に関わる箇所なら、事実確認まで戻します。

URL変更は旧URLから新URLへたどれる状態を先に作る

URLやslugを変える場合は、文章変更より慎重に扱います。公開済みURLは、検索意図、外部リンク、内部リンク、ブックマーク、サイトマップに関わっています。

安易にURLを変えると、読者も検索エンジンも古い場所から新しい場所へたどれなくなります。変更が必要な場合は、旧URLと新URLの対応を作り、リダイレクトとcanonicalを確認します。サイトマップ、内部リンク、Search Consoleでの確認までを一件のリリースとして扱います。URL変更を伴う大きな移行では、Google検索セントラルのサイト移転ガイドも確認します。

移行先が決まっていないURL変更は公開しません。旧URLから新URLへたどれる状態を先に作り、公開後に実URLで確認します。戻す手順がない場合も、公開を止める条件に入れます。

フォーム変更は送信と通知まで確認できなければ止める

フォームは、壊れていても見た目だけでは気づきにくい場所です。入力欄が表示されていても、送信できない、通知が届かない、外部記録に残らない、計測だけ発火しないといった問題が起きます。

フォーム変更では、入力、バリデーション、完了画面、通知メールを見ます。スプレッドシートやCRMへの記録、二重送信防止、スパム対策、計測タグの発火も確認範囲です。問い合わせの機会損失が直接出るため、送信テストができない状態なら公開を止めます。

確認では、正常送信だけでなく、必須項目の未入力や不正な入力も見ます。完了画面が出るだけでなく、通知と記録が残るところまでがフォームの確認範囲です。

共通部品の変更は主要ページとモバイル表示へ影響する

テンプレートや共通部品の変更は、影響範囲が広がります。ヘッダー、フッター、パンくず、記事テンプレートを変えた場合は、変更したページだけを見ても足りません。CSSやJavaScriptの変更も、複数ページで確認します。

トップページ、下層ページ、Knowledge一覧、記事ページ、404、フォームページを見ます。スマートフォン表示も確認します。PCでは崩れていなくても、モバイルのメニュー、フォーム、下部導線が使いにくくなっていることがあります。

共通部品の変更で特に危ないのは、主要導線が消えることです。お問い合わせ、料金、サービスページ、記事導線など、読者が次に進むためのリンクが残っているかを確認します。

リリース票は変更種別から戻し方まで一件で読めるようにする

チェック項目を別々に持っているだけでは、公開直前に何を止めるべきか判断しにくくなります。一件のリリース票に、変更種別、影響範囲、公開前確認、中止条件をまとめます。公開後確認、戻し方、担当も同じ票で読めるようにします。

記入例は、架空の成果を残すためではなく、公開判断の粒度をそろえるために使います。実際の作業では、対象URLや担当者名をその案件に合わせて書き換えます。

この票は、変更が小さいほど省略したくなります。けれども、フォーム、URL、共通部品、計測のように壊れたときの影響が大きい変更では、短い票があるだけで公開を止める判断がしやすくなります。

公開後チェックでは実URL、noindex、計測、戻す手順を見る

公開前に問題がなくても、公開後にだけ起きる問題があります。キャッシュ、サーバー設定、権限、環境変数、外部サービス連携は、ローカル確認では見えないことがあります。

公開後には、実URLで表示、リンク、フォーム、計測を確認します。サイトマップ、noindexやrobots指定も確認範囲です。特に、意図しないnoindexは検索結果への表示に関わるため、robots metaタグとX-Robots-Tagの扱いを確認します。URL変更がある場合は、旧URLから新URLへたどれるかも見ます。

中止条件は事前に決めておきます。フォームが送れない、主要ページが表示できない、意図しないnoindexが入っている、旧URLからたどれない、計測が重複している、戻す手順がない。このような状態なら、公開を止めるか戻します。

公開後には、変更内容、確認範囲、中止条件、実URL確認、戻す担当を一件のリリース票へ残します。止めた理由まで残しておくと、次の公開でも同じ基準で判断できます。