「内容は間違っていないはずなのに、読者に信頼してもらえない」。WordPressでブログやホームページを運営していると、こうした悩みにぶつかることがあります。原因の一つは、記事の中身だけを整え、「誰が、どのように、何を根拠に書いたのか」を伝えきれていないことかもしれません。
この伝え方の全体を、本記事では情報発信プロセスと呼んで整理します。Google公式の考え方を確認しながら、E-E-A-Tとの関係を正確に解説し、WordPress(SWELL)で今日から取り組める改善手順まで紹介します。
本記事は2026年11月6日時点で確認できたGoogle公式情報をもとにしています。最新の内容は、各章で示す公式ページもご確認ください。
1. 情報発信プロセスとは?記事の「中身」と「伝え方」を分けて考える
情報発信プロセスとは、記事の情報が「誰によって、どんな目的と方法で、いつ、何を根拠に発信されたか」を読者が確認できる状態にする考え方です。この章では定義、5W1Hでの整理、Googleの「誰が・どのように・なぜ」との関係、透明性が信頼に与える影響を説明します。
1-1. 本記事での定義
「情報発信プロセス」はGoogleが定めた公式用語ではありません。今回確認した公式資料では、この言葉を見つけられませんでした。SEOの現場で使われる整理の仕方として、信頼性を考える枠組みに使います。
記事の品質は、二つに分けて考えられます。
- 中身の品質:情報が正確か、読者の疑問に答えているか
- 伝え方の透明性:誰が書き、いつの情報で、根拠は何か、どう作られたかが確認できるか
中身が良くても、伝え方が不透明だと、読者は「信じてよいのか」を判断できません。情報発信プロセスは、後者を意識して整える取り組みです。
1-2. 5W1Hで整理する
信頼性を点検するときは、5W1Hで整理すると抜け漏れを防げます。ただし、これは記事を点検するための整理方法です。Googleが6項目をランキング要因として定義しているわけではありません。
| 要素 | 読者の疑問 | 記事で示す例 |
|---|---|---|
| What | 何についての情報か | 対象範囲、結論、対象読者 |
| Who | 誰が発信しているか | 執筆者名、プロフィール |
| When | いつの情報か | 公開日、更新日、更新内容 |
| Where | 出どころはどこか | 公式ページなどへの出典リンク |
| Why | なぜ出す情報か | 記事の目的、広告の有無 |
| How | どう調べ、確かめたか | 調査方法、AI利用の有無 |
1-3. Google公式の「誰が・どのように・なぜ」との関係
Google検索セントラルの「有用で信頼性の高い、ユーザー第一のコンテンツの作成」には、コンテンツについて「誰が」「どのように」「なぜ」を問う考え方があります(以下は要約です)。
- 誰が:誰が作ったかを読者に分かるようにする。署名や、著者の背景が分かるページへの案内が有用とされています。
- どのように:読者が制作方法を気にしそうな場面では、その方法を説明する。自動化やAIの利用も対象です。
- なぜ:最も重要な問いです。人の役に立つことが目的か、検索流入を得ることが目的かが問われます。
本記事の5W1Hとは、「誰が」がWho、「どのように」がHow・Where・When、「なぜ」がWhyにおおむね対応します。これは筆者の整理で、Google公式の対応表ではありません。
1-4. 透明性が読者の信頼に与える影響
透明性とは、読者が自分で判断するための材料を渡すことです。料金の記事に更新日がなければ、今も正しいのか分かりません。出典と更新日が明記されていれば、読者は自分で裏取りできます。ただし、こうした透明性が検索順位を直接引き上げる仕組みだとは、公式情報で確認できていません。本記事では、読者が発信元を判断できる状態を作ることを目的に、施策を紹介します。
2. Googleの品質評価の考え方:評価の話と実践施策を分ける
この章の要点は、Googleの「品質の考え方」と運営者の「実践施策」を混同しないことです。ユーザー第一のコンテンツ、E-E-A-T、評価ガイドライン、YMYL、そして適用範囲の違いを整理します。
2-1. ユーザー第一のコンテンツ
Googleは、検索エンジンのためではなく、人のために作られた有用で信頼できるコンテンツを重視すると説明しています。公式ページには、独自の情報や分析があるかといった自己点検の質問が並んでいます。順番は「読者の役に立つために書き、その過程が伝わるようにする」です。
2-2. E-E-A-Tとは
E-E-A-Tは、コンテンツの質を考える四つの観点です。
| 観点 | 意味 | 示し方の例 |
|---|---|---|
| Experience(経験) | 実際に使った、試した経験があるか | 自分で試した手順、画面キャプチャ |
| Expertise(専門性) | 知識やスキルが十分か | 正確な解説、実務経験(事実のみ) |
| Authoritativeness(権威性) | その分野で参照される存在か | 他者からの引用や紹介(事実のみ) |
| Trustworthiness(信頼性) | 正確で誠実か | 出典、更新日、運営者情報 |
Googleは、この四つのうち信頼性が最も重要と説明しています。ほかの三つは信頼性を支える要素と捉えると分かりやすいでしょう。
2-3. E-E-A-Tと検索ランキングの関係
「E-E-A-Tの点数を上げれば順位が上がる」という説明は正確ではありません。Googleは、E-E-A-Tそのものを特定のランキング要因とは説明していません(要約経由の確認)。内部の仕組みや重み付けは公開されていないため、本記事では次のように区別します。
- 公式に確認できること:E-E-A-Tは品質を考える枠組みで、中心は信頼性
- 公開されていないこと:個々のシグナルがどう使われ、どれほど影響するか
- 実践施策:推測で断定せず、読者が判断しやすい記事とサイトを作る
「E-E-A-T対策」も、スコアを上げる操作ではなく、信頼される要素を整える作業と読み替えるのが安全です。
2-4. 検索品質評価ガイドラインとの関係
検索品質評価ガイドラインは、Googleの品質評価者が検索結果を評価するときに使う資料です。評価者の評価が個々のサイトの順位を直接決めるものではないと、Googleは説明しています(生成AIに関する公式ページの記述を要約経由で確認)。ガイドライン本文は今回取得できませんでした。順位対策のチェックリストにせず、考え方を知る参考にとどめてください。
2-5. 信頼性が特に重要になるテーマ(YMYL)
YMYLは、健康、経済的な安定、安全など、人の生活に大きく影響しうるテーマです。E-E-A-Tの考え方は、こうしたテーマで特に重要になると説明されています。医療、投資、法律、税金などの記事では、断定を避けて公的情報を示し、確認時期を明記し、必要なら専門家への相談を案内しましょう。
2-6. 適用範囲を区別する
Googleの資料は性質が異なります。混ぜて説明しないよう注意が必要です。
| 資料 | 位置づけ | 本記事での扱い |
|---|---|---|
| ユーザー第一のコンテンツ(検索セントラル) | Google検索での考え方 | 「誰が・どのように・なぜ」の根拠 |
| スパムポリシー(検索セントラル) | 検索でスパムとされる行為 | 大量生成のリスクの根拠 |
| 検索品質評価ガイドライン | 評価者向けの資料。ランキングを直接決めない | 参考(本文は未取得) |
| Googleニュースのコンテンツポリシー | ニュース用の掲載面に適用 | 透明性の例。検索全般の要因とはしない |
Googleニュースのポリシーには、日付と署名、執筆者や発行元、運営組織の情報、連絡先を示す趣旨の透明性の項目があります。ただし適用されるのはニュース用の掲載面で、通常の検索全般の順位基準ではありません。本記事で触れるのは、読者への誠実さの参考になるからです。適用対象と、運営者が自主的に取り入れる行動は分けて考えてください。
3. 良い記事と悪い記事は何が違う?説明用の架空例で比較
同じ内容でも、情報発信プロセスの示し方で読者の受け取り方は変わります。以下は説明用の架空例で、実在の記事ではありません。テーマは「WordPressのバックアップ方法」とします。
| 観点 | 記事A(透明性が低い例) | 記事B(確認できる例) |
|---|---|---|
| 執筆者 | 表示なし | 氏名と担当分野、プロフィールへのリンク |
| 日付 | なし | 公開日と更新日、更新内容の一言 |
| 出典 | 「一般的に言われています」のみ | 公式ドキュメントへのリンク |
| 検証方法 | 記載なし | 試した環境と手順を明記 |
| 体験 | なし | 画面キャプチャとつまずいた点 |
記事Aでは、読者は「今のバージョンでも通用するのか」「誰の意見なのか」を判断できません。記事Bなら、出典を開いて確かめ、自分の環境と照らして使えます。記事Bに特別な権威は必要ありません。実際に手を動かした事実を、確認できる形で書くことが出発点です。事実がないことは書けません。
4. 記事単位でできる信頼性向上施策
この章では、記事ごとに実施できる九つの施策を、理由、方法、注意点の順に解説します。まずは日付、執筆者、出典から始めるのが取り組みやすいでしょう。
4-1. 公開日と更新日を明示する
- 理由:読者は「いつの情報か」で、使えるかを判断します。
- 方法:読者に見える場所に「公開日」「最終更新日」を表示します。構造化データを使うなら
datePublishedとdateModifiedを指定し、表示と一致させます。Googleの日付ガイドでも、見える日付の表示と構造化データとの一致が示されています(要約経由の確認を含む)。 - 注意点:更新日だけを変えて新しい記事に見せかける行為は、お勧めしません。 内容を見直して変更があったときに更新します。
4-2. 執筆者情報を掲載する
- 理由:書き手が分かれば、読者は経歴や立場を踏まえて読めます。
- 方法:記事の冒頭か末尾に執筆者名を出し、プロフィールページへリンクします。
- 注意点:実在しない人物名やAI生成の顔写真で専門家に見せかけてはいけません。Googleも欺瞞的な著者情報を避けるよう求めています。個人名を出せない場合は「編集部」でも構いませんが、運営者は確認できるようにします。
4-3. 必要に応じて監修者情報を掲載する
- 理由:医療、法律、お金など影響の大きいテーマでは、専門家の確認が判断材料になります。
- 方法:氏名、肩書き、監修した範囲、監修日を明記します。
- 注意点:実在し、実際に確認した人に限ります。名前だけを借りてはいけません。
4-4. 信頼できる情報源を引用する
- 理由:根拠が示されていれば、読者は自分で確かめられます。
- 方法:制度や仕様は公式ドキュメントや官公庁を優先し、該当箇所の近くに資料名つきでリンクします。
- 注意点:引用は必要最小限にし、二次情報しか確認できなければ断定を避けます。
4-5. 一次情報を活用する
- 理由:他のページの繰り返しでは読む理由が薄れます。一次情報とは、自分や発信元から直接得た情報です。
- 方法:自社のデータ、よくある質問、公式ドキュメントの直接確認、試した結果を載せます。
- 注意点:顧客情報は載せず、実績は作りません。
4-6. 実際の体験や検証結果を記載する
- 理由:Experience(経験)は、E-E-A-Tの最初のEです。試した人にしか書けない情報は価値になります。
- 方法:いつ、どの環境で、何をしたかを書き、つまずいた点も残します。
- 注意点:体験していないことを体験したように書いてはいけません。
4-7. 情報収集・調査方法を説明する
- 理由:Googleの「どのように」に対応します。
- 方法:参照した公式資料と確認日、検証環境、確認できなかった点を3〜5行で書きます。
- 注意点:確認できなかったことを隠さず書くほうが、信頼につながります。
4-8. 古い情報を適切に更新する
- 理由:古い情報が残ると読者を誤らせるおそれがあります。
- 方法:重要な記事は見直し時期を決めます(例:半年ごと)。公式情報が変わったら本文を直し、更新日を変えて変更点を添えます。
- 注意点:直せない記事は統合や削除を検討し、URLを変えるならリダイレクトも設定します。
4-9. 読者が内容を検証できるようにする
- 理由:読者が自分で確認できる状態が、総仕上げです。
- 方法:出典リンクを置き、設定画面の名称やバージョンを明記し、末尾に参考資料を並べます。
- 注意点:リンク切れは信頼を損ないます。定期的に確認します。
5. Webサイト全体でできる信頼性向上施策
この章の要点は、ページを増やすこと自体が目的ではないということです。「誰が、何のために運営しているのか」を読者が判断できる状態を作ります。ページを追加すれば順位が上がる、という性質のものではありません。
| 施策 | 載せる内容 | 注意点 |
|---|---|---|
| 運営者情報ページ | 運営者名、連絡手段、開始時期、目的 | 公開できる範囲を決める |
| 会社概要・事業内容 | 事業内容、所在地など | 確認できない情報は載せない |
| メディアポリシー | 運営目的、情報の集め方、訂正方針、広告 | 実態と一致させる(雛形は第9章) |
| 編集方針 | 制作・確認・更新のルール、AIの扱い | ポリシーに含めてもよい |
| 著者プロフィール | 担当分野、経歴(事実のみ) | 執筆者名からリンクする |
| お問い合わせ先 | 実際に返信できる窓口 | 見つけやすい位置に置く |
| プライバシーポリシー | 個人情報や解析の取り扱い | 法的要件は専門家に確認 |
| 記事から運営者情報への内部リンク | 記事末尾やサイドバーのリンク | 発信元に移動できるように |
| 運営目的の明確化 | 「誰の、どんな悩みを解決するか」を一文で | Googleの「なぜ」にも答えやすい |
6. WordPress(SWELL)で実践する具体的な方法
画面を見ながら設定できるよう、WordPress標準機能で行える内容と、SWELLやプラグインに依存する内容を区別して説明します。
ご注意:WordPress、SWELL、SEO SIMPLE PACKは更新されるため、メニュー名や配置が変わることがあります。SWELLの設定項目は、2026年11月6日にAFFICAMPの管理画面で確認した名称です。
6-1. 投稿者プロフィールを設定する(WordPress標準)
- 管理画面の「ユーザー」から、執筆者のプロフィール編集画面を開きます(自分なら「プロフィール」)。
- 「ニックネーム」を入力し、「ブログ上の表示名」で記事に表示する名前を選びます。
- 「プロフィール情報」に自己紹介を入力し、保存します。
ログインIDと表示名は分けましょう。 表示名がログインIDのままだと、セキュリティ面で好ましくありません。
6-2. 記事に著者情報を表示する(SWELL)
SWELLでは、記事の下に著者情報のエリアを表示できます。設定場所は、管理画面の「外観」→「カスタマイズ」→「投稿・固定ページ」→「記事下エリア」です(2026年11月6日にAFFICAMPの管理画面で確認)。
- 管理画面の「外観」から「カスタマイズ」を開く
- 「投稿・固定ページ」→「記事下エリア」を開く
- 「著者情報エリアの設定」にある「著者情報を表示」にチェックを入れる(「著者ページへのリンクを表示する」も選べます)
見出しは「著者情報エリアのタイトル」欄で変更できます(初期値は「この記事を書いた人」)。タイトルの下に著者名だけを出したい場合は、「投稿・固定ページ」→「タイトル」の「タイトル下に著者を表示する」を使います。プロフィール文がWordPressユーザーのどの項目から取られるかは、確認できていません。表示を有効にして、プレビューで確かめてください。
6-3. 公開日・更新日を表示する
WordPress標準では、公開日時は投稿編集画面の設定パネルで確認・変更でき、更新日は保存した時点で自動的に記録されます。SWELLでは、「外観」→「カスタマイズ」→「投稿・固定ページ」→「タイトル」で、タイトル横に表示する日付(公開日と更新日のどちらか)と、タイトル下に公開日・更新日を表示するかどうかを選べます。
運用では、両方を表示するか、どの程度の変更で更新日を変えるか、変更点を記事内に一行添えるかを決めておきましょう。
6-4. 運営者情報ページを作る(固定ページ)
- 「固定ページ」の「新規追加」を選ぶ
- タイトルを「運営者情報」にし、運営者名、目的、連絡手段、開始時期を入力する
- プロフィールやメディアポリシーへのリンクを追加する
- 下書き保存し、プレビューを確認してから公開する
6-5. メディアポリシーページを作る
作り方は運営者情報と同じ固定ページです。雛形は第9章を参考にし、公開後は「外観」の「メニュー」からフッターなどに追加します。
6-6. 引用元リンクを設置する
ブロックエディタで文字列を選択してリンクを設定します。リンクの文字は「こちら」ではなく資料名にします。広告やアフィリエイトを含む場合は、その旨も明示します。
6-7. 記事末尾に著者紹介を置く
6-2の表示が使えない場合は、共通の著者紹介をブロックとして用意する方法があります。ブロックを使い回せる「パターン」機能(以前は「再利用ブロック」と呼ばれていました)を使うと、複数の記事で同じ内容を表示できます。内容は、執筆者名、担当分野、プロフィールと運営者情報へのリンクです。
6-8. 内部リンクを整える
関連する話題が出た箇所に、移動先が分かる言葉でリンクを置きます。記事末尾の「次に読む記事」は数本に絞り、公開済みの記事のみにリンクします。あわせて、SWELL:記事投稿マニュアル、SWELL導入後の初期設定、Googleサーチコンソールの導入方法もご覧ください。
6-9. Article・BlogPosting構造化データを確認する
Google検索セントラルの「記事の構造化データ」では、必須プロパティはなく、ページに当てはまる推奨プロパティを追加する形とされています(要約経由の確認)。
| プロパティ | 内容 |
|---|---|
| headline | 記事のタイトル |
| image | 記事に関連する画像のURL |
| datePublished | 公開日時(ISO 8601形式) |
| dateModified | 更新日時(ISO 8601形式) |
| author | 著者(PersonまたはOrganization)、名前とURL |
著者は、表示されている人をすべて含め、複数なら別々に記述します。author.nameには名前だけを入れます。構造化データはページの内容を正しく表し、読者に見えない内容を記述しない、という一般ガイドラインもあります。ArticleとBlogPostingのどちらが有利かは、確認した公式情報からは断定できません。
6-10. 重複出力に注意する
AFFICAMPのサイトでは、SWELLが記事ページにJSON-LD形式の構造化データを出力していました(2026年11月6日にページのソースで確認)。種類はArticle、BreadcrumbList、Organization、WebSite、WebPageで、Articleには公開日・更新日・著者・発行者などが含まれていました。SEO SIMPLE PACKの説明ページでは、構造化データの記載は確認できませんでした(出力しないという意味ではありません)。追加で実装する前に、次の順で確認します。
- 記事を公開して表示を確認する
- リッチリザルトテストに記事のURLを入力する
- 検出された種類とプロパティを見る
- すでに出力されているなら、重ねて出力しない
このサイトで確認した範囲では、Articleは1つだけ出力されていました。お使いの環境では、リッチリザルトテストなどで確認してください。
6-11. リッチリザルトテストで確認する
リッチリザルトテストは、ページの構造化データを確認するGoogleのツールです。公開URLの入力か、コードの貼り付けで検査できます。「検出された」ことと「検索結果に特別な表示が出る」ことは別です。
7. AIライティングと情報発信プロセス
問われるのはAIの利用そのものではなく、コンテンツの目的と品質、人間の編集責任です。「AIで書いたから不利」という単純な話ではありません。
7-1. AIで作成した記事はGoogleに評価されるのか
Googleの生成AIコンテンツに関するページでは、生成AIは調査やオリジナルコンテンツの構造づくりに役立つとされています。一方、ユーザーに価値を加えずに生成AIで多数のページを作ることは、スパムポリシーの「スケールコンテンツの不正使用」の例に挙がっています。このポリシーは、どのように作られたかにかかわらず、利用者にほとんど価値がない大量のコンテンツを問題にしています。基準は作り方ではなく、目的と読者への価値です。
7-2. 利点と問題点
利点は、論点の洗い出しや下書きが速いことです。問題点は、一般論に寄りやすいこと、誤りや不正確な出典が混ざることです。
7-3. 誤情報への対策とファクトチェック
生成AIは事実を検索しているのではなく、言葉を予測して文章を作るため、もっともらしい誤りが含まれることがあります。Googleも、公開前に生成AIの内容を手作業で事実確認することを示しています。
- 数値、日付、固有名詞、制度名をすべて拾い出す
- 一つずつ公式資料で確認する
- 確認できないものは削除するか、断定を避ける
- AIが示したURLは、実在するか、内容が合っているかを自分で開いて確かめる
7-4. 人間の編集責任
AIは内容に責任を負えません。公開する以上、責任は運営者にあります。最終確認者を明確にしましょう。
7-5. AI利用の透明性をどう確保するか
Googleは、読者が「どのように作られたか」を気にしそうな場面では、制作方法の説明を勧めています。ただし、すべての記事に一律の開示が義務づけられている、と本記事は断定しません。 公式情報で確認できるのは、読者が制作過程を知ることに意味がある場合に、適切な形で伝えることが推奨されている、という点です。
開示の例(実際の運用に合わせて修正してください):
本記事は、構成案の作成にAIツールを使用し、内容の確認と編集は運営者が行っています。数値と制度の記述は、記載の公式資料で確認しています。
7-6. 独自の経験や一次情報を加える
自分が試した結果、相談で気づいた点、失敗談はAIだけでは作れません。ここを人間が加えることが、記事の独自性になります。
7-7. 大量生成のリスク
価値を加えないまま大量に公開すると、スパムポリシーの対象になるおそれがあります。小規模なサイトでは、本数より一つの記事の確認と更新を優先しましょう。
7-8. AIを利用した記事制作フロー
| 段階 | 作業 | 担当 | 確認すること |
|---|---|---|---|
| 1. 企画 | 検索意図と目的を決める | 人間 | 「なぜ」書くのか |
| 2. 調査 | 公式資料を直接確認する | 人間(AIは補助) | 出典URLと確認日 |
| 3. 下書き | 構成案や下書きを作る | AI | 事実を含むか |
| 4. 検証 | 数値・日付・固有名詞を確認する | 人間 | 公式資料と一致するか |
| 5. 追記 | 体験や検証結果を加える | 人間 | 事実のみか |
| 6. 編集 | 表現と構成を整える | 人間 | 不自然な文がないか |
| 7. 公開 | 執筆者、日付、出典を整える | 人間 | 設定漏れがないか |
| 8. 更新 | 定期的に見直す | 人間 | 古い情報がないか |
8. 中小企業・個人サイトのための優先順位
専任の編集部や監修者を置けない場合は、費用と作業負担の少ない順に進めるのが現実的です。
| 優先度 | 施策 | 負担の目安 |
|---|---|---|
| 1 | 執筆者名と公開日・更新日の表示 | 小 |
| 2 | 運営者情報とお問い合わせ先の整備 | 小〜中 |
| 3 | 主要記事への出典リンク追加 | 中 |
| 4 | 著者プロフィールページ | 小〜中 |
| 5 | メディアポリシーの公開 | 中 |
| 6 | 体験・検証結果の追加 | 大 |
| 7 | 構造化データの確認 | 中 |
まず、アクセスが多い、または問い合わせにつながる記事を3本選んで整えます。全記事を一度に直そうとすると、作業が止まりやすくなります。
9. メディアポリシーの雛形
以下は一例です。実際のサイトの運営体制、情報の集め方、AIの利用状況と一致するように、必ず修正してください。実態と異なる内容は、かえって信頼を損ないます。【 】は自社の情報に置き換えます。
【サイト名】 メディアポリシー
1. 運営目的
【対象読者】が【課題】を理解し判断できるよう、【テーマ】の情報を提供します。
2. 運営者
【運営者名・会社名】(運営者情報:【URL】)
3. 執筆・編集体制
記事は【執筆者の区分】が執筆し、【確認者の区分】が確認します。
執筆者情報は各記事とプロフィールページに掲載します。
4. 情報の収集と確認方法
制度や仕様は公式ドキュメントなどの一次情報を優先して確認し、
参照資料と確認日を記載するよう努めます。確認できない情報は断定しません。
5. AIツールの利用
【使う場合】構成案や下書きにAIを使うことがあります。
事実確認と最終編集は人間が行います。【使わない場合は削除】
6. 更新と訂正
【頻度】を目安に見直し、誤りは修正して必要に応じて訂正を記載します。
7. 広告・アフィリエイト
【有無と選定方針】
8. お問い合わせ
【問い合わせ先】
制定日:【年月日】 最終更新日:【年月日】
監修者が実際にいる場合だけ「監修」を残し、守れない言い切りは避けます。
10. 実践チェックリスト
自分のサイトの点検に使ってください。確認方法も添えています。
10-1. 記事単位
□ 誰が執筆したか分かる(冒頭か末尾に氏名があるか見る)
□ 執筆者名からプロフィールに移動できる(リンクをクリックする)
□ 公開日・更新日が表示され、実際の更新内容と合っている
□ 数値や制度の記述の近くに出典がある(リンク先を実際に開く)
□ 体験や独自の情報があり、調べ方も説明されている
□ AIを使った場合、人間が確認した記録がある
10-2. サイト全体
□ 運営者情報が掲載され、フッターなどから行ける
□ お問い合わせ先に、実際に返信できる体制がある(テスト送信する)
□ メディアポリシー・編集方針を確認できる
□ 必要な著者・監修者情報が掲載されている(実在の人物のみ)
□ プライバシーポリシーが実態と合っている
□ 記事から運営者情報への内部リンクがある
□ 構造化データが重複していない(リッチリザルトテストで確認)
10-3. 改善の優先順位
第8章の表の順に進めます。まず、アクセスの多い記事3本の執筆者名・日付・出典を整え、次に運営者情報と問い合わせ先、最後にメディアポリシーと構造化データを確認します。
11. まとめ:信頼は「確認できる状態」の積み重ね
この記事のポイントを整理します。
- 情報発信プロセスは公式用語ではなく、信頼性を整理する枠組みです。5W1Hは点検用で、Googleのランキング要因ではありません。
- Googleは「誰が・どのように・なぜ」を問うことを勧めており、E-E-A-Tでは信頼性が中心です。単独のスコアではありません。
- 記事では日付・執筆者・出典・調査方法を、サイトでは運営者情報・問い合わせ先・メディアポリシーを示します。
- 問題になるのはAIの利用ではなく、価値のない大量生成と確認の省略です。
- WordPressは標準機能で整えられる部分が多くあります。SWELLなどの画面は更新されるため、ご自身の環境で確認してください。
信頼される記事は、確認できる状態を一つずつ増やし、定期的に見直すことで形になります。
AFFICAMPへのご相談について
AFFICAMPは、WordPressを活用したホームページ制作、ブログ制作、SEOを意識したWebサイト設計を行っています。次のようなお悩みがあれば、お気軽にご相談ください。
- ホームページを作りたい
- SEOを意識したブログを始めたい
- 既存サイトの構成を改善したい
- 信頼性のある企業サイトを制作したい
- WordPressの設定や運用に不安がある
現状を確認したうえでご提案します。まずは、今のお悩みをお聞かせください。

