SEO・GEO教科書 · Lesson 04
robots.txtとnoindexの使い分け、canonicalによる重複統合、サイトマップ、構造化データ、Core Web Vitalsの直し方を実装単位で整理します。Nuvemshop・redBus・Yahoo! JAPANニュースなど、公開されている改善事例の数値も添えます。
検索エンジンがページを取得し、正しく理解し、快適に表示できる状態を自分で作れるようになる。
このレッスンで扱うこと
robots.txtは「クロールしてよいか」を、noindexは「インデックスに登録してよいか」を制御します。 この2つは目的が違い、混同すると意図と逆の結果になります。とくに、検索結果に出したくないページに robots.txtのDisallowを使うのは誤りです。Googleは、ブロックされたページでも他ページからリンクされていれば URLがインデックスに登録される場合があると説明しています。[出典: robots.txt の書き方、設定と送信]
| やりたいこと | 使う仕組み | 書く場所 | 間違えると |
|---|---|---|---|
| 検索結果に出したくない | noindex | ページの <meta name="robots" content="noindex"> または X-Robots-Tag ヘッダー | Disallowで代用すると、URLだけ検索結果に残ることがある |
| クロール自体させたくない（管理画面・検索結果ページなど） | robots.txt の Disallow | サイト直下の /robots.txt | noindexで代用すると、無駄なクロールが発生し続ける |
| クロールもインデックスもさせたくない | まず noindex を付け、登録が消えてから Disallow | 両方 | 同時指定すると、取得できないためnoindexが読まれない |
| リンクを評価の対象にしたくない | rel="nofollow" / rel="sponsored" / rel="ugc" | 該当の a タグ | 広告リンクを無指定で置くと、リンクスパムとみなされる可能性がある |
robots.txtを変更したら、Search Consoleのrobots.txtレポートでGoogleが実際に読んだ内容を確認します。 CDNやサーバーの設定によっては、ブラウザで見えている内容とクローラーが取得する内容が違うことがあります。
同じ内容が複数のURLで見える状態は、評価が分散するだけでなく、どのURLを検索結果に出すかの判断をGoogleに委ねることになります。canonical・301リダイレクト・サイトマップの3つで、代表URLを1本に決めます。
Figure
重複URLを1本化する判断
Step 1
旧URLを残す必要がない
301リダイレクトで新URLへ恒久的に転送する。旧URLは検索結果から消える。
ここで落ちると リダイレクトを張らずに削除すると404が残り、流入が消える。
Step 2
両方のURLにアクセスさせたい
canonicalで代表URLを指定する。両方生きたまま、評価は代表URLに寄せられる。
ここで落ちると canonicalを付けないと、Googleがどちらかを勝手に選ぶ。
Step 3
パラメータ違いが大量にある
canonicalでパラメータ無しのURLを代表にする。サイトマップにも代表URLだけを載せる。
ここで落ちると 全パターンがインデックス対象になり、クロールが分散する。
サイトマップには、代表URLだけを載せます。canonicalで除外したURLをサイトマップに残すと、 サイトマップとcanonicalが矛盾したシグナルを出すことになります。サイトマップの更新日（lastmod）も、 全ページ同じ日付にすると更新のシグナルとして機能しません。[出典: サイトマップの作成と送信]
構造化データは、ページの内容を機械が読める形で併記するマークアップです。順位を上げる設定ではなく、 検索結果での表示のされ方（リッチリザルト）を変えるためのものです。[出典: 構造化データの仕組みについて]守るべき条件は1つで、マークアップの内容がページに表示されているテキストと一致していることです。
| ページの種類 | 使う型 | 何が変わるか |
|---|---|---|
| 記事・ニュース | Article / NewsArticle | 見出し・公開日・著者が正しく解釈される |
| よくある質問 | FAQPage | 質問と回答が構造として伝わる（表示は保証されない） |
| 手順の解説 | HowTo | 手順の並びが構造として伝わる |
| レシピ | Recipe | 調理時間・材料・評価が検索結果に表示されうる |
| イベント | Event | 日時・場所・チケット情報が検索結果に表示されうる |
| 求人 | JobPosting | 求人の検索結果に掲載されうる |
| 動画 | VideoObject | 動画タブ・Discoverなどの動画向け面に載る条件を満たす |
| パンくず | BreadcrumbList | 検索結果のURL表示が階層表示になる |
| 用語の定義 | DefinedTerm | 用語とその定義・別名の関係が伝わる |
実装後は、リッチリザルトテストとSearch Consoleの拡張レポートで検証します。 楽天レシピはCMS側で対応して2週間で全ページに反映し、構造化データテストツールで検証したうえで、 検索エンジンからの流入が2.7倍になったと報告しています。Eventbriteは基本テンプレートを1つ作り、 以降は微調整だけで運用しています。1ページずつ手で書くのではなく、テンプレートで一括して出すのが実装の要点です。
なお、生成AI向けの特別な構造化データは存在しません。Googleは、AI機能に表示されるために 特別なschema.orgの構造化データを追加する必要はないと明記しています。詳しくはレッスン07で扱います。
Core Web Vitalsは、LCP（読み込み）・INP（応答性）・CLS（視覚的な安定性）の3指標です。 良好とされる目安はLCPが2.5秒以内、INPが200ミリ秒以下、CLSが0.1以下で、判定はモバイルとPCを分けたうえで 全体の75パーセンタイルの値で見ます。[出典: web.dev「Web Vitals」]
Figure
Core Web Vitalsの3段階（良好／改善が必要／不良）
LCP
主要なコンテンツが表示されるまでの時間
INP
操作してから画面が反応するまでの時間
CLS
読み込み中にレイアウトがずれる量
3指標を同時に追わないでください。PageSpeed Insightsのフィールドデータを開き、最も悪い1指標に絞るほうが進みます。実際、redBusはINPだけに絞って改善し、売上が7%増えたと報告しています。
| 指標 | よくある原因 | 最初に試す対処 |
|---|---|---|
| LCP（読み込み） | ファーストビューの画像に loading="lazy" が付いている／LCP要素の読み込み優先度が低い／サーバーの応答が遅い | ファーストビューの画像から loading="lazy" を外し、fetchpriority="high" を付ける。先頭要素のCSSトランジションを外す |
| INP（応答性） | 1回の操作で重い処理が走る／1リクエストで大量のデータを取得している／状態更新の範囲が広すぎる | 1回あたりの取得件数を減らす。入力中の状態はコンポーネント内で持ち、確定時だけ全体に反映する |
| CLS（安定性） | 画像や広告枠の寸法が指定されていない／後から差し込まれる要素がある／Webフォントの差し替えで文字が動く | 画像・iframe・広告枠に width と height を指定する。差し込み領域の高さをあらかじめ確保する |
Figure
Core Web Vitalsの進め方
やること
やらなくていいこと
このレッスンで扱った作業について、施策と結果の数値が同じ文書で公開されている事例です。数値は各社の環境での結果であり、同じ結果を保証するものではありませんが、どの作業がどの指標に効いた例があるかの対応関係は読み取れます。
Core Web Vitals
ブラジル・ECプラットフォーム（18万店舗超）
やったこと
ブラウザがLCP要素を取り違えていた原因を3つ潰した。ファーストビューの画像から loading="lazy" を外し、LCP画像に fetchpriority="high" を付け、先頭セクションのCSSトランジションを削除した。
報告された結果
出典: How Nuvemshop's image prioritization strategy led to a 68% improvement in LCP and 8.9% more conversions（web.dev（Google）ケーススタディ）
Core Web Vitals
インド・バス予約
やったこと
検索結果の1リクエストあたりの取得件数を30件から10件に減らし、入力欄の状態をコンポーネント内で持ってblur時だけ全体に同期するようにした。INP（操作への応答性）に絞って改善している。
報告された結果
出典: How redBus improved their INP by 72% and increased sales by 7%（web.dev（Google）ケーススタディ）
Core Web Vitals
日本・ニュースメディア
やったこと
CLS（読み込み中のレイアウトのずれ）を改善し、ラボデータで約0.2から0にした。
報告された結果
出典: Yahoo! JAPAN News improved CLS by 0.2 and increased page views per session by 15%（web.dev（Google）ケーススタディ）
構造化データ
日本・レシピ投稿（月間アクティブ1,500万人）
やったこと
レシピの構造化データを2012年から導入し、2014年に対象を広げた。2017年にはGoogle検索チームと共同でマークアップを見直し、CMS側で対応して2週間で全ページに反映。構造化データテストツールで検証している。
報告された結果
出典: Rakuten Recipe increases time on site 1.5X with structured data（Google 検索セントラル 成功事例）
構造化データ
米国・イベントチケット
やったこと
Googleのイベント向けドキュメントに沿って、公開している全イベントページにEvent構造化データを実装した。基本テンプレートを1つ作り、以降は微調整だけで運用している。実装後は構造化データテストツールで正しさを確認。
報告された結果
出典: Eventbrite boosts traffic 100% with event structured data（Google 検索セントラル 成功事例）
数値は各社の環境・時期・同時に実施した他の施策を含んだ結果です。同じ施策で同じ結果が出ることを示すものではありません。
Figure
Core Web Vitalsの改善で報告された事業指標の変化
Rakuten 24: 訪問者あたり収益
53.37%
CLSを92.72%改善するなどCore Web Vitalsに投資（A/Bテスト）
Nykaa: tier2・3都市からの自然検索流入
28%
LCPを40%改善
Yahoo! JAPANニュース: セッションあたりPV
15.1%
CLSを約0.2から0へ
Nuvemshop: モバイル自然検索のCVR
8.9%
ファーストビュー画像の優先度を修正
Vodafone（イタリア）: 売上
8%
LCPを31%改善
redBus: 売上
7%
INPを870〜900msから350〜370msへ
全11件の実例はレッスン09にまとめています。 次のレッスンでは、技術的に読める状態になったページに、引用される本文を書いていきます。
次の項目を自分のサイトで確認できたら、このレッスンは終わりです。1つでも「まだ」がある場合は、次のレッスンに進む前にそこを埋めてください。
されないとは限りません。Googleは、robots.txtでブロックされたページでも、他のページからリンクされていればURLがインデックスに登録されることがあると説明しています。検索結果に出したくないページには、robots.txtのDisallowではなくnoindexを使います。noindexは、クローラーがそのページを取得できて初めて読み取られるため、Disallowと同時に指定すると機能しません。
構造化データはページの内容を検索エンジンが理解し、リッチリザルトとして表示するための仕組みです。順位を直接上げる設定ではありません。ただし、公開されている成功事例では、Event構造化データの実装後にイベントページへの検索流入が例年比で約100%増えた（Eventbrite）、レシピの構造化データで検索流入が2.7倍になった（楽天レシピ）といった結果が報告されています。表示のされ方が変わることでクリックが増える、という経路で効いていると考えられます。
まず「良好」の目安（LCP 2.5秒以内、INP 200ミリ秒以下、CLS 0.1以下）を全体の75パーセンタイルで満たすことを目標にします。3つ全部を同時に追うのではなく、PageSpeed Insightsのフィールドデータで最も悪い1指標に絞るほうが進みます。redBusはINPだけに絞って870〜900msを350〜370msに改善し、売上が7%増えたと報告しています。
必須ではありません。Googleは、Googleニュースやトップニュース枠への掲載にAMPを必須とはしておらず、通常のページでCore Web Vitalsを満たせば同じ扱いを受けられます。過去の成功事例にAMPが登場するのは、当時の実装として選ばれたためです。いまから始める場合は、通常のページの表示速度を直すほうが優先です。