Webページの表示確認を700種類以上のデバイス・OS・ブラウザでシミュレートできるというサービスを紹介している。モバイル対応を進めている人には非常に便利だろう。ほかにも、スマホ対応・モバイル関連の情報を7本お届けする、モバイル大特集だ。
ブラウザ表示確認を、各種デバイス700パターン以上で手軽にできる便利サービス
検証に便利かも(BrowserStack)
スマートフォンやタブレットを含むさまざまなデバイス・OS・ブラウザでサイトがどのように表示されるかをシミュレーションできるオンラインツール「BrowserStack(ブラウザスタック)」を紹介する。
スマホ対応を進めている人も多いかと思うが、iOSとAndroidとPCとタブレットと……と、さまざまな環境でどのように表示されるのかを実機で確認するのは、大変な作業だ。
しかし、700種類以上の環境での表示をシミュレートできると謳うBrowserStackを使えば、そのチェックも楽にできるはずだ。
スクリーンショットも撮れるほか、表示だけではなく、指定したデバイスとOS、ブラウザをエミュレートして動作を確認するライブテストもある。それ以外にも多数の機能を備えている。
すべての機能を利用するには有料になるが、興味があれば無料アカウントで試してみるといい。
日本語で読めるSEO/SEM情報
グーグルのモバイルフレンドリー志向は2011年から始まっていた!?
慌てるのは放置していた自己責任(ホームページ集客のススメ)
モバイルフレンドリーのアルゴリズムの導入は唐突なことではありません。
グーグルは、5年も前からモバイルの重要性を言い続けてきました。
グーグルの長山氏は、The 13th In-house SEO Meetupでこういった趣旨の発言をした。
ピックアップ元記事は、(日本の)グーグルウェブマスター向け公式ブログが投稿したモバイル関連の記事を過去にさかのぼって集めている。
2011年5月の記事を皮切りに、毎年数を増やしながらモバイル関連の記事を継続して投稿しているのがわかる。急速に拡大するモバイルユーザーへの対応を喚起している記事も多い。
「モバイルフレンドリーの期日まで2か月しか猶予がない」と不平をいう人がいたとしたら、それは、ユーザーの変化に対応せずに放置していた自己責任だと言ってもいいだろう。
それはともかくとして、ここでリストアップされている過去記事を再度読み返しておくのは、いかがだろうか。ユーザー体験を高めるためにグーグルが推奨するモバイル対応のアドバイスを、たくさん入手できる。
グーグル社員が説明するモバイルフレンドリーテストの挙動
CSSやJavaScriptのブロックは避ける(グーグル ウェブマスター向けヘルプフォーラム)
表示されていた「スマホ対応」ラベルが何かの拍子で消えてしまったという相談が、グーグル公式ヘルプフォーラムであった。この質問へのフォローのなかで、グーグル社員のTakeaki氏が次のようなコメントを残した。
1) モバイル フレンドリー テストは、修正後のページのチェックを目的としているため、ライブ データをチェックしていますが、モバイル ユーザビリティ ツールや実際のインデックスではライブ データを見に行っているわけではありません。毎回完全に同一手順でクロールをすることは保証できませんので、モバイル フレンドリー テストはあくまでクロールができた場合の判定結果として利用いただければと思います。
2) CSS や JavaScript ファイルのようなレイアウトなどに影響のあるファイルのクロールを制限しないようにお願いします。クロールが制限されますとサイトをきちんと解析することが難しくなってしまいます。
つまり、こういうことだ。
モバイル フレンドリー テストは、URLを指定した時点で、実際にクローラがページを取得して、判断している。
ウェブマスターツールの「モバイル ユーザビリティ」に表示されている内容は、グーグルが継続的にクロールしている内容であり、サイトの修正がリアルタイムに反映されているわけではない。
実際に「スマホ対応」ラベルを表示するかどうかを決めているインデックスの情報も、グーグルが継続的にクロールしている内容であり、サイトの修正がリアルタイムに反映されているわけではない。
だから、次のようなことに注意するべきだという。
そのため、「モバイル フレンドリー テスト」で問題がなかった場合でも、実際のインデックスのためのクロールの時点で問題があれば、「スマホ対応」ラベルは表示されない。
そうしたことが起きる原因として、CSSやJavaScriptのファイルにロボットがアクセスできない設定をrobots.txtでしてしまっていることは、有り得る。
フォーラムのベテランメンバーからは、こうした挙動は一般のウェブ担当者にはわかりづらいという指摘も出ているが、現時点の対応という意味では、理解しておくしかない。
またしつこいようだが、コンテンツのレンダリングに関わるCSSやJavaScriptなどのリソースをブロックしてはいけないことは、改めて確認しておこう。
同様の話題は海外でもあり、今週の海外情報のほうにもあるので、併せて確認しておくといいだろう。
スマホサイトでよく見るけど実は注意が必要な6種類のUI
注意点に気を付けて使うべし(EFO・フォーム改善ブログ)
モバイル向けサイトでよく見かけるものの、実際のユーザー行動では使いにくいことがあるユーザーインターフェイスを指摘した記事。
注意を要するUIとして、次の6種類を挙げている。
- モーダルウィンドウ
- 折りたたみ表示
- ページTOPへのスクロール
- 固定表示
- 画面内のスクロール
- 別窓表示
すべてが使うべきでないUIということでもない。ユーザビリティを阻害する点に注意して利用すればうまく機能するUIもある。詳しくは元記事をご覧いただきたい。
ちなみに「ページTOPへのスクロール」に関しては、ページ下のみに表示することを推奨しているが、上向きに一定量以上スクロールしたときに出すという方法が最適なのではないかと思われる。
SEOの神が恐れるほどのローカル検索結果の激しい変化
3つ並んだ写真付きのローカルパックが今の主流か(バカに毛が生えたブログ)
ローカル検索結果のユーザーインターフェイスの変化を観察した記事。
3つ並んだ写真付きの“ローカルパック”は、このコーナーで紹介した去年の11月に米Googleで導入されたカルーセルの置き換えと同じものだ。日本でも導入されたのだろう。
SEO専門家の辻氏は、この記事を見て次のようにツイートしている。
地域系は本当に変化が激しくて、いろいろ試していて怖いですね……>【2015.4.5】地域+グルメ系キーワード検索で検索結果の差し込みが一部変化 | バカに毛が生えたブログ http://t.co/y63c1HHJ1K
— 辻正浩 | Masahiro Tsuji (@tsuj) 2015, 4月 10
写真付きの3つのローカルパック結果は、米国ではレストランやホテル、レジャー施設を中心に適用されていたが、最近になって他の業種にも範囲を広げてきたとの情報を、筆者は得ている。米国は日本以上に変化が激しそうだ。
日本でもこの形式のローカル結果が主流になる気配だ。実際に、モバイル検索でも頻繁に目にするようになっている。
マスターすればアクセス解析力アップ、GAの7つのセグメント
モバイル対応に役立つ設定もあり(nanapi)
アクセス解析で有名な小川卓氏が、Googleアナリティクスで設定してみるといいセグメントとして次の5つを解説した記事を、紹介する。
- 3ページ以上閲覧の訪問
- ソーシャルメディアからの流入
- スマートフォンからの流入
- 特定の目標のみを達成
- 東京以外からのアクセス
1年以上前の記事のため用語などは少し古いが、考え方は今でも通用するものだ。使いこなせば、サイトの課題を見つけるのに役立ちそうなものばかりだ。
「セグメントとは何か?」から始まり、設定手順も説明している。GA初級者でも安心して挑戦できる。
海外SEO情報ブログの
掲載記事からピックアップ
モバイルフレンドリーのアルゴリズムとApp Indexingに関する記事を今週はピックアップ。
- Googleのモバイルフレンドリーのアルゴリズム変更はタブレット検索には影響しない
スマホからの検索のみ - App IndexingについてGoogleの人に質問してきた at Google Developers Summit Tokyo 2015
iOSをサポートするのか?
- モバイルフレンドリーテストでは合格なのにスマホ対応ラベルが付かないのはなぜ?
- スマホ向けサイトとPC向けサイトの2つのサイトマップを送信する必要なし
- スマホサイトの表示速度はランキング要因ではない、今のところはね
- グーグル、軽量化したモバイル検索結果を開始
- モバイルフレンドリーアルゴリズムの重要性-Googleの新しいアルゴリズムにどう対応するべきか?
- Googleのモバイルランキング変更へ対処すべきこと~レスポンシブデザイン・モバイル専用ページ・動的な配信のそれぞれの特徴について~
海外のSEO/SEM情報を日本語でピックアップ
モバイルフレンドリーテストでは合格なのにスマホ対応ラベルが付かないのはなぜ?
主な原因は2つ(Stone Temple Consulting)
「モバイルフレンドリーテスト」ツールで合格しているのに、検索結果で「スマホ対応」のラベルが付かないことがある。なぜだろうか?
主な2つの原因をグーグルのゲイリー・イリーズ氏が説明した。筆者からの補足も付け加えてまとめる。
検索結果にまだ反映されていない
モバイルフレンドリーテストはリアルタイムで結果を出す。つまりその瞬間の状態でスマホ対応しているかどうかを判断する。
対して、検索結果にラベルを表示するには、Googlebotがそのページをクロール・インデックスし、その後の処理が行われなければならない。最新の状態を反映するまでに一定の時間が必要だ。クロール頻度が少ないページならより長い時間がかかるかもしれない。
robots.txtでリソースがブロックされている
スマホ対応のラベルに要求される要素をレンダリングするために必要なCSSやJavaScriptなどのリソースが、robots.txtでブロックされていたりしてGooglebotがアクセスできないときは、ツールで合格していてもラベル表示されないだろう。
モバイルフレンドリーテストはクローラではないので、robots.txtには従わない。よって、ブロックされているリソースも読み込む(サイト全体がrobots.txtでブロックされているときはツールでも検出する)。
現在の状態が反映されるまでには一定の時間が必要なのはウェブマスターツールのモバイルユーザビリティレポートと同じだ。また、リソースのブロックが理由で「スマホ対応」ラベルが表示されなかった事例を先週紹介している。
同様の話題は日本でもあり、今週の国内情報のほうにもあるので、併せて確認しておくといいだろう。
スマホ向けサイトとPC向けサイトの2つのサイトマップを送信する必要なし
ガラケー用サイトマップは必要(Google Webmaster Help Forum)
スマホ向けサイト用のサイトマップを、PC向けサイトとは別に送信する必要はありますか?
このような質問がグーグル公式ヘルプフォーラムに投稿された。
グーグルのジョン・ミューラー氏が次のように回答した。
原則として、スマホ向けサイト用のサイトマップを別途作って送信する必要はないし、すべきではない。
レスポンシブウェブデザインで正しく構成できているなら、それで十分だ。
ただし、旧式のケータイ端末(フィーチャーフォン)向けのサイトを提供しているのならば、そちらはスマホ用のインデックスとは別なので、サイトマップが必要だが。
レスポンシブウェブデザインと動的配信はPC向けもスマホ向けも同じURLなので、別々のサイトマップ送信が不要なのは明らかだ(そもそも無理)。
別々のURLの構成では、スマホ向けサイトのサイトマップを送信することは可能だ。しかし、(rel="canonical"の)アノテーションを正しく設定していれば、結果としてPC向けページのURLに正規化されるので、実際には適切ではない。なぜならサイトマップにはインデックスするURLだけを含めるべきだからだ。PC向けページに対応するスマホ向けページを(rel="alternate"の)アノテーションでグーグルは発見できる。
さらに補足しておくと、rel="alternate"のアノテーションは、HTMLに記述せずに、サイトマップに記述することもできる。詳細はドキュメントで説明されている。
また、ミューラー氏が指摘しているように、WAP/WML端末、つまりフィーチャーフォン(ガラケー)向けのサイトを今でも提供しているなら、モバイルサイトマップを送信しておいたほうがいいだろう。
スマホサイトの表示速度はランキング要因ではない、今のところはね
時間の問題(The SEM Post)
モバイル検索のランキング要因には、モバイル向けサイトの表示速度は含まれていない。
こうしたことを、グーグルのゲイリー・イリーズ氏が明言した。英ブライトンで開催されたBrightonSEOというカンファレンスでの発言だ。
これはすでに知られている事実だ。PCでのウェブ検索と同様に、表示速度が遅いページはモバイル検索でもランキングが下げられることがありうる。ところが、モバイル検索といえど、用いられているのはPC向けページの表示速度だ。モバイル検索なのにモバイル向けページの表示速度が使われてはいないのだ。
奇妙な評価基準であることはグーグルもわかっており、変更を検討していると、グーグルの長山氏は先日のIn-house SEO Meetupで言っていた。
当のイリーズ氏も、モバイル向けページの表示速度がランキング要因になっていないというこの記事に対して、こんなツイートを投稿している。
@jenstar yet ;)
— Gary Illyes (@methode) 2015, 4月 10
まだだね。
いずれはモバイル向けページの表示速度がランキング要因に使われるようになるのは間違いないだろう。問題は、それがいつになるかだけだが、グーグルの指標とは関係なく、ユーザーが快適に表示できる速度にしていくのが、正しい姿勢だろう。
グーグル、軽量化したモバイル検索結果を開始
低速回線でもサクサク表示される(Google on Google+)
グーグルはモバイル検索において、回線速度が遅い状況では、それに合わせて軽量化した検索結果を返すようにした。必要な情報は変わらずに提供しつつも、表示速度が遅くならないようにシンプルなフォーマットで表示する。
たとえば、3つのサンプル画像のうちの右は、Hanamaruというカリフォルニアのサンバレーにある日本食レストランが出ている検索結果だ(画像をクリックすると拡大表示できる)。遅い回線ではこのように表示されるらしい。
通常の高速回線では次のように表示される。
この表示と比べると、Google+の投稿で示されている遅い回線版では、写真や地図など、データ量が多い要素は省略されているし、色も付いていない。
遅い回線でも軽快な検索結果をユーザーに提供しようとするグーグル検索の改良だ。モバイルユーザーにとってスピードアップはそれだけ重要なのだろう。筆者たちもモバイル向けサイトの高速化にさらに取り組みたい。
SEO Japanの
掲載記事からピックアップ
いよいよ導入まで1週間に迫ったモバイルフレンドリーアルゴリズムに関する記事を2本今週はピックアップ。
- モバイルフレンドリーアルゴリズムの重要性-Googleの新しいアルゴリズムにどう対応するべきか?
アルゴリズム概要のおさらい - Googleのモバイルランキング変更へ対処すべきこと~レスポンシブデザイン・モバイル専用ページ・動的な配信のそれぞれの特徴について~
スマホ対応についてのホワイトペーパー
※このコンテンツはWebサイト「Web担当者Forum - 企業ホームページとネットマーケティングの実践情報サイト - SEO/SEM アクセス解析 CMS ユーザビリティなど」で公開されている記事のフィードに含まれているものです。
オリジナル記事:ブラウザ表示確認を、各種デバイス700パターン以上で手軽にできる便利サービス など10+4記事 | 海外&国内SEO情報ウォッチ | Web担当者Forum
Copyright (C) IMPRESS CORPORATION, an Impress Group company. All rights reserved.