CMS判定ツール

このサイトのCMSは何? どのWebサイトでも、プラットフォーム、テーマ、プラグイン、その背後の技術スタック全体を、それぞれを証明するコードの行とともに確認できます。

7,600以上の技術 · サイトのヘッダー、HTML、DNS · ご要望に応じて実際のブラウザー
7,660種類の技術

ドメイン、またはパス付きの完全なURL。確認したサイトを公開することはありません。

例
読み取る場所DNS · ヘッダー · HTML · ブラウザー
探しているもの基盤 1,773プラグイン 600コード 718マーケティング 2,293コマース 659チャット 341メディア 467サーバー 212ネットワーク 465その他 132
DNSNS · MX · TXT
ヘッダーサーバー · Cookie · リンク
<head>meta · スクリプト · スタイル
<body>マークアップ · スクリプト · コメント
ブラウザーJS · リクエスト

見つけた技術はすべて、証拠のある場所に印を付けて示します。DNSレコード、レスポンスヘッダー、ページの行、または実際のブラウザーが読み込んだものです。

CMS判定ツールの結果:techcrunch.comはWordPressで動作。テーマ、プラグイン、各証拠がページのどこにあるかを表示CMS判定ツールの結果:techcrunch.comはWordPressで動作。テーマ、プラグイン、各証拠がページのどこにあるかを表示あらゆるWebサイトドメイン、またはパス付きの完全なURL。ページは古いクロールではなく、その場で読み取ります。答えプラットフォーム、そのバージョン(WordPressは最新リリースと比較)、そしてテーマ。どこで見つけたかすべての技術を、証拠のある場所に印で示します:DNS、ヘッダー、ページの行、ブラウザー。証拠選択中のシグナルを、サイトが送ったそのままの形で表示します(ヘッダーの行、タグ、ファイルパスなど)。‹ › ですべてのシグナルを順に確認できます。
結果の例です。プラットフォームとそのバージョン、テーマ、そしてすべての技術を証拠のある場所に印で示す帯。番号を選ぶと、各部分に何が表示されているかを確認できます。

CMS判定ツールの仕組み:何を手がかりに調べるのか

当ツールであることを名乗ったうえでサイトにページを1回だけ要求し、各プラットフォームが残す痕跡を、レスポンスヘッダー、Cookie、HTML、ファイルのパスから探します。

痕跡の中には、プラットフォーム自身が付けるため、偽装や削除が難しいものがあります。WordPressはLinkヘッダーでREST APIを告知し、Shopifyは_shopify_essentialというCookieを設定します。一方、ページに書き込まれる痕跡は削除もコピーもできます。generatorタグ、クラス名、コメントなどです。

そのため、誰でもコピーできる痕跡は手がかりにすぎず、互いに独立した痕跡が2つ、またはプラットフォーム自身しか付けない痕跡が1つあれば証拠になります。上のツールの答えにはすべて、根拠となった痕跡を見つけたとおりそのまま引用し、それに基づく確度を確定、有力、可能性ありのいずれかで表示します。

ページのほかにドメインのDNSレコードも読み取り、WordPressサイトでは同じホストから最大2つのファイルを追加で取得します。テーマのstyle.cssと、ページが示している/wp-json/のインデックスです。実際のブラウザーを使うのは、ご要望があったときだけです。

1つのレスポンス、8つの痕跡 · nalgene.com、2026年10月24日
  1. HTTP/2 200 · ヘッダー23件
  2. 13行目server: cloudflare
  3. 27行目link: <https://nalgene.com/wp-json/>; rel="https://api.w.org/"
  4. 38行目link: <https://nalgene.com/wp-json/wp/v2/pages/87>; rel="alternate"; title="JSON"; type="application/json"
  5. 415行目set-cookie: __cf_bm=BZFgzmA1kpRQ…; HttpOnly; Secure
  6. HTML · 464 KB
  7. 51,085バイト目<!-- This site is optimized with the Yoast SEO Premium plugin v28.0 (Yoast SEO v28.6) -->
  8. 68,283バイト目<link rel='stylesheet' href='…/wp-content/themes/nalgene-twentytwenty/style.css?ver=9260242'>
  9. 752,255バイト目<meta name="generator" content="WP Rocket 3.23.5.1">
  10. 8432,563バイト目<script src="…/wp-includes/js/wp-util.min.js?ver=7.1.3"></script>
  1. 1ヘッダーCloudflareがサイトを配信確定
  2. 2ヘッダーWordPressのREST API:WordPress自身が付与確定
  3. 3ヘッダーページ自身のRESTアドレス:これもWordPressコア確定
  4. 4CookieCloudflare Bot Management確定
  5. 5コメントYoast SEOとそのバージョン有力
  6. 6ファイルパステーマのフォルダー、続いてstyle.cssのヘッダー確定
  7. 7generatorタグWP Rocket:自己申告で、簡単に削除できる有力
  8. 8?ver=コアスクリプトに付いたWordPress 7.1.3有力
