인기 도구

테마

CMS 확인 도구

이 사이트는 어떤 CMS를 쓸까요? 어떤 웹사이트든 플랫폼, 테마, 플러그인과 그 뒤의 기술 스택 전체를 각각을 증명하는 코드 줄과 함께 확인하세요.

7,600개 이상의 기술 · 사이트의 헤더, HTML, DNS · 요청 시 실제 브라우저
기술 7,660개

도메인 또는 경로가 포함된 전체 URL. 확인한 사이트는 절대 공개하지 않습니다.

예시
읽는 곳DNS · 헤더 · HTML · 브라우저
찾는 항목플랫폼 1,773플러그인 600코드 718마케팅 2,293커머스 659채팅 341미디어 467서버 212네트워크 465기타 132
DNSNS · MX · TXT
헤더서버 · 쿠키 · 링크
<head>meta · 스크립트 · 스타일
<body>마크업 · 스크립트 · 주석
브라우저JS · 요청

찾은 기술은 모두 증거가 있는 위치에 표시됩니다. DNS 레코드, 응답 헤더, 페이지의 한 줄, 또는 실제 브라우저가 불러온 것입니다.

CMS 확인 도구 결과: techcrunch.com은 WordPress 기반이며 테마, 플러그인, 각 증거가 페이지 어디에 있는지 표시CMS 확인 도구 결과: techcrunch.com은 WordPress 기반이며 테마, 플러그인, 각 증거가 페이지 어디에 있는지 표시모든 웹사이트도메인 또는 경로가 포함된 전체 URL. 오래된 크롤링이 아니라 페이지를 실시간으로 읽습니다.답플랫폼과 그 버전(WordPress는 최신 릴리스와 비교), 그리고 테마.찾은 위치모든 기술을 증거가 있는 위치에 표시합니다: DNS, 헤더, 페이지의 한 줄, 브라우저.증거선택한 신호를 사이트가 보낸 그대로 보여 줍니다(헤더 한 줄, 태그, 파일 경로 등). ‹ › 버튼으로 모든 신호를 차례로 넘겨 볼 수 있습니다.
결과 예시입니다. 플랫폼과 그 버전, 테마, 그리고 모든 기술을 증거가 있는 위치에 표시하는 띠. 번호를 선택하면 각 부분에 무엇이 나오는지 볼 수 있습니다.

CMS 확인 도구는 어떻게 작동하나요?

도구의 이름을 밝힌 채 사이트에 페이지를 한 번 요청하고, 각 플랫폼이 응답 헤더, 쿠키, HTML, 파일 경로에 남기는 흔적을 찾습니다.

어떤 흔적은 플랫폼 자체가 설정하므로 위조하거나 제거하기 어렵습니다. WordPress는 Link 헤더로 REST API를 알리고, Shopify는 _shopify_essential 쿠키를 설정합니다. 반면 페이지에 적힌 흔적은 제거하거나 복사할 수 있습니다. generator 태그, 클래스 이름, 주석 등이 그렇습니다.

그래서 누구나 복사할 수 있는 흔적은 단서일 뿐이고, 서로 독립된 흔적 두 개나 플랫폼 자체만 설정하는 흔적 하나는 증거입니다. 위 결과의 모든 답은 근거가 된 흔적을 발견한 그대로 인용해 보여 주고, 그에 따른 확신 정도를 확인됨, 유력, 가능성 있음 중 하나로 표시합니다.

페이지 외에 도메인의 DNS 레코드도 읽고, WordPress 사이트라면 같은 호스트에서 파일을 최대 두 개 더 가져옵니다. 테마의 style.css와, 페이지가 가리키는 /wp-json/ 인덱스입니다. 실제 브라우저는 요청하실 때만 사용합니다.

응답 하나, 흔적 여덟 개 · 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. 4쿠키Cloudflare 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 페이지의 네 줄입니다. WordPress generator 태그는 없지만(끌 수 있습니다), REST 헤더, 파일 경로, 코어 스크립트에 붙은 버전이 여전히 WordPress 7.1.3을 가리킵니다.

