ユニバーサル アナリティクス（以下UA）の停止が発表されました。Google アナリティクス 4（以下GA4）への移行を迫られています。
7月1日以降、UAはデータ収集を停止し、さらに半年後にはデータが削除され、閲覧もできなくなりそう。

2023 年 7 月 1 日をもって、標準のユニバーサル アナリティクス プロパティにおける新しいヒットの処理は停止されます。 現在ユニバーサル アナリティクスをご利用のお客様には、Google アナリティクス 4 を使用するための準備をしていただくことをおすすめします。

ユニバーサル アナリティクスのサポートは終了します
support.google.com/analytics/answer/11583528?hl=ja&ref_topic=10094551

「今までのデータはどうなるの？」
「コロナ前と後の比較とかできなくなっちゃうの？」
「とにかく、UAのデータをバックアップしなくちゃ！」

アナリティクスヘルプをみると、データのエクスポートには3つの方法が提示さています。

1. レポートを個別にエクスポート
2. GA Reporting APIを使用
3. BigQueryを使用（GA360利用の場合）

でも、この3つの方法だけではありません。
ウェブ通おススメの方法はこちら。

4. バックアップ専用ツール「Analytics Backup by QA」を利用

ユニバーサルアナリティクスをバックアップする4つの方法をそれぞれ簡単に説明します。

1. レポートを個別にエクスポート

UAの機能を使って、データをエクスポートします。

（参考）レポートのエクスポートと共有
support.google.com/analytics/answer/1038573

形式はCSV、TSV、TSV 形式（Excel）、Excel（XLSX）、Google スプレッドシート、PDFから選べます。

あらかじめ、必要なレポートや期間を設定し、画面に表示させてからエクスポートします。
手動での作業なので、管理するサイトが多い場合や必要なデータが多い場合は手間がかかります。

Googleスプレッドシートのアドオンを使うと、最新データを自動で取得できます。

（参考）アナリティクスのデータをスプレッドシートに移動する
support.google.com/a/users/answer/9308667?hl=ja

基本は表データなので、数字が並ぶだけのデータになります。
解析するためには、データの成型が必要です。

メリット

簡単にバックアップできる。
無料。

デメリット

運用しているサイト・ビューがたくさんあると、ひとつずつエクスポートするのが手間。
数字のみのデータ。

2. GA Reporting APIを使用

APIを使うことで、UAからプログラムを介してデータを取得できます。
Java、Python、PHPなどいくつかの種類があります。
ちなみにPHPの場合はcomposerで操作します。

（参考）Google アナリティクス Reporting API
developers.google.com/analytics/devguides/reporting/core/v4

取得方法やコマンドは、それぞれの分野に詳しい方がブログ等で解説しているので、検索してください。
取得データは、csvなどで保存できます。

メリット

ディメンジョンやメトリクスの指定で柔軟なデータを取得できる。
無料。

デメリット

プログラミングの知識が必要。
数字のみのデータ。

3. BigQueryを使用（GA360利用の場合）

360（有料）を契約している大規模サイトのみ利用できるサービスです。
なので、詳しくは割愛します。

（参考）Google アナリティクス 360 をご利用の場合: BigQuery へのエクスポートも可能
support.google.com/analytics/answer/3437618

4. バックアップ専用ツール「Analytics Backup by QA」を利用

ウェブ通おススメのバックアップ！
というか、宣伝です。けど、とてもおススメなんです！

Analytics Backup by QA
ga-backup.com/

• 1クリックで大量のビューをバックアップ
• バックアップデータは使いやすいユーザーインターフェース（UI）で閲覧
• アクセス解析・サイト運用のプロが開発

ウェブ通の運営会社である「株式会社ウェブジョブズ」が開発。
長年、ウェブ通でアクセス解析を担当した丸山だからこそできる、自分が使いたい、皆さんにも使っていただきたいアプリです。

Analytics Backup by QAは、UAのデータを取得・バックアップし、同じくウェブジョブズが開発したアクセス解析ツールQAアナリティクスのUIで閲覧できます。
1日ずつデータを取得するので、過去のデータとの比較なども柔軟に行えます。

システムとしては、UAのデータをGoogle アナリティクスAPI経由でダウンロードし、任意のサーバーに保存します。

WPプラグインなのでサーバーにWordPressは必要ですが、サイト本体はWordPressで作成されていなくても使用できます。

バックアップしたデータは成形不要。表やグラフで分かりやすいUIをご用意。

QAアナリティクスのUIは、GA4よりも使いやすいと好評です。
UAのようにグラフや表で可視化されるので、直感的に理解できます。

Google アナリティクスAPIを設定すれば、管理しているサイトのプロパティ・ビューを複数個、まとめてダウンロードできます。
しかし、1日あたりに取得できるデータには制限があるので、あれこれ無制限にデータを取得すると、期限までにダウンロードが終わらないかもしれません。

Analytics Backup by QAは、全てのデータの取得はしません。
アクセス解析・サイト運用のプロが開発しているから、今後の分析に過不足ないデータを見極めてダウンロードします。目標値や完了数もバックアップできます。

「高額だけど、うちのサイトにそんな価値あるかなぁ」
「APIって設定が難しそう」
と思われる方もあるでしょう。

Analytics Backup by QAには「パートナープログラム」が用意されています。
パートナー企業がライセンスを取得し、エンドユーザーにサービスを提供します。

エンドユーザーは使いやすい価格でデータをバックアップし、閲覧できます。
Google アナリティクスAPIの設定方法が分からない、WordPressサーバーの構築ができないときも大丈夫。
手間のかかる設定やバックアップ環境構築なども請け負ってくれるパートナー企業様をご紹介します。

近い将来、Analytics Backup by QAとQAアナリティクスも連携できるよう計画しています。
バックアップデータと移行後のデータを同じツールで閲覧、比較できるようになるんです。

メリット

プラグイン経由でデータを表示し、活用しやすい。
データをまとめてダウンロードできる。

デメリット

有料。
APIには利用制限があるため、移行に日数がかかる。

バックアップとアナリティクスを検討しよう

UAとGA4は、どちらもGoogleのアプリですが、システムは異なっています。
UAはGoogleが他社から買収したシステムでアクセスの数値を計測、GA4は新たにGoogleが開発したシステムでユーザー行動を計測するので、システムの目的が違います。
Googleがすすめるバックアップの方法でも、UAからGA4にデータをインポートすることはできません。
過去のデータを数字として、またはPDFなど加工できないデータとして保管するだけです。

Analytics Backup by QAなら、必要なデータを簡単にバックアップでき、取得したデータは分かりやすいUIで閲覧できます。

サイトをWordPressで運用していても、広告用のLP（ランディングページ）はデザイン重視でHTML形式のままでサイトに掲載していませんか？
リライトしたりボタンのテキストを変更したいときに、WordPressで修正できたら便利なのになーと思うことはありませんか？

ウェブ担当者通信を運営しているウェブジョブズでも、広告用のLPはHTML形式で納品されることがほとんど。
近ごろはQAアナリティクスを利用しているので、LPがWordPress化されていればユーザー行動を簡単に確認できるのに！
WordPressなら、ふだんHTML編集ソフトを使わないスタッフでも、ちょっとは修正できるし…。
そこで、HTMLで作成された静的LPをとりあえずWordPress化して掲載しています。

HTMLとCSSの知識、FTPは必要ですが、基本的にコピー＆貼り付けでできる作業です。

QAアナリティクスとは
タグ不要で簡単に導入できるアクセス解析＆ユーザー行動分析のWordPress公式プラグインです。
ヒートマップやセッションリプレイも見ることができるので、ページ単位で分析を行いたいランディングページでは特に使いたいWPプラグインです。

1. HTMLで作成された静的LPをWordPressで表示したい

※2024年2月11日追記

余談ですがWordPress公式ツールの作成が検討されているようです。早く進んでほしいですね。

github.com/WordPress/data-liberation/blob/trunk/guides/html-to-wordpress.md

静的LPをWordPressで表示させるために、固定ページ用の独自テンプレートを作成します。
独自テンプレートの作成は、主に2つの方法があります。

1. HTMLすべてをテンプレートで作成する
2. コンテンツ部分はWordPressのカスタムHTMLで作成する

QAアナリティクスのサイトを例にすると
「丸わかりQAマンガ」はすべてをテンプレートで作成、「機能・プラン」はカスタムHTMLで対応しています。

元のHTMLの構造や運用から、どちらにするか検討してください。

1-1. すべてをテンプレートで作る方法

複雑なHTMLや編集の予定がないページにおすすめ
QAアナリティクス「丸わかりQAマンガ」のページは、メインが画像でデザイン重視、HTMLやCSSも細かく設定してありほとんど編集しないので、すべてをテンプレートで作成しています。

【メリット】
ほぼ丸ごとコピーするだけなので簡単
Dreamweaverなどソフトを使って修正できる

【デメリット】
あとで修正をするときにもテンプレート（PHP）を編集する

1-2. 固定ページのカスタムHTMLで対応する方法

同じテンプレートで複数のLPを作成するときや、ときどき更新のあるページにおすすめ
QAアナリティクス「機能・プラン」のページは、機能が拡張され編集の予定がある、また他のページでもコンテンツを流用するので、カスタムHTMLで作成しています。

【メリット】
同じテンプレートでもコンテンツを変更できる
WordPressの機能も使える

【デメリット】
レイアウトできる範囲がやや制限される
修正はWordPressのカスタムHTMLでコードを編集する

2. 固定ページ用の独自テンプレートを作成するために必要なもの

静的LPをWordPressで表示させるために、まずLP用固定ページの独自テンプレート作成します。 HTMLをほぼそのままPHPで保存ですが、WordPress化に必要なコードを追加します。
テンプレートを作成するために、編集ソフトがあると便利です。

必要なもの

• HTMLデータ、画像データ一式、スタイルシート、jQuery（使用している場合）
  静的LPのデータが一通りそろっていることを前提としています。
• FTPソフト
  作成したPHPファイルや画像などをサーバーにアップできる環境。
• HTML、PHPが編集できるソフト
  コードで編集できるソフト。私はDreamweaverを使っています。

LP用固定ページの独自テンプレートを作成する準備ができたら、さっそく静的LPをWordPressで作っていきます。
2つの方法の手順をまとめています。

3. ページのすべてをテンプレートで作成する手順

HTMLをまるごとコピーして、テンプレートを作成します。
テンプレートをアップロード後は、テーマエディターで編集できます。

3-1. 新しいテンプレートを用意する

HTML編集ソフトなどで新規ファイルを作成します。ファイル名を付けて保存してください。
名前の付け方は「page-任意の文字列.php」です。
任意の文字列には後から見て分かりやすい名前を付けます。
ここでは仮に「page-lp01.php」とします。

3-2. テンプレートの名前を付ける

「page-lp01.php」の最初に、テンプレートの名前を付けるコードを入力します。
WordPressで固定ページを作成するときに表示されます。日本語でもかまいません。

<?php
/*
Template Name: ここにテンプレートの名前
*/
?>

3-3. HTMLをコピーする

表示させたいHTMLデータのソースを全選択してコピーし、先ほどの「page-lp01.php」に貼り付ける。

3-4. ヘッダーとフッターを追記する

コピーしたHTMLの「</head>」の前の行に「<?php wp_head(); ?>」を追加。
<?php wp_head(); ?>
</head> 「</body>」の前の行に「<?php wp_footer(); ?>」を追加。<?php wp_footer(); ?>
</body>

3-5. 依存ファイルを任意の場所に保存し、リンクを設定する

画像、CSS、JSなど、必要なデータを適当な場所へ保存します。
WordPress使用中のテーマ内が便利です。

例えば、使用中のテーマ内に「lp01-image」フォルダを作り、画像を保存した場合。

画像のフォルダのURL： https://あなたのサイト/wp-content/theme/使用中のテーマ/lp01-image/

page-lp01.phpにコピーしたソース内で画像などへのリンクを再設定します。

<img src="image/mainphoto.png">
↓下記に変更
<img src="https://あなたのサイト/wp-content/theme/使用中のテーマ/lp01-image/mainphoto.png">

編集ソフトの置換機能でまとめて変更すると簡単ですね。
CSSやJsも同様にリンクを再設定してください。

3-6. テンプレートのPHPと依存ファイルをサイトにUP

テンプレート（page-lp01.php）と依存ファイル（画像、CSSなど）をFTPで、WordPressの使用中のテーマへアップロードします。

3-7. 固定ページにテンプレートを設定する

WordPressで固定ページを新規作成します。
設定で、固定ページのテンプレートから先ほど作成したテンプレートを選びます。
上記3-2で設定した「ここにテンプレートの名前」部分が表示されているはずです。

固定ページを保存し、テンプレートで作成した静的HTMLが表示されているか確認してください。
画像やスタイルがうまく表示されない場合は、リンクを確認してみてください。

4. 固定ページのカスタムHTMLで作成する手順

コンテンツ部分をWordPressで編集できるようにします。

4-1. 前項と同じ手順でテンプレートを作成する

前項（3-1～3-7）と同じく、ページのすべてをテンプレートで作成し、固定ページの設定をします。

4-2. テンプレートの本文をWordPressにコピー

WordPressで編集したい部分を、テンプレートのPHPからコピーします。
<body>の間や、ヘッダー・フッターの間など、区切りの分かりやすい部分がおすすめです。

WordPressの固定ページにカスタムHTMLのブロックを追加し、先ほどコピーしたPHPを貼り付け、保存します。

4-3. テンプレートのPHPにコードを追加する

テンプレートで先ほどコピーしたHTML部分を削除し、固定ページの内容を表示させるコードを追加します。

<?php the_content(); ?>

テンプレートの<title>タグもPHPに変更します。
固定ページのタイトルが表示されます。

<title><?php wp_title(); ?></title>

※テーマによってはfunction.phpで、タイトルを出力するように設定されています。
function.php内に「add_theme_support( ‘title-tag’ );」の記述があれば、テンプレート内の<title>タグは不要です。（分からなければスルーしてOK）

テンプレートのPHPを保存し、サーバーにアップロードします。
固定ページを表示し、テンプレートのデザインとコンテンツが表示されているか確認してください。

5. 追加の設定

ほぼ丸ごとコピーで対応できますが、ちょっと追加しておきたい設定を追記します。

OGPやアナリティクスの設定

SNSで表示させたい画像や、Googleアナリティクスのタグなど、静的LPには設定されていない場合があります。
WordPressテーマのヘッダー用プレート（header.php）から必要な部分をコピーして貼り付けると簡単です。

URLをPHPで呼び出す