nalgene.comの23件のレスポンスヘッダーのうち4件と、464 KBのページのうち4行です。WordPressのgeneratorタグはありません(無効にできます)が、RESTヘッダー、ファイルパス、コアスクリプトに付いたバージョンが、WordPress 7.1.3であることを示しています。

CMS、サイトビルダー、ヘッドレスCMS、フレームワークの違いは?

どれもWebサイトを作るためのものですが、ページに名前を残すのは一部だけです。コンテンツがどこにあるかによって、判定ツールに見えるものが決まります。

WordPressのような従来型のCMSは、コンテンツを保存し、すべてのページを自ら生成するため、痕跡がページのあちこちにあります。Wixのようなサイトビルダーはサイトのホスティングも行うため、ファイルを配信するホストから判別できます。

ContentfulのようなヘッドレスCMSはコンテンツを保存するだけで、ページは別のフロントエンド(多くはNext.js)が生成するため、見えるのはせいぜいCMSの画像ホストです。Hugoのような静的サイトジェネレーターは事前にプレーンなHTMLを生成し、残すのはせいぜいトップページのgeneratorタグだけです。

コンテンツの置き場所と、ページに届くもの
従来型CMSWordPress
  1. コンテンツ + テーマ
  2. WordPressが生成
  3. 自前のサーバーで配信
  4. ページ

ページに現れるもの

/wp-content/rel="https://api.w.org/"<meta name="generator">

判定結果WordPress確定

サイトビルダーWix
  1. コンテンツ
  2. Wixが生成
  3. Wixがホスティング
  4. ページ

ページに現れるもの

static.wixstatic.com/mediax-wix-request-idserver: Pepyaka

判定結果Wix確定

ヘッドレスCMSContentful + Next.js
  1. コンテンツはContentfulに
  2. APIで取得
  3. Next.jsが生成
  4. ページ

ページに現れるもの

/_next/static/images.ctfassets.net

判定結果ページにCMSなし可能性あり

静的サイトジェネレーターHugo
  1. Markdownファイル
  2. 1回だけHTMLにビルド
  3. 静的ファイルとして配信
  4. ページ

ページに現れるもの

<meta name="generator" content="Hugo …">トップページのみ

判定結果Hugo有力

それぞれの種類のシステムが、訪問者に届くHTMLに何を残すかを示しています。W3Techsは調査で4つともCMSとして数えていますが、判定ツールが名前を挙げられるのは痕跡を残すものだけです。

サイトのWordPressテーマとプラグインの調べ方

ページ内のファイルパスにあるフォルダー名を読みます。WordPressテーマ判定ツールは/wp-content/themes/<name>/からテーマのフォルダーを取り出し、そのテーマのstyle.cssを開きます。そのヘッダーには、テーマ名、作成者、バージョン、そして子テーマの場合は親テーマが書かれています。

このヘッダーはテーマの身分証のようなもので、WordPressのテーマハンドブックで定められています。子テーマは親テーマのフォルダー名をTemplate:に記すため、1つのページに2つのテーマが現れることがあります。nalgene.comは、独自のNalgene Twenty TwentyをGenesis 3.5.0の上で動かしています。

プラグインも同じように/wp-content/plugins/<name>/のフォルダーとして現れ、多くは?ver=の番号が付いています。この番号がプラグインのバージョンなのは、リリースと一致する場合だけです。nalgene.comのWooCommerceのスクリプトには、WordPress.orgのreadmeにあるStable tagと同じ11.2.1が付いていますが、別のプラグインのファイルにはタイムスタンプが付いています。

