アイルランドのアクセス解析調査会社 StatCounter社は、世界約300万サイトにトラッキングコードを埋め込むことによってアクセス解析（ブラウザー、ブラウザーのバージョン、モバイル用ブラウザー、パソコン用OS、モバイル用OS、PC用検索エンジン、モバイル用検索エンジンのシェア、モバイルとデスクトップPCの比率、ソーシャルメディアのシェア）を実施しています。

そのアクセス解析データは、リアルタイムで常にウェブサイト StatCounter Global Stats で見ることができます。

　　▶ StatCounter Global Stats

　　　（スタットカウンター・グローバル・スタッツ）

　　　（Stats は Statisticsの略語・俗語）

ウェブページ内では、以下のような情報を確認でき、かつ出力できます。

【 StatCounter の統計項目】

　　◎ Statistic（＝統計の種類）

　　　　　Browser（＝ブラウザーのシェア）

　　　　　Browser Version（＝ブラウザーのバージョンのシェア）

　　　　　Mobile Browser（＝モバイル用ブラウザーのシェア）

　　　　　Operating System（＝パソコン用OSのシェア）

　　　　　Mobile OS（＝モバイル用OSのシェア）

　　　　　Search Engine（＝PC用検索エンジンのシェア）

　　　　　Mobile Search（＝モバイル用検索エンジンのシェア）

　　　　　Mobile vs. Desktop（＝モバイルとデスクトップPCの比率）

　　　　　Social Media（＝ソーシャルメディアのシェア）

　　◎ Country/Region（＝国・地域）

　　　　　Japan（＝日本）もあります

　　◎ Time Period（＝統計期間）

【 StatCounter のグラフ形式】

　　◎ Line（＝折れ線グラフ）値は時系列

　　　（デフォルトは直近の13ヶ月）

　　◎ Bar（＝棒グラフ）値は統計期間における平均値

【 StatCounter のデータ出力】

　　◎ Save Graph Image（＝jpegフォーマットでの書き出し）

　　◎ Download Data（＝csvファイルでの書き出し）

　　◎ Emned（＝ホームページ埋め込みようhtmlソース）

なお、ここでの値はあくまで参考程度に留めた方が良さそうです。

とりわけ「日本」での情報は信憑性がかなり疑問です。

例えば、統計期間2009年６月〜2010年６月で、

1. 日本における検索エンジンの比率において、Google 77.6%、Yahoo! 19.83%となっており、明らかに間違い。
2. 日本におけるPCとモバイルの使用比率において、デスクトップPCが 98.95%、モバイル 1.05%となっており、これも明らかに間違い。
3. 日本におけるソーシャルメディアの比率において、Facebook が１位で、mixi が入っていない。

少なくとも日本における統計比率は実際のものとかなりかけ離れているという印象です。

Tweet

昨日に引き続き、グーグル・ウェブマスターブログに掲載されたグーグルのサイトクリニックでのSEOネタを。

　　▶ ダブリンで開催された「サイトクリニック」を紹介します

　　　（グーグル・ウェブマスター向け公式ブログ）

SEOに関連して、

グーグルがトップレベルドメイン（TLD）について触れています。

6. トップレベル ドメイン ( .com や.info ) の違いは掲載順位に影響しますか？

影響しません。掲載順位で重視されるのはサイトのコンテンツです。

7. 日本向けのコンテンツを有するウェブサイトを運営していますが、サイトのトップレベルドメインは .so です。日本での掲載順位は低くなってしまいますか？

.so はソマリアの国別コード トップレベル ドメインで、確かに Google 検索では検索結果がユーザーにとって最適かどうか判断するときにこれを参考にします。とは言え、ウェブサイトの掲載順位はさまざまな要素に基づいて決定されており、トップレベルドメインはそのうちの 1 つに過ぎません。ウェブサイトに日本向けのコンテンツがあれば、日本の検索結果でもランキングされます。ただし、Google の検索エンジンのアルゴリズムが、どのような検索結果にあなたのサイトを表示すべきか判断するのに、通常より少し時間がかかるかもしれないことにご留意ください。

この２つの回答が矛盾していることに気づいた方は、するどいです。

グーグルは、

６の回答ではトップレベルドメインは検索結果の「掲載順位に影響しません」と答え、

