ビジネスサポートプランニング: 2015

2015年8月17日月曜日

動画　動画のサイズを正しく設定する　動画のサイズを確認する

エンコード済み動画のフレームサイズは、動画要素のサイズによって違ってくる場合があります（画像を実際のサイズでは表示できない場合があるため）。
エンコードされた動画サイズの確認方法は、動画要素の videoWidth と videoHeight プロパティを使用します。
width と height は、動画要素のサイズを返します。
この値は、CSS またはインラインの width と height 属性を使用してサイズが設定されている事があります。

関連記事

動画のサイズを確認する
動画がコンテナからはみ出さないようにする

2015年8月16日日曜日

動画　動画プレーヤーをカスタマイズする

動画の表示方法はプラットフォームごとに違います。
モバイルではデバイスの向き（縦向きか、横向きか）を考慮しなければなりません。
Fullscreen API は動画コンテンツのフルスクリーン表示を制御できます。

詳しくは以下の記事を参考にしてください。

動画を追加する
レガシープラットフォーム用の代替手段を提供する
動画プレーヤーをカスタマイズする
動画のサイズを正しく設定する
利用しやすさに関する問題
クイックリファレンス

2015年8月15日土曜日

動画　動画プレーヤーをカスタマイズする　コンテンツのフルスクリーン表示の制御

フルスクリーンでの動画の再生を強制できないプラットフォームでは、Fullscreen API が幅広くサポートされています。

出典：http://caniuse.com/fullscreen

Fullscreen API を使用すると、コンテンツやページのフルスクリーン表示を制御できます。

video:のように要素をフルスクリーン表示する方法
elem.requestFullScreen();

ドキュメント全体をフルスクリーン表示する方法
document.body.requestFullScreen();

フルスクリーン状態の変更をリッスンする方法
video.addEventListener("fullscreenchange", handler);

要素が現在フルスクリーンモードかどうかを確認する。
console.log("In full screen mode: ", video.displayingFullscreen);

また、CSS で :fullscreen 疑似クラスを使用して、フルスクリーンモードの要素表示方法を変更できます。

Fullscreen API をサポートしているデバイスでは、動画のプレースホルダとしてサムネイル画像を使用することを推奨しています。

実際の動作を確認するには、グーグルのデモをご覧ください。

グーグルのデモ画面スクリーンショット

注意：requestFullScreen() は現在プリフィックスベンダーです。
完全なクロスブラウザの互換性のための余分なコードが必要な場合があります。

関連記事

2015年8月14日金曜日

動画　動画プレーヤーをカスタマイズする　インラインまたはフルスクリーン表示

動画の表示方法はプラットフォームごとに違います。
iPhoneのSafariは、動画要素をウェブページ内で表示しますが、再生するときはフルスクリーンモードになります。

縦向きの iPhone に表示された動画要素のスクリーンショット

Androidは、フルスクリーンアイコンをクリックすることでフルスクリーンモードをリクエストできます。
デフォルトではインラインで動画を再生します。

縦向きの Android の Chrome で再生している動画のスクリーンショット

iPad の Safari では動画をインラインで再生します。

横向きの iPad Retina の Safari で再生している動画のスクリーンショット

動画　動画プレーヤーをカスタマイズする　さまざまなデバイスでのデバイスの向きの影響

デバイスの向きは、デスクトップやノートパソコンでは問題になりません。
しかし、携帯端末やタブレット末端ではデザインを検討する際には非常に重要です。
iPhone の Safari は、縦向きと横向きでの切り替えが非常にスムーズです。

縦向きの iPhone の Safari で再生している動画のスクリーンショット

横向きの iPhone の Safari で再生している動画のスクリーンショット

iPadやAndroidでは、デバイスの向きが問題になる場合があります。

例　横向きの iPad での動画の再生をカスタマイズしなかった場合。

横向きの iPad Retina の Safari で再生している動画のスクリーンショット

CSS で width: 100% または max-width: 100% と設定すると、デバイスの向きによるレイアウトの問題の多くは解決できます。
また、フルスクリーンの代替手段も検討しなければならない場合があります。

関連記事

2015年8月12日水曜日

動画　レガシープラットフォーム用の代替手段を提供する

https://developers.google.com/web/fundamentals/media/video/provide-alternatives-for-legacy-platforms?hl=ja

すべてのプラットフォームがすべての動画形式をサポートしていません。
プラットフォームでサポートされている動画形式を確認し、各プラットフォームで動画を再生できるようにします。
詳細は以下の記事を参考にしてください。

動画を追加する
レガシープラットフォーム用の代替手段を提供する
動画プレーヤーをカスタマイズする
動画のサイズを正しく設定する
利用しやすさに関する問題
クイックリファレンス

2015年8月11日火曜日

動画　レガシープラットフォーム用の代替手段を提供する　使用されている形式を確認する

ブラウザで選択されている動画形式を確認したい場合は、ソースを確認します。
JavaScriptは、動画の currentSrc プロパティを使用して、使用されているソースを取得できます。

Chrome と Firefox は chrome.webm を選択し、Safari は「chrome.mp4」を選択しています。

関連記事
サポートされている形式を確認する
複数の形式で動画を生成する
使用されている形式を確認する

2015年8月10日月曜日

動画　レガシープラットフォーム用の代替手段を提供する　複数の形式で動画を生成する

同じ動画を異なる形式で保存できるツールがあります。

このツールを使い、様々なプラットフォームや形式で再生が出来るようにします。

代表的なツール

デスクトップツールFFmpeg・・・エンコード、トランスコード、マルチプレクサ、デマルチプレクサ、ストリーム、フィルタをデコードし、人間と機械が作成しているほとんど何でも再生することが主要なマルチメディアフレームワークです。
GUI アプリケーションMiro
HandBrake・・・近代的な、広くサポートされるコーデックの選択に、ほぼすべての形式からビデオを変換するためのツールです。
VLC・・・フリーなマルチプラットフォーム対応のマルチメディアプレイヤーであり、DVD、オーディオCD、VCDや様々なストリーミングプロトコルを再生可能なフレームワークです。
オンラインエンコーディング / トランスコーディングサービスZencoder・・・ライブでのパフォーマンスのリーダーとファイルクラウドエンコーディング、iOS用の完全なアダプティブビットレートソリューション、放送局やプロのコンテンツプロバイダのエンコード、マルチスクリーン、ライブストリームのためのアダプティブビットレートのトランスコーディング。
Amazon Elastic Encoder・・・クラウドのメディア変換サービス。高度なスケーラビリティ、使いやすさ、高い費用効率性を実現する設計で、開発者や企業は、メディアファイルをその元のソース形式からスマートフォン、タブレット、PC などのデバイスで再生可能できるバージョンに変換（または「トランスコード」）できます。

関連記事
サポートされている形式を確認する
複数の形式で動画を生成する
使用されている形式を確認する

2015年8月9日日曜日

動画　レガシープラットフォーム用の代替手段を提供する　サポートされている形式を確認する

サポートしている動画形式を検出する方法は、canPlayType() を使います。
このメソッドは、mime-type とオプションのコーデックで構成された文字列引数を受け取り、いずれかの値を返します。

関連記事
サポートされている形式を確認する
複数の形式で動画を生成する
使用されている形式を確認する

2015年8月8日土曜日

動画　動画を追加する

ユーザーの多くは動画を好む傾向にあります。
ユーザーにとって動画は、面白かったり判りやすかったりするからです。
携帯端末の場合、テキストや画像コンテンツより、動画コンテンツの方が情報を理解しやすい場合もあります。
一方で動画は帯域幅が必要な為、すべてのプラットフォームで常に同様に視聴できません。
ローディング時間が長く待たされたり、再生をタッチしても何も起きない場合があります。
その様な場合、ユーザーエクスペリエンスは最悪です。
動画をサイトに追加して、どのデバイスでも最高のユーザーエクスペリエンスを実現する方法が必要になります。
詳細は以下の各ページを参考にしてください。

