サイトの信頼性を高める方法というと、コンテンツに焦点を当てたものが一般的です。実体験に基づく情報、専門知識を持つ執筆者、独自の調査、そしてAIを活用する場合でも人間が関与することなどが重視されます。

もちろんいずれも重要ですが、検索エンジンやAI検索エンジン、そしてサイト訪問者は、コンテンツにたどり着く前に別のシグナルも読み取っているという点は見落とされがちです。サイト速度、稼働率、セキュリティ、エラー率などがその一例で、これらはサイトを支えるインフラによって左右されます。また、サイトのリニューアル時などに一度評価されるだけではなく、継続的に評価されています。

今回は、サイトの信頼性を左右するシグナルとその評価方法、MyKinstaで確認する方法について解説していきます。

信頼性には、コンテンツより先に評価される「技術的な側面」がある

E-E-A-T(Experience=経験、Expertise=専門性、Authoritativeness=権威性、Trustworthiness=信頼性)は、Googleの検索品質評価ガイドラインに由来する考え方で、ページの品質を評価し、検索ランキングの仕組みに反映するために用いられています。

コンテンツに関する一般的なアドバイスでは、最初の3つが取り上げられることが多いですが、Googleが最も重要としているのは「信頼性」です。そして信頼性を左右するのは、コンテンツの正確さだけではありません。

  • 安全なインフラ:HTTPSは一度設定して終わりではなく、SSL証明書の有効期限切れを防ぎ、常に安全な接続を維持する必要がある。
  • 安定した稼働率:クローラーがアクセスできないページは、信頼できるページとして評価することができない。
  • 高速で安定したパフォーマンス:サイトのリニューアル時などに一度確認するだけでなく、継続的に良好な状態を維持することが重要。

サイトのパフォーマンスは、GoogleのCore Web Vitalsを通じて評価されます。Largest Contentful Paint(LCP)、Interaction to Next Paint(INP)、Cumulative Layout Shift(CLS)はいずれも、Chrome User Experience Reportで収集された実際の訪問者のデータに基づく指標です。3つすべての指標で、実際の訪問の75%が「良好」の基準を満たして初めて合格と判定されます。

つまり、コンテンツを一切変更していなくても、実際のサイトパフォーマンスの変化によって、技術面での信頼性に対する評価が変動します。

AI生成コンテンツの普及で技術的なシグナルの重要性が高まる理由

コンテンツを以前より簡単かつ低コストで制作できるようになったことで、サイトの信頼性を示すシグナルの意味も変化しています。執筆者の経歴や実体験、一次情報などは今でも重要であり、他のコンテンツとの差別化につながりますが、これらは簡単に偽装できてしまう要素でもあります。

たとえば、架空の経歴であっても、本物と見分けがつかないように見せることは可能です(人の目で確認しない限り)。しかし、技術的なシグナルはそうはいきません。

  • 安定した稼働率:後から作り出せるものではなく、継続的な安定稼働によって積み重ねていくもの。
  • セキュリティ上の問題がないこと:一度でもマルウェアを配信してしまえば、その事実を後からなかったことにはできない。
  • LCPを継続的に2.5秒未満に維持:高速なインフラに加えて、それを長期にわたって安定して運用する体制が必要。

こうしたシグナルを積み上げるには時間やリソース、そしてそれに伴うコストがかかります。だからこそ偽装することが難しく、対策を怠ってきた場合には短期間で追いつくことも容易ではありません。

質の高いコンテンツだけに注力するよりも、コンテンツとそれを支える技術的なインフラの両方を強化することで、サイトの信頼性という点でより大きな優位性を築くことができます。

サイトの信頼性を損なう3つの瞬間

サイトの信頼性は、徐々に低下するというより、いくつかの特定の出来事をきっかけに大きく損なわれる傾向があります。ただし、それを目にするのが検索クローラー、AIシステム、サイト訪問者のいずれであるかによって、その影響は異なります。

