上級者向けSEOガイド3/9 : schema、エンティティ&セマンティック検索対応

上級者向けのSEOガイドを紹介する記事シリーズ第三弾は、セマンティック検索対応について。相変わらず徹底的に網羅された内容です。知識としては何となく知っていても、本格的に対応している人やサイトはまだまだ少ないのが現状とは思いますが、とりあえずこの記事をブックマークしておけば何かの時には使えそうです。 — SEO Japan

サイトはクロール可能 & インデックス可能になり、スピードも大幅にアップした。 チャプター 3ではさらにギアを上げ、新しい検索の要素を取り上げていく。検索は、セマンティックな“現実に近い”環境に向かって動きつつある。つまり、検索エンジンが人物、場所、映画、会社等の実際の物事の間の関係を理解する環境である。今すぐこの流れに乗り、ウェブサイトに反映していこう。


1. Schema.orgのメタデータを実装する

schema.orgは世界共通のメタデータのマークアップであり、2011年に主要な検索エンジンによって導入された。このマークアップは、ウェブサイト上の意図されたタイプのコンテンツをエンジンに伝えるために用いられている。schema.orgをフル活用していない人達はまだ大勢いる。

ここでは、複数の種類のschemaの実装方法、そして、正確なマークアップをHTMLコードに統合する方法を紹介していく。

パート 1 – マイクロデータの基本的なアトリビュート

  1. itemscope
  2. itemtype
  3. itemprop
  4. itemid
  5. itemref

この5つの要素を例を使って分かりやすく説明する。

以下にschemaのメタデータがない状態のコードを掲載する:

<!DOCTYPE HTML>

<html lang="en">

<head>

<meta charset=utf-8>

<title>メタデータなしのページの例</title>

</head>

<body>

<section>

<h1>何でもいい</h1>

<span>作者: デレック・シバーズ</span>

<span>Category : business</span>

<a href="http://sivers.org/ayw/">本について</a>

</section>

</body>

</html>

特別なマークアップはどこにも見当たらない、普通のHTMLである。次に、メタデータ付きのコードを掲載する:

<!DOCTYPE HTML>

<html lang="en">

<head>

<meta charset=utf-8>

<title>マイクロデータ付きのページの例</title>

</head>

<body>

<section itemscope itemtype="http://schema.org/Book">

<h1 itemprop="name">Anything You Want</h1>

<span>作者: <span itemprop="author">デレック・シバーズ</span></span>

<span>カテゴリー : <span itemprop="genre">ビジネス</span></span>

<a href="http://sivers.org/ayw/"><span itemprop="detail">本について<span></a>

</section>

</body>

</html>

一つずつ要素を見ていく。

1. Itemscope

<section itemscope itemtype="http://schema.org/Book">

</section>

bookに関するものは全てitemscopeの要素の間に入る。検索エンジンに「中身はすべて本に関するコンテンツ」があることを伝えている。

2. Itemprop

<h1 itemprop="name">何でもいい</h1>

itempropは本の名前を意味する。

<span>作者: <span itemprop="author">デレック・シバーズ</span></span>

<span>カテゴリー : <span itemprop="genre">ビジネス</span></span>

<span>カテゴリー : <span itemprop="genre">ビジネス</span></span>

<a href="http://sivers.org/ayw/"><span itemprop="detail">本について<span></a>

また、Itempropは、本の作者、カテゴリ、そして、ジャンルを表す。ここまでは、簡単である。

<span>タグを使って、itemporpの要素を挿入する。

パート 2 – schemaをブログで利用する

恐らく、皆さんの多くは何らかのタイプのブログを運営しているのではないだろうか。ブログにもschemaを利用することが可能である。ワードプレスを用いているなら、テーマの作者を確認し、schemaを利用することが出来るか確認しよう。利用することが出来ない場合、ワードプレスはタグをはぎ取ってしまう。これはワードプレスの設定に左右される。以下に一般的な例を挙げる。

a. schemaのないコード

<!DOCTYPE HTML>

<html lang="en">

<head>

<meta charset=utf-8>

<title>マイクロデータなしのブログの記事の例</title>

</head>

<body>

<div>

        <h1>…ズルせずに、上位にランクインするオーソリティを構築するためのヒント</h1>

        <p>まず、オーソリティを定義していく – ドメインのオーソリティとは、上位にランク付けさせるドメインのポテンシャルを意味する。ランキングが高ければ高いほど、オーソリティが高くなる。そして、オーソリティが高ければ高いほど、ランキングも高くなる。</p>

        <p>それでは、その方法を紹介していく:</p>

        <p>1. トピックごとにページのグループにリンクを張る</p>

        <p>2. 特定の一つのページにより多くのリンクを張る</p>

        <p>3. ドメインベースの外部リンクを主役のページに送る</p>

        <p>4. キーワードの共食いを避ける</p>

        <p>5. 関連するウェブサイトから、外部のリンクを主役のページにもたらす</p>

        <p>6. リンクをページの上部に配置する</p>

        <p>7. このコンセプトを理解する上で役に立つ図を使った解説</p>

        <p>8. 壊れているページを修正する</p>

</div>

</body>

</html>

b. Schema付きのコード

<!DOCTYPE HTML>

<html lang="en">

<head>

<meta charset=utf-8>

<title>マイクロデータ付きのブログの記事の例</title>

<a rel="author" href="https://profiles.google.com/103074333439002308043/about">Bidhan Chatterjee</a> </head>

<body>

<div itemscope itemtype="http://schema.org/Blog">

<h1>…ズルせずに、上位にランクインするオーソリティを構築するためのヒント</h1>

        <p>まず、オーソリティを定義していく – ドメインのオーソリティとは、上位にランク付けさせるドメインのポテンシャルを意味する。ランキングが高ければ高いほど、オーソリティが高くなる。そして、オーソリティが高ければ高いほど、ランキングも高くなる。</p>

        <p>それでは、その方法を紹介していく:</p>

        <p>1. トピックごとにページのグループにリンクを張る</p>

        <p>2. 特定の一つのページにより多くのリンクを張る</p>

        <p>3. ドメインベースの外部リンクを主役のページに送る</p>

        <p>4. キーワードの共食いを避ける</p>

        <p>5. 関連するウェブサイトから、外部のリンクを主役のページにもたらす</p>

        <p>6. リンクをページの上部に配置する</p>

        <p>7. このコンセプトを理解する上で役に立つ図を使った解説</p>

        <p>8. 壊れているページを修正する</p>

</div>

</body>

</html>

c. 要素の説明

1. Rel = Author

HTMLの<head></head>にこのタグを加える理由が知りたい人もいるだろう。理由は、グーグルがこの方法で作者を言及することを認めているためだ。

見ての通り、とてもシンプルである:

<a rel="author" href="https://profiles.google.com/103074333439002308043/about">Bidhan Chatterjee</a>

このコードを<head>に加えた後、グーグルプラスのプロフィールをブログに向ける – この方法は、後で取り上げるグーグルオーサーシップのセクションで紹介する方法と同じである。

2. Intemscope

<div itemscope itemtype="http://schema.org/Blog">

この要素もまた、コンテンツが話題にする やアイテム のタイプを伝えるために用いられる。 

おまけ: ソーシャルシェア用のschema

ソーシャル共有データをschemaに組み込むことも出来る。要素itemprop とinteractioncountが役に立つ。以下に例を挙げる

<meta itemprop="interactionCount" content="FacebookLikes:8"/> <meta itemprop="interactionCount" content="GooglePlus:3"/>

テスト

ここでも、グーグルが提供するリッチスニペットのテスターを使って、マークアップをテストするべきである: http://www.google.com/webmasters/tools/richsnippets


2. 動画のインデクセーション – 動画をschema.orgでマークアップする

schema.orgを使って動画をマークアップすると、クリックスルー率が大幅に改善する。下のスクリーンショットでは、SEOmozが動画のメタデータを使ったことで、SERP内のビジュアルが著しくパワーアップしたことが分かる。

コードを追加すること自体は難易度が高くないが、適切なマークアップを知る必要がある。

始める前に、幾つか前提となる条件を挙げていく:

  1. 動画を自分自身でホスティングしていること(ユーチューブのエンベッドには適応することが出来ない)
  2. HTMLにアクセスし、コードを編集することが出来る

ステップ 1: 通常の動画のコードをページに貼り付ける

典型的な動画のエンベッドコードを以下に掲載する:

<h1>ニール・パテル</h1>

<h2>動画: ブロガー向けの高度なSEO</h2>

<object …>

 <param …>

 <embed type="application/x-shockwave-flash" …>

</object>

<p>SEOおよびマーケティングのエキスパート、ニール・パテルが提供する特別な動画。大量のリードをブログに送り込み、コンバージョン率の7つの秘密を学ぶ。</p>

ステップ 2: VideoObjectを囲む

<div>でコードを包む

VideoObjectデータを加える

ステップ 3: 基本的なマークアップを加える

以下に基本的なプロパティを挙げていく;

  1. Name
  2. Thumbnail
  3. Duration
  4. Description

「name」「description」のフィールドは、既存のコンテンツを囲む<span>タグの内側に加えられる :

プロパティ「duration「thumbnail 」は、通常、nameの下、そして、実際の動画の前に加えられることが多い<meta>内に掲載される

注記: 「duration」はISO_8601フォーマットを採用している。ISO_8601の詳細は次のURLを参考にしてもらいたい: http://en.wikipedia.org/wiki/ISO_8601

ステップ 4: さらにマークアップを加える

MediaObject(VideoObjectのオブジェクト)に対して、好きなプロパティを加えることが出来る:

  1. associatedArticle
  2. bitrate
  3. contentSize
  4. contentURL
  5. duration
  6. embedURL
  7. encodesCreativeWork
  8. encodingFormat
  9. expires
  10. height
  11. playerType
  12. regionsAllowed
  13. requiresSubscription
  14. uploadDate
  15. width

あるいは、動画専用のプロパティを加えることも可能だ:

  1. caption
  2. productionCompany
  3. thumbnail
  4. transcript
  5. videoFrameSize
  6. videoQuality

以下に[upload date]と[width]と[height]を加えたコードの例を掲載する:

動画のマークアップを加え、競合者に差をつけよう。

完成したコード

<div itemprop="video" itemscope itemtype="http://schema.org/VideoObject">

<h2><span itemprop="name">動画: ブロガー向けの高度なSEO</span></h2>

<meta itemprop="duration" content="T1M33S" />

<meta itemprop="thumbnail" content="neil-patel-video-thumbnail.jpg" />

<meta itemprop="uploadDate" content="2012-04-01T08:00:00-05:00" />

<meta itemprop="width" content="640" />

<meta itemprop="height" content="480" />

<object …>

 <param …>

 <embed type="application/x-shockwave-flash" …>

</object>

<p><span itemprop="description">;SEOおよびマーケティングのエキスパート、ニール・パテルが提供する特別な動画。大量のリードをブログに送り込み、コンバージョン率の7つの秘密を学ぶ。</span></p>

</div>


3. ヤフー!のサーチモンキー RDFa

RDFa マイクロフォーマットは、ヤフー!がより簡単に情報を特定し、分類するために利用するマークアップ言語である。

RDFはResource Development Frameworkの略である。

RDFを使って、コマースサイトの商品、スケジュール & コンテンツを検索エンジンに説明することが出来る。

RDFはHTMLで書かれているのではなく、XML フォーマットが用いられている。

これから、このコードをコンテンツに追加する方法を、幾つか例を使って紹介していく。

パート 1 – 識別子を理解する

resource - URL上に存在するもの全て

property - 名前付きのresource(例えば、ウェブページ上のコンテンツのタイプ) – author、homepage、book、movie等

property value – propertyの特徴、例えば本の作者や映画に出演する俳優

次に「statement」を形成していく。「statement」は、subject、predicate、そして、objectで構成される。

statement[QuickSproutの作者はNeil Patel]は次のようにまとめられる:

subject: http://www.quicksprout.com

predicate: author

object: Neil Patel

パート 2 – 例

1. 全てのRDFはXMLの宣言 & RDFのラッパータグで始まる

2. 次にRDFのシンタックス、そして、データが参照するURLを宣言する:

3. ドキュメントで描写されるアイテムを宣言する

ここでは、具体的なCD「Thriller」を取り上げており、CDが存在するURLを参照している。

4. resourceのpropertyである要素を加える

ラッパータグ<cd:artist></cd:artist>(またはcountry、price等)を使って、参照しているアルバムのpropertyを宣言することが可能だ)。

パート 3 – 完成したコードの例

以下に完成したコードの例を掲載する。ニーズに応じて、この例を利用し、修正することが出来る。

<?xml version="1.0"?>

<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:cd="http://www.cdstore.com/cd01">

<rdf:Description

rdf:about="http://www.cdstore.com/cd01/Thriller">

        <cd:artist>Michael Jackson</cd:artist>

        <cd:country>USA</cd:country>

        <cd:company>Epic Records</cd:company>

        <cd:price>12.99</cd:price>

        <cd:year>1982</cd:year>

</rdf:Description>

</rdf:RDF>

最後に、バリデータを使って、作品をチェックしよう: http://www.w3.org/RDF/Validator/


4. サイトにダブリンコアを加える

ダブリンコアもまた、ウェブ上のデータを説明するために用いられるメタデータのフォーマットである。ダブリンコアは様々な要素を採用している。その一部を以下に掲載する:
  1. title – resourceに与えられる名前
  2. creator – コンテンツを所有する人物または組織
  3. subject – コンテンツのトピック
  4. description – コンテンツの説明
  5. publisher – resourceを公開した人物
  6. contributor – コンテンツに貢献した人物/span>
  7. date – resourceが公開された日付
  8. type – コンテンツが該当するカテゴリ
  9. format – リソースが提示される仕組み
  10. identifier – URL等のコンテンツに対する数字の識別子
  11. source – コンテンツが引き出された元の場所
  12. language – コンテンツの作成に用いられている言語
  13. relation – コンテンツとその他のresourceとの関係。例えば、当該のコンテンツが、本のチャプターの1つかどうか
  14. coverage – resourceが物理的に置かれている場所
  15. rights – 著作権情報へのリンク

パート 2 – 例

実際のダブリンコアのメタデータの例を掲載する。このコードは、quicksprout.comの仮想の文書を表示する:

<head profile="http://dublincore.org">

<title>ニールパタルがダブリンコアを分かりやすくひも解く</title>

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />

<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />

<meta name="DC.Identifier" schema="DCterms:URI"

content="http://quicksprout.com/fakeitems/dublincore/" />

<meta name="DC.Format" schema="DCterms:IMT" content="text/html" /> <meta name="DC.Title" xml:lang="EN" content="Dublin Core Tutorial" />

<meta name="DC.Creator" content="ニール・パテル" />

<meta name="DC.Subject" xml:lang="EN" content="ダブリンコアのメタタグ" />

<meta name="DC.Publisher" content="I'm Kind of a Big Deal, LLC" />

<meta name="DC.Publisher.Address" content="neil@neilpatel.com" />

<meta name="DC.Contributor" content="ニール・パテル" />

<meta name="DC.Date" scheme="ISO8601" content="2012-06-01" />

<meta name="DC.Type" content="text/html" />

<meta name="DC.Description" xml:lang="EN"

content="このチュートリアルは、ニール・パテルが提供する上級者向けSEOガイドの一部です。" />

<meta name="DC.Identifier" content="http://quicksprout.com/fakeitems/dublincore/" />

<meta name="DC.Relation" content="QuickSprout.com" scheme="IsPartOf" />

<meta name="DC.Coverage" content="I'm Kind Of A Big Deal, LLC" />

<meta name="DC.Rights" content="著作権 2012 ニール・パテル 全ての権利を保有" />

<meta name="DC.Date.X-MetadataLastModified" scheme="ISO8601" content="2012-06-01" />

<meta name="DC.Language" scheme="dcterms:RFC1766" content="EN" />

おまけ: ダブリンコアのジェネレータ

投稿済みのウェブページにこの無料のダブリンコアのジェネレータを実行してみよう: http://www.ukoln.ac.uk/metadata/dcdot/


5. グーグルのrel=authorタグを複数の作者が存在するサイトに実装する方法

rel=authorを複数の作者が存在するサイトに実装する方法は2つある。

簡単な方法

この簡単な方法では、リンクを各投稿から、rel=authorを使って、対応するグーグルプロフィールページに向けるだけである。

ステップ 1: 個別の作者のプロフィールに各投稿からリンクを張る

AとBの2本の記事が投稿されたブログを運営していると仮定する。Aを書いたのは私だが、Bは別の作者によって投稿された。この場合、それぞれの投稿に対して、次の作業を実施することになる:

A

オプション A: グーグルプラスのバッジ

先程も申し上げた通り、 https://developers.google.com/+/plugins/badge/personal-configにアクセスしてコードを作成する(自分のグーグルプラスのIDを利用すること)。しかし、この場合、自分が作成した個別の投稿にコードを貼り付けるだけである。

オプション B: rel=authorタグを利用する

<a href="https://plus.google.com/109412257237874861202?rel=author">Neil Patel</a>

これも従来のrel=authorタグの利用方法である。名前とグーグプラスのプロフィールのIDを自分のものに置き換え、自分が作成した投稿またはページのみに貼り付ける。

新しい代案: 特別なパラーメタのリンクを利用する

<a href=”https://plus.google.com/112759904453577892472?rel=author>+Neil Patel<a/>

作者のプロフィールにリンクを張る方法の中で、これは最も簡単である。上のコード(名前とリンクを自分のものに置き換えること)を作成したページに貼り付けるだけでよい。

B

最適なオプションを選択し、上述のステップを繰り返す。しかし、この場合、ゲストの作者一人一人にauthorのリンクを加えていく必要がある。

オプション A: グーグルプラスのバッジ

グーグルプラスのバッジのコードを https://developers.google.com/+/plugins/badge/personal-configで切り取り、貼り付ける。今回は、ゲストの作者のプロフィールの情報を利用する。

オプション B: rel=authorタグを利用する

ゲストの作者に対するタグの例を掲載する:

<a href="https://plus.google.com/100613060119695637213?rel=author">Guest Author</a>

全てのページで、ゲストの作者に対してこのプロセスを繰り返したら、ステップ 2に進む。

ステップ 2: それぞれの作者が“contributor”リンクを寄稿した全てのブログに張る

サイトに寄稿した作者は、サイトに対するリンクをそれぞれのグーグルプラスのプロフィールの“contributor”のセクションに加える必要がある。“contributor”セクションには好きなだけリンクを加えることが可能であり、どれだけ多くのサイトにコンテンツを提供していたとしても、自分が作者である点を証明することが可能である。

例えば、3つのサイトに寄稿するSujan Patelのプロフィールを見てみよう:

上級者向けのメソッド

ステップ 1: すべての作者にプロフィールページを設定する

この上級者向けのメソッドでは、すべての作者に個別のページを用意する必要がある。次のスクリーンショットを見れば分かるように、SEOmozは巧みにこの取り組みを実施している。

一部のワードプレスのテーマはこの機能を内蔵している。この機能が提供されていないなら、セクション「ワードプレスで作者のプロフィールを自分で設定する」を確認してもらいたい。

ステップ 2: ブログの投稿からプロフィールページへのrel=”author”リンクを加える

作者が1人しかいないブログで、“rel=author”リンクをグーグルプラスのプロフィールに向ける方法を思い出してもらいたい。複数の作者が在籍するブログでは、rel=authorを当該のウェブサイトのプロフィールページに向けることになる。

ステップ 3: 経歴ページからグーグルプロフィールへのrel=”me” を加える

