「構造化データ」がよく分かる!初心者向け徹底解説

SEOの文脈においても頻繁に話題になる「構造化データ」。意外にそこまで詳細に理解されている方は多くないのでは?と思います。ここでは構造化データやリッチスニペットの概要から、HTMLでの記述方法、テストツールなど、全体像を掴んで頂ければと思います。今回はコンサル部門サブマネージャーの巣鷹による執筆。

目次

セマンティックWebについて
構造化データとは
構造化データを使用するメリット
ボキャブラリーとシンタックス
構造化データをマークアップする方法
HTML上で直接マークアップする方法
データ ハイライターを用いる方法
テストツールのご紹介
まとめ

セマンティックWebについて

構造化データとセマンティックWebという考え方は切っても切り離せないものです。今回は構造化データを説明する前にセマンティックWebというものに簡単に触れておきたいと思います。

「セマンティックWeb」は、例えば以下のように説明されています。

Webページおよびその中に記述された内容について、それが何を意味するかを表す情報(メタデータ)を一定の規則に従って付加することで、コンピュータが効率よく情報を収集・解釈できるようにする構想。インターネットを単なるデータの集合から知識のデータベースに進化させようという試みがセマンティックWebである。
引用元:http://e-words.jp/w/E382BBE3839EE383B3E38386E382A3E38383E382AFWeb.html

コンピュータ(検索エンジン)は従来、テキストを単なる”文字”として認識し情報として蓄積していました。しかし、それでは検索エンジンは文字を記号としてしか認識することができず、その意味を推し量ることはできません。

そこで、文字を”意味”としてその背景や文脈まで解釈し、それを蓄積していこうというのがセマンティックWebの考え方です。

構造化データとは

セマンティックWebを実現するための手段として、構造化データがあります。構造化データは、言葉に対して意味をメタデータとして持たせることで、ロボットがそのもつ内容の解釈を容易にし、検索エンジンはより有用な検索結果をユーザーに提供できるようになります。

わかりづらいので例を。例えば、以下のような例を考えます。

--</pre>
<div>私は土居 健太郎 (天照SEO)です。</div>
<pre>
--

私達がこれを見た時に、この人は土居健太郎という”名前”の人物で、天照SEOという”ニックネーム”を持っているのだとある程度推測することができます。

検索エンジンもその推測ができないわけではありませんが、これを明確にニックネームだと定義することは難しいのです。そこで、そうした情報の「意味」を検索エンジン等に明確に伝えてあげましょうというのが構造化データの考え方です。

構造化データはHTMLに直接マークアップする、もしくはウェブマスターツール上で設定しますが(設定方法は後述します。)、上述した土居健太郎の例でいうと以下のような記述となります。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> (<span itemprop="nickname">天照SEO<span itemprop="nickname">)です。</span></span></div>
<pre>
--

nameやnicknameという値が含まれているのが御覧頂けるかと思いますが、特定の情報に対してHTMLマークアップを行う(メタデータを付与する)ことでその情報の説明が付与することができるようになります。

構造化データを使用するメリット

検索エンジンがサイトコンテンツの把握を容易に行えます

上述した通り、特定のテキストあるいは画像がどういう情報なのかを指し示すことで、検索エンジンはコンテンツの内容がどういう意味を持つものか、容易に把握できるようになります。

構造化データを用いることで、前述した文章は、「私の名前は土居健太郎で、ニックネームは天照SEOです」のように、情報の持つ意味がより明確に検索エンジンに伝わり、適切に認識されるようになります。

リッチスニペットが表示されます

通常の検索結果においてサイトが表示される際には青色のリンク、その下meta descriptionやサイト内テキストから引用したスニペットが表示されますが、構造化データを用いることで、リンクの下に通常とは異なる情報が表示されることがあります。これを「リッチスニペット」と言います。

リッチスニペットの画像

こういった検索結果を見たことがある方は多いのではないかと思います。

これにより検索結果で目につきやすくなり、クリックされやすくなるなどのメリットがあります。リッチスニペットに対応されているコンテンツは、上の画像のレビュー情報やレシピ、筆者情報以外にも音楽や映画、イベント、パンくずなどがあります。

ボキャブラリーとシンタックス

構造化データを理解する上で、この2つの言葉についてきちんと理解しておく必要があります。

ボキャブラリー

冒頭の例では文章全体に”http://schema.org/Person”という値を、土居健太郎に”name”、天照SEOに”nickname”という値を付けました。その指定する値を定義している規格のようなものがボキャブラリーです。

ボキャブラリーの代表的なものにschema.orgがあります。schema.orgはGoogle、yahoo!、Microsoftの大手検索エンジン企業が共同で取り組んでおり、値の数は日々拡張されています。

先ほどの例では人物の説明でしたが、人物の説明には名前やニックネームはもちろんのこと、所属する団体や誕生日なども情報として持つことがあるかと思います。そういった部分もある程度網羅されており、こちらのページ(※リンク先は英語です)にてまとめられています。propertyという欄で人物の説明に対してマークアップ可能な値が表示されています。

なお、schema.orgで構造化データマークアップに対応している情報のタイプはこちらでまとめられています。実際にHTMLをマークアップする際にはこれらの中からコンテンツに合致するタイプを選択し、実装します。
※マークアップしたい項目について、リンク先に利用可能な値が記載されています。

また、見て頂くとわかるかと思いますが、プロパティは階層構造となっています。

例えば「Thing(もの)」という大項目の子として「Book(本)」や「Event(イベント)」という項目、「Event(イベント)」の子として「BusinessEvent(企業向けイベント)」といった階層を形成しています。

シンタックス

ボキャブラリーは値を定義しているだけのものですので、HTMLにマークアップする際にはどうマークアップするかの仕様が必要ですが、その仕様がシンタックスです。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> (<span itemprop="nickname">天照SEO<span itemprop="nickname">)です。</span></span></div>
<pre>
--

ちなみにこの文章でいうとitemscopeやitemtypeの部分がシンタックスで決められている仕様です。

シンタックスには代表的なもので以下の4つがあります。

  • Microdata
  • RDFa
  • Microformats
  • JSON-LD

Googleが推奨しているのはMicrodataです。

また、JSON-LDはHTML上で各情報に直接マークアップするその他のシンタックスとは異なり、スクリプトを用いて記述するため、各データに直接マークアップする必要がなく、一箇所で構造化データを記述できるとぃう利点があります。

先ほどの例

再度、土居健太郎の例を用いて詳しく見てみましょう。
※以下の例はボキャブラリーにschema.orgとシンタックスにMicrodataを用いています。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> <span itemprop="nickname"> (天照SEO) <span itemprop="nickname">です。</span></span></div>
<pre>
--

1. itemscope
itemscopeという属性がdivに付与されています。これはこのdivに構造化データが付与されているということを意味します。

2. itemtype
itemtypeはitemscopeで示された構造化データが何に関するものなのかを示すために用います。上述したデータでいうとhttp://schema.org/Person という人物を表す値が用いられているためdiv内の情報が人物を表す情報であると確認できます。

人物以外にも組織や会社を表すhttp://schema.org/Organization や、商品であればhttp://schema.org/Product などが定義されています。

3. itemprop
itempropはitemtypeで示された人物や組織・会社などの詳細な情報を示すために用いられます。

上の例ではdivに対してitemtypeで人物の情報であると提示されているので、itempropがnameと指定されているspan内の情報は、人物の名前であることが読み取れます。また、その次のnicknameが記載されているspanはニックネームを表しています。

構造化データをマークアップする方法

構造化データを検索エンジン(Google)に伝える際には大きくわけて2つの方法があります。

  • HTML上で直接マークアップする方法
  • データ ハイライターを用いる方法

前者のHTMLに直接マークアップする方法は文字通り上述した土居の例のようにHTMLタグに構造化データの要素を追加します。

一方でデータ ハイライターを用いる場合、ウェブマスターツールのページ上でクリックすることによりページの構造化データを(HTMLをいじることなく)Googleに伝えることが可能です。

Googleヘルプには以下のように書かれています。

■HTML の使用が適しているケース:
・サイト上のイベント、レシピ、その他の各種データの Google による認識方法を明確にコントロールしたい場合。
・HTML マークアップを一貫してすべてのデータ項目に追加できる場合。
・サイトの構造が頻繁に変わる場合。
・Google 以外の検索エンジンでもウェブサイトのコンテンツが認識されるようにしたい場合(データ ハイライターで抽出されたデータを利用できるのは Google のみです)。

■データ ハイライターの使用が適しているケース:
・サイトで表示するデータが、イベントに関するものである場合。
・サイトで構造化データやリッチ スニペットを使用することを検討しているが、HTML マークアップを更新するためのリソースの準備がまだできていない場合。
・HTML マークアップを記述するよりも、ウェブページをポイントしてクリックするほうがよい場合。
・サイトで HTML マークアップを変更できない、またはデータ項目を一貫してマークアップできない場合。
引用元:https://support.google.com/webmasters/answer/99170?hl=ja

どちらの方法もメリット・デメリットがありますので、運営されている体制やサイトの状況などにより、どちらを使うか検討することが望まれます。

ではそれぞれ実際に説明していきましょう。

HTML上で直接マークアップする方法

この方法には大きく分けて二つあります。それぞれ説明します。

ボキャブラリーとシンタックスを参考にHTMLにマークアップしていく方法

今回はボキャブラリーにschema.orgとシンタックスにMicrodataを用いてマークアップする方法を紹介します。

一般的に構造化データがマークアップされている情報は人物や商品、パンくずが多いですが、こちらにまとめられている通り、マークアップできる情報は他にも沢山あります。

今回は以下の文章について考えてみましょう。

--</pre>
<div>ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

①まずはitemscopeを入れましょう。

上述した通り、構造化データであることを示すはじめの一歩はitemscopeを該当するタグに入れることです。

--</pre>
<div itemscope="">ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

②itempropで何を示している情報なのかを指定しましょう。

今回はヴォラーレ株式会社の情報ですので、itemtypeで企業情報であることを示すhttp://schema.org/Corporationを用います。

--</pre>
<div itemscope="" itemtype="http://schema.org/Corporation">ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

これでこのテキストは企業に関する情報であることをマークアップできました。

③itempropを使って各情報についてそれぞれマークアップしていきます。
企業に関する情報の際に使えるitempropはこちらのページで挙げられています。マークアップしてみると以下のようになります。

--</pre>
<div itemscope="" itemtype="http://schema.org/Corporation"><span itemprop="”name”">ヴォラーレ株式会社</span>は<span itemprop="”lacation”">五反田</span>に位置する企業です。<span itemprop="”foundingDate”">2007年1月15日</span>に<span itemprop="”founder”">高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a itemprop="”URL”" href="”">http://www.volare.jp/</a></span></div>
<pre>
--

「ヴォラーレ株式会社」は企業名なので「name」を、「五反田」は住所にあたるので「lacation」を、その他創業日や創業者、コーポレートサイトへのURLもマークアップしています。

構造化データマークアップ支援ツールを用いた方法

ウェブマスターツールには、構造化データマークアップを支援する機能があります。

先に説明した方法だとschema.orgなどを理解した上でマークアップする必要がありましたが、こちらの方法はそれよりも容易に構造化データを用いることが可能になります。

ここでは弊社の開発室が運用しているブログを用いて説明します。

①構造化データマークアップ支援ツールに該当するページのURLを入力し、今回マークアップするデータを選択した上でタグ付け開始をクリックします。

構造化データマークアップ支援ツールの画面「

今回はブログ記事のマークアップですので、記事を選択しました。

②実際にマークアップしてみましょう。

ブログ記事ページイメージ

タグ付けはツール内でページが読み込まれた画面で行います。右にタグ付けできるデータが並びます。この例で言うと、前の画面で記事を選んだため、著者や公開日など、記事に関連するデータが並んでいます。

ではまず一番上にある「名前」(今回の場合は記事タイトルです)をマークアップしてみましょう。

タイトルがハイライト

タイトルに当たるところをドラッグすると、選択肢が出てきますのでそこから「名前」を選択しますと右側にマークアップしたいテキストもしくは画像が追加されます。著者情報や公開日なども 同様の要領で指定していきます。

データの指定が終わったら右上にある「HTMLを作成」をクリックするとそのページのHTMLが出力されます。

イメージ

③出力されたHTMLをサイトに反映させます。
どういったサイト運用をされているかにもよりますが、出力されたHTMLでマークアップされた部分(黄色くハイライトされています)、もしくはソース全てをコピーしてHTMLを実装しましょう。これでマークアップは完了です。

データ ハイライターを用いる方法

データハイライターを用いた場合には 直接HTMLをいじる必要がなく、構造化データマークアップ支援ツールのようにブラウザ上でクリックすることで構造化データをGoogleに伝えることが可能です。

①ウェブマスターツールでデータハイライターを開きます。

データハイライター画面

ハイライト表示を開始しましょう。

ハイライト表示

先ほどと同様に構造化データを設定したいURLを入力し、タイプを選択します。今回は天照SEOブログを用いますので、タイプに「記事」を選択しました。

また「このページをタグ付けし、他のページも同様にタグ付けする」の場合は(幾つかのサンプルページにてタグ付けを行うことで)同様のページ群もGoogleが学習して構造化データを認識してくれるようになります。一方で「このページだけをタグ付けする」場合はGoogleに学習させず選択したページのみをタグ付けしたい場合に用います。

ブログ記事のように同じようなページ群がある場合には前者、そうでない場合には後者が望まれると思います。
今回はブログ記事ですので前者を選択しました。

②タグ付けを行います。

アイテムを選ぶ

上述した構造化データマークアップ支援ツールと同様に、タグ付けしたいところをクリックもしくはドラッグし、タグ付けするデータを選択します。タグ付けが終了したら右上の「完了」を選択しましょう。

③Googleに自動でタグ付けして欲しいページを選択します。
※この選択肢は「このページをタグ付けし、他のページも同様にタグ付けする」を選択した場合にのみ表示されます。

ページセットの作成画面

左の項目ではGoogleが同様だと判断したページ群が選択肢として表示されます。それでは問題がある場合は「カスタム」で設定しましょう。※ページ群の設定は正規表現で行います。

これらを選択したら「ページセットを作成」に進みましょう。

④サンプルページで上手く設定できているか確認します。

確認画面

Googleは最初にタグ付けした設定から他のページでも同様の構造化データをタグ付けします。このページでは③で選択した構造化データを設定したいページ群の中から、構造化データ部分をハイライトした状態でサンプルページが表示されます。自分の意図通りに設定されている場合には、右上の「次へ」をクリックしましょう。

次々にサンプルが表示されますので、問題がある場合には手動で設定を修正しましょう。5ページ分のサンプルを確認すると、「完了」という項目が右上に表示されるので次に進みましょう。

⑤最終確認画面

採取確認画面

最後に確認したサンプルページを再度見直して、問題が無い場合は右上の「公開」ボタンを押しましょう。これでデータハイライターによる構造化データの設定は完了です。

テストツールのご紹介

構造化データ テスト ツール

構造化データ テスト ツールで正しく構造化データが記述できているかを確認できます。URLもしくはHTMLを入力することでそのページに設定した構造化データが正しく設定されているか、どの項目が設定されているかに加えて、検索結果上でどういう表示がなされるページなのかを確認できます。

テストツール

構造化データのマークアップを行った後には出来る限りこのツールを用いて、正しく設定されたかを確認するようにしましょう。

※なお、このツールで表示される検索結果プレビューが必ずしも本物の検索結果で表示されるとは限らないようです。

ウェブマスターツールの「構造化データ」項目

ウェブマスターツールの構造化データでは、構造化データの設定にエラーが無いか一覧で確認することができます。検索結果のプレビュー機能は無いですが、構造化データにエラーがあるデータタイプやページが一覧で確認できますので、URLを何度も入力する必要のある構造化データテストツールよりもその点は便利です。

まとめ

ここ最近の検索エンジンまわりの動きを見ても、構造化データを利用する重要性は高まるはずなので、サイトによっては是非チャレンジされると良いかと思います。しかし、サイトの全体的なマークアップに構造化データを適用するというのはコスト的に現実的でない場合が多く、そのあたりのバランスは今はまだなかなか難しいのかなと思います。

最後に、こちらも参考にどうぞ。

皆様のお役に立ちましたら幸いです。

ヴォラーレ株式会社 巣鷹

元雑誌編集者が語る、あなたの”コンテンツマーケティング”が上手くいかないワケ

コンテンツが重要、という考え方が徐々に浸透しつつありますが、ここでは元雑誌編集者、という視点から、Web媒体のコンテンツ制作の現場についての「それってどうなの?」な色々について取り上げて解説します。今回はコンテンツ制作部門の寺田による執筆です。

コンテンツを作ることがコンテンツマーケティングではない

「オウンドメディア」「コンテンツマーケティング」などというキーワードが注目を集めています。SEOの現場でも、GoogleがブラックハットSEOについて厳しいアップデートでのぞむ一方、「これからはコンテンツマーケティングだ!」「オウンドメディアで自社サイトをメディア化するんだ!」と、”ユーザーの役に立つ”コンテンツが重視される傾向にあります。

この流れ自体は誰の目にも素晴らしいことです。ただ、とりあえずコンテンツをジャンジャン書いてページをたくさん作ったところで、思ったようにアクセスが取れなかったり、アクセスは増えても商売につながらなかったり、ということも珍しくはないでしょう。

でも、実際に多くのWebのコンテンツを見ていると、これって実は当たり前というか。

