構造化データauthorの書き方｜LLMO観点で失敗しない書き方と著者情報の整え方

構造化データのauthorを設定したはずなのに、それが本当に検索エンジンやAI検索に「正しく」伝わっているか、確信を持てないまま公開している方は少なくありません。

実際にAIコマース研究所の支援現場でも、authorの構造化データ自体は実装済みでありながら、表示名とマークアップ上の名前が一致していない、プロフィールページへの導線が切れているといった不一致が見つかるケースは多いです。こうした細かなズレは、ChatGPTやPerplexity、Google AI Overviewsのような生成AI検索が著者を正しく認識する妨げになりやすい傾向があります。

本記事では、LLMO対策を専門支援するAIコマース研究所が、構造化データauthorの基本的な書き方に加えて、実装後に「表示名・Person・プロフィール・役割」の4項目が一致しているかを自分で確認できるチェック方法まで解説します。読み終える頃には、自社の著者情報がどこまで正しく機能しているか、次に何を直すべきかが判断できるようになります。

構造化データのauthorとは？記事の著者情報を検索エンジンとAI検索に伝える仕組み

構造化データのauthorとは、記事や投稿の執筆者情報を、検索エンジンや生成AIが機械的に読み取れる形式で記述するプロパティです。ページ上の見た目には表れない「裏側の情報」として、誰が書いた記事なのかをGoogleや生成AI検索に明示的に伝える役割を持ちます。

ページを訪れた読者はバイラインや著者情報ボックスといった見た目の情報から著者を認識しますが、検索エンジンやAI検索のクローラーはHTMLの構造だけでは「著者名らしき文字列」と「本当に著者を示す情報」を区別できません。そこでArticleやBlogPostingといった記事の構造化データの中に、authorプロパティとしてPerson型の情報を明示的に記述することで、人間向けの表示と機械向けの情報を橋渡しします。

authorプロパティが果たす役割

authorプロパティの本質的な役割は、ページ上に表示されている著者名と、裏側のマークアップ情報とを一致させることです。

この一致が崩れていると、検索エンジンや生成AIが「このページの著者は誰か」を正確に特定できなくなり、著者の実績やプロフィールを記事と結びつけて評価することが難しくなります。

authorとpublisherの違い

authorは記事を執筆した個人（Person）を指すのに対し、publisherは記事を公開している組織（Organization）を指します。

個人ブログであれば両者が同一人物になることもありますが、企業のオウンドメディアでは「執筆した個人」と「運営する法人」が別のエンティティであるため、authorにOrganizationを指定してしまうと、Googleが人物としての著者を正しく認識できなくなる点に注意が必要です。

なぜ構造化データauthorの整備が重要なのか

結論として、著者情報の構造化データそのものに直接的な検索順位向上効果はありませんが、Googleが著者を独立したエンティティとして認識するための土台になり、生成AI検索が回答の根拠として引用する際の判断材料にもなり得ます。

Googleが重視する「誰が書いたか」というE-E-A-Tの観点

Google検索セントラルの「有用で信頼性の高い、ユーザー第一のコンテンツの作成」というガイドラインでは、コンテンツの評価軸としてE-E-A-T（経験・専門性・権威性・信頼性）が挙げられており、その中で「コンテンツの作成者が誰であるかを明確にしているか」という問いが示されています。

もっとも、著者情報を掲載しただけで機械的に順位が上がるわけではなく、あくまで信頼性を判断するための一要素として位置づけられている点は誤解のないよう整理しておく必要があります。

ChatGPT・AI Overviewsなど生成AI検索における著者情報の扱われ方

生成AI検索は、回答を生成する際にウェブ上の情報源を横断的に参照し、そのページの発信元がどの程度信頼できるかを判断材料の一つとして扱います。AIコマース研究所が複数の支援先サイトを分析してきた中では、著者情報が構造化データとして整備され、かつプロフィールページやSNSなど外部の情報と一貫してつながっているサイトほど、生成AI検索からの参照が安定しやすい傾向が見られます。