動画を追加する
レガシープラットフォーム用の代替手段を提供する
動画プレーヤーをカスタマイズする
動画のサイズを正しく設定する
利用しやすさに関する問題
クイックリファレンス

2015年8月7日金曜日

動画　動画を追加する　ポスター画像を含める

動画要素に poster 属性を追加すると、ユーザーのデバイスが要素が読込んだ時に、内容をすぐに把握できます。
この場合、ユーザーは動画をダウンロードして再生する必要がなくなります。

<video poster="poster.jpg" ...>
...
</video>

ポスターは、動画の src が破損していたり、指定した動画形式がすべてサポートされていない場合には代替手段になります。
ポスター画像のデメリットは、追加のファイルリクエストによって帯域幅を消費し、レンダリングが必要になることです。
詳細は、画像の最適化を参考にしてください。

ポスター有りと無しでは表示が異なります。

ポスター有り

ポスターなし

ポスター有りの方がユーザーにとって親切であることが一目瞭然です。

関連記事

2015年8月6日木曜日

動画　動画を追加する　開始時刻と終了時刻を指定する

動画コンテンツを使用する場合は、帯域幅を節約して、レスポンシブなサイトを構築します。
それには、Media Fragments API を使い、動画要素に開始時間と終了時間を追加します。

メディアフラグメントの追加は、メディアの URL に #t=[start_time][,end_time] を加えます。

例
5～10 秒の間だけ動画を再生する場合の指定。
<source src="video/chrome.webm#t=5,10" type="video/webm">

また、Media Fragments API を使用すると、同じ動画の複数のビューを配信でき、複数のファイルをエンコードする必要はありません。

覚えておかなければならないこと。

Media Fragments API は、ほとんどのプラットフォームでサポートされていますが、iOS はサポートされていません。

使っているサーバーが Range リクエストをサポートしている事を確認します。一部のホスティングサーバーでは無効の場合があります。

ブラウザデベロッパーツールを使用して、レスポンスヘッダーの Accept-Ranges: bytes を確認します。

関連記事

2015年8月5日水曜日

動画　動画を追加する　複数のファイル形式を指定する

すべてのブラウザが全ての動画形式をサポートしていません。
要素では、ユーザーのブラウザがいずれかの形式をサポートしていない場合の代替として、複数の形式を指定します。

例
<video controls>
<source src="chrome.webm" type="video/webm">
<source src="chrome.mp4" type="video/mp4">
<p>このブラウザは、video要素をサポートしていません。</p>
</video>

ブラウザはオプションの type 属性を使用しタグの解析をおこない、どのファイルをダウンロードし、再生をするか判断します。
例の場合、ブラウザが WebM をサポートしている場合は chrome.webm で再生をします。
サポートしていない場合は MPEG-4 動画で再生します。
ウェブで動画と音声を使用する方法については、デジタル動画に関する、楽しくてためになる解説動画を参考にしてください。
これは、特に携帯端末でさまざまな HTML やサーバー側スクリプトを配信する場合に、次の4つのメリットがあります。

デベロッパーが優先順位に基づいて形式を指定できる。
ネイティブクライアント側で切り替える為、コンテンツ取得リクエストが 1 つ生成するだけですみ、ロード時間が短縮できる。
サーバー側でユーザーエージェントの検出機能とサポートデータベースを使用するより、ブラウザで形式を選択する方がより簡単で迅速であり、信頼性も高くなります。
ファイルごとにソースのタイプを指定するとブラウザが動画の一部をダウンロードして形式を識別しなくてすみ、ブラウザが動画ソースを選択する為にネットワークのパフォーマンスが向上します。

特にモバイルコンテンツは、帯域幅とロード時間が重視されます。
モバイルコンテキストではユーザーが我慢する局面がある場合、ユーザーエクスペリエンスが著しく低下する為、特に重要です。
type 属性を指定しない場合、複数ソースの中にサポートされていないタイプが存在すると、パフォーマンスに影響を及ぼします。
モバイルブラウザデベロッパーツールを使用して、type 属性がある場合と type 属性がない場合でネットワークのアクティビティを比べてみましょう。
また、ブラウザデベロッパーツールでレスポンスハンドラを確認し、サーバーが適切な MIME タイプを報告することを確認します。
これが無いと動画のソースタイプのチェックが機能しません。

関連記事

2015年8月4日火曜日

動画　動画を追加する　動画要素を追加する

サイトで動画の読み込み、デコード、再生を行うための動画要素を追加します。

この動画のソースは
<video controls=""><source src="video/chrome.webm" type="video/webm"><source src="video/chrome.mp4" type="video/mp4"><p>このブラウザは、動画要素をサポートしていません。</p></video>

関連記事

2015年8月3日月曜日

モバイル SEO よくあるミスを回避する再生できないコンテンツ

動画やコンテンツの種類により、モバイルで再生出来ない場合があります。

例

ライセンスの制約があるメディア

モバイル端末で幅広くサポートされていないFlash

その他のプレーヤーを必要とする場合

再生できないコンテンツがあるとユーザーの不満の原因になります。
モバイルでサポートされていないコンテンツが含まれているページにアクセスすると、エラーメッセージが表示されます。

動画を再生できない

ユーザーにとって快適なモバイルサイトではありません。
独自の動画プレーヤーや、サポートされていない形式のコンテンツを提供するのではなく、HTML5 標準タグを使用して動画等のコンテンツをアップする事をグーグルは推奨しています。

Flashやマルチメディアプレーヤーでレンダリングする動画コンテンツがある場合は、すべてのウェブブラウザで動作する HTML5 のアニメーションの使用をグーグルは推奨しています。
Google Web Designer はHTML5で簡単に作成できます。

グーグルの推奨する対処方法

アニメーションに HTML5 標準を使用します。

すべての端末で再生できる動画を埋め込んで使用します。

動画の字幕を利用します。ブラウジング支援機能を利用している人や、独自の動画形式を再生できないブラウザを利用している人が、アクセスできます。

詳しくは、Google の Web Fundamentals で動画に関するおすすめの方法を参照してください。

関連記事

JavaScript、CSS、画像ファイルをブロックしている
再生できないコンテンツ
間違ったリダイレクト
モバイル端末でのみ 404 エラーが発生する
インタースティシャル
不適切な相互リンク
表示速度の遅いモバイルページ

2015年8月2日日曜日

モバイル SEO　よくあるミスを回避する　JavaScript、CSS、画像ファイルをブロックしている

最適なレンダリングとインデックスを実施するには、ウェブサイトで使用している JavaScript、CSS、画像ファイルについて、常に Googlebot からのアクセスを許可します。
Googlebot がウェブサイトの表示をユーザーと同様に確認する為です。
ボットのクロールを、robots.txtファイルで禁止している場合、コンテンツのレンダリングとインデックスの作成をするアルゴリズムにダイレクトに悪影響があります。
その結果、ランキングが最適化されません。

グーグルが推奨する対処方法

Google Search Consoleの「Fetch as Google」で、Googlebot が JavaScript、CSS、画像ファイルをクロールしている事を確認します。「Fetch as Google」は Googlebotがどんな形でコンテンツ認識し、レンダリングしているか確認出来る為、インデックス登録時の問題を特定して修正できます。

Google Search Console　robots.txt テスターで、robots.txt のチェックとテストをします。

モバイルフレンドリーテストで、モバイルページをテストし、モバイルユーザーが利用できるサイトか確認します。

モバイルページ用に別の URL を使う（既に使用している）場合は、必ずモバイルとパソコン双方のURL をテストをおこない、リダイレクトが認識され、クロール出来ることを確認します。

JavaScript、CSS、画像ファイルをブロックしている
再生できないコンテンツ
間違ったリダイレクト
モバイル端末でのみ 404 エラーが発生する
インタースティシャル
不適切な相互リンク
表示速度の遅いモバイルページ

