前回の続きです。

Googleアナリティクスの検索エンジン最適化レポートのフィルタ機能を活用して

  1. 表示回数が100回以上のクエリを対象にしたい
  2. 平均順位が5位以上のクエリを対象にしたい
  3. CTRが5%以上のもののクエリを対象にしたい
  4. 検索を”ウェブ”と”携帯(スマートフォン)”のみを合算して絞り込みたい
  5. 30日以上の長期間の集計を行いたい
  6. 期間比較を行いたい

をレポートします。

 

1.表示回数が100回以上の検索クエリを対象にしたい

アドバンスを選択し条件に一致させます

表示回数が100回以上の検索クエリを対象にする

          • 表示回数が100を上回るように設定

 

2.平均順位が5位以上の検索クエリを対象にしたい

平均順位が5位以上の検索クエリを抜き出す

            • 平均掲載順位が5を下回るように設定
            • 平均掲載順位が1を上回るように設定

 

『平均掲載順位が1を上回るように設定』しているのは、クリック数、表示回数が < 10 で掲載順位が取得できないものを除くためです。

 

3.CTRが5%以上のもののクエリを対象にしたい

CTRが5%以上のもののクエリを対象にしたい

          • CTRが5を上回るように設定
          • 表示回数が100を上回るように設定

条件に表示回数を入れているのはブレを少なくするためです。一回しか表示されないようなキーワードがクリックされたらそれだけでCTRが100%となってしまうため、そのようなものを除外しています。

 

4.検索を”ウェブ”と”携帯(スマートフォン)”のみを合算して絞り込みたい

検索を”ウェブ”と”携帯(スマートフォン)”のみを合算して絞り込みたい

            • セカンダリディメンションに『Google関連サイト』を指定
            • Google関連サイトの『画像』を除外
            • Google関連サイトの『動画』を除外
            • Google関連サイトの『モバイル』を除外

 

合算するには不必要なものを『除外』して表示させます。OR条件できるようにしてほしいですね。

 

5.30日以上の長期間の集計を行いたい

30日以上の長期間の集計を行いたい

試してみたところ最大4ヶ月保存のようです。保存期間が決まっているのは残念ですが、それでもウェブマスターツールの5週間に比べればずっと良いですよね。

 

6.期間比較を行いたい

期間比較を一度に行いたい

説明不要ですね。Googleアナリティクスでいつも行なっている期間比較が行えます。

 

おまけ:フィルタ適用後のキーワード数の確認

条件を絞り込んだ後のキーワード数はどのくらいあるのか気になりますよね。ページ送りの横にひっそりとでています。

キーワードの数は重要な指標になると思うのですがこの扱いとは・・・

キーワード数の調査

 

最後に

いかがでしょう。

例えば

『ディスクリプションを変更した!』

『リッチスニペットに対応した!』

『SSLを導入しシールインサーチに対応した!』

など検索エンジンの評価に関係がなくても、ユーザー心理を読んでCTRを上げる施策はありますよね。効果の程はどうなのか、このレポートをうまく使えばそのような検証が手軽に行えます。

Goolge検索における上位1,000件(日別)しか取得できないという制約はありますが、それを補って余りある魅力的な機能だと私は思います。

 

 

Googleのウェブマスターツールを使えば検索クエリを知ることができます。

例えば以下はあるサイトの検索クエリのページです。

あるサイトにおけるウェブマスターツールの検索クエリの例

        • 期間・・・2012/02/13 – 2012/03/14
        • フィルタ・・・指定なし
        • クエリ数・・・10,268
        • 表示回数・・・300,000(75,000件が表示されています)
        • クリック数・・・40,000 (5,500件が表示されています)

