【Google検索セントラル解説】プロフィールページ（ProfilePage）の構造化データ｜人や組織の紹介ページに付ける範囲と更新の経緯

2026年10月8日

著者の紹介ページや、代表・スタッフの紹介ページに、「この人はこういう人です」とGoogleへ伝えるコードを足したほうがよいのでしょうか。Googleは検索セントラルの1ページで、その書き方を説明しています。

そのページ「Profile page (ProfilePage) structured data」を、英語版の原文から読みます。何に付けてよいか、必須の項目、英語版と日本語版の差、更新の経緯に加え、弊社の著者ページで確かめた結果も載せました。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。このページを読むと、人の紹介ページに付けるコードの範囲について、Google自身の線引きが分かります。

結論：3行で言うと

必須の項目は少なく、紹介の対象を示すmainEntityと、その人や組織のnameの2つです。写真や肩書きなどは推奨の位置づけです
付けてよいのは、1人または1組織が主役のページです。著者ページ、自己紹介ページ、従業員のページが例に挙がります。店のトップページは使えない例です
2026年9月8日にトラブルシューティングの説明が1文足されました。変更履歴に記載があるのは、2024年8月の冒頭の書き換えのほうです

このページの基本情報

項目	内容
原題（英語）	Profile page (ProfilePage) structured data
日本語版の題名	プロフィールページ（ProfilePage）の構造化データ
英語版の最終更新日	2026年9月8日
日本語版の最終更新日	2026年9月12日
Google検索セントラルの中の位置（章）	「ランキングと検索での見え方」の中の「構造化データ」にあるページの一つです
直近の主な更新	2026年9月8日。トラブルシューティングに説明が加わりました（変更履歴に記載なし）

原文はこちらで読めます。英語版／日本語版。

Googleがこのページで言っていること

何のためのマークアップか

ProfilePageは、作成者（個人または組織）が、自分の直接の経験にもとづく視点を共有するサイト向けのマークアップです。

追加の狙いは、オンラインのコミュニティに投稿する作成者をGoogle検索が理解し、そのコミュニティのより良いコンテンツを検索結果に出すことです。「ディスカッションとフォーラム」の機能が例に挙がっています。

記事、レシピ、ディスカッションフォーラム、Q&Aページの構造化データにも作成者がいて、そこからProfilePageのあるページへリンクできる、と説明しています。

追加から公開までの流れ

流れは、必須の項目を足す、ガイドラインに従う、リッチリザルトテストで重大なエラーを直す、の順です。そのあと数ページに入れてURL検査ツールで確かめ、再クロールの依頼とサイトマップの送信へ進みます。

使える場合と使えない場合

コンテンツのガイドラインが求める条件は、ページの主役が、ウェブサイト全体に関係する単一の個人または組織であることです。

判定	ページが挙げる例（と理由）
使える	フォーラムやソーシャルメディアのユーザープロフィール
使える	ニュースサイトの作成者のページ
使える	ブログの「自己紹介」ページ
使える	企業サイトの従業員のページ
使えない	店のメインのホームページ（プロフィール以外の情報が多い）
使えない	組織のレビューサイト（組織自体がそのウェブサイトと関連していない）

技術面のガイドライン

作成者の最近の活動（投稿など）も載せるときは、それぞれにURLを付けてマークアップすると、全文を持つページを参照できます。

コード例では、mainEntityのPersonに@id（#main-author）を付け、hasPartに入れたArticleのauthorが同じ@idを指します。人と記事が、同じコードの中でつながります。

項目の一覧

必須は2つで、残りは推奨です。推奨を足すと、プロフィールページの情報が増え、利用者の体験の向上につながる可能性がある、と説明しています。

対象	項目	位置づけ	ページの説明の要点
ProfilePage	mainEntity	必須	ページの対象の個人（Person）か組織（Organization）です。種類が不明なとき（アカウントの種類が分からない場合など）は、Personを既定にします
ProfilePage	dateCreated	推奨	プロフィールが作られた日時（ISO 8601の形式）です
ProfilePage	dateModified	推奨	プロフィールの情報が編集された日時です。人が手で行ったメタデータの変更だけを反映するのが理想とされています
Person・Organization	name	必須	識別の主たる方法です。実名を勧め、SNSのハンドル名はalternateNameに入れます。nameが使えないときは、alternateNameで要件を満たせます
Person・Organization	alternateName	推奨	nameに実名を入れたときのSNSハンドル名などです
Person・Organization	description、identifier、image、sameAs	推奨	署名欄や資格、サイト内で使う一意のID（内部のデータベースIDでもよい）、プロフィール画像のURLかImageObject、外部の他のプロフィールやホームページのURLです
Person・Organization	interactionStatistic	推奨	そのエンティティに向けられた統計です。FollowAction（フォロワー数）、LikeAction（いいね数）、BefriendAction（双方向の関係）を認識します。ページを載せているプラットフォームの数字だけを入れます
Person・Organization	agentInteractionStatistic	推奨	そのエンティティ自身の行動の統計です。FollowAction（フォローしている数）、LikeAction（他の人の投稿へのいいね数）、WriteAction（投稿数）、ShareAction（再共有数）を認識します

imageについて、原文は次のように書いています。”If there are no images, don’t include a default image, icon, or placeholder image in this field.”（画像が無いときは、この項目に既定の画像、アイコン、プレースホルダ画像を入れないでください）。

Search Consoleでの確認と、うまく表示されないとき

ページは、Search Consoleを見る場面を3つ挙げています。初めて入れた後は、関連するリッチリザルトのステータスレポートで、有効な項目が増え、無効な項目が増えていないかを見ます。

