ウェブサイトのプラットフォーム検出について
サイトが何で構築されているかは、どうやって見分けられるのでしょうか?
どのプラットフォームにも、固有の痕跡が残ります。ジェネレーターのメタタグ、アセットのURLに含まれる規則的なフォルダー名、特定のシステムだけが設定するCookie、特定のホストが常に追加するヘッダーなどです。いずれも意図的に公表されているわけではありませんが、読み取ることはできます。
CMS検出ツールは、こうしたシグナルを読み取り、既知のプラットフォームのライブラリと照合します。これは巧妙な処理というよりパターンマッチングであり、そのため高速である一方、ときどき誤判定することもあります。
最も便利なのは、自分がまったく関わっていないサイトにも使えることです。競合他社が何を使っているのか、あるいは見込み顧客からどのような環境で作業することを期待されるのかを知るのに、会話をする必要はなく、数秒で済みます。
CMS、ECプラットフォーム、それともサイトビルダー?
これらはひとまとめにされがちですが、実際にはそれぞれ異なる役割を果たします。
- CMSはコンテンツを管理します(WordPress、Drupal、Ghost、Craft)。
- ECプラットフォームは商品と決済を管理します(Shopify、Magento、BigCommerce)。
- サイトビルダーはページをビジュアルに作成します(Wix、Squarespace、Webflow)。
- 静的サイトジェネレーターは、あらかじめページを生成し、プレーンファイルを配信します。
このツールは、検出された各プラットフォームがそのどちらに該当するかを報告し、すべてを「CMS」として分類することはありません。Shopifyで運営されているショップには、厳密な意味でのCMSは存在せず、そう明示するほうが、そうでないかのように扱うよりも有用です。
SEOにとってプラットフォームが重要な理由
作業の前提となる制約を定めます。URLについて変更できること、タイトルやメタディスクリプションの管理方法、構造化データが標準で提供されるのか、それとも構築が必要なのか、ページ速度をどの程度コントロールできるのか――これらはすべて、誰かが一言でも書くはるか前に、プラットフォームによって決められています。
また、発生する問題も予測できます。特定のプラットフォームでは、特定の問題が繰り返し発生します。そのため、何を見ているのかを把握していれば、最初に確認すべき箇所や、現実的に利用できる修正方法がわかります。
代理店業務では、これは技術的な問題であると同時に、作業範囲の確認に関わる問題でもあります。自由に編集できるサイトへの見積もりと、変更のたびに開発者が必要になるサイトへの見積もりは異なります。
検出結果が空だった場合
結果が空でも、サイトに問題があるとは限りません。十分に適切に構築されたサイトでも、独自仕様で作られていたり、一般的でない仕組みを使っていたり、指紋情報を取得できるものが何もない静的ファイルで構成されていたりすることはよくあります。
また、意図的に情報を目立たせないプラットフォームもあります。generatorタグを削除したり、アセットのパス名を変更したりすることは、標準的なセキュリティ強化策です。さらに、サイトの前段にプロキシやCDNがあると、検出ツールが本来読み取れるはずのヘッダーが削除される場合もあります。
また、検出結果が逆方向に誤ることもあります。プラットフォーム間で移行したサイトでは、古いプラットフォームの痕跡が何年もマークアップ内に残っていることが多いため、予想外の結果が出た場合は、すぐに信じ込むのではなく、もう一度確認する価値があります。
このツールがチェックする項目
URLを入力すると、ツールがページを読み込み、検出した内容を既知のプラットフォームのライブラリと照合します。認識した各プラットフォームと、その属するカテゴリ、さらにプラットフォームによって公開されている場合はバージョンも報告します。
プラットフォームに特化して確認します。通常、1つのページにはそれ以上に多くのテクノロジー(アナリティクス、フォント、フレームワーク、ホスティングなど)が使われており、全体像を把握するには別のチェックが必要です。
次に行うこと
プラットフォームは答えではなく、出発点です。
技術チェックでページが読み込むその他すべての要素を確認し、
Googlebotシミュレーターでページがどのように表示されるかを確認し、
Core Web Vitalsテストでプラットフォームが何らかのコストを生じさせていないかをチェックしましょう。