次に、3本目のリンク – 経歴のページからグーグルプラスのプラフィールページへのリンク – を作成する。

このリンクは最後のつながりを確立する。すると次のような鎖が出来あがる:

投稿 (rel=author) -> 経歴/プロフィール (rel=me) -> グーグルプラスのプロフィール

ステップ 4でも説明していくが、この鎖は逆方向でも同じように作用する。

グーグルプラスのプロフィール(contributorリンク) -> 経歴/プロフィール

ステップ 4: グーグルプロフィールから、作者の経歴ページに逆にリンクを張る

現時点で、リンクをグーグルプラスのプロフィールから、寄稿するサイトに追加する方法には、既に慣れているはずである。

この最後のステップでは、リンクが、自分が寄稿しているウェブサイトの経歴/プロフィールのページ直接向けられている点に注目してもらいたい。私のグーグルのプロフィールからSEOmozに戻るリンクは次のようになる:

http://www.seomoz.org/users/profile/361137


6. グーグルのrel=authorタグを作者が1人のサイトに実装する

作業に取り掛かる前に: グーグルプロフィールを設定する

この時点で、まだグーグルプロフィールを設定していないなら、今すぐに設定してもらいたい。これは、グーグルプラスのページを作る取り組みと同じぐらい重要である。

作者のプロフィールを設定すると言うコンセプトは、基本的に2つの場所にリンクを張ることを意味する。次のようにウェブサイトからグーグルプロフィールに相互にリンクを張ることになる:

ウェブサイトの全てのページ (rel=author) -> グーグルプラスのプロフィール

グーグルプラスのプロフィール (contributor) -> ウェブサイト

一度全てのステップを踏めば、割と簡単に実施することが出来るが、知っていてもらいたい複数のオプションと細かい設定があるので、紹介していく。

ステップ 1: rel=authorをサイトに加える

オプション A

グーグルプラスのバッジをサイトにインストールする

https://developers.google.com/+/plugins/badge/personal-config 

上のスナップショットに表示されているように、コードを取得し、サイトの掲載したい場所に貼り付ける。ワードプレスを利用している場合、サイドバーのウィジェットに通常は掲載される。

自分のグーグルプラスのプロフィールのIDを利用すること。

オプション B

サイトの全てのページからグーグルプラスのプロフィールにrel=authorのアトリビュートを使ってリンクを張ることが出来る。

これはオーサープロフィールが導入された時に、初めて利用することが可能になった方法である。

ブログの全てのページの自分の名前から、グーグルプロフィールにリンクを張る必要がある。

ワードプレス等のコンテンツ管理システムを利用し、自分の名前が記入された「about」ボックスを利用することが出来るなら、フッターやサイドバーのウィジェットを介して、この作業を簡単に実施することが可能である。

以下にコードを掲載する。サイドバーやフッターに切り取り & 貼り付けよう:

<a href="https://plus.google.com/109412257237874861202?rel=author">Neil Patel</a>

当たり前だが、自分の名前とグーグルプラスのプロフィールのIDを利用する必要がある。

最新の代案 – ステップ 1: 特別なパラメータのリンク

ブログのページからグーグルのプロフィールにリンクを反対に張る、この新しいシンプルな方法はあまり知られていない。これは、rel=authorが初めてリリースされた際に、HTMLを編集することなくリンクを実装する簡単な方法としてデビューした。

まず、作者の名前がサイトのページに表示されている点を確認し、次のリンクに変える:

<a href=”https://plus.google.com/112759904453577892472?rel=author>+Neil Patel<a/>

私の名前の前に+が記されている点に注目してもらいたい。これは、URLの最後に特別なパラメータを利用していることをグーグルに伝える上で効果がある。ここでもやはり、自分のグーグルプラスのプロフィールのURLを利用してもらいたい。

このメソッドでは、rel=authorアトリビュートやグーグルプラスのバッジを利用する必要がない。

3つのどのメソッドを利用していても、これで、グーグルのプロフィールをサイトに向ける準備は整ったことになる。

ステップ 2: グーグルのプロフィールからサイトにリンクを返す

ログインして、プロフィールページにアクセスし、Edit Profileをクリックする。

プロフィールの“contributor”セクションを利用する

ブログをリンクとして加える

リッチスニペットのテストツールを使ってテストを行う - http://www.google.com/webmasters/tools/richsnippets

するとオーサーシップを正確に実装したかどうか、そして、SERPでページがどのように提示される可能性があるかが分かる。


7. エンティティ検索

エンティティ検索は、まだ生まれたばかりの分野である。現段階では、特定のタイプの人、ウェブサイト、または、企業しかこの機能を利用することは出来ないが、間もなく一般公開される見込みである。

このセクションは、他のセクションとは異なり、コンセプトに焦点を絞って説明していく。

エンティティ検索とは?

「ナレッジグラフ」と呼ばれることが多い。あまり意味を持たない単なるキーワードではなく – 人、場所、そして、物事を結びける。例えば、キーワード「boston」は場所を意味するかもしれないが、バンド名でもある。

「boston」に対する現在のナレッジグラフを見ていこう。

このデータは、どのようにしてこの場所に提示されたのだろうか?グーグルは、ウィキペディア等の各種のデータレポジトリからデータを引き出している。

SERPの右側に掲載されるナレッジフラフは、結果のようにエンティティが表示される場所として、最も目立つ場所と言えるだろう。隠されることもあるが – ここにエンティティのタイプの結果が表示される。

インプライドサイト検索

グーグルは長らくこのサイト検索から距離を置いているが、インプライドサイト検索と言う機能が実在する。通常のsite search:に関しては、ご存知の方が多いのではないだろうか。

それではインプライドサイト検索の結果を見ていく:

上位の6つの結果は全てquicksprout.comのページである – グーグルはquicksproutを会社 – エンティティと認知しており、そのため、この検索を上位の検索結果に対するサイト検索に書き換えることが出来る。

related search オペレータ

この機能を利用している人はあまりいないが、quicksproutのrelated: searchの結果を見ていこう。

ご覧のように、ウェブ開発、ブログ、そして、分析のトピックとのquicksproutの関係が明確に表れている。このようにエンティティの関連性は役に立つ。このようなサイトの間では重要なキーワードが共有されているわけではないが – それでもお互いに関連するサイトとして表示される。

この、エンティティとの関連性が、誰にでも当てはまるわけではない点を実証するため、以下に結果がゼロのrelated:searchを掲載する。

自然言語検索

「自然な言語検索」でもエンティティの結果が表示される。これには、質問、文、もしくは、ロングテールのディスクリプションの検索クエリが該当する。

例 – “what’s the capital of florida?”

グーグルは質問に対する答えを返している。これは「キーワード」よりも、フロリダが州であり、タラハシーがフロリダ州の州都であることが最も重要視されている。

グーグルにエンティティとして見てもらうことのメリットが、徐々に理解してもらえるようになっただろうか?ウェブ上で複数の場所で表示され、オーソリティを高める効果が見込める。

次のセクションでは、エンティティベースのソースに選んでもらう上で役に立つ具体的な方法を紹介する。


8. エンティティベースのソースにサイトに加える

一つ前のセクションでは、グーグルにエンティティとして見てもらうことの重要性、そして、エンティティとして出来るだけ多くの関連する情報を持つことの重要性を説明した。それでは、実際にエンティティ検索を活用するにはどうすればいいのだろうか?フリーベースに取り上げてもらう必要がある。

以下に、グーグルがエンティティの情報を得るために利用する場所が掲載された、私の知る限り最も広範なリストを提供する。

  1. abc.state.va.us/Pricelist/RUM_(IMPORTED).html
  2. Adherents.com
  3. ArXiv
  4. Baseball Almanac
  5. Berlin International Film Festival
  6. Books and Writers kirjasto.sci.fi/
  7. bornrich.com
  8. Boston.com
  9. Bureau of Labor Statistics, Unemployment in US
  10. Bureau of Labor Statistics, Unemployment in US Counties
  11. Bureau of Labor Statistics, Unemployment in US States
  12. Câmara dos Deputados
  13. celebritynetworth.com
  14. Center for Responsive Politics
  15. ChefMoz
  16. chickipedia
  17. Claud Butler
  18. croctail.corpwatch.org/
  19. Crore
  20. Crunchbase.com
  21. Database
  22. databasebasketball.com
  23. databaseFootball.com
  24. DatabaseOlympics
  25. DayLife.com
  26. E-LIS
  27. en.citiZENdium.org/wiki/
  28. English Wikipedia
  29. Eurostat, Minimum Wage in Europe
  30. exploredia.com
  31. Facebook
  32. Factual
  33. famenetworth.com
  34. FDIC
  35. Food and Drug Administration
  36. Forbes
  37. France
  38. Freebase
  39. GEBCO Undersea Features Gazetteer
  40. Geographic Names Information System
  41. Geonames.org
  42. German Wikipedia
  43. Google Plus
  44. Healthcare Cost Report Information System
  45. https://protecfuelsaver.com/diesel-fuel-cleaner
  46. https://protecfuelsaver.com/gas-fuel-cleaner
  47. https://protecfuelsaver.com/oil-system-rehab
  48. https://protecfuelsaver.com/PROTEC-Internal-Engine-Cleaner
  49. Hulu
  50. IES NCES Public Library Survey
  51. imdb.com
  52. Infochimps
  53. InstantEncore
  54. Internet Movie Database
  55. Internet Speculative Fiction Database
  56. Internet Speculative Fiction Database
  57. ISO 15924
  58. ITIS
  59. Library of Congress
  60. Library of Congress id.loc.gov/
  61. Lurkmore.ru
  62. MBLWHOI Library
  63. Medpedia
  64. Metaweb topic merging algorithm
  65. Mexican INEGI statistics
  66. Million
  67. MusicBrainz
  68. MySpace
  69. Named entity recognition
  70. National Center for Education Statistics
  71. National Fire Department Census Database
  72. National Oceanic and Atmospheric Administration
  73. Nature
  74. Netflix
  75. Nielsen Company
  76. Official Website
  77. Open Library
  78. Open Library Project
  79. OurAirports
  80. Paragliding Earth
  81. Pocket Statistical Data on Switzerland 2006
  82. Pocket Statistical Data on Switzerland 2007
  83. Public domain
  84. PubMed Central
  85. Quotationsbook
  86. Ranker.com
  87. Reference.com
  88. Securities and Exchange Commission sec.org
  89. Simon Property Group
  90. SkyGrid
  91. Slovak Statistical Office
  92. Stanford University
  93. StarCraft and StarCraft II Wiki
  94. The Football Database
  95. The Hollywood Reporter
  96. The National Institute of Statistics, Spain
  97. The TVDB
  98. The World Factbook
  99. therichest.org
  100. topics.nytimes.com
  101. TVRage
  102. tvrage.com
  103. U.S. Food and Drug Administration National Drug Code Directory
  104. UN Stats
  105. Unified Medical Language System Release 2011AB
  106. United States Census Bureau
  107. United States Census Bureau, Population
  108. United States Department of Housing and Urban Development
  109. United States International Trade Commission
  110. United States Securities and Exchange Commission
  111. Virtual INternet Authority File viaf.org/
  112. Wikipedia
  113. Wikipedia Categories
  114. Wikipedia infoboxes
  115. World Bank, World Development Indicators

フリーベースは、上に挙げた全ての場所からデータを引き出す。それでは、フリーベースに自分のサイトを追加する方法を伝授する。

Freebase

注記: フリーベースへの登録を、ディレクトリへの投稿、または、スパムと一緒にしないでもらいたい。フリーベースは、編集可能な公開されているデータベースである(グーグルが買収したメタウェブが始めた)。リンクを落とす場所でも、投稿を行う場所でもない(いずれにせよ、あまり効果はないだろう)。ここでは、エンティティの情報が完全であり、誤りがないことを確認してもらいたい。

1. アカウントを作成する

2. アカウントを作ったら、Edit Modeを選択する(編集するトピックを閲覧するのが楽になる)。

3. 次にエンティティが存在するかどうか確かめる

何度もエントリする行為は、ひんしゅくを買う(削除される)。ページで、検索ボックスを使って、エンティティが存在するかどうか確認しよう

4. 見当たらなかったら – 「トピック」を探す

トピックは、エンティティが最もフィットするカテゴリである。例えば、ZapposはCompanyに振り分けられ、American IdolはTV Programに分類される。

QuickSproutにはInternet Companyが最も適すると考えられるため、このトピックのページにアクセスする。

5. トピックページにアクセスしたら、「view all」をクリックする

6. 次に「add more topics」をクリックする

7. 再びエンティティに対する検索を行い、確認する – 表示されなかったら、「create new topic」をクリックする

8. リストに新しいトピックが表示される – クリックする

9. Edit Modeに設定しているため(ステップ 2)、新しいトピックに対する情報を追加 & 編集することが出来る

繰り返すが、これはセールスページではない。事実に基づくウィキペディアのエントリのように扱ってもらいたい。


このチャプターはここで終わるが、schemaやエンティティ検索の重要性を深く理解してもらえたのではないだろうか。ウェブサイトを「未来の検索」フレンドリーにする上で役立ててもらいたい。

上級者向けSEOガイドの記事一覧はこちらから


この記事は、Quick Sproutに掲載された「Chapter 3: New Search」を翻訳した内容です。

相変わらずの充実度でした。余りに種類がありすぎて、どこから対応していけばいいかわからない、、、(スミマセン、正直私も迷います)という意見もあると思いますが、まずは検索結果の表示内容に直接インパクトがありそうなものから徐々に対応していくのが結果も出ますし確実そうですね。 — SEO Japan [G+]

GoogleのWaze買収の効果が一つ実る: MapsがWazeのリアルタイム事件事故報告をインポート

GoogleがWazeを買収したのは、当然ながらGoogle Mapsを良くするためだ。そして今日(米国時間8/20)まさにMapsは、そのモバイルのアプリをアップデートしたことによって、やや良くなった。Wazeのリアルタイム事件報告をAndroidとiOSのアプリの導入したのだ。

Wazeでは、ユーザが事故、路肩駐車、工事、道路封鎖などを、見つけた運転者がリアルタイムで報告できる。それによってほかのユーザは、いろんな対策をとれる。この機能を使えるのは、アルゼンチン、ブラジル、チリ、コロンビア、エクアドル、フランス、ドイツ、メキシコ、パナマ、ペルー、スイス、イギリス、合衆国だけだが、今後もっと増える予定だ。

ただし、このMapsのアップデートはリードオンリーだ。つまり、事件報告を見るだけ。報告行為はWazeからでないと、できない。Wazeのアプリも、今日アップデートされ、ユーザにGoogleの機能を少々おすそ分けした。Google Search(検索)、ストリートビュー、衛星画像などだ。いずれも、Waze上で熱心にいろいろ報告する人を助けるだろう。

Googleの、Wazeの扱い方も見えてきた。Mapsに完全合体させるのではなくて、むしろMapsプロジェクトの“枝”の一つとして、コミュニティ起源の製品開発部門、という位置づけだ。だからWazeはWazeで便利なアップデートの提供を続けることが結果的に、Mapsの情報力の強化にもつながるのだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Chrome 29がリリース: Android用はWebRTCをサポート, デスクトップはサイト提案を改良

ふつうどおりのアップデートサイクルとしてGoogleは今日(米国時間8/20)、同社のChromeブラウザのバージョン29をリリースした(Mac, Windows, Linux, Chrome Frame)。サプライズは何もないが、安定版のアップデートによくあることとして、小さなアップデートがいくつかある。まずデスクトップでは、URL入力と検索入力を兼用するChrome独特のOmniboxが、ユーザが最近訪れたサイトも参考にして提案をするようになった。

Omniboxのこの新しいアルゴリズムについてGoogleは、“よりタイムリーでそのときの状況によく合った提案ができる”、と言っている。

Macのユーザは、Chrome 29 for Macが、Chromeバージョン28からの<リッチ通知>機能をやっとサポートしたと聞いて嬉しいだろう。“これからはあなたのアプリケーションやエクステンションで起きていることがすぐに分かるようになります”、という次第だ。

デスクトップのもう一つの新機能は、ブラウザの設定を数クリックでリセットできることだ。楽しいエクステンションをたくさん導入しすぎたときの掃除などによい、という。リセットするとブックマークやテーマやアプリケーションはそのままだが、エクステンションはすべて削除される。

今回のアップデートで、ChromeのAPIも新たに増えた。その多くは、今年初めにベータチャネルで紹介されていたものだ。

WebRTCがAndroidに

Chrome 29 のいちばん重要なアップデートは、AndroidバージョンがWebRTCをサポートしたことだろう。プラグイン不要でビデオやオーディオの高速伝送を可能にする、今や人気者の機能だ。これでデベロッパにとっては、モバイルのWebRTCがいわば標準機能になるから、その採用も短期間で広まるだろう。なお、GoogleがWebRTCで実装したビデオチャットアプリケーションの例がここにある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Android版YouTubeで大改造を実施。検索中も(最小化画面にて)ビデオ再生を継続

Googleは一部利用者に対してAndroid版YouTube最新版の提供を開始した。これまでの更新履歴を振り返っても最大級のもののひとつだといえそうだ。いわゆるアプリケーション内マルチタスキングをサポートしているのだ。どのようなものかといえばすなわち、チャネル内を閲覧していたり、あるいは検索中には、再生中のビデオを最小化して表示するというものだ。また、Googleが提唱する「カード」インタフェースもサポートするようになった。

これまでは別のビデオを探したりする際には、閲覧中のビデオを停止する必要があった。新しいバージョンでは再生中のビデオは右下隅に表示されるようになり、再生は継続されるようになる。最小化状態からフルスクリーンには簡単に戻ることができる。あるいは左右にスワイプすれば再生中のビデオは停止する。

他の動作をしているときにビデオ再生をストップしないというのが、新リリースの目玉であることは間違いない。しかし他にもいろいろな新機能が搭載されている。たとえばビデオを連続して閲覧できるようなプレイリストの検索が、一層簡単に行えるようになっているのだ。

Google Chromecastのリリースなどもあり、YouTubeアプリケーションに利便性向上は当たり前のことと言えるのかもしれない。Chromecastや、スマートTVでビデオを再生していても、他の作業を行いつつプレビュー画面を見ることができるようになるわけだ。ビデオを次々に再生していくのに必要な機能が実装されつつあると言えるだろう。

今回のアップデートが、いつiOS版に反映されるのかについて正式なアナウンスはない。しかしGoogleによれば、すぐにも全プラットフォームに対応する予定なのだそうだ。

Android版は部分的なリリースから始まっているが、まもなくすべての人に公開されるようになりそうだ。公式リリースが待てないという人のためには、Android PoliceがAPKへのリンクを公開している。

原文へ

(翻訳:Maeda, H)


上級者向けSEOガイド2/9 : サイトスピードとパフォーマンス改善

米国のカリスマウェブマーケッター、ニール・パテルが書き下ろした上級者向けのSEOガイドを紹介する記事シリーズ第二弾。今回はランキングへの影響はもちろん、それ以上にサイト内のユーザーアクションにも大きな影響があるといわれるサイトスピードやパフォーマンスの確認&改善方法について。この種の記事はこれまでにも様々な所で紹介されていますが、その中でも網羅度&マニアック度はNo.1クラスの充実した内容です。 — SEO Japan

チャプター 1では、サイトをクロール可能 & アクセス可能にするための方法を伝授した。チャプター 1を完了し、ウェブ上のその他の多くのサイトよりも優れたサイトにすることが出来れば、まずまずの出だしと言えるだろう。