2015年8月1日土曜日

ユーザーエージェントの正確な検出

ユーザーエージェントの検出はミスが発生しやすい傾向があります。
あらゆる原因がありますが、主な原因は次の3つです。
この3つの原因は発生率が高くなっています。

ユーザーエージェントの検出は、ユーザーエージェントストリング（またはサブストリング）リストとマッチングをします。このリストは、常に更新する必要があり、更新しないと新しいユーザーエージェントとあわなくなります。実際、リストの多くは適切に保守されていないのげ現状です。最新の状態でない場合、ユーザーエクスペリエンスが低下する原因になっています。
ユーザーエージェントを照合した場合、不一致が頻繁に起こります。PC ユーザーがモバイル端末ユーザーとして検出される場合や、その逆があります。タブレットがスマートフォンとして処理される場合もあります。サイトにアクセスするブラウザのユーザーエージェントを検出する場合は、モバイルストリングを探すのではなく（たとえば「ios」だけをチェックする）、スマートフォン固有のストリングを探します（たとえば「ios」と「Mobile」の両方をチェックする）。詳しくはMo’ better to also detect “mobile” user-agentを参照してください。
ユーザーエージェントの検出ではクローキングに十分配慮します。ユーザーエージェントを検出する際は、ユーザーエージェントストリングでデバイス名を探してデバイスのクラスやタイプを検出します。Googlebot だけを対象にはできません。すべての Googlebotユーザーエージェントは、Googlebot自体を特定のモバイル端末と見なします。モバイル端末の場合と同一に扱います。例）スマートフォン用 Googlebot が自身を iPhone と見なしている場合、iPhone ユーザーに対するのと同じレスポンス（リダイレクト、最適化されたコンテンツなど）を返さなければなりません。

2015年7月31日金曜日

Vary HTTP ヘッダー　とは

Vary HTTP ヘッダーには重要で役立つ効果が 2 つあります。

キャッシュからページを配信するかを決定する際、ユーザーエージェントを選択する必要性を、キャッシュサーバーに知らせます。Vary HTTP ヘッダーがない場合、モバイルユーザーに PC 用 HTML ページのキャッシュが送られたり、逆のパターンもあります。
Googlebot がモバイル端末向けのコンテンツを迅速に検出できます。有効な Vary HTTP ヘッダーは、ボットがクロールする際に利用可能な信号です。

Vary HTTP ヘッダーは、リクエストに対するサーバーからの応答の一部です。

例
GET /page-1 HTTP/1.1
Host: www.example.com
(...rest of HTTP request headers...)
HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710
(... rest of HTTP response headers...)

Vary ヘッダーは、ユーザーエージェントの種類別に、レスポンスが変異するとブラウザに伝えます。
サーバーで既に Vary HTTP ヘッダーを使用している場合は、既に配信されているリストに「User-Agent」を追加できます。

2015年7月30日木曜日

Make the Web Faster　ウェブサイトの高速化

ウェブサイトの高速化をおこなう為の診断をグーグルはGoogle developers で提供しています。

https://developers.google.com/speed/?csw=1

このサイトは、サイトの分析と最適化をおこなうツールがあるので便利です。

またツールの他に学習するコンテンツもあります。

Analyze with PageSpeed Insights（サイトのパフォーマンス測定）

Speed up with the PageSpeed Modules
PageSpeedモジュールでスピードアップ
自動的に書き換え、自分のWebサイト上のリソースを最適化するために、あなたのApacheやnginxのサーバー上でオープンソースPageSpeedモジュールを実行します。

Speed up your browsing with Google DNS
グーグルのDNSを使用してブラウジングを高速化
レバレッジGoogleのパブリックDNSはブラウジング体験のセキュリティと速度を向上させることができます。

Offload popular open-source libraries
人気の高いオープンソースのライブラリをオフロード
最も人気のある、オープンソースのJavaScriptライブラリを提供するために、Googleのインフラストラクチャを使用して、あなたのサイトを高速化。

Protocols & Standards
プロトコル·規格
より速くウェブを作るために設計された最新のプロトコルやWeb標準については、こちらをご覧ください
WEBP
SPDY
その他の規格

Performance Best Practices
パフォーマンスベストプラクティス
パフォーマンスのWeb慣行に飛び込むにはあなたのウェブサイトのための最新のパフォーマンスのWeb最適化を学習します。

2015年7月29日水曜日

モバイルSEO 　設定を検索エンジンに伝える　レスポンシブウェブデザイン

レスポンシブウェブデザイン（RWD）は、サーバーからどのデバイスに対しても常に同じ HTML コードを配信し、CSS を使用して各デバイスでのページのレンダリングを変える設定です。

Googlebotがページとそのアセット（CSS、JavaScript、画像）をクロールできれば、Google のアルゴリズムがレスポンシブデザイン設定であると自動的に検出します。
レスポンシブデザインは、画面サイズに合わせて調整する同一のコードがすべてのデバイスに配信されます。

meta name="viewport" タグを使用すると、コンテンツをどう調整すべきかをブラウザに伝えることができます。
詳細は「Web Fundamentals」を参考にしてください。

ページがすべてのデバイスに対応していることをブラウザに知らせるには、ドキュメントのヘッダーに次のメタタグを追加します。

meta viewportタグは、ページのサイズや縮尺を、デバイスの幅に合わせてどのように調整すべきかをブラウザに伝えるために使用します。
meta viewport要素を指定しない場合は、モバイルブラウザのデフォルトであるパソコン画面の幅でページがレンダリングされます。
その後モバイルブラウザが、フォントを大きくして画面に合う縮尺に変える、コンテンツの一部のみが画面に収まるように表示する等の調整を試みます。
この調整により、フォントサイズの統一が消失したり、コンテンツを操作するためにダブルタップやピンチで拡大する必要が生じる場合があります。
Googleは、モバイル端末でこの操作を必要とするページを、モバイルフレンドリーと見做しません。

左側が meta viewportを指定していないページ。
モバイルブラウザがパソコン画面の幅を想定してページをレンダリングしているため、細かすぎてコンテンツを読み取ることができません。
右側は、同じページにmeta viewport指定したページ。
デバイスの幅に合っているため、モバイルブラウザ側でページの縮尺を変える必要がなく、コンテンツが読みやすい大きさで表示されます。

レスポンシブな画像には、<picture>

URLが1つなので、ユーザーがコンテンツを簡単に共有やリンクができます。
対応するパソコン用ページやモバイル用ページが存在することをGoogleアルゴリズムに伝える必要がなく、ページへのインデックスプロパティの割り当てが正確に行われます。
同じコンテンツのページを維持管理する手間が省けます。
モバイルサイトのよくあるミスを抑えることができます。
ユーザーのデバイスに最適ページへリダイレクトする必要がないため、読み込み時間を短縮できます。また、ユーザーエージェントに基づくリダイレクトは、エラーが発生しやすいため、ユーザーの利便性を失う可能性があります（詳細は、ユーザーエージェントを正しく検出するを参照してください）。
Googlebotがサイトをクロールするために必要なリソースを節約できます。同じコンテンツのページが複数存在すると、別々のGooglebotがすべてのバージョンを複数回クロールする必要があります。レスポンシブウェブデザインの場合は、一つのGooglebotがページをクロールだけです。クロールの効率が上がると、サイト内で多くのコンテンツがインデックス登録され、適切なタイミングで更新されます。

レスポンシブウェブデザインに関する詳細は、ウェブマスターセントラルのブログ、Web Fundamentalsを参考にしてください。

以下の点にご注意ください。
robots.txt などの方法で、Googlebotのクロールをブロックしないでください。
Googlebotが外部ファイルにアクセスできることで、そのサイトの設定がレスポンシブウェブデザインであることがアルゴリズムによって検出され、適切に処理されます。
よくあるミスが発生しないようにしてください。

