Web制作で SVG ベクター画像をよく使っています。経験してみて初めて分かった現在の SVG を取り巻く環境や Google 検索と SVG の関係についての考察記事です。
まだ SVG を使ったサイトさんは少ないですが、ベクトルの画像をWebで表現するには、Flash が終了した現在、現実的に SVG しかないので、これから増えていくのは確実です。
先行して使ってみての経験則になりますが、ちょっとだけ詳しくなったので、これから SVG を使ってみようというウェブマスターさんの参考になればと思います。
SVG は画像
検索エンジンにとって SVG はテキストデータではなく、見ているのは最終的にレンダリングされた画像として見える SVG のみ。
Google 検索が、SVG をインデックスの対象としたのは 2010年9月。その頃から今まで表示方法の変化は見られますが、認識能力はあまり変わっていない印象を受けます。
Google 検索エンジンは、xlink、title、desc、text、著作権情報など SVG 内の情報を一切見ていない。
SVG の Width と Height と ViewBox は残す
Width と Height は GoogleBot がレンダリングする際に影響が出ます。
以前は記載がないと最小のエリアで検索結果に表示され、何の画像か分からないどころか見つけるのすら困難でした。
基本的な SVG の描画に Width と Height は不要ですが、Google 画像検索の結果に正しくない縦横サイズが表示される、IE のバグで表示が崩れるなど影響があるので、記述は残しておきます。
ViewBox も残す。先の IE のバグは背景指定の場合ですが、こちらは、IE 11 で img にも影響が出ます。SVG 単体では正確に描画されますが、CSS で大きさを指定するとアスペクト比が崩れるパターンが存在します。
<svg x="0px" y="0px" width="1200" height="1200" viewBox="0 0 1200 1200">
インライン SVG は画像としては見ていない
HTMLへインラインで埋め込んだ SVG は画像検索に現れません。検証を継続中ですが、通常の検索では、<desc> タグや <text> タグ内のテキストは認識されスニペットに表示されるのを確認しています。
これらはテキストとして見ているようで、画像とは見ていないと思われます。
通常検索では、<svg> のタグはスルーされているように見えます。文字列としては意味のない <path> などのタグは取り払って理解できるテキストのみを抽出しているようです。
ページ コンテンツとは関係ない文字列が並ぶので、おそらく SEO にはマイナス。ソースも読みにくくなるので、JavaScript で動かしたいなど、やむを得ない場合以外は控えた方がよいでしょう。
* インライン <svg> 要素の場合は、<title> 要素を代替テキストとして使用できます。(2022年12月 公式ドキュメントに追加)
ただし、画像検索にインライン SVG は発見できず、ページ内での画像の評価の意味のようです。また、Bing Web マスター ツールで Title が 2 つある 旨の指摘がされます。
画像検索用に大きいサイズを指定しておく
画像を検索するユーザーには大きい画像が好まれるので、なるべくサイズを大きく指定しておくと効果的です。
site: でサイト内の画像を検索しても縦横のサイズの大きい画像が先頭付近に並びます。
ただし、あまり大きくするとプレビュー時に何の画像か分からなくなるのと、ベクター画像は拡大しても見た目は変わらないものの、縦横のサイズを大きくするにつれて各パスの座標の桁数が増えてファイルサイズも大きくなるので、最大でも 1200px くらいまでがいいでしょう。
アイコンと SVG
ベクトルでも拡大縮小を繰り返すと小数点以下の切り捨てで少しずつ誤差が出たり、<rect>,<circle>等の基本図形がただの<path>になってしまうので、アイコンに SVG を使うなら初めから表示する予定の大きさで作成するのがベスト。
実際は <path> の方がデータ量は少なくなりますが、CSS 装飾で不整合がおこる可能性があるので念のため。
役割がほぼ決まっているなら、線のアウトライン化をしなくてもそのまま使えばファイルサイズも小さくなります。
32px のアイコンでは、中間色のある PNG の方が綺麗に見えることが多々ありました。また、ものによりますがファイルサイズも概ね PNG のが小さくなりました。実用重視ならアイコンのような小さい画像は PNG の方が良いかもしれません。
SVG の描画には負荷が掛かる
SVG はベクトルのデータなので、ブラウザがレンダリングする際に計算が必要です。
少し古めのパソコンで SVG アイコンをビッシリ敷き詰めたページを表示してスクロールさせると明らかに重くなるのを確認できます。
最新のデバイスなら、ほぼ問題にはなりませんが、負荷が掛かっていることに変わりはないので、ちょっとだけ頭の片隅にとめておくべきです。
URLフラグメント
<![CDATA[
g { display: none; }
g:target { display: inline; }
]]>
</style>
URL フラグメントを使って表示を切り替える SVG の手法は画像検索で透明画像で表示されます。
検索者が SVG を知っていればソースを確認するかも知れませんが、普通は素通りされるので SEO の効果は期待できません。汎用的に使用するものだけに利用すべし。
Google は # 以下を使用しません。少し考えを巡らせて、じゃあ、どうやってこの画像を分類したかというと、画像は見えないが alt や 隣接テキストから判断して検索結果に表示したということになります。
リンクは画像の外側に付ける
Google は xlink を見ておらず、リンクを辿らないので、外部リンク、内部リンクの被リンク効果を期待するなら、通常の画像と同じように、<a href=""></a> で囲います。
ただし、画像プレビューからの流入もあるので、xlink 自体は無駄にはなりません。
ひとつ面白い話があって、海外企業のサイトに自分の SVG 画像が使われていたのですが、xlink を外していないため、うちのサイトへのリンクになっていました。
xlink を使うなら名前空間の xmlns:xlink="http://www.w3.org/1999/xlink" は必要です。
ナレッジグラフにも SVG は表示される
Google 検索結果の右上に大きく表示されるナレッジグラフには、掲載されたサイト以外の画像も引用表示されます。
ナレッジグラフには、Wikipedia の記事が多く出現します。日本にはフェアユースの概念がないので en.Wikipedia と比べて、ロゴなどごく一般的に使われている画像でも掲載されないことが多く、難易度の高いクエリでも画像は結構狙い目です。
ナレッジグラフに表示される画像は正方形です。透明背景を少なくして、うまく正方形に収めるときれいに表示されナレッジグラフの画像からの流入も期待できます。
ソーシャルメディアに SVG は表示されない
構造化データでの SVG の扱い
構造化データ テストツールでは、単に、<img itemprop="image" src=""> は O.K ですが、itemtype="http://schema.org/ImageObject" の itemprop="url" に SVG へのパスを指定すると「image.url」には有効な URL を指定する必要があります。とでてエラーになります。
当初はエラーの理由が分かりませんでした。
Articles の AMP logo guidelines のロゴ画像の解説の「SVG は不可」の記載からのものと思われますが、該当する画像のプロパティは logo ではないし、Review など他のタイプではエラーにならず 紛らわしい状態です。
つまり、構造化データとしては正しいけれど、Google は認識しないということです。
現在の SVG を取りまく環境
SVG が実際に使われ出したのは IE9 以降。比較的新しい技術なので、あまり解説やツール類は揃っていないのが現状です。
ツールはそこそこありますが SVG の特性を出し切れておらず、最適化するには、まだ手動でのテキスト編集が必須です。
日本語の総合的な解説はsvg要素の基本的な使い方まとめさんが唯一といっていいです。SVG 関連語で検索すると大抵ヒットします。
SVG 画像を扱うには、HTML や CSS やベクター画像を作成できる知識が必要です。前 2つはセットですが、ベクター画像の作成はほぼ別分野なのでハードルが高くなっています。
また難しいのが SVG を取り巻く環境です。
ブラウザごとの対応状況。Adobe Illustratorから SVG で出力する複数のフォーマットの選択。Inkscapeの SVG との違いや変換方法、名前空間の扱い。XML ファイルの中で不要な記述、必要な記述。Webサーバーで SVG を表示する方法や DEFLATE して送信する方法などなどなどなど。
挙げたのはほんの一部ですが、これら実践しないと分からない事や SVG の仕様とは直接関係のない分野に対応するために、立ち止まって新しい知識の吸収が必要でした。
それゆえ、SVG は新しい技術ながら経験が物を言う技術だと思います。