いずれの場合も、最初に起こる出来事(サイトの停止、表示速度の低下、セキュリティ警告)そのものより、その後サイトの信頼性にどのような影響が及ぶかが重要です。

サイト停止の影響はダウンタイムだけではない

サイト停止は、ステータスページに表示される「何分間停止したか」で評価されることが一般的ですが、停止中に訪問者やクローラーがどのような行動を取るかの方が重要です。その反応によって、サイト停止がもたらす影響は変わってきます。

  • 訪問者:サイト停止中にアクセスした訪問者は、サイトの信頼性に疑問を持ち、ページを閉じて、同じ商品や情報を別のサイトで探す可能性がある。しかも、なぜ離脱したのかを把握できないことも少なくない。
  • Googlebot:短時間の停止であれば、翌日などに再度アクセスするため大きな問題にはならないが、エラーが数日以上続くと、ページが存在しなくなったと判断され、Googleのインデックスから削除されることがある。
  • AIクローラー:キャッシュされたインデックスではなく、リアルタイムでページを取得することが多いため、Googlebotよりもタイムアウトの影響を受けやすい傾向がある。この場合、検索順位ではなく、AIによる引用・参照の機会を失う可能性がある。

訪問者の離脱による影響は、数週間後にコンバージョン率がわずかに低下するなど、原因がわかりにくい形で現れることがあります。そもそも、その変化に気づけない可能性もあります。一方、検索への影響は比較的把握しやすく、数日間にわたるサイト停止であればアクセス解析から変化を確認できます。それでも、サイトを安定した状態に戻した後、その影響の全体像を把握するまでには数ヶ月かかることがあります。AI検索については、初期の調査によると、クローラーからのリクエストの75%以上でページ取得に失敗したサイトは、安定してアクセスできるサイトと比較して、引用される回数が約18分の1だったことが示されています。

制作会社向けWordPress監視ツールを提供するWP Umbrellaも、サービスを提供する側としてこうした問題を経験していました。Kinstaに移行する前に利用していたサーバーでは、サイト停止が繰り返し発生し、アクセスが集中する時間帯にはページの表示速度も目に見えて低下していました。サイトの信頼性を支えるサービスを提供する同社にとって、これらの問題はSEOとユーザー体験の両方に影響を及ぼしていました。同社は、「WordPress管理ツールを提供する企業として信頼を得るには、サイトが非常に高速に表示され、いつでもアクセスできる状態が必要不可欠」と語っています。

ページの表示が遅ければ、コンテンツを読んでもらう前に訪問者を失う

サイト停止とは異なり、ページの表示速度が遅くても、明確なエラーメッセージが表示されるわけではないため、その影響を過小評価しがちです。しかし、訪問者にとっては、サイトに掲載された専門知識や実績、コンテンツなどに触れる前に、ページが表示されるまでの待ち時間そのものがサイトの第一印象になります。

この第一印象がもたらす影響は、以下のような複数の調査結果にも表れています。

Vodafoneのテストで注目したいのは、2つのページで変更されたのが読み込み速度だけだったという点です。つまり、インフラに左右されるページの表示速度だけでも、訪問者の信頼を損なう要因になり得ることがわかります。

セキュリティ警告は一瞬で信頼を搈ね、回復にも時間がかかる

サイトが停止していたり、ページの表示が遅かったりしても、訪問者にはそのまま待つ、あるいは後でもう一度アクセスするという選択肢があります。しかし、ブラウザに「このサイトは危険な可能性がある」と警告されれば話は別。そのまま閲覧を続けるユーザーはほぼいないでしょう。さらに厄介なのは、問題を解決した後も検索結果に警告が表示され続ける可能性があり、サイトの評判への影響が長引くことです。