見えるのは、ページに何かを出力するプラグインだけです。バックアップやセキュリティのツール、お問い合わせページのフォームは、トップページのHTMLに何も残さないため、サイトのプラグインをすべて列挙できる判定ツールはありません。

テーマ1組とプラグインフォルダー15個 · nalgene.com、2026年10月24日

テーマ

ページ内

/wp-content/themes/nalgene-twentytwenty/style.css?ver=9260242/wp-content/themes/genesis/lib/js/skip-links.min.js?ver=3.5.0class="… wp-child-theme-nalgene-twentytwenty …"

子テーマNalgene Twenty Twenty

  1. /wp-content/themes/nalgene-twentytwenty/style.css
  2. Theme Name: Nalgene Twenty Twenty名前
  3. Author: Scout Digital作成者
  4. Version: 9260242バージョン · ビルド番号
  5. Template: genesis親テーマのフォルダー

親テーマGenesis 3.5.0 · StudioPress

  1. Theme Name: Genesis名前
  2. Author: StudioPress作成者
  3. Version: 3.5.0バージョン

プラグイン

  • /plugins/woocommerce/?ver=11.2.1

    WooCommerce 11.2.1:WordPress.orgのreadmeにあるStable tag

  • /plugins/woocommerce/…/jquery-blockui/?ver=2.7.0-wc.11.2.1

    WooCommerceに同梱のライブラリ(jQuery BlockUI 2.7.0)で、WooCommerceのバージョンが付いたもの

  • /plugins/elasticpress/?ver=1792138636

    タイムスタンプ(2026年10月16日)で、ElasticPressのバージョンではない

  • + ほか13個のプラグインフォルダーinstagram-feed-prowoo-discount-ruleswoo-discount-rules-prowoo-variation-swatcheswoocommerce-back-in-stock-notificationswp-rocketsimple-cloudflare-turnstilekount-fraud-preventiondatalayer-for-woocommerceaddify-advanced-split-ordernalgene-customizervital-theme-modificationsvital-message-bar-master

ページに何も出力しないプラグイン:どの判定ツールにも見えません

子テーマのstyle.cssはGenesisを親テーマに指定しており(Template: genesis)、Genesis自身のヘッダーがそのバージョン3.5.0を示しています。3つの?ver=の値のうち、1つはプラグインのバージョン、1つは同梱ライブラリのバージョン、1つはタイムスタンプです。

Shopifyストアが使っているテーマの調べ方

ページのソースでShopify.themeを検索します。当サイトで確認したShopifyストアはすべてこのオブジェクトを出力しており、Shopifyテーマ判定ツールはこれを読み取ります。そのストアでのテーマ名、ベースになっているテーマとそのバージョン、テーマストアの番号、公開中のテーマかどうかがわかります。

名前はマーチャントが自分のコピーに付けたものなので、あまり参考にならないことがあります。LACMAのミュージアムショップでは、テーマ名が「Updated copy of Kingdom」です。schema_nameとschema_versionがベースのテーマ(Kingdom 4.3.1)を示し、theme_store_idはShopifyテーマストアでの番号です。

大手ブランドは独自のテーマを使うことが多く、allbirds.comのテーマはallbirds-theme 1.231.12をベースにしており、テーマストアの番号はありません。プラットフォーム自体は、powered-by: Shopifyヘッダーや_shopify_essential Cookieなど、Shopifyのほかの痕跡で確定します。

Shopify.themeを分解 · allbirds.com、2026年10月24日
  1. Shopify.theme = {
  2. 1"name": "[DNAM Theme July 2026]",
  3. 2"id": 130450260048,
  4. 3"schema_name": "allbirds-theme",
  5. "schema_version": "1.231.12",
  6. 4"theme_store_id": null,
  7. 5"role": "main"
  8. }
  1. 1マーチャントがこのテーマのコピーに付けた名前
  2. 2このストアでのテーマID
  3. 3ベースのテーマと、そのテーマのバージョン
  4. 4Shopifyテーマストアでの番号:ここではなし
  5. 5main:顧客に表示される公開中のテーマ

3つのストア、3種類のテーマ

