CLSとはCumulative Layout Shift（累積レイアウトシフト）の略語で、この数値が高いほどにサイト閲覧中にガタっとレイアウトがずれていることを意味します。 このズレが多いページはサーチコンソールでCLSエラーとして通知されます。

CLSはユーザー体験を悪化させるので、なるべく早い解消が必要です。 そんなCLSエラーの調査・解消方法についてお話します。

CLSエラーの多くは「領域サイズ未指定」が原因

CLSエラーのほとんどが「領域にwidthとheightを指定していない」ことが原因です。

領域にwidthとheightを設定していれば、ページ読み込み時にあらかじめ領域サイズの枠が確保され、後から枠内に描写されていきます。 しかし未設定の場合、領域が読み込まれるタイミングで枠が確保されるので、領域を読む毎にレイアウトシフトが発生します。

CLSエラーの原因のほとんどは「画像・広告・カルーセルスライダーなどの領域にサイズを指定していない」ことにあります。 特にheightの未指定はCLSに繋がることが多いです。

領域にはwidthとheightを指定しておきましょう。 またはサイズを指定したdiv領域などに放り込むのも良いです。

widthとheightには数値以外にも%やcalc関数を指定することも可能です。 レスポンシブサイトなどでサイズが流動的な場合はこちらを利用しましょう。

CLSエラーの補足情報

サーチコンソールのCLSエラーはファーストビュー

サーチコンソールで通知されるCLSエラーは、見た感じではファーストビューに限ったもののようです。 なのでエラーを解消するだけなら画面外の領域はとりあえず考慮しなくて良いかもしれません。

意図的な領域移動処理もCLSとして計測されてしまう場合があるので、そういったものはファーストビューに入れない方が無難です。

CLSのチェックは「モバイル」と「PC」双方から

CLSレポートには「モバイル」と「PC」に分けて調査されるものが多いです。 これらは主に端末サイズと接続速度に違いがあります。

どちらもエラーになっていたら根本的にページがまずいですが、片方だけエラーになる場合もあります。 例えば小画面ではファーストビューに表示されない部分に問題がある場合、PC版のみがエラーとなります。

確認・修正・検証も両端末の違いを意識して行う必要があります。

CLSはブレる

CLSは接続タイミングによってブレがあります。 修正確認してCLSが解消されたと思ったら、たまたま小さくカウントされていたなんてこともあります。

CLSの確認はリアルタイム計測ならスーパーリロードを数回、レポートなら数回作成して確認した方が良いでしょう。

CLSの調査方法

CLSを調査・検証するツールを紹介します。

PageSpeed Insights

CLSエラーの有無は「PageSpeed Insights」で確認しましょう。

ページURLを入力して分析し、Cumulative Layout Shift（CLS）と書いてある項目が赤くなければOKです。

なおPageSpeed Insightsには「フィールドデータ」と「ラボデータ」があります。 フィールドデータは過去28日の収集期間から割り出したもので、修正して即確認しても数字には反映されません。 解消されかをその場で確認する場合は「ラボデータ」のところを見ましょう。

Web Vitals

PageSpeed Insightsは色々なデータを解析してくれる一方で、解析には時間がかかります。 CLSだけ確認するならChromeの拡張機能「Web Vitals」を使う方が簡単です。

拡張機能を入れて表示される小窓が、サイトアクセス時に赤くなっていなければOKです。

なおCLS以外にも調査項目があり、いずれかに問題があると小窓が赤くなります。原因がCLSにあるかは小窓をクリックして確認してください。

Lighthouse

chromeのデベロッパーツール「Lighthouse」を使うのもおすすめです。 chromeでページを開いて右クリック→検証を選択し、一番上のタブから「Lighthouse」を選択ましょう。（なければ「>>」の中にあります）

Generate Reportでレポートを作成して「Cumulative Layout Shift」の評価結果を確認しましょう。 問題ある場合「Avoid large layout shifts」を確認すれば、どの要素が問題だったかを教えてくれます。

developer tool

CLSの原因がなかなか特定できない場合、Chromeのdeveloper tool機能を使うのがお勧めです。 chromeでページを右クリック→検証から機能を利用できます。

まずNetworkタブを選択し、Disable cacheにチェックを入れ、Onlineバーの「Slow 3G」を選択します。 これは回線速度が速いと一瞬でページが表示されてしまい、レイアウトシフトの原因が探りにくいからです。 （動体視力に自信があるなら不要です）

次にPerformanceタブを選択し、下方にあるRenderingタブ内のLayout Shift Regions にチェックを入れます。 これによりレイアウトシフトした領域が青く光るようになります。

以上の下準備が終わったら、デベロッパーツールのリロードボタンを押してみてください。 レイアウトシフトした箇所が青く光るので、そこから原因の箇所を大よそ絞り込めます。

ページコンテンツを削ってみる

解析ツールを使用しても、CLSが起きている原因がいまいち絞り込めないこともあります。 その場合はページコンテンツ自体を削って原因を探すのも手です。

例えばCLSが発生しているページの前半部をばっさり削り、それでCLSが解消されれば原因は前半部に、解消されなければ原因は後半部もしくは両方にあると特定できます。 こうして削る範囲を少しずつ狭めていけば、やがて問題となっている箇所を特定できることでしょう。

WordPressサイトにて商品やアイテムなどの細かいデータの集合を使いたい場合があります。 色々やり方はあり一長一短ですが、その一つにWordPressデータベースに独自テーブルを追加する手法があります。

ここでは独自テーブルの使い方をお話します。

データベースに独自テーブルを追加する

まずデータベースに独自テーブルを追加しましょう。 私はインストールしているphpMyAdminでSQLとUIを使いながら作りました。

この際テーブルはWordPressデータベースの中に作り、またテーブルの接頭辞を合わせることに注意してください。 デフォルトなら「wp_」ですが、変更しているなら周りのテーブルに合わせましょう。

マルチサイトの場合、接頭辞はサイトIDまでを含めたものになります。

wp-db.phpを修正する

WordPressに追加したテーブルを認識させます。 具体的にはWordPressとデータベースのやり取りを記述している、wp-includeフォルダ下のwp-db.phpにテーブルを追記します。

直接wp-db.phpを修正しても良いですが、その場合アップデートでファイルが更新されてしまうと記述が消え、再度同様の修正を行う必要があります。 その面倒を避けるため、db.phpにてオーバーライド（別のphpファイルを優先する）した方がスマートです。