次にさらにレベルを上げ、サイトをスピードアップさせて、より効率良く動かす上で役に立つテクニックを紹介していく。効率を高めることが出来れば、ユーザーエクスペリエンスだけでなく、検索エンジンにとってもプラスに働くはずだ。

このチャプターを読み進めていけば、サイトを期待通りの早さで動かす方法に関するアドバイスを得られるはずである。


1. サイトのスピードを計測する

ページスピード、または、ページのロード時間は、ランキングを少し押し上げる効果が期待できるだけでなく、ユーザーもサクサク動くサイトを好むため、欠かせない要素の一つである。ビジターに早さを提供する取り組みは非常に重要度が高い。

サイトスピードを計測する2つの方法を紹介する。

1. グーグルのPageSpeed Online

2. グーグルのクローム向けPageSpeedプラグイン

1. PageSpeed Onlineを利用する

ステップ 1 – Google PageSpeed Onlineにアクセスする

 https://developers.google.com/pagespeed/にアクセスする

ステップ 2 – ホームページでツールを実行する

すると総合スコアが得られる。ホームページのスコアは、サイト全体の基準として、有効である。

次に、優先順位がつけられた課題のリストを詳しく見ていくことが出来る:

まずは優先順位の高いアイテムと中ぐらいのアイテムに絞るべきである。アイテムをクリックすると、詳細が表示される。

このツールを利用すると、各アイテムに対する詳細な提案が得られる。一般的な問題の解決策に関しては、このガイドの後半で紹介する。とりあえず、ここではツールを使って、問題を診断する。

ステップ 3 – 内部のページでツールを実行する(特にホームページとはスピードが異なる可能性が高いページ)

私のサイト クイックスプラウトには、その他のページとは毛色が完全に異なるページが1つある –  http://www.quicksprout.com/pro/

そのため、PageSpeedツールをこのページで実行し、違いを見つけておく。なぜなら、これはセールスのページであり、重要度が高いためだ。

ステップ 4 – モバイルのサイトスピードをテストする

右上の“mobile”タブをクリックする

内部のページのテストも忘れずに実施すること


2. ページのロードをアナリティクスで追跡する

ページのロードスピードをアナリティクス内部で測定することが出来る点は、ご存知の方も多いだろう。しかし、その他にも幾つかこのアプローチを活用する方法があることは、あまり知られていない。

2つの方法で手順を紹介していく:

1. ワードプレスで計測する

2. ワードプレス以外のサイトで計測する

パート 1 – ワードプレスで追跡を設定する

ステップ 1 – 通常の追跡コードをインストールする

通常の分析追跡コードをワードプレスにインストールする方法、さらには、ページスピードのコードのスニペットをインストールする方法に関しても、既にご存知なのではないだろうか。

ここではGoogle Analyticator プラグインを利用する。

これは基本中の基本だが、ヒントになるはずである。ここに追跡コードをインストールする。

次に、ページスピードを設定する前に、ユーザーの追跡を正確に設定しているかどうかを確認する。念には念を入れよう。

以下のシンプルな3つの手順に従う必要がある:

1. “no”を選択する

2. トラフィックを追跡したくないユーザーにチェックを入れる(私ならadminのみにチェックを入れる)。

3. “Remove”を選ぶ – これが一番簡単な方法だ。

次にサイトスピードの設定に移る。この分析プラグインでは、とてもシンプルな設定方法が用意されている。

“enabled”になっていることを確認する。

簡単過ぎると思った方もいるのではないだろうか。しかし、これはあくまでも上級者向けのガイドである。これで基本の設定はカバーしたので、幾つかさらに重要な機能を加えていく。

ステップ 2 – Sample Rateを設定する

あまり知られていないが、sample rateを設定することが出来る。通常、グーグルアナリティクスは、サイトスピードのデータの大半を測定の対象から外している(デフォルトでは1%のみ)。そのため、、小規模なサイトを運営しているなら、多くの重要なデータを見失っている可能性がある。

Sample Rateは、トラッカーの初期設定の前にインストールする必要があり、適切なボックスを利用する必要がある点に注意してもらいたい。

以下にコードのスニペットを掲載する(Asyncのスニペット):

_gaq.push(['_setSiteSpeedSampleRate', 5]);

数字の‘5’に注目してもらいたい。これは、新しい sample rateである – 全ての訪問の5%を指す。一ヶ月に訪問が1万回以下の小規模なサイトの場合、この数字を50、もしくは100に上げても問題ないが、理に適った量のデータの収集に徹してもらいたい。

しかし、サイトが、1日に10000回以上訪問される場合、グーグルは、自動的に1%のサンプルのみを集める可能性がある点を留意しておこう。

出来るだけサイプルの規模を抑えつつも、データを集める上で十分な量に指定することを薦める。

ステップ 3 – ソースコードを確認する

適切に動いていることを確認するため、常にソースコードを確認する癖をつけるべきである(adminとしてコードを閲覧することが許可されないため、ワードプレスにログインしている間は、チェックするべきではない)。

次のスクリーンショットのように、Track Pageviewの上にSample Rateのコードが表示されているはずだ。

パート 2 – ワードプレス以外のサイトで設定する

基本的に同じようなプロセスだが、全ての手順を説明していく。

ステップ 1 – グーグルアナリティクスを探し出す

サイトの設定によっては、ヘッダーを処理する.phpファイルを持っている人もいれば(ワードプレスのように)、ヘッダーが用意された静的なHTMLファイルを持っている人もいる(この場合、全てのファイルをアップデートしなければならない)。

私たちの例ではheader.phpを利用している。

ステップ 2 – ページロード時間のコードを加える

基本的なことだが、ページロード時間のコードを忘れずにアナリティクスに加えておこう:

以下にアナリティクスのコードを掲載する。ページロード時間のコードは太字で表記しておく:

<script type="text/javascript">

 var _gaq = _gaq || [];

 _gaq.push(['_setAccount', 'UA-1589983-1']);

 _gaq.push(['_trackPageview']);

 _gaq.push(['_trackPageLoadTime']);

 (function() {

   var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;

   ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';

   var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);

 })();

ステップ 3 – Sample Rateコードを加える

次に同じようにsample rateコードを加えていく:

再び、次のコードを利用する:

_gaq.push(['_setSiteSpeedSampleRate', 5]);

数字を使って(今回は5)ページスピードを計測するサイトの割合を調節することが出来る。

レポートの場所

次の順にアクセスしていくと、このデータを見ることが出来る:

Content->Overview->Site Speed

次の手順を見過ごす人達が多いので注意してもらいたい。“page timings” ->にアクセスし、“technical”をクリックする。

この画面は、サイトのスピードに何が影響を与えているのかを示している。

アナリティクスの設定をテストする

最後にアナリティクスのクローム用プラグイン Debuggerを使ってテストを行う -

https://chrome.google.com/webstore/detail/jnkmfdileelhofjcijamephohjechhna

以上


3. ヤフー!のYSlow プラグインを利用する

ステップ 1 – YSlowをインストールする

 http://yslow.org/にアクセスする。

ブラウザにYSlowプラグインをインストールする(インターネットエクスプローラ以外)。

ステップ 2 – YSlowを開き、実行する

rulesetには3つの選択肢が用意されている:

1. YSlow (V2) – 23 ruleのフルセットを実行する

2. Classic (V1) – 初めの13のruleを実行する

3. Small Site or Blog – 小規模なサイトに適用される14のruleを実行する

1ヶ月間の訪問が1万以下の場合に限って、small site or blogを利用するべきである。1万を超えるなら、YSlow (V2) を選ぶことを薦める。

テストしたページを読み込む。“Run Test”をクリックする。

ステップ 3 – 結果を確認する

Overall performance score – 85(B)を目指そう。

また、結果のタイプでレポートを絞り込むことも出来る。

優先順位付けの戦略として、私ならまずはFに力を入れる。

各レポートには、簡単な説明、そして、ヤフー!のディベロッパーサイトに掲載されている詳細へのリンクが記載されている。

YSlowに返された一つ目のエラーを確認する。

Make Fewer HTTP Request

“This page has 23 external Javascript scripts. Try combining them into one.

This page has 7 external stylesheets. Try combining them into one.

This page has 19 external background images. Try combining them with CSS sprites.”

これは一般的なエラーであり、CSSとJSファイルが最適化、そして、縮小されていないために起きている。

この分野の改善に関しては、”LESSを使ってCSSを最適化する”セクションを参考にしてもらいたい。

それでは、特に簡単な分野の一つ – 大きなイメージの縮小に取り掛かろう。


4. 大きなイメージを見つけて縮小する

大きなイメージは、サイトスピードの低下の要因となっていることが多い。そこで、大きなイメージを見つけ、縮小するための方法を紹介していく。

メソッド 1 – グーグルの画像検索

グーグルの画像検索を使って、大きなイメージを発見することが可能だ。これは、手っ取り早く、簡単に見つけられるイメージを探し出すメソッドとしてうってつけである。。

ステップ 1 – グーグルの画像検索にアクセスする

images.google.com

ステップ 2 – サイト検索を行う

site:quicksprout.comで検索をかけると、グーグルがインデックスした私のサイトのイメージが全て表示される:

ステップ 3 – セーフサーチをオフにする

確実にすべてのイメージを表示させる必要がある。

ステップ 4 – サイズで絞り込みを行う

まずは控えめなサイズ – larger640×480以上を選び、絞り込みをかける。

ステップ 5 – 結果を見る

結果を見る際は、「大きな」イメージになるべきではないにも関わらず、最終的にサイズが大きくなっているイメージを見つけてもらいたい。CSSやHTMLで、望む大きさにサイズが変更されている可能性がある。

以下に結果ページを掲載する。私はこのイメージが気になった:

写真をクリックすると、実際のサイズは遥かに大きいことが分かる。


これは明らかに大きなイメージを手っ取り早く探す手法である。続いて、スケールに応じて、より効果が高いアプローチを紹介していく。

メソッド 2 – スクリーミングフロッグ SEO スパイダーを利用する

スクリーミングフロッグを使って、サイトをクロールし、ファイルサイズごとに大きなイメージを表示させていく。

ステップ 1 – サイトをクロールする

チェックしたいサイトをクロールする。

次にイメージをクリックする。

Over 100kbで絞り込む。

サイズで絞り込みをかける。

.csvにエクスポートする。

スプレッドシートを使って、イメージの縮小プロセスの進捗状況を記録していく。大きなイメージを大量に抱えているなら、この作業には時間がかかるかもしれない。


5. グーグルクロージャーを使って、スピードを最適化する

JavaScriptを縮小して、単一のファイルに変えることで、ウェブサイトのスピードを改善することが出来る。なぜなら、多くの大きなファイルではなく、単一の小さなファイルをダウンロードすれば済むようになるためだ。これから、グーグルのクロージャーツールをインストールし、JavaScriptを全て縮小する方法を伝授する。

  1. グーグルのコンパイラークロージャーサイトにアクセスする
    ウェブサイトのURL: http://code.google.com/p/closure-compiler/
  2. downloadをクリックする
    リンク「compiler-latest.zip」をダウンロードする。
  1. ZIP ファイルを開く

    Mac:
    ZIP ファイルをダブルクリックする。すると、「JAR」ファイルが含まれる同じ名前のフォルダが生成される。

  2. JAR ファイルを全てのJavaScriptが存在するフォルダにコピーする

    この例では、compiler.jarファイルをJavaScriptがあるフォルダにドラッグしている。

  1. コマンドラインのウィンドウを開く

    Mac:
    Finderにアクセスし、 Applications > Utilities > Terminalの順に開いていく。ウィンドウズ:
    Startをクリックし、“command prompt”を入力し、“command prompt”をクリックする。
  2. JavaScriptが保存されているフォルダに変える

    Mac:
    “~/” を入力すると、JavaScriptのフォルダの場所が特定される。

    この例では、私のJavaScriptが、code、os2、public、JavaScriptと言うフォルダのホームディレクトリに存在することが判明している。

    ウィンドウズ:
    “cd \”を入力すると、JavaScriptのファイルが存在するフォルダが明らかになる。
  3. Javaのコマンドを入力して、縮小したJavaScriptのファイルを生成する

    ウィンドウズおよびMac:
    次のコードを入力する: “java -jar compiler.jar –js jquery.js jquery_spinner.js –js_output_file output.js

    “jquery.js”と“jquery_spinner.js”を縮小したいJavaScriptのファイル名に置き換える。順番が重要なら、適切な順序で入力していく。

    output.js”を置き変える

    この例では、jquery.jsと“jquery_spinner.”と呼ばれるプラグインをコンパイルした:

4. 縮小したJavaScriptファイルをプロジェクトに戻す

この例では、列 8を加え、JavaScriptをHTMLファイルに追加した。

5. 最後にテストして、全て動作するかどうかを確認する


6. CSSファイルとJSファイルを最適化する

二つ目のセクションと三つ目のセクションでは、サイトのパフォーマンスを評価する方法を取り上げた。次に、CSSファイルとJSファイルを、「LESS」を使って最適化する上級者向けの方法を伝授する。

LESSは動的なスタイルシートの言語であり、CSSを作成する。ここでは、LESSコンパイラーに自動的にCSSファイルを縮小させ、ユーザーがページをダウンロードするスピードを上げる、高度なテクニックを紹介する。

  1. Lessのアプリケーションをダウンロード & インストールする
    Lessは、CSSファイルを圧縮するための無料のアプリケーションを用意している

    Mac:
     http://incident57.com/less/を訪問し、Less.Appをダウンロードする。

ウィンドウズ:
 http://winless.org/を訪問し、WinLessアプリケーションをダウンロードする。

  1. Lessをコンピュータにインストールする。
    Mac: ダウンロードをダブルクリックし、LessアプリをApplicationのフォルダに移動する。
  1. Lessアプリケーションを開く
    Mac:
    Applicationフォルダをクリックし、Lessをダブルクリックする。
  1. CSSファイルが保存されているフォルダを開き、CSSファイルの名前を「.less」に変える。
    この例では、ワードプレスのテーマのCSSファイルを取り上げ、すべて「.less」に変更している。

    変更前:
    変更後:

  1. Lessファイルを持つフォルダをLessアプリケーションにドラッグする

    この例では、Lessファイルを含むフォルダをアプリケーションにドラッグして移動している:
  1. Click、そして、Compileをクリックしていく
    すると、ダウンロードのスピードアップにつながる、新しいCSSファイルが生成される。
  1. Lessは、開いている間に、自動的にLessファイルをCSSファイルに縮小する。
    アプリケーションが開いている時は、Lessファイルを変換する度に、自動的に縮小版CSSがアップデートされる。

Lessのファイルは通常のファイルと同じように表示されるため、編集することが出来る:

しかし、縮小したCSSファイルは次のように表示される:

この例では、ファイルサイズを2000削減した。大きな違いではないが、小さな最適化を重ねていくことで、ユーザーはより早くサイトをダウンロードすることが可能になる


7. グーグルのApache向けMOD_SPEEDをインストールする

  1. グーグルのApache向けMOD_SPEEDをインストールする

Apacheサーバーでウェブサイトを運営しており、サーバーの設定をモジュールレベルで変更する権限を持っているなら、MOD_PAGESPEEDをインストールして、容易にスピードアップを実現することが可能だ。

警告: このテクニックは難易度が非常に高く見えるが、実際にはサーバーレベルでApacheを設定した経験がある人にとっては、割と簡単である。しかし、経験のない人が自力でこのアプローチを実施してしまうと、ウェブサイト全体がダウンする事態になりかねない。Apacheのモジュールをインストールし、ウェブサーバーをコマンドラインから設定する方法を知っていることが前提である。この方法が分からないなら、経験豊かなプロのウェブ開発者かシステム管理者に任せるべきである。 

MOD_PAGESPEEDの詳細は次のURLで確認してもらいたい: https://developers.google.com/speed/docs/mod_pagespeed/using_mod

Debianベースのサーバーを利用している場合(DebianやUbuntu等):

  1. サーバーにSSHで接続する
  2. mod-pagespeed .debパッケージをダウンロードする。

    サーバーが32-bitのマシンなら、次のコマンドを利用する:
    wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb

    64-bitのマシンの場合は、次のコマンドを利用する:
    wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb

  3. .debパッケージをインストールする

    コマンドラインに次のコードを入力する:
    dpkg -i mod-pagespeed-*.deb
  4. 壊れた依存性を修正する

    次のコードをコマンドラインに入力する:
    apt-get -f install

RedHatベースのサーバーを利用している場合(RedHat、Fedora、またはCentOS):

  1. サーバーサーにSSHで接続する
  2. mod-pagespeed .debパッケージをダウンロードする

    サーバーが32-bitのマシンなら、次のコマンドを利用する:
    wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.rpm

    サーバーが64-bitのマシンなら、次のコマンドを利用する:
    wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_x86_64.rpm

  3. Yumパッケージマネージャーを使って、“at”をインストールする

    次のコードをコマンドラインに入力する:
    yum install at
  4. 壊れた依存性を修正する

    次のコードをコマンドラインに入力する:
    rpm -U mod-pagespeed-*.rpm

MOD_PAGESPEEDを設定する

  1. 編集するApacheの設定ファイルを開く

    UbuntuまたはDebianを利用しているなら、ファイルは次の場所にある:

    /etc/apache2/mods-available

    CentOS、Fedora、または、Redhatを利用しているなら、ファイルは次の場所にある:
    /etc/httpd/conf.d
  2. pagespeed_moduleのディレクトリを探す。
    IfModuleディレクティブの内側にある。

module per folderを有効または無効にする
サイトの.htaccessファイルに次の列を加える:

ModPagespeedを有効にするには:
ModPagespeed on

ModPagespeedを無効にするには:
ModPagespeed off


8. ブラウザのキャッシング(ワードプレス以外のサイト)

恐らく、皆さんの多くがワードプレスのサイトを運営しているはずである。そこで、パフォーマンスをスピードアップする上で役に立つプラグインを幾つか紹介していく。

しかし、まずは、ワードプレスを利用していない人達のために、スピードを最適化するための技術的な情報を提供する。

ここでは、ブラウザのキャッシングを活用するため、.htaccessファイルを利用する高度なテクニックを幾つか取り上げる。グーグルのPageSpeed Onlineで警告を受けたなら、以下のテクニックを利用して、問題を解決してもらいたい。

注記: .htaccessファイルの編集に慣れている必要がある。編集するべきかどうか分からないなら、ウェブマスターに声をかけるべきである。

ステップ 1 – FTPサーバーにログインして、.htaccessファイルをバクアップする

好きなFTPクライアントを利用するか、または、FileZillaをダウンロードして、利用する: http://filezilla-project.org/

FTPを介してログインする方法をご存知だとは思うが、念の為に簡単に説明しておく:

Host: ウェブサイトの名前

Username

Password

Port: 大抵の場合、ここは空白のままにしておく。

ステップ 2 – .htaccessファイルを探す

このファイルはルートディレクトリに存在する。隠れているファイルを見られる状況にしておく。さもないと、気づかない可能性がある。

注記: 場合によっては、.htaccessファイルを持っていない可能性もあるが、その場合は、新しいファイルを作成すればよい。テキストエディタで新しい文書を作り、名前を.htaccessにする。

ステップ 3 – .htaccessファイルをダウンロードして、バックアップする

次に、.htaccessファイルをダウンロードし、バックアップを保存する。安全に編集するためだ。万が一、ミスがあったら、復元しよう。

FileZillaで、右クリックし、ダウンロードする:

テキストエディタで開く。

次に、‘save as’をクリックし、テキストファイルとしてバックアップのコピーを保存する:

これで、編集する準備が整ったことになる。

ステップ 4 – コードを加える

