Headless CMSを使うとSEOに弱くなる？

エンジニアリング

2019/09/26

2021/10/05

松田承一

この記事は公開後、1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

先にまとめ

サーバサイドでHeadless CMSのAPIの利用にはSEO的に気にすることは特にない（普通に対策すればOK）
クライアントサイドでHeadless CMSのAPIの利用には以前はSEO的に大きな不安があったが、今年5月ごろからGoogleクローラが進化したためデメリットの大部分はなくなった
ただしクライアントサイドでのAPI利用はSNSシェアの点で劣る場面があるため、必要に応じてサーバサイドでコンテンツを用意する必要はある

はじめに

microCMSのようなAPIをベースにしたCMSの利用するにあたって、気になることの一つにSEO（Seach Engine Optimization）があるのではないでしょうか。

より簡単に言うとGoogle検索で上位検索されるの？という疑問です。
※厳密には検索エンジンはたくさんあるためGoogleに限らない話ですが、本記事では簡単のため基本的にはGoogleにおけるSEOについて記載します。

Headless CMSの利用方針

単にHeadless CMSを使う、といってもその利用方針には大きく2つの方法があります。

サーバサイドでHeadless CMSのAPIを利用する
クライアントサイドからHeadless CMSのAPIを利用する

ほかにも静的サイトジェネレーターを使ってビルド時のみAPIを呼び出し配信するのはただの静的ファイル、という構成もあります。
この場合は配信されるのはごく普通のHTML/CSS/JavaScriptであり当然SEO対策は非常にしやすいため、今回の方針からは外しました。

サーバサイドからAPIを利用する場合のSEO

サーバサイドからAPIを呼び出す場合はサーバサイドプロセス（RubyやNode、PHP、Goなど）でHeadless CMSのAPIから値を取得し、テンプレートエンジンなどを使ってHTMLページを構築します。

SEOの観点ではこの構成はどうでしょうか？
さきに結論を述べるとSEO対策がとてもしやすい構成です。

そもそも検索エンジンってどういう仕組み？

Search Engine Optimization、つまり検索エンジン最適化は名前の通り検索エンジンに向けた取り組みです。

それでは、検索エンジンはどのように動いているのでしょうか？
Googleが公式にページを用意しているのでぜひ一度は目を通しておきましょう。

簡単に説明しましょう。
Googleは「クローラ」というプログラムを常に走らせています。
このクローラはリンクなどを辿りながら大量のページに実際にアクセスを行い、そこに記載された内容やリンクされている数などのたくさんの指標を使って総合的にサイトの評価を行います。

ここで問題になるのはブラウザ上でJavaScriptを実行してコンテンツを動的に変更している場合です。
これまでのクローラは基本的にはこのJavaScriptによるページ内容の変更に弱く、JavaScriptによる変更のうち一部の内容のみが評価対象となっている可能性がありました。
※2019年9月時点の最新情報は後述します

それでは、ここまでを理解したうえでサーバサイドでHeadless CMSを利用した場合を考えてみましょう。

サーバサイドでAPIを呼び出して値をテンプレートに埋め込むような構成のサービスの場合、クローラが最初にアクセスした時点で全ての情報が揃います。
そのため静的なクローラから見るとHTMLファイルを置いているようなシンプルな構成と同じく、クローラから非常に読み取りやすい内容を提供できています。

これがサーバサイドでHeadless CMSを利用する場合のSEO対策がとてもしやすいという理由です。

クライアントサイドからAPIを利用する場合のSEO

それではクライアントサイドからAPIを利用する場合を考えてみましょう。

最近のフロントエンド開発ではReactやVueなどを使ったSPA（Single Page Application）を選択するケースが非常に増えています。
SPAとHeadless CMSは非常に相性が良く、開発がしやすいのですがSEOの観点ではどうでしょうか？

実は今年2019年5月のGoogle I/O（Googleの公式カンファレンス）で大きな発表がなされました。
https://webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html

つまりGoogleのクローラがページにアクセスした時にChromeと全く同じ仕組みでページ内容を解釈することができるようになった、という発表です。
これによって以前は不安のあったJavaScriptによるページ内容の更新も、Googleクローラはほぼ完璧に把握可能となったのです。

これは開発やメンテナンス工数の観点でも非常に大きな変更です。
今まではSEOへの対策上必要だったサーバサイドプロセスが必要なくなり、シンプルなHTML/CSS/JavaScriptのページをS3やGithub Pagesで配信するだけでもSEO的には不利にならないためです。

ただし一点注意があります。
ページにアクセスして内容を読み取るシンプルなクローラ動作と、JavaScriptの実行は別プロセスで行われます。
そのためサーバサイドでページ内容を用意する場合に比べ、検索エンジンに認識されるまでに時間がかかる場合があるようです。
English Google Webmaster Central office-hours hangout

この注意点さえ除けば、これまではSEO的に不利だったクライアントサイドからHeadless CMSのAPIを呼ぶ方式でもSEOの観点では特にデメリットはなくなったと見て良いでしょう。

クライアントサイドの場合の注意点

ここまででGoogleクローラを対象にしたSEOについては大きな問題がなくなってきた、という説明してきました。
しかしSPAなどクライアントサイドメインのページを作成する場合、SEO以外の観点で大きな問題が残ります。

それはFacebookやTwitterなど、JavaScriptによるページ変更を読み込まないクローラを持つSNSです。

FacebookやTwitterなどにシェアを行う場合、これらのSNSは対象のURLにアクセスし以下のようなmeta情報を読み取ってその内容を表示します。

<meta property="og:title" content="サイトのタイトル">
<meta property="og:image" content="content="https://www.example.com/sns_share_image.png">

JavaScriptでこれらの値を設定するとFacebookやTwitterのクローラはその値を読み取ることができず、SNS側にデフォルトのページタイトルや画像しか表示されません。
これではページ内容をうまく伝えることができず、せっかくユーザにページをシェアしてもらっても効果は半減してしまいます。

※具体的なシェア内容は以下の内容で確認することができます

これに対する解決策はmeta要素については何らかの形でサーバサイドで用意することです。
せっかくクライアントサイドでAPIを利用するシンプルな構成にしたのにも関わらず、サーバサイドプロセスを用意するのははっきり言って手間のかかる作業ですね...。

この点に関しては大変多くの開発者が困っていることもあり、Googleと同様にFacebookやTwitterのクローラがJavaScriptを解釈することが非常に待たれます。
FacebookやTwitterの動向を注視していきましょう。

以上です。