構造化データのauthorの書き方｜著者の経歴を載せる場所まで解説

「構造化データのauthorに、名前と肩書き、経歴まで書き込めば、Googleに著者の専門性が伝わりそう」。E-E-A-Tの説明で「誰が書いたか」が大事だと聞くと、JSON-LDに著者の情報を多く入れるほど有利に思えます。ところが、Googleの記事（Article）の構造化データにも、author.nameには名前だけを書き、author.urlには著者の略歴ページなどのURLを入れると説明されています。著者の経歴は、構造化データの中ではなく、読者が開けるプロフィールページに書きます。

本記事では、authorに書く項目とGoogleが挙げる5つの注意点から、経歴をプロフィールページに書いてauthorからつなぐ方法まで、記事制作会社の視点で、弊社代表の経歴を例にお伝えします。

構造化データのauthorに書く項目

構造化データのauthorは、記事を書いた人をGoogleに伝える項目です。Googleの記事の構造化データには必須の項目が無く、authorも推奨プロパティの1つです。

ブログの記事は、記事の構造化データの型の1つであるBlogPostingで書けます。Googleのページが挙げるauthorの項目のうち、記事でよく使うのは次の5つです。

弊社代表の米山拓真を著者にしたブログ記事なら、JSON-LDは次のように書きます。URLは例なので、自社のページのURLに置き換えてください。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "記事のタイトル",
  "datePublished": "2026-10-08T09:00:00+09:00",
  "author": [
    {
      "@type": "Person",
      "name": "米山拓真",
      "jobTitle": "代表",
      "url": "https://www.example.com/authors/takuma"
    }
  ],
  "publisher": {
    "@type": "Organization",
    "name": "合同会社Writers-hub",
    "url": "https://www.example.com/"
  }
}

JSON-LDとmicrodataの違いや、JSON-LDをページに入れる基本の手順は、schema.orgとは？構造化データが効くページと書き方を解説で解説しています。

Googleが挙げるauthorの5つの注意点

Googleは、作成者を正しく認識して表示できるように、authorを書くときの注意点を5つ挙げています。

ページに出ている著者を全員書くこと

記事の署名（ページに出す著者名の表示）に名前が出ている著者は、全員をauthorに書きます。

複数の著者を1人ずつ分けること

著者が複数いるときは、authorの中で1人ずつ別の項目に分けて書きます。

"author": [
  { "@type": "Person", "name": "米山拓真" },
  { "@type": "Person", "name": "共著者の名前" }
]

1つのnameに「米山拓真, 共著者の名前」と2人をまとめて書く形は、Googleが避けるよう示している書き方です。

@typeとurlを添えること

authorには、nameのほかに@typeとurlを書きます。urlには、自社サイトの著者ページなど、その人の詳しい情報があるページのURLを入れます。

sameAsはurlの代わりに使える項目で、urlとsameAsのどちらにも、有効なURLを入れます。

nameに名前だけを書くこと

author.nameには著者の名前だけを書き、Googleが挙げる次の4つは入れません。

• 会社やメディアの名前：publisher（記事の発行元を書く項目）に書く
• 役職：jobTitleに書く
• 敬称：honorificPrefixかhonorificSuffixに書く
• 「投稿者：」のような名前以外の言葉：nameから外す

たとえば、nameを「Writers-hub代表 米山拓真」とする書き方は、会社名と役職が混ざっています。nameは「米山拓真」だけにし、役職と会社名は別の項目へ分けます

個人と組織の型を取り違えないこと

著者の型は、個人ならPerson、会社や編集部などの組織ならOrganizationにします。Googleは、個人にOrganizationを使う取り違えと、人か組織かを表さないThingを使うことを避けるよう示しています。

記事（Article）の構造化データ | Google 検索セントラル | Documentation | Google for Developers

ニュース記事とブログに記事スキーマ マークアップを追加して、Google 検索結果に表示されやすくする方法をご確認ください。

🌐 developers.google.com

外部リンク

著者の経歴の載せ方とauthorでのつなぎ方

著者の経歴は、authorの中に書き込まず、著者のプロフィールページの本文に書きます。記事からは、署名のリンクとauthor.urlの2つでプロフィールページを指します。

Web担当者

経歴はJSON-LDのauthorに書いておけば、プロフィールページを作らなくても済みませんか？

Writers-hub
編集部

経歴を検索エンジンに伝えたいという考えは合っています。ただ、JSON-LDだけに書いた経歴は読者には見えません。Googleは、ページの読者に表示されない内容をマークアップしないよう求めているので、経歴はプロフィールページの本文に書き、構造化データはそのページを指す形にします。

プロフィールページへの経歴の書き方