７の回答では、「ウェブサイトの掲載順位はさまざまな要素に基づいて決定されており、トップレベルドメインはそのうちの 1 つに過ぎません」とトップレベルドメインが掲載順位決定の１つの要素だと答えています。

答えが矛盾していることにグーグルは気がついていないのでしょうか？

不思議ですね〜。

なお、SEOの世界では一般に、ある国でウェブ展開するなら、その国のトップレベルドメインを取得して運営することが推奨されています。

また、ドメインの取得が困難なもの（＝審査が厳しいドメイン）や限定されるもの（＝取得するのが限定されるドメイン）のほうが、SEO的に有利とされています。一例を挙げると、アメリカ合衆国の連邦政府と地方行政機関が使用できる .gov などは最も価値の高いドメインのひとつとみなされています。

もっともこれには異議を唱えるSEO専門家もいます。

たまたま特定のドメインをとれるような組織が検索結果の上位にくる要素を沢山持ち合わせているのだという理由で。

ひとつだけ言えることは、あまりヘンテコなトップレベルドメインを取得するのはオススメできないということです。

２つほどその理由を挙げておきましょう。

１．見た目では、見慣れないドメインに対するユーザーの違和感が、ブランディングにおいてマイナスに影響します。

２．聞いたことのないような国のドメインの管理がずさんだと、通信アクセスに悪影響を及ぼしかねません。最悪、トップレベルドメインが無くなってしまう可能性も全くないとは言えません。

Tweet

グーグル・ウェブマスターブログにグーグルのサイトクリニックの様子が一部紹介されています。

　　▶ ダブリンで開催された「サイトクリニック」を紹介します

　　　（グーグル・ウェブマスター向け公式ブログ）

SEOに関して役に立つ情報ですが、納得できない点もあります。

１つ目の話題「同じ内容のブログを 3 つ運営しているのですが、問題ありませんか？」を抜粋し、取り上げてみたいと思います。

1. 同じ内容のブログを 3 つ運営しているのですが、問題ありませんか？

コンテンツの内容が全く同じである場合、検索結果に反映されるのは 1 つのブログだけとなってしまう可能性が高いでしょう。また、ブログ運営の労力を分散してしまうと、ブログのリンクも分散してしまいがちです。つまり、複数の同じ内容のブログを運営することは、ユーザーだけでなく検索エンジンにとって、どのブログがメインなのか判断するのが難しくなるというリスクを伴ってしまいます。この場合、リダイレクトや canonical 指定 を使って、優先したいブログを指定するとよいでしょう。

これについては、結構迷っている方もおられるのではないでしょうか。

考えられるケースは、同一の投稿を数種類の無料ブログ（例えばライブドアブログ、アメーバブログ、FC2ブログなど）に投稿して、露出を増やそうという目的でしょう。

ところが現状、無料ブログに対しては、リダイレクト設定も canonical 指定（＝URL正規化タグ）も施すことができません。

（設定できるようになれば非常にありがたいのも事実ですが。）

できないことを奨められても意味がありませんね。

というか、グーグルの回答中にある「リダイレクト」設定ってどういう意味なんでしょうか？

301リダイレクトを施したら、少なくともそのブログには本文が存在しません。例えばアメーバブログに載っているタイトルを見てクリックしてジャンプすると、ライブドアブログの行って投稿を読むことになるでしょうか。ナンセンスです。

302リダイレクトを施すとしたらどうでしょう。リダイレクトするまでの設定時間をめちゃめちゃ長く設定したらいいのでしょうか？　それにしても一般に302リダイレクトの検索エンジンの解釈は、「ページの一時的な移転」です。これによりリダイレクト先のウェブページが優先されるのでしょうか。甚だ疑問です。

canonical 指定（＝URL正規化タグ）にてしても、無料ブログでは設定できないし、CMS利用の場合ならプログラムを改良しなければなりません。一般の人ができる作業ではありません。

ちなみに、グーグルが運営する公式ブログでさえ、canonical 指定（＝URL正規化タグ）を適切に使ってはいません。

（それについてはデザクロブログ「URL正規化タグ（rel="canonical"）をきちんと使っていないGoogleのウェブページ」で取り上げていますので、よろしかったらどうぞ。）

さらにはグーグルが運営する無料ブログサービス Blogger でも canonical 指定（＝URL正規化タグ）はできません。

（テンプレートを編集して、自身のURLを正規化するようにはできます。）