画像へのリンクなど、WordPressのURLはphpで呼び出すことができます。
URLをPHPに置き換えます。

・テーマのURLを呼び出す場合

https://あなたのサイト/wp-content/theme
↓
<?php echo get_template_directory_uri();?>

・子テーマの場合

https://あなたのサイト/wp-content/theme/使用中の子テーマ
↓
<?php echo get_stylesheet_directory_uri(); ?>

たとえば、テーマの中に画像フォルダ「lp01-image」を作成し、画像「mainphoto.png」を保存した場合

<img src="https://あなたのサイト/wp-content/theme/使用中のテーマ/lp01-image/mainphoto.png">
↓
<img src="<?php echo get_template_directory_uri();?>/lp01-image/mainphoto.png">

となります。

テンプレートのPHP内で使用できますが、WordPressのカスタムHTMLでは使用できないので気を付けてください。

カスタムフィールドでCSSを設定する

外部リンクでCSSを読み込んでもいいのですが、ちょっと修正したいときにWordPressだけで編集できると楽ですよね。

WordPressで固定ページ編集画面の下に「カスタムフィールド」があります。
カスタムフィールドにCSSを追加して、この固定ページのみにCSSを適用させます。

まず、テーマのfunction.phpへ、カスタムフィールドにCSSを追加するコードを記載します。

※ご注意
functions.phpの編集はWordPressの動作に影響が出ます。
必ずバックアップを保存してから作業してください。

/* 独自 CSS を適用 */
add_filter( 'wp_get_custom_css', 'add_custom_css' );
function add_custom_css( $css ) {
if ( is_singular() ) {
if ( $custom_css = get_post_meta(get_the_ID(), 'css', true ) ) {
$css .= $custom_css;
}
}
return $css;
}

固定ページのカスタムフィールドで、名前「css」を選び、「カスタムフィールドを追加」します。
上の段に「css」のカスタムフィールドが追加されます。
cssの「値」欄に、HTMLのcssをコピーして貼り付け、カスタムフィールドを「更新」します。

カスタムHTMLを分割

コンテンツをWordPressのカスタムHTMLで作成した場合、長いHTMLがひとつの欄にずらずら書いてあると、修正したい箇所を見つけにくくなります。
段落やパートに分けて、いくつかのカスタムHTMLブロックを作成すると管理がしやすくなります。

CSSの確認と調整

既存のヘッダー、フッターを使用し、コンテンツ部分のみカスタムHTMLで作成する場合もあります。
静的LPのCSSと既存のCSSで同じclass名を使っていると、既存のヘッダー、フッターのレイアウトが崩れてしまいます。
静的LPのclass名を変えるなどして、調整します。

まとめ

静的LPをとりあえずWordPressで表示させる方法。

1. 固定ページのテンプレートを作成し、テンプレート名を付ける
2. HTMLを丸ごとコピーし、WordPressのヘッダー・フッターを追加する
3. WordPressで固定ページを新規作成し、テンプレートを適用する

大まかな手順は以上です。
ソースを編集するので、見慣れていない方は一瞬戸惑うかもしれませんが、コピー＆貼り付けだけの単純な手順です。

表示されない場合は、画像やCSSのリンクが正しいか確認してください。
画像へのリンクが一番手間のかかる部分かもしれません。
画像はできるだけ同じフォルダにまとめるなど、分かりやすく管理すると作業しやすくなります。

静的LPをWordPress化すると、QAアナリティクスでの計測にも自動的に含まれます。
QAアナリティクスは、インストールするだけで使える設定不要のWordPress公式プラグインです。
アクセス解析も他のページと同じく簡単にできるようになりますね。

（※本記事はメルマガ週刊！ウェブ担当者e通信（5/25送付）のものを一部修正して公開しています)

QAアナリティクスがver3.0にアップデートしました。

▼QA Analytics – QAアナリティクス – – WordPress プラグイン | WordPress.org 日本語
ja.wordpress.org/plugins/qa-heatmap-analytics/

この動画を見てもらうとわかりやすいと思います。関西の人には馴染みのある形だと思います笑。
▼QAアナリティクスの画面イメージ。WordPressがある時 （※音がでます）

森野さんからはTwitterでこんなご意見をもらっています。

広告を出していなくて自然検索とSNS経由からのアクセスがほとんどであれば、GA4じゃなくてQAアナリティクスでほぼ問題なし。目標設定の機能ができてくれたらGA4は保険というか勉強用になると思う。広告も運用者しだいでGA4って感じかな～。

— 森野誠之 (@uneidou) May 24, 2022

実際私も今はQAをメインで使う感じになっています。

…で、QAを使ってどう改善すればいいの？

QAはアナリティクスを触ったことがない人でも使えるように考えて作っています。
じゃあその先に何が待っているのか。

森野さんだけじゃなく、松尾さんはじめ凄腕のマーケッターの人とも話すのですが、やはり今後は「使い方をもっと知りたい」というニーズが出るという見解は一致しています。

「データ解析ノウハウを学んで、自ら改善していけるようにしたい」ということですね。

データ解析ノウハウを学ぶには

ではデータ解析ノウハウはどう学べばよいのでしょう？