WordPressサイトはこうしたリスクにさらされやすい傾向がありますが、それはWordPress自体の安全性が低いからではなく、ウェブ上で非常に広く利用されているためです。Patchstackの「State of WordPress Security in 2026」では、次のようなデータが報告されています。

  • 2025年には、WordPressエコシステム全体で11,334件の新たな脆弱性が発見され、前年比で42%増加。
  • そのうち91%はWordPressコアではなく、プラグインで発見されたもの。
  • 脆弱性が公開されてから実際に悪用されるまでの加重中央値は5時間。特に攻撃対象となった脆弱性の20%は、公開から6時間以内に悪用されている。

この「悪用されるまでの時間」は、セキュリティ対策を考えるうえで非常に重要です。たとえば、月に一度まとめてアップデートを行っている場合、わずか5時間で悪用される可能性のある脆弱性には十分に対応できないことになります。

ISO 27001認証、およびオランダ政府のBIO認証を取得しているWordPress制作会社のStuurluiは、こうしたリスクを回避することを前提にサービスを構築しています。同社では、セキュリティをパフォーマンス、アクセシビリティと並ぶ3つの柱の一つと位置付け、制作するすべてのサイトで欠かすことのできない要素として取り入れています。「お客様が求めているのは、優れたパフォーマンスを発揮し、最高水準のセキュリティ基準とアクセシビリティガイドラインを満たした、信頼性の高いサイトです。この3つの柱は、私たちの取り組みの根幹を成しています」

MyKinstaでサイトの信頼性を示すシグナルを確認する方法

ここまで、サイトの信頼性がどのような場面で損なわれるのかを見てきました。

重要なのは、顧客からの苦情や検索順位の低下が起きてから問題に気づくのではなく、日頃からサイトの状態を確認しておくことです。MyKinstaでは、「稼働率」「パフォーマンス」「セキュリティ」という3つの観点から、サイトの信頼性にかかわるシグナルを直接確認できます。

稼働状況の監視

Kinstaでは、サイトの稼働状況を3分ごとに監視します(1日480回)。サイトが利用できる状態を安定して維持することは、パフォーマンスやセキュリティなど、その他の信頼性シグナルを支える前提となります。

MyKinstaのユーザー設定「通知」画面でWordPressサイトの監視をオン/オフ可能
MyKinstaのユーザー設定「通知」画面でWordPressサイトの監視をオン/オフ可能

MyKinstaの「ユーザー設定」>「通知」の「WordPressサイトの監視」をオンにすると、以下の3つの重要な項目について通知を受け取ることができます。

  • サイトエラー:サイト自体で問題が検出された場合に通知
  • SSLエラー:証明書や設定に問題が検出された場合に通知し、訪問者への影響を未然に防ぐ
  • ドメインの有効期限:ドメインの有効期限が切れる前に通知

通知は3回連続でチェックに失敗した場合にのみ送信されるため、一時的な問題による不要な通知を抑えることができます。有効にしておけば、顧客からの連絡で初めて問題を知るのではなく、Kinstaが問題を検出したタイミングで把握できます。

通知を受け取ったら、まずは「分析」画面の「レスポンス」タブでエラーコードの内訳を確認します。ここでどのようなエラーが発生しているのかを把握してから、詳しい原因を調査することができます。

パフォーマンスデータ

サイトが遅いと感じても、データがなければ原因を正確に特定するのは困難です。「サイト」>(サイト名)>「分析」画面の「パフォーマンス」タブでは、推測ではなく実際のデータからページの表示速度低下につながっている要因を確認できます。

  • PHP+MySQL平均応答時間:キャッシュされていない各リクエストについて、アプリケーションの処理やデータベースへのクエリにかかった時間を確認可能。最近になって応答時間が急増している場合は、いつ頃からパフォーマンスが低下したのかを特定する手がかりに。
  • アップストリーム時間最大値上位:サイト内で特に処理に時間がかかっているパスを確認でき、平均応答時間を押し上げている特定のページやエンドポイントを絞り込むことができる。

