海外SEO情報ブログ

Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。今週取り上げた記事は次のとおりです。

今週のピックアップ

• クロールバジェットを140文字で定義せよ & クロールバジェットを気にかけるべきか？
  

日本語で読めるSEO/SEM情報

• 検索ユーザーにも検索エンジンにも高評価される最強のコンテンツの作り方
• グーグルからAMP対応を迫るメールが送られてきた
• グーグルアナリティクスの全機能を体験できるデモアカウント、だれでも使えます
• グーグルの検索結果からレストラン予約ができる機能、登場

海外のSEO/SEM情報を日本語でピックアップ

• JavaScriptリダイレクトも移転先ページに評価は渡る
• HTTPS移行するときは、外部JSもHTTPSで読み込ませること
• グーグルがAMPエラーを検索結果で教えてくれた
• パンくずリストの構造化データに画像の指定が必要ってホント？

海外SEO情報ブログの掲載記事からピックアップ

• Google、検索アナリティクスの表示回数・掲載順位・クリック数のデータについて詳細に説明するヘルプ記事を公開
• モバイル検索結果がすべてAMPになる日が来る!? 巨大なAMP専用枠”Live Ticker”をGoogleがこの秋に導入予定
• SEOに大きな痛手か？AdWords広告予算が少ないと、キーワードプランナーで月間検索ボリュームが手に入らなくなる

SEO Japanの掲載記事からピックアップ

ピックアップなし。

こちらからどうぞ。

• クロールバジェットとは？ SEOにどう関係するの？ ウチでも注意すべき？ などSEO記事まとめ10+3本

- クロールバジェットとは？ SEOにどう関係するの？ ウチでも注意すべき？【海外＆国内SEO情報ウォッチ】 -

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

[レベル: 上級]

AMP プロジェクトは、広告をAMPで配信できるランディングページを開発しました。
AMP Ad Landing Pages、通称 ALP と呼びます。

ALPはAMPフォーマットで作られているので、広告用のランディングページを高速に表示できます。

ALPは1秒以内で表示完了

ALPを採用した広告ランディングページは、1秒かからずに表示を完了することができます。

Googleのモバイル検索からAMPページにアクセスし、そのページに掲載されている広告をタップしてALPが表示されるまでの流れが、次のアニメーションGIFで紹介されています。

このデモでは、広告バナーをタップしてからALPが表示されるまでに要した時間は0.83秒です。

ALPの高速表示を実現するために用いられる4つの技術

主に、次の4つの技術を用いてALPは高速な広告配信を実現しています。

• ランディングページへのプリコネクト
• ランディングページのプリロード
• キャッシュ配信
• リダイレクトなし

ランディングページへのプリコネクト

ALPでは、最終的に到達する実際のランディングページに対して事前に接続をリクエストしておきます。
こうすることでユーザーが広告を本当にタップしてから接続を開始するよりも、ランディングページにアクセスするまでの時間を短縮できます。

ランディングページのプリロード

ユーザーが広告をタップするよりも前に、ファーストビュー（スクロールせずに、最初の時点でスマホのディスプレイに表示される領域）の要素をリクエストしダウンロードしておきます。
CPUを消費を抑えられます。

キャッシュ配信

AMPキャッシュからランディングページを配信します。
広告を配信するサーバーではなくAMP CDNからの配信なので高速にページが返されます。

リダイレクトなし

計測を目的に、広告ではランディングページに到達するまでにリダイレクトを挟むことがあります。
可能であれば、ALPではリダイレクトを取り除き、広告からランディングページまで直接連れて行きます。amp-pixel を設定すればトラッキングは可能です。

ALPでの広告配信方法

ALPでの広告配信には次の3者が関わってきます。

広告配信者

広告を掲載するサイトは、AMP対応したページを公開し、ALPに対応した広告をそこに載せます。
たとえば、僕のブログはAMP対応しているのでALP広告を掲載できます。

広告主

広告を発行するサイトは、AMP対応したランディングページを作成します。
ここで注意するのは、通常のランディングページとそれに対応したAMPのランディングページをペアで作成することです。
つまり、通常のAMP対応と同じです。

広告配信システムがALPをサポートしている場合は、AMPページに掲載された広告をユーザーがタップするとALPを見せます。
通常のページに広告が掲載されていれば、通常のランディングページを見せます。

最終的な到達ページとして、あなたがALPを指定するわけではないのです。
ALPに着地させるか通常のランディングページに着地させるかは、広告配信システムが処理します（次で説明）。

AMPページを直接のランディングページとして構成することは可能ですが、それだと誰がどのデバイスでどんなページからいつアクセスしても、必ずそのAMP広告ページに着地することになりますね。

広告配信システム

1つ前で触れたように、広告配信システムがALPをサポートしていなければなりません。

公式アナウンスで言及されているのは、DoubleClick for Publishers (DFP) です。
DFPは次の2つの四半期をかけて（つまり年内をかけて）ALPの統合を進めていくとのことです。

検索結果からAMPページにアクセスしたときは瞬時に表示されたのに、そのページに掲載されていた広告をタップしたらなかなか表示されない。
こんな状況に出会ったら、AMPが速いぶん、よけいにストレスを感じそうです。

広告のランディングページだって速い方がいいに決まってます。
ページの表示速度がコンバージョン率に大きな影響を与えた事例は山ほどあります。

ALPでは、広告ページから元のページに戻るときもきちんと高速で表示されるように設計されています。

ALPをサポートすることがはっきりしている広告配信システムは、今のところDFPだけです。
AdSenseやAdWordsがALPをサポートし始めたら、AMP対応を始めるサイトが一気に増えるかもしれませんね。

- AMPに対応した広告用ランディングページ「ALP」、DFPが年内に配信開始予定 -

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

[レベル: 上級]

AMPプロジェクトは、第3四半期 中間のロードマップを更新しました。

ロードマップには、その期間にAMPプロジェクトが集中的に取り組む、新機能の追加や機能の改善に関する予定と進捗が示されています。

ECサイトでの利用が想定されている機能のサポートが、第3四半期のロードマップには含まれています。

ECサイトでの利用を想定したAMPの新機能

ECサイトのAMP対応の普及を目的に、新しい機能の開発に取り組むことになっています。

たとえば、次のような機能をECサイトのAMPページで利用できるようにします。

• フォーム
• サムネイル画像ギャラリー
• アクセス解析

フォーム

AMPページでフォームを使えるようにします。
<form> や <input> に相当する機能がECサイトでは必須です。
こうした機能を含むフォームに必要な仕組みを amp-form という拡張仕様によって、AMPページでも利用可能にしていきます。

