ウェブ制作 – ウェブ担当者通信 https://webtan-tsushin.com ウェブ担当者通信は「知るべきことを知る」「わかる」「できる」をコンセプトにした、日本初のSEO、PPC、マーケティングなどを扱うWebディレクター向け実践専門サイトです。 Sun, 11 Feb 2024 11:11:35 +0000 ja hourly 1 https://wordpress.org/?v=4.7.29 静的LPをとりあえずWordPressに対応させる方法 https://webtan-tsushin.com/stock_202206_lp-to-wp Fri, 24 Jun 2022 06:26:43 +0000 https://webtan-tsushin.com/?p=25210

サイトを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公式プラグインです。
アクセス解析も他のページと同じく簡単にできるようになりますね。

]]> Google検索用の構造化データは種類からではなく、機能『部門』から入る。 https://webtan-tsushin.com/intro-to-structured-data Tue, 22 Mar 2022 05:26:18 +0000 https://webtan-tsushin.com/?p=24564

構造化データ。
馴染みはあるでしょうか？
私はよくわからないまま、とりあえずソースコードに記述した、というのが始まりでした。そして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. 出したい情報・出したくない情報が正しくマークアップされているかチェックする。

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

]]> Web運用本の著者にも聞いた！WordPressサイトで絶対導入すべきおすすめプラグイン3選と注意するポイント【2021年版】 https://webtan-tsushin.com/wordpress-plugins Fri, 22 Oct 2021 06:16:58 +0000 https://webtan-tsushin.com/?p=23565

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

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

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

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

ご相談の中でも意外に多いのが「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」は、リンクに異常があったときに通知してくれるリンクチェック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つ。

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月時点）公開されています。
]]> WPのカスタム分類（タクソノミー）とは？活用法とメリットとデメリットまとめ https://webtan-tsushin.com/wp-custom-taxonomies Sun, 07 Jul 2019 08:47:30 +0000 https://webtan-tsushin.com/?p=20431

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%をパーマリンクで使えなくなること。また投稿の画面もカテゴリを使用しなくなるので、一般の人にはわかりづらい投稿画面になります。

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

判断の基準になるもの

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

  カテゴリ タグ カスタム分類
よく使われるカテゴリ系の関数が使えるか ○ ○ ×
ネット上の情報の多さ ○ △ ×
適用されるテンプレート category.php  tag.php taxonomy.php 
パーマリンク設定のカスタマイズ %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パラメータの追加（wprewrite/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」という言葉が出てきますので、覚えておきましょう。

]]> 【プレミアム】「WebサイトとWebアプリの違いを教えてほしい！」。その問いにあなたは答えられますか？（2） https://webtan-tsushin.com/stock_201812_website_webapp2 Wed, 16 Jan 2019 05:49:47 +0000 https://webtan-tsushin.com/?p=19800

続きはプレミアムメンバー限定（有料）です。

入会のご案内プレミアムメンバーとは

プレミアムメンバーとは

 

]]> 【プレミアム】「WebサイトとWebアプリの違いを教えてほしい！」。その問いにあなたは答えられますか？ https://webtan-tsushin.com/stock_201812_website_webapp1 Tue, 25 Dec 2018 11:30:49 +0000 https://webtan-tsushin.com/?p=19586

スマートフォンやタブレットの普及に伴い、子どもから高齢者までインターネット上にあるサービスを誰でも簡単に利用できるようになりました。そして、そんなインターネットの上に無数に公開されているサービスを支えているのがWebページと呼ばれるものです。

かつてWebページは、高価でなかなか手が出なかったパソコンからしかアクセスできませんでした。
なんて言われても、生まれたときからインターネットなどデジタルなものが身の回りにあるデジタルネイティブ世代にとってはピンきませんよね。そんな時代があったのかくらいの、教科書の中の出来事でしかないでしょう。

そんなインターネットと当たり前に生きてきた世代であっても、明確には答えられないことがあります。そのひとつが今回のテーマでもあるWebサイトとWebアプリの違いです。
現在インターネット上に公開されているWebページの集合体は、世間一般では“Webサイト”という呼ばれ方をしています。ですが厳密にいえばこれは間違いです。

