SEO業者の大半は詐欺と言っていい

「検索順位で1ページ以内に表示させます」と豪語する業者がいますが、そんな業者にSEOの依頼をする意味はありません。

理由はシンプルで、実現できるケースが少ないのと、実現できても、そもそも意味がないからです。

検索結果で1位になったのに、注文が来ない

例えば、ある会社がSEO業者に月額1万円でSEOを依頼して特定のキーワードで一位になったと喜んでいたのですが、それでも注文がこないと私に相談しに来られました。

確認したら、確かにあるキーワードで一位なのですが、検索エンジンのクロールを抜いたアクセス解析の結果が、1日の平均UU(訪問者数)が約30、PV(総閲覧ページ数)で約50でした。

それもそのはずで、その会社固有のサービス名で一位になってただけで、検索エンジンからの訪問者数は皆無に近い状況だったのです。

業界トップ企業のサービスなど、よほど市場で認知されたサービスでもない限り、会社固有のサービス名をキーワードとして検索する人はいません。これは極端な例ですが、似たようなケースがほとんどです。

また、ユーザーは様々なキーワードまたはそれらを組み合わせたもので検索するので、特定のキーワードでの検索順位で一喜一憂するのは、とてもバカバカしく意味のないことです。

もし、特定のキーワードでの検索結果が売上に大きく影響するのなら、SEO業者にお金を払って不確実なプロモーションをするよりも、Googleにお金を払って検索結果トップの広告枠に表示した方が、遥かに安全で費用対効果も高いのです。

ですから、「検索順位で1ページ以内に表示させます」なんて言ってしまう業者にお金を払う意味はないのです。

SEOとは、Webサイトのコンテンツを検索エンジンに正しく評価させること

ユーザーにとって大して価値のないWebサイトが、何か特別な技術で検索結果の上位に来るようであれば、誰もその検索エンジンを良いモノとは認めません。ごく限られた期間にそのようなことが起きえたとしても、検索エンジンはそのようなケースを減らすべく、随時検索順位を決めるアルゴリズムを改善しています。

検索エンジンのビジネスモデルを支えるベースは、「ユーザーにとって価値あるコンテンツを届けられる」ことです。検索エンジンは、それができるからユーザーを獲得でき、広告モデルを成り立たせることができるのです。

ですから、Webページの最適化で最も重要なのは、「検索エンジンに合わせる」ことではなく、「ユーザーに価値あるコンテンツを発信し、それらが快適に見られるようにする」ことです。そうすれば、自然と検索エンジンにも高く評価されるようになりますし、何よりユーザーに評価されるのできちんと収益に繋がります。

本来のSEOとは、検索エンジンに「Webサイトの価値を正しく評価させる」ためにコードを最適化することであり、「Webサイトの価値を本来の価値以上に粉飾する」ことではないのです。

Webサイトの本来の価値を高めずに、価値を粉飾することに必死になって投資をしても何の意味もないのです。そんなWebサイトは検索エンジンもユーザーも価値を認めません。


Webページの読み込み速度を向上させ、検索エンジンの評価を高める

1年前に書いた「Webページの読み込み速度を高める」と最近書いたWebサーバの話をベースに、Webページの読み込み速度の向上について、少しまとめます。

Webページの読み込み速度が検索エンジンの評価に影響する

1年前に、GoogleがWebページの読み込み速度をサイトの評価項目として採用したことを発表しました。

単に速ければ速いほど評価が高いというわけではなく、1ページの平均読み込み速度が1.4秒以内に収まるかどうかが評価基準になるようです。

ページの読み込み速度は、Google ウェブマスター ツールの「Labs」にある「サイトのパフォーマンス」で確認できます。

Google Webmaster Tool

この例だと、ほぼ「遅い」と評価されています。

サーバのチューニングやキャッシュ処理をさせているのですが、それでもサイト内のほとんどが動的ページで重たい処理をさせているので、このくらいの速度になっています。

あとは、もっとパフォーマンスの高いサーバに切り替えるなどハードに投資すれば、おそらく「速い」になると思います。

ただ、サイトの読み込み速度が速いと検索エンジンの評価は高くなりますが、あくまで評価項目の一つであり、それだけで劇的に良くなるわけではないので、あまり無理してコストをかける意味はありません。

ここでは、固定コストをかけずにできる高速化を紹介します。

Webサーバの処理を高速化する

Webページの読み込み速度を高速化する主な方法の一つは、Webサーバの処理を高速化するということになります。

以前の記事、「最低限やっておくといいApacheチューニング」と「簡単にできるWebサーバの負荷軽減」を参考にWebサーバの処理を高速化してください。

その記事の中では言及しなかったのですが、htaccessと同様にコンテンツネゴシエーション(mod_negotiation.so)もそこそこ遅くなります。使うことがなければ無効にしてください。まず使うことはないので、その記事ではこのモジュールを無効にすることを推奨しています。

コンテンツデータの最適化

もう一つ主な方法となるのがコンテンツデータの最適化です。

こちらは「Webページの読み込み速度を高める」と「SEOのため、PNGのファイルサイズを極限まで縮小させる」という記事を参考にしてください。

一点、そこで紹介しているAdobe Spryのpackedについて補足すると、「ライブラリは縮小版を使うべき」ということです。