手順ごとにコードを紹介していく。最後に切り取り & 貼り付けすることも出来るが、手順を追うことで、仕組みを理解することが可能になる。また、個人的に、実際に入力することを薦める :-)

写真ファイル

1. RewriteEngineを有効にする – .htacessファイルでまずこの作業を行うべきである

2. <file>のラッパータグを加える

3. ラッパー内にファイルのタイプを加える

4. キャッシングを生成し、最長時間を1週間に設定するコードを加える

5. 同じコードをその他の写真ファイルのタイプにも加える – .png & .gif

– ここでは、写真のキャッシュの時間は1週間に設定している。写真が変わる頻度、そして、ユーザーが訪問する頻度に応じて、自分のサイトに適切な時間の枠を指定する必要がある。

CSS

コードは基本的に同じだが、CSSでは異なる時間の長さを選んでいる。

するとCSSは1日でキャッシュされるようになる。繰り返すが、期間は、CSSファイルを変更する頻度、そして、ユーザーがサイトを再び訪問する頻度に左右される。

Javascript

JavaScriptのキャッシングのコードも基本は同じだが、ここでは、1ヶ月に設定する。

この期間は、サイトのJavaScriptへの依存の度合い、そして、変更される頻度に左右される。

時間の早見表

以下にそれぞれの時間の枠を秒数で計算した値を挙げていく:

  1. 5分間を秒数にすると = 300
  2. 1日を秒数にすると = 86,400
  3. 1週間を秒数にすると = 60,4800
  4. 1ヶ月間を秒数にすると = 2,629,000
  5. 6ヶ月間を秒数にすると = 15,774,000
  6. 1年間を秒数にすると = 31,536,000(無限に近い)

先程も申し上げた通り、サイトにとって妥当な時間枠をファイルのタイプで組み合わせることも、マッチさせることも出来る。自信がないなら、安全を優先させ、若干時間の枠を短くすることを薦める。


このチャプターで紹介したアドバイスに従い、伝授したテクニックを実行すれば、サイトのスピードは確実に上がるはずである。次のチャプターでは、検索の新しい & 画期的な領域を取り上げていく。競合者に遅れを取りたくないなら、これから紹介するアドバイスに従ってもらいたい。

上級者向けSEOガイドの記事一覧はこちらから


この記事は、Quick Sproutに掲載された「Chapter 2: Site Speed and Performance」を翻訳した内容です。

Pagespeedはもちろん各種ツールのマニアックな解説からして凄かったですが、Google画像検索を使った画像サイズのチェック方法のアイデアなど、筆者のニール・パテル、探究心の塊というかオタク中のオタクというか、、、正にSEOはもちろんウェブマーケを追及するために生まれてきた人間といっても過言ではないような?今後の記事も期待できそうでワクワクしてきた適度なSEOオタクの私でした。 — SEO Japan [G+]

上級者向けSEOガイド1/9 : インデクセーションとアクセシビリティの深い関係

米国のカリスマウェブマーケッター、ニール・パテルが書き下ろした上級者向けのSEOガイドを今日から一章ずつ紹介していきたいと思います。どの記事もその辺のSEO関連書籍を凌駕しかねない充実の内容ばかり。第一回目は検索エンジンにクロールされるための究極のサイト作りと手法についてページネーションから.htaccess、サイトの正しい移行方法から各種ツールの使い方まで徹底解説。 — SEO Japan

上級者向けSEOガイド チャプター 1へようこそ。このチャプターでは、インデクセーションおよびアクセシビリティを考慮してウェブサイトを評価 & 最適化する上級者向けの手法を伝授していく。

ただし、検索エンジンに対するアクセシビリティだけでなく、実際のユーザーに対するアクセシビリティにも配慮する。要するに、このチャプターには、エンジンとユーザーに対するベストプラクティスが網羅されていることになる – まるで、グーグル翻訳をインストールして、AJAXをクロール可能にするようなものだ。

このチャプターで取り上げた手法をウェブサイトに必要に応じて適用すると、並外れてクロール可能 & アクセス可能なウェブサイトに生まれ変わるだろう。

1. 検索エンジンのようにサイトを閲覧する

SEO目的でサイトを最適化する際、検索エンジンの視点に立って考えるべきではないだろうか?また、検索エンジンが見ているように、サイトを見るべきである。ご存知のように“ソース”を閲覧して、ブラウザ向けのHTMLソースを見ることが可能である。しかし、検索エンジンの視点でサイトを閲覧し、技術的なSEOの穴を見つける上で効果が高く、すぐに利用することが可能なメソッドを私は発見した。

ステップ 1: プラグインをインストールする

ここではファイヤーフォックスが便利である。以下にプラグインを挙げる:

ウェブディベロッパー - https://addons.mozilla.org/en-US/firefox/addon/web-developer/

ユーザーエージェントスウィッチャー - https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher/

ステップ 2: ファイヤーフォックスでJavaScriptを無効にする

「preferences」 & 「content」にアクセスし、「Enable JavaScript」のチェックを外す。

メニュー、リンク、そして、ドロップダウン等のアイテムをJavaScriptを使わずにグーグルボットに提供する必要があるため、この作業を実施する。JavaScriptに埋められていると、グーグルはクロールすることが出来ないのだ。

ステップ 3: ウェブディベロッパープラグインを使ってCSSを無効にする

グーグルボットがHTMLの順番でコンテンツをクロールするため、CSSを無効にする必要がある。CSSのスタイリングは、コンテンツの順序を曖昧にしてしまうことがあるためだ。

ステップ 4: ユーザーエージェントをグーグルボットに設定する

ステップ 5: ウェブサイトを立ち上げ、閲覧する

クイックスプラウトはグーグルボットの目にはどのように見えているのだろうか?

これはページの上部のみである(すべてページを掲載すると、とても長くなってしまう)。しかし、クリック可能なリンクとしてメニューが表示されており、その他のテキストやリンクはグーグルボットに全て公開されている点は伝わるはずだ。

このようにして、ウェブサイトを閲覧すると、思わぬ発見をすることがある。

チェックするべきポイントを幾つか挙げていく:

  1. メニューのリンクはすべて表示されているだろうか(ドロップダウンも)?
  2. すべてのメニューアイテムとリンクは、プレーンテキストとして表示されているだろうか?
  3. すべてのリンクはクリック可能だろうか?
  4. この手法を利用することにより、以前は隠されていたテキストが表示されるだろうか(隠されたテキストは、グーグルボットに警告を送る。悪意があって隠しているわけではなくても、グーグルボットから隠すべきではないはずだ)?
  5. サイドバーやウィジェットのコンテンツは、上部に掲載されているだろうか?忘れないでもらいたいことがある。特に重要なリンクやコンテンツは、HTMLの上部に掲載されているべきである。この点は、大規模なサイトにとっては特に重要である。

それでは、問題のあるサイトの例を以下に掲載する。

このサイトの問題点は、メニューのテキストが実際にはテキストではなく、イメージである点である。要するに、グーグルボットに与えるテキストのシグナルが存在しないのだ。被リンクに対するアンカーテキストの重要性は皆さんもご存知のはずである。内部リンクにとってもテキストは同じように重要である。上のウェブサイトでは、ホームページから注がれるリンクジュースの価値を余すところなく受けている内部のページは存在しないことになる。

検索エンジンの視点でオンサイトの調査を実施したら、次にウェブスパイダーを使ってサイトをクロールする段階に移る。


2. スクリーミングフロッグを使ってサイトをクロールする

スクリーミングフロッグとは?

スクリーミングフロッグ SEO スパイダーを利用すると、ウェブサイトをクロールし、見るだけで、サイトを今までよりも遥かに簡単に且つ素早く構築する方法に関して、重要な情報を得ることが出来るようになる。数分後には、サイトの見え方に関して新たな見解を得ているはずである。

これは実践ガイドであるため、自分のウェブスパイダーを利用するメリットの詳細を知りたいなら、次のスクリーミングフロッグの文書を参考にしてもらいたい:

http://www.screamingfrog.co.uk/seo-spider/

注記: スクリーミングフロッグは無料で1度に500ページまでクロールすることが可能である。そのため、500ページ以上持つ大きなサイトでこのツールを利用する場合、年間ライセンスを購入する必要がある。ここでとっておきの次善策を紹介しよう。サブディレクトリを入力してクロールさせることが出来る – 例えば http://www.quicksprout.com/2012/では、2012年の投稿のみを対象にしている。 複数のサブディレクトリでこの作業を実施すると、少しずつではあるが、サイト全体をクロールすることが出来る。

ステップ 1: サイトをクロールする

ステップ 2: クロールを保存する

ステップ 3: ページレベルをチェックする

ステップ 4: クロールのエラーを確認する

ステップ 5: 長いタイトルを探し、修正する

ステップ 6: 長いデスクリプションを探し、修正する

ステップ 7: インデクセーションの設定を確認する

おまけのアドバイス: 何らかのHTMLを持つ全てのページを見つける方法

ステップ 1: サイトをクロールする

スクリーミングフロッグを立ち上げ、サイトでクロールを実施する。

このタスクには、サイトの大きさに応じて、2 – 20分間を要する。

ステップ 2: クロールを保存する

ファイルフォーマット.seospiderでサイトのクロールの結果を保存するべきである。こうすることで、プログラムを閉じてしまった場合、または、後に見直したい場合でも、再びクロールを行わなくても済む。ただし、サイトに大きな変更を加えたら、再びクロールする必要がある点を忘れないでもらいたい。いずれにせよ、このデータがあれば、クロールを記録しておくことが出来る。

ステップ 3: ページレベルをチェックする

これはあくまでも上級者向けのガイドであり、SEOを確実に改善する、本当の意味での変化をウェブサイトにもたらすことを目標に掲げている。そのため、サイトに適用することが可能なスクリーミングフロッグの情報を獲得する取り組みに焦点を絞って説明させてもらう。

ウェブサイトの奥深くに埋められたページを持っているなら、ユーザーにとっても、SEOにとっても、マイナスに働いてしまう。そのため、スクリーミングフロッグを使って、簡単にこのようなページを見つけ、行動を起こすことが出来るようにリストアップする方法を紹介する。

クロールを行った後、サイトの内部で集められた全てのデータを表示するメインの「Internal」ページに移動する。

ドロップダウンメニューの下のHTMLを選択する。

右端までスクロールする。

「level」をクリックして、ページレベルごとにコンテンツをソートする。

クイックスプラウトでさえ、4-7ページの深さにある過去の投稿が幾つか存在する。

因みに、crosslinker(http://wordpress.org/extend/plugins/cross-linker/ )等のワードプレス用のプラグインの利用を検討してもらいたい。内部でリンクを張り、投稿をリンクで結ぶ上で役に立つためだ。

スクロールして左端に戻ると、新しい投稿を作成する際に、優先的にリンクを張っておきたいページのリストが完成しているはずだ。

リストをCSVフォーマットにエクスポートする:

これで、エクセルから直接、新しい投稿でリンクを張ることが可能な、優れた実用的なURLのリストを手に入れたことになる。

また、リンクを張る際は、当該のリファレンスが、関連しており、有益であり、そして、記述的なキーワードが豊富に詰まったアンカーテキストである点を確認してもらいたい。

ステップ 4: クロールのエラーを確認する

次に、上部のメニューのその他の項目を調べていく。スクリーミングフロッグには多くの掘り出し物が眠っているものの、探し出す方法を知らなければ宝の持ち腐れである – これからその方法を伝授する。

もちろん、グーグルウェブマスターツールでもクロールのエラーに関するデータを得ることが可能だが、データが不完全、または、古い可能性がある。また、この方法は、リンクを張っている全てのリンク切れを起こしている外部 リンクを見つけることも出来る。加えて、自分のツールでサイトをクロールする度に、最新の正確なリストを得られるメリットがある。

  1. 「Response Codes」をクリックする
  2. フィルタードロップダウンメニューから「Client Error 4xx」を選択する
  3. CSVでエクスポートする

こうすることで、400レベルのエラー(通常は404)を返すページのみのリストを得ることが可能になる。

ステップ 5: 長いタイトルを探し、修正する

タイトルタグとメタディスクリプションには、推奨される長さがあることは、皆さんもご存知のはずである。やはり、ウェブマスターツールからこの類のデータを手に入れることが出来る。

スクリーミングフロッグで入手可能なデータは完全であり、ソート & フィルターすることが可能である。

  1. 上部のメニューで「Page Titles」をクリックする。
  2. メニューから「Over 70 Characters」を選択する。
  3. CSVにエクスポートする。

CSVファイルを開く。

アドバイス: すぐに「名前を付けて」保存することを薦める。さもなければフォーマットにより変更を失う可能性がある。

このエクセル文書で、新しいタイトルに対して新たにカラムを作成しておこう。また、長さに対するカラムも作成するべきである。

エクセルで、新しいタイトルタグを作る度に、自動的に文字数をカウントする容易な手段が欲しいだろうか?それなら、このシンプルな数式を「new length」のカラムに加えよう。

=LEN(E3)

当然だが、新しいタイトルを入力したセルを参照する必要がある。

次に

  1. 数式のセルを選択する。
  2. 数式のセルの右下にカーソルを合わせる。
  3. カーソルが十字型に変化するまで待つ。
  4. スクエアをコラム全体に下方向にドラッグする。

これで全ての新しいタイトルタグの長さをカウントしてもらえるうようになる。

ステップ 6: 長いデスクリプションを探し、修正する

長いデスクリプションを探し、修正する作業は、一つ前の作業に似ている。

デスクリプションのメニューにアクセスする。

フィルタードロップダウンメニューから「Over 156 Characters」を選択する

CSVにエクスポートする

新しいタイトルタグと同じように、エクセスで新しいディスクリプションの作成に取り掛かることが可能だ。ここでも、新しいカラムを作り、数式 =LEN(E2) を使って、自動的に新しいデスクリプションタグの長さをカウントさせよう。

ステップ 7: インデクセーションの設定を確認する

「meta and canonical」メニューにアクセスして、インデクセーションの設定を確認する必要がある。次のようなエラーを探すべきである:

  1. カノニカルタグの欠如
  2. 誤ったカノニカルタグ(異なるページに向けられている等)
  3. インデックスされるべきなのにも関わらず、「noindex」タグがつけられているページ。
  4. インデックスされるべきではないにも関わらず、メタタグが欠けている、あるいは「index」がつけられているページ。

おまけのアドバイス: 何らかのHTMLを持つ全てのページを見つける方法

さらにテクニカルな内容に踏み込む。特定のHTMLを持つ全てのページを探し出したい状況を想像してもらいたい。例えば、クイックスプラウトで、新しいタブやウィンドウで開くリンクを持つページを全て見つける必要があると仮定する。

1: Configurationメニューから「Custom」を選択する

2: 探したいHTMLを「Filter 1」に入力する。

注記: 入力したHTMLを含まないページを探すことも可能だ。最高で5つのフィルターを入力することが出来る。

3: サイトを再びクロールする

4: メニューで「Custom」を選ぶ

5: フィルタードロップダウンメニューから「Filter One」を選択する

これで、新しいタブまたはウィンドウで開くリンクを持つページが全て判明したことになる。

このメソッドは、何も変わらないなら、既存のサイトにとって大きくプラスに働く。しかし、サイトのデザイン変更を準備している場合はどうすればいいのだろうか?それなら、デザイン変更に備えて、自己評価するべきである。


3. サイトのデザイン変更を自己評価

次にサイトのデザイン変更を行う際の評価プロセスを、手順を追って説明していく。これは、ウェブサイトを進化させる上で、そして、オンラインでのオーソリティをアピールする上で重要なステップとなる。また、このステップでも、トラフィックを取り逃さないことを心掛けてもらう。

上級者向けSEOガイドのこのセクションが対象にしているのは、新しいサイトを作りながら、次のようなベストプラクティスに従っている人達である:

  1. クロール可能なことを確かめる
  2. 新しいXMLサイトマップを投稿する
  3. 301リダイレクトを導入する

進捗状況を確認するためのスプレッドシートを作成する

以下に、新しいサイトを立ち上げる際に、このようなメトリクスを測定する方法を示すモデルのスプレッドシートを掲載する。


日付

インデックスされたページ数

キャッシュの日付

PR

DA

WMTのエラー

注記

4/1/2012

4,200

3/23/2012

6

71

525

新しいサイトを立ち上げる

4/8/2012

3,750

4/7/2012

5

67

679

新しいサイトのキャッシュが行われる

4/15/2012

4,150

4/12/2012

6

70

482

エラーの修正作業を開始

インデックスされたページ数を測定

グーグルの site: searchを利用する

キャッシュの日時を測定する

グーグルのcache:sitename.com検索をここでも利用する。

キャッシュの日時は、アルゴリズムでグーグルがサイトのどのバージョンを利用しているのかを判断する上で、最も役に立つ。

ページランクを測定する

PRはメトリクスとして重要視されているわけではないが、今でもサイトの価値の目安を得る上では有効である。

SEOquakeのツールバーは、ページランクを手っ取り早くチェックすることが可能である。次のURLからインストールしてもらいたい: http://www.seoquake.com/

SEOmozのドメインオーソリティーを測定する

このメトリクスは、SEOmozがリンクスケープのインデックスをアップデートするタイミングによって、遅延が生じることがある。それでも測定する価値はある – ツールバーは次のURLで入手することが可能だ:: http://www.seomoz.org/seo-toolbar

DAのオーソリティでは次のポイントに注目してもらいたい

「not found」エラーを測定する

ウェブマスターツールを利用し、「not found」のエラーを確認し、スタッツを入手する。

このツールおよびステップを介して、出来るだけサイトをスムーズに移行することが可能になる。  


4. 公開する前に新しいサイトをテストする

このチュートリアルでは、URLを入力すると、テストウェブサイトに向かうようにコンピュータを設定し、本当のURLを使って、サイトを公開する前にテストすることが出来る状態を作っていく。

  1. 新しいウェブサイトのIPアドレスを取得する。 
    ウェブサイトをホスティングしている場所によって、方法は大幅に変わるが、基本的に、管理者パネルのどこかに掲載されているはずである。見つけられなかったら、ホスティングサービスに電話して、尋ねよう。
  2. ホストのファイルを編集して、IPアドレスに向ける
    Macを利用しているなら:

    A. Application folder > Utilities > Terminalの順にアクセスしていく

  1. terminalアップの中で、「sudo nano /etc/hosts」と入力する。
    ユーザー名とパスワードを必要に応じて入力する。
  2. ファイルの最後に、以下の列を入力する:
    111.222.333.444 www.newdomain.com
    111.222.333.444をステップ 1で入手した実際のIPアドレスに、www.newdomain.comを新しいドメインに置き換える。
    Control-Oを押し、エンターを押す。

    E. Control-Xを押し、エディターを終了する。 

    F.

    terminalウィンドウを閉じる

    ウィンドウズのコンピュータを利用しているなら:

    A. Startをクリックし、「notepad&quot」を検索ボックスに入力し、スタートメニューでノートパッドを表示させる

    B. ノートパッドで右クリックし、「run as administrator」を左クリックする。
    許可を求められたら、「はい」を選択する

    C.

    ファイルをクリックし、開く

    D. ファイル名のボックスで、「\windows\system32\driver\etc」を入力し、Enterを押す。sp;

    E. ファイルのタイプのプルダウンを「text file」から「all files」に変更する。

    F. 「hosts」をダブルクリックする。

    G. ファイルの最後に、次の列を入力する:
    111.222.333.444 www.newdomain.com
    111.222.333.444をステップ 1で入手した実際のIPアドレスに、 www.newdomain.comを新しいドメインに置き換える。
  3. ブラウザを開いて、ウェブサイトをテストし、思い通りに表示されているかどうか確認する。新しいウェブサイトに対するURLを入力する。すると、hosts fileエディターは、テストのサイトにアクセスさせるようになる。
  4. テストを行ったら、ステップ 2で加えた変更を戻す必要がある。単純に、ファイルに戻り、加えた列を削除するだけでよい。

5. ダウンタイムなしで新しいサイトに移行する

警告: 何か誤るとサイトをダウンさせる可能性があるので、細心の注意が必要である。

新しいウェブサイトに移行する際は、以下のガイドラインに従い、ダウンタイムを出すことなく、安全な移行を心掛けてもらいたい。アップデートされたIPを世界中のサーバーが入手するには約1日を要するため、少なくとも、新しいサイトの運営を開始してから1週間は新旧のサーバーを両方とも稼働させる計画を立てておこう。

  1. 新しいドメインのTTLを5分間に設定する
    方法はホスティングサービスやドメイン登録サービスによって異なる。通常は、ドメインのコントロールパネルに設定が用意されているはずだが、見つからなかったら、ドメイン登録サービスに連絡し、サポートを要請しよう。

    GoDaddyを利用しているなら:

    A) GoDaddyのウェブサイトにログインする

    B) My Accountをクリックする。Domainsを探し、Launchをクリックする

    C) ドメインの1つをクリックする

    D) DNS Managerまで下にスクロールし、Launchをクリックする

    E) ホストの下で「@」を探し、「TTL」の下にある鉛筆のアイコンをクリックする

    F) メニューをプルダウンして、最短の時間(1/2時間)を選択する

    CNAMEがつけられた「www」を持っているなら、同じように1/2時間に変更しておくべきである。

  2. ドメインのDNSの設定を見つける
    これでサイトのテストの実施 & TTLの変更を終えたことになる。次に、ドメイン名のDNSの設定を変える作業に移る。

    まず、現在のドメイン登録サービスにアクセスし、現在のDNSの設定を探す。次に、新しいホスティングサービスにアクセスし、現在のドメイン登録サービスに入力する必要のある新しいDNSの設定をメモする。

    手続きはホスティングサービスによって、そして、ドメイン登録サービスによって異なる。

    通常は、ドメインのコントロールパネルに設定が用意されているはずだが、見つからなかったら、ドメイン登録サービスに連絡を取り、テクニカルサポートを要請しよう。

  3. 現在のドメインのDNSの設定を変更する。
    双方の登録機関の設定を新しいホスティングサービスでメモしたDNSのアドレスにしたら、どこを変えればいいのかは検討がつくはずだ。既にステップ 3で見つけている。
  4. ステップ 1で加えた列を削除して、hosts ファイルを解除する。
    元々加えた列を削除する作業以外は、基本的にステップ 1の手順に従ってもらいたい。
  5. 5分間待ってから、新しいウェブサイトにアクセスしてみよう。
    ブラウザのキャッシュとクッキーをクリアする必要があるかもしれない。新しいウェブサイトがアップしたら、これで完了。アップしなかったら、ステップ 4の作業をリバースし、古いウェブサイトに戻そう。