Webページの一つ一つは“Webサイト”もしくは“Webアプリ”によってできています。
この2つの違いについてお分かりになるでしょうか？わからなくても心配しないでください。Webページの利用が中心の方はもちろん、サービスの提供者であってもその違いをハッキリ答えられる方は、それほど多くはありません。

しかしながら、この2つの違いをわからないままサービスを続けていってしまうと、本来の提供目的とズレたサービスを提供してしまったり、無駄なコストをかけてしまったりと、自社にとってもサービス利用者にとっても不都合が生じてしまう場合もあります。

そこで今回は今回はWebサイトとWebアプリの違いについて解説していきたいと思います。両者の違いを知ることで、既存の自社サービスの向上を図るとともに、新規サービスを立ち上げるときの参考にもしていただければ幸いです。

WebサイトとWebアプリの定義とは

さてここで質問です。いつもあなたが見ている（使っている）Webページを思い浮かべてください。
そのWebページは“Webサイト”ですか？それとも“Webアプリ”ですか？

どうでしょう、すぐに答えることができたでしょうか。

一昔前に比べて、WebサイトやWebアプリは多くの人に認知されるまでになりましたが、両者の違いについて明確に語れる人はまだそれほど多くはありません。知識がない人であれば、見た目でWebサイトとWebアプリの違いを見分けるのは至難の技でしょう。

では何をもって、Webサイト、Webアプリと定義するのでしょうか。

＜情報提供を主体としているWebサイト＞

Webサイトは一般的に、ユーザーへ情報提供することを目的として作られています。企業や役所のホームページなどをイメージしていただければわかりやすいかもしれません。自社の商品情報やサービス情報、市のイベント情報、発信する場として活用されています。いわゆる“静的”なつくりです。

画像引用：株式会社ウェブジョブズ

 

その他には、情報配信を目的としたウェブマガジンやキュレーションメディアなども、Webサイトのひとつです。

画像引用：モデルプレス

 

画像引用：ウェブ担当者通信

中には一部のコンテンツをアプリケーションに置き換えた、ハイブリッド型のWebページも存在していますが、その説明は後ほど。

＜Webアプリはユーザーのアクションを起こす＞

Webサイトが“静的”なつくりであるのに対して、Webアプリは“動的”なつくりであることが特徴です。

アプリと聞くと、多くの方はスマートフォンやタブレット、パソコンなどのホーム画面から使うものを連想するでしょう。しかし、ここでいうWebアプリとはブラウザ上で動作が可能なものを指しています。

どういうこと？と疑問に思った方もいらっしゃるかもしれませんので、ここでいくつかWebアプリの例を出してみましょう。

ネットショッピング系

画像引用：UTme!

ゲーム系

 

画像引用：SDガンダムオペレーションズ

 

ここで例に出したWebページは、世間一般ではWebサイトとして扱われることが多いものですが、その性質は前述したWebサイトとは大きく違います。一方的な情報の提供を目的としているのではなく、ユーザー側も動作が起こせるように設計されているのです。ユーザーとの対話型というとイメージしやすいでしょうか。

ユーザーの行動をデータベースに保存し、特定の動作に基づいて見た目や表示コンテンツのカスタマイズを行います。

＜WebサイトもWebアプリも使用されるプログラムはほぼ同じ＞

両者を構成するためのプログラムにはそれほど違いはありません。もちろん、特定の動作を必要とするには個別のプログラムがいりますが、基本的にはhtmlやCSSなど情報表示するための言語がベースとなっています。
Webアプリの場合はさらにブラウザ上で動作するための言語（主にはJavaScript）を用いており、これがユーザーとの対話を可能としています。

＜いつもあなたの手の中にある、ネイティブアプリ＞

アプリを語る上で外せないのが、ネイティブアプリ。少し聞き慣れない言葉かもしれませが、これこそが一般的にアプリと呼ばれているものの正体です。そう、スマートフォンやタブレットのホーム画面にあるアレのことです。

Webブラウザ上で動作するWebアプリとは違い、こちらは独立して動くことを想定して設計されています。わざわざインターネット上のWebページにアクセスする必要もなく、スマートフォンやタブレットの中だけで完結できます。※バージョンアップなどによって通信は発生します

