Snippets must not be written or provided by the business or content provider unless they are genuine, independent, and unpaid editorial reviews.

Reviews must allow for customers to express both positive and negative sentiments. They may not be vetted by the business or restricted by the content provider based on the positive/negative sentiment of the review before submission to Google.

Reviews cannot be template sentences built from data or automated metrics. For example, the following is not acceptable: “Based on X number of responses, on average people experienced X with this business.”

Reviews for multiple-location businesses such as retail chains or franchises can only be submitted for the specific business location for which they were written. In other words, reviews for multiple-location businesses cannot be syndicated or applied to all business locations of the same company.

Aggregators or content providers must have no commercial agreements paid or otherwise with businesses to provide reviews.

Do not include reviews that are duplicate or similar reviews across many businesses or from different sources.

Only include reviews that have been directly produced by your site, not reviews from third-party sites or syndicated reviews.

日本語訳

日本語ページが存在しないので、日本語にしました。

本物で、関係性がなく、対価を支払わず自発的に書いてもらったものでない限りは、レビューは、ほかのビジネスやコンテンツ提供者によって書かれたり提供されたりしたものであってはいけません。
レビューは、好意的な意見と批判的な意見のどちらも顧客が表せるようでなければなりません。Googleに投稿する前に、そのレビューが好意的か否定的かという感情にもとづいて、ビジネス運用者によって審査されたりコンテンツプロバイダーによって制限されたりしてはいけません。
レビューは、データや自動解析から作られた定型文であってはいけません。たとえば次のようなレビューは許可されません ―― 「◯件の返信にもとづくと、たいていの人はこのサービスに対して◯◯を体験しています」
チェーン店やフランチャイズのように複数の場所で営業しているビジネスに対するレビューは、そのレビューが書かれた店舗の場所においてのみ投稿できます。言い換えると、複数の場所で営業しているビジネスのレビューを、同じ経営元のほかの場所の店舗に複製したり掲載したりすることはできません。
レビューを配信するサービス提供者やコンテンツプロバイダーは、対価を支払っても支払わなくても、レビューを提供するために営利目的の契約を結んではいけません。
たくさんのビジネスに渡る、あるいは異なるソース元からの、重複したり類似したりするレビューを含めてはいけません。
あなたのサイトに直接投稿されたレビューだけを含めてください。サードパーティのサイトからのレビューや同報配信されたレビューを含めてはいけません。

わかりやすい日本語版

僕の日本語訳では意味がわかりにくいところがあったのではないでしょうか。
オリジナル自体が（僕にとっては？）わかりづらい英語で書かれていて、日本語に訳しづらい表現が多いのです。

要点を絞って、わかりやすく書き換えたのがこちらです。

純粋な顧客ではない評論家や業者によってレビューが書かれたとしたら、そういった人・業者にはお金を払っていてはいけないし、関係性があってはいけない。宣伝目的ではなく、中立な立場でのレビューでなければならない。
良いレビュー、悪いレビューのどちらも顧客は投稿できるようにする。悪いレビューだからといって検閲してはいけない。
自動生成したレビューを掲載してはいけない。
複数の店舗があるビジネスでは、レビューを掲載できるのはその場所の店舗（のサイト/ページ）だけ。たとえば、新宿・渋谷・池袋の3か所にお店があったとして、新宿店に対して書かれたレビューを渋谷店や池袋店（のサイト/ページ）に掲載することはできない。
レビューサイトは、営利目的でレビューを提供してはいけない。
同一または類似したレビューを掲載してはいけない。
構造化データでマークアップできるのは自分のサイトに投稿されたレビューだけ。たとえば、Googleや食べログに書き込まれたレビューを自分のサイトに掲載してそれをマークアップしてはいけない。

お金を払って書いてもらったレビューをマークアップしてはいけないのは当然として、レビューが批判的だから掲載しないとか、別の店舗のレビューを使いまわしするとか、レビューサイトに書かれたレビューをコピーしてそれをマークアップするとか、気を付けなければならない点がいくつもあります。

ガイドラインに違反していると、構造化データでマークアップしていてもリッチスニペットが検索結果に出なくなることがあります。
悪質な場合は手動対策の対象になるかもしれません。

