What is this site built with?
Enter an address: from the home page code and response headers we identify the CMS or site builder, the server and protection, and the analytics in use. For every finding we show the evidence.
How we identify the platform
We load the site's home page the way a regular visitor does and look for the traces every CMS and site builder leaves. We do not request other pages or probe anything: we only look at what the site shows to everyone.
- The generator meta tag. Many CMSs write their name and version right into the code: “WordPress 6.6”, “Joomla! 4”.
- File paths. WordPress uses /wp-content/, Bitrix uses /bitrix/templates/, Tilda loads files from tildacdn.com.
- Response headers. X-Powered-By, X-Generator, Server and CDN service headers.
- Cookies. Cookie names give the platform away: BITRIX_SM_ for Bitrix, laravel_session for Laravel.
We rate each finding by the number and strength of clues as “certain”, “likely” or “possible”, and show the clues themselves so you can verify the result.
When the platform stays hidden
Identifying the platform does not always work. Custom-built sites often leave no familiar traces. Experienced administrators hide the CMS version and rename system folders. If bot protection sits in front of the site, it may give us a challenge page instead of the real home page: then there are hardly any clues, and we will say so.
The opposite happens too: a third-party widget or script can look like a sign of another platform. That is why weak findings are marked “possible”.
Server, CDN and analytics
Besides the platform, we show what sits in front of the site and what the page loads. The Server header names the web server: nginx, Apache, LiteSpeed. Service headers and cookies reveal the CDN and DDoS protection: Cloudflare, Qrator, DDoS-Guard, Variti. When a site sits behind such protection, its real server is hidden and the answers come from the protection's nodes.
The X-Powered-By header often states the language and version, for example PHP/7.4. That alone is not a vulnerability, but an outdated PHP no longer receives security fixes, which is a reason to plan an upgrade.
The analytics block lists the counters and widgets the page loads: Yandex Metrica, Google Analytics, Tag Manager, Top.Mail.Ru, live chats and call tracking. It is handy for checking your own site after a move: are all the counters in place, and is there leftover code from a service you stopped using long ago that only slows loading down?
Why it is worth knowing
- Before buying or taking over a site. The platform decides who can maintain it and what changes and licences cost.
- When the developer has disappeared. You know which specialist to look for and where to start.
- To size up competitors. What their shop is built on, which analytics they use, their hosting and protection.
- For security. A visible PHP or CMS version tells bots which vulnerabilities to try. Outdated versions should be upgraded and version headers hidden.
What to do with the result
If the site runs on WordPress or Bitrix, start by checking when the core and plugins were last updated and whether backups exist. If it is on a site builder that no longer fits, it can move to its own code while keeping the design and page URLs. If the site is custom-built and undocumented, begin with an audit: it shows what state the code is in and what it takes to maintain.
Questions.
How accurate is the detection?
Do you scan the site?
Why didn't you find the platform when I know what the site uses?
Is it dangerous that the PHP or CMS version is visible?
Do you detect plugins and themes?
Need someone to maintain or rebuild the site?
We support sites on WordPress, 1C-Bitrix, Tilda and custom code: updates, backups, monitoring and improvements. If a site builder has become too limiting, we move the site to its own code.