ざっくりと言ってしまえば、App StoreやGoogle Playなどからダウンロードして使用するアプリのことをネイティブアプリと呼びます。

（ここではイメージしやすようスマートフォンやタブレット用のアプリに特化してお話しましたが、ネイティブアプリはサーバー環境などに左右されず端末スペックに依存します。そのためデスクトップパソコンやノートパソコンで使用するアプリもネイティブアプリと同種のものです。）

 

画像引用：App Store

 

画像引用：Google Play

 

ネイティブアプリでは、プッシュ通知などスマートフォンの機能を活用できることから、より集客や習慣化目的のために使われることが多いようです。

WebサイトとWebアプリ、どんなシーンで使い分けられている？

ここで一度おさらいしておきましょう。

  • Webサイト＝情報提供型（静的である）
  • Webアプリ＝ユーザーとの対話型（動的である）
  • ネイティブアプリ＝ユーザーとの対話型（インストール要）

ここまではOKですね？
では、WebサイトとWebアプリは私たちの生活においてどのように、使い分けられているのでしょうか。
ここで既存のサービスがどのようにWebサイトとWebアプリを使い分けているか、一例を見ていきましょう。

画像引用：UNIQLOオンラインストア

 

画像引用：ユニクロアプリ

 

UNIQLO

メインサイト（オンラインストア）はいわゆる静的なWebサイトを利用していますが、オリジナルTシャツを製作するコンテンツに関してはWebアプリを利用しています。まさにハイブリッド型。
オンラインでの買い物を中心に企業としての情報発信やセール情報はWebサイトで、ユーザーが楽しめるコンテンツはWebアプリを導入するなど特性をうまく活かして運用。またスマートフォン用のネイティブアプリでもUNIQLOの新着商品やセール情報を配信。在庫確認からレジにかざすとクーポンが獲得できるゲームの配信といったサービスの展開で、店舗への集客につなげています。

Facebook

コミュニケーションツールの代表格でもあるFacebook。皆さまはネイティブアプリ使っていますか？それともWebアプリ？
どちらも基本的にできることは変わりませんが、ネイティブアプリは動作が早く軽いです。またプッシュ通知によってタイムラインやページ、グループへの投稿を教えてくれるので、大事なコメントを見逃しにくくなります。ただし常駐アプリは常に何かしらの動作を行っているので電池の減りが早いです。
対してブラウザ版であれば通信量が少ないのでスマートフォンの充電節約にも繋がります。しかし残念ながら通知がきませんのでコメントの見逃しも発生しがち。しかしながら「いちいち通知されるのが煩わしい！」という人にピッタリかもしれません。

このように同じサービスであっても、ブラウザとアプリでは強みとしていることが違い、どちらにもメリット・デメリットがあるのです。この性質を理解した上で開発を行えば、新しくサービスを立ち上げる際にも開発コストの削減や人材確保の計画も立てやすくなります。

まとめ

今回ご紹介したのはあくまでも一例です。まだまだ私たちの生活と密接に絡んでいるWebサイトやWebアプリがありますし、これからもっと多くのWebサービスがリリースされていくでしょう。
もしかすると、サービスを開発運用するのは、この記事をご覧になっているあなたかもしれません。その際にどんな技術が必要なのか、どう開発を進めていけばいいのか、そもそもどんな人材が必要になってくるのか。考えなければいけないことは山積みです。

しかし、ひとりで抱えていてもなかなか解決はしませんよね。そんなときは知っている人に直接聞いてみてください。横の繋がりほど心強いものはありません。もしまわりに頼れる人がいないければ、セミナーを活用するのもひとつの手です。

ウェブ担当者通信では2019年1月25日に開催するセミナー「ウェブ担当者が今知っておきたいWeb界隈の最新動向」の中で、「ウェブ担当者が押さえておくべきフロント技術の最新知識2019」についてお伝えします。

最新の技術動向から開発の進め方、人材についての質問まで網羅。ウェブ業界のトップリーダーたちに直接聞くことができるまたとないセミナーです。ぜひご活用ください。

