ヘッドレスCMSのSEO：注意すべき点

公開: 2020-11-30

目次

基本的に、ヘッドレスCMSのSEOは、従来のCMSと同じルールに従います。 そのため、クロール可能性、速度、およびコンテンツ品質は、それに取り組みたいときの目標のままです。 達成すべき目標は似ていますが、ヘッドレスCMSではこれらの目標を達成するための手段が異なります。

ヘッドレスCMSでのSEOの違い

ヘッドレスCMSでは、プロセス全体を簡単にするプラグインやアドオンが通常ないため、ほとんどのSEO作業は手動で行う必要があります。これは、作業が増え、プロセスで学ぶことが増えることを意味します。サードパーティのツールに依存しています。 さらに、現在ほとんどのヘッドレスCMSおよびフロントエンドフレームワークはJavaScriptベースであるため、このような環境のSEOは、クローラーがJavaScriptを簡単にレンダリングできないという性質により、複雑になる可能性があります。

GooglebotはJavaScriptをレンダリングできますが、それに依存したくありません。

Martin Splitt、動的レンダリングの実装について
推奨読書：ヘッドレスCMSと従来のCMS

ヘッドレスCMSで注意すべきこと

代替テキスト

代替テキストは、画像コンテンツをGoogleボットが読み取れるようにするのに役立ちます。 カスタムメタデータと同様に、画像の代替テキストはほとんどのヘッドレスCMSですぐに使用できる機能ではないため、CMSプロバイダーが実装する必要があります。

Alt Text機能が組み込まれていないヘッドレスCMSの場合、画像に<alt>属性を追加するだけでよいため、画像ごとにaltテキストを手動で追加できます。 

 <img src = "image.png" alt="私たちの代替テキスト">

メタデータ

メタデータタグは、Google検索が理解できる特別なタグです。 これらのタグは、サイトのコンテンツを説明し、Google検索でのページの表示方法を制御するのに役立ちます。 また、従来のCMSとは異なり、ヘッドレスCMSには通常、メタデータタグをその場で編集する機能がありません。つまり、ページのタイトル、説明、その他のメタタグをコンテンツモデルに手動で追加する必要があります。

たとえば、 Reactベースのフロントエンドを備えているがカスタムメタデータをサポートしていないヘッドレスWebサイトの場合、react-helmetを使用してメタデータを<head>に簡単に追加します。

カスタムメタデータをサポートするヘッドレスCMSの場合、通常、カスタムメタデータタグを含むフィールドをコンテンツモデルに追加するか、必要なすべてのメタタグを含むカスタムSEOモデルを作成する必要があります。 作成されたSEOモデルは、それを必要とするすべてのページとの関係を持つように構成する必要があります。

GraphCMSのSEOモデル
GraphCMSのSEOモデル

構造化データスニペット

構造化データスニペットは、Google検索がページとその中のすべてのコンテンツをよりよく理解するのに役立ちます。 有効な構造化データスニペットを提供することにより、サイトは豊富な結果を得る資格があります。

構造化データスニペットを作成するには、サイトの<head>に保存されているJSON-LD配列を使用します。 また、プロセス全体がプラグイン（Yoast SEOなど）で自動化される従来のCMSとは異なり、ヘッドレスCMSでは次のことを行う必要があります。

  • ページに適した構造化データ型を選択してください
  • 必要なすべての構造化データを生成するか、サーバー側でレンダリングされた構造化データに情報を追加するのに役立つカスタムJavaScriptコードを追加します
 fetch（'https://api.example.com/recipes/123'）
.then（response => response.text（））
.then（structuredDataText => {
  const script = document.createElement（'script'）;
  script.setAttribute（'type'、'application / ld + json'）;
  script.textContent = structureDataText;
  document.head.appendChild（script）;
}）;
  • リッチリザルトテストを使用して実装をテストします

ページビュー追跡の問題

ヘッドレスウェブサイトにGoogleAnalyticsを実装しようとしたことがあれば、ウェブサイトの最初のページビューのみが追跡されていることに気付いたでしょう。 これは主に、ヘッドレスCMSのフロントエンドが本質的にシングルページアプリケーションであるという事実によるものです。つまり、ページは1回だけ読み込まれ、セッションごとに1つのpageViewイベントのみがトリガーされます。 この問題を回避するために、History APIを実装して仮想ページビューを有効にし、Googleタグマネージャーの履歴変更トリガーを使用して追跡できるようにします。

履歴変更トリガー

履歴変更トリガーは、URLフラグメントまたは履歴状態オブジェクトの変更を追跡します。 これら2つの間で変更が発生すると、次の変数があります。

  • 履歴古いURLフラグメント： URLフラグメントが以前は何であったか。
  • 履歴新しいURLフラグメント：現在のURLフラグメントは何ですか。
  • 履歴の古い状態：サイトのpushStateの呼び出しによって制御される古い履歴状態オブジェクト。
  • 履歴の新しい状態： pushStateへのサイトの呼び出しによって制御される新しい履歴状態オブジェクト。

