SEO修正を公開した後、ブラウザで見た画面が正しければ、これで完了と考えたくなります。しかし、HTMLに古い設定が残っていたり、JavaScriptの実行後にcanonicalやrobotsが変わったりしていると、検索エンジンには意図と異なる情報が伝わることがあります。「公開できた」は完了のしるしではなく、確認を始める合図です。
この記事の答えは、検索順位が上がったかを見るのではなく、実装した仕様が本番の検索エンジン向け出力まで正しく反映されたかを合否判定する、ということです。確認では、対象URL、HTTPレスポンス、ソースHTML、レンダリング後のHTML、canonical、robots・noindex、構造化データ、計測タグを順番に見ていきます。
以降では、確認する6つの層、対象URLと期待値の固定、STEP1〜6の手順、不具合を差し戻す基準、成果指標と分けて判定するタイミング、最後に使えるチェックリストを順に示します。
公開後のSEO確認は、本番の出力で合否を判定する
SEO修正の公開後チェックでは、管理画面の設定値や開発担当者からの完了報告だけで判断しません。どちらも実装の意図や結果の報告であって、検索エンジンが実際に受け取る内容そのものではないためです。実際に公開されているURLへアクセスし、検索エンジンが取得できる状態まで確認します。
判断の前提として、Googleの処理の流れを押さえておきます。Googleは、Webページをクロール（巡回して内容を取得）した後、必要に応じてJavaScriptを実行してページを組み立て（レンダリング）、その結果をインデックス（検索エンジンへの登録）の処理に利用します。初期HTMLに問題がなくても、レンダリング後に内容が変わる場合があるため、両方を見る必要があります。（出典：Google Search Central）
確認の対象は、次の6層に分けると漏れを減らせます。下の図と表は、層ごとに何を見て、何をもって合格とするかを整理したものです。
SEO修正は画面表示だけでなく、URLから計測まで複数の層を分けて確認します。
| 確認する層 | 主な確認項目 | 合格の考え方 |
|---|---|---|
| URL・HTTP | 対象URL、ステータス、リダイレクト | 仕様で定めたURLと応答になっている |
| ソースHTML | title、description、canonical、robots | 本番HTMLに期待した値が出力されている |
| レンダリング後 | 本文、見出し、リンク、canonical、robots | JavaScript実行後も仕様が崩れていない |
| クロール・インデックス制御 | robots.txt、noindex | 公開方針と矛盾していない |
| 構造化データ | JSON-LD、必須プロパティ | 本文と一致し、重大なエラーがない |
| 計測 | Googleタグ、GA4・GTM等 | 必要なタグが発火し、重複していない |
この6層は、STEP1〜6の順番とほぼ対応します。ただし、クロール・インデックス制御（robots.txt・noindex）はSTEP2の中で確認し、STEP4のSearch Consoleの公開URLテストは、Google側から見た現在の状態を確認する手順です。計測のSTEP6では、必要なタグが動作してデータが送られること（発火）まで確認します。
この確認では、順位、クリック率（CTR）、問い合わせ数までは評価しません。これらは実装の品質ではなく、公開後に一定期間を置いて観測する成果指標だからです。
公開前の段階で、noindex・canonical・robots・リダイレクトの事故を防ぎたい場合は、SEOリリース前チェックも参考にしてください。
最初に対象URLと「正しい状態」を固定する
本番確認を始める前に、何を確認すれば合格なのかを文章にしておきます。「SEO修正を確認する」とだけ決めると、担当者ごとに見る場所が変わってしまうためです。対象URLと期待値を1行ずつ記録しておくと、開発側への差し戻しも具体的になります。
先に「何なら合格か」を決めてから本番出力と比較すると、差し戻し条件が明確になります。
次の表は、記録の例です。「実際の結果」と「判定」は、確認後に埋めます。
| 対象URL | 変更内容 | 期待する状態 | 実際の結果 | 判定 |
|---|---|---|---|---|
| サービス詳細 | canonical修正 | 自己URLを指定 | 確認結果を記録 | OK / NG |
| 記事ページ | noindex解除 | noindexなし | 確認結果を記録 | OK / NG |
| カテゴリ | title修正 | 指定タイトル | 確認結果を記録 | OK / NG |
| 記事ページ | 構造化データ追加 | 指定JSON-LDを出力 | 確認結果を記録 | OK / NG |
対象URLが多い場合は、少なくともトップページ、記事、カテゴリ、サービス、問い合わせなど、テンプレートが異なる代表URLを分けて選びます。
共通テンプレートを1ページ確認しただけで全ページを合格にすると、特定のテンプレートだけ値が渡っていない実装漏れを見逃す可能性があります。
確認の担当だけでなく、SEOを内製・外注・ハイブリッドのどの体制で進めるかまで整理したい場合は、SEO導入の体制構築の全体地図も参照してください。
STEP1｜HTTPステータスと最終URLを確認する
最初に確認するのは、修正したURLへ正常にアクセスでき、意図したURLにたどり着くかどうかです。URLが違えば、その後のcanonicalや構造化データが正しくても受け入れ判定はできないため、まずURLとレスポンスを確定させます。
検索結果へ掲載したい通常ページでは、Googleの技術要件上、HTTP 200の正常応答が基本です。Googleは、正常に動作するページについて、200のHTTPステータスをインデックス対象の要件として説明しています。（出典：Google Search Central）
確認する項目は次のとおりです。
- 入力したURLが意図したURLへ到達するか
- 通常ページが200を返しているか
- リダイレクト対象は予定したURLへ移動するか
- 意図しないリダイレクトが増えていないか
- 404にすべきURLが200になっていないか
- http / https、www有無、末尾スラッシュ等の扱いが仕様と一致するか
STEP2｜ソースHTMLでcanonical・robots・SEOタグを確認する
次に、サーバーから返された元のHTML（ソースHTML）を確認します。ブラウザの「ページのソースを表示」で見えるHTMLは、JavaScriptが実行される前の情報です。Googleも、元のソースとレンダリング後のHTMLを区別して確認する方法を案内しています。（出典：Google Search Console ヘルプ）
確認対象は、今回変更した項目に絞ります。
- title
- meta description
- canonical
- meta robots
- hreflang
- 構造化データ
- SEO上重要な本文やリンク
canonicalは「存在するか」ではなく「どこを指しているか」を見る
canonicalは、タグが付いているだけでは合格ではありません。指している先が正しいかどうかで判定します。
Googleはrel=”canonical”を正規URLを示す強いシグナルとして扱い、同じページに矛盾したcanonical指定を行わないことや、正規ページ自身にも自己参照canonicalを設定できることを案内しています。（出典：Google Search Central）
公開後は次を確認します。
- canonicalが1つに整理されているか
- hrefが期待した正規URLか
- 本番URLではなくステージングURLを指していないか
- http / httpsが正しいか
- パラメータ付きURLを誤って正規化していないか
- sitemapや内部リンクのURL方針と矛盾していないか
特に、canonicalが別ページを指している場合は、後述の「即差し戻し」に当たる優先度の高い不具合です。
robotsとnoindexは別々に確認する
robots.txtとnoindexは役割が異なります。robots.txtは主にクロールを制御します。一方、noindexは検索結果へのインデックス登録を防ぐための指定です。
robots.txt、noindex、canonicalは制御する対象が異なるため、本番確認でも別々に見ます。
robots.txtとnoindexは、組み合わせ方にも注意が必要です。Googleは、noindexを認識させるにはGooglebotがページをクロールできる必要があり、robots.txtでブロックするとページ内のnoindexを確認できない場合があると説明しています。（出典：Google Search Central）
本番確認では、次の3点を分けて確認します。見る場所が違うため、1つが問題なくても、ほかも問題ないとは言えません。
- robots.txtで対象URLを意図せずブロックしていないか
- meta robotsにnoindexが残っていないか
- X-Robots-Tag（HTTPヘッダーで返すrobotsの指定）でnoindexが返っていないか
STEP3｜レンダリング後のDOMでJavaScript実行後を確認する
JavaScriptを使用するサイトでは、ソースHTMLだけで合否を決めないことが重要です。ブラウザで見える最終的な状態は、JavaScriptの実行後に変わっている可能性があるためです。
ソースHTMLとJavaScript実行後の状態は別々に確認し、必要に応じてGoogle側から見た現在の公開状態まで検証します。
Chromeの開発者ツールで確認できるDOM（ブラウザが組み立てたページの構造）は、JavaScript実行後の状態です。Googleの案内でも、ブラウザの「検証」やSearch Consoleの公開URLテストからレンダリング済みHTMLを確認できます。
特に確認したいのは次の項目です。
- SEO上重要な本文がDOM上に存在するか
- H1・H2などの見出しが正しく出ているか
- 内部リンクが実際のリンクとして存在するか
- canonicalがJavaScriptによって別URLに変更されていないか
- robotsが実行後に意図しない値へ変わっていないか
- JSON-LDがレンダリング後も存在するか
canonicalについては、Googleの説明も確認しておきます。GoogleはJavaScriptでcanonicalを生成すること自体には対応していますが、元のHTMLと異なるcanonicalへ変更しないことを推奨しています。複数のcanonicalが生成される実装にも注意が必要です。（出典：Google Search Central）
「画面には表示されている」ではなく、「検索エンジンが処理するHTMLに必要な情報が存在するか」で判定します。
STEP4｜Search Consoleの公開URLテストでGoogle側の取得結果を確認する
自社サイトでSearch Consoleを利用できる場合は、URL検査の「公開URLをテスト」まで確認します。ここまで確認すると、自分の環境で見た結果だけでなく、Google側から見た現在の状態まで確かめられます。
公開URLテストでは、現在公開されているページをGoogleの検査ツールが取得し、クロール可能性やインデックス登録上の問題を確認できます。さらに「テスト済みのページを表示」から、次の情報などを確認できます。（出典：Google Search Console ヘルプ）
- 返されたHTML
- レンダリング後のスクリーンショット
- HTTPヘッダー
- JavaScriptコンソール
- 読み込まれたリソース
読み取るときは、「Googleインデックス上の情報」と「現在の公開URLテスト」を混同しないことが大切です。修正直後は、Googleが以前取得したインデックス情報に古い状態が残っている場合があります。そのため、実装反映の受け入れ確認では、まず公開URLテストで現在の本番状態を確認します。
STEP5｜構造化データは本番URLで検証する
構造化データを修正した場合は、HTMLにJSON-LD（構造化データの記述形式）が存在するだけでなく、Googleが処理できる状態かまで確認します。
Googleは構造化データの検証にRich Results Testを案内しています。JavaScriptで生成した構造化データについても、URLを使ったテストが推奨されています。（出典：Google Search Central）
確認するポイントは、次の4点です。
- 想定した構造化データの種類が検出されるか
- 必須項目にエラーがないか
- URL、タイトル、日付、著者などが実際のページ内容と一致するか
- JavaScript生成の場合もレンダリング後に存在するか
構造化データのテストに合格したことは、検索結果でリッチリザルトが必ず表示されることを意味しません。（出典：Google Search Central）
そのため、ここでは「実装が仕様どおりで、Googleが処理可能な状態か」までを判定します。
STEP6｜計測タグは「コードの存在」と「実際の発火」を分けて確認する
Google AnalyticsやGoogle Tag Managerなどを変更した場合は、HTMLにタグの文字列があるだけでは確認不足です。コードが存在することと、実際に計測されることは別の問題だからです。
GoogleのTag Assistantは、タグの実装や発火状態を確認するためのツールです。Googleの説明では、ソースコード上の実装確認と、Google側へ実際にリクエストが送信されたかの確認は別のチェックとして扱われています。（出典：Google Tag Assistant ヘルプ）
そのため、計測タグは次の4点を確認します。
- 必要なコードが本番に存在する
- 想定した条件でタグが発火する
- 同じタグやイベントが重複していない
- 必要なID・イベント名になっている
SEO修正と同時に計測設定を変更した場合は、「SEO設定は合格だが計測はNG」のように判定を分けます。差し戻す範囲が明確になるためです。
差し戻す不具合と、公開を進めてよい状態を分ける
すべての不具合を同じ優先度で扱う必要はありません。検索エンジンがページを取得・理解できるかに直接関わる問題は、優先的に差し戻します。次の表は、判定ごとの代表例と対応をまとめたものです。
| 判定 | 代表例 | 対応 |
|---|---|---|
| 即差し戻し | 想定ページが404・500、誤canonical、意図しないnoindex、robots.txtによる重要URLのブロック | 修正後に再QA |
| 原則差し戻し | 主要本文がレンダリング後に存在しない、重要な内部リンクが生成されない、構造化データの重大エラー | 対象機能を修正 |
| 条件付き修正 | descriptionの軽微な差、構造化データの任意項目警告 | 仕様と影響を確認 |
| 合格 | 期待値と本番出力が一致 | QA記録を残して完了 |
差し戻すときは、単に「違っていた」と伝えるのではなく、次の5点をセットにします。
- 対象URL
- 期待値
- 実際の値
- 確認方法
- 合格条件
5点がそろっていれば、開発担当者が同じ手順で再現でき、修正後の再確認も同じ基準でできます。
公開直後の実装確認とSEO成果の評価は分ける
本番反映の確認が終わっても、その日の順位やCTRだけでSEO施策の成否を判断しないようにします。
GoogleのURL検査では、Googleがすでに保持しているインデックス情報と、現在の公開URLを確認するライブテストが分かれています。ページを更新しても、Google側の再クロール・再処理には時間差があります。（出典：Google Search Console ヘルプ）
公開直後に判定するのは、「実装が仕様どおり本番へ反映されたか」です。順位、表示回数、CTR、問い合わせ数などは、その後の観測工程で評価します。
この2つを分けると、「正しく実装できていない」のか、「正しく実装されたが成果がまだ出ていない」のかを見分けやすくなります。
SEO修正の本番反映チェックリスト
ここまでの確認を、公開後の代表URLごとに使えるチェックリストにまとめます。上から順に使ってください。
- 対象URLが正しい
- HTTPステータスが仕様どおり
- リダイレクト先が正しい
- title・descriptionが仕様どおり
- canonicalが正しいURLを指している
- 意図しないnoindexがない
- robots.txtで必要なURLやリソースをブロックしていない
- レンダリング後も主要本文・見出し・内部リンクが存在する
- レンダリング後にcanonicalやrobotsが変わっていない
- 構造化データが本文と一致する
- Rich Results Testで重大なエラーがない
- Search Consoleの公開URLテストで取得できる
- 必要な計測タグが発火する
- タグやイベントが重複していない
- NG項目には対象URL・期待値・実際の値・確認方法・合格条件を残した
確認項目を毎回ゼロから作ると、担当者によって品質が変わります。同じチェックリストを使えば、担当者が変わっても確認の品質をそろえやすくなります。
まとめ
SEO修正の本番反映確認では、ブラウザで見える画面だけで合否を決めません。検索エンジンへ渡る本番の出力が、実装した仕様どおりかどうかを判定します。
対象URLと期待値を固定したうえで、HTTPレスポンス、ソースHTML、レンダリング後のHTML、canonical、robots・noindex、構造化データ、計測タグを順番に確認します。特にJavaScriptを利用するサイトでは、元のHTMLとレンダリング後の状態を分けて確認することが重要です。
公開直後は「検索順位が上がったか」ではなく、「検索エンジンへ渡る本番出力が仕様どおりか」を判定します。問題があれば、対象URL・期待値・実際の値・確認方法・合格条件を残して差し戻し、修正後に同じ手順で再確認しましょう。最初の一歩としては、直近のSEO修正1件について、対象URLと期待値を1行で書き出し、チェックリストに沿って確認しましょう。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Central「Understand JavaScript SEO Basics」：JavaScriptのクロール、レンダリング、canonical・robotsの扱いを確認。 Google Search Central
- Google Search Central「How to specify a canonical URL」：canonicalの実装方針と注意点を確認。 canonical公式ドキュメント
- Google Search Central「Block Search Indexing with noindex」：noindexとrobots.txtの関係を確認。 noindex公式ドキュメント
- Google Search Console Help「View the rendered source for a page」：元のHTMLとレンダリング後HTMLの確認方法を参照。 レンダリング済みHTMLの確認方法
- Google Search Console Help「URL 検査ツール」：公開URLテストとレスポンスデータの確認方法を参照。 URL検査ツール
- Google Search Central「Structured Data」：構造化データの検証方法を参照。 構造化データ公式ドキュメント
- Google Tag Assistant Help：Googleタグの実装・発火確認方法を参照。 Tag Assistant Help
‹ 親記事: SEO導入の体制構築とは？内製・外注・ハイブリッドの判断基準と進め方の全体地図
関連記事
- › SEO内製化後の運用設計｜RACI・会議体・判断記録で属人化を防ぐ
- › SEOで何を変更したか管理する方法｜設定変更・影響・復旧を記録
- › 【2026年版】SEOツールおすすめ10選｜無料・有料の機能・料金・用途を比較
- › 【2026年版】SEO対策会社10選｜費用・対応範囲・実績を比較
- › SEO対策会社へ依頼する前に決めること｜範囲・KPI・権限・成果物
- › SEO対策会社の提案はどこを比較？範囲・工数・KPI・見積もり
- › SEO対策会社の契約更新判断｜成果・実装量・残る課題・次の施策
- › SEO対策会社を乗り換えるときにやること｜Search Console・GA4・CMS・これまでの対応内容・権限を引き継ぐ
- › 社内SEO担当者の引き継ぎ｜GA4・対応履歴・権限を整理
- › SEO対策会社の月次レポートの見方｜順位・流入・CV・実施内容・次月計画を評価する方法
- › SEO対策会社へ相談する前に準備する7項目｜目標・対象ページ・Search Console・実装体制を整理
- › SEO改善が止まる原因は？課題特定・実装・検証・優先順位・専門性の5工程で診断
- › SEO対策会社と契約する前に確認すること｜実装範囲・権限・成果定義・引き継ぎ
- › SEO施策の実装が開発待ちで止まるときの進め方｜仕様・チケット・担当・検証を整える
- › SEO実装はどこまで外注する？仕様・開発・QA・公開後検証
- › SEO対策の費用相場｜施策別料金・契約形態・費用対効果を整理
