CMS Detector

Beyond the CMS name, the tool shows the evidence: what was found and where, in the markup, response headers, cookies or robots.txt. You can verify it yourself.

With or without https://, Cyrillic domains are supported. We look at the home page and robots.txt: engine traces survive longer in that file than in the markup.

A plain check names the engine and stops there. You cannot confirm the answer, because the clue it was built on stays hidden. This tool shows the evidence next to the verdict: what it found and where, whether in the page source, a server response header, a cookie name, or a line in robots.txt. Any of these clues can be checked by hand in a minute.

Page markup changes most often: templates get redesigned, the generator meta tag gets removed, files get moved. A header like X-Powered-CMS, a cookie with a recognizable name, or a disallowed service folder in robots.txt tends to stay in place for years. That is why the clues come from the page source, headers, cookies, and robots.txt all at once.

Every clue carries a weight: the engine signature in a meta tag weighs more than a folder that several systems share. The percentage next to the answer is the sum of those weights, not a guess. When a single weak clue matches, there is no verdict: a match like that is shown separately as a weak one.

Some sites serve robots not the real page but a browser check or a blank skeleton that a script assembles. In that case the tool says so directly: the site did not show its page. That is more honest than an answer of "no engine found", which would suggest the site had actually been checked.

Frameworks, the server-side stack, analytics counters, chat widgets, and the web server delivering the page get collected alongside the engine. They do not count toward the verdict: a site running a ready-made engine with its own framework on top is a common thing, and there is nothing to argue about.

Rate this tool

Help us get better

Other tools