プラットフォームSEO

TL;DR — サイトを構築するプラットフォームは、1語も書く前からSEOの選択肢を形作ります。自動で多くを処理するプラットフォームもあれば、完全な制御を与える代わりに設定を多く残すものもあります。この違いは、タイトル、canonical、サイトマップ、構造化データ、robots.txt、レンダリングといった技術SEOで特に重要です。

プラットフォームの選択がSEOに影響する理由

SEOの助言の多くは、ウェブサイトを白紙のキャンバスとして扱います。実際には、CMSやウェブサイトビルダーが、URL構造、サイトマップの生成方法、robots.txtを編集できるか、メタデータの扱い、どの構造化データを自動で注入するかなど、すでに数十のSEO判断を行っています。

良い知らせは、主要なプラットフォームのほとんどが基本を適切に処理することです。違いが現れるのは、標準外のことを行う必要があるとき、特定の技術的問題を修正するとき、または数万ページまで規模を拡大するときです。

5つのカテゴリー

従来型CMS（WordPress、Drupal、Joomla、HubSpot CMS、Umbraco、Sitecore）は、自分のサーバー（またはマネージドホスト）にインストールし、技術SEOの設定をすべて深く制御できます。特にWordPressには豊富なプラグインエコシステムがあり、YoastやRank Mathなどが設定後の技術SEOの大部分を自動処理します。

ビジュアル型およびSaaS型のウェブサイトビルダー（Wix、Squarespace、Webflow、Framerなど）はサイトをホスティングし、インフラを管理します。HTTPS、CDN、サイトマップ、基本的なメタデータを自動処理しますが、多くはサーバー側の設定とURL構造を制限します。robots.txtへのアクセスはビルダーによって異なり、WixとSquarespaceはロックダウンされていますが、WebflowはSettings → SEOの下で直接公開しています。ほとんどのサイトには適していますが、特殊なケースでは制約になります。

ヘッドレスCMS（Contentful、Strapi、Sanity、Storyblok、Ghost）は、コンテンツを書く場所とレンダリング方法を分離します。SEOは、選択したフロントエンドレンダラーによって完全に決まり、SSGとSSRは安全ですが、CSRには注意が必要です。WordPressのプラグインが自動処理するもの（メタデータ、サイトマップ、canonical）は、明示的に構築することになります。

JavaScriptフレームワーク（React、Next.js、Vue、Nuxt、Angular、Astro、Svelte）は、コンテンツ管理システムではなく、フロントエンドのレンダリング環境です。各フレームワークには、サーバー側、ビルド時の静的、ブラウザー内のいずれでページをレンダリングするかに応じたSEO上の意味があります。Next.jsとNuxtというメタフレームワークは、組み込みのSEOサポートが最も充実しています。

Eコマースプラットフォーム（Shopify、WooCommerce、Magento、BigCommerce）は、商品構造化データ、ファセットナビゲーション、ページネーション、バリアントやコレクションによる重複URL、プラットフォーム固定のURL構造など、Eコマース固有のSEO上の論点を追加します。

このセクションの使い方

まずプラットフォームカテゴリーのハブから始め、次に特定のプラットフォーム記事へ進みます。それぞれ、プラットフォームが自動処理するもの、制限するもの、そして人をつまずかせるプラットフォーム固有の癖を扱います。

TL;DR — プラットフォームSEOは、制約とデフォルトを理解することです。触る前にプラットフォームが決めるものは何か、そしてその決定のどれを上書きできるかを確認します。重要な差は、レンダリングアーキテクチャ（CSRとSSRとSSG）、robots.txtの編集可能性、構造化データの注入、URL構造の柔軟性、サイトマップのカバレッジです。それ以外は、適切なプラグインやビルド設定でほぼ構成できます。

SEOのためのプラットフォーム評価

SEOのためにプラットフォームを評価するとき、大規模運用で重要な質問は次のとおりです。

レンダリングアーキテクチャ — プラットフォームは事前レンダリング済みHTMLを提供しますか、それともブラウザーがJavaScriptでページを構築しますか？静的HTMLが安全なデフォルトです。CSRはレンダリングの遅延を生み、スクリプトの実行に失敗するとGooglebotがコンテンツを見落とす可能性があります。SSRとISR（インクリメンタル静的再生成）はその中間です。SSRは安定してクロール可能ですが、再検証の期間が長すぎると、ISRはクローラーに古いバージョンを提供することがあります。

メタデータの制御 — 各ページの固有の<title>、<meta description>、Open Graph、canonicalタグをプログラムで設定できますか？現代のプラットフォームの多くは可能です。制約は通常、大規模カタログで現れます。カスタム開発なしに、メタデータを規模に応じてテンプレート化できますか？

構造化データ — プラットフォームはスキーマを自動注入しますか、それとも手動ですか？Shopifyの商品スキーマはテーマに依存します。WordPressにはプラグインが必要です。ヘッドレス構成では明示的な実装が必要です。