• Intent to Implement: AMP Forms Support

サムネイル画像ギャラリー

ECサイトでよく使われる、サムネイル画像を並べて、1つをタップするとその拡大画像を表示する機能をAMPページでも提供します。

• Component for image attached to thumbnail carousel (amp-image-picker-carousel)

アクセス解析

ECサイトでは、ほかの業種のサイトでは取得しないような解析データが必要になってきます。
ECサイトで必要な、イベントトラッキングや商品情報の取得などECサイト向けのアクセス解析を可能にしていきます。

• amp-analytics e-commerce features

ECサイトでは、eBayが先行して試験的にAMP対応を始めています。
しかし、AMP化したのは商品一覧ページです。
コンテンツがほとんど変化せず、「カートに入れる」のようなユーザーからのアクションは発生しません。
ニュース記事と同じ、AMPと相性がいい静的なコンテンツと言えます。

そうではなく、商品詳細ページで購入ができる状態のAMPページを提供するための取り組みが本格的に始まりました。

通常の検索結果にAMP対応ページを表示する開発プレビューのモバイル検索をGoogleは先日公開しました。
プレビュー版ではなく実際の検索でのテストも始まっています。

Googleが着々とAMPサポートを拡大させるなか、AMP対応したくても必要な機能を提供できないために歯がゆく感じているサイト管理者もいることでしょう。
AMPのECサイト機能サポートをこの記事では取り上げましたが、ECサイト以外でもよく使われる機能のAMPサポートも少しずつ始まっています。

通常のスマホ向けページと同じユーザー体験をAMPページでも提供できるようになれば、AMP対応へのハードルがずいぶんと低くなります。
今後のAMPの発展に期待しましょう。

- AMPプロジェクトが第3四半期のロードマップを更新、ECサイトでのAMPサポートを目指す -

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

[レベル: 上級]

通常のモバイル検索にAMP対応したページを表示する開発プレビューをちょうど2週間前にGoogleは公開しました。
g.co/ampdemo にアクセスすることでAMP用に特別に作られた検索結果を体験できます。

しかし、本当の通常検索でAMPページを表示するテストをすでに始めているようです。

本番環境でのAMP結果

開発プレビューの検索結果では、上部にAMPを紹介するメッセージボックスが掲載されます（キャプチャは英語ですが、日本語の検索結果では日本語になります）。

しかしこちらのAMP結果にはそのメッセージが表示されていません。
なぜなら、開発プレビューではなく本当に通常の検索結果だからです。

AMPカルーセルの上、検索結果1位のAMP Projectの公式ページにAMPマークが付いています。

少し下にスクロールしても、AMPページが検索結果に出ています。

もう少し下がると Mobile-friendly（モバイル対応）ラベルのページも混ざってきました。

開発プレビューではなく、本番環境でのモバイル検索にAMPページを表示するテストに遭遇したユーザーはほかにもいます。

本番環境でのAMP検索を本当に実験しているのかどうかという質問に対して、GoogleのGary Illyes（ゲイリー・イリェーシュ）氏は次のように答えています。

僕らは常に実験やテストを行っている。きっとそういったのに出会ったのだろう。

@glenngabe @JohnMu we're experimenting and testing things all the time. You're most likely seeing that

— Gary Illyes (@methode) 2016年8月12日