JavaScript
モバイルフレンドリーサイトを作成する場合、JavaScript をどのように使い、各種デバイスでサイトのレンダリングと動作を変更するか検討する事です。

JavaScriptの一般的な用途には、ページに表示する広告や画像の解像度の決定などがあります。
JavaScript のさまざまな実装方法と、それらの方法がレスポンシブウェブデザインの使用にどう関連するかの解説です。

一般的な設定
モバイルフレンドリーサイトでJavaScriptの一般的な方法は3つです。

すべてのデバイスに同じ JavaScript を配信：同じ HTML、CSS、JavaScriptのコンテンツを配信します。JavaScriptがデバイスで実行されたときに、サイトのレンダリングや動作が変更されます。ウェブサイトにJavaScriptが必要な場合、Googleはこの方法を推奨しています。
JavaScript とサーバー側でのデバイス検出：ウェブサイトは JavaScript とサーバー側でのデバイス機能の検出を両方使って、デバイスごとに異なるコンテンツを配信します。
JavaScript の動的配信：すべてのデバイスに同じ HTML が配信されますが、JavaScript はデバイスのユーザーエージェントで異なるJavaScriptコードを動的に配信するURLから配信されます。

すべてのデバイスに同じ JavaScript を配信
URLはすべてのデバイスに同じコンテンツ（HTML、CSS、JavaScript、画像）を配信します。
デバイスでJavaScriptが実行された場合のみ、サイトのレンダリングや動作を変更します。
これは、CSSメディアクエリを使用したレスポンシブウェブデザインの動作に似ています。

例
ページで、すべてのデバイスに同じ HTML が配信され、その HTML に含まれている <script> 要素が、JavaScriptを配信する外部URLをリクエストするとします。
このJavaScriptのURLをリクエストするデバイスはすべて同じコードを取得します。
このコードが実行されたときに、JavaScriptはデバイスを検出し、ページのレンダリングなどを変更することを決定します。
つまり、パソコン向けの画像や広告コードではなく、スマートフォン向けの画像や広告コードが組み込まれることになります。

レスポンシブウェブデザインと非常に密接な関連があり、Googleアルゴリズムはこの設定を自動的に検出します。
ページやアセットのURLがコンテンツを動的に配信しないため、Vary HTTP ヘッダーは必要ありません。
このようなメリットがあることから、ウェブサイトでJavaScriptを使う必要がある場合はこの設定をグーグルは推奨しています。

JavaScript とサーバー側でのデバイス検出
サーバーがクライアント上のJavaScriptと連携してデバイスの機能を検出し、配信するコンテンツを変更します。

例
サイトで、デバイスがPCとスマートフォンのいずれかに基づいて、コンテンツのレンダリングを変更するとします。
この場合、画面のサイズを検出するJavaScriptをウェブサイトに組み込みます。
検出した画面サイズはサーバーに送信され、デバイスに送信するコードをサーバーが更新または変更します。
一般に、JavaScriptは検出したデバイス機能をCookieに保存し、サーバーはそれ以降の同じデバイスからのアクセス時にCookieを読み取ります。

サーバーがユーザーエージェントごとに異なるHTMLを返すので、この方法は動的な配信設定の一種と見なされます。
詳細は 動的な配信 - ウェブマスター向けモバイルガイドに記載されています。
簡単に言うと、ユーザーエージェントごとに異なるHTMLコンテンツを配信するURLが必要な場合は、ウェブサイトに「Vary: User-agent」HTTPレスポンスヘッダーを含めます。

JavaScript の動的配信
すべてのデバイスに同じHTMLが配信され、そのHTMLに、リクエスト側のユーザーエージェントに応じて異なるコンテンツを用意できる外部JavaScriptファイルを含む <script> 要素が含まれます。
JavaScript コードは動的に配信されます。
この場合、JavaScript ファイルは「Vary: User-agent」HTTP ヘッダーと一緒に配信することをグーグルは推奨しています。
これは、キャッシュや Googlebot に対し、JavaScript がユーザーエージェントごとに異なる可能性があることを知らせるものです。
また、Googlebot がJavaScript ファイルをクロールするためのシグナルです。

2015年7月28日火曜日

Analyze with PageSpeed Insights（サイトのパフォーマンス測定）

Analyze with PageSpeed Insightsでは、あなたのサイトのページスピードを診断します。
Page Speed Insightsでは、デスクトップ末端とモバイル末端向けに診断をおこないます。
診断結果から、グーグルが最適な解析をおこない、ページスピードアップの為の提案をしてくれます。

URLを入力し、分析をクリックします。

分析が終わると解析結果が表示されます。
解析結果はモバイルユーザーエージェントと PC ユーザーエージェントで 1 回ずつ、計2回取得します。

解析結果はスコアで表示されます。
スコアの範囲は 0～100で表示され、スコアが大きいほどサイトのスピードは良好であり、85 以上のスコアは解析ページのパフォーマンスが高いことを示します。
PageSpeed Insights は継続的に改良されているので、スコアに変動があります。

以下の提案がされる可能性があります。

●スクロールせずに見える範囲のコンテンツの読み込み時間ユーザーが新しいページをリクエストした瞬間から、スクロールせずに見える範囲のコンテンツがブラウザで表示されるまでの経過時間。
●ページ全体の読み込み時間ユーザーが新しいページをリクエストした瞬間から、ブラウザでページが完全に表示されるまでの経過時間。

ただし、ネットワーク接続のパフォーマンスにより、大きく変動するため、ネットワークに依存しない部分（サーバー設定、ページの HTML 構成、画像やJavaScript、CSS などの外部リソースの使用方法）のみを考慮しています。
提案された解決策を実装すれば、ページの相対的なパフォーマンスは改善されます。
しかし、絶対的なパフォーマンスはユーザーのネットワーク環境に大きく左右されます。

各提案は、重要性を表す優先度インジケータが表示されます。

赤色の感嘆符
この問題を修正すると、ページのパフォーマンスが大幅に改善されます。

黄色の感嘆符
それほど忙しくない場合はこの問題の修正を検討してください。

修正方法を表示をクリックすると詳細を見る事が出来ます。
詳細には

緑色のチェックマーク
大きな問題は見つかりません。パフォーマンスは良好です。

このページ向けに最適化された画像、JavaScript、CSS リソースをダウンロードできます。

この様に表示され場場合、クリックをすると最適化された画像、JavaScript、CSS リソースのダウンロードを開始します。

PageSpeed Insightsは、モバイルのパフォーマンス向上に力を入れています。
PageSpeed Insights のモバイル分析について、Google I/O 2013 で行われた素早いモバイルウェブサイトに関するプレゼンテーションを参照してください。
PageSpeed Insights で実行された分析の詳細なリストも見る事が出来ます。

2015年7月27日月曜日

Google ニュースサイトマップの作成

サイトが Google ニュースに登録されているか確認します。
登録されていない場合は、Google ニュースパブリッシャーセンターで登録を申請できます。

関連記事

ニュースサイトマップのガイドライン
サイトマップエントリの例
サイトマップの送信
ニュース固有のタグの定義

2015年7月26日日曜日

Google ニュースサイトマップの作成　ニュース固有のタグの定義

<publication>
必須
<publication> タグでは、記事が掲載されているパブリケーションを指定します。このタグには、<name> と <language> の 2 つの子タグが必要です。
<name> はニュースパブリケーションの名前です。この名前は、news.google.co.jp で記事に表示される名前と完全に一致させる必要があり、後続の括弧で囲まれた部分は除外します。たとえば、Google ニュースに「毎週新聞（購読）」と表示する場合は、「毎週新聞」と指定します。
<language> はパブリケーションの言語です。この言語は、ISO 639 言語コード（2 文字または 3 文字）で指定する必要があります。例外として、中国語の場合、簡体中国語は zh-cn、繁体中国語は zh-tw を指定します。