「wp_product（接頭辞wp_）」テーブルを追加する場合は、以下のように修正します。

直接修正する場合

wp-db.phpの259行辺りの記述に、接頭辞を外したテーブル名を追記します。

**
 * List of WordPress per-blog tables
 *
 * @since 2.5.0
 * @see wpdb::tables()
 * @var array
 */
var $tables = array(
  'posts',
  'comments',
  'links',
  'options',
  'postmeta',
  'terms',
  'term_taxonomy',
  'term_relationships',
  'termmeta',
  'commentmeta',
  'product',
);

オーバーライドする場合

WordPressはwp-contentフォルダ下にdb.phpがあると、wp-db.phpよりもdb.phpを優先してくれます。 db.phpの内容でwp-db.phpをオーバーライドできるということです。

この場合はwp-db.phpは修正不要で、代わりにwp-contentフォルダ下にdb.phpファイルを作成します。

なおアップデートによりwp-db.phpの該当箇所で読み込むテーブルが増えた場合、db.php側を同様に修正する必要があります。 滅多にないことではありますが、どこかに書き残しておいた方が良いでしょう。

SQLでテーブルからデータを引っ張ってくる

後はSQLでデータを引っ張ってくればOKです。

私の場合はfunctions.phpにショートコードにて処理を記述し、投稿からショートコード経由でデータを引っ張ってきています。 更にショートコードの引数に検索条件を指定することで、取得データを変えられるようにしています。

以下はwp_productテーブルからcategory列の値がhogehogeのデータを抜き出し、name列,price列,category列の値をリスト形式で出力する場合の例です。

function.php

unction shortcode_tableGet($atts){
  global $wpdb;
  $rows = $wpdb->get_results("SELECT * FROM $wpdb->product $atts[0]");

  foreach($rows as $row){
    $arg .= "<div class='productList'>";
    $arg .= "<ul>";
    $arg .= "<li>$row->name</li>";
    $arg .= "<li>$row->price</li>";
    $arg .= "<li>$row->category</li>";
    $arg .= "</ul>";
    $arg .= "</div>";
  }
  return $arg;
}
add_shortcode('tableGet', 'shortcode_tableGet');

WordPress投稿

lt;p>WordPressの投稿から、ショートコード経由でwp_productのcategory列の値が'hogehoge'のデータを取得する</p>
[tableGet "WHERE category='hogehoge'"]

以上、私がWordPressに独自テーブル追加対応したことの備忘録でした。

ちなみにですが、上記のような仕組みをサイトネットワークにある「名言集」というサイトに使っています。 そのサイトでは名言リストを独自テーブルに持ち、投稿から条件指定したショートコードで各種名言を抽出しています。

サイトをテーブル、投稿をレコードに見立てる方法もある

サイト自体を独自テーブルとして見立てる手もあります。 具体的にはサイトをテーブル、投稿をレコードに見立てて使います。

投稿はタイトル、本文、カテゴリ、タグなどの値を持っているので、ここを属性としてデータを入れれば立派にレコードとして機能します。 足りなければショートコードやカスタムフィールドを利用すればいくらでも項目を増やせます。またレコードの抽出もアーカイブや検索機能で可能です。

これならシステムの修正も、SQLやデータベースの知識も不要です。 これで要件を満たせるのなら、こちらで済ます方が簡単です。

ただし複数のテーブルを管理したい、普通の投稿もしたいなど、要件が増えるとこの方法では難しくなってきます。 そんな時にはデータベースに独自テーブルを作った方が良いでしょう。

サイト制作に際して、画像クリックで拡大表示されるいわゆる「lightbox」系のプラグインを探していました。 他にも「画像をスワイプ可能」など希望要件が色々ありまして、色々探しながら比較してみたのです。

そして辿り着いたのが、今回ご紹介する「baguetteBox.js」です。 これ素晴らしいプラグインですね。

baguetteBox.jsとは

baguetteBox.jsとは、画像をクリックした時に拡大表示するいわゆるlightbox系のプラグインです。 以下の公式デモページを見ていただければ、大よその機能が分かると思います。

数あるlightbox系プラグインの中でbaguetteBox.jsを選んだのは、以下の理由からです。

スワイプ可能

画像を特定のクラスでまとめて、スライドショーのように拡大画面でスワイプすることが可能です。 画像がメインコンテンツとなるサイトだったので、この機能は嬉しいです。

画像が画面一杯に広がる

baguetteBox.jsは特に設定を変えずとも、拡大画像が画面一杯（あるいは元の画像サイズ）に広がってくれます。 折角拡大表示するんだから、画面一杯に広がって欲しかったんですよね。

拡大処理が簡潔で早い

拡大描写に凝った処理をするプラグインも多いのですが、あれユーザーの利便性とトレードオフになっていると思うんですよね。 その点baguetteBox.jsの描写は簡素で高速なのが素晴らしいです。

拡大画面に文字が入れられる

baguetteBox.jsは拡大画面の最下段に文字を入れることが出来ます。 簡素な内容ではありますが、あるのと無いのではユーザーが受ける印象も違ってきますからね。

jQueryいらず

後で気付いたんですが、これjQueryの読み込み要らないんですね。 私のサイトは他の処理で読み込んでいるのであまり関係ありませんでしたが、読み込み不要なサイトであれば速度の向上が望めます。

baguetteBox.jsの導入方法

まずGitHubからプラグイン一式をダウンロードして展開しましょう。

必要なのはdistフォルダに入っている.jsと.cssの2ファイルのみです。 通常のファイルと、改行とスペースを取り除いて最小サイズにしたminファイルが用意されているので、好きな方を使いましょう。

CSSはheadタグで、JavaScriptはbodyタグ終了直前で読み込むのが良いでしょう。 そしてJavaScriptを読み込んだ後に、任意のクラスでbaguetteBoxを実行する記述をします。 以下はgalleryクラスでの起動を前提としたものです。

  window.onload = function() {
    baguetteBox.run('.gallery');
  };

これで準備は完了で、後はHTMLに記述して使うだけです。 拡大画像とサムネイル画像は、別でも同一でも問題ありません。

<div class="gallery">
  <a href="拡大画像のURL" data-caption="拡大時に表示したい文字">[eyecatch "サムネイル画像のURL" "画像の説明"]</a>
  <a href="拡大画像のURL">[eyecatch "サムネイル画像のURL" "画像の説明"]</a>