履歴変更トリガーを作成するには、Googleタグマネージャーに移動して次の操作を行います。

  • [トリガー] >[新規]を選択します
  • [トリガー構成] >[履歴変更]を選択します
トリガータイプを選択

この後、次のように、作成したばかりの履歴変更トリガーで起動する新しいGoogleアナリティクス構成タグを作成する必要があります。

GoogleAnalytics構成タグ

以上です。 これで、ヘッドレスWebサイトのページビューを追跡できるようになります。

SEO監査の問題

ヘッドレスWebサイトは主にクライアント側のJavaScriptで作成されているため、ほとんどの無料のSEO監査ツールで使用されるクローラーにはJavaScriptをレンダリングする機能がないため、SEO監査が問題になる可能性があります。

JavaScriptレンダリングは、ほとんどのSEO監査ツールの無料機能ではありません
JavaScriptレンダリングは、ほとんどのSEO監査ツールの無料機能ではありません

この問題は、次のプレミアムプランにアップグレードしてこの機能のサポートを有効にできるため、追加料金を支払うことで解決できると予想されます。 また、ほとんどのSEO監査ツールではJavaScriptレンダリングがデフォルトで有効になっていないことに注意してください。つまり、ヘッドレスWebサイトをクロールするにはJavaScriptレンダリングを手動で有効にする必要があります。

ScreamingFrogでJavaScriptレンダリングを有効にする
ScreamingFrogでJavaScriptレンダリングを有効にする

コード分​​割

一般的なヘッドレスCMSはJavaScriptベースであるため、Webサイトで使用されるJavaScriptコードの量は、特に多数のサードパーティライブラリを使用する場合に、圧倒される可能性があります。

JavaScriptの起動時間が長すぎる
出典：コード分割でJavaScriptペイロードを削減

そして、ご存知のとおり、ページ速度はSEOに影響を与えるため、JavaScriptコードをこのように維持することはできません。そのため、この問題を回避するためにコード分割が行われます。 コード分​​割を使用すると、JSコードを小さなバンドルに分割して、実行時に動的にロードできます。 この機能は現在、factor-bundleを介してWebpackやBrowserifyなどのバンドラーによってサポートされています。 

 'react'からReact、{Suspense、lazy}をインポートします。
import {BrowserRouter as Router、Route、Switch} from'react-router-dom';

const Home = lazy（（）=> import（'./ routers / Home'））;
const About = lazy（（）=> import（'./routes/About'））;

const App =（）=>（
  <ルーター>
    <サスペンスフォールバック={<div>読み込み中...</div>}>
      <スイッチ>
        <ルートの正確なパス="/"コンポーネント={ホーム}/>
        <Route path = "/ about" component = {About} />
      </ Switch>
    </サスペンス>
  </ルーター>
）;

動的レンダリング

ヘッドレスWebサイトの大部分は本質的にJavaScriptであるため、JavaScriptレンダリングと同じ主要なSEOの課題に直面しています。

[…]、JavaScriptを処理することは困難であり、すべての検索エンジンクローラーがJavaScriptを正常にまたはすぐに処理できるわけではありません。

動的レンダリングの実装、Google

クローラーはJavaScriptを効果的にレンダリングできないため、Google自身が当面の回避策として動的レンダリングを提案しているのはなぜですか。 Google I / O '18で導入された動的レンダリングは、クライアント側のレンダリングに伴うすべての利点を維持しながら、SEOの課題を簡単に解決する方法を必要とするJavaScriptベースのWebサイトにとって理想的なソリューションです。 この新しいレンダリング方法を使用すると、Webサーバーは通常のクライアント側でレンダリングされたコンテンツをユーザーに送信し、検索エンジンのクローラーは完全にサーバーでレンダリングされた静的なHTMLコンテンツを取得します。

動的レンダリングのしくみ
動的レンダリングのしくみ（簡略化）

これが意味するのは、動的レンダリングで両方の長所を活用できるということです。つまり、サーバー側レンダリングのクロールのしやすさと、クライアント側レンダリングの後続の高速レンダリングです。

動的レンダリングを実装するには、RendertronやPuppeteerなどの動的レンダラーに依存してプロセス全体を短縮する必要があります。 これらのレンダリングは、サイトのコンテンツをクローラーが理解できる静的HTMLに変換します。

ダイナミックレンダラーのインストールと構成が完了したら、Googleの公式ドキュメントの追加手順に従って、ユーザーエージェントの動作を構成します。

結論

ヘッドレスCMSのSEOは最も簡単な方法ではなく、すべてを正しく行うには開発者の少しの作業が必要になります。 しかし、一度コツをつかめば、ヘッドレスCMSは、SEOに関しては従来のCMSと同じくらい効果的です。 さらに、コンテンツを思いどおりに作成するための自由度と柔軟性が大幅に向上します。