CMS, 사이트 빌더, 헤드리스 CMS, 프레임워크의 차이는?

모두 웹사이트를 만드는 도구지만, 페이지에 이름을 남기는 것은 일부뿐입니다. 콘텐츠가 어디에 있느냐에 따라 확인 도구가 볼 수 있는 것이 달라집니다.

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. 한 번 HTML로 빌드
  3. 일반 파일로 제공
  4. 페이지

페이지에 보이는 것

<meta name="generator" content="Hugo …">홈페이지만

확인 결과Hugo유력

각 시스템이 방문자가 받는 HTML에 무엇을 남기는지 보여 줍니다. W3Techs는 네 가지 모두를 조사에서 CMS로 집계하지만, 확인 도구가 이름을 댈 수 있는 것은 흔적을 남기는 것뿐입니다.

사이트의 WordPress 테마와 플러그인은 어떻게 확인하나요?

페이지의 파일 경로에 있는 폴더 이름을 읽으면 됩니다. WordPress 테마 확인 도구는 /wp-content/themes/<name>/에서 테마 폴더를 찾은 뒤 그 테마의 style.css를 엽니다. 이 파일의 헤더에는 테마 이름, 제작자, 버전, 그리고 자식 테마라면 부모 테마가 적혀 있습니다.

이 헤더는 테마의 신분증으로, WordPress 테마 핸드북에 정의되어 있습니다. 자식 테마는 Template:에 부모 테마의 폴더를 적으므로 한 페이지에 테마 두 개가 보일 수 있습니다. 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에 아무것도 남기지 않으므로, 사이트의 모든 플러그인을 나열할 수 있는 확인 도구는 없습니다.

테마 한 쌍과 플러그인 폴더 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부모 폴더
/wp-content/themes/genesis/style.css

부모 테마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을 알려 줍니다. ?ver= 값 세 개 중 하나는 플러그인의 버전, 하나는 포함된 라이브러리의 버전, 하나는 타임스탬프입니다.

스토어가 쓰는 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 쿠키 같은 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: 고객에게 보이는 게시된 테마

스토어 세 곳, 테마 세 종류

스토어스토어에서의 이름기반 테마테마 스토어
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의 흔적이 없기 때문입니다. 대부분은 네 가지 경우에 해당합니다.

어떤 경우인지 보이면 알려 드립니다. 사이트 대신 받은 봇 확인 페이지, CMS 흔적이 없는 프레임워크, 사이트 소유자가 꺼 둔 흔적, 또는 사이트의 나머지 부분과 다른 시스템으로 돌아가는 페이지입니다.

그리고 정말로 CMS가 없는 경우도 있습니다. W3Techs는 웹사이트의 32.1%에서 자신이 인식하는 CMS를 찾지 못하므로, 세 사이트 중 한 곳 정도에서 아무것도 찾지 못하는 확인 도구는 정상적으로 작동하는 것입니다.

실제 원인 네 가지 · 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이 돌아갑니다. 저희는 URL 하나를 확인하므로, 쇼핑몰이나 블로그 섹션을 포함해 원하는 페이지를 붙여 넣으세요.

각 카드의 띠는 도구와 같은 종류의 읽기를 작게 그린 것입니다. 흔적이 어디에 있었고, 무엇이 빠져 있었는지 보여 줍니다.

브라우저 스캔은 일반 확인이 놓치는 무엇을 찾나요?

HTML 이후에 도착하는 모든 것입니다. 태그 관리자가 추가하는 태그, 분석 및 광고 픽셀, 채팅과 동의 관리 도구, JavaScript가 실행되어야 비로소 생기는 스크립트 등입니다. allbirds.com에서는 실제 Chrome이 페이지 HTML만 읽어서는 놓친 기술 15개를 찾아냈습니다.

일반 확인은 서버가 보내는 것을 읽습니다. 빠르고, 플랫폼, 테마, 기술 스택 대부분을 보여 줍니다. 브라우저 스캔은 Chrome에서 페이지를 몇 초 동안 불러와 스크립트를 실행시키고, 스크립트가 불러오는 것을 읽습니다.

