日本語 English(Home)

CMSとSEO:選ぶときに確かめる機能と、ヘッドレスCMSで注意する点

CMSで決まるのは、titleやcanonical、リダイレクトをページごとに設定できるかという土台です。選ぶときのチェック表、インストール型・サービス型・ヘッドレスの違い、描画方式の確かめ方、移行の手順を、Googleの説明と当サイトの例で示します。

CMSとSEO:選ぶときに確かめる機能と、ヘッドレスCMSで注意する点

この記事の要点:

  • CMS(ウェブサイトの更新管理システム)で決まるのは、title・canonical・noindex・リダイレクト・サイトマップなどを「ページごとに設定できるか」という土台です。順位を決める記事の中身は、どの CMS でも書き手しだいです。
  • Google は、CMS を使っていればタイトルの技術的な作業は不要で、適切なタイトルを書くことに集中するよう説明しています。「SEO に強い CMS」を探すより、必要な設定ができるかを表で確かめるほうが確実です。
  • ヘッドレス CMS や JavaScript で表示を組み立てる構成では、最初の HTML に本文・リンク・title が入っているかを確かめます。Google は、サーバーサイド レンダリングや静的なレンダリングでの解決を勧めています。
  • CMS を入れ替えて URL が変わる場合は、旧 URL と新 URL の対応表、301 リダイレクト、内部リンクとサイトマップの更新を同時に行います。

CMSとSEO:CMSで決まることと、記事の中身で決まること

CMS(Content Management System)とは、HTML を直接書かなくても、管理画面からページの作成・更新・公開ができる仕組みです。WordPress のようにサーバーに入れて使うもの、サービスとして提供されるもの、表示の部分を持たないヘッドレス CMS などがあります。

SEO の観点で CMS が決めるのは、検索エンジンに正しく届けるための「設定のしやすさ」です。ページごとに title を書けるか、検索に出したくないページを noindex にできるか、URL を変えたときに 301 リダイレクトを設定できるか、といった点は CMS の機能に左右されます。

一方で、検索結果で選ばれるかどうかは、記事が読者の問いに答えているか、信頼できる根拠があるかで決まります。Google の SEO スターター ガイドは、title について「CMS を使用している場合は、タイトルに関して行う必要のある技術的な作業はないので、適切なタイトルを書くことに集中してください。ほとんどの CMS では、タイトルを自動的に HTML の <title> 要素に設定します」と説明しています(SEO スターター ガイド、2026年10月13日確認)。

CMS の機能で決まることCMS では決まらないこと
title・メタディスクリプションをページごとに書けるかtitle に何を書くか、読者の問いに答えているか
URL の形(パーマリンク)を決められるか、変えたときに転送できるか記事の内容が正確で、出典が示されているか
canonical・noindex・サイトマップを管理できるかどのテーマで記事を書き、どの語で検索されたいか
表示速度の土台(画像の処理・キャッシュ・不要なスクリプト)著者・運営者の情報、経験や一次情報の有無

CMS 選びは、検索に必要な設定ができない状態を避けるためのもの、と考えると判断がぶれません。WordPress を使う場合の具体的な設定は「WordPressのSEO対策」で説明しています。

SEOで確かめるCMSの機能:チェック表

CMS を選ぶときは、次の項目が「ページごとに」設定できるか、設定した内容が公開ページの HTML にそのまま出るかを確かめます。サイト全体で 1 つしか決められない項目があると、ページの種類が増えたときに困ります。

項目確かめることできないと起きること
titleページごとに書けるか。サイト名の付け方を決められるか全ページが同じ題名になり、検索結果で区別できない
メタディスクリプションページごとに書けるか検索結果の説明文を自分で用意できない
URL(スラッグ)英数字の短い URL を付けられるか。階層を決められるかID 番号だけの URL になり、内容が伝わらない
301 リダイレクト旧 URL から新 URL への恒久的な転送を設定できるかURL を変えたときに旧 URL が 404 になる
canonical各ページで正規 URL を出力するか。手で変えられるか同じ内容の URL が複数あるときに、どれを検索に出すか示せない
noindexページごとに検索に出さない設定ができるか中身の少ない一覧や検索結果のページが検索に出る
項目確かめることできないと起きること
XML サイトマップ自動で作られ、公開・削除に合わせて更新されるか。noindex のページを除けるか新しいページが見つかりにくい
構造化データ記事・パンくずなどの構造化データを出せるか。種類を変えられるかリッチリザルトの対象にならない
画像の alt画像ごとに代替テキストを入れられるか画像の内容が検索エンジンと読み上げの利用者に伝わらない
パンくずリスト階層に沿って自動で出せるか読者と検索エンジンにページの位置が伝わりにくい
見出し本文で h2・h3 を使い分けられるか。テーマが h1 を 1 つだけ出すか見出しの構造が崩れる
表示速度画像の縮小・次世代形式・遅延読み込み・キャッシュに対応するかモバイルで表示が遅くなる
多言語言語ごとの URL と hreflang を出せるか(必要な場合)言語の違うページが正しく対応づけられない

