SEO修正が本番に反映されたか確認する方法｜HTML・レンダリング・canonical・計測タグを検証

監修: 菊地 将（リブランディング株式会社）

SEO修正は「公開できた」だけでは完了ではありません。ブラウザ上の見た目が正しくても、HTMLに古い設定が残っていたり、JavaScript実行後にcanonicalやrobotsが変わったりすると、検索エンジンには意図と異なる情報が伝わることがあります。

公開後は、対象URL、HTTPレスポンス、ソースHTML、レンダリング後のHTML、canonical、robots・noindex、構造化データ、計測タグを順番に確認します。

重要なのは、検索順位が上がったかを見ることではなく、「実装した仕様が本番の検索エンジン向け出力まで正しく反映されたか」を合否判定することです。

公開後のSEO確認は「本番出力」を合否判定する

SEO修正の公開後チェックでは、管理画面の設定値や開発担当者からの完了報告だけで判断しません。実際に公開されているURLへアクセスし、検索エンジンが取得できる状態まで確認します。

GoogleはWebページをクロールした後、必要に応じてJavaScriptを実行してページをレンダリングし、その結果をインデックス処理に利用します。初期HTMLに問題がなくても、レンダリング後に内容が変わる場合があるため、両方を見る必要があります。（出典：Google Search Central）

最低限、次の6層を分けて確認すると漏れを減らせます。

SEO修正は画面表示だけでなく、URLから計測まで複数の層を分けて確認します。

この時点では順位、CTR、問い合わせ数まで評価しません。それらは実装品質ではなく、公開後に一定期間を置いて観測する成果指標だからです。

公開後の受け入れ確認とあわせて、noindex・canonical・robots・リダイレクトの事故を公開前に防ぐ場合は、SEOリリース前チェックも確認してください。

最初に対象URLと「正しい状態」を固定する

本番確認を始める前に、何を確認すれば合格なのかを明文化します。

「SEO修正を確認する」だけでは、担当者ごとに見る場所が変わります。対象URLと期待値を1行ずつ記録すると、開発側への差し戻しも具体的になります。

先に「何なら合格か」を決めてから本番出力と比較すると、差し戻し条件が明確になります。

対象URLが多い場合は、少なくともトップページ、記事、カテゴリ、サービス、問い合わせなど、テンプレートが異なる代表URLを分けます。

共通テンプレートを1ページ確認しただけで全ページを合格にすると、特定テンプレートだけ値が渡っていない実装漏れを見逃す可能性があります。

本番確認の担当だけでなく、SEOを内製・外注・ハイブリッドのどの体制で進めるかまで整理する場合は、SEO導入の体制構築の全体地図も確認してください。

STEP1｜HTTPステータスと最終URLを確認する

最初に、修正したURLへ正常にアクセスできるかを確認します。

検索結果へ掲載したい通常ページでは、Googleの技術要件上、HTTP 200の正常応答が基本です。Googleは正常に動作するページについて、200のHTTPステータスをインデックス対象の要件として説明しています。（出典：Google Search Central）

確認する項目は次のとおりです。

• 入力したURLが意図したURLへ到達するか
• 通常ページが200を返しているか
• リダイレクト対象は予定したURLへ移動するか
• 意図しないリダイレクトが増えていないか
• 404にすべきURLが200になっていないか
• http / https、www有無、末尾スラッシュ等の扱いが仕様と一致するか

URLが違えば、その後のcanonicalや構造化データが正しくても受け入れ判定はできません。まずURLとレスポンスを確定させます。

STEP2｜ソースHTMLでcanonical・robots・SEOタグを確認する

次に、サーバーから返された元の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は制御する対象が異なるため、本番QAでも別々に確認します。

Googleは、noindexを認識させるにはGooglebotがページをクロールできる必要があり、robots.txtでブロックするとページ内のnoindexを確認できない場合があると説明しています。（出典：Google Search Central）

本番確認では、

• robots.txtで対象URLを意図せずブロックしていないか
• meta robotsにnoindexが残っていないか
• X-Robots-Tagでnoindexが返っていないか

を分けて確認します。

STEP3｜レンダリング後のDOMでJavaScript実行後を確認する

JavaScriptを使用するサイトでは、ソースHTMLだけで合否を決めないことが重要です。

