法律事務所のスキーママークアップ:完全JSON-LDガイド(2026)
ここ数年、数十の法律事務所ウェブサイトにスキーママークアップを実装してきましたが、パターンはいつも同じです。事務所の開発者(あるいはそれ以上に悪い「SEO担当者」)は何もしていないか、自動生成されたYoastスキーマを適用しているだけで、表面をかすめているだけです。一方、通りの向かい側の競合事務所はFAQリッチリザルトやナレッジパネルデータを得ており、AI検索ツールに引用されています。すべては適切なJSON-LDを書く時間をかけたからです。
このガイドは、私が始めたころに存在していたらよかったと思う内容です。法律事務所にとって重要なすべてのスキーマタイプ(LegalService、Attorney、FAQPage、Organization、およびそれらがどのように結合するか)をカバーします。本番環境に対応したJSON-LDを提供しており、今日から適応および展開できます。
目次
- 2026年における法律事務所のスキーママークアップが重要な理由
- JSON-LD対マイクロデータ:正しい形式を選択
- LegalServiceスキーマ:基礎
- PersonマークアップのAttorneyスキーマ
- 実務分野用FAQPageスキーマ
- Organizationスキーマすべてを統合
- 接続されたスキーマグラフの構築
- テンプレート内のJSON-LD配置場所
- 検証とテスト
- リッチリザルトを破壊する一般的なミス
- FAQ

2026年における法律事務所のスキーママークアップが重要な理由
はっきり言いましょう。スキーママークアップだけでサイトのランクを上げることはありません。従来の意味でのランキング要因ではありません。しかし、時間とともに加算される3つのことを行います。
SERP内のリッチリザルト。 FAQドロップダウン、星評価、事業詳細など、これらはより多くの画面不動産を占有し、クリックスルーレートを向上させます。2025年のMilestone Research調査のデータによると、構造化データを使用したページは、使用していないページよりも40~50%高いCTRを得られました。
AI検索引用。 Google AI Overviews、Bing Copilot、Perplexity、ChatGPT検索はすべて構造化データを解析してエンティティを理解します。誰かが「オースティンの最高の個人損害賠償弁護士」と尋ねたときに事務所が引用されるようにしたい場合、スキーマはこれらのシステムがあなたが誰であるか、何をするか、どこにいるかを理解するのに役立ちます。
ナレッジパネルの適格性。 Googleのナレッジグラフはスキーマからのデータを重く取得します。一貫した
sameAsリンクを持つ適切にマークアップされた法律事務所は、ブランド化されたナレッジパネルをトリガーする可能性がはるかに高くなります。
法律事務所の場合、利害関係は高いです。法律キーワードは有料検索で最も高価なものです(競争的な実務分野では$50~150以上クリック当たり)。有機的な可視性を改善するためにできることは、エンジニアリング時間の価値があります。
JSON-LD対マイクロデータ:正しい形式を選択
短い答え:JSON-LDを使用してください。常に。
Googleは明示的にJSON-LDを推奨しています。メンテナンスが簡単で、HTMLマークアップを汚さず、<script>タグ経由で動的に挿入できます。マイクロデータでは、HTMLエレメントに直接属性を追加する必要があり、特にSanity、Contentful、StoryblokなどのヘッドレスCMSを使用している場合(コンテンツとプレゼンテーションが分離されている場合)、すぐに面倒になります。
| 特徴 | JSON-LD | マイクロデータ | RDFa |
|---|---|---|---|
| Google推奨 | ✅ はい | ⚠️ サポート対象 | ⚠️ サポート対象 |
| HTMLから分離 | ✅ はい | ❌ いいえ | ❌ いいえ |
| メンテナンスが簡単 | ✅ はい | ❌ 複雑 | ❌ 複雑 |
| ヘッドレスCMSで動作 | ✅ 完璧 | ⚠️ 可能 | ⚠️ 可能 |
| AI検索互換性 | ✅ 優秀 | ✅ 良好 | ✅ 良好 |
| 動的挿入 | ✅ 簡単 | ❌ DOMの変更が必要 | ❌ DOMの変更が必要 |
Next.jsやAstroで構築している場合(Social Animalでもこれらを多く行っています。Next.js開発とAstro開発の機能を参照してください)、JSON-LDは特に詳細です。JavaScriptオブジェクトとして生成して、<head>の<script type="application/ld+json">タグに挿入します。
LegalServiceスキーマ:基礎
LegalServiceは法律事務所と法律業務のために特別に設計されたschema.orgタイプです。LocalBusinessのサブタイプであり、すべてのローカルビジネスプロパティ(住所、電話、営業時間)を継承し、法律固有の詳細を指定できます。
ここに本番対応の例があります。
{
"@context": "https://schema.org",
"@type": "LegalService",
"@id": "https://www.smithlawfirm.com/#organization",
"name": "Smith & Associates Law Firm",
"alternateName": "Smith Law",
"url": "https://www.smithlawfirm.com",
"logo": {
"@type": "ImageObject",
"url": "https://www.smithlawfirm.com/images/logo.png",
"width": 600,
"height": 200
},
"image": "https://www.smithlawfirm.com/images/office-exterior.jpg",
"description": "Smith & Associates provides personal injury, family law, and estate planning legal services in Austin, Texas.",
"telephone": "+1-512-555-0199",
"email": "contact@smithlawfirm.com",
"address": {
"@type": "PostalAddress",
"streetAddress": "456 Congress Avenue, Suite 300",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78701",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 30.2672,
"longitude": -97.7431
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "18:00"
}
],
"priceRange": "$$",
"areaServed": {
"@type": "City",
"name": "Austin",
"sameAs": "https://en.wikipedia.org/wiki/Austin,_Texas"
},
"hasOfferCatalog": {
"@type": "OfferCatalog",
"name": "Legal Services",
"itemListElement": [
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Personal Injury Representation",
"description": "Legal representation for car accidents, slip and fall, and workplace injuries."
}
},
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Family Law",
"description": "Divorce, child custody, and prenuptial agreement services."
}
}
]
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"reviewCount": "127",
"bestRating": "5"
},
"sameAs": [
"https://www.facebook.com/SmithLawAustin",
"https://www.linkedin.com/company/smith-law-austin",
"https://www.avvo.com/attorneys/smith-associates.html"
]
}
スキップすべきでない主なプロパティ
@id:これはスキーマを一緒に接続するために重要です。他のスキーマブロックが参照できる一意の識別子と考えてください。geo:Googleはこれをローカルパック検索結果に使用します。スキップしないでください。areaServed:複数の都市または郡にサービスを提供する場合、それらすべてをリストしてください。半径ベースのサービスエリアにはGeoCircleを使用します。hasOfferCatalog:これは実務分野をサービスとして列挙する方法です。各実務分野ページには、理想的には独自のServiceスキーマも含まれています。sameAs:Avvo、Justia、FindLaw、LinkedIn、Facebook(権威あるプロフィール)を含めます。これはナレッジパネルのGoogleの接続を支援します。aggregateRating:正当なファーストパーティレビューから引き出している場合にのみ含めます。Googleのガイドラインはここで厳しいです。評価を作成しないでください。