</div>

以上、baguetteBox.jsの紹介でした。 とても素晴らしいプラグインですね。

マルチサイトを運営していると、サイト毎に微妙にやりたい事も変わってきます。 例えば親サイトの検索は横断検索にしたいとか、カスタム投稿タイプの設定をサイト毎に別のものにしたいなどがあります。

テーマを完全に分けるのも一つの手段ですが、それほどの違いでなければサイト毎に条件分岐して処理を変えるのも手です。 WordPressにおいては「親サイトと子サイト」または「ブログID」で条件分岐させることができます。

親サイトと子サイトで条件分岐

親サイトと子サイトで条件分岐させたい場合、is_main_siteで判定できます。

  // 親サイトでの処理

  // 子サイトでの処理

ブログIDで条件分岐

ブログIDで条件分岐させたい場合、ブログIDを指定して処理を記述することができます。

ブログIDは[サイトネットワーク管理]→[サイト]→[IDを知りたいサイト]をクリックし、URL末尾の「ID=n」に表示されているものです。

f ( get_current_blog_id() == 1 ) {
  //ブログIDが1のサイトの処理
}

サイト毎の使用テンプレートファイルの振り分けなんかもよくやります。

witch(get_current_blog_id()){
  case 1:
    get_template_part('frontpageA');
    break; 
  default: 
    get_template_part('frontpageB');
}

記事やサイトのURLを変更した場合、何も対応をしないと以前のURLにそのままアクセスされてしまいます。 折角アクセスして貰ったのに404ページを出してしまうのは申し訳ないですよね。

そんな時に設定するのがリダイレクトです。 リダイレクトは特定のURLにアクセスされた時に特定のURLへ転送することが可能です。 これを上手く使えばURLを変えても特に通知することなくそのままの感覚でサイト運用が可能です。

リダイレクトとは

ウェブサイトを運営しているとドメイン、パーマリンク、記事URLを変更したくなる時があります。 しかし安易に変えてそのままにしておくと、ユーザーや検索エンジンはURLが変わったことが分からず、以前のURLにアクセスしようとしてしまいます。 当然ページが存在しないので404になり、サイトの機会損失になってしまいます。

リダイレクトはそれを解消する手段で、サイトの特定ページにアクセスがあった場合に、別のページに遷移させることができます。 これによりユーザー側に意識させることなくURLを変更することが可能になります。

例えば記事URLを「page1」から「page2」に変更したとします。 この場合は「page1へのアクセスをpage2に向ける」ように設定すれば、既に存在しないpage1を見ようとしたユーザーをpage2に誘導できる訳です。 もちろんpage2へのアクセスはそのままです。

リダイレクトはページ単位だけではなく、ディレクトリ単位やドメイン単位で設定することも可能です。 他にもサイトURLのwwwあり・なしを片方に寄せたり、httpへのアクセスをhttpsに寄せたりもよく施される設定ですね。

リダイレクトには301リダイレクトと302リダイレクトがあります。 どちらもリダイレクト結果は同じですが、検索エンジンの解釈が変わるので用途に合った方を選択しましょう。 検索エンジンについては次項で詳しく説明します。

301リダイレクト

301リダイレクトは永続的なリダイレクト設定を表します。 サイト移転やURL変更の際に設定することが多いです。

302リダイレクト

302リダイレクトは一時的なリダイレクト設定を表します。 ページの工事中やキャンペーン期間中など、一時的にリダイレクト処理を設定したい時に使います。

301リダイレクトはSEO評価を引き継げる

検索エンジンのサイトやページ評価は、URLに対して蓄えられていきます。 つまりURLを変更してしまったら、せっかく今まで積み上げてきたページ評価を失ってしまう訳です。

私も時折URLやサイト名が気に入らずに変えてしまうことがありますが、変えると検索エンジンからの流入が目に見えて減ります。 今まで1日1000PVあった記事が10PVに落ち込んだりすることも珍しくありません。

その対策こそが301リダイレクトです。 301リダイレクトはサイトやページのURLを変更したことを検索エンジンに対して明示的に知らせ、今まで積んできた評価を引き継ぐことができるのです。

Googleウェブマスター向け公式ブログにおいてもURL変更の際は301リダイレクトの設定を推奨しています。 リダイレクト設定は最低でも2か月以上、少なくとも1年以上、できれば永続的に設定すると良いそうです。

ただし完全に評価を引き継げるとは明示されていません。 若干順位が下がったなどの話もよく聞きますし、完全に評価が引き継げる訳ではない可能性はあります。

またリダイレクトには処理時間がかかりますし、リダイレクト設定は不自然なものという見方もあります。 なのでなるべくリダイレクトをしなくて済むように、最初にしっかりとドメインとパーマリンクの設定をしておきたいですね。 このサイトのようにリダイレクト処理を300行以上に渡って記述するハメにならないように気を付けましょう。

しかしサイトを運営していると、URLを変えたいと思う時が必ず来ます。 私もしょっちゅうURLの変更衝動に駆られています。そんな時にはきちんとリダイレクト設定を施しましょう。

WordPressプラグインは色々あるけど、使い始めの頃は何をどう使って良いのか分からないと思います。 一例としてこのサイトで使っているプラグインを紹介してみようと思います。

こうして書いておかないと自分で何をどう使ってるのか忘れるんですよね…

私のサイトで使っているプラグイン

All In One WP Security

WordPressのセキュリティを管理するプラグインです。

サイトのセキュリティの強化や、脆弱性を確認することもできます。 複数サイトを運営しているとセキュリティ対応を忘れることもあるので、プラグインで確認しています。

Category Order and Taxonomy Terms Order

カテゴリを任意に並べた順でサイトに表示できるプラグインです。

カテゴリの表示順に拘りたいサイトもあるので、そのような時に重宝します。

Classic Editor

WordPressエディタをver4.9のまま使えるプラグインです。

WordPress5.0にてエディタの仕様が大きく変わり、使い難かったりプラグイン対応していなかったりする問題が発生しました。 その応急処置としてリリースされたのが本プラグインで、エディタだけ従来のまま使用することができます。

Contact Form 7

メールフォーム生成プラグインです。

