Moz - SEOとインバウンドマーケティングの実践情報

レスポンシブデザインがすべてではない:マーケターが適応するべきデザインと開発のトレンド(後編)

モバイル専用サイトやAjaxによる動的サイトなど、レスポンシブデザインではないサイトデザインの可能性について探ってみよう

3回に分けてお送りしてきたこの記事も、今回が最終回だ。後編となる今回は、モバイル専用サイトやAjaxによる動的サイトなど、レスポンシブデザインではないサイトデザインの可能性について探ってみよう。
→まず前編中編を読んでおく

モバイル専用サイトに立ち返るサイトもあるが、それはそれでいい

グーグルはレスポンシブデザインを「好んで」いて、レスポンシブサイトを優遇して検索順位を引き上げると言われている。しかし僕は、実際にはそんなことはないと思う。グーグルは、利用されているテクノロジに関係なく、ユーザーが求めるものを提供するサイトを好むのだ。

確かにグーグルは、レスポンシブデザインを推奨している。僕だってそうだ。だが、僕が推奨する理由は、マルチデバイス向けアプローチとして管理が群を抜いて容易で、完全な失敗に陥るということがまずないからだ。だからといって、これが唯一の方法だというわけではないし、別の方法で優れたモバイル体験を提供するサイトにグーグルがペナルティを科すわけでもない。

モバイル専用サイトには多くの利点がある。モバイルユーザーの意図や行動がデスクトップユーザーとは明確に異なっているようなサイトの場合、モバイル固有の体験を生み出すのは当然だ。

なによりも、読み込みの速いサイトにするという点でも優れている。

フォーマット別のページ平均読み込み時間(秒)
平均読み込み時間
モバイル専用サイト
レスポンシブウェブデザイン
デスクトップ

The Search Agencyのレポートによると、一般にレスポンシブサイトは読み込みがはるかに遅いという。

サイトをレスポンシブにしてなおかつ高速化することはできるし、高速化するべきではあるが、ほとんどのレスポンシブサイトがモバイルで遅くなってしまう理由はたくさんある。動的に表示されるサイトもモバイルサイトも、本来スピードを意識して構築するものだ。モバイル専用のサイトは、その時点でユーザーの意図に理想的な体験も提供できる。

2015年7月、シンディ・クルム氏はMozConのプレゼンテーションで「モバイルにおける意図」について語った。バズワードだと言われそうだが、モバイルユーザーが特殊であることは事実だ。彼らは、次のような特性をもっている

  • あまり比較しようとしない
  • すぐに購入したがる
  • 製品について手軽にわかる情報を得たがる

モバイルサイトを手がけることを考えているなら、正しく構築して、かつ維持するために、多くのスタッフを用意しておこう。サイト全体にかかる開発時間を過小評価してはいけない。relタグを設定できるSEO担当者が必要だし、理想を言えばモバイルサイトも同じURL構造にしなければならない。どのページタイプも正しく機能させるためにはたくさんの検査確認が必要になるだろう。

SEO担当者の中には、モバイル用のサブドメインやサブフォルダについて、そういったサブドメインやサブフォルダに張られたリンクはメインサイトへのリンクとみなされないため、SEO的に不利になると言う人がいる。ナンセンスだ! そのために「rel="canonical"」タグや「rel="alternate"」タグがあるのだ。

昔は、URLが「www」で始まっていないページを「www」バージョンに301リダイレクトすることについて思い悩んでいた時期もあったかもしれない。それと同じことで、今はもう以前ほど気にする必要はなくなっている。グーグルは賢くなっているので、実装が間違っていない限り、状況を把握できる。

大多数の企業にとって、やはりレスポンシブデザインはよりよい選択肢ではあるが、それだけにとらわれなければならない理由はない。グーグルが3つのオプションを提示しているのは、提示すべき理由があるからだ。モバイルサイトは大企業に効果的で、巨大なEコマースサイトには最善の選択肢という場合が多い。

ウェブ開発は進化し続ける――JavaScriptライブラリだって同様だ

SEO担当者は、JavaScriptの利用に関してすでに時代後れになったアドバイスをするというへまをやらかすことが、しばしばある。SEOは、優れたコンテンツがより多くの検索結果でより多くの人に表示されるようにするものでなければならない。絶対にそうしなければならないという場合でない限り、SEOは有用なコンテンツ作成ツールを排除するために使われるべきではない。

SEOではこれまでずっと、「クローラーに見てほしければ、コンテンツをJavaScriptに組み込むな」というのが賢いやり方だった。しかしこれは、2015年のウェブサイトに対するアドバイスとしてはもう古い。ReactやAngularJSなどのライブラリは素晴らしいツールになり得る。機能満載で、楽しく使えて、ウェブサイトがより高速でレスポンシブだと感じさせてくれる。

もちろん、グーグルにコンテンツを認識してもらったうえでだ。そう。グーグルはすでにクロール・インデックスにおいて、JavaScriptを実行した結果を評価できるようになっている。

グーグルが有意義なユーザー体験を優遇したいと考えているなら、そして、サイトオーナーにとってJavaScriptが優れたユーザー体験を提供する助けになるなら、SEO担当者はJavaScriptを受け入れるべきだ。サイト上のJavaScriptにやみくもに反対するのではなく、僕たちのアプローチ法をもう少し改善して、チームがツールを正しく使えるよう支援するべきときに来ている。

