公開前チェック:表示速度・スマホ・アクセシビリティ・検索・セキュリティ|Webサイト制作の基本と進め方 第5回
監修田中 磨生株式会社Abin 代表取締役
株式会社Abin代表取締役。AI SaaSの上場企業やHR系ベンチャーのマーケティング責任者を経て、2023年BtoBマーケティング特化のコンサルティング会社株式会社Abinを設立。創業から30社以上のBtoBマーケティングの戦略立案から実行までを行う。2025年には株式会社プロベルの役員に就任。NYマーケティング株式会社の執行役員も務める。
執筆Abin編集部

この回で分かること:①公開前に何を確かめればよいかを、6つの観点で整理する方法、②表示速度の目安(Core Web Vitals)とスマホ対応、アクセシビリティの基本、③検索と計測、セキュリティと個人情報で、公開前に必ず確かめたい設定。前回は制作会社への発注と進め方を学びました。今回は、完成したサイトを世に出す直前の「検収」の中身です。

公開前チェックは「検収の基準」になる
第4回で、納品物を確認して完成を認めることを「検収」と呼びました。公開前チェックは、その検収の中身そのものです。何を確かめるかが決まっていないと、確認は「なんとなく見て、良さそうならOK」になり、公開後に問題が見つかります。
図1は、公開前に確かめる6つの観点です。
- 表示と内容:誤字脱字、リンク切れ、画像の抜け、古い情報が残っていないか
- スマホ・ブラウザ:主要な端末やブラウザで、崩れずに表示・操作できるか
- 表示速度:ページが速く表示され、操作にすぐ反応するか
- アクセシビリティ:さまざまな人や環境で、情報が伝わり、操作できるか
- 検索・計測:検索エンジンに正しく伝わり、成果を測れる状態か
- セキュリティ・個人情報:情報が守られ、扱いが正しく示されているか
第3回で要件定義書に「非機能」の条件を書いておくと、それがそのままチェックの基準になります。制作会社も社内でテストをしていますが、発注側が自分の目で確かめる項目を決めておくことが大切です。
観点1・2:表示と内容、スマホとブラウザ
最初に、ページの中身そのものを確かめます。
- 文章:誤字脱字、表記の揺れ、古い情報(住所、電話番号、料金、役員名など)が残っていないか
- リンク:すべてのボタンやリンクが、正しいページに飛ぶか。外部サイトへのリンクが切れていないか
- 画像:すべての画像が表示されるか。ぼやけていないか。使用許諾の確認が済んでいるか
- フォーム:実際に送信して、完了画面が出るか。通知メールが正しい宛先に届くか。自動返信メールの文面は正しいか
次に、スマホとパソコン、主要なブラウザで表示と操作を確かめます。Googleは、スマートフォン向けのクローラーで取得したモバイル版のページを使って、検索のインデックス登録とランキングを行っています(モバイルファースト インデックス)。検索の面でも、読者の面でも、スマホでの見え方と使いやすさは最優先で確かめるべき項目です。
スマホでは、とくに次の点を確かめます。
- 文字が小さすぎないか、横にはみ出してスクロールが必要になっていないか
- ボタンやリンクが指で押しやすい大きさで、押し間違えにくい間隔か
- 問い合わせボタンが見つけやすいところにあるか
- フォームの入力がしやすいか(フォームの改善はLP・CVR改善の教科書でも扱っています)
Googleの「モバイルファースト インデックス」の説明として、最も適切なものはどれでしょう?
- パソコン版のページだけを使って検索の順位を決める
- スマートフォン向けのクローラーで取得したモバイル版のページを使って、インデックス登録とランキングを行う
- スマホからの検索にだけ適用される
答えと解説
正解は2です。Googleはモバイル版のページを基にインデックス登録とランキングを行っています。スマホでの表示と内容を、パソコン版と同じくらい、あるいはそれ以上に丁寧に確かめる必要があります。
観点3:表示速度とCore Web Vitals
ページの表示が遅いと、読者は待ちきれずに離れてしまいます。表示速度を測る代表的な指標が、Googleが定めているCore Web Vitalsです。図2は、その3つの指標と「良好」の目安です。