これはGoogleの検索順位とは別の文脈ですが、「著者が誰であるかを機械が特定しやすい状態にしておく」という土台作りの重要性は共通しています。

authorの構造化データの基本的な書き方（JSON-LD）

結論として、authorの構造化データはJSON-LD形式でPerson型を用い、氏名とプロフィールページへのリンクを最低限含める形で記述します。複雑なプロパティを網羅する必要はなく、まずは基本形を正確に書くことが優先されます。

Person型を使う基本構文とサンプルコード

記事本文にArticleまたはBlogPostingの構造化データを設置し、その中のauthorプロパティにPerson型で著者情報を記述します。基本形は次のような構成です。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事のタイトル",
  "author": {
    "@type": "Person",
    "name": "著者の氏名",
    "url": "https://example.com/author/著者スラッグ"
  }
}

記事本体をArticleやBlogPostingで、著者をPersonで、著者ページをProfilePageでマークアップするのが基本的な型の使い分けです。

ここでOrganizationを人物に対して使ってしまう誤用は、実装現場で頻出するミスの一つです。

author.nameには氏名のみを指定する

author.nameプロパティには、著者のフルネームだけを記述します。「山田太郎（株式会社〇〇代表）」のように肩書きや所属を氏名に含めてしまうと、検索エンジンはこれを一つの固有名詞として処理してしまい、他のページや外部プロフィールに記載された同一人物の氏名と照合しづらくなります。

肩書きを構造化データで表現したい場合は、jobTitleプロパティに分離して記述するのが適切です。

author.urlでプロフィールページと紐づける

author.urlは、著者を一意に識別できるウェブページへのリンクを指定するプロパティです。Googleの記事構造化データに関する解説ドキュメントでは、著者のSNSページや紹介ページ、略歴ページなどへのリンクを指定することが推奨プロパティとして案内されています。

このurlの指定先が、内部の著者プロフィールページであり、かつそのページ自体もProfilePage構造化データでマークアップされていれば、著者情報の一貫性がより伝わりやすくなります。

構造化データauthorを実装する際によくある間違い

結論として、authorの構造化データで頻発する誤りは、型の誤用・プロパティの混同・著者の記載漏れの3パターンに集約されます。いずれも実装時に見落としやすい箇所です。

Organization型を人物に誤用してしまうケース

企業のオウンドメディアでよく見られるのが、authorに個人ではなく会社名やサイト名をOrganization型で記述してしまうケースです。この場合、記事の実質的な執筆者が誰であるかをGoogleが特定できず、著者個人のエンティティ評価につなげることができません。

監修者や運営会社の情報を伝えたい場合は、authorとは別にpublisherプロパティやreviewedByプロパティを使い分けるのが適切です。

typeと@typeを混同してしまうケース

構造化データでは型を指定するために@typeというプロパティを使いますが、これをtypeと誤記してしまう構文ミスも実装現場で少なくありません。

@typeはJSON-LDの仕様上定義されたメタプロパティであり、typeという独自のキーを使ってもGoogleは型として認識しません。実装後は必ずGoogleのリッチリザルトテストなどの検証ツールで構文エラーがないかを確認することが推奨されます。

複数著者を1人分しかマークアップしていないケース

共著記事やチームで制作した記事であっても、実際に執筆・監修に関わった著者は全員マークアップに含めることが望ましいとされています。

authorプロパティは配列として複数のPersonオブジェクトを記述できるため、1名分の情報しか含めていないと、他の関与者の実績や専門性が記事の評価に反映されない可能性があります。

authorの構造化データの実装セルフチェック法

結論として、authorの構造化データが正しく機能しているかどうかは、「表示名」「人物」「プロフィール」「役割」の4項目が一致しているかを確認することでセルフチェックできます。これはAIコマース研究所が支援現場で用いている確認手順を基にしたものです。

