ホームページ制作の納品確認では、「表示されるサイト」「引き継ぐデータ・管理権限」「公開後に続ける運用」を分けて確認します。完成画面を見るだけでなく、自社の担当者が必要な更新を行い、問い合わせを受け取り、問題時の連絡先へたどれる状態かを確かめましょう。

この記事は、制作会社へ依頼する企業の担当者に向けた納品チェックリストです。WordPress・Google・W3Cの一次資料を比較し、「納品物→試す操作→残す証跡」を対応させる独自の確認表を作成しました。自社の実案件や法的な契約基準の紹介ではありません。

何を納品物とするか、いつ確認するか、修正と追加要望をどう扱うかは、発注前に制作会社とすり合わせます。デザインの編集元データや外部サービスの権限等が、すべての契約に一律で含まれると考えないことが大切です。

発注前に「確認できる納品条件」を決める

「スマートフォン対応」「更新可能」「SEO対応」だけでは、完了の判断が曖昧です。対象ページ、操作、確認環境、期待する結果を組にします。たとえば「お知らせを追加できる」なら、誰の権限で本文と画像を保存し、どの一覧と詳細へ反映されることを確認するかまで決めます。

制作前の整理はホームページ制作の要件定義書で扱っています。この記事では、合意した条件に対して納品段階で何を受け取り、どう試すかに絞って説明します。制作全体の順序はホームページリニューアルの進め方も参照してください。

受け取り・動作確認・運用引き継ぎを一続きにする

合意した範囲を照合し、納品物を受け取り、操作を試し、結果と運用担当を記録する確認フロー。不一致は修正後に再確認する。
工程の順序と完了条件は案件ごとに合意します。不具合・未確認が残る場合は、解消条件と担当を記録して再確認します。

データの受領だけでは、使えることは分かりません。反対に、画面が動いていても、更新する権限や復旧方法を引き継げていない場合があります。次の表では受領欄と確認欄を分けて使います。

対象 受け取る・共有するもの 試す操作と残す証跡
公開ページ 対象URLと合意したページ一覧 主要ページを開き、本文・画像・リンクの確認結果を残す
CMS更新 担当者アカウントと操作手順 検証用原稿の保存・確認・公開の役割分担を試す
フォーム 宛先、通知、運用担当、確認手順 合意したテスト送信の到達とエラー時の表示を記録する
サイトデータ 構成に応じたファイル・DB・素材と出力手順 復元や移行に必要な対象と不足を照合する
契約・管理 サーバー、ドメイン、外部サービスの管理担当と更新条件 担当者が必要な管理へ到達できるか確認する
保守・障害対応 連絡先、対象範囲、対応の条件 問題を誰へ渡すか、終了・引き継ぎ時の方法を残す

これは発注者側の検討表であり、特定のデータ形式や権限の引き渡しを一律に要求するものではありません。SaaS等ではソースコード一式を受領する構成でない場合もあります。利用継続と乗り換えに必要な情報を、サービスの条件に沿って確認します。

WordPressでは「記事の出力」と「サイトの復元」を分ける

WordPressの「ツール→エクスポート」で作成されるWXR形式のXMLは、投稿、固定ページ、分類などのコンテンツを移すためのものです。テーマ・プラグイン・アップロードファイル・データベース等を含めたサイト全体のバックアップと同じだとは判断しないでください。

WordPressのバックアップ資料は、サイトのファイルとデータベースを区別しています。納品時には、何が保存され、何が保存されていないか、誰がどの環境で復旧するかを記録します。バックアップファイルが存在することと、復元できたことも別の確認です。

確認したいこと 確認の手掛かり 不足として残す例
原稿を別サイトへ移せるか エクスポートの対象・形式 画像の実体や独自項目の移行が未確認
同じサイトを復旧できるか ファイル・DB・設定と復元手順 DBのみでテーマ・画像が含まれていない
障害時に作業を始められるか 保存場所、担当、検証環境 保存先へ担当者がアクセスできない

