結論から言うと、記事の著者情報は「構造化データへ名前を入れれば完了」ではありません。画面に表示する署名、著者を説明するページ、Article構造化データの名前とURLを同じ人物または組織へそろえ、公開後のHTMLまで確認します。Googleは2026年8月、Articleの推奨プロパティとして author.url を明確にしました。ただし、設定だけで掲載順位や生成AIからの引用が上がると断定できるものではありません。
まず、誰を著者として示すか決める
WordPressでは投稿者アカウント、画面上の著者名、SEOプラグインが出力する構造化データが別々に管理されることがあります。先に「執筆と内容確認の責任主体を、個人と組織のどちらで示すか」を決めます。担当者名を公開しない運用なら、実態に合う組織名を著者として扱う方法もあります。反対に、画面では個人名を出しているのに、構造化データだけ会社名へ置き換えると情報が食い違います。
複数人で書いた記事は、Googleの案内どおり著者を一つの文字列へ連結せず、一人ずつ分けて指定します。執筆者と確認者を区別する場合も、画面上の表記と構造化データの役割を一致させることが大切です。
author.urlは著者を識別できるページへ向ける
author.url には、著者を一意に確認できるページを指定します。社内の著者紹介ページ、事業者の運営者情報、本人または組織の公式プロフィールなどが候補です。記事一覧や問い合わせフォームのように、著者の説明がないページへ機械的に向けるものではありません。
サイト内の著者プロフィールを使う場合、GoogleはProfilePage構造化データも推奨しています。ただし、先にプロフィール本文を用意するのが順序です。名前、役割、扱う分野、所属など、訪問者が著者を判断できる情報を画面に表示し、その内容と構造化データを一致させます。表示していない資格や実績をマークアップだけへ追加してはいけません。
WordPressで確認する場所
- 投稿編集画面の投稿者が意図したアカウントか
- 記事本文付近に表示される著者名と確認者名が正しいか
- ユーザー表示名、プロフィール、著者アーカイブに不要な個人情報がないか
- SEOプラグインやテーマがArticleを重複出力していないか
authorの種類、名前、URLが画面上の事実と一致するか- プロフィールURLがHTTP 200で、canonicalやnoindexに不整合がないか
テーマとSEOプラグインの両方がArticleを出す構成では、同じ記事に異なる著者情報が併存することがあります。管理画面の設定だけを見ず、公開ページのソースまたは構造化データ検証結果で、最終的な出力を確認します。
公開前後の検証を分ける
公開前は、検証環境で著者名、URL、プロフィール表示、権限設定を確認します。個人のログイン名やメールアドレスが意図せず公開されていないかも見ます。公開後はリッチリザルトテスト、Search ConsoleのURL検査、実際のHTMLを使い、Googleが取得できる状態かを確認します。
構造化データにエラーがなくても、検索結果で特定の表示になる保証はありません。著者情報は検索エンジン向けの飾りではなく、読者が誰の説明かを判断するための情報です。SEOや生成AI検索のために項目だけ増やすのではなく、本文の専門性、出典、更新日、問い合わせ先まで含めて整えます。
制作時の受け渡し項目に加える
制作会社様からWordPress実装を受ける場合は、著者を個人・組織のどちらで出すか、プロフィールページを作るか、確認者を表示するかを仕様書へ加えておくと手戻りを減らせます。既存テーマやSEOプラグインの出力も確認し、必要な範囲だけ調整します。
GreenCodingでは、支給デザインからのコーディングに加え、WordPressの表示項目や公開後の確認方法も案件ごとに整理します。実装範囲がまだ固まっていない場合は、コーディング代行の対応内容をご確認ください。
最終チェック
- 画面上の著者と構造化データが一致している
- 著者URLの先で本人または組織を確認できる
- 複数著者を一人ずつ指定している
- Articleの重複や矛盾がない
- プロフィールへ未公開の実績を足していない
- 公開後のHTMLとURL検査まで確認した
最終確認日: 2026年8月22日。Googleの推奨項目やWordPressの出力は今後変わる可能性があるため、プラグイン更新やテーマ変更の後にも再確認します。