ウェブ担当者が今知っておきたいWeb界隈の最新動向

テーマは1年のスタートにふさわしく「ウェブ担当者が今知っておきたいWeb界隈の最新動向」。前半は「フロントエンドエンジニアリングの最新キャッチアップ」、後半ではトップリーダーに登壇いただき最新動向やみなさまからのご質問をもとにパネルディスカッションを行います。

セミナー概要・お申し込み

日時：2019年1月25日（金） セミナー／15:00-18:30、懇親会／19:00-21:00
場所：ちよだプラットフォーム（東京都千代田区神田錦町3‐21）
概要・お申し込み：ウェブ担当者が今知っておきたいWeb界隈の最新動向

]]> WordPress 5.0の新エディターGutenbergを使い始めるとき気をつけること https://webtan-tsushin.com/alert_20181213_gutenberg Thu, 13 Dec 2018 07:46:33 +0000 https://webtan-tsushin.com/?p=19516 WordPress 5.0の新エディターGutenbergを使い始めるとき気をつけること

画像：pixabay

12月7日、WordPress 5.0がリリースされました。

WordPress 5.0は大きな仕様変更があり、これまでとまったく異なる新エディターGutenbergの実装、これに伴いデータ保存形式が変更されています。

WordPress 5.0にバージョンアップをすると、今まで使っていたプラグインやテーマが利用できなくなることもあります。
必ずバックアップ取得、ステージング環境の動作確認を行なうよう気をつけましょう。

新エディターGutenbergを使いたくない場合には、Classic Editor プラグインをインストールし有効化することで旧エディターのまま利用可能です。

いつかは新エディターに対応しないといけなくなるときがくると思いますので、時間を見つけてステージング環境で動作確認、アップデートの対応をしておきましょう。

日本語 « WordPress 5.0 利用開始前に知っておくべきこと

WordPress 5.0のGutenberg（グーテンベルグ）についてよくある質問集 | コリス

WordPressのブロックエディタ「Gutenberg」に対して私たち制作者が考えなくてはならないこと | ウェビンブログ | CMSのウェビングスタジオ

]]> PageSpeed Insightsが新しくなりました https://webtan-tsushin.com/alert_20181114_psi Wed, 14 Nov 2018 08:55:20 +0000 https://webtan-tsushin.com/?p=19186 PageSpeed Insightsが新しくなりました

画像：PageSpeed Insights

Googleが提供しているウェブページの読み込み時間を計測しアドバイスしてくれるツール「PageSpeed Insights」が新しくなりました。

Chromeの拡張機能にあるLighthouseを利用して表示速度を計測するようになったそうです。
新しくなったPageSpeed Insightsでは、Chromeのデベロッパーツールにある「Audits」タブからチェックできる内容とアドバイスが日本語で分かりやすく表示されています。

ページが表示されるまで待てる時間は2秒まで、とよく言われますが、個人的には2秒でも長いなぁと最近感じてしまいます。（ウェブ通サイト遅いですよね…すみません…汗）
ページ表示速度をどうやれば高速化できるのか気になっている方はまずはPageSpeed Insightsでチェックしてみましょう。

【Google】PageSpeed Insightsがアップデートでかなり使いやすくなってる。 | Mobile First Marketing Labo

PageSpeed Insights

]]> 【プレミアム】「レスポンシブWebデザインで行こう！」の、その前に（3） https://webtan-tsushin.com/chance_201810_bef-responsive03 Tue, 16 Oct 2018 08:00:55 +0000 https://webtan-tsushin.com/?p=18646

今回の記事「レスポンシブWebデザインで行こう！の、その前に」は、実践型プロジェクト管理と精緻なサイト設計に強みをもつ株式会社グランフェアズ 代表取締役 大和誠司氏に寄稿していただきました。

前回記事(2)では、レスポンシブWebデザインへの誤解やレスポンシブWebデザイン以外でのサイト構築の方法について解説しました。
今回は、レスポンシブWebデザイン導入にあたって事前に精査しておきたいポイントについてまとめていきます。

レスポンシブWebデザイン導入要件

ここからはより具体的に、レスポンシブWebデザインの導入に当たって事前に精査したいポイントをまとめます。