結論から言うと、「メディア」って相応の労力(またはお金)や時間をかけたり、伝え方ひとつとっても様々な工夫をしていかないと、十分な効果は得られないんですよ。なのに、「何でもいいからコンテンツを作る」で走ってしまっているから失敗しているだけなんです。冷静に考えれば、それって”マーケティング”でもなんでもないですよね。

元雑誌編集者から見たWebコンテンツ制作現場

以前、10年ほど雑誌制作の現場にいました。そこからWeb業界に移籍してきたので、すべてが新しいことだらけなのですが「コンテンツを作る」という業務は同じなので考え方は同じというか。要は「人が読みたくなる文章を書く」ということは同じですからね。

雑誌からWebへと媒体が変わっても引き続きコンテンツ制作に関わっているのですが、Web業界で仕事をしていると「アレ?!」と感じることがあるので違いを軽くまとめてみます。

1. 誰が書いたかわからない記事・・・って大丈夫?

最近はクラウドソーシングって流行ってますよね。この業界に移籍して初めて知りましたが、文字単価0.2円(500文字書いても100円!)とかでの発注もあるみたいです。とにかく安い。。

クラウドソーシングという世界そのものについては、発注者にとってもクリエイターにとっても様々な課題を解決し得る、画期的な仕組みだと思っています。ライターとしても、空いた時間を有効活用できるので人気を集めてます。発注者側としても、コストを抑えてコンテンツが制作できてWin-Winです。

ただ、それをどう活用するかというのは利用者次第だと思っていまして。例えば、用途によりますが、どこの誰が書いたかわからない、何を情報ソースにしているかも不明な記事を、ロクにQAもせず自社名義のサイトに掲載されているものをしばしば見かけますが、それって皆さん怖くないんでしょうか?

もちろん、クラウドソーシングに登録されている方の中にもきちんとしたライター経験者も多くいます。でも少なくともしっかりした実績と実力のある方で、文字単価0.2円みたいな報酬で一生懸命文章を書きたいという人はそこまでいらっしゃらないと思います。

また、なにか問題が起きても「しーらない」でドロンされちゃったらどうするんだろうと。雑誌の現場だと、たまに聞くんです。いわゆる「飛んじゃった」ってやつで。

徹夜続きのデスマーチな現場だとありがちです。いきなり会社に来なくなったり、連絡が取れなくなったりする人。デスマの現場で誰か飛んじゃったら炎上どころの騒ぎじゃないので、やっぱり信頼できる人と仕事したいですよね。

2. 何を伝えたいのかわからない、ゆるい原稿

紙媒体だと誌面に限りがあるので、文字数との戦いは避けて通れない苦悩です。ガッツリ2時間かけて取材して聞いてきた内容を400文字にまとめてくれ、なんてことも多々あります。一方でWeb系の制作は物理的な文字数の制限がなく、「1000文字以上であればOK」といった発注も多いですよね。非常にざっくりしています。

それで、前述のクラウドソーシングみたいな文字単価の設定だと、ネットの情報を切り貼りしたような内容の浅い記事ができあがります。まぁ、これも必然というか。ボランティアではありませんから、ギャラ200円の原稿に何十分も時間かけてリサーチとかインタビューなんてなかなか出来ないですよね。

そうすると、どこかのまとめサイトとかWikipediaとかの内容を集めてきた薄ーい1000文字の原稿ができあがります。極端に言えば「伝えたいこと?そんなの関係ないよ」の世界です。

しかし、その文章はサイトに掲載することだけが目的なのでしょうか?違いますよね。そのコンテンツによって誰かの問題が解決したり、サイトを訪れたユーザーがあなたのサービスや商品のことを好きになったり、そういうことが目的なのですよね。であれば、それが伝わるように文章を作らなければいけません。

3. そもそも、見直ししてる…?

紙媒体だと印刷したらやり直しが効かないので、何度も何度も、これでもかというくらい校正確認をします。書いた本人はもちろん、ディレクター>編集担当者>取材対象者>デスク>クライアント>校閲者>編集長…といった感じで初校・再校と校正確認がまわるのです。

校正を経て、最終的には納品時の原型を留めていないことだってあります。それはそれでどうなんだという話もありますが、電話番号ひとつ、値段の桁ひとつ、間違えるだけで大変なことになると徹底的に叩き込まれるので穴のあくほど何度も校正が鉄則です。

ところがWeb サイトの場合、掲載後だって修正が可能なためか「この記事、見直し…してるよね?」という初歩的なミスがあるのにそのまま掲載されているものが多いです。読めばわかるレベルの大量の誤字脱字がそのまま、明らかに論理的な飛躍があるのにスルーというのは・・・残念ながら、悪い意味で行間から書き手の気持ちが伝わってきます。

ただでさえ、モニターで確認する原稿は、紙に出力して確認する原稿よりも間違いを見落としやすいという特性があります。それを考えると、納品前に数分程度の見直しだったら何度やってもいいと思うのですけど。

「編集者のように考えよう」とよく言われるけれど

簡単に3つほど挙げてみましたが、要はWebの場合、記事の質が「軽い」んです。コンテンツマーケティングの文脈ではよく「編集者のように考えよう」と言われていますが、自社サイトをメディア化するのであればしっかりとユーザーに“刺さる”コンテンツが必要です。

前述したような幾多のチェックを突破して掲載される雑誌の記事は、企画から取材・校正と膨大な時間と人件費を使って鍛えられ、磨き上げられます。

例えば、「東京○✕△グルメ」のような120ページくらいの情報誌であっても、制作費だけでウン百万円とかは必要になります。それでも雑誌になって800円くらいで2万部も売れたらOK、という感じでしょうか。

さらに企画から制作、印刷まで終えて本屋さんに届くまでには3ヶ月~半年とか時間が必要です。つまり何がいいたいかというと、メディアにはお金も時間も労力もかかるということです。それでも紙媒体はご存じの通り「出版不況」なので、利益を出すのは大変です。

ここで例えば、1つの雑誌(メディア)を創ると考えて上記と同じリソースを1サイトの「コンテンツ」として投下したらどうでしょうか。

じっくりと練られたクオリティの高いテキストと写真。例えばあなたのサイトにそういうレベルの1000文字の記事が100本200本あるだけで、それなりの集客効果が期待できるのではないでしょうか。

雑誌とWebのメディアが大きく異なるのは、日本全国で実売2万部の雑誌を手にすることができる場所は限られますが、Webコンテンツはいつでもどこでも、極端な話では何年後にも多くの人に見てもらえる可能性があるということです。つまり、そのコンテンツは資産として長く有効活用できるのです。

SEOの世界でもかつて通用したテクニック的な手法が通用しなくなっていますので、なおのこと、こういうところに積極的に投資しない手はないのでは、と思います。

問題は、ユーザーに何を伝えたいか

そもそも論になってしまいますが、企業のオウンドメディアで大事なのは「サイトへの流入が増えるだけの記事」ではなく「あなたのサイトが大事にしたいユーザーによろこばれる記事」ではないでしょうか。

今日もどこかでユーザーは困っています。困っているからこそ検索などを活用して解決策を探し、よりベストな方法を検討しているのでしょう。

彼らに伝えなくてはいけないのは、どこかで聞いたような解決方法の切り貼り記事ではなく、知識や経験に裏打ちされた「役に立つ情報」です。

それは新製品を使ってみた体験レビューかもしれないし、リアリティのある見積もりデータかもしれないし、あなたの会社が信念を持って取り組んでいる商品やサービスに関する知識を深めるためのコンテンツかもしれません。

ただ、少なくとも確実なのは「伝えたい」という気持ちの無い原稿からは何も伝わらないということです。逆に言えば、「伝えたい」という気持ちがあれば、それは必ず伝わるものです。

「伝える」ための5つのヒント

長くなってしまいましたが、「コンテンツマーケティング」だ「オウンドメディア」だと流行りのWebマーケティングに便乗したところで、「伝えたいもの」がない浅いコンテンツをどれだけ投下したところで、あなたのビジネスやサイトを訪れたユーザーを取り巻く問題は解決しません

一方で、慈善事業ならまだしもビジネスの観点から考えると「いつか伝わると思います」ではプロダクトとして社内コンセンサスも何も得られないでしょう。

気持ちだけではなく、実践的なWebライティングの経験やサイト構築の戦略といったナレッジが必要となります。メディアとして、想いを伝えるためにはテクニックが必要です。例えば、

  • あなたのサイトに来てほしいターゲットユーザーは、どんな人ですか?
  • あなたは彼らのどんな問題をどのように解決できますか?
  • そのターゲットユーザーには何をしてほしいですか?
  • 競合他社と差別化したいポイントはどこですか?
  • 上記の目的を果たすために、どんな記事をユーザーに読んでもらうべきですか?

といったことを常に心がけながら、コンテンツの制作・運営を進めることが重要です。そうすれば、オウンドメディアに必要なリソースは大きく削減できることでしょう。

そのためには制作チーム内で、それがたとえクラウドの向こうにいるライターだとしても、しっかりとビジョンを共有してみてはどうでしょうか。また出来あがってきた文章に、編集者はひと手間もふた手間も加えて、情報発信側の熱のこもったコンテンツとして公開してみてはどうでしょうか。

ぜひこの機会に、こうしたことを改めて一緒に考えてみて下さい。

最後に宣伝ですが、もし、こういうことを相談できる人が周囲にいない、考えてはいるんだけど手が回っていない、そういう方がいらっしゃいましたら、私たちはそうしたコンテンツ制作や企画の後方支援的なお手伝いもしておりますので、何でもお気軽にご相談ください。きっと何かの力になれると思います。

※よろしければこちらも合わせてお読みください※
Webサイトに必要なコンテンツとSEOについて
「ユーザー」から出発するWebコンテンツ企画の5ステップ【基本編】(外部サイト)

ヴォラーレ株式会社 寺田

SEOに有利?不利?エンジニアが見るHTML5とSEO

弊社はSEOのサービスを提供している関係上、直接コンサルティングには直接携わらないエンジニアでも、時折SEOに関する質問をされる機会は少なくありません。なかでもしばしば尋ねられるのが、SEOとHTML5の話題です。いまさらという感は否めませんが、本記事ではHTML5とSEOの関係についてざっくりと述べてみたいと思います。

HTML5とは

「HTML5」と言う場合、単純なマークアップ言語としてのHTML5をさす場合と、その関連技術を含む広義のHTML5をさす場合があります。

狭義のHTML5は、HTML4.0、XHTML1.1などと同列の、テキストを構造化するマークアップ言語です。要素の追加や変更、新たに導入された概念などの違いがあります。ただし既存の(X)HTMLとの互換性もある程度維持されており、本質的にはこれまでの(X)HTMLと大きな違いはありません。

一般的にHTML5といった場合、単純なマークアップ言語としての側面だけでなく、WebStorage、WebSocketなどのAPIも含めてHTML5と言われることが多いと思います。文脈によってはCSS3やSVG、WebGLといった技術も含めてHTML5と呼ばれることもあるようです。

本記事では、初めにマークアップ言語としてのHTML5について述べ、後半ではAPIの話題にも軽く触れておきたいと思います。

マークアップ言語としてのHTML5とSEO

マークアップ言語としてのHTML5を見たとき、HTML5にはどのような特徴があるのでしょうか?主な特徴として以下のようなものがあると考えています。

  • コンテンツ・モデルとカテゴリーの導入
  • 要素の追加、廃止と意味付けの変更

以上の点を、以下で少しだけ解説します。

コンテンツ・モデルとカテゴリーの導入

HTML4.0で定義されていた要素には、ブロック要素とインライン要素があり、インライン要素の中にブロック要素を入れてはいけないなどのルールが存在しました。例えば、インライン要素であるa要素を、ブロック要素であるdiv要素の中には入れることができないといったルールです。

このルールに従った場合、例えば以下のようなマークアップは認められません。

<a href=“http://www.seohacks.net/”><div>SEO HACKS</div></a>

例. HTML4.0における間違った要素の配置

HTML5では、このブロック要素とインライン要素に代わり、カテゴリーとコンテンツ・モデルという概念が定義されました。

カテゴリーとは、その要素が定義された目的を示すものです。例えば、body要素の中に設置できる要素はフロー・コンテンツというカテゴリーに属しますし、文章の章や段落を定義する要素は、セクショニング・コンテンツというカテゴリーに属します。

それぞれの要素で、中にどのカテゴリーの要素を含めてもよいか?というルールを表したのがコンテンツ・モデルになります。例えば、section要素のコンテンツ・モデルはフロー・コンテンツとセクショニング・コンテンツなので、このいずれかのカテゴリーに該当する要素を中に含めてよいことになります。

要素の追加、廃止と意味付けの変更

HTML5では、新たに追加された要素、廃止された要素、そして引き続き存続し続けるものの、意味付けの変更されているものが存在します。

追加された要素としては、article、section、header、asideなど文章構造を表現する要素や、embed、video、audioなどのインタラクティブな要素を表すものなどが追加されています。こうした要素の追加により、より文章の構造的意味を明確に示すことができるようになったり、インタラクティブなページの構成ができるようになりました。

一方で廃止された要素もあります。廃止された要素は、big、center、fontなどの見た目を定義していた要素や、frame、framesetのようなフレームに関する要素などです。これらの要素はCSSを使用したり、他の代替候補となるタグをすれば問題ないでしょう。

b、iなど、廃止ではないものの、以前のバージョンのHTMLから、意味付けが変更された要素もあります。例えばb要素はこれまで太字を現す要素で、かつ太字で現すという意味での仕様は非推奨とされていますが、HTML5では他と区別して表記すべきフレーズを示す要素となりました。

具体例 – hx要素のマークアップ

さて、HTML5によって変わる具体的な例として、SEO上も重要といわれる見出し要素のマークアップを考えてみましょう。見出しを表すh1〜h6要素はHTML4.01の場合、1〜6という数字でそのランクを示します。

<h1>見出しレベル1</h1>
<div>
  <h2>見出しレベル2</h2>
  <div>
  </div>
  <h2>見出しレベル2</h2>
  <div>
  </div>
</div>

例. HTMLの見出しレベル分け(HTML5でも有効)

最上位の見出しであるh1要素はSEO上、1つの文書内で1度しか利用できないというルールがありました。HTML5の場合も、このルールに従っていれば何ら問題はありません。

一方でHTML5の場合、新たに追加されたsection要素のようなセクショニング・コンテンツの深さを使ってセクションを表現することもできます。以下のようなケースでは、h1要素を複数使用されていても、それぞれのセクションにおける見出しのレベルを区別できるようになっています。

<section>
 <h1>見出しレベル1</h1>
 <section>
  <h1>見出しレベル2</h1>
 </section>
 <section>
  <h1>見出しレベル2</h1>
 </section>
</section>

例. HTML5ではこのような見出しの使い方も認められる

とはいえ、HTML5では既存の方法によるマークアップも可能です。当然の疑問として、どちらの方法を使うのが良いか?ということになりますが、上述の2つの例に優劣はありません。単に選択肢が増えただけなので、使いやすい方を選べばよいでしょう。

HTML5はSEOに有利なのか?

ここまで、HTML5におけるマークアップ言語として変わった点をごく簡単に記載しました。HTML5はSEOに対してどういった影響を与えるのでしょうか?結論だけ先に述べますと、HTML5の使用は、SEOに有利とも不利ともいえないと考えています。

確かにHTML5を使用することで、以前のバージョンのHTMLに比べ、より文章構造を明確することができ、サーチエンジンにとってもより文章の示す意味を解釈しやすくなったのは事実です。また、HTML5に追加されたインタラクティブ・コンテンツや、後述するAPIを利用すれば、よりリッチなコンテンツを記述することができます。

しかしながら単なるフォーマットの違いです。XHTMLで記述していた文書が、HTML5になることによって、ページそのものの価値が高くなったりすることはあるでしょうか?利用するサイトがHTML4.01なのかHTML5なのか、を気にする一般ユーザーはほとんどいないはずです。

新規でサイトを作る場合や、サイトのフルリニューアル時にHTML5を選択するのはありだと思います。しかし、SEO目的で既にHTML4.0やXHTMLで構成されているサイトをそのままHTML5に書き直すといったことは全く必要ないでしょう。

Web周辺技術としてのHTML5

HTML5のカバーする領域は非常に幅広く、マークアップ言語の側面のみならず、JavaScriptを介して扱うAPIや、WebSocketなどの関連技術もその範囲に含まれます。例えばWebStorage、WebSocket、Paging APIといったものが該当します。非常に幅広い領域のAPIが定義されており、全てを紹介しきることは到底できませんので、少しでもSEOに関係のありそうなAPIを簡単に紹介させていただこうと思います。

表示速度を計測する「Navigation Timing API」

Webサイトを見るときには、リンクをクリックしたり、アドレスバーにURLやキーワードを打ち込んだりすると思います。大抵のサイトでは、1秒〜せいぜい数秒の内にページが表示されるはずです。利用するユーザにとっては一瞬のできごとですが、ブラウザ上で見たいページをリクエストしてから実際にWebサイトが表示されるまでには、いくつかの段階を経ています。Navigation Timing APIとは、一言で言えばこの”いくつかの段階”として示しているものを共通化して、表示速度の記録・参照が可能なAPIです。

W3Cから拝借したNavigation Timing APIについてのドキュメント図では、以下のようなフェーズに分けられています。

Navigation Timing API