プロフィールページの経歴は、肩書きを並べるより、記事のテーマに関わる仕事で何をしてどんな結果を出したかが分かる文で書きます。Googleも、署名が著者の経歴や専門分野の情報につながっているかを、コンテンツの自己評価の質問に挙げています。

弊社代表の米山拓真なら、プロフィールページの本文に次の2文を書きます。

「Webライター」「編集長」という肩書きだけでは、どんな記事を書いてきた人かを読者は判断できません。

経歴に書くのは確かめられる事実だけにし、肩書きや実績を足しません。Googleは、架空の名前や偽りの資格で著者を作ることを、欺く行為の一種としています。

記事とプロフィールページのつなぎ方

記事とプロフィールページをつなぐときは、プロフィールページの側にも構造化データを書きます。author.urlが自社サイトのプロフィールページを指すとき、Googleは、そのページをプロフィールページの構造化データ（ProfilePage）でマークアップするよう勧めています。

米山拓真のプロフィールページなら、ProfilePageは次のように書きます。

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "mainEntity": {
    "@type": "Person",
    "name": "米山拓真",
    "description": "開発職を経て編集部へ移り、2019年にWebライターとして独立しました。LeadGridのサービスサイトの初代編集長として、月60件のリードを獲得する体制を作りました。"
  }
}

descriptionは、Googleが署名欄や認証情報を書く項目としているもので、本文に書いた経歴と同じ文を入れます。SNSなど外部のプロフィールがあれば、sameAsにそのURLを足します。

ProfilePageの説明で、Googleは、ページの主な内容を、そのサイトに関係する1人の個人か1つの組織にするよう求めています。会社概要のページに複数の人を並べるのではなく、著者ごとにプロフィールページを1つずつ用意します。

名前の書き方を、署名とプロフィールページと外部のプロフィールでそろえる手順は、エンティティSEOの意味と対策｜社名や著者の情報をそろえる手順で解説しています。

authorを書くと検索順位は上がるか

authorを書いても、検索順位が上がるとは限りません。Googleは、authorの書き方を、作成者を正しく認識・表示するための方法として、記事の構造化データの説明で示しています。

Googleは、E-E-A-T自体はランキングに直接影響する要因ではないと書いています。一方で、Googleのコンテンツの自己評価の質問では、著者が誰かを明確にしているかと、ページの然るべき場所に署名があるかを尋ねています。どちらも、構造化データではなく、読者が見るページについての問いです。

公開前に確かめるauthorの5項目

authorを書いたページは、公開前にリッチリザルトテストで調べ、検出された記事の構造化データについて次の5項目を確かめます。

• 署名に出ている著者が、全員authorに入っている
• author.nameが署名と同じ表記で、役職や会社名が入っていない
• @typeが、個人ならPerson、組織ならOrganizationになっている
• author.urlのページが開き、そのページの本文に著者の経歴がある
• CMSやプラグインが出すauthorと、自分で書いたauthorが食い違っていない

CMSのプラグインやテーマが記事の構造化データを自動で出しているときは、自分で書いたJSON-LDを足すと、記事の構造化データが2つになり、authorの名前が食い違うことがあります。JSON-LDを足す前に、今のページをリッチリザルトテストで調べ、すでに出ているauthorを確かめてください。

構造化データのauthorでよくある質問

構造化データのauthorを書くときに迷いやすい質問は、次の3つです。

metaタグのauthorも書くべき？

Google検索のためなら、metaタグのauthorは書かなくても構いません。Googleがサポートするmetaタグの一覧にauthorは無く、サポートしていないmetaタグは無視されると書かれています。Googleに著者を伝えるなら、構造化データのauthorと記事の署名を整えます。

監修者もauthorに入れる？

監修者は記事を書いた人ではないため、authorには入れません。Googleの記事の構造化データには、監修者を書く項目がありません。

schema.orgには、ページの内容を確かめた人を表すreviewedByという項目がWebPageの型にあります。監修者は、本文に名前と経歴を書いて読者に示します。監修者と著者の役割の違いは、監修者の役割と著者との違い｜選び方と依頼の手順を制作会社が解説で解説しています。

会社名義の記事はどう書く？

会社名や編集部名で出している記事は、authorの@typeをOrganizationにし、nameに会社名か編集部名を、urlに会社のホームページのURLを入れます。署名に個人の名前を出している記事は、Personで書きます。

まとめ｜経歴はnameでなくプロフィールページに

構造化データのauthorでは、nameに著者の名前だけを入れ、役職や会社名は別の項目に分けます。著者の経歴はプロフィールページに書き、author.urlでそのページを指します。authorを書いても順位が上がるとは限らないので、読者に見える署名とプロフィールページを先に整え、構造化データはその内容に合わせて書きます。

私たち合同会社Writers-hubは、滋賀の会社に向けて、AIに聞かれたときに社名が答えに出るようにするLLMO対策・AI検索対策をお受けしています。