WordPressでヒートマップを使うには?導入前の比較と、テーマ変更後の点検

公開 更新 14 分で読了
WordPressでヒートマップを使うには?導入前の比較と、テーマ変更後の点検

WordPressでヒートマップを使うための選定条件を解説。プラグイン・GTM・コード設置の違い、固定目次やフォーム、キャッシュ、管理者除外を試用要件表で確認できます。

WordPressにヒートマップを入れたいと思ったら、最初に決めるのは改善したいページです。

記事の途中で読まれなくなる場所を探すのか、問い合わせボタンが押されない理由を探すのかで、必要な機能は変わります。

WordPress向けのヒートマップは、料金だけでなく、自分のテーマで正しく表示され、更新後も計測を続けられるかで選びましょう。

この記事では、導入前の比較項目と、テーマ・フォーム・キャッシュを含めた試用方法を整理します。

最後に、候補ツールへ同じ条件を当てはめられる試用要件表も用意しました。

2026年10月5日時点の公式資料を参考にした検証手順であり、特定のWordPress環境での動作を保証するものではありません。

WordPressでヒートマップを使う目的

記事と販売ページで目的を分ける図

すべてのページを眺めるよりも、調べたいことが明確なページから始めると、改善案を作りやすくなります。

最初は、代表的な記事と、問い合わせや購入につながるページを分けて選びます。

投稿と販売ページを分ける

記事ページでは、知りたい情報までたどり着けるか、目次から必要な見出しへ移動できるかを調べます。

一方、販売ページでは、料金・利用条件・実績などを確認した後、申し込みへ進めるかを調べます。

同じスクロール率でも、読者が途中で答えを見つけた記事と、購入条件に届かない販売ページでは意味が異なります。

最初の調査メモには、ページの役割と、読者にしてほしい次の行動を一文で書いてください。

例えば、説明用の仮想例として、次のように整理できます。

対象 調べたいこと 次の行動
比較記事 比較表までたどり着けるか 詳細な解説を開く
サービス紹介 利用条件を確認できるか 問い合わせへ進む
商品ページ サイズや送料が分かるか カートへ追加する

「滞在を長くする」だけを目標にすると、迷って操作が増えた状態まで良い結果と扱ってしまいます。

問い合わせを短い操作で完了できたなら、滞在が短くても目的を果たした可能性があります。

ヒートマップは、その行動を理解するための材料として使いましょう。

必要なヒートマップの種類を決める

クリックヒートマップは、ボタンやリンクなどが押された場所を確認するのに向いています。

スクロールヒートマップは、ページのどの深さまで表示されたかを調べるのに向いています。

例えばClarityは、クリックマップとスクロールマップを提供しています(参考:Clarityのヒートマップ機能)。

ただし、スクロールしてその位置に到達したことと、文章を読んで理解したことは同じではありません。

アテンションや滞在を表す機能も、計測方法と分母を確かめてから使います。

ツール選定時は、色の種類よりも「この問いに答えられるか」で必要な機能を整理すると迷いにくくなります。

ボタンが押されない理由を調べるなら、位置と到達状況に加えて、操作の前後を見られる録画が役立ちます。

画像が何度も押される場面なら、リンクと誤解されているのか、拡大操作を期待しているのかを録画で確認します。

WordPress向けヒートマップの選定条件

設置方法と運用条件を比較する図

WordPressで使う場合は、計測サービスそのものと、サイトへ設置する方法を分けて考えます。

専用プラグインがあることだけで、比較を終えないようにしましょう。

設置方法と更新のしやすさを見る

主な設置経路には、専用プラグイン、GTMなどのタグ管理、管理されたコード設置があります。

どれを選んでも、設定場所と変更担当者が分かる状態にすることが大切です。

設置方法 向いている運用 導入前の確認
公式プラグイン WordPress管理画面で設定をまとめたい 提供元・更新状況・対応環境
GTM 他の計測タグも一緒に管理している 公開権限・発火条件・同意連携
管理されたコード設置 開発担当が配置と条件を管理する 更新時の維持・除外条件・戻し方

ClarityにはMicrosoftが提供するWordPressプラグインがあり、公式ディレクトリで提供元や更新履歴を確認できます(参考:Microsoft Clarityプラグイン)。

GTMでの設置を選ぶ場合は、WordPressへGTMを入れる経路と、そのGTMからClarityなどを配信する設定の両方を管理します。

すでにGTMから配信しているタグを、専用プラグインでも追加しないようにします。