書店にいけばGoogleアナリティクス本もたくさん出ていますし、ウェブ解析士協会さんもありますし、a2i(アナリティクスアソシエーション）さんもあります。
また統計的な学習では回帰分析とかもあります。いくつか本を読んだことがある人も多いのではないかと思います。

とはいえ、データ解析にはなかなか解決できない２つの根本問題があります。

1. 時間がない問題
2. 社内で勉強してもらう必要がある問題

これはずっと解決できない問題ですから、別の究極の質問に変えた方がいいと思うのです。

「より短い時間で、誰がどうすれば上手にデータ活用できるの？」と。

ワークマン事例から「より短い時間で上手にデータ活用」を学ぶ

ワークマンは近年売上を伸ばし続けていますが、エクセル経営で有名です。

▼ ワークマンが駆使する「自作エクセル」を初公開　データ経営の要 xtrend.nikkei.com/atcl/contents/18/00599/00004/

これが一つの回答になるかもしれません。なんといっても社員全員がExcelを使って自主的に考えて動いているわけですから。

では彼らはどうやったのか？記事から抜粋するとこんな内容でした。

前提

ワークマンはほぼフランチャイズなので、全社員≒本部の社員というイメージです。

扱うデータ

品揃えと売上の関連データ

教育方法

社員全員がExcelでデータの使い方研修を3年間受ける。講師は社員

• 1年目：商品分析システムの使い方
• 2年目：Excelの使い方
• 3年目：データ加工方法

結果

• 本部スーパーバイザーの加盟店に対する提案力向上（数字があるので説得力が増した）
• 部署別の経営会議に幹部も参加．数値を中心に議論
• トップダウンから並列な関係へ

データ活用の肝は「フィードバック」

私がワークマン経営でどの企業でも真似できるなと思ったのは下記2点です。

1. 見るデータを絞る
2. 社員がみんなに教える

データ解析とは、つまるところ市場からのフィードバックを得て、各自が独りよがりにならずに着想することに価値があると私は考えています。

なんでデータ解析をしないと不安になったり問題になるかというと、市場からのフィードバックをまったく無視して独りよがりの施策をしてしまうからで、それは外す確率が高くなります。
「今の方向性があっているのか？」の確証もずっと持てません。体重計のらずに手当たり次第にダイエットするのと一緒というか。

これが全員がデータ解析を学ぶ大きなメリットで、統計とかそういうのは関係なく「市場からのフィードバックをもとに独りよがりにならず考えようよ」ということなんですよね。

ですので究極の質問「より短い時間で、誰がどうすれば上手にデータ活用できるの？」に対しての答えは

• まず見るデータを絞って
• みんながデータからフィードバックを得て
• それぞれの立場で着想できたらよい

が正解だと思っています。

QAが目指すモノ

1年前のnoteにも書いたのですが、QAのコンセプトはまさに上記です。

▼データの‟分析”はもうやめよう。WordPress無料プラグイン「QA Heatmap Analytics」が実現するこれからのWebマーケティング note.com/qateam/n/nfd612fa7822d

今QAで頂いている意見は、地味ですが、それを反映できているのかなと思います。

• UIが見やすい
• 「伸びているランディングページ」が、見れるのが良い
• 各指標の数値をページ遷移なしで見れるのでGA4に比べてストレスがない
• 数値やグラフの期間表示が早く、これもGA4よりストレスがない

【悲報】QAアナリティクスの感想嬉しいけど、使ってみないとわからないことばかり。

・「伸びているランディングページ」が、見れるのが良い
・各指標の数値をページ遷移なしで見れるのでGA4に比べてストレスがない
・数値やグラフの期間表示が早く、これもGA4よりストレスがない
・UIが見やすい

— 丸山耕二 / WebJobs (@koji_maruyama) May 24, 2022

望むすべての人にデータによるインスピレーションを

最後はQAへの想いを。

noteにも書きましたが、私は一部の人だけがデータを見る文化を変えたいと思っています。

データを見る側の人も孤独になるし、見ない側の人は独りよがりになりやすいし、共通認識も生まれづらい。ついでにそうやって日本全体もIT貧乏になっていき、誰もハッピーではありません。

日本人には底地があると思います。多くの人がデータを使えるようになれば、それはもっとすごくなると信じています。

今の黒船信仰が強いまま、特にこのタイミングで何も起こらず「GA4を学べないやつはダメだ」なんて気風のままでいけば、おそらくデータを使える人が限られたままになってしまうどころか、多くの人がよりデータを見なくなります。
せっかくワークマンが魔法ではない誰でもできる秘訣の一つを教えてくれているのに、これはあまりにもったいないと思っています。

データツールは別に一つじゃなくて、ExcelとTableauを同時に使ってもいいし、GA4とQAに関してはむしろ同時に使ってもらった方がいいです（私達もそうしています）

QAの目標は最初から変わっていません。

「望むすべての人にデータによるインスピレーションを」

小さな会社で作っているので、まだまだ全然及ばないことが多いですが、森野さんの力も借りて、一歩ずつ日本から世界に誇れるツールにしたいと思っています。

IT後進国とバカにされるけど、日本だって底力は世界に負けていない。
そういえるようになりたいなぁと思います。

裏話：QAはマーケティング的には失敗

ちょっと最後にこっそり裏話を…

QAはマーケティング的には失敗しています（苦笑）

なぜかというと、先ほどのお客さんの意見をみてもらうとわかるのですが「速度が速くてストレスがない」など、バーンと機能比較表に出るようなキャッチーな特徴がありません。
よくマーケティングで言われるように「使ってみないとよくわからない商品」は、キャッチーではなく拡散しづらいのでとても難しいです。

更に悪いことにQAは「誰でもすぐに使えて分かりやすい」を目指しているため、「使い方がわからないツール」でもないので書くことも少なく、わざわざブログで説明を書いてくれる人も少ないです。

もう一つおまけに「緊急で使う必要性を感じない」商品です。これも問題。

実際我々はこれで苦労しているので、もし何かサービスや商品の販売で苦労している場合、ぜひ上記に当てはまっていないかチェックされることをオススメします（苦笑 ← 2回目）

ただ本格的に今年は社内でデータ活用をするんだ！と思っている方向けには、強い味方になれる自信があります。
実際、QAを使うことで、下記のように大きく売上を伸ばしたブロガーさんがいらっしゃいます。

• 毎月4万円 → 毎月140万円
• 毎月7万円 → 毎月200万円

収入が１桁から３桁になり、法人を設立されたり副業から本業に独立されました。「このツールは正直広めたくない」とまで言われています（困るけど）。QAはこのあたり含め森野さんに入ってもらって、一緒に広めていくような活動を今後していく予定です。

QAはひっそりとキャンペーン中です

7/31までQAはひっそりキャンペーンをやっています。
quarka.org/plan/

法人の方で「今年こそデータ解析の文化を社内に！」という方には、プラチナパックを検討してもらうといいかなぁと思います。
なぜかというと、プラチナパックには「法人サポート」がついているのですが、サポートとは、データ活用のご相談にのるプランです。

そして今回が初めての一期生なので、内容が悪く言えば手探りなんですが、よく言うとお客様と相談しながらになるので、必然的にカスタマイズ性が高くなり手厚くなります。
つまり言葉を変えると年間のデータ解析コンサルティング+ヒートマップ全ページ自動取得でトータル年間5万円って感じなんですよね。

…と、あまり書くと我々側がサポートでパンクするかもしれないので、ひっそりですが、そんな内容なので宜しければぜひ。

サイトを作成する際、WordPressを利用することが主流になってきました。
便利なプラグインも多種開発されています。
よく使うプラグインは気軽に導入しますが、攻撃対象になることもあります。
また、もうちょっと便利に使いたいと思うこともあります。

「Contact form 7」もWordPress用のプラグインです。
ja.wordpress.org/plugins/contact-form-7/
手軽に複数のお問い合わせフォームを設置できるので、使っている方も多いのではないでしょうか。
自分の備忘録も兼ねて、導入後に設定したいポイントをまとめます。

迷惑メール対策

「Contact form 7」はメジャーなプラグインなので迷惑メールの対象として狙われやすく、海外からの迷惑メールが大量に届くこともあります。
迷惑メールは手動ではなくBotと呼ばれるプログラムで送信されています。なので、Bot対策として「reCAPTCHA」を設定します。

画像：Google reCAPTCHA

reCAPTCHAとは

▼reCAPTCHA|出典: フリー百科事典『ウィキペディア（Wikipedia）』
ja.wikipedia.org/wiki/ReCAPTCHA

フォームからメールを送信するときに、ゆがんだ英文の画像が表示されることありますよね。
「表示されている文字を入力してください」とパスワードのように入力します。
Botでは判読できない文字を利用して、人間かBotかを区別する仕組みです。

現在は「reCAPTCHA v3」と呼ばれるシステムで、複雑な文字を入力しなくても人間かBotかを自動で判別しています。

reCAPTCHA機能の設定

reCAPTCHA機能は、Googoleのサイトから「サイトキー」と「シークレットキー」を取得し、自身のWordpressに設定します。
キーを取得したら、コピー＆貼り付けで簡単に設定できます。

1. Googleにログインし、reCAPTCHAのページを開く
   www.google.com/recaptcha/about/
2. 「v3 Admin Console」から新しいサイトを登録
3. サイトキー、シークレットキーを取得
4. WordPressのダッシュボードから「お問い合わせ＞インテグレーション」を開く
5. 「reCAPTCHA」からインテグレーションをセットアップ

解説はこちら
▼reCAPTCHA (v3)｜Contact Form 7
contactform7.com/ja/recaptcha/

reCAPTCHバッジをフォーム画面のみに表示

reCAPTCHAの設定を完了すると、デフォルトの設定ではサイトの全ページにreCAPTCHAのバッジが表示されます。
バッジが表示されていると、ページスピードに影響が出たり操作の妨げになることもあるので、Contact form 7を使用しているページだけに適用させます。

下記サイトを参考に、テーマのfunctions.phpへコードを追加します。

※ご注意
functions.phpの編集はWordpressの動作に影響が出ます。
必ずバックアップを保存してから作業してください。
下記スクリプトは公式ではありませんが、私の運用している複数のサイトで利用しています。今のところ問題なく稼働しています。

解説はこちら
▼ContactForm7のキャプチャをお問い合わせページだけに表示｜ワードプレス・ドクター
wp-doctor.jp/blog/2021/05/14/contactform7キャプチャをお問い合わせページだけに表示/

承諾確認の追加

「個人情報の保護に関する法律についてのガイドライン（通則編）」（個人情報保護委員会）によると、「本人による同意する旨の確認欄へのチェック」することにより「本人の同意」を得ていると判断されます。

また、承諾確認チェックボックスを設置することで、海外からのスパムメールをある程度防ぐ効果もあります。

Contact form 7では簡単にチェックボックスを設置できます。

解説はこちら
▼承諾確認チェックボックス｜Contact Form 7
contactform7.com/ja/acceptance-checkbox/

便利に使いたい

デフォルトの設定でも使えますが、こうだったらいいな…と思うこともあります。
見た目と使いやすさについて参考サイトを紹介します。

CSSで見た目をわかりやすく

スタイルシート（CSS）で見た目を整えると、必須項目や入力箇所が分かりやすくなります。
コピーして使えるCSS、HTMLを公開しているサイトも多数あります。

メールフォームのデザインは、テーブル（table）、定義リスト（tl）、ブロックレベル（div）などを利用してカスタマイズされています。
最近のCSSではレスポンシブにも対応しているので、サイトの用途やテーマに合ったCSSを選んでください。
CSS、HTMLの知識があれば、カラーの変更なども簡単にできます。

▼【Contact Form 7】CSSでデザイン カスタマイズ（コピペOK・レスポンシブ対応）｜ツッチーブログ
tsutchii.com/cf7-design-customize

▼Contact Form 7のカスタマイズ（コピペOK、レスポンシブ対応）｜webicon
webicon.jp/wordpress/contactfoam7-setting/

▼Contact Form7をCSSでおしゃれにカスタマイズ【コピペ用】｜misaMAG
shimamisa.com/contact-form7-css/

郵便番号から住所を自動入力

WordPressのプラグインです。
郵便番号を入力すると、自動で住所が入力されます。

【zipaddr-jp】
wordpress.org/plugins/zipaddr-jp/

Contact Form7を利用していると設定がより簡単にできます。

▼Contact Form 7 が、より簡単に利用できます。｜ZipAddr2
zipaddr2.com/contactform7/

「都道府県」「市区町村」など命名ルールから次の入力項目を判断する方法と、入力項目に既定のname属性を設定する方法があります。
入力項目の数やレイアウトで設定は違うので、それぞれのサイトに適した方法を利用してください。

確認ページがない

Contact Form7は確認ページがないんですよね。
プラグインで表示させることもできるようですが、更新がされていないものや、レイアウトに手間がかかるものや、いまいちコレ！というおすすめがありません。
もしおススメあれば教えてください^^;

トラッキングのために

トラッキングとは、サイトにおけるユーザーの行動や情報を収集する機能です。
ユーザーがフォームを書き込んで、送信したか離脱したか、解析することもあります。

Googleアナリティクス対応のためにサンキューページへリダイレクトさせたい方もいるでしょう。
Contact Form7のサイトではリダイレクト方法も掲載されていますが、「トラッキングする簡単な方法」を推奨しています。

▼送信後に異なる URL にリダイレクトさせるには｜Contact Form 7
contactform7.com/ja/redirecting-to-another-url-after-submissions/

▼フォーム送信を Google Analytics でトラッキングする｜Contact Form 7
contactform7.com/ja/tracking-form-submissions-with-google-analytics/

今後、GA４に変わった場合は対応どうなるのかしら…。
なんだか面倒そう…。
と思ったあなたには、WordPress公式プラグイン「QAアナリティクス」をおススメします。
タグやコードの設定は不要、導入するだけでアクセス解析できますよ。

HTTPでは動作しなかった話

余談ですが。
WordPressで新しいサイトを構築中、Contact Form7で作成したメールフォームから送信テストをしても、アイコンがくるくる回るだけで動作しないことがありました。
新しくページを作って設置すると送信できるのに、お問い合わせページからはくるくる…

プラグインの干渉？
バージョン？
何か設定がおかしい？

しばらく悩んでから、アドレスバーの違いに気づきました。
お問い合わせページへのリンクをうっかり「http://～」に設定していたため、「保護されていない通信」になっています。
「https://～」でテストしたら、すんなりと送信できました。

サイト構築中でサーバーやBasic認証の影響かもしれません。
調べても原因がわからず悩んだので、おまけで書いておきます。

Google アナリティクス（ユニバーサル アナリティクス）の2023年計測停止に伴って、「GA4どうする？」と話題になっていますね。

GA4へのツール移行、ぶっちゃけて言うとメチャクチャ難易度高いです。
ひとりで頑張るウェブ担当者を応援するウェブ通としては、わざわざ難しいGA4を使う必要はないサイトがある、と思っています。

GA4をがんばって使う必要がないサイト・ウェブ担当者

• GAよりもSearch Consoleをよく見る
• GAではPV数、ページ離脱率、訪問経路をチェックし、サイト改善に活かしている
• GAで細かくサイト分析をし、サイト改善施策を検討するのは年1回ペースくらい
• ひとりウェブ担当者でサイト分析以外の業務が多い
• GA4の学習コスト、GA4の設計外注などの予算がない中小企業
• 10万PV/月以下のWordPressサイト

上記に該当するサイト・ウェブ担当者の方、「GA4を勉強しなきゃ！」と焦る必要はありません。
以下のようなデータが取得できて閲覧できれば、サイト運用・改善施策対応に問題がない方は多いのではないでしょうか？

上記画像は、ユーザー行動解析ツールQA ヒートマップアナリティクスの管理画面です。

宣伝っぽくなってしまうのですが、QAはWordPress公式プラグインなので、WordPressサイトであれば簡単に導入できます（現在WP以外サイトへの対応も開発中）。
さらにヒートマップや録画再生機能があるので、サイト改善・ページリライトなどの施策検討において、GAで数値を眺めるよりもいいアイデアが浮かびやすいです。

GA4に取り組む前に、まずはサイト運用でGAをどう使っていたかの棚卸し、そしてアクセス解析ツールの検討から始めましょう！

なぜGoogleはユニバーサルアナリティクスをやめるのか？

ところで、なぜGoogleはユニバーサルアナリティクスの計測停止を決めたのでしょうか？
GA4が発表になったころ（QAの開発初期と同時期なのですが…）、丸山は以下のように予想していました。

スマートフォン時代に入り、ユーザーの行動は、以前ほどシンプルではなくなってきています。その中で、イベントを計測するようになったというのは理にかなっていると思います。

データ分析の最大の敵は「インフラコスト」
（中略）
そんな全サイトで、今までのデータに加え、さらにその数十倍となるであろう全てのユーザーの行動データを詳細に長期間記録するというのは、さすがのGoogleといえどもちょっときついはずです。

引用：ウェブサイト分析ソフトウェア開発の舞台裏（前編） – 無料のWordPressヒートマッププラグイン【QA Heatmap Analytics】

そもそもGoogleがアナリティクスを無料で提供する理由は「世界中のサイト傾向を把握し、ユーザーを追跡する」だったはずですが、この目的はもう達成されています。かつ最近のプライバシー問題でユーザー追跡は排除されていくので、ますますGoogleアナリティクスの役割はGoogleにとって曖昧になります。なのに未だにめちゃくちゃお金がかかっている。
（中略）
そんなわけで、多くの人が使っている現行のGoogleアナリティクスはそのうちサポート終了のお知らせがきたり、過去データが強制削除される可能性が高いと私は予想しています。

引用：データの‟分析”はもうやめよう。Wordpress無料プラグイン「QA Heatmap Analytics」が実現するこれからのWebマーケティング｜QA広報チーム｜note 

Googleは、2023年中にサードパーティーCookieの利用廃止を発表しています。
上に引用したユーザー追跡の排除対応ですね。

そしてアメリカではデータプライバシーに関連して、現在のCCPAを拡大・強化した「カリフォルニア州消費者プライバシー権法（CPRA）」が2023年1月1日に施行されます。
欧州のGDPRで制裁金を課せられているGoogleとしては、個人データに関して2023年はキーとなる年だったのかもしれませんね。

Google アナリティクス（ユニバーサル アナリティクス）の計測停止について

現行のGoogle アナリティクス（ユニバーサル アナリティクス）は、2023年7月1日（土）をもって計測を停止し、その後少なくとも6か月間は過去データを閲覧できるようにする、とGoogleが2022年3月16日に発表しました。

▼ユニバーサル アナリティクスのサポートは終了します｜Google アナリティクス ヘルプ
support.google.com/analytics/answer/11583528?hl=ja

Web界隈の人たちのTwitterやFacebookは先週大騒ぎでしたね（他人事ではまったくないのですが）。GA4がリリースされたときから「いつかくる」とは分かっていましたが、こんなに早くアナウンスされるとは…驚きました。

簡単に無料版について、計測停止スケジュールとポイントをまとめます。

• 2023年7月1日（土）まで
  • 現行ユニバーサルアナリティクス
    データ収集・計測OK、閲覧OK
  • GA4
    データ収集・計測OK、閲覧OK

• 2023年7月1日（土）～数ヶ月間（おそらく2023年12月31日（日）まで）
  • 現行ユニバーサルアナリティクス
    データ収集・計測STOP、7月1日までのデータ閲覧OK
  • GA4
    データ収集・計測OK、閲覧OK

• 2024年1月1日（月）～
  • GA4
    データ収集・計測OK、閲覧OK

• 2023年7月1日までにやっておくべきこと
  • アクセス解析ツールの検討
  • GA4に移行する場合
    ・GA4でデータが蓄積されるよう設定する
    ・GA4を学んで知る、触ってみる
    ・データ収集・解析の要件定義
    ・データ収集およびレポートの設計
    ・データ収集の設定・レポート設定
    ・Google タグマネージャーを理解する<
    ・タグ設計・設定
  • Google アナリティクスと連携しているツールの設定変更
    ・APIを利用した現行ユニバーサルアナリティクスも、上記スケジュール同様に停止
    ・GA4を使用する場合はAPIの移行設定
    ・Google AdWords、Google タグマネージャー、Google データポータル、Google スプレッドシートなど各種連携見直し
    ・WordPressなどCMSの設定見直し

残り1年と少し。まずは現状把握と今後の対応の検討を！

Googleが強く推奨するGA4とは？

GA4とは、2020年10月にリリースした「Google アナリティクス 4 プロパティ」の略称です。
現行ユニバーサルアナリティクスとの大きな違いは、「イベント計測型」「アプリとWebを横断して計測」「BigQueryが無料で使える」こと。

ツールとしての設計思想が、これまでのユニバーサルアナリティクスと大きく異なっています。
現行ユニバーサルアナリティクスはページ単位でのセッションを計測するツール設計ですが、GA4はイベントを計測するツール設計です。

GA4は、ページの概念がないアプリをサイトとともに計測できるようになっているため、サイトとアプリを持つ企業にとっては分析がしやすいツールと言えるかもしれません。
また大量のデータを分析して有効活用したい企業にとっても、BigQueryが無料で使えるのはありがたいですね。

残念ながら、現時点ではユニバーサルアナリティクスからGA4へのデータ移行はできません。もし2023年7月1日以降はGA4を本格的に使って分析を行ないたい、と考えているのであれば、早めにGA4での計測を開始してデータを貯めておいたほうがいいでしょう。

イベント計測型

「イベント計測」とは「ブラウザ上で取得もしくは設定できる何らかのアクションを計測」することを指しています。
たとえば「問い合わせボタンをクリックした」とか「ユーザーがページをスクロールした」など、サイト訪問ユーザーやアプリ利用ユーザーが行なった行動を「イベント」と言います。

現行ユニバーサルアナリティクスでも、「問い合わせボタンのクリック」などのイベントを目標設定することはできましたが、GA4はもっと細かくイベント計測のための設計・設定ができます。

つまりGA4では、デフォルト以外で取得したいすべてのイベントに対して設定をしていく必要があります。
タグの数が非常に膨大になり煩雑になりがちであるため、Google タグマネージャーとGA4を連携して、タグマネでタグの管理をするのがほぼ必須となります。

また前述した「BigQueryが無料で使える」のはメリットなのですが、BigQueryからデータを取得するためにはSQLの知識が必要です。
SQLの習得は、なかなかウェブ担当者にとって高いハードルですよね。。。

GA4の現状

現行ユニバーサルアナリティクスでは、サイトにタグさえ入れれば、あとは勝手に計測してアクセス数もレポートも見せてくれました。
GA4では、まず「何を計測するのか？」「どんなイベントを取得するのか？」「どんなレポートを出すのか？」など計測のための設計が必須です。
設計をしてからタグ設定して、ようやく見たいデータの計測・閲覧ができるようになります。

GA4への移行手順については、アユダンテさんの記事が詳しいので参考にしてください。

▼教えてアユダンテGA4編「ユニバーサルアナリティクス(UA) からGA4へ移行する大事なポイントは？」 
ayudante.jp/column/2022-03-17/11-00/

正直ひとりですべてやるのは難しいツールになるなー、と思います。Web運用の業務のかたわら、GA4・タグマネ・SQLを一から学習して使いこなせるようにしていくのはかなり難易度が高いです。

しかもGA4は現時点はまだ完全なツールではなく、日々進化している状況です。そのため学習しようにも、理解した部分の仕様が変わることも起こっています。

2023年以降のアクセス解析はどうする？

このような状況では、ひとりで頑張るウェブ担当者の方は「現行ユニバーサルアナリティクスが計測停止になるから、同じGoogleのGA4に移行すればいいんでしょ？」と簡単には考えられないと思います。

そこで今後のアクセス解析はどうするのがよいか？をまとめます。

1. 現行ユニバーサルアナリティクスでどの数値をみているか、GA閲覧頻度、分析頻度を棚卸し
2. サイト改善のために「絶対必要な数値やデータは何か」を洗い出し
3. 1,2から、他のアクセス解析ツールの選択肢はあるのかを検討
4. 1,2,3から、GA4に移行するしかないと判断したら、現行ユニバーサルアナリティクスと並行してGA4でも計測を開始しておく
5. GA4の設計・設定について学習する

Web運用はサイトの規模や種類などによって異なります。GAで見ている数値、重要視しているデータは当然変わってきます。
そのため「GA4への移行しか選択肢がない」と考えず、自分たちのサイトでどのようにGAが使われているのか？を把握することから始めましょう。

他のアクセス解析ツールとの比較

現行UAとGA4、そしてユーザー行動解析ツールQA ヒートマップアナリティクスと比較しました。
Google アナリティクスとよく比較検討されるAdobe アナリティクスは、高機能で導入にもサポートがほぼ必須、かつ有料版のため、比較から外しています。

現行GA（ユニバーサルアナリティクス）は2023年7月1日に計測停止されますが、GA4への移行を焦ることはありません。
まずは何の数値がサイト改善に必要なのか？どんなデータを取得したいのか？から棚卸しすることから始めましょう！

構造化データ。
馴染みはあるでしょうか？
私はよくわからないまま、とりあえずソースコードに記述した、というのが始まりでした。そしてSchema.orgの構造化データとGoogle検索セントラルのドキュメントの間で若干迷いました。

この記事は、構造化データをマークアップすることに関連した、ちょっぴり技術寄りのお話です。
何から手を付けたらいいんだ？という時のヒントに、また、道標代わりに、私の思うマークアップの進め方と小さな発見を記します。
構造化データはある程度わかるよ！という方には、おそらく退屈な話になります。（不慣れだとこうなるんだなーという参考くらいにはなるかも？）
ちなみに実際のマークアップ例が書いてあるわけではありません。そちらを期待されていた方、ごめんなさい。

こんな話をしていきます▼

• 構造化データの種類を書けば、Google検索用の定義に自然と はまるわけではありません。（思い込みはいけません。）
• Google検索用の構造化データは、Google検索用の定型様式を守りましょう。
  Schema.orgは辞典のようなものと捉えましょう。
• マークアップの大まかな進め方と注意点。

主な参照▼
Google 検索セントラル　検索ギャラリーを見る
Schema.org　ドキュメント

はじめに

さて、構造化データはSchema.orgが定義しています。
そして構造化データは「ここはこの属性、この内容ですよー」とGoogleに伝えるのに使われています。
Googleは「こんなページならこれ書いて」と明示しているので、あとはそれに合わせて内容を詰めるだけ。
ではなぜGoogleはそんな指定をしているのか？
それは、Googleがページの内容を把握しやすくなり、その内容によっては検索結果を専用の表示形態で出せるように、ですね。リッチリザルトといわれています。（※構造化データが検索結果に表示されるとは限りません。）
つまりGoogle検索用構造化データ＝リッチリザルト用ともいえるでしょう。
検索結果の表示専用枠があるので目立つという点から、構造化データはSEOの一環と捉えられることもあります。

SEOの視点なら（プレミアム限定）▼
【プレミアム】あなたのサイトで構造化データを導入すべきか否かの判断基準について

思い込みはいけません（私の例）

では構造化データを入れてみよう、と思われた方も多いでしょう。

最初の一歩として、構造化データとGoogle検索用の構造化データ、違いは大丈夫でしょうか？

私はこの境界が曖昧だったために、こんがらがったのでした。
どうしてか。
（ここからはソースコードを見たことがある前提で進みます。）

構造化データのコード、書き出しは決まって {
"@context": "https://schema.org/",
"@type": ... なんですよね。
そうかそうか、この@typeというのが内容を表していて、いろんな種類があるのだな、と、私はまず思いました。（以降、このTypeを種類と呼んでいます。）
ここまではあながち間違いではないでしょう。

しかし「構造化データというものがあって、Google検索に有効らしい」と初めて聞いた時、なるほどページの内容を構造化データの種類のどれかにあてはめればよいのね、と勝手に解釈しました。
実はもうこの時点でズレ始めています。

一つ。そもそも構造化データの種類や階層は、そんなに単純ではない。

Google検索セントラルの「検索ギャラリーを見る」に、構造化データの定義はSchema.orgのドキュメントを参照しろ、と書いてあったので、私は見ました。
なんだか種類がたくさんあります。その分類だか階層だかを見ても、うーん、印象だけは確かに「構造」だね、って具合です。でも勝手に、個々の種類が独立している、とでもいいますか、構造化データの階層を系統図のように単純なものだと思っていました。
大きな間違いです。
構造化データの種類は、単純に独立して存在しているわけではありません。階層はありますが、それぞれが複雑に関係しあっています。というより、きちんとした定義のもとで情報に合った階層構成を組み立てられるからこそ、構造化データたるものでしょう。

二つ。「Google検索に有効」とは、「Google検索用リッチリザルトとして受け付けてもらえる」ということを指す。

私は、とにかくページ内容を表す構造化データの種類を書く⇒Googleが受け入れてくれる
だと勘違いしていたのですが、
Google検索用の構造化データを書く⇒Googleリッチリザルトとして受け付けられる
が正解だったのです。
よしんば自分でがんばって構造化データの種類を書き込んでも、Google検索用の構造化データに当てはまらなければ無駄足です。
そう、Google検索用の構造化データでなくては意味がないのです。
Googleは構造化データ（のボキャブラリ）を使って、検索用の構造化データの定型様式を造り、これならリッチリザルトになるよ、と私たちに提示しているのです。

 では改めて基本を抑えていきましょう。

基本は、Google検索用『部門』の定型様式に記入。Schema.orgは『辞典』のようなもの。

繰り返しになりますが、ここでの目的は、「Google検索用」の構造化データです。

検索用の構造化データについて書かれたGoogle検索セントラルでは、「検索ギャラリーを見る」の「機能」一覧にいくつか項目が並んでいます。この項目ごとにそれぞれのリッチリザルト、検索結果表示に対応しています。ここではそのイメージから、機能項目を『部門』と呼ぶことにします。
検索用に用意された各部門では、「この部門では構造化データのこの種類が必須・推奨項目だよ」と『定型様式』を提示しています。例えるなら、検索結果表示で優遇してもらうためのエントリーシートみたいなもので、名前や特技を書くように、構造化データの特定の種類に対して内容を記入します。定型様式なので、階層構成も定められています。

くどいようですが、勝手に、うちのページ内容だと正確には構造化データのこの種類でこの階層構成だろう、なんて独断で選んで書くと、部門の定型様式と異なり受け付けてもらえず、Google検索用には意味がありません。

検索用の構造化データでは主に schema.org のボキャブラリが使用されていますが、Google 検索の動作の定義には、schema.org のドキュメントではなく Google 検索セントラルのドキュメントを使用してください。

引用：Google 検索セントラル「構造化データの仕組みについて」

正に本質がここにあったのでした。
当然といえば当然ですが、Google 検索セントラルのドキュメントに挙がっている部門の定型様式に必ず合わせましょう。

そして私は素通りしてしまっていたのですが、ちゃんと書いてあったのです、「schema.orgの『ボキャブラリ』」と。
ボキャブラリ、つまり「ことば」の定義がなされているのがSchema.org。いうなれば、構造化データ『辞典』です。
（実はSchema.orgにも書いてあるんですけどね、ボキャブラリ。これも後になってようやく気づいた私です。）

種類だ種類だと思ってきましたが、いえ、確かにたくさんの種類のボキャブラリなのですが、種類という選ぶものより、ボキャブラリだと使うもの、という印象が強くなりました。目から鱗。（気づくのがここまで遅いのは私だけかもですが。）

上級者は辞典そのものを楽しめますが、一般的に、辞典はことばの意味や用法がわからない時に活躍します。Schema.orgは、この構造化データの中身はこれでよいのか、などという疑問があった時、調べるものとして使いましょう。

ページの内容＝構造化データの種類ではなく、Google検索用の『部門』に当てはめ、定型様式通りに書く。
その上で補助的に、Schema.orgという『辞典』で調べる。
この基本を忘れなければ、迷わずに行けるでしょう。

マークアップは、サイト構成を3つに区分して、アピール度合から見る。

基本を抑えたら、次は準備とマークアップといきましょう。
サイト構成を大きく３つに分けて見ていきます。
・パンくずリスト
・サイトのメインカテゴリー
・その他のページたち

これら３つについて、Googleにアピールする優先度が高いのか、補助的に構造化データを入れるのか割り振ってみましょう。

 ポイントとステップ

1. 『Google検索にアピールしたいところ』を中心に据える。＝Google検索用の部門に当てはめる。定型様式通りにマークアップする。
2. 余裕があれば、構造化データで情報を補足する。＝Schema.orgを使う。
3. プラグインを使う場合は『表立って出したくないところ』も意識する。

区分イメージはこんな感じです。

(1) 部門を決めて、定型様式に合わせる。

パンくずリストについてはもう明確でしょう。
次に、Googleにアピールしたいカテゴリーがどの部門に当てはまるのかを探しましょう。

▼Google検索用の部門
（出典：Google 検索セントラル「検索ギャラリーを見る」から一部抜粋。順不同。2022/3/14現在のもの）

• パンくずリスト（Breadcrumb）
• 記事（Article）
• 書籍（Book）
• 映画（Movie）
• イベント（Event）
• ハウツー（HowTo）
• レシピ（Recipe）
• 動画（VideoObject）
• 求人情報（JobPosting）
• 商品（Product）
• よくある質問（FAQPage）
• Q&A（QAPage）
• 生命科学、社会科学、機械学習、市民および政府のデータなど（Dataset）
• 練習問題（Quiz）〔英語で利用可〕
• 数学の解法（MathSolver, LearningResource）〔英語とスペイン語で利用可〕
• コースリスト（Course）
• COVID-19（新型コロナウイルス感染症）に関するお知らせ（SpecialAnnouncement）〔ベータ版〕

わかりやすいやつから特殊なものまで、なかなかに個性的なラインナップです。（と私は思います。）
「COVID-19（ベータ版）」が追加されたことからもわかりますが、変化していくものなので、最新のものをチェックするようにしましょう。また、英語のみ対応、などという部門もありますから、説明をよく読みましょう。

蛇足ですが以前「求人情報（JobPosting）」をやろうとした時、Googleの一覧を見て、JobPostingが英語だからか、とにかく目に入りませんでした。今よりもっとデジタル不慣れだった当時の私は、「ないのか、Google？！　どこを見るんだ？」と、しばし迷走しました。
そんな時のために『検索窓』というものが画面右上にあるのでした。候補が見当たらない時は、検索してみてください。（はい、とっくに使ってる？…失礼しました。）

検索してもピンとこず、どの部門なのか悩んだ場合は、同業種のサイトが参考になるかもしれません。こっそりサイトを訪れて、ソースコードを見てみましょう。

ついでに「検索ギャラリーを見る」ページでは、「ウェブサイトを表すカテゴリを選択してください」で、部門候補を絞り込むことができます。目立たないし、そこまででもない…と思ってしまったのは私だけでしょうか。

それでは部門が決定したら、そこから入りましょう。
検索ギャラリーを見るページの機能一覧（または左メニューの機能ガイド一覧）のリンクから、該当する部門の「スタートガイド」を参照し、Googleの定型様式通りにマークアップして、規定に沿うようにします。
階層構成や構造化データの種類指定だけでなく、内容の約束事もありますので、ドキュメントをよく読むようにしましょう。

例えば、Article 部門。
AMPと非AMPページで必須・推奨項目が異なります。
特にpublisherはAMPの必須項目となっています。もちろん非AMPページに書いてあっても補足情報となり、損はないでしょう。
しかしpublisherのlogoに注目すると、AMPの場合、画像サイズが決まっています。指定サイズでなくても構造化データから見れば間違いではありません。でもGoogle側から見ると、規定と違う、となってしまいます。

また、Googleは

ページの読者に表示されないコンテンツをマークアップしないでください。

引用：Google 検索セントラル「構造化データに関する一般的なガイドライン」

と言っています。
Articleの例でいえば、公開日などを表示していなかった場合は表示するように変更したほうが無難でしょう。

例えばついでに、もう一つ。
Articleのauthorに関して、マスコットキャラが書いている設定だったとしましょう。
これはPersonなのか、所属のOrganizationにすべきか。
悩んだら、こういう時こそSchema.orgです。
ここでも検索窓を使いましょう。（英語ですが、ひるんではいけません。Chromeだったらブラウザの翻訳ボタンを押せば、説明は日本語に。便利。たまに変だけど。）
いわく、「Person：人（生きている、死んでいる、アンデッド、または架空の）」。
架空＝マスコットキャラでもよい、ということがわかります。…ちょっとアンデッドは空恐ろしい気もしますが。

(2) 補足情報を入れてみる。

Googleは、

schema.org には Google 検索では不要な属性やオブジェクトもありますが、他のサービス、ツール、プラットフォームで役立つ場合もあります。

引用：Google 検索セントラル「構造化データの仕組みについて」

とか、

コンテンツを公開しているサイトの背景情報（著者ページへのリンクやサイトの概要ページなど）など、掲載されている情報が信頼性の高いものであることを示すための情報を提供しているか

引用：Google 検索セントラル ブログ「Google のコア アップデートについてサイト所有者が知っておくべきこと」

は大事だ、と述べています。余裕があれば、マークアップしてみるのもよいでしょう。（ステップ１をこなした後であれば、きっと力もついているはず。）

補足情報を入れる場合は２つのパターンがあるでしょう。

1. Googleの部門にあるもので、定型に足す。
   定型様式に使われている構造化データtypeをSchema.orgで調べ、他の要素の情報を加える。
2. Googleの部門にはないけれど、他のページに構造化データを入れる。

（１）は気が向いたらやるくらいでよいと個人的には思います。

（２）については、情報源として有益に働きそうです。

ここでSchema.orgを覗いてみましょう。
基本やステップ１では、散々Schema.orgは調べるためだけに使うと言ってきましたが、ステップ２では手のひらを返したように、Schema.orgで、あてはまる種類を探すことにしたいと思います。
ここで述べる構造化データの「種類」とは、Schema.orgの「Type」を指すと思ってください。

サイトの「他のページ」にあてはまりそうな種類ですから、「ウェブページ」グループを見てみましょう。

▼Schema.org「WebPage（ウェブページ）」の、より具体的なType
（出典元：A Schema.org Type「WebPage」2022/3/14現在のもの。※変更される可能性があるので最新をチェックしてください。）

• AboutPage（概要ページ）★
• CheckoutPage
• CollectionPage
  • MediaGallery
    • ImageGallery
    • VideoGallery
• ContactPage（お問い合わせページ）★
• FAQPage※
• ItemPage（特定の製品やホテルなど、一つの項目に特化したページ。）☆
• MedicalWebPage（医療情報ページ）
• ProfilePage（プロフィールページ）
• QAPage※
• RealEstateListing（不動産リストページ）
• SearchResultsPage（検索結果ページ）

※はGoogle検索用の部門に挙げられています。

中でも★印を付けたAboutPageやContactPageは役に立ちそうです。

それぞれのプロパティの中から項目を選んで書くことになりますが、これが悲しいかな、マークアップ例が載っている構造化データ種類もあるのに、記載なしの種類もあるのです。
でも諦めるのはまだ早い。そういう時は、一つ上の階層WebPageを見ましょう。もともとこのWebPageを更に細かく分類したものが上の一覧になります。
親が使うプロパティを子も使っていたりします。確認して同じものがあれば、親の例を真似て書いてみるとよいかもしれません。

また、プラグインによってはマークアップしてくれるものもありますので、WordPressを使ったサイトなどは検討されてみてはいかがでしょうか。
なるほどこの種類はこういう使い方か、と勉強になることも。（白状すると、上の★印２つはプラグインの受け売りです。使ったプラグインについてはステップ３で紹介しています。）

余談ですがもしかすると、Google検索用の部門にはないんだけど、そしてGoogle検索用としては意味を成さないことを承知しているけれど、情報としては出しておきたい、という場合があるかもしれません。（本当にそんな場合があるかは不明です。）
例えば、製品ページ。Google検索用の部門「Product」の定義に、出したい情報がはまらない、という場合だったとしたら、（Google検索用としては働かないだろうということを織り込み済みで）私なら構造化データの種類は「ItemPage」を使う選択をすると思います。
ただし、個人的な意見なので正直確証はありません。それでもあえてGoogle検索用の部門ではない所を狙ってみる、というのも、事実狙っているのだとしたら価値はあるのかもと私は思います。

(3) 出したくない情報が表に出ていないか確認する。

構造化データが正しくマークアップされているか確認するのは大切です。

Google検索セントラル「構造化データをテスト」ページには２つのテストツールが載っています。
この２つの違いはもうお手のものでしょう。
Google検索用の部門の定型様式にちゃんとはまっているかは、リッチリザルトテスト（※ページの構造化データで生成される Google のリッチリザルトを確認するもので、それ以外はテストできません。）、
Schema.orgが定義する構造化データとして正しくマークアップされているかは、スキーマ マークアップ検証ツール、ですね。
皆さん、きちんとされると思うので、ここでは詳細など割愛します。

反対に抜けがちなのが、プラグインなどを使った場合に、出したくない情報が出てしまっていないかという確認です。
プラグインは自動でやってくれるので簡単ですが、出力内容のチェックは必ずしましょう。
出力設定をしたページだけでなく、一応他のページも万遍なく見ることをお勧めします。こんなの出てた、ということがあるかもしれません。

ちなみに私が使ったことのあるWordPressプラグイン『Schema』は、記事カテゴリー一覧ページに「CollectionPage」を出してくれていました。
ほうほう、この種類になるのね、なんて思った一方で、WordPressカテゴリー設定の関係でdescription内容が合っていなかったので、Schemaプラグインの公式サイトを調べ、出力OFFにしました。便利だからといって、丸投げにしてはいけないと学んだのでした。
構造化データの種類とページの一致だけでなく、そのプロパティの中身が合っているかもよく見ましょう。

道筋のおさらい

思い込みばかりの私の道中。こんなふうによくわからないまま構造化データの種類から入ると、「Google検索用に構造化データを入れる」という本筋を見失うかもしれません。
私は迷ったおかげで発見もありましたが、迷わずに行けるに越したことはないでしょう。（この記事を読んで、一緒に迷ったかのように不必要な疲れを感じていらしたら、ごめんなさい。）
最後に道筋のおさらいをしたいと思います。

基本の心得

• 構造化データの種類を書けば、Google検索用の定義に自然と はまるわけではない。
• Google検索用の構造化データは、部門別の定型様式に はめる。Schema.orgは辞典のようなものと捉える。

道筋と道標

1. サイト構成を分類する。
2. Google検索用の部門から考える。（構造化データの種類という考えを一旦捨て、アピールしたいページ内容＝どの部門か？を考える。）
3. （余裕があれば）補足情報を入れる。（ここでは種類を考えてみる。）
4. 出したい情報・出したくない情報が正しくマークアップされているかチェックする。

皆さんの進む、検索用の構造化データマークアップの道が少しでも明るくなりますように。

WordPressはオープンソース型のCMS（コンテンツ管理システム）のひとつで、個人ブログから企業サイトまで幅広く使われています。
W3Techsによると2021年10月時点で、CMSを利用した日本語サイトでのWordPressのシェアは83.7%です。

なぜこんなにWordPressは人気があるのか？
なんといっても「欲しい機能が簡単に追加できる、使い勝手のいいプラグインが豊富にある」のはサイト運用者にとってWordPressを辞められない理由のひとつでしょう。
詳しい人気の理由は「おまけ：WordPressが人気の理由」にまとめています。

ウェブ担当者通信は「知るべきことを知る」「わかる」「できる」をコンセプトにしたウェブ担当者／Webディレクター向けのメディアです。
2012年から2020年まで、ひとりで頑張るウェブ担当者/ウェブディレクター向け会員制ウェブ教育サービスを著名な講師陣と共に提供してきました。

私たちウェブ担当者通信に関わっているメンバーは自社サービスサイトだけでなく、クライアントのビジネス拡大を目的としたサイト運用にがっつり関わっています。そのためメディアとして生まれ変わって以降も、会員や講師の方々と情報交換やご相談をいただくことが多いです。

ご相談の中でも意外に多いのが「WordPressプラグインって何使ってる？」
そこで今回は、数多くのWordPressサイト運用に関わってきたウェブ担当者通信が、運用しているウェブ担当者やウェブ運用本を書いている著者にここ最近聞いてきた、本当に役に立つプラグインをまとめました。

目次

• ウェブ担当者通信おすすめ絶対導入すべきプラグイン3選
• SiteGuard WP Plugin
• QA Heatmap Analytics
• XML Sitemap & Google News
• 必要なら入れると便利なおすすめWordPressプラグイン
• プラグインを導入するときの注意点
• まとめ
• おまけ：WordPressが人気の理由

ウェブ担当者通信おすすめ絶対導入すべきプラグイン3選

• どうやってプラグインを選べばいいの？
• 多くのプラグインを使うとサイトが遅くなるって聞いたけど…
• プラグイン選びで注意しておかないといけないポイントは何？
• テーマ（テンプレート）にいろいろ機能があるけどプラグイン必要？
• サイト運用で最低限これだけは入れておくべきプラグインは？

WordPress公式プラグインだけで6万件もある中から、まずは絶対導入すべきプラグインを3つご紹介します。

「サイトに負荷をかけないこと」「サイトを安全に保つこと」「サイトからの収益アップにつなげること」に限定してピックアップしています。
ちなみに「サイトを安全に保つ」という観点ではバックアップ系プラグインを使っている方も多いです。レンタルサーバー等でバックアップを用意していることが多いため、運用を考えるとサーバーでのバックアップがお勧めです。

SiteGuard WP Plugin 【セキュリティ対策】

「SiteGuard WP Plugin」は、管理ページとログインページを攻撃から守ることに特化したWordPress公式プラグインです。

ja.wordpress.org/plugins/siteguard/

WordPressは悪意ある第三者から攻撃されやすく脆弱性を指摘されることが多い、という弱点を抱えています。攻撃されやすい理由は「人気が高く、使っているサイトが多いこと」「オープンソースソフトウェアであること」「無料であること」。
そのためWordPressサイト運用においてセキュリティ対策は必須です。

WordPressは定期的に脆弱性やセキュリティ対策のためのアップデートを行っています。WordPress本体・プラグイン・テーマのバージョンは、できるだけ常に最新版にアップデートしておきましょう。
さらに管理ページへのアクセス制限・不正ログイン対策機能をもつWordPressプラグイン「SiteGuard WP Plugin」を入れておくと安心ですね。

SiteGuard WP Pluginの機能・特徴

1. 管理ページへのアクセス制限
2. 不正ログイン対策
3. コメントスパム対策
4. 日本製プラグイン
5. サポートページすべて日本語対応
6. 無料

QA Heatmap Analytics 【視覚的にサイト改善】

「QA Heatmap Analytics」は、顧客データを活用したデータ分析やマーケティングに携わる方にも役に立つユーザー行動データ収集&分析 WordPress公式プラグインです。

ja.wordpress.org/plugins/qa-heatmap-analytics/

サイトやブログの運用をしている方はほぼ毎日WordPressにログインしています。
新規記事の作成、既存記事のリライトやボタン位置の修正など、Googleアナリティクスで数値とにらめっこしながら、ユーザーの行動意思を想像しサイト改善に活かしています。

「QA Heatmap Analytics」はプラグインをインストール・有効化するだけで、サイトに訪れたユーザーの行動データをすべて取得・保存します。ユーザー行動データはヒートマップや録画再生（セッションリプレイ）の機能を使って、WordPress管理画面上から一目で直感的にページ単位でユーザーの行動を把握できるのです。

外部の分析ツールにログインすることなく、ほぼ毎日ログインしているWordPress管理画面からすぐに確認できるので、効率よくリライトなどサイト改善に活かせますね。

QA Heatmap Analyticsの機能・特徴

1. すべてのユーザー行動データを取得
2. ページの回遊も離脱もヒートマップで直感的に把握
3. 録画再生（セッションリプレイ）
4. 分析ツールにありがちなタグ設置不要
5. 日本製プラグイン、サポートも日本語対応
6. 無料

XML Sitemap & Google News 【SEO対策】

「XML Sitemap & Google News」は、Googleなどの検索エンジンにクロール・indexさせるXMLサイトマップを、自動生成・通知するWordPress公式プラグインです。

ja.wordpress.org/plugins/xml-sitemap-feed/

WordPress5.5からXMLサイトマップ自動生成が標準実装されています。でも残念ながらXMLサイトマップとして必要な情報が満たされていません。
XMLサイトマップ自動生成・通知を行う必要があるサイトでは、WordPressプラグインの導入をお勧めします。

GoogleはXMLサイトマップの必要性について以下のように伝えています。

サイトの各ページが適切にリンクされていれば、Google は通常、サイトのほとんどのページを検出できます。 適切にリンクされているというのは、なんらかのナビゲーション（ページに配置したサイトのメニューやリンクなど）によって、重要なすべてのページに移動できる状態を指します。サイトの各ページが適切にリンクされている場合でも、大規模なサイト、複雑なサイト、専門性の高いファイルのクロールを改善する手段としてサイトマップが役立ちます。

引用：サイトマップの概要 | Google 検索セントラル | Google Developers

XMLサイトマップはすべてのサイトでSEOに効果があるわけではありません。XMLサイトマップを設置しておくことで、画像や動画、早くindexして欲しいページなどの情報とサイトの構造を、検索エンジンに的確に早く伝える効果があります。

XML Sitemap & Google Newsの機能・特徴

1. 軽い
2. 必要最低限の機能のみなので分かりやすい
3. すべての画像URL取得
4. カテゴリーページを一括で除外
5. 無料

テーマ（テンプレート）に最初から欲しい機能（たとえば「問い合わせフォーム」「SEO対策」など）が備わっていることもあります。機能が要件を満たしていればプラグインを新たに入れる必要はありません。
注意するポイントに記載していますが、不要なプラグインをたくさん導入・有効化するとサイトが遅くなったり不具合につながる恐れもあります。

必要なら入れると便利なおすすめWordPressプラグイン

つづいて、入れておくと便利なおすすめプラグインをご紹介。

Yoast SEO 【SEO対策】

「Yoast SEO」は、プラグインインストールの目安となる有効インストール数が500万以上の超人気SEO対策 WordPress公式プラグインです。

ja.wordpress.org/plugins/wordpress-seo/

SEO対策プラグインとしてもうひとつ有名な「All in One SEO Pack」も以前使ったことがあるのですが、パンくずリスト設定ができない・重いなどの理由から現在は「Yoast SEO」のほうがおすすめです。

Contact Form 7 【サイト制作】

「Contact Form 7」は、問い合わせフォームを簡単に作れるWordPress公式プラグインです。

ja.wordpress.org/plugins/contact-form-7/

「Contact Form 7」も有効インストール数が500万以上の超人気プラグインです。
プラグインのアップデートも頻繁に行われており、一時期言われていたスパムメール対策にも対応しています。

Yoast Duplicate Post 【サイト運用】

「Yoast Duplicate Post」は、投稿記事/固定記事を複製できるWordPress公式プラグインです。

ja.wordpress.org/plugins/duplicate-post/

前に書いた記事のデザインのままで記事を新しく作りたいときに「Yoast Duplicate Post」はとても便利です。また公開している記事をリライトするときに、書き換え＆再公開の機能を使うと、公開中の記事に影響することなくリライトした記事に置き換えられ、作業効率が上がります。

Broken Link Checker 【サイト運用】

「Broken Link Checker」は、リンクに異常があったときに通知してくれるリンクチェックWordPress公式プラグインです。

ja.wordpress.org/plugins/broken-link-checker/

サイト内の内部リンクと外部リンクを自動で監視チェックしてリンク切れを通知してくれます。
回遊率を上げてコンバージョンにつなげたいと思っていても、肝心のリンクが間違っていたらユーザーはがっかりしてそこで離脱するかもしれません。
ただ最近は「ちょっと重い」という声も耳にします。自動でリンクチェックすることが本当に必要であれば入れておくと便利です。

プラグインを導入するときの注意点

WordPressプラグインは「無料（有料もあり）」「便利」「簡単に使える」、WordPressサイト制作・運用をする上でとてもいいツールが揃っています。

プラグインもテーマ（テンプレート）も数が多いので、プラグイン選びに悩むことも多いですよね。
ウェブ担当者通信運営者がプラグイン（テーマも同様です）を選ぶとき、導入するときに注意しているポイントをお伝えします。

できるだけWordPress公式プラグインを選ぶ

おそらく多くの人は「やりたいこと」「機能」でプラグイン（テーマ）をネットで調べると思います。
書いている人が多くてよさそうなプラグインが見つかったら、WordPress公式プラグインでプラグイン名を入れて検索してみましょう。

個々のプラグインページで「有効インストール数」「レビュー（評価）」を見る人は多いですが、実は重要なのは「最終更新日」「開発タブに書かれている更新履歴」「検証済み最新バージョン」「PHPバージョン」です。

• 最終更新日・・・最後にアップデートされた日
• 更新履歴・・・どのくらいの頻度でメンテナンスされているか
• 検証済み最新バージョン・・・重要なWPバージョンアップに対応しているか
• PHPバージョン・・・自サイトのPHPバージョンに対応しているか

有効インストール数が多くても更新がされていないプラグインは、メンテナンスされておらず古い可能性があります。メンテナンスされていないプラグインは、他のプラグインや新しいWPバージョンとの不具合を起こす恐れがあります。また開発者自身が他サービスに移っていて、サポート対応があまりよくないことも…

WordPress公式プラグインは、WordPressコミュニティが厳しいソースコードチェックを行っています。
公式プラグインになるためには、審査がめんどくさかったり、WordPressの作法にのっとって開発しないといけなかったり、面倒な手間がいくつかあります。
この手間をクリアしたうえで公式プラグインとなっていて、第三者によるチェックがされているというのは、プラグインを選ぶうえでサイト運用者としては安心ですね。

もちろん公式プラグインでなくても素晴らしいプラグイン（テーマ）は数多くあります。
ただ第三者によるチェックはされていないため、非公式プラグインを選ぶときにはプラグインの情報やサポート対応などをしっかりと確認しておきましょう。

プラグイン同士の相性を調べる

プラグインを提供している開発者のサイトをみると、使い方マニュアルや注意事項が書かれていると思います。
そこに「○○プラグインと△△関数が競合するので注意」のようなことを書いている場合があります。

新しく導入したいプラグインと既存で使っているプラグインが「競合するかも」と書かれていた場合、おそらく解決方法がマニュアルに記載されていることでしょう。解決方法にそって対応をするか、もし解決方法が書かれていないときは、新しく導入したいプラグインを提供する開発者に問い合わせをしてから導入しましょうね。

入れすぎ注意

便利だからといってあまり使わないプラグインを大量にインストール・有効化するのはNGです。

1つ目の理由は「サーバーへの負荷が大きくなってページ表示速度が遅くなる」こと。
プラグインには単体での処理が軽いもの、重いものが存在します。
プラグインを大量に入れると、中には処理の重いプラグインが含まれていたり、処理が軽いプラグインばかりだったとしても、数が増えれば全体として処理が重くなってしまうことも…

ページ表示速度はSEOに影響します。
使わないプラグインは無効化もしくは削除するようにしましょう。

2つ目の理由は「何の目的で入れたプラグインか分からなくなる」こと。
使わないプラグインを削除しようと思っても、複数人で複数サイト運用をしていると「どれが不要か分からない」ことありませんか？
プラグインの数が増えるとアップデートの対応も大変です。また何か不具合が起こったとき、前述した「プラグイン同士の相性」について調べることが増えてしまいます。

プラグインの入れすぎには注意しましょう！

テストサーバーorステージングサーバーがあればまずはテストを

サービスをすでに提供しているサイトや既存クライアントサイトなど、不具合が生じて一定時間サイトが閲覧できなくなると困るWordPressサイトに、プラグインを新しく入れるときには以下手順を踏むとよいでしょう。

1. テストサーバーやステージングサーバーがあればプラグインを導入しテスト
2. 問題がなければ本番サーバーにプラグインをインストール・有効化

テストサーバーやステージングサーバーでプラグインを導入することで、不具合が起こらないかのテストだけでなく「欲しい機能があるか」「設定がやりやすいか」「期待した動作をしてくれるか」といった動作チェックも並行して行えます。

高速化が大事だからといってむやみにキャッシュ系プラグインを入れない

「ページ表示速度を爆速させるキャッシュ処理プラグイン○選」といった記事をよく見かけます。
キャッシュについてはある程度知識が必要となります。そこそこ有名なサイトでも間違った設定やムダな対策をとっていることも実は多いんです。

まずは自サイトでどこがボトルネックになって表示速度が遅くなっているのかを調べることから始めましょう。

ブログなどであればページキャッシュを行うキャッシュ系プラグインで高速化に効果があることも。
データベースに頻繁にアクセスするサイトやCDN（Contents Delivery Network）をすでに使っているサイトなどは、キャッシュ系プラグインを導入しても効果はありません。むしろ不具合を起こす可能性が増えてしまいます。

ページ表示速度を高速化させたいなら、ウェブ担当者としてはキャッシュ系プラグインを導入する前にまずはコンテンツサイズの圧縮を行いましょう。
そしてどこがボトルネックになって表示速度が遅くなっているのかを調べて、サーバーなどインフラ環境の見直しなどを検討するのもひとつの方法です。

まとめ

今回は、WordPressサイトで絶対導入したほうがいい「ウェブ担当者通信のおすすめプラグイン」と「プラグイン選びで注意するポイント」をご説明しました。

ウェブ担当者通信がおすすめするプラグインはこの3つ。

• SiteGuard WP Plugin【セキュリティ対策】
  ja.wordpress.org/plugins/siteguard/
• QA Heatmap Analytics 【サイト運用】
  ja.wordpress.org/plugins/qa-heatmap-analytics/
• XML Sitemap & Google News 【SEO対策】
  ja.wordpress.org/plugins/xml-sitemap-feed/

WordPressプラグインはとても便利で使いやすいものが多いですが入れすぎには注意してくださいね。

おまけ：WordPressが人気の理由

情報量が多く、ちょっとWebに詳しい人からも「WordPressがいいよ」と勧められる

WordPressが人気である一番の理由ですね。
日本での圧倒的シェアを誇るWordPressは、インストール・テーマ選び・構築からコンテンツ制作・カテゴリー設定、運用に至るまで、ネットで調べれば日本語で書かれた情報がたくさん見つかります。
しかも知り合いのサイトもWordPressで構築されていることが多いため、リアルでも相談しやすいメリットがあります。
一方で注意するポイントに記載していますが、間違った情報が多いデメリットも抱えていますので注意が必要です。

HTMLやCSSの詳しい知識がなくても自分好みのサイトが作れる

ブログは外部ブログサービスで書くのが楽ですしWebの知識も不要です。
でも外部ブログサービスを長く続けていくと、機能面やデザイン面で物足りなくなったり、自分好みのサイトにしたいと感じてきたりしたとき、WordPressであればHTMLやCSSの詳しい知識がなくてもサイト構築・運用が簡単にできます。
もちろんHTML/CSS/PHPの詳しい知識があれば、さらにWordPressサイト運用が楽になります。

テーマ（テンプレート）の種類が多い

HTMLやCSSの詳しい知識がなくても自分好みのサイトが作れるのは、テーマ（テンプレート）が無料で豊富に公開されているからです。
有料のテーマ（テンプレート）では、SEO対策など機能があったりデザインやカラーが多く簡単に変更できたりします。

プラグインで簡単に欲しい機能が手に入る

WordPressプラグインとは、WordPress単体の機能やテーマ（テンプレート）に含まれている機能では足りない、便利な機能を追加・拡張できるツールです。
テーマ（テンプレート）もプラグインも公式と非公式に分かれます。WordPress公式プラグインはソースコードチェックを行ったうえで、世界中の開発者によって6万件近く（2021年10月時点）公開されています。

「自分のWebサイトのアクセス数/収益を増やしたい」

この記事にたどり着いた方は、そう感じているのではないでしょうか？

今回は、Webサイトのアクセス/収益UPに効果が高い、ヒートマップについて書いていきます。

=>ウェブ通が作ったQA Heatmapはこちら

Webサイトのアクセス/収益を上げる方法

アクセス/収益UPは、Webサイト運営における最重要事項の一つ

アクセス/収益UPは、Webサイト運営における最重要事項の一つでしょう。

Webサイト運営の目的は、運営者によってそれぞれです。

「自社製品やサービスを多くの人に届けたい」

「役に立つ/楽しい情報を発信したい」

「アドセンスやアフィリエイトでたくさん稼ぎたい」

など、人や企業によって様々な目的があるでしょう。

しかし、どんなサイトを運営するにしても、アクセス/収益がなければ始まりません。

Webサイトのアクセス/収益を上げるために必要なこと

Webサイトのアクセス/収益を上げるために必要なことはなんでしょうか？

最近のGoogleはコンテンツ内容を重視しており、しっかりとコンテンツ計画を行えば、SEOを活用したアクセスアップがしやすくなっています。

そこで、今回は主にSEOを意識したWebサイト運営にあたり、必要な工程を整理してみましょう。

上の図のように、Webサイト運営で必要な工程は、

• Plan→計画
• Do→実行
• Check→検証
• Action→改善

のように分けられます。

PDCAサイクルと呼ばれるものですね。

具体的な例を挙げると下のようになります。

• Plan(計画)→月間PVを1,000伸ばすために、「新しく10記事を投稿する。」という計画を立てる。
• Do(実行)→アクセスが伸びそうな10記事を作成して、投稿する。
• Check(検証)→半年を目安に10記事がどれだけPVを集めているか定期確認する。
  • 月間1,000PVに達していれば、うまくいった原因を分析してノウハウとする。
  • 失敗時は仮設をたてる(例)「SEO対策が不十分だった。」「競争が激しいキーワードを狙いすぎた。」など。
• Action(改善)→仮説に応じて、改善策を考え、実行する。
  • 「SEO対策が不十分だった。→不十分だった点について、修正をする。」
  • 「競争が激しいキーワードを狙いすぎた。→新しい記事を作成する際に、競争が弱いキーワードを狙う。」

Check(検証)の段階で、解析ツールが活躍する！

Check(検証)の段階で重要なことは、改善につながるデータを取得すること

今回は、特にCheck(検証)の段階を取りあげます。

Check(検証)の段階で重要となるのは、改善につながるデータを取得することです。

改善につながるデータとは、例えば

• 記事のPV(ページビュー)数
• 検索順位
• ユーザーが関心を持った(or持たなかった)部分

などです。

目標に対して、どれくらい達成できているのかを把握することで、次にやるべきことが明確になります。

解析ツールを活用することにより、改善につながるデータを得られる！

改善につながるデータを得るためには、解析ツールを活用することが一般的です。

代表的な解析ツールには、

• Google Analytics
• Google Search Console
• ヒートマップ

があります。

それぞれの解析ツールで得られるデータが異なります。

詳しくみていきましょう。

Google Analytics、Google Search Console、ヒートマップで得られるデータ

Google Analytics、Google Search Console、ヒートマップのそれぞれを使って得られるデータは下のようになります。

Google Analyticsを使って得られるのは、PV数や滞在時間などです。

Google Search Consoleを使って得られるのは、記事の検索順位などです。

ヒートマップを使って得られるのは、記事のなかで「ユーザーがどの部分に関心を持ったのか？」、「どの部分で離脱をしたのか？」といったデータです。

あまり注目されていないが、ヒートマップは重要な解析ツール！

ヒートマップの予備知識

ヒートマップとは、記事の

• どの部分がよく見られているのか？
• どこがクリックされているのか？
• どの部分が見られていないのか？

などの情報を、ビジュアルで知ることができるツールです。

上の写真のように、

• 注目されている部分→赤色
• クリックされている部分→黄色
• 注目されていない部分→紫色

といった形で、ユーザーの動き/関心を把握することができます。

他の解析ツールに比べて、ヒートマップはあまり注目されていない

代表的な解析ツールは、

• Google Analytics
• Google Search Console
• ヒートマップ

の三つでした。

その中でもヒートマップは、他の二つのツールに比べてあまり注目されていません。

※Ubersuggest参照, 2020年度3月時点, 日本語における検索数

注目されていないからといって、効果が低いというわけではありません。

むしろ、多くの人が注目していない、掘り出し物の解析ツールと言えます。

ヒートマップを使えば、ユーザーの関心を詳しく把握できる！

ヒートマップを使うことで、ユーザーが

• Webページのどの部分に関心を持っているのか？
• Webページのどの部分で離脱しているのか？

ということがわかります。

ユーザーが関心を持っている事柄について、さらに詳しい文章を載せたり、離脱しやすい部分を改善したりすることで、記事の質を向上させることができます。

結果として、サイトのアクセスや収益向上につながるのです。

自信を持っておすすめできるヒートマップ

ヒートマップにはたくさんの種類がある。

ヒートマップにはたくさんの種類があります。

• MIERUCA(ミエルカ)
• User Heat
• Ptengine
• Hotjar
• Heatmap.me
• Fullstory
• Mouseflow
• Matomo

など、この他にも色々な種類のものがあります。

では、数あるヒートマップの中で、どれを使ったらいいのでしょうか？

既存のヒートマップの中で、無料では自信を持ってお勧めできるものはない。

ヒートマップを選ぶ基準としては、

1. 無料版があること
2. 日本語で使えること
3. ユーザー登録が必要ないこと
4. 高度な技術/知識がいらず、使いやすいこと
5. サイトのアクセスUP/収益UPに役立つ機能が豊富であること

の５つを考えたいところです。

上にあげたヒートマップについて、５つの基準から考えてみましょう。

※上に挙げた全てのヒートマップに、無料版があります。

どのヒートマップにも一長一短がありますが、登録やタグ設置が必要ということもあり「これがベストだ」とお勧めできるものはありません。

逆にいえば、ちゃんと登録や対価を払えば、どれもおすすめできます。ですからプロの方であれば、上記のどれでも要件は達せられると思いますし、英語が使える方であれば、Hotjarが一押しです。

とはいえ、英語が使えなくても、登録をせずとも、気軽に「いいヒートマップを使いたい」という方は多いでしょう。

「皆さんにWebサイト運営を成功させてほしい」という思いで、新しいヒートマップを開発しました！

既存のヒートマップには、自信を持ってお勧めできるものはありませんでした。

そこで、皆さんに自信を持ってお勧めできるヒートマップ（※）を、私たちが作成しました。

その名もQA Heatmapです！

QA Heatmapのβ版無料ダウンロードはこちら。

※今のところQAHeatmapはWordPressをお使いの方限定ですが、将来は一般サイトでも使えるようになります。

5つの条件を全てクリアするQA Heatmap！

QA Heatmapは、ヒートマップを選ぶ基準として挙げた、

1. 無料版があること
2. 日本語で使えること
3. ユーザー登録が必要ないこと
4. 高度な技術/知識がいらず、使いやすいこと
5. サイトのアクセスUP/収益UPに役立つ機能が豊富であること

の全てを満たすように作成しました。

QA Heatmapは、無料でβ版を利用できる！

QA Heatmapでは、無料でβ版を利用できるようにしています。

より多くの人に活用してもらいたいので、無料としました。

無料だからといって、性能が低いということはありません。

むしろ、既存のヒートマップより高性能なものを目指しました。

QA Heatmapは日本製のヒートマップ！もちろん日本語で利用できる

QA Heatmapは日本製のヒートマップです。

私たちが作ったものなので、当たり前といえば当たり前ですが。

そのため、日本語で利用することができます。

辞書を引きながら、英語のサービスを使う必要が無くなります。

QA Heatmapでは、面倒なユーザー登録や資料請求が一切不要！

QA Heatmapでは、利用するためにユーザー登録や資料請求をする必要がありません。

メールアドレスや電話番号などの、個人情報も登録しなくていいです。

もちろん、皆さんに営業電話をかけることはありません。

ワードプレスのプラグインなので、簡単なインストールをすれば、すぐに使えます。

QA Heatmapはワードプレス上で直感的に利用できる！さらに使いこなすためのユーザー会もある！

QA Heatmapは、ワードプレス上で直感的に利用できる点が大きな特徴です。

ヒートマップの管理画面に入るのに、ログインする必要がありません。

ワードプレス上で全ての機能が使えるので、業務効率が上がります。

専門知識がない人でも、直感的に利用できるような管理画面を目指しました。

また全国のリーダーによるユーザー会（勉強会）も開催予定ですので、より改善に役立てて頂けます。

QA Heatmapには、精読率、リンククリック、ヒートマップ、アテンションの4つの機能が搭載されている！

QA Heatmapには、

• 精読率
• リンククリック
• ヒートマップ
• アテンション

という4つの機能が搭載されています。

※上のリンクから、それぞれの用語解説に遷移します。

従来のヒートマップと比較して、高い機能性を実現しました。

直感的に、分析ができるように作っています。

ぜひ、QA Heatmapを活用して、Webメディア運営を成功させてくださいね。

β版無料ダウンロードはこちらから！

Googleはなぜページ表示速度を重視するのか？

そもそもなぜGoogleが、特にモバイルで画像の遅延読み込みを推奨しているかというと、世界中の回線環境の悪いユーザーを意識しているという理由が大きいと思われます。

そのような回線環境が悪いユーザーは、大きな画像をダウンロードすると、全然ページが表示されず、イライラします。ですから、グローバル展開しているGoogleとしてはモバイル向けの表示速度を無視できません。

実際GoogleのPageSpeed Insightsのアドバイスでも、特にモバイルで「画像の遅延読み込み」を推奨されます。

画像の遅延読み込みという対策

上記のような回線環境が悪いユーザーへの対策として。

まずファイルサイズの小さいダミー画像（下記のような画像）をダウンロードさせます。そうすれば、すぐにページが表示されるのでユーザーがイライラしなくてすみます。

しかしユーザーはダミー画像を見たいわけではないので、ユーザーがスクロールして該当の画像を見た時に、JavaScriptを用いて本当の画像を表示させる。

つまり画像を遅延読み込みさせることで、表示速度UPとユーザーの満足度UPを狙おうというのが「画像の遅延読み込み処理」になります。

画像の遅延読み込み処理を実現する方法

画像の遅延読み込みを実現するには、2つの対応が必要です。

1. サイズの小さいダミー画像を用意する
2. JavaScriptプログラムを用意する

1に関しては、サイズが小さければどんな画像でもよいです。

主に悩むのは2の部分でしょう。 まず、JavaScriptプログラムの用意の仕方は、だいたい以下のパターンにわかれるかと思います。

• 自分で簡単なJavaScriptプログラムを書く
• JSの画像遅延ライブラリを探して自分で書く
• プログラムが組めないので、ネットでプログラムを探してコピペする
• プログラムが組めないので、WordPressのPluginを使う

今回は、主に自分でプログラムを組む人に向けて情報を記載します。 WordPressも対象にして書きます。

プログラムが組めない人は、WordPressを使っているならPluginを使うのが最も良いと思います。

どのPluginがいいの？ということで悩まれると思いますが、「最新にメンテナンスされていそうなもの」がオススメです。なぜかというと、後述するのですが、Googleの推奨方式が時々かわるからです。

最新のおすすめプラグインはこちら
→Web運用本の著者にも聞いた！WordPressサイトで絶対導入すべきおすすめプラグイン3選と注意するポイント【2021年版】

ライブラリは使わない方がよい！？実装方法の比較

JSのプログラムを組もうという人であれば、まず自分で1から書くより、ライブラリを探す人が多いと思います。

しかし、少しお待ちください。画像の遅延読み込みで実現したいのは下記ですよね。

• 一番Googleに強い
• ユーザーに対して一番早く軽く画像を表示できる
• 実装（プログラム）が簡単

これらを考えると、ライブラリが唯一の選択肢ではありません。 以下、順番に。

Googleが推奨する画像遅延の手法はどれ？

Googleが推奨する方法は、ちゃんと公式ページに出ています。 こちらです。

イメージと動画の遅延読み込み -Developers Google

上記を読んでもらうとわかるのですが、GoogleはモダンブラウザでサポートされているIntersection Observerを使うことを推奨しています。 Intersection Observerは、まさに「要素が表示されたら」といった状態をコントロールするためのブラウザAPIで、画像の遅延読み込みに適しています。

普通に考えると、「ユーザーがスクロールしたら」ということで「スクロールイベント」を使ってしまいそうなのですが、GoogleはIntersection Observerの使用を推奨しています。

まぁGoogleのクローラーはユーザーではないので、スクロールして画像をちゃんと取得するというのはちょっと辛いですよね。だからこそ最近、公式サイトでGoogleクローラーはIntersection Observerを読み込めるようになった、とアナウンスするわけです。
※今後変わる可能性はありますので、上記リンク先は一度みておいてください。

JSの画像遅延ライブラリの比較

Googleの推奨を考慮するならば、ほとんどのJSのライブラリは、スクロールイベントを監視しているため、危険です。 有名なLazyLoadでもGoogleが認識できないことがあると指摘されています。私もスクロールイベントを使って少し影響があったサイトを知っています。

Lazy LoadはSEOに不向き？ Lazy Loadで表示する画像をGooglebotは認識できないことがある -海外SEO情報ブログ

ある程度メンテナンスが入るライブラリであれば、そのうちIntersection Observerを採用するかも知れませんが、やはり未来は誰にもわかりません。

従って、私の推奨は「Intersection Observerを採用し、自分でJavaScriptを組む」ということです。

そもそも、とても簡単なんです。

自分で画像遅延を実装する方法

画像の遅延表示はなんら難しい処理ではありません。下記の順番で処理するだけです。

1. 全てのimgタグを変更する。srcにダミー画像を指定し、data-src属性などに本当の画像を指定する。また処理対象にするために任意のclass名をつける
2. JavaScriptで、各imgタグを監視する（ここにIntersection Observerを使う）
3. 2.で表示されたら、data-src属性をsrc属性と入れ替えて本当の画像を表示させる

Gogole公式サイトにもコードサンプルあるのですが、ちょっとエラー処理が緩いので、実働するコードのサンプルを貼っておきます。

1の対応

imgタグを下記のようにします。 dummy.jpgがダミー画像。realimage.jpgが本当に表示したい画像です。

<img src="dummy.jpg" data-src="/img/realimage.jpg" class="lazy">

2と3の対応をするJavaScriptをいれる

下記のスクリプトを<head>の中に書くだけです。

<script>
document.addEventListener("DOMContentLoaded", function() {
  var lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          if (typeof lazyImage.dataset.srcset === "undefined") {
          }else{
              lazyImage.srcset = lazyImage.dataset.srcset;
          }
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  } else {
    // Possibly fall back to a more compatible method here
  }
});
</script>

問題点とその対処

画像の遅延処理自体は簡単なのですが、2つの問題点があります。

IntersectionObserverのサポート外ブラウザの対応と、WordPressの問題です。

IntersectionObserverサポート外のブラウザ対応

IntersectionObserverは比較的新しいブラウザでしかサポートされていないAPIです。従って、古いブラウザのために対策を考えなくてはいけません。

※先ほどのコードにもifのelse条件に”Possibly fall back to a more compatible method here”と記載があります。

一番簡単なのは「polyfill（ポリフィル）」を活用することです。

polyfill（ポリフィル）とは？

polyfillとは、「サポート対象外のブラウザ用に、自分で同等機能を供給する方法」のことです。 polyfillとは、海外にある「壁の隙間を埋めるペースト」の商品名（Polyfillaというらしい）から来た造語だそうで。

つまりIntersectionObserverのサポート対象外のブラウザでも、IntersectionObserverが使えるようなライブラリを、有志が作ってくれているのですね。 「polyfillを活用しよう！」という場合、そのライブラリを活用しよう、という意味になります。

ライブラリは下記からダウンロードできます。 github.com/w3c/IntersectionObserver/tree/master/polyfill

上記のpolyfillを活用する場合、冒頭に読み込みを一行いれて下記のようになります。

メリットはもちろん、そのライブラリを読み込めば、サポート対象外のブラウザであっても、普通にIntersectionObserverを使えるということです。

ポリフィルのライブラリを最初に読み込んだコードを下記に示します。パスはあたなの環境にあわせて書き換えてください。

<script src="/js/intersection-observer.js"></script>
<script>
document.addEventListener("DOMContentLoaded", function() {
  var lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          if (typeof lazyImage.dataset.srcset === "undefined") {
          }else{
              lazyImage.srcset = lazyImage.dataset.srcset;
          }
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  } else {
    // Possibly fall back to a more compatible method here
  }
});
</script>