Navigation Timing API

このAPIは、通常のWebサイト上で利用するものではありませんが、Chromeのデベロッパーツールなどではこのフェーズを閲覧することができます。またGoogle Analyticsの「サイトの速度」で表示出来る時間も、このNavigation Timing APIにより測定されているものだと思います。

SEO上は小さなファクターであるものの、ユーザーエクスペリエンス的な側面も考えると、サイトの表示速度は決して無視できるものではありません。

以前、別の記事でWebサイトの高速化に関するトピックを紹介しました。このAPIを利用すると、こうした高速化による改善状況などを定量的に計測することができます。具体的な利用例としては、弊社開発室のブログでNavigation Timing APIを利用したツールでパフォーマンス測定を自動化するというトピックを紹介しておりますので、よければそちらも参照ください。

より詳しい解説は外部のサイトに譲りますので、このようなAPIも利用できることだけ知っていただければ十分です。

画面遷移せずに履歴を操作する「History API」

いわゆる“Ajax”を多用したサイトでは、画面の遷移なくコンテンツを書き換えたりすることが行われます。一方で、クローラーは1つのURLを1ページとして認識するため、このようなサイトのコンテンツを意図通りにインデックスさせることが困難でした。

上述のようなAjaxを使用したページをインデックスさせる方法として、Googleは#!(hashbang)を使ってAjaxアプリケーションをクロールさせる方法を提示していましたが、複雑な仕様で誰しもが利用できる仕様とはいえませんでした。

これを代替する手段として、近年はpushStateの利用を推奨しているようです。

pushStateは、HTML5で定義されているHistory APIの機能の1つで、画面遷移せずにブラウザの履歴にURLを追加することができる機能です。画面遷移をせずにAjaxを使ってコンテンツの書き換えを実現したい場合、pushStateを使えばコンテンツの書き換えと同時にURLも変更することができます。

もちろんAjaxを使わずとも閲覧できるサイトのほうが検索エンジンライクなのは間違いないと思いますが、必ずしもSEOが最重要のファクターである、というケースばかりではないと思います。検索エンジンには独立したページとしてインデックスさせたいといったニーズがある場合、利用を検討してみるのも良いのではないでしょうか?

まとめ

本記事では、HTML5の概要や、HTML5とSEOとの関係、HTML5に含まれるAPIの一部を紹介しました。すでに述べた通り、HTML5を使うことそれ自体がSEO上特別有利になるとか、不利になることはないと考えています。

とはいうものの、HTML5について正しく理解しておくことや、HTML5で何ができるか?を知っておくことは、誤った使い方によるリスクを避けたり、取りうる選択肢を増やすという意味で重要と言えるのではないでしょうか。

ヴォラーレ株式会社 若松

Webサイトに必要なコンテンツとSEOについて

SEOの強化のために、これからコンテンツを頑張る!で失敗するケースはよく見ます。単純にコンテンツとして貧相というのもありますが、方向性や優先順位を誤っていることも多いとは思います。ここでは「どんな順番で」「どんなコンテンツを」「どんな目的で」「どんな感じで」作りましょうか、をまとめてみました。

買いに来てる人が買うにあたって有用な情報を提示するのが最優先

さてSEO全然関係ないんですけど、うちに過去にアパレル販売を長年やってたメンバーがいまして、ブランドをいくつか渡り歩きつつ大手ショッピングモール内で全国店舗でTOPの売上をコンスタントに叩いてたみたいな感じです(ただし本人談かつ未確認情報)。

そんな彼がショップ店員時代になかなか売れない後輩がいて相談された時のエピソードについて少し前に話をしていたんですけれども、その話がなかなかよかったんですね。

「どれだけ接客下手なんだろうって思って、彼(後輩)がデニムを売るところを後ろから見てたんですけど、デニムについての蘊蓄とかを一生懸命お客さんに語ってて。でもそんなもん買い物に来てるお客さんはほとんど興味ねーだろって。接客がんばる方向が全然違うよね、って。」

「もっと、色とか履き心地、シルエット、素材感とか、組み合わせとか、そういう買うとか選ぶにあたってダイレクトに知りたいことをきちんと説明してあげたり提案してあげて、お客さんがほしいものを買うための選択肢となるような情報として提示しないといけない。」

本当その通りだしWebでもSEOでも同じだなあって思って聞いていました。

お客さんの反応を直に見る仕事してるとこういう感覚って結構養われると思うんですけどPC向かってるとこの感覚って薄れますよね。どうもデータとか見ながら機械的、テクニカルに考えちゃったり。

Webでも優先順位が違う場合が多い

商用のWebサイトについても同じことが言えて、第一に必要とされるコンテンツって間違いなくこういうところだと思います。少なくとも売りたい商品を掲載していてユーザーが買うものを探しに来てるのに、どんな情報をもとにどう選んで良いかわからない、とかじゃ本末転倒ですよね。

でも実際には、そんな状態なのに検索キーワードをベースにして用語集とかハウツー系のコンテンツばっかりを投下して蓄積するとかっていうケースは意外にあったりします。それ自体に意味がない、ではないんですけど普通に考えて順番は違いますよね。

もちろん、「そういう情報を日常的に探してるようなユーザーを優先的にサイトに集めたい」「日常的に情報収集をするようなユーザー層がコアなターゲット層なのでそこは厚くしておきたい」という場合であればそれで良いのでしょうけど。

ただし、商品を買いにきたユーザーがそこに来ているのであれば、まずは最優先で彼らが目的の商品を探せて選んで見つけられて購入できる、それがいい感じに実現できるためのコンテンツなり機能を十分に用意することが求められるはずですよね。

「売ることを主眼としたコンテンツ以外のコンテンツ」を用意することの意味

ここまで話ましたけど、売るためのコンテンツ、だけじゃいつかプロモーションとして先細りすることも実際には多いです。市場によりますが競合と少ないパイの奪い合いになりやすいですし、SEOを考える上でも限界がありますよね。

そこでその状況から脱却してマーケティングの可能性を広げていくためにサイトに掲載するコンテンツの範囲を拡張していく、ということが求められるわけですね。

なんでマーケティングの可能性が広がるかと言えば、その入り口としては

「売ることを主眼としたコンテンツ以外にコンテンツを用意することで、今サイトに用事のない(=今買おうと思っていない)ユーザーもサイトを訪れる理由やきっかけが出来る」

から、と言い切ってよいと思います。つまりコンテンツの範囲を拡張することで、その分サイトを訪れるユーザーが拡張するという具合です。

サイトを訪れるユーザーの幅が広がれば当然ユーザーの母数も増え、例えばですが、サイト内で打ちだすキャンペーンの効果が増したり、リターゲティング広告の配信リストが拡張できたり、リピートユーザーも増えたりリンクとかシェアを得られる機会も増えたり、まあ色んな可能性が広がるわけですね。

もちろん、ユーザーの幅を広げると言っても全くビジネスに関係のないユーザーばかりを集めてもそれはやはり徒労に終わるので(PV増やすことが目的のサイトは除く)、あくまでもその延長線上に売上なり何なりビジネスへの貢献がある、ということは求められます。

どういうコンテンツを用意するべきか

何でもかんでもコンテンツを広げて作ろうとすれば、それは失敗することも多いと思います。例えば、そのコンテンツが目的を持たないから、あるいはユーザーを想像して作られていないから、などの理由で失敗します。

そうならないように、まずは最低でも次の2つのことをを考えてみるとよいです。

  • どんなユーザーと接点を持ちたいか?(=どんな人にサイトに来て欲しいか?)
  • その人たちってどんな情報に興味があるのか?

これだけみると当たり前じゃんとしか思えないですけど、じゃあどのサイトもコンテンツ作るときこういうこと考えてる?と聞けば多分ですけどそうではないことも多いんじゃないかなと思います。

そしてこの2つを考慮してコンテンツを作ろうとすれば、少なくとも何でもかんでもページを増やしましょうという話にはなりませんよね。この視点は、コンテンツをどう展開しようかとかを考えるときには必ず持つべきことと思います。

そして、サイトに来て欲しい(自分たちが接点を持ちたい)ユーザーが興味ある情報を、一定以上の品質で展開できれば、少なくともそのコンテンツって絶対に無駄にはならないんですよね。

じゃあ品質って何よ、という話なんですけれども。

一定以上の品質って何だろう?

コンテンツの品質の定義って曖昧だし色々あると思いますけど、ここでは便宜的に文脈に合わせて都合良く決めてしまいますね。何かこんな感じかなと。

  • 訪れたユーザーにとって望ましい内容が書いてあるかどうか
  • コンテンツを通じてユーザーに何かしらのポジティブな態度変容があるかどうか
  • それがWebサイトの目的に直接的または間接的に貢献できるものかどうか

要は、コンテンツに辿りついて読んでみたけど「読む気がしない」「で、だから何?」「意味わかんない」「つまんない」で終わったらダメってことですね。

「へーそういうことなんだなるほどねー」とか「明日会社の人に教えてあげよー」とか「へーこれ面白いねー」「この会社に興味出てきたわ」「とりあえずブックマークしておくか」「クッソワロタwww」とか、そういう何かちょっとでもポジティブな変化を起こせるかどうか、だと思うのです。

もちろんそれがWebサイトの目的に近づくような態度変容であれば良し、ということですね。

こういうところを気にしていけば低品質な記事ってほとんど生まれないですし、つまるところ

  • あなたが接点を持ちたいと思うユーザーが
  • 興味関心または課題感をもつようなコンテンツを
  • 彼らが(顕在的または潜在的に)望んでいたような内容で作り、
  • ユーザーに何かしらのポジティブな態度変容が起こり、
  • Webサイトの目的に近づくことが出来る

ということが起きるわけですね。無理やり理屈にすれば、ですけれども。まあこの辺りはまた別記事でまとめてみようと思います。

ちなみに、少し話それるかもしれませんがこういうことを一生懸命考えていくと、どういう形でリンクをもらえるか、とかちょっとずつイメージできるようになります。何故かというと画面の向こう側にいるユーザーがイメージできるからです。

例えば、「●●業界用語集」とかよく見ますけど、適当に書いたものがリンクされるわけないですよね。そもそも誰が見るんだそれ、みたいなものも多いですし。

でもWikipediaは皆に見られていて恐ろしいくらいリンクされてますよね。その違いは何?とか、Wikipediaがリンクされる瞬間ってどういう瞬間?「おぉ、なんて素晴らしい用語解説だ!」とか「この用語解説に激しく同意!」みたいな感じでリンクすることってあんまりないよね?みたいなことを考えるわけですね。

じゃあ、どこまでコンテンツを広げればいいの?

今でしょ!

ではなくて、この辺も考えていかないといけないことです。皆が皆、コンテンツを広げていくことがサイトにとって重要というわけではありません。優先順位や投資バランスを間違えれば単なる回り道になることもあり得ます。

例えばApplivといううちが運営しているメディアにおいては、力を入れているコンテンツは今も昔もアプリの紹介です。何故かと言えばこのサイトはアプリを探すユーザーをターゲットとしているのでアプリを探すユーザーが必要な情報に軸を置いてコンテンツを展開しています。

それで、アプリを探すユーザーってどれくらいいるの?と言えば、めちゃくちゃたくさんいるわけです。なのでここをおろそかにして、「アプリを探してないユーザーにも見てもらえるコンテンツを」とかいってそればっかりを作ってたら、サービスにとって肝心なところが薄くなってしまうわけですね。

この辺は優先度とバランスの問題と考えるべきなのですが、無理やり言語化するなら

  • 拡張しなければ先細りするとか激戦区過ぎて勝負が苦しいなら「広げる」という選択肢を持つ
  • 「今すぐ」のユーザーがすごく多いのであれば、まずはそこに注力する

こういうことかな、と思います。まあ、後者のような場合には、競合とのコンテンツとしての差別化がなかなか難しいものも多く、言うは易しだったりもするのですが、、そういう場合は同様に広げることの優先度を少し上げるべきかなと思います。

最後に、SEOはどう考えるのか?

記事タイトルを見直して、SEOに何も触れていないことに気付きました。先ほどのコンテンツの考えるべき要件に加えて、以下のことを追加で考えてみてください。

  • 検索して探されるような情報か?どれくらい検索されるか?
  • 検索する人がはどのような言葉で探すか?またそういう言葉で文章が書かれているか?
  • 検索エンジンが正しく理解・評価できる形式で書かれているか?
  • 新しいリンクの獲得に貢献できているか?

ここまでの内容が「そりゃそうだろ」と思う方については、コンテンツ×SEOの考え方は特にハードルの高いものではないと思います。この辺の話題は “ホワイトハットSEOが上手くいかない”という人へのアドバイス という記事でも多少触れているので参考までに。

逆に、こういうことを何も考えずにコンテンツを作ってきた方、これから作ろうと思っていた方は、こういう考え方をするかしないかで、コンテンツのテーマ、書き方、文章構成、言葉選び、効果検証、色々と変わってくると思います。

完璧なコンテンツなんてありませんし皆がハイレベルなコンテンツを作れるわけではありませんし(僕が身をもって実証中)、ただ、何も考えずに作るのと、こういう思考のもと何かを作るのでは全然違います。伝えようと思えば、伝わる人には伝わるものです。

少なくとも、こういうことを日常的に考える癖がつけば、「どれくらい記事をアップしたら上位表示できますか?」というようなSEOの呪いからは解き放たれるのではないでしょうか。

是非、参考にしてみてください。

ヴォラーレ株式会社 土居

URL正規化の方法、、の前に考えるべきこと

主に制作とか開発の仕事をされている方と話していて、URL正規化についての考え方、についてちょっと違うんじゃないのと思うことがあるので書きます。すごく基本的なことなのですが、あまり話題として触れられていないように思ったので。

URLの正規化とは何ぞ、という方にまず解説

検索すればそういう記事はとてもたくさん出てきますが、サッパリでピンと来ませんという人のために、かなり粗いんですけど例えを入れておきますね。まずはイメージから。

例えばSalesforceみたいな基幹システムを色んな人が好き勝手触ってると、いつの間にかどんどんデータが乱れてくることってありますよね。その中でも結構やっかいなのがこういうデータの重複登録問題。

電話番号違い、社名表記違いなどで同じ企業データが重複判定されずに複数存在してしまっている状態

例えばですが、こういう感じですね。こうなってしまうと企業データを検索して新しいデータ入力しようとしたりするときに無駄な確認とか処理が発生しますよね。もちろんトラブルの原因にもなるのでこれはよろしくないです。

で、こういう風に「複数存在してしまっているけど実質同じものはひとつにまとめた方が良いよね」というのがいわゆるSEOの正規化のイメージです。

(補足)
もともと正規化って「”名寄せ”みたいな感じ」って言ったほうが近いものがあるかもしれませんが、SEOの話題としては必ずしも名寄せとは感覚が同じでない場合とかもあるのでそういうことにしておきます。

どっちにしても「1つであるべきデータがバラバラになっていたら管理とか処理にあたって色々不都合ありますよね」ということだと思っていて下さい。

SEOでいうところの正規化について

SEOでいうところの正規化のイメージは、「複数の異なるURLに同じコンテンツが存在する場合、どのURLを検索エンジンが評価すれば良いのかを1つ定めてそこに評価をまとめる」ということです。

実質的に同じコンテンツが、異なる複数のURLで閲覧できてしまう状態から、正規化処理を行いひとつの代表的なURLを指定しそこに評価を統一する

検索エンジンも、同じコンテンツなのに別々のURLでそれが返されてしまうと、「どれを見ればいいんだろ?」ということになって正しい処理が行われなかったり、少なくとも無駄な処理をさせることにはなってしまうわけですね。

規模や内容によりますが、あまりにこうした問題がサイト全体で好き勝手に発生しまくっているという状況はSEO上かなりネガティブになり得ることですので、きちんと整備しておくことに越したことはありません。

さてようやく本題です。

まず最初に考えるべきは「重複させないための仕組み」

冒頭の例に戻りますが、ああいう形での重複データがあると、検索して最新状況確認する際に色んなとこに情報が散らばってたりしていて、「誰だよこっち書いた奴、こっちにまとめろよ」みたいなことになるわけですね。

この状態は間違いなく色々不便かつ正しくない状態なので、避けるべきことです。

1つ2つあるだけならまだしも、これが数百とかに渡って大量の重複データがシステム内に存在する、あちこちに情報が散乱してまとまってない、みたいな状態になっていたらもうカオスですよね。

で、この時にその部署の管理者が真っ先に考えるべきことって、「重複が原因で顧客データに不備があってで何かトラブルが発生したときの対応策」とか「重複データをどのデータにまとめるかのルール」ではなくて「重複データが発生しないための仕組み」ですよね。

予めシステム側で上手く照合されるように良い塩梅の条件決めておくとか、オペレーター側での指導や管理の徹底だったりとか、そういうことで問題が起こらないように仕組みを作っておくわけです。

最近LINEマンガでROOKIESを久々に読んだのですが、

「あらかじめ打球を予測していとも簡単に捕る。それが本当のファインプレーだ」

と池辺教頭もおっしゃっていまして、それと同じ理屈です。

コンテンツに対してURLが一意であることが理想

SEOに話を戻します。前の話をURL正規化の話に無理やり帰着させて、「URLがばらけるから正規化しよう」ではなくて「URLがばらけないように作ろう」が先にあるべきだ、という話ですね。

