[対象: 全員]
お知らせしていたように、11月13日〜14日に伊ミラノで開催されたSMX Milanに参加してきました。
スイスのGoogleからJohn Mueller（ジョン・ミューラー）氏がスピーカーとして招かれました（チューリッヒからミラノまでは電車で3時間くらいなんだそうです）。
ミューラー氏に、たくさんの質問を直接聞いてきて回答を得てきました。
今日と明日の2回に分けてブログ読者のあなたとシェアします（2回に分けるくらいたくさん質問してきた）。
役立つ情報がふんだんに含まれてることを約束します。
では行ってみましょう！
スクレイピング対策
Q: コンテンツを無断コピーされて困っている。DMCA侵害の申し立てを申請すればいいのはわかっているが、必ずしも受理されるとは限らない。また、完全コピーではなく、若干修正されることもある。
通常はオジリナルである自分のコンテンツがきちんと検索結果に出てくるが、稀に、スクレイパーのコンテンツが自分よりも上に出てくることがある。どうすれば防げるか。
A: たしかにDMCA侵害のリクエストが最も確実な手段だ。
オリジナルではなくコピーが上に出てくるときは、（オリジナルのコンテンツがある）サイトに何かしらの問題があることが考えられる。
Q: Googleは誰がオリジナルなのかを判断するのにどんなことをシグナルにしているか？
次のようなことが重要だと考えているがどうだろうか？
- 最初にインデックスさせる
- サイトのオーソリティを高める
- 常にオリジナルのコンテンツを作る（他のサイトのコピーコンテンツばかりだとしたら信頼されないはず）
A: インデックスのタイミングは非常に大切だ。誰がオリジナルかを判断する重要なシグナルにしている。
またサイトのオーソリティもとても大切になってくる。
[鈴木メモ]
スクレイピング（無断コピー）に悩んでいるサイト管理者が多いはずなので質問しました。
スクレイパーが自分よりも上にときに考えられる原因の1つとして「サイトに問題がある」というのは、貴重な情報ではないでしょうか。
オリジナルなのに評価が下がるような要因を抱えているために、コピーにすら負けてしまうのです。
僕のブログ記事もあちこちでコピーされています。
でもコピーが僕のオリジナル記事よりも上に位置したことは、いまだかつて見たことがありません。
そう考えると、スクレイパーに負けてしまっているとしたら評価が下がっている要因がないか調べる必要がありそうです。
先にインデックスさせることが大切だと、Matt Cutts（マット・カッツ）氏も以前に説明していました。
インデックススピードを促進することには、PubSubHubbubやRSSフィードのサイトマップ送信が役に立ちます。
自動化できないのが難点ですが、Fetch as GoogleでのURL送信もインデックスのスピードアップに効果を期待できます。
シンジケーション
Q: スクレイピングではなく、双方の同意のもとで別のサイトに記事を配信するシンジケーションの場合に、自分がオリジナルであることを伝える方法についても聞きたい。
有効な方法の1つとして、自分の記事にリンクしてもらうことがある。記事ではなく、サイトのトップページにリンクしてもらうのはどうだろうか？ 対応する個別記事でなくてもオリジナルであることを伝えるシグナルになるか？
A: トップページへのリンクでもシグナルになる。
[鈴木メモ]
別のところでGoogleの人に同じことを聞いたことがあり、そのときはトップページへのリンクではシグナルにならない可能性が高いとの回答を得ました。
なると思っていたのでそれだと厳しいなと思い、念のためミューラー氏にも尋ねました。
ところがミューラー氏は、トップページでもシグナルになると言っていました。
参考までに、シンジケーションの場合、自分がオリジナルであることを伝える方法は、理想順に次のようになります。
- rel=”canonical”で（自分に）正規化する
- シンジケーション側にnoindex robots metaタグを入れる
- シンジケーション記事からオリジナル記事（自分の記事）にリンクする
- シンジケーション記事からオリジナル記事のサイト（自分のサイト）のトップページにリンクする
1と2は、相手側のサイトでheadセクションを修正してもらわなければなりません。
断られることも多いでしょう。
そこで3になるのですが、これも難しいことがあります。
でも4の方法で、トップページへのリンクを、たとえばロゴのリンクとしてテンプレートに組み込むことはできそうです。
とはいえ、対応する記事へのリンクではないため効果が不透明というわけです。
「期待できないけれどひょっとしたら……」くらいな方法にとらえていいたほうがいいのでしょうか？
なおスクレイピングでも話があったように、インデックスのタイミングとサイトのオーソリティも、シンジケーションにおいてももちろん重要な要因になります。
JavaScriptやCSSのブロック
Q: JavaScriptやCSS、画像などのリソースのクロールをrobots.txtでブロックしないようにGoogleは推奨している。
もしブロックしたからといって、それだけの理由で評価を下げたり、ましてペナルティを与えたりすることはありえないよね？
A: ブロックだけを理由にそういったことはしない。
ただ、ブロックしていたらモバイルでは正しい評価ができずに（本来よりも）低い順位になってしまうことがある。だから十分に気をつけたほうがいい。
[鈴木メモ]
クロールされると問題が起きるリソースはもちろんrobots.txtでクロール拒否して構いません。
たとえば、サイト内検索結果ページはブロックするべきですね（Googleもそのように指示している）。
ECサイトで、セッションIDが付くようなURLもブロックします。
ただしコンテンツのレンダリングに関わるリソースは原則的にブロックしません。
そのページのコンテンツがどのように表示さるのかをGooglebotが知ることで、正しく評価できるからです。
これは特にモバイル向けサイトでは非常に重要なことです。
ブロックしてしまったら、本当のモバイルページをGoogleが見ることができなくなります（まして、モバイルのURLそのものをブロックするのは論外）。
このようにrobots.txtのブロックによってマイナス現象が発生することはありえますが、ブロックしたという行為そのものに対して何らかの対策が講じられることはありません。
とはいえスパム行為が疑われて、CSSやJavaScriptのクロールをrobots.txtでブロックしていた場合、目視によって人間のスタッフが中身を確認することはあるかもしれません。
モバイルユーザー体験
Q: モバイルサイトのユーザー体験を向上させたい。どういったことに優先的に取り組んでいくべきだろうか？ アドバイスが欲しい。
A: PageSpeed Insightsがチェックする項目から改善していくといい。
[鈴木メモ]
スマートフォンユーザーが爆発的に伸びています。
モバイルユーザーのユーザー体験を高めるようにとGoogleもことあるごとに指示しています。
でも、何から手を付けたらいいか迷います。
PageSpeed Insightsには、モバイルのユーザビリティを診断する機能があります。
この機能がチェックする次の項目から手を付けていくといいとミューラー氏は助言してくれました。
- viewport の設定
- コンテンツのサイズを表示域に合わせる
- 判読可能なフォント サイズの使用
- タップ ターゲットのサイズを適切に調整する
- プラグインを使用しない
PageSpeed Insightsと同じ項目のエラーをレポートする「モバイルユーザビリティ」がウェブマスターツールには実装されました。
ユーザビリティの悪さはユーザー体験を悪化させる大きな要因になります。
PageSpeed Insightsとモバイルユーザビリティレポートをまずは参考にして、モバイルユーザー体験の向上に取り掛かりましょう。
モバイルサイトの表示スピード
Q: モバイル向けサイトでは、ページの表示スピードはランキング要因にならないというのは本当のこと？ PC向けサイトのスピードだけが対象になるってこと？
A: そのとおり。PC向け向けサイトの表示速度がランキング要因として用いられる。ただし今の時点での話であって、将来的には変わることは十分にありうる。
[鈴木メモ]
ミューラー氏が、セッション後のQ&Aのなかで誰かからの質問の回答のなかで、「ページスピードはPCサイトが対象で、モバイルサイトは対象ではない」と言っていたのを聞いて「え、そうなの？」と驚いたので直接確認しました。
影響力は微々たるものですが、ランキングを決定するアルゴリズムとしてページの表示速度をGoogleは取り入れています。
モバイルでもページスピードが検索順位に影響するとしても、用いられているデータはPC向けサイトの表示速度のようです。
極端にいえば、「PC向けページがものすごく速い、一方でモバイル向けサイトがものすごく遅い」、こんなケースでは速いPC向けサイトがプラス評価され、遅いモバイル向けサイトはマイナス要因にならないそうです（これも確認した）。
もっとも、これはSEO観点での話です。
じゃ、「モバイル向けサイトは遅くてもいいんだ」と結論付けてはいけません。
UX観点から見たら、PCユーザーよりもモバイルユーザーの方が表示速度を気にしそうです。
遅いモバイルサイトは確実に嫌われます。
ユーザー体験を高めるために、モバイル向けサイトの高速化には積極的に取り組みましょう（高速化にもPageSpeed Insghtsを活用できる）。
それに将来的にはモバイル向けサイトのスピードも考慮に入れる可能性にミューラー氏は含みをもたせていました。
ちなみに、HTTPSの評価を上げるアルゴリズムはモバイルサイトも対象になっていると言っていました。
音声検索
Q: 音声検索の利用が伸びているようだ。サイト側で何か対応しておくべきことはあるか？
A: いや、特別すべきことはない。音声でのクエリをGoogleがきちんと認識・処理して、関連性が高い結果を返すことに変わりはない。ページに「Show me……」とテキストを入れたりしなくていい。
[鈴木メモ]
「10代の若者の50%以上がGoogle音声検索を毎日使う」という米国での調査結果が出ています。
音声検索が増加するという情報を聞いて、音声検索向けのSEOを気にかけるかもしれません。
しかし何か特別なことは不要です。
ミューラー氏が言うように、音声によるクエリを認識・処理するのはGoogleの仕事です。
従来のテキスト入力であろうが音声入力であろうが、検索ユーザーの問いに対してふさわしい回答を準備しておくことが僕たちの仕事です。
“Show me photos of Mt. Fuji.”（富士山の写真を見せて）のように音声検索でよく使われるフレーズをページに書き込んだりする必要はありません。
以上です。
JS・CSSのブロックや音声検索のように、わざわざジョンに聞くまでもなくわかることであっても確認をとってきました。
「Googleの人がそう言っていた」と聞いたほうが安心するひとも多いだろうと考えたからです。
ジョンとはGoogle+を中心に2、3年数えきれないくらい何度も手助けしてもらっています。
でも直接会うのは初めてでした。
オフラインでもオンラインとまったく変わることなく、1つ1つの質問に丁寧に答えてくれました。
セッションも勉強になりましたが（セッションレポート記事はまた後日）、ジョンに直接質問できたのがSMX Milanのいちばんの収穫でした。
マットだと行列ができるので、平気で1時間くらい待たなければなりません。
それでも質問できるのは1つ2つです。
その点、SMX Milanではジョンを捕まえるチャンスがたくさんありました。
明日は残りのQ&Aをシェアします。
お楽しみに。