実際の復元試験は、本番を上書きせず隔離した環境で行います。具体的な対象の整理はWordPressのバックアップと復元確認を参照してください。

本番で確認する表示・リンク・操作

テスト環境で確認した後も、本番URLで確かめます。サーバー設定、URL、送信先、外部サービスの許可条件が異なる場合があるためです。以下は初期の確認例です。合意した対象ブラウザ・端末・ページ範囲を記録し、見ていない範囲を確認済みにしないようにします。

W3C WAIのEasy Checksは、タイトル、画像の代替、キーボード操作等の初期点検に役立ちます。ただし、この点検だけでアクセシビリティへの適合全体を確認したことにはなりません。必要な品質基準と試験範囲は別に定めます。

フォームは、送信完了画面だけで終えない

試験用データと宛先を事前に合意し、必須項目のエラー、入力した内容、完了表示、担当者側の受信まで確認します。自動返信を設けた場合は、その到達と内容も見ます。実在の顧客情報を無断でテスト入力しないようにします。

計測も依頼範囲に含まれるなら、画面の完了と計測側の受信を別に記録します。対象サービスの権限がない場合は「未確認」と残します。フォームの詳しい確認は問い合わせフォームの改善と公開前QAへまとめています。

検索に公開する設定と、実際の登録状態を区別する

検索公開を意図するページでは、本番にnoindexが残っていないか、クロールを妨げていないか、意図した正規URLを示しているかを確認します。Googleの公式資料では、noindexを認識するにはGooglebotがページへアクセスできる必要があると説明されています。

canonicalは正規URLを示すための方法の一つですが、指定だけでGoogleの選択が確定するわけではありません。Search ConsoleのURL検査では、Googleインデックス側の情報とライブテストを区別して記録します。

「登録可能」「サイトマップに記載」「登録をリクエストした」は、実際の登録完了を意味しません。納品確認では、技術設定の結果と、Google側で取得できた登録状態を別欄にし、まだ情報がない場合は未照合と残します。検索順位や登録までを保証する表現に置き換えないでください。

不具合・追加要望・未確認を分けて引き継ぐ

見つかった点は、ページURL、再現手順、期待した結果、実際の結果、確認環境、証跡を1件ずつ残します。「フォームがおかしい」より、「指定ブラウザで必須項目を空にして送信すると、エラーの場所へ移動できない」の方が確認と再試験を進めやすくなります。これは記録方法の例であり、実在案件の不具合ではありません。

記録する状態 整理する内容 次の対応
合意した条件と不一致 どの条件を満たしていないか 担当と修正後の再確認方法を決める
追加で実現したいこと 当初の範囲との差と希望 範囲・費用・予定を別に相談する
まだ確認できていない 権限や資料、環境が不足する理由 必要な準備と確認日を決める

残件があるときの扱いを一方だけで決めず、公開や引き継ぎの条件を双方で確認します。契約上の判断や修正費用・期間は個別の取り決めによるため、共通の無料期間などを仮定しません。

制作会社へ相談するときに添えるもの

これから発注する場合は、対象サイト、目的、ページの候補、更新担当、必要な機能、移行元、希望する確認範囲を用意します。すでに納品を控えている場合は、合意資料と残件一覧、未確認の理由を加えます。パスワードや非公開の顧客データを、公開資料や一般の問い合わせ欄へ書く必要はありません。

SEVEN PEBBLESへ制作・リニューアルを相談する際も、まず「何を自社で更新し、何を制作側へ任せたいか」を整理すると、確認すべき範囲を共有しやすくなります。対応内容と条件は個別に相談してください。Web制作・リニューアルの相談窓口へ、現在の状況と検討事項をお送りください。

公開後の分担まで含めた比較には、ホームページ保守の範囲と費用の考え方もご活用ください。

出典・参考資料

一次資料の確認日：2026年10月16日。以下の機能・仕様を比較し、本文の判断表と確認例を作成しました。