ストアストアでの名前ベーステーマストア
allbirds.com独自テーマ[DNAM Theme July 2026]allbirds-theme 1.231.12なし
theme-dawn-demo.myshopify.comShopifyのデモストアDawnDawn 15.0.0#887
thelacmastore.orgミュージアムショップUpdated copy of KingdomKingdom 4.3.1#725
ShopifyはShopify.themeオブジェクトを文書化していないため、これらのストアで観察した内容として読み取っています(Dawnのデモでは Dawn 15.0.0、テーマストア番号887)。roleの値はShopifyのもので、mainは公開中のテーマです。

CMS判定で「見つかりません」と表示されるのはなぜ?

多くの場合、CMSがないからではなく、読み取ったページにCMSの痕跡がないからです。主な原因は4つです。

原因が見えるときは、それを示します。サイトの代わりに返ってきたボットチェック、CMSの痕跡がないフレームワーク、サイト所有者が無効にした痕跡、あるいはサイトのほかの部分とは別のシステムで動いているページです。

そして、本当にCMSがないこともあります。W3Techsによると、Webサイトの32.1%では認識できるCMSが見つかりません。そのため、3サイトに1つ程度で何も見つからなくても、判定ツールは正常に動作しています。

4つの実際の原因 · 2026年10月23〜24日に確認
ボット対策でブロック

drupal.org

3 KB · サイトではない

Fastlyがサイトの代わりに3 KBの「Client Challenge」ページを返したため、読み取れるDrupalのマークアップがありません。「ブロック」と表示し、ブラウザースキャンを提案します。

CMSの痕跡がないフロントエンド

openai.com

フレームワーク · CMSは可能性あり

Vercel上のNext.jsです。文章はヘッドレスCMSから来ているかもしれませんが、それを示すのはContentfulの画像ホストだけなので、「可能性あり」のままです。

痕跡を無効化

nalgene.com

generator削除 · それでも確定

WordPressのgeneratorタグはありませんが、RESTのLinkヘッダー、/wp-content/のパス、?ver=7.1.3が今もWordPressを示しています。痕跡を完全に消せることはまれです。

別のページで別のシステム

ghost.org

/ = Hugo · /blog/ = Ghost

ghost.orgのトップページはHugoで作られ、/blog/ではGhost 6.73が動いています。チェックするのは1つのURLなので、ショップやブログのセクションも含め、目的のページを貼り付けてください。

各カードの帯は、ツールと同じ種類の読み取りを小さく描いたものです。痕跡がどこにあり、何が欠けていたかを示します。

ブラウザースキャンでしか見つからないものは?

HTMLの後から届くものすべてです。タグマネージャーが追加するタグ、アクセス解析や広告のピクセル、チャットや同意管理のツール、JavaScriptが実行されて初めて現れるスクリプトなどです。allbirds.comでは、実際のChromeが、ページのHTMLを読むだけでは見逃していた15の技術を見つけました。

通常のチェックは、サーバーが送るものを読み取ります。高速で、プラットフォーム、テーマ、技術スタックの大部分がわかります。ブラウザースキャンはChromeでページを数秒間読み込み、スクリプトを実行させて、それらが読み込むものを読み取ります。

5つのサイトで試したところ、サーバー側の読み取りで見つかった技術をブラウザーが見落とすことは一度もなく、追加で見つかった技術は2(Wikipedia)から27(TechCrunch)でした。タグマネージャー経由で動いているサイトほど増え、シンプルなWikiのページはほとんど変わりません。

サーバー側の読み取りと実際のブラウザー · 5サイト、2026年10月24日
  • allbirds.com10+15リクエスト389件 · 8.1秒
  • bbc.com14+19リクエスト201件 · 6.3秒
  • nextjs.org6+8リクエスト83件 · 3.6秒
  • techcrunch.com17+27リクエスト237件 · 6.8秒
  • wikipedia.org7+2リクエスト40件 · 3.8秒
  • HTML内
  • ブラウザーでのみ

allbirds.comでブラウザーでのみ見つかったもの

アクセス解析・マーケティング

  • Google Analytics
  • Facebook Pixel
  • Microsoft Clarity
  • OneTrust
  • Attentive
  • Impact
  • DoubleClick Floodlight

フレームワーク・ライブラリ

  • Vue.js
  • GSAP
  • Framer Motion
  • core-js
  • Datadog
  • Goober

フォント

  • Google Font API

コマース

  • Shop Pay
