SEOの内部対策｜サイトの点検手順

記事を書き始める前に、必ず通す点検があります。8工程・90分で終わり、費用はかかりません。 ここが壊れていると、何本書いても検索結果に出ません。順位の話ではなく、そもそも読まれる状態にあるかの話です。 この章は、点検を順番に並べ、それぞれ「どの道具で見て、合格ラインはどこか」を数字で決め、12項目の点検リストで土台の合否を出すための章です。

この章で分かること

• 点検の順番と、その理由（前の工程が×なら、後ろを直しても結果は変わらない）
• 8工程それぞれの、使う道具と合格ライン（すべて数字か○×で書いてある）
• ×が出たときに直す順番。今日やるものと、後回しにしてよいもの

工程1　サーバーとURLの集約

手順：アドレス欄に4通りで打ちます。http://example.com ／ http://www.example.com ／ https://www.example.com ／ https://example.com/（末尾スラッシュの有無も）。

合格ライン：4通りすべてが301で同じ1つのURLに着地する。鍵マークが出る。証明書の有効期限が30日以上先。

よくある×：wwwあり・なしの両方がそのまま表示される。同じ内容が2つのURLにある状態で、工程6の重複の原因そのものです。評価が割れ、どちらも上がりません。

工程2　インデックス（ここが最重要）

手順：Search Console →「ページのインデックス登録」→「登録済み」の数を公開ページ数と比べる →「登録されなかったページ」の理由を1つずつ開く。

主な理由の読み方です。

表示される理由	意味	どうするか
検出 - インデックス未登録	見つけたが、まだ読みに来ていない	内部リンクを足す（工程8）／サイトマップに入れる
クロール済み - インデックス未登録	読んだが、載せる価値を認めていない	中身を足す・統合する（7章）
重複（Googleが別の正規URLを選択）	別のURLと同じ内容と判断された	工程6へ
noindexタグによって除外	意図どおりか確認する	意図していないなら外す
robots.txt によりブロック	読みに行けていない	工程3へ

合格ライン：登録済み ≧ 公開ページ数 × 0.9。かつ未登録の理由を全部説明できること。

この表は、理由の名前を覚えるための表ではありません。未登録のページを1つ開いて、表示されている理由を左の列から探し、右の列の作業に進むために使います。理由ごとに行き先が違うので、全部をまとめて「インデックスされない問題」として扱わないでください。中身を足すべきものと、リンクを足すべきものと、設定を外すべきものが混ざっています。

この工程が×のまま記事を増やすのが、最も多い失敗です。 索引に入っていなければ、順位も表示回数も永久に0です。

たとえば、3年かけて記事を120本ほど書いてきた会社を考えます。担当者は毎月きちんと更新していて、中身も現場の知見が入った良いもの。ところが問い合わせは1件も増えていない。Search Console を開いて登録済みの数を数えると、120本のうち索引に入っているのは30本ほどで、残りは「検出 - インデックス未登録」のまま止まっている——こういうことが起こりえます。

よくある原因は、記事同士がどこからもリンクされていないことです。記事の一覧ページが作られておらず、公開しても既存のページからたどり着けない。サイトマップに入っていても、それだけでは読みに来る優先度が上がりません。一覧ページを作って内部リンクを通すのは、作業としては半日です。

この場合に失っているのは、記事90本分の労力です。書く力にも、続ける意志にも問題はありません。90分の点検を一度もやっていない、というだけです。

工程3　robots.txt

手順：ブラウザで https://自社ドメイン/robots.txt を開き、次の5点を見ます。

1. 200で表示されるか（無い場合、Sitemap: の行も失っています）
2. Disallow: / が入っていないか。 テスト環境の設定が本番に出る事故は実際に起きます。ここが×なら他の点検は不要。今すぐ直します
3. CSS・JS・画像のフォルダを塞いでいないか。 Googleは描画して評価するため、塞ぐと崩れた状態で判断されます
4. Sitemap: の行があるか
5. 消したいページを robots.txt で塞いでいないか