この例では上記のようにレポートされました。(表示回数とクリック数の”○○件が表示されています”については後述

さて、この素晴らしいレポートを様々な断面で分析したいと思った場合どうしますか?例えば

  • 表示回数が100回以上のクエリを対象にしたい
  • 平均順位が5位以上のクエリを対象にしたい
  • CTRが5%以上のもののクエリを対象にしたい
  • 検索を”ウェブ”と”携帯(スマートフォン)”のみを合算して絞り込みたい
  • 30日以上の長期間の集計を行いたい
  • 期間比較を一度に行いたい

残念ながらウェブマスターツールのフィルタでは機能が不足しているため、これらの一つでも実現することができません。
こまめにCSVにダウンロードして手で集計すれば実現出来るかもしれませんがそれだけはごめんです。ではどうすれば良いでしょう?

私はGoogleアナリティクスの強力なフィルタリング機能を利用しています。

 

Googleアナリティクスの検索エンジン最適化レポート

2011年11月より、それまでウェブマスターツールでしか見られなかった検索クエリのレポートがGoogleアナリティクスでも見れるようになりました。

ところが(これは私の周りだけかもしれませんが)この素晴らしいレポートを活用している人が少ないように感じています。

そこで私がよく見るレポートを紹介してみます。

事前準備

はじめにGoogleアナリティクスで”検索エンジン最適化レポート”を使えるようにしなくてはいけません。連携が行われていないと以下のような画面が表示されます。

このレポートを使用するにはウェブマスター ツールを有効にする必要があります。

ウェブマスターツールとGoogleアナリティクスを連携させる

アカウント設定 > プロパティ設定 > ウェブマスターツールの設定

より設定が行えます。なお連携させるには、ウェブマスターツールでサイトの管理者であること、そのプロパティのGoogleアナリティクス管理者であることが必要です。

プロパティがウェブマスター ツールで確認されたウェブサイトであり、お客様がそのウェブサイトの所有者であれば、ここでウェブマスター ツールのデータを関連付けることができます。Google アナリティクスでは一部のレポートでそのデータを表示することができます。

あとは手順通りに進めればOKです。

ここで一つ注意ですがウェブマスターツールとの連携はウェブ プロパティ単位となります。必ずサイトごとにプロパティを追加するようにしましょう。もし一つプロパティ内でプロファイルを分けることによって複数のサイトをトラッキングしている場合、ウェブマスターツールとの連携は代表の一つのサイトしか行えません。

Googleアナリティクス側で検索クエリの表示を確認

さて、連携が行えた所でGoogleアナリティクス側で検索クエリのレポートを表示させてみましょう。

先程のウェブマスターツールで表示させたレポートと同じ条件のものを表示させてみます。

Googleアナリティクスによる検索クエリレポート

          • 期間・・・2012/02/13 – 2012/03/14
          • フィルタ・・・指定なし
          • クエリ数・・・7,118
          • 表示回数・・・75,000
          • クリック数・・・5,500
          • 平均順位・・・19
          • CTR・・・7.33%

 

クエリ数や表示回数、クリック数がウェブマスターツールと比べて少なくなっているのにお気づきですか?この差を見て

「ほんとに正しく連携できているの?」

と思ってレポートを見なくなった方も多いのではないでしょうか?

実はこれ

”一日あたり上位1,000件のクエリに対する表示回数、クリック数”

のことです。ウェブマスターツールでグレーで小さく表示されている部分のことですね。

webmaster-01

非常に分かりにくい。

とは言え、一部のデータしか見れなくても提供されているだけでありがたいものです。

同じ条件で比較するのであれば十分傾向はわかります。

それでは連携が行えた所で前述のレポートを順に見て行きましょう。

でもちょっと長くなってしまったので続きはまた次回。

 

 

先日の行われた、第11回コンバージョン塾の発表資料の公開です。

少し古いですが、Googleの2010年のメーデーアップデートの攻略記です。

ネタっぽいタイトルですが、一言で当時の心境をよく表しているのです。

口頭の説明が多かったので伝わりきれないかもしれませんが、何かの参考になれば幸いです。

 

 

コンバージョン塾という勉強会の発表資料の公開です。

SEOの話ではありません。要求分析の活動の中で行われる『要求を伝える』ということについてです。

前半は要求を伝え、ゴールはどこかチームが理解するための取り組みについて。
後半はUMLのユースケース図の利用について考えてみました。

 

後半部分のユースケースは、前半部分の『ゴールはどこかチームが理解するための取り組み』の手段の一つとして捉えて頂ければと思います。

それにしてもユースケースなんて本当にいまさらです。

でもうまく使えば効果的だと思います。色々意見はありそうですが、実はちょっと見なおしているんです。

 

前回、Pythonを用いて検索クエリのダウンロードをご紹介しました。

今回、Stephan Schmitz氏によって検索クエリをダウンロードできるPHPプログラムが公開されたので紹介します。
http://code.google.com/p/php-webmaster-tools-downloads/

公開されているサンプルをコマンドライン実行するまでの手順は以下の通りです。

  1. PHPのインストール
  2. gwtdata.phpのダウンロード
  3. サンプルプログラムのダウンロード、およびデータを取得するサイトURLとそれを管理しているGoogelアカウントのemail、パスワードの書き換え
  4. ターミナルからサンプルプログラムの実行

Pythonの時はGoogle Data APIsを扱うためのクライアントライブラリをインストールする必要がありましたが、PHPバージョンでは不要です。即、実行できます。手軽ですね。

さて早速チュートリアルに入りましょう。

 

1.PHPのインストール

PHPをダウンロードし、インストールします。
Windowsの場合インストーラーが用意されています。
http://windows.php.net/download/

PHPのインストール

現時点(2012年1月28日現在)では、5.3.9がステーブルです。

今回、コマンドラインから実行する予定なので、Thread SafeでもNon Thread Safeでもどちらを選んでもかまいません。両者の違いは説明しませんが、Webサーバー上で動かす場合

  • IIS・・・Non Thread Safe
  • Apache・・・Thread Safe

と覚えておけばいいでしょう。

インストーラーに従ってインストールします。

Welcome to the PHP 5.3.9 Setup Wizard

Webサーバーをセットアップしますか?と聞かれますが、今回はコマンドラインから実行するのでDo not Setup a web serverを選びました。

Select the Web Server you wish to setup.

さて次はパスの確認です。

コマンドプロンプトを立ち上げ、 php –v と打ってみてください。

php -v

のように表示されれば完了です。

表示されない場合は、前回のPythonの時のようにパスを設定してあげます。

システムのプロパティ⇒詳細設定⇒環境変数⇒システム環境変数⇒Path

に、PHPのインストール先を追加します。パスが通っているかの確認は、コマンドプロンプトから path とうちます。

path

のようにPHPのインストール先が含まれればOKです。

2.gwtdata.phpのダウンロード

以下よりダウンロードします。
http://php-webmaster-tools-downloads.googlecode.com/files/gwtdata.php

適当なディレクトリに設置します。

3.サンプルプログラムの取得

使い方
http://code.google.com/p/php-webmaster-tools-downloads/wiki/Running

サンプルコード
http://code.google.com/p/php-webmaster-tools-downloads/source/browse/

先ほど設置した、gwtdata.phpと同じ場所に置きます。

 

4.example-simple.phpの実行

もっともシンプルなexample-simple.phpを実行してみましょう。

ソースを開きとこんな感じです。

example-simple.php

ファイルをメモ帳などで開き、Googleアカウントのemailとパスワード、検索クエリを取得したいサイトのURLを記述します。
サイトのURLはスラッシュで終わっている必要があります。

さて、いよいよ実行です。ファイルを設置したディレクトリに移動し、 php example-simple.php と実行します。

php example-simple.php

このサンプルは結果を何も返しませんが、処理が終わるとcsvファイルが作られています。

image

おお!素晴らしい!これで終わり!

・・・とおもいきや・・・

ファイルを開くと日本語が?に置き換わっています。

検索クエリの日本語が?に置き換わっています

 

マルチバイト文字の正しく表示できるようにする

マルチバイト文字の問題はとてもここでは書き切れないので省略です。原因箇所の特定と修正方法のみ書きますね。

gwtdata.phpの233行目を見てみると、DownloadCSVという処理で、ut8_decode を使っているのがわかります。

Downloads the file based on the given URL.

この関数は、UTF-8でエンコードされたISO-8859-1文字列をシングルバイトのISO-8859-1に変換する処理です。つまりマルチバイトには対応していません。対応しない文字列は全て「?」に置き換わるため、日本語が全て?になってしまうんですね。

実はこのデコード処理は不要なんじゃないかと思いつつ、いずれにせよこのままではつかえません。

ではどうすればよいか?

utf8_decodemb_convert_encoding に置き換えます。

具体的には233行目のutf8_decode($data)mb_convert_encoding($data, “SJIS”, “UTF-8”)

に置き換えます。UTF-8の文字列をSJISの文字列に置き換える処理で、マルチバイトに対応しています。(SJISにしたのはExcelでそのまま扱えるようにするため)

再実行し、ダウンロードしたCSVの結果が以下です。

mb_convert_encodingに置き換えて再実行

ちゃんと日本語が表示できました!

最後に

さて、今回はチュートリアルということでもっともシンプルなもので実行しました。

他のサンプルを見てみると、管理サイト全ての検索クエリをいっぺんにダウンロードしたり、HTML表示させたり、日付を絞り込んだりというものもありました。興味のある方は是非チャレンジしてみて下さい。

 

 

久々のブログ更新です。なかなかまとまった時間がとれず随分間が開いてしまいましたが、決してネタが無いわけではありません(必死)

さて、今回はGoogle Webmaster Central Blogにて面白い記事がアップされたのでそのご紹介です。
Download search queries data using Python

Googleが公開したPythonスクリプト使用してウェブマスターツールの検索クエリをCSV形式でダウンロードし、かつGoogle Docsにアップロードしてしまおう!という内容です。

面白い内容なのですが、プログラミングに慣れていない方には少し敷居が高い作業となるかもしれません。ですがやってみると意外にすんなり行くと思うので簡単にセットアップ手順をご紹介します。

最初に全体の流れを説明すると以下の手順になります。

  1. Pythonのダウンロードとインストール
  2. Google Data APIs Python Client Libraryとダウンロードとインストール
  3. downloader.pyをダウンロードし、適当なディレクトリに設置
  4. example-create-spreadsheet.pyのダウンロード、およびデータを取得するサイトURLとそれを管理しているGoogelアカウントのemail、パスワードの書き換え
  5. ターミナルからexample-create-spreadsheet.pyを実行
  6. Google Docsで取得

では順番に追って行きましょう。

1.Pythonのインストール

Pythonというのは、オブジェクト指向のスクリプト言語で、Perlとならんで普及している言語の一つです。今回紹介するプログラムはPython上で動かすため、作業するマシンにPythonをインストールする必要があります。

Pythonのバージョンは2.5以上である必要があります。2.5未満の場合、別途ElementTreeというXML関連のライブラリをインストールする必要があります。ここでは2.5以上のPythonを使っているという前提ですすめますので、2.5未満の場合は最新版にするか、ElementTreeをインストールして下さい。

Windowsの場合

Pythonのダウンロードページにインストーラーが用意されています。
http://www.python.org/download/

www.python.org

ここでは最新の2.7.2を選びました。
クリックするとインストーラーがダウンロードされます。
あとはインストーラーを実行し、画面の指示に従ってインストールします。

インストールが正常に完了したか確認します。

コマンドプロンプトを立ち上げ、python –V と打ってみてください。

コマンドプロンプトは、プログラムとファイルの検索 から cmd と検索すると出てきます。

'python'は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されていません。

このようなメッセージが表示される場合、パスの設定を行う必要があります。

システムのプロパティより環境変数を選択します。

システムのプロパティ

システム環境変数にある、Pathを選択します。

環境変数

Pythonのインストール先を追加します。(『;』で連携します)

Path

この例では、C:\Python\Python27 という場所にインストールしたのでそれを追加しました。

コマンドプロンプトを exit で一度終了させ、再度立ち上げ直します。
新しく立ち上げ直したコマンドプロンプトで、path と打ち、パスが通っているか確認します。

path

このように追加したパスが表示されればOKです。

もう一度 python -V を試してみます。

python -V

このようにバージョンが表示されればOKです。

 

Mac OS X の場合

Mac OS Xの場合はすでにPythonがインストールされています。ユーティリティの中のターミナルを立ち上げ、同じように python –V でバージョンを確認してみましょう。

 

2.Google Data APIs Python Client Libraryのインストール

gdataを扱うためのGoogleが提供しているPythonライブラリをインストールします。
http://code.google.com/p/gdata-python-client/downloads/list

現時点(2011/12/24)では2.0.15が最新のようです。

gdata-python-client

ダウンロード後、解凍します。

解凍したディレクトリにcdコマンドで移動し、python setup.py install と打ちインストールを実行します。

python setup.py install

例はWindowsのコマンドプロンプですが、Macのターミナルからも同じ手順となります

インストールされたかどうかの確認

テスト用のスクリプトを実行するため、 python tests/run_data_tests.py と打ち込みます。

python tests/run_data_tests.py

つらつらとテストが実行されますが、すべてにOKが表示されれば完了です。

 

3.downloader.pyのダウンロード

ここまでくれば、あともう一息です。

downloader.pyをダウンロードし、適当なディレクトリに設置します。

2011/12/24現在、ファイルはダウンドードできないようで、その場合はコードをコピーして”downloader.py”という名前で保存します。

 

4.example-create-spreadsheet.pyのダウンロードと編集

example-create-spreadsheet.pyをダウンロードし、downloader.pyと同じディレクトリに設置します。

ソースをテキストエディタで開き、 Email address and password used to sign-in to Webmaster Tools and Google Docs と書いてある箇所を変更します。

Email address and password used to sign-in to Webmaster Tools and Google Docs

  • email・・・Googleアカウントでログインするアドレス
  • password・・・パスワード
  • website・・・検索クエリを取得するサイトのURL(スラッシュで閉じる必要があるっぽい)

 

5.example-create-spreadsheet.pyを実行

ファイルを設置したディレクトリに移動し、 python example-create-spreadsheet.py と実行します。

成功の例

python example-create-spreadsheet.py

以下のように、Google DocsへのURLが表示されれば成功です。(例ではkeyの値はマスクしています)

失敗の例

アカウント情報が正しくないと BadAuthentication がでます。

image

また、websiteが正しくないなど、取得できる値が無いと ValueError となります。
URLが正しいか確認しましょう。なお、URLの末尾が『/』スラッシュで終わっていない時もこのエラーがでます。

image

見慣れないとぎょっとすると思いますが、エラーの内容は書いてあるので落ち着いて対処しましょう。

 

6.Google Docsで確認

Google Docsで見てみると、このようにCSVファイルがアップロードされました。

Google Docs

開いてみるとこのように。

モバイルSEOの勧めの検索クエリ

 

おわり

以上、簡単ではありますが、最低限のサンプルとしてWebmaster Central Blogに書いている内容そのままを実行してみました。
汎用的にするのであれば、アカウント情報などはプログラムソースの外から渡すようにしたりするのが良いでしょう。
また、スケジューラーと組み合わせれば定期的に検索クエリをダウンロードするという手間が自動化できます。
皆さんだったらどう活用するでしょうか。

 

dメニュー

11/18にdocomoのスマートフォン向けポータルサイト、「dメニュー」がサービス開始しました。

dメニューとは?

オフィシャルページに説明があります。

http://www.nttdocomo.co.jp/service/information/dmenu/

つまりdocomoのスマートフォン向けのポータルサイトですね。dメニューのメニューリストに登録しているサイトの検索や、スマフォ向けアプリが購入できるdマーケットなどを利用することができます。

dメニューが採用している検索エンジン

メニューリスト掲載サイトの検索結果とウェブ検索結果にわかれます。メニューリスト掲載サイトはgoo、ウェブ検索はGoogleのエンジンが採用されています。(2011年11月現在)

2010年5月にiモードの一般サイトの検索をGoogleモバイルからモバイルgooのエンジンに切り替えたこともあり、今後変更される可能性は否定できません。

dメニューからのトラフィックは?

さて、dメニュー開始から一週間たちました。メニューリストに登録した、あるスマートフォン向けサイトにおけるdメニュー検索、およびメニューリストからのトラフィック割合を調べて見ました。

dメニュー登録サイトにおける1週間のトラフィック割合

結果は全体のトラフィックの1%未満という、ちょっと肩透かしを食らった感じです。もちろんサービス開始直後ということで認知度も低いし、これからテコ入れを行うのでしょう。

docomoとしては決済手段を提供することでコンテンツ利用料の何割かを手数料として徴収できるので、利用者をメニューリスト登録サイトへ囲い込むことは重要な戦略であるはずです。今後は携帯電話キャリアならではの戦略を打ち出してくるかもしれませんね。

私個人はdメニューに関して否定も肯定もありませんが、今後割合をどこまで伸ばすか注目していきたいと思います。

 

Cinciいちしまさんが主催する、第3回_gaTrackerに参加してきました。

プレゼン

私もLTしてきたのでプレゼン資料の公開です。

本当はモバイルアクセス解析において、自社ツールを開発することになった経緯や、課題を解決するためのアイデアなどをお話ししたかったのですが、社内ポリシーと照らしあわせた結果NGとし、代わりにモバイル版GoogleアナリティクスのTipsを紹介してきました。

モバイル版のGoogleアナリティクスではサポートされていないカスタム変数について、使うにはどうすればよいかというお話です。(エンジニア向けなら一枚のスライドで済む話なんですが)

このブログでも過去に紹介しているので興味のある方は御覧ください。 ⇒ モバイル版Googleアナリティクスでカスタム変数を使う!

 

 

みなさんBaidu(バイドゥ)についてはどれくらい意識していますか?私は全く意識していませんでした。

この件があるまでは・・・

結論から言うと

Baiduクローラーに対してCookieをセットすると次のアクセスでそのCookie情報を送ってくる

いやー驚きました。技術云々ではなく、クローラーの設計思想に。

次に示すのは問題のアクセスログです。(最後の項目がCookie情報です)

■最初にURLその1にアクセス
119.63.196.92 Tqg8vMCojToAAB7xp0gAAAAY – [27/Oct/2011:02:00:44 +0900] “GET {URLその1} HTTP/1.1″ 301 – “-” “Mozilla/5.0(compatible;Baiduspider/2.0; +http://www.baidu.com/search/spider.html)” {ドメイン} 80 28270 -/- (-%) “-

■URLその2に301リダイレクト
119.63.196.124 Tqg8vMCojToAAB6go84AAABq – [27/Oct/2011:02:00:44 +0900] “GET {URLその2} HTTP/1.1″ 301 – “-” “Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)” {ドメイン} 80 16483 -/- (-%) “JSESSIONID=46C941B688E7E95CD16FB5762FDD7C53;

■URLその3に301リダイレクト
119.63.196.96 Tqg8vMCojToAAB7xp0kAAAAP – [27/Oct/2011:02:00:44 +0900] “GET {URLその3} HTTP/1.1″ 200 21023 “-” “Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)” {ドメイン} 80 1966261 -/- (-%) “JSESSIONID=46C941B688E7E95CD16FB5762FDD7C53;