僕も運良く（？）被験者に当たったのでしょう。
でもシークレットモードで立ち上げた時だったので、閉じたらもう体験できなくなりそうです。;(

ちなみに、同じ状態で日本のGoogleではAMPページは表示されず普通のモバイル検索結果でした。

一般ユーザーの反応を伺うためか？

一般ユーザーが開発プレビューの検索結果を利用するとは思えません。
AMPページを表示する検索結果を本番環境で提供することによって、普通のユーザーがどのように反応するかをGoogleは確かめようとしているのでしょう。

それにしても、僕の予想よりも早く本番に移してきました。
ともすると開発プレビューの公開と同時に実環境でもテストを始めていたのかもしれませんね。

AMP検索の年内の公開をGoogleは予定しているようですが、一般ユーザーの反応は果たしてどうなることでしょう。

- Google、開発版ではなく本番のモバイル検索でAMP結果を表示するテストを開始 -

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

[レベル: 中級]

Googleは、キーワードプランナーで提供するデータに制限をかけました。
広告費用が少ない広告主は、月間平均検索ボリュームの詳細なデータが手に入らなくなることがあります。

キーワードプランナーは本来はAdWords広告主のためのツールです。
しかし、SEOためのキーワードリサーチの目的で利用しているサイト管理者も多いはずです。
広告を出稿していないサイト管理者にとっては、この制限はたいへん残念な仕様変更になりそうです。

広告費用が少ないと検索ボリュームが（かなり）大まかに丸められる

英語版のAdWordsコミュニティでGoogle社員がキーワードプランナーの更新について次のようにアナウンスしました。

Hi AdWords Community,
 
As of this week, previous technical issues affecting the Keyword Planner tool are now resolved. Some important updates to keep in mind:
 

• Most advertisers will see search volume data in Keyword Planner as usual.
• Advertisers with lower monthly spend may see a limited data view in the Keyword Planner. For example, you may see values such as 0, 1-100, 100-1K, 1K-10K, 10K-100K, 100K-1M, 1M+ in the average monthly searches column. In addition, other advertisers may trigger the limited data view by reaching a limit on the number of searches for search volume data (specifically, requests to our API).
• Access to traffic forecast data will remain unchanged.

 
These changes will ensure that AdWords advertisers are able to get the data they need to optimize their accounts.

箇条書きの部分を訳します。

• ほとんどの広告主は検索ボリュームのデータをキーワードプランナーでいつものように見ることができます。
• 毎月の支払いが少ない広告主はキーワードプランナーで限られたデータしか見られなくなるかもしれません。たとえば、月間平均検索ボリュームの列で、値が次のようになることがあります ―― 0、1〜100、100〜1000、1000〜1万、1万〜10万、10万〜100万、100万以上。加えて、検索ボリュームデータ調査の上限数に到達したことによってデータ制限が発生する広告主も出てくるかもしれません（特に、APIを利用してのリクエスト）。
• トラフィックの予測データの利用には変更はありません。

僕たちにとって特に重要なのは強調した2つ目です。

月々支払う広告費用が少ないと、月間平均検索ボリュームが範囲の広い概算になります。

こちらは、通常のデータ表示結果です。
100または10の桁まで月間平均検索リュームが提供されます。

こちらは、制限がかかっているデータ表示結果です（入手できなかったので、Search Engine Roundtableでバリーが投稿した記事からいただきました）。

借りものなので英語のインターフェイスですが、”K”は 1,000 を意味します。
“M”は 1,000,000 を意味します。
したがって、「100K ― 1M」は「10万〜100万」になります。
「10K ― 100K」は「1万〜10万」になります。

かなりざっくりとした数値になってしまっています。

月ごとのボリューム数の推移を示す棒グラフも制限バージョンでは表示されなくなっていることにも気付いてください。

キーワードプランナーはSEOじゃなくて広告主のためのツールだけど……

キーワードのバリエーションを拾うという目的ではキーワードプランナーは依然として使えます。
しかし、どのくらいの数のユーザーがそのキーワードで検索するのかという需要調査においては非常に頼りなくなってしまいました。

月々の支払が少ない広告主には制限がかかるということは、有効な広告キャンペーンを走らせていなければ費用はゼロなので当然制限がかかります。
AdWordsを使っていないとしたら、即アウトです。

AdWordsを使っていたとしても、制限がかからない最低費用がいくらなのかは不明です。

また、基準以上の予算を消費していたとしても、APIを使って大量のクエリを投げていたとしたら制限が課せられることもあるとのことです。
ツールを利用している場合は注意が必要です。

キーワードプランナーは、（Googleの最重要な収益源になっている）AdWordsの広告主のためのツールです。
たいして出稿していない広告主やAPIでシステムに負荷をかけたりするような使い方に制限をかけるのは、大切な顧客である広告主を守るために必要な措置だとGoogleは判断したのでしょうね。

客観的に見れば納得がいく仕様変更だと僕には思えます。
とはいえ、SEOに取り組む人にとっては喜べない変更になりそうです。

ちなみに、もう5、6年もの間いっさい広告を出していない僕のAdWordsアカウントでは詳細データをまだ入手できました。
ですが、制限がかかり始めている広告主が日本でも出てきているようなので、米国だけでの話ではないはずです（日本語UIのキャプチャをください！）。
ゆっくりと適用は進んでいるのかもしれません。

- SEOに大きな痛手か？AdWords広告予算が少ないと、キーワードプランナーで月間検索ボリュームが手に入らなくなる -

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

[レベル: 上級]

Googleは、批評家が書いたレストランやカフェのレビュー記事をナレッジカードに掲載するようにしました。
批評レビュー記事を提供しているサイトは、構造化データでマークアップすることでナレッジカードに掲載される機会を得ることができます。

ナレッジパネルに掲載される批評レビュー

こちらは「restaurants seattle」（レストラン シアトル）の検索結果に出てきたローカルパックです。

3つ出てきたレストランの下に「E」のロゴとともに、短いスニペットが見えます。
これらは、”食”をテーマにしたEaterというサイトに掲載された、そのレストランが言及された記事のタイトルです。

タップするとそのレストランのナレッジカードに移動し、そのレストランを紹介している、もっと多くのレビュー記事を見ることができます。
ここでは、レストランレビューサイトのZagat（現在はGoogleが所有）のレビューが「Critic reviews」（批評レビュー）というラベルとともにトップに大きく掲載され、そのほかのレビューがその下にリストアップされています。

レビューをタップすれば、そのサイトに移動してレビュー記事の全文を読めます。

必ずしも、レストランのレビューサイトだけからとは限りません。
The GuardianやCBS Local‎のようなニュースサイトも混じっています（レビューが掲載されるサイトは後述）。

PC検索のナレッジパネルにも「Critic reviews」は出てきます。

ちょうど1年前に、映画やTV番組に対する批評家のレビュー記事を、同じように「Critic review」としてGoogleはナレッジパネルに掲載し始めました。
レストランやカフェなどのローカルビジネスにも批評家によるレビュー記事の掲載をGoogleは拡大したのです。

構造化データで批評レビューをマークアップ

あなたのサイトがレストランの批評記事を提供しているなら、Critic review向けの構造化データでマークアップすることによりナレッジカードに掲載される機会を得ることができます。

Critic reviewsに必要なschema.orgは、デベロッパーサイトに先日公開されました。

ただし、Critic reviewはまだ試験運用中です。
ZagatやEaterなど限られたパートナーサイトが参加しているにすぎません。

興味を持った場合は、専用フォームから参加をリクエストする必要があります。

ローカルビジネスの批評レビューは、今のところ米Google (google.com) の英語のレビューが対象です。
しかしほかの国と言語にもすぐに展開するとのことです。

ユーザーによって投稿されたレビューではなく、精通しているライターによって書かれたレストランのレビュー記事を掲載しているサイトは今のうちから準備に取り掛かると面白いかもしれませんね。
ナレッジカードを通じて、あなたの批評レビュー記事をさらに多くのユーザーに読んでもらえるチャンスを手にできそうです

批評レビューのナレッジカード掲載に興味を持ったならこちらのGoogle公式情報をお読みください。

• Inside Search: Never miss a “must-try” with Google Search
• Official Google Webmaster Central Blog: Promote your local businesses reviews with schema.org markup
• Reviews  |  Search  |  Google Developers

- Google、レストランのナレッジカードに批評レビュー記事を掲載。Critic reviews用のschema.orgが掲載には必要。 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by 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

[レベル: 上級]

Googleは、”Live Ticker”（ライブ ティッカー）と呼ぶ、AMP用の新しいセクションをモバイル検索結果にこの秋に導入することを計画しているようです。
“Live Ticker”は、最新ニュースを掲載するためのAMPコンテンツ専用のセクションで、トップニュースのAMPカルーセルの上に表示されます。

パブリッシャー向けの発表会のなかで明らかにしたと、Digidayが報じています。

AMPカルーセルの上に表示される巨大な Live Ticker

Digidayの記事によれば、Live Tickerとは次のような特徴を持つセクションです。

• トップニュース枠（AMPカルーセル）の上に表示される
• ウェブのさまざまなソースから集めた、非常に新しいコンテンツが対象
• AMPコンテンツだけを掲載する

記事には、プレゼンテーションでGoogleが見せたLive Tickerが掲載される検索結果のモックアップが紹介されています。

モックアップを見ると、3週間ほど前に僕がたまたま遭遇したモバイル検索結果に酷似しています。

スマホのスクリーンの下半分には、今やおなじみになったトップニュースのAMPカルーセルが表示されています。
そしてそのカルーセルの上には、ひときわ目立つ大きな1枚の”AMPカード”が表示されています。
これがLive Tickerに違いありません。

位置と大きさのため、カルーセルよりも目を引きます。（ハ◯頭の写真なのも視線を引く要因かもしれませんがw）。

発表会に参加していたパブリッシャーによると、この新しい Live Ticker は秋ごろの公開が予定されているそうです。

モバイル検索結果は、上から順にAMP、AMP、AMP？

クエリに最も関連した非常に新しいコンテンツ（プレゼンでは、”the best super-fresh content”と表現）に対して、Live Tickerが適用されるとのことです。

通常の検索結果にもAMPページを含める開発プレビューのモバイル検索をGoogleは先日公開しました。

Live TickerとAMP混在の検索が正式導入されたとすると、クエリによっては、モバイル検索結果に掲載されるコンテンツは上から順に次のようになるかもしれません。

1. AMPのLive Ticker
2. トップニュースのAMPカルーセル
3. 通常の検索結果に混ざったAMPページ

ライブ配信や写真ギャラリー、実況中継など記事以外にもサポートを予定しているAMPコンテンツも発表会では紹介されたようです。
モバイル検索結果でAMPを掲載するセクションがさらに増えることになります。

ともすると、「検索結果に表示されるすべての結果がAMP」なんてことが近い将来に実際に起こりそうです。

たとえ今の段階ではAMP対応を見送っているとしてもまったく問題ないと僕は思います。
それでも、AMPの動向にはこれからも注視していきましょう。

- モバイル検索結果がすべてAMPになる日が来る!? 巨大なAMP専用枠”Live Ticker”をGoogleがこの秋に導入予定 -

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

[レベル: 中級]

Search Consoleで提供されている検索アナリティクス レポートの表示回数と掲載順位、クリック数のデータの取得方法や見方を詳細に説明するヘルプ記事をGoogleは新規に公開しました。

• 表示回数、掲載順位、クリック数とは – Search Console ヘルプ

ウェブマスター必読のヘルプ記事

日常的に検索アナリティクスを利用するサイト管理者はもちろんのこと、たとえときどきであっても検索アナリティクスを利用するのであれば、必ず目を通しておくべきヘルプ記事です。

従来のように単に10個の青色リンクが並ぶだけの検索結果だったなら、読まなくても検索アナリティクスレポートの見方にさほど支障はないでしょう。
しかしながら、ユニバーサル結果やナレッジパネル、強調スニペット、AMPカルーセルなど現在の検索結果は多種多様です。
要素によって、表示回数とクリック数の数え方、掲載順位の割り当て方が変わってきます。

たとえば、ナレッジパネルは検索結果ページの（右側の）最上部に表示されますが、掲載順位としては11位が割り当てられることがあります。
1つのナレッジパネルには複数のリンクが含まれています。
サイト別に見るかページ別に見るかによって、リンクの表示回数の数え方が変化します。

AMPカルーセルは、カルーセル内のAMPページにはすべて同じ掲載順位が割り当てられます。
ただし、そのページの要約（サムネイル画像と記事タイトル）がカルーセルの中で表示されないと表示回数には含まれません。
ところが検索結果のカルーセルの中では表示されなかったとしても、AMPビューアの中で閲覧されれば表示されたことになり、かつクリック数も1カウントされます。

理解できるまで繰り返し読みたい

日本語ページができているので安心して読めます。
僕のブログでの一般的な解説は不要でしょう。

でも1回読んだだけでは意味を理解しづらい複雑なところあるかもしれません。
きちんと理解できたと自信が持てるまで、何度か読むことをおすすめします。

それでも説明していることがわからなかったり疑問が出てきたりしたときは、コメントかTwitter、Google+で質問してください。
わかる範囲内ですが、アドバイスできると思います。

あるいはヘルプフォーラムで質問すれば僕以外のフォーラムメンバーからも回答してもらえます。

- Google、検索アナリティクスの表示回数・掲載順位・クリック数のデータについて詳細に説明するヘルプ記事を公開 -

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

[レベル: 上級]

Googleのモバイル検索結果にAMPページが表示されるには、有効なAMP HTMLでのマークアップに加えて、schema.orgを用いた構造化データが必須でした。
しかし、今後は必須でなくなります。

通常の検索結果にもAMPページを将来的に表示することを視野に入れた変更です。

またこの変更にあわせて、Search ConsoleのAMPレポートでは構造化データ関連の問題はエラーの対象から外れました。

AMPに構造化データはもはや不要

これまでは、AMPコンテンツを検索結果に表示させるには次のいずれかのschema.orgによる構造化データが必要でした。

• schema.org/Article
• schema.org/NewsArticle
• schema.org/BlogPosting
• schema.org/VideoObject

要件指定された構造化データでマークアップすることが、トップニュース枠のAMPカルーセルに表示される条件に含まれます。

しかし、通常の検索結果にもAMP対応したページを表示する開発プレビュー版のモバイル検索をGoogleは先週公開しました。

トップニュースのAMPカルーセルはニュース系のコンテンツが掲載対象だったのに対して、通常の検索結果ではコンテンツのタイプは問われません。
結果として、構造化データは必須ではなくなりました。

開発プレビュー版が公開された直後に、GoogleのJohn Mueller（ジョン・ミューラー）氏に確認をとりました。

@suzukik @methode For AMP in the "normal" search results you don't need any special structured data markup.

— John Mueller (@JohnMu) 2016年8月2日

AMPカルーセル掲載にはこれまでどおり必要

ただし、トップニュース枠のAMPカルーセルに掲載されるには、これまでどおり構造化データが必要です。
Article や NewsArticle など、先に挙げた4つのいずれかのタイプの schema.org を実装してください。

構造化データがAMPレポートのエラー対象から外れる

ここまで説明したように、通常の検索結果に表示されるAMPページには構造化データが必須ではなくなりました。

開発プレビュー版の検索結果は試験公開が始まったばかりですが、この変更を先取りしてSearch ConsoleのAccelerated Mobile Pagesレポートでは構造化データはエラーの対象から外れました。
次の2つは「問題」として依然としてレポートされるものの、エラー数を示すグラフには含まれなくなります。

• 構造化データがありません
• 無効な構造化データ

AMPエラーレポートの8月2日（正確には8月1日）の「更新」がこの変更を示しています。
この日を境にAMPエラーが急激に減っているサイトがあるかもしれません。

このキャプチャには出ていませんが、構造化データに問題がある場合はグラフの下のリストには「情報」というラベルとともにレポートされます（「エラーではないけれど可能なら修正してね」ということですね）。
ただし先ほども書いたように、グラフには含まれません。

なお、構造化データがAMPに必須ではなくなったこととSearch ConsoleのAMPレポートでの扱いに変更があったことは、Google+とヘルプページで公式にアナウンスが出ています。

もともと構造化データは、AMPの仕様に必要だったわけではなくAMPカルーセルに掲載するためにGoogleが独自で設定した要件でした。
AMP対応するプロセスのなかに構造化データが不要になったので、実装の敷居がいくらか下がりました。

通常の検索結果にAMPページを表示させることが果たして本当にいいことなのかどうかの議論はこれから本格的に始まるとして、AMP対応が自分のサイトのメリットになるかどうかを検証するために、少しの手間をかけられるなら、これを機に思い切ってAMP化してしまうのもいいかもしれません。

- AMPに構造化データはもはや不要、Search Consoleのエラーレポートからも外れる -

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

Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。今週取り上げた記事は次のとおりです。

今週のピックアップ

• AMPがグーグルの通常の検索結果にまで拡大へ――準備はOK？
  

日本語で読めるSEO/SEM情報

• こうすればPageSpeed Insightsで100点満点を獲得できる！
• 最も厄介なスパムは、それが正しいとサイト管理者が信じてやるもの
• 「SEOに効果がある」が信じられない3つの理由
• ガイドライン違反のアフィリエイトへの対応、アダルトサイトの年齢認証とクローキングなど7月2回目のオフィスアワー

海外のSEO/SEM情報を日本語でピックアップ

>
• 販売終了ページをカテゴリページやトップページにリダイレクトするとソフト404になる!?
• いったん削除して404にしたページを復活したら評価は回復するか？
• 良いリンクを否認しても、否認ファイルから削除すれば再評価される
• HTTPS移行とCMS移行は同時に実行すべきか？
• アプリではドロップダウンを使うべきでない!? 使わないほうが操作時間40%短縮

海外SEO情報ブログの掲載記事からピックアップ

• 「301/302リダイレクトでPageRankが失われることはもうない」とGoogle社員が認める
• 低品質ページが多いからといってGoogleのアルゴリズム評価が下がるとは限らない、しかしユーザー体験の観点からは削除すべき

SEO Japanの掲載記事からピックアップ

更新がなかったのでお休み。

こちらからどうぞ。

• AMPがグーグルの通常の検索結果にまで拡大へ――準備はOK？ などSEO記事まとめ10+2本

- AMPがグーグルの通常の検索結果にまで拡大へ――準備はOK？【海外＆国内SEO情報ウォッチ】 -

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

海外SEO情報ブログの読者のみなさまへ

いつもご訪問ありがとうございます。

8月4〜5日の2日間、Google主催のTop Contributor Meetup Tokyoに参加します。
Top Contributor Meetupは、Googleの公式ヘルプフォーラムで活動しているメンバーが招待される特別イベントです。
海外ではなく日本での開催ですが期間中めいっぱい楽しんできたいので、明日とあさってのブログ更新をお休みします。

金曜日のWeb担当者Forumの連載コラムはいつもどおりお届けします。

また来週お会いしましょう！

- 【ブログ読者へご連絡】8/4〜8/5のブログ更新をお休みします -

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

[レベル: 中級]

モバイル検索の通常の検索結果で、スマホ向けページに置き換えてAMPページを表示する実験をGoogleは開始しました。
これまでは、AMPに対応したページは「トップニュース」として、通常の検索結果とは別枠のカルーセル（またはリスト）の中に掲載されていました。

AMPページとスマホ対応ページが混在

通常の検索結果にAMPページが表示される実験用の検索ページには、g.co/ampdemo からアクセスできます（スマホでアクセスしてください）。
うまくいかない場合は、こちらからアクセスしてください。

トップニュース用のAMPカルーセルではなく通常の検索結果の中にAMPページが表示されます。
（僕たちにとっては）おなじみのAMPマークが付いているのですぐにわかります。

検索結果の上には、AMPを説明するためのメッセージが表示されていますね。

こちらは、AMPページとスマホ対応ページが混在する状況がもっとわかりやすい検索結果です。

1つだけ（2つ目）が、スマホ対応で残りの3つはAMP対応です。

リッチスニペットの結果でもAMPとスマホ対応 (Mobile-friendly) が混在しています。

AMP対応ページがあるときはスマホ対応ページに置き換わる

検索結果に表示されたページにAMP対応したバージョンがあるときに、通常のスマホ対応バージョンのページに置き換わってAMP対応ページが表示されます。
つまりこの検索結果においては、AMP対応しているサイトでは通常のモバイル向けページは表示されなくなるということになります。

AMP対応していなければ、今までどおりにモバイル向けページが表示されます（モバイル対応していなければ、もちろん「スマホ対応」ラベルなしのPC向けページが表示される）。

ランキングアルゴリズムの変更ではない

注意したいのは、ランキングを決定するアルゴリズムの変更ではないという点です。

検索順位には影響しません。
そのページにAMP対応パージョンがあれば、代わりに、AMPページを優先して検索ユーザーに提示するというだけです。

AMPページを優先する理由は、単により速く表示されるページをユーザーに提供することで、ユーザー体験を向上させることが目的です。
AMPページの評価や順位を上げることが目的ではありません。

AMP対応で十分、スマホ対応は不要になる？

“early preview”（初期プレビュー）ということで、AMPを通常の検索結果に差し込むモバイル検索は実験が始まったに過ぎません。
実際に導入されるかどうかはユーザーの反応次第です。

とはいえ、いずれ導入されるだろうと個人的には思います。

ただし、解決しなければならない問題が出てくるだろうし、そのままではなくさまざまな改良がきっと加えられるでしょう。

通常の検索結果からだとしたら、AMPページにアクセスされることを望まないサイトがあるだろうことは容易に想像できます。

AMPは徹底的な高速性を追求するために、できることに制限がかかっています。
高速性を失わないようにさまざまな機能がAMPでも利用できるようにAMPプロジェクトは取り組んではいます。
しかし、今すぐに何でもできるようになるわけではありません。

AMP専用枠じゃないなら、通常のスマホ対応ページに来てもらったほうがメリットが多いと考えるサイトも必ず出てくるはずです。

またAMPページを優先表示するなら、モバイル向けページを作る必要がなくなりそうです。
Google検索のようにAMPをサポートするプラットフォームではなかったとしても、AMPページをユーザーに見せても問題はありません。
いっそのこと、これまでのモバイル向けページを完全にAMP対応ページに置き換えてしまったほうがコストも下がります。

もっとも、それはそれで良いことなのかもしれませんけどね。

いずれにしても、Googleが検索でAMPをどのように扱っていくのか、目が離せない状況は続きます。

- スマホ対応が不要になる!? Google、通常のモバイル検索結果でスマホ向けページの代わりにAMPページを表示する実験を開始 -

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

[レベル: 上級]

Googleが検索を完全にHTTPS化して以来まもなく5年がたちます。
さらにセキュリティを高めるために、www.google.comドメインで HTTP Strict Transport Security (HSTS) の実装を始めたことをGoogleはアナウンスしました。

HSTSを適用したことにより、米Google検索を含む www.google.com ドメインを利用するときの2回目以降は、たとえ http で始まるURLでアクセスしようとしたとしても、ブラウザ側で https に置き換えてアクセスするようになります。

※HSTSに詳しくなければ、Web担当者Forum連載コラムでの解説をご覧ください。このブログのHTTPS移行の際にもHSTS（とPreload HSTS）を実装しています。

www.google.com のHSTSを検証

www.google.com が本当にHSTSになっているかどうかを確かめてみました。

HTTPヘッダー

HTTPヘッダーでは、Strict Transport Security がきちんと返されています。

ちなみに、max-age が「86400」に設定されています。
単位は秒で、86,400秒は1日です。

非常に短い期間ですが、www.google.com は極めて巨大なサイトなので、移行にともなって発生するかもしれない問題を回避するためにあえてこのように短く設定しているとのことです。
今後数か月かけて、最低でも1年間の有効期間になるまで徐々に増やしていく予定です。

GoogleニュースのHTTPS移行でも、max-age を徐々に増やしていくことをGoogleはアドバイスしていましたね。

僕は最初から1年（31536000秒）でした。w

Google Chrome

Chromeのアドレスバーに「chrome://net-internals/#hsts」を打ち込むことで、ブラウザ（Chrome）が認識しているHSTSのステータスを調査することができます。

www.google.comで検索します。
「dynamic_upgrade_mode」の「STRICT」が、HSTSが適用されていることを示しています。

www.google.co.jpには（まだ？）HSTSは実装されていません。
「dynamic_upgrade_mode」は「UNKNOWN」になっています。

307リダイレクト

ブラウザがHSTSを認識している状態で、HTTPの http://www.google.com にアクセスしてみました。

307リダイレクトが返っています。

307はブラウザ内部でのリダイレクトです。
HSTSが正常に動作している証拠ですね。

GmailやYouTubeはすでにHSTSを実装しています。
Google検索のHSTS適用はむしろ遅めだったのかもしれません。
今のところは、www.google.com だけですが、いずれは www.google.co.jp はもちろんのこと世界中のGoogleに広めていくのでしょう。

常時HTTPSのサイトをあなたも運営しているなら、セキュリティをさらに高めるためにもHSTS（とPreload HSTS）の実装をお忘れなく。

- Google、www.google.comドメインにHSTSを適用。常にHTTPSで接続するように -

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

HTTPからHTTPSへの移行に際して、Googleニュースに登録しているパブリッシャーからよく尋ねられる質問とその回答を、Google+のGoogleウェブマスター公式アカウントが共有しました。

長山さんがそのうち日本語に訳してくれるように思いますが、それまでのつなぎとして代わりに僕が翻訳したものをこのブログに掲載します。

基本的には、Googleニュースに登録しているサイト向けですが、一般サイトのHTTPS移行のときにも役立つ情報も含まれています。

ではお読みください。

Googleニュース登録サイトのHTTPS移行でよくある質問

Q. HTTPSに一度に移行すべきですか？ それとも少しずつ移行すべきですか？

Q. どのくらいの期間テストを実行すべきですか？

Q. 1セクションだけから始めたとしても、サイト全体をHTTPSで利用できるように計画しています。HTTPSのコンテンツが先にインデックスされないように、リダイレクトやrel=”canonical”を使うべきですか？

Q. HTTPのサイトマップをrobots.txtで参照しています。HTTPSの新しいサイトマップを含むように更新すべきでしょうか？

Q. HTTPS化のテスト中は、HTTPSのセクションをどちらのサイトマップに記述すべきでしょうか？

Q. HTTPSバージョン用のrobots.txtに、特別に何か追加するものはありますか？

Q. 私たちのHTTPSサイトは、まだ移行していないページをHTTPにリダイレクトして戻しています。サイトマップには何を記述したらいいでしょうか？ HTTPとHTTPSの両方のURLをサイトマップに記述するのでしょうか？ テストしているセクションで、HTTPのURLがHTTPSのURLにリダイレクトしている場合はどうなるでしょうか？

Q. includeSubDomains をHSTSヘッダーに設定した場合、どのドメインに影響しますか？

A. サイト全体をHTTPSに移行したあとは、セキュリティをさらに高めるためにHSTSプリロードに対応させることができます。HSTSを有効にするためには、includeSubDomains ディレクティブをHSTSヘッダーに設定しなければなりません。

includeSubDomains が設定されたHSTSヘッダーを www.example.com のサイトが返したとしたら、次のようなドメイン名のサイトに適用されます。

• www.example.com
• foo.www.example.com

しかし、次のようなドメイン名のサイトには適用されません。

• notexample.com
• foo.example.com

ただし、HTTPに戻す際の手順をHSTSは複雑にします。次のステップを推奨します。

1. まず、HSTSなしでHTTPSを展開する。
2. 短い期間を指定した max-age でHSTSヘッダーの送信から始める。ユーザーとほかのクライアントの両方からのトラフィック、また広告などの付属要素のパフォーマンスを監視する。
3. HSTSの max-age の期間を徐々に増やしていく。

HSTSがユーザーと検索エンジンに悪い影響を与えなかったら、望むのであれば、ChromeのHSTSプリロードリストにサイトを追加するように依頼できます。

[鈴木補足: HSTSとプリロードHSTSがわからない人は、Web担当者Forumのコラムでの解説記事をお読みください。]

Q. サイト全体に対して単体のGoogleニュースサイトマップを使っています。部分的に少しずつ移行するとしたらどうしたらいいですか？

Q. HTTPSの移行に伴って、Google ニュース パブリッシャー センターでやることが推奨されるようなことは何かありますか？

以上です。

常時HTTPSへの移行を計画している人は、僕のブログのHTTPS移行時のステップ・バイ・ステップも参考にしてください。

- Googleニュース登録サイトのHTTPからHTTPSへの移行に際してよくある質問にGoogleが回答 -

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

Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。今週取り上げた記事は次のとおりです。

今週のピックアップ

• 「検索の意図はなし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化
  

日本語で読めるSEO/SEM情報

• 目立ってる？ 今度の検索結果の絵文字はパンくずリスト
• お待たせしました、AMPの公式ドキュメント日本語版も順次公開！
• App Indexingって何？ おいしいの？ という人におすすめの記事
• ヤフーが48億ドルで身売り！？

海外のSEO/SEM情報を日本語でピックアップ

• 音声検索は文字入力検索に比べてアクション系クエリが30倍多い
• 大量のURLを再クロールさせるにはlastmod付きのサイトマップが役立つ
• AMPの成功事例は今後もっと増えていきそう
• 偽のスパムレポートを競合に繰り返し送られたらどうなる？
• 外部サイトへの発リンクはランキングに悪い影響を与えるのか？

海外SEO情報ブログの掲載記事からピックアップ

• Google、AMPに完全対応した爆速表示の広告 A4A を公開
• Google、テーマパークの平均滞在時間をモバイル検索のローカルナレッジパネルに表示

SEO Japanの掲載記事からピックアップ

更新がなかったのでピックアップなし。

こちらからどうぞ。

• 「検索意図なし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化 などSEO記事まとめ10+2本

- 「検索意図なし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化【海外＆国内SEO情報ウォッチ】 -

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

高品質なページに比べて低品質なページがサイト内にたくさんあるからといって、必ずしも、サイト全体の評価が下がるわけではありません。
とはいえ、質が悪いコンテンツばかりのサイトをユーザーが気に入るはずがありません。
したがって、ユーザー体験を高めるためにも低品質なページは削除するか改善することが望まれます。

Googleはページ数だけで評価しない

英語版のオフィスアワーで参加者がこんな質問を投稿しました。

もしサイト内のページの70%が低品質で、30%が高品質だったとしたら、Googleが直接割り当てるドメインスコアが低くなって、最終的に、サイト全体のランキングに影響しますか？

GoogleのJohn Mueller（ジョン・ミューラー）氏は次のように回答します。

なんとも言えない。場合によってはそういうことがあるかもしれない。

検索検索のどの順位にそうしたURLを配置したらいいかを私たちが判断する際には、単にページの数だけではなくもっと多くのことを見ている。

たとえば、カレンダーのスクリプトをサイトに1つ設置し、それが100,000ページを自動生成していて、同時に、質が本当に高いページも5つ持っている状況を考えてみてほしい。

スクリプトで作られた実質的に中身がない100,000ページと良い5ページという理由だけで、悪いウェブサイトということにはならない。

その5ページはとても良いページだということだってありえるから、検索結果で表示したいと私たちは考えるかもしれない。特定のクエリに対して検索結果で表示するのにふさわしいかもしれないからだ。役に立つ情報を提供するかもしれないし、ユーザーの疑問を解決するかもしれない。抱えている問題を解く助けになるかもしれない。

したがってページ数だけを見るというものではない。

だが一般的に言って、サイトを見て、「粗雑なページがたくさんある、このページのコンテンツは古くて質が低い」と感じたのなら、Google側のアルゴリズムによる対処がどうであれ削除した方がいい。

ユーザーがそういうのに出くわしたなら、「この1ページだけはすばらしいけど、このサイトにある他のページは本当にひどい」と言うかもしれない。そんなことになったら、忠実なユーザーにはそのユーザーはならないだろう。もう戻ってこないだろうし、ほかの人にあなたのサイトを勧めることもないだろう。

アルゴリズムの評価が下がるとは限らないがユーザーの評価は下がる

たとえ低品質なページが大部分を占めていたとしても、高品質なページに対するアルゴリズム的な評価までもが下がるとは限らないようです。
クエリによっては、（数少ない）高品質ページが検索結果で上位表示することがありえます。

しかし、低品質なコンテンツばかりのサイトをユーザーが好きになるはずがありません。
1回訪問して、それっきりでしょう。
ブックマークしたりRSSに登録したりすることはないでしょう。

リピーターになってもらう、評判を高めるという観点からは質が低いコンテンツは存在させるべきではありません。

もっとも、質が低いコンテンツばかりのサイトは検索結果でも全体的に不利になる傾向にあるように僕は経験から感じます。
むやみにページ数を増やすのではなく、本当に質が高いコンテンツだけでサイトを作り上げたほうが全体的な評価が上がるはずです。

また可能であれば、低品質だからといって単純に削除するのではなく高品質になるように改善するほうが好ましいことを最後に付け加えておきます。

- 低品質ページが多いからといってGoogleのアルゴリズム評価が下がるとは限らない、しかしユーザー体験の観点からは削除すべき -

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

[レベル: 上級]

AMPプロジェクトは、コンテンツのライブ更新を可能にする仕組みとして <amp-live-list> のベータ版を試験公開しました。
amp-live-listを実装すると、追加のナビゲーションやページのリロードなしでコンテンツを最新の状態に動的に更新できます。

AMPページをリロードなしで即座に更新

こちらはAMPプロジェクト公式ブログのアナウンスで紹介されている amp-live-list を実装したAMPページのデモです。

“YOU HAVE UPDATES”（更新があります）という青いメッセージが画面上部に出現したあと、上にスクロールして戻ると新しいコンテンツが追加されています。

読み込んだという感覚は皆無で、AMPページの高速表示はまったく損なわれていません。

amp-live-list は刻々と状況が変化するコンテンツ向き

刻々と状況が変化するコンテンツに amp-live-list は向いています。

たとえば、イベントの内容をリアルタイムで配信するライブブログです。
執筆者が新たに書き込んだ記事を次から次へとAMPページで読むことができます。

amp-live-list は、ページのコンテンツの一部分だけに利用することが可能です。
スポーツの試合のスコアや選挙の開票状況を掲載しているページでは、ページ全体を更新する必要はありません。
スコアや開票状況の部分だけリアルタイムで更新すれば十分です。
こうしたケースでは、限定した部分のみに amp-live-list を適用することができます。

AMPは、変化しない静的なコンテンツに向いている技術なのに、ライブ更新が可能になるというのは面白い機能ですね。

バックグラウンドで、コンテンツを配信しているサーバーとクライアント（ブラウザ）が直接”ポーリング”して、コンテンツに更新があるかどうかをチェックするのだそうです。
更新があれば、更新を動的にクライアントのページに差し込みます。

しかしAMPで高速化を実現しているキャッシュシステムをスルーするわけではありません。
データ量やスマホ側の帯域幅、CPUの負担を削減するためにAMPキャッシュの機能は依然として活躍しています。

amp-live-list によるライブ更新を必要とするサイトはそう多くはなさそうな気がしますが、興味があるなら試してみるといいでしょう。

実験段階なので利用するにはオプトインする必要があります。
JavaScriptコンソールで次のコードを実行するか、もしくは専用ページからオプトインします。

AMP.toggleExperiment('amp-live-list')

そのほか、amp-live-list の詳しい仕組みと実装方法に関しては、公式アナウンスとGitHubを参照してください。

- AMPページでライブ更新を可能にする amp-live-list が試験公開される -

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

[レベル: 中級]

Googleにおいては、301リダイレクトを設定した場合、いくらかのPageRankが喪失します。
しかしこれはもう過去の話です。
現在では、301リダイレクトや302リダイレクトを含む30x系のリダイレクトでPageRankが失われることはありません。

Googleのゲイリー・イリェーシュとジョン・ミューラーがともに認める

PageRank喪失の仕様が現在は適用されないことを最初に明らかにしたのは、GoogleのGary Illyes（ゲイリー・イリェーシュ）氏です。

30x redirects don't lose PageRank anymore.

— Gary Illyes (@methode) 2016年7月26日

30xのリダイレクトがPageRankを失うことはもうない

ゲイリーのツイートが正しいことを、John Mueller（ジョン・ミューラー）氏も、昨日のオフィスアワーで認めています。

これからは安心して301/302リダイレクトを使える

301リダイレクトによるPageRankの喪失をGoogleが発生させていた大きな理由は、スパム対策です。

301を不正に利用する人たちがいます。
たとえば、301リダイレクトを繰り返して大元のサイトを隠蔽したりします。
マネーロンダリングみたいなものですね。
そうした不正利用に対処するためでした。

不正利用への別の対策が可能になったのかどうかはわかりませんが、いずれにしても現在は301リダイレクトでPageRankが失われることはありません。
喪失処理の撤廃は301リダイレクトだけではなく、302リダイレクトも307リダイレクトも含めて、300系リダイレクトすべてに当てはまります。

リダイレクトの影響で失われるPageRankはもともと微々たるものでした。
気にかける必要はまったくなかったのです。

それでもSEOを意識している人にとってはインパクトがある情報だったため、ドメイン名移転やHTTPS移行に際して301リダイレクトを使うことに強い抵抗を示す人がたくさんいます。
それしか手段がないにもかかわらずです。

ですが、もはやそういった（本当に些細な）心配をする必要はなくなりました。
これからは安心してリダイレクトを使えます。

ちなみにPageRank喪失の仕様が廃止されたのは、最近の話ではなくしばらく前からとのことです。

なお、301リダイレクトと302リダイレクトはどちらもPageRankを渡します。
「302リダイレクトはPageRankを渡さない」は必ずしも正しくありません。
301よりも302が適切だと考えるなら、302を使ってもなんら問題ありません。

301と302、307をはじめ各種リダイレクトの違いはこちらの記事を参照してください。

- 「301/302リダイレクトでPageRankが失われることはもうない」とGoogle社員が認める -

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

[レベル: 初級]

「ありがとうございます！」「参考になりました！」こういった非常に短い、ただの感想コメントはそのままにしていおいても問題ないのでしょうか？
それとも削除すべきなのでしょうか？

GoogleのJohn Mueller（ジョン・ミューラー）氏がTwitterでフォロワーからの質問に回答しました。

スパムコメントを私は削除しています。「この記事に本当にひらめきを得ました！」のような感謝系のコメントはそのままにしおくべきでしょうか？ それとも削除すべきでしょうか？

まったくあなた次第だ。私にとっては、問題ないものもあるだろうし、単にリンクを張ろうとしているものもあるだろう。

コメント管理はしっかりと

コメントはそのページのコンテンツの一部になります。
有益なコメントはほかのユーザーの役に立つことがあります。
コメントに書き込まれたことが検索にひっかかって、検索トラフィックが生じることすらあるでしょう。

とはいえ、「ありがとうございます！」「参考になりました！」のようなコメントがたくさん集まってもページの価値を上げることはなさそうです。
そうは言っても、本当に感謝の気持ちを伝えるために（人間）が書き込んでくれたのであれば、もちろん嬉しいことなのでそのままにしておいてもまったく問題ありません。

問題なのは、自動生成されたコメントやまったく関連性がないページヘのリンクを落としていくスパムコメントです。
放置しておくとそのページやサイト自体の評価が下がることがあり得ます。
その記事を読んだユーザーに不快感を与えるようなコメントは根本的に削除すべきです。

たいていのCMSは、コメント内のリンクにnofollowが自動で付く設定になっています。
しかしそれでも、リンク獲得を目的としたコメントなら削除対象にしたほうがいいでしょう。

コメントを開放しているサイトの管理者は、コメント管理も重要な仕事であることを認識しておかなければなりません。
自動承認せずに手動で承認したり、スパムコメントを弾くプラグインなどを活用できます。

コメントではありませんが、サイト管理者ではなくユーザーが生成したコンテンツが理由でGoogleから手動の対策を受けたケースが過去にあったので紹介しておきます。

• Mozilla、UGCスパムが原因でGoogleから手動ペナルティを喰らう
• 米スプリント・ネクステルがUGCスパムを理由にGoogleから警告を受ける

最後におまけを。

WordPressのコメントスパム対策プラグインといえば、Akismetが有名です。
僕はこれに加えてSiteGuard WP Pluginのコメント認証も併用しています。

SiteGuard WP Pluginの良いところは、「日本語」のキャプチャをコメント投稿時に要求することです。

自動化されたボットのコメントスパムは海外（特にロシアや中国）から来るものが大半です。
キャプチャ認証を使っていても、英数字だとくぐり抜けてしまうコメントスパムもあります。

しかし海外製なので日本語入力ができません。
つまりSiteGuard WP Pluginの日本語キャプチャをパスできないのです。

Akismetは、ほとんどのスパムコメントを検出してスパムボックスに入れてくれますが、それでもコメント自体は投稿されてしまいます。
SiteGuard WP Pluginなら投稿すら拒絶します。

SiteGuard WP Pluginを入れて以来、スパムコメントが本当に激減しました。
ほかにもセキュリティを高める機能があり、SiteGuard WP Pluginは僕のお気に入りのプラグインの1つです。

- 「ありがとうございます！」のような感謝系の1行コメントを削除すべきか？ -

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