jQueryやAdobe Spryなどのライブラリは、特別な理由がなければ、可読性を無視してファイルサイズを縮小したもの(jQueryならMinified、Adobe Spryならpacked)を使ってください。これだけでWebページの読み込み速度が速くなります。

ハイパフォーマンスを追求する

Webサーバの処理の高速化も、コンテンツデータの最適化も、ここで紹介しきれないほど様々な方法があります。

紹介した別記事の中でも何度も推薦していますが、オライリーの「ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール」と「続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス」の2冊は、本当に良くまとめられているので、是非読んでみてください。

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール
  • HTTPリクエストを減らす
  • CDNを使う
  • Expiresヘッダを設定する
  • コンポーネントをgzipする
  • スタイルシートは先頭に置く
  • スクリプトは最後に置く
  • CSS expressionの使用を控える
  • JavaScriptとCSSは外部ファイル化する
  • DNSルックアップを減らす
  • JavaScriptを縮小化する
  • リダイレクトを避ける
  • スクリプトを重複させない
  • ETagの設定を変更する
  • Ajaxをキャッシュ可能にする

続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス

続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス
  • Ajaxアプリケーションとパフォーマンス
  • 応答性の高いウェブアプリケーション
  • 初期ロードの分割
  • 実行をブロックしないスクリプトのロード
  • 非同期スクリプトの組み合わせ
  • インラインスクリプトの適切な位置
  • 効率的なJavaScriptコード
  • Comet
  • gzip圧縮再考
  • 画像の最適化
  • 主ドメインの細分化
  • ドキュメントのフラッシュ
  • iframeの取り扱い
  • CSSセレクタの単純化

SEOのため、PNGのファイルサイズを極限まで縮小させる

前回の記事のとおり、GoogleがWebページの読み込み速度をサイトの評価項目として採用したことで、画像のファイルサイズの縮小は有効なSEOとなりました。(今のところ日本では評価項目になってないかも)

前回の記事では、画質を落とすことなく GIF や JPEG よりもファイルサイズを小さくできる PNG に画像形式を替えることを紹介しましたが、単に画像編集ソフトでPNG形式で保存するだけでは、あまりファイルサイズを縮小させることができません。

今回は、PNG形式の画像のファイルサイズを極限まで縮小させる方法を紹介します。
Continue reading


Webページの読み込み速度を高める

先日、GoogleがWebページの読み込み速度をサイトの評価項目として採用したことを発表しました。

単に速ければ速いほど評価が高いというわけではなく、現在で1ページの平均読み込み速度が1.4秒以内に収まるかどうかが評価基準になるようです。

ページの読み込み速度については、Google ウェブマスターツールやGoogleが配布するFirefoxアドオン「Page Speed」で確認できます。

この発表を受けて、Webページの読み込み速度を高めるために自社サイト「エクストリームオンライン」を以下のとおり更新しました。

読み込み頻度の高い画像を PNG に変更

ロゴや見出しの背景など、読み込み頻度の高い画像を、画質を落とすことなく GIF や JPEG よりもファイルサイズを小さくできる PNG に置き換えました。

これまでは互換性の問題から PNG の利用を控えていましたが、PNG が正しく表示できないブラウザを使っている人はほぼ皆無になったこと(携帯電話のブラウザはいまだに多いので注意)と、ページ読み込み速度がサイトの評価項目として採用されたことで、画像のファイルサイズの縮小を優先することにしました。

Adobe Spry のスクリプトを packed に変更

Adobe Spry のスクリプトを組み替えることも、コードを読むこともないので、可読性を無視してファイルサイズを小さくした packed に置き換えました。

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

今回は上記二点のみの対応となりましたが、これまでにも様々な高速化の取り組みを行ってきました。

その時に参考にしたのが、ウェブサイトの高速化についてフロントエンドの処理を中心にまとめた「ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール」という書籍です。

インターネット上でも様々な情報を探せますが、どうでもいいような小技の羅列が多いので、本質的なウェブサイトの高速化を学び、実践するまでにはかなりの時間がかかるため、この書籍で勉強することをお勧めします。

フロントエンドエンジニアの方はもちろん、ウェブデザイナーの方にも、是非読んでほしい一冊です。

また、続編として、「続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス」が出版されています。

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス

続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス

自社サイトの横幅を950ピクセルに変更

2007年の時点で、ほとんどのユーザーが横幅1024ピクセル以上のPCを利用しており、2008年1月には、国内最大のポータルサイト Yahoo! JAPAN がWebサイトの横幅を950ピクセルに変更しました。

この後、その他の主要サイトも次々と追随したため、現在では、Webサイトの横幅は950ピクセルにしてもよいというのが一般的な考えになっています。

私は、最近のUMPCの普及により、さらに状況は進展していると感じています。UMPCは、一般的なもので横幅1024ピクセル、製品によっては1280ピクセル以上と横幅は十分ですが、逆に縦幅については一般的なもので600ピクセルとかなり物足りない状況です。これだけ縦幅が狭いと横幅の狭いWebサイトを閲覧するのはかなり非効率でストレスもかかります。

横幅800ピクセル以下のユーザー数とUMPCのユーザー数を考えれば、横幅950ピクセルへの拡張は、「してもよい」から「した方がよい」に変わるべきだと思います。

そう思い始めてから、少し時間がかかりましたが、ようやく自社サイトの横幅を760ピクセルから、950ピクセルに変更しました。