納品前のSEO検証とは、実装したSEO設定（メタタグ・OGP・見出し構造・構造化データ・canonical）が公開前に正しく機能しているかを、実際のページ出力を確認して検証する工程のことです。「設定した」と「正しく効いている」は別物で、テーマやプラグインの挙動、出力タイミングのズレで、書いたはずの設定がページに反映されていないことは珍しくありません。
「このサイト、SEO大丈夫ですか？」——納品後にクライアントからこう聞かれて、慌ててソースを確認した経験はないでしょうか。設定ファイルに書いた内容を信じて納品したものの、実際の出力を一度も自分の目で確かめていない、というのはフリーランスや小規模制作の現場でよく起きるパターンです。
この記事では、Web制作の納品前に最低限おさえたいSEO5項目について、「どう確認するか（手順）」「どこまでできていれば合格か（合否ライン）」「現場でつまずきやすい検証ミス」の3点セットで解説します。実装方法そのものではなく、実装が正しく効いているかを自分の手で検証することにフォーカスした内容です。最後に、検証が終わったあとの「次の一手」まで案内します。
納品前のSEO検証とは何か（「設定した」と「効いている」は違う）
SEO設定は「コードに書いた」時点では完了していません。完了とは、実際に配信されるHTMLに、意図したタグが意図した値で出力されていることを指します。CMSのテーマ、SEOプラグイン、キャッシュ、リバースプロキシなど、コードと配信HTMLの間には複数の層があり、そのどこかで上書き・欠落・重複が起きます。
だからこそ、納品前の検証は「設定画面のスクリーンショット」ではなく「公開される実物のHTML」を見るのが原則です。下の表のように、作業のゴールを“設定済み”から“検証済み”へ引き上げることが、納品後のトラブルを防ぐ最短ルートになります。
| 状態 | 確認しているもの | 納品可否 |
|---|---|---|
| 設定済み | 管理画面・コードに値を入力した | 不十分 |
| 検証済み | 配信HTML・専用ツールで出力を確認した | OK |
検証を省いて納品すると、数週間後に「SNSでシェアしたらサムネイルが出ない」「検索しても下層ページが出てこない」とクライアント側が気づいて連絡が来る、という展開になりがちです。原因の多くは初期設定の出力ミスで、納品前に検証していれば数分で防げたものばかり。しかも公開後に直すとなると、原因調査・修正・再確認・場合によっては再クロール待ちと、納品前の何倍もの時間がかかります。検証は「最後のひと手間」ではなく「最も費用対効果の高い保険」だと考えてください。
検証に使う3つの基本ツール
特別な有料ツールは不要です。次の3つで5項目の大半は検証できます。まずはこの3つを手に馴染ませておくと、どの案件でも同じ手順で確認できるようになります。
- ソース表示（View Source）：ブラウザで
Ctrl/⌘ + U。配信されている生のHTMLを見る。タグの有無・重複の確認に最適。 - デベロッパーツール（DevTools）：
F12→ Elements / Network。JavaScriptで後から書き換わるタグや、レンダリング後の状態を確認できる。 - Googleの公式検証ツール：リッチリザルトテスト、スキーママークアップバリデーターなど。Googleが実際にどう解釈するかを確認できる。
ポイントは、「ソース表示」と「DevTools」を使い分けることです。JavaScriptでメタ情報を後から注入するサイトでは、ソース表示には出ずDevToolsのElementsにだけ出ることがあります。逆に、サーバー出力の重複はソース表示の方が見つけやすい。両方見るのが安全です。コマンドで素早く確認したい場合は、次のように生HTMLを取得してタグを抜き出すこともできます。
# 配信HTMLからtitle・meta・canonical・OGPをまとめて確認
curl -sL "https://example.com/" | grep -iE "<title>|<meta|<link rel=.canonical"検証の順序にもコツがあります。まずソース表示でタグの「有無と重複」をざっと確認し、次にDevToolsで「JavaScriptによる書き換えがないか」を見て、最後に公式ツールで「Googleがどう解釈するか」を確かめる——この順で進めると、原因の切り分けがスムーズです。いきなり公式ツールから入ると、問題が「実装の出力ミス」なのか「Googleの解釈の問題」なのか判断しづらくなります。
【ポイント1】メタタグ（title / description）
最初に確認するのはtitleとmeta descriptionです。検索結果に直接出る要素であり、ここが空・重複・全ページ同一だと、SEOの土台が崩れます。
確認方法：ソース表示で <title> と <meta name="description"> を検索し、トップ・下層・記事の最低3ページで「ページごとに中身が違うか」を見ます。同じtitleが複数ページで出ていないかが最重要チェックです。
| 項目 | 合格ライン |
|---|---|
| title | 全ページで1つだけ出力／ページごとに固有／重複なし |
| description | 各ページに存在／ページ内容と一致／全ページ同一文でない |
| 長さの目安 | titleは表示が途切れにくい範囲、descriptionは内容を要約できていればOK |
よくある検証ミス：テーマ標準のtitleとSEOプラグインのtitleが二重に出力されているケース。設定画面だけ見ると正しく見えるのに、ソースには <title> が2つ並んでいる。これは管理画面では絶対に気づけず、必ずソース表示で確認しないと見落とします。トップページだけ確認して下層を見ず、下層が全部同じtitleだった、というのも定番の取りこぼしです。
【ポイント2】OGP（SNSシェア時の表示）
OGP（Open Graph Protocol）は、SNSでシェアされたときのタイトル・説明・サムネイル画像を制御するタグです。検索順位に直接は効きませんが、クライアントが真っ先に「見た目」で気づく部分なので、納品前検証では外せません。
確認方法：ソースで og:title og:description og:image og:url の4つがあるかを見て、実際のシェア表示は OGPプレビューツール でプレビューします。画像が表示されるか、URLが本番ドメインになっているかまで目視します。
| 項目 | 合格ライン |
|---|---|
| og:image | 本番URLの絶対パス／実際に画像が表示される／推奨は横長（1200×630目安） |
| og:url | 本番ドメイン／開発・ステージング用URLが残っていない |
| og:title / description | ページごとに適切／文字化けしていない |
よくある検証ミス：og:image を相対パスや開発環境のドメインのままにしてしまうケース。ローカルでは画像が見えるのに、本番でシェアするとサムネイルが出ない。さらに、SNS側は一度取得したOGPをキャッシュするため、修正後に再取得（キャッシュクリア）しないと古い表示のまま、という二段構えの落とし穴があります。納品直前に必ずプレビューで実物を見ることが防御策です。X（旧Twitter）向けの twitter:card 系タグの確認漏れも多く、OGPだけ入れて満足してしまうと、X上での見え方が意図と変わることがあります。主要SNSでの表示を一通り確認しておくと安心です。
【ポイント3】見出し構造（h1〜h3）
見出しタグは、検索エンジンとユーザーの双方にページ構造を伝える骨格です。デザイン優先で組むと、見た目は整っていても構造が壊れていることがよくあります。
確認方法：DevToolsのElementsで h1 を検索し、1ページに1つだけかを確認します。次に h1 → h2 → h3 の順序が飛んでいないか（h2を飛ばしていきなりh3になっていないか）を見ます。ブラウザ拡張の見出しアウトライン表示を使うと一覧で把握できます。
| 項目 | 合格ライン |
|---|---|
| h1 | 1ページに1つ／ページの主題を表している |
| 階層 | h1→h2→h3の順で、レベルを飛ばしていない |
| 用途 | 装飾目的でh1〜h6を使っていない（強調はCSSで） |
よくある検証ミス：ロゴ画像とページタイトルの両方をh1にしてしまい、1ページにh1が2つあるケース。あるいは、サイドバーのウィジェット見出しがh3で、本文の見出しがh2より先に来てしまい階層が逆転しているケース。これらは見た目では全く分からず、Elementsで構造を追わないと検出できません。ページビルダーで作ったサイトも要注意で、見出し風に大きく表示しているだけのdivやspanが実はh2扱いになっていなかった、という逆パターンもあります。「大きい文字＝見出しタグ」とは限らないので、必ずタグ自体を確認してください。
【ポイント4】構造化データ（JSON-LD）
構造化データは、ページの内容を検索エンジンが理解しやすい形で伝えるマークアップです。実装そのものはテーマやプラグインに任せることが多いため、納品前は「正しく出力され、エラーがないか」の検証に集中します。
確認方法：GoogleのリッチリザルトテストにページURLを入れて、検出されたタイプとエラー・警告を確認します。より細かく見たい場合はスキーママークアップバリデーターを併用します。エラー（赤）はゼロ、警告（黄）は内容を確認のうえ許容するか判断します。
| 状態 | 判断 |
|---|---|
| エラー（赤） | 必ず修正。リッチリザルトの対象外になる原因 |
| 警告（黄） | 推奨項目の欠落。内容を見て対応要否を判断 |
| 検出なし | そもそも出力されていない可能性。実装側を確認 |
よくある検証ミス：プラグインを複数入れた結果、同じタイプの構造化データが重複して出力されているケース。リッチリザルトテストでは通っても、重複は意図しない解釈を招きます。また、テスト環境では正しくても、本番のキャッシュ層が古いHTMLを返していて反映されていない、という検証漏れも起きます。必ず本番URLでテストするのが鉄則です。構造化データの実装・修正まで踏み込みたい場合は、SEO診断ツールの改善提案を活用すると効率的です。
【ポイント5】canonical URL
canonical（正規URL）は、内容が同じ・似ているページが複数ある場合に「これが正規版」と検索エンジンに伝えるタグです。設定ミスがあると、評価が分散したり、意図しないページがインデックスされたりします。
確認方法：ソースで <link rel="canonical"> を検索し、各ページのcanonicalが「そのページ自身の本番URL」を指しているかを確認します。トップ・下層・記事ページで、全ページが同じURLを指していないか（多くはトップに固定されるミス）を重点的に見ます。
| 項目 | 合格ライン |
|---|---|
| 指す先 | 原則そのページ自身の本番URL（自己参照） |
| ドメイン | 本番ドメイン／http・wwwの有無が実URLと一致 |
| 個数 | 1ページに1つだけ（重複なし） |
よくある検証ミス：移行・複製時に全ページのcanonicalがトップページURLに固定されてしまうケース。これをやると下層ページがインデックスから外れる重大な事故につながります。さらに、httpsへ統一したのにcanonicalだけhttpのまま、wwwあり・なしが実URLと食い違っている、といった細部のズレも頻出します。あわせて確認したいのが noindex との併発です。canonicalで正規版を示しているページに noindex が同時に付いていると、シグナルが矛盾し、意図せずインデックスから外れることがあります。canonicalを見るついでに、納品対象ページに不要な noindex が残っていないかも確認しておきましょう。Googleはcanonicalを「強い推奨」として扱う（最終判断はGoogle側）ため、矛盾のないシグナルを出すことが重要です。
5項目を一括で検証する（手作業の限界とツール活用）
ここまでの5項目は手作業でも検証できますが、ページ数が多い案件や、複数サイトを並行して納品する場合、1ページずつソースを追うのは現実的ではありません。抜け漏れのリスクも上がります。そこで、5項目をまとめて自動診断できるツールを“一次チェック”に使い、引っかかった箇所だけ手作業で深掘りする流れが効率的です。
CodeQuest.work SEOは、URLを入力するだけでメタタグ・構造化データ・見出し構造などをまとめて診断し、改善ポイントを一覧化します。納品前の“一次チェック”として使い、スコアが低い項目を本記事の手順で個別検証する、という二段構えが最も漏れにくい方法です。どのツールを組み合わせるか迷う場合はSEOチェックツールの比較も参考にしてください。
検証が終わったら：公開後のGSC URL検査へ
5項目の検証が終わり、サイトを公開したら、検証はそこで終わりではありません。次の一手は、Google Search Console（GSC）のURL検査で「Googleが実際にどう見ているか」を確認することです。自分のブラウザでの見え方と、Googleがクロール・レンダリングした結果は必ずしも一致しないためです。
URL検査では、インデックス登録の可否、検出されたcanonical、構造化データの認識状況などを、Google視点で確認できます。納品前の手作業検証で「自分の目」を通し、公開後にURL検査で「Googleの目」を通す——この2段階で、SEOの初期設定はほぼ取りこぼしなく担保できます。GSCの初期設定や使い方は別記事で詳しく扱うため、ここでは「公開したらまずURL検査をかける」という流れだけ押さえておいてください。
検証を毎回の納品フローに組み込む
検証を「気づいたときにやる作業」にしておくと、忙しい納品直前ほど抜けます。一度きりで終わらせず、毎回の納品で同じ手順を回せる仕組みにしておくと、品質が安定し、確認漏れが構造的に減ります。おすすめは次の流れをプロジェクトの標準手順に組み込むことです。
- ステージング環境の段階で一度、5項目を一括診断にかける（本番反映前に問題を発見できる）
- このチェックリストをプロジェクトのタスク・Issueテンプレに入れ、納品チェック項目として固定する
- 検証結果のスクリーンショットを残し、納品物に「SEO初期設定 確認済み」の根拠として添える
- 公開直後にGSCのURL検査をかけ、結果を記録しておく
特に効くのが3番目です。冒頭の「SEO大丈夫ですか？」という不安に対して、聞かれる前に「確認済みです」と根拠を提示できる状態を作っておく。これは小さな手間ですが、制作者としての信頼を積み上げる一次的な材料になります。検証を“納品の一部”として標準化しておくことが、属人化を防ぎ、チームでも品質を揃える近道です。
納品前SEO検証チェックリスト（保存版）
毎回の納品前に、このリストを上から確認すれば5項目を取りこぼしません。ブラウザにブックマークしておき、案件のたびに開く使い方を想定しています。
- title：全ページで1つだけ／ページごとに固有／重複なし
- description：各ページに存在／内容と一致／全ページ同一文でない
- OGP：og:image が本番絶対URLで表示される／og:url が本番ドメイン
- 見出し：h1は1ページ1つ／h1→h2→h3の階層が飛んでいない
- 構造化データ：本番URLでリッチリザルトテストがエラー0／重複なし
- canonical：各ページが自身の本番URLを指す／全ページトップ固定でない
- 公開後：GSCのURL検査でGoogle視点を確認
よくある質問
Q. 納品前のSEOチェックはどこまでやれば十分ですか？
本記事の5項目（メタタグ・OGP・見出し・構造化データ・canonical）が、最低限のラインです。これらは検索結果やインデックスに直結し、設定ミスの影響が大きいためです。コンテンツSEOや被リンクは納品後の運用フェーズの話で、納品前検証では「技術的な初期設定が正しく出力されているか」に集中すれば十分です。
Q. 検証はツールに任せれば手作業は不要ですか？
一括診断ツールは“一次チェック”として非常に有効ですが、手作業の確認を完全に置き換えるものではありません。たとえばtitleの二重出力や、ページごとの内容の妥当性は、最終的に人の目で確認するのが確実です。ツールで全体をスクリーニングし、引っかかった箇所と重要ページだけ手作業で深掘りする、という役割分担が効率的です。
Q. WordPressサイトでも同じ手順で検証できますか？
はい、検証手順は同じです。WordPressの場合、テーマとSEOプラグインの両方がメタタグを出力しようとして二重出力が起きやすいため、ソース表示でのtitle・canonical重複チェックが特に重要になります。プラグイン設定画面ではなく、必ず配信HTMLを確認してください。
Q. 構造化データのエラーと警告、どちらも直すべきですか？
エラー（赤）は必ず修正してください。リッチリザルトの対象から外れる直接的な原因になります。警告（黄）は推奨項目の欠落を示すもので、内容を確認したうえで対応要否を判断します。納品前は「エラー0」を必須ライン、「警告は内容を把握して説明できる状態」を目標にすると現実的です。
Q. 公開後にも検証は必要ですか？
必要です。納品前検証は「自分のブラウザでの見え方」の確認で、公開後はGSCのURL検査で「Googleから見た状態」を確認します。キャッシュやレンダリングの差で、公開後に初めて分かる問題もあります。公開直後にURL検査をかけ、インデックス可否とcanonicalの認識を確認するところまでをワンセットにするのがおすすめです。
まとめ
納品前のSEO検証で大切なのは、「設定した」で止めず「配信されている実物が正しく効いているか」を自分の手で確認することです。メタタグ・OGP・見出し・構造化データ・canonicalの5項目を、確認方法と合否ラインに沿ってチェックし、最後にGSCのURL検査で公開後の状態まで見届ける。この流れを納品フローに組み込めば、「SEO大丈夫ですか？」に自信を持って答えられます。
まずは手元の案件URLで一括診断をかけ、引っかかった項目を本記事の手順で個別検証してみてください。検証だけでなく、SEOを含めたサイトの実装・改善まで依頼したい場合は、Web制作を手がけるRINIAにご相談ください。