<access>
一般公開でない場合は必須、それ以外は省略
指定できる値は「Subscription」または「Registration」です。
記事へのアクセス方法を指定します。
登録や購読なしで Google ニュースの読者に記事を公開する場合、このタグを省略します。

<genres>
ジャンルを適用する場合は必須、それ以外は省略可
「PressRelease」や「UserGenerated」など、記事内容の特徴を示すプロパティをカンマ区切りで指定します。
指定できる値については、Googleニュースパブリッシャーセンター　コンテンツタイプタグの記事を参照してください。
ユーザーが戸惑うことのないよう、コンテンツタイプは正確に指定します。

<publication_date>
必須
記事の公開日を W3C 形式で指定します。
「完全な日付」（YYYY-MM-DD）、または「完全な日付、時、分、秒」とタイムゾーン指定子（YYYY-MM-DDThh:mm:ssTZD）のいずれかの形式を使用します。
記事をサイトマップに追加した時刻ではなく、記事をサイトに公開した最初の日時で指定しなければなりません。

以下のいずれかの形式であれば Googleクローラが認識します。
完全な日付
YYYY-MM-DD（例: 1997-07-16）

完全な日付、時、分
YYYY-MM-DDThh:mmTZD（例: 1997-07-16T19:20+01:00）

完全な日付、時、分、秒
YYYY-MM-DDThh:mm:ssTZD（例: 1997-07-16T19:20:30+01:00）

完全な日付、時、分、秒、小数秒
YYYY-MM-DDThh:mm:ss.sTZD（例: 1997-07-16T19:20:30.45+01:00）

<title>
必須
ニュース記事のタイトルです。
注: Google ニュースに表示される際、表示上の理由でタイトルが省略される場合があります。<title> タグには、サイトに表示される記事のタイトルのみ記入します。
記者やライターの名前、パブリケーション名、公開日を入れてはなりません。

<keywords>
省略可
記事のトピックを示すキーワードをカンマ区切りで指定します。
キーワードは、Google ニュースの既存のキーワードから選択する事も、その他のキーワードを指定することもできます。

<stock_tickers>
省略可
記事の主題となっている企業、投資信託会社、その他の金融機関の証券コード（最大 5 つ）をカンマ区切りで指定します。
該当するのは、主にビジネス記事です。
各証券コードは、コードの前に証券取引所の名前を付ける必要があります。

また、Google Finance のエントリと一致する必要があります。

関連記事
ニュースサイトマップのガイドライン
サイトマップエントリの例
サイトマップの送信
ニュース固有のタグの定義

2015年7月25日土曜日

Google ニュースサイトマップの作成サイトマップの送信

サイトマップの作成後、ニュース記事を含む最上位のディレクトリにサイトマップをアップロードします。
サイトマップの送信方法について詳しくは、サイトマップページでサイトマップを管理する の記事を参照してください。

関連記事

ニュースサイトマップのガイドライン
サイトマップエントリの例
サイトマップの送信
ニュース固有のタグの定義

2015年7月24日金曜日

Google ニュースサイトマップの作成　サイトマップエントリの例

Google ニュースサイトマップで使用するサイトマッププロトコルには、ニュース固有の追加タグがあります。
ニュース固有タグを使用したニュースサイトマップエントリの例を次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:news="http://www.google.com/schemas/sitemap-news/0.9">
<url>
<loc>http://www.example.org/it/article31.html</loc>
<news:news>
<news:publication>
<news:name>The IT News</news:name>
<news:language>en</news:language>
</news:publication>
<news:access>Subscription</news:access>
<news:genres>PressRelease, Blog</news:genres>
<news:publication_date>2014-10-13</news:publication_date>
<news:title>新しいグーグルのアップデート</news:title>
<news:keywords>business, IT, google, seo, sec</news:keywords>
<news:stock_tickers>google, JPX</news:stock_tickers>
</news:news>
</url>
</urlset>

関連記事

ニュースサイトマップのガイドライン
サイトマップエントリの例
サイトマップの送信
ニュース固有のタグの定義

2015年7月23日木曜日

Google ニュースサイトマップの作成ニュースサイトマップのガイドライン

ニュースサイトマップを作成する際は、以下の要件を満たす事を考慮します。

ニュースサイトマップには、過去 2 日以内に公開された記事の URLだけ含める事が出来ます。2 日以上前の記事は、ニュースサイトマップから削除でき、ニュースインデックスに 30 日間保存されます。
新しい記事が公開されたら、随時ニュースサイトマップを更新します。Googleニュースボットは、他のボットと同様の頻度でニュースサイトマップをクロールします。
1 つのニュースサイトマップに含めることができるURL数は 1,000個です。1,000を超える数の URLを含める場合は、複数のサイトマップに分割し、サイトマップインデックスファイルで管理します。サイトマッププロトコルで規定されている XML 形式で作成します。サイトマップインデックスファイルで指定できるサイトマップは 50,000個までです。この制限は、ウェブサーバーが過負荷を防止する為です。
新しい記事を公開する際に、毎回新しいニュースサイトマップを作成する必要はありません。新しい記事のURLを追加してサイトマップを更新します。
Googleサイトマップ生成ツールは、サイトの個々のニュース記事とは関連しないURLも対象も生成の対象になります。Googleサイトマップ生成ツールはニュースサイトマップの作成には使えません。Googleニュースサイトマップの生成に役立つサードパーティ製ニュースサイト専用ツールもあります。

関連記事

ニュースサイトマップのガイドライン
サイトマップエントリの例
サイトマップの送信
ニュース固有のタグの定義

2015年7月22日水曜日

Googleニュースパブリッシャーセンターサイトについての情報が間違っている場合の対処方法

Google ニュースパブリッシャーセンターで、初めてニュース提供元情報の記録を表示したときに、サイトの古い情報が表示される場合があります。

この場合、ニュース提供元情報の記録は、その大半をパブリッシャーセンターで更新できます（セクション URL の追加または編集、ニュース提供元の名前やラベルの更新など）。ニュース提供元の URL や国など、その他の更新については、グーグルニュースに問い合わせます。問合せ先。

サイトの古い情報が表示される多くの場合、ニュースクローラがそれらのページのコンテンツを検出し続けるからです。
たとえば、ページ上にある「話題のニュース」セクションや「もっと見る」リンクなどが原因です。
これらは、サイト上の他の場所に対象コンテンツがあれば削除しても問題ありませんが、古いページが自動的に除外されない原因となります。

ニュース提供元情報の記録は、Google ニュースが更新する場合があります。
サイトの情報を可能な限り最新の状態に保つことが重要です。
古い情報を見つけた場合は、ニュース提供元情報の記録を更新します。

サイトの情報を最新の状態に保つことは、Google ニュース読者とニュースメディア双方にとって有益です。
これにより、読者はクリックしようとしているコンテンツのタイプ（「ブログ」など）を知ることができ、ニュースボットはサイトのニュースコンテンツを検出、分類が容易になります。

関連記事
Google ニュースパブリッシャーセンターについて
Google ニュースパブリッシャーセンターをフル活用する
サイトが Google ニュースパブリッシャーセンターで表示されない場合の解決方法
用語集
セクション URL を追加、編集、削除する方法
各ニュース提供元ラベル（「ブログ」など）について
ニュース提供元の詳細を更新する方法

2015年7月21日火曜日

Google ニュース用語集

ニュース提供元
ニュース提供元は、ブログ、ニュースパブリケーション、オンラインマガジンなどのニュースサイトです。

セクション
セクションは、あなたがニュース記事を投稿するニュースサイトのページです。
ボットがこのページにアクセスして新しい記事を検出します。
セクションページはホームページ、サブディレクトリ、またはサブドメインが設定できます。
通常、セクションは、同じカテゴリ（「IT」、「レジャー」など）またはトピック（「国政選挙」など）に属しているニュース記事が含まれます。
Google ニュースパブリッシャーセンターを使用してサイトの各種セクションを記述することで、Google ニュースがコンテンツを検出、掲載しやすくなります。
セクションは、個々の記事の URLではありません。

