geo-schema

GEO スキーマと構造化データ

目的

構造化データは、エンティティが何であり、何を行い、他のエンティティとどのようにつながっているかを AI システムに伝える、主要な機械可読シグナルです。従来、スキーママークアップは Google のリッチリザルトを獲得するためのものでしたが、GEO における役割は根本的に異なります。構造化データは、AI モデルがエンティティを理解し、信頼するための手段です。構造化データで完全なエンティティグラフを構築すると、すべての AI 検索プラットフォームで引用される確率が大幅に高まります。

このスキルの使用方法

1. fetch_page.py を使用して対象ページの HTML を取得します（以下の注記を参照）。
2. 既存の構造化データ（JSON-LD、Microdata、RDFa）をすべて検出します。
3. 検出したスキーマを Schema.org の仕様に照らして検証します。
4. ビジネスタイプに基づき、不足している推奨スキーマを特定します。
5. すぐに使える JSON-LD コードブロックを生成します。
6. GEO-SCHEMA-REPORT.md を出力します。

---

Step 1: 検出

重要： WebFetch は HTML を Markdown に変換し、<head> の内容を削除するため、JSON-LD ブロックも取り除かれます。代わりに fetch_page.py を使用してください。

python3 ~/.claude/skills/geo/scripts/fetch_page.py <url> page

出力には、ページから解析されたすべての JSON-LD ブロックを含む structured_data 配列があります。

JSON-LD のスキャン

HTML 内の <script type="application/ld+json"> ブロックを探します。各ブロックを JSON として解析します。ページには複数の JSON-LD ブロックが含まれる場合があるため、すべて収集してください。

Microdata のスキャン

itemscope、itemtype、itemprop 属性を持つ要素を探します。ネストされた項目の階層をマッピングします。注：Microdata は JSON-LD よりも AI クローラーによる解析が困難です。Microdata だけが見つかった場合は、JSON-LD への移行を推奨してください。

RDFa のスキャン

typeof、property、vocab 属性を持つ要素を探します。Microdata と同様に、JSON-LD への移行を推奨してください。

優先順位

GEO では、JSON-LD が強く推奨される形式です。Google、Bing、AI プラットフォームはいずれも、JSON-LD を最も確実に処理します。サイトが Microdata または RDFa のみを使用している場合は、優先度の高い移行事項として指摘してください。

---

Step 2: 検証

検出した各スキーマブロックについて、以下を検証します。

1. 有効な JSON：JSON-LD の構文は正しいですか？末尾のカンマ、引用符で囲まれていないキー、不正な形式の文字列がないか確認します。
2. 有効な @type：@type は認識済みの Schema.org タイプと一致していますか？https://schema.org/docs/full.html と照合します。
3. 必須プロパティ：スキーマに、そのタイプの必須プロパティがすべて含まれていますか？（タイプごとの要件は以下を参照。）
4. 推奨プロパティ：AI からの発見可能性を高める推奨プロパティがスキーマに含まれていますか？
5. sameAs リンク：他のプラットフォーム上のプレゼンスにリンクする sameAs プロパティがスキーマに含まれていますか？
6. URL の有効性：スキーマ内のすべての URL にアクセスできますか（404 ではありませんか）？
7. ネスト：スキーマは適切にネストされていますか（例：Article 内の author、Organization 内の address）？
8. レンダリング方法：JSON-LD はサーバーでレンダリングされた HTML 内にありますか、それとも JavaScript 経由で挿入されていますか？Google の 2025 年 12 月のガイダンスによると、JavaScript で挿入された構造化データは処理が遅れる可能性があります。JavaScript の実行を必要とするスキーマがあれば指摘してください。

---

Step 3: GEO のスキーマタイプ

Organization（必須 — すべてのビジネスサイト）

すべての AI プラットフォームでのエンティティ認識に不可欠です。AI モデルがビジネスの内容を識別するために使用します。

必須プロパティ：

