WordPressサイトを公開する直前は、期待と不安が同時に大きくなるタイミングです。デザインが整っていても、問い合わせが届かない、検索エンジンに見つけてもらえない、スマートフォンで読みにくい、古いテストページが残っているといった問題があると、公開後の機会損失につながります。
一方で、公開前にすべてを完璧にしようとすると、確認が終わらず公開日だけが延びてしまいます。大切なのは、公開を止めるべき重大な問題と、公開後に改善できる項目を分けることです。
この記事では、WordPressサイトの公開前に確認したい項目を、目的、内容、導線、表示、操作、SEO、セキュリティ、運用の順に整理します。自社で確認できる範囲と、制作会社や保守担当者へ依頼した方がよい範囲も分かるように解説します。
- 公開前チェックの目的を決める
- サイトの目的と想定読者を再確認する
- 公開対象のページを一覧にする
- 文章と情報の正確性を確認する
- 問い合わせや申込みの導線を実際に試す
- パソコンとスマートフォンで表示を確認する
- 画像とファイルを確認する
- リンク切れとエラーページを確認する
- URLとWordPressの基本設定を確認する
- 検索エンジンに関する設定を確認する
- アクセス解析と計測を確認する
- 表示速度と安定性を確認する
- セキュリティと権限を確認する
- バックアップと復元方法を確認する
- 公開当日の手順を決める
- 公開直後に確認する
- 自分で確認できる範囲を見極める
- 公開可否を判断する基準
- 公開前チェックを一度きりにしない
- 会社情報と法的な表示を確認する
- アクセシビリティの基本を確認する
- 外部サービスと契約状況を確認する
- 公開後の担当と費用を確認する
- まとめ
- 参考にした公式情報
公開前チェックの目的を決める
公開前チェックの目的は、単に誤字を探すことではありません。訪問者が必要な情報にたどり着き、安心して問い合わせや購入などの行動を取れる状態かを確かめることです。同時に、公開後の更新や障害対応を続けられる状態かも確認します。
確認項目は多いため、最初に優先順位を決めておくと判断しやすくなります。次の三つに分ける方法が実用的です。
- 公開を止める問題：サイトが開けない、フォームが届かない、個人情報が露出している、決済できないなど
- 公開前に直したい問題：重要ページの誤字、スマートフォンでの大きな表示崩れ、リンク切れなど
- 公開後に改善できる問題：細かな余白、補足説明、記事追加、画像の差し替えなど
この区分を関係者で共有しておくと、細部の好みで公開判断が止まりにくくなります。公開日が決まっている場合は、確認担当者、修正担当者、最終承認者、修正期限も決めておきましょう。
サイトの目的と想定読者を再確認する
チェックを始める前に、サイトの目的を一文で説明できるか確認します。たとえば「地域の見込み客にサービス内容を理解してもらい、相談予約につなげる」「採用候補者に働く環境を伝え、応募につなげる」といった形です。
目的が曖昧なままだと、トップページに情報を詰め込みすぎたり、問い合わせボタンを置きすぎたりします。誰に、何を伝え、次に何をしてほしいかをページごとに決めると、内容と導線の良し悪しを判断できます。
主要ページの役割を整理する
トップページ、サービス紹介、会社情報、よくある質問、お問い合わせなど、主要ページにはそれぞれ役割があります。各ページに似た説明を繰り返すのではなく、トップページは全体像、サービスページは選ぶための情報、会社情報は信頼性、お問い合わせページは行動の不安を減らす情報というように分担させます。
サービス本体サイトに料金、実績、問い合わせ情報がある場合、コラム側に同じページを重複して作る必要はありません。コラムは悩みの整理や判断材料を提供し、必要な読者を既存のサービスページへ自然につなぐ役割にすると、サイト全体の整理がしやすくなります。
公開対象のページを一覧にする
目視だけで確認すると、メニューに出ていないページやテスト用ページを見落としがちです。公開対象のURL、ページ名、担当者、確認状況を一覧にします。投稿、固定ページ、ランディングページ、カテゴリーページ、必要に応じてカスタム投稿も対象です。
不要なページが公開されていないか確認する
サンプルページ、テスト投稿、仮のランディングページ、重複ページ、古い規約、制作中のページが残っていないか確認します。削除が不安な場合は、すぐに完全削除せず下書きや非公開へ戻し、必要性を判断します。ただし、公開後に外部リンクや検索流入が発生したページは、安易に削除せず転送の要否を検討します。
ナビゲーションから到達できるか確認する
重要なページがヘッダー、フッター、本文内のリンクからたどれるかを確認します。メニューだけに頼らず、関連する説明の直後に適切な内部リンクがあると、読者は次の情報へ進みやすくなります。
反対に、似た役割のボタンが多すぎると迷いが生まれます。主要な行動はページごとに絞り、ボタンの文言から移動先を予測できるようにします。「詳しくはこちら」だけを並べるより、「サービス内容を見る」「相談方法を確認する」のような具体的な表現が分かりやすいでしょう。
文章と情報の正確性を確認する
誤字脱字だけでなく、会社名、氏名、住所、電話番号、受付時間、料金、提供地域、支払い方法、納期、保証範囲など、意思決定に関わる情報を重点的に確認します。数字や条件は古くなりやすいため、原資料と照合し、確認日も記録しておくと更新時に役立ちます。
表記を統一する
同じ意味の言葉がページごとに変わると、読者が別のサービスだと誤解することがあります。サービス名、プラン名、会社名、英数字の全角と半角、日付、金額表記、敬語の調子を統一します。
専門用語は、想定読者が理解できる言葉へ置き換えます。どうしても必要な用語には短い説明を添えます。社内では通じる略称でも、初めて訪れる人には意味が伝わらないことがあります。
仮テキストと仮画像を探す
「ここに文章が入ります」「準備中」「Lorem ipsum」などの仮テキスト、ダミー画像、未設定の代替テキスト、仮の電話番号が残っていないか確認します。ページ上に見えなくても、画像のファイル名、リンク先、メタ情報、フォームの自動返信文に残っていることがあります。
問い合わせや申込みの導線を実際に試す
フォームは表示されているだけでは十分ではありません。訪問者と運営者の両方の立場で、最初から最後までテストします。テスト時には本番と同じ経路で入力し、送信完了画面、管理者への通知、利用者への自動返信、管理画面への保存まで確認します。
フォームで確認したい項目
- 必須項目が必要最小限か
- 入力例とエラーメッセージが分かりやすいか
- スマートフォンでも入力しやすいか
- 送信後に完了したことが明確に伝わるか
- 管理者通知と自動返信の送信元、宛先、件名、本文が正しいか
- 返信までの目安や次の流れが案内されているか
- 個人情報の取り扱いへの同意方法が適切か
メールは環境によって迷惑メールへ入る場合があります。複数のメールサービスで受信を試し、届かない場合は送信方式やドメイン認証を確認します。フォームテストの結果には、テスト日時、使用したアドレス、届いた場所、送信にかかった時間を残しておくと、公開後の不具合調査に役立ちます。
電話や外部予約への導線も確認する
電話番号のタップ、地図、予約システム、SNS、決済サービスなど、外部サービスへ移動するリンクも実機で確認します。別のアカウントや古い店舗ページへつながっていないか、ログイン中の管理者だけが見られるURLを貼っていないかに注意します。
パソコンとスマートフォンで表示を確認する
制作中はパソコンの管理画面を中心に見がちですが、実際の訪問者はさまざまな画面サイズで閲覧します。少なくともパソコンとスマートフォンの実機で、トップページと主要な行動ページを確認します。可能であれば異なるブラウザでも試します。
スマートフォンで見落としやすい点
- 見出しや長い英単語が画面からはみ出していないか
- 画像や表が横にはみ出していないか
- ボタン同士が近すぎず、指で押し分けられるか
- 固定ヘッダーが本文やリンクを隠していないか
- 電話番号やメールアドレスを正しくタップできるか
- フォーム入力時に画面が不自然に拡大しないか
- ポップアップが閉じられず操作を妨げていないか
すべての端末を用意する必要はありません。アクセスが多いと想定する端末とブラウザを優先し、公開後のアクセス解析を見ながら検証範囲を広げます。
画像とファイルを確認する
画像はサイトの印象を大きく左右します。ぼやけていないか、引き伸ばされていないか、縦横比が崩れていないかを確認します。容量が大きすぎる画像は表示を遅くするため、用途に合う寸法と形式へ調整します。
画像の代替テキストは、装飾ではなく内容を伝える画像に設定します。画像が表示されない場合や読み上げ機能を利用する場合に、何を示す画像かが伝わる表現にします。見た目だけの装飾画像へ無理に説明を入れる必要はありません。
PDFや資料のダウンロードリンクがある場合は、ファイルが開くか、最新版か、個人情報や編集履歴が残っていないか、ファイル名が利用者に分かりやすいかを確認します。社内用資料や見積書のひな形を誤って公開していないかも重要です。
リンク切れとエラーページを確認する
ヘッダー、フッター、本文、ボタン、画像、パンくずリスト、ロゴなど、クリックできる要素を確認します。内部リンクは本番ドメインを向いているか、外部リンクは意図したページを開くかを確かめます。制作環境やプレビュー用URLが残っている場合は修正します。
存在しないURLへアクセスしたときに404ページが表示され、トップページや主要ページへ戻れるかも確認します。エラー画面にサーバーの詳細情報や管理者向けの警告が表示されている場合は、公開前に原因を調べます。
URLとWordPressの基本設定を確認する
WordPressの「設定」には、サイト全体へ影響する項目があります。公開直前に勢いで変更するのではなく、現在値を記録してから確認します。
サイトアドレスとHTTPS
サイトのURLが本番ドメインのHTTPSになっているか、HTTPや制作環境のURLへ戻るリンクがないか確認します。HTTPSへ統一する場合は、ページ内の画像やスクリプトもHTTPSで読み込まれている必要があります。URL設定を誤ると管理画面へ入れなくなることがあるため、不安がある場合は変更前にバックアップを取り、サーバーや制作担当者へ確認します。
パーマリンク
パーマリンクは投稿や固定ページの恒久的なURLです。WordPress公式ドキュメントでも、公開後に利用される恒久的なURLとして説明されています。構造を公開後に変更すると、既存リンクや検索評価へ影響するため、公開前に方針を決めます。設定を変えるだけでなく、主要ページを開いて404にならないか確認します。
サイトタイトルと管理者メール
サイトタイトル、キャッチフレーズ、タイムゾーン、日付形式、管理者メールアドレスを確認します。管理者メールが退職者や制作会社の個人アドレスのままだと、重要な通知を受け取れなくなる可能性があります。運用主体が管理できるアドレスにし、受信できることを確かめます。
検索エンジンに関する設定を確認する
公開しただけで、すぐに検索結果へ表示されるとは限りません。検索エンジンがページを取得できる状態か、表示させたいページが適切に案内されているかを確認します。
検索エンジンでの表示設定
制作中に検索エンジンへの表示を抑制していた場合、公開時に解除し忘れることがあります。WordPressの表示設定と、SEOプラグイン側のnoindex設定を確認します。ただし、会員限定ページや重複ページなど、検索結果へ出す必要がないページは個別に判断します。
robots.txtはクロールを制御する仕組みであり、検索結果から確実に除外するための万能な設定ではありません。Googleの公式資料でも、インデックス制御にはnoindexやアクセス制限など、目的に合う方法を使うよう案内されています。設定の意味が分からない場合は、公開前に専門家へ確認しましょう。
タイトルとメタディスクリプション
主要ページには、そのページ固有のタイトルを設定します。ページ名だけでなく、何の情報があり、誰に役立つかが伝わる表現にします。メタディスクリプションは検索結果に必ずそのまま表示されるとは限りませんが、内容を短く説明するために設定しておくと管理しやすくなります。
サイトマップとSearch Console
XMLサイトマップが生成され、公開したいURLが含まれているか確認します。Google Search Centralでは、サイトマップは新しいページや更新したページを知らせる方法として案内されていますが、送信したからといってインデックス登録や順位が保証されるわけではありません。
Search Consoleを利用する場合は、正しいプロパティを確認し、サイトマップを送信します。公開直後の数ページはURL検査で状態を確認できます。インデックス登録には時間がかかるため、同じURLを何度も送信するより、クロールを妨げる設定や内容の品質を確認する方が有効です。
アクセス解析と計測を確認する
アクセス解析や広告計測を導入している場合は、タグが入っているかだけでなく、実際にデータが届くかを確認します。トップページだけでなく、問い合わせ完了や購入完了など、成果として計測したい地点までテストします。
同じタグをテーマとプラグインの両方へ入れると、二重計測になる場合があります。管理方法を一つに決め、誰がどこで設定しているか記録します。管理画面で自分のアクセスを除外する設定がある場合も、テスト時には条件を理解しておきます。
Cookieや広告に関する表示は、利用する計測・広告サービス、対象地域、事業内容によって必要な対応が変わります。法的な判断が必要な場合は、一般的なテンプレートを貼るだけで済ませず、専門家へ相談してください。
表示速度と安定性を確認する
公開前には、主要ページが実用的な時間で表示されるかを確認します。数値だけを追うのではなく、最初に必要な内容が見えるまでの待ち時間、ボタンを押したときの反応、表示中の大きなレイアウト移動を実際に体験します。
遅い場合は、大きな画像、動画の自動再生、外部フォント、多数のプラグイン、外部タグ、重いアニメーションなどを確認します。キャッシュを有効にした後は、ログインしていない状態でも最新内容が表示されるか、フォームや会員機能が壊れていないかを確かめます。
短時間の負荷試験でもサーバーへ影響することがあります。共有サーバーや本番環境で無断実行せず、必要な場合は契約先や担当者と方法を相談します。
セキュリティと権限を確認する
公開前には、WordPress本体、テーマ、プラグインが安全に保守できる状態かを確認します。更新は重要ですが、公開直前に大量の更新をまとめて行うと、不具合が起きた際の原因を特定しにくくなります。バックアップと復元手順を用意し、変更後に表示と機能を再確認します。
ユーザーアカウントを整理する
不要な管理者アカウント、共有アカウント、制作中だけ必要だったアカウントを確認します。担当者ごとに必要最小限の権限を割り当て、強いパスワードを使用します。可能であれば二要素認証も検討します。
制作会社のアカウントを残す場合は、保守契約や緊急対応の役割を確認します。削除する場合も、投稿の所有者や作業履歴への影響を把握してから進めます。
Site Healthを確認する
WordPressの「ツール」からSite Healthを開くと、重大な問題、推奨される改善、サーバーやプラグインなどの情報を確認できます。WordPress公式ドキュメントでは、Statusで注意が必要な項目、Infoで構成情報を確認できると説明されています。
すべての推奨項目を機械的に直す必要はありません。サイトの構成や運用方針によって意図的な設定もあるため、重大度と影響を見て判断します。技術情報を外部へ共有する場合は、サーバーパスやデータベース情報などの機密性にも注意します。
バックアップと復元方法を確認する
バックアップは「取得できた」だけでなく、「どこに保存され、誰が復元できるか」まで確認して初めて役立ちます。WordPressのファイルとデータベースの両方が対象か、保存先が本番サーバーと別か、世代管理されているかを確認します。
公開直前の状態を一つの復元ポイントとして残し、取得日時と変更内容を記録します。復元テストを本番環境でいきなり行うのは危険です。可能であれば検証環境で試すか、サーバー会社や保守担当者に復元条件を確認します。
公開当日の手順を決める
公開作業は、担当者の記憶だけに頼らず手順として残します。ドメイン切り替え、HTTPS確認、キャッシュ削除、検索エンジン設定の解除、フォームテスト、主要ページ確認、アクセス解析確認、バックアップなど、実際の構成に合う順番を決めます。
公開作業中に問題が起きた場合の中止条件も決めます。問い合わせが届かない、決済できない、主要ページが表示されない、管理画面へ入れないといった問題は、状況によって公開延期や切り戻しを検討します。
公開時間を選ぶ
アクセスが少なく、制作担当者と運用担当者が対応できる時間を選びます。深夜に公開すると訪問者は少なくても、トラブル時にサーバー会社や関係者へ連絡できない場合があります。公開後に一定時間監視できる時間帯が安心です。
変更履歴を残す
公開日時、作業者、変更した設定、確認結果、未対応項目を記録します。後から問題が起きたとき、「いつ、何を変えたか」が分かれば原因の切り分けが早くなります。
公開直後に確認する
公開操作が完了しても、チェックは終わりではありません。ログアウトした状態や別の通信環境からサイトを開き、訪問者と同じ条件で確認します。管理者としてログインしていると、キャッシュや権限の問題に気づかないことがあります。
- 本番URLでトップページと主要ページが開く
- HTTPSで警告が出ない
- メニュー、ボタン、内部リンクが機能する
- フォーム送信とメール受信ができる
- 画像、CSS、JavaScriptが読み込まれる
- 検索エンジン向け設定が想定どおりである
- アクセス解析でテストアクセスを確認できる
- 404やサーバーエラーが増えていない
公開後の数日間は、フォーム、アクセス解析、Search Console、サーバーのエラー状況を定期的に確認します。Googleのクロールやインデックス登録には時間がかかるため、公開当日に検索結果へ出ないことだけを理由に設定を何度も変更しないようにします。
自分で確認できる範囲を見極める
文章、連絡先、画像、リンク、スマートフォン表示、フォームの入力しやすさなどは、サイト運営者自身が確認する価値があります。実際の顧客を理解している人だからこそ気づける問題があるためです。
一方、DNS、SSL証明書、サーバー移行、データベース、複雑なキャッシュ、セキュリティ事故、決済、個人情報の法的要件などは、誤った操作の影響が大きくなります。設定の意味や戻し方が分からない場合は、作業を止めて担当者へ相談する方が安全です。
外部へ依頼した方がよいケース
- 公開日が決まっており、失敗時の事業影響が大きい
- ドメインやサーバーを同時に変更する
- 会員、予約、決済など停止できない機能がある
- 個人情報や機密情報を扱う
- エラーが発生しても社内で復旧できない
- 複数の制作会社やサービスが関わり、責任範囲が曖昧である
依頼時には「全部見てください」だけでなく、公開日、サイトの目的、重要な導線、利用中の外部サービス、変更してよい範囲、現在困っている点を共有します。確認結果は、重大度、修正方法、担当者、期限が分かる形でもらうと、公開判断に使いやすくなります。
公開可否を判断する基準
公開可否は、未修正項目がゼロかどうかではなく、事業と利用者への影響で判断します。次の条件を満たしていれば、細かな改善を公開後の計画へ回せる場合があります。
- 主要ページが安定して表示される
- 問い合わせや購入などの主要行動が完了できる
- 重要な情報に誤りがない
- 個人情報や機密情報の漏えいがない
- バックアップと復旧連絡先がある
- 未対応項目と対応期限が記録されている
反対に、フォーム不達、決済不能、個人情報の露出、重大な表示崩れ、管理画面へのアクセス不能、復元手段がない状態は、公開を止める判断が必要です。問題を隠して公開するのではなく、関係者へ影響と対応案を共有します。
公開前チェックを一度きりにしない
サイトは公開後も変化します。WordPress本体、テーマ、プラグイン、サーバー、外部サービス、会社情報、料金、担当者が変わるため、公開時に問題がなくても永続的に安全とは限りません。
公開前チェックで作った一覧を、毎月、四半期、更新時の点検表へつなげます。問い合わせテスト、バックアップ確認、更新状況、リンク切れ、主要ページの表示、管理者アカウント、アクセス解析などを定期的に見直すと、問題を早く見つけられます。
会社情報と法的な表示を確認する
会社名、所在地、代表者名、連絡先、営業時間などの基本情報が、会社案内、フッター、特定商取引に関する表示などで矛盾していないか確認します。移転前の住所や以前の電話番号が残っていると、訪問者の不安だけでなく、郵送物や問い合わせの取りこぼしにつながります。
商品販売、予約、会員登録、メール配信、アクセス解析など、サイトで行うことによって必要な表示や同意の取り方は変わります。プライバシーポリシーや利用規約は、他社の文章をそのまま流用せず、実際に取得する情報、利用目的、委託先、問い合わせ方法と一致しているか確認します。
業法や広告表現の規制が関係する事業では、公開前に資格者や法律の専門家による確認が必要な場合があります。制作会社はサイトの実装を確認できても、事業固有の法的判断まで保証できるとは限りません。誰が内容を承認するかを明確にします。
著作権と利用許諾を確認する
写真、イラスト、フォント、アイコン、動画、文章、顧客の声、ロゴなどについて、公開用途で利用できる権利があるか確認します。素材サイトのライセンスは、商用利用、加工、クレジット表記、利用数などの条件が異なります。購入履歴や許諾メールは、担当者が変わっても確認できる場所に保存します。
制作実績やお客様の声を掲載する場合は、掲載範囲と期間について許可を得ます。担当者の口頭了解だけでなく、公開する文章や画像を相手に確認してもらうと、認識違いを防ぎやすくなります。
アクセシビリティの基本を確認する
アクセシビリティは、特定の人だけのための追加対応ではありません。文字が小さすぎない、背景とのコントラストが低すぎない、キーボードでも操作できる、リンクの目的が分かるといった基本は、多くの利用者にとって使いやすさにつながります。
公開前には、文字を拡大しても内容が重ならないか、画像だけに重要情報を載せていないか、フォームの項目名と入力欄の関係が分かるかを確認します。色だけでエラーや選択状態を伝えると、違いを認識しにくい利用者へ情報が伝わらないことがあります。文章や形でも補足します。
キーボード操作と読み上げを試す
Tabキーでメニュー、リンク、ボタン、フォームへ順番に移動できるか、現在位置が見えるかを確認します。マウスを使わないと開けないメニューや、閉じられないダイアログがある場合は修正が必要です。
すべてを専門的に監査できなくても、主要ページをOSの読み上げ機能で聞くと、見出しの順序、画像の説明、リンク文言の分かりにくさに気づけます。公共性が高いサイトや対象者が広いサイトでは、専門的なアクセシビリティ試験を依頼する判断も検討します。
外部サービスと契約状況を確認する
WordPressサイトは、サーバー、ドメイン、メール、フォーム、予約、決済、地図、動画、アクセス解析など、複数の外部サービスに支えられています。画面上では動いていても、試用期間の終了、支払い方法の期限切れ、契約者の退職によって突然使えなくなることがあります。
各サービスについて、契約名義、管理URL、管理者、更新日、支払い方法、緊急連絡先を一覧にします。パスワードを表計算に直接書くのではなく、組織で管理できる安全なパスワード管理方法を使います。
ドメインとDNSの管理者を確認する
ドメインの有効期限、自動更新、登録メールアドレスを確認します。DNSの変更はサイトだけでなくメールにも影響するため、公開作業で変更する場合は現在の設定を記録します。メール用のレコードを誤って消すと、サイトが表示されてもメールが届かなくなることがあります。
制作会社名義で契約している場合は、契約終了後の管理方法、移管に必要な情報、費用を確認します。サイトの所有者がドメインと主要サービスを管理できる状態にしておくと、将来の更新や制作会社変更がスムーズです。
APIキーやテストモードを確認する
地図、決済、メール配信などでAPIキーを利用している場合は、本番用の設定か、利用制限が適切かを確認します。テストモードのままでは実際の決済や通知が行われないことがあります。反対に、本番モードでテストをすると実課金が発生する場合があるため、サービスごとの確認方法に従います。
公開後の担当と費用を確認する
公開後に誰が何をするか決まっていないと、更新通知や問い合わせが放置されます。記事や会社情報の更新、WordPressの更新、バックアップ確認、フォームテスト、障害対応、契約更新について担当者と頻度を決めます。
保守を外部へ依頼する場合は、月額費用だけでなく、含まれる作業、対応時間、緊急時の連絡方法、復旧作業の範囲、追加費用が発生する条件を確認します。「保守あり」という言葉だけでは、記事更新、デザイン修正、サーバー障害、セキュリティ対応のどこまで含むか分かりません。
引き継ぎ資料を用意する
管理画面の操作方法、更新してよい場所、画像の推奨サイズ、バックアップ方法、利用中のプラグイン、外部サービス、問い合わせ先をまとめます。操作説明会を行う場合は、担当者が実際に記事更新やフォーム確認を行い、手順書だけで再現できるか確かめます。
公開時点で未対応の項目は、理由、影響、対応期限、担当者を残します。未対応項目が見えないまま運用へ移ることを防ぎ、公開後の改善を計画的に進められます。
まとめ
WordPressサイトの公開前チェックでは、見た目だけでなく、情報の正確さ、問い合わせ導線、スマートフォン表示、URL、検索エンジン設定、計測、セキュリティ、バックアップ、公開後の監視まで確認します。
重要なのは、公開を止める問題と公開後に改善できる項目を分け、担当者と期限を決めることです。確認できない技術項目を無理に操作せず、変更の影響が大きい部分は制作会社、保守担当者、サーバー会社などへ相談します。
公開は完成の終点ではなく、運用の開始です。公開直後の確認と、その後の定期点検まで含めて準備することで、利用者が安心して使え、事業の成果につながるサイトを育てやすくなります。