この問題の一番の解決法は、URL正規化タグ（rel="canonical"）を投稿時に自由にURLを設定できるようになることです。

ですが、無料ブログを提供する側は、それを可能にすることを好まないでしょう。なぜなら、自社の無料ブログに投稿する人が、別の無料ブログを正規化指定した場合、検索エンジン経由での自社の無料ブログへの集客ができず、メリットがなくなってしまうからです。

実に難しい問題です。

Tweet

自社のホームページ戦略を考える上で、または、

これから自社でホームページを作成して成果を上げようと考える場合、

グーグルやヤフーなどの検索エンジンの検索結果で

上位表示されている他社のホームページは当面のライバルであり、

気になるところです。

とは言え、どうして検索結果で上位表示を実現しているかは

なかなか簡単には判らないものです。

グーグルやヤフーの検索結果で上位表示を実現するためには、

次の４つの要素が大きく影響します。

　　１．検索エンジン最適化（SEO）がしっかり行われているか否か

　　２．ウェブサイトの規模（＝コンテンツの質・量ともに）

　　３．ウェブサイトへの被リンク（＝リンクの質・量ともに）

　　４．広告展開などによる自社サイトへのトラフィック

今回はこの中から、〔２〕のウェブサイトの規模（＝コンテンツの質・量ともに）の調べ方をご紹介します。

実際にホームページを開いてみれば、ある程度そのホームページの規模は判りますが、実際の規模、何ページの分量があるのかまでははっきりとは判りません。

ライバルの他社のホームページよりも検索上位を目指すのであれば、

自社のホームページの規模を質と量の両面で他社を上回るくらいの規模を実現することが必要になります。

そのためにもライバルのホームページの規模を知ることは大切です。

一番使い勝手が良いのは次のサイトのウェブツールです。

　　▶ Yahoo! Site Explorer

Yahoo! Site Explorer は英語になりますが、

日本語版（＝サイトエクスプローラー）のものよりも、

現時点では精度も高く、使い勝手が格段に良いです。

ここに調べたいホームページのURLを入力します。

全体の規模を確認するために、この欄にはサブドメインを省いて、

　　http://ドメイン名　を入力します。

　　（www.もサブドメインですから、www.は入力しません。）

ページ総数と実際のページ（のページタイトルとURL）が

ずらりと100件ずつ表示されます。

初期設定では「全てのサブドメインを含む」となっています。

なお、調べるホームページのURLで www. を含めると、「全てのサブドメインを含む」という初期設定では www. 以外のサブドメインが含まれない状態となり、ウェブサイト全体の把握ができない場合が発生します。

サブドメイン www. を省いたURLで調べてください。

なお、グーグル検索では、

検索窓に「site:ドメイン名」と入力して検索すると、

そのウェブサイトの全ページが検索結果として表示されます。

Tweet

SEO界における昨年の一番の出来事と言える

Googleの「URL正規化タグ（rel="canonical"）」の採用。

　　▶「検索結果に優先的に表示させたいページの指定について」

　　　（グーグルウェブマスター向け公式ブログ）

このタグ指定により、重複コンテンツ・重複URLの検索エンジンによる

インデックス化の分散を回避することが可能になりました。

指定の仕方は、

複製コンテンツページのheadセクションに以下の記述を追加します。

（なお、優先させるページ自身に、自身URLを記述して正規化しても構いません。）

＜link rel="canonical" href="http://優先させるホームページのURL" /＞

（山括弧はブログ用に全角にしてあります）

簡単な説明はこれくらいにして、先日、米Googleが新しい検索インデックスシステム「Caffeine」を公式ブログで発表した際、米Googleはいわゆる公式ブログとウェブマスター向け公式ブログの両方で同じ内容のページ（タイトル「Our new search index: Caffeine」）をアップしていました。

実際、本文には「(Cross-posted on the Official Google Blog)」と、

両方のブログにまたがって投稿している旨が記載されています。

▼グーグル公式ブログでの公開

http://googlewebmastercentral.blogspot.com/2010/06/our-new-search-index-caffeine.html

▼グーグルウェブマスター向け公式ブログでの公開

http://googleblog.blogspot.com/2010/06/our-new-search-index-caffeine.html

そこで rel="canonical" が気になり、

グーグルは一体どちらを優先指定しているのかと、

HTMLのソースを確認してみました。

▼グーグル公式ブログのHTMLコード

