Posted:
オンラインで何らかの情報を公開するとき、最も重視すべきことの 1 つがセキュリティです。サイトがハッキングされると、オンラインでの評判に悪影響を及ぼすだけでなく、重要な非公開データを失うおそれもあります。Google の把握しているところでは、ハッキングされたサイトの数は過去 1 年間で 1.8 倍に増加しています。Google としてもこの増加傾向を食い止めようとさまざまな対策を講じていますが、サイト運営者ご自身の手でウェブ コンテンツをハッキングの被害から守る方法もご紹介できたらと思っています。

Google では、本日からおよそ 1 か月間、 #NoHacked キャンペーン を再び実施します。キャンペーン期間中、不正なハッキングからサイトを保護する方法に焦点を当て、それぞれの方法がどのように機能するかについて理解を深めていただきたいと思っています。#NoHacked キャンペーンについては、TwitterGoogle+ でもフォローできます。また、セキュリティをテーマとした Google ハングアウト(英語)も予定しています。セキュリティの専門家に質問できる貴重な機会です。ぜひご参加ください。

では早速、キャンペーンのスタートに、ウェブ上のサイトを保護するための基本的な方法をいくつかご紹介します。

アカウントのセキュリティを強化する

パスワードの推測や解読を難しくすることは、サイトを保護する上で不可欠です。たとえば、文字、数字、記号を組み合わせる方法や、字数を増やしてパスフレーズにする方法があります。パスワードの長さは重要です。長くすればするほど推測が難しくなります。パスワードの強度をテストできるサイトも数多くありますが、実際のパスワードを他のサイトに入力しないよう注意してください。実際のパスワードの強度は、似たようなパスワードをテストすることで、ある程度把握できます。

また、複数のサービスで同じパスワードを使い回さないようにすることも重要です。ハッカーは多くの場合、漏えいしたパスワードの一覧やハッキングしたサービスからユーザー名とパスワードを手に入れ、それらを使ってできるだけ多くのアカウントに不正アクセスしようとします。

サービスに 2 段階認証(リンク先は英語。参考:Google アカウントでの 2 段階認証紹介ページ)が用意されている場合は有効にすることも重要です。これによりアカウントのセキュリティが大幅に向上し、さまざまなタイプの攻撃からアカウントを保護できるようになります。2 段階認証のメリットについては、別の日に詳しくご紹介します。

サイトのソフトウェアを常に最新にする

ハッカーがサイトに不正アクセスする際に最も利用されるのが、サイト上の安全性の低いソフトウェアを経由する方法です。サイトに古いソフトウェアがないか確認してください。特に、セキュリティ ホールを塞ぐためのアップデートは定期的に確認しましょう。Apache、nginx などの商用ウェブ サーバー ソフトウェアを使用している場合は、提供されているパッチを必ず適用してください。コンテンツ管理システム(CMS)を使用している場合や、サイトにプラグインやアドオンを追加している場合は、必ずそれらを常に最新のバージョンに更新するようにしてください。また、使用しているウェブ サーバー ソフトウェアや CMS にセキュリティ関連の情報をメールなどで受け取れるサービスがあれば登録します。さらに、ウェブサイトに不要になったアドオンやソフトウェアがあれば削除を検討してください。無用なリスクを避けられるだけでなく、サイトの動作速度が改善する可能性もあります。

ホスティング プロバイダのセキュリティ問題への対応を調べる

ホスティング プロバイダを選ぶ際には、そのプロバイダがセキュリティに関する方針やハッキングされたサイトへの対応ポリシーをきちんと有しているかを考慮に入れることも重要です。ホスティング プロバイダを利用している場合は、サイト上で問題が発生した際に問い合わせられるサポートがあるかどうかを確認してください。また、オンラインでの評判を調べて、ユーザーのサイトからハッキングされたコンテンツを除去する作業を支援した実績があるかどうかも確認しましょう。

サーバーを自前で運用する場合や仮想専用サーバー(VPS)サービスを利用する場合は、発生するすべてのセキュリティ問題にご自身で対処する必要があります。サーバーの管理は非常に複雑です。サーバー管理者の重要な業務の 1 つが、ウェブ サーバーやコンテンツ管理システムのソフトウェアを最新にし、すべてのパッチが適用されている状態に維持することです。やむを得ない理由がない限り、自前でサーバーを管理するのではなく、サーバー管理サービスを提供するホスティング プロバイダを利用することをおすすめします。