サイトマップについて、Google の「サイトマップの作成と送信」は「ほとんどのコンテンツ管理システム(CMS)で自動的にサイトマップが生成される」と説明しています(2026年7月13日更新、2026年10月13日確認)。自動で作られる場合も、noindex のページや転送されるページが載っていないかは確かめます。

機能の一覧に「SEO 対応」と書かれていても、中身は製品ごとに違います。デモ環境や試用版で記事を 1 本作り、公開ページのソースを開いて <title>、name="description"、rel="canonical"、name="robots" の行が意図どおりに出ているかを確かめるのが確実です。

CMSの種類ごとの違い:インストール型・サービス型・ヘッドレス

CMS は大きく、サーバーに入れて使うインストール型、提供会社のサーバーで動くサービス型(SaaS)、表示の部分を持たず内容だけを配信するヘッドレス型に分けられます。SEO で確かめる点は種類ごとに少しずつ違います。特定の製品の良し悪しではなく、種類ごとの傾向として整理します。

種類仕組みSEO で確かめること運用で注意すること
インストール型(例:WordPress)自社で用意したサーバーに入れて使う。テーマとプラグインで機能を足すテーマとプラグインで title・構造化データなどが二重に出ていないか本体・テーマ・プラグインの更新とバックアップを自社で行う
サービス型(SaaS)提供会社のサーバーで動き、管理画面から使うリダイレクト・canonical・robots.txt・サイトマップを自分で変えられる範囲提供会社の仕様変更や契約の終了時に、URL とデータを持ち出せるか
ヘッドレス内容を API で配信し、表示は別のフロントエンドで作る最初の HTML に本文・リンク・title が入っているか(描画方式)メタ情報・サイトマップ・リダイレクトをフロントエンド側で作る必要がある

インストール型は設定の自由度が高い分、機能を足しすぎて同じタグが二重に出ることがあります。サービス型は手間が少ない分、提供されていない設定は変えられません。ヘッドレス型は表示の自由度が高い分、SEO に必要な出力を自分たちで作る範囲が広がります。

ヘッドレスCMSで注意すること:描画方式

ヘッドレス CMS や JavaScript でページを組み立てる構成では、検索エンジンが最初に受け取る HTML に、本文・内部リンク・title・canonical が入っているかを確かめます。Google は JavaScript を実行してページを表示できますが、Google の説明では、JavaScript を使うページを「クロール」「レンダリング」「インデックス登録」の 3 つのフェーズで処理し、レンダリングの前にキューで待つことがあります(JavaScript SEO の基本を理解する、2026年3月5日更新、2026年10月13日確認)。

同じページで Google は、「bot によっては JavaScript を実行できないものもあるため、サーバー側でのレンダリング(プリ レンダリング)も有効な方法として検討してみてください」と説明しています。また、ダイナミック レンダリング(クローラーにだけ別に描画した HTML を返す方法)については、「回避策であり」、「サーバーサイド レンダリング、静的なレンダリング、ハイドレーションのいずれかで解決することをおすすめします」としています(回避策としてのダイナミック レンダリング、2025年12月18日更新、2026年10月13日確認)。

描画方式最初の HTML確かめること
静的生成(SSG)公開前に作った完成済みの HTML記事の更新・削除のたびに作り直されるか
サーバーサイド レンダリング(SSR)リクエストごとにサーバーで組み立てた HTML表示速度と、エラー時に正しいステータスコードを返すか
クライアントサイド レンダリング(CSR)ほぼ空の HTML。ブラウザの JavaScript で中身を作る本文・リンク・title が JavaScript 実行後にしか無い状態になっていないか。存在しないページで 404 を返せるか

確かめ方は、ページのソース(JavaScript を実行する前の HTML)に本文が含まれているかを見ることと、Search Console の URL 検査で Google が取得した HTML とスクリーンショットを見ることです。描画方式ごとの詳しい違いとよくある問題は「JavaScript SEOとは」で説明しています。

