New format
How to tell a site’s CMS: code, clues, and tools
Knowing a competitor’s or another project’s CMS helps estimate the stack, plugins, and typical SEO limits. That’s open-signal reconnaissance — not hacking.
Below: manual code review, what to check in robots and URLs, online detectors, and why “nothing found” often means custom code or a well-hidden generator. For a nearby WP article without the `-2` suffix, treat this as the canon.
Manual HTML review
Open the source (View Source / Ctrl+U). Look for `meta name="generator"`, paths `/wp-content/`, `/bitrix/`, `/skin/frontend/`, template comments, typical body classes.
In DevTools → Network check static URLs: `wp-includes`, `catalog/view/theme`, `tildacdn` and similar. One marker isn’t proof — collect matches.
Quick Ctrl+F:
- `generator`
- `wp-content` / `wp-includes`
- `bitrix`
- `opencart` / `catalog/view`
- `tilda`, `wix`, `shopify`
URL, robots, and headers
`/robots.txt` and the sitemap sometimes contain admin paths or system directories. Pretty URLs like `/index.php?route=` hint at OpenCart; `/blog/2020/05/post/` often WP — but not always.
`X-Powered-By`, cookie names, login redirects — extra clues. Don’t mix up the web server (nginx) with the CMS.
What to record:
- public paths from robots
- product/article URL pattern
- cookie names in Application
- login/admin response without password guessing — only that a public URL exists if it’s open
Online tools and extensions
Detectors (WhatCMS, BuiltWith, Wappalyzer and similar) speed screening: CMS, CDN, analytics, JS frameworks. Results diverge — cross-check.
Browser extensions help across a series of sites. Don’t rely on one verdict for a client contract.
Practical tips:
- run the URL in 1–2 tools
- confirm with code markers
- record a version only if it’s explicit
- don’t scan the admin with vulnerability scanners “while you’re at it”
Typical markers of popular systems
WordPress: `/wp-content/`, `/wp-json/`, sometimes generator. 1C-Bitrix: `/bitrix/`, `BITRIX_*` cookies. OpenCart: `route=product/`, themes in `catalog/view`. Joomla: `/components/`, `/media/jui/`. Tilda: `tildacdn.com`, `t-` classes.
Remember:
- markers get faked and stripped
- multisite and headless confuse detection
- CMS version in generator meta can be stale
- plugins ≠ proof of the core, but strengthen the hypothesis
Ethics and boundaries
The goal is to understand the platform for analysis and scoping. Don’t use CMS knowledge to hunt holes, guess passwords, or attack. For your own site, check the admin and hosting docs — more reliable than any detector.
In a client report write: “markers X look like Y; confirm with access.”
Recon checklist:
- View Source + Network
- robots/sitemap
- 1–2 external detectors
- CMS hypothesis + confidence
- no vulnerability scans
FAQ
Why know the CMS?
To understand URL templates, typical SEO modules, how fast edits go live, and risks (outdated plugins). For a bid — estimate work complexity.
Is it legal?
Reading public HTML and headers is normal practice. Breaking into admin, brute force, and exploits are not.
Is meta generator always there?
No. WordPress and others often disable it. Missing generator doesn’t mean “not a CMS.”
Which CMS get detected most?
WordPress, Bitrix, OpenCart, Joomla, MODX, Tilda/builders — via asset paths and typical markers.
Do tools get it wrong?
Yes. Cross-check two sources and the code by eye. Custom Laravel/Next may show as “unknown.”
Does robots.txt help?
Sometimes: `/wp-admin`, `/bitrix/`, `/catalog/` paths reveal the ecosystem. Not always.
What do cookies show?
Names like `PHPSESSID`, `BITRIX_SM_…`, `wp-settings-` are hints, not a verdict.
What if nothing is visible?
Likely custom, headless, or heavily cleaned markers. Then look at the stack via JS bundles and server headers — carefully, without vulnerability scanning.
Need the stack for a bid — and detectors disagree while generator is stripped?
We’ll cross-check public HTML markers only — recon for scoping, not admin attacks.
Discuss the task