- LCP(Largest Contentful Paint):ページの中でいちばん大きな要素(大きな画像や見出しなど)が表示されるまでの時間です。2.5秒以内が良好の目安です。
- INP(Interaction to Next Paint):ボタンを押すなどの操作をしてから、画面が反応するまでの時間です。200ミリ秒以内が良好の目安です。
- CLS(Cumulative Layout Shift):表示の途中で、画像や広告が遅れて読み込まれてレイアウトがずれる量です。0.1以下が良好の目安です。
web.devの説明では、これらはページの読み込みの75パーセンタイル(遅いほうから4分の1にあたる値)で、モバイルとパソコンに分けて評価します。つまり、速い環境で1回見て速かったから良い、ではなく、多くの人にとって速いかを見る指標です。
GoogleはCore Web Vitalsをランキングのしくみで使っていると説明しています。ただし同時に、スコアが良いからといって上位に表示されることが保証されるわけではなく、内容が役に立つことのほうが大切だとも説明しています。表示速度は、検索のためというより、読者に快適に使ってもらうための条件として改善しましょう。
公開前の段階では、PageSpeed Insightsなどのツールで主要なページを測り、大きな画像がそのまま載っていないか、不要な読み込みが多くないかを制作会社と確かめます。
観点4:アクセシビリティ
アクセシビリティは、年齢や障害の有無、使っている端末や環境にかかわらず、誰もが情報を得て、操作できるようにすることです。目が見えにくい人が画面の読み上げソフトを使う、手が不自由な人がキーボードだけで操作する、明るい屋外でスマホを見る、といったさまざまな状況を想定します。
日本では、ウェブコンテンツのアクセシビリティの規格としてJIS X 8341-3があります。国土交通省の資料では、JIS X 8341-3は国際規格ISO/IEC 40500:2012と内容が一致し、W3CのWCAG 2.0の解説書が理解の参考になると説明されています。また、WCAG 2.1・2.2で追加された内容はJIS X 8341-3には含まれていないとも書かれています。デジタル庁は、自らのWebサイトで「JIS X 8341-3:2016における適合レベルAAに準拠することを目標」としています。
すべての基準を一度に満たすのは大変ですが、公開前に図3の基本だけでも確かめておきましょう。

- 見る:文字と背景のコントラストが十分か。画像に、その内容を説明する代わりの文章(alt属性)が入っているか。赤と緑のように、色だけで情報を区別していないか。
- 操作する:マウスを使わず、キーボードだけでメニューやフォームを操作できるか。フォームの入力欄に、何を入れる欄かを示すラベルがあるか。エラーのときに、どこが・なぜ間違っているかが分かるか。
- 理解する:見出しが正しい順番(大見出し→中見出し)で使われているか。「こちら」ではなく、リンク先が分かる文言になっているか。ページの言語が正しく指定されているか。
アクセシビリティの考え方と具体的な点検のしかたは、UI・UXデザイン入門の講座で詳しく扱っています。
アクセシビリティの観点から、画像に入れておくべきものはどれでしょう?
- 画像の内容を説明する代わりの文章(alt属性)
- 画像を作ったデザイナーの名前
- 画像のファイルサイズ
答えと解説
正解は1です。代わりの文章があると、画面の読み上げソフトを使う人にも、画像が何を伝えているかが伝わります。画像が表示されない環境でも役立ちます。
観点5:検索と計測の設定
公開した瞬間から、検索エンジンに正しく伝わり、成果を測れる状態にしておく必要があります。図4は、公開前に確かめたい項目です。

- タイトル・説明文:Googleの「SEOスターターガイド」では、良いタイトルは「そのページに固有で、明確かつ簡潔であり、内容を正確に説明している」ものだと説明されています。すべてのページが同じタイトルになっていないか、確かめましょう。
- URL:ページの内容が分かる語が入っているか、公開後に変えなくてよい形になっているかを確かめます。
- noindexとrobots.txt:制作中のテスト環境では、検索結果に出ないように「noindex」という指定を入れていることがよくあります。Googleの説明では、noindexが検出されたページは検索結果から削除されます。この設定が本番に残ったまま公開してしまうと、いつまでも検索に出ません。公開前に必ず外れているかを確かめる項目です。
- 旧URLからの転送:リニューアルでURLが変わる場合、Googleは、技術的に可能ならサーバー側の永続的なリダイレクト(301など)を使い、旧URLと新URLの対応表を作り、リダイレクトはできるだけ長く(一般に1年以上)残すことを勧めています。対応表は第3回の要件の段階から準備しておきます。
- 計測:Googleアナリティクス4(GA4)のタグが入っているか、問い合わせなどの成果が「キーイベント」として計測されるか、Search Consoleにサイトを登録したかを確かめます。設定の具体的な手順はアクセス解析とGA4の講座で扱っています。