ラベル
ラベルは、通常ユーザーが各種のニュースカテゴリを見分けるために、あらかじめ定義する一連の用語です。
これらのラベルを付けるのは、Google ニュースがセクションやニュース提供元のコンテンツを分類する際に簡便に素早くおこなえます。
そうする事により、ニュースがいち早くグーグルニュースにラインナップされます。

セクションラベル：ボットが各セクション URL の記事をトピックごとに分類する際に使用します。
たとえば、「IT」ラベルを http://example.com/it に追加すると、このセクションの記事をIT関連の記事として分類します。
ニュース提供元ラベル：あらかじめ定義されている一連の用語で、通常、サイトの内容を表し、Google ニュースがコンテンツを分類、表示するためのヒントとなります。
たとえば、「ブログ」ラベルをサイト（http://exampleblog.com/）に追加すると、サイトをブログとして分類することができます。
各ニュース提供元ラベルの詳細は、ニュース提供元ラベルガイドライン（各ニュース提供元ラベルについて）の記事を参考にしてください。

関連記事
Google ニュースパブリッシャーセンターについて
Google ニュースパブリッシャーセンターをフル活用する
サイトが Google ニュースパブリッシャーセンターで表示されない場合の解決方法
セクション URL を追加、編集、削除する方法
各ニュース提供元ラベル（「ブログ」など）について
ニュース提供元の詳細を更新する方法
サイトについての情報が間違っている場合の対処方法

2015年7月20日月曜日

Googleニュース　サイトがGoogleニュースパブリッシャーセンターで表示されない場合の解決方法

Google ニュースパブリッシャーセンターでニュース提供先情報の記録を表示する場合は、サイトをGoogle ニュースに登録し、Google Search Console で所有者確認をおこなわなければなりません。

パブリッシャーセンターでサイトが表示されない場合は次の項目を確認します。

サイトが Google ニュースに登録されている事。
記事が Google ニュースのインデックス登録されていることを確認します。
確認する方法は、site: を使います。
Google ニュースホームでsite:○○○○で検索します。
○には該当するサイト名を入れます。
（例: 「site:google.com」で検索するとグーグル社が発信しているニュースが表示され、グーグルがパブリッシャーセンターに登録されている事が判ります）。

ニュースサイトがまだ Google ニュースに登録されていない場合は、Googleニュースパブリッシャーセンター　Googleニュースに登録する　の記事を参考にしてください。

Google Search Console でサイトの所有者確認をおこなったか。
サイトの所有者確認が完了していない場合は、サイトの確認方法　Google アナリティクストラッキングコードによる確認の記事を参考にサイトの所有確認をおこないます。
確認後、サイトがパブリッシャーセンターで表示されるまでに、１時間程度の時間を要する場合があります。
注: 所有者確認は、ドメイン名プロバイダを使用する事をグーグルは推奨しています。
ドメイン名プロバイダを使用する事より、ニュース提供元情報の記録を表示する場合や、サブドメインを記録に追加する場合に発生する問題を最小限に抑えれます。
ドメイン名プロバイダを使用できない場合は、HTML ファイルによる確認方法をグーグルは推奨しています。

また、複数のサブドメイン（www.example.com と news.example.com など）からニュースコンテンツを提供している場合、トップドメイン（この例では example.com）の所有者確認をいます。
トップドメインの所有者確認をしていない場合、パブリッシャーセンターで特定のニュースセクションを設定が出来なくなります。

Google Search Console所有者確認はサイト全体に対しておこなったか。
たとえば news.example.com というサイトの場合、news.example.com/news の所有者確認を行っただけでは、サイトの他の部分についての所有者確認は行われません。
同様に、sports.example.com、www.example.com、www.example.com/news などの関連サイトだけを所有者確認しても、news.example.com へのアクセスは許可されません。

正しいログイン用メールアドレスを使用しているか。
パブリッシャーセンターにログインする際のメールアカウントが、Google Search Console でニュース提供元の所有者確認に使用したメールアカウントと同じであることを確認します。

ニュースチームに問い合わせる。
各項目を確認してもサイトが表示されない場合は、ニュースチームに問い合わせます。

関連記事
Google ニュースパブリッシャーセンターについて
Google ニュースパブリッシャーセンターをフル活用する
用語集
セクション URL を追加、編集、削除する方法
各ニュース提供元ラベル（「ブログ」など）について
ニュース提供元の詳細を更新する方法
サイトについての情報が間違っている場合の対処方法

2015年7月19日日曜日

Search Console サイトの所有権を確認するドメイン名プロバイダ

ドメイン名プロバイダでサイト確認をします。
この確認方法を使用する場合、使用しているサイトのドメイン名プロバイダ（たとえば、google.co.jpやyahoo.co.jp、Amazon.com など）にログインできる状態であること。
また、新しい TXT レコードか CNAME レコードのいずれかを追加することが必要です。

ドメインレジストラでサイトを確認する方法。

ドメインレジストラの確認ツールを使用する。
一部のドメインレジストラでは、サーチコンソールから直接、サイトが確認できます。
これは最も簡単なサイト確認方法です。
現在、GoDaddy や eNom などが使用できます。

DNS TXT または CNAME レコードを追加する。
使用しているレジストラが確認ツールに対応していない場合は、DNSレコードを追加すればサイトを確認できます。
確認ツールはこの追加手順を提供しています。
この手順は使用しているレジストラに固有のものです。
デフォルトでは、DNS TXTレコードの追加手順が表示されます。
この方法が使えない場合は、CNAME レコードの追加手順が表示されます。

現在ドメインレジストラでサイトを確認する方法にはこの二つの方法があります。

ドメインレジストラでサイトを確認する
Search Console のホームで、目的のサイトの横にある [プロパティの管理] をクリックしてから [このプロパティを確認] をクリックします。

[別の方法] タブをクリックします。

[ドメイン名プロバイダ] を選択します。

ドメインレジストラまたはプロバイダを選択し、画面の手順に従います。

利用しているドメインレジストラがリストにない場合は [その他] を選択し、手順に従って手動で DNS レコードを作成します。

[確認] をクリックします。

サーバーからレコードを削除しないでください。
削除すると、サイトが未確認の状態になります。

2015年7月18日土曜日

Googleニュースパブリッシャーセンターをフル活用する　

Googleニュースパブリッシャーセンターを使用するには、まず、Search Console（旧Google ウェブマスターツール）でニュース提供元の所有者確認をします。

パブリッシャーセンターにより、所有するすべてのニュース提供元が一覧表示されます。
セクションまたはニュース提供元の情報が古い場合は更新できます。

各ニュース提供元について、次の内容を確認します。

Google のシステムにサイトの現在のセクションURLが登録されていることを確認。セクションとは、ニュース記事を投稿するサイトのサブディレクトリです。通常、ひとつのセクションには同じカテゴリ（「IT」など）またはトピック（「エンタメ」など）に属しているニュース記事が含まれます。サイトの記録に含まれているセクションURLを確認します。変更する場合はセクションURLを追加、編集、削除する方法の記事を参照してください。

関連するセクションラベルが各セクションURLに適用されていることを確認。セクションのラベル（「IT」など）を確認します。変更する場合はセクションURLを追加、編集、削除する方法の記事を参照してください。

ニュース提供元情報が正しいことを確認。サイトの名前、ドメイン URL、言語、国などのニュース提供元情報を確認します。変更する場合はニュース提供元の詳細を更新する方法の記事を参照してください。

サイトに適用されているニュース提供元ラベル（「ブログ」など）が正しいことを確認します。Google ニュースでサイトに適用されているニュース提供元ラベルガイドライン（各ニュース提供元ラベルについて）の記事を参照してください。変更する場合はニュース提供元の詳細を更新する方法の記事を参照してください。