テクニカルに「こうすればいいんです!」みたいな応急処置を積み重ねていくと、後々どこでどんな処理をしていたかとか分からなくなったりリニューアルの際に抜け漏れが発生したり、あまり良いことはありません。

もちろん、www.とか拡張子とか「/」有無とかutm系のパラメータとかそういう当たり前に発生するものはいつも通りの転送やcanonicalなどで正規化処理をする必要がありますので(今回は解説割愛)、そういうもの以外での不要な正規化処理を避けようとすることが大事ということです。

分かりやすい例で言えばクロスカテゴリ(財布(アイテム)×シャネル(ブランド)みたいにあるカテゴリと別のカテゴリとの掛け合わせ)が発生するようなサイトでこういう形を稀に見ます。

経路によって、クロスカテゴリのページや商品のページのURLが変化してしまっている例 実質的に同じコンテンツが複数存在するのが当たり前の仕様なのでこれはよろしくない

こういう仕様でガッチリとシステムを固めてしまうとあまり簡単にはいじれなくなりますので無理やりcanonicalで対応するような処理をする必要が出てきます。

この場合は、複数の可能性が考えられる経路やカテゴリに、クロスカテゴリのURLや商品ページのURLが依存してしまってるのが問題ですね。

ディレクトリの従属関係を予め決めておく、商品ページはカテゴリから独立したディレクトリ配下のURLにする、などの考慮があると一意のURLが定まる

これは一例ですが、このように商品のURLはカテゴリや経路に依存しない仕様にしておかないと、というような配慮があれば正規化処理などここではもともと考える必要もなかったわけです。

よほど大規模だったり複雑なサイトでなければ、最初にURLについて考えておけば大抵の問題は回避できるんじゃないかなと思います。それなのに「URLもちゃんと考えておかないと」って考えて設計しようとしている方って意外に少ない気がします。

あるコンテンツに対してURLは一意、が基本

「ひとつのコンテンツに対してURLがひとつ」であるべきで、余計な正規化処理をしなくてよいURLの設計を心がけてみてください。

SEOってサイトとかページとかではなく本質的にはURL単位でクロールされ、URL単位でインデックスに格納され、URL単位で評価が付きます。そういう意味ではURL設計を考慮することは基本的なSEOのひとつです。

仕事柄、色んなエンジニアの方と話す機会ありますが、「URLをどう吐きだすかとか深く考えたことなかったッスねー」という感じの人は (受託開発してるとかメディア運営してるとか関わらず)多かったりします。

特に幅広いコンテンツを扱うとか大量のコンテンツを扱う、とかの場合、このあたりのURLの考慮の有無によって後々余分な処理をするための工期が削減できる、改修や拡張が入った時にも変更が少なくて済む、変更が少なくて済むということは実装ミスによる検索トラフィック損失などのリスクが減らせる、というわけです。

補足:検索エンジンが進化しても機械への配慮はしておく

「Googleも上手く対処できるようになってるから細かいことはあんまり気にしなくていいよ」とはGoogleがよく言っていることで、確かにそうなってきています。しかしここは受け手としては「検索エンジンの技術に合わせることに躍起になってコストかけなくていいよ(Googleが頑張るからさ)」と捉えたいところ。

サイトを作る方は、「それでもサイトを制作する時には(検索エンジンに限らず)機械への配慮を怠らない」と考えるべきと思います。SEOに限って言えば、そうすることで防げる損失がかなり大きい場合も珍しくありません。

ということで、この記事を読んで「へぇそういうこともあるのか」と感じた方は、是非参考にしてみてください。

ヴォラーレ株式会社 土居

「SEOノウハウ」って何だろうね、という話

“SEOノウハウ”という表現、よく使われますけど、これまたエラく曖昧な、そしてその言葉を単独で使えば、何とも胡散臭い言葉だと自覚しています。この業界では特に、でしょうか。「僕らSEOのノウハウたくさん持ってるよ」とかドヤ顔で言われても何言ってるのか正直よく分からないですよね。

(※って言って”SEOノウハウ“って調べたら僕が以前に取材頂いた記事が1位に、、すみませんでした)

話を戻して、何をもってSEOのノウハウというんだろう、ということについて。言葉を明確に定義する必要もないとは思うんですけど、「言葉にするなら多分こういうものかな」って言えば自分はしっくりくるなと思ってる内容をまとめてみようと思います。

「SEOノウハウ」がそれ単独で出来ることは少ない

ちょっと話は逸れますが、例えば、大学生3人で始めたばかりのスタートアップ企業が、いきなりリクルートさんの主力Webサービスと同じサービスをWebで展開しても同じことはできないですよね(例に出してしまってすみません)。資金力、人的資源、組織力、ノウハウ、運用歴、ブランド、何もかもが圧倒的に違うわけですね。

そしてそれはSEOにしても同じことが言えます。

表面的なサイトの形や機能は同じように構築すれば同じようにできることは多いと思いますが、じゃあ既にそのジャンルのトップ(キーワードの順位だけじゃなくて事実上のトップ)に長らく君臨するようなサイトはそういう要素だけで出来上がってるの?と言えば全然違うわけです。

世間一般にSEOが強いとされるサイトを見てその表面だけ真似ても、長期的に蓄積されてきたWeb上の資産は一朝一夕ではまねられません。そういうサイトのSEOの”強さ”の土台となっているのは「SEOのノウハウ」なんていうものではなく、サイトへの投資、ビジネスへの投資そのものだったりします。

だから単にSEOに詳しい人がいるだけでは、ビジネスを加速させることには限界があるわけですね。

SEOに長けている人がWebに関わると何が変わるのか

じゃあ、SEO強い人がいると何が良いのよ?というお話で。SEOに関する知見の多寡によって差が出るのは、次のような項目なんじゃないかと思っています。

  • そのビジネスにおけるSEOの重要度の評価を適切にできるかどうか
  • そのサイトでの理想的なSEOのイメージ(将来像)を持てているかどうか
  • 現状の課題を正しく認識し、現実的かつ妥当な施策のプランニングができるかどうか
  • サイト運用や企業活動の実績をどれだけ有効なSEO資産に転換できるか
  • 蓄積されたSEO資産をどれだけ有効な検索トラフィックに転換できるか
  • 検索トラフィックをどれだけ資産や収益に転換できるか

せっかく良質なサイトを運用していてもこのノウハウが欠如すれば100の投資をした結果のリターンが20しかないかもしれない(実際そういうサイトは多いですよ、勿体ない)。

でも、ある程度の知見があればこれを150にできるかもしれない。
本当にSEOに強い人がやればこれを300まで持っていけるかもしれない。

ちょっと雑ですけど、個人的には、SEOのノウハウというのはそういう類のものだと思っています。

ちなみに”SEO資産”というと何とも怪しい表現ですが、砕けて言えば「検索エンジンに認識・評価され検索結果により多くサイトが露出されるための材料となるもの」みたいな感じでしょうか。

コンテンツやリンクといった直接的な資産は分かりやすいですが、「継続的にサイトに訪れ、リンクや共有をしてくれる可能性の高いユーザー」みたいなものとかそういうのも本質的にはサイトの資産と考えるべきかなとも思います。

何にしてもサイトに色んなものを蓄積していくことは必要

基本的には先ほどこういうものになります。ただし、人工リンクみたいにサイト自体の改善をせずに評価を底上げするようなやり方を除き、100の投資自体はきちんとする必要があるんですよね。

つまりサイトに対する100の投資を300のリターンに出来るような”SEOに強い人”がいたとしても、投資が10のサイトであればそれを30にすることしかできないんですね、超単純計算では。

その場合、別のサイトでそれなりのスキルを持った人たちが100の投資で150のリターンを返してきているなら、そのサイトには勝てないわけです。

多分これがSEOノウハウというもののある意味での限界かなと思っています。

何もない状態で出来ることがほとんどなくて、何かする場合には基本的に何をするにもSEOが関わってくるのでそこにいちいちSEOを考慮した要件や仕組みを組み込んでいく、そんなイメージです。

しかし、言うは易し、するは難し

簡単に言っていますが、先ほど挙げたようなこと(資産を蓄積し大きなリターンに転換する)を本当に上手に実現しようと思うと、SEOと一言で言っても本当にいろんなことを知っていないといけないし、最低でも、相応に広い視野を持たないといけないのです。

また、必要な素養が幅広いので大変です、ということ以上に、明確なリターンが見えるわけではなく、かつ確かな正解のないものに、そうした動きを積極的にしていきましょうよ、としてそれを実行に移すまでのハードルが、企業によっては非常に高いと思うんですよね。

そういうところを少しでもカバーできればと思って(勿論、あわよくば案件のご相談など頂ければと思って)セミナーとか勉強会とかもやっているわけですね。今は需要の濃い話題とか、検索エンジン周りに寄せていますが、今後少しずつ領域広げてバリエーション増やしていきたいなとも思っています。

そんな感じで引き続きよろしくお願いいたします。

ヴォラーレ株式会社 土居

2014年は大人数のSEOセミナー形式だけでなく少人数制のワークショップや勉強会を開催します

さて、放置気味だったサイトを1月に全面的にリニューアルし、ブログもしばらく更新が滞っておりましたが、2月からまた更新を再開いたします。2014年もよろしくお願いいたします。

SEO勉強会・ワークショップ定期開催のお知らせ

ということで、2014年最初の更新が告知のような内容で恐縮なのですが、昨年まで月次で開催する(しなかった月もありましたが汗)SEOセミナーが中心でしたが、今年は大人数を集めてセミナー形式、というよりも、少人数制でのワークショップや勉強会を中心に、頻度を上げてテーマを色々変えて毎週開催する予定です。

→詳細:ヴォラーレ SEOセミナー開催情報 | SEO HACKS

理由としては、実際に案内をしても「日程が合わないので」という理由で来られない方が結構いらっしゃったり、あと月に一回だとテーマもそんなに色々できるわけでもないですし、ということで、もうちょっと小回り効かせながら小規模開催をしていきましょう、ということになりました。

勉強会・ワークショップの内容

色々テーマを変えながらやっていますが、今やっているのは主に内部的な話、ペナルティ系の話題、事例中心の話題、初心者向けの話題、などなどまあ色々です。

ちょっと現時点でやってみて頻度が多すぎると既に思っている節もありますので頻度については今後は週1~2程度で開催されていく、程度に解釈して頂けるとよろしいかと思います。

講師の實川くんが講義している写真

これまで行った内容のアンケート

1月に行った勉強会のフィードバックとしてはこうしたものがありました。

実践に基づいた説明のため、リアルに伝わった。

受講者参加型で題材となるサイトのSEOのレビューを行うなど、普段あまり体験できない内容もあり、ためになった。

半分位は知っている知識でしたが改めて整理されました。もう半分は知らないことでしたので活用できそうです。

少人数だったこともあり、自分が気になる点をたくさん伺うことができました。無駄がない。

初心者にもわかりやすかったです。知識が追いつかずどう質問して良いのかわからないところもありましたが、自社HPの課題がなんとなく見えてきた気がします。

超初心者にもわかるSEO、みたいな内容も今後やって欲しいです。タグのこと、キーワードのこと、ブログの書き方で気を付けることなど。

こうしたフィードバックを受け、順次改善できるポイントは改善して参ります。

2月開催中の勉強会・ワークショップ

リンクに依存しない内部SEO改善のポイント
人工リンクのリスクが高まる中、インハウスでSEOに取り組まれる企業様向けに、見落としがちな改善ポイントをピックアップしていく形で内的SEOのエッセンスを学んでいただきます。

脱・広告依存!SEOでトラフィックを集めるための基本要件
リスティング広告の単価高騰×ブラックハットSEOの市況の変化に伴い、競合に対する優位性の確保に悩む企業様向けのSEO勉強会です。

不動産賃貸サイト事例に見る、内部SEO改善のポイント
不動産賃貸サイトや求人サイトなどによく見られる典型的なDB連携の検索サイトのような、なかなか独自性や差別化をはかることが難しいサイトのSEOのポイントについて解説します。

順位下落と手動警告の最新事例から読み解く、Googleペナルティ対処法最新セミナー
不自然リンクに起因するGoogleペナルティの解除対応事例を紹介した上で、今すぐに活用できるペナルティへの対処方法をお教えします。

【ワークショップ】Googleペナルティ対応担当が教える、不自然リンク調査(リンク精査編)
実際に不自然リンクペナルティを受けてしまった企業様が、自社でリンクの調査を行い解除まで導くために、ワークショップを通じて実際にどのようなリンクを削除対象とし、どのようなリンクを残すべきかを学んで頂きます。

Q&A

たまにお問い合わせで頂く内容についてはあらかじめ回答しておきます。

終わったあとにガッツリ営業されるの?

営業かけられるんじゃないの?という点については「後日営業しても良いですか?」というアンケート項目がありますのでそこにYesと書いていただけたら喜んで営業しますし、そうでなければ引き続きよろしくお願いいたします程度に留めますのでその点気負わずご参加頂ければと思います。セミナー案内くらいは継続的にお送りすると思いますがご了承ください。

営業を希望しますか?というアンケート硬毛k

SEOについて素人だけど大丈夫?

講師もSEOに不慣れな方でも分かるような説明を心がけておりますので、参加して意味がないことはないと思います。ただし、既にSEOを実践している方向けの内容も多く含まれたり、質疑応答もそうした内容が中心になることもありますので、講義の内容についてはある程度選ばれたほうが良いかもしれませんし、こういうのないの?というご要望などは大歓迎ですのでお気軽にお問い合わせ頂ければと思います。

このくらいの金額だったら無料にすれば?

特に数千円の収益を上げたいということではなく、真剣に勉強されたい、あるいは既に実践している中で明確な課題を感じている、といった方を中心に参加して頂きたいと思っています。

以前はほとんどが無料でのセミナーでしたが、例えば私が去年25,000円のセミナーを開催した際は2回とも満員御礼(第1回は40名、第2回は70名)までご来場頂きましたが、無料セミナーとの違いについて感じたこととしては、全体の真剣さが格段に違うなあ、というところ(タイプ音が半端ない)と、質問されるレベルも、普段から色々とSEOについて情報のキャッチアップをしつつ試行錯誤されてきたんだろうな、というようなご質問ばかりでした。

実際に1月の勉強会でも、わざわざ地方から複数名でいらっしゃったり、題材として是非自分のサイトを使って欲しい、というご要望も多く頂いたりしています。数十名で行うセミナーよりも講師とのコミュニケーションの機会は多くとっていただけますし個別の質問についても対応できることも多いですので、費用は頂きますがご参加頂く価値は十分あるかと思いますので是非日程合えばご参加下さい。

ということで2014年もSEO頑張っていきましょう。今年もよろしくお願いいたします。

※勉強会・ワークショップの詳細はこちら→ヴォラーレ SEOセミナー開催情報 | SEO HACKS

ヴォラーレ株式会社 土居

スマートフォン版サイトがないのにスマホとPCで検索順位が全然違う、という事例を調べてみた

6月に、「スマートフォンユーザーにとって著しくユーザーエクスペリエンスを損ねるような実装をしている場合、スマートフォン検索においてのみランキングを下げることがある」というような話題がありました。

※参考:Google ウェブマスター向け公式ブログ: スマートフォン向け検索でのランキングの変更について

先日、うちのメンバーに頼まれてあるクライアント様のサイトを調査してみたところ、それに近い話題で、ただちょっと特殊っぽい事例にあたりましたので紹介しておきます。

結論:スマホでは普通に見れるけどGooglebot-Mobileには不適切な転送設定されていた

ざっくり言いますと、「通常のスマホブラウザでは問題なくレスポンスが返されてサイトが閲覧できるのに、スマートフォンのUAを持ったGooglebot-Mobileに不適切なリダイレクト、具体的には『全てTOPページへ転送』のような設定がされていた」という状態でした。

と言われても何のこっちゃピンと来ないという方も多いと思いますので簡単に解説していきます。

解説

まず状況としては、

  • 少し前からスマホ検索でのみ検索結果に表示されなくなった
  • でもスマホサイトもないし、スマホでの閲覧も問題なく出来る
  • 変なリダイレクトがかかってたりする様子もない
  • PCサイトでは問題なく検索トラフィック伸びてるのにスマホだけ激減してる

という感じで、最初は検索結果のバグかテストか何かかな?とも思ったのですが、それなりの期間そういう状態だったのでそういうわけでもなく、何かしら致命的な問題があるはずと思って改めて調べてみたわけですがしばらくの間は良く分からんという感じでした。

ようやく思い立ってFetch as Googleで投げてみた

ちなみにFetch as Googleって何、という人のために言うと、「Googlebotがどういう風に情報を取得しているのかを確認できる、ウェブマスターツールの機能」です。こんな感じです。

ウェブマスターツール左メニュー「クロール」から「Fetch as Google」の機能を選び、URLを指定してクローラの種類を指定する
こんな風にURLとクローラーを指定すると、

Googlebotが受け取る情報がそのまま表示される
こんな風にクローラーが受け取る情報を表示してくれます。(↑はテストなので気にしないで下さい)

さて話を戻しますが、ChromeでUAとかいじくりながら色んなUAでアクセスしてみても全部通常に見れて、冒頭の記事にあるように「スマホ閲覧に苦しいくらい表示が遅い」なんてこともないし、何だろうなあと思いながら色々見てたのですが、「あ、Googlebotで見てない」とようやく気付いてウェブマスターツールでFetch as Googleで投げたんですね。

