hikoharu's blog

エンジニアリング、プロダクトについて考えていること。twitter: @hikoharu06

React,Vue..どのFW使おうかなー 〜それSEO考慮しなくて大丈夫?〜

これは何?

とある新規のWebサービスを開発することになり、フレームワークを選ぶことに 「React使おうかな、Vue使おうかな、Angularはちょっと古いかな」とか色々考えていたら、作るサービスがKPIはMAU,Googleでの自然検索流入がメッチャ重要、SEO意識しないとダメということに気づき、これはエンジニアリング的な目線だけで決めてはマズいのでは?と思い調べてみた

そもそもの疑問

Googleがサイトをクローリングして検索のインデックスが作られて、自然検索に引っかかる訳だが、このクローリングはHTML要素をチェックしているはず。その時に

  • 操作によってHTML内のDOMがサーバーからのレスポンスによって動的に切り替わる場合:初期表示されていないものをクローリング対象にできないよね?
  • Reactとかだと、そもそもHTML単体だとほとんど情報がなくて、全部jsで差し込むけど大丈夫か?

というのがそもそもの疑問

クローラーとjsについて調べてみた

Googleクローラー(GoogleBot)がサイトを巡回して、キーワードを解釈してインデックスにしていることでGoogleで検索可能にしている。

Q.GoogleBotはjavascriptを認識できるのかどうか

A.できる どうやらGoogleが2015年くらいに公式で「JavaScriptで動的に表示されるコンテンツのインデックスはされない」という発表をしたらしく、それが広まってしまっているのが色々な認識齟齬の原因。 現在はGoogleBotがJavaScriptを実行してその結果を見ている。 この改善が公式発表されているわけでなく、GoogleのJohn Muellerさんが2016年くらいにtwitterでさりげなくつぶやいている。カジュアルか

https://twitter.com/GiceOne/status/804332185130008576?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fpromonista.com%2Fevaluation-of-javascript%2F&tfw_creator=Prmnista&tfw_site=Prmnista

Q.じゃあ何も気にしなくてもいいのか

A.いいえ 確かにGoogleBotはjavascriptを認識してくれるものの、

  • jsが正しく実行されるか
  • ページ内をもれなく操作してインデックスしてくれるか

を考慮する必要があります。

jsが正しく実行されるか

GoogleBotはページにアクセスしてレンダリングするが、ChromeIEの違いがあるようにブラウザによってjsの処理、パフォーマンスは微妙に変わってくる。 2018年現在GoogleBotのブラウザはChrome41(2015年1月リリース)を使っていると公式が発表しており、かなり古い これにより、意図しない部分でjsエラーが起きる。または処理が異常に遅くなりタイムアウトする可能性がある。

ページ内をもれなく操作してインデックスしてくれるか

GoogleBotはサイトのFirstViewにアクセスしてから、サイト内を操作して、FirstView以外のページの情報を取得している。この時にこちらが意図した通りに全ページを見てくれるかを考慮する必要がある

SSR(サーバーサイドレンダリング)とは

GoogleBotはjsは実行してくれるけど、正しく実行されない可能性がある。。。という問題に対して、現状よく使われているのがSSRです。 解決策としてはAPとは別でレンダリングサーバーを用意して、そこでjsが実行されたhtmlをキャッシュ、リクエストが来た場合はそれを返すというもの イメージは下記

スクリーンショット 2018-04-11 18.14.30.png

なおSEO的な意味とは別に、jsが事前に実行されているので純粋に初期描画が速くなるというメリットもある

なおSSR以外の解決策としてPrerenderingというものもある これはサーバーの中にヘッドレスブラウザ(Phantom.jsとかが有名)を用意しておいて、リクエストが来たら、ヘッドレスブラウザでレンダリング処理を行って、htmlを返すというもの。 どうやら、あまりメジャーではないよう SSRに比べて、導入も運用も低コストでいいと思うが、厳密には違うもののリクエスト投げてからブラウザ描画するのを2回やるオーバーヘッドを気にするのが理由かなと

SSRはいいことづくめ?

SSRには否定的意見も結構多い。ほとんどが

  • 費用対効果が悪すぎる:SEOと初期描画高速化に効果があることは間違いないが、それにしても導入、保守が大変だし。開発効率も大幅に落ちる
  • そもそも解決が本質的ではない:速度に関しては別の効果的な打ち手もあるし、SEO対策にしてもGoogleBotが更新されていけば改善されるのでは?なおかつなんか時代に逆行している気がする(歪なキメラという表現がされている)

というところに収束する 最近はNuxt.jsといったSSR専用のフレームワークとかも出てきているので、それで改善されるか?

結論

SPAにするかどうか、フロントエンドフレームワーク何使うかはSEO的には色々回避策あるので、それほど気にしなくてもいい。 ただ対応に尋常でないコストがかかる or 開発後期に見つかってアーキテクチャー変わると悲惨なので、こまめにGoogleBotにどう見られているのか確認する

このFetch as Googleを使うと簡単にチェックできるらしい https://support.google.com/webmasters/answer/6066468?hl=ja

一通り調べてみたものの、ぶっちゃけこれからやっていく段階で多分いろいろ試行錯誤しそう このあたり知見ある方いれば、ぜひご意見いただきたいです。

備考

SEO以外にも、近年のSNSの盛り上がりを経てOGP(Open Graph Protocol)対応も重要。 Facebookが始めた概念で、urlをSNSとかに書き込むと、概要が表示されるあれのこと

スクリーンショット 2018-04-11 18.51.00.png

このOGPもGoogleBotと同様にjavascriptの動作が通常のブラウザと違うという問題があり、SSRを含めて、対応が必要。これについては直近使う予定がないので、また必要になったら調べて書きます。

後日談

この記事を社内で共有したところ、いろいろ反響いただき結論としては SSRは導入、保守にとてつもない労力がかかるというのと、その労力をかけてまでSPAで表現する必要があるんだっけ? ということから、よほどの必要性がない限りはSSRに踏み切らないほうがいい(サービス全部をSPA前提にしないほうがいい)という結論に収束しつつあります。 ただサービスの中で部分的にSPAにするのは全然ありなので、サービスをデザインする時には初期段階で

  • どの部分をSPAで表現するか
  • そこはSEO的にクローリングされなくても問題ない部分か

ということを考慮すると、フレームワーク選定、リリース後にくる「こんなはずでは」を防げるのではと思いました。