Google のツールを使用してサイトのコンテンツがハッキングされた兆候がないか監視する

問題が発生する前からサイトを監視し、問題に対処するためのツールを備えておくことは重要です。不正アクセスの発見が早ければ、早い段階から問題の解決に着手できます。

Search Console をまだご利用いただいていない場合はご利用されることをおすすめします。Google が提供する Search Console は、ハッキングされたコンテンツが見つかった場合も含め、サイト上に発生した問題をウェブマスターに知らせるツールです。また、サイトに Google アラートを設定して、問題の兆候がある場合に通知を受け取ることもできます。たとえば、ペット用品の販売サイト www.example.com を運営している場合に、[site:example.com 格安ソフトウェア] というアラートを設定しておくと、サイトがハッキングされて格安ソフトウェアに関するコンテンツが表示されるようになると通知が届きます。複数のアラートを設定できますので、ハッキングを含むスパム行為でよく使われる言葉を設定しておくとよいでしょう。スパム行為でどのような言葉がよく使われるか不明な場合は、Google で「スパムワード リスト」と検索してみてください。


今回紹介した方法がサイトの保護に役立つことを願っています。ソーシャル メディアで #NoHacked キャンペーンをフォローし、また、サイトを保護するための皆さん自身のアイデアやコツをハッシュタグ #NoHacked でぜひ共有してください。

ご不明な点がありましたら、ウェブマスター ヘルプ フォーラム でお知らせください。

Posted:
Google 検索では、ユーザーが入力を終える前にクエリを予測するオートコンプリート サービスを提供しています。これまで何年もの間、数多くのデベロッパーが、公開されていない非公式の API を使ってオートコンプリートの結果を自らのサービスに統合してきました。この API には使用の制限もありませんでした。Autocomplete API の存在を知るデベロッパーは、Google 検索に関係のない形でオートコンプリート サービスを組み込むことが可能となっていました。

これまでに何度か、デベロッパーのコミュニティが非公開の API を介して Google サービスをリバースエンジニアリングすることで、大きな進歩につながった事例があります。たとえば、Google Maps API は、創造力のあるエンジニアの手によって地図データと他のデータソースを結合したものが登場してから数か月後、公式にサポートされる API となりました。現在、Google では 80 以上の API をサポートしており、デベロッパーはこれらを使って Google のサービスやデータを自らのアプリケーションに統合することができます。

しかしながら、サポートされていない非公開の API の使用には、ある日突然 API が利用できなくなるというリスクが伴うこともあります。今回もそのような状況のひとつです。

オートコンプリートは Google 検索の補完機能のひとつとして構築されたもので、ユーザーの検索クエリの予測という目的から離れて使用されることは一切意図されていません。オートコンプリートのデータフィードには検索結果の他にも有用な用途があるといえるものの、全体としてオートコンプリートのコンテンツは検索結果とともに使用する意図のもとに最適化されており、ウェブ検索以外の状況ではユーザーに重要なメリットをもたらさない、ということが時間の経過とともにわかってきました。

そこで、Google 検索の一部というオートコンプリートの位置づけを保つため、2015 年 8 月10 日より、非公開の Autocomplete API に対する未許可のアクセスを制限します。Google ではオートコンプリートを、Google 検索と密接に関係したサービスという設計時の用途に沿った形でユーザーの皆様にお使いいただけるようにすることを目指しています。そうすることで、検索とオートコンプリートの両方のサービスにおいて最適なエクスペリエンスを提供できると考えています。

サイトで引き続きオートコンプリート サービスをお使いになりたいサイト運営者およびデベロッパーの皆様は、Google カスタム検索エンジンをお使いいただくと、サイトで検索機能とともにオートコンプリート機能をご利用いただけます。既に Google カスタム検索エンジンをお使いのパートナー様には今回の変更による影響はございません。それ以外の皆様で 2015 年 8 月 10 日以降も引き続きオートコンプリート機能をお使いになりたい場合は、カスタム検索エンジンの登録ページをご覧ください。