これで完了です。
サイトに対して、記録に含まれる情報に影響する変更を加える場合は、必ずパブリッシャーセンターでニュース提供元の再確認を行い、必要に応じて更新します。

現在のところ、一部のニュース提供元についてはパブリッシャーセンターでの修正や変更が出来ない場合があります。

関連記事
Google ニュースパブリッシャーセンターについて
Google ニュースパブリッシャーセンターをフル活用する
サイトが Google ニュースパブリッシャーセンターで表示されない場合の解決方法
用語集
セクション URL を追加、編集、削除する方法
各ニュース提供元ラベル（「ブログ」など）について
ニュース提供元の詳細を更新する方法
サイトについての情報が間違っている場合の対処方法

2015年7月17日金曜日

ニュース提供元の詳細を更新する方法　

Googleニュースパブリッシャーセンターでニュース提供元を開きます。
ニュース提供元名とURLの右側にある「詳細」をクリックします。

以下の編集が出来ます。

サイト名の更新：実際に更新を行う前に、サイト命名ガイドラインを確認します。
ガイドラインに違反した場合、グーグルにシステムへの不正な操作を意図しているとみられ、サイト登録ステータスに影響が出る場合があります。

Google+ ページ URL の追加、編集：Googleは、より快適にニュースを閲覧でき、コンテンツをより見やすく表示するために、Google+ ページで公開されている情報を使用する場合もあります。
コンテンツのある Google+ ページURL を追加し、コンテンツのGoogle+ アカウントをニュース提供元情報の記録と関連付けます。
Google+ のURL には、https://plus.google.com/+ExampleSite （例：google.com/+B-s-planningBlogspotJp）または https:plus.google.com/[アカウントを表す数字]（例：plus.google.com/107578398302623317597）の形式を使用します。

ニュース提供元ラベル（「ブログ」など）の追加、編集：ラベルは、ニュース提供元のすべてのセクションに当てはまる場合にのみ適用してください。各ニュース提供元ラベルについて詳しくは、ニュース提供元ラベルガイドライン（各ニュース提供元ラベルについて）の記事を参照にしてください。

ニュース提供元の詳細の編集が完了したら、【保存】をクリックします。

注: ニュース提供元情報の記録に変更を加えると、変更が反映されるまでに最大 24 時間かかります。
24 時間が経過しても変更が反映されない場合は、Google チームに問合せをします。
問合せ先：ニュースヘルプ

更新できない場合の理由
言語
ニュース提供元は最初に、指定した言語でニュースに追加されています。
サイトの言語を変更した場合は、Google ニュースパブリッシャーセンターで再登録をする必要があります。
Google チームが新しい言語の新しいコンテンツの審査をします。

国
ニュース提供元は最初に指定した国でニュースに追加されていきます。
サイトの国を変更した場合や、新しい国の設定で使用する場合は、Google ニュースパブリッシャーセンターで再登録をする必要があります。
Google チームが新しいコンテンツを審査します。

ニュース提供元 URL
サーチコンソールとパブリッシャーセンターは、サイトの URL によってニュース提供元を識別しています。
URLを変更することはできません。
ニュース提供元 UR変更をする場合は、Google チームに問い合わせます。
問合せ先：ニュースヘルプ　pdate　domain

関連記事
Google ニュースパブリッシャーセンターについて
Google ニュースパブリッシャーセンターをフル活用する
サイトが Google ニュースパブリッシャーセンターで表示されない場合の解決方法
用語集
セクション URL を追加、編集、削除する方法
各ニュース提供元ラベル（「ブログ」など）について
サイトについての情報が間違っている場合の対処方法

2015年7月16日木曜日

ニュース提供元ラベルガイドライン　風刺

風刺的なコンテンツを主に公開する場合です。
風刺ラベルをパブリケーションに適用します。
時事問題を風刺的に、大げさに面白おかしく表現して社会的主張を行っている記事が含まれます。
グーグルニュースはさまざまな意見やコンテンツを提供するために、これらの記事を掲載しています。
これらの記事は「（風刺）」ラベルが表示されます。
この為速射は風刺的な記事であることが事前に判別できます。

サイト上の特定のセクションまたは記事が風刺的なコンテンツである場合、これらの記事のサイトマップで <genres> タグの値に「Satire」を入力します。
サイトマップを使用してさまざまなコンテンツタイプを指定できます。
詳細はGoogleニュースパブリッシャーセンター　コンテンツタイプタグの記事を参照してください。

2015年7月15日水曜日

ニュース提供元ラベルガイドライン　ブログ

パブリケーションがブログの場合です。
ブログラベルをパブリケーションに適用します。
通常、ブログは、標準のブログ形式に従って最新のエントリから順に表示されます。
多くの場合、個人的な見解が含まれています。
ブログと識別されたニュース提供元には、パブリケーション名の横に「（ブログ）」ラベルが表示されます。

サイト上の特定のセクションまたは記事がブログである場合、これらの記事のサイトマップで <genres> タグの値に「UserGenerated」を入力します。
サイトマップを使用してさまざまなコンテンツタイプを指定できます。
詳細はGoogleニュースパブリッシャーセンター　コンテンツタイプタグの記事を参照してください。

2015年7月14日火曜日

ニュース提供元ラベルガイドライン　ユーザー作成コンテンツ

サイトで編集者の公式なレビューを経て、報道価値のある第三者のユーザーが作成したコンテンツを主に公開する場合です。
このコンテンツをユーザー作成コンテンツと呼ばれています。
ユーザー作成コンテンツラベルをパブリケーションに適用します。

サイト上の特定のセクションまたは記事のみがユーザー作成コンテンツである場合、これらの記事のサイトマップで <genres> タグの値に「UserGenerated」を入力します。
サイトマップを使用してさまざまなコンテンツタイプを指定できます。
詳細はGoogleニュースパブリッシャーセンター　コンテンツタイプタグの記事を参照してください。

2015年7月13日月曜日

ニュース提供元ラベルガイドライン　意見コンテンツ

意見コンテンツ（論説ページには掲載されない意見記事。例えばレビュー、インタビューなど）の場合は、意見ラベルをパブリケーションに適用します。
「意見」に指定されたニュース提供元のパブリケーション名の横に、「（意見）」ラベルが表示されます。

サイト上の特定のセクションまたは記事が意見コンテンツである場合、これらの記事のサイトマップで <genres> タグの値に「Opinion」を入力します。
サイトマップを使用してさまざまなコンテンツタイプを指定できます。
詳細はGoogleニュースパブリッシャーセンター　コンテンツタイプタグの記事を参照してください。

2015年7月12日日曜日

ニュース提供元ラベルガイドライン　論説コンテンツ

パブリケーションが意見を主とする記事で、特にサイトの論説セクションに掲載される場合です。
論説ラベルをパブリケーションに適用します。
論説と識別されたニュース提供元は、パブリケーション名の横に「（論説）」ラベルが表示されます。

サイト上の特定のセクションまたは記事が論説である場合、これらの記事のサイトマップで <genres> タグの値に「OpEd」とします。
サイトマップを使用してさまざまなコンテンツタイプを指定できます。
詳細はGoogleニュースパブリッシャーセンター　コンテンツタイプタグを参考にしてください。

2015年7月11日土曜日

ニュース提供元ラベルガイドライン　プレスリリース

別のニュース提供元や組織のプレスリリースを配信する場合です。
プレスリリースラベルをパブリケーションに適用します。
Google ニュースに表示の際、パブリケーション名に「（プレスリリース）」ラベルが追加されます。
読者はコンテンツをクリックする前に、記事が配信業者や公的機関から提供されたプレスリリースと認知できます。

サイト上の特定のセクションまたは記事がプレスリリースの場合、記事のサイトマップで <genres> タグの値に「PressRelease」を入力します。
サイトマップを使用してさまざまなコンテンツタイプを指定できます。
詳細はGoogleニュースパブリッシャーセンター　コンテンツタイプタグの記事を参照してください。

