Webサイト・LP公開前に確認する24項目のチェックリスト
公開前に確認するのは、headとmeta（1〜9）、見出し・画像・リンク（10〜15）、文言（16〜18）、表示と動き・フォーム（19〜24）の24項目です。このうち4・7・9・24の4項目は、公開した直後に本番のURLで見ます。
確認する項目を1行1項目の表にしておけば、毎回上から同じ順に見るだけで済み、その日の忙しさで見る場所が変わりません。
24項目を、ツールで見るか目視で見るか、公開前か公開直後かで分けた図です。目視の欄には、ツールでも一部を見られる3項目（7・11・16）が入っています。
下の表の「確かめ方」の「ツール」は、ページのソースや検証ツールの結果で確かめる項目、「目視」は画面を開いて、見たり操作したりして確かめる項目です。「いつ」の列は、公開前に見るか、公開した直後に見るかです。
「見るところ・合格の目安」の列には、その行を確認済みにしてよい状態を書きました。
表計算ソフトに貼るときは、下のブロックをそのままコピーしてください。タブ区切りなので、貼ると列に分かれます。「確認した日」と「メモ」の列は、案件ごとに埋めます。
No 確認すること 確かめ方 いつ 確認した日 メモ
1 title ツール 公開前
2 meta description ツール 公開前
3 OGPの3項目（og:title・og:description・og:image） ツール 公開前
4 SNSシェア表示 目視 公開直後
5 ファビコン・apple-touch-icon ツール 公開前
6 headの基本設定（viewport・charset・lang・canonical） ツール 公開前
7 計測タグ ツール＋目視 公開直後
8 JSON-LD ツール 公開前
9 noindex・Basic認証・テスト設定 目視 公開直後
10 見出し階層 ツール 公開前
11 alt ツール＋目視 公開前
12 重い画像 ツール 公開前
13 ダミー・粗い画像 目視 公開前
14 内部リンク切れ ツール 公開前
15 ボタン・電話・メールの飛び先 目視 公開前
16 誤字・表記ゆれ ツール＋目視 公開前
17 仮の文言 ツール 公開前
18 表記ルール ツール 公開前
19 デザイン再現 目視 公開前
20 画面幅ごとの表示 目視 公開前
21 ブラウザ・端末ごとの表示と動き 目視 公開前
22 動き 目視 公開前
23 HTML文法 ツール 公開前
24 フォーム送信とメール 目視 公開直後
headとmeta・公開の設定（1〜9）
ページを複製して作ると、前のページのtitleやdescriptionがそのまま残りがちです。1〜9は、HTMLのhead部分に書く情報と、公開時の設定です。
titleとmeta descriptionは、ページ同士で同じになっていないかを並べて見ます。
OGPの画像がテスト環境のURLのままだと、テスト環境が認証付きだったり公開後に消したりしたときに、SNSに貼っても画像が出ません。noindexとBasic認証は、外し忘れると検索にも人にも見えないサイトになります。この2つは公開前に本番用のファイルから外し、公開直後に本番のURLで本当に外れたかを見ます。
見出しと画像・リンク（10〜15）
10〜15は、見出しの順番、画像、リンクです。altは、意味のある画像に内容を書きます。
飾りの線や背景の画像には、読み上げで邪魔にならないよう alt=”” を入れます。alt=”” も指摘に出すツールがあるので、飾りの画像かどうかは自分で見分けます。
15のボタン・電話・メールの飛び先は、ツールでは正しさまで分かりません。電話番号は、スマホで実際に押して発信画面に出る番号を、クライアントからもらった資料の番号と1桁ずつ見比べます。
文言（16〜18）
「ダミーテキスト」のような仮の文言は、作った本人ほど見慣れて読み飛ばします。16〜18では、誤字と表記ゆれ、仮の文言、クライアントの表記ルールを見ます。
表記ルールは案件ごとに違うので、もらったルールを確認の前にメモへ書き出しておくと、見る基準がぶれません。
表示と動き・フォーム（19〜24）
19〜24は、画面を開いて手で触らないと分からない項目です。デザインカンプとの差、画面幅、ブラウザ、動き、フォームを見ます。
どの画面幅とブラウザで見るかは、案件の最初にクライアントと決めて、表の「メモ」の列に書いておきます。決めていないと、どこまで見れば終わりかが決まりません。
一人で確認するときに抜けやすいのはどこか
24項目は「ツールで確かめられるか、目視が要るか」と「公開前に見られるか、公開した直後にしか見られないか」の2つの軸で分けると、次の表のようになります。表の番号は、上の24項目の番号です。
一人で確かめるときに抜けやすいのは、表の右の列にある公開した直後にしか見られない4項目です。SNSに貼ったときの表示、計測タグでアクセスが計測されているか、noindexやBasic認証が外れているか、本番のフォームからメールが届くかの4つは、テスト環境では確かめきれません。公開して気が抜けたところで見忘れます。
もう1つは、目視で確かめる項目のうち、ボタンの飛び先や電話番号のリンクのように「作った本人は合っていると思い込んでいる」項目です。作った人ほど、書いたつもりの番号を読み流します。
チェックリストそのものの作り方や、確認する項目が毎回変わってしまう原因は、仕事の抜け漏れを防ぐチェックリスト術で説明しています。
納品のたびに、この表を案件ごとにコピーし、24行を上から順に見て、見つかったミスを書き出して直す作業を繰り返すことになります。
LP公開前のチェックリストを一人で確かめる手順
一人で回すときは、①ツールで見られる項目→②画面幅とブラウザ→③フォーム→④公開直後の順で見ます。ツールの指摘を直すとHTMLが変わるので、画面の確認を先にすると、直したあとに見直しが要るからです。
一人で回すときの順番です。ツールの指摘を書き出して直してから、画面幅とブラウザ、フォーム、公開直後の順に進みます。
①ツールで見られる項目を先に片付ける
最初に、ツールで確かめられる12項目と、ツールでも一部見られる3項目（7・11・16）のツールの部分を片付けます。項目ごとに、使う道具を先に決めておきます。
URLを入れて使う道具は、外から開けるページしか読めません。テスト環境に認証をかけているときは、一時的に外したURLを使うか、コードを貼り付けて確認できる入力欄があればそちらを使います。
ここで見つかった指摘は、まず全部をメモに書き出し、書き出し終えたらまとめて直してから②に進みます。1件ずつ直しながら進めると、どこまで見たかが分からなくなるからです。
整骨院のLPの例では、トップページだけで「altが空」「titleが短い」「リンク先のページがない」といった指摘が数行たまります。
②画面幅とブラウザの組み合わせを決めて見る
次に、案件の最初に決めた画面幅とブラウザの組み合わせを、1行ずつ表にして見ます。たとえば「スマホの幅×iPhoneのSafari」「パソコンの幅×Chrome」のように、組み合わせごとに確認した日を入れます。組み合わせを決めずに見ると、いつまでも終わりません。
見る順番は、19のデザイン再現から22の動きまで、どの組み合わせでも同じにします。メニューを開く、スライダーを送る、ページの一番下までスクロールする、の3つを毎回やると、動きの見落としが減ります。
同じ画面で、13のダミー画像や粗い画像、15のボタン・電話番号・メールの飛び先も見ます。11のaltの中身と16の誤字は、ツールが出した指摘のほかに、自分の目でも読みます。
電話番号のリンクは、スマホの幅で実際に押して、発信画面に正しい番号が出るかを確かめます。
③フォームは送信からメールの到着まで通しで試す
フォームは、送信ボタンを押して完了画面が出たところで終わりにしません。自動返信メールが入力したアドレスに届くか、管理者宛てのメールがクライアントの指定したアドレスに届くかまで、通しで試します。迷惑メールのフォルダも開いて見ます。
テスト環境で届いても、本番で届くとは限りません。サーバーが変わるとメールの送り方の設定も変わるので、公開直後に本番のフォームからもう一度送ります。
フォームは完了画面で終わりにせず、自動返信メールと管理者宛てメールの両方が届くところまで試します。
④公開した直後にしか見られない項目を確かめる
本番に公開したら（サーバーに上げたら）、すぐに4・7・9・24の4項目を本番のURLで確認します。noindexとBasic認証が外れているか、URLをSNSに貼って画像とタイトルが出るか、計測画面に自分のアクセスが出るか、本番のフォームからメールが届くかを見ます。この4項目は、公開した日の予定に入れておきます。
7の計測には、Search Consoleにサイトを登録してサイトマップを送ることも含めます。表の4項目のほかに、httpsのURLで開いて警告が出ないかも、この日に確認します。
SNSは一度読み込んだOGPをしばらく保存しています。直した画像が出ないときは、Facebookのシェアデバッガーのように確認ツールがあるSNSでは、それで読み直させます。
確認ツールが無いSNSでは、時間をおいてから貼り直して確かめます。
①〜④を回すと、メモには直す箇所が何行もたまります。指摘を書き出して修正内容に書き換え、直したら同じ行を見直します。この手作業の進め方は、次の章で表にしました。
Webサイト納品前チェックリストで見つかったミスの直し方
見つかった指摘は、1行1件の修正内容に書き換えてから直します。「altがない」のままでは、どのページのどの画像に、何を書けば終わりなのかが分かりません。
指摘を1件ずつ修正内容に書き換える
指摘を書き換えるときは、ファイル名、場所、直したあとの状態の3つを入れます。整骨院のLPの例なら、次のようになります。
クライアントや外注のコーダーに直してもらうときも、この形で渡すと、受け取った人が迷いません。修正の指示を1行1修正で書く方法は、Webサイトの修正指示の書き方で詳しく説明しています。
直したら同じ行をもう一度見てから渡す
直したら、その行の「直したあとに見るところ」をもう一度見て、確認した日を入れます。ヘッダーやフッターのように同じ部品を使っているページも一緒に見ます。1ページで直した部品が、別のページでは直っていないことがあるからです。
指摘が10行、20行とたまると、どれが直っていて、どれをまだ見ていないかを追うだけで手間がかかります。表を毎回コピーし、ツールの結果を書き写し、1行ずつ修正内容に書き換える作業は、納品のたびに同じ形で繰り返します。
サイト公開前のチェックツールで自動化できる範囲｜TASKULの納品前チェック
前の章の手作業のうち、5項目の確認、9項目の確認の一部、指摘ごとのタスク作りは、TASKULの納品前チェックに任せられます。一部だけを見る9項目の残りの部分と、HTML文法（23）は自分で確かめます。
直したあとの状態はタスクに自分で書き足し、画面幅・ブラウザ・動き・フォームの確認はこれまでどおり手作業で行います。
納品前チェックは、LP・WebサイトのZIPファイルをアップロードすると、HTMLの中身・meta・画像のalt・リンク切れなどを調べ、AIで誤字や表記ゆれも探す機能です。24項目に当てはめると、次のようになります。
TASKULの納品前チェックで見られる範囲です。24項目のうち10項目は検出しないので、画面幅・ブラウザ・動き・フォームなどは自分で確かめます。
使える条件と、できないこと
納品前チェックは、ProプランとFullプランだけで使えます。アップロードできるのはZIP形式・50MB以下のファイルで、読むのは.html・.htmのファイルと画像だけです。
CSSとJavaScriptのファイルは、チェックの対象外です。
そのため、WordPressのサイトをそのまま確かめることはできません。静的なHTMLに書き出したものをZIPにすればチェックできますが、書き出したHTMLのリンクがhttpから始まる書き方だと、リンク切れは確かめられません。
反対に、contact/ のようにフォルダで終わるリンクは、中にindex.htmlがあっても「内部リンク切れ」と出るので、その指摘は自分でリンクを開いて確認します。1か月に使える回数には上限があり、AIのチェックでは、AIの処理量に応じてAIクレジットが減ります。
画面にも「※ AIによる自動チェックのため、結果はすべて正確とは限りません」と出るので、AIの指摘は自分の目でも確かめます。
WordPressのサイトを公開した状態のままチェックしたい人や、CSSやJavaScriptの不具合を見つけたい人には向きません。
TASKULで公開前チェックをかけて、指摘をタスクにする手順
手順は3つです。最後の手順で、指摘ごとのタスクが一度にできます。タスクの説明にはファイル名・問題・修正案が入るので、前の章の「1行1件の修正内容」のうち、直したあとの状態だけを書き足します。
手順1：プロジェクトの「納品前チェック」タブでZIPを選ぶ
案件のプロジェクトを開き、「納品前チェック」タブで、公開するLPのHTMLと画像をまとめたZIPを選びます。
手順2：表記ルールを「レギュレーション・チェックルール（任意）」に書いて「チェック実行」を押す
クライアントの表記ルールがあれば、ルール欄に貼ります。整骨院のLPの例なら「『お問い合わせ』は『お問合せ』に統一する」のように1行ずつ書き、「チェック実行」を押します。
架空の整骨院のLPのZIPを選び、ルール欄に表記ルールを2行書いた状態です。「チェック実行」の横に「※ AIによる自動チェックのため、結果はすべて正確とは限りません」と出ます。データは架空です。
手順3：直す指摘を選んで「〇件をタスク化」を押す
チェック結果は、要修正・確認推奨・参考の3つに分かれて並びます。直す指摘にチェックを入れて「〇件をタスク化」を押すと、指摘の文がタスク名になり、説明欄にカテゴリ・ファイル名・問題・修正案が入ったタスクが、そのプロジェクトにまとめてできます。
チェック結果です。要修正4件・確認推奨3件・参考1件の合計8件が並び、要修正の4件にチェックを入れて「4件をタスク化」を押せる状態です。表記ゆれと仮の文言の2件はAIの指摘で、文面は撮影用の作例です。データは架空です。
「4件をタスク化」を押したあとの、同じプロジェクトのタスク一覧です。指摘の文面がそのままタスク名になり、未着手で一番下に並びました。メモ欄には、カテゴリやファイル名などの説明が入っています。データは架空です。
外注のコーダーに直してもらうなら、TASKULのチーム共有でパートナーをプロジェクトに招待すれば、できたタスクの担当者にできます。納品前チェックはProプランの14日間無料トライアル（2026年10月30日23:59までのキャンペーン）で試せるので、次に公開するLPのZIPで、TASKULの納品前チェックを1回かけてみてください。
Webサイトの公開前チェックでよくある質問
公開前チェックにはどれくらい時間がかかりますか？
サイトの規模と、見る画面幅・ブラウザの組み合わせの数で変わるので、一律には言えません。Web制作会社のベイジは、公開前の最終チェックにサイトの規模によって1～4人日かかり、複数人で分担することが多いと書いています。
一人で回すなら、1案件ごとにかかった時間を表の横に書いておくと、次の見積もりで使えます。
一人でダブルチェックするにはどうすればいいですか？
見る人を変えられないときは、見る日と見る順番を変えます。作った日の翌日に、表を下の行から見直すと、作った流れに引きずられにくくなります。確認する項目を毎回同じにする仕組みは、抜け漏れを防ぐチェックリストの作り方で紹介しています。
WordPressのサイトもTASKULの納品前チェックで確かめられますか？
WordPressのサイトをそのまま確かめることはできません。読むのはZIPに入ったHTMLと画像だけです。
静的なHTMLに書き出したものをZIPにすればチェックできますが、リンクがhttpから始まる書き方になっていると、リンク切れは確かめられません。
TASKULの指摘が0件なら、そのまま納品していいですか？
いいえ。24項目のうち10項目は検出しないので、SNSシェア表示、noindex、ボタンの飛び先、画面幅、ブラウザ、動き、フォームなどは、指摘が0件でも目視で確認します。
一部だけを見る9項目（titleの重複、OGP画像のURL、httpから始まるリンク、altの中身など）も、自分で確かめます。
公開後にミスが見つかったらどうしますか？
まずチェックリストに1行足してから直します。直したら、同じ部品を使っているページも見直します。クライアントには、何をいつ直したかを1行で伝えます。足した行は次の案件から表に残るので、同じミスを繰り返しにくくなります。
無料プランで納品前チェックは使えますか？
使えません。納品前チェックはProプランとFullプランの機能です。
無料のFreeプランでは、24項目をプロジェクトのタスクとして登録し、確認が済んだ行から完了にしていく使い方ができます。Proプランは14日間無料で試せます（2026年10月30日23:59までのキャンペーン）。
まとめ｜Webサイトの公開前チェックはツール→画面→フォーム→公開直後の順に回す
Webサイトの公開前チェックは、24項目を「ツールで確かめられる12」と「目視で確かめる12」に分け、ツール→画面幅とブラウザ→フォーム→公開直後の順で回します。見つかった指摘は、ファイル名・場所・直したあとの状態を入れた1行1件の作業に書き換え、直したら同じ行と同じ部品のページを見直します。
公開した直後にしか見られない4項目は、公開した日の予定に入れておきます。納品したあとの検収や支払いの段取りは、納品後の検収が終わらないときの対処法で説明しています。
案件が重なって、表のコピーと指摘の書き写しが手間になってきたら、TASKULのProプランを14日間無料で試して、次に公開するLPのZIPで納品前チェックをかけてみてください。24項目をタスクとして並べて管理するだけなら、無料のFreeプランでも使えます。