• @type："Organization"（または Corporation、LocalBusiness などのサブタイプ）
• name：正式なビジネス名
• url：公式ウェブサイトの URL
• logo：ロゴ画像の URL（ImageObject が推奨されます）

GEO で推奨されるプロパティ：

• sameAs：すべてのプラットフォームの URL の配列（以下の sameAs 戦略を参照）
• description：組織の説明（1～2 文）
• foundingDate：ISO 8601 形式の日付
• founder：Person スキーマ
• address：PostalAddress スキーマ
• contactPoint：電話番号、メールアドレス、contactType を含む ContactPoint
• areaServed：対象地域
• numberOfEmployees：QuantitativeValue
• industry：テキストまたは DefinedTerm
• award：受賞歴の配列
• knowsAbout：組織が専門とするトピックの配列（GEO に強いシグナル）

LocalBusiness（実店舗があるビジネス向け）

Organization を拡張します。ローカル AI 検索結果と Google Gemini に不可欠です。

追加の必須プロパティ：

• address：完全な PostalAddress
• telephone：電話番号
• openingHoursSpecification：営業時間

GEO で推奨されるプロパティ：

• geo：GeoCoordinates（緯度、経度）
• priceRange：価格帯の指標
• aggregateRating：AggregateRating スキーマ
• review：Review スキーマの配列
• hasMap：Google Maps の URL

Article + Author（出版社には必須）

Author スキーマは、AI プラットフォームにおいて最も強力な E-E-A-T シグナルの 1 つです。

Article の必須項目：

• @type："Article"（または NewsArticle、BlogPosting、TechArticle）
• headline：記事のタイトル
• datePublished：ISO 8601 形式
• dateModified：ISO 8601 形式（鮮度シグナルに不可欠）
• author：Person または Organization スキーマ
• publisher：ロゴを含む Organization スキーマ
• image：代表画像

GEO に必要な Author（Person）：

• name：氏名
• url：サイト上の著者ページ URL
• sameAs：LinkedIn、Twitter、個人サイト、Google Scholar、ORCID
• jobTitle：職業上の肩書き
• worksFor：Organization スキーマ
• knowsAbout：専門分野の配列
• alumniOf：出身教育機関
• award：専門分野での受賞歴

Product（E コマース向け）

必須：

• name、description、image
• offers：価格、priceCurrency、availability を含む Offer
• brand：Brand スキーマ
• sku または gtin／mpn

GEO で推奨されるプロパティ：

• aggregateRating：AggregateRating
• review：個別のレビューの配列
• category：製品カテゴリ
• material、weight、width、height（該当する場合）

FAQPage

2024 年時点の状況：Google は、FAQ のリッチリザルトを政府機関および医療関連サイトに限定しています。ただし、FAQPage スキーマは引き続き GEO に役立ちます。AI プラットフォームは、質問と回答を抽出するために FAQ の構造化データを解析します。リッチリザルトが表示されない場合でも、AI が読み取りやすくなるよう実装してください。

構造：

• @type："FAQPage"
• mainEntity：Question スキーマの配列。各要素には Answer スキーマを含む acceptedAnswer を設定します

SoftwareApplication（SaaS 向け）

必須：

• name、description
• applicationCategory：例："BusinessApplication"
• operatingSystem：対応プラットフォーム
• offers：価格

GEO で推奨されるプロパティ：

• aggregateRating：ユーザー評価
• featureList：機能の配列（引用に強いシグナル）
• screenshot：スクリーンショット
• softwareVersion：現在のバージョン
• releaseNotes：変更履歴へのリンク

WebSite + SearchAction（サイトリンク検索ボックス向け）

構造：

{
  "@type": "WebSite",
  "name": "Site Name",
  "url": "https://example.com",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://example.com/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}

Person（単独で使用 — 個人ブランド、著者、オピニオンリーダー向け）

About／Bio ページで単独のスキーマとして使用します。個人の専門性を示すエンティティグラフを構築できます。

必須： name、url GEO で推奨： sameAs、jobTitle、worksFor、knowsAbout、alumniOf、award、description、image

speakable プロパティ（音声／AI アシスタント向け）

speakable プロパティは、コンテンツの特定のセクションが音声や AI アシスタントでの利用に特に適していることを示します。Article または WebPage のスキーマに追加してください。

{
  "@type": "Article",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".article-summary", ".key-takeaway"]
  }
}