各サイトをインドからChromeで1回ずつ読み込み(読み込み後さらに3秒)、HTMLと同じルールで照合しました。件数は同意バナー、地域、時間によって変わります。ブラウザーでしか見つからなかったものの中にも、より詳しいルールなら読み取れる痕跡を残すものがあります。Shop Payのプリロードスクリプトは、allbirds.comのHTMLにあります。

WebサイトはCMSを隠せますか?

部分的には可能です。自前でホスティングするCMSなら、所有者がgeneratorタグを無効にしたり、パスをいくつか変更したりできますが、ページにはプラットフォームの特徴が残ります。ShopifyやWixのようなホスティング型プラットフォームでは、痕跡をまったく隠せません。

完全に隠せることはまれです。よく使われるWordPressのスニペットはページからgeneratorタグを消しますが、RSSフィードからは消しません。/wp-json/の名前を変えてもrel="https://api.w.org/"のリンクは残り、wp-contentを移動しても、ページには/themes/フォルダーと?ver=の番号が残ります。

そのため、「見つかりません」は「CMSなし」という意味ではありません。痕跡のないページでも、どのCMSで動いていてもおかしくありません。うまく隠しているサイトでは、答えが有力または可能性ありに下がり、残っている痕跡を表示します。

無効にしても、まだ見えるもの
  • WordPressのgeneratorタグ<meta name="generator" content="WordPress 7.1.3">無効にする方法remove_action( 'wp_head', 'wp_generator' )まだ見えるものRSSフィードのgenerator行<generator>https://wordpress.org/?v=7.1.3</generator>
  • WordPressのRESTパス/wp-json/無効にする方法add_filter( 'rest_url_prefix', … )まだ見えるものリンクのrel値rel="https://api.w.org/"
  • wp-contentフォルダー/wp-content/無効にする方法WP_CONTENT_DIR · WP_CONTENT_URLまだ見えるものその中のthemesフォルダーと?ver=の番号…/themes/<name>/?ver=
  • Next.jsのヘッダーx-powered-by: Next.js無効にする方法poweredByHeader: falseまだ見えるものファイルパス/_next/static/
  • Hugoのgeneratorタグ<meta name="generator" content="Hugo …">無効にする方法disableHugoGeneratorInject = trueまだ見えるものなし:静的サイトでは動いているCMSがない
  • Joomlaのバージョン<meta name="generator" content="Joomla! …">無効にする方法MetaVersionデフォルトで無効まだ見えるものバージョンなしのgeneratorタグJoomla! - Open Source Content Management
  • Shopify{{ content_for_header }}無効にする方法無効化不可まだ見えるもの全ページのスクリプトとCookie_shopify_essentialpowered-by: Shopify
  • Wixstatic.wixstatic.com/media無効にする方法無効化不可まだ見えるものメディアホストstatic.wixstatic.com/media
それぞれの無効化方法は、プラットフォーム自身の設定で、そのドキュメントやソースコードに基づいています。自前でホスティングするシステムは痕跡を抑えられますが、ホスティング型プラットフォームでは独自のスクリプトとファイルホストが必須です。

CMSのバージョンが見えると、なぜ問題なのですか?

古いバージョンには、すでに公になっているセキュリティホールがあるからです。WordPress自身のセキュリティ強化ガイドは、古いバージョンはセキュリティアップデートで保守されておらず、修正が出れば、その穴を突く方法はほぼ確実に公開されている、と述べています。

それでも、バージョン番号だけでは、サイトが危険にさらされている証明にはなりません。公式にサポートされているのはWordPress 7.1だけですが、2026年10月6日にWordPressは4.7までのすべてのブランチで新しいバージョンをリリースしました。そのため、6.9.10のサイトは、そのブランチの最新リリースを使っていることになります。

そこで当ツールは、ページに書かれているバージョンを表示し、WordPress.orgの最新リリースと一致する場合だけ「最新」と表示し、サイトを「脆弱」とは決して呼びません。Drupalはメジャーバージョンしか示しませんが、古いものを見分けるにはそれで十分です。Drupal 7のセキュリティサポートは2025年1月5日に終了しました。

