なぜSEOスパムとされる可能性があるといわれているか

間違わないで欲しいのが、画像置換を行う行為自体はSEOスパム行為ではない。文字を飛ばしても画像に置き換えているんだから、装飾のために見た目を変えているだけで、画像置換自体は文字情報を隠しているという訳ではないので、装飾のために行っている画像置換はSEOスパム行為ではない。ただ、この画像置換で使っているCSSテクニックで、テキスト情報を画像に置換して表現しているのではなく、「見た目は隠してあるからそんな情報が埋め込まれていることは分からないんだけど、実はSEO効果を狙ってHTMLにテキストが埋め込まれている」ということを行うことができ、これは明らかにSEOスパム行為である。この行為が増えた場合は、検索エンジンがこれをSEOスパムと判別するようになるかもしれないので、これと同じテクニックを使っている前者を区別するすべが難しいため、SEOスパムとされてしまう危険性があるとされている。

アクセシビリティの為に、例えば音声ブラウザの為に、見た目上は見えないんだけど音声ブラウザで読み上げると「ここからナビゲーションです。」といった情報を出すというのもあるけど、これも上記の画像置換と同様にSEOスパムとされる危険性はあるとされている。スパム行為じゃないのにね。

実際に画像置換のテクニックを使っていたサイトが、SEOスパムとされて検索エンジンに表示されなくなったりしたという話は聞く。ただ、これの真偽は、SEOを生業としていない俺には分からない。

そういや、例えばスペーサーにテキストを入れて記述しまくるSEOスパムとかあったけど、スペーサー使うとSEOスパムとなっちゃう危険性があるからスペーサーは使わないって話は聞いたことないな。

文書構造と装飾をHTMLとCSSに分けるべき

例えば見出しの場合、見出しとは「それ以下のコンテンツが何を表しているかを簡潔に表し、文章を読みやすくするもの」なので、デザイン性はHTML文書としての情報には含まれず、「それ以下のコンテンツが何を表しているか」までが文書としての情報なので、テキストでマークアップしてデザインはCSSで再現するべきだとうい考え方がある。

これには利点がある。
同じHTMLで状況に応じてデザインを変えるということができる。例えば、iPhoneで見たときに見出しも画像でマークアップしてたら、重いし、デザインも変えれない（それこそimgを背景画像で置換すれば変えれる）けど、分けてあれば解決する。他には同じHTMLでCSSだけ変えて、まるっとサイトデザイン変えることもできる。blogなんかでは偶にある。

これらのことから、俺個人の理想としては、ロゴや挿入画像などのビジュアルも含めてコンテンツであるから、その見た目でその幅その高さであることまでが情報としてHTMLにマークアップされるべきであり、imgでwidthとheightとaltを設定すべき。見出しやリード文・背景などは、ビジュアルはHTMLに記述されるべきではないから、テキスト等でマークアップしCSSで装飾すべき。よって画像置換も現状で出来るCSSのテクニックとして全然有りだと思うが、そもそも、フォントとか画像にしないと駄目なデザインじゃなくて、デバイスフォントでも見栄えのよいデザインをすればいいじゃんと思う。なんなら、サイトにフォントを埋め込む？方法もあるよね。現状で使えるもんかは置いといて。
ていうか、SEOスパムなんてあるから問題になるわけで、今使えるCSSの仕様を最大限に利用して装飾を制御しようという試みは非常におもしろく素晴らしいことで、本来は問題視されることではないと思う。

因みにGoogleは、自サイトのロゴをdivと半角スペースでマークアップして背景画像として表示している。文字を飛ばしたり文字の上に被せたりしている訳ではないが。
もしかすると、画像置換がスパムと認識される可能性があるから、こうしているのだろうか？
しかし、これではHTML文書としてはどうかと思う。

こういう考え方に対するいいわけ

自分でいいわけ的にこういう考え方に対して反論してみる。

そのwebサイトにとってその情報はどんなものとしてHTMLに記述されるべきかと考えてマークアップすればよいって考え方をすれば、ある意味文書として情報だけHTMLに記述しているともいえるんでない？

そのwebサイトにとって、「そのデザインであることも含めて見出しとしての情報」であれば、例えば、印刷時にもそのデザイン通り表示したいってことは、「そのデザインであることも含めて見出しとしての情報」なのだから、そこまでを記述してHTML文書としてなりたつからimgでマークアップすればよい。