これにより、引用または読み上げに最適な文章がどれかを AI アシスタントに伝えられます。

---

ステップ 4：廃止・変更されたスキーマにフラグを立てる

スキーマ	ステータス	注記
HowTo	リッチリザルトは 2023 年 8 月に廃止	AI による解析には引き続き有用ですが、リッチリザルトは保証しないでください
FAQPage	2023 年 8 月より政府機関／医療機関に制限	AI による解析には引き続き有用です（上記を参照）
SpecialAnnouncement	2023 年に廃止	COVID 向けのスキーマでした。まだ存在する場合は削除してください
CourseInfo	2024 年の Course の更新により置き換え	更新された Course スキーマのプロパティを使用してください
VideoObject contentUrl	2024 年に動作が変更	ページの URL ではなく、実際の動画ファイルを指定する必要があります
Review スニペット	2024 年に適用が厳格化	商品ページの自己宣伝的なレビューは表示されない場合があります

廃止されたスキーマが見つかった場合はフラグを立て、代替案を推奨してください。

---

ステップ 5：sameAs 戦略（エンティティ認識にとって極めて重要）

sameAs プロパティは、GEO において最も重要な構造化データプロパティです。AI システムに「自分のウェブサイト上のこのエンティティは、他の場所にあるこれらのプロフィールと同一のエンティティです」と伝えます。これにより、AI プラットフォームが情報源を検証し、信頼して引用するために利用するエンティティグラフが作成されます。

推奨する sameAs リンク（優先順位順）

1. Wikipedia の記事 — 最も権威のあるエンティティリンク
2. Wikidata の項目 — 機械可読なエンティティ識別子（例：https://www.wikidata.org/wiki/Q12345）
3. LinkedIn — 会社ページまたは個人プロフィール
4. YouTube — チャンネル URL
5. Twitter/X — プロフィール URL
6. Facebook — ページ URL
7. Crunchbase — 会社プロフィール（スタートアップ／テック企業向け）
8. GitHub — 組織または個人のプロフィール（テック企業向け）
9. Google Scholar — 著者プロフィール（研究者／学術関係者向け）
10. ORCID — 研究者識別子（学術関係者向け）
11. Instagram — プロフィール URL
12. Apple App Store／Google Play — アプリの掲載ページ（ソフトウェア向け）
13. BBB — Better Business Bureau の掲載情報（米国企業向け）
14. 業界ディレクトリ — 関連する業界特化型ディレクトリ

sameAs の監査プロセス

1. エンティティに関する既知のウェブ上の情報をすべて収集します
2. 各 URL が正常に表示されること（404 やリダイレクトになっていないこと）を確認します
3. Organization／Person スキーマにすべての URL が含まれていることを確認します
4. 各プラットフォーム上の情報（名前、説明、設立日など）に一貫性があることを確認します
5. エンティティが存在すべきなのに存在していないプラットフォームにフラグを立てます

---

ステップ 6：JSON-LD の生成

検出したビジネスタイプに基づき、そのまま貼り付けて使える JSON-LD ブロックを生成します。必ず次のものを生成してください。

1. Organization または Person（エンティティタイプに応じて） — 常に生成
2. SearchAction を含む WebSite — ホームページ用に常に生成
3. ビジネスタイプに応じたスキーマ — 出版社には Article、EC サイトには Product、地域のビジネスには LocalBusiness、SaaS には SoftwareApplication
4. BreadcrumbList — ホームページより下層にあるページ向け

生成ルール