6. クロール可能なAJAX(JQuery GETを利用)

この例では、jQueryのpostメソッドを使って、クロール可能なAJAXを作る方法を紹介する。このチュートリアルでは、「XMLHttpRequest POST」メソッドを利用する。

このベストプラクティスに関する詳細は次のURLで確認してもらいたい:

http://googlewebmastercentral.blogspot.com/2011/11/get-post-and-safely-surfacing-more-of.html

  1. HTMLテンプレートを作成する。

  2. jQueryをサイトに加える
    この例では、列 4が加えられている。

  3. 「DIV」タグを固有のIDと共に、本文の動的なコンテンツが向かう場所に加える。
    この例では、列 8が加えられている。

  4. サイトに「DIV」タグにコンテンツを読み込むJavaScriptを追加する。
    この例では、列 10-15が加えられている。

  5. PHP スクリプトを作成する。
    例のコードは、例のブログの投稿をアウトプットする。
  6. ウェブサーバーでスクリプトを試す。
    次のようなページが表示されるはずである:

  7. ページのソースを確認する。
    このHTMLテンプレートと同じようなソースになるはずである。
  8. Inspect Elementをチェックする。
    DOMに動的なコンテンツが読み込まれているはずである。次のようなソースが表示されるはずだ:

7. クロール可能なAJAX(ハッシュなし)

このチュートリアルは、更新することなく、動的なコンテンツを読み込むものの、URLを変更するウェブサイトを対象にしている。グーグルは、HTMLのスナップショットに対するクエリの文字列内で、ルーティング「_escaped_fragment_」を推奨している。HTMLをグーグルボットに、JavaScriptをユーザーに表示するためだ。

同じ成果をもたらす方法は他にも多くある。方法はウェブサイトの設定に左右される。この例では、PHPを使って、何を表示するべきかを判断する。

次のようなURLを持っているなら: “http://www.example.com/index.php” スピードアップを図るため、コンテンツを動的に、そして、非同期的に読み込むJavaScriptでページを作るPHPが理想である。

次のようなURLを持っているなら: “http://www.example.com/index.php?_escaped_fragment_” インデックス & クロール可能な通常のHTMLのページを作るPHPが必要である。

この方法のベストプラクティスに関する詳細は次のページで確認しよう: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

  1. まず、ヘッダーに適切な「meta」タグを加えるPHPスクリプトを作成する.  
    こうすることで、クエリの文字列「_escaped_fragment_」を用いて、ページをクロールすることが可能な点を検索スパイダーに伝えられる。この例では、「head」タグ全体を生成する関数を作成した。 

    注記:  列 10に、スパイダーに「espcaped fragment」を使ってクロールするよう伝えるメタタグが記されている。
  2. 次に、ページを表示させる関数を作成する。
    この例では、「render_post」は因数「$render_snapshot」を持つ。デフォルトの状態では、このページは通常のページをユーザーに対して表示する。「render_snapshot」が正しい場合、グーグルボットに対して同じコンテンツのHTMLページを表示する。

    注記:
    このPHPの列 25は、ページがHTMLか動的かの判断を行う。
    列 26-29は、コンテンツを取得し、DIVタグ内にHTMLを返す。
    列 31-37は、jQueryを使ってコンテンツを返し、動的にHTMLをDIVタグ内に加える。


  3. 次に、「escapted fragment」のクエリの文字列を処理するコードを加えていく
    この例では、_escaped_fragment_が見つかった場合、HTMLを使って投稿を表示する。

  4. 次に、content.phpファイルを作成する。
    この例では、コードはJSONをHTMLに変換する。
  5. 最後に、ajax_crawling.jsonを作る。
    これはあくまでもデモに過ぎないが、複雑な設定のウェブサイトにもこの原則を当てはめることが出来る。通常、コンテンツはデータベースから届けられる。このデモでは、単一のファイルである。

  6. ユーザーによってレンダリングされるページをテストする:
    次のようなページが表示されるはずだ:
  7. view sourceを確認する
    コンテンツはJavaScriptを使って動的に加えられているため、表示されていないはずである。

  8. Inspect Elementsのビューを確認する。
    Inspect Elementのビューでは、JavaScriptが実行された後のHTMLに似ているため、コンテンツは表示されている。


  9. ボットのビューを「_escaped_fragment_」をURLの最後に加えてチェックする。
    ダイナミックなページと同じページが表示される:

  10. ボットのビューを確認しよう。
    JavaScriptのない通常のHTMLのようなソースが表示されるはずである。

8. クロスドメイン Rel=canonical

いつクロスドメインを利用するべきか

これは大勢の人達が混乱するポイントであり、実装する前に、このタグを利用するべきタイミングについてを説明していく。

  1. 古いサイトのコンテンツ、または、重複するコンテンツを新しいサイトにを動かす必要がある時 – そして、古いサイトがサーバーサイドのリダイレクトを提供していない時。
  2. ただし、出来るだけ古いサイトでオンサイトの重複を削減した後、利用するように心掛けてもらいたい。
  3. 代わりに301リダイレクトを実装することが可能であり、ユーザーエクスペリエンスの面で好まれるなら、301リダイレクトを利用しよう。
  4. また、ページでrel = canonicalとnoindexを併用するべきではない。このページは、リダイレクトを拾ってもらうため、インデックス可能でなければならないためだ。
  5. 両方のページでコンテンツが同じ場合、または違いが僅かな場合に利用しよう。

実装する方法

通常のcanonicalタグを実装する方法と基本的に同じである。

1. ページを準備する

2. (オリジナルの)1つ目のページでソースコードを編集可能な状態にする

3. 古いページの「head」セクションにタグを加え、新しいページに向かわせる:

        <link rel="canonical" href="http://www.example.com/example-page-name/>

「example-page-name」は新しいページのURLである。

以下のインフォグラフィックの投稿をクイックスプラウトから…

http://www.quicksprout.com/2012/06/11/5-ways-to-get-your-infographic-to-go-viral/

…KISSmetricsに移動するケースを想定する。現実的ではないかもしれないが、とりあえず、移動することにする。次のURLに移動するプロセスを説明する:

http://blog.kissmetrics.com/5-ways-to-get-your-infographic-to-go-viral

その他のアドバイス

  1. リンクをrelativeではなくabsoluteにする(http:// etcを丸ごと含む)
  2. 301と同じように、canonicalの連続を避ける
  3. これは絶対的なルールではなく、あくまでもグーグルに対するヒントであるため、グーグルのインデックスとウェブマスターツールでグーグルがこのタグに従っているかどうかを確認しておきたいところだ。

9. httpsの重複するコンテンツのエラーを修正

皆さんもご存知だとは思うが、httpsとはプロトコルであり、ページをワールドワイドウェブに安全に転送する規約である。ショッピングカート等のページ、ログインページ、そして、その他の安全なページには、httpsのアドレスを設定するべきである。しかし、この取り組みでは、URLに「s」を加えるため、コンテンツの重複を生む可能性がある。

通常は、httpsは、インデックスに含めるべきではない。基本的には公開しないページであり、検索結果に返す必要がないからだ。

クロールレポートやサイト評価で、httpsを持つURLがサイトで重複していることが明らかになったなら、この問題を解決するために以下の3つの手順を踏んでもらいたい:

1. インデックスされているページを特定する

2. インデックスされている理由を診断する

3a. 存在するべきではなページを301リダイレクトする

3b. 存在するべきではないなら、インデックスから削除する

ステップ 1 – インデックスされているhttpsのページを探す

httpsを持つ、インデックスされているページを探し出す次のグーグル検索を実施する

  1. site:yourdomain.com inurl:https

crazyeggのウェブサイトは何の問題もないように思える。flash loaderを除けば、htttpsのページはインデックされていない。

KissMetricsはインデックスにhttpsが存在するサイトの典型的な例である。

この2つ目のページは通常のブログの投稿であり、インデックスされるべきではない(このページで3つ目)。

また次のページは、httpsを利用するべきではあるものの、インデックスに含まれるべきではないページである

それでは、インデックスされるべきではないページを発見したら、どのように対処すればいいのだろうか?インデックスから削除したい、不要な古いページと同じように、そもそもなぜインデックスに含まれたのかを解明する必要がある。

ステップ 2 – インデックスに含まれた理由を診断する

例として上のブログの投稿を利用する。それでは、ページを詳しく見ていこう。

グーグルクロームは、URLにhttpsが存在するものの、このページが安全が保証されていないことを指摘している。これは、当該のページが、このこのような方法でインデックスに含まれるべきではない点を裏付けている。

内部または外部からリンクが張られたことが原因でインデックスに含まれた可能性が高い。そこで、複数のツールを使って、リンクのソースを発見する試みを行う。

まずは、スクリーミングフロッグを利用する。サイトを完全にクロールする必要があるためだ。

スクリーミングフロッグで、ウェブサイトのルートドメインを入力する(なぜなら、KissMetricsのように、中にはwww/blog等異なるサブドメインで運営しているサイトもあるからだ – ウェブサイト全体が完全にクロールされている点を確かめる必要がある)。

サイトをクロールする際は、当該のページのURLを検索し、表示されるまで待つ。

その後、クロールが完了するまで待ち、「In Links」を精査する。

「to」カラムをチェックし、「https://」を利用しているリンクがあるかどうか確認する

この例では、ページのhttps://版に向けられる内部リンクは見つからなかった。

内部リンクが見つかったら、内部リンクを変更し、httpsバージョンをhttpバージョンに301リダイレクトする必要がある。

内部リンクが見つからなくても、外部リンクが見つかる可能性がある。この場合、必ずしも設定を変える権限を持っているとは限らない。そのため、httpバージョンに301リダイレクトする。すると、ユーザーをhttpバージョンにリダイレクトし、最終的に、httpsバージョンをインデックスから削除/置き換えることが出来る。

ステップ 3a – 内部リンクを修正する

ベストプラクティスとして、常にサイトで「absolute」の内部リンクを利用してもらいたい。

例えば、次のURLにリンクを張る代わりに: /2012/04/30/6-ways-to-generate-more-traffic-out-of-your-images/

私なら次のURLにリンクを張る: http://www.quicksprout.com/2012/04/30/6-ways-to-generate-more-traffic-out-of-your-images/

http://を含むURLのパス全体が含まれている点に注意してもらいたい。

ワードプレスを利用しているなら、自動的にこの作業は行われるはずである。しかし、一部のカスタムサイトまたは他のCMSのサイトでは、自動的に修正してもらえない可能性があるので、自分で修正しなければならない。

エラーを修正する

httpsのリダイレクトに関する指南については、「htaccess hacks」のセクションを参照にしてもらいたい。


10. Rel=nextを用いるページネーション

ページネーションは、オンページのSEOおよびアーキテクチャにおいて、処理が最も難しい取り組みの一つに数えられる。しかし、現在、グーグルは、「next」および「prev」の利用を認めており、一連のページを持っていることを伝えやすくなっている。

ワードプレスのようなCMSを利用している場合、Yoast SEO等、様々なプラグインが提供されている。しかし、自分でサイトを作った人のために、あるいは、ピュア HTMLで自力でコーディングしたサイトを運営している人のために、上述した新しいタグを使って、ページネーションを是正する方法を紹介する。実は割と簡単である。インターネットでは最高のリソースを見つけるのは難しいが、ここでは万全の対策を伝授する。

ステップ 1 – 一連のページを特定する

Zapposを例に説明していく。以下に男性用のスニーカーのページ 1を掲載する。

メニューでページ 2、3等が確認できるため、一連のページ数が振られたページの中で、このページが1ページ目であることを特定した。

以下にページ 1のURLを記載する

http://www.zappos.com/mens-sneakers-athletic-shoes~dA

続いてページ2、ページ3のURLを記載する

http://www.zappos.com/mens-sneakers-athletic-shoes~dB

http://www.zappos.com/mens-sneakers-athletic-shoes~dC

注記: ページを変更するため、Zapposは文字(a、b、c)を利用している。

ステップ 2 – rel=”next”を1ページ目に加える

このように、一連のページを特定すると、ページ 1のみに「next」タグがつけられているはずである。なぜなら、一連のページの最初のページだからだ。そのため、ページ 1に対して、「head」セクションで次のコードを加える:

<link rel="next" href="http://www.zappos.com/mens-sneakers-athletic-shoes~dB”>

ステップ 3 – 中間のページにrel=”next” とrel=”prev”を加える

1ページ目と最後のページを除く全てのページに「next」と「prev」タグが必要である。前後のページが存在するためだ。ページ 2(mens-sneakers-athletic-shoes~dB)に次のタグを加えることが出来る。

<link rel="prev" href="http://www.zappos.com/mens-sneakers-athletic-shoes~dA”>

<link rel="next" href="http://www.zappos.com/mens-sneakers-athletic-shoes~dC”>

ステップ 4 – rel=”prev”を最後のページに加える

一連のページの最後のページには、そのページの一つ前のページのみを参照すればよいため、次のタグを加える:

<link rel="next" href="http://www.zappos.com/mens-sneakers-athletic-shoes~dY”>

Zが最後のページであると仮定している。

注記

cannonicalタグをnext/prevと関連させて含めることが出来る。

absoluteまたはrelativeのURLを利用することも可能だが、個人的には出来る限りabsoluteの利用を薦める。


11. .htaccessを使ってエラーページをリダイレクトする

以下のプロセスに従う必要がある:

1. エラーページを作成する – このページには特別なスクリプトを与える。

2. .htaccessファイルを設定し、エラーページへリダイレクトする。

ステップ 1 – エラーページを作成する

エラーが返されるページを作成する – 名称は何でも構わない – error.phpを薦める。

このページで、上部に次のコードを加える:

<?php
switch($_SERVER["REDIRECT_STATUS"]){
        case 400:
                $title = "400 Bad Request";
                $description = "The request can not be processed due to bad syntax";
        break;
        case 401:
                $title = "401 Unauthorized";
                $description = "The request has failed authentication";
        break;
        case 403:
                $title = "403 Forbidden";
                $description = "The server refuses to response to the request";
        break;
        case 404:
                $title = "404 Not Found";
                $description = "The resource requested can not be found.";
        break;
        case 500:
                $title = "500 Internal Server Error";
                $description = "There was an error which doesn't fit any other error message";
        break;
        case 502:
                $title = "502 Bad Gateway";
                $description = "The server was acting as a proxy and received a bad request.";
        break;
        case 504:
                $title = "504 Gateway Timeout";
                $description = "The server was acting as a proxy and the request timed out.";
        break;
}
?>

このPHPコードは、それぞれのタイプ別に異なるタイトルを作成する。こうすることで、異なるファイルを大量に作らなくても済む。すべて一つのファイルで実施することが出来る。

この例では、それぞれのエラーページに対して、固有のタイトルとディスクリプションを一つだけ作成している。しかし、変数を加えて、好きな固有のコンテンツを作成することが出来る。

ステップ 2 – .htaccessを設定する

多くのエラーコードをエラーページにリダイレクトしなければならない。以下の列を.htaccessに加えてもらいたい。

ErrorDocument 400 /error.php
ErrorDocument 401 /error.php
ErrorDocument 403 /error.php
ErrorDocument 404 /error.php
ErrorDocument 500 /error.php
ErrorDocument 502 /error.php
ErrorDocument 504 /error.php


12. RSS フィードを最適化する

RSS フィードはブログで大きな役割を担っている。しかし、このフィードを最適化することで得られるメリットの大きさを見過ごしてしまうことがたまにある。以下の実践的なアドバイスに従ってもらえば、RSS フィードを最大限まで活用することが出来るようになるだろう。

ここではフィードバーナーを利用していると仮定する。

ヘッダーでデフォルトのRSS フィードを置き変える

フィードバーナーを利用していると仮定した場合、ウェブサイト上の全てのリンクは適切なフィードに向けられているだろうか?クイックスプラウトのヘッダーセクションは、フィードバーナーのフィードに向けられている。

この作業を実施していないなら、header.phpファイル(ワードプレスの場合)、または、利用しているCMSが認める場所で、フィードのURLを変更する必要がある。

header.phpファイルでRSSのリンクを見つける

フィードバーナーのフィードのURLに置き換える

フィードバーナーでは早さが命

フィードバーナーには簡単に有効にすることが出来る機能が幾つか存在する。全て利用していることを確認してもらいたい。

Activate SmartFeed

SmartFeedは、あらゆるリーダーとの互換性を確立させる上で便利である。

Optimize->Smartfeedの順にクリックする

Activateをクリックする

FeedFlareを有効にする

Feedflareはリンクをフィードの下に掲載し、フェイスブックでの共有、eメール、deliciousでのブックマーク等の行動をユーザーに要請する手段である。

これは、あらゆるRSSフィードにとって絶対に欠かせないアイテムである。

Optimizeタブで、FeedFlareをクリックする。

表示したいリンクを選択する。 フィードは、フィードをウェブサイトに送信した際に、RSS フィードに表示されるアイテムを意味する。サイトは、ウェブサイトに表示されるアイテムを意味する。

Activateボタンは見にくい位置に掲載されているので注意してもらいたい。一番下に用意されている。

次に、「パーソナル」なフレアを幾つか加えていく。これは、ユーザーが作成したクエリであり、一連のデフォルトのフレアのセットには存在しない。

「Browse the Catalog」をクリックする。

利用可能なフレアを閲覧する。好きなフレアを見つけ、「Link」をクリックする。

するとこのフレアのタブが開く。URLをコピーする。

最初のスクリーンに戻る。フレアのURLを貼り付ける。次に「Add New Flare」をクリックする。

フレアが上に表示される。表示する場所を選ぶ(フィード、サイト、または、その双方)。

下でフレアのプレビューを見ることが出来る。アイテムをドラッグ & ドロップして順番を整えることが出来る。

忘れずに「Save」をクリックすること。 見過ごしやすいので注意してもらいたい。

PingShotを有効にする

PingShotは、アップデートが発生するとフィードバーナーに通知する機能である。PingShotにはフィードの提供をスピードアップする効果が見込める。

Publicize->PingShotの順にアクセスし、「Activate」をクリックする。

フィードのオリジナルのソースにリンクを張る

RSSフィードが許可なく利用され、別のサイトで重複する事態に直面したことはあるだろうか?(このガイドの恩恵を受け)人気の高いサイトを運営しているなら、常にこの問題を抱えているはずだ。グーグルボット、またはユーザーは、どちらがオリジナルのソースなのか分からず混乱している可能性がある。

そのため、これからRSSフィードの下に「自分」こそがコンテンツのオリジナルのソースである点を伝えるリンクを加える方法を伝授する。この手法を実行すると、検索エンジンとユーザーにとって格好の判断材料になるだけでなく、被リンクを得られる可能性がある。

1. RSS ソースリンクをブロガー(ブログスポット)に追加する

Settings -> Site Feedの順にアクセスする

以下のコードを加える:

<hr />
<a href="http://www.myblog.com">My Blog Name</a>

2. RSS ソースリンクをワードプレスに追加する

Appearance -> Editor -> functions.phpの順にアクセスする

次のコードを加える:

function embed_rss($content) {
 if(is_feed())
    $content .= "<p><a href='". get_permalink() ."'>'";
    $content .= get_the_title() ."</a></p>";
 return $content;
 }
add_filter('the_content', 'embed_rss');

これでコンテンツのオリジナルのソースに対するリファレンスをRSSフィードに用意することが出来る。それでは、いつものように正しく表示されているかテストしよう。

Thank Youを作成する

パーソナライゼーション、そして、読者への感謝のメッセージは大いに効果がある。以下にシンプルなメッセージをフィードに設定する方法を紹介していく。

Optimize->BrowserFriendly->Content Optionsの順にアクセスする

‘enable’をクリックして、個人的なメッセージを入力する。

RSSのeメールを送るタイミングを決める

送信する時間を管理して、より多くのRSSのeメールを開けてもらう。

Publicize->Email Subscriptions->Delivery Optionsにアクセスする

時間帯、オーディエンスにとって最善の時間を選択する。午前9-11時を薦める。

ワードプレスのRSSをフィードバーナーにリダイレクトする

ワードプレスに内蔵されている標準のRSSフィードを利用している人がいてもおかしくはない。そのRSSフィードを購読している人がいる可能性もある。「フィードバーナーリダイレクト」と言うプラグインを利用すると、すべてのフィードがフィードバナーを経由するように設定することが出来る。

プラグインは次のURLで手に入れることが可能だ - http://wordpress.org/extend/plugins/tentbloggers-feedburner-rss-redirect-plugin/

1. ワードプレスのセットアップでインストールする。

2. 有効にする。

双方のフィールドにフィードバーナーのURLを入力する。これで完了。


13. 動画のサイトマップ

動画をサイトまたはブログに投稿しているなら、とりわけ、メタデータでマークアップしているなら、動画のサイトマップを用意するべきである。こうすることで、グーグルやビングが動画のコンテンツに気づき、処理し、インデックスするプロセスが大幅にスピードアップする。

オプション A – 自力で作成する

サイトの規模が小さく、投稿する動画が2、3本しか存在せず、また、たまに投稿する程度なら、自分で動画のXMLサイトマップを容易に作成することが可能である。/span>

まず、XML構造のスケルトンのテンプレートを提供する。後はデータを加えていけばよい。

これは必要なフィールドを持つだけの最もベーシックなテンプレートである。

ステップ 1: 空のXMLファイルを作成する

  1. ファイルを作成する。名前は何でも構わないが、個人的に好きなファイル名を挙げておく: sitemap_video.xml
  2. 次に以下のようにルートディレクトリに保存する: http://www.quicksprout.com/sitemap_video.xml

先程も申し上げた通り、ファイル名、そして、保存場所は何でも構わないが、サイトマップをウェブマスターツールに投稿する際にこの情報が必要なので忘れないように気をつけてもらいたい。

ステップ 2: 次のコードをXMLファイルに貼り付ける

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"

       xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">

 

  <url>

    <loc></loc>

    <video:video>

      <video:thumbnail_loc></video:thumbnail_loc>

      <video:title></video:title>

      <video:description></video:description>

      <video:content_loc></video:content_loc>

      <video:player_loc allow_embed="yes" autoplay="ap=1"></video:player_loc>

    </video:video>

  </url>

</urlset>

上のコードを説明しておく:

テンプレート内のプロパティの大半は任意だが、とりあえず全てを紹介したかったので掲載しておいた :-)