▼グーグルウェブマスター向け公式ブログのHTMLコード

すると、両ページにおける正規化タグの記述は以下のようになっていました。

（山括弧はブログ用に全角にしてあります）

▼グーグル公式ブログ

＜link href='http://googleblog.blogspot.com/2010/06/our-new-search-index-caffeine.html' rel='canonical'/＞

▼グーグルウェブマスター向け公式ブログ

＜link href='http://googlewebmastercentral.blogspot.com/2010/06/our-new-search-index-caffeine.html' rel='canonical'/＞

同じ内容のページだというのに、

それぞれが自身のウェブページを正規化してしまっています。

グーグルの説明によれば、

本来どちらか一方のURLに一本化すべきはず。

まあ、ブログ投稿のシステムの一環として、

自身のURLを正規化タグに入るように設定してあるのでしょうが、

グーグル自体が正規化タグをきちんと使っていないというのは、

ちょっとした発見でした。

ちなみに、検索クエリ「"Our new search index: Caffeine"」（ピンポイントで検索するため、ダブルクォーテーションマークで囲んで検索）でグーグル検索すると、下画像のように、上述の２つのサイトが１位と２位で表示されます。

検索クエリ「"Our new search index: Caffeine"」での検索結果

グーグルは自社のサイトに対してさえ、ペナルティを与えるくらい厳しい企業です。

まさかグーグルが提唱するURL正規化タグ rel="canonical" を

自身のホームページできちんと使っていないとはね . . .

Tweet

ホームページの情報発信の機能として有効なRSSやAtomの

フィードの構文をチェック（検証）できるウェブサイトを２つメモ。

大方のフィードは、ブログや

CMS（＝コンテンツ・マネージメント・システム）の一部として自動生成されるので、普段その構文の正当性・妥当性を気にすることはあまりないかもしれません。

フィードの検証サイトはどちらも英語のサイトです。

“validate（バリデート）” という単語を含みますが、

バリデートとは検証を意味します。そしてバリデートを行うツール・ソフトを “Validator（バリデータ、バリデーター）” と呼びます。

　　▶ Feed Validation Service（W3C）

　　　（フィード検証サービス）

　　▶ FEED Validator

　　　（フィード検証ツール）

検証したいRSSフィードのURLを入力し、

検証をおこない、問題がなければ、

「正当なRSSフィード」と認められ、

「正当なRSSフィード（VALID RSS ）」のアイコン（上画像中の黄色のアイコン）をホームページに貼ることができます。

なお、英語圏のウェブサイトで日本語サイトを検証すると、

上記２つのウェブ検証サービスに限らず、

時々、＜ ＞ 記号（半角英数）が意味不明なエラーと認定されることがあります。（検証する時期のよっては同じソースでもエラーにならなかったりすることもあります。正直これだけはいかんともし難いところです。）

Tweet

ウェブブラウザー用のファビコンの設定を修繕し、

iPad・iPhone・iPod touch 用の WebClipアイコン（ウェブクリップアイコン）を設定してみました。

ファビコンの作成・設定については、ホームページ作成の際、

可能な限り行っていますが、

ファビコンの見え具合やファビコン内のレイヤー設定などで

どうも納得できないでいました。

現状、ファビコンは

ひとつのファイル「favicon.ico」の中に、

16×16px、32×32px、48×48pxの３つのサイズを埋め込んだものが望ましいと考えられています。

　　16×16px　…　通常のブラウザー用

　　32×32px　…　一部のブラウザー用

　　48×48px　…　ショートカットアイコン用

これら３つを含む３層のファビコンを生成してくれるウェブサイトや

無料アプリケーションもありますが、

取り込める元ファイルの重さに制限があったり、

pngファイルが読めなかったりで、

なかなか良い方法が見つからないでいました。

（ファビコン制作に余り時間は掛けたくはないところです。）

プロのウェブデザイナーならファビコンの元となるデータは

基本、Fireworks のベクトルデータ（png形式）ではないでしょうか。

pngデータなら透過ファイルを作成するのは簡単です。

実はこれが厄介な事態を引き起こすことになっていました。

png透過データからfavicon.icoファイルを作成すると、

透過部分の背景が真っ黒になってしまいます。

規格上、背景は透過のままであるべきなのですが、

ブラウザー上で黒になるのだから、仕方ありません。

（ウェブ制作上、何もファビコンに限ったことではありません。）