다섯 개 사이트로 시험한 결과, 브라우저는 서버 읽기에서 찾은 기술을 한 번도 놓치지 않았고, 추가로 찾은 기술은 2개(Wikipedia)에서 27개(TechCrunch)였습니다. 태그 관리자로 운영되는 사이트일수록 많이 늘어나고, 단순한 위키 페이지는 거의 변하지 않습니다.

서버 읽기와 실제 브라우저 · 사이트 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으로 한 번씩 불러와(로드 후 3초 추가) HTML과 같은 규칙으로 대조했습니다. 개수는 동의 배너, 지역, 시간에 따라 달라집니다. 브라우저에서만 찾은 것 중 일부는 더 정교한 규칙이라면 읽을 수 있는 흔적을 남깁니다. Shop Pay의 프리로드 스크립트는 allbirds.com의 HTML에 있습니다.

웹사이트가 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 }}끄는 방법끌 수 없음여전히 보이는 것모든 페이지의 스크립트와 쿠키_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일).

웹사이트 취약점 점검 도구인가요?

수동적(패시브)인 점검 도구입니다. 사이트가 헤더, 페이지, 브라우저 스캔에서 보여 주는 정확한 버전마다 해당 버전에 적용되는 공개된 보안 권고(CVE 포함)를 OSV.dev에서(파일로 찾은 JavaScript 라이브러리는 Retire.js에서), 릴리스 라인 지원 현황을 endoflife.date에서 가져와 PHP2Shell 같은 저희 자체 공지와 함께 나열합니다. 프로브나 공격 요청은 절대 보내지 않습니다.

버전 번호에는 한계가 있습니다. Linux 배포판의 패키지는 오래된 번호 그대로 백포트된 수정을 담고 있을 수 있고, 보안 권고가 사이트에서 쓰지 않는 기능을 전제로 할 수도 있으며, 많은 사이트가 버전을 숨깁니다. 그래서 답은 버전에 대한 사실(“Next.js 14.1.0에 해당하는 공개된 보안 권고 36건”)만 나열하고, 사이트가 취약하다고는 절대 말하지 않습니다.

Cloudflare 뒤에서는 Server 헤더가 “cloudflare”로 표시되어 웹 서버 자체의 버전은 보이지 않지만, 사이트의 다른 헤더는 그대로 전달됩니다. X-Powered-By의 PHP 버전은 여전히 보입니다. 자신의 사이트를 제대로 점검하려면, 그 사이트에 실행해도 된다는 허가를 받은 취약점 스캐너를 사용하세요.

버전에서 세 가지 답으로 · 실제 패턴 세 가지, 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: cloudflare웹 서버 버전: 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의 보안 권고(두 데이터베이스에 실린 결함은 한 번만 셉니다), endoflife.date의 지원 기간, 저희 자체 공지입니다. 대시는 해당 출처가 그 제품을 다루지 않는다는 뜻입니다. 호스트 이름은 가상이지만, 패턴과 답은 실제입니다.

BuiltWith, Wappalyzer, WhatCMS와 비교하면?

BuiltWith는 자체 웹 인덱스에서 답하고, Wappalyzer는 최근 30일 이내에 검증된 결과나 조회 5회로 계산되는 실시간 읽기를 제공하며, WhatCMS는 페이지를 실시간으로 읽지만 최근 조회 목록을 홈페이지에 올립니다. CMS 확인과 웹사이트 기술 확인을 함께 하는 이 도구는 입력한 페이지를 지금 읽고, 각 답의 근거가 된 줄을 보여 줍니다.

인덱스는 이력을 보기에 좋습니다. BuiltWith의 API는 도메인을 마지막으로 인덱싱한 시점을 알려 줍니다. 실시간 읽기는 붙여 넣은 바로 그 페이지를 지금 상태로 보여 주며, 쇼핑몰이나 블로그 하위 폴더도 포함됩니다.