投資としてコストパフォーマンスが悪かったり、システムによって選択できなかったりする場合もあるため、これらをプロジェクトの始動時に検討すると、手戻りによる時間やコスト（人的を含む）の無駄遣いを防ぐことができます。

予算とスケジュール

前回記事(2)では、レスポンシブWebデザインの導入では「初期・運用ともに工期・コストを抑えられる」と書きましたが、それはあくまでも「レスポンシブWebデザイン」「アダプティブWebデザイン」「動的配信」の3つの方法を比較した場合のことです。

これまで、PC向けサイトとモバイル向けサイトを別々で用意したときは、それぞれのサイト構築は別のタイミング（同時プロジェクトでも少しずらして）で進行したと思います。
またモバイル向けサイトはPC向けよりコンテンツを削ったかもしれません。
それぞれは完全に独立していて、別の制作会社や別のチームで対応することもできました。

レスポンシブWebデザインで構築する場合は、全てを同時並行で進める必要があります。
それも、PC向け／モバイル向けの2種類ではなくあらゆるスクリーンサイズに対応するため、デザイナーや開発者は一般的ではないサイズであってもデザインの一貫性が保たれるように、実装しながら試行錯誤を繰り返していきます。

当然、チェックする量も増えます。
そのため、過去のサイト制作よりも工期と予算がかかることを想定しておきましょう。

モバイル向けにフォーカスする

たとえば「新規サービスで具体的なターゲットのデータはないが、明らかにPCを持たない世代に向けたもの。まだこれからなので多重管理は避けたい」といった場合は、対応するスクリーンサイズを減らし、モバイル向けにフォーカスすることで工数を抑えるのも一つの手です。

極端に言うと、スマートフォンではコンテンツが見やすくボタンの配置もわかりやすいが、PCではテキストが横に間延びして読みにくく、ボタンが画面の端にあるため押しにくい、といった状態です。

この例のように、モバイルでの使い勝手に予算を集中投下するといった判断も、ターゲットユーザーを把握していれば可能になります。

ターゲットユーザーと利用シーン

事業を複数持っている企業のコーポレートサイトはたくさんのターゲットユーザーが想定されます。

このように、ステークホルダーが多ければ多いほど、レスポンシブWebデザインに向いています。
なぜなら、多種多様なスクリーンサイズでアクセスされるからです。

このような場合は、すべてのユーザーに一定の優れたUXを提供することがサイトホルダーとしてのおもてなしであり、ひいてはその企業の姿勢を示すことになります。

ターゲットが絞られる場合／利用シーンが異なる場合

上記の「予算とスケジュール」で触れましたが、ユーザーの90％がスマートフォンなど、明らかにユーザーの偏りがあれば、そのスクリーンサイズで最も快適に閲覧できるように作ることを検討すべきです。

特にBtoCサービスを提供するサイトの場合、ターゲットユーザーが限定されることがあります。

管理の多重化を許容できるなら、既存のPC向けサイトはそのままに、モバイル向けサイトをアダプティブWebデザインで最適化する方法もありますし、PCとモバイルでユーザーの利用シーンが全く異なるなら、モバイルアプリを開発するという選択肢もあるでしょう。

モバイルファースト

繰り返しになりますが、レスポンシブWebデザインは、あらゆるスクリーンサイズで一定の優れたUXを提供するために汎用化する技術です。この「UX」にはコンテンツも含まれます。

レスポンシブWebデザインのデメリットとして、モバイル閲覧時の表示の遅さが挙げられますが、この大きな要因の一つが、旧来の「デスクトップから考える」という進め方にあります。

デスクトップはスクリーンが広いため、思いつく限りの情報を掲載することができ、見通しのいいメニューから深い階層に誘導することも難しくありません。
旧来のように画像での装飾にこだわることもできます。

PCサイトからサイトの設計・コンテンツの精査を始めてしまうと、いざモバイル向けのサイトにしたときに以下のような問題が出てくることがあります。

  • コンテンツ分量がモバイルで見るには多すぎる（精査がされていない）
  • どこを押せば目的のページに行けるか分からない（遷移設計がモバイルに合っていない）
  • デザインがごちゃごちゃして見にくい（デザインがモバイルに合っていない）
  • ごちゃごちゃをモバイルでは隠したけど表示が遅い（不要な要素をロードしていることに変わりはない）