AI 検索との関係では、Google は「AI 機能とウェブサイト」で、AI による概要や AI モードに表示されるための追加の要件は無いとしたうえで、SEO の基本として「重要なコンテンツはテキスト形式で提示します」「クロールが robots.txt に加え、CDN またはホスティング インフラストラクチャで許可されていることを確認します」を挙げています。CMS やその前段の配信の仕組み(CDN)の設定でクローラーを止めていないかも、選ぶときの確認項目に入れます。

CMSを移行するときのSEOの手順

CMS を入れ替えて URL が変わる場合は、旧 URL を新 URL へ 1 対 1 で 301 リダイレクトし、内部リンクとサイトマップを同時に新しい URL に直します。Google 検索セントラルは、URL の変更を伴うサイト移転について、旧 URL と新 URL の対応づけ、サーバー側の永続的なリダイレクト(301・308)、内部リンクの更新、新しいサイトマップの送信を挙げ、リダイレクトを「できるだけ長く保持します(一般的には 1 年以上)」と説明しています(URL の変更を伴うサイト移転、2026年9月11日更新、2026年10月13日確認)。

  1. 今の URL を全部書き出す:XML サイトマップ、Search Console の「ページ」、アクセス解析のページ一覧を合わせ、外部からリンクされている URL も含める
  2. 旧 URL と新 URL の対応表を作る:URL を変えずに済むページは変えない。変えるページは 1 対 1 の転送先を決め、すべてをトップページへ送らない
  3. 新しい CMS で設定を再現する:title・説明文・canonical・noindex・構造化データ・画像の alt が引き継がれているかを、チェック表で確かめる
  4. 301 リダイレクトを設定する:転送が 2 回以上続かないようにする
  5. 内部リンク・canonical・サイトマップを新しい URL に直す:Search Console で新しいサイトマップを送る
  6. 公開後に確かめる:旧 URL の転送、robots.txt と noindex の残り、Search Console のページの登録状況を見る

Google は同じページで、サイトの大きな変更のあとは再クロールの間に順位が変動することがあり、中規模のサイトでは新しい URL が表示され始めるまでに数週間以上かかることがあると説明しています。CMS の移行は、順位が一時的に動くことを前提に、時期と確認の担当者を決めて進めます。

当サイトの例:WordPressでの構成と自動の点検

当サイト(seoagent.jp)は、レンタルサーバー(エックスサーバー)上の WordPress で、独自のテーマ、SEO プラグインの Rank Math、多言語プラグインの Polylang を使っています。設定は管理画面で手で変えるのではなく、リポジトリの設定スクリプトから反映しています。

CMS の機能でできることと、テーマやプラグインの組み合わせで起きた問題の両方があります。当サイトでは、次の問題を見つけて直しました。

起きていたこと原因行ったこと
記事一覧の canonical が、存在しない URL(/ja/blog/ja/)を指していた多言語プラグインとの組み合わせcanonical をページ自身の URL に直す処理を追加
SEO プラグインのサイトマップが古いキャッシュのまま、4 件しか載っていなかったサイトマップのキャッシュキャッシュを作り直し、反映のたびに作り直すようにした
記事の構造化データの型が空で、投稿者の欄に管理者のユーザー名が出ていたテーマとプラグインの初期設定型を BlogPosting に変え、著者を運営組織にした
GA4 の計測の設定が 2 つのプラグインにあった機能の重なり1 つのプラグインにまとめた

また、日本語版を /ja/ の下に置いていた構成を、2026年10月11日に日本語版をトップ / に置く構成へ変えたときは、/ja/ で始まる URL を対応するページへ 1 対 1 で 301 転送し、記事内のリンクも新しい URL に直しました。反映のたびに、転送と全ページの canonical が新しい URL を指していることを確かめています。

公開ページは、自動の点検スクリプトでも確かめています。2026年10月13日の点検(222 ページ)では、ステータスコードの異常、内部リンクのリンク切れ、h1 の数の異常、タイトルの重複、alt の無い画像、どこからもリンクされていないページはいずれも 0 件でした。点検している項目は次のとおりで、CMS を選ぶときのチェック表とほぼ重なります。

  • 検索エンジンに届くか:ステータスコード、サイトマップに載っている noindex のページ、canonical が自分の URL と違うページ、サイトマップに無いページ、robots.txt
  • ページの中身:h1 の数、見出しの階層の飛び、title と説明文の長さと重複、alt の無い画像、og:image、本文の文字数
  • サイト全体:内部リンク先のステータスと転送、どこからもリンクされていないページ、日英のページの対応(hreflang)

