技術SEOの確認手順｜取得・登録・表示と実装の検収を分ける

技術SEOを点検するときは、まず「どの公開ページを、誰に、何のために見つけてもらいたいか」を決め、そのURLの取得、登録、検索結果での表示、読者の操作を分けて確認してください。タイトルの文字数や検査点数だけを揃えても、必要な情報が届くことを確かめたとはいえません。

この記事は、企業サイトの調査を依頼する担当者と、調査・修正・検収を行う制作会社向けです。現象と証拠から修正対象を選び、変更後に何を確認するかを整理します。検索順位、相談数、受注の保証を目的にしたチェック表ではありません。

1. 対象URLと困っている現象を記録する

検索で見つからない、古い説明が表示される、ページが開けない、スマートフォンで操作できないなど、現象ごとに確認先が違います。対象URL、重要な情報、公開・変更の時点、発見した画面と日時、利用端末を控えます。

対象は、会社・サービス、実績、記事、フォームなどの役割に分けます。存在しないURL、意図的に公開しないページ、検索から案内したいページを混同しないでください。権限のない環境や個人情報を、調査用という理由で公開しません。

Googleのクロールとインデックス登録の概要も参照し、巡回による取得と検索への登録を別の段階として扱います。公開した直後に見つからないことだけで、原因や修正範囲を断定しません。

2. ページと必要なリンクを取得できるか確かめる

対象URLのHTTP応答、最終的に開くURL、ログインの必要性、エラー、主要な本文とリンクを確認します。画面が表示されても、本文の一部が取得できない、リンクがボタンの操作だけに依存するなどの場合は別途調査が必要です。

主要ページがサイト内の自然なリンクから辿れるか、リンク先が読者の次の疑問に答えるかを確認してください。内部リンクは本数を増やすためではなく、必要な情報へ案内するために置きます。Googleのリンクをクロール可能にする方法も確認します。

JavaScriptによる表示が関係する場合は、初期HTML、ブラウザーで実行した後の表示、Google側の検査を区別します。詳しい手順はJavaScriptの本文・リンクの検収へ進めます。URLが開けたという結果だけを、検索側の取得確認として記録しません。

3. 登録・公開方針と取得結果を照合する

Search ConsoleのURL検査を使える担当者は、登録済みの情報と現在のライブテストの日時、正規URL、取得結果を記録します。ライブテストが成功したことと、検索へ登録されたこと、検索結果で希望の見え方になることは別です。

robots.txtは巡回の制御で、公開を守る認証の代わりではありません。また、巡回を止めることと検索から除外することも同じではありません。Google公式のrobots.txt説明を確認し、目的と影響を調べる前に一律の拒否を追加しません。

canonicalは正規URLの判断に関わる指定です。Google公式の正規化案内に沿って、内部リンク、転送、サイトマップ等との整合を調べます。重複を見つけただけで、別の内容のページへ指定を付け替えないでください。

XMLサイトマップは発見を助けますが、登録や順位を保証しません。公式のサイトマップ説明と照合し、検索へ案内したい正規URLが含まれているか、終了・非公開・転送対象が混ざっていないかを確認します。索引やURLの変更は、影響と承認を伴う別の作業として扱います。

4. タイトルと説明をページの答えに合わせる

タイトルは、ページで答える疑問と対象が分かるものにします。descriptionも本文の要約にし、対応していないサービス、確認できない無料条件、成果の約束を加えません。似たテーマでも、ページの役割が分かる表現へ整理します。

Googleはタイトルリンクを複数の情報から生成し、指定したtitleがそのまま表示されるとは限りません。タイトルリンクの公式説明を確認してください。固定の文字数だけを合否にせず、冗長な語の反復を減らし、必要な区別を保ちます。

descriptionにも固定の長さ制限はなく、表示時には必要に応じて切り詰められます。スニペットは本文からも生成され、検索内容によって異なる場合があります。Google公式のスニペット案内に沿って、本文の結論と重要な条件を確認します。変更直後の表示差だけで効果を断定しません。

5. スマートフォンで必要な情報と操作を試す

スマートフォンの幅で、メニュー、長い見出し、画像、比較表、フォーム、戻る操作を試します。PCで見える説明がスマートフォンでは欠けていないか、本文を読む前に操作が遮られないかも確認してください。

画像の意味は適切な代替テキストと周囲の説明でも伝えます。重要な情報を画像の中だけに置かず、表は見出しと対応が分かる形にします。特定の文字サイズやタップ寸法の数字一つだけで、すべての利用条件を満たしたとは扱いません。

表示速度の測定では、実利用と試験室の値、対象ページ、取得期間、通信条件を分けます。PageSpeed Insightsの公式説明に沿って、点数だけでなく原因と業務への影響を確認します。ページの使いやすさや検索・相談への効果は、改善後にも別々に観察します。

6. 構造化データは表示内容と現行条件を確認する

構造化データを付ける場合は、そのページの内容を表す形式か、現在のGoogleの対応条件に合うかを確認します。FAQ、レビュー、会社情報などを記述すること自体を、特別な検索表示や順位上昇の約束にしません。

Google公式の構造化データの概要と対象形式の現行ガイドを参照してください。記述が技術的に正しくても、希望する検索表示が必ず出るわけではありません。表示本文と違う内容、架空の評価、確認できない実績を追加しません。

WordPressではテーマと複数のプラグインから同じ形式が出る場合があります。実際に出力されたデータ、担当する部品、表示本文との一致を調べます。重複と変更の検収はJSON-LDの確認手順で詳しく扱います。

7. 修正前後の差分と検収を残す

現象と証拠に対応する変更を選び、対象URL・部品・変更理由・影響・原本・戻し方を保存します。修正する実装と、公開方針、URL、解析などの設定を分け、合意していない範囲へ変更を広げません。

WordPressに保存できたことだけで、公開ページへ反映されたと判断しません。公開後に必要な本文とリンク、メタ、画像、PC・スマートフォン・切替幅、受付や外部連携を読戻します。問題があれば、他者の更新を巻き戻さない対象単位の復元を検討します。

8. 調査と実装の依頼範囲を決める

企業担当者は、URL、見つけてもらいたい内容、困る現象、現在の担当、最近の変更を整理すると調査を依頼しやすくなります。Search Consoleの検査や技術設定をすべて自力で済ませてから相談する必要はありません。

企業・事業者は企業向けWeb制作・運用、制作会社はWordPress実装・既存修正の受託案内から、対象構成の調査、必要な原稿・出力・表示の修正と試験の範囲を確認できます。

相談窓口には、分かる範囲のURLと症状、依頼したい実務をお知らせください。調査できる環境と権限、納品する記録、修正・公開・継続観察の担当、費用と期間を個別に合意します。認証情報や個人情報を初回の文章へ貼り付ける必要はありません。

検査に合格すれば検索順位は上がりますか？

取得や表示の検査は、確認した条件での結果です。順位、適切な相談、受注、顧客の解決とは分けて確認します。技術上の問題を直すとともに、読者が必要とする答えとサービスへの自然な案内も確認してください。

支援後に何を残してもらうとよいですか？

課題に対応する変更差分と検収結果、残る条件、更新・復元の担当、次に観察する指標を残します。必要な公開情報と操作を維持し、担当者が次の更新や不具合時の判断へ進める状態を目指します。