といったことになり、モバイルユーザーを思って改修したのに、モバイルユーザーに不快感を与える結果になってしまいます。

これらの症状を回避するため、モバイルファースト（モバイル向けサイトから設計・コンテンツを考える）が推奨されますが、それが難しいとしても、常にモバイルでの見え方・操作を念頭に入れながら、並行して設計をしていくという考え方が必要です。

もしプロジェクトメンバーに「PC向けサイトのデザインをすぐ出して」という人がいたら、まずは、今から取り組もうとしていることはどういうことなのかを納得してもらってからスタートすることをお勧めします。

コンテンツ内容

少し制作寄りな話になりますが、レスポンシブWebデザインは「グリッド」と呼ばれるブロックを積み上げてレイアウトを構成し、そのブロックの積み方をスクリーンサイズに応じて可変させることで、あらゆるスクリーンサイズに対応します。

よって、一つのブロックの中身が非常に細かい場合、別の言い方をするとページ内のコンテンツがブロックに分解できないような内容を扱うサイトは、レスポンシブWebデザインに向いていません。

おそらくその場合は現状、PCでの閲覧が主だと思われるので、現在のPC向けサイトはそのままに、別のコンテンツ内容でモバイル向けサイトを作成する、アダプティブWebデザインが候補になります。

ECカートやCMSなどのシステムの仕様

ECシステムのショッピングカート

ASP型のECシステムでショッピングカートがレスポンシブWebデザインに対応しているサービスはまだまだ少ない状況です。むしろ、対応しているサービスの方が限られていると言った方がいいでしょう。

また、対応済みとしているサービスも実際には不完全な場合があるので、注意が必要です。
さらに、ECシステムの仕組み自体は対応していても、そのシステムを組み込むベンダーが不慣れなことも散見されます。

ASP型のECシステムの対応が遅れていることから、フルスクラッチでオリジナル開発したり、オープンソースをカスタマイズしたりすることも選択肢になりますが、プログラミングとUIを同時に担当できるベンダーは少なく、実際には分離して進められることが多いと思います。

この場合、デザイン会社から提供されたHTMLをシステム会社が組み込むフローになるのですが、相互の連携やUIへの対応不足により、表示速度の遅さやレイアウトの崩れ、ボタン等のタッチアクションの反応悪化、といった不具合がよく起こります。

これらを避けるには、開発に強いUI会社を選択するか、開発とUIデザインを橋渡しする会社（人物）を別途アサインするかを検討したほうがいいです。
ECサイトにレスポンシブWebデザインを適用する場合、このベンダー選択が重要な要素になります。

CMS

あまり多くはありませんが、CMSでも対応していないものがあります。
具体的に言うと、システムで管理しているテンプレートがPC用とモバイル用で分かれていて、振り分けを解除できない場合はレスポンシブWebデザインを実装することができません。

WordPressやMovableType等の一般的なものであれば気にする必要はありませんが、現在使っているCMSが特殊な場合は、事前の確認が必須です。

運用体制と運用予算

「レスポンシブWebデザインの優位性」として「二重（多重）管理を避けられる」点を挙げました。すべてのスクリーンサイズに対してテンプレートとなるHTMLは1つなので、共通部分の変更は一回で済みます。

ここで注意したいのは、そのHTMLは「レスポンシブWebデザインで制作されたHTML」だという点です。レスポンシブWebデザインはこれまでの制作技術と多くの部分で異なるため、HTML構造を変更する場合は、その技術への知識が必要です。

HTMLは1つでも、すべてをサイトオーナー側で管理することは難しいということを前提に運用体制を組み、運用予算を想定しておきましょう。
また同時に、事前に運用要件（担当者、リテラシーレベル、更新頻度、更新範囲、承認フローなど）を洗い出し、CMSの機能や範囲を適切に定めることと、プロの手を借りる範囲を決めておくことも重要です。

まとめ