親テーマのファイルを直接書き換えた変更は、テーマ更新で失われる可能性があります(参考:WordPressの子テーマ)。

子テーマを使う場合も、別のテーマへ切り替えたら同じコードが必ず残るわけではないため、変更後の確認は必要です。

WordPress.comを利用している場合は、プラグインを使える契約条件も先に確認します(参考:WordPress.comのプラグイン案内)。

料金以外の条件を確認する

無料のツールでも、対象ページ・保持期間・共有方法が自社の運用に合うかを確認します。

例えばClarityは無料でヒートマップと録画を使える候補ですが、保存期間や動的表示の制約まで無制限という意味ではありません。

Clarityの通常録画は30日間、ヒートマップは9か月間など、データの種類で保持期間が異なります(参考:Clarityのデータ保持)。

月次の報告会で先月の録画を使うなら、確認する日と保存の扱いまで決めておく必要があります。

一方、分析後のページ編集やA/Bテストもまとめたい場合は、それらを提供するサービスが比較候補になります。

Ptengineはヒートマップ、A/Bテスト、Web接客などを案内しているため、必要機能が使える契約条件を確認する入口になります(参考:Ptengine公式サイト)。

この違いは優劣ではなく、分析だけを行うのか、施策の実装まで同じ環境で行うのかという運用範囲の違いです。

候補ごとに、対象URL数、計測量、保存期間、ユーザー権限、社外共有、サポート窓口を同じ表に記入します。

請求の単位がPVなのかセッションなのかも確認し、実際のアクセス量へ当てはめて比較してください。

WordPress固有の画面を試用する

固定要素とフォームを試す図

デモサイトできれいに表示されても、自社のテーマやプラグインの画面で同じように見えるとは限りません。

導入前の試用では、普段の読者が使う操作を一通り実行します。

テーマの固定要素を確認する

固定ヘッダー、追従目次、画面下のCTA、モバイルメニューを一覧にします。

これらはスクロールやタップによって位置や表示状態が変わるため、通常の本文と分けて点検します。

最初の試験では、次の順で操作すると、画面の変化を追いやすくなります。

  1. ページを先頭から開き、初期表示を確認する
  2. 目次のリンクから途中の見出しへ移動する
  3. 固定ヘッダーやCTAが出る位置までスクロールする
  4. モバイルメニューを開閉する
  5. 同じ訪問の録画と、対象ページのヒートマップを確認する

Clarityには、開閉するメニューなどの動的部分をヒートマップへ表示できない制約があります(参考:動的要素に関する制約)。

メニューが写っていないヒートマップにクリックだけが重なって見えるなど、表示が不自然な場合は、集計対象の状態を確かめます。

クリックが重なっている場所をすぐに改善対象とせず、実画面と対応しているかを先に確認してください。

また、追従する目次が本文の上に重なる場合は、見出しが隠れていないかも実際の操作で点検します。

フォームと会員ページを確認する

フォームは、入力前・エラー表示・入力内容の確認・完了の各状態を分けて試します。

送信ボタンを押せることだけでなく、何を直せば送信できるのかが分かるかを見ます。

入力エラーには、問題のある項目と修正方法が伝わる案内が必要です(参考:W3Cのフォーム通知ガイド)。

録画の試験にはダミーの情報を使い、入力欄だけでなく、確認画面に表示された文字も隠れるかを点検します。

Clarityのマスキングは新しく取得する記録への設定なので、本物の情報が入る前に確認します(参考:Clarityのマスキング設定)。

会員ページでは、ログイン後に名前・購入履歴・限定コンテンツが表示される範囲を洗い出します。

分析する必要がないページは対象外にするなど、記録範囲そのものを先に決めてください。

外部サービスを埋め込んだフォームは、親ページの録画で内容まで再現できない場合があるため、フォーム側の計測と分けて確認します。

確認結果には「録画で分かる操作」と「フォーム管理側で確認する結果」を書き分けます。

WordPressの表示変更に備える

変更前後のページとキャッシュを点検する図

記事の追記やテーマ変更は、ヒートマップの読み方にも影響します。

同じURLのまま見た目を変えた場合ほど、いつ何を変えたかを残しておきます。

レイアウトの変更日を残す

テーマ名とバージョンに加えて、本文の並び順、画像、ボタン、目次の変更を記録します。

変更日だけでなく、公開した時刻と、計測設定を変更したかどうかも残すと比較に役立ちます。