テンプレートやコードを更新した後は、無効な項目の増加と、有効な項目だけの減少に注意します。後者は、構造化データが埋め込まれなくなった可能性を示します。

定期的な分析には、パフォーマンスレポートを使います。

トラブルシューティングには、次の1文があります。”Google does not guarantee that features that consume structured data will show up in search results.”（構造化データを使う機能が検索結果に表示されることを、Googleは保証しません）。

手動による対策を受けたページでは、構造化データが無視されますが、ページ自体は検索結果に出られます。ガイドライン違反は、構文の問題とは限らず、その場合はリッチリザルトテストでは見つけられない、とも書かれています。

英語版と日本語版の違い

英語版（2026年9月8日更新）と日本語版（同9月12日更新）を、節ごとに読み比べました。項目の名前と型、必須と推奨の区分、4つのコード例は一致しています。

日本語版は4日新しく、9月8日の追加説明（トラブルシューティングの最後の項目）も日本語版に入っています。内容を変える差は見つかりませんでした。

訳の濃淡が、冒頭の段落に2点あります。どちらも、実務の判断を変える差ではないと考えます。

英語版は、コミュニティの「より良い」コンテンツを検索結果に出す、という書き方です。日本語版は「最適なコンテンツを表示できるようになります」で、「最適」のほうが強く読めます
英語版は、Googleが理解し、見せる「助けになる」という書き方です。日本語版は「把握し〜表示できるようになります」で、控えめな言い方が薄れています

更新の経緯

変更履歴ページ（2026年10月1日更新の版）と、Internet Archiveの保存版（2023年12月2日、2024年7月27日、2026年9月1日の3つ）を使い、現在の英語版と文面を比べました。

日付	出どころ	内容
2023年11月27日	変更履歴	プロフィールページ、ディスカッションフォーラムの構造化データのドキュメントを追加し、Q&Aページの推奨を広げました
2023年12月1日（最終更新日）	保存版	冒頭は、名前やSNSのハンドル名、プロフィール写真、フォロワー数、コンテンツの人気といった情報を目立たせる助けになる、と説明していました。Perspectivesの機能にも触れていました
2023年12月〜2024年4月	保存版の比較	コード例の日付が2019年から2024年に変わり、コードラボへの案内文と、キャッシュのリンクでデバッグしないよう促す警告が消えました。解析不能な構造化データのレポートへの案内が加わりました
2024年8月23日	変更履歴	プロフィールページとディスカッションフォーラムのマークアップの使われ方を明確にしました。理由は、Perspectivesが検索でForumsに改称されたことです。冒頭は、2024年7月27日の保存版が旧文、2026年9月1日の保存版が現行文で、変更履歴と合います
2025年12月10日	最終更新日	2026年9月1日の保存版が示す最終更新日です。変更履歴に項目は無く、保存版の間隔が空いているため、変更の中身は特定できませんでした
2026年9月8日	保存版の比較	トラブルシューティングの最後の項目に、構造化データの問題が表示に影響しうること、リッチリザルトが見つからない場合や総数が減った場合のガイドで手順を確かめることが加わりました。変更履歴に項目はありません

2026年9月8日の変更履歴にあるのは、別の資料（検索体験の地域差）の追加です。

このシリーズで追う161ページのうち、英語版の最終更新日が同じ9月8日のものは30ページあります。変更履歴だけを見ると、こうした本文の更新を見落とします。

このページから、言えること・言えないこと

言えること	言えないこと
主役が1人または1組織のページに使う前提で、著者ページ、自己紹介ページ、従業員のページが例に挙がっている	会社のトップページや事業紹介のページに付けてよい
必須の項目はmainEntityと、Person・Organizationのnameの2つ	推奨の項目を全部埋めないと、検索で使われない
Googleは、コミュニティの作成者の理解や、ディスカッションとフォーラムの機能に使うと説明している	付ければ、検索結果にプロフィール写真やフォロワー数が出る
構造化データを使う機能の表示を、Googleは保証しない	書式が正しければ、必ず表示される
ページに、国や言語ごとの提供状況の記載は無い	ディスカッションとフォーラムの機能が、日本の検索で表示されている

中小企業の視点で、どう受け取るか

ここからはGoogleの説明とは別の、私の読み取りです。

対象のページを洗い出し、いまのコードを読みます。WordPressなら、管理画面の「ユーザー」一覧の「表示」で、著者ページのURLが分かります。固定ページの代表挨拶やスタッフ紹介も数えます。各ページのソースを表示して、ProfilePageとnoindexを検索します。SEOプラグインが自動で出していることがあります
検証は、公式ページの順に行います。リッチリザルトテストにURLを入れて重大なエラーが無いかを見ます。次に、URL検査ツールで、Googleが取得できることと、noindexで止まっていないことを確かめます。ステータスレポートは、インデックス登録の後に見ます
記事の著者と、紹介ページを結びます。Googleの記事（Article）のページは、作成者のurlにサイト内のプロフィールページを指定し、そこにProfilePageを付けることを勧めています。sameAsで代用する方法も書かれています。構造化データ全般の入れ方は、構造化データとは非エンジニアでもわかる実装ガイドにまとめています
コードの内容は、ページに載せている範囲に揃えます。ページに書いていない肩書きや実績を、コードにだけ入れる使い方は避けます。一般的な構造化データのガイドラインは別のページにあり、今回は未確認です。人の情報は、公開してよい範囲かを本人に確かめてから入れます