元々はメールフォームをPHPで記述していましたが、スパムとのいたちごっこが面倒になってプラグインに任せることにしました。 スパム対策の大定番であるreCAPTCHAを簡単に設定できるのも良い所です。

Delete Custom Fields

カスタムフィールドを削除するプラグインです。

カスタムフィールドが不要になった、誤って追加してしまった時などにこれで消しています。

Google XML Sitemaps

Googleの提供するサイトマップ生成プラグインです。

サイトマップを生成するプラグインは沢山ありますが、サイトマップはGoogleツールと連携させることが多いのでこれを使っています。

Intuitive Custom Post Order

投稿、タグ、カテゴリなどを並び替えることができるようになるプラグインです。

これらは登録順ではない任意の並び順にしたい事も多いので重宝しています。 投稿はこれで並び替えた順に表示できますが、カテゴリを並び順で表示はできないようなので「Category Order and Taxonomy Terms Order」で補完しています。

Search Regex

投稿や固定ページから任意の単語を検索・置換できるプラグインです。

私は投稿内にHTMLタグを直接記述しているので、CSS修正時などにこれで走査して修正記事の検索や変更結果を確認したりします。 他にも誤字脱字の修正、リンクの検索、複数の表現をしている表記を一方に寄せるなどに使うこともありますね。 使い道が色々あって便利です。

TinyMCE テンプレート

記事のテンプレートを記録・呼び出しできるプラグインです。

サイトのひな型やタグの記述・使用方法などをこれに書いて、必要に応じて呼び出しています。 ひな形兼覚え書きとして使っている感じですかね。

WP-DBManager

DBのバックアップ・修復・最適化などをやってくれるプラグインです。

これでDBのバックアップ・最適化・修復をスケジューリングして自動でやってもらっています。

WP Multibyte Patch

マルチバイト文字の取り扱いに関する不具合の累積的修正と強化を行うプラグインです。 日本語版をインストールしたのであれば最初から入っていると思います。

日本語を使用する以上は欠かせないプラグインです。

以上、本サイトで使用しているプラグインでした。 プラグインはサイトや運営者によって何をどう使うか全然変わってくるものですが、何かの参考になれば幸いです。

ライティングとは文字通り文章を書くことであり、「日記」「体験談」「商品紹介」「ニュースの感想や解説」など内容によってその技法も様々です。 しかしどのようなライティングにも基本的で普遍的な技法があります。

簡単に言えば「分かりやすい文章」を「分かりやすい表現」で書くことです。 どのような文章を書く時にも役に立つ、ライティングの基本を抑えておきましょう。

分かりやすい文章を書く

主語を明確にする

主語は文章の中心となる言葉です。後回しにしたり省略したりすると、文章は分かりにくく難解になります。

主語はなるべく文頭に書きましょう。 ただし連続した文章で同じ役割の主語が続く場合は省略しましょう。

主語と述語を対応させる

主語と述語は対応していなければなりません。 短文なら食い違いに気付けますが、長文になるほど非対応を見落とすことが多くなります。

文章の主語と述語を意識して対応させるクセを付けましょう。

先に目的を書いてから指示をする

ページによってはユーザーに指示をする場合があります。 例えば料理の作り方のページでは「タマネギを炒めてください」などの指示をしますね。

しかし指示だけ書かれても、ユーザーはそれが一体何のための指示なのか分かりません。 先に目的を書いてから指示をすることを心がけましょう。

文体を統一する

文体とは文章のスタイルのことです。

敬体は文末が「です・ます」で終わるスタイルで、読み手に丁寧でやわらかい印象を与えます。 一般的な文章は敬体が使われることが多いです。

常態は文末が「だ・である」で終わるスタイルで、読み手に強くしっかりした印象を与えます。 レポートや論文、演説などに使われるスタイルです。

ウェブサイトにおいては敬体を使うのが一般的ですが、常態を使った方が良い性質のサイトもない訳ではありません。 ただどちらを使うにしろ、どちらかにスタイルを統一しましょう。

口語と文語のどちらかに寄せる

日常生活で会話に用いられる言葉遣いを「口語」と言います。 口語はくだけた・親しみやすい印象を与えるため、ブログや対話式の文章に向いています。

文章に用いられる言葉遣いを「文語」と言います。 文語はしっかりした・信頼できる印象を与えるため、サイトやレポートの文章に向いています。

口語と文語の境界線は曖昧で、どちらにも同じ言葉が用いられることもあります。 それ故に意識して使わないと、口語と文語が混じった文章になりがちです。

厳密な運用は難しいですが、どちらのスタイルに寄せるかはあらかじめ決めておきましょう。

体言止めは使わない

名詞で終わる文章技法を「体現止め」と言います。 動詞を省くことで解釈の余地を広げる効果がありますが、逆に言えば文章の意図が伝わりにくくなります。

例えば「外は満点の星空。」という言葉は詩的で美しさを感じますが、綺麗だと言いたいのか、明るいと言いたいのか、星空に思いを馳せているのか分かりません。

あえて体言止めによる効果を演出したい場合を除いては、使わない方が良いでしょう。

誤字脱字や間違いに注意

誤字脱字、言い回しの間違い、漢字の誤変換、二重敬語などは文章の信頼性を一気に下げます。 そこにどれだけ良いことが書いてあったとしても、誤字がひとつあるだけで一気に胡散臭い文章になります。

なるべくエラーを出さないように気を付け、書いた文章は念入りに確認しましょう。 また確認は書いてすぐよりも、一晩寝てからの方が間違いに気づきやすいです。

単語や文章を接続し過ぎない

「会社の経理部の新入社員の性別」のように助詞が多すぎる名詞は、何が重要か分かりにくくなる上に稚拙に見えます。 接続しなくても済む名詞になるよう工夫し、それでも長くなる時は情報の切り捨ても検討しましょう。

「だから」「しかし」などの接続詞を多用し過ぎた文章も同様です。 接続は2～3箇所を目安にして、多くなるようなら一度文章を区切りましょう。

分かりやすい表現で書く

同じ文末を連続して使わない

同じ文末が続くと、なんだか機械的で稚拙な印象になります。 「～です。～です。～です。」のような文章は、読んでいて何だか違和感を感じますよね。

同じ文末が連続して続かないよう、文章の構成や文末を工夫しましょう。

文章を適切な長さで区切る