5番は間違えやすい場所です。robots.txt はクロール（読みに来ること）を止めるもので、インデックス（載ること）を止めるものではありません。 塞ぐと noindex も読めず、他サイトからリンクされていればURLだけが検索結果に残ることがあります。消したいなら、クロールを許可して noindex を読ませるのが正しい手順です。

当社の robots.txt は、/admin/ と /api/ だけを Disallow し、AIクローラーのユーザーエージェント（GPTBot・OAI-SearchBot・ClaudeBot・PerplexityBot など）を1つずつ書いて明示的に許可しています。誰でも開いて確認できます。

工程4　サイトマップ

手順：/sitemap.xml を開く → Search Console の「サイトマップ」に登録 → ステータスと「検出されたURL」の数を見る。

合格ライン

• ステータスが「成功」、エラー0
• 検出URL数が公開ページ数と±10%以内
• 1ファイル 50,000URL・50MB（非圧縮）以内（Googleの上限。超えるなら分割）
• lastmod が、実際に更新した日になっている

よくある×：noindexのページや404のURLが混ざっている。lastmod が毎日全ページ「今日」になっている。Googleは lastmod を「一貫して正確であれば使う」としているため、後者は日付そのものを信用されなくなるやり方です。

当社はサイトマップをコードから自動生成し、1時間ごとに作り直しています。手で書いたXMLは更新漏れが必ず起きるので、生成する仕組みに寄せてください。

工程5　表示速度

手順：PageSpeed Insights に本番URLを入れる → モバイルのタブ → 「実際のユーザーの環境で評価する」（フィールドデータ） の3つの数字を読む。

合格ライン（Google公表の「良好」。過去28日の75パーセンタイルで判定）

指標	何の時間か	良好
LCP	大きい要素が表示されるまで	2.5秒以下
INP	操作してから反応するまで	200ミリ秒以下
CLS	表示中のガタつきの量	0.1以下

0〜100の点数（パフォーマンススコア）は合格ラインに使いません。 ラボ環境の推定値で、日によって10点以上動きます。見るのは上の3つだけです。フィールドデータが出ない場合はラボデータで代用し、画像の圧縮・画像の縦横サイズ指定・フォントの読み込みの3つだけ直せば、たいてい基準に入ります。

この工程は×でも執筆を止めません。 工程2・3・4の×は「出ない」ですが、速度の×は「出るが遅い」です。

工程6　重複と正規化

手順：主要ページのソースで <link rel="canonical"> の値を見る。同じ内容が複数URLで開けないか試す（?utm_source= 付き、末尾スラッシュ有無、index.html 付き、同じ記事が複数カテゴリの下にある）。

合格ライン：canonical が自分自身の正規URLを指している。Search Console の除外理由に「重複」がほぼ出ていない。

canonical は Google にとって命令ではなくヒントで、従わないこともあります。最終的な解決は、1つの内容が1つのURLでしか開けない状態にすることです。

工程7　構造化データ

手順：リッチリザルトテストにURLを入れる → エラーを確認 → Search Console の「拡張」レポートで全体を見る。

合格ライン：エラー0。Organization（会社情報）と BreadcrumbList（パンくず）が入っている。書いてある内容が画面の表示と一致している（不一致はスパムポリシー違反です）。

ここで期待値を合わせます。構造化データを入れると順位が上がる、という公表はありません。 効くのはリッチリザルト（パンくず表示、求人、レビューの星など）の対象になることだけです。しかも対応する種類は決まっていて、FAQ と HowTo は2026年9月時点で対応一覧（検索ギャラリー）に載っていません。 書くのは構いませんが、出る前提では扱いません。

当社は Organization（社名・所在地・法人番号・代表者）・Person・WebSite・Article・BreadcrumbList を入れています。会社の実体を1か所で確定させるのが目的で、AI検索対策としてやっていることも実質ここまでです。

工程8　内部リンク