JSESSIONIDが引き継がれていることを確認できます。(JSESSIONIDというのは、Javaサーブレットコンテナが発行するセッションを維持するためのCookieです)

最初のアクセスの場合はCookieは空ですが、2回目移行はこのセッションCookieを維持しています。

他にもわかったこと

転送元から転送先へアクセスする間隔が殆ど無い!(ミリ秒以下)ということがわかりました。上記のタイムスタンプを確認するとほぼ同時にアクセスされていることがわかります。

Googlebotなどはサーバの負荷を考慮し、そのサーバに最適な間隔に調整してアクセスしてきてくれます。例えばGoolgebotで同じ転送URLを踏ませると、転送先へは数秒から十数秒の間を開けてアクセスしてきてくれます。もちろんCookieは送られて来ません。

やはりBaiduは好かん

これってセキュリティホールのある下手なつくりのサイトだと認証URLをたどってログインされて会員情報引っこ抜かれて全部クロールされて・・・なんてこと起きますよ。

下手にアクセスを許して変なCookieつけて色々なところをアクセスされるくらいならすべてブロックしてしまおうかと思っています。

不適切なくだりで誤解を与える恐れがあるため削除いたします。詳しくはコメントをご覧下さい。(2011年11月1日)

 

 

 

最近、『コンバージョン塾』という勉強会を開催しています。