必要なフィールド

  1. ページのURL
  2. 動画ファイルのURLまたはプレイヤーのURL
  1. タイトル
  2. ディスクリプション
  3. サムネイル

それでは、例のテンプレートに情報を記入していく。このテンプレートでは、その他のプロパティは省略し、必要な要素に絞る:

動画1本に対するXML動画サイトマップの基本的なコード

<url>

<loc>http://www.quicksprout.com/videos/neil-patel-video-1.html</loc>

<video:video>         <video:thumbnail_loc>http://www.quicksprout.com/thumbs/thumbnail.jpg</video:thumbnail_loc>

<video:title>Advanced SEO for Bloggers</video:title>

<video:description>An exclusive video with SEO expert Neil Patel. Drive ridiculous amounts of leads to your blog and learn the 7 secrets of conversion rate optimization.</video:description>

<video:content_loc>http://www.quicksprout.com/video.flv</video:content_loc>

</video:video>

</url>

その他のプロパティを追加する

次のように、動画のサイトマップに追加することが可能なプロパティが数多く存在する:

<video:duration>

<video:expiration_date>

<video:rating>

<video:view_count>

<video:publication_date>

<video:tag>

<video:tag>

<video:category>

<video:restriction>

<video:restriction>

<video:restriction>

<video:gallery_loc>

<video:gallery_loc>

<video:price>

<video:requires_subscription>

<video:uploader>

<video:uploader>

<video:platform>

<video:platform>

<video:platform>

<video:live>

例のテンプレートに上のプロパティを幾つか加え、動作を確認しよう。

 <url>

    <loc>http://www.quicksprout.com/videos/neil-patel-video-1.html</loc>

    <video:video>

      <video:thumbnail_loc>http://www.quicksprout.com/thumbs/thumbnail.jpg</video:thumbnail_loc>

      <video:title>Advanced SEO for Bloggers</video:title>

      <video:description>An exclusive video with SEO expert Neil Patel. Drive ridiculous

                      amounts of leads to your blog and learn the 7 secrets of

                      conversion rate optimization.</video:description>

      <video:content_loc>http://www.quicksprout.com/video.flv</video:content_loc>

      <!–optional properties–>

      <video:duration>750</video:duration>

      <video:rating>4.1</video:rating>

      <video:view_count>54321</video:view_count>    

      <video:publication_date>2012-04-01T19:20:30+08:00</video:publication_date>

      <video:family_friendly>yes</video:family_friendly>  

      <video:restriction relationship="allow">IE GB US CA</video:restriction>

      <video:requires_subscription>no</video:requires_subscription>

      <video:live>no</video:live>

    </video:video>

  </url>

これは一目見れば分かる類のプロセスである。認められている個別のフィールドの詳細は、グーグルの文書で確認してもらいたい。

ステップ 3: グーグルウェブマスターツールにサイトマップを投稿する

オプション A – ウェブマスターツールに直接投稿する

グーグルにXMLサイトマップを投稿する手法としては、この手法を薦める。

- ウェブマスターツールにサインインする

- ウェブサイトのプロフィールを見る

- Site Configuration->Sitemapsにアクセスする

- 右隅の“Add/Test a Sitemap”をクリックする

- サイトマップの名前を入力し、投稿する。

オプション B – robots.txtファイルに以下の列を加える -

サイトマップ: http://www.example.com/sitemap_video.xml

あらゆるXMLのサイトマップに共通することだが、robots.txtファイルが適切に設定されていると、グーグルはrobot.txtの情報を基に動画を発見し、処理していく。


14. .htaccessのテクニック

これから紹介するアドバイスは、クライアントがApacheを利用している場合のみ有効である。ウィンドウズ IISを利用しているなら、IISのテクニックを参照すること。

  1. サーバーで.htaccessファイルを探し出す。
    (“サーバーで.htaccessを探す方法”を参照)
  2. .htaccessを見つけたら、テキストエディタを使ってファイルを編集する。
    ウィンドウズを利用しているなら、 Notepadを薦める。Macを利用しているなら、  TextWrangler等の無料のテキストエディタをダウンロードしよう。
  3. .htaccessファイルで何をしたいのかを決め、コードの列を加える:

自分で404ページを作るには

“ErrorDocument”を利用し、最後にオリジナルの404ページへのURLを加える。例:

ErrorDocument 404 http://www.example.com/my-custom-404-page.html

フォルダーをパスワードで保護するには

A. まず、htpasswdファイルを作成する。オンラインツールを利用すると簡単に作成することが出来る: http://www.tools.dynamicdrive.com/password/

B. 左側に希望するユーザー名を、そして、当該の人物に与えたいパスワードを右側に入力する。

C. “path to .htpasswd”ボックスで、公開しないフォルダーを記入する。通常は、次のように、ホームのディレクトリを入力すると安全である:“/home/myusername”

D. submitをクリクし、ダウンロードした.htpasswdファイルを“/home/myusername”に置く。

E. 次にこの情報を.htaccessファイルに入力する。

AuthUserFile /home/myusername/.htpasswd

AuthName EnterPassword

AuthType Basic

require user some_users_name

some_users_name”をこのフォルダで許可されるユーザーネームと置き換える。

IPアドレスでユーザーをブロックするには

次の4つの列を.htaccessファイルに入力する:

Order allow, deny

Deny from 111.222.333.444

Deny from 555.666.777.888

Allow from all

“deny from,”の列で、例のIPアドレス“111.222.333.444”をブロックしたいIPアドレスに置き換える。

リファラーでユーザーをブロックしたいなら

以下の3つの列を.htaccessファイルに加える:

RewriteEngine On

RewriteCond %{HTTP_REFERER} somedomain\.com [NC]

RewriteRule .* – [F]

複数のリファラーをブロックしたいなら、次のようにRewriteCondの列を増やす必要がある:

RewriteEngine On

RewriteCond %{HTTP_REFERER} somedomain\.com [NC,OR]

RewriteCond %{HTTP_REFERER} anotherdomain\.com [NC,OR]

RewriteCond %{HTTP_REFERER} 3rdDomain\.com [NC]

RewriteRule .* – [F]

最後の列を除く全ての列が“[NC,OR]”で終わっている点に注目しよう。

index.html以外をデフォルトのページに指定するには

“home.html”をデフォルトのページに指定したいと仮定する。その場合、次の列を.htaccessファイルに利用してもらいたい:

DirectoryIndex. home.html

古いドメインを新しいドメインに301リダイレクトするには

以下の列をhtaccessファイルに加える。

RewriteEngine on

RewriteCond %{HTTP_HOST} ^olddomain.com [NC,OR]

RewriteCond %{HTTP_HOST} ^www.olddomain.com [NC]

RewriteRule ^(.*)$ http://www.newdomain.com/$1 [R=301,NC]

"olddomain.com"を古いドメイン名に置き換える。すると、古いドメインからWWWで始まる新しいドメインにリンクを301リダイレクトするようになる。

ウェブサイト上のリソースへの直リンクを防ぐには

次の列を.htaccessファイルに加える:

RewriteEngine on

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC]

RewriteRule \.(gif|jpg|js|css)$ – [F]

mydomain.comをドメイン名に置き換える。この列によって、GIF、JPG、JS、そして、CSSファイルへの直リンクを阻止することが可能になる。

HTTPS://からHTTP://へ全てのページをリダイレクトするには

次の列を.htaccessファイルに加える:

RewriteEngine on

RewriteCond %{SERVER_PORT} !^80$

RewriteRule ^(.*)$ https://www.domain.com/$1 [NC,R=301,L]

domain.comを実際のドメインに置き換える。

HTTP://からHTTPS://へ全てのページをリダイレクトするには

.htaccessファイルに次の列を加える:

RewriteEngine on

RewriteCond %{SERVER_PORT} !^443$

RewriteRule ^(.*)$ http://www.domain.com/$1 [NC,R=301,L]

domain.comを実際のドメインに置き換える。

1つのURLをHTTPS://からHTTP://にリダイレクトするには

URLがhttp://www.domain.com/mypage.htmlだと仮定する

RewriteEngine on

RewriteCond %{HTTP_HOST} !^80$

RewriteCond %{HTTP_HOST} ^www.domain.com/mypage.html [NC]

RewriteRule ^(.*)$ http://www.domain.com/mypage.html [NC,R=301,L]


15. グーグルボットを検知する

ユーザーエージェントとしてグーグルボットを検知しておくべきである。その理由は数多くあるが、皆さんの想像に任せておく。 :)

1.  次のコードを文書の「body」のどこかに切り取り & 貼り付けする

if(strstr(strtolower($_SERVER['HTTP_USER_AGENT']), "googlebot"))

{

   // what to do

}

2. Replace with your content

“// what to do”を好きな指示に置き換える。

アドバイス: To make it HTML

次のコードを加える:

if(strstr(strtolower($_SERVER['HTTP_USER_AGENT']), "googlebot"))

{?>

          <h1>Put your HTML here</h1>

<p>anything you’d normally do</p>

<?php

}

PHPの各パーツを分ける。

if(condition){} - this is just a simple function that says “if x is true, do y”.

次にネスト化したステートメントの内側から作業する。

‘HTTP_USER_AGENT’ - これはブラウザ特有のIDの文字列を引き出す

$_SERVER – これはヘッダー、パス、スクリプトのロケーション等、ウェブサーバーによって生成される情報を持つ配列である

strtolower – 全てのアルファベットを小文字に変えた状態で文字列を返す

strstr – 最初のneedleの発生からhaystackの最後までを含むhaystackの文字列の一部を返す

{

        // what to do

}

フォワードスラッシュ // はコメントを残すためだけに用いられる。つまり、波括弧の間に望む動作を挟めばよい。

ビジュアルを好むなら – このコードは分かりやすい:


16. サイトにカスタム検索エンジンを加える

グーグルのカスタム検索エンジンは強力なツールになり得るものの、このツールを利用していないサイトは意外と多い。それでは、サイトにカスタム検索エンジンをインストールする手順を説明していく。

- http://www.google.com/cseにアクセスする

ステップ 1: タイトルとディスクリプションを作成する

ステップ 2: 検索に含めるサイトを加える

ここでちょっとしたテクニカルなノウハウが役に立つ。

サイトのURLをただ単に加えるのではなく – アスタリスク (*) をURLの後ろに加えて(例

http://www.quicksprout.com/*)サイト全体を検索することが出来るようにしなければならない。

ステップ 3: Editionを選択して、確認する

この作業を完了すると、カスタム検索エンジンをサイトに実際にインストールする前に試す機会が得られる。

Let’s check it out!

カスタム検索エンジンで[twitter tips]を検索すると、良質な検索結果が表示された。また、エンジン内のサイトのバラエティも申し分ない(プレミアム版を購入しない限り、広告が表示される点に注意)。

それでは、これからサイトにインストールするプロセスを説明する。

カスタム検索エンジンをサイトにインストールする

このタイプのインストールは、新しいページか新しい投稿のいずれかに行うことになる。例では新しいページを利用するが、新しい投稿にも同じ方法を用いることが可能である。

ステップ 1: “new page”にアクセスする

ステップ 2: HTMLモードで編集する

JavaScriptのコードをページに貼り付けるため、HTMLモードで編集を行う。

ステップ 3: コードを貼り付ける

プレビューを見る


17. 複数の言語のマークアップとグーグル翻訳

グーグル翻訳をインストールして、別の言語を話すビジターにもサイトを楽しんでもらう方法をこれから伝授する。これは割と新しいテクニックであり、利用している人はまだ少ない。そのため、早い段階で導入しておくことを薦める。

 http://translate.google.com/translate_toolsにアクセスする

段階 I – コードを取得する

翻訳をサイトに実装するため、まずはオプションを選択し、コードのスニペットを生成する。

ステップ 1: ページ全体またはページの一部を翻訳するかを決める

大抵、ページ全体を翻訳したいのではないだろうか。しかし、一部のテキストを異なる言語に翻訳したい場合でも、ページの一部のみを翻訳する選択肢があるので心配しないでもらいたい。

ステップ 2: ウェブページの言語を選択する

大抵の場合、英語を選択することになる。

ステップ 3: Optional Settingsを表示させる

十字マークをクリックして、optional settingsを開く。

optional settingsを使って、サイトの翻訳を完全にカスタマイズすることを私は薦める。

翻訳される言語を選択することが出来る。

翻訳ボックスの表示方法を選択することが出来る。個人的には、「inline」と「dropdown only」が良いと思う。

さらに上級者向けの設定も用意されている。ここでは、ページを翻訳する必要がある読者に自動的にバナーを表示する。また、グーグルアナリティクスで利用を追跡する。

アドバイス: グーグルアナリティクスのIDを早く見つける方法

1. 自分のウェブページにアクセスする

2. ソースを見る

3. Control F(クロームの場合)を押して、テキストを探す

4. “ua-”(ダッシュ付き)を検索する

選択を終えたら、完成したスニペットのコードが表示されるはずだ。

ページのプレビューを見る

コードをコピーして、サイトに加える前に、翻訳ボタンのプレビューを見ることが出来る。

段階 II – コードをサイトにインストールする

これでコードの準備が整ったので、これからサイトに実際にインストールしていく。ワードプレスのようなコンテンツ管理システムを利用しているなら、割と簡単にインストールすることが可能だ。ここでは、コードを挿入するスポットを探す作業のみ説明する。

ステップ 1: 翻訳ボックスを表示する場所を決める

翻訳ボックスをインストールする基本的な場所は次の2つである。

オプション A – クイックスプラウトのように、ヘッダーのどこかに表示する:

オプション B – クックスプラウトのこのページのようにサイドバーのどかに表示する:

ステップ 2(オプション A): コードをヘッダーにインストールする

再びソースコードを確認すると、コードを挿入する必要のある場所が見えてくる:

検索ボックスとロゴの間に挿入する必要がある。

1. ワードプレスにログインする

2. 「editor」にアクセスする

3. 「Header」を選択する

4. header.phpファイルの翻訳コードを貼り付ける

翻訳ボックスを表示させる場所をコードで探し出し、header.phpファイル内でスニペットを貼り付け、保存する。

ステップ 2(オプション B): サイドバーにコードをインストールする

新しいテキストのウィジェットを作成することが出来るため、このオプションの方が少し難易度は低い。

1. ウィジェットにアクセスする

2. サイドバーに新しい「Text Widget」を加える

3. 翻訳コードをウィジェットに貼り付ける

これで完了。今後は異なる言語のユーザーにもサイトを楽しんでもらえる。


18. 悪意のある、または害をもたらす可能性のあるリンクをブロックする

時折、ハッカー、または、悪意のない経験の浅い人達が、クエリパラメータを最後に加えたリンクを送ってくることがある。例を以下に挙げる:

http://www.quicksprout.com/?neilpatelscam

(このような方法でリンクを張ってもらいたくない)

また、悪意のあるクエリの文字列が異なるページに向かわせてしまうこともある:

http://www.quicksprout.com/page/2/?neilpatelscam

http://www.quicksprout.com/page/3/?neilpatelscam

このページはそのままインデックスされ、本物のページをインデックスで置き換えてしまう可能性がある。可能性こそ低いものの、万が一の時は、修正する必要がある。以下に、そのための.htaccessのコードを掲載する:

# FIX BAD LINKS
<ifModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} querystring [NC]
RewriteRule .* http://example.com/$1? [R=301,L]
</ifModule>

