技術的SEOとAIO最適化のハブ: 構造化データ・Core Web Vitals・内部リンク設計
title/meta、JSON-LD構造化データ、sitemap、Core Web Vitals、内部リンク、AI回答エンジン対策まで。Webサイトを検索とAIに見つけてもらうための土台を、実装つきでまとめます。
ある朝、自分のブログを site:claudecodelab.com でGoogle検索したら、3か月前に書いた記事がインデックスにすら入っていませんでした。
本文は悪くない。むしろ自信作だった。なのに、検索の表舞台に立てていない。原因を1つずつ潰していったら、犯人は文章の質ではありませんでした。<title> がテンプレートのまま全ページ同じ、構造化データが空、画像が4MB、内部リンクがゼロ。要するに、Googleとブラウザに「読んでください」と伝える配線が、まるごと抜けていたんです。
SEOというと、つい「キーワードを何回入れるか」の話になりがちです。でも僕がこの数か月で痛感したのは、もっと手前に土台があるということ。検索エンジンとAI回答エンジンが、ページを見つけて・読めて・引用できる状態を作る。ここが崩れていると、どれだけ良い文章を書いても空振りします。
この記事は、その土台をまとめたハブです。技術的SEO(titleやmeta、構造化データ、sitemap、表示速度)、コンテンツSEO(検索意図と内部リンク)、そして近年効いてきたAIO(AIに引用される構造)。深掘りが必要なテーマは、関連記事へリンクしてつなぎます。
この記事の要点
- SEOは「順位の小技」ではなく、検索エンジンとAIにページを理解させる配線。まず技術面の土台を直すと効きが速い。
- 技術的SEOの優先順位は、**①インデックス可否(robots/canonical/sitemap)→②構造化データJSON-LD→③Core Web Vitals(LCP 2.5秒/INP 200ms/CLS 0.1)**の順。
- コンテンツSEOの核は検索意図に答えることと、内部リンクで関連記事を束ねるトピッククラスタ。
- AIO(AI回答エンジン最適化)は結論先出し・FAQ・明確な見出しが効く。この記事自体がその構造で書いてある。
- 記事末尾に、JSON-LDのコピペで動く最小コードと、公開前チェックリストを置いた。
SEOは順位の小技ではなく「配線」である
最初に言葉の整理をします。SEOは大きく2つに分かれます。
技術的SEOは、検索エンジンがページを見つけて読むための配線です。クロール(巡回)、インデックス(登録)、構造化データ、表示速度、モバイル対応。地味ですが、ここが切れていると評価の土俵に上がれません。コンテンツSEOは、検索した人の疑問に正面から答える中身づくり。検索意図、本文の有用性、内部リンク。
たとえるなら、技術的SEOはお店の電気とドアの鍵と看板です。どんなに料理がうまくても、看板が消えていて鍵が閉まっていたら、客は入れません。コンテンツSEOは料理そのもの。両方そろって初めて、お客さんが来て、また来てくれます。
そして今は3つ目の軸が加わりました。**AIO(AI Optimization、AI回答エンジン最適化)**です。ChatGPTやGoogleのAI概要が、検索結果の手前で答えを出すようになった。ここに引用されるかどうかで、流入が変わり始めています。これは別物の新技術というより、機械が読みやすい構造を徹底することで、技術的SEOの延長線上にあります。
僕は長いあいだコンテンツSEOばかり磨いていました。でも冒頭のとおり、配線が切れていたら全部むだになる。順番が逆だったんです。
技術的SEO:まずインデックスの配線を直す
検索結果に出ない記事は、たいてい中身ではなく配線で詰まっています。優先して確認するのは次の5つです。
| 確認項目 | 何を見るか | よくある事故 |
|---|---|---|
| robots | クロールを止めていないか | robots.txt で /blog/ を Disallow したまま |
| noindex | metaやヘッダで除外していないか | テンプレート全ページに noindex が残存 |
| canonical | 正規URLが自分を指しているか | 全記事のcanonicalがトップを指していた |
| sitemap | URLが載って送信済みか | 生成されているが Search Console 未送信 |
| 内部リンク | どこからか辿れるか | 孤立記事(どこからもリンクされない) |
canonical(正規URL)は、同じ内容が複数URLで見えるとき、検索エンジンに「これが代表」と教えるタグです。ここが他ページを指していると、自分の記事が評価されません。
sitemapは詰まりやすいので関連記事に切り出しました。毎ビルドで全記事の更新日を「今日」にしてしまい、かえって順位を落とした失敗談は サイトマップを毎ビルド今日付にして順位を落とした話 にまとめています。lastmod を実際の更新日にそろえるのが地味に大事です。
クロールの範囲を自動化ツールに任せるとき、robots.txt や本番設定を勝手に書き換えられると事故になります。どこまで触らせるかを先に決める考え方は Claude Code 権限監査チェックリスト が近いので、運用に組み込むなら合わせて読んでください。
技術的SEO:構造化データJSON-LDを実装する
構造化データは、検索エンジンに「これは記事で、著者はこの人、公開日はこの日」と機械が読める形で伝える補足情報です。書き方の主流は JSON-LD。HTMLの見た目を変えず、<script type="application/ld+json"> で埋め込みます。
Googleの公式ドキュメントによると、記事の型は Article / NewsArticle / BlogPosting の3つが使えます。ブログ記事なら BlogPosting が素直です。必須プロパティは実はありません。当てはまる推奨プロパティをできるだけ入れるのが方針で、Googleが名前を挙げているのは headline、author(name と url)、datePublished、dateModified、image です。詳しくは Google検索セントラルのArticle構造化データ を一次情報として確認してください。
下が、そのままページに貼れる最小のJSON-LDです。値を自分の記事に書き換えれば動きます。
<!-- 記事ページの <head> 内に貼る。値だけ自分の記事に差し替える -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "技術的SEOとAIO最適化のハブ",
"description": "title/meta、構造化データ、Core Web Vitals、内部リンク、AIO対策の土台。",
"image": "https://claudecodelab.com/images/hero/hero-043.png",
"datePublished": "2026-03-25",
"dateModified": "2026-06-07",
"author": {
"@type": "Person",
"name": "Masa",
"url": "https://claudecodelab.com/about/"
},
"publisher": {
"@type": "Organization",
"name": "ClaudeCodeLab"
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://claudecodelab.com/blog/claude-code-seo-optimization/"
}
}
</script>
実際に静的サイトに組み込むときは、frontmatterの値から自動生成すると保守がラクです。AstroやNext.jsなら、記事データを受け取ってこのオブジェクトを組み立てるコンポーネントを1つ用意すれば、全記事に展開できます。
// JSON-LD(BlogPosting)を frontmatter から組み立てる小さな関数
// 戻り値を JSON.stringify して <script type="application/ld+json"> に流す
type ArticleMeta = {
title: string;
description: string;
heroImage: string;
pubDate: string; // "2026-03-25"
updatedDate: string; // "2026-06-07"
slug: string;
};
const SITE = "https://claudecodelab.com";
export function buildBlogPostingJsonLd(a: ArticleMeta) {
return {
"@context": "https://schema.org",
"@type": "BlogPosting",
headline: a.title.slice(0, 110), // headlineは長すぎると無視されやすい
description: a.description,
image: a.heroImage.startsWith("http") ? a.heroImage : `${SITE}${a.heroImage}`,
datePublished: a.pubDate,
dateModified: a.updatedDate || a.pubDate,
author: { "@type": "Person", name: "Masa", url: `${SITE}/about/` },
publisher: { "@type": "Organization", name: "ClaudeCodeLab" },
mainEntityOfPage: {
"@type": "WebPage",
"@id": `${SITE}/blog/${a.slug}/`,
},
};
}
注意点を2つ。1つは、構造化データの内容と本文を一致させること。本文に書いていない著者や日付を構造化データだけに書くと、ガイドライン違反になります。もう1つは、dateModified と記事の表示上の更新日をそろえること。ここがずれていると、更新したのに古い日付で見られます。書いたら リッチリザルトテスト で構文を確認すると安心です。
技術的SEO:Core Web Vitalsで体感速度を測る
表示速度は、SEOであると同時に、読者がページを閉じるかどうかの分かれ目です。Googleはこれを Core Web Vitals という3つの指標で測ります。2025〜2026年時点の「良好」の目安はこうです。
| 指標 | 何を測るか | 良好の目安 |
|---|---|---|
| LCP(Largest Contentful Paint) | 主要コンテンツが表示されるまで | 2.5秒以内 |
| INP(Interaction to Next Paint) | クリック等の反応の速さ | 200ミリ秒以内 |
| CLS(Cumulative Layout Shift) | レイアウトのガタつき | 0.1以下 |
INPは、かつての FID(First Input Delay)に代わって2024年から正式指標になりました。古い記事で「FIDを改善」と書いてあったら、もうINPの時代だと思ってください。これらは75パーセンタイル(実ユーザーの遅いほうから数えて上位25%を切ったライン)で評価されます。一次情報は web.devのCore Web Vitals解説 が分かりやすいです。
ありがちなのは「全部100点を目指す」迷子です。そうではなく、読者体験を壊している原因から直します。僕の場合、LCPの犯人はだいたいヒーロー画像でした。4MBのPNGをWebPにして遅延読み込みを整えたら、LCPが目に見えて縮みました。手順は Claude Codeで画像最適化を自動化 にまとめています。
CLS(レイアウトのガタつき)の地味な犯人がWebフォントでした。フォント読み込み中に本文がチラついて、読み始めた行が下にずれる。font-display とサブセット化で止めた話は Webフォントで本文がチラつく問題を止める にあります。
計測そのものの考え方、つまり「スコアを追う前に何を測るか」は Claude Codeでパフォーマンス最適化:計測からCore Web Vitals改善まで が母艦記事です。速度で迷ったらここから入るのがおすすめです。
コンテンツSEO:検索意図に答え、内部リンクで束ねる
配線が通ったら、ようやく中身です。コンテンツSEOの核は2つだけ。検索意図に正面から答えることと、関連記事を内部リンクで束ねることです。
検索意図とは、読者が検索窓に言葉を入れた背景です。「構造化データ JSON-LD 実装」と打った人は、定義の説明ではなく、貼って動くコードを探しています。だからこの記事は、定義を3行で済ませて、すぐ実装に入りました。意図を外すと、どれだけ長く書いても刺さりません。
そして内部リンクです。1本の記事で全部を語ろうとすると、薄く長くなって誰にも刺さりません。代わりに、中心となるハブ記事(この記事)から、各テーマの深掘り記事へリンクを張る。これをトピッククラスタと呼びます。SEO・速度・画像・フォント・sitemapが、1つのまとまりとしてGoogleに伝わります。
| 役割 | この記事から張るリンク |
|---|---|
| ハブ | この記事(技術的SEO + コンテンツSEO + AIO) |
| 深掘り(速度) | パフォーマンス最適化 / 画像最適化 / font-optimization |
| 深掘り(クロール) | sitemap生成 / 権限監査 |
| 運用 | 毎日公開チェックリスト / コンテンツ導線監査 |
内部リンクの落とし穴は、関連だからと機械的に並べることです。クリックされません。リンクの前に「なぜ次に読むのか」を一文添えると、読者にも検索エンジンにも関係が伝わります。公開を運用に乗せたい人は Claude Codeで毎日1本公開するための高品質記事チェックリスト を、流入を売上につなげたい人は Claude Codeでコンテンツ導線を監査する を合わせて読むと、点が線になります。
AIO:AI回答エンジンに引用される構造を作る
ここ最近いちばん変化を感じるのがAIOです。検索結果の手前で、AIが答えをまとめてしまう。そこに自分の記事が引用されれば、上位表示と同じかそれ以上の価値があります。
では何が効くのか。試した範囲で、はっきり効果を感じたのは3つです。
- 結論を先に書く。記事冒頭に「この記事の要点」を箇条書きで置く。AIは結論部分を拾って要約に使います。この記事のTL;DRがまさにそれです。
- FAQを置く。読者が実際に検索する疑問を、1問1答で簡潔に。AIは質問と答えのペアを引用しやすい。後ろに「よくある質問」を用意したのもこのためです。
- 見出しを具体的にする。「SEOとは」より「構造化データJSON-LDを実装する」。見出しだけ拾えば内容が分かる状態が、機械にやさしい。
要するに、AIO対策の多くは人間にとっても読みやすい構造と重なります。小細工ではなく、結論先出し・FAQ・明確な見出しという基本の徹底。これが結果的にAIにも届く、というのが今の手応えです。
僕がやらかしたSEOの失敗3つ
正直に書きます。土台を軽視していた頃の失敗です。
ひとつ目は、canonicalの一括ミス。テンプレートを直したとき、全記事のcanonicalがトップページを指す状態になっていました。Googleから見れば「この200記事は全部トップの複製」。しばらく新記事が伸びず、原因に気づくまで2週間溶かしました。
ふたつ目は、slugを気軽に変えたこと。語感が悪いからとURLを変えたら、過去の内部リンク・外部リンク・SNSシェア・検索評価が全部分断されました。リダイレクトとcanonicalをセットで張るのを忘れて、しばらく流入が消えました。URLは住所です。引っ越すなら転送届を出す。
みっつ目は、PVだけ見て満足したこと。表示回数は増えたのに、誰も次の行動に進まない。無料PDFにも教材にも相談にも行かない。検索流入が事業の入口で止まっていました。それ以来、Search Consoleの数字の隣に「次の行動に進んだか」を必ず並べて見ています。
よくある質問
Q. SEOで最初に手をつけるべきは何ですか? A. 中身より先に、インデックスの配線です。robots、noindex、canonical、sitemap、孤立記事。ここが切れていると、良い記事も評価されません。次に構造化データ、次にCore Web Vitalsの順がおすすめです。
Q. 構造化データは全ページに必要ですか? A. 記事ページにはBlogPosting(またはArticle)を入れる価値があります。必須プロパティはありませんが、headline・author・datePublished・dateModified・imageは入れておくと、検索結果での見え方が安定します。本文と矛盾する値は書かないこと。
Q. Core Web Vitalsは全部100点にすべき? A. 不要です。75パーセンタイルで「良好」の範囲(LCP 2.5秒・INP 200ms・CLS 0.1)に入れば十分。満点より、体感を壊している原因(重い画像、チラつくフォント、無駄なJS)を先に直すほうが効きます。
Q. AIO対策とSEO対策は別物ですか? A. ほぼ地続きです。結論先出し、FAQ、具体的な見出し、構造化データ。AIに引用されやすい形は、人間にも読みやすい形とほぼ一致します。新しい小細工を覚えるより、基本を徹底するのが近道です。
Q. 記事を更新したら順位は上がりますか? A. 更新すれば上がるわけではありません。検索意図に合わせて不足を補い、dateModifiedと表示上の更新日をそろえ、内部リンクを足す。その実体が伴って初めて再評価されます。日付だけ今日に変える運用は逆効果になり得ます。
実際に試した結果
冒頭の「インデックスされない記事」は、結局すべて配線の問題でした。canonicalを自分自身に直し、sitemapのlastmodを実際の更新日にそろえ、JSON-LDを全記事に展開する。この3つを片づけた数週間後、止まっていた記事がインデックスに入り、検索表示が動き始めました。
順番として効いたのは、文章を増やすことではなく、機械に伝える配線を先に通すことでした。そのうえで検索意図に答え、内部リンクでハブとして束ね、結論先出しとFAQでAIにも届く形に整える。派手さはありませんが、ここが土台です。
この土台ができたら、次は流入を売上につなげる段階です。読者の状態に合わせて 無料PDF で日々の使い方を持ち帰ってもらい、手を動かしたい人には 教材一覧、チームで導入したい人には Claude Code導入相談 を案内する。SEOのゴールは順位ではなく、読者が次の一歩に迷わない状態だと、今は考えています。
無料PDF: Claude Code はじめてのチートシート
まずは無料PDFで基本コマンドと最初の使い方をまとめて確認してください。登録後はそのままテンプレート集や導入相談にも進めます。
スパムは送りません。登録情報は厳重に管理します。
Claude Codeを仕事で使える形にしませんか?
まず無料PDFで基本を固め、繰り返し使う作業はGumroad教材へ、チーム導入や権限設計は導入相談へ進めます。
この記事を書いた人
Masa
Claude Codeの実務活用、導入設計、収益導線改善を検証しているエンジニア。10言語の技術メディアを運営中。
関連書籍・参考図書
この記事のテーマに関連する書籍を楽天ブックスで探せます。
※ 当サイトは楽天市場のアフィリエイトプログラムに参加しています。上記リンクから商品をご購入いただくと、運営者に紹介料が支払われる場合があります。
関連記事
Claude Codeに1ファイルだけ直させる指示文のつくり方
「もっと良くして」で40行も変えられた失敗から学んだ、触る範囲・検証・戻し方をセットにしたClaude Code用の依頼文テンプレートを紹介します。
Claude Code の権限拒否から復旧する: 止まった理由を次の安全手順に変える
Claude Code のコマンドが拒否されたとき、焦って許可を広げずに、拒否理由、代替手順、証拠コマンド、再試行条件へ分解する方法。
Claude Codeにビルド→スモークテスト→自動修正を回させる足場の作り方
最小スモークテストの選び方、失敗ログを食わせて直させるループ、回数上限と確認ゲートで暴走を止める方法を、コピペで動くコード付きで紹介します。