文章が短すぎるとぶつ切りな印象を与えますが、長い文章は読んでいて疲れます。 文章を適切な長さにしたい時に意識すると良いのが句読点です。

文章を長くしたい場合は読点（、）で接続します。 ただし句点が多すぎる文は読んでいて疲れるので、一文に使うのは三つまでを目安にしましょう。

また読点の前後の文章量がアンバランスだと読みにくく感じます。 特に前側が極端に少ないと文章が頭に入りにくくなるので、バランスを意識して読点を使いましょう。

文章を短くしたい場合は句点（。）で終わらせると良いです。 句点と読点は大体が置き換えできるので、上手く使って文章を適切な長さにしましょう。

箇条書きはリストにする

複数の短い文が連続すると散らかっている印象を受けます。 例えば商品のメリットを並べる場合、そのまま文章で羅列すると目が滑ります。

そんな場合は箇条書きにして一覧表にかき出しましょう。 視覚的にシンプルになって分かりやすくなります。

難しい言葉や専門用語をなるべく使わない

世の中には多くの人が知らない言葉や言い回しがあります。 難解な言葉は知らない読者に負担をかけますし、それが多すぎると途中で読むのを止めてしまうでしょう。

広く読んで欲しい文章は「中学生が分かるように書く」と良いです。 中学生が分からないかもしれない表現は使わないようにしましょう。

数字の表現を統一する

数字には漢数字、全角英数字、半角英数字など色々なスタイルがあります。 同じ表現に違うスタイルを使ってしまわないよう、スタイルを統一しておきましょう。

特にこだわりがなければ「基本的な文章においては漢数字、数字を表現する際にはカンマ区切り半角数字」にしておくと良いです。

前後しなければ確認できない表現を避ける

「前者・後者」「前述・後述」などの表現は、それが何を指しているのか確認するのに文章を前後しなければなりません。

なるべくこのような表現を使わずに済むよう、文章の構成や表現を工夫しましょう。

文章をシンプルにする技法

文章が冗長すぎると分かりにくいし読んでいて疲れます。 特にウェブページにおいては、面倒を感じさせると最後まで読んでもらえない可能性も高いです。

以下の手法を使ってなるべく文章をシンプルにすることを心がけましょう。

省いても意味が変わらない箇所を削る

切り捨てる

「こと」「もの」「という」「ところ」「など」「とか」は、省ける場合があります。 無くても問題ないようなら切り捨てましょう。

ただしやり過ぎると逆に読み難くなるので、あくまで無駄と感じる箇所だけを省きましょう。

言葉を置き換える

同じ役割の言葉や言い回しは、なるべく短いものを使った方がシンプルで分かりやすくなります。

「なのだ→だ」「なのである→である」「そうは言っても→とは言え」など、候補の中から最も短い表現を選びましょう。

二重否定を肯定に変える

二重否定は長い上に分かりにくくなるので、素直に肯定しましょう。

なるべくシンプルに伝える

何でもかんでも全て伝えようとしたところで、読み手に全て伝わることはありません。 本当に伝えたいことは何かを考え、なるべくシンプルに伝えましょう。

文章の長さに無頓着だと一文に詰め込むことが多くなります。 シンプルな文章にするためにも、一文を長くし過ぎないことを意識してください。

文章が冗長になってしまう人は、一文節が100文字を大きく超えないように心がけてみましょう。 そうすれば自ずと文章はシンプルになります。

文章量と重要度のバランスを意識する

話の本筋よりも補足や蛇足の方が文量が多いと、全体がぼやけて要点が分かりにくくなります。 文章は一番伝えたいことを中心に展開すべきです。

伝えたいことに重要度を付け、文量もその比重に寄せる意識をしましょう。 重要な部分は詳細まできっちり書き、補足や蛇足は要点だけ書いて流すと良いです。

それほど重要でないのに文量が多くなる場合は切り捨ても検討しましょう。

まとめ

以上、ライティング入門でした。

この「分かりやすい文章」を「分かりやすい表現」で書く手法は、ウェブサイト以外にも使える普遍的なものです。 レポート、論文、ビジネス文章など、色々な用途があります。

ライティング技法を習得すれば、誰にでも分かりやすい文章を書けるようになります。 まずは上記の内容をよく意識しながらライティングの練習をしてみましょう。

紙媒体でのライティング能力があっても、ウェブサイトでそのまま通用する訳ではありません。 ウェブサイト特有の事情があり、それを汲んだウェブライティング能力が求められるからです。

そんなウェブライティングの基本を抑えておきましょう。

ウェブライティングの作法

ターゲッティングを意識する

テレビや雑誌と比べると、ウェブサイトが情報を発信する対象は限定的です。 万人に訴えるようなポータルサイトやメディアもありますが、基本的には特定の年齢、性別、属性、趣味などの限られた対象をターゲットとしています。

ターゲットが設定されているサイトの文章は当然そのターゲットに向けた書き方になります。 ターゲットが理解できる・伝わる・共感できるなど、ターゲットに合わせたライティングが必要になる訳です。

まずは文章を書く前に、そのサイトやページが誰に向けて何を伝えるものかを考えてみてください。 そうすれば自ずとどのような文章を書くべきかが見えて来るはずです。

結論を先に言う

ウェブページは最初から最後まで全部読まれるとは限りません。 長々と前フリする余裕はないので、先に結論を言いましょう。

ウェブページを読むユーザーの動機の多くは暇つぶしで、読むのに飽きればすぐにでもページを離脱してしまいます。 紙媒体のように全て読んでもらう前提で起承転結を書いても通用しないことが多いです。

ただこの辺の機微はサイトの性質やターゲットによって変わるので、方針は統計を見ながら調整していくことになります。 あまり固定観念にとらわれず柔軟にやりましょう。

ページ単位である程度完結される

本を読む時は最初のページから順に読みますが、ウェブページはそうとは限りません。 ユーザーは検索エンジンやリンクから飛んでくることが多く、前後にページがあっても１ページしか読まれないことも多いです。

コンテンツはページ単位で完結させ、そのページしか読まれなくてもユーザを満足させられる構成にしましょう。

見出しはとても大事

見出しとは<hx>タグで囲う範囲のことです。

見出しで区切ることで文章にメリハリが付いて読みやすくなります。 またあらかじめ見出しに内容を端的に示しておくことで、読み手の理解を深める効果もあります。