納得できないまま、

試しに透過pngファイルを透過gifファイルにしてみました。

透過gifファイルを元にfavicon.icoファイルを作ると

あっけなく上手く行きました。

キレイなものを作るためには、元データはより質の良いpngファイルで、

という気持ちが却って上手くいかない結果を招いていたんですね。

また、元ファイルのアイコンの形状によっては、

16×16pxのキレイなアイコンを作るのは困難な場合もあります。

実は、弊社のロゴがそれに当てはまります。

16×16pxファビコンではカーブをキレイに表現できないんですね。

なんども試してみて、結局今回は16×16pxファビコンの層を無くして

32×32pxと48×48pxの２層のファビコンにすることにしました。

（結果的にこれが一番キレイに見えたからです。）

もっとも、現時点で透過ファビコンが一番問題になるのは Firefox です。

特にMac版は透過部分のブラウザー背景となる灰色が濃いので、

キレイに透過しないと見栄えが良くありません。

他のブラウザーは背景が白色なので、問題はありません。

実のところ透過にしないで、ファビコンの背景を白色にしてもOKです。

なお今回、様々なファビコン作成ウェブ・サービスを試してみましたが、

次のサイトがベストだと思います。

（機会があれば操作手順も解説できればとも思いますが。。。）

　　▶ FavIcon from Pics（英語）

このウェブサイトでは、同時に

iPad・iPhone・iPod touch 用の WebClipアイコンも作成できますが、

ウェブクリップアイコンのフォーマットは png なので、

Fireworks などのベクトルデータのままでOKです。

ファイル名は「apple-touch-icon.png」にします。

pngのファイルの大きさを57×57pxにすればいいだけのことです。

（後は勝手に iPad・iPhone・iPod touch がキレイにアレンジして表示してくれます。）

注意点は、pngファイルを透過にすると、

iPad・iPhone・iPod touch の透過の背景のデフォルトが黒色だということです。

ウェブクリップアイコンの背景は透過にしないほうがいいでしょう。

後は（X）HTML内のhead内に以下の２行を追加すればＯＫです。

（例のURLは弊社の場合。ブログ表示用に括弧には全角文字を使用。）

＜link rel="shortcut icon" type="image/x-icon" href="http://www.designcross.org/favicon.ico" /＞

＜link rel="apple-touch-icon" type="image/png" href="http://www.designcross.org/apple-touch-icon.png" /＞

特別な意図がなければ、トップページのあるサーバーの階層に

ファビコンとウェブクリップアイコンをアップロードします。

ちなみに iPhone・iPod touch の画面のキャプチャーは

「ホームボタン」を押したままの状態で「電源ボタン」を押して

おこないます。

Mac の場合、

iPhoto 経由でパソコンにキャプチャー画像を取り込めます。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

後日（６月５日）、実際に iPad が届いたので、

自社のウェブクリップアイコンを確認すると、

アイコン画像が明らかに甘い（＝ぼやけている）。

（まあ、なんとなくは予想していました . . . ）

改めてWebClipアイコンについて調べてみると、

以下のことが判明しましたので追記しておきます。

　　57×57px（公式サイズ）

　　60×60px（標準クオリティ）

　　129×129px（最高クオリティ）

これからのこと（iPad対応）を考えると、129×129px が無難だと思われます。（実際にはどんなサイズでも表示されます。）

早速デザクロのアイコンも129×129px に変更しました。

ベースがベクトルデータで作ってあれば、

比較的簡単に変更できます。

57pxか60pxのどちらが最適かという問題については、

アイコンにする元画像の性質によって異なります。

　　「階調が多く直線が少ない画像」では60px

　　「細い直線が多い画像」では57px

のほうが一般にはキレイに表示されます。

最終的には実際に試してキレイなほうを選ぶことをオススメします。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

日本時間６月８日、新しいiPhoneが発表されました。

それを受けて追記。

今度のiPhoneの画面解像度は、

これまでの480×320pxから

960×640pxへと、大幅に高くなっています。

写真で見る限り、ウェブクリップアイコンの見た目の大きさは変わりありませんから、

解像度的には、これまでの57×57pxの２倍相当になっているものと考えられます。

だとすると、129pxあれば充分だと判断つきます。

逆に57pxのウェブクリップアイコンのままだと、

相当ボケボケのアイコンになってしまうでしょう。

Tweet