WordPressの各ブランチの最新リリース · 2026年10月24日時点
WordPressサイトでのシェア(W3Techs)
  • バージョン7
    • 7.1.3 最新 · 唯一サポート中のブランチ
    • 7.0.7
    66.9%
  • バージョン6
    • 6.9.10
    • 6.8.11
    • 6.7.10
    • 6.6.10
    • 6.5.13
    • 6.4.13
    • 6.3.13
    • 6.2.14
    • 6.1.15
    • 6.0.17
    26.3%
  • バージョン5
    • 5.9.19
    • 5.8.18
    • 5.7.20
    • 5.6.22
    • 5.5.23
    • 5.4.24
    • 5.3.26
    • 5.2.29
    • 5.1.27
    • 5.0.30
    4.7%
  • バージョン4
    • 4.9.34
    • 4.8.33
    • 4.7.38
    • 4.6.30
    • 4.5.33
    • 4.4.34
    • 4.3.35
    • 4.2.39
    • 4.1.42
    • 4.0.38
    2.0%
  • バージョン3
    • 3.9.40
    • 3.8.41
    • 3.7.41
    • 3.6以前
    0.2%
  • 2026年10月6日リリース
  • 最終リリース2025年7月
  • 最終リリース2022年11月30日
  • 2013年以降リリースなし
4.7から7.1までのすべてのブランチが2026年10月6日にリリースを受け取りました。古いブランチへは厚意によるバックポートで、公式に保守されているのは7.1だけです。各メジャーバージョンの横にあるのは、W3Techsがバージョンを確認できるWordPressサイトの中でのシェアです(2026年10月23日)。

Webサイトの脆弱性チェックツールとして使えますか?

受動的(パッシブ)なチェックとして使えます。サイトがヘッダー、ページ、ブラウザースキャンで示す正確なバージョンごとに、そのバージョンが対象となる公開済みセキュリティアドバイザリ(CVEを含む)をOSV.devから(ファイルから見つかったJavaScriptライブラリはRetire.jsから)、リリースラインのサポート状況をendoflife.dateから取得し、PHP2Shellなど当サイト独自の注意喚起とあわせて一覧にします。プローブや攻撃リクエストを送ることは一切ありません。

バージョン番号には限界があります。Linuxディストリビューションのパッケージは古い番号のままバックポートされた修正を含んでいることがあり、アドバイザリがサイトで使っていない機能を前提にしていることもあり、多くのサイトはバージョンを隠しています。そのため答えは、バージョンについての事実(「Next.js 14.1.0を対象とする公開済みアドバイザリは36件」)を示すだけで、サイトが脆弱だとは決して言いません。

Cloudflareの背後ではServerヘッダーが「cloudflare」になるため、Webサーバー自体のバージョンは見えませんが、サイトのほかのヘッダーはそのまま届きます。X-Powered-ByのPHPのバージョンは見えたままです。ご自身のサイトをきちんと検査するには、そのサイトに対して実行する許可を得ている脆弱性スキャナーを使ってください。

バージョンから3つの答えへ · 3つの実際のパターン、2026年10月24日
  1. 1Flaskアプリの開発用サーバーflask-app.example

    サイトが送るものServer: Werkzeug/2.0.1 Python/3.8.10

    Werkzeug2.0.1公開済みアドバイザリ · OSV.devアドバイザリ11件重要2件サポート · endoflife.date–この情報源の対象外当サイトの注意喚起–この情報源の対象外
    Python3.8.10公開済みアドバイザリ · OSV.dev–この情報源の対象外サポート · endoflife.date2024年10月7日に終了当サイトの注意喚起–この情報源の対象外
  2. 2Cloudflareの背後のPHPshop.example

    サイトが送るものServer: cloudflareWebサーバーのバージョン:Cloudflareにより非表示X-Powered-By: PHP/7.4.33

    PHP7.4.33公開済みアドバイザリ · OSV.dev–この情報源の対象外サポート · endoflife.date2022年11月28日に終了当サイトの注意喚起脆弱性の影響を受ける可能性ありPHP2Shell · PHPプロジェクトから7.4向けの修正版リリースなし
  3. 3ブラウザースキャンで見つかったNext.jsapp.exampleブラウザースキャンで発見

    サイトが送るものwindow.next.version → "14.1.0"

    Next.js14.1.0公開済みアドバイザリ · OSV.devアドバイザリ36件緊急4件サポート · endoflife.date2025年10月26日に終了最新は14.2.35当サイトの注意喚起–この情報源の対象外