また見出しは書き手にとっても重要です。 内容を体系的に整理して文章の流れを確認する指標となるでしょう。

ページの要点や流れは見出しによって作られています。 あらかじめ見出しをしっかり引き、それから文章を肉付けしていきましょう。

視覚的に訴える

文章だけが淡々と書かれているウェブページは読むのが大変です。 アイキャッチ、補足画像、リスト要素、CSS効果など、ユーザの視覚に訴えて情報を補完しましょう。

文章よりも画像や表の方が分かりやすく伝えられるケースは多いです。 文書が淡々と続きすぎている場合、これらに置き換えられる箇所がないか探すと良いでしょう。

ただしウェブページの主体はあくまでテキストなので、バランス感覚が大切です。

一文をコンパクトに

ユーザの半数以上はスマホでネットを閲覧していると言われています。 大画面では数行の文章であっても、スマホで閲覧すると行数は倍になりボリュームを感じます。

一文節をなるべくコンパクトにしましょう。 一文節100文字以内を目安にして、それを大きく超えるようなら分けて書きましょう。

文章を装飾する

淡々と書かれている文章はメリハリがなく、何が要点でどこが重要なのか分かりにくいです。

キーワードは括弧で括る、要点や重要な箇所を太字にするなどして、読み手の意識をガイドしましょう。 あらかじめ文章の装飾ルールを作っておくと良いです。

ただし過剰装飾は逆に何が言いたいのか分かりにくくなります。 2～3種程度に留めておくのが無難です。

改行しない

文章を改行する際に<br>タグがよく用いられますが、これはあまりお勧めできません。 閲覧サイズが変わると文章の折り返し地点も変わり、意図しない位置で改行されてしまうためです。

<br>タグによる改行ではなく、<p>タグによって文節を区切りましょう。

ウェブ文章特有の構成

ウェブ文章は本文以外にも設定されていることが多いです。 それぞれの役割を知っておきましょう。

リード文

リード文とは記事冒頭に書く、記事の要約や紹介です。 記事の内容をあらかじめ提示することにより、以下の効果が見込めます。

• ミスマッチを防ぐ
• 記事への理解を深める
• ユーザーとの距離を縮める・共感を呼ぶ
• せっかちなユーザーに答えを提示する

ここの掴みが良いほどにユーザーは興味を持って読み進めてくれますし、ミスマッチだった場合は時間を無駄にする前に離脱できます。

よほどの特殊な記事でもない限りは、リード文を書くメリットは大きいです。 記事を書き上げたら、記事の内容を端的に説明した魅力あるリード文を200文字程度で書きましょう。

目次

目次はリード文下に書く記事の見出し一覧です。 記事の概要や流れを確認できる、読みたい位置にジャンプできるなどのメリットがあります。

しかしユーザーには邪魔に見られる場合もあり、目次を設置すべきかは意見の分かれるところです。

またページの性質によっても必要性は変わってきます。 論文のようなページではほぼ必須ですが、日記には必要ありません。

記事の性質を見て目次が必要かを判断しましょう。 ただ目次が長すぎると邪魔に感じるので、その場合は見出しレベルを絞った方が良いです。

まとめ

まとめは記事の最後に書く、記事の要点やポイントの切り抜きや総括です。

内容のおさらいを短時間でできるため、特に解説や指南のページに有用です。 ただ特にまとめることもないのに「いかがだったでしょうか」とまとめる必要はありません。

記事をまとめる必要があると感じた時にだけまとめを作成しましょう。 その際にはリスト要素使って要点を箇条書きにするとスマートにまとめられるでしょう。

SEOを意識する

ウェブページがどれだけ読んで貰えるかはSEOに大きく依存でします。 どれだけ良い文章を書いても検索エンジンに拾って貰えなければ誰にも見て貰ないので、ウェブライティグをする上でSEOは避けて通れません。

SEOを第一に考えるのは問題ですが、全く意識しないのも難しいです。 SEOと上手く付き合うためのウェブライティング手法を知っておきましょう。

キーワードを意識した記事を書く

ユーザーは目的や欲求を達成するために検索エンジンでキーワードを入力します。 主な目的は「したい」か「知りたい」のいずれかなので、それに対するキーワードと関連ワードが記事に盛り込むべきキーワードになります。

例えば福岡で美味しいラーメンを食べたいと考えている人は「福岡」「ラーメン」「美味しい」などのキーワードを使って検索すると思われます。 ページにこれらのキーワードを盛り込めば、検索エンジンに関連ページと見なされ、上位表示される可能性が高くなる訳です。

ただしキーワードは多くなるほど記事の要点がぼやけるので多用は禁物です。 記事の中心に据えるキーワードを2～3語設定し、それを中心に記事を書きましょう。

見出しはとても重要

SEOにおいても見出しはとても重要です。

検索エンジンの検索結果にはウェブページの<h1>見出しが表示されます。 検索結果からあなたの書いた記事を読んで貰うには、ユーザーが読みたいと感じてクリックするような魅力的な見出しを設定する必要があります。

また見出しはキーワードの価値が高く、特にタイトルである<h1>タグは検索エンジンから重要視されています。 ユーザーにクリックしてもらえるような魅力的な見出しを32文字内でまとめましょう。

見出しキーワードの選定はGoogle社の提供する「Google AdWords」の「キーワード プランナー」を使うとよりSEOに強いものを作ることができます。 キーワードの検索ボリューム・関連性・競合性を教えてくれるので、見出し選定に大いに役立ちます。

余裕があればディスクリプションを設定する

ディスクリプションとは各ページの要約のことで、全角120文字以内で記述できます。 これは検索結果のタイトル下に表示される内容となります。

ディスクリプションを確認してからクリックするユーザーもいるので、的確なディスクリプションの設定はSEOの向上が期待できます。 なお設定しない場合は検索エンジンが表示する内容を勝手に決めます。

理想を言えば全ての記事にディスクリプションを設定すべきですが、いちいち見ないユーザーが多い割に手間のかかる作業となります。 余裕があれば設定しておきましょう。

ウェブ文章の確認

一晩寝て確認する

記事を書いてからすぐに確認しても間違いや違和感を見落としやすいです。 夜中に素晴らしい記事が書き上がったと思っても、朝に確認したらおかしい事だらけだったりします。

記事を書き上げたら時間を置いてから確認しましょう。 出来れば一晩寝てからの方が良いです。

PCとスマホで確認する

