AI時代に著者ページを独立させる理由

著者名だけでは、「誰なのか」までは伝わらない

記事の末尾に著者名を書くだけでも、人間には「誰が書いた記事か」は分かります。

しかし、同じ名前の人がいる場合や、別の記事・別ページでも同じ人物が登場する場合、名前だけではサイト全体で一貫した識別子になりません。

そこで著者本人を説明する独立ページを1つ作り、記事側から常にそのURLを参照します。

著者ページは、単なる自己紹介ではなく、サイト内で「この人物とは誰か」をまとめる固定の参照先になります。

author.urlで、記事と人物をつなぐ

GoogleのArticle構造化データでは、author.urlとして「記事の著者を一意に識別するウェブページ」へのリンクを指定できます。

そのリンク先は、著者のSNS、Aboutページ、略歴ページなどでも構いませんが、サイト内部のプロフィールページを使う場合、GoogleはProfilePage構造化データで著者をマークアップすることを推奨しています。

つまり、各記事の著者名をバラバラに扱うのではなく、同じ著者ページへつなぐ構造を持たせられます。

著者ページは「一人の人物」を中心にする

GoogleのProfilePageガイドラインでは、ページの主役は、そのサイトに関係する単一の人物または組織であることが求められています。

ニュースサイトの著者ページ、ブログのAbout Me、企業サイトの従業員ページなどは有効な例として挙げられています。

著者ページに会社紹介、サービス説明、商品案内などを詰め込みすぎるより、「この人物は誰か」を中心にした方が役割が明確になります。

プロフィール情報を、記事ごとに繰り返さない

著者の経歴や専門領域を、すべての記事へ長く書く必要はありません。

記事には名前と短い肩書きを置き、詳しいプロフィールは独立ページへ集約できます。

経歴が変わったときも、著者ページを更新すればよく、何十本もの記事本文を修正する必要がありません。

これはSEO以前に、情報を重複させず一か所で管理するための設計として有効です。

Person情報を一か所へ集約する

ProfilePageでは、対象となるPersonまたはOrganizationに、name、description、image、identifier、sameAsなどの情報を持たせられます。

sameAsを使えば、本人の外部プロフィールやホームページなど、同じ人物を示す別URLも関連づけられます。

重要なのは、プロパティを増やすこと自体ではなく、同じ人物について複数ページで矛盾した説明をしないことです。

Blog・Knowledge・Experimentsから同じ人物へ戻る

海辺の部屋では、BlogだけでなくKnowledgeやExperimentsにも著者情報があります。

それぞれのコンテンツごとに別プロフィールを書くのではなく、authorUrlを共通の著者ページへ統一すると、コンテンツの種類が違っても同じ人物へ戻れます。

この構造は、サイト内で情報レイヤーが増えたときほど効きます。

AI時代でも、やることは「人を明確にする」こと

AI検索や生成AIを意識すると、特殊な「AI向けプロフィール」を作りたくなります。

しかし、著者ページでまず必要なのは、人間が読んでも分かるプロフィール、専門領域、実績、関連コンテンツ、外部プロフィールです。

そのうえで、記事から同じauthor.urlを参照し、構造化データでも同じ人物を表します。

Google公式資料は、著者を一意に識別するURLやProfilePageの利用を案内していますが、それ自体が検索順位やAI回答への引用を保証するものではありません。

著者ページに置く情報

• 名前：サイト内で一貫した表記
• プロフィール：何をしている人物か
• 専門領域：どの分野について書いているか
• 実績：確認できる事実だけを掲載
• 関連コンテンツ：Blog・Knowledge・Experimentsなど
• 外部プロフィール：必要に応じてsameAsで関連づける

著者ページは、権威を大きく見せるためのページではありません。「この内容を書いた人物を、後から確かめられるページ」と考えると設計しやすくなります。

このKnowledgeの関連知識

サイト構造の前提： 著者ページは、Blog・Knowledge・Experiments・Sourcesを役割別に分けた情報資産構造の中で機能する。

Blog・Knowledge・Experiments・Sourcesを分ける理由

人物情報の根拠をつなぐ： Web上のPerson情報も、抽象的な自己紹介だけでなく、実績や具体的Evidenceへ辿れる構造にする。

人物像は「性格の要約」ではなく、具体的な会話とEvidenceで書く

現在地： WEB & CMS → 情報資産・サイト構造設計

Knowledgeトップを見る