CMS detection is an informed guess until verified
Caches, CDNs, security tools, headless front ends and custom builds can hide or imitate familiar signatures. Use public clues for orientation, then confirm through authorised hosting or application access.
Public checks
Inspect the page without probing the server
- Open the page source and look for generator metadata, asset paths and script names.
- Review links to stylesheets, JavaScript and images for platform-specific directories.
- Check response headers and cookies in browser developer tools, remembering that sites can remove or rename them.
- Look at the login or administration link only when it is already public; do not attempt passwords or enumerate accounts.
- Compare several independent clues before naming a platform.
Common signatures
Recognise typical, not definitive, patterns
- WordPress
- Paths such as /wp-content/ or /wp-includes/, WordPress REST links and familiar plugin assets.
- Joomla
- Joomla media, component or template paths and related generator metadata.
- Drupal
- Drupal-specific assets, settings, modules or cache headers.
- Hosted builders
- Provider CDN hostnames, generated asset bundles or platform scripts may identify Wix, Squarespace, Shopify or similar services.
- Static or custom site
- No CMS signature may mean static files, a custom framework, a headless CMS or simply well-hidden metadata.
- Reverse proxy
- The visible front end may not reveal the origin application at all.
Your UKC-hosted website
Confirm from Plesk and the file system
- WP Toolkit lists detected WordPress installations and their document roots.
- Applications may list software installed through Plesk.
- Files such as wp-config.php, configuration.php or settings.php can confirm the application.
- Database names and tables can support the identification, but inspect only the intended subscription.
- The document root confirms which installation serves the hostname.
Do not turn identification into vulnerability scanning
Publicly identifying a likely CMS does not authorise aggressive version enumeration, login attempts or security testing. Scan only systems you own or have explicit permission to assess.
Use the result correctly
Plan the next task, not an SEO shortcut
- Website migration
- Confirm application, version, database, extensions, PHP requirements and storage before quoting or copying.
- Security update
- Use authorised panel access to identify the exact version and installed components.
- Performance review
- Measure the actual page and request waterfall; a platform name alone does not explain speed.
- SEO review
- Assess crawlability, content, structured data and page experience rather than judging the CMS brand.
Need UKC to identify an installation?
Send the domain, hosting service, reason for checking and any authorised panel or migration context. Do not send application, database or Plesk passwords in the ticket.
Ask the Hosting team