この間、第7回を開催しました。

第7回の発表資料はこちらから参照できます。
http://conversion-school.blogspot.com/

 

第7回ではSEOに関するトピックが集中し、多くの方に参加いただき大変盛り上がりました。
勉強会中、SEOについてディスカッションしていくうちに、『URLのディレクトリ階層はGoogleの評価に関係してくるのか?』という話題になりました。

その場での一致した意見としては

  • ディレクトリ階層と評価には関係が無さそうだ (『これ』というキーワードで上位表示しているサイトの事例)
  • リンクのクリック数のリンク階層の方が重要
  • ただし綺麗なディレクトリ構造は分かりやすく、人に好まれやすい。 (Googleガイドライン)
  • ディレクトリがサイト階層構造にならっているとアクセス解析などに有利

というものでした。

一方で、「数万とか数十万ページの規模のサイトで大掛かりなURL変更の事例ってあるのでしょうか?」という意見もでました。

はい!ここにあります!ということで過去にこのブログでも紹介した『URL変更でトラフィックに変化があるか?』で行った大掛かりなURL変更の事例をもう少し掘り下げて再考してみたいと思います。

 

前提

前の記事ではPCサイト1つ、モバイルサイト2つの合計3サイトで検証しましたが、そのうちのPCサイトの事例をご紹介します。