診断の現場では、構造化データ自体は技術的に正しく記述されているにもかかわらず、この4項目のいずれかにズレがあるために、Googleや生成AI検索が著者を一つのエンティティとして統合的に認識できていないケースが頻繁に見つかります。具体的には次の4点を順番に確認します。

まず1点目の「表示名」は、ページ上に表示されている著者名と、構造化データのauthor.nameが完全に一致しているかどうかです。表記ゆれ（フルネームと略称、旧字体と新字体など）があると、同一人物として認識されにくくなります。

2点目の「人物」は、構造化データが指し示しているPersonが、実在する正しい人物として一意に特定できる状態かどうかです。汎用的な役職名や部署名をauthor.nameに使ってしまっていないか、複数人が同じPersonとして扱われていないかを確認します。

3点目の「プロフィール」は、author.urlが指すプロフィールページのURLが実際に存在し、正しく機能しているかどうかです。リンク切れや、noindex設定によってインデックスされていないプロフィールページを指定してしまっているケースは、実装後に見落とされがちなポイントです。

4点目の「役割」は、構造化データ上で著者とされている人物が、実際にその記事を執筆しているかどうかという実態面の一致です。担当者の異動や退職後もマークアップが更新されず、実際には執筆していない人物が著者として表示され続けているケースは、企業のオウンドメディアで特に起こりやすい問題です。

この4項目が一致していれば、人間向けの表示と機械向けの構造化データとのズレを減らすことができ、Googleや生成AI検索が著者のエンティティを認識しやすい状態に近づきます。逆に、どれか1つでも欠けていると、せっかく実装した構造化データが本来の効果を発揮しにくくなります。

著者プロフィールページ・ProfilePage構造化データとの連携方法

結論として、著者プロフィールページはProfilePage構造化データでマークアップし、sameAsプロパティで外部のSNSや寄稿先のプロフィールと接続することで、著者エンティティの識別を後押しできます。

プロフィールページに含めるべき情報

著者プロフィールページには、氏名、写真、経歴、専門分野、外部のSNSアカウントや寄稿先へのリンク、連絡先などをまとめて掲載します。

検索エンジン向けというよりも、まず読者にとって「この人が書いているなら信頼できる」と感じてもらえる内容にすることが基本方針です。その上で、ページ全体をProfilePage構造化データでマークアップし、mainEntityプロパティの中にPerson型で情報を記述する形が一般的です。

sameAsプロパティで外部SNS・プロフィールと接続する

sameAsプロパティは、同一人物の別ページ（X、Facebook、LinkedIn、noteなど）のURLを列挙し、「これらはすべて同一人物のプロフィールである」ことを検索エンジンに伝えるためのプロパティです。

著者が複数のプラットフォームで一貫した活動をしていることが伝わるほど、Googleが著者をエンティティとして識別しやすくなると考えられています。

構造化データauthorとAI検索経由の指名検索・引用の関係性

結論として、著者情報の構造化データを整備すること自体に直接的な順位向上効果はありませんが、著者がGoogleや生成AI検索にとって既知のエンティティとして認識された場合には、間接的にプラスの影響が生じる可能性があります。

著者がエンティティとして認識されることのSEO・LLMO上の意味

Googleが公開している特許文書では、コンテンツ制作者のエンティティに関連度・注目度・貢献度・受賞歴といった指標に基づくスコアを割り振り、検索結果のランキング調整に利用する手法が示されています。

これはあくまで特許文書に記載された技術の一例であり、そのままの形で現行のアルゴリズムに実装されているとは限りませんが、著者を独立したエンティティとして識別可能な状態にしておくことの重要性を示す一つの根拠として参考にできます。

「著者情報を書けば順位が上がる」わけではない点への正しい理解

Google SearchLiaisonは、単に著者情報を追加するだけではランキングが向上するわけではなく、署名欄に「専門家」と書かれているからといってGoogleのシステムがそれを鵜呑みにすることもない、という趣旨の発言をSNS上で行っています。