手順：Search Console →「リンク」→「内部リンク」をリンク数の多い順に見る。トップから売りたいサービスページまで何回クリックするかを数える。

合格ライン：重要ページがトップから3クリック以内。内部リンクが0のページが無い。内部リンク数の上位に、売りたいページが並んでいる。

よくある×：記事からサービスページへのリンクが1本も無い。記事が読まれても問い合わせに届きません。順位ではなく導線の問題です。

ついでに確認する：AI検索まわり

ついでに3つだけ見ます。確かなことが少ない領域なので、分かっている事実だけ書きます。

• AIクローラーを robots.txt で塞いでいないか。 塞ぐのも選択肢ですが、意図して選んだかが大事です。学習用のクローラーと、回答のために読みに来るクローラーは別物です
• llms.txt は要るのか。 Googleは公式ガイド「生成AI機能向けの最適化」（2026年7月10日更新）で、AI OverviewsやAIモードに出るために llms.txt のような新しいファイルやマークアップを作る必要はなく、ランキングにも影響しないと明記しています。主要なAI提供元で「使う」と表明しているところもありません。当社は置いていますが、効果は主張しません。構造化データも同じで、生成AI検索に必須ではないとされています
• 見え方は Search Console の生成AIパフォーマンスレポートで確認する。2026年6月に提供開始、8月31日に全サイトへ展開。見られるのは表示回数だけで、クリック・CTR・検索語は含まれません

つまり2026年9月時点のAI検索対策は、この章の工程1〜8をやることとほぼ同じです（8章で詳しく）。

×が出たときに直す順番

全部を同時に直そうとすると止まります。次の順で片付けます。

優先	×の内容	理由
今日	4（Disallow: / で全体を塞いでいる）／3（主要ページが未登録）	存在しないのと同じ
今週	2（URLが集約されていない）／9（重複）	評価が割れて上がらない
今月	6・7（サイトマップ）／11（孤立ページ）	見つかるのが遅れる
時間があるとき	8（表示速度）／10（構造化データ）	出ないわけではない

この表は、×の一覧を並べ替えるために使います。点検で出た×を、左の列のどれかに割り振ってください。割り振った時点で、今日やることが決まります。全部を一度に片付けようとすると、たいてい取りかかりやすいものから手が付き、重いものが残ります。

どれを自分で直し、どれを頼むかで迷ったら、robots.txt とサイトマップと内部リンクは自分で、速度と重複の解消は頼む、という線を勧めます。前者は設定と構成の話で、間違えてもすぐ戻せます。後者はコードや画像の作り方に踏み込むので、手を出すと別のところを壊すことがあります。ただし、頼む前に自分で○×を付けておいてください。×の項目だけを渡せば、見積もりの範囲がそこで確定します。

「時間があるとき」の行に、いちばん時間を使ってしまうのが典型的な失敗です。 速度を0.3秒縮めるより、未登録のページを索引に入れるほうが桁違いに効きます。

速度の改善は、成果が数字で見えるので達成感があります。点数が50から80に上がれば、報告もしやすい。索引の登録は、数えてみるまで増えたかどうかも分かりません。人は見える成果のほうに寄るので、放っておくと優先順位は自然に逆転します。この表を作る目的は、その自然な傾きに逆らうことです。

この章の出口

手元に残っているべきものは3つです。

1. 12項目の○×が付いた表（日付入り。次回の比較に使う）
2. 直す順番が付いたリスト（今日・今週・今月・時間があるとき）
3. 自分で直せるもの／頼むものの線引き

3番で「頼む」に入ったものが、外部に出す範囲です。当社のサイト改善は、初回相談と改善方針の提案が無料、現状分析が20万円から、継続的な改善が月5万円からです。12項目を自分で付けてから相談すれば、話が早く、見積もりも小さくなります。

土台が○になったら、次は「何を成果と呼ぶか」を決めます。点検で使った Search Console が、そのまま毎月見る道具になります。

次の章へ：3章 SEOの効果測定｜順位ではなく問い合わせ数