Facebookも表示が早いWebページをニュースフィードで優先すると発表!【SEO記事12本まとめ】
グーグルの検索結果に続いてFacebookも、さくさく表示されないWebページのフィードにおける表示優先度を下げると発表した。あなたのページは大丈夫だろうか。
ほかにも、「構造化データでよくある15の間違い」「301リダイレクトはいつまで続けるべき?」「モバイル画像検索結果にバッジ表示開始」や、「SEO担当者よ、JavaScriptを学べ」「7年前のグーグルSEO情報でも役に立つ?」「wwwの有無どちらが良いか」といった情報もまとめてお届けする。
今週のピックアップ
Facebookも表示が早いWebページをニュースフィードで優先すると発表!
素早く表示されるサイトを好むのは当然 (Facebook Newsroom) 海外情報
フェイスブックは、モバイルアプリのニュースフィードに掲載する記事の優先度に、表示速度を考慮するアルゴリズムを導入することを発表した。
素早く表示されるページはニュースフィードにより表示されやすくなり、表示に時間がかかるページはニュースフィードに掲載されにくくなる。
この変更は、数か月をかけて徐々に展開していくとのことだ。
時間計測は、フェイスブックのモバイルアプリでニュースフィードからクリックされたリンクに対して行われ、評価にはモバイルネットワークの接続状況や他のページの表示速度なども勘案される。
グーグルが表示速度をランキングアルゴリズムに取り入れているのは、ご存知のとおりだ。Webページがすばやく表示されることを期待しているのは、グーグルユーザーだけではなくフェイスブックユーザーも同じということだ(もっと言えば、すべてのインターネットユーザーがスピードを求めているに違いない)。
ただし、「大変だ! これからは表示速度だ!」と大騒ぎするのはちょっと違う。というのも、劇的な変化は起こらないだろうことを、フェイスブックは次のように明確に示しているからだ。グーグルと同じように、本当に本当に表示が遅いのでない限りは、大きな悪影響は受けないだろう。
ほとんどのページではニュースフィードへの出現に大きな違いは出ないだろう。特に表示に時間がかかるWebページはニュースフィードからのトラフィックは減るかもしれない。
もしかしたら、「Facebook表示速度マーケティング」などを大声で強調する人が出てくるかもしれないが、そうした声に流されないようにしてほしい。
もちろん、そうしたことに関係なく、良いユーザー体験を提供するために表示のスピードアップに重点を置くことには、大賛成だ。ぜひ進めてほしい。
- FBでプロモーションしているすべてのWeb担当者 必見!
テクニカルSEO情報
グーグル向け構造化データでよくある15の間違い――手動対策の原因にも!
「知らなかった」が原因で手動対策を受けないように (Google Developers) 海外情報
構造化データの手動対策に関する情報が、構造化データを解説するグーグルの開発者向けサイトに追加された。
手動対策の理由にもなってしまう、構造化データにありがちな間違いが説明されているので、紹介する。
すべての構造化データに共通
構造化データ内の情報が、ユーザーが見えるテキストとして表示されていないのはダメ。
たとえば、構造化データにはレビューの星(★)があるのに、ページ内に情報として存在しない状態を考えてみてほしい。検索結果に出ていた「★」に興味をもって訪問したユーザーは、ページのどこを探してもレビューの「★」関連の情報がなければ、困惑してしまうだろう。
商品やレビューの構造化データで起きやすい間違いだ。
イベント
イベントの構造化データがマークアップされているのに、目に見えるイベント関連コンテンツがページに存在しないのはダメ。
マークアップ内のテキストや説明が、プロモーションや販売を目的としたものになってしまっていて、イベントの説明ではなくなっているのはダメ。
求人
求人のマークアップが使われているのに、ページには求人コンテンツがないのはダメ。
求人に応募する方法が書かれていないのはダメ。
求人のマークアップが表示されている説明と一致していないのはダメ。
応募に支払いを要求したり、偽の求人に見えたりするのはダメ。
誤解を招くような求人の説明はダメ。
リストアイテム
どんな種類であろうと、構造化データの情報を割り当てる際に、リスト(筆者注: カテゴリと考えていい)を単体のアイテムのように扱ってはいけない。
実際には中身はリストなのに、単独の「レビュー」や「場所」として扱われるようマークアップするのは正しくない。そうではなく、リストに含まれる各アイテムの個々の属性に割り当てる。
たとえば「マドリードのホテル」「サマードレス」「ケーキのレシピ」などを1つのアイテムのように構造化マークアップで扱ってはいけない。
商品
商品の名前は次のようでなければならない
商品自体の名前であること。製造者や販売者の名前になっているのはダメ。
実際の名前であること。説明になっているのはダメ
- ×不適切な例: 「Androidスマホ」「Nexusスマホ」「売れ筋No. 1のNexusスマホ」
- ○適切な例: 「Nexus 6P」
商品のレビュー
商品のレビューが、そのサイトの管理者や商品を販売している人によって書かれているのはダメ。
レビューは、「購入者」「関係者ではない人」「金銭の授受がない人」によって書かれていなければならない。
ユーザーがレビュー投稿する仕組みがないのにレビューが掲載されているのはダメ。
レビュー
ページにあるすべてのアイテムの平均がレビューの評価として与えられているのはダメ。レビューの評価は、個別のアイテムが対象になっていなければならない。
レシピ
レシピのページではないのにレシピのマークアップが使われているのはダメ。
- 構造化データを利用している人だけ
何年たったら301リダイレクトを解除できるのか?
解除できません (John Mueller on Twitter) 海外情報
ドメイン名移転やサイト構造変更などで、既存のリンク資産を失わないためにリダイレクトを設定することがあるだろう。このリダイレクトは、どれぐらい残しておかなければいけないのだろうか。
グーグルのジョン・ミューラー氏にツイッターのフォロワーが次のように質問した。
たとえば設定して1年経つ301リダイレクトが解除されたり失効したりしたら、転送元ページから転送先ページへの評価の受け渡しをグーグルはストップしますか?
ミューラー氏は次のように答えた。
リダイレクトを解除したら、それはもう恒久的なリダイレクトではなくなる。通常はある時点で、別々のURLだと私たちは解釈し始めるだろう。
これは、たびたび出てくる質問だ。
SEO観点では「リダイレクトは永久に設定しておくもの」だと考えるのが、原則だ。
旧URLから新URLへの評価の引き継ぎは、リダイレクトが有効な間だけしか処理されない。たとえ10年間リダイレクトしていたとしても、リダイレクトをなくしたら、グーグルはそれ以降の再クロールでリダイレクトがなくなったことを把握し、リダイレクトによる評価の引き継ぎはいずれ消滅すると考えるべきだ。
以前のURLの評価を引き継がなくても十分に評価が高まったり、古いURLにアクセスするユーザーがいなくなったりして、リダイレクトの必要性がほぼ完全になくなったのでない限りは、リダイレクト設定は永遠に継続しておくことを強く推奨する。
- すべてのWeb担当者 必見!
- インフラ担当者にも周知しましょう
iOS向けとAndroid向けのページはリダイレクトで振り分けないほうがいい
ユーザーに委ねる (Webmaster Central Help Forum) 海外情報
ちょっと変わった質問が、英語版ヘルプフォーラムに投稿された。
コンテンツはほとんど同じですが、iOS向けとAndroid向けに別々のページを用意しています。振り分けには、302リダイレクトを使っています。
ただ、Googlebotには異なるコンテンツを見せたくないので、Googlebotはリダイレクトしないほうがいいのかとも思うのですが、わかりません。
ジョン・ミューラー氏は次のようにアドバイスした。
なかなかいい質問だ。
本質的には、国や言語による振り分け設定と同じことが言える(たとえば、フランス語を設定しているブラウザはフランス語ページにリダイレクトする設定)。すべてのユーザー(と検索エンジン)がすべてのバージョンのページにアクセスするのを許可することが、私たちの推奨だ。
間違ったバージョンのページに来てしまったと思われるユーザーには、適切に表示されるバージョンのページがあることを示す小さなバナーを見せるといい。たとえば、こんなメッセージを表示するんだ。
Androidをお使いのようです。ここをクリックするとこのページのAndroid版を見ることができます。
また、ユーザーが再訪問したときに最適なページを自動的に見せるためにCookieを使う方法もある。理想的なのは、「常にAndroid版ページを表示する」のようなチェックボックスでユーザーに選択させることだ。
Cookieが設定されていたら自動的にリダイレクトするのは、問題ない(クローラーは通常はCookieを保持しないから検索には影響を与えない)。
こうすれば、iOS版とAndroid版の両方がインデックスされるし、ユーザーが自分の意志で適切なバージョンのページを見ることが可能になる。
ブラウザ設定を日本語にしているすべてのユーザーが日本語ページを見たがっているとは限らない。また、日本からアクセスしたからといってすべてのユーザーが日本語ページを見たがっているとは限らない。
同様に、iPhoneユーザーだからといってすべてのユーザーがiOS向けページを見たいとは限らないだろう。そう考えれば、強制的なリダイレクトは適切ではない。
とはいえ、iOS端末ならiOS向けページを、Android端末ならAndroid向けページを最初から見せることは、言語や国とは異なり、自然なようにも筆者には思える。しかしそれでも、ユーザーに選択を委ねるのは悪いことではない。
それにGooglebotのクロールを考えると、ユーザーエージェントによるリダイレクトは慎重に扱いたい。iOSとAndroidで振り分けると、モバイルGooglebotはユーザーエージェントに「Android」を含むので、iOS向けページをクロールできなくなるだろう。
- SEOがんばってる人用(ふつうの人は気にしなくていい)
すべてのSEO担当者に告ぐ、「JSを学びなさい」
JSチームにはSEOを教えてあげる (John Mueller on Twitter) 海外情報
ウェブはすでにシンプルなHTMLの時代から脱却している。SEOに取り組む身として、あなたはその事実をもう受け入れていることだろう。
JavaScriptの開発者から学び、SEOの知識を彼らと共有しよう。JavaScriptがなくなることはないのだから。
こんなメッセージを、ジョン・ミューラー氏がツイートしていた。
The web has moved from plain HTML - as an SEO you can embrace that. Learn from JS devs & share SEO knowledge with them. JS's not going away.
— John ☆.o(≧▽≦)o.☆ (@JohnMu) 2017年8月8日
ミューラー氏が言うように、HTMLだけで構成された純粋な静的サイトはもはや存在しないだろう。特にJavaScriptはどんなサイトでも当然のように使われている。
アクセス解析もJavaScriptで動くものが大半だし、ソーシャルボタンもJavaScriptでできている。メニューなどでちょっとした使いやすいインターフェイスを実現するのにもJavaScriptは使われているし、PWAの機能をフルに使うのであればJavaScriptの知識は必須だ。
ということは、SEO担当者としてはJavaScriptを避けるわけにはいかないし、開発チーム側が「グーグルSEOと相性がいいJavaScriptサイト」を理解していなければ問題が起きてしまう。
JavaScriptを用いている開発チームとSEOチームの相互協力は、特に規模が大きなサイトでは間違いなく重要になっているし、今後さらにその重要度は高まっていくだろう。
昔のように「SEOのために、できるだけJavaScriptは使わない」なんてことを言っていられる時代ではないのだ。
- すべてのWeb担当者 必見!
- 技術がわかる人に伝えましょう
PWA vs.ネイティブアプリは対立軸にはならない
SafariのSWサポートでウェブの可能性が広がる (Eiji Kitamura on ツイッター) 国内情報
グーグルはPWAをプッシュしているのだが、iPhone人気が高い日本では、iOSのPWA非対応がネックになっている。
というのも、iOSのSafariでは、PWAに必須と言っていいService Workerという仕組みをサポートしていないため、PWA特有の機能を利用できないのだ(iOSでは、ChromeほかすべてのブラウザでService Workerをサポートできていない)。
ところが、SafariがService Workerをサポートする可能性が高まってきた(正確に言えば、Safariが使用しているHTMLレンダリングエンジンのWebKitだが)。このことに言及した記事に対するコメントを見たグーグルの北村氏が、次のようなツイートを連続投稿した(北村氏はグーグルで、PWAなどモバイルウェブをはじめとした開発技術を広める職務に就いている)。
ブコメが想像以上にネガティブでビックリ。PWAという言葉に踊らされず、単にウェブの可能性が広がったと理解してほしいです。既存サイトに必要最小限の機能を追加するだけでも構わないんですよ。 / “やばい、iOSにネイティブアプリ要ら…” https://t.co/0KJvpNeqsy
— Eiji Kitamura (@agektmr) 2017年8月8日
分かりやすい例で言えば、既存のサイトでも、manifestファイルひとつをサーバーに置いて、HTMLに参照するタグを追加するだけで、ホーム画面から起動する時の体験がグッと良くなったり(一日あればできる)https://t.co/kypRxcT4uY
— Eiji Kitamura (@agektmr) 2017年8月8日
Workboxを使えば、Service Workerの詳細を意識せずに、繰り返し使うリソースをキャッシュしてロード時間を早くしたりもできるしhttps://t.co/IMMSzg4Vsi
— Eiji Kitamura (@agektmr) 2017年8月8日
プッシュ通知を簡単に導入できるウェブサービスも結構あるみたいだし。
— Eiji Kitamura (@agektmr) 2017年8月8日
ウェブからのトラフィックが馬鹿にならないくらい多いサービス、例えばプッシュ通知を送るためだけにアプリをインストールさせてるニュースサービスやeコマースサービスは、PWAを検討する価値はあるんじゃないかと思いますよ。
— Eiji Kitamura (@agektmr) 2017年8月8日
SafariがService Workerを本当にサポートして、SafariでPWAが稼働するようになったとしても、それは決してネイティブアプリの終わりを意味するわけではない。
そもそも、「モバイルウェブ(PWA) vs. ネイティブアプリ」の対立軸で語られる問題ではない。双方にメリット・デメリット、向き・不向きがある。自社ビジネスに照らして、ふさわしいほうを選べばいい。PWAを採用するにしても、必要な機能のみを実装するだけでも価値がある。
もちろん、PWAとアプリの両方を採用することだってできる。むしろ両方できるのはすばらしいことだ。
いずれにせよ、iOSでPWAを利用できるようになるのならば、それはすばらしいことだ。楽しみに待ちたい。
- SEOがんばってる人用(ふつうの人は気にしなくていい)
- 技術がわかる人に伝えましょう
ソーシャルもやってます!