現状は「そのデザインであることも含めて見出しとしての情報」であるケースが多いように思う。「いかなる状況下においてもそのデザインであること」は重要視されるし、リニューアルの際は、コンテンツや構造自体が変わる。コンテンツや構造が変わらずにデザインだけ変えたいなんてケースは稀だ。

コーダーとしてはどうするか

以前は、普遍性が高いものだけ画像置換を行っていた。例えば、グローバルナビや各カテゴリの見出しを画像置換するし、それ以下の階層の見出しになると数も多くなって工数が多くなり対応しきれないため行わない。理由としては、冒頭の理由以外に以下の2点があったから。

• imgで入れると変な隙間が出るときがあるので飛ばした方が逆に工数がかからない場合がある
• 印刷時はそれ用のレイアウトを用意するようになるだろうと考えていた

しかし、現状は、以下の3点から通常は画像置換を行わないとしている。

• 噂の出所が増えてきた
• 今後altもすべての検索エンジンが検索対象に含む可能性はある
• 「印刷時にブラウザ表示と同じように表示したい」という要望が多い

検索エンジンがCSSまで読むことはないんじゃないかなと思うけど、SEOを生業としていない俺はそこまで詳しくもなく動向も読めず答えはだせないので、より無難な選択をすべきだろう。また、もし印刷時にブラウザ表示と同じようにしたいという要望が後から出てきたときの工数を考えると、かなりの手間になってしまう。よって、通常は画像置換を行わないという選択をしておいて、もしSEOやCMSなんかの運用上の理由で、画像置換を使ってくれという場合に使用するとしておくのが妥当だという結論。

まとめ

なんだか色んな話をまぜちゃってめちゃくちゃになってる気もするが、結局は、SEOはトレンドもあるので明確な答えは存在せず、都度対応するしかないんじゃないか、と思う。そのサイトで画像置換を行うかどうかは、今後の対応の工数と現時点での効果を比較し、妥当だと思われるところで手を打つのが無難なんじゃないかな。

画像置換については以下のメリット・デメリットをふまえた上で、そのサイトにとってどうすべきかを検討し、使用するしないを決定すべき。特に指定やこだわりがない場合は、imgで入れておくのが無難。

メリット

一枚のHTMLファイルからいろんなデザインを再現可能

HTML自体が軽くなる

再利用性が高くなる

デメリット

SEOスパムとされる可能性があるかもしれない

何もしていない場合の印刷時など、CSSオン・画像オフ環境で表示されない

MacBook を買って、いくつかwebオーサリングソフトを試してみた。結果、表題の件に行き着いた。なんだかんだで、Dreamweaver がいい。
というのは、あるかないかによってコーディングスピードに大きく関わってくる4つの機能を併せ持っているからだ。

1. 他のファイルとリンクしているファイルを移動したときにパスを更新
2. スニペット+キーバインド +閉じタグの補助+使用しているid/class名入力補助
3. 選択したテキストを囲んでタグをつける
4. 選択したHTMLタグに適用されているCSSプロパティの表示

上に挙げた4つの機能はどれも重要で、これらすべてを兼ね備えたものは他になさそうだった。

例えば、Codaというソフトはかなり気に入った。見た目が Mac らしくてとても美しい。ただ、機能の拡張性はないように思う。2のかわりに文字列tabで登録したコードを入れることができるのだが、3ができない。マークアップの際は、テキストを原稿からコピーしてきてからタグ付けというフローも多くなるためかなりのスピードダウンになる。2と3の併せ技はとてもすばらしいのだ。これは、vimのプラグインで凄く快適にできるようだが、これはオーサリングソフトではなくエディタなので、1や4はできない（と思う）。

1や4については、小さいサイトを制作している時はよいが、大きなサイトを制作するにつれて効果が大きくなってくる。中には途中でディレクトリ構造を変えなければならないときもある。CSSだって量が増えると意図しないところにかかっていたりする場合もある。これは特に複数人でやっていると、しっかりルール決めしていても、自分が思っても見ないところでハマったりするものだ。どこに書かれたどんなプロパティを継承しているかをいっぱつで見分けれるのは、そんな場合に効果絶大だ。

Dreamweaver は「</」を入力したらタグを閉じる、という設定にできるところもよい。これができないと、いちいち閉じタグをすべて打たなくてはならない。細かい機能としては「&」を入力すると、コードヒントで特殊文字がでてくるのもよい。