そうしたら案の定、スマホUAを持ったGooglebot-Mobileでアクセスすると「リダイレクトループになる」とか「全てのURLがTOPページにリダイレクトされる」的な感じになっていました。Fetch as Googleで取得した情報は以下のようなものでした。

HTTP/1.1 302 Found
Date: Wed, 13 Nov 2013 11:36:07 GMT
Server: Apache
Location: http://www.**********.jp/
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF=”http://www.***********.jp/”>here</A>.<P>
</BODY></HTML>

※この辺りの見方についてはHTTPステータスコードについての記事を参考にしていただければと。

まとめ

「スマホ版のサイトを持ってないなら、変な仕様になってスマホ検索結果で変な結果になることはないはずなんだけどなあ」というところでちょっと先入観ありましたがあくまで情報を取得してるのはGoogleのクローラーなのですからそちらでチェックしないといけないですね。

あまり汎用的ではない話題だと思いますが、ここ最近だけでも数回、スマートフォン検索での検索結果が下がった、などの相談を頂きましたが、どれも不適切なリダイレクトなどの初歩的な設計ミスが何かしら発生しているという状態でした。

そもそも冒頭にあるような話題をキャッチアップしていなかった人は必ず知っておくべき事項ですし、こういう細かな設定ミスでもトラフィックに重大な影響を与える可能性もあるということで、きちんと予備知識として再確認をしておけると良いですね。

ヴォラーレ株式会社 土居

おすすめの記事

titleタグなどのキーワード最適化は「ページの内容」ではなく「検索する人」に合わせて言葉を書く

SEO視点でのキーワードチューニングについて書きます。比較的ライトな話題ですが大切なのに意外に考えられていないことも多かったりするなあと思いますので、というかそう思うことが何度か最近あったので書いてみることにします。自分で言うのも何ですが得意な領域ではありません。

キーワードは「ユーザーが検索に使う言葉」を使う

概要として何が言いたいかと言いますと、「ここはこういうページだからこのキーワードを入れる」「ここにはそういうキーワードを入れるのはちょっと違和感」みたいな感じで行くと、上手くいかないことは結構ありますよね、ということです。

そうではなくて、「このページを検索して探す人というのは(一連の検索行動に)どんな結果を期待している人で」「その人はどういう言葉を使って検索するんでしょうね」ということを考えないと本当はいけないと思うのです。

例:「○○ ランキング」みたいな検索

例えばですけど「結婚指輪 ランキング」という言葉。これ、直接的な検索の意図としては「結婚指輪のブランドの人気ランキングが知りたい」とかなんでしょうけど、このキーワード、ランキング形式とかじゃない普通のブランドサイトをLPとしても結構コンバージョンしますよね。

要はこの人の元のニーズを単純に考えれば「結婚指輪を探してる」人なんですよね。たまたまその手段として「ランキングで比較して調べよう」って思いついたからその検索を行っただけであって。

本質的に検索に求めるものと実際に検索窓に打ち込むものとは必ずしも一致しない

なので「うちはランキングサイトじゃないからランキングという言葉は要らない」という考え方は、ある意味正しいのかもしれませんが完全に捨ててしまうのはそれはそれでロスになってますよということが言えるはずです。

「このページはこういうページだから」よりも「この検索をする人が何を求めて検索してるのよ」ということを考えたり、CVに直結するようなワードでは「この検索をするような人はコンバージョンするの?しないの?」ということを考えるほうが重要ですよね。

更にその言葉がドンピシャでSEOで上位ヒットさせられるかとかコンテンツが作れるかとかはその後の話であって。(もしドンピシャでなければその言葉を含んだ細かなロングテールの掛け合わせ検索にコンテンツの可能性を探ったり云々)

SEOとリスティング広告の大きな違い

前出の例で言えば、ブランドサイトがランキング形式じゃないのにランキングという言葉にバシッとヒットするようなコンテンツを作るとか考えるというのはそんなに簡単なことではないと思います。こういうのは結構難しいなといつも感じるところです。

個人的に感じるSEOとリスティング広告の一番大きな違いはこういうところだと思ってるんですよね。短期的な云々とか中長期的な視野でとかいうよりも、「キーワードが(受け口となる)ページのテキスト情報に依存する」のがSEOで「ページのテキスト情報に依存せずにキーワードを考えられる」のがリスティング広告で、という感じで。

ですからリスティングで効果のあるキーワード→SEOでそのキーワードで上位表示、という昔からの常套手段的なアプローチですが、無理やりSEOでやろうとすると結構無理やりになったり効率悪くなったりするキーワードも中には含まれることもありますね。

例えば賃貸とかでも「ペット可」とか「保証人不要」とかこういう言葉ってSEMでCV穫れるイメージありますけどSEOでこの単ワードの上位を狙っていくのってそんなに簡単ではないですしね。何も考えなければ「エリア+賃貸」的な掛け合わせにSEOは寄りがちです。

「正しい言葉よりも候補に漏れないこと」

ここから先はどんどん話がそれていくのですが、何年か前にどなたかがブログかツイッターか何かで言ってらっしゃった言葉が印象的で未だに覚えているんですが「文章や言葉として正しいことより、検索結果で候補に漏れないことが大事」という感じのことですね。

確かこの発言自体は広告文の作り方か何かの話題だったと思うのですが、SEOのタイトル付けに関してもこれはほんとその通りだなと思ってまして、自分でSEO考える時には必ず意識するようにしています。日本語として矛盾があっても構わない、多少の羅列でも構わない、とか。助詞を変に使わずに半角スペースで区切る、とか。(もちろんウンザリするような羅列や詰め込みは色々アウトですよ)

※この辺の話題であんまり下手に掘り下げて変なこと言うとSEM專門の人達とかから怒られそうな気がするのでこの辺にしておきます汗

動的なサイトの検索結果ページなどのタイトル付け

「検索に漏れないことが大事」という意味では、動的に吐き出されるテンプレートの中のタイトル設計を見ていても、意外に「カテゴリ名 | ☓☓なら△△ナビ」みたいな感じになっているものも結構多いですが、これは検索という観点から見ても非常に勿体ないことですよね。

弊社のApplivというサイトでも結構な数の一覧ページがありますが、こんな感じで出し分けるようにしています。

実際の「家計簿アプリ一覧ページ」

例えばですが、「家計簿」というジャンルの一覧ページのtitleタグ表記とmetaディスクリプション表記について見てみます。(無料アプリ版ページも合わせて書いておきます)

(デフォルトの一覧ページ)

家計簿 アプリランキング | iPhone/iPadアプリ - Appliv
Applivでは「家計簿」に関連するiPhoneアプリ・iPadアプリを135件紹介しています。 Appliv独自のランキングやユーザーレビュー、アプリ画像などから、人気・おすすめの アプリを探すことができます。

(「無料」で絞り込んだ一覧ページ)

無料 家計簿 アプリランキング | iPhone/iPadアプリ - Appliv
Applivでは「家計簿」に関連する無料iPhoneアプリ・iPadアプリを75件紹介しています。 Appliv独自のランキングやユーザーレビュー、アプリ画像などから、人気・おすすめの アプリを探すことができます。

このような感じのタイトルやメタディスクリプションで今のところやっています。日本語として正しいかどうかは置いておいて、アプリを探す検索の組み合わせでかなり多い「ランキング」「無料」「おすすめ」「人気」などの主要な言葉は全て押さえておきましょうという感じです。もちろん検索結果表記だけでなくページ内でもそういう言葉が必ずでるようには設計しています。

要は「漏れたくない」のです。なのでちょっとキーワードの羅列的な表示であっても、検索結果で目についてクリックしてもらえればそれで良し、としています。

※もちろん絞りこまれた検索になるほど「全てのキーワードが書いてある」を満たさなくても、ある程度意図を満たしそうなものであれば検索にも普通にヒットするのですが、とは言えそれが「敢えて大事な言葉を書かない」理由にはならないと思っています。

勿体無いなあと思う形(例)

例えばよく見るのはこんな形です。同じような一覧ページがあったとして、

(デフォルトの一覧ページ)

家計簿 | Appliv[アプリヴ] - iPhoneアプリ・iPadアプリが探せる、見つかる
家計簿のページです。22196件のアプリレビューと独自のランキングから、あなたが欲しいアプリを探すことが できます。新着アプリもおすすめアプリも、iPhoneアプリ・iPadアプリをお探しならAppliv にお任せください。

(「無料アプリ」の一覧ページ)

家計簿 | 無料アプリ | Appliv[アプリヴ] - iPhoneアプリ・iPadアプリが探せる、見つかる
家計簿のページです。22196件のアプリレビューと独自のランキングから、あなたが欲しいアプリを探すことが できます。新着アプリもおすすめアプリも、iPhoneアプリ・iPadアプリをお探しならAppliv にお任せください。

こんな感じでしょうか。よくあります。こういうのだからヒットしないということはありませんが、掛け合わせ検索への対応はちょっと弱くなると思います。もちろんこのようなタイトル付けですとクリック率が下がることもあるでしょうし。

まとめ

珍しくこういう話を触れましたが、SEOの基本として「(よく検索される)大事な言葉は必ずタイトルや文章内に出現させる」ということはどこの本でも書かれていることですが、システムが絡んだり大きなサイトになったりすると、テクニカルな要件が優先されてこういうところは意外に抜け落ちやすいのかなあなどと思ったりもしています。

また制作する方がそういう要件を必ずしも汲んでサイトをいつも作っているかといえばおそらくそうでないことのほうが圧倒的に多いとは思っていますので、企画する人というかSEOに理解がある方がこういうところはある程度考えてサイトは作った方が良いですよね。

細かなテキストチューニングを行う場合とか、SEOの目標とする主要なキーワードを選ぶとかそういう場合にも、まずは「検索する人が使う言葉」を使って、「検索結果できちんと目にとまる」ことを意識するだけで、比較的大きな改善ができるサイトも多いんじゃないでしょうか。

ヴォラーレ株式会社 土居

おすすめの記事

WordPressって何?という人が読んでも5分で何となく分かる記事

今回はこのブログでもお世話になっているWordPressについて解説します。WordPressって何?という人向けの記事です。

WordPressとは?

WordPressはCMS(Contents Management System)というものの1種です。直訳で「コンテンツ管理システム」です。

通常、Webサイトを作成・公開するためにはHTMLやCSSの知識が必須ですが、WordPressに代表されるCMSを利用すればそのような専門知識などをもっていなくとも文章や画像といったコンテンツさえ準備する事が出来ればWebサイトを作成・公開する事が出来ます。Webの専門知識がない人でもブログなどでWebに記事を公開できるのは、そういう仕組みがあるからですね。

しかし一口にCMSといってもめちゃめちゃ幅広いものです( Google検索「CMS 種類」 )。

そのたくさんあるCMSの中でも特に多くのシェアをもっているのがWordPressなんです。

WordPressが使われる理由

WordPressには他のCMSと比較して以下のような特徴を持っています。

情報が豊富

ユーザが多いので情報が豊富です。WordPressに関する書籍は数え切れないくらい出ていますし、何か困った事が起きてもGoogle検索で大体の事が解決できます。

Webサイトの基本的な構造が作りやすい

トップページが有り、カテゴリページが有り、タグページが有り・・と言った基本的なWebサイトの構造をHTMLをいっさい触らずに作る事ができます。

プラグインが豊富

プラグインというのはWordPressに追加機能を簡単に付与させる事ができる仕組みです。サイトの表示を高速化するものや、サイトのバックアップを助けてくれるものなどたくさんのプラグインが有ります。「こんな機能があったらいいのにな・・・」と思う機能はだいたいプラグインを探せば有ります。

テーマが豊富

テーマはWebサイトの着せ替え機能みたいなものです。記事や画像、カテゴリやタグなどの情報はそのままに、サイトの見た目部分を変更する事が出来ます。

WordPressはテーマを作成して公開、利用する仕組みがよく整えられていて、世界中のデザイナー、デベロッパーが作成した様々なテーマが無料で公開されています(有料のものもあります)。ユーザはそれらを自由に利用する事ができ、自分でテーマを作成して使用する事もできます。

つまるところ、WordPressが多くのシェアを獲得している理由としては、

  • 数あるCMSの中でもすごくポピュラーで情報がたくさんある事
  • HTML、CSSなどの詳しい知識が無くても大丈夫なお手軽さ
  • プラグインやテーマなどが自由に使える拡張性の高さ

というところかなと思います。

WordPressの仕組み

さてここからは、WordPressというCMSが、どのような(技術的な)仕組みで動いているのか?管理画面から投稿した記事や画像が、どのようにWebサイトとして反映されているのか?ということにも触れていきたいと思います。

WordPressのサイトにアクセスしてサイトが表示されるまでの流れ

WordPressでは、ユーザが投稿した記事やそれに対するコメントなどが直接HTMLのファイルを生成する訳ではありません。

WordPressは「PHP」というプログラミング言語で構築されており、コンテンツの管理には「MySQL」というデータベースを利用して、CMSとしての機能を実現しています。

WordPressで作成されたWebサイトにアクセスした時、ブラウザあるいはブラウザの向こう側で一体どういう事が起きているのでしょうか。サイトが表示されるまでのざっくりとした流れは次の通りです。

1. ブラウザはサイトに見たいページの情報を送ります。
2. サーバサイトにアクセスがあるとPHPが動作し、MySQLから記事やコメントなどのデータを取り出してHTMLを生成、送信します。
3. 送信されてきたHTMLを、ブラウザがうまく変換して表示します。

ブラウザがサーバーにアクセスし、PHPがMySQLのデータを参照しHTMLを生成しブラウザに返すという流れ

WordPressを動かすPHPと、データを保存するデータベースが分かれており、連携して1つのページを表示させるというのがポイントです。

コンテンツの管理にデータベースを使う理由

WordPressではコンテンツの管理にデータベースを利用していると説明しました。

このような仕組みを取る事で「コンテンツ」と「Webサイトの器(≒テンプレート)」を別々に管理する事が出来るようになっています。

例えば、MySQLを操作するためのSQL文が書ければデータベース中のコンテンツを一斉に扱う事が出来ますし、HTML、PHP、CSSが書ければ自由なレイアウト、デザインでコンテンツを展開出来ます。

HTMLはPHP、CSSの部分とコンテンツの部分を別に管理しているから、独立してデザインの変更などが行える

また、Webサイトの見た目をテーマによって簡単に切り替える事が出来たり、プラグインによる拡張が容易に行えたりといった機能を提供できるのも、コンテンツ管理にデータベースを利用しているおかげです。

コンテンツをデータベース化し、表示をプログラムで作るという仕組みがWordPressの汎用性、拡張性の高さを支えているのです。

SEOから見るWordPress

WordPress自体にSEO効果があるという情報をよく見ますが、それは正しいと言える側面もある一方、捉え方次第では誤解を招きそうなので、SEOに関することも最後に解説しておきます。

別にWordPressを使ったからといってSEO効果があるわけではない

SEOとは「Webサイトが検索エンジンから正しい評価を受ける事が出来るように最適化する事」です。SEOを正しく行う事でWebサイトはその存在を正しく検索エンジンに理解・評価してもらう事が出来ます。そうする事でWebサイトは適切なキーワードにおける適切な順位に登場する事が出来るようになるのです。

ですので、WordPressを使ったからといってそのサイトが検索結果のより上位に表示されるかというと、そんな事はありません。それを踏まえた上で、WordPressはSEOとどういった相性にあるのか考えてみます。

SEOを行うには都合が良いという点はある

WordPressを使っただけでSEO的に何か効果があるかといえば全くそんな事は無いという話は先にしました。ただし、SEOを行う上で都合が良い点はあると言えます。

例えばプラグインを使って簡単に記事毎のmetaディスクリプションやキーワードを設定出来たり、カテゴリ、タグ構造を用いた内部リンクの調整やアイキャッチ画像の設定がやりやすかったりと、サイト訪問者がサイト内を迂回してくれるような仕組みが作りやすかったりします。

つまり、WordPressそれ自体にSEO効果は無いですが、SEOを比較的やりやすいのがWordPressだ、という認識で良いと思います。

全体まとめ

まとめると、

  • WordPressは最も使われているCMS(コンテンツ管理システム)の1つ
  • WordPressは文章やコメント、画像などのオリジナルなコンテンツと、サイトそのものの構造や見た目を切り分けて管理できる。
  • だから、コンテンツをそのままにサイトの構造やデザインを容易に調整できる。
  • 情報の豊富さ、ユーザの多さからWordPressにまつわる大体の事がググればなんとかなる。
  • WordPress使えばSEOばっちりかと言えばそんな事無い。
  • ただし構造の変えやすさ、SEOを助けるプラグインの存在などから、SEOはやりやすいと言える

という感じです。どうでしょう。WordPressがどのようなものなのか、ざっくりと伝わったでしょうか?この記事で少しでもWordPressに興味をもっていただけると嬉しいです。

ヴォラーレ株式会社 工藤

おすすめの記事

Webサイト高速化・表示速度改善のために知っておきたい基礎知識

Webサイトを高速化をする事によって得られるメリットは様々あると思いますが、ユーザーエクスペリエンスの改善といった話とは別に、個人的にはサーバの台数が減らせるというのも大きなメリットだと思っています。サーバサイド側のエンジニアとしてはやはりサーバの台数が減ればコストも下がるし、運用も楽になりますので、SEOに関わらず努力したいところではありますね。

