この記事の要点：
- SEOの内部対策（テクニカルSEO）は、検索エンジンがページを見つけ、内容を理解し、インデックスに登録できるように、サイトの技術的な状態を整えることです。
- 点検はクロール・インデックスとURL・ページの構造・ページの体験の26項目で行い、検索に出ない原因になる優先度「高」の項目から確かめます。
- リダイレクトやnoindexは見た目では分からないため、Search ConsoleのURL検査やcurlでHTTPの応答を確かめます。
- テンプレートやサーバーの変更はサイト全体を止めうるため、バックアップ・反映前の自動確認・元に戻す手順を用意します。
SEOの内部対策（テクニカルSEO）とは
SEOの内部対策（テクニカルSEO）とは、検索エンジンがページを見つけ、内容を正しく理解し、インデックス（検索エンジンのデータベース）に登録できるように、自社サイトの技術的な状態を整えることです。
内部対策は、順位を直接押し上げる手段ではなく、良いページが正しく評価されるための前提です。noindexの付け忘れが1行あれば良い記事も検索に出ず、問題のない項目に時間をかけても見え方はほとんど変わりません。
内部対策の3つの柱
| 柱 | 目的 | 主な項目 |
|---|---|---|
| クロール | 検索エンジンのプログラム（クローラー）がページにたどり着けるようにする | robots.txt、XMLサイトマップ、内部リンク、サーバーエラー、JavaScript |
| インデックス | 見つけたページを、正しいURLで、正しい内容として登録させる | noindex、canonical、URLの統一、301リダイレクト、重複、title、見出し、構造化データ |
| ページの体験 | 訪れた人が安全に、快適に読めるようにする | HTTPS、モバイル表示、コアウェブバイタル、画像、404ページ |
外部対策・コンテンツSEOとの違い
内部対策は「自社のサイトの仕組みと設定」、コンテンツSEOは「ページに何を書くか」、外部対策は「他のサイトから被リンクや言及を得ること」を扱います。titleや見出しを内部対策に含める説明も多く、この記事でもサイト全体で点検する項目として扱います。title・見出し・リンク・画像など、ページの HTML のどのタグを Google が何に使うかはSEOに関係するHTMLタグ一覧で整理しています。
内部対策チェックリスト26項目
優先度は「高＝検索に出ない・評価が分散する原因になりうる」「中＝影響するページが多ければ早めに」「低＝該当するサイトだけ、または余裕があるとき」の目安です。テクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。
クロール（8項目）
| # | 項目 | 確認方法 | 道具 | 優先度 |
|---|---|---|---|---|
| 1 | robots.txtで、検索に出したいページをブロックしていない | /robots.txt を開き、Disallow の行を確認。「設定」→「robots.txt」で取得状況を見る | ブラウザ、Search Console | 高 |
| 2 | XMLサイトマップを送信し、インデックスさせたいURLだけを載せている | 「サイトマップ」でステータスが「成功」か、検出されたURLの数が実際のページ数に近いか | Search Console | 高 |
| 3 | 重要なページへ、aタグ（href付き）の内部リンクでたどれる | トップやカテゴリーから実際にクリックして到達できるか。リンクがonclickだけになっていないか | ブラウザ、クロールツール | 高 |
| 4 | サーバーエラー（5xx）やタイムアウトが続いていない | 「設定」→「クロールの統計情報」の「ホストのステータス」 | Search Console | 高 |
| 5 | サイト内のリンク切れ（404）がない | 「ページのインデックス登録」の「見つかりませんでした（404）」、クロールツールの結果（404エラー） | Search Console、クロールツール | 中 |
| 6 | 本文やリンクをJavaScriptで出す場合、表示後のHTMLに含まれる | URL検査の「公開URLをテスト」→「テスト済みのページを表示」でHTMLを確認（JavaScript SEO） | Search Console | 中 |
| 7 | カテゴリーと記事の階層が整理され、深すぎない | 重要なページがトップから何回のクリックで届くかを数える（サイト構造） | ブラウザ、クロールツール | 中 |
| 8 | パンくずリストで、ページの位置が分かる | テンプレートで全ページに出ているか、リンクが正しい階層を指しているか | ブラウザ、リッチリザルトテスト | 中 |
インデックスとURL（8項目）
| # | 項目 | 確認方法 | 道具 | 優先度 |
|---|---|---|---|---|
| 9 | 検索に出したいページにnoindexが付いていない | URL検査の「インデックス登録を許可？」、ページのソースの meta robots、HTTPヘッダーの X-Robots-Tag | Search Console、curl | 高 |
| 10 | 空の一覧、サイト内検索の結果、テスト用ページなどを検索対象から外している | 「ページのインデックス登録」で「登録済み」のURLに不要なものが混ざっていないか | Search Console | 中 |
| 11 | canonicalが、自分自身か正しい正規URLを指している | URL検査で「ユーザーが指定した正規URL」と「Googleが選択した正規URL」を比べる | Search Console、ソース表示 | 高 |
| 12 | http／https、wwwの有無、末尾スラッシュの違いが1つのURLに統一されている | それぞれのURLを開き、301で1つに転送されるか（URLの正規化） | curl、ブラウザ | 高 |
| 13 | URLを変えたページは、旧URLから新URLへ直接301リダイレクトしている | 転送の回数と最終URLを確認。A→B→Cの連なりがないか | curl | 高 |
| 14 | 同じ内容のページが複数ない | 「重複しています。ユーザーにより、正規ページとして選択されていません」の件数と中身（重複コンテンツ） | Search Console | 中 |
| 15 | 未登録のURLの理由を把握している | 「ページのインデックス登録」の理由ごとの件数（インデックスされない原因） | Search Console | 高 |
| 16 | 多言語サイトでは、言語ごとのURLとhreflangが対応している | ページのソースで、相互に hreflang が指し合っているか | ソース表示 | 低（該当時は中） |
ページの構造（5項目）
| # | 項目 | 確認方法 | 道具 | 優先度 |
|---|---|---|---|---|
| 17 | titleがページごとに異なり、内容を表している | 同じtitleのページがないか、長すぎないか（タイトルタグとメタディスクリプション） | クロールツール、検索結果 | 中 |
| 18 | meta descriptionがページの要約になっている | テンプレートの同じ文がすべてのページに入っていないか | クロールツール | 低 |
| 19 | h1が内容を表し、h2・h3が構成どおりに並ぶ | 見出しだけを抜き出して目次として読めるか（見出しタグ） | ブラウザの拡張機能、開発者ツール | 中 |
| 20 | 内容を伝える画像にalt属性がある | alt が空・未設定の画像を一覧にする | クロールツール、Lighthouse | 中 |
| 21 | 構造化データにエラーがなく、ページの内容と一致している | リッチリザルトテスト、Search Console の種類別のレポート | Search Console、リッチリザルトテスト | 中 |
ページの体験（5項目）
| # | 項目 | 確認方法 | 道具 | 優先度 |
|---|---|---|---|---|
| 22 | 全ページがHTTPSで表示され、http の画像やスクリプトが混ざっていない | 「HTTPS」レポート、ブラウザの開発者ツールのコンソール（混在コンテンツの警告） | Search Console、ブラウザ | 高 |
| 23 | スマートフォンでも、パソコンと同じ本文・リンク・構造化データがある | URL検査のスクリーンショットとHTML、スマートフォン実機での表示（モバイルファーストインデックス） | Search Console、実機 | 高 |
| 24 | コアウェブバイタルで「不良」のURLがない | 「ウェブに関する主な指標」でURLのグループごとに確認し、PageSpeed Insightsで原因を見る | Search Console、PageSpeed Insights | 中 |
| 25 | 画像が表示サイズに合い、ファーストビュー以外は遅延読み込みしている | Lighthouse の指摘、画像の実寸と表示サイズの比較（画像の最適化） | Lighthouse | 中 |
| 26 | 存在しないURLが、案内付きの404ページを返す（200を返していない） | 適当なURLを開き、ステータスコードが404か確認 | curl、ブラウザ | 低 |
優先度の付け方（判断の目安）
今のサイトの状況から、先に見る項目を決めます。
| 状況 | 先にやること | 後回しにしてよいこと |
|---|---|---|
| 新しいページがいつまでもインデックスされない | 1・9・11（ブロック・noindex・canonical）を確認し、次に3と2（内部リンクとサイトマップ） | 表示速度の細かな改善 |
| サイトのリニューアルやURL変更を予定している | 旧URLと新URLの対応表を作り、13（301）と12（URLの統一）を公開前に準備 | meta descriptionの書き直し |
| 表示回数がある時期から急に落ちた | その前後の変更（テンプレート・プラグイン・サーバー）と、9・11・4を確認（検索順位が下がったときの確認手順） | 新しい構造化データの追加 |
| 数百ページ程度で、Search Consoleに目立つ問題がない | 15で未登録の理由を一度確認したら、記事の改善に時間を使う | クロールの効率（Googleは、クロールの割り当てを気にする必要があるのは主に大規模なサイトと説明しています） |
| 「不良」のURLが同じテンプレートに集中している | 24・25をテンプレート単位で直す | 1ページずつの個別調整 |
| WordPressで複数のSEOプラグインやテーマの機能が重なっている | title・canonical・構造化データ・サイトマップが二重に出ていないか確認 | 新しいプラグインの追加 |
30日で進める内部対策の点検計画
社内の担当者が通常業務と並行して1か月で一巡する計画の例です（施工事例120ページとブログ80記事がある、社員30名の工務店のWordPressサイト）。
| 期間 | やること | 終わりの状態 |
|---|---|---|
| 1〜3日目 | Search Consoleの権限を確認し、サイトマップからURLの一覧を出す。問い合わせにつながる重要なページを10〜20本選ぶ | 点検するURLの一覧と、重要ページの印 |
| 4〜7日目 | 項目1・4・9・15：robots.txt、noindex、サーバーエラー、未登録の理由を確認 | 「検索に出ない原因」がないか、ある場合はその一覧 |
| 8〜14日目 | 項目10〜14：URLの統一、301、canonical、重複を確認。サイトマップから noindex やリダイレクトのURLを外す | 1つの内容に1つのURL |
| 15〜21日目 | 項目22〜26：HTTPS、スマートフォン表示、コアウェブバイタル、画像、404ページ | 「不良」のURLのグループと、直す担当の決定 |
| 22〜27日目 | 項目3・5〜8・17〜21：内部リンク、リンク切れ、見出し、alt、構造化データ | 重要ページに関連記事からリンクがある状態 |
| 28〜30日目 | 直したURLをURL検査で確認し、必要なものはインデックス登録をリクエスト。変更した内容と日付を記録 | 変更履歴と、次回（例：3か月後）の点検日 |
4〜7日目：止まっている原因を探す手順
- Search Consoleの「ページのインデックス登録」で、「ページがインデックスに登録されなかった理由」を件数の多い順に見ます。
- 「noindex タグによって除外されました」「robots.txt によりブロックされました」に検索に出したいページが含まれていないか、URLの例で確かめます。
- 重要ページを1本ずつ「URL検査」にかけ、「クロールを許可？」「インデックス登録を許可？」「Googleが選択した正規URL」を記録します。
- 「設定」→「クロールの統計情報」で、サーバーの応答に問題が出ていないかを確認します。
制作中の設定が残りやすいのが次の robots.txt で、最初の2行だけでサイト全体のクロールが止まります。
# 制作中の設定
User-agent: *
Disallow: /
# 公開後の例
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xmlクロールの統計情報レポートの見方
クロールの統計情報レポートは、Googleのクロールのリクエスト数・応答・ファイル形式などを示すSearch Consoleのレポートで、「設定」→「クロールの統計情報」から開きます。Search Console ヘルプは上級者向けとし、1,000ページ未満のサイトでは使う必要はないとしています（2026年10月に確認）。
| 項目 | 見ること |
|---|---|
| ホストのステータス | 過去90日にrobots.txtの取得・DNS・サーバー接続の問題があったか |
| クロール レスポンス | 大半が200などの正常な応答か。5xxやリダイレクト エラーが無いか |
| ファイル形式・目的 | HTML以外の取得の割合、「検出」と「更新」の割合 |
ドメイン プロパティか、ルートのURLプレフィックス プロパティでだけ使えます。気にすべきサイトの目安は「クロールバジェット」で説明しています。
8〜14日目：URLの統一をコマンドで確かめる
ターミナルの curl でHTTPの応答を見ます。
# http から https へ、恒久的（301）に転送されているか
curl -sI http://example.com/ | head -n 5
# → HTTP/1.1 301 Moved Permanently
# → Location: https://example.com/
# 最終的なURLと、転送の回数（1回が目安）
curl -sIL -o /dev/null -w '%{url_effective} %{num_redirects}n' http://www.example.com/works
# HTTPヘッダーで noindex を指定していないか
curl -sI https://example.com/works/ | grep -i x-robots-tag
# HTMLの canonical と meta robots
curl -s https://example.com/works/ | grep -i -E 'rel="canonical"|name="robots"'canonical は、そのページ自身のURLを絶対URLで書くのが基本です。例：<link rel="canonical" href="https://example.com/works/kitchen-renovation/">。並べ替えや絞り込みのパラメータが付いたURLでは、パラメータのない一覧のURLを指します。
28〜30日目：記録を残す
変更した日付、URL、変えた設定、確認した方法を1行ずつ残します。表示回数が動いたとき、関係しそうな変更を振り返れます。
当サイト（seoagent.jp）での実例
当サイトの作り直しで、見た目では気づけず、HTTPの応答やSearch Consoleで分かった問題です。
| 項目 | 起きていたこと | 行ったこと・確認方法 |
|---|---|---|
| リダイレクト（#12・13） | トップ / から日本語版 /ja/ への転送が302（一時的）だった | 301（恒久的）に変更し、旧サイト時代のURLも1対1で301に。その後、検索への登録前に日本語版をトップ / に移し、/ja/ で始まるURLは対応するページへ301。反映のたびにこの301を確認 |
| XMLサイトマップ（#2） | SEOプラグインのサイトマップが古いキャッシュのまま、4件しか載っていなかった | キャッシュを作り直し、反映のたびに作り直すようにした。4件から72件になり、その後の記事追加で150件を超えた。記事のない一覧（noindex）はサイトマップから外している |
| canonical（#11） | 記事一覧 /ja/blog/ のcanonicalが、/ja/blog/ja/ という存在しないURLを指していた（多言語プラグインとの組み合わせ） | canonicalをページ自身のURLに直す処理を追加。全ページのcanonicalが自分自身を指すことを点検で確認 |
| 表示速度（#24・25） | モバイルのLighthouseが85、LCPが4.1秒 | モバイルではヒーロー画像を読み込まない、800px幅の画像を追加、画像のキャッシュ期間を延長。Lighthouseモバイル85→100（LCP約1.5秒）。いずれもラボ値 |
| 反映の安全策 | 追加した処理の名前が既存のものと重なり、反映直後に本番サイトが約9分止まった | 反映前にPHPの構文と関数名の重複を自動で確認し、問題があれば止めるようにした。反映前のバックアップと自動の切り戻しは元から実施 |
よくある失敗と対処
| 起きる状況 | 原因 | 直し方 |
|---|---|---|
| リニューアル後、ほとんどのページが検索から消えた | 制作環境の noindex や robots.txt の Disallow: / が残っている | 公開当日に、トップと重要ページをURL検査で確認する手順を公開作業に入れる |
| 旧URLの評価が引き継がれていないように見える | 旧URLをすべてトップへ転送している、または302のまま | 旧URLごとに内容の近い新URLへ301。対応先がないページは404で構わない |
| 記事がインデックスされず、「Googleが選択した正規URL」が別のページになっている | テンプレートのcanonicalがトップや一覧を指している | canonicalをページ自身のURLに直し、テンプレート単位で全ページを確認 |
| サイトマップの「検出されたURL」が実際より極端に少ない | プラグインのキャッシュ、投稿タイプの除外設定 | サイトマップのURLを直接開いて中身を確認し、キャッシュを作り直す |
| スマートフォンで見ると関連記事のリンクがない | モバイル用のテンプレートで内容を省いている | 折りたたみ表示などで、モバイルにも同じ本文とリンクを残す |
| 計測ツールの点数のために画像や本文を削った | 点数を目的にしている | 読者に必要な内容は残し、画像の圧縮や読み込み順で改善する |
| 背景と同じ色の文字でキーワードを並べている | 古い手法の名残 | 隠しテキストやクローキング（人と検索エンジンに別の内容を見せる）は、Googleのスパムに関するポリシーに反するため削除する |
AI検索と内部対策
GoogleのAIによる概要やAIモードに表示されるために、特別なマークアップや追加の技術的な要件は必要ないと、Googleは説明しています。前提は通常の検索と同じく、ページがクロールでき、インデックスされ、スニペット付きで表示できる状態で、チェックリストの項目1・9・11などはAI検索での表示の前提でもあります。
- 大事な情報は画像の中だけでなく、テキストで書く
- 構造化データは、ページに見えている内容と一致させる
- robots.txt で、Googleの検索用のクローラーを誤ってブロックしない。生成AIの学習用の制御（Google-Extended）は、Google検索への掲載や順位には影響しないとGoogleは説明しています
AIの回答に使われる情報は検索エンジン側が決めるため、内部対策を整えても引用は約束されません。
よくある質問
内部対策の点検は、どのくらいの頻度で行えばよいですか？
一巡した後は、3か月ごとなど時期を決めて点検します。テーマやプラグインの変更、サーバーの移転、URLの変更の後や、表示回数が急に変わったときは、その都度、重要なページをURL検査で確かめます。
専門知識がなくても、自分で点検できますか？
Search Consoleで確かめる項目（ページのインデックス登録、URL検査、サイトマップ、HTTPS、ウェブに関する主な指標）は、管理画面の操作で確認できます。robots.txtやサーバーの設定、テンプレートの修正が必要になった場合は、制作会社やサイトの担当者と進めます。
Lighthouseなどの点数が低いと、順位に影響しますか？
Lighthouseの点数は決まった条件で測ったラボ値で、順位を決める値そのものではありません。まず、実際の利用者のデータに基づくSearch Consoleの「ウェブに関する主な指標」で「不良」のURLがあるかを確かめます。点数のために必要な内容は削りません。
リニューアルを制作会社に頼むとき、何を伝えればよいですか？
旧URLと新URLの対応表と301の設定、公開時に制作環境のnoindexやrobots.txtの「Disallow: /」を外すこと、canonicalがページ自身を指すこと、の3点は依頼の時点で伝えます。公開当日にトップと重要ページをURL検査で確かめる作業も、公開の手順に入れてもらいます。
SEOAGENTでできること
SEOAGENTでは、AI検索向けのクローラー設定や表示速度の確認、記事同士の内部リンクの提案、Search Consoleと連携した効果測定を進められます。テーマやサーバーの設定そのものは、サイト側で変更します。