著者情報はあくまで読者の信頼獲得とエンティティ識別の土台であり、それ単体を検索順位や指名検索数を直接押し上げる施策として捉えるのは誤解であることに注意が必要です。

構造化データのauthorに関するよくある質問

構造化データのPersonとは何ですか？

Personは人物を表すschema.orgの型で、著者名や経歴などを検索エンジンに伝える際に使います。authorプロパティの値としてよく使われ、氏名やurlなどのプロパティを組み合わせて記述します。組織を表すOrganizationとは明確に区別して使う必要があります。

Article構造化データとは何ですか？

Article構造化データは、記事ページであることを検索エンジンに伝えるための型で、見出しや公開日、著者情報などをまとめて記述します。BlogPostingやNewsArticleといった派生タイプもあり、コンテンツの性質に応じて使い分けます。authorプロパティもこの中に含める形で記述します。

構造化データのtype WebSiteとtype Articleの違いは何ですか？

WebSiteはサイト全体を表す型で、Articleは個別の記事ページを表す型という違いがあります。サイト全体のトップページなどにはWebSiteを、個々の記事にはArticleやBlogPostingを設定するのが基本的な使い分けです。両者を混同して記述すると、検索エンジンがページの性質を誤認する可能性があります。

構造化データのsameAsプロパティはどう使いますか？

sameAsは、同一人物・同一組織の別ページを列挙し、それらが同じ実体であることを示すプロパティです。著者のX、Facebook、LinkedInなど外部プロフィールのURLを配列で指定するのが一般的な使い方です。著者プロフィールページのProfilePage構造化データ内で使用します。

構造化マークアップとは何ですか？

構造化マークアップとは、ウェブページの情報をJSON-LDなどの形式で検索エンジンが読み取りやすいように記述する仕組みです。通常のHTML表示に加えて、機械可読な形式で情報を補足することで、検索結果でのリッチリザルト表示や、AI検索での正確な内容理解につながる傾向があります。

authorの構造化データの具体的な記述例を教えてください

基本形はArticleのauthorプロパティにPerson型でname・urlを指定する形です。例えば「author」の値として「@type: Person」「name: 氏名」「url: プロフィールページのURL」を記述します。肩書きはjobTitleなど別プロパティに分離するのが適切です。

構造化データのimageObjectはauthorとどう関係しますか？

ImageObjectは画像を表す型で、著者のプロフィール写真をPersonのimageプロパティに指定する際に使われることがあります。単なる画像URLの文字列ではなく、ImageObject型として幅・高さなどの情報を含めて記述すると、より詳細な画像情報を検索エンジンに伝えられます。

実装したauthorの構造化データが正しく機能しているか確認する方法はありますか？

Googleのリッチリザルトテストなどの検証ツールで構文エラーの有無を確認するのが基本的な方法です。加えて、表示名・Person・プロフィール・役割の4項目が一致しているかを目視で確認するセルフチェックも有効です。構文が正しくても実態面でズレているケースは検証ツールだけでは見つけにくい傾向があります。

構造化データが正しいかどうかを自分で確認する方法はありますか？

本記事で紹介した「表示名・人物・プロフィール・役割」の4項目を照合するセルフチェックが確認方法の一つです。加えて、Googleの検証ツールで構文エラーがないかを確認すると、技術面と実態面の両方をカバーできます。判断に迷う場合は専門家による診断を利用するのも一つの方法です。

構造化データauthorは「読者への信頼」と「AIへの伝達」の両輪で整備する

構造化データのauthorは、それ単体で検索順位を押し上げる魔法のタグではありません。しかし、Person型での正確な記述、author.urlによるプロフィールページとの連携、そして「表示名・人物・プロフィール・役割」の4項目の一致を丁寧に積み重ねることで、Googleや生成AI検索が著者を一つのエンティティとして認識しやすい土台を作ることができます。

まずは自社の代表的な記事で4項目のセルフチェックを行い、それでも不安が残る場合はLLMO無料診断で専門的な観点から確認してみてください。