<img src="dummy.jpg" data-src="/img/realimage.jpg" class="lazy">

function customize_img_lazy($content) {
  //classにlazyを付与
  $re_content = preg_replace('/(<img.*class=")/', '$1lazy ', $content);

  //classがないimgタグにもclass="lazy"を付与
  $re_content = preg_replace('/(<img*(?!.*class)[^>]*)/', '$1 class="lazy"', $re_content);

  //srcを入れ替え
  $re_content = preg_replace('/(<img[^>]*)\s+src=/', '$1 src="/img/dummy.jpg" data-src=', $re_content);

  //srcsetを入れ替え
  $re_content = str_replace('srcset','srcset="/img/dummy.jpg" data-srcset',$re_content);

  //置換したcontentsを返す
  return $re_content;
}
add_filter('the_content','customize_img_lazy');

WordPressには便利な2つのカスタム機能があります。 カスタム投稿タイプと、カスタムタクソノミー（分類）です。 一緒に使うことも多く、同時に紹介されることが多いのですが、この2つ、機能としては全く別物です。

カスタム投稿タイプは、記事を「投稿」する時に使うもの。つまり投稿機能を拡張（カスタム）するもの。 一方、カスタムタクソノミー（分類）は、記事を分類する時に使うもの。つまりカテゴリやタグ機能を拡張するものです。タクソノミーとは「分類」という意味の英語です。