• 複数のスキーマを 1 つの JSON-LD ブロックに含めるには、@graph パターンを使用します
• すべての URL は絶対 URL（相対 URL ではないもの）にします
• スキーマ間の相互参照には @id プロパティを含めます
• すべての日付に ISO 8601 を使用します
• Article スキーマには、主要なコンテンツセクションを指す CSS セレクターを指定して speakable を含めます
• JSON-LD は <head> セクションに配置します。JavaScript 経由で挿入しないでください

テンプレート：GEO シグナルをすべて含む Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Company Name",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png",
    "width": 600,
    "height": 60
  },
  "description": "Concise description of what the company does.",
  "foundingDate": "2020-01-15",
  "founder": {
    "@type": "Person",
    "name": "Founder Name",
    "sameAs": "https://www.linkedin.com/in/founder"
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "City",
    "addressRegion": "State",
    "postalCode": "12345",
    "addressCountry": "US"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+1-555-555-5555",
    "contactType": "customer service",
    "email": "[email protected]"
  },
  "sameAs": [
    "https://en.wikipedia.org/wiki/Company_Name",
    "https://www.wikidata.org/wiki/Q12345",
    "https://www.linkedin.com/company/company-name",
    "https://www.youtube.com/@companyname",
    "https://twitter.com/companyname",
    "https://github.com/companyname",
    "https://www.crunchbase.com/organization/company-name"
  ],
  "knowsAbout": [
    "Topic 1",
    "Topic 2",
    "Topic 3"
  ]
}

---

スコアリング基準（0～100）

基準	点数	採点方法
Organization／Person スキーマが存在し、完全である	15	完全なら15点、基本的な内容なら10点、なければ0点
sameAs リンク（5つ以上のプラットフォーム）	15	有効な sameAs リンク1つにつき3点、最大15点
著者の詳細を含む Article スキーマ	10	著者スキーマが完全なら10点、名前のみなら5点、なければ0点
ビジネスタイプ固有のスキーマが存在する	10	完全なら10点、一部なら5点、なければ0点
WebSite + SearchAction	5	存在する場合は5点、存在しない場合は0点
内部ページに BreadcrumbList がある	5	存在する場合は5点、存在しない場合は0点
JSON-LD 形式（Microdata／RDFa ではない）	5	JSON-LD なら5点、混在している場合は3点、Microdata／RDFa のみの場合は0点
サーバー側でレンダリングされている（JS による挿入ではない）	10	HTML ソースに含まれていれば10点、JS で head 内にある場合は5点、動的な JS の場合は0点
記事に speakable プロパティがある	5	存在する場合は5点、存在しない場合は0点
有効な JSON + 有効な Schema.org タイプ	10	エラーがなければ10点、軽微な問題があれば5点、重大なエラーがあれば0点
Organization／Person に knowsAbout プロパティがある	5	3つ以上のトピックとともに存在する場合は5点、存在しない場合は0点
非推奨のスキーマがない	5	問題がなければ5点、非推奨のスキーマが見つかった場合は0点

---

出力形式

次を含む GEO-SCHEMA-REPORT.md を生成します。

# GEO Schema & Structured Data Report — [Domain]
Date: [Date]

## Schema Score: XX/100

## Detected Schemas
| Page | Schema Type | Format | Status | Issues |
|---|---|---|---|---|
| / | Organization | JSON-LD | Valid | Missing sameAs |
| /blog/post-1 | Article | JSON-LD | Valid | No author schema |

## Validation Results
[List each schema with pass/fail per property]

## Missing Recommended Schemas
[List schemas that should be present based on business type but are not]

## sameAs Audit
| Platform | URL | Status |
|---|---|---|
| Wikipedia | [URL or "Not found"] | Present/Missing |
| LinkedIn | [URL or "Not found"] | Present/Missing |
[Continue for all recommended platforms]

## Generated JSON-LD Code
[Ready-to-paste JSON-LD blocks for each missing or incomplete schema]

## Implementation Notes
- Where to place each JSON-LD block
- Server-rendering requirements
- Testing with Google Rich Results Test and Schema.org Validator