PersonマークアップのAttorneyスキーマ
事務所の各弁護士は、バイオページにPersonスキーマを持つべきです。ここでE-E-A-Tが本当に活躍します。検索エンジンに資格、弁護士資格、教育、および専門知識を明示的に伝えています。
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://www.smithlawfirm.com/attorneys/jane-smith/#person",
"name": "Jane Smith",
"jobTitle": "Managing Partner",
"url": "https://www.smithlawfirm.com/attorneys/jane-smith",
"image": "https://www.smithlawfirm.com/images/attorneys/jane-smith.jpg",
"description": "Jane Smith is a personal injury attorney in Austin, TX with over 15 years of experience and a track record of $50M+ in settlements.",
"telephone": "+1-512-555-0200",
"email": "jane@smithlawfirm.com",
"worksFor": {
"@id": "https://www.smithlawfirm.com/#organization"
},
"alumniOf": [
{
"@type": "CollegeOrUniversity",
"name": "University of Texas School of Law",
"sameAs": "https://law.utexas.edu"
}
],
"hasCredential": [
{
"@type": "EducationalOccupationalCredential",
"credentialCategory": "Bar Admission",
"recognizedBy": {
"@type": "Organization",
"name": "State Bar of Texas"
}
}
],
"knowsAbout": [
"Personal Injury Law",
"Car Accident Claims",
"Wrongful Death",
"Premises Liability"
],
"sameAs": [
"https://www.linkedin.com/in/janesmith-attorney",
"https://www.avvo.com/attorneys/jane-smith.html",
"https://www.martindale.com/jane-smith"
]
}
`worksFor`参照が重要な理由
worksForプロパティに注目してください。LegalServiceスキーマからの@idを使用します。これがグラフを接続する方法です。Googleはジェーン・スミスがスミス・アンド・アソシエーツで働いており、それがオースティンの法律サービスプロバイダーであることを理解します。これらの接続は両方のエンティティを強化します。
hasCredentialプロパティは比較的新しいですが、ますます重要になっています。弁護士資格、専門資格、Super Lawyers指定。それらすべてをマークアップしてください。AI検索システムはこの種の検証可能な認証情報データを好みます。
実務分野用FAQPageスキーマ
FAQスキーマは波乱万丈の歴史を持っています。Googleは2023年8月にFAQリッチリザルトの可視性を削減し、主に権威のある政府および健康サイトに限定しました。しかし、ここに本当のところがあります。FAQPageスキーマは2026年でも2つの理由で重要です。
- AI検索解析。 LLMは答えを生成する際にFAQの構造化データを積極的に消費します。PerplexityとGoogle AI Overviewsはどちらもキャプションタイプコンテンツを引用します。
- **Bingおよび他のエンジンBingは、GoogleよりもリベラルにはまだFAQリッチリザルトを表示します。
各実務分野ページについては、関連するFAQセクションと一致するスキーマを持つべきです。
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How much does a personal injury lawyer cost in Austin?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Most personal injury attorneys in Austin work on a contingency fee basis, meaning you pay nothing upfront. The standard contingency fee ranges from 33% to 40% of the settlement or verdict amount. If you don't win, you don't pay attorney fees."
}
},
{
"@type": "Question",
"name": "What is the statute of limitations for personal injury in Texas?",
"acceptedAnswer": {
"@type": "Answer",
"text": "In Texas, you generally have two years from the date of the injury to file a personal injury lawsuit. There are exceptions for minors, government entities, and cases where the injury wasn't immediately discovered. Consulting an attorney promptly is critical to preserve your rights."
}
},
{
"@type": "Question",
"name": "How long does a personal injury case take to settle?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Most personal injury cases in Texas settle within 6 to 18 months. Simpler cases like fender-benders with clear liability may resolve in a few months. Complex cases involving catastrophic injuries or disputed fault can take 2-3 years or longer if they go to trial."
}
}
]
}
重大なFAQPageルール
- コンテンツはページに表示される必要があります。 Googleのガイドラインは明確です。FAQマークアップは、ページ上の表示されるコンテンツと一致する必要があります。JSON-LDにのみ存在する質問のためにFAQスキーマを追加しないでください。
- 回答は簡潔にしてください。 回答あたり2~3文が最高のパフォーマンスを発揮します。複雑なことを説明する必要がある場合は、専用ページにリンクしてください。
- 実際の質問を使用してください。 Google Search Console のクエリデータ、「人々はまた尋ねます」ボックス、および実際のクライアントインテーク会話から引き出します。誰も尋ねない質問を作成しないでください。
- ページあたり5~10に制限してください。 それ以上だと関連性を薄めています。
Organizationスキーマすべてを統合
事務所に複数のオフィスがある場合、ホームページに親エンティティとして機能するOrganizationスキーマが必要になり、各拠点に個別のLegalServiceスキーマが必要です。
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.smithlawfirm.com/#organization",
"name": "Smith & Associates Law Firm",
"url": "https://www.smithlawfirm.com",
"logo": "https://www.smithlawfirm.com/images/logo.png",
"foundingDate": "2008",
"founder": {
"@id": "https://www.smithlawfirm.com/attorneys/jane-smith/#person"
},
"numberOfEmployees": {
"@type": "QuantitativeValue",
"value": 25
},
"subOrganization": [
{
"@type": "LegalService",
"name": "Smith & Associates - Austin Office",
"url": "https://www.smithlawfirm.com/locations/austin"
},
{
"@type": "LegalService",
"name": "Smith & Associates - San Antonio Office",
"url": "https://www.smithlawfirm.com/locations/san-antonio"
}
],
"sameAs": [
"https://www.facebook.com/SmithLawAustin",
"https://www.linkedin.com/company/smith-law-austin",
"https://twitter.com/SmithLawATX"
]
}
接続されたスキーマグラフの構築
ここで、ほとんどの法律事務所ウェブサイトが失敗します。彼らは接続されていないスキーマのブロブを持っています。ここにLocalBusinessの少し、そこにPersonの少し。しかし、何も一緒にリンクしていません。Googleのドキュメントは「エンティティの調整」について説明しています。これは基本的にこれらのデータのすべての部分が同じ現実世界のエンティティを指すことをどのように理解するかです。
@idプロパティはそのためのツールです。グラフがどのように接続するかは次のとおりです。
| ページ | スキーマタイプ | 参照 |
|---|---|---|
| ホームページ | Organization + WebSite |
組織の@id |
| ロケーションページ | LegalService |
parentOrganization → 組織@id |
| 弁護士バイオ | Person |
worksFor → 組織@id |
| 実務分野ページ | Service + FAQPage |
provider → 組織@id |
| ブログ記事 | Article |
author → 人の@id、publisher → 組織@id |
| お問い合わせページ | ContactPoint |
組織またはLegalServiceにネストされています |
実務分野ページがどのようにリンク戻るかの簡単な例を以下に示します。
{
"@context": "https://schema.org",
"@type": "Service",
"name": "Personal Injury Representation",
"serviceType": "Personal Injury Law",
"provider": {
"@id": "https://www.smithlawfirm.com/#organization"
},
"areaServed": {
"@type": "State",
"name": "Texas"
},
"description": "Legal representation for car accidents, truck accidents, workplace injuries, and wrongful death claims throughout Texas.",
"hasOfferCatalog": {
"@type": "OfferCatalog",
"name": "Personal Injury Services",
"itemListElement": [
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Car Accident Claims"
}
},
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Truck Accident Claims"
}
}
]
}
}
テンプレート内のJSON-LD配置場所
JSON-LDは<script type="application/ld+json">タグに入ります。<head>またはの直前に配置できます。</body>閉じるタグ。Googleは配置について気にしていませんが、組織の正気のために<head>を好みます。
ヘッドレスCMSとNext.jsやAstroなどのフレームワークで作業している場合は、CMS データから動的にスキーマを生成する必要があります。次に、簡略化されたNext.jsの例があります。
// components/LegalServiceSchema.tsx
export function LegalServiceSchema({ firm }) {
const schema = {
"@context": "https://schema.org",
"@type": "LegalService",
"@id": `${firm.url}/#organization`,
"name": firm.name,
"url": firm.url,
"telephone": firm.phone,
"address": {
"@type": "PostalAddress",
"streetAddress": firm.address.street,
"addressLocality": firm.address.city,
"addressRegion": firm.address.state,
"postalCode": firm.address.zip,
"addressCountry": "US"
}
};
return (
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
/>
);
}
このパターンは、コンテンツがヘッドレスCMSに存在する場合に美しく機能します。スキーマは自動的にデータと同期されます。電話番号が変わるときに手動で更新する必要はありません。このアプローチに興味がある場合、ヘッドレスCMS開発の仕事を通じて定期的にこの種のシステムを構築しています。
検証とテスト
ライブにプッシュする前に、テストしてください。毎回。実際に使用するツールは以下のとおりです。
| ツール | URL | 実行内容 |
|---|---|---|
| Google リッチリザルトテスト | search.google.com/test/rich-results | ページが適格なリッチリザルト表示 |
| スキーママークアップバリデーター | validator.schema.org | スキーマに対して検証します。org spec(Googleより厳密) |
| Google Search Console | search.google.com/search-console | デプロイ後のエラーと警告を表示 |
| Merkle Schema Markup Generator | technicalseo.com/tools/schema-markup-generator | 初期マークアップ生成に適しています |
私のワークフロー
- JSON-LDを手動で書くか、CMSデータから生成します
- 最初にschema.orgバリデーターで検証します(構造的な問題を検出)
- Google Rich Results Testでテストします(Googleが解析することを確認)
- デプロイして、2~4週間Search Consoleの「拡張機能」レポートを監視します
site:yourdomain.com検索を使用してSERPで実際にリッチリザルトが表示されているかを確認します
リッチリザルトを破壊する一般的なミス
十分な数の法律事務所スキーマをデバッグしてきたので、ミスのグレーテストヒットリストを持っています。
不可視マークアップ。 FAQスキーマを追加しますが、質問と回答はページに表示されていません。Googleは明示的に、構造化データはページ上の表示されるコンテンツを反映する必要があると述べています。これを違反すると、手動操作のリスクがあります。
偽のまたは自己発行されたレビュー。 Google Business Profile、Avvo、または別のサードパーティから引き出されていない、自分のウェブサイトにのみ存在するレビューを使用してAggregateRatingを追加します。これはGoogleのレビュースニペットガイドラインに違反しています。2024年に彼らは非常にハードにクラックダウンしており、それは緩まっていません。
プラグインからの重複スキーマ。 YoastやRank Mathをインストールします。これは自動的にOrganizationスキーマを生成します。その後、あなた(または開発者)もカスタムJSON-LDを追加します。これでGoogleは2つの矛盾するOrganizationブロックを見ています。真実の1つのソースを選択します。
@id参照がない。 @idプロパティがなければ、スキーマブロックは島です。Googleは弁護士を事務所に接続したり、サービスを場所に接続したりすることはできません。常に@idを使用し、関連スキーマで{"@id": ".."}を使用して参照します。
古いデータ。 事務所は6ヶ月前に移動しましたが、スキーマはまだ古い住所を持っています。あるいは、弁護士が事務所を辞めましたが、その人のスキーマはまだライブです。スキーマをコードのように扱う。メンテナンスが必要です。
スキーマタイプとしてのAttorneyを使用しています。 これは一般的な混乱です。Schema.orgにAttorneyタイプはありません。@type: "Attorney"はありません。Personを「Attorney」のjobTitleと一緒に使用し、worksFor経由でLegalServiceに接続してください。一部のプラグインはこれを間違えます。
FAQ
すべての法律事務所ウェブサイトが持つべきスキーマタイプは何ですか?
最小限でも、ホームページにLegalService(またはOrganizationとLegalServiceサブタイプで)、各弁護士バイオページにPerson、実務分野ページにFAQPageが必要です。ブログコンテンツを公開する場合、適切なauthor参照を持つArticleスキーマを追加してください。複数の場所の事務所の場合、各事務所は独自のLegalServiceブロックを場所固有の詳細で必要とします。
FAQPageスキーマは2026年でもリッチリザルトで機能していますか?
Googleは2023年8月にFAQリッチリザルトの可視性を大幅に削減し、主に政府および健康当局のサイトでそれらを表示しています。ただし、FAQスキーマは、Google AI Overviews、Bing Copilot、Perplexityなどのアクティブに、FAQスキーマが活発に解析されるAI検索システムにとって依然として価値があります。答えを生成するときにFAQの構造化データをパースします。実装する価値はあります。
弁護士のために具体的に指定されたスキーマタイプはありますか?
いいえ。Schema.orgはAttorneyタイプを定義しません。正しいアプローチは、「Attorney」または「Partner」に設定されたjobTitleなどのプロパティを持つPersonを使用することです。弁護士資格認定のためのhasCredential、worksFor参照を事務所のLegalServiceまたはOrganizationスキーマに使用することです。一部のSEOプラグインは不正にAttorneyを使用します。それらを避けるか、出力をオーバーライドしてください。
スキーママークアップで複数の実務分野を処理するにはどうすればよいですか?
各実務分野ページは、事務所の@idに戻るprovider参照を持つ独自のServiceスキーマを持つ必要があります。ホームページまたはメインサービスページで、OfferCatalogを使用して、各サービスをリストします。これにより、個別のページレベルの信号と事務所レベルの概要が両方作成されます。
スキーママークアップは私の法律事務所がGoogleのAI Overviewsに表示されるのを助けることができますか?
はい。GoogleのAI Overviewsおよびその他のAI検索ツールは、生成されたクエリのソースを選択するときに、構造化データをシグナルとして使用します。答え。適切に接続されたスキーマグラフ(LegalService、Person、FAQPage、適切なsameAsリンク付き)は、AI システムが事務所の権威、位置、特化を理解するのに役立ちます。これは唯一の要因ではありませんが、ますます重要になっています。
スキーマプラグインを使用するか、JSON-LDを手動で書くべきですか?
プラットフォームと技術的な快適さに依存します。WordPressの場合、Rank MathやSchema Proなどのプラグインは基本をハンドルできます。ただし、法律事務所の場合、デフォルトはまれに十分です。LegalService、弁護士資格情報、実務分野のサービスの出力をカスタマイズする必要があります。Next.jsまたはAstroを使用したヘッドレスCMSでは、CMSデータからプログラム的にJSON-LDを生成することが最もクリーンなアプローチです。ヘッドレスCMS開発サービスを通じて、これを設定するのを支援します。
スキーママークアップを展開してから結果を表示するまでどのくらい時間がかかりますか?
有効な構造化データを展開してから、Googleは通常2~4週間以内にそれを処理します。ただし、時間がかかる可能性があります。Google Search Consoleの「拡張機能」レポートで最初にスキーマが検出されます。リッチリザルト(適格な場合)は表示されるまで数週間かかることがあります。AI検索引用の改善はより測定しにくく、1~3か月で目立つようになる場合があります。
スキーママークアップとE-E-A-Tの関係は何ですか?
スキーママークアップは、E-E-A-T(Experience、Expertise、Authoritativeness、Trustworthiness)を検索エンジンに信号する最も直接的な方法の1つです。hasCredentialを含むPersonスキーマは専門知識を示しています。AggregateRatingとReviewスキーマは信頼性を信号します。権威的な法的ディレクトリへのsameAsリンクは権威を強化します。Googleの品質格付人ガイドラインはスキーマを明示的には言及していませんが、エンコードするデータは品質格付人が評価することに直接マップされます。