点検のやり方はSEOチェックのやり方で紹介しています。

運用面の確認:投稿・予約・外部連携

CMS は、公開した後の運用のしやすさも SEO に影響します。記事を書き足す・直す・統合するたびに作業が重いと、古い情報のまま残る記事が増えるためです。選ぶときは、次の点も確かめます。

確かめること理由
予約公開と、公開済み記事の更新ができるか計画どおりに公開し、内容が古くなった記事をすぐ直せる
更新日を正しく出力するか読者と検索エンジンに、いつ確かめた情報かを伝えられる
権限を分けられるか(書き手・確認者・公開者)公開前に事実と出典を確かめる手順を挟める
外部のツールから投稿できるか(API など)記事の作成・点検の道具と、公開の作業をつなげられる
記事と画像のデータを書き出せるか将来 CMS を変えるときに、内容と URL を引き継げる

外部のツールから投稿する場合は、サーバー側の設定でその接続が届くかも確かめます。当サイトでは、レンタルサーバーの国外からのアクセス制限により、国外からの WordPress の REST API への接続が 403 で断られる状態を確認しています。CMS の機能が対応していても、サーバーやセキュリティの設定で外部連携が止まることがあるため、実際に投稿する環境で試してから運用を決めます。REST API とアプリケーションパスワードで投稿する手順と、つまずく原因は「WordPressの自動投稿の手順」で説明しています。

CMSとSEOと関わるテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。

よくある質問

SEOに強いCMSはどれですか?

特定の CMS を使うだけで順位が上がる、という Google の説明はありません。Google は、CMS を使っていればタイトルの技術的な作業は不要で、内容を書くことに集中するよう説明しています。title・canonical・noindex・リダイレクト・サイトマップをページごとに設定できるかを、チェック表で確かめて選びます。

ヘッドレスCMSはSEOに不利ですか?

不利とは限りません。最初の HTML に本文・リンク・title が入る描画方式(静的生成やサーバーサイド レンダリング)にすれば、通常のサイトと同じように扱われます。ブラウザの JavaScript で中身を作る構成では、Google のレンダリングを待つことになり、JavaScript を実行しないクローラーには中身が届きません。

CMSを変えると順位は下がりますか?

URL が変わる場合、Google は再クロールの間に順位が変動することがあると説明しています。旧 URL から新 URL への 301 リダイレクト、内部リンクとサイトマップの更新、title や構造化データの引き継ぎを確実に行うと、影響を小さくできます。URL を変えずに済むなら、変えないのが最も確実です。

オウンドメディアにはどのCMSを使えばよいですか?

記事を書く人数、更新の頻度、社内で技術の担当者がいるか、外部のツールと連携するかで決めます。技術の担当者がいない場合は、設定の多くを管理画面でできるものが運用しやすくなります。どの CMS でも、選ぶ前に試用版で記事を 1 本公開し、出力される HTML を確かめます。

SEOAGENTでできること

SEOAGENT では、記事の作成から WordPress への投稿、公開前の確認までを支援します。

  • WordPress投稿・予約:サイトの URL・ユーザー名・アプリケーションパスワードで接続し、タイトル、本文、画像、カテゴリ、タグ、スラッグなどを設定して送れます。すぐに公開するか、日時を指定して公開するかを選べます
  • 品質チェック:公開の前に、答えるべき問い、数字の根拠、公開ページの設定などの確認が必要な項目を示します

できないこと:CMS の選定や入れ替え、サーバーの設定、リダイレクトの設定は行えません。WordPress への投稿では、下書きとして送ることはできません(すぐに公開か予約公開)。多言語プラグインや SEO メタの対応範囲は、接続する環境ごとに確かめます。

参考情報

関連する記事

「テクニカルSEO」の記事をすべて見る →

クロールバジェットとは:Googleの説明と、気にすべきサイト・しなくてよいサイト
テクニカルSEO

クロールバジェットとは:Googleの説明と、気にすべきサイト・しなくてよいサイト

クロールバジェットは、多くのサイトでは気にする必要がありません。Google の「クロール バジェットの管理」の原文に沿って、決まる仕組み、対策が必要なサイトの目安、クロールの統計情報での確かめ方、クロールを無駄にする原因と対処を、当サイトの点検結果とあわせて説明します。

AIでSEO対策を、もっと続けやすく。

機能と使い方、料金・契約条件は、サービス資料でご案内します。