しかしながら、「高速化しよう」「表示速度を改善しよう」といっても、実際にどういうところに高速化を阻害するような要因があるのか、ということを知っていなければそもそもどう取り組んで良いか分かるはずもありません。

ということで今回は、技術者の方でなくともサイト高速化のポイントがある程度理解できる(多分)ように、最低限「こんなことがあるのね」というポイントを大まかにまとめてみました。

高速化のための基礎知識

高速化という言葉の中には、大きく分けて2種類の概念が存在します。

  1. フロントエンド側での高速化
  2. サーバサイド(バックエンド)側での高速化

フロントエンドとは

ここで定義したいフロントエンドとは「HTML・CSS・JavaScriptなどの技術」と解釈してください。噛み砕いて言えば、「ページがブラウザに表示される」という部分に関する部分がフロントエンドということです。フロントエンドの領域では、ある程度HTMLが書ける方ならポイントさえつかめれば誰でも高速化する事が可能です。

サーバサイド(バックエンド)とは

サーバサイド(バックエンド)側、というのは文字通りサーバー側での最適化なのですが、状況によって見るべきポイントが異なりますし、ある程度は専門的な知識が求められるので、誰でも簡単に高速化、というのは難しいことも場合と思いますので、今回はいくつかの要素について掻い摘んでお話しようと思います。

フロントエンドの高速化

これに関しては様々な方法があると思いますが、シンプルに考えて以下の3つを注意した上で高速化を行っていけばいいと思います。

  1. サーバーへの通信の回数を減らす
  2. サーバーへの通信量を減らす
  3. レンダリングの速度を低下させない

1.サーバーとの通信の回数を減らす

まず、普段ウェブサイトを表示する時のブラウザの動作を考えてみましょう。ウェブページにアクセスする際には、ブラウザに「http://xxxx.○○.html」などといったURLを入力したり、リンクをクリックしたりすると思いますが、このサイトを開く場合にサーバへのアクセスは何回になるか?

と聞くと、意外に「1回しか通信しない」と思っている人も多いのではないでしょうか。

実は「http://xxxx.○○.html」を開いて中のHTMLを確認するまで、実際に何回サーバーとの通信が発生するかはわかりません。

なぜ開くまでわからないのか?といえば、それはHTML書かれている内容によって通信回数が異なるからです。通信回数はHTMLの中に記述されている、画像、外部CSSファイル、外部Javascriptファイルの数によって変わってきます。

外部ファイル化されたスタイルシート(CSS)やJava Scriptは、都度そのファイルの情報をサーバーから受け取ります。同じく画像ファイルも、都度サーバーから情報を受け取っているため、画像ファイルが多ければ多いほど通信も多く発生しています。ブラウザにキャッシュが残っている場合には、サーバーとの通信は発生せずキャッシュの情報を読み込みます。

単純に考えて画像の数だけ、CSSの数だけ、Javascriptの数だけ通信が発生していまします。
※304を返す場合は通信は発生しません。ステータスコードに関しては「よく見るHTTPステータスコード一覧とその意味を理解する」を参照してもらえればいいのかなと思います。

通信回数が多いということは、その分だけ表示が遅れることにつながりますので、なるべく少ない通信回数で表示が完了できるようにするという事がまず大切です。もちろん、決して「通信を1回に押さえろ」というわけではなく、あくまで無駄な通信をしないということです。

2. サーバーへの通信量を減らす

通信の回数、ではなく「通信量」を減らすということをイメージすると、例えば画像ファイルの容量を減らすことが思い浮かぶ方が多いと思いますが、そういうことです。画像や動画ファイルはファイルサイズがとても大きいので、通信量が増えます。

この点では、本当に基本的な事かもしれませんが、読み込むファイルのサイズを減らすということが重要になります。一番多くのサイトに関係があるのはやはり画像ファイルだと思います。

「これ以上は画質を荒くしたくない」という事情は多々あると思いますので、そんなときは、画質を落とさずにファイルサイズを減らす「画像の最適化」を行います。

通常の画像データにはウェブページとしては不必要なデータが含まれている事があります。それらを排除することで、ファイルサイズを軽くする事が出来ます。画像によっても変わってきますが、相当ファイルサイズが減るのでおすすめです。

最適化する際は専用のソフトウェアがあるので、そちらを使いましょう。

ちなみに、余力があれば、CSSとJavascriptのファイルサイズも少なくした方が良いと思います。もともと、画像に比べたらファイルサイズは小さいのですが、それでも軽量化をするべきだと私はを思います。

ある程度ウェブサイトを長年運用していると、CSSやJavascriptが徐々に追加され、気づいたら容量が増えていたなんてことがあります。また、簡単に軽量化できるので、導入しやすさもあります。

ただし、不必要なJavascriptやCSSは削除してしまえばいいんじゃないの?って思う方もいるかもしれませんが不必要だと思ってたら、必要だったCSSの記述だとか、使っていないと思っていたJavascriptの関数を削除してしまったり…と、もちろん不必要な記述は削除するべきですが、現実的にはなかなか難しいと思います。

そんなときは「ファイルの圧縮」を行います。不必要な空白や改行を削ってCSSファイルや、Javascriptファイルを軽量化する手法です。

もちろんエディタ等の置換機能を駆使して、消していく事もできますが、何千行なんてCSSやJavascriptファイルだった場合はとても大変なので自動で変換してくれる便利なツールがたくさんあるのでそちらを使いましょう。

3.レンダリング(≒HTML解析~ブラウザ表示)の速度を低下させない

ブラウザの表示速度を遅くしてしまう要因は通信だけではありません。HTMLの記述のしかた一つでブラウザの表示速度も下がってしまう場合もあります。

例えば一昔前はよくJavascriptをheadタグのなかに記述している事が多かったと思いますが、最近ではbodyの閉じタグの直前に記述するのが主流です。(ただし、Google アナリティクスの計測用コードなどはhead内に記述したほうがより正確な計測が出来るといった事情もあるように、必ず・全てということではありません。)

headタグ内への記述を推奨されない理由は、ブラウザの表示速度が低下してしまうからです。たとえばheadの中に外部Javascriptの読み込みがあると、その時点でJavascriptの読み込み、実行がされてしまいます。その間ブラウザは表示に関する処理は止まってしまうので、ユーザーに取ってはその分表示されるのが遅く感じてしまいます。

headタグ内にJSのタグが存在すると、これらのスクリプトが先に処理、実行される。bodyタグ内のコンテンツの表示はJSの処理が完了してから行われるため、<br />
				体感として表示が遅くなってしまう。

そこで、先にブラウザに表示できるものを表示させて、あとからJavascriptの処理をさせるという順序にすれば、体感的にユーザーに遅さを感じさせないようにすることができます。

body閉じタグ直前にコードが入っていれば、コンテンツの表示が完了してからその処理が実行されるため、その分ユーザーの体感速度は改善する。

もちろん1つ2つの処理であればそこまで影響が出ることは無いと思いますが、大量にJavascriptファイルがある場合などは大きな影響が出る可能性があります。

サーバサイド(バックエンド)側での高速化

さて、ここからは簡単にサーバサイド側の高速化の話を軽く触れていきたいと思います。どうしても技術よりの話題になりますので普段全く技術に関わらない方はナナメ読みで良いと思います。

サーバサイドは本当に様々な条件によって変わってきますので、状況によって高速化の手法はバラバラです。Ruby、Python、NodeJS、Perl、Java、PHPなどプログラミング言語によってももちろん違いますし、BtoCなウェブアプリケーション、BtoBなアプリケーションなど、ターゲットによっても変わります。また、サーバのスペックなどによっても変わってしまいます。非常に複雑で、ある程度以上の専門的な知識が必須になります。

とは言っても、高速化に関してサーバサイドで重要な事は、突き詰めていけばたった一つだけ。「ブラウザに返すレスポンスの速度を上げる」ということです。

特に速度が遅くなりやすい部分、アプリケーションによるデータベースの扱い方について私が意識的に注意している部分に関して簡単に掻い摘んで説明します。

使わなくてよい物はDBを使わない

Webアプリケーションではほとんどの場合、何かしらのデータベースが使われています。データベースは非常に強力なソフトウェア(ミドルウェア)ですが、アプリケーションから使い方を間違えると速度の低下につながります。

ついつい、データベースで何でも管理したくなってしまいがちですが、データベースに入れなくていいデータを入れるのはやめましょう。特にセッションデータをデータベースに入れているケースをたまに見かけますが、なるべく控えたほうがいいです。

このセッションデータと呼ばれる物は、ユーザーがアクセスする度にデータを取得して、更新して書き込むということが発生します。リクエストが発生する度に、データベースへの書き込み処理、読み込み処理が発生してしまうので、データベースに不要な負荷を与えてしまいます。

キャッシュを活用する

当たり前の事かもしれませんが、データベースは呼ばれれば呼ばれるほど、速度が低下します。小さい事かもしれませんが、比較的変更の少ない固定されているデータ「商品マスタ」「ユーザー情報」などはキャッシュしておくべきです。ユーザー数やアクセス数が多いサービスにはかなり有効な方法です。

※ただし、キャッシュを多様しすぎると、正しくないデータがブラウザに表示されてしまうなんて事もあるので使用する際は注意してください。

実行しているSQLの最適化

データベースを使う場合に、本当に最適なデータベースの使い方をしているのか見直しましょう。データを取得する際にSQLを使用しますが、その際に実行されているSQLが意図としたSQLになっているのか?見直してみると無駄がある事も多いので、ここは慎重に確認するべきです。

データベースのインデックスの見直し

データベースの高速化の技術の一つにインデックスという物が存在します。本で言うところの「索引」と同じような物ですが、このインデックスの設定の仕方で速度が何倍も変わってきます。

良いインデックスというのはデータベースの設計やアプリケーションによって変わってきますが、インデックスがしっかり使われているかを確認しましょう。

非同期処理でデータを保存する

データベースにデータを保存する際に、「保存しました」というレスポンスをデータベースから帰って来るのを待っていると速度が遅くなってしまいます。書き込む量が多くなれば多くなるほど速度は遅くなってしまいます。

大切なデータに関しては同期的に対応するべきですが、そこまで重要じゃないデータに関しては非同期で保存するという方法は有効です。

不必要なデータは保存しない

データベースはデータ量が多くなれば多くなるほど、速度が低下してしまいます。不必要なデータを保存するのは避けた方がいいです。

分割を意識した設計

データ量が多くなってしまうデータベースでは、データベースやテーブルが分割されても大丈夫なような設計をするべきです。

、、など、見るべきポイント、高速化を阻害する要因というのは様々あります。

まとめ

ウェブサイトの高速化というと例えば「CSSスプライトを使いましょう!」などのフロントエンド寄りの話が話題になりやすいですが、こういったサーバサイドでもしっかりと対応するために、どの程度のユーザーが使うのか、どの程度の規模のサービスなのか?といったあたりも意識しながらウェブサイトを設計・構築することが重要です。

サイトの高速化について大まかに掻い摘んで書きましたが、まだまだやらなければ行けない事はたくさんあります。今回紹介したポイントを意識して最適化することにより、確実に高速化できるのではないでしょうか。

ヴォラーレ株式会社 望月

おすすめの記事

自社メディアを事例としたSEOセミナー開催のお知らせ+過去に開催したセミナーの開催報告

ここのところ更新を完全にサボっておりましたが丁度良い話題として久々にセミナー告知させて頂ければと思っております。

ApplivのこれまでのSEOや現状についてゴリゴリお話します

昨年リリースした自社サービス「Appliv」がちょうど運用歴1年となりましたので、これまでのSEOへの取り組み方や、その経過報告などをしたいと思っています。トラフィックデータの公開とかは積極的に行いますのでそれだけでもそれなりに面白いと思います。

詳細:ヴォラーレSEOセミナー「広告を一切使わず1年で700万PVのメディアを作る方法」

ここでも補足で概要をご案内しておきますと、Applivは、簡単に言えばiPhoneアプリやiPadアプリを探すためのサイトです。本家のApp Storeさんやアプリレビューサイトの代表格のAppBankさんなどに比べて「ジャンル・目的でアプリを探す」ことに特化したメディアです。

ちなみに1年で700万PVてどうなのという声もあると思いますが、少なくともたくさんのPVを集めること自体を目的として運営しているサイトではありませんのでそこの数字自体はオマケで捉えて頂ければと思います。

どなたかが何かの記事で「メディアは1000万PVを超えてようやく中堅、1億PVを超えるとブランドに」というお話をされてたのですが(ソースを見つけられません、、ご存知の方いましたらお知らせ頂けると幸いです。)そういう意味で現状のApplivはまだまだ人間で言えば思春期に入る前くらいの段階だと思います。

2013年のオーガニック流入はこんな感じで推移しています。

当日お話するのはPV集めのテクニックではなくてあくまでこのサイトがどのようにSEOを行いどのような結果に至っているか、という情報を参加者の方に共有する目的が主となります。

今回は自社サイトの具体的なデータまで開示しますので珍しく有料とさせて頂けますが、他のサイトが1年間どのようなことを行ってきたのかということをお話しますので相応の価値はあると思っています。というか出せるように頑張ります。

詳細・申込はこちらから:http://www.seohacks.net/seminar/201309/

過去のセミナー開催のご報告

こちらもそういえば毎月ご報告します、というお話でしたが全然していなかったですね。基本的にはSEOセミナーは今も毎月開催していまして、こちらの過去の開催分についても簡単にまとめさせて頂きます。

8月:解除事例から見る 最新被リンクペナルティ解除対処法

開催:8月23日(金) 講師:實川  セミナー詳細はこちら

2012年以降、ペナルティ解除やリンク否認ツール、再審査リクエストなどに関連する話題は日常的に見るようになりましたが、Google側の対応含めてその内容はかなりの速度で変化をしてきています。最近では手動対策ビューアの登場などで色々と戸惑った方も多かったと思います。

今回のセミナーでは、8つの事例を元に、再審査リクエストのドキュメント作成例や、否認ツールの効果の有無、警告メッセージ受領→ペナルティ解除までの順位推移事例などについてお話させて頂きました。

リンクペナルティ関連のに関しては状況が順次変わっているものですので何ヶ月かに一度は今後も開催していきます。

過去の開催レポート:「ペナルティ解除はやるべきことを着実に、ただひたすらに泥臭く」
関連記事1:不自然リンクによるGoogleペナルティ解除事例 (基礎編)
関連記事2:不自然リンクペナルティ・再審査リクエスト絡みの質問を20個集めて汎用的かつ無難なQ&A集を作ってみた

7月:一から学べるSEO基礎セミナー

開催:7月26日(金) 講師:山田  セミナー詳細はこちら

内容としては久しぶりに超基礎に絞ったセミナーでしたので内容は割愛しますが、これまでのセミナーの中では圧倒的な自由度を表現できたセミナーだったのではないかと評価しています。

少しばかりスライドの一部をご紹介しておきます。




6月:キーワード選定プロセスを学ぶ

開催:6月21日(金) 講師:土居  セミナー詳細はこちら

珍しく(やったことなかった話題だったので)キーワード選定に関する内容でお話しました。

こちらはまとめようと思ったらkenjieeen’s blog様が内容を簡潔にまとめて頂いておりましたので、こちらをご紹介するに留めることとします。ご紹介有難うございます。

まとめ:セミナー@ヴォラーレ(キーワード選定編)

5月:Webサイト設計に関わるセミナー

開催:5月24日(金) 講師:土居  セミナー詳細はこちら

こちらについては4月に行いましたセミナーと同じ内容となります。4月に比較的多くの方から嬉しいFBを頂きましたので(省エネも兼ねて)第二回目を行わせて頂きました。

実況:ヴォラーレ:Webサイト設計に関わる無料SEOセミナー セルフまとめもいいとこ
開催報告:理解していれば回避できるはずの問題は予め回避しておくが吉
まとめて頂きました:Web制作・開発に関わる方が知っておくべきSEO設計ポイントまとめ

最後に:セミナーの反響からみるSEOの需要

毎月色んなテーマでセミナーやっていますが、テーマ毎に反響は全然違いますね(その時の集客への力の入れ具合にも寄るのかもしれませんが)。

  • リンクペナルティとか再審査リクエストに関する話題
  • Webの設計、コンテンツなど内部施策に関する話題
  • ペンギンアップデートとかパンダアップデートみたいな話題

やはりこうしたものが安定して需要があるみたいです。どの回もFacebookやTwitterでの簡単な告知と、最低限のリターゲティング広告での集客ですが、例えばキーワードの話題とか超基礎とかよりも上記のものの方が全然集客で勢いが違うなあと思っています。

今後も定期的にセミナーは開催させて頂きますのでよろしくお願い致します。

ヴォラーレ株式会社 土居

おすすめの記事

2013.4.26 SEOセミナー開催レポート:「理解していれば回避できるはずの問題は予め回避しておくが吉」

さて、最近セミナー報告ばかりになりつつある当ブログですが、今回は4月26日(金)に開催しました制作や開発に関わる方向けのSEOセミナーのレポートです。前回と同じくtwitterで内容お伝えしていたのでそれもまとめてあります。

twitterまとめ:Webサイト設計に関わる無料SEOセミナー セルフまとめもいいとこ

4月26日に開催されたセミナーの風景

今回はマーケティングとかリンクとかコンテンツとか検索エンジンアルゴリズムといった話題にはあまり触れず、Webサイトの設計・制作にあたりどういったことを予め考慮しておかなければならないのか、という内容で予定では120分のところ150分くらいに渡りお伝えしました。