ただ、これは使用した Dreamweaver CS4 が試用版だからかもしれないが、Dreamweaver 8 の時にはできていたファイル一覧から画像をCSSファイルにドラッグするとパスが入る機能が使用できなかった。今までできてたものができなくなるとは何事だ？
また、環境設定で設定した文字コードと違うコードで記述されたCSSファイルを編集するときに文字コードを誤って認識、且つ、ツールバーなどから文字コードを変更することはできずいちいち環境設定を開かなければならない。というエディタとしては最悪な部分も併せ持つ。
その他CS4になって追加された機能のすべてを試した訳ではないが、よいと思ったものは何一つ無い（コード手打ちだからなのかもしれないが）。
コードナビゲータなんかは文字を入力している最中に出てきて打ってるコードが見えなくなる。うざいのでオフにした。
しかしながら、これらを差し引いても上記4つの機能を兼ね備えているということは重要であり、Dreamweaverが優れていると感じた次第だ。

次回は「Dreamweaver のこれだけはやれ！」を書こうかな。

コメントしようと思ったら、ちょっと長くなってしまったのでこっちに書きます。

で、よく記事を見ると、この人は「開発時間の20%もIE6対応に費やしている」ということを理由として述べている。しかし、はっきり言うがそれは多過ぎじゃないのか？ IE6対応に20％もの時間がかかっているなら、ちょっとスキル不足のような気がしますた。

成吉思汗にアイヌネギ : Stop developing for Internet Explorer 6 より

まず背景として、上の引用は外国のサイトを見て書いている。俺は英語を読むには時間がかかるのでそのサイトは見ていないのだが、日本でも IE 6 対応に相当時間がかかると言われているし、似たような話題もあった。それ自体はむしろおもしろいと思っていたが（けして推奨する訳ではなく）、上記引用元でも言われているように、そもそも IE 6 対応ってそれほど大変な作業じゃない。zoom: 1; という魔法の言葉もあるし。

もしかすると、例えば、モダンブラウザで先行実装されている CSS 3 の技術を用いたりして、最先端のテクニックを使った技術レベルの高いサイトを作ろうというときなんかは、それくらいの工数が必要になるのかもしれない。

俺は制作会社が作ったデザインをコーディングだけ行うというコーダーが本職の人間だ。
今の日本で、しかも外注に出そうと考えるサイトには、そのような企画はない。日本では IE しか使ってはいけないというところだってあるし、やっぱりユーザーが多いということで IE 6 / 7 最優先。そして web にかける予算も、あれば企画やデザイン、映像などもっと上流のところにまわすので、結局HTMLコーディングの予算はない。（スケジュールもきつきつだ！）
ニーズがそこにあるから、現状は「ちょっと古い技術をもっとも効率の良い方法でやる」のが最善の選択だ。
ただ、IE 6 は少なくともまだ2〜3年は残る。他のブラウザ達は Acid Test もクリアして新しい技術が日常的に使われ、今よりそれらのブラウザにかける工数は少なくなっているだろう。そんな過渡期には、IE 6 だけのために 20％ くらいの労力も要するのかもしれない。

それはどこに目標を定めるかにもよる。今みたいに「対象全部のブラウザで全く同じに見えるように」ではなく、「古いブラウザでは可読性を損なわない程度にそれなりに見れ、モダンなブラウザではよりリッチに見える」という方向に進めば、そんなにはかからないだろうし、かけていられない。そんな方向に向かうべきだ。少なくとも、コーダーの立場からみれば。

ブラウザエンジンが全部統一されれば、一番楽だとは思う。もう、全部 webkit でいいだろと。
まあ、そんな訳にも行かないので、IE 6 対応は必要だ。それを使って見てる人が大勢いるんだから。理想論で言えば、例え使用者が少ないブラウザであっても、最低限読めるようにするのは必要だと思う。ただ、それは上記のような背景に照らし合わせると、現実問題として難しい。作るだけならばまだしも、作ったら作りっぱなしと言うわけにはいかず、各ブラウザでのチェックもあるし稼働後の更新だってある。

結局何が言いたいのかというと、スキル不足にしろサイトポリシーにしろ、今この現状で、そんなにもの時間を IE 6 にかけている時間はかなり勿体ない。
IE 6 のことをそんなに考える時間があるなら、新しい知識や技術を一つでも取り入れた方がよい。

かくゆう俺も、なかなか時間を作れずにいる訳だが・・・。
取り敢えず、飲みに出歩くのを控えます（苦笑）

ちなみに、最近は印刷対応案件が増えてきた。
なんだか書いている内に他にも色々書きたいことが出てきた気もするが、まとまらなくなりそうなのでまた次回とする。