グーグルが示すスマホサイト最適化のための25の原則 など10+4記事
グーグルが示すスマホサイト最適化のための25の原則
ユーザーテストの結果により導き出された （Multi-Screen Resources – Google）
スマートフォンなどのモバイルユーザーが使いやすくコンバージョンに繋がるモバイルサイトを構築するための25の原則を、グーグルが公開した。
119時間をかけて行われたユーザーテストの結果により導き出されたものだ。
モバイルサイトのデザイン・設計について、次の5つのテーマで、合計25個の原則を説明している。
- ホームページとサイトのナビゲーション
- サイト内検索
- ECサイトとコンバージョン
- フォーム入力
- ユーザビリティとフォームの要素
文書はPDF版（全42ページ）でダウンロードできる。英語が苦手な人や、読む時間をすぐにはとれない人は、グロースハックジャパンさんが要点を簡潔に日本語にまとめたページを参照するといいだろう。
モバイルサイトの重要性は増すばかりだ。モバイルサイト運営に役立つ貴重な資料として活用したい。
日本語で読めるSEO/SEM情報
物語で学ぶ、SEOに成功する人・失敗する人
あなたはどちらのタイプ？ （SEO 検索エンジン最適化）
SEOを施策する際の重要な考え方を、住太陽氏が“物語風”に解説した。
2つの物語を公開している。
どちらの話にも、「成功する側」と「失敗する側」が登場する。何が成功をもたらしたのか、反対に何が失敗をもたらしたのかを考えてみてほしい。
Web担にもマンガや小説のコンテンツが多い。同じ情報を伝えるにも、文章で解説するよりも、このようなスタイルで示すほうがわかりやすい場合がある。「オウンドメディアのコンテンツ作り」という観点でも、参考になるだろう。
グーグル、不正なリダイレクトに関係するヘルプを更新
具体例を追加 （グーグル ウェブマスター向け公式ブログ）
グーグルは、品質に関するガイドラインに含まれる「不正なリダイレクト」のヘルプに具体例を追加した。次のようなものが不正なリダイレクトとみなされる。
検索エンジンにはあるコンテンツが表示されるが、ユーザーはまったく違うコンテンツにリダイレクトされる。
PC ユーザーには通常のページが表示されるが、モバイル ユーザーはまったく別のスパム ドメインにリダイレクトされる。
また、「ハッキングされたコンテンツ」のヘルプに、次のような「リダイレクト」の項目を加えた。
ハッカーは、有害なページやスパム ページにユーザーをリダイレクトする悪質なコードをウェブサイトに挿入することがあります。この種のリダイレクトは、リファラー、ユーザーエージェント、デバイスによって挙動が異なる場合があります。たとえば、Google 検索結果で URL をクリックすると、不審なページにリダイレクトされる可能性がありますが、同じ URL にブラウザから直接アクセスした場合はリダイレクトされません。
「不正なリダイレクト」だけでは何が不正なのかが曖昧だった。具体的な例を示すことで、ウェブ担当者もよりイメージしやすくなるだろう。
意図せず不正なリダイレクトだとみなされないように注意するとともに、リダイレクトを仕込むハッキングを受けないようにも注意しよう。
グーグル社員がリンクの否認ツールの使い方にあらためて注意を喚起
リンクを十分削除せずに使うとリスク （ウェブマスター向け公式ヘルプフォーラム）
リンクの否認ツールの使い方に関して、グーグル社員のKyotaroさんが公式ヘルプフォーラムで注意を喚起した（強調は筆者による）。
こちらのスレッドなどでもご案内している通り、リンクの否認ツールは、不自然なリンクを可能な限り取り除いたにもかかわらず、まだどうしても取り除くことのできないリンクが残ってしまった場合にのみ使用してください。詳しい調査と対処をせずに大まかにドメイン否認をして再審査リクエストを行うことには以下のようなリスクがあります。
そもそも再審査リクエストが通らずに手動による対策が解除されない（再審査リクエストではガイドライン違反箇所の詳細な調査と対処をお願いしています）。
たとえ再審査リクエストが通り、手動による対策が解除されたとしても、多くのオーガニックなリンクも否認された状態であるためにサイトのパフォーマンスが回復しない。
手動による対策が解除されたあとに否認ファイルを編集し、ドメイン単位の否認から、より細かい URL 単位に切り替えようとしても、ガイドライン違反の状況について詳しく把握・対処していなかったために作業が困難となる、あるいは再びガイドライン違反となる。
以上から、再審査リクエストを送信する前に、サイトへのリンクを精査し、ガイドライン違反となっているリンクをきちんと把握し、削除できるものは削除するように取り組んだ上で、適切にリンクの否認ツールを利用することをおすすめしています。その際に改めて削除できる不自然なリンクは削除するように取り組むことをおすすめします。
また、時折、「ドメイン単位で大雑把に否認して再審査リクエストを通してしまおう」といった考えをお持ちの方がいるともお聞きしますが、上記理由により、そうした方法が長期的に見て意味のないことであることを付け加えさせていただきます。
わかりやすく言えば、「ちゃんとリンクを精査して、各リンクのリンク元とやりとりして消せるものは消してもらって、これ以上はどうにもできないとなった段階で、リンク否認ツールを使う」ということだ。
リンクの否認ツールは、一般のウェブ担当者が日常的に使うツールではない。そのため、どうしてもグーグルが想定した正しい使い方で用いられていないようだ。
このツールを利用せざるを得ない状況に陥ること自体が問題だといえば問題なのだが、やむを得ず使う必要に迫られたのであれば、Kyotaroさんの指示に確実に従おう。
ウェブ担当者だって認識しておきたいUXに関する7つの注意点
SEOとともにUXも重要なウェブ担当者の重要タスク （Kajiken.me）
優れたユーザーエクスペリエンスを追求するうえで認識しておかなければならないことを7つ挙げた記事。
その「7つの注意点」とは、次のようなものだ。
- 優れたUXを一発で作ることは不可能
- ユーザーインタビューは不可欠
- UX設計のプロセスに決まったパターンはない
- UXはUIと違う
- ユーザビリティテストは、絶対に不可欠
- ユーザビリティ＝UXではない。
- UX周りの全てができる人材はほとんどいない。
SEOではなくUXに関することだし、元記事は「プロジェクトマネージャ」を対象にしているが、ユーザーエクスペリエンス向上への取り組みもウェブ担当者には重要なタスクだ。参考にしたい。
SEOで成功して多くのユーザーを集められたら、せっかく訪れてくれた人には良い体験を提供して、会社やサイトを好きになってもらいたい。「集客」と「体験」のどちらかが欠けてもよろしくないし、究極には分けて考えるべきものではないものなのかもしれない。
使いこなせれば強い武器になるGAの「コホート分析」
上級者向け （真摯のブログ）
ある時期に初めてサイトを訪れた人が、どれぐらいリピートしたりコンバージョンしたりしているか、訪問モチベーションはどう変わっているのか、時期ごとに分けて知りたい。
特定のキャンペーンで初めてサイトを訪れた人が、その後サイトをどう使っているか、キャンペーンごとに分けて見たい。
そうしたことを分析し、より効果の高い集客や接客をできるようにしたいと考えたことはないだろうか？ それを実現するのが「コホート分析」だ。
コホート分析とは、次のようなものなのだという。
コホートとは、ある特定の条件や属性をもった集団（ユーザーグループ）のことで、コホート分析は、時間の経過に伴いそのコホートの行動がどのように変化するかを分析するものです。
Googleアナリティクスの「セグメント」（旧アドバンスセグメント）には、コホート分析を行う機能がある。
この機能は、簡単に言うと「特定の期間に初めて訪れた人がその後どのような行動をとっているか」を追跡できる機能だ。たとえば、2014年1月に初めて訪問したユーザーのうちどのくらいが今も引き続き訪問しているかを知ることができる。
この「Googleアナリティクスのコホート分析機能」の使い方や、「セグメント機能を使った他のコホート分析」の手法を、こちらの記事は解説している。
Googleアナリティクス以前からコホート分析を実装しているツールがいくつかある。しかしGoogleアナリティクスで「コホート分析」としている機能は、それらのツールほどには洗練されていないようだ。
一方、Googleアナリティクスでコホート分析が可能になったというものの、残念ながら先ほどのような「コホート分析」という言葉でイメージされるレポートは提供されていません。Googleアナリティクスの「セグメント機能」を活用して各自の設定でコホート分析ができるようになった、というのが実際のところです。
それでも、コホート分析を使いこなせればユーザーの分析とサイトの改善に強い武器になるだろう。上級者向けの内容ではあるが、全員が一読する価値がある解説だ。
掲載記事からピックアップ
マット・カッツ氏が説明するグーグルのタイトル生成の仕組みと、間違いやすい構造化マークアップの用語の解説を今週はピックアップ。
- Googleがtitleタグを置き換える3つの理由と書き換えを防ぐ方法
マット・カッツによる役立つ情報 - [構造化データ初級者向け] schema.orgとMicrodata、RDFaって何が違うの？
ボキャブラリーとシンタックス
- 今すぐできる会社ロゴのschema.org構造化マークアップ
- 「#」が付いたURLはSEOに不向きなの？
- schema.orgのパンくずリストは使えない
- SSLを導入していないのにSSLエラーがウェブマスターツールに届く
- オーガニック検索におけるクリックスルー率の方程式
- ソーシャルメディアとSEOの短い歴史＆輝ける未来
海外のSEO/SEM情報を日本語でピックアップ
今すぐできる会社ロゴのschema.org構造化マークアップ
ナレッジグラフ以外にも利用してほしい （Matt Cutts on Google+）
組織や企業のロゴのschema.orgによる構造化マークアップについて、グーグルがサポートを開始したのは、ちょうど1年前だ。
グーグルのマット・カッツ氏が「ぜひロゴをマークアップするように」とGoogle+の投稿でリマインドした。
ロゴをマークアップしておけば、その画像が組織・会社の正式なロゴだとグーグルにシグナルを送ることができる。
そうすると、たとえば次のようにナレッジグラフに使われる。
あなたの会社がナレッジグラフに現在表示されているならばぜひ、そうでなくてもほかの用途に使われることも今後ありうるだろうから、この機会にロゴをマークアップしておくといい。
実装方法は簡単だ。
たとえば、Web担なら、ページ内でロゴ画像を表示している部分で、HTMLを次のようにしておく。
<div itemscope itemtype="http://schema.org/Organization">
<a itemprop="url" href="http://web-tan.forum.impressrd.jp/">
<img itemprop="logo" src="/images/webtan-logo.png" />
</a>
</div>上記はMicrodataによるマークアップだが、JSON-LDを利用すると次のようになる。
<script type="application/ld+json">
{
"@context" : "http://schema.org",
"@type" : "Organization",
"url" : "http://web-tan.forum.impressrd.jp/"
"logo" : "http://web-tan.forum.impressrd.jp/images/webtan-logo.png"
}
</script>ページ上に表示しているロゴ画像にCSSスプライトを使っている場合などは、JSON-LDを使った指定のほうがいいだろう。
「#」が付いたURLはSEOに不向きなの？
通常のURLなら関係ない （Matt Cutts (@mattcutts) on Twitter）
グーグルのマット・カッツ氏がフォロワーからの質問に答えた。
（フォロワー）： マット・カッツさん、ページ内のaタグ（で指定しているURL）にフラグメント（#）を含んでいると、SEOには不向きですか？
そんなことはないと個人的には思うのですが、間違っているかもしれません。
マット・カッツ氏： 通常は取り除くから、そういうURL（「#」が付いたURL）はすべて1つに正規化される。
技術的なことをいえば、URLのうちフラグメントの部分はクライアント側で処理するものであって、サーバー側で処理するものではない。
ページ内の特定の場所にリンクしたい際に、リンクのURLに「#」を付けたaタグを利用できる（この部分は正しくは「フラグメント」と呼ぶが、記号を指して「ハッシュ」と呼ぶこともある）。たとえば、このコーナーのそれぞれの記事紹介見出しがそうなっている。
各見出し先頭の
http://web-tan.forum.impressrd.jp/e/2014/05/09/17440/page=0,1#f4これをクリックすると、このページのこのピックアップの部分に移動する。
ただこの処理はブラウザによるものだ。ブラウザがウェブサーバーにリクエストするときに使うURLには、「#」以降が含まれていない。「#」で指定した場所に移動するのはブラウザの仕事だからだ。
つまり通常は、Googlebotには、URL内の「#」以降の部分は関係ない。「#」以降が異なっていても同じURLとして認識、処理されるのだ。
さらに補足しておくと、これが理由で、Ajaxで使われる「#」付きのURLをグーグルは正しくクロール・インデックスできないのだ。ブラウザでは異なるコンテンツが表示されていたとしても、Googlebotは「#」が付かないURLを取得してしまうからだ。
そのため、「#」を含むURLでAjaxを使ってコンテンツを出し分けるサイトに関しては、「#!」に置き換えるグーグルのための構成にするか、HTML5の「pushState」などを使った構成にしないと、SEO的に不利になるのだ。
schema.orgのパンくずリストは使えない
グーグルは未サポート （Google Webmaster Help Forum）
パンくずリストのマークアップに関してグーグルのジネブ氏が公式ヘルプフォーラムで次のようにコメントした。
今のところ、グーグルはschema.orgのパンくずリスト用マークアップをサポートしていません。そのためグーグルに対しての利用は適切ではありません。担当チームがschema.orgと解決のために取り組んでいるところです。
問題が解決されるまでは、ヘルプセンターの「パンくずリストのリッチスニペット」で説明されているマークアップを使用してください。
schema.orgのパンくずリストは、定義されているマークアップ方法にやや問題があるらしくグーグルはサポートできていない。したがってパンくずリストをマークアップするときはschema.orgではなくdata-vocabulary.orgを利用するのが確実だ。
data-vocabulary.orgとMicrodataを使ってパンくずリストを構造化マークアップする手順をWeb担の安田編集長が以前に解説している。かなり前の記事だが今でも変わらず機能する。
SSLを導入していないのにSSLエラーがウェブマスターツールに届く
「証明書のサブジェクト名と不一致」の警告 （Google Webmaster Help Forum）
日本版の公式ヘルプフォーラムでは目にしないのだが、英語版の公式ヘルプフォーラムでSSLに関するエラーメッセージがウェブマスターツールに届くサイトが多発している。
「SSL証明書に割り当てられているサブジェクト名（ホスト名/サイト名）とそのサイトのドメイン名が一致しない」という警告が、SSLを導入していないサイトに届き、身に覚えがないエラーにサイト管理者たちが困惑してしまっているのだ。
この原因は、ホスティング会社の設定でSSLでも接続できる構成になっているため、自分が取得したわけではない証明書でSSLを使ったHTTPS通信も可能になっていることのようだ。
この事態に対して、グーグルのジョン・ミューラー氏は次のようにコメントした。
混乱を起こしていることがわかって、こうした警告メッセージを送るのを停止することに決定した。再開する前に、もっとわかりやすいメッセージにし、警告する基準を微調整することに取り組むつもりだ。
冒頭でも言ったように、SSLエラーの警告が日本で発生している様子はない。しかしSSLを導入していないのに「証明書が不適切だ」というエラーメッセージがもし届いていたとしたら、無視して構わない。
掲載記事からピックアップ
検索結果のタイトルとスニペットを考察した記事とSEOとソーシャルの関係を分析した記事を今週はピックアップ。
- オーガニック検索におけるクリックスルー率の方程式
クリック率を上げるために必要なこと - ソーシャルメディアとSEOの短い歴史＆輝ける未来
SEOとソーシャルは切っても切れない関係になりつつある
ソーシャルもやってます!