Website Intelligence — Like WhatCMS.org

Website & CMS Analyzer

Detect CMS with version number, web server, programming language, database, social media profiles, DNS records, domain owner, SSL & full technology stack — exactly like WhatCMS.org. Enter any domain for a complete technical profile in seconds.

CMS + Version
Server + Language
Social Media Profiles
DNS + WHOIS
SSL + Security

What's Actually Running Behind Any Website?

How tech stack detection works, and why it matters for developers, marketers and security researchers

Before You Analyze
Every Website Leaves a Technical Fingerprint

Behind every website's visual design sits a stack of technical decisions — which CMS powers the content, which server handles requests, which language runs the backend, which database stores the data. None of this is visible to a typical visitor, but almost all of it leaves traces in the HTML source code and HTTP response headers, which is exactly what tools like Wappalyzer and WhatCMS.org are built to read.

What does this analyzer do? Enter any domain and it fetches the live HTML through a CORS proxy, then scans that HTML and the HTTP response headers against a database of regex fingerprints for over 50 technologies — CMS platforms, web servers, programming languages, databases, JavaScript frameworks and analytics tools. Alongside the tech stack, it pulls DNS records via Cloudflare's public DoH API, domain ownership via rdap.org WHOIS, and checks security headers like HSTS and CSP directly from the response.

Why does this matter? Developers use stack detection to understand competitor architecture before a rebuild, or to sanity-check a client's existing site before a migration. Marketers use CMS detection to qualify leads for platform-specific services (a WordPress agency wants to know who's running WordPress). Security researchers use version detection to identify outdated, vulnerable software — an exposed WordPress version number is often the first thing a vulnerability scanner checks. Procurement teams use it to verify vendor claims about a site's technology before signing a contract.

Who should use this tool? Web developers scoping a redesign or migration project. Digital marketers and SEO consultants qualifying prospects by platform. Security-conscious site owners checking their own exposed version numbers. Researchers and journalists investigating who operates a given domain. Anyone curious what technology stack their favourite website runs on.

Real-life example: Analyzing a typical small business website might reveal: WordPress 6.4.2 (CMS), Apache 2.4.58 (server), PHP 8.1 (language), MySQL (database, inferred), Elementor (page builder plugin), and Google Analytics (tracking) — plus three social media profiles found in the footer HTML and an SPF record confirming the domain sends email through Google Workspace. That's a complete technical profile assembled in under ten seconds, the kind of audit that would otherwise require manually viewing page source and running separate DNS lookup tools.

Important limitations: This analyzer reads static HTML fetched through a public CORS proxy — it cannot execute JavaScript, so frameworks or social widgets injected dynamically after page load may be missed. Site administrators who deliberately strip version-revealing meta tags (a recommended WordPress security practice) will show as "version unknown" rather than a false number. WHOIS data may be redacted by privacy protection services. Always treat results as a strong indicator, not a guaranteed exhaustive inventory — particularly for heavily JavaScript-rendered single-page applications.

Why This Analyzer is Better
Version detection — not just "WordPress" but the exact version number
50+ technologies — CMS, server, language, database, frameworks, analytics
Social profile extraction — direct links to Facebook, LinkedIn, Twitter and more
DNS + WHOIS + Security — full domain profile, not just tech stack
Plain-English explanations — every detected technology comes with context
No sign-up, no API key — completely free, instant results
👨‍💻
Developers
Scope migrations and rebuilds with confidence
📊
Marketers
Qualify prospects by their existing platform
🔒
Security Researchers
Spot outdated software and exposed versions

Website & CMS Analyzer — CMS Version, Server, Language, Social Media & More

Fetches real HTML to detect CMS version, PHP version, Apache/Nginx, MySQL, social media profiles & 50+ technologies

How it works: This tool fetches the website's actual HTML source through a CORS proxy and analyzes it using regex fingerprints — the same technique used by WhatCMS.org and Wappalyzer. Results include CMS with version, server, language, database, and social media links found in the HTML.
https://
Try:
wordpress.org
joomla.org
drupal.org
techcrunch.com
wikipedia.org
github.com
Analyzing website…
Fetching website HTML source
Detecting CMS & version
Identifying server & language
Extracting social media profiles
Fetching DNS & WHOIS
Security & SSL check
Connecting to proxy…
🌐
Technology Stack — CMS, Server, Language, Database
Detecting…
Analyzing…
Social Media Profiles Found in Website HTML
Scanning…
Scanning for social links…
DNS Records — A, MX, NS, TXT, CNAME, AAAA
Fetching…
Fetching DNS…
Security Headers & SSL Analysis
Checking…
Checking security…
Domain Owner & WHOIS Information
Looking up…
Looking up WHOIS…
Share This Analysis

How the Analyzer Detects CMS Version, Language & Social Media Profiles

The same detection methods used by WhatCMS.org and Wappalyzer