諸注意として予めお伝えしたこと

本題の前に皆さんに事前にお伝えしたこととして、

  • 検索エンジンが評価したいのはコンテンツ&リンク
  • 検索エンジンは「正しく作られたWebサイト」を評価したいのではない
  • 正しく作られたWebサイト≠高く評価されるWebサイト

というのがまず原則としてあります。ですので、ここではあくまでSEOの観点から、という話にしますが、例えば実際にHTMLのマークアップを行う方がいくらそれらを美しく記述したところで、それ自体はSEOの完成ではなく、むしろSEOを行う土台を整える作業のうちのごく僅かな要素の一つ、というところでしかありません。

しかし、それでも尚、「(ある程度)検索エンジンを考慮してサイトを作る」ということはとても重要なものであるという認識でおり、サイト規模が大きくなる、とか長きに渡ってコンテンツを配信していく、というサイトであればあるほど、運用に入る前、設計の段階でどこまでSEOが考慮されたか、によって運用後の検索トラフィックには大きな差が出ます。

「クローラーの仕組みやランク付けアルゴリズムを研究して完璧なSEO設計をする」とかそういうことではなく、ある種の「普通に回避できるはずだった問題」を予め回避することが出来るのであれば、それは事前に対処して回避しておくのが吉じゃないですか(実際には、普通に回避できるはずだった問題点を回避できてなくて色々損してるケースがあまりに多く勿体ない)、ということが今回の本旨です。

セミナーコンテンツ

詳細はボリュームが多いので(スライド150枚以上)概要をラインナップとして並べます。

150枚以上のスライドを小さく並べてみた
※実際のプレゼンで使用したスライド一覧

1.検索エンジンの基礎知識

今回はかなりサラッと流しましたが、これはどの回でも必ず行います。最低限、裏でどんなものがどのように、何のために動いているのかは理解しておかないとその先の話が通じなくなってしまいます。

  • 検索エンジンの仕組み
  • 検索エンジンの収益モデル
  • 検索結果が返されるプロセス

2.企業がSEOに取り組む意義と得られるもの

今回はメインの話題がサイトの作り方の部分だったりもするのでここも流してしまいましたが、目的と手段を混同しないように、ということと、最終的にどのようにSEOを通じて検索トラフィックが獲得されるのか、ということに簡単に解説しました。

  • 企業がSEOを行うメリット
  • SEOのWebプロモーション上の特性
  • SEOの運用と目標達成までのプロセス

3.SEOの取り組み内容とその分類

例えば内部対策と外部対策とか、コンテンツとリンクとか、ユーザビリティとクローラビリティとか、まあ色んな確度からそれぞれの要素が様々分類されて対比されます。まずはどういう要素がSEOには存在していて、それぞれがどういう分類をされるのか、みたいなことをかなりザックリまとめてお話しました。

  • 機械(検索エンジン)を考慮したサイト設計
  • キーワード/コンテンツ/リンク
  • 制作・開発担当者が直接SEOに貢献できる事
  • 内部と外部 / 機械と人間

4.制作者が行えるSEO

メインはこの部分です。事例を交えて、サイトのデザインや機能の実装にあたり最低限、少なくとも知っておかれたい、或いは気にされたい部分を約100枚くらいのスライドで駆け足で解説しました。

限られた時間の中で、なのでこういうお話を新情報として聞かれる方もいらっしゃったと思いますが、もちろんボリューム的には一つ一つについて網羅できるはずもないので、まずは「なるほど、こういうことも気にしておかないといけないのね」ということだけでも理解して頂ければ良いかなとは思っています。

  • 検索キーワードと流入口ページの確保
  • テキスト情報の独自性の担保
  • 重複コンテンツ問題
  • クロール・インデックス
  • ページレイアウト
  • サイトの速度

まとめ

今回お話した内容は、一つ一つの項目としては取り立てて珍しい話ではないというかごく基本的なことの確認、おさらいのような感じでしたが、しかし基本的であることと皆さんがそれを満遍なく理解しているということはイコールではありません。

実際に、少なくとも全体から見れば一部を除いた多くのWebサイトは、SEOに適しているとはとてもではないが言い難い、というような作り方をされていると思います。

少なくとも、HTML構文チェックで100点を目指すこと自体のSEO的な価値というのはほぼ皆無だと思っておりますが、そういう類の「最適化」を求めるのではなく、最低限、作成するコンテンツの内容や得られたリンクが漏れ無く無駄なく評価される、ということがSEOの前提ですので、こうした認識は、Webの制作や運用に関わる皆さんにやはり最低限以上は知っておいて頂きたいなと感じる所存です。

次回開催のお知らせ

アンケートやTwitter上での反響は割と良かった方だったので、僕個人の省エネも兼ねて5月にもう一度同じ内容のセミナーをすることになりました。

詳細:Web制作・開発に関わる方向けのSEO設計基礎セミナー(第二回)

Web制作会社の方や社内のWeb担当者の方をメインターゲットとしていますが、マーケティング担当者の方とかまあ色々要は基本的にはご興味がありましたらご参加頂ければと思います。

当日は事前に簡単なレジュメ(?)をお配りして、プレゼン資料とかは終了後にお持ち帰り頂けるようにしていますが、今回は資料印刷ミスりました。細かな誤字チェックとかは複数人でやったのにも関わらず表題だけが作成当初のまんまになってました。

Web制作者が知っておきたい基礎SEO設計セミナー(仮) で印刷しました
※内容は本番でした。

ということで5月のセミナーも告知前からちらほらと参加お申込み頂いている企業様もいらっしゃり大変有難い状況ではありますが、今後のセミナーも機会とご興味とお時間ありましたら是非ご参加下さい。

ヴォラーレ株式会社 土居

おすすめの記事

よく見るHTTPステータスコード一覧とその意味を理解する

404や503、301・302など「ステータスコード」とか言われるものをよく見るけど実はその意味はよく分かっていません、という方は意外に多いんじゃないかなと思ったので、よく見るものを一覧でまとめて解説してみました。このあたりの話題にそこまで詳しくない方でなくとも理解できるように解説しているつもりです。

Webブラウザやクローラーが情報を受け取る仕組み

私たちは普段、FireFoxやChrome、SafariなどのWebブラウザを通じてURLにアクセスしてWebコンテンツを閲覧しています。この「URLにアクセスする」ときに、Webブラウザは「リクエスト」を送り、Webサーバーが「レスポンス」を返す、というやり取り(通信)が行われています。

ブラウザからリクエスト(URL)を送り、サーバーからレスポンスが返される図

リクエストを送る側は、「サーバー(提供者)」に対して「クライアント(依頼者)」と呼ばれます。Googleのような検索エンジンのクローラーもブラウザと同じくクライアントという扱いになります。

HTTPステータスコードとは?

WebブラウザやクローラーがURLにアクセスしようとするとWebサーバーからどのようなレスポンスを受け取っているのか?というのは例えばGoogleのウェブマスターツールの基本機能「Fetch as Google」などを使って知ることができます。
※図の中の赤枠以下の情報を受け取っています。

ウェブマスターツール Fetch as Google を使用してGoogleBotが受け取ったデータが表示。ステータスライン、メタ情報、ボディメッセージを受け取っている。

少し見づらいですが、通常通りアクセスできてコンテンツの情報が得られる場合にはブラウザやクローラーはこのようなデータをWebサーバーから受け取っています。

ここで少しだけ專門用語を使うと、上の図にあるようなレスポンスは「ステータスライン」「レスポンスヘッダ」「メッセージボディ」の3つから成っています。
上からステータスライン、メタ情報(データに付随する情報)、ボディメッセージ(この場合はHTMLテキスト)という具合でデータを受け取っている

レスポンスヘッダとメッセージボディについては今回本題から外れますが、折角ですので合わせて簡単に解説します。

ステータスライン

ステータスラインは一番上に記述されている「HTTP/1.1 200 OK」や「HTTP/1.1 301 Moved Permanently」等のようなもので、「レスポンスの状態」を表します。この中の「200」や「301」といった3桁の数字が今回の話題となる「ステータスコード」です。「OK」「Moved Permanently」は「説明句」というもので、その名の通りステータスコードの内容説明をするものです。

HTTP/1.1 は「通信規約とそのバージョン」 200 はステータスコード OK は説明句

クライアント(WebブラウザやGoogleBot)はWebサーバからどのステータスコードが返ってきたかによって、その中身を見なくとも次にどんな処理を行えばよいかを判断することができます。

レスポンスヘッダ

レスポンスに付与するメタ情報が記載されている部分です。ここでいうメタ情報とは、「(受け取った)データに関する補足情報」のようなものと思って下さい。例えば、URLが転送(リダイレクト)されている場合に転送先のURLの情報を「Location」として付与する、などの情報です。

メッセージボディ

いわゆる”本文”にあたるもので、Webページに問題なくアクセスできた場合にはHTML情報がここに記載されます。私達が普段見ているWebページはこのHTMLテキストをブラウザが解釈して表示したものです。

さて、本題のHTTPステータスコードについて話を戻します。

HTTPステータスコード

ステータスコードは本来ブラウザやクローラーが処理するために付与されているものなので、普段私達がブラウザ上でWebページを見ている際に見ることはありませんが、時々エラーでこんなのをお目にかかることはありますね。

404 Not Found

503 Service Unavailable

また、Google Chromeに標準搭載されているDeveloper Toolsや、Firefoxのアドオン(Live HTTP headersやFirebug等)を使えばレスポンスに含まれているHTTPステータスコードを確認することができます。今回はその使い方は割愛させていただきますが興味の有る方はお試しください。

それでは次節からは本題であるステータスコードについてお話をさせていただきます。

ステータスコードの大まかな分類と意味

さて、ステータスコードは大まかに分けて5つに分けられます。

  • 100番台 : 処理中
  • 200番台 : 成功
  • 300番台 : リダイレクト
  • 400番台 : クライアントエラー
  • 500番台 : サーバエラー

このようにそれぞれの番台によって異なる意味を持っています。個別のステータスコードの前に、まずここでは各番台について簡単にその意味を説明しておきます。

100番台

100番台はクライアントからのリクエストを処理中であることを示すステータスです。

Webサーバ側からクライアント側に対して「もうちょっと詳しくやってほしいことを教えてくれ」とか「今、頼まれたことをやってるんだけども時間かかるわ」という内容のレスポンスを返します。これらのステータスコードが使われている場面はあまり見かけません。

200番台

200番台はクライアントからのリクエストが受付に成功したというステータスです。私達がWebページを見ているとき、多くが200番のステータスです。

300番台

300番台は「リダイレクト」と書きましたが、厳密には「リクエストを達成するためには、ブラウザ側で追加の処理を実行する必要がある」というステータスです。

その追加の処理が301では例えば「別URLへの移動」になります。301番、302番のコードについては「301リダイレクト」「302リダイレクト」などサイトURL変更の際の転送処理として聞いたことのある方が多いのではないでしょうか。

400番台・500番台

400番台、500番台のコードはエラーコードであり、正常にリクエストされたものが返せない状態のときに使用されます。そのうち400番台はクライアント側に原因があるエラー、500番台はWebサーバ側が原因のエラーです。

それぞれのステータスコードについて

ここまででざっくりとした分類をお話ししたので、本節ではそれぞれのステータスコードについてお話します。今回は普段の業務を行う中で比較的頻繁に目にすることの多いメジャーなものに絞りたいと思います。

200 OK

リクエストは問題なく受理され、要求に従ったレスポンスが返されます。私達がWebページを正常に閲覧している際、大抵このステータスとともに返ってきたレスポンスの内容を見ています。

200はそのまま「OK、問題ありません」の意味

301 Moved Permanently

リクエストで要求された情報の中身が別の場所に移動したことを示します。

この移動は一時的なものではなく、恒久的なものです。サイトの引越しを行ったりしてアクセスするURLが変更され、ずっとそのURLを使用していく場合にこのステータスコードを返すようにしておく必要があります。

301は恒久的な転送、つまり「引っ越したよ」の意味。

googleからの評価を新しいURLに引き継がせるためにも301を設定しておきましょう。また、あるページへのアクセス経路を一本にまとめる、いわゆるサイトの正規化を行う場合にもこの301リダイレクトを使用します。

302 Found (※Moved Temporarily)

こちらもリクエストで要求された情報の中身が別の場所に移動したことを示します。301と異なるのは、その移動が一時的なものであるという点です。

302は「今ここにいないよ、そのうち戻ってくるよ」の意味

たとえばメンテナンス等で一時的にサイトを別の場所に移さなければならないが、また元の場所に戻す場合はこの302番のステータスを返すように設定しておきましょう。GoogleBotもそれが一時的な移動であることを読み取ってサイトの評価を移動先のURLに移すことはしません。

※302は昔の規格(HTTP/1.0)では説明句が「Moved Temporarily」でしたが現行の規格(HTTP/1.1)になって「Found」に変更されました。一時的な転送、という以外でも利用されることが多かったためのようで、現在別の307という比較的マイナーなステータスコードで「Temporary Redirect」が割り振られていますが、実際の使用例は見たことはありません。

304 Not Modified

これはリダイレクトではありませんが、補足的に説明をしておきます。

304は「未更新」を表します。私達が正常にWebページを見れているとき、多くは200ステータスが返ってきているのですが、実際には304ステータスのコンテンツが混じっていることもあります。このときWebサーバからはメッセージボディ、つまりコンテンツが返ってきません。ブラウザ側では304を受け取ると、ブラウザ内のキャッシュに残っているコンテンツを使ってWebページを表示しています。

ステータスコード304は「前に渡したのと同じだよ」という意味

403 Forbidden

サーバ側で外から見えないように設定してある領域へのアクセスをリクエストしたときに返ってくるステータスコードです。簡単に言えば立ち入り禁止です。

403は立入禁止の意味。

見せたいページでこのエラーが出ているときはアクセス制御の設定が間違っている可能性がありますので設定ができる方は確認してみましょう。

404 Not Found

リクエストしたページが見つからない場合に返されるステータスコードです。

404はそのまま「探したけど見つかりませんでした」の意味

ウェブマスターツールではGoogleBotが検出した404エラーをレポートしてくれていますが、特に404エラーが多いからといってgoogleからのサイトの評価が下がることはないと言われています。サイト内からリンクされているページが404エラーになっている(=リンク切れ)のは問題ですが、そうでない限りは放置しても良いかと思います。

他サイトから多くのリンクを受けているようなページを404エラーとしてしまうと、折角サイトが得られた被リンクの恩恵を逃してしまうことになります。何かしら代替のコンテンツを用意してそのページを残しておくか、近い内容を持つページに301リダイレクトするなどでリンク資産をサイト内に残せる処理をするのが一般的です。

410 Gone

404と同じくリクエストしたページが見つからない場合に返されるステータスコードです。404と違う点は、そのリクエスト先のページが「消滅した」という意味合いがあることです。

410は「前あったけどもう無いんだよね」の意味。

こちらの記事によると最近はGoogleBotは404と410を微妙に区別しているとのことですが、記事でも書いてあるようにそこまで神経質になる必要はほとんどないと思います。

補足:ソフト404エラー

ブラウザ上ではそのページが存在しない旨のメッセージが表示されているにも関わらず、ステータスコードとしては404や410を返していない(つまり正常なレスポンスとして「200 OK」が返されている)パターンが存在します。これを「ソフト404エラー」などと呼びます。

ソフト404はサーバーは「OK」と返しているのにユーザーには「無い」に見えている状態

どういうときに発生するかというと、例えばサイト運営側で独自にエラーメッセージ表示用のコンテンツを作成して、想定していないURLに対してリダイレクトをかけてそのコンテンツに飛ばすというケースが考えられるでしょうか。

Webページを見ているユーザに対してページがないことが伝わっても、機械的にHTTPステータスコードを読み取るbotに対しては伝わりません。このようなソフト404ページが存在するとGoogleBotがクロールのリソースを無駄に消費することになりますので、存在しないページにアクセスしたときはステータスコードとして404もしくは410が返されるように正しく設定するべきです。

500 Internal Server Error

サーバ側の何らかのミスによってリクエストに応えられない場合です。例えばシステム開発中にバグを混入させてしまうとこのエラーを起こすことがあります。

500は「サーバー内部の調子が悪い」のエラーの意味

503 Service Unavailable

Webサーバの過負荷状態で一時的にWebページが表示できないときなどに発生します。例えばTwitterがクジラを表示させている状態、とでも言えばイメージが沸きやすいでしょうか。

twitterが混雑してるとくじらが出ます。

メンテナンスでサービスをストップさせている際に意図的に503を返すように設定することもありますが、基本的にはサーバー負荷の問題ですので頻発するようであれば、サーバーの変更を検討するか、サイト側での負荷軽減などの手を打つ必要があります。

503は「今忙しいから後にして」の意味。

まとめ

ここまでHTTPステータスコードについてのお話をさせていただきましたがいかがでしたでしょうか。表には出てこない部分ではありますが、こうした部分まで意識してみることができれば、今よりもクローラにとって優しいサイトが作れるかもしれません。

特に一般の方(技術に関わりのない方)にとってはこうした話というのはあまり重要視されにくい話題と思いますが、SEOの観点では、サイトが検索エンジンに正常にクロールされ、正しく検索インデックスに登録してもらえるための基本的な作法として、サイトを制作・管理する方には皆さまに理解していただけると嬉しいです。

文責:ヴォラーレ株式会社 西村

