制作・引き渡し
WordPress納品チェックリスト｜公開前・公開後・引き渡しの確認項目
WordPressサイトの納品チェックリストを、公開前・本番公開後・引き渡しの3段階で整理。表示、フォーム、検索設定、認証、バックアップの確認操作と合格条件、結果の記入例を紹介します。編集して使えるExcel付き。
WordPressサイトの納品では、表示、フォームの受信、検索設定、更新操作、バックアップまで確認します。制作環境で問題なく動いていても、本番のURLやメール設定に切り替えると結果が変わることがあります。
一般的な企業サイトを想定し、納品時の確認を「公開前」「本番公開後」「引き渡し」の3段階に分けます。各項目に確認操作と合格条件を添え、結果を残せるExcelも用意しました。特定のテーマやプラグインを使っていなくても利用できます。
WordPress納品チェックリストをダウンロード（Excel）
WordPress納品チェックリストの使い方
チェックを始める前に、仕様書やページ一覧を見ながら、対象URL・機能・確認する端末とブラウザを決めます。そのうえで、次の順に使ってください。
| 確認する時点 | 主な対象 | 確認の終わり方 |
|---|---|---|
| 公開前 | 原稿、表示、リンク、WordPress設定、更新操作 | 検証環境で仕様との不一致を直し、本番で再確認する項目を残す |
| 本番公開後 | 公開URL、フォーム、HTTPS、検索設定、計測 | 本番の条件で動かし、実際の表示・受信・記録まで確かめる |
| 引き渡し | バックアップ、権限、操作説明、管理担当、残件 | 顧客と確認結果を共有し、今後の担当と対応予定を記録する |
公開と納品の順序は案件によって異なります。公開前に一度納品する場合も、本番確認の担当と実施予定を残しましょう。「本番ではまだ試していない」を、公開前の確認結果で埋めないことが大切です。
結果は4種類に分ける
Excelでは、各項目に「未確認」「OK」「要対応」「対象外」を記録します。
- 未確認：まだ試していない、または判断に必要な結果がそろっていない
- OK：決めた環境・範囲で操作し、合格条件を満たした
- 要対応：不備が見つかったため、修正や再確認が必要
- 対象外：今回の仕様では不要と確認した。理由も残す
フォームのないサイトなら、フォームの項目は対象外にできます。一方、フォームはあるものの顧客側で受信を確認できていない場合は、未確認です。
本記事の表は、一般的な企業サイトの確認を始めるためのひな形です。EC決済、会員サイト、予約、マルチサイトなどは、購入・アクセス制御・在庫等の固有の検査を追加してください。サイト移転を伴う場合も、DNS、既存メール、旧URLからの転送など、移行計画に沿った確認が必要です。
公開前：表示・内容・リンクを確認する
まず、クライアントが承認した内容と、実際に表示される内容を照合します。トップページだけでなく、下層ページや一覧の2ページ目など、普段見落としやすい画面も対象に含めます。
原稿・画像・画面表示
| ID | 確認項目 | 確認する操作 | 合格条件 |
|---|---|---|---|
| A01 | 正式な原稿・連絡先 | 承認済み原稿と各ページを照合し、会社名・数値・日付・電話番号等を確認する | 正式情報と一致し、ダミー文章・仮の数値・誤字が残っていない |
| A02 | 画像・資料の差し替え | 写真、ロゴ、ダウンロード資料を開き、内容と使用許可を確認する | 採用した素材が表示され、透かし・仮画像・旧版の資料が残っていない |
| A03 | PC・スマートフォンの表示 | 合意した端末・ブラウザで各ページを開き、文字・画像・表・メニューを見る | 文字やボタンが欠けず、重なりで操作を妨げない。表以外で不要な横スクロールがない |
| A04 | キーボード・読みやすさ | Tabキー等で主要操作を試し、フォーカス、見出し、画像の代替テキストを確認する | 操作対象が分かり、主要経路を操作できる。情報を伝える画像の内容を文字でも把握できる |
| A05 | 読み込み・画像容量 | 主要ページを初回表示し、画像の容量や読み込みの遅い箇所を調べる | 合意した表示性能の条件を満たし、極端に重い画像や操作を妨げる遅延が残っていない |
ブラウザの画面幅を狭める確認と、スマートフォン実機での確認は分けて記録します。実機で試していない場合は、その点を残してください。横長の表を表の領域内だけでスクロールできる設計は、ページ全体が横にはみ出す不具合とは別です。
代替テキストは画像の役割に合わせます。内容の説明が必要な画像と装飾画像を区別し、すべての画像へ同じ説明文を入れる扱いにはしません。基本的な考え方はW3Cの画像のアクセシビリティ解説も参考になります。
A05で遅い箇所を調べるには、Chromeの開発者ツールで「Network」を開き、ページを再読み込みします。画像等の転送量や読み込み時間を見て、重いファイルを絞り込みます。端末・通信条件・キャッシュで結果が変わるため、確認条件も記録してください。
リンク・一覧・検索などの機能
| ID | 確認項目 | 確認する操作 | 合格条件 |
|---|---|---|---|
| A06 | 主要な導線 | ヘッダー・フッター・本文から、サービス紹介や問い合わせ等へ順に進む | 意図したページへ到達でき、空リンクや制作環境へのリンクが残っていない |
| A07 | 外部リンク・電話・資料 | 外部サイトや資料を開き、電話・メールのリンク先も確認する | 正しい宛先や資料が開く。電話やメールは意図した番号・宛先が表示される |
| A08 | 一覧・詳細・検索 | 採用した一覧・詳細・ページ送り・検索を、結果あり／なしの条件で試す | 対象コンテンツに到達でき、結果0件でも次の操作が分かる |
| A09 | 存在しないURL | 存在しないページを開き、表示とHTTPステータスを確認する | 404として応答し、利用者がトップ等へ戻れる案内がある |
リンクチェックツールは、リンク切れを探す補助に使えます。ただし、正常に開けても別の会社のSNSだったり、古いPDFだったりすることはあります。主な導線は人が内容まで確認しましょう。電話・メールのリンクは、確認だけのために実際の発信や送信をする必要はありません。
公開前：WordPressの設定と更新操作を確認する
公開画面の確認が終わったら、管理画面と更新の流れを見ます。制作担当の管理者アカウントで操作できたことと、納品後の担当者が操作できることは、別に確認します。
| ID | 確認項目 | 確認する操作 | 合格条件 |
|---|---|---|---|
| B01 | 基本設定・パーマリンク | サイト名、管理用メール、時刻、ホーム・投稿ページ、サイトURL・パーマリンクを案件条件と照合し、実URLも開く | 設定が運用方針に合い、合意したURLで表示できる。制作時の仮設定が残っていない |
| B02 | テーマ・プラグイン・更新方針 | 使用中の版、用途、更新の要否と検証結果を一覧で確認する | 用途と管理担当が分かり、必要な更新を検証済み。不具合や未対応事項を放置していない |
| B03 | 不要なデータ・機能 | テスト投稿、仮ユーザー、コメント・ピンバック、未使用ソフトを確認する | 不要と確認したものを整理し、必要な下書きや依存するテーマ等を残している |
| B04 | エラー・デバッグ出力 | 主要画面と管理画面を操作し、エラー表示・ログ・サイトヘルスの指摘を確認する | 操作に支障のあるエラーや機密情報の表示がなく、未解決の指摘には対応方針がある |
| B05 | アカウント・権限・認証 | 利用者・役割と認証情報の管理方針を照合し、担当者のログイン・権限・採用した追加認証を試す | 必要な操作だけを行え、不要な共有アカウントがない。強固なパスワードを使い、採用した認証が機能する |
| B06 | 記事・画像の更新 | 検証用コンテンツで編集・プレビュー・公開・画像差し替えを試す | 合意した更新ができ、公開表示へ正しく反映される |
基本設定と認証の確認場所
B01では、管理画面の「設定 → 一般」でサイト名・管理用メール等、「設定 → 表示設定」でホーム・投稿ページを確認します。「設定 → パーマリンク」では合意したURL構造を照合し、実際の投稿・一覧も開きます。納品直前に見栄えだけでURL構造を変えず、変更が必要なら既存リンクや転送への影響を先に確認してください。WordPress公式のパーマリンク設定も参照できます。
B04の確認は「ツール → サイトヘルス」が入口です。指摘された項目と対応方針を残し、公開画面・管理画面の実操作も行います。サイトヘルスに問題が表示されないことだけで、すべての機能を検査済みにはしません。
B05では、本人が強固で使い回しのないパスワードを管理していることを確認します。パスワードそのものを聞き取って表に残す必要はありません。二要素認証を採用した場合は本人によるログインと復旧方法も確認します。WordPress公式のセキュリティ解説を参考に、ログインURLの変更だけで認証対策が完了したとは扱わないでください。
更新は、納品直前にまとめて実行して終わりにせず、バックアップと動作確認を含めて計画します。テーマ・プラグインには親子関係や機能上の依存があるため、「停止中だから不要」とは決めつけません。
コメントやピンバックを使わない案件では、基本設定に加えて既存投稿の受付状態も確認します。設定を変えても、作成済みの投稿が同じ状態になっているとは限りません。
WordPressの権限は、標準の役割に加え、プラグイン等で変更される場合があります。WordPress公式の権限資料を基準に、実際に渡すアカウントで確かめましょう。採用サイトで顧客へ渡す操作自体を検討する場合は、顧客権限の設計記事で判断の順序を整理しています。
本番公開後：フォーム・検索設定・計測を確認する
検証環境で確認を済ませても、本番への切り替え後に改めて試します。ログアウトした状態で主要な経路をたどってください。ログイン中だけ表示されるページや、キャッシュによる表示の違いも確認できます。
本番URLとフォームの送受信
| ID | 確認項目 | 確認する操作 | 合格条件 |
|---|---|---|---|
| C01 | 本番での主要経路 | ログアウトしてA03・A06・A08の対象を本番URLで再確認する | 閲覧者が必要なページを表示・操作でき、検証環境との差による不具合がない |
| C02 | HTTPS・URL転送 | 本番のトップと下層へアクセスし、証明書、読込エラー、http等からの転送を確認する | 意図したHTTPSのURLへ到達でき、証明書警告や転送ループがない |
| C03 | 本番の通知先・送信内容 | フォームの宛先、返信先、通知文、個人情報の案内を運用担当と照合する | 承認した宛先・文面が設定され、入力前に必要な案内を読める |
| C04 | 正常送信と受信 | 合意したテスト情報で送信し、完了画面、運用先の受信、必要な自動返信を確認する | 入力内容が正しく届き、文字化けや通知の欠落がない |
| C05 | 入力エラー・添付・スパム対策 | 空欄や不正な形式、採用した添付機能・スパム対策の許可／拒否条件を、合意した方法で試す | 入力制御と対策が仕様どおり働き、直す項目が分かる。通常の送信を妨げず、不要な通知を送らない |
| C06 | 外部サービス・埋め込み | 本番から地図、予約サービス、外部フォーム等の採用機能を使う | ドメイン制限や認証等に阻まれず、合意した操作を完了できる |
C02の例として、正規URLを https://example.com/service/ とします。http://example.com/service/ を開き、同じ下層の正規URLへ到達するかを確認します。www付きURLも受け付ける設計なら、その転送も試します。トップだけに戻されたり、転送が繰り返されたりしていないかを見ましょう。「入力したURL」「到達URL」「結果」を記録します。ここでのドメインは説明用の例です。
転送の途中やA09の404応答は、Chrome開発者ツールの「Network」で確認できます。「Preserve log（ログを保持）」を有効にして対象URLへ移動し、ページ本体のリクエストを選びます。「Headers（ヘッダー）」のステータスコードや、転送応答の Location を見ます。使い方はChrome公式のネットワーク機能解説を参照してください。
フォームは「送信しました」という画面だけでOKにしません。運用担当の受信箱に届いたこと、自動返信を使う場合は入力者側にも届いたことを確認します。未着なら、通知先、送信設定、配信ログ、迷惑メール判定等を切り分け、修正後に再テストします。
テスト日時・件名・受信確認者を残すと、どの送信を確認したかが分かります。実在する顧客情報や応募者情報は使わず、テスト用と分かる内容を運用担当と合意してください。記録にメール本文を丸ごと貼る必要はありません。
C05でスパム対策を採用している場合は、通常の問い合わせが通ることを確認します。拒否条件は、製品が用意したテスト方法で別に確かめてください。本番ドメインの設定や、添付・同意欄との組み合わせも対象です。大量送信で試す必要はありません。未採用の機能は理由を記録し、特定の認証サービスの導入を全案件へ一律に求めないようにします。
検索エンジン・SNS・アクセス計測
| ID | 確認項目 | 確認する操作 | 合格条件 |
|---|---|---|---|
| C07 | 検索対象と除外設定 | 検索対象ページのrobots指定、HTTPヘッダー、robots.txtを方針と照合する | 検索させたいページを誤って除外・クロール拒否していない。除外対象は意図どおり |
| C08 | タイトル・説明・正規URL | 各ページのtitle、description、canonical等の出力を確認する | ページ内容に合い、仮文章や制作環境のURLを出力していない |
| C09 | XMLサイトマップ | 実際のサイトマップURLを開き、対象URLとSearch Consoleの処理状況を確認する | 対象ページが本番URLで含まれ、意図しないURLが混入していない。送信を担当する場合は結果も記録済み |
| C10 | OGP・サイトアイコン | 本番で出力される画像・タイトル・URLと、対応する確認ツール等での表示を見る | 意図した情報が取得でき、仮画像や別サイトの情報が残っていない |
| C11 | アクセス・成果計測 | 合意した同意条件で閲覧・問い合わせ等を試し、計測側の確認画面と照合する | 採用したタグやイベントが仕様どおりに記録され、意図しない重複がない |
検索設定は管理画面と本番の出力を照合する
C07・C08では、検索対象ページと除外するページを先に決め、次の順に確認します。
- 管理画面の設定を見る。 「設定 → 表示設定」の「検索エンジンでの表示」と、採用したSEOプラグインのページ別設定を照合します。設定画面の見方はWordPress公式の表示設定を参照できます。
- 本番ページのHTMLを見る。 ログアウトして対象URLを開き、ブラウザの「ページのソースを表示」を選びます。
robots、googlebot、title、description、canonicalを探します。検索対象に意図しないnoindexがないか、正規URLが本番URLかを確認します。 - HTTPヘッダーとrobots.txtを見る。 開発者ツールの「Network」を開き、ページを再読み込みします。ページ本体の「Headers」で
X-Robots-Tagの有無と内容を確認します。サイトの/robots.txtも開き、対象URLへのクロールを妨げる指定がないか照合します。
たとえばトップとサービス紹介は検索対象、フォームの完了ページは除外対象、とページごとに結果を残します。管理画面のチェック状態が正しくても、本番のHTMLやヘッダーに別の指定が出ていれば、設定元を調べて再確認します。この照合だけで検索結果への登録を保証するものではありません。
noindexは検索結果への登録を制御する指定です。robots.txtによるクロール拒否とは働きが異なります。クロールを拒否するとGoogleがnoindexを読み取れないことがあります。意図した除外を一律に解除せず、Google公式のnoindexの説明と照らして確認します。
XMLサイトマップも、ファイルが開くだけで終わらせず、含まれるURLを見ます。生成方法によってURLが異なるため、実際のWordPressやSEOプラグインの設定から確認してください。Search Consoleへの送信が成功しても、すべてのページが登録される、上位表示されるという意味ではありません。
計測ツールを導入しない案件では、C11は対象外です。導入する場合は、何を成果として数えるか、テスト送信を実績に含めるかも決めます。管理担当まで合わせておくと、運用へつなげやすくなります。
引き渡し：バックアップ・管理権限・運用担当を確認する
納品後にサイトを運用できるよう、復元方法と管理主体を整理します。WordPressへのログイン情報だけでなく、サーバー・ドメイン・メール・有料サービスの更新も確認対象です。
| ID | 確認項目 | 確認する操作 | 合格条件 |
|---|---|---|---|
| D01 | バックアップの範囲・保管 | データベースと必要なファイルの取得時点、保管先、取得結果を確認する | 復元に必要なデータがそろい、担当者が取り出せる。公開領域へ不用意に置いていない |
| D02 | 復元方法 | 公開前に決めた手順で隔離環境へ復元し、主要表示と管理操作を確認する | 復元結果を確認でき、手順・担当・必要な権限が分かる |
| D03 | 管理主体・更新期限 | サーバー、ドメイン、メール、ライセンス、計測等の管理者と更新条件を照合する | 各管理対象の契約・支払い・更新担当が決まり、引継ぎ先が必要な権限を持つ |
| D04 | 顧客のログインと操作 | 顧客自身のアカウントでログインし、合意した更新と確認を一緒に行う | 顧客が必要な操作を実行でき、不明点と操作資料の所在が解消している |
| D05 | 保守・問い合わせ窓口 | 更新、障害、バックアップ、修正依頼の連絡先と対応範囲を共有する | 何を誰に依頼するかが分かり、未契約の保守を実施する前提にしていない |
| D06 | 残件と確認結果の共有 | 要対応・未確認の項目、修正担当、期限、再確認の方法を顧客と照合する | 公開・納品への影響が判断され、残件の扱いに認識のずれがない |
バックアップは、WordPressのデータベースとファイルの両方が必要です。WordPress公式のバックアップ解説を参照し、データを取得したことと、復元できたことを分けて確認しましょう。本番サイトへ試しに復元するのではなく、外部への通知や決済等を止めた隔離環境で試します。
顧客と一緒に更新を確認するときは、制作担当が操作を代行し続けず、実際の担当者に試してもらいます。「お知らせを編集する」「画像を差し替える」「公開前に表示を確認する」など、運用で必要になる操作を選んでください。
パスワードやライセンスキーを、このチェック表に直接記入しないようにします。アクセス情報は別の適切な方法で渡し、表には「共有先」「管理担当」「受領確認済み」などの事実を残します。
チェック結果の記入例と、未完了項目の残し方
次は、架空の小規模企業サイトを想定した記入例です。実際のサイトの検査結果ではありません。
| ID | 項目 | 結果 | 記録する内容の例 |
|---|---|---|---|
| C01 | 本番での主要経路 | OK | 9/17、担当A。トップ→サービス→問い合わせをPC Chrome・iPhone Safariで確認。表示記録を保存 |
| C04 | 正常送信と受信 | 要対応 | 9/17、担当A。テスト件名「納品確認01」。完了画面と自動返信は確認、運用先の通知は未着。担当Bが9/18までに配送設定を確認し、再送信する |
| A08 | 一覧・詳細・検索 | 対象外 | サイト内検索のみ不採用。9/17に仕様書と照合済み。一覧・詳細・ページ送りは別の行に分けて確認する |
| D04 | 顧客のログインと操作 | 未確認 | 制作担当では操作できたが、顧客の操作確認は未実施。担当Cと9/19に実施予定 |
一つの項目に「確認済み」と「未確認」が混在する場合は、行を分けます。A08の例なら、サイト内検索が不要という理由だけで、必要な一覧・詳細まで対象外にしないようにしてください。
不具合が見つかったら、現象だけでなく、対象URL・環境・確認日・次の担当・期限を残します。修正後は、同じ条件で再確認してから結果を変更します。
フォームの未着、必要なページの表示不良、権限の不備による情報の露出は、公開や納品の判断に直結します。「ほかの項目がOKだから進める」とせず、該当機能を含めて公開を止めるのか、修正後に切り替えるのかを関係者で決めましょう。
Excelに確認結果を残す
配布Excelには、「確認リスト」「記入例」「使い方」の3シートを用意しています。本文と同じ項目を使い、対象URL・環境、結果、確認者と日付、記録・残件、対応担当と期限を記入できます。
WordPress納品チェックリストをダウンロード（Excel）
「確認リスト」の黄色い欄へ記入してください。初期状態はすべて未確認です。対象ページや機能が多い場合は行を複製して分け、結果や担当をそれぞれ残します。項目を追加したときは、表の範囲、結果の選択肢、上部の集計範囲も追加行まで含めてください。
上部の件数は作業状況の把握用です。OKの件数だけで納品を自動判定するものではありません。対象外の理由と未完了項目を含めて共有し、案件ごとの合意条件と照合して使います。
まとめ：本番での動作と、引き渡し後の運用まで確かめる
WordPressの納品確認は、表示・設定から始め、本番のフォームや検索設定、顧客の更新操作へ進めます。
チェックリストには、操作した環境と合格条件、確認結果を残しましょう。公開前に試したものを本番で再確認し、最後にバックアップ・管理担当・残件を共有します。記録があれば、何を確かめて引き渡したかを後からたどれます。
採用サイト特有の工程や役割分担は、WordPress採用サイトの制作・引き渡しチェックリストも参照してください。