著者の構造化データの書き方｜Personとurl・sameAsの指定手順

名前だけでは足りない。型と、本人を示すURLまで書く

記事テンプレートの JSON-LD を開くと、"author": "山田" とだけ書かれている。あるいは "author": {"name": "編集部 山田太郎（マーケティング部長）"} のように、肩書きまで1つの欄に詰め込まれている。よく見かける状態です。

結論を先に書きます。著者は @type（Person か Organization）と name に加えて、本人を一意に示すページの url（または sameAs）まで書きます。name には名前以外を入れません。 この2点を直すだけで、Google が勧める形にほぼ揃います。

Google 検索セントラルの Article（記事）構造化データのドキュメントは、著者について、型と url（または sameAs）を使うことを「強く勧める」と書いています。理由は、著者が誰なのかを Google がよりよく理解できるようにするためです。

名前の文字列だけでは、同じ名前の別人と区別する手がかりがありません。だから URL が要ります。

Google が著者マークアップに求めていること

ドキュメントの記述を、実装でそのまま使える形に整理します。対象は Article・NewsArticle・BlogPosting のいずれかの型で書いた記事です。

表の3行目には続きがあります。url に指定したのがサイト内のプロフィールページなら、その著者をプロフィールページの構造化データでマークアップすることも勧められています。著者ページを持っているサイトは、記事側の url とプロフィールページ側の記述をセットで整えると考えてください。

もう1つ、Organization の場合です。著者が組織なら、url には組織のトップページを指定する例が載っています。「Wemiro編集部」のような編集部名義は、この Organization の形にあたります。

name 欄に入れてはいけない4つの情報

いちばん崩れやすいのが name です。CMS の「表示名」をそのまま流し込むと、見た目用の文字列が混ざります。

ドキュメントは、author.name には著者の名前だけを書くよう求めています。具体的に入れてはいけないとされているのは次の4つです。

1. 発行元（パブリッシャー）の名前。会社名やメディア名は publisher プロパティに書きます。
2. 著者の肩書き。示したいなら jobTitle という専用の欄を使います。
3. 敬称（前置き・後置き）。敬称は honorificPrefix・honorificSuffix に分けます。
4. 前置きの言葉。「posted by」のような言葉を含めないよう書かれています。日本語サイトなら「投稿者:」「文:」「執筆:」がこれにあたると考えられます。

つまり、見た目では「マーケティング部長 山田太郎（株式会社サンプル）」と1行で出していても、JSON-LD では欄を分けます。表示と記述を同じ文字列にしようとしないことが、崩れを防ぐコツです。

ワークスルー：同じ名前の人が多い著者で書いてみる

ここからは実際に1本書きます。架空の設定です。

• 会社: 住宅設備の会社のオウンドメディア（https://www.example.com）
• 著者: 山田 太郎（社内の施工管理担当。同じ名前の人が世の中に多い）
• 社内の著者ページ: https://www.example.com/authors/yamada-taro
• 本人の外部プロフィール: 業界団体の会員紹介ページと、業務用 SNS アカウント
• 記事: 監修なし、山田さん1人で執筆

直す前

テーマが出力していた JSON-LD はこうでした。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "浴室乾燥機の交換時期と費用の目安",
  "author": {
    "name": "施工管理 山田太郎（株式会社サンプル）"
  }
}

問題は3つあります。@type がない。name に肩書きと会社名が混ざっている。本人を示す URL がない。これでは「山田太郎」という文字列以上の手がかりを Google に渡せていません。

直した後

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "浴室乾燥機の交換時期と費用の目安",
  "author": [{
    "@type": "Person",
    "name": "山田太郎",
    "jobTitle": "施工管理",
    "url": "https://www.example.com/authors/yamada-taro",
    "sameAs": [
      "https://association.example.org/members/yamada-taro",
      "https://sns.example.net/yamada_taro_reform"
    ]
  }],
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "url": "https://www.example.com"
  }
}

変えた点を、さきほどの表に一つずつ戻して確かめます。