ソースHTMLとJavaScript実行後の状態は別々に確認し、必要に応じてGoogle側から見た現在の公開状態まで検証します。

Chromeの開発者ツールで確認できるDOMは、JavaScript実行後の状態です。Googleの案内でも、ブラウザの「検証」やSearch Consoleの公開URLテストからレンダリング済みHTMLを確認できます。

特に確認したいのは次の項目です。

• SEO上重要な本文がDOM上に存在するか
• H1・H2などの見出しが正しく出ているか
• 内部リンクが実際のリンクとして存在するか
• canonicalがJavaScriptによって別URLに変更されていないか
• robotsが実行後に意図しない値へ変わっていないか
• JSON-LDがレンダリング後も存在するか

GoogleはJavaScriptでcanonicalを生成すること自体には対応していますが、元のHTMLと異なるcanonicalへ変更しないことを推奨しています。複数のcanonicalが生成される実装にも注意が必要です。（出典：Google Search Central）

「画面には表示されている」ではなく、「検索エンジンが処理するHTMLに必要な情報が存在するか」で判定します。

STEP4｜Search Consoleの公開URLテストでGoogle側の取得結果を確認する

自社サイトでSearch Consoleを利用できる場合は、URL検査の「公開URLをテスト」まで確認します。

公開URLテストでは、現在公開されているページをGoogleの検査ツールが取得し、クロール可能性やインデックス登録上の問題を確認できます。

さらに「テスト済みのページを表示」から、

• 返されたHTML
• レンダリング後のスクリーンショット
• HTTPヘッダー
• JavaScriptコンソール
• 読み込まれたリソース

などを確認できます。（出典：Google Search Console ヘルプ）

ここで重要なのは、「Googleインデックス上の情報」と「現在の公開URLテスト」を混同しないことです。

修正直後は、Googleが以前取得したインデックス情報には古い状態が残っている場合があります。実装反映の受け入れQAでは、まず公開URLテストで現在の本番状態を確認します。

STEP5｜構造化データは本番URLで検証する

構造化データを修正した場合は、HTMLにJSON-LDが存在するだけでなく、Googleが処理できる状態か確認します。

Googleは構造化データの検証にRich Results Testを案内しています。JavaScriptで生成した構造化データについても、URLを使ったテストが推奨されています。（出典：Google Search Central）

確認するポイントは、

• 想定した構造化データの種類が検出されるか
• 必須項目にエラーがないか
• URL、タイトル、日付、著者などが実際のページ内容と一致するか
• JavaScript生成の場合もレンダリング後に存在するか

です。

構造化データのテストに合格したことは、検索結果でリッチリザルトが必ず表示されることを意味しません。ここでは「実装が仕様どおりで、Googleが処理可能な状態か」までを判定します。（出典：Google Search Central）

STEP6｜計測タグは「コードの存在」と「実際の発火」を分けて確認する

Google AnalyticsやGoogle Tag Managerなどを変更した場合は、HTMLにタグ文字列があるだけでは確認不足です。

GoogleのTag Assistantは、タグの実装や発火状態を確認するためのツールです。Googleの説明では、ソースコード上の実装確認と、Google側へ実際にリクエストが送信されたかの確認は別のチェックとして扱われています。（出典：Google Tag Assistant ヘルプ）

そのため、計測タグは、

1. 必要なコードが本番に存在する
2. 想定した条件でタグが発火する
3. 同じタグやイベントが重複していない
4. 必要なID・イベント名になっている

まで確認します。

SEO修正と同時に計測設定を変更した場合は、「SEO設定は合格だが計測はNG」のように判定を分けると、差し戻し範囲が明確になります。

差し戻すべき不具合と公開可能な状態を分ける

すべての不具合を同じ優先度で扱う必要はありません。

検索エンジンがページを取得・理解できるかに直接関わる問題は、優先的に差し戻します。

ポイントは、単に「違っていた」と伝えるのではなく、

• 対象URL
• 期待値
• 実際の値
• 確認方法
• 合格条件

をセットにして差し戻すことです。

これだけで、開発担当者が再現しやすくなります。

公開直後の実装確認と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導入の体制構築とは？内製・外注・ハイブリッドの判断基準と進め方の全体地図