観点6:セキュリティと個人情報
最後に、情報の守り方と扱いを確かめます。図5は、その主な項目です。

- HTTPS:すべてのページがHTTPSで表示され、「http」で始まるURLにアクセスしたときもHTTPSに転送されるかを確かめます。
- CMSと拡張機能:CMSの本体やプラグインが最新の版になっているか。使っていないプラグインは削除したか。WordPressの公式の解説でも、常に最新のバージョンに更新することと、使っていないプラグインを削除することが勧められています。
- 管理画面:管理画面のパスワードは推測されにくいものか。多要素認証を使えるか。制作中に作ったテスト用のアカウントは消したか。
- フォーム:個人情報を集めるフォームでは、利用目的の扱いを確かめます。個人情報保護委員会のガイドライン(通則編)では、Webの入力画面などで本人から直接個人情報を取得する場合、あらかじめ本人に利用目的を明示することが求められています。プライバシーポリシーへのリンクや、利用目的の説明をフォームの近くに置きましょう。
- バックアップ:バックアップがどこに、どのくらいの間隔で取られているか。実際に戻せることを試したか。
Webサイトのセキュリティについては、情報処理推進機構(IPA)が開発者・運営者向けに「安全なウェブサイトの作り方」を公開しています。制作会社には、どのような対策をしているかを、この資料も参考に聞いてみるとよいでしょう。社内全体の対策は情報セキュリティの基本の講座で扱っています。
リニューアルの公開前チェックで、検索に出なくなる事故を防ぐために特に確かめたいものはどれでしょう?
- トップページの写真の色合い
- 会社のロゴの大きさ
- テスト環境で入れた「noindex」の指定が本番に残っていないか
答えと解説
正解は3です。noindexが残ったまま公開すると、ページが検索結果から外れてしまいます。テスト環境の設定が本番に持ち込まれていないかを、公開前に必ず確かめましょう。
実務ではこう使う
公開前チェックは、表にして関係者で分担すると漏れが減ります。次のような形で、ページごと・観点ごとに担当と結果を記録しましょう。
| 観点 | 確かめること | 担当 | 結果 |
|---|---|---|---|
| 表示と内容 | 全ページの誤字、古い情報、リンク切れ | 発注側(各部署) | OK/要修正 |
| スマホ・ブラウザ | iPhone・Android・パソコンで主要ページを操作 | 発注側+制作会社 | 同上 |
| 表示速度 | 主要ページをPageSpeed Insightsで測定 | 制作会社 | 同上 |
| アクセシビリティ | alt、コントラスト、キーボード操作 | 制作会社 | 同上 |
| 検索・計測 | noindexの解除、リダイレクト、GA4・Search Console | 制作会社+発注側 | 同上 |
| セキュリティ・個人情報 | HTTPS、更新、管理画面、フォームの利用目的 | 制作会社+発注側 | 同上 |
公開日は、チェックと修正の時間を見込んで設定しましょう。公開日を先に決めて、チェックの時間を削るのは本末転倒です。また、公開した直後にもう一度、本番の環境で主要なページとフォームを確かめると安心です。
FOR BUSINESS
マーケティング・DXの発注先選びに迷ったら
ツギノテを運営する株式会社Abinは、BtoBマーケティングに特化したコンサルティング会社です。創業から30社以上のBtoBマーケティングを支援してきました。
相談無料ツギノテ編集部に相談する→この回のまとめ
- 公開前チェックは検収の中身。表示と内容、スマホ・ブラウザ、表示速度、アクセシビリティ、検索・計測、セキュリティ・個人情報の6つの観点で確かめる。
- Googleはモバイル版のページを基にインデックス登録とランキングを行うので、スマホでの表示と操作は最優先で確かめる。
- Core Web Vitalsの良好の目安は、LCP 2.5秒以内、INP 200ミリ秒以内、CLS 0.1以下。速さは読者のための条件として改善する。
- 公開前に、noindexが外れているか、旧URLから301などで転送されるか、計測が動くかを必ず確かめる。
- HTTPS、CMSの更新、管理画面、フォームの利用目的の明示、バックアップを確認する。
確認テスト
Core Web VitalsのLCPの「良好」の目安として、web.devで示されているものはどれでしょう?
- 2.5秒以内
- 10秒以内
- 0.1秒以内
答えと解説
正解は1です。LCPは、ページの中でいちばん大きな要素が表示されるまでの時間で、2.5秒以内が良好の目安です。INPは200ミリ秒以内、CLSは0.1以下が目安です。
リニューアルでURLが変わるときにGoogleが勧めていることとして、最も適切なものはどれでしょう?
- 旧URLのページはすぐに削除し、転送は設定しない
- 新URLだけをSearch Consoleに登録すれば十分
- 旧URLと新URLの対応表を作り、サーバー側の永続的なリダイレクトをできるだけ長く残す
答えと解説
正解は3です。Googleは、旧URLと新URLの対応表を作り、技術的に可能ならサーバー側の永続的なリダイレクト(301など)を使い、一般に1年以上残すことを勧めています。
Webのフォームで、本人から直接個人情報を取得するときの扱いとして、個人情報保護委員会のガイドラインに沿った考え方はどれでしょう?
- 取得した後で、気が向いたときに利用目的を知らせればよい
- あらかじめ本人に利用目的を明示する
- 利用目的は社内で決めておけば、外に示す必要はない
答えと解説
正解は2です。ガイドライン(通則編)では、ユーザーの入力画面などで本人から直接個人情報を取得する場合、あらかじめ利用目的を明示することが求められています。
JIS X 8341-3について、国土交通省の資料で説明されている内容として最も適切なものはどれでしょう?
- 国際規格ISO/IEC 40500:2012と内容が一致し、WCAG 2.1以降で追加された内容は含まれていない
- WCAG 2.2の内容をすべて含んでいる
- 日本の行政機関だけが使う規格で、民間のサイトとは関係がない
答えと解説
正解は1です。国土交通省の資料では、JIS X 8341-3はISO/IEC 40500:2012と一致し、WCAG 2.0の解説書が参考になる一方、2.1以降の追加内容は含まれていないと説明されています。
次回予告
第6回は「公開後の運用と改善」です。公開後に見る数字、更新が止まらない体制、保守、そして部分改善とリニューアルのどちらが必要かの判断を学び、全6回を振り返ります。
参考資料
- web.dev「Web Vitals」 https://web.dev/articles/vitals (確認日:2026年11月13日)
- Google 検索セントラル「モバイルサイトとモバイルファースト インデックスに関するおすすめの方法」 https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing?hl=ja (確認日:2026年11月13日)
- Google 検索セントラル「Google 検索結果におけるページ エクスペリエンスについて」 https://developers.google.com/search/docs/appearance/page-experience?hl=ja (確認日:2026年11月13日)
- Google 検索セントラル「検索エンジン最適化(SEO)スターター ガイド」 https://developers.google.com/search/docs/fundamentals/seo-starter-guide?hl=ja (確認日:2026年11月13日)
- Google 検索セントラル「noindex を使用して検索インデックス登録をブロックする」 https://developers.google.com/search/docs/crawling-indexing/block-indexing?hl=ja (確認日:2026年11月13日)
- Google 検索セントラル「URL の変更を伴うサイト移転」 https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=ja (確認日:2026年11月13日)
- 国土交通省「JIS X 8341-3とWCAGの関係について」(資料) https://www.mlit.go.jp/sogoseisaku/barrierfree/content/001734098.pdf (確認日:2026年11月13日)
- デジタル庁「ウェブアクセシビリティ方針」 https://www.digital.go.jp/accessibility-statement (確認日:2026年11月13日)
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」 https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/ (確認日:2026年11月13日)
- 情報処理推進機構(IPA)「安全なウェブサイトの作り方」 https://www.ipa.go.jp/security/vuln/websecurity/about.html (確認日:2026年11月13日)
- WordPress.org 日本語「WordPress の安全性を高める」 https://ja.wordpress.org/support/article/hardening-wordpress/ (確認日:2026年11月13日)
この記事は役に立ちましたか?
NEXTあわせて読みたい
-
BPOサービス(業務アウトソーシング)おすすめ7選|コンタクトセンター・バックオフィスの外注先を規模・料金・事例で比較
-
Shopify制作会社おすすめ7選|Shopify Plus・越境EC・運用まで、認定・実績・事例で比較
-
マーケティング研修おすすめ7選|法人向けの基礎・実践・BtoB研修を料金・形式・実績で比較
-
ECコンサル会社おすすめ5選|楽天・Amazon・自社ECの売上を伸ばす支援会社を範囲・料金・事例で比較
-
広報・PR代行(PR会社)おすすめ7選|ベクトル・プラップジャパン・共同ピーアールなどを支援範囲・料金・事例で比較
-
企業データベースおすすめ6選|Speeda・帝国データバンク・東京商工リサーチ・ユーソナーなどを料金・収録数で比較