例えば、説明用の仮想例として、料金表を記事の後半から前半へ移した場合を考えてみましょう。

変更前のページで取得したスクロール深度と、変更後のページで取得した深度は、同じ割合でも指している内容が違います。

「以前より下まで読まれた」と書く前に、その位置に何があったのかを確かめる必要があります。

レイアウト変更後は、ヒートマップの期間を変更日以降に絞り、背景に使われる画面も確認してください。

Clarityではヒートマップのスクリーンショットを変更する機能があるため、表示状態を確認する手がかりになります(参考:ヒートマップのスクリーンショット変更)。

背景を切り替えたことと、過去の操作データが新しいレイアウトへ正しく変換されたことは別です。

比較資料には、期間とページの版が分かるメモを添えましょう。

キャッシュの影響を調べる

WordPressでは、プラグイン・ホスティング・ブラウザなど、複数の場所にキャッシュがある場合があります。

キャッシュは表示を速くする仕組みですが、設定変更後に古いページやコードが配信されていないかを確認する必要があります(参考:WordPressのキャッシュ)。

管理者として見たページが新しくても、未ログインの読者へ同じものが届いているとは限りません。

計測タグを変更した後は、通常の閲覧者の状態でも対象ページを開きます。

点検は、次のように変更箇所を絞って進めると原因を追いやすくなります。

  1. 変更したタグ・テーマ・プラグインと時刻を記録する
  2. 対象ページを未ログインの状態で開く
  3. 新しい表示と正しいプロジェクトへの送信を確認する
  4. 古い状態が残る場合は、担当者が対象のキャッシュを更新する
  5. 同じ操作を再度試して結果を残す

JavaScriptを遅延させる最適化設定がある場合は、操作前と操作後で計測開始のタイミングが変わらないかも調べます。

一度にすべての高速化機能を止めるのではなく、設定と症状の関係を確かめて変更します。

WordPressの計測を運用する

タグ管理と管理者の操作を分ける図

導入後のトラブルを減らすには、タグの担当者と変更場所を明確にします。

編集者が記事を更新する作業と、計測設定を変更する作業を分けることも大切です。

タグを一か所で管理する

同じツールのタグは、どの経路から配信しているのかを一つの台帳へまとめます。

プラグイン、GTM、テーマの設定欄、コード用プラグインを順番に確認し、重複がないか調べます。

台帳には、ツール名・接続先ID・設置場所・対象ページ・同意条件・担当者を記録してください。

GTMで管理している場合は、作業中の設定と公開済みの設定が異なるため、公開したバージョンも残します(参考:GTMの公開とバージョン)。

プラグインで管理している場合は、テーマ更新時とは別に、そのプラグインの更新も確認対象へ入れます。

WordPressの自動更新機能についても、実行後に通知や状態を確認する運用を決めます(参考:プラグインとテーマの自動更新)。

設定を移行する際は、旧経路の停止と新経路の確認を一つの作業として扱います。

新しい経路だけを追加すると、古い経路が残ったまま原因を調べることになりかねません。

管理者の操作を分ける

WordPressの編集者や管理者は、記事の確認のために何度も同じページを開きます。

その操作が分析に混ざると、目次やボタンが実際以上に使われているように見える場合があります。

除外したいのが社内担当者なのか、ログイン利用者全員なのかを先に決めてください。

WordPressには管理者・編集者・購読者など異なる権限があるため、ログインしていることだけで社内利用とは判断できません(参考:WordPressの権限と役割)。

会員サイトで「ログイン中はすべて除外」にすると、分析したい会員の行動も記録できなくなります。

開発担当が条件分岐を実装する場合も、ログイン判定と権限判定を混同しないようにします(参考:WordPressのログイン判定)。

除外設定の確認では、管理者・一般会員・未ログインの三つの状態で同じ公開ページを開き、想定どおり記録が分かれるかを試します。

IPアドレスによる除外を使う場合は、在宅勤務やVPNなどで接続元が変わる点も確認項目に入れます。

分析画面で後から絞り込む方法と、最初から送信しない方法は異なるので、どちらを採用したかも台帳に記載します。

WordPressのヒートマップ導入を決める

同じページで候補を試すための要件表

候補が絞れたら、同じページと同じ操作で比較します。

製品ごとの見た目の違いよりも、必要な事実が確認できたかを採用の基準にします。

同じページで候補を試す

次の表は、WordPress用ヒートマップの試用要件表です。

確認結果は「可・条件付き・不可・未確認」で記入し、条件付きの場合は使える範囲を具体的に残します。