• 型の行は、"@type": "Person" を足して満たしました。
• name の行は、名前だけを残し、肩書きを jobTitle、会社名を publisher に移しました。
• url の行は、社内の著者ページを指定しました。このページは山田さん1人のためのページなので、「著者を一意に示す」に当てはまります。
• sameAs の行は、外部の2つのプロフィールを並べました。ドキュメントは sameAs を url の「代わりに使える」ものとして書いています。ですから、どちらか一方でも推奨は満たせます。ここでは手がかりを増やすために両方を書いています。

同じ名前の人が多い著者ほど、この URL の部分が効いてくると考えられます。名前が一致する人は大勢いても、同じ著者ページや同じ外部プロフィールを持つ人は1人だけだからです。

共著になったとき

翌月、同じ会社の佐々木さんとの共著記事が出ました。ここでやりがちなのが、name に「山田太郎、佐々木花子」と並べる書き方です。ドキュメントはこれを避けるよう書いています。1人ずつ別の要素にします。

"author": [
  { "@type": "Person", "name": "山田太郎", "url": "https://www.example.com/authors/yamada-taro" },
  { "@type": "Person", "name": "佐々木花子", "url": "https://www.example.com/authors/sasaki-hanako" }
]

ページの著者欄に2人の名前を出しているなら、マークアップにも2人とも入れます。表示と記述で人数がずれないことが条件です。

実装から公開後までの確認手順

コードを直したら、確かめる場所は3か所あります。書いた直後、数ページを公開した直後、そして公開後しばらくたってからです。

1. ページ上の著者表示と JSON-LD を突き合わせる。 表示している著者の人数・名前と、author 配列の中身が一致しているかを見ます。テンプレートの条件分岐で、共著のときだけ1人分しか出ない、という崩れはここで見つかります。
2. リッチリザルトテストにコードを貼って検証する。 Google はこのツールを、構造化データを検証し、場合によっては検索での表示をプレビューできるツールとして案内しています。重大なエラーは必ず直します。
3. 重大でない指摘も読む。 ドキュメントは、重大でない問題も直すと構造化データの品質が上がる場合がある、としています。ただし、リッチリザルトの対象になるために必須ではない、とも書いています。著者の url の書き忘れのように、意図して入れたはずの項目が抜けていないかをここで見ます。
4. 数ページだけ公開し、URL 検査ツールで確かめる。 Google が実際にそのページをどう見ているかを確認します。あわせて、ページが robots.txt・noindex・ログイン必須のどれかでブロックされていないことも確かめます。
5. 公開後はリッチリザルトのステータスレポートを見続ける。 テンプレートや配信の問題で、公開後に記述が壊れることがあると Google は書いています。開発中はリッチリザルトテスト、公開後はステータスレポート、という役割分担です。

手順2で「エラーなし」と出ても、安心するのは早いです。Google はこのツールを構造化データの検証とプレビューのためのものとして案内しています。url の行き先が本当にその著者1人のページかどうかは、ツールの結果に頼らず、手順1の突き合わせで人が見るのが確実です。

よくある誤解と例外

「sameAs に SNS を並べれば url はいらない」

Google の記述上は、そのとおりです。sameAs は url の代わりに使えるとされています。ただし、自社サイトに著者ページがあるなら、url にはそちらを指定するのが自然です。プロフィールページの構造化データとつながるのは、サイト内の著者ページのほうだからです。外部のアカウントは、運用をやめると URL が切れることもあります。

「編集部名義だから著者マークアップは関係ない」

関係あります。編集部や会社の名義で出している記事は、author を Organization にして、url に組織のトップページを指定する形が例として示されています。author を省くのではなく、型を変えて書きます。名義そのものを実名にすべきかは別の問題で、著者名がないとSEOで不利かを整理した記事で扱っています。

「JSON-LD とページの表示は別物だから、ずれても構わない」

ずれは避けます。ページに著者として出している人は全員マークアップに含める、というのが Google の求めです。反対に、ページに出していない人を JSON-LD にだけ足すのもやめておくのが無難です。

自己点検チェックリスト

自社の記事テンプレートを1本開いて、上から当てはめてください。

全部 OK なら、次は公開後の監視です。エラーと警告の読み分けは構造化データの「エラー」と「警告」の違いにまとめています。JSON-LD と Microdata が混ざっているテーマなら、先にJSON-LDとMicrodataのどちらで書くかを決めてから著者欄を直すと、二重の記述を避けられます。