ReactやAngularJSといった優れたJavaScriptフレームワークによって動的コンテンツがより楽しく使えるようになるのは間違いないが、グーグルが(まだ)よく理解していないAjaxのようなクライアントサイドの実行も多用することになる。開発者やSEO担当者は、うまく機能させる方法を認識する必要がある。

Ajaxをグーグルに合わせて最適化することについては、それだけで記事が書けるかもしれない。実際、すでにいくつか素晴らしい記事がある。グーグルも優れたガイドを提供しているので、以下のリンクからこれらのリソースも確認してほしい。ただし、念のため忠告しておくが、このトピックについては古くなった情報もたくさんある。

さらに技術的な話しにはなるが、PrerenderV8などを使うと、核心となるテクニカルSEOの多くを自分でやらずにすませられる。Ajaxを使いながら、クロール可能なバージョンを自動生成するツールを探そう。開発者と話し合って、自分の設定でうまく機能するソリューションを見つけてほしい。

悲惨な例

すでに述べたように、構築にかかる前に開発者とコミュニケーションを取ることが重要だ。先ごろ僕が味わった苦い経験を例に挙げよう。

僕たちは、必要なインターネット速度を初心者でも見積もれるよう支援するReactベースのツールを開発した。しかし、このツールには、SEOにおける大きな問題点があった。

というのも、すべての訪問者が即座に1つのURLにリダイレクトされるのだ。調査がいくつかのページで行われるのだが、それらのコンテンツに個別のURLは存在せず、クライアントサイドで実行しなければコンテンツは一切クロールされなかった。

なんてことだ! 僕たちはきわめて優れたツールを構築したのに、それをグーグルがちゃんとアクセスできないようにしてしまったのだ。見落としたやつを解雇してもらわないと……(ただし、それが僕だったことは内緒だ)。

僕たちは使ったReactというJavaScriptフレームワークは、素晴らしかった。このサイトにより、ユーザーから嬉しいフィードバックも受け取った。

問題だったのはReactやAjaxではない。大切なのは、そうした技術を使わないようにすることではなく、早めに開発者にSEOの要件を伝えることだ。修正はすぐになされるだろうが、事前に適切な配慮をしていたら、それに要する工数もずっと少なかっただろう。

グーグルに合わせたJavaScriptの実装を理解することは、すべてのSEO担当者の責務だ。SEO担当者以外のデジタルマーケターは、少なくとも潜在的問題と技術的解決策があることは認識しておかなければならない。

僕は、高速で便利なインタラクティブツールが大好きだ。SEO担当者は、素晴らしいものを構築するよう後押ししなければならない。これはつまり、現代のウェブで広く使われているツールセットのすべてに反対するのではなく、解決策を見つけるよう支援するということだ。

インデックス可能なアプリを忘れてはいけない

グーグルは今やアプリのインデックス化とランク付けができるようになっており、やり方についてそれなりのガイドラインも提供している。モバイルだけを利用する顧客を基盤とするアプリベースの企業では、従来型のウェブサイトは不要といってもいい場合さえある。

ほとんどの企業は今後もウェブサイトを構築して維持したいと考えているだろうが、小規模なモバイルゲーム開発企業では、レスポンシブサイトが最善の選択肢ではないこともある可能性を考慮する姿勢を持とう。コンテンツやディスカッションへのリンクを加えて、アプリ内でのディープリンクをサポートするほうが正しい選択肢かもしれないのだ。

アプリだけというやり方が正しい選択肢ではないとしても、すでにアプリをインストールした人にとって、アプリ内のコンテンツは、より魅力的な媒体になり得ることを考慮しよう。たとえば、ゲームプレーヤー向けのディスカッションボードはゲームアプリ本体の中にある方が効果的かもしれない。ユーザーがアプリから離れずに他のユーザーに質問したり、最新のアップデートを話題にしたりできれば、より魅力が増し、没入感が得られるのは間違いない。

終わりに

デザインを幹部にプレゼンするとき、ウィンドウを拡大したり縮小したりして見せれば、素晴らしいサイトに見えるだろう。しかし、実際の意思決定者であるユーザーがハンバーガーメニューを知らないのなら、地球の素材写真をどんどん売り込んだりはしたくない。レスポンシブデザインは素晴らしい選択肢であり、多くの場合、正しい選択肢でもあるが、唯一の選択肢ではない。この記事が、レスポンシブの正しいやり方について考えるきっかけになることを願っている。

もちろん僕は、レスポンシブが死んだと言っているわけではない。僕が言いたいのは、僕たちのアドバイスがデザインや開発に取り入れられるとしたら、より具体的なアドバイスができなければならないということだ。画面サイズに対応するウェブサイトを構築するだけではだめなのだ。顧客のニーズに即座に対応するウェブサイトを構築しよう。

用語集
JavaScript / SEO / インデックス / クローラー / クロール / ディープリンク / フィード / リンク / 訪問者
この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

インデックス
検索エンジンがWebページをデータベースに保存しているデータベース。データベース ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]