問題のあるページを絞り込んだら、Kinsta APMを使用して、遅延の原因となっている特定のプラグインやデータベースクエリを突き止めることができます。2〜24時間の監視期間を設定してAPMを有効にし、問題を再現した後、「トランザクション」「WordPress」「データベース」「外部」の4つの項目から結果を確認します。

Kinsta APM
Kinsta APM

Largest Contentful Paint(LCP)の低下は、コードではなくキャッシュに問題があることも少なくありません。「分析」画面の「キャッシュ」タブでは、すべてのリクエストがHITBYPASSMISSに分類されます。正常にキャッシュが機能しているサイトでは、HITが大部分を占めるのが理想的です。

MyKinstaの分析画面で確認できるサーバーキャッシュの構成内訳
MyKinstaの分析画面で確認できるサーバーキャッシュの構成内訳

BYPASSの割合が増えている場合は、「サーバーキャッシュ除外上位パス」セクションで、キャッシュをバイパスしている具体的なパスを確認できます。サイト全体を作り直すよりも、こうした問題を特定して対処するほうが、Core Web Vitalsの改善につながる近道になることが少なくありません。

Core Web Vitalsを自動でチェックしたい場合は、Kinsta APIでサイトのURLを取得し、PageSpeed Insights APIに送信することもできます。各指標が設定したしきい値を下回った時点で通知する仕組みを構築すれば、定期的な手動チェックを継続的な早期検知の仕組みに変えることができます。

セキュリティ

KinstaではすべてのプランでCloudflare統合を標準提供しており、コードインジェクション、SQLインジェクション、レイヤー7 DDoS攻撃などのトラフィックをサーバーに到達する前にフィルタリングします。「サイト」>(サイト名)>「ボット対策」では、こうしたトラフィックの状況を直接確認し、設定を調整できます。

MyKinstaの「ボット対策」画面
MyKinstaの「ボット対策」画面

SSL証明書、マルウェアスキャン、ボット対策をはじめとするセキュリティ対策をすり抜けて問題が発生した場合でも、マルウェアセキュリティ保証により、追加料金なしでマルウェアの除去を依頼できます。

また、コンプライアンス要件への対応が求められる企業にとっては、KinstaのSOC 2 Type II報告書やISO 27001認証も判断材料の一つになります。Trust Centerページでは、これらの第三者機関による評価を確認でき、Kinstaのセキュリティ対策や管理体制が適切に運用されていることを確認できます。

セキュリティ認証に関連するバッジや情報を確認できるKinstaのTrust Centerページ
セキュリティ認証に関連するバッジや情報を確認できるKinstaのTrust Centerページ

サーバー環境もサイトの信頼性を支える重要な要素

コンテンツの信頼性はもちろん重要ですが、そのコンテンツは常に技術的な基盤の上にあり、両者は並行して評価されています。どれほど優れたコンテンツを制作しても、サイトの表示が遅かったり、頻繁にアクセスできなくなったり、セキュリティ上の警告が表示されたりすれば、積み上げてきた信頼性を損ないかねません。

コンテンツ戦略を見直す前に、まずは3つのポイントを確認してみてください。サイト停止を検知する通知が適切に設定されているか、実際のパフォーマンスデータでCore Web Vitalsの状態を確認できているか、そして問題が発生してから対応するのではなく、継続的にサイトを保護するセキュリティ対策が整っているかです。

Kinstaが提供するWordPress専用マネージドクラウドサーバーでは、稼働状況の監視、パフォーマンスを支えるインフラ、セキュリティ対策をそれぞれ個別に管理するのではなく、WordPressサイトを支える一つの環境としてまとめて利用できます。ご興味がありましたら、是非一度お試しください。気軽にお試しいただける初月無料プランもご用意しています。

Joel Olawanle Kinsta

Kinstaでテクニカルエディターとして働くフロントエンド開発者。オープンソースをこよなく愛する講師でもあり、JavaScriptとそのフレームワークを中心に200件以上の技術記事を執筆している。