
インタースティシャルがあるページは11月1日以降、検索で評価が下がる!? などSEO記事まとめ10+4本

ページにアクセスしようとしたら全画面で広告――そんな「インタースティシャル」があるページの評価がモバイル検索で下がるようになる話題が、今週のピックアップ。ほかにもSEOの競合調査、インデックス登録ページ減少、URL削除ツールの正しい使い方、モバイル対応などなど、SEOの話題をまとめてお届けする。
- 今週のピックアップ [1]
- 日本語で読めるSEO/SEM情報 [2]
- 海外SEO情報ブログの掲載記事から [3]
- 海外のSEO/SEM情報を日本語で [4]
- SEO Japanの掲載記事から [5]
インタースティシャルがあるページは11月1日以降、検索で評価が下がる!? [6]
まずはアプリDLインタースティシャルが対象 (グーグル ウェブマスター向け公式ブログ)
インタースティシャル [8]が、モバイルフレンドリーの要因に追加された。もちろん、モバイルフレンドリーではないと判断されるマイナス要因としてだ。
検索結果からアクセスしたページのコンテンツの大部分がインタースティシャルで覆われている場合、そのページはモバイルフレンドリーだとはみなされなくなる。
モバイルフレンドリーテストツールとSearch Consoleのモバイルユーザビリティレポートは、全面のインタースティシャルを通知するようにすでに更新されている
現時点のモバイルフレンドリーテストツールではインタースティシャルがあってもモバイルフレンドリーだと表示されるが、11月1日以降はモバイルフレンドリーではないと評価される。つまり、全面インタースティシャルのページはモバイル検索結果で順位が下がる可能性があるのだ。
ただし、今回の変更はアプリのダウンロードを宣伝するインタースティシャルだけに適用される。それ以外のインタースティシャルには影響しない。またアプリダウンロードのインタースティシャルであっても、スクリーンの一部に表示されるのであれば問題視されない。
現在、アプリダウンロードの全面インタースティシャルを設定しているなら、OSに応じて次のいずれかの仕組みに置き換えることで危機を回避できる。
- スマートバナー [10](Safari向け)
- ネイティブ アプリ インストール バナー [11](Chrome向け)
グーグルが公開しているモバイルガイドの「よくあるミスを回避する」セクションにも、インタースティシャルの項目 [12]が追加されている。こちらもよく読んでおきたい。
インタースティシャルをモバイルフレンドリーの要因にグーグルが組み込むことは、このコーナーの読者であればわかりきっていたことだ。はっきりしなかったのは、いつになるかだけであった。
今のところはアプリダウンロードのインタースティシャルだけが対象だが、そのほかのタイプのインタースティシャルにいずれ範囲を拡大することがあっても不思議ではない。
日本語で読めるSEO/SEM情報
検索アナリティクスで999件の制限を超えてデータを調べる方法 [13]
APIを使えば5000個までは取得可能 (グーグル ウェブマスター向けヘルプフォーラム)
旧ウェブマスターツールの「検索クエリ」では情報を全件CSVでダウンロードできたが、新しい「検索アナリティクス」では999件までしかダウンロードできない。検索アナリティクスで999件の制限を超えてデータを入手する方法はないのだろうか。
Google Search Consoleの「検索クエリ」は、その機能を拡張した「検索アナリティクス [14]」の正式版が公開されたあとも、3か月は提供を続けることをグーグルは約束していた。約束の期間が過ぎ、検索クエリへのリンクの表示を撤去した。
URLに直接アクセス [15]すれば依然として「検索クエリ」を利用することは可能だ。だが遅かれ早かれ完全に廃止するのではないだろうか。
新しい検索アナリティクスは検索クエリと比べると非常に優秀なツールなのだが、1つ難点がある。ダウンロードできるデータが999件までに限定されていることだ。これでは、規模が大きいサイトでは十分なデータを得ることができない。
上限を上げる方法はないだろうかという質問が公式ヘルプフォーラムに投稿された。
Search Consoleの検索アナリティクスを直接使っている限りはどうにもならない。しかし、グーグルが先日公開した検索アナリティクスAPI [16]を使えば、最大5000までは取得できるとのことだ。
プログラミングのスキルが必要だが、1000個以上のクエリデータを手に入れる必要があるならば、APIを利用したツールを作成するといい。
ツールなんて役立たず、本当の競合調査はこの4ステップで完璧 [17]
検索結果を自分の目で見て調べる (ブログマーケッターJUNICHI)
世間でよく知られているSEOツールを利用しても本当の競合調査には役立たない
このようにキッパリと言い切った [18]うえで、どうすれば本当の競合調査ができるのかを説明した記事。
競合調査においてもっとも重要なのは、ツールが算出するデータを比較することではなく、次の2つを調べることだという。
- 検索ユーザーの質問の意図
- 検索ユーザーに提供したら喜ばれるであろう答え
そして、コンテンツに着目した競合調査を4つのステップに分解して説明している。
狙いたいキーワードでグーグル検索する
検索上位のコンテンツの情報をメモする
ユーザーの質問の意図と知りたいことをリスト化する
検索ユーザーに提供すべき情報をユーザーが理解しやすい順番に並べ替える
競合調査におけるツールの利用が100%無意味だとは、筆者は思わない。それでも、ここで説明されている競合調査の方法が有用であることも、また確かなことだと思う。応用してみてはいかがだろうか。
日本語版ウェブマスター向けオフィスアワー 9月版 [19]
インタースティシャルの話もあり (ウェブマスター オフィスアワー on Google+)
グーグル日本のサーチクオリティチームが主催するウェブマスター向けオフィスアワーの9月版が開催された。
今回交わされたQ&Aの一部は次のとおり。
- GooglebotのIPアドレス
- JSON-LDを使ったリッチスニペット
- 画像の利用に対するグーグルの評価
- 検索アナリティクスの取得クエリ数
- Fetch as Googleの「インデックスに送信」の上限数
- サイトマップへの画像URLの記載
Q&Aに先立って冒頭では、インタースティシャルの件についてもグーグル社員が説明しているので視聴しておこう。
グーグルマイビジネスにログインしないとグーグルマップから消えるかも [20]
ローカルビジネスオーナーは要注意 (Inside AdWords Japan)
グーグル マイビジネス [21]に定期的にログインし、登録情報に変更がないかどうかを確かめるようにと、グーグルが促した。グーグル マイビジネスに登録した住所や電話番号、写真などのビジネス情報は、ウェブ検索やグーグルマップの検索結果に利用されることがある。
過去1年間にログインしなかったビジネスオーナーには、ログインして登録情報を確認するように依頼するメールを送信することがあるそうだ。
ここまでは、「ああそうなのね」と軽く流してしまう内容に響くかもしれない。
注意したいのは、以下で筆者が強調した部分だ。
メールを受け取ったら
このようなメールを受信した場合、本文に記されたステップに沿って Google マイビジネス ダッシュボードにログインのうえ、必要に応じて情報の修正をお願いいたします。Google から通知が送信されてからもアカウントにログインいただけない場合、アカウント認証が取り消されたり、Google マップから情報が削除される可能性があります。
大切なビジネス情報が検索結果に表示されなくなってしまうかもしれない。ローカルビジネスにとっては、検索結果に表示されるあなたのビジネス情報は重要だ。検索トラフィックはもちろんのこと、あなたのビジネスの認知度・信頼度にも影響するかもしれない。
グーグルマイビジネスに登録しているならば、忘れずに定期的にログインしよう。
[23]海外SEO情報ブログの
掲載記事からピックアップ
nofollow属性とFetch as Googleに関する記事を今週はピックアップ。
- nofollowリンクがたくさんあっても問題ないが、自発的なリンクにはnofollowを付ける必要なし [24]
必要な場面で利用すればいい - Fetch as Googleは長いページを最後までレンダリングできない [25]
サイズ制限あり
- Search Consoleでインデックス登録ページ数が突然減少! 何があったのか
- URL削除ツールにできるのは一時的にインデックスから削除することだけ
- 「今すぐモバイル対応せよ、しかも完璧に」グーグル社員が発言
- グローバルサイトでのIP振り分けは301? 302?
- App Indexingの上級者向けTIPS
- 検索エンジンの最適化から、検索体験の最適化へ。
- SEOにおける新たな領域。あなたのアプリを見つけてもらおう。
- 今週のピックアップ [1]
- 日本語で読めるSEO/SEM情報 [2]
- 海外SEO情報ブログの掲載記事から [3]
- 海外のSEO/SEM情報を日本語で [4]
- SEO Japanの掲載記事から [5]
海外のSEO/SEM情報を日本語でピックアップ
Search Consoleでインデックス登録ページ数が突然減少! 何があったのか [26]
減って増えて (Search Engine Roundtable)
8月23日前後に、Search Consoleのインデックスステータスで「インデックスに登録されたページの総数」が突然減るという現象が、いくつものサイトで報告されていた。日本のヘルプフォーラム [27]でも不安になったサイト管理者 [28]が何人か質問を投稿 [29]している。
Search Engine Roundtableのバリー・シュワルツ氏がグーグルに問い合わせたところ、次のような回答を得たとのことである。
この変更は、グーグルが何ページをインデックスしているかの概算をより正確に反映したものです。
表示が以前よりも正確になったということで、実際のインデックスが減少したわけではなさそうだ。心配いらないだろう……と思いたいところだが、不可思議な現象がその後発生している。
インデックスが減ったのち、再び元の水準に戻っているサイトがあるのだ。
いったいどれが正確なのだろうか? この件に関してのグーグルからのコメントは得られていないようだ。
URL削除ツールにできるのは一時的にインデックスから削除することだけ [31]
永久的な削除を目的としていない (Forum d'aide pour les webmasters)
URL削除ツールを使用する際の注意点を、グーグル社員のジネブさんが公式ヘルプフォーラムで説明した。
URL削除ツールはそのページをインデックスから完全に消去するわけでありません。検索結果から一時的に非表示にするだけです。
まず一時的に非表示にしておいて、その間に、サイト管理者がそのページをサーバーから実際に削除して404または410のHTTPステータスコードを返すように設定するという意図です。
グーグルは、削除申請から90日後に再度そのページを調査します。もしそのページが200のHTTPステータスコードを返していれば、インデックスに再び登録します。404か410を返していれば、永久にインデックスから削除します。
ページに正常にアクセスできる状態(200番のHTTPステータスコードを返す状態)であっても、Search Consoleのサイト管理者なら、URL削除ツールを使えばそのページを検索結果から削除できる。
しかしジネブさんが言うように、これは一時的な処置だ。そのままでは90日が過ぎたあとに再びクロールされてインデックスされ、検索結果に出てくることがありうる。
あるページが検索で表示されないようにするには、URL削除ツールを使うだけでなく、実際にサーバー上のページを削除し404または410を返さなければならない。もしくは、noindex robots metaタグを記述するかだ。
robots.txtでクローラをブロックするのも悪くないが、robots.txtだけでは検索結果にリンクが表示されることがある [32]ため、やはり削除するかnoindexを指定するのがいいだろう。
「今すぐモバイル対応せよ、しかも完璧に」グーグル社員が発言 [33]
HTTPSとは違ってこっちは同意できるはず (John Mueller on Google+)
グーグルのジョン・ミューラー氏が、モバイル対応の必要性を力説した。
グーグルがいつもモバイルのことばかり話しているのを聞き飽きたかもしれない。だからというわけではないが、「モバイルインターネット」という考え方から離れるべきなのかもしれないと考えている。
数字を見れば、モバイルからのインターネット利用は、いまや特別なことではなく、あらゆるジャンルで行われている。モバイル利用がすでにPC利用を超えている分野もあるし、ほとんどすべての分野が近い将来にそうなるだろう。
もし、いろいろなものごとがモバイルですばらしく機能するようになるのを待っていたなら、もう目を覚まして行動し始める必要がある。待っていてはダメだ。
あなたのサイトで提供しているモバイルウェブの体験が、あまり良くない(それどころか、ユーザー視点でみるとひどい)のならば、サイト運営にあたっての優先事項をもう一度考え直したほうがいい。
ほとんどのケースにおいて、モバイルユーザーがもっと増えるまで待つのはウェブサイトが時代遅れになるのを待つのと同じことだ。あなたのサイトの利用データに現れないモバイルユーザーは、もう何か別のものを使い始めているのだから。
ようするにミューラー氏は、「様子を伺いながらではなく、今すぐにモバイル対応せよ。それも中途半端にではなく完璧に」と言いたいのであろう。
HTTPSを猛烈にプッシュしたゲイリー・イリーズ氏 [34]による先日の発言とは違って、こちらは筆者も100%同意できる。
グローバルサイトでのIP振り分けは301? 302? [35]
302リダイレクトを使う (John Mueller on Twitter)
グローバルサイトにおいて、アクセスしてきたユーザーのIPアドレスから判断される所在地に基づいて自動的に適切な国向けのページに振り分ける場合のリダイレクトについて、グーグルのジョン・ミューラー氏がツイッターでフォロワーからの質問に答えた。
(フォロワー)国のIPアドレスでユーザーをリダイレクトするときは、301と302のどちらがいいですか? グーグルがこの方法を使っているのを知っていますが、私の場合に理想的なのはどちらでしょうか。
(ミューラー氏)googlewebmastercentral.blogspot.ch/2014/05/creating-right-homepage-for-your.htmlを調べてみたところ、302という言及がある。
@zivelbaz [36] I'd check out http://t.co/uN3O2dgDX1 [37] - it has tips on that + mentions the 302.
— John Mueller (@JohnMu) 2015, 8月 26 [35]
ミューラー氏が参照したのは、海外のユーザーに適したホームページの作成を解説した公式ブログの記事 [38](リンクは同記事の日本語版)。次のように説明している。
(前略)ユーザーの地域や言語設定に応じて、適切な HTML コンテンツを自動的に配信します。このシナリオの実装は、サーバー サイドで 302 リダイレクトを使用する(後略)
注意深く読んでいないと見過ごしてしまいそうだ。グローバルサイトを運用するなら知っておこう。
App Indexingの上級者向けTIPS [39]
コマンドラインからログ取得 (Jarek Wilkiewicz on Google+)
App Indexingの開発にたずさわっている、ジャレク・ウィルキビチ氏が、App Indexingのデバッグ方法をGoogle+でシェアした。
Android Debug Bridge [40]という、コマンドラインで利用するデバッグツールを使うと、App Indexing APIをコールしたときに送られるデータのログを取得できる。
adb shell setprop log.tag.AppIndexApi VERBOSE
adb logcat -v time -s AppIndexApi:V
Android Debug Bridgeではほかにも、ディープリンクが正しく機能しているかどうかを調べることもできる。
App Indexingを実装するときにアプリ開発者に教えてやるといいだろう。詳しいことは開発者向けドキュメント [41](英語)を参照してほしい。
[42]SEO Japanの
掲載記事からピックアップ
Search Experience Optimization(検索体験最適化)について語った記事とSEOにおけるアプリの役割の記事を今週はピックアップ。
- 検索エンジンの最適化から、検索体験の最適化へ。 [43]
SEOとユーザー体験は密接な関係 - SEOにおける新たな領域。あなたのアプリを見つけてもらおう。 [44]
これからはアプリもSEOに必須になりそう
ソーシャルもやってます!