この記事では、最近特に依頼が多くなったレスポンシブWebデザインでの構築について、それ以外の選択肢を踏まえつつ、採用する上での注意点をご紹介しました。
本記事がウェブ担当者のみなさまの「転ばぬ先の杖」となれば幸いです。

次回はより具体的に、レスポンシブWebデザインでの構築技術について、弊社が導入している方法をご紹介します。

]]> ウェブ通を常時SSL化したよレポート https://webtan-tsushin.com/chance_201807_ssl Tue, 21 Aug 2018 09:00:40 +0000 https://webtan-tsushin.com/?p=18208

お気づきでしょうか？
ウェブ担当者通信も常時SSL化に対応しました。
PHPの知識の少ないデザイン系ウェブ担が、SSL化にチャレンジ！レポートします。

経緯

SSL証明書はかなり前に発行され、サーバー側の設定はできていました。
いよいよタイムリミットです。
→ サイト全体のHTTPS化、2018年7月までに対応したほうがユーザーは安心です

「とりあえずやってみて。はまったら内容をシェアして」
と、代表の丸山から投げかけられましたので、調べながら作業しました。

主に、下記サイトを参考にさせていただきました。
【コピペでOK】WordPressサイトを簡単にSSL化する方法（初心者にもおすすめ！無料 WordPress テーマ Principle）

ちなみに、ウェブ担当者通信は、Wordpressと静的HTMLの混在するサイトです。
DB（MySQL）も使用していますがSSL化には影響しないので、今回はDBには触れません。

【事務局注】
今回はなるべく最低限の労力でSSL化をすることを目的にしました。従ってDBなどのエンジニアの作業が必要そうな箇所は極力避けて、その内容をシェアいたします。

各種設定

SSL化とは何か？

SSL化は、ご存知のようにhttps通信時に正しくサイトを表示できれば完了です。

つまり、サイト上の各コンテンツがhttpsで正しく表示できればよく、かつhttpでアクセスされた時にはhttps通信にリダイレクトするようにすればよいことになります。そのように考えればやることはシンプルですね。

【事務局注】
多くのhttps化マニュアルが複雑にみえるのは、https通信に対応できないアフィリエイトプログラムがあるなど、URLがhttpsに変わってしまうため、SNSでのカウント数がやり直しになることを避けることも含めてマニュアル化されているからです。今回はシンプルにSSL化だけにトライします。

ウェブ通のSSL化で行ったこと

SSL化のおおまかな流れです。

  • WordPressの設定
  • サイト全体の設定
  • 画像のURL変更
  • 確認・修正
  • Googleの設定

作業前にサイト全体のバックアップをしましょうね。

WordPressの設定

ダッシュボード「設定」→「一般設定」を開きます。
WordPress アドレス (URL)、サイトアドレス (URL)の「https://」に書き換えます。

サイト全体の設定

「.htaccess」を変更します。
書き方を間違えると無限ループに陥るので、バックアップは必ず保存しておきます。

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

画像ファイルのURLをhttpsに変える

WordPressの記事に、「メディアを追加」から画像を追加すると、「http://webtan-tsushin.com/…」のように絶対パスで画像が挿入されます。
この部分を「https://webtan-tsushin.com/…」に変更する必要がありますが、500記事以上あるので手作業での修正は現実的ではありません。

プラグインを利用する場合も多いようです。
ウェブ担当者通信では、記事内の文字を変換するコードを挿入することにしました。

WordPressテーマ内の「functions.php」にコードを追加します。
こちらも、バックアップを保存してから作業します。

参考サイト
【コピペでOK】WordPressサイトを簡単にSSL化する方法（初心者にもおすすめ！無料 WordPress テーマ Principle）

「5.4 記事内の画像」で紹介されている、記事内の「http」を「https」に書き換えるコードです。

…ちょっと壁にぶつかりました

ウェブ担当者通信は、PCとスマホで異なるテーマを使っています。
PC版は書き換えばっちりでしたが、スマホ版は機能しない…
シンプルなコード、眺めてもどこがネックになってるのか分からず…

PHPに詳しい担当さんに助けてもらいました！
解説は後ほど。

設定後の調整

書き換わらない画像のURLを手作業で変更