確認項目 試す操作 残す結果
記事の基本表示 先頭から本文末まで移動 見出し・画像・クリックの位置
固定要素 目次・追従CTA・メニューを操作 表示状態と録画の一致
フォーム エラーから修正して完了へ進む 再現できる範囲とマスキング
会員ページ 一般会員と管理者で開く 記録対象と除外条件
更新後の計測 テーマや配置を変更して確認 記録継続と版の識別
継続運用 月次報告と共有を想定する 保存期間・権限・担当者

候補を同時に大量に設置すると、比較のための負荷が通常運用と異なることがあります。

試験環境や限定した範囲で条件をそろえ、どのツールを有効にした状態で確認したかを残してください。

表示速度については、タグの有無以外に画像・キャッシュ・端末・回線もそろえて比較します。

気になる点があれば、対象ページと操作手順を添えて提供元へ確認し、回答を要件表へ反映します。

専用の設置記事へ進む

Clarityを選ぶ場合の大まかな流れは、公式プラグインのインストールと有効化、Clarityへのサインイン、既存または新規プロジェクトへの接続です(参考:ClarityのWordPress公式手順)。

ただし、プラグインを有効にしただけで作業完了とせず、公開ページを開いて記録を確認します。

具体的な設置順序と二重設置の確認は、WordPressへのClarity導入手順で説明します。

すでにGTMで計測をまとめている場合は、ClarityのGTM導入手順も確認してください。

最初の一週間は、数値を良くすることよりも、見たいページと操作が正しく記録されるかの確認に使います。

その後、読まれない情報や押しにくい導線を一つ選び、変更した日と結果を残します。

WordPressのヒートマップ導入は、インストールよりも、更新後も使い続けられる条件を整えることが重要です。

よくある質問

Q. WordPressでは無料のヒートマップを使えますか?
Clarityなどが候補ですが、保存期間や動的な表示への対応も確認して選びます。
Q. 専用プラグインとGTMは両方必要ですか?
同じ計測タグを複数の経路から配信しないよう、既存の設置状況を確認して管理方法を決めます。
Q. テーマを更新すると計測は必ず止まりますか?
必ず止まるわけではありませんが、直接変更したファイルや表示構造が変わる場合があるため更新後の確認が必要です。
Q. 管理者だけ除外すれば会員は記録できますか?
除外する条件が権限なのかログイン状態なのかを確認し、一般会員まで除外していないかを実際に試します。
Q. どのページで比較すればよいですか?
代表的な記事と販売ページを選び、固定要素・フォーム・スマホ表示を同じ操作で比較します。

出典・参考データ

  1. [1] Clarityのヒートマップ機能 (Microsoft) — 取得 2026-10-05
  2. [2] Microsoft Clarityプラグイン (wordpress.org) — 取得 2026-10-05
  3. [3] WordPressの子テーマ (developer.wordpress.org) — 取得 2026-10-05
  4. [4] WordPress.comのプラグイン案内 (wordpress.com) — 取得 2026-10-05
  5. [5] Clarityのデータ保持 (Microsoft) — 取得 2026-10-05
  6. [6] Ptengine公式サイト (www.ptengine.jp) — 取得 2026-10-05
  7. [7] 動的要素に関する制約 (Microsoft) — 取得 2026-10-05
  8. [8] W3Cのフォーム通知ガイド (www.w3.org) — 取得 2026-10-05
  9. [9] Clarityのマスキング設定 (Microsoft) — 取得 2026-10-05
  10. [10] ヒートマップのスクリーンショット変更 (Microsoft) — 取得 2026-10-05
  11. [11] WordPressのキャッシュ (developer.wordpress.org) — 取得 2026-10-05
  12. [12] GTMの公開とバージョン (Google) — 取得 2026-10-05
  13. [13] プラグインとテーマの自動更新 (wordpress.org) — 取得 2026-10-05
  14. [14] WordPressの権限と役割 (wordpress.org) — 取得 2026-10-05
  15. [15] WordPressのログイン判定 (developer.wordpress.org) — 取得 2026-10-05
  16. [16] ClarityのWordPress公式手順 (Microsoft) — 取得 2026-10-05

この記事を書いた人

水島 翔吾

株式会社kairos 代表取締役 / AgentSignal 開発者

AI クローラー・AI 流入計測と AIO 診断ツール AgentSignal を開発。実測データを元に AI 検索時代の計測と対策を書いています。

関連記事