残念ながら後者のカスタムタクソノミーについてはあまり情報が多くありません。 そこで、今回の記事ではこのカスタムタクソノミー機能を深掘りしたいと思います。

【目次】

1. なぜカスタムタクソノミーを使うのか？
2. カスタムタクソノミーの使い方
3. カスタムタクソノミーを使うメリットとデメリット
4. カテゴリー、タグ、カスタムタクソノミー、どれを使うべきか？その判断基準
5. カスタムタクソノミーのテンプレート
6. カスタム分類（タクソノミー）のURL
7. SEO対策として、カテゴリ構造とパーマリンク（URL）はどうするべきか？
8. カスタムタクソノミーの一覧の取得方法（関数）
9. カスタムタクソノミーを作るためのプラグイン
10. まとめ
11. 【基礎知識】カテゴリとタグの違いとは？

※QA Heatmap Analyticsは弊社で作った無料で簡単につかえるのに高機能な行動分析ツールです

なぜカスタムタクソノミーを使うのか？

一言でいえば、カテゴリとタグだけしか使えないと、ごちゃごちゃする情報をカスタムタクソノミーを使えばビシッと整理できるからです。

たとえば、ゴルフのノウハウを発信するサイトを運用しているとします。 最初はカテゴリとして「コラム」とか「特集」なんてカテゴリを作ります。こんな感じ。