閲覧デバイスが変われば記事の見え方や読み具合も変わってきます。 PCで問題ないように見えてもスマホではボリュームが大きすぎると感じたり、スマホでは普通に読めてもPCでは無茶苦茶な流れに感じたりします。

記事の確認はPCとスマホの両方で行いましょう。

まとめ

以上、ウェブライティング入門でした。

紙媒体でのライティング能力があっても、ウェブライティグが出来る訳ではありません。 ウェブにはウェブの作法があることを覚えておきましょう。

実際に記事を書く時にここまで意識していませんが、大よその方針として何となく覚えておいて損はありません。 役に立ちそうなものだけを抽出して、サイトのライティングルールを作るのも良いでしょう。

小手先のテクニックに頼ってSEOに振り回されるのは碌な結果になりません。 その時間をコンテンツの充実に使った方が余程効果的です。

しかしその一方でSEO的にNGな行為を繰り返すと検索エンジンに中々拾って貰えません。 折角良いサイトを作っても誰にも気付かれないまま電子の藻屑となる可能性すらあります。

過度にSEOに振り回されるのは良い事ではありませんが、全く知らないのもそれはそれで茨の道です。 ここでは最低限抑えておくべきSEO知識についてお話ししておきます。

最低限抑えておくべきSEO

正しくコーディングする

HTML、CSS、その他ウェブサイトを記述する言語は正しくコーディングしましょう。

ウェブ言語は記述に誤りがあっても正常に描写されることも多いので、ぱっと見は問題なくても実はエラーになっている事も多いです。 ブラウザの検証機能や検証サイトを使ってエラーがないか確認した方が良いでしょう。

記事やサイトのURLは変えない

サイトや記事の評価はURLに貯まっていきます。 なのでURLを変えると今まで貯めた評価がどこかに行ってしまいます。

変更する時はURLリダイレクトによって評価を引き継げますが、手間がかかるし完全に引き継げる訳ではありません。 最初にしっかりとサイトURLとパーマリンク設定を行い、URLの変更が起きないようにしておきたいですね。

そんな事情でパーマリンクにカテゴリ名を含めるのは止めておいた方が良いです。 カテゴリ名や記事の所属カテゴリを変えると記事のURLまで変わってしまうので、動的に動かしにくくなります。

記事URLは記事を端的に表す英文字にすると良いです。 区切り記号として-（ハイフン）を使い、1～3語で記事を簡潔に説明するものを設定しましょう。

最低でも1記事1000文字以上を目安に

検索エンジンに評価されるページはそれなりに文字数が多い場合が多いです。 もちろん検索ワードやコンテンツの内容にもよりますが、100文字程度の短文が検索上位に来ることは中々ありません。

最低でも1記事1000文字以上を目安に書きましょう。 過不足なく伝えたいことを書くのが基本ですが、それでもこれぐらいの文字数は検索エンジンに載るために必要です。

検索結果の傾向を見るに、現状は文字数が多い記事ほど上位表示される傾向があると言わざるを得ない状況です。 欲を言えば2000～3000文字ぐらいは欲しい所です。

ただし文字数があれば良いという訳ではないので、無意味な文字数稼ぎは厳禁です。 また5000文字を超えると流石に読むのが大変なので、記事の分割を考えた方が良い場合が多いです。

記事タイトルにキーワードを含める

記事の大見出し（h1タグ）は検索キーワードとなる単語を含め、記事の内容を簡潔に32文字以内で表しましょう。 なお32文字というのはGoogle検索結果で省略されずに表示される文字数です。

関連して小見出し（h2タグ以下）も適切に使いましょう。 見出しを適切に整理することで検索エンジンに対してどのようなページかを端的に伝えることができます。 小見出しは目次として使うイメージで良いでしょう。

Googleが推奨することはやっておく

Googleが提供しているサイトマスター向けブログ、Search Console、Google Analiticsを始めとしたの一連のツールには、より良いサイトを作るためのヒントが多く書かれています。 またツールを通して最適化案や推奨などの連絡が来ることもあります。

Googleの目指すところとサイトの制作・運営方針のすり合わせをしておきましょう。 サイトを作る前に一度は目を通しておいた方が良いと思います。

以上、最低限知っておいた方が良いSEOでした。

知っておいた方が良いSEO

以降は必須ではないけど知っておいた方が良いSEOです。 純粋に良いサイトを作りたいだけなら気にする必要はありませんが、沢山の人に見てもらいたい場合は知っておいた方が良いでしょう。

コンテンツに合ったサービスの選定

既存のブログサービスには横の繋がりがあり、メディアに記事を取り上げられる可能性も見込めます。 ブログサービス毎に特色や強い分野も違うので、自分が作ろうとしているサイトに合ったサービスを選びましょう。

しっかりしたサイトを作る気ならレンタルサーバを借りて独自サイトを作るのも良いでしょう。 WordPressなどの優秀なツールを利用できる利点がありカスタマイズ性も高いです。 しかしその反面「陸の孤島」と言われるほどスタートアップに弱いのは覚悟しておきましょう。

最初はブログサービスから初めて、軌道に乗ったら専用サイトに引っ越しするなんて手もよく見られます。 作ろうとしているコンテンツに合ったサービスを選定しましょう。

ビッグキーワードを狙う

マニアックなキーワードは検索されることが少ないです。 ニッチなキーワードで上位表示される良いサイトを作った場合、ライバルは少なくても需要も少ないため、検索流入はそれほど見込めません。

Googleキーワードプランナーを使って、どのようなキーワードにどれぐらい検索ボリュームがあるのか確認してみると良いでしょう。 それを基にサイトや記事を作る方針を立てれば、効果的なアクセスアップが見込めます。

被リンク数を増やす

被リンク数もサイトや記事の評価に影響します。 なるべく多くのリンクやシェアが貰えるよう、良質で面白い記事を作りましょう。

またSNSのシェアボタンを記事下に置いておくと、読了後にシェアされることが多くなります。 記事下にシェアボタンを固定で設置しておくと良いでしょう。

ブラックSEOは止めておく

自作自演や業者を使ってのブラックSEOは、検索エンジンに見破られて逆効果になる場合があります。 こんなことに時間やお金をかける暇があったら、記事の一つでも書いた方が良い結果になるでしょう。