あなたがローカルビジネスを営んでいてレビューの構造化データを設置しているなら、ガイドラインに沿っているか点検してください。

- Google、ローカルビジネス向けレビューの構造化データのガイドラインを更新。悪いレビューも許可すること、サードパーティサイトのレビューはマークアップ不可など -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

schema.orgがv3.1を公開、ホテルや旅館など宿泊業のサイトで使いたいプロパティを豊富に追加

投稿日時: 8月 12, 2016 投稿者: Kenichi Suzuki

[レベル: 上級]

schema.orgは、バージョン3.1を公開しました。
特に注目したいのは、ホテルや旅館など宿泊施設に関係するプロパティ（ボキャブラリ）が数多く追加されたことです。

LodgingBusiness と Accommodation に豊富なボキャブラリを追加

LodgingBusiness と Accommodation にたくさんのプロパティが新たに追加されました。

LodgingBusinessは、ホテルや旅館、ホステル、B&Bなどの宿泊施設が利用できるschema.orgのタイプです。
Accommodationは、ホテルの部屋や貸し会議室、アパート、キャンプ場の1区画（1グループが利用する範囲）などの収容施設で利用できるタイプです。

たとえば、次のようなプロパティを設定できるようになりました。

starRating ―― 五つ星、三つ星などのホテルの格付け（利用者の評価ではない）
floorSize ―― フロア面積
amenityFeature ―― 提供されているサービス（たとえばホテルにあるサウナとかジム、ビジネスセンターなどの施設）
checkinTime / checkoutTime ―― チェックイン/チェックアウトの時間
petsAllowed ―― ペット同伴が可能か

宿泊関連ビジネスのサイトで使いたい構造化データ

ホテルや民宿などのサイトではぜひ使いたい構造化データのボキャブラリがschema.orgに登場しました。
また、そういういった宿泊施設を紹介するオンラインホテル予約サイトでも活用できます。

構造化データというコンピュータが理解しやすい形式で情報を提供すれば、検索ユーザーが求めるものにより適したページだと認識してもらえる可能性が高まるでしょう。
たとえば、「4つ星以上で、ペットと泊まれて、サウナがあるホテル」とユーザーが検索したとしたら、構造化データによって条件により合致したホテルを検索エンジンは探しやすくなるかもしれません。

上で紹介したプロパティのほかにも、部屋数 (numberOfRooms) や対応可能言語 (availableLanguage) なども設定できます。
どんなプロパティがあるかを、それぞれのタイプのページで確認してください。
そして可能な限り多くのプロパティで構造化してください。

なお、LodgingBusiness / Accommodation の下にHotel（ホテル）やHostel（ホステル）、Room（部屋）、Apartment（アパート）などのサブタイプがあります。
マークアップする際は、より詳細なタイプを利用することを推奨します。

schema.org 3.1に含まれる更新の詳細はリリースノートを参照してください。

- schema.orgがv3.1を公開、ホテルや旅館など宿泊業のサイトで使いたいプロパティを豊富に追加 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

AMPカルーセルの画像サイズは幅が696px以上、縦は最小要件なし

投稿日時: 7月 22, 2016 投稿者: Kenichi Suzuki

[レベル: 上級]

Googleモバイル検索のトップニュースのAMPカルーセルに掲載されるにはその記事に画像が必須で、構造化データで指定します。
画像のサイズには要件があり、幅 (width) は 696px 以上です。
しかし高さ (height) には、最小サイズの要件はありません。

公式ドキュメントには高さの要件記載なし

トップニュースのカルーセルに必要な構造化データを説明した、Google公式のドキュメントには画像のサイズ要件が示されています。

Images should be at least 696 pixels wide.

画像の幅は最小で696ピクセルです。

ところが、幅の要件の記載はあるのですが、高さの要件の記載がありません。
高さ対しては要件は指定されていないのでしょうか？

高さの最小要件は定められていない

「高さは何でもいいのか？」という疑問に対して、GoogleのTomo T氏はヘルプフォーラムで次のように回答しています。

There is no minimum height requirement for images. As a general rule of thumb, the bigger the image provided, the better they would look in the carousel. In the spirit of AMP, it’s also important to be considerate with the img file size and format; as such, bitmaps aren’t recommended :)