【タイトル】ゴルフのボールはなぜ飛ぶのか？

【カテゴリ】

• ゴルフコラム

ところが、しばらく運用していると以下のようになってきます。

【タイトル】接待ゴルフは嫌だー！最初のドライバーショットは手を抜くべき？

【カテゴリ】

• レッスン
• ゴルフコラム
• 初心者
• ゴルフクラブ→ドライバー

【タグ】

• マナー
• 接待
• 初心者
• …

だんだんと、タグを使うべきかカテゴリを使うべきか混乱してきますし、分類も増えます。 このように長年ブログを運用していくと、「なんかうまくカテゴリを整理できていないな」「タグが多くて選びづらいな」と思ったことがあるはずです。

まさにこのような問題に対処するために、カスタムタクソノミーが存在します。

カスタムタクソノミーの使い方

カスタムタクソノミーは、前出したように、情報の分類を自由に作っていける機能です。 分類をカスタムできるから、カスタム分類（タクソノミー）と言われます。

階層化（hierarchical）してカテゴリのようにも使えますし、階層化せずタグのような分類も作ることができます。

※カテゴリとタグの違いがわからない人はこちらもご覧ください。

カスタムタクソノミーを使った場合の投稿画面の変化

たとえば先ほどの例で考えます。

【カテゴリ】