おすすめの記事

2013.2.26 SEOセミナー開催レポート:「基礎と累積の2軸で考え、まずはスタートラインに立つ」

先の2月26日、弊社主催の無料SEOセミナーを開催させて頂きました。スピーカーの實川自身は今回が初となるセミナーでしたが、アンケートではなかなかの高評価を頂いておりました。ご参加頂いた皆様、大変お忙しい中ご足労下さり、誠に有難うございました。

セミナー風景、写真

今回のセミナーでは、SEOの基本である内部対策、外部対策やその考え方について、基本的な部分を中心に90分弱お話させて頂きました。概要を以下にレポートとしてまとめます。

1.SEOをとりまく環境の変化とその背景
2.SEOの考え方と取り組み方
3.具体的に何をすれば良いの
4.まとめ

SEOをとりまく環境の変化とその背景

SEOをとりまく環境

ここ最近の低品質外部リンクの淘汰や各種アルゴリズムアップデートを経て、これまで多くの企業(SEO会社を)がSEOの中で目指してきたベクトルと、検索エンジンが向かうベクトルに差異があることが結果として露呈するようになりました。

・企業の目標
色んなキーワードで上位表示して、自然検索経由の流入を増やしたい。

・検索エンジンの目標
検索サービスとしての価値を向上し、検索ユーザー数を維持、拡大したい。

企業としては最終的には売上・業績を伸ばすことを目的に、ウェブサイトへのトラフィックを増やす一つの手段としてSEOに取り組み、ゴールを見据えた目標設定をします。

しかし検索エンジンとしては、ユーザーの「検索して情報を見つける」という一連の行為の満足度を向上させることができるような検索結果を返せるようにする、ことがまず前提としてあり、この視点が欠落した施策が逆効果、裏目に出たり効果が薄れてきたりしている、という背景があります。

検索エンジンの変化

例えば外部リンクが検索順位に大きく影響するため「リンクを購入する」という考え方があります。しかし検索エンジンは昔よりもはるかに精度が向上していますので、リンクを貼れば順位が上がる時代から、少し間違えばそうしたリンクが原因となってサイトへの評価が思い切り下げられるような時代へと変化しました。

Googleが不正リンクを使ったランキング操作の抑制や、低品質なウェブサイト(中身がない、コピーサイト、重複するコンテンツなど)を検索結果から除外するための動きが、最近では過去に比べより活発になり、そうした施策に対するSEOのリスク、特にそうした施策にばかり依存したSEOを行うことのリスクが顕在化してきています。

※筆者補足※
一方で仮に有料リンク、人工リンクだったとしてもその累積によりウェブサイトへのアクセスや売上が一定量担保出来ている場合だと、すぐにその状況から脱却する(つまりそうした恩恵を破棄して、やり方を一新する)、といった選択肢を取ることも企業的な諸事情により難しいケースが多いのもまた事実と思います。

つまり「わかっちゃいるんだけど、さあどうしたもんかね」という状態にある方が比較的多いのではないかな、ということですね。

そうした中、今後は、一気には難しいけど徐々にそういう方向にシフトしていく流れが今後も加速していくでしょう、ということと、問題提起されている人工リンク施策については次第に衰えていくもののしばらくは健在で、リンク提供型のSEOサービスに対しても一定量の需要が引き続き残るでしょう、とは思っていますし、多分これが多くのSEO関係者の共通認識だと思います。そのことの是非については特に触れませんが、基本的にはそういうことだと思っています。

SEOの考え方と取り組み方

このような状況において、今後どうやってサイト運営に取り組めば良いのでしょうか。「人工的なリンク施策に頼るは怖いからコンテンツをとにかく増やそう」というような考え方はもちろん良いのですが、そうは言っても時間や労力、場合によってはお金がかかるお話ですのですぐ行動!とする前に一旦落ち着いて考えてみる必要があるのではないでしょうか。

SEOを2つの軸で考える

今回のセミナーでは、SEOを行う上で考えるべき軸を大まかに以下の2軸として解説していました。

縦軸にリンクやコンテンツ(累積資産)、横軸にサイト設計(基礎)、のグラフ

①累積する資産:コンテンツやリンク

  • ユーザーがサイトを訪れる理由になる(コンテンツ)
  • 独自の資産となり、競合優位性を築く
  • 結果が出るまでには大抵それなりの時間がかかるしその覚悟が必要
  • 成功すれば、無料の検索トラフィックが安定して獲得できる
  • 基本的には終わりがない取り組み

②基礎となる土台:サイト設計

  • 累積したコンテンツやリンクを適切に認識、評価させる
  • 初歩的なWeb/SEO知識でもある程度改善できる
  • ちょっとした改善で大きな効果があることもある。(逆も然り。)
  • 応用的な改善は非常に難しいし高い専門知識が必要

以上を踏まえ、少しばかり乱暴な分類ではあるかもしれませんが、以下のようなマトリックスでウェブサイトのSEOを考えてみると整理しやすいのではないでしょうか。(セミナーの前後の細かい文脈は割愛しますのでセミナー時資料とは若干修正入れています)

先ほどのグラフを用いて 左上:コンテンツやリンクはあるが設計に難あり、 右上:コンテンツやリンクが十分で設計もよく出来ている、 右下:設計に問題はないがコンテンツやリンクは乏しい、左下:コンテンツもリンクも設計もダメダメ の分類をしているマトリックス図

縦軸をコンテンツやリンクの軸、横軸をサイト設計の軸として、右上に行けば行くほどSEOとしては優れていて、左下のような状態(基本的な最適化も出来ていなければコンテンツもリンクも乏しい)は当然優れたSEOには程遠い、というイメージです。

SEOに優れたサイトにするためには縦軸、横軸どちらか一方だけ優れていれば良い、というわけではなく、どちらも基本的なことはしっかり出来ていなければ継続的にSEOに取り組んだとて、十分な結果を得ることは難しいということですね。

ですので次の図のように自社のサイトがマトリックスの右下枠に該当するのであれば、細かなチューニングにこだわるのではなく、コンテンツを見直したり増やしながらリンクを獲得していく必要がありますし、左上枠に該当する場合は、闇雲にそのまま突っ走るのではなく、改めてSEO設計を見直すことでコンテンツやリンクの評価を正しく受けることができるようになります。

先ほどの図でマトリックスの左下から左上枠に向かって改善を図ろうとしている図:「適切に評価されるための土台が整っていないのにひたすらコンテンツやリンクを増やす」

マトリックスの左下から右下枠に向かって改善を図ろうとする図:「コンテンツやリンクが乏しいのに細かなサイトチューニングばかりこだわろうとする」

優れたサイトとして検索結果での露出アップを目指すために、何もないところからいきなり完璧を目指すのではなく、まずはスタートラインを目指す、ひとまず「損をしない」ところまでを見据えてSEOに取り組む、というのが今回の一つの主なテーマになります。

マトリックスの中心をスタート地点として、コンテンツやリンクもまずは必要十分なものを揃え、基礎的なSEOを踏まえた実装が出来ているという状態を目指しましょう、という図

具体的に何をすれば良いの

ここから先は、ごく基本的なSEOの内容について概要を説明させて頂きました。このブログの読者の多くの方には改めて解説するようなことではないことも含まれるかもしれませんが、

  • 検索キーワードの考え方や探し方
  • 目標とするSEOキーワード選定の基準
  • コンテンツマップや主要なキーワード
  • キーワードチューニングの考え方と方法
  • クロールやインデックスの仕組み、その制御について
  • 内部リンクのSEO上で考慮するポイント

等について、事例も含めながら少し駆け足で解説しました。今回のセミナーではいずれもごく基本的な事柄でしたので記事ボリュームの関係から詳細についてはここでは割愛させて頂きます。

※筆者補足※
基本的なこととは言っても、本来これら一つ一つの項目でも最低1時間ずつくらいはかけてお話しないといけないくらい、考えることや知らなければいけないことは多いと感じているのですが、一つのセミナーでまとめて語ることはやっぱり難しいです(昔一度トライしましたが2時間半の予定が4時間くらいかかってなお、全然話しきれなかったです)

まとめ

基本的なこと、一般的にこうした方が良い、と言われていることをとにかくやってみる、ということが出来れば、度合いはともあれ基本的にSEOとは一定以上の効果が得られるものです。見る限り、世の中に公開されているウェブサイトの大半は、SEOの基本的なことがキチンと実践できているとは言い難い状態である、というのが現実だと思います。

何か素晴らしいSEOの事例、素晴らしい技術、最新の動向などを知ることもとても大切と思いますが、まずは走り出しの段階で、当たり前にやった方が良いことを当たり前に実践できているか、ということがその後のSEOの成否を大きく左右することにつながると思います。

情報収集される際の注意として、主にリンク関連の話題、「上位表示対策」についての話題などでインターネット上にある情報は玉石混交、かつ内訳は石が大半という印象ですので、情報の取捨選択に自信がない方や相応のリスクを負えない方、そもそもどういうリスクがあるかがよく分からないという方は、何かしらの根拠がない限りはあまり参考にされないほうが今は無難だと思います(SEO関連の書籍につきましても良著とそうでないものは同様に分かれる、という印象です)。

最後に、今後も定期的にSEOセミナーは開催します(直近では3月に別テーマで開催させて頂く予定です)。基本的にはこうした基礎的なセミナーは無料で開催するスタンスですが、夏あたりに少し突っ込んだテーマで有料のセミナーも開催させて頂く予定ですので、その際には改めて告知させて頂きます。

と、今回の記事は比較的堅苦しい感じで終わらせて頂きます。このブログにつきましても、基本的には若いメンバーを中心に(今度こそ)継続的に更新していく予定ですので、引き続きよろしくお願い致します。

文責:ヴォラーレ株式会社 土居

おすすめの記事

SEOではページ数より「情報量」+「充実度」

こういう仕事をしていると、WEBサイトの現状を把握するために何かしらのSEO系の調査ツールを使うことがしばしばあります。そういうツールでは被リンク数、タイトルやmeta情報、インデックス数、など様々な数値がまとめて見られるため、ぱぱっと概要を把握するには便利です。ただし、そこで得られる表面的な数値を根拠に何かを話すことはあまりありません。

今回はその中でも「ページ数が少ないので増やす」ということに関してたまたまクライアント様から質問を受けましたので記事にしてみます。

巨大なサイトは確かにビッグキーワードでも上位になりやすい

例えば「賃貸」とか「求人」などのいわゆるビッグキーワードと呼ばれるキーワードで検索すれば、ほとんどが有名どころの巨大ポータルサイトなどが上位にあり、ポッと出の10ページそこそこしかないWEBサイトはいないですね。

この事実だけを見ても分かりますが、ページ数が多いということはもちろん重要なことなのです。ただしそれはあくまでも「検索されたキーワードに対してコンテンツ(=中身)が十分にある」という意味で重要なのであって、たくさんページ数があればいいと言うことは全くありません。

むしろ、メインテーマに無関係なコンテンツや中身がスカスカなページの量がサイトの中で大きな比重を占めてくると、今後はマイナスにも作用すると思っていて良いでしょう。そういうサイトは見かけのページ数は多くても充実しているとは言えません。

ページ数・インデックス数は後からついてくるもの

よく「被リンクは後からついてくるものだ」などという議論がなされます。この議論の本意としては「リンクは本来は増やすものではなく増えるものだ」ということです(もちろん狙ってリンクを増やすというテクニックは重要です)。

「ページ数」という指標も結局はコンテンツを充実させていく結果として増えていくものであって、ページ数が多いからエライ、なんていうことは全くありません。検索されたキーワードに呼応するコンテンツがどれだけあるかどうか?がそもそも重要になります。

上位に表示されたWEBサイト=Googleが選ぶ「ベストアンサー」

別のブログのエントリーでGoogleに評価されやすいコンテンツ設計という記事にも書きましたが、検索エンジンから見てどれが最もユーザーを満足させられそうか?がWEBサイトの評価を決めると考えて良いでしょう。

結局は「検索=リクエスト」であり「検索結果=アンサー」である以上、検索結果の上位はベストアンサー群というわけです。当然そのアンサーを選ぶ基準として被リンクというのは非常に重要な要素なわけですが、土台はやはり中身です。キーワードに見合ったコンテンツがあり、それがテーマ毎に分けて整理されていて、検索エンジンにそれぞれ分かりやすいように表現されている、という状態がまずは基本であって、前提になります。

(参考)
インデックス数を増やすことでSEO対策に効果はありますか?

アンサー度とは

薄い100ページよりは中身の詰まった10ページを

まとめになりますが、ただ増やしただけのコンテンツを排除して、本来ベストなアンサーとなるべきコンテンツを上位に残す為にGoogleのアップデート(パンダ・アップデート)も進んでいますし、仮にそれが日本で本格導入された際にそこまでのインパクトを与えられなかったとしても、いずれは濃いページが残り薄いページは排除される方向に進むのは間違いありません。

※画像はイメージです
※画像はイメージです

こういう感じにならないためにもユーザーの期待にこたえるコンテンツを、テーマをぶらさずにできるだけ多く用意しておいた方が良いでしょう。少し具体性のない漠然とした内容に終始してしまいましたが、次回(か分かりませんがいずれ)は用意したコンテンツをまとめて整理する方法なんかについても書こうと思います。

ヴォラーレ株式会社 土居健太郎

おすすめの記事

内部リンクの構造の変化がアクセス数に与えた影響

今回の記事は内部リンクの最適化がSEO対策上及ぼす効果に関する話題です。SEOで「リンク」と言えば外からのリンク(外部リンク)を指すというイメージもある方もいるかもしれませんが、内部リンク(サイト内リンク)はサイト内で行き来するリンクのことで、ユーザーを受け渡すという意味では大きく価値は変わりません。

内部リンクのSEO対策における重要性

「外部リンクだけではなく、内部リンクも変わらず重要です」というのは簡単ですが、実際にどのような価値があるのかということを言われると、その役割は様々で一口に言うのは難しいです。

こちらで書くと長くなりますので別のブログの関連記事を紹介します。

「検索エンジン最適化」について再考・まとめておく- 天照SEOブログ

私が個人的に別で書いている記事ですが、この中に内部リンクに関する重要事項がかいつまんで話されているので参照下さい。上記記事の言葉を借りて以下に内容を簡単にまとめると、

  • ページランクの調整
  • リンク階層の調整
  • WEBページ間の情報の関連付け
  • アンカーテキストで端的にページの主なテーマを示す

という内容になっています。詳細はこちらでは割愛しますが、サイト内のナビゲーションという意味だけではなく、SEO対策に於いても色々な意味を持っていると言えます。

内部リンクの改悪・改善が検索流入数に与える影響

約1年半前にオープンし、SEOを弊社で行ってきたとあるクライアントさまのWEBサイトを2011年の春~7月にかけてリニューアルしました。目的は主にUI(ユーザーインターフェース)の改善によるPV(ページビュー)数の増加と直帰率の低下、SEO対策面での強化、その結果としての問合せ数の向上です。

UI・デザイン面での向上をはかるにあたり、少し(見た目上)目立って露出されていた内部リンクを、一旦どのページからも外してみた時期がありました。その関係で、一部のアーカイブのページへの内部リンク(※)が極端に減少しました。それが下記図の①の時期です。

この時期に検索エンジンに関わる変更はそれ以外には行っておらず、その減少が内部リンクの構造の改悪によるものと判断し、その後にそれを修正し、見た目上のストレスにならない位置へとそれを以降しました。また、その他でもそれが下図の②の時期です。

クリックで拡大
※クリックすると画像が拡大して見られます。

ちょっと見た目には分かりづらい変化ではありますが、実際に数字を見てみると6月中旬から7月上旬にかけて、それまでのアベレージのアクセス数に比べて約10~15%程度(数で言えば約25~40/日 程度)の減少があり、実際に新しいコンテンツを追加した後にそのページが明らかにランキング上位にヒットしなくなったということも実際に見られました。

②以降数日後からは順調に回復し始め、最終的にはその他のUIの改善に伴い更に内部リンクを強化(主にTOPページから下位ページへのリンクの見直し)を行い、つい先日ようやく過去最高の検索流入数(492)をマークしました。2ヵ月前からの推移を見ればそれなりの%での改善が出来ています。

また、PV数もまだまだとは言えリニューアル前後で見れば大分改善しています。

PV数の推移

※①の内部リンクは、イメージではブログでいう「タグ」とか「カテゴリ」へのリンクのようなアーカイブに飛ばすリンクのイメージです。

簡単にまとめ

少しざっくりとした内容ではありますが、基本的なことは昔から誰かが言ってきたことで、特に難しいテクニックを使っているわけではなく、重要なページには内部リンクを集めた方がよく、関連性の高い内部リンクは価値があり、アンカーテキストは端的にキーワードで書いた方が分かりやすく、、などということです。

言われてみればどこかで聞いたことがあるようなフレーズですが、やはりSEOと言うとどうしてもそのあたりの意識が飛んでいってしまってテクニックというか小技を頭に描いてしまうのは我々SEO業者の良くないところかもしれませんが、一旦冷静になって考えてみるとちょっとした一部の改善だけで少なくとも数%とか数十%くらいのアクセス改善は行えるのではないかと思います。

内部リンクの最適化は特にページ数が多い、更新が多いなどというWEBサイトでは特に影響力が大きいので、あまりナメてかからない方が良いですね。ご参考までに。

ヴォラーレ株式会社 土居健太郎

おすすめの記事