単純に次の手順に従ってもらいたい:

1. .htaccessがルートディレクトリに存在することを確認する。

2. このコードを.htaccessファイルの一番下に掲載する。

3. “querystring” を利用されている悪意のあるクエリ文字列と置き換える。

4. example.comをサイトのURLと置き換える。

5. 複数のクエリ文字列を加えるには、“pipes” ( | )を“or”を表現するために用いる:    

           例えば、neilpatelscam|quicksproutripoff|badblogger

6. 最後に1週間後または2週間後にグーグルで、次のようなsite: queryを実行して、インデックスから削除されている点を確認する:

        site:quicksprout.com/?neilpatelscam


19. オンサイト分析向けのブラウザプラグイン

ブラウザプラグインは、ワークフローと効率を大幅に改善するポテンシャルを秘めている。そこで、グーグルクロームのプラグインを幾つか紹介し、高度な使い方も幾つか伝授していく。

このセクションでは、サイトのアクセシビリティおよびインデクセーションを最適する上で役に立つプラグインを取り上げる。

以下にリストを掲載する。

  1. Broken Link Checker - https://chrome.google.com/webstore/detail/ojkcdipcgfaekbeaelaapakgnjflfglf
  2. Web Developer - http://chrispederick.com/work/web-developer/
  3. Redirect Path Checker - https://chrome.google.com/webstore/detail/aomidfkchockcldhbkggjokdkkebmdll
  4. SEOmoz Toolbar - https://chrome.google.com/webstore/detail/eakacpaijcpapndcfffdgphdiccmpknp
  5. Chrome Sniffer - https://chrome.google.com/webstore/detail/homgcnaoacgigpkkljjjekpignblkeae
  6. Google Analytics Debugger - https://chrome.google.com/webstore/detail/jnkmfdileelhofjcijamephohjechhna
  7. Microformats for Chrome - https://chrome.google.com/webstore/detail/oalbifknmclbnmjlljdemhjjlkmppjjl
  8. Rulers Guides and Eyedropper Color Picker - https://chrome.google.com/webstore/detail/bjpngjgkahhflejneemihpbnfdoafoeh
  9. Word Count - https://chrome.google.com/webstore/detail/kmndjoipobjfjbhocpoeejjimchnbjje
  10. Source Kit - https://chrome.google.com/webstore/detail/iieeldjdihkpoapgipfkeoddjckopgjg?hl=en-US

次に、高度な利用方法を紹介する。

Broken Links Checker

このプラグインは、リンク切れを手っ取り早く確認することが出来るだけでなく、リンクの構築および獲得に関するアイデアを得るため、他のサイトに利用する手もある。

例えば、競合者のウェブサイトのサイトマップでこのプラグインを実行してみよう。手順は以下の通りだ:

1. 競合者のHTML sitemapを探す。例えば、ランダムに www.bizchair.comを取り上げ、サイトマップを探し出してみる: http://www.bizchair.com/site-map.html

2. Link Checkerを実行する

エクステンションのアイコンをクリックする

リンク切れが見つかるまで待つ – この例では、多くのリンク切れが見つかった。

特に目立つのは、“resources” ページである。リソースのコンテンツを再現する、または、リンクを得るために利用することが出来る。

Chrome Sniffer

このプラグインは、ウェブサイトが利用しているCMS、または、スクリプトのライブラリを自動的に表示する。例えば、ワードプレスのサイトのオーナーのみに接触したい際に、とても便利である。

ウェブを閲覧している際に、利用されているCMSやライブラリに合わせて、URLの右端のアイコンが変化する。

例えば、私のサイトはワードプレスで構築されていることが分かる

そして、ドルーパルで構築されているサイトの場合このように変化する

Redirect Path Checker

このプラグインは、リダイレクトでページに移動される際に自動的に警告を発する。ウェブを閲覧している際に、内部(または外部)で期限切れのURLにリンクを張っている場合、非常に役に立つ。

例えば、私は、たった今、Gizmodo 302リダイレクトにリンクを張っていることに気づいた:

このプラグインが302を通知してくれたため、リダイレクトに気づいたのだ。

アイコンをクリックすると、ブラウザがページに向かう上で経由したリダイレクト(または一連のリダイレクト)を表示する。

SEOmoz Toolbar & Plugin

Mozのプラグインは、様々な用途で利用することが可能である。より高度な方法を幾つか紹介する:

followedとnofollowedのリンクを早く発見する

ウェブサイトの国またはIPアドレスを発見する

上級者向けSEOガイドの記事一覧はこちらから


この記事は、Quick Sproutに掲載された「Chapter 1: Indexation and Accessibility」を翻訳した内容です。

圧巻の質と量を誇る記事でした。英語圏のツールを中心に紹介されていましたが、大半が日本語でも問題なく使えるものばかりですし(というか、日本で使える同種のツールは余りないですし)、日本のウェブマスターにも十分に役立つ内容だったと思います。ここまで徹底してSEOに取り組んでいるサイトも余り無いと思いますし、全てを行う必要があるわけでもないとは思いますが、ここという時に参考になる情報が満載でした。 — SEO Japan [G+]

GoogleのCloud Storage, これからは全データを自動的に暗号化

今日を皮切りに、GoogleのCloud Platform上のユーザデータはすべて自動的に暗号化される。同社のCompute EnginePersistent DisksScratch Disksはすでにデータがすべて暗号化されていたが、同社の今日の発表ではGoogle Cloud Storageのデータもすべて、128ビットのAdvanced Encryption Standardで暗号化される。

今日の発表でGoogleは、次のように説明している: “各オブジェクトのキーも、そのオブジェクトのオーナーに結びつくユニークなキーで暗号化される。さらにこれらのキーは、定期的にローテーションされるマスターキーの集合のどれかを使ってさらに暗号化される”。デフォルトでは、データのキーをGoogleがユーザに代わって管理するが、ユーザはデータをCloud Storageに書き出す前に独自に暗号化してもよい。暗号のセキュリティについて神経質な人は、Googleにキーの保存と管理を任せるのは不安だろう。しかしGoogleは曰く、“Googleが自社の暗号化データに対して用いているものと同じ、強化されたキー管理システムを使って、厳しいキーアクセスコントロールと監査を行う”。

この暗号化は新たに書き込まれるデータに対しては今日から有効だが、前からあるオブジェクトに関しては“今後数か月内に”暗号化を行う、という。

なおAWSのクラウドストレージS3は、2011年ごろから256ビットのAdvanced Encryptionによるサーバサイドの暗号化を提供している。またセキュリティ基準がより厳しい企業や政府機関など向けにAmazonは最近、専用ハードウェア(高価!)によるHardware Security Moduleを導入して、Amazonのクラウドにおける機密データや暗号キーの管理を行っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google、Windows PhoneのYouTubeアプリをアク禁―「HTML5で書け」とMicrosoftに要求

今朝(米国時間8/15)、GoogleはMicrosoftのYouTubeのWindows Phoneアプリをアクセス禁止 にしたことを認めた。これはアプリが発表されてから50時間後の決定だった。Windows Phoneユーザーは当然ながら失望している。

いったいどういう事情があったのか? ここ数時間、私が状況を調べてみたところ、以下のようなことがわかった。

Microsoftが新しいYouTubeアプリをWindows Phone向けに最初に発表したのは5月だった。 Googleはこれに不満を抱いた。このアプリはGoogleの配信する広告を正常に表示せず、ビデオのダウンロードが許されていた他、Googleブランドの表示もGoogleが望むような仕様になっていなかった。Microsoftはいったんアプリを引っ込め、両者はアプリの修正に向けて協力していくことで合意した。

それなのに修正されたはずの新アプリが再度、アク禁となってしまったわけだ。問題の原因は、GoogleがアプリがHTML5で開発するよう要求したのに対し、Microsoftは機能面ではGoogleの3つの要求を容れたものの、Windows Phoneプラットフォームの技術的な制約のために不可能だとして、あくまでネーティブ・コードで開発を続行した点にある。

MicrosoftはまたGoogleに対して「将来、Windows Phone側の準備が整い次第HTML5に移行する」ことを約束した(つまりMicrosoftはWindows Phoneのメジャー・バージョンアップに取り組んでいる)。

しかしこの点に関して両者の合意ができないまま、Microsoftはアプリを公開してしまった。当然Googleは不快になり、YouTubeへのアクセス権を剥奪した。またMicrosoftはGoogle自身が利用しているモバイル広告APIへのアクセスを要求していたが、Googleはこれも却下した。

Googleは「YouTubeアプリの開発者は全員が同一のガイドラインに従うべきだ」というコメントを発表した。つまり全員がHTML5で開発せよということだ。それは理にかなっているように聞こえるが、全員というのはGoogleには適用されない。Google自身のiOS向けとAndroidのYouTubeアプリはネーティブ・コードで記述されている。

しかしそのぐらいでGoogleはたじろがず、Microsoftに「そいつをHTML5で書け」と要求した。そこでMicrosoftは困難な立場に立たされた。Windows PhoneにきちんとしたYouTubeアプリが必要なのはもちろんだが、Windows Phoneがアップデートされるまで正常に動作するYouTubeアプリはHTML5で書けない。そこでMicrosoftはGoogleにアク禁にされる可能性が十分あるのを知りながらネーティブ・コードのアプリを一方的に発表するという少々図々しい戦術を取った。で、予想どおりGoogleはアク禁にした。

テクノロジー界隈では「事実は小説より奇なりだ」。

いい迷惑なのは何百万人もWindows Phoneユーザーだ。もちろん、モバイル版Internet Explorerを使えばWindows PhoneでYouTubeを閲覧するのは可能だ。今後どう決着がつくか予想はできない。ともあれ今後もGoogleとMicrosoftは小競り合いを続けていくことになるだろう。

アップデート: MicrosoftはHTML5問題を詳しくブログ記事で説明している。

[画像:Flickr]

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Google Mapsストリートビューの楽屋裏を見せるためのサイトができた…とにかくきれい

GoogleはそのTrekker(トレッカー)事業に相当な人と時間を投じて、地球上のはるか遠方の地域を地図とビューに収めてきた。そして今回は、その楽屋裏をユーザに見せ、それらの場所と制作過程の両方について、詳しく教えてくれる。そのためにGoogleが特製したサイトはBehind The Scenes site for the Treks Street View projectと名づけられ、そこにはビデオや素晴らしい画像、地図、オーディオヴィジュアルなツアーなどがある。

この楽屋裏サイトは暇つぶしに絶好だが、Googleはここで複数のプロダクトをユーザに一望させる。それらは、YouTube、Google Maps、Mapsのツアー、HTML5によるWeb技術、スライドショウ、などだ。またここは、ある意味ではChromeブラウザの潜在的な能力を見せるデモでもある。

現在、このミニサイトで見られるのは、Burj Khalifa(ブルジュハリファ, 上図)、Iqaluit(イカルイト)、Mt. Everest(エヴェレスト山)、Grand Canyon(グランドキャニオン)、Great Barrier Reef(グレートバリアリーフ)、Amazon Basin(アマゾン盆地)、Kennedy Space Center(ケネディ宇宙センター)である。Galapagos Islands(ガラパゴス島)やVenice(ヴェニス)のツアーも、もうすぐ加わるそうだ。

GoogleはTrekker事業に企業や団体の協力を求めているから、あなたが作ったビューが、このミニサイトの呼び物になる可能性もある。Googleの独創的というか独走的なプロジェクトにはときどき、何の役に立つの?と冷やかしたくなることもあるが、このミニサイトはなにしろ、ヴィジュアルがきれいである。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google検索がパーソナルになった。自分のフライト情報、レストラン予約、写真、等々が検索可能に(ただし米国のみ)

Googleは今日(米国時間8/14)、検索で個人的情報を見つけやすくする新機能を発表した。同検索エンジンは、次のフライト(「私のフライトは定刻に出発するのか?」)やホテル、OpenTableの予約、荷物の配達(「私の荷物はいつ届くのか?」)、買ったもの、予定などの情報を探してくれる。Google+と同じように、通常のGoogle検索を使って自分の写真を「海辺での自分の写真を検索」等のクエリで見つけることができるようになった。

これらの機能はすべて「オプトアウト」で、米国で英語を使っている全ユーザーに今後数日間のうちに提供される。Google Glassを除く全プラットフォームで利用可能で、もちろん音声認識も利用できる。

Gmailの検索フィールドのトライアルGoogle Nowを使っている人は、この数ヶ月間に、検索でこれらのカードがポップアップしたのを見たことがあるだろう。Googleの広報担当者が私に話したところによると、今日公開された新機能はGmailの検索フィールドトライアルの一部であり、トライアルは今後も最新機能に触れたい人たちのための実験台として続けられる。いずれはフィールドトライアル機能の多くをGoogle検索に取り込む計画だ。

写真(以前はGoogle+でのみ利用可能でアップロードした写真を分析する)を除き、Googleはこの情報をすべてGmailの受信メールから取得する。

プライバシーの懸念やこうした情報の繊細さを踏まえると、Googleが本機能をオプトアウトにした決断は興味深い。Googleが指摘するように、個人情報はすべて暗号化されて通信され、Googleにログインしている時のみ表示される。いつでも完全に遮断するか(検索設定に新たに「プライベートな検索結果」セクションが追加された)、検索結果ページの地球儀アイコンをクリックしてセッションごとにオフにすることができる。

Googleが答えられるようになった質問のリストはここにある。以下にいくつか例を示す。

  • フライト:“Is my flight on time?” と質問すれば、これから乗るフライトの最新情報がわかる。
  • 予約:“my reservations” でディナーの予定を見たり、“my hotel” でホテルの名前と住所が得られる。ワンクリックで、車や公共交通の経路が表示されるので何ステップも節約できる。
  • 買い物:“my purchases” で現在注文してある商品の配達状況がわかるので、ママへのプレゼントが予定通り届くかどうかを確認できる。
  • 予定:“What are my plans for tomorrow?” で、明日のフライト、ホテル、レストラン、イベントの予定が表示される — 旅行中に非常に便利な機能だ。
  • 写真:“Show me my photos from Thailand”と打てば、Google+にアップロードした写真を見られる。さらには、“my photos of sunsets” とすれば、過去何年かに撮影した自慢の夕暮れの写真を探してくれる。

Google担当者が私に語ったところによると、質問の認識はかなり柔軟性が高く、これらのクエリは新機能を確実に使用するが、類似の言い回しを使うこともできる。

原文へ


Googleのバグ発見謝礼制度の累積支払い賞金額が200万ドルを突破, 賞金額増額へ

Googleのバグ発見報奨制度は、今日の同社の発表によると、これまでの報奨金提供額の総額が200万ドルを突破した。この事業がスタートしたのは3年前だが、これまでの報奨の対象となったバグ報告は、Chromiumと同社のWebアプリケーションにおける2000件あまりのセキュリティ関連バグだ。200万ドルのうち約100万ドルがChromiumのバグ発見者へ、残る100万ドルがWebアプリケーションのバグを見つけた者へ行った。

今日の発表と合わせて同社は、一部の賞金額を大幅に上げた。“これまで賞金額1000ドルとされたバグは、今後は、最大5000ドルまでとする”、とGoogleの金庫番Chris EvansとAdam Meinが今日の発表声明で書いている。また賞金の最高額は最大1万ドルに引き上げられ、それはバグの性質を特定せずGoogleがケースバイケースで決める。さらに、バグ報告とともにそのパッチを提供した者は、賞金が増額される

今日の発表の前には、Web脆弱性発見報奨金事業でも同様の増額が行われ、クロスサイトスクリプティングバグは7500ドル、GmailとGoogle Walletのバグおよび認証バイパスバグは5000ドルとなった。Webアプリケーションのバグ報告の賞金の最低レベルは500ドルから3133.7ドルに上がった。

たしかに、バグ報告はお金になる。Facebookも1週間前に、同様の発表を行った。同社がこれまで支払った賞金総額は、100万ドルあまりだそうだ。長年この種の事業に抵抗を示していたMicrosoftも最近ついに折れて、賞金上限額10万ドルの報奨制度を発足させた。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google Drive、スペルチェックと箇条書きに機能追加

このところGoogle Driveの生産性ツールに画期的変更は起きていないが、Googleは小さな改善を定期的に続けている。今日(米国時間8/12)、新しいスペルチェック機能および、「構造化好き」な人たちのために、段落番号と箇条書きのカスタマイズが強化された。

新しいスペルチェックモードは、リアルタイム・スペルチェックが標準になる前の世代(あるいは今でもWordでこのモードを使っている人)にとっては親しみがあるだろう。このモードを使うと、文書やプレゼンテーション全体のスペリングをチェックできる。

「ツール — スペリング]を選ぶと、画面の横に小さなウィンドウがポップアップするので、そこで文書内の不運なタイプミスを修正あるいは無視できる。

新しい箇条書きについてGoogleは、「個々の行頭文字の色、サイズ、スタイルを変更可能で、オリジナルを追加することもできる。おそらくもっとも有用な機能は、行頭文字ごとに変更できることで、例えば特定の項目に完了のマークをつけられる。

Google Driveは、つい先週リンクツールが強化された、共有設定も最近改善された。

原文へ


Google Drive/Docsに便利なリンク生成機能…リンク先候補に検索の結果を表示

Google Driveにささやかだけど便利なアップデートが加わった。それは、ハイパーリンクツールだが、そんじょそこらの平凡なエディタ機能と違って、上の図でお分かりのように、1)Google検索の結果、2)ドキュメント中のブックマーク、3)Drive上の関連ファイルが表示され、それらの中の好きなものをワンクリックでリンクできる。

ユーザはリンクにしたい語を高輝度にする。そしてハイパーリンクアイコンをクリックすると、上記の候補一覧が表示される(キーボードショートカットのCtrl-Kを使ってもよい)。いちばん登場頻度が多い候補は、その語のWikipedia記事だ…ただしレポートなどで多用すると、それを読む先生はあまり嬉しくないかもしれない。テキスト中のブックマークは、たぶんGoogle Docsなどを使って長い記事を書いたり編集することの多い人にとって便利だろう。まあ比較的地味な機能だけど、でもとにかく最近のGoogleは、自社サービスをそうやって統合化するのに熱心なのだ。