• レッスン
• ゴルフコラム
• 初心者
• ゴルフクラブ→ドライバー

上記では、どれがメインカテゴリか分かりづらい上に、サブカテゴリも増えたら記事の投稿画面もごちゃごちゃしますよね。

ところがカスタム分類で作ると、投稿画面で選ぶのがとてもわかりやすく選べるようになります。 先に画面を見て頂いた方が早いので、お見せします。

普通は「Categories」しか表示されていないですが、その下に「道具」「性別」などの分類が表示され、それぞれ選べるようになっています。

• 道具
• 性別
• レベル
• 年代
• ゴルフウェア

カスタム分類を使うと、このような分類を無限に作っていけるのです。 だいぶ情報が整理されて、投稿がやさしくなると思いませんか？

カスタムタクソノミーを使うメリットとデメリット

上記で見て頂いた投稿画面がやさしくなる以外にも、カスタムタクソノミーには様々なメリットがあります。

メリット

• カテゴリーの一覧で表示されない隠れた分類をシステム的にもつことができる
• それぞれ独自のテンプレートをあてやすくなる
• 検索条件を柔軟にプログラムしやすくなる
• 投稿画面がやさしくなる
• ユーザーにわかりやすいUIを提供できる

一言でいうと「情報をきれいに分類し、個別に細かくプログラムで管理できる」ことが主なメリットです。