サイトの構造は以下の図のようになっています。(わかりやすいように超シンプルに表現しています)
URL変更の対象にした機能はカテゴリが数十、ひとつのカテゴリには数個のサブカテゴリ、ひとつのサブカテゴリには数万の記事があります。

サイト構造

 

変更前のURL

変更前のURLを見てみましょう。
これは2005年のサービス開始当時のURLです。『URLのディレクトリ階層を浅くしたほうが評価が高い』というSEO都市伝説を間に受けた、かどうかはわかりませんが、すべてのコンテンツを/public/配下に集約させていました。

トップ /public/showTopPage.do
機能分類 /public/show{機能分類}TopPage.do
カテゴリ /public/showCategory{カテゴリ}.do
サブカテゴリ /public/showSubCategory{サブカテゴリ}.do
記事詳細 /pubic/showMessageDetail{記事ID}.do

 

変更後のURL

これをサイトの階層と合わせ構造に変更しました。一番トラフィックを稼ぐ記事詳細ページは2階層目から4階層目になっているなど、結構ドラスティックに変えてみました。

トップ /
機能分類 /{機能分類}/
カテゴリ /{機能分類}/{カテゴリ}/
サブカテゴリ /{機能分類}/{カテゴリ}/{サブカテゴリ}/
記事詳細 /{機能分類}/{カテゴリ}/{サブカテゴリ}/{記事ID}/

 