🔍
CMS & Version Detection
The HTML is scanned for <meta name="generator"> tags which contain the exact CMS name and version (e.g. WordPress 6.8.5). WordPress is also confirmed by /wp-content/ paths and versioned script URLs. Joomla, Drupal, Ghost, and 25+ other platforms have unique HTML/path signatures.
🖥️
Server, Language & Database
HTTP response headers contain: Server: Apache/2.4.62 (web server + version), X-Powered-By: PHP/8.2.0 (language). Database is inferred: WordPress → MySQL, Django → PostgreSQL/MySQL, Rails → PostgreSQL. This is exactly how WhatCMS.org detects PHP and MySQL for WordPress sites.
📱
Social Media Profile Extraction
All anchor <a href> links are scanned for known social domains: facebook.com/, linkedin.com/company/, twitter.com/, instagram.com/, youtube.com/, etc. The profile handle is extracted with regex. This gives you the exact profile name and direct URL — exactly what WhatCMS.org shows in its Social Media section.
🌐
DNS, WHOIS & Security
DNS records (A, MX, NS, TXT) are fetched via Cloudflare's public DoH API. WHOIS/domain owner data comes from rdap.org. Security headers (HSTS, CSP, X-Frame-Options) come directly from HTTP response headers. SPF and DMARC are extracted from DNS TXT records. All APIs are public, CORS-safe, and require no API key.

FAQ — How It Compares to WhatCMS.org

Common questions about CMS detection, version numbers, and social media profile finding

Why might the CMS version not show?
CMS versions are most reliably found in the <meta name="generator"> tag. However, many site administrators deliberately remove this tag for security reasons (WordPress security guides recommend hiding the version). When the meta tag is absent, version is estimated from script URL version parameters (?ver=6.x). If a site hides all version info, the CMS name is still detected but shown as "version unknown."
Why are some social media profiles missing?
Social media links are only detected if they appear in the website's main HTML source. Sites that load social buttons via JavaScript after page load (dynamically injected), or that place social links only in the footer loaded via AJAX, may not have their profiles detected. Also, some sites use shortened URLs or social share buttons without direct profile links. WhatCMS.org uses a full browser-rendered scan; our analyzer works on the static HTML source, which is why it may miss some dynamically loaded profiles.
Why does it show PHP for WordPress when PHP isn't in the URL?
PHP is the server-side language WordPress is built with, even if your URLs don't end in .php (WordPress uses mod_rewrite to create pretty URLs). The PHP version comes from the X-Powered-By HTTP response header. Similarly, MySQL is inferred because WordPress officially supports only MySQL and MariaDB as its database. This is the same logic Wappalyzer uses — detecting WordPress implies PHP + MySQL as a dependency chain.

6 Mistakes People Make Reading Stack Analysis Results

How to avoid misinterpreting CMS, server and security findings from any tech-detection tool

Avoid These Traps
Reading Results Correctly Matters as Much as Getting Them
Treating "Not Detected" as "Doesn't Exist"
A technology not showing in results often means it wasn't detectable from static HTML — not that it isn't there. JavaScript-rendered frameworks, server-side technologies with no HTML fingerprint, and deliberately hidden version tags all produce "not found" results for tech that's actually present.
Assuming an Outdated Version Means Vulnerable
An old WordPress version number is a strong signal worth investigating, but it doesn't automatically confirm an active vulnerability — many sites apply security patches without bumping the public version display, and some "vulnerabilities" require specific plugin combinations to be exploitable. Treat version findings as a starting point for a security audit, not a conclusion.
Confusing Inferred Tech with Confirmed Tech
Database detection (like "MySQL" for a WordPress site) is usually inferred from the CMS, not directly observed — most databases sit behind the server and leave no HTML trace. This is standard practice for every stack-detection tool, but it's worth knowing that not every line in a tech report was directly fingerprinted; some are dependency-chain assumptions.
Ignoring That CORS Proxies Can Be Rate-Limited
Free public CORS proxies occasionally throttle or block requests during high traffic. A failed or partial analysis sometimes reflects proxy availability rather than anything about the target site. If a scan seems incomplete, trying again after a short wait often resolves it.
Mistaking WHOIS Privacy for Hiding Something Suspicious
A redacted WHOIS record ("Privacy Protected" registrant) is extremely common and used by millions of legitimate domains — most registrars now include privacy protection by default. It's not, on its own, a signal of anything unusual about the site's intent.
Skipping the Security Header Section
It's easy to focus only on the "what CMS is this" question and skip the security headers panel — but missing HSTS, CSP, or X-Frame-Options headers are often more actionable findings than the CMS name itself, especially for site owners auditing their own domain.

About This Tool

How this analyzer was built and where its data comes from

Created by KeeHelper (by Keeroot Solutions)

KeeHelper is a free calculator and analysis platform built by Keeroot Solutions. This analyzer's detection engine uses the same regex-fingerprinting methodology as Wappalyzer (an open-source project whose technology signature format is publicly documented) — scanning HTML markup, script paths, and HTTP response headers against a curated database of 50+ known technology signatures.

DNS resolution uses Cloudflare's public DNS-over-HTTPS API (1.1.1.1), domain ownership data comes from rdap.org — the official RDAP successor to traditional WHOIS, standardised by IETF RFC 7480 — and security header checks read directly from the live HTTP response. No proprietary or paid data sources are used; every API this tool relies on is public and free.

Accuracy Note
Results are based on static HTML analysis and public APIs — they reflect what's detectable, not a guaranteed complete inventory. JavaScript-rendered content, hidden version tags, and WHOIS privacy protection can all limit what's found. Use results as a strong starting indicator for further investigation.
50+
Technologies Detected
5
Analysis Categories
0
Sign-Ups Required