무료 사용 범위도 다릅니다. Wappalyzer는 계정이 있으면 월 50회 조회, BuiltWith는 단일 사이트 조회가 무료, WhatCMS의 무료 API 요금제는 월 500회 감지이며 비공개 조회는 월 $40부터입니다. 이 페이지는 계정이 필요 없고 아무것도 공개하지 않습니다.

“이 사이트는 무엇으로 만들었나?”에 답하는 네 가지 방법 · 2026년 10월 24일

DNS Robot이 페이지

답의 출처
붙여 넣은 페이지를 지금 읽고, 각 답의 근거가 된 줄을 표시
무료 사용
계정 불필요, 아무것도 공개하지 않음
알아 둘 점
요청 시 실제 브라우저 스캔

BuiltWith

답의 출처
검색 엔진처럼 크롤링한 자체 웹 인덱스
무료 사용
단일 사이트 조회
알아 둘 점
API가 도메인을 마지막으로 인덱싱한 시점을 알려 줌

Wappalyzer

답의 출처
30일 이내에 검증된 결과 또는 실시간 읽기
무료 사용
계정이 있으면 월 50회 조회
알아 둘 점
실시간 결과는 조회 5회로 계산

WhatCMS

답의 출처
요청할 때 가져온 페이지
무료 사용
API: 월 500회 감지
알아 둘 점
최근 조회를 홈페이지에 나열, 비공개 조회는 월 $40부터
2026년 10월 24일 각 도구의 자체 페이지에서 가져왔습니다. 요금제는 바뀌므로 선택하기 전에 각 도구의 페이지를 확인하세요.

CMS 확인: 자주 묻는 질문

웹사이트 CMS 확인은 어떻게 하나요?

위의 CMS 확인 도구에 사이트 주소를 붙여 넣으세요. 페이지의 헤더, 쿠키, 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”가 되어 웹 서버 자체의 버전을 가립니다. 예외는 봇 확인입니다. Cloudflare나 다른 방화벽이 사이트 대신 챌린지 페이지로 응답하면 확인이 차단되었다고 알려 드리며, 브라우저 스캔은 통과할 수도 있습니다.

CMS 확인 도구마다 결과가 다른 이유는 무엇인가요?

서로 다른 것을 다른 시점에 읽기 때문입니다. BuiltWith는 자체 웹 인덱스에서 답하고 Wappalyzer의 캐시된 결과는 최대 30일 전 것일 수 있지만, 실시간 도구는 지금 페이지를 읽습니다. 도구마다 다른 페이지를 확인하거나 다른 규칙을 쓰거나, 사이트 대신 봇 확인 페이지를 받을 수도 있습니다. 그래서 저희의 모든 답에는 근거가 된 줄을 보여 드립니다.

이 CMS 확인 도구는 얼마나 정확한가요?

모든 답에는 근거와 세 가지 라벨 중 하나가 붙습니다. 확인됨은 서로 독립된 신호 두 개, 또는 그 플랫폼 고유의 헤더, 쿠키, 파일 경로처럼 그 플랫폼만 만드는 신호 하나가 있다는 뜻입니다. 유력은 generator 태그처럼 누구나 복사하거나 지울 수 있는 신호 하나입니다. 가능성 있음은 이미지 호스트 같은 간접적인 단서입니다. 차단되었거나 빈 페이지는 그대로 알려 드리며, “CMS 없음”으로 표시하지 않습니다.

CMS 버전이 표시되지 않는 이유는 무엇인가요?

많은 플랫폼이 버전을 출력하지 않기 때문입니다. Joomla는 기본적으로 버전을 숨기고, Drupal의 헤더는 메이저 버전만, Ghost는 메이저와 마이너 버전만 보여 줍니다. WordPress는 소유자가 지우지 않는 한 정확한 버전을 출력하며, 파일 주소에도 ?ver=로 남아 있는 경우가 많습니다. 저희는 페이지의 신호가 실제로 담고 있는 버전만 보여 드리며, 어디서 찾았는지도 알려 드립니다.

웹사이트의 알려진 취약점(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의 네트워크에서 페이지를 불러옵니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

관련 도구