記事以外の画像や外部から直リンクの画像は、上記のコードでは変換されません。
今回変換されなかったのは、「この記事を書いた人」のプロフィール画像と、書籍紹介で使用しているAmazonの書影です。

執筆者のみなさんのプロフィール画像は、アップしなおしました。
書影は、Wordpress内の記事、静的ページ、ともにHTMLを編集して「https」に書き換えました。

アドレスバーの「！」マークをクリックすると警告が表示されます。

「F12」キーを押してコンソールを表示します。
黄色い三角の警告マークで該当箇所を探し、HTMLを修正します。

ウェブ通はボリュームが多くないのでひとつずつ作業できましたが、ページ数が多いとたいへんかも…。

…ほかにも修正箇所がありました

メンバーズページのアクセス制限をかけてる部分も、フォルダ内のfunctions.phpを修正しました。
自分では気づかず指摘してもらったので、ほかにも問題のあるページがあるかもしれません。
（´-`）.｡oO（見つけたら教えてくださいね）

Facebookのいいね！

「いいね！」の引き継ぎも試してみたのですが、うまくできていませんね…。
プラグインは使いたくないし…。
検索していくうちに、「あきらめる」を選択するサイトもあるようなので、あきらめようかしら。

「いいね！」してくださったみなさん、寄稿してくださったトップリーダーのみなさん、申し訳ありません。
今後ともよろしくお願いいたします。

【事務局注】
いいね！などの数がリセットされてしまうのは、httpからhttpsに変わることで、多くのSNSが別ページになったと認識するためです。この対策は公式サイトに方法が載っていることがあります。Facebookはこちらです。
今回引き継ぎがうまくいかなかったのはFacebookのクローラーが新しいhttpsにリダイレクトされてしまうためだと考えられます。つまり昔のURLは消えたと思ってしまうのです。
今回の作業は「技術者以外でもhttps化に対応する」という趣旨のため、ウェブ通では対応をしないことにしましたが、技術的な対処が可能な場合は公式ページを参考に対応されると良いと思います。

ただし、Facebookの仕様はコロコロ変わることもありますし、ogタグも無視されることもあるので、うまく動かなかった場合は潔く諦めることも選択肢に入れてよいと思います。

Google各サービスの設定

アナリティクス、Search Consoleの設定。
こちらは担当者に変更してもらいました。

サーチコンソールをhttpsで設定して、それを既存のGoogleアナリティクスの紐付けにかえます。

スマホサイトの画像が書き換わらなかった件

WPの記事を表示させるためのテンプレートは「single.php」ですね。
通常、記事を表示させるときは「the_content」というコマンドを使いますが、ウェブ通のスマホでは「get_the_content」が使われています。

the_contentとget_the_contentの違い（PHPプログラミングの教科書 [php1st.com]）

WordPress関数のthe_contentもget_the_contentも、ページの本文を取得する関数です。違いは、the_contentは本文を画面に表示するのに対して、get_the_contentは変数などに本文を返します。

（略）

もう1つの違いは、get_the_contentは本文をそのまま取得するだけですが、the_contentは取得した本文にフィルターフックが適用されます。

逆にいえば、「get_the_content」はフィルターフックが機能しないということ。
前述、参考サイトのPHPに使われている「add_filter」が動作しません。

なので、「get_the_content」で取得した情報を「the_content」形式として呼び出し、前述の関数を適用できるように、「single.php」を修正してもらいました。

$p_cont = get_the_content();
$p_cont = apply_filters( 'the_content', $p_cont); //この行を追加

WordPressのadd_filterとapply_filtersのまとめ（小粋空間）

チーム力

結論として。ひとりでSSL化はできませんでした。
そもそも、ウェブ通のサイトもチームで作成しています。
ひとりでは目の届かない部分、気づかない部分もあります。
また、PHP修正のように担当者によっては弱い部分もあるでしょう。

周りの人、専門知識のある人を巻き込んで作業できるのがベストですね。

ただし。
SSL化をためらうよりも、「まずはやってみる！」ことをオススメします。
やってみてうまくいかないこともありますが、致命的なエラーにはなりませんから。

]]>