検索エンジン経由のトラフィックの変化

前の記事でも取り上げていますが、もう一度紹介しておきます。データから結論すると、
『検索エンジンの評価は全く変わりがなかった』
ということが言えます。

Google検索

URL変更にともなうGoogle検索経由のトラフィックの推移

Yahoo!検索

URL変更にともなうYahoo検索経由のトラフィックの推移

Bing検索

URL変更にともなうBing検索経由のトラフィックの推移

興味深かったのは、URL変更を行うと直後はトラフィックが減り、その後すぐ回復するということが言われていますが、このサイトの例では特に影響が見られませんでした。(ドメイン移転であればまた違った結果かもしれませんね)

 

ディレクトリ階層をサイトの構造と合わせることのメリット

サイトの階層構造をURLに反映させることは以下の点で有利です。

  1. アクセス解析でディレクトリごとのきめ細かい分析が行える
  2. ディレクトリごとに転送設定やアクセス制限を設けるのが比較的容易に行なえる
  3. robots.txtでディレクトリ単位で制限することができる

サイトの階層構造を無視したURLにはメリットはほとんどありません。それどころか上記の点がそのままデメリットになります。

またサイトの階層構造とURLを合わせておくとシステム的な面でも融通もきかせやすくなります。
例えば特定のサブディレクトリへのアクセスを別のドメインに転送したり、EC-CUBEで構築しているサイトの特定ディレクトリをWordPressに向けたりといったことも比較的容易に行えます。
もちろん、上記のようなことはどんなURLでも行えます。ですがサーバサイドの設定を後で見直すときに格段に分かりやすいというメリットがあります。

 