Google Docsの最強の対抗馬はMicrosoftのOffice Web Appsかもしれないが、それはまだBingを統合していない。ただし最近のBingはAPIの充実増強に力を入れ、新しいデベロッパサービスのローンチにも熱心だから、Office製品からBingを使う機能が提供されるのも、時間の問題だろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google、検索結果におすすめの「詳細(in-depth)コンテンツ」のハイライト表示を開始

GoogleがGoogle検索に関連する新機能のアナウンスを行った。検索内容に関する詳細(in-depth)な内容を特別に強調して表示するものだ。Googleによると、検索を行う利用者の多くは、わかりやすい「答え」を探しているケースが多いそうだ。しかし別に同社が行ったリサーチによれば、10%の人は、より詳細(in-depth)な情報を探し求めてもいるのだそうだ。そうした利用者の声にも応じる形で、Googleは検索結果のページで詳細情報へのリンクをハイライト表示することにした。

Googleがどのような判断基準で、ある記事が、とくていの内容についての「詳細」(in-depth)記事であると判断するのかの詳細については明らかになっていない。もちろん、高品質で、細かいところまで記述しているものが選ばれることになる。現在のところでの発表によると「品質、詳細さなどを示す指標から、自動的に記事のランク付けを行います」とのこと。「多くの人に、さらに高品質なコンテンツを提供してもらい、調査や発見にも役立つ情報が得られるようになるでしょう」とも言っている。

当面のうちは、この機能は英語でGoogle.comを利用する利用者に対してのみ提供されるそうだ。

この詳細(in-depth)コンテンツとして紹介されたいと考えるのであれば、長い記事を作成する際に一般ガイドライン(general guidelines)に従ったものとすることが第一です(ページネーションのマークアップなども同様)とGoogleは言っている。もちろん内容的にも深く掘り下げたものであることが大事なのは当然のことだ。

「作成してから数ヶ月、あるいは何年もの間、参照され続けるコンテンツが生まれ続けているというのは、とても素晴らしいことだと思います。こうしたコンテンツを味わう喜びを、より多くの人に広めようというのが、今回アナウンスした新機能の目的のひとつです。そのようにGoogleのスタッフであるPandu Nayakが記している。尚、有名なパブリッシャーからの情報はもちろん、内容によって有名とはいえないパブリッシャーからの情報も詳細(in-depth)コンテンツとして紹介されることがあるとも記している。

このところGoogleは、検索結果をクリックしなくても、簡単な情報を把握できるような機能をリリースしてきていた。今回のアナウンスは、情報密度の面でも、クリックして別サイトに飛んでから情報を入手するという意味でも、これまでとは逆のアプローチであると言えるかもしれない。もちろん、両者はいろいろな意味で補完的に作用していくのが自然なスタイルでもある。

原文へ

(翻訳:Maeda, H)


GoogleがもうすぐローンチするAndroid Device ManagerはなくしたAndroid機をWebから見つける

Appleのユーザはかなり前から、自分のiPhoneなどを紛失したときに、iOSにあるデバイスロケータ(device locator, デバイスの所在を見つける)やリモートワイピング(remote wiping, 遠隔データ消去)機能を利用できるが、Androidのユーザにはサードパーティ製のアプリしかなかった。それが、もうすぐ変わる。Googleの今日(米国時間8/2)の発表では、今月の終わりごろにAndroid Device ManagerというWebサービスがローンチし、ユーザはどこかにあるはずの自分のデバイスの位置を知ったり、呼び出し音を鳴らしたり、リモートワイプしてデータが悪者の手に渡らないようにできる。

対象機は、Android 2.2以上を搭載した機種で、今日の発表から推測すると、Android Device Managerのサイトには紛失したデバイスにpingする機能があるようだ。そのほかにどんな機能があるのか、それはまだ分からない。

当然というか、このサービスはAppleのFind My iPhoneの機能にとてもよく似ている。呼び出し音は最大音量で鳴らせるから、愛機があなたのカウチのクッションの下にあっても分かる。デバイスの位置は地図上に示される(これも当然)し、リモートワイプはほんの数クリックで完了する。Appleの、紛失した携帯にメッセージを送る機能とか、リモートでロックするツールは、ないようだ。

とくに新しいものは何もなく、一部のOEMは自社製品にすでにそんな機能を搭載しているが、Googleからやっと正式に出たということは、Androidユーザにとって喜ばしいことだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google、全米のStarbucks7000店舗に無料の高速Wi-Fiを提供へ

さきほどGoogleはブログ記事で、Starbucksと協力して、アメリカの全7000店のコーヒーショップに無料の高速Wi-Fiホットスポットを設置すると発表した。このプロジェクトは完了までに1年半ほどかかる予定だ。

Googleによれば、現行のStarbucksの無料ホットスポット比べて速度は最低10倍にアップする。Googleが光ネットワークの実験を行っているカンサスシティーなどでは100倍に高速化されるという。

8月中にもGoogle化されたStarbucksのWi-Fiが登場し始めるという。ひいきのStarbucks店舗がGoogle化されたかどうかは手持ちのデバイスでSSIDをチェックすればよい。Googleはこれまでにも本社の所在するマウンテンビュー市に無料の高速Wi-Fiアクセスポイントを設置している。またBoingoと協力してさまざまな場所に無料Wi-Fiを設置してきた。最近ではサンフランシスコ市の公共の場所に多数の無料Wi-Fiを設置する計画を発表している。承認が得られれば 2014年の4月までに設置が完了する。

今回のプロジェクトでGoogleは全米のStarbucks店舗のWi-Fi設置と運営という大きな事業をAT&Tから引き継ぐことになる。その意味でも結果が大いに注目される。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


やっぱりAndroidはモバイル時代のWindowsか?

柔軟で拡張性の高いOSがサードパーティーのハードウェア・メーカーに開放されて市場に独占的地位を築いた。どこかで聞いた話? デジャヴ?

実際、AndroidとWindowsの並行関係は驚くほどだ。ではAndroidはMicrosoftがWindowsで陥っているような落とし穴を避けられるだろうか?

ともあれまず現在のAndroidと95年のWindows 95の類似点をおさらいしてみよう。

  • Androidはほぼ無数のフォームファクターのハードウェアによって断片化(多様化といいたければそうも言える)されている。 サードパーティーのメーカーのAndroidサポートは(Windows同様)、きわえめて広範囲で、根強い。
  • Androidの柔軟性と自由性はありとあらゆる種類のアプリケーションが爆発的に生まれることを可能にしたが、アプリ市場にマルウェアや屑アプリが蔓延するなど無法状態も招いている。インターネット初期のWindowsも同様の無法時代を経てきた。
  • AndroidはAppleがパイオニアとして切り開いた市場に後発で参入した。その際にサードパーティーのハードウェア・メーカーを味方につける戦略を採用し、Appleのハードウェア製造、販売能力を凌駕することに成功した。世界市場でAndroidタブレットのシェアははiPadを2対1で上回っている。Windowsもよく似た道筋を通ってAppleを圧倒した。
  • サードパーティー・メーカーはデバイスごとの利益を最大にしようとして、Android OSに過剰なカスタマイズを行い互換性の障害となっている。またくだらない独自開発のアプリをプレインストールしてユーザー体験を損なっている。ハード・メーカーの過剰なカスタマイズとプレインストール独自アプリがユーザーを苛立たせているのは現在のWindowsも同じだ。
  • Androidデバイスは全体としてはiOSデバイスより安価だ。最小限の業務ができればよいというならWindowsノートはMacbookよりずっと安価だが、一方でおそろしく複雑なグラフィックス処理をリアルタイムで実行したいというゲームマニアは大金を投じてスーパー・ゲーム・マシンを買うことができる。Macにはそういう自由はない。iOSデバイスと巨大スクリーンのハイエンドAndroidデバイスの関係はこれに似ている。.

ただし、AndroidとWindowsを比較する上でもっとも重要な点は製品寿命だろう。 Windowsは1985年以来市場に君臨し続けている。ハードウェアで優位に立ったOSは驚くほど寿命が長い

1985年以来コンピュータは大きく姿を変えてきたが、Windowsも同様だった。スマートフォンとタブレットもこれから大きく変貌していくだろう。またモバイル時代が到来してもわれわれが依然としてPCを使っているのと同様、今後どのような新しいコンピューティングの波が押し寄せようと、10年後もわれわれがスマートフォンとタブレットを使っていることは間違いない。AndroidはMicrosoftのWindows戦略にならってハードウェアとソフトウェアのもっとも重要な2つのセグメントに支配権を打ちたてようとしているようだ。

「いやAndroidはシェアが大きいだけで、iOSこそユーザーに愛され、もっとも利益を上げているOSだ」という声も聞こえてきそうだ。しかし歴史が教訓となるならば、スマートフォン戦争は短期の利益率やアプリの数の競争ではなく、スマートフォンというプラットフォームを5年、10年、15年に渡って支配するのは誰かという戦いになる。その誰かは日増しにAndroidであるらしく思えてくる。

ここで決定的に皮肉なのは、Microsoftの過去の戦略をそのまま採用して大成功を収めたAndroidに対してMicrosoft自身が苦戦を強いられていることだ。Microsoftが早期にモバイル分野で自分自身のWindows戦略を採用することに気づいていれば状況は大きく変わっていただろう。 

[原文へ]

(翻訳:滑川海彦 Facebook Google+


居間の大画面に動画をストリーミングできるGoogle Chromecast―試用してみたが、圧倒的にオススメだ

「十分に進歩したテクノロジーは魔法と見分けがつかない」というアーサー・C・クラークの名言を思い出した。

GoogleのChromecastの使い方はこの上なんく簡単だ。テレビのHDMI端子に挿しこむだけでよい。すると手持ちの各種スマートフォン、タブレット、パソコンからビデオや音楽をストリーミング再生できる。Chromecastには専用リモコンはない。何であれストリーミングできるデバイスならすべてリモコンとしても利用できる。Chromecastには独自のユーザー・インタフェースさえない。ユーザー・インタフェースもストリーミングを開始したデバイスに任されている。ChromecastはテレビをWiFi経由でクラウドのコンテンツに接続させるポータルに過ぎない。

驚きが詰まった小さなデバイス:

これほどいろいろな意味で驚かされたデバイスは最近記憶にない。

値段が驚きだ。わずか35ドルである。冗談だろう? Googleによれば、これでも赤字販売ではないという。 WiFiチップ、CPU、2GBのフラッシュメモリ、RAM、HDMIライセンス料、組立て、包装、送料等々を支払ってもまだ利益が出るのだそうだ。もちろん利益といっての4セントかそこらだろうが、ともかく35ドルでも赤字ではないそうだ。

設定? HDMI端子に挿す。あとはパソコン、スマートフォンのChromecastアプリからWiFiに接続させるだけ。 以上で終了。これも驚きのシンプルさだ。

アプリがサポートするコンテンツの幅も驚くほど広い。YouTubeやNetflixがすでにサポートされている。しかもいちいち個別のアプリを起動したり、設定したりする必要がない。スマートフォンでYouTubeを訪問するとすでにChromecastボタンが表示されているので、押すだけだ。

Chromecastの発表自体、なかなか驚きの演出だった。Googleは発表のまさにその瞬間までほぼ完全にChromecastの秘密を守ることに成功した。Googleの開発チームに加えてNetflix、Pandora、OEMメーカーなど数多くのサードパーティが加わっているのに見事な情報管理だ。

もちろんChromecastはまだ完全な製品ではない。しかしほとんどは容易に修正可能だろう。それに35ドルでは機能に多少の限定があっても強い批判の対象にはなるまい。

良い点、悪い点:

ストリーミングの画質は良い。少なくともXbox 360やApple TVに劣ることはない。Chromecastに最適化されているNetflix、Youtube、GooglePlayのコンテンツについては非常に良い。再生、停止などはストリーミングを開始したデバイスだけでなくChromecastアプリをインストールしたあらゆるデバイスから自由にできる。

ただし、パソコンのChromeブラウザにChromecastエクステンションをインストールしてHuluやHBOGOのようなChromecastに最適化されていないチャンネルを再生すると画質はかなり落ちる。これはYoutubeなどの場合、サイト側でChromecast向けに直接ストリーミングを行うのに対して、Huluなどの場合、パソコンでChromecast向けにエンコードし直してストリーミングを行わねばならないためだ。パソコンが間に入るため、その能力によって画質に大きな差が出ることなる。

Chromeエクステンションの話が出たついでに紹介しておくと、 パソコンにローカルに保存されたコンテンツをこのエクステンションを通じてChromecastにストリーミングすることもできる。AVI、MOV、MKVなどのフォーマットを試してみたがうまくいった(ただし2012年のMac Book Airと802.11nではかなりフレームレートが落ちた)。

さらに改善されるはず:

AppleTV、正確にいえばAppleTVのAirPlayストリーミング機能と比較してChromecastの最大のセールスポイントはクロスプラットフォームの互換性だ。AirPlayが基本的にiOS、Mac、WindowsのiTunesに限定されるのに対してChromecastアプリはiOS、Android、Mac、Windowsのすべてで作動する。いまのところChromecastのCastプロトコルはAirPlayほどサードパーティのメーカーに広まっていない(なにしろ今登場したばかりだ)が、状況はすぐに変わるだろう。スマートテレビへの内蔵、スピーカーその他のガジェットのサポートなどが近く実現しそうだ。そうなればAirPlayの有力なライバルとなる。

結論:

これほど自信をもって推薦できるデバイスも珍しい。多少でも興味を持ったらともかく買ってみるようお勧めする。35ドル以上の価値があることは保証する。またその機能は近いうちに大きく改良、拡張されるはずだ。多少のバグもすぐに修正されるだろう。

[情報開示:GoogleはChomecastを1台評価用に貸してくれた。この記事を書き終わったら返却しなければならない。大いに気に入ったので私は1台注文ずみだ。]

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Googleの即席通訳機能が完成すれば言語バリアはすべて解消

Googleは、データを集めるためのものを作るのが好きだ。そのデータを使って消費者や企業の意思など、ありとあらゆる利益目的を判断していく。でもその池にある最大の魚はBabel fish、Douglas Adamsが彼のHitchhiker’s Guide to the Galaxyシリーズの中で発明した即席翻訳機だ。あらゆる言語間の翻訳/通訳を瞬時にして行い、シームレスなコミュニケーションを可能にする。Googleは、そのBabel fishを作ることによって、旅行時などの便宜を提供するだけでなく、集めたデータの採掘価値を増幅しようとしている。言うまでもなく翻訳/通訳によって、データの利用価値や受益者数が増加するからだ。

今日のThe Times紙の記事によると、GoogleのAndroidプロダクト管理担当VP Hugo BarraがThe Times紙に、単純な会話においてリアルタイムの通訳をするデバイスをGoogleは企画している、と話した*。人びとのあいだの言語バリアを取り除くその製品は、一部の言語に関してはすでに“ほぼ完成”していて、まわりにノイズのない環境では十分実用になるそうだ。〔*: THE TIMESのその記事では、通訳専用機ではなく携帯のアプリのようだ。〕

Googleには前からGoogle Translateというサービスがあり、テキストを翻訳する。Webページ全体の翻訳もする。しかし今回の目標は、受け答え関係のある二者間における日常の実用通訳だ。地球上の主な言語すべてに対応する製品の完成には数年を要するという、ほどんどSF的な話のようだが。

しかしすでにGoogleにはGoogle Nowというものがあり、パーソナルアシスタントや自動化デジタルプランナーもある。だから、これらの仲間に即席通訳機能が加わるのは自然だ。しかも、一部の言語と条件に関してはすでに完成しているというから、すごい。どこの誰とでも会話ができる超汎用通訳機能の完成は何年も先らしいが、そのときわれわれは、気づかない可能性もある。おそらく、それほど自然にさりげなく、Googleの全製品に搭載されるのだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Android 4.3に隠し機能を発見。アプリケーション毎に細かなパーミッション設定が可能

大方の予想通り、Googleは水曜日に行われたイベントにて、AndroidのチーフであるSundar PichaiよりAndroid 4.3の発表を行った。カメラインタフェースの改善、Bluetooth Low Energyのサポート、アニメーションの円滑化などのパフォーマンス改善、制限付きマルチユーザーアカウントの導入などが行われた。ただ、そうしたものがアップデートの全てではなかった。Googleは公にしていなかったが、Android Policeが隠し機能をスクープした。その隠し機能とは、アプリケーション毎に特定パーミッションをオン・オフする設定機能だ。

この機能はApp Opsと呼ばれる。アプリケーション毎に、位置情報や通知機能の利用といったパーミッション設定を細かく行うことができるようになっている。Android Policeでも報じているように、このApp Opsのフロントエンドとして利用できるアプリケーションも既にGoogle Playに登録されている(Android 4.3が必要となる)。

App Opsの目的は、Android利用者に、アプリケーション毎のパーミッション設定を柔軟に行なってもらえるようにすることだ。バッテリーの浪費をやめさせたり、あるいは絶え間ない通知をオフにするような機能を提供する。App Opsにわかりやすいインタフェースを与えるなら、セキュリティないしプライバシーの面から言っても非常に便利なものとなるに違いない。利用者は細かなところまで意識しつつ、細かくセキュリティ設定を行うことができるようになるのだ。

インストールするのを躊躇していたようなアプリケーションについても、利用者のこだわりに応じて設定することができるようになれば、インストールしてみようと考えるようになるかもしれない。そうなれば開発者にとっても良い話となり得る。

但し、Android Policeの言うように、App Opsは確かに目的に応じた動作はするものの、まだ完璧というわけにはいかないようだ。たとえばFacebookアプリケーションを対象にテストしてみると、アプリケーションが特定の動作をした後にのみ、当該動作を許可するかどうかが表示されるようになるらしい。こうした混乱要素があるがゆえに、GoogleはこのApp Ops機能を公式にアナウンスしていないのだろう。機能をいつ頃までにチューニングして正式リリースする予定なのかについて、Googleに問い合わせているところだ。新しいことがわかったらぜひお伝えしようと思っている。

尚、利用者側から見ると、アプリケーションの一部機能が動作しないのが、設定をいじったからなのかどうかがわかりにくいという面もあるだろう。同様の問題は、通知トレイ内での設定が、着信音をならすかどうかなどのメイン設定を上書きしてしまう機種があることで既に顕在化している。アプリケーション毎の設定ができるようになれば、利用者側の混乱はきっと大きくなることだろう。Android Policeは、App Opsの設定によってアプリケーションの正常動作が妨げられている際には、システムレベルで通知できるようにすべきであるとしている。但し、パーミッションを厳しく設定すれば、そうした通知が溢れ出すことも想定される。するとせっかく通知機能を導入しても、利用者がオフにしてしまうということになるかもしれない。

あるいはこのApp Opsというのは、そもそも一般利用者に公開するために導入したものではなく、とりあえず制限付きマルチユーザーアカウントを導入するためのものとして作成されたものなのかもしれない。

モバイルプラットフォームでのマルウェアは、Android環境上に蔓延しているという話もある。Androidのセキュリティ機能に対する不安も広がりつつあり、GoogleとしてはApp Opsのような機能を導入しなければならない状況にあるとも言える。App Opsのようなものがあれば、勝手に音声通話を利用されたり、SMSマルウェアをインストールされてしまったりということが減るものと思われる。もし完全には防げないにしても、どのアプリケーションがあやしげな動作をしているのかを確認する手段ともなり得ると思われる。

原文へ

(翻訳:Maeda, H)