ヘッダー、ページ、ブラウザースキャンが示すとおりの各バージョンを、チェック当日に照会したものです。OSV.devのアドバイザリ(2つのデータベースに載っている欠陥は1件として数えます)、endoflife.dateのサポート期間、当サイト独自の注意喚起です。ダッシュは、その情報源がその製品を対象にしていないことを示します。ホスト名は架空ですが、パターンと答えは実際のものです。

BuiltWith、Wappalyzer、WhatCMSとの違いは?

BuiltWithは独自のWebインデックスから答え、Wappalyzerは過去30日以内に検証された結果か、5回分の検索としてカウントされるライブ読み取りを提供し、WhatCMSはページをライブで読み取りますが、最近の検索をトップページに一覧表示します。CMS判定とサイトの使用技術の分析を行うこのツールは、指定されたページをその場で読み取り、各答えの根拠となった行を示します。

インデックスは履歴を見るのに向いています。BuiltWithのAPIは、ドメインを最後にインデックスした時期を返します。ライブ読み取りなら、貼り付けたページそのものを現在の状態で確認でき、ショップやブログのサブフォルダーにも対応します。

無料で使える範囲も異なります。Wappalyzerはアカウント登録で月50回、BuiltWithは単一サイトの検索が無料、WhatCMSの無料APIプランは月500回の検出で、非公開の検索は月$40からです。このページはアカウント不要で、何も公開しません。

「このサイトは何で作られている?」に答える4つの方法 · 2026年10月24日

DNS Robotこのページ

答えの元
貼り付けたページをその場で読み取り、各答えの根拠となる行を表示
無料で使える範囲
アカウント不要、何も公開しない
知っておきたいこと
ご要望に応じて実際のブラウザーでスキャン

BuiltWith

答えの元
検索エンジンのようにクロールした独自のWebインデックス
無料で使える範囲
単一サイトの検索
知っておきたいこと
ドメインを最後にインデックスした時期をAPIが返す

Wappalyzer

答えの元
30日以内に検証された結果、またはライブ読み取り
無料で使える範囲
アカウント登録で月50回
知っておきたいこと
ライブの結果は5回分の検索としてカウント

WhatCMS

答えの元
依頼したときに取得するページ
無料で使える範囲
API:月500回の検出
知っておきたいこと
最近の検索をトップページに一覧表示。非公開の検索は月$40から
2026年10月24日に各ツール自身のページから引用しました。プランは変わるため、選ぶ前に各ツールのページを確認してください。

CMS判定ツール:よくある質問

サイトが使っているCMSの調べ方は?

上のCMS判定ツールにサイトのアドレスを貼り付けてください。ページのヘッダー、Cookie、HTMLとドメインのDNSレコードを読み取り、プラットフォームを、それを証明するコードの行と確度とともに示します。自分で調べることもできます。ページのソースを表示して、generator、wp-content、Shopify.theme、wixstaticを検索してください。

サイトのWordPressテーマを判定できますか?

はい、ページがテーマのフォルダーからファイルを読み込んでいればできます。/wp-content/themes/<name>/からフォルダー名を取り出し、そのテーマのstyle.cssのヘッダーから名前、作成者、バージョンを読み取ります。子テーマはTemplate:の行で親テーマを示すため、Genesis 3.5.0上のNalgene Twenty Twentyのように両方がわかります。テーマファイルをブロックするホストでは、フォルダー名だけになります。

ストアが使っているShopifyテーマを判定できますか?

はい。ShopifyストアはHTMLにShopify.themeオブジェクトを出力しており、そのストアでのテーマ名、ベースのテーマ(schema_name)とそのバージョン、テーマストアの番号、roleが含まれます。名前は「Updated copy of Kingdom」のようにマーチャントが自由に入力できるため、ベースのテーマも表示します。allbirds.comのようなブランド独自のテーマには、テーマストアの番号がありません。

WordPressサイトのプラグインをすべて見つけられますか?

どの判定ツールにもできません。プラグインが見えるのは、ページに何かを出力する場合だけです。/wp-content/plugins/<name>/の下のスクリプトやスタイルシート、コメント、クラス名などです。バックアップ、セキュリティ、お問い合わせページのフォームなど、管理画面やほかのページで動くプラグインは、トップページに痕跡を残しません。プラグインが動いているページを調べると、より多く見つかります。

WordPressだとわかっているのに、WordPressではないと表示されるのはなぜですか?

