検索エンジンにとって SVG はテキストデータではなく、見ているのは最終的にレンダリングされた画像として見える SVG のみ。

Google 検索が、SVG をインデックスの対象としたのは 2010年9月。その頃から今まで多少の変化は見られますが、認識能力はあまり変わっていない印象を受けます。

Google 検索エンジンは、xlink、title、desc、text、著作権情報などの SVG 内の情報を一切見ていない。

Width と Height も見ていませんが、GoogleBot がレンダリングする際に影響が出ます。

以前は記載がないと最小のエリアで検索結果に表示され、何の画像か分からないどころか見つけるのすら困難でした。

基本的な SVG の描画に Width と Height は不要ですが、Google 画像検索の結果に正しくない縦横サイズが表示されるなど影響があるので、記述は残しておきます。

<svg x="0px" y="0px" width="1200px" height="1200px" viewBox="0 0 1200 1200">

HTMLへインラインで埋め込んだ SVG は画像検索に現れません。検証を継続中ですが、通常の検索では、<desc>タグや<text>タグ内のテキストは認識されスニペットに表示されるの確認しています。

これらは近接テキストとして見ているようで、「画像の」とは見ていないと思われます。

通常検索では、<svg>のタグはスルーされているように見えます。文字列としては意味のない<path>などのタグは取り払って、理解できるテキストのみを抽出しているようです。

画像を検索するユーザーには大きい画像が好まれるので、なるべくサイズを大きく指定しておくと効果的です。

ただし、あまり大きくするとプレビュー時に何の画像か分からなくなるのと、ベクター画像は拡大しても見た目は変わらないものの、縦横のサイズを大きくするにつれて各パスの座標の桁数が増えてファイルサイズも大きくなるので、最大でも 1200px くらいまでがいいでしょう。

ベクトルでも拡大縮小を繰り返すと小数点以下の切り捨てで少しずつ誤差が出たり、<rect>,<circle>等の基本図形がただの<path>になってしまうので、アイコンに SVG を使うなら初めから表示する予定の大きさで作成するのがベスト。実際は <path> の方がデータ量は少なくなりますが、CSS 装飾で不整合がおこる可能性があるので念のため。

役割がほぼ決まっているなら、パスのアウトライン化をしなくても線のまま使えばファイルサイズも小さくなります。

32px のアイコンでは、中間色のある PNG の方が綺麗に見える事が多々ありました。また、ものによりますがファイルサイズも概ねPNGのが小さくなりました。実用重視ならアイコンのような小さい画像は PNG の方が良いかもしれません。

SVG はベクトルのデータなので、ブラウザがレンダリングする際に計算が必要です。

少し古めのパソコンで SVG アイコンをビッシリ敷き詰めたページを表示してスクロールさせると明らかに重くなるのを確認できます。

最新のデバイスなら、ほぼ問題にはなりませんが、負荷が掛かっていることに変わりはないので、ちょっとだけ頭の片隅にとめておくべきです。

URL フラグメントを使って表示を切り替える SVG の手法は画像検索で透明画像で表示されます。検索クエリが、alt や近接テキストにマッチすると検索結果に表示されます。

これは先ほどの Google は最終的にレンダリングされたものしか見ていない裏付けの 1つにもなっています。

検索者が SVG を知っていればソースを確認するかも知れませんが、普通は素通りされるので SEO の効果は期待できません。汎用的に使用するものだけに利用すべし。

Google は xlink を見ておらず、リンクを辿らないので、外部リンク、内部リンクの被リンク効果を期待するなら、通常の画像と同じように、<a href=""></a> で囲った方が良いです。

ただし、画像のプレビューからの流入もあるので、xlink 自体は無駄にはなりません。

xlink を使うなら名前空間の xmlns:xlink="http://www.w3.org/1999/xlink" は必要です。

Google 検索結果の右上に大きく表示されるナレッジグラフには、掲載されたサイト以外の画像も引用表示されます。

ナレッジグラフには、Wikipedia の記事が多く出現します。日本にはフェアユースの概念がないので en.Wikipedia と比べて、ロゴなどごく一般的に使われている画像でも掲載されないことが多く、難易度の高いクエリでも画像は結構狙い目です。

ナレッジグラフに表示される画像は正方形です。透明背景を少なくして、うまく正方形に収めるときれいに表示されナレッジグラフの画像からの流入も期待できます。

Google+、Twitter、Facebook、いずれも SVG 画像は対応しておらずシェアできません。Pinterest も候補には表示されますがピン不可。

ソーシャルメディアとは違いますが、このブログで利用しているシェアボタンの AddThis は SVG画像を認識する珍しい例です。

ベクトルを扱えるユーザーなら PNG を起こすのは造作もないこと。別途 OGP 画像を用意しておきます。PNG8 (256色)だと、ディザや白マット、黒マットなどの調整が面倒なので、容量はかさみますが、思い切って PNG24 にしてしまうのがおすすめです。

構造化データ テストツールでは、単に、<img itemprop="image" src=""> は O.K ですが、itemtype="http://schema.org/ImageObject" のitemprop="url" に SVG へのパスを指定すると「image.url」には有効な URL を指定する必要があります。とでてエラーになります。

当初はエラーの理由が分かりませんでした。

Articles のAMP logo guidelines のロゴ画像の解説の「SVG は不可」の記載からのものと思われますが紛らわしくなっています。

つまり、構造化データとしては正しいけれど、Google は認識しないということです。

SVG が実際に使われ出したのは IE9 以降。比較的新しい技術なので、あまり解説やツール類は揃っていないのが現状です。ツールはそこそこありますがSVGの特性を出し切れておらず、最適化するには、まだ手動でのテキスト編集が必須です。日本語の総合的な解説は「svg要素の基本的な使い方まとめ」さんが唯一といっていいです。SVG 関連語で検索すると大抵ヒットします。

SVG 画像を扱うには、HTML や CSS やベクター画像を作成できる知識が必要です。前 2つはセットですが、ベクター画像の作成はほぼ別分野なのでハードルが高くなっています。

それにまして難しいのが SVG を取り巻く環境です。

ブラウザごとの対応状況。Adobe Illustratorから SVG で出力する複数のフォーマットの選択。InkscapeのSVGとの違いや変換方法、名前空間の扱い。XMLファイルの中で不要な記述、必要な記述。WebサーバーでSVGを表示する方法やDEFLATEして送信する方法などなどなどなど。

挙げたのはほんの一部ですが、これら実践しないと分からない事やSVGの仕様とは直接関係のない分野に対応するために、立ち止まって新しい知識の吸収が必要でした。

それゆえ、SVG は新しい技術ながら経験が物を言う技術だと思います。