2015年7月10日金曜日

ニュース提供元ラベルガイドライン　無料登録

コンテンツにアクセスするために無料登録が必要な場合です。
無料登録が必要な場合、登録ラベルをパブリケーションに適用します。
Google ニュースにコンテンツが表示されるときには、パブリケーション名に「（登録）」ラベルが追加されます。
読者は登録が必要なコンテンツにアクセスするか選択を事前にする事が出来ます。

サイト上の特定のセクションまたは特定の記事のみが登録制の場合、記事のサイトマップで <access> タグの値に「Registration」を入力します。
サイトマップを使用してさまざまなコンテンツタイプを指定できます。
詳細はGoogleニュースパブリッシャーセンター　コンテンツタイプタグの記事を参照してください。

2015年7月9日木曜日

Googleニュース　技術的な要件　定期的に変更されないセクションのページ

Google ニュースは、メインのニュースセクションの URL が、毎日または毎週、毎月、四半期ごとに変更されるサイトは掲載していません。
これは、変更によりURL が一定しない為です。
URL が一定しない場合、クロールに必要な最新の URL が検出できません。
この為に新しいコンテンツがクロール出来なくなります。
Google ニュースの自動クローラは、メインのニュースセクションの URL が変動しないサイトのクロールに最も適しています。
サイトが Google ニュースで承認された後にメインのニュースセクションを変更する場合は、Google ニュースパブリッシャーセンターでセクション URL を更新します。

注意
Googlebot-News によるクロールに最も適しているのは HTML リンクです。JavaScript に埋め込まれたリンクや画像リンクはクロールできません。セクションページの記事に HTML リンク以外のリンクを含めないようにしてください。

また、セクションページ内のアンカーテキストは、リンクする記事のタイトルやページタイトルと同じものを使います。
最後に、リンクする記事の URL には 3 桁の数字を含めます。
これら技術上の要件を満たすことが難しい場合、サイトマップのみに基づいたクロールで対応できる可能性があります。
この場合はGoogle チームに問い合わせて設定方法等の指導を受けます。

2015年7月8日水曜日

ニュース提供元ラベルガイドライン　有料登録

コンテンツにアクセスするために有料登録が必要な場合です。
有料登録ラベルをパブリケーションに適用します。
サイトが Google ニュースに表示されるときには、パブリケーション名に「（購読）」ラベル表示されます。
これにより、読者は支払いが必要なコンテンツにアクセスするか選択する事が事前に出来ます。

サイト上の特定のセクションまたは記事のみが有料登録制である場合、これらの記事のサイトマップで <access> タグの値を「Subscription」とします。
サイトマップを使用してさまざまなコンテンツタイプを指定できます。
詳細はGoogleニュースパブリッシャーセンター　コンテンツタイプタグを参照してください。
また、Google ニュースは多くの購読サイトと提携しており、一部有料コンテンツに Google ユーザーのみが無料でアクセスできます。
サイトに適した登録方法を使い分けます。

2015年7月7日火曜日

Google ニュース技術的な要件サイトのユーザー登録と購読申し込み

ゴーグルニュースを読んでいる読者から、Google ニュースリンクをクリックした直後に登録や購読手続きのページが表示されるのは嫌だという意見がグーグルに寄せられているようです。
ニュース提供元のサイトが登録や購読の申し込みを必要な場合、そのサイトの記事を Google ニュースのインデックスに登録する 3 つの方法があります。

要約すると、Googlebot は、提供元からアクセスを許可されたサイトの範囲をクロールし、インデックス登録します。
グーグルはFirst Click Freeの使用を推奨しています。
推奨理由は、読者の利便性を最大限に高め、コンテンツがより多くのユーザーの目に留まりややすくなるのが、First Click Freeだからです。
購読ユーザーのみにアクセスを限定されたい場合は、「要購読」のラベルが表示されます。
あなたが読者であった場合、どちらを選びますか？
あなたが選ぶ方が、あなたのサイトにあった方法です。

2015年7月6日月曜日

Google ニュース技術的な要件 robots.txt とサイトマップ

サイトの中に購読制コンテンツがあり、Google ニュースから対象コンテンツを除外したい場合は、robots.txt ファイルで指示できます。
たとえば、サイトのコンテンツのうち、一部は自由にアクセスできるコンテンツで一部は登録が必要なコンテンツの場合、購読制コンテンツをサイトの 1 セクションにまとめ、robots.txt にそのセクションを記述します。
この場合、該当セクション内の全てのコンテンツは、クロールとインデックス登録の対象外になります。
詳しくは、Google ニュースロボットを使用してブロックするを参照してください。
もう一つの方法は、クロール用サイトマップのみに変更し、サイトマップ内で各記事へのアクセスレベル（登録 / 購読不要、要登録、要購読）を設定します。
ニュースコンテンツのみをクロールするために必要な変更を行った場合は、グーグルに連絡し、グーグルの確認と更新を待ちます。

2015年7月5日日曜日

Google ニュースロボットを使用してブロックする

報道メディアは多数のコンテンツを配信し、記事によっては Google ニュースに適さない場合もあります。
Google ニュースのクロールは、ウェブ検索と同じGooglebotでおこなわれています。

Google 検索と Google ニュースは、Googlebot と Googlebot-News の異なる 2 つのロボットを使用しています。
これらのロボットをメタタグとして使用するかロボットエントリ内で使用して、コンテンツを表示する場所を管理できます。

つまり、

Googlebot-Newsをブロックすると、Google ニュースにコンテンツが掲載されません。
Googlebot をブロックすると、Google ニュースとウェブ検索のどちらにもコンテンツが掲載されません。

robots.txt ファイルの作成
robots.txt ファイルで、Google 検索と Google ニュースにサイト内のどの部分を掲載するかを詳細に管理できます。
robots.txt ファイルの作成と維持に関する総合的なガイドは、ウェブマスターツール　ROBOTS.TXT を使用して URL をブロックするの記事を参考にしてください。

注意

Google ニュースにサイトが掲載されないようにするには、robots.txt ファイルを使用して Googlebot-News によるアクセスをブロックします。

Google ニュースと Google 検索にサイトが掲載されないようにするには、robots.txt ファイルを使用して Googlebot によるアクセスをブロックします。

サイト内の特定セクションをクロール対象外に指定するには、クローラが robots.txt ファイルにアクセスできる状態にしておきます。

メタタグの作成
サイトの特定の領域へのクローラのアクセスをブロックするには、robots.txt ファイルを使用する方法の他に、HTML ページにメタタグを追加して、特定のページをクロールしないようロボットに指示することができます。
この方法は、メタタグを使用して検索インデックス登録をブロックするを参照してください。

注意

サイト内の特定の記事を Google ニュースに掲載しないようにするには、メタタグを使用して Googlebot-News によるアクセスをブロックします。

サイト内の特定の記事を Google ニュースと Google 検索に掲載しないようにするには、メタタグを使用して Googlebot によるアクセスをブロックします。

サイト内の特定の記事がどのロボットにもクロールされないようにするには、メタタグを使用してアクセスをブロックします。

特定の記事の画像がロボットによりクロールされないようにするには、メタタグを使用してアクセスをブロックします。

記事が期限付きであり、その期限を過ぎたら Google インデックスから記事を削除するよう指定するには、タグを使用します。

日付と時刻は RFC 850 形式で指定します。
この情報は削除リクエストとして処理されます。
該当ページが検索結果に表示されなくなるのは、インデックスから削除後約 1 日後です。
ただし、タグを正常に機能させるには、記事が最初にクロールされる時点でタグが記事に追加されている状況であることが絶対条件です。

HTTP ヘッダーでの指定を使用する
ロボットへの指示を HTTP ヘッダーの中に記述することもできます。詳しくは、Google Developers の HTTP ヘッダー仕様を参考にしてください。

登録: 投稿 (Atom)

analytics

このブログを検索