多くの場合、取得したページにWordPressの痕跡がなかったためです。ボット対策がサイトの代わりにチャレンジページを返した(「ブロック」と表示します)、所有者がgeneratorタグを削除してwp-contentを移動した、あるいはそのアドレスでは別のシステムが動いている、といった場合です。ghost.orgはトップページがHugo、ブログがGhostです。目的のページそのものを調べるか、ブラウザースキャンをお試しください。

Cloudflareの背後にあるCMSもわかりますか?

たいていはわかります。Cloudflareはサイト自身のヘッダーとHTMLをそのまま通すため、WordPressのRESTヘッダー、ファイルパス、X-Powered-Byヘッダーは見えたままです。変わるのはServerヘッダーが「cloudflare」になることだけで、これでWebサーバー自体のバージョンが隠れます。例外はボットチェックです。Cloudflareなどのファイアウォールがサイトの代わりにチャレンジページを返すと、チェックがブロックされたと表示します。ブラウザースキャンなら通る場合があります。

CMS判定ツールによって結果が違うのはなぜですか?

読み取る対象と時点が違うからです。BuiltWithは独自のWebインデックスから答え、Wappalyzerのキャッシュされた結果は最大30日前のものですが、ライブのツールは今のページを読み取ります。ツールによって確認するページやルールが違うこともあれば、サイトの代わりにボットチェックを受け取ることもあります。そのため当ツールの答えには、それぞれ根拠となった行を示しています。

このCMS判定ツールの精度は?

すべての答えに根拠と、3つのラベルのいずれかが付きます。確定は、独立した2つのシグナル、またはそのプラットフォーム独自のヘッダー、Cookie、ファイルパスのように、そのプラットフォームにしか出せないシグナルが1つあることを意味します。有力は、generatorタグのように誰でもコピーや削除ができるシグナルが1つの場合です。可能性ありは、画像ホストのような間接的な手がかりです。ブロックされたページや空のページはそのまま報告し、「CMSなし」とは表示しません。

CMSのバージョンが表示されないのはなぜですか?

多くのプラットフォームがバージョンを出力しないからです。Joomlaはデフォルトでバージョンを隠し、Drupalのヘッダーはメジャーバージョンだけ、Ghostはメジャーとマイナーだけを示します。WordPressは所有者が削除しない限り正確なバージョンを出力し、ファイルのアドレスにも?ver=として残っていることがよくあります。当ツールが表示するのは、ページ上のシグナルが実際に示しているバージョンだけで、どこで見つけたかも示します。

Webサイトの既知の脆弱性(CVE)をチェックできますか?

はい。サイトが示すバージョンについて受動的にチェックします。ヘッダー、ページ、ブラウザースキャンにNext.js 14.1.0のような正確なバージョンがあれば、それを対象とするOSV.devのアドバイザリ(ファイルで見つけたJavaScriptライブラリはRetire.js)、リリースラインが今もサポートされているか(endoflife.date)、PHP2Shellなど当サイト独自の注意喚起を一覧にします。プローブは送らず、サイトを脆弱とも呼びません。バックポートされた修正はバージョン番号に現れないからです。

サイトがPHP2Shellの影響を受けるか確認できますか?

サイトが公開しているPHPのバージョンでのみ判断します。X-Powered-ByまたはServerヘッダーがPHPを示していれば、OpenAIのphp2shell-checkerと同様に、php.netの2026年10月21日の修正(8.5.12、8.4.27、8.3.36、8.2.35)と比較します。これらのブランチの古いリリースか、PHP 5.4〜8.1なら「脆弱性の影響を受ける可能性あり」です。ディストリビューションのパッケージにはバックポートされた修正が含まれることがあり、PHPのバージョンを隠すサイトはこの方法では確認できません。

確認したサイトは保存・公開されますか?

公開することはありません。最近の検索の公開リストもありません。同じページをもう一度確認したときにすぐ表示できるよう、結果は短時間だけ保持し、その後は消えます。確認先のサイトに見えるのは当サイトのサーバーからのリクエストで、あなたのIPアドレスが見えることはありません。リクエストはDNS RobotのCMS判定ツールと名乗り、ブラウザースキャンはCloudflareのネットワークからページを読み込みます。

足りないものはありますか?機能や新しいツールを提案する