robots.txtとクロール制御 — robots.txtを直接編集できますか？ほとんどのプラットフォームでは可能です。Shopifyはrobots.txt.liquidテーマテンプレートを通じて、すべてのプランでカスタマイズに対応し、WebflowはSettings → SEOでネイティブに公開しています。WixとSquarespaceはよりロックダウンされた例外です。ほとんどのサイトでは重要ではありませんが、複雑なサイトでは、どれだけ上書きできるかの違いが重要です。

URL構造 — パスをカスタマイズできますか、それともプラットフォームによって強制されますか？Shopifyの/products/プレフィックスは固定です。従来型CMSのほとんどは完全な制御を与えます。

サイトマップ — 自動生成、手動管理、またはプラグイン経由ですか？何が含まれますか。特定のページや投稿タイプを除外できますか？

移行リスク — ライフサイクルの途中でプラットフォームを変更するとURLが変わり、壊れたリダイレクトのリスクが生じます。プラットフォームに関係なく、リダイレクトマップと移行後の完全なクロールの予算を確保してください。

制約によるプラットフォームSEOの比較

プラットフォームSEOは、CMSやウェブサイトビルダーが自動で処理するものと、手動で設定する必要があるものを理解することです。すべてのプラットフォームは、触る前に、レンダリング方法、URL構造、サイトマップ生成、メタデータの処理、robots.txt制御といった技術SEOの判断を行っています。

従来型CMS（WordPress、Drupal、Joomla、HubSpot CMS、Umbraco、Sitecore）：すべてのSEO設定を完全に制御できます。WordPressはSEO自動化のためのプラグインエコシステムが最も豊富です。保守は重くなりますが、最も柔軟です。

SaaSウェブサイトビルダー（Wix、Squarespace、Webflow、Framer、Weebly、Duda）：HTTPS、CDN、基本的なサイトマップ、メタデータを自動処理します。多くはURL構造とサーバー設定を制限し、robots.txtへのアクセスはさまざまです（Webflow：完全編集、Wix／Squarespace：ロックダウン）。ほとんどのサイトに適しています。

ヘッドレスCMS（Contentful、Strapi、Sanity、Storyblok、Ghost）：SEOは選択したフロントエンドフレームワークに完全に依存します。SSGまたはSSRを使い、CSRは避けます。プラグインが処理していたSEO（サイトマップ、canonical、メタデータ）はすべて明示的に構築する必要があります。

JavaScriptフレームワーク（React、Next.js、Vue、Nuxt、Angular、Astro、Svelte）：SEOはレンダリングモードによって異なります。Next.jsとNuxtは組み込みのSSR／SSGサポートが強力です。CSRモードの純粋なReact／Vueでは、信頼できるインデックス登録のために事前レンダリングまたはSSRが必要です。

Eコマースプラットフォーム（Shopify、WooCommerce、Magento、BigCommerce）：商品スキーマ、ファセットナビゲーション、コレクションやバリアントによる重複URL、ページネーション、プラットフォーム固定のURL構造など、Eコマース固有の論点を加えます。

SEOのためのプラットフォーム選定フレームワーク

ステップ1 — レンダリングの制約を特定する

• 順位付けが必要なコンテンツ → SSRまたはSSGが必要（クローラーに配信される静的HTML）
• CSRのみ → 重要ページを事前レンダリングするか、SSR／SSGに切り替える
• ISR → 頻繁に変わるコンテンツには短い再検証期間を設定する

ステップ2 — プラットフォームのデフォルトを監査する

• プラットフォームは何を自動生成するか？（サイトマップ、canonical、構造化データ）
• 何がロックまたは設定不能か？（robots.txt、URL構造、<head>へのアクセス）
• プラグインまたはカスタムコードが必要なのは何か？

ステップ3 — SEO要件をプラットフォームの機能に対応付ける

• 大規模なメタデータのテンプレート化は可能か？
• カスタム構造化データの種類は使えるか？
• ファセットナビゲーション／パラメータの処理は可能か？
• 国際向けのhreflangは可能か？
• クロール分析のためのログファイルアクセスは可能か？

ステップ4 — 移行コストを評価する

• 現在のURL構造 → 維持できるか、リダイレクトが必要か？
• 新しいプラットフォームのリダイレクト基盤はあるか？
• 移行後の監視計画はあるか？

プラットフォーム移行チェックリスト

• 現在のすべてのURLをエクスポートする（クロールまたはサイトマップ）
• 古いURLから新しいURLへマッピングし、変更されるものに印を付ける
• 変更されたすべてのURLに301リダイレクトを実装する
• 公開前にcanonicalタグを設定する
• Search Consoleで新しいサイトマップを送信する
• ステージングをクロールして、レンダリング、タイトル、メタ、canonicalを確認する
• 公開後4〜6週間、クロールエラーとインデックスカバレッジを監視する
• 新しいプラットフォームでCore Web Vitalsを確認する（CDNや画像処理はしばしば異なる）

プラットフォーム別の詳しい解説

• WordPress SEO
• Shopify SEO
• Webflow SEO
• ヘッドレスCMS SEO
• Next.js SEO

変更履歴