一方、もちろんデメリットもあります。

デメリット

• カテゴリ系の一覧記事にはそのままでは表示されない（つまりカテゴリ系の関数{get_the_categoryなど}ではデータが取得できない）
• 汎用ではarchive.phpテンプレートが適用されるが、category系とは違う関数を追加で組み込まなくてはいけない
• 上記の流れからもわかるように、基本システムがわかる人でないと使いづらい

デメリットは、メリットの裏返しで、「個別管理する手間とプログラム量が増える」ということです。

カテゴリー、タグ、カスタムタクソノミー、どれを使うべきか？その判断基準

結論からいうと下記の判断基準がよいと思います。

【WordPressのシステムにあまり詳しくない人】

• カスタム分類（タクソノミー）は基本的に使わない
• 基本的に、タグも使わない。全部カテゴリで作る方向で考える
• タグを使うのは、上記カテゴリを横断する必要のある分類のみで使う

カテゴリでも工夫すればいろいろ対応はできますので、基本はカテゴリを使います。 タグは階層化ができない上に、増えてくるとカオスになるので、なるべく増やさず「カテゴリを横断する必要がある場合」にうまく使うようにします。

ただサブカテゴリも含めてカテゴリが100以上できそうな場合は、やはりカスタム分類があった方が綺麗にまとまりますので、その場合はシステムに強い人と一緒に作る方がいいかも知れません。

【WordPressの関数が（なんとなくでも）わかる人】

• ユーザが読みたくなるような記事の分類はカテゴリを使う
• 上記のカテゴリを横断する分類やシステム的な分類は、カスタム分類を使う
• タグも情報が混沌としていくので基本的には使わない。カスタム分類を使う

カテゴリはマーケティング目的、カスタム分類はシステム目的で使う

カテゴリはユーザーが読みたくなるような記事の分類に使います。近いイメージでいうと「サイドメニューに出したいメニュー（サブカテゴリも含む）」です。例えばゴルフで言うと「レッスン」や「マナー」、「ゴルフ場レビュー」といった分類が該当します。

上記のようにカテゴリを使うと、以下のメリットを享受できます。

• いつも通りカテゴリを使うので初期構築が簡単になる
• パーマリンクの%category%にもうまく対応できる
• カテゴリを使う前提のプラグインにも対応できる

多くのウェブサイトは「記事を読んでもらう」ことが主目的ですので、カテゴリはユーザー目線（マーケティング目的）で作るというのがポイントです。

そこまでで基礎を構築した上でカスタム分類を追加すれば、将来の拡張にも柔軟に対応できます。

つまりスモールスタートをする人には特に向いている考え方です。余談ですが、私はこの考え方が一番好きです。

一方デメリットとして、プログラムを組むときには「この時はカテゴリ系の関数」「この時はカスタム分類の関数」と意識的に切り替えねばならず、統一したコードにならないので、プログラマが混乱しやすいというのがあります。

【WordPressを細かくカスタマイズしたい人】

• カテゴリやタグは使わず、最初から全てカスタムタクソノミーを使う
• つまり、カテゴリやタグ系の関数は使わず、最初から全てのテンプレートを0から作る

すべてカスタム分類で作ると、同じルールと同じカスタム分類系の関数を適用できるので、プログラムに統一感が出るのが一番のメリットです。

デメリットとしては、最初の構築に手間がかかるのと、%category%をパーマリンクで使えなくなること。また投稿の画面もカテゴリを使用しなくなるので、一般の人にはわかりづらい投稿画面になります。

つまり標準と違うことをするので、その分、運用で考えなければいけないことと、使えないプラグインが増えたり、ユーザー教育の手間が増えます。

判断の基準になるもの

標準で用意されているカテゴリーやタグと、カスタム分類の主な違いは下記になります。

上記の違いを考慮すると、なるべくカテゴリやタグを基本路線として使った方が、ネット上の情報も多くサイト構築が容易なため、上述の判断になっています。

カスタムタクソノミーのテンプレート

カスタム分類のテンプレート

カスタムタクソノミーでは、下記の順番でテンプレートがあたります。 {taxonomy}は分類名のslugで、{term}はターム名のslugです。 例えば性別(sex)というカスタム分類を作った場合は、{taxonomy}がsexで、{term}はwomanになります。

1. taxonomy-{taxonomy}-{term}.php
2. taxonomy-{taxonomy}.php
3. taxonomy.php
4. archive.php
5. index.php

▼参考
タクソノミーテンプレート -WordPressCodex日本語版

カスタム分類（タクソノミー）のURL

カスタム分類のURL（パーマリンク）はどうなるか？

カスタムタクソノミーのアーカイブ（記事一覧）を出力するURLは、基本的に下記のルールで適用されます。

example.com/{taxonomy}/{term}/

注意点としては、階層化されていたとしてもそれは反映されません。

× example.com/area/tokyo/shibuya/
◯ example.com/area/shibuya/

記事のURLはどうなる？

記事自体のURLは、カスタムタクソノミーに属していてもいなくても関係なく、WordPress標準のパーマリンクの設定が有効になります。

それら標準のパーマリンクを変更したい場合は大抵プラグインが出ていますが、私は基本的にプラグインはなるべく使わない方がよいと思っています。 なぜなら、脆弱性のもとになったり、WordPressのバージョンアップで動かなくなったり、動きが重くなったりするからです。

そこで、そもそもパーマリンクを変えるべきなのか？ということを下記項で考えてみます。

SEO対策として、カテゴリ構造とパーマリンク（URL）はどうするべきか？

カスタム分類は、前出の通りパーマリンク設定の対象外です。問題はカテゴリです。

カテゴリを作る場合、パーマリンクに/%category%/%post%/とカテゴリを入れるべきかどうかは、悩む人も多いと思います。 なぜ悩むかというと、まずパーマリンク（URL）のディレクトリがSEOに効くと言われているからですね。

しかしそれは昔の話。たしかに200以上あるといわれているSEOファクターの一つでありますが、その効果はほとんどありません。そんなことより今のGoogleに対しては、ユーザーの好む内容の濃いページを作る方がはるかに効果的です。

複数カテゴリを設定した時、パーマリンクの制御は難しい

WordPressの標準機能では、複数カテゴリを指定した場合、記事のパーマリンクで使われている%category%には、「一番初期にできたカテゴリ（IDが若いカテゴリ）」が選択されます。標準ではカスタマイズ不可です。

どうしてもカスタマイズしたい場合、function.phpでやろうとするとかなり複雑になるので（※）、プラグインを使うのがオススメですが、たくさんのプラグインをいれると問題が発生します。

一番のオススメは、後述しますがYoast SEOプラグインを使うことです。

※ WordPressのパーマリンク処理は、基本的にDBのwp_optionsテーブルに入っている値をみながら行われます。それらを書き換えるには仕組みを理解しなくてはなりません。

■ WordPressのパーマリンク処理の参考になる記事

▼WordPress の表示ロジックを理解する
www.prime-strategy.co.jp/2499/

▼wordpressで謎の転送処理されているのを突き止める
aulta.co.jp/2017/08/15/3805.html

▼WordPressに独自リライトルールと独自URLパラメータの追加（wp_rewrite/wp_query） rensrv.com/wp/apps-and-sitemap/prepare-app/add-rewrite-rules/

ディレクトリのユーザビリティについて

SEO以外のパーマリンクのメリットを考えると、ユーザーにとってわかりやすいという利点はあります。 例えば、下記の例では、ディレクトリ構造をみれば「タワーレコード渋谷店」がどこにあるか、よりわかりやすくなります。

例）
○　http://example.com/area/tokyo/shibuya/towerrecord-shibuya
△　http://example.com/shibuya/towerrecord-shibuya

しかし、今どきのスマホで見るユーザーはURLを見ないので、あまり意味をなさないです。かつ上記のような階層化されたURLにこだわるためには、プラグインなども入れなければいけなく、それでサイトの表示速度が遅くなったらトータルではマイナスかも知れません。

総じてユーザビリティのためだけにディレクトリ構成にこだわる必要性は低いです。

パンくずナビ（breadcrumb）の重要性

GoogleはURLのディレクトリ構成よりも、パンくずのリンク構造の方を重視します。つまり、ディレクトリは割とどうでもよく、それよりパンくずをしっかり考えた方がメリットがあるのですね。

ですからYoast SEOなどのプラグインは、複数カテゴリを選んだ場合に、メインカテゴリを選べるようになっており、パンくずもうまく制御できるようになっています。

結論：記事のパーマリンクにカテゴリを含めるか否か？

上記を踏まえ、私は、下記の判断で良いと思っています。

1. 基本的に記事のパーマリンク（URL）にはカテゴリを含めない
2. もしカテゴリを含めるならば、Yoast SEOプラグインをいれて、メインカテゴリを設定して運用する
3. そもそもパーマリンクより、パンくずナビを優先する

記事のパーマリンクは標準の%postname%がよいと思います。カテゴリを含める必要はありません。

一方で、やはり含めたいという判断をされる場合。

SEOだけのために多くのプラグインを入れると脆弱性のもとになるので、あまりオススメできません。メジャーであるYoast SEOプラグインさえ入れれば、カテゴリを意識したパーマリンクとパンくずを設定してくれますので（パンくずはYoastSEOの関数を使う必要があります）安心です。

なお、Yoast SEOプラグインは、上記にかかわらず、様々なSEO補助機能があるので自分でプログラムをガリガリ書くのがメンドクサイ人にはお勧めです。

カスタムタクソノミーの一覧の取得方法（関数）

まず、関数をご紹介する前に、そもそも、データ上は、カテゴリもタグもカスタムタ分類（クソノミー）もほぼ一緒の扱い、つまり同じwp_term関連のTableに保存されています。 従って、カスタムタクソノミーは、それらTableのデータを扱う、よりWPのネイティブに近い関数を使って制御します。

関数は二種類にわかれる

関数はタクソノミー(taxonomy)に関するものと、ターム(term)に関する2種類にわかれます。

例えば、「女子向けゴルフおすすめファッション！」という記事があり、それが「性別」というタクソノミー（分類）の「女性」というタームに所属しているとして説明します。

タクソノミーに関する関数は少ない。

タクソノミー（分類）に関する関数は少な目です。その理由は、そもそも利用機会が少ないからだと思われます。

例えば上記の記事中で「性別」という言葉を使う機会など、めったにないですよね。だいたいタクソノミー名が必要な場合とは、サイドメニューに表示するか、何かバックグラウンドで処理をする時に必要かぐらいです。

以下に代表的な関数をリストアップします。

▼投稿オブジェクトからタクソノミーオブジェクトを取得
get_object_taxonomies( $object, $output );

▼検索条件を指定してタクソノミーオブジェクトを取得
get_taxonomies( $args, $output, $operator ) 

おわかりのように、タクソノミーに関する関数は、get_object_taxonomiesなどのようにtaxonomyという言葉が入っています。他にもいくつかありますので、詳しくは上記リンクを押してみてください。

タームに関する関数は多い

タクソノミーと違い、タームに関する関数は結構多いです。その理由は「女性」というタームに所属している記事一覧を表示したかったり、記事が所属しているタームを表示したいというニーズが結構多いからだと思われます。

以下に代表的な関数をリストアップします。

▼idからtermオブジェクトを取得
get_term( $term, $taxonomy, $output, $filter )

▼slug名からtermオブジェクトを取得
get_term_by( $field, $value, $taxonomy, $output, $filter )

▼ある任意の投稿に含まれるtermオブジェクトを取得
get_the_terms( $id, $taxonomy） 

その他にもいろいろあります。詳しくは上記のリンク先をご覧ください。

タクソノミー一覧取得で使える関数と、投稿(single.php)で使える関数

カテゴリなどでもそうですが、タクソノミーでも「タクソノミーテンプレート(taxonomy.php）で使えるもの」と「投稿（single.php）で使えるもの」の二種類にわかれます。

投稿(single.php）だと投稿IDが確定しているので、その投稿が属するタクソノミーをシンプルに取得できるような関数が用意されています。こちらもどこかで分類して提示したいと思います。

カスタムタクソノミーを作るためのプラグイン

カスタムタクソノミーを作りたい場合、function.phpに細かい定義を直接書き込むこともできます。 しかし定義項目が意外と多いですし、URLなども制御したい場合はいちいち調べながら進めなければいけないため、設定しやすいプラグインを使ってしまうのも手です。 

メジャーで私も使っているのはCustom Post Type UIです。これを使っていて困ったことはないです。 使い方はインターネットで検索するとたくさん出てきますし、ヘルプも充実してるのでここでは割愛します。

最新のおすすめプラグインはこちら
→Web運用本の著者にも聞いた！WordPressサイトで絶対導入すべきおすすめプラグイン3選と注意するポイント【2021年版】

まとめ

この記事では、カスタム分類（タクソノミー）について、情報をまとめました。

カスタム分類を使える（WordPressの関数がわかる）人であれば、結論として、

カテゴリはマーケティング目線の分類で使って、他はカスタムタクソノミーで作る。そしてYoastSEOプラグインを入れる

ということがオススメです。

カスタムタクソノミーを使うと、できる幅が拡がるので、ぜひチャレンジしてみてください。

【基礎知識】カテゴリとタグの違いとは？

付録的な情報ですが、カテゴリとタグの違いがわからない人は、カスタムタクソノミーを使う前に基本をおさえておきましょう。

実は、カテゴリとタグは、記事を分類するという意味では、一緒の機能です。でも2つ存在しています。なぜでしょうか？

両方使ってみると感覚的にわかると思いますが、タグは、分類するだけ。一方でカテゴリは「サブカテゴリ」を作ることができます。つまり階層化できるのです。

階層化の例は、百科事典を思い出してみるとわかりやすいでしょう。哺乳類→ネコ科→ライオンのように階層化して整理してあげるとわかりやすくなります。 一方で、タグは階層化できない分類に適しています。先ほどの例でいえば「ひげ」とか「かわいい」といったタグが考えられます。

実際に投稿画面でも、カテゴリ設定画面は階層化がわかりやすく表示されます。一方でタグは多くの中から選ぶような画面になっています。

このように分類する手法は「階層化するか否か」で2つにわかれます。

なお階層化のことを英語でhierarchicalと言います。カスタム分類の設定では、分類を階層化するか否かを選ぶことができますが、その時によくこの「hierarchical」という言葉が出てきますので、覚えておきましょう。