専門家が施策を行ってなお失敗することも多いのがブラックSEOです。 素人の拙い考えが検索エンジンに通じるとは思わない方が良いでしょう。

以上、知っておいた方が良いかもしれないSEOでした。 どこまでやるかはともかく、これだけ知っていれば十分ではないでしょうか。

SEOとは「Search Engine Optimization」の頭文字を取った略称で、直訳すると検索エンジン最適化という意味になります。 概念的なところもありますが、要は「検索エンジンに上位表示されるためのノウハウ」のことです。

一口にSEOと言っても色々あり、記事を書くことだってSEOの一環です。 SEOとは何なのか、サイト運営に際してどうすれば良いのか、SEOの基本を抑えておきましょう。

SEOとは

SEOとは「サーチエンジンに対してサイトを最適化させる」ことを言います。 具体的な手法をいくつか挙げると「優れたコンテンツを作る」「被リンクを増やす」「サイトの権威や信頼性を付ける」「ユーザービリティを高める」などが挙げられます。

検索エンジンはユーザーが入力したキーワードに対して、無数のサイト群から最適なページを探し出してユーザーに提示しています。 このロジックは検索エンジンごとに異なり、例えばGoogleとBingでは同じキーワードでも違ったページや並び順が提示されます。

検索エンジンがどのようにページを評価しているか明確にはされていませんが、大雑把な方針は公開されており、また上位表示されるページからある程度は推測できます。 それらを集約した検索エンジンに上位表示させるためのノウハウが「SEO」と呼ばれている訳です。

ウェブサイトへのアクセスは検索エンジン経由が少なくない割合を占めており、上位表示されればそれだけサイトのアクセスが増えます。 アクセスアップのためにはSEOは避けては通れません。

SEOはおおよそGoogleの話

広義のSEOは検索エンジン全般に対しての話になりますが、実態はほとんどがGoogle検索に対しての話になります。 これは検索エンジンにGoogleを使うユーザーが圧倒的に多いからです。

世の中に検索エンジンは数多くありますが、一般的なユーザーが知っているのはせいぜいGoogle、Yahoo、Bingぐらいなものだと思います。 そしてYahoo検索にはGoogleのロジックがそのまま使われているので実質Googleです。

日本においての検索エンジンシェアはGoogle（+Yahoo）が9割前後と言われ、諸外国においても多少の差はあれどGoogleの覇権は変わりません。 そんな事情でSEOと言えばGoogleなのです。

なおBingもそれなりに有力な検索エンジンなので、ウェブマスター登録など最低限のことはやっておいた方が良いです。 今後の動向次第でシェアを伸ばしてくることも十分に考えられます。

SEOは更新される

検索エンジンがどのようなページを上位表示するかのロジックは定期的に変更されます。 これはよりユーザーの要求にマッチングした質の高いページを上位表示するためです。

更新タイミングは特に決まっていませんが、日常的に順位は変動しています。 またGoogleは数か月～数年のタイミングで、大規模アップデートが実施されています。

大規模アップデートが起きると、検索順位が大変動する可能性があります。 それによってサイトのアクセス数が3倍になったとか、9割減になったとかいう話も珍しくありません。 本サイトも±50%程度の変動に何度も見舞われています。

つまりSEOは常に更新され続けています。 アップデート前までは効果的だったけど、今からは逆効果になるからむしろ止めた方が良いなんてSEO施策も珍しくありません。

そのため小手先のSEOテクニックに囚われるのはあまり得策ではありません。 検索エンジンが真っ先に振り落とそうとしているのがその類のサイトなのですからね。

だからSEOは小手先のテクニックではなく大枠で捉えた方が効果的です。 SEOと上手く付き合うことを心がけましょう。

ホワイトSEOとブラックSEO

SEOにはホワイトSEO／ブラックSEOと呼ばれる区分があります。 これは自然に任せるか、自作自演をするかの違いです。

ホワイトSEOはサイトの拡充や記事の質の向上によってサイトの評価を上げることを目指します。 優れたコンテンツは多くの人に読まれ、多くのリンクが張られ、それがSEOに繋がります。

対してブラックSEOは自作自演によってサイトの評価を上げることを目指します。 例えば被リンク数がSEOに繋がるのであれば、自分でサイトを作ってリンクを張れば、それがSEOに繋がります。

一般的におすすめされるのはホワイトSEOですが、綺麗ごとだけでは世の中を渡っていけない側面もあります。 現在大きく成長したサイトの中にもブラックSEOによって成り上がったサイトは沢山あります。

ブラックSEOが選択肢の一つとして存在していることは確かです。 ただあまりに露骨だと検索エンジンに対策され、逆効果となることもあるので気を付けましょう。

SEOの例

よく言われるSEOをいくつか紹介します。

優れたコンテンツ

独自性がある、内容が専門的、興味深いことが書かれている、読んでいて面白いなど、とにかくコンテンツが優れていることがSEOに繋がります。

検索エンジンが良いページを上位表示したいのは考えるまでもなく当たり前のことです。 しかし意外に盲点になっていることです。

正しい文法

HTML、CSS、JavaScriptなど、コードが正しく記述されていることがSEOに繋がります。 当たり前と言えば当たり前ですが、文法が守られていないサイトは意外に多いです。

ウェブ言語は多少間違っていてもほぼ問題なく動作することもあるので、ちゃんとチェックしないとなかなか気づきません。 正確に記述されているかはツールでチェックする必要があるでしょう。

被リンク数が多い

様々なサイトからリンクされているページはそれだけ支持されているページと言えます。 そのため被リンクが多いことも評価に繋がります。

ただし単純に数が多ければ良いというものではなく、権威のあるサイトから真っ当に張られたリンクほど高い評価になります。 被リンクを増やすための相互リンクやペラサイトなどは逆効果になる場合もあるので注意しましょう。

SXOを意識する

SXOは「Search Experience Optimization（検索体験最適化）」の略で、ユーザーの検索ワードに対して適正なサイトやページを用意しているかどうかを問うものです。

「ラーメン　美味しい店」で検索したユーザーは美味しいラーメンが食べたいと考えています。 これでラーメンの歴史やうんちくを語るページが出てきたら、検索エンジンやページに悪印象を持つことになります。

アクセスアップを狙って関連性の低いビッグキーワードが設定されることがありますが、このように逆効果になりかねません。 ページの内容や趣旨と合ったキーワードを設定することが重要なのです。