Posted:
多くのモバイル サイトでは、プロモーション用のアプリ インタースティシャルを使用して、ユーザーにネイティブ モバイル アプリのダウンロードを宣伝しています。アプリによっては、ネイティブ版のほうがユーザー エクスペリエンスが優れており、ブラウザでは簡単にアクセスできない端末機能を使用できるものもあります。そのため、多くのアプリ所有者は自分のオンライン プロパティやサービスのネイティブ版をユーザーに宣伝したいと考えています。しかし、どれくらい積極的に宣伝すべきかは明らかではありません。ページ全体に表示されるインタースティシャルは、ユーザーがアクセスしたいコンテンツの邪魔になっているかもしれません。


そこで Google では、Google+ モバイル ウェブにおけるインタースティシャルの利用状況を詳しく調査することにしました。Google社内でのユーザー エクスペリエンス調査では、インタースティシャルが妨げになっていることがわかりました。昨年の IO でもジェニファー・ゴーブがこの話題を取り上げ、ユーザーの不満が高かったと語っていました。

インタースティシャルは削除すべきと思われましたが、Google ではデータに基づいて意思決定しているため、まずはインタースティシャルが Google ユーザーにどのような影響を与えているかを調べました。その結果、次のようなことがわかりました。

  • Google のインタースティシャル ページにアクセスしたユーザーのうち 9% が「アプリを入手」ボタンを押していました(このユーザーのうち数パーセントは既にアプリをインストールしているか、アプリストアでのダウンロードを完了しませんでした。
  • Google のページから離れたユーザーは 69% でした。これらのユーザーはアプリストアを訪れることもなく、Google モバイル サイトの閲覧も中止しました。

キャンペーンの CTR が 9% というのは良い結果のようですが、Google ではそれよりも、インタースティシャルで遮られたためにサービスの利用をやめたユーザーの数に注目しました。2014年7月、Google は、前述のデータを踏まえて、インタースティシャルの削除がサービスの実際の利用にどのような影響を与えるかについて実験で調査することにしました。Smart App Banner を追加し、モバイル SEO ガイドのよくあるミスを回避する ページの推奨どおりに、目立たない方法で引き続きネイティブ アプリのプロモーションを行いました。その結果は驚くべきものでした。

  • モバイル サイトの 1 日のアクティブ ユーザーは 17% 増加しました。
  • Google+ の iOS ネイティブ アプリのインストール数には、ほとんど影響がありませんでした(-2%)(Android 搭載端末からのインストール数については、ほとんどのユーザーが Google+ をインストール済みなのでここでは扱いません)。

この結果に基づき、このインタースティシャルを完全に廃止することにしました。Google サービスでユーザー数が増えたことはプラスの変化です。この結果を見て、ウェブマスターの皆様にはプロモーション インタースティシャルの使用を再考していただければと思います。邪魔なものを取り除いて、モバイル ウェブのユーザー エクスペリエンスを向上させましょう!
(この調査の結果、Google は App Banner すら表示しないような、より心地よいモバイル体験(英語)を提供することにしました。※このバナーは、iOS6 以下では表示されています。)

Posted:
新しいジェネリック トップレベル ドメイン(gTLD)が数多く登場していますので、Google の検索でどのように処理しているかについて説明しておきたいと思います。新しいトップレベル ドメイン(.guru、.how、.ブランド名 gTLD など)の処理については、以下に挙げるようにさまざまな疑問や誤解があるようです。

Q: 新しい gTLD は検索に影響しますか?Google は、新しい TLD が有利になるようアルゴリズムを変更しているのですか?検索において、新しい TLD はどの程度重視されるのですか?
A: 基本的に、新しい gTLD も他の gTLD(.com、.org など)と同じように処理されます。検索において、特定の TLD のキーワードが有利に働くことも不利に働くこともありません。

Q: 「.みんな」のような IDN TLD も、Googlebot がクロールしてインデックス登録し、検索で使用できるようになるのですか?
A: はい。このような TLD も、他の TLD と同じように使用できます([site:みんな] を検索すると簡単に確認できます)。Google では、Punycode バージョンのホスト名を Unicode バージョンと同等のものとして処理します。したがって、リダイレクトしたり別々に正規化したりする必要はありません。URL の残りの部分に非 ASCII 文字を使用する場合は、URL 内のパスやクエリ文字列に必ず UTF-8 を使用してください。

Q: .ブランド名 TLD の扱いが .com と異なることはありますか?
A: いいえ。そのような TLD も他の gTLD と同じように扱われます。同じ地域ターゲティング設定が必要ですし、URL のクロール、インデックス登録、ランク付けにおいてウェイトや影響が異なるということもありません。

Q: 地域や都市の TLD(.london、.bayern など)はどう処理されますか?
A: 地域固有の TLD も gTLD と同じように処理します。.eu や .asia などの地域 TLD と同じ扱いということです。ただし、実際にどう使用されているかによって、多少の例外がある場合もあります。詳しくは、ヘルプセンターの多地域、多言語のサイトをご覧ください。必要な場合は、Search Console で地域ターゲティングを設定してください。

Q: 従来の ccTLD(国別コード トップレベル ドメイン)はどうですか?Google では、.uk、.jp などの ccTLD を、その国で検索している人のローカル ドメインとして重視しますか?
A: Google の既定の処理では、ほとんどの ccTLD(例外あり)をウェブサイトの地域ターゲティングに使用しています。ccTLD を見れば、そのウェブサイトが該当の国に関係している可能性が高いと判断できます。詳しくは、ヘルプ記事「多地域、多言語のサイト」をご覧ください。

Q: ドメインを .com から新しい TLD に移転する場合、SEO に関して Google のサポートを受けることはできますか?ウェブサイトを移転する際、検索のランキングや履歴を維持するにはどうしたらよいですか?
A: ヘルプセンターのドキュメントで、サイトの移転について詳しく説明しています。Google では、新しい TLD への移転も他のサイト移転と同じように扱います。ドメインを変更すると検索のための処理に時間がかかるだけでなく、検索以外の面でも、メールアドレスが長期間変わらないことをユーザーは期待するものなので、できるだけ長期間使用できるドメインを選択することが重要です。

今回は、Google が新しいトップレベル ドメインをどのように処理しているかについて説明しました。他にご不明な点などありましたら、ウェブマスター ヘルプ フォーラムで質問してください。

Posted:
このたび goo.gl 短縮リンクに新機能が加わり、1 つの goo.gl リンクを Android アプリ、iOS アプリ、ウェブサイトなどにまたがるコンテンツへのリンクとして使用できるようになりました。Android と iOS の App Indexing を設定すると、goo.gl で生成されたリンクは、アプリをインストール済みのユーザーはアプリ内の適切なページへ、そうでないユーザーはウェブサイトへリダイレクトするようになります。これにより、ユーザーにアプリを再度利用してもらう機会を増やすことが可能になります。この機能は過去に生成した短縮 URL にも同じように適用されます。

適切に機能するリンクを共有しよう

さらに、URL Shortener API をアプリの共有フローに統合すると、ユーザーがリンクを共有する際、プラットフォームが異なっていても自動的にネイティブ アプリにリダイレクトされるようになります。また、自分のアプリへのディープリンクを、他のウェブサイトやアプリに埋め込むこともできます。

Google マップを例に説明しましょう。クロスプラットフォームになった goo.gl リンクを開くと、ユーザーがどのプラットフォームを利用しているか、マップ アプリがインストールされているかどうかが自動的に検出されます。アプリがインストールされている場合は、Android または iOS のマップ アプリで直接そのコンテンツが開かれます。アプリがインストールされていない場合やパソコンを使用している場合は、マップのウェブサイトが表示されます。

実際に試してみましょう。Google マップ アプリがインストールされた携帯端末で、http://goo.gl/maps/xlWFj にアクセスしてみてください。

設定方法

goo.gl を利用して、あなたのアプリへのディープリンクを設定するには:
  1. g.co/AppIndexing にアクセスし、Android と iOS で App Indexing を使用するのに必要な手順を行います。なお、現行の Google 検索からのディープリンクとは異なり、goo.gl ディープリンクはすべての iOS 開発者が利用できます。この手順を完了すると、既存の goo.gl 短縮リンクもアプリへのディープリンクとして機能するようになります。
  2. 必要に応じ、URL Shortener API をアプリの共有フローやメール キャンペーンなどに統合します。これにより、アプリに直接アクセスできるディープリンクをプログラムによって生成できるようになります。
この新機能を活用し、クロスプラットフォームでのリンクの共有にお役立てください。