URLを変更することの大変さ

URLというのは一度決定すると変更するのが大変です。なぜならURLというのはシステムに大きく依存するからです。今回の事例では2週間程度で比較的簡単にロンチできましたが、融通の利かないシステムだと変更自体がそもそも無理で、システムを一から作りなおすということにもなりかねません。

また、一度URL変更を行うと変更前のURLの”保証”を永続的に行う必要がでてきます。つまり変更前のURLにアクセスされた場合に変更後のURLに転送する設定です。

 

ウェブマスターとして取り組むべきこと

ウェブマスターはサイト設計の段階でURLまで注意を払うべきです。

現実問題として、URLの決定はシステムを構築するエンジニア任せにしているところは多いのではないでしょうか?
特に制作を外注しているところは要注意で、URLまで完璧にコントロールすべきだと思います。

もし、あなたがエンジニアであるならばコーディングする前に画面とアクションに対応するURLを一覧化しておくことをお勧めします。

システムを外注しているところは、基本設計の段階で画面一覧と共にURL一覧を作成しておくべきでしょう。その際、完璧なURL一覧というよりは階層構造がわかる大枠だけでも良いと思います。

そしてかならずURLに対してレビューすること。

 

結論

SEOの観点で見ると、URLのディレクトリ階層と評価には関係が無いと言えると思います。ですが上記に上げたようにサイトの階層構造を反映したURLにすることは多くのメリットがあります。

どのようなURLが正解かというのはなかなか難しい議論かもしれません。完璧なRESTFulを目指す必要は無いと思いますが、少なくとも自分の提供したいサービスを迷わずに使ってもらえるURLにすることをお勧めします。

 

(自戒を込めて・・・)

© 2011 モバイルSEOの勧め Suffusion theme by Sayontan Sinha