Is It WP? WordPress Detector

What Is The Is It WP Tool?

Is It WP is a WordPress detector that checks whether a public website exposes recognizable evidence of WordPress. Instead of relying on one copied string, ClockTools compares independent signals from the returned HTML, HTTP headers, official REST API discovery, the core wp/v2 namespace, wp-content and wp-includes asset paths, core script names, publishing links, response cookies, and pingback headers. The result keeps the verdict beside the evidence so a user can see exactly what was found and what remained unavailable.

The tool answers more than the narrow question is this site WordPress. It shows a transparent WordPress signal score, any public version clue, the final URL after redirects, the HTTP response, the amount of HTML inspected, detected theme and plugin slugs, public theme stylesheet metadata, REST namespaces, and the edge that handled the check. That evidence can help developers study a public stack, agencies review a migration, owners check accidental disclosure, and researchers compare content platforms without signing into the target.

Technology detection has an important boundary. A public page can be cached, proxied, exported as static HTML, transformed by a CDN, or served by a headless frontend. Security tools can remove ordinary WordPress paths and metadata. A no-signal result therefore means that the checked response did not expose a recognized clue at that moment. It cannot prove that WordPress is absent from every private backend, origin, build process, or content pipeline connected to the site.

Which Signals Can Confirm WordPress?

The strongest machine-readable signal is a WordPress REST API index that publishes the core wp/v2 namespace or core routes. WordPress describes its REST API as distributed because each supporting site exposes its own API. The platform also defines an official discovery relation named https://api.w.org/. That relation can be published in an HTML link element or an HTTP Link header and can point a client to the correct API root even when the installation does not use the obvious root URL.

Generator metadata that explicitly names WordPress is another strong signal and may include a public version. Many site owners and security plugins remove it, so absence is ordinary and not negative proof. Public resources under wp-content and wp-includes provide independent supporting evidence. Recognizable core scripts such as the WordPress emoji, embed, hooks, internationalization, or polyfill files make an asset-path finding more specific than a random sentence that merely mentions WordPress.

Traditional publishing clues add smaller weights. An RSD link can point toward xmlrpc.php, a Windows Live Writer manifest can identify a familiar publishing setup, an X-Pingback header can advertise XML-RPC, and anonymous response cookies can use WordPress, wp-settings, or WooCommerce prefixes. Each clue can be disabled, renamed, cached, or copied, so ClockTools never lets one weak header decide the entire verdict. Independent evidence is more useful than one brittle signature.

How Does The WordPress Theme Detector Work?

WordPress themes often expose public files below /wp-content/themes/theme-slug/. ClockTools collects those resource references from the checked HTML, groups them by slug, and counts how many public assets point to each directory. A site can legitimately expose more than one theme slug when a child theme depends on a parent theme, when an old cached asset remains, or when a component loads a resource from another theme directory. The raw public slug remains separate from a verified display name.

For the strongest theme candidate, the detector requests the conventional public style.css in that same directory. A WordPress theme stylesheet can declare Theme Name, Theme URI, Description, Author, Version, Template, and Text Domain in its header. The Template field usually names the parent theme used by a child theme. ClockTools displays these fields only when the stylesheet returns them and does not convert a friendly-looking slug into invented metadata.

Theme detection can fail without meaning that WordPress is absent. Build tools can bundle CSS into hashed files, optimization plugins can combine resources, a CDN can rewrite origins and paths, a custom theme can omit public metadata, and a reverse proxy can remove WordPress directory names. Some block themes also rely on different frontend assets than a classic theme. The result should be read as public theme evidence from one page, not an authenticated inventory of files installed on the server.

What Can The WordPress Plugin Detector Find?

Frontend plugins commonly load JavaScript, CSS, images, fonts, or other assets from /wp-content/plugins/plugin-slug/. Must-use plugins can expose files under /wp-content/mu-plugins/. ClockTools extracts unique public slugs, retains an asset-reference count, and lists regular and must-use locations separately in its JSON evidence. This can reveal visible page builders, form tools, commerce features, analytics integrations, optimization layers, or other frontend components without guessing a product from the visual design.

A plugin asset slug is not a complete plugin inventory. Backend-only plugins, inactive plugins, command-line tools, server integrations, plugins without frontend assets, renamed directories, combined bundles, CDN transforms, and custom deployments can remain invisible. A cached reference can also survive briefly after a plugin changes. REST namespaces may offer additional technology clues, but ClockTools does not automatically call each namespace a plugin because a theme or custom site code can register routes too.

The detector is not a vulnerability scanner. It does not enumerate users, attempt authentication, submit login forms, test passwords, execute exploits, crawl administration paths, or compare every slug and version against a vulnerability database. An owner should verify installed and active components inside the authenticated WordPress administration area, keep supported software updated, review backups, and use an authorized security workflow for risk assessment.

What Does The WordPress Signal Score Mean?

The score is a transparent evidence weight from zero to one hundred, not a statistical probability and not a measure of WordPress market share. A confirmed core REST namespace contributes more than a pingback header. Explicit generator metadata contributes more than a general publishing link. Several asset, API, and header clues can reinforce one another until the evidence reaches a confirmed verdict. The ledger shows the status and explanation for every signal so the number is auditable.

WordPress confirmed means that strong machine-readable evidence or several independent public signals identify the platform. WordPress likely means that meaningful supporting evidence exists but a decisive core signal was unavailable. Detection inconclusive means that a restricted, failed, partial, or ambiguous response does not support a safe answer. No public WordPress signals found means that the checked responses exposed no recognized clues; hidden, hardened, proxied, cached, exported, or headless WordPress remains possible.

A score of zero must be interpreted carefully. It does not mean there is a zero-percent chance of WordPress. It only records that no weighted signal was found in the bounded public requests. Conversely, a high score does not prove who owns the site, whether WordPress is current, whether every visible plugin is active, or whether the installation is secure. The score organizes technology evidence rather than replacing direct access to the system an owner controls.

Why Can Hardened Or Headless WordPress Be Missed?

A hardened installation can remove generator metadata, disable pingbacks, restrict the REST index, rename content paths, block anonymous automation, and put resources behind a CDN. A web application firewall may return a challenge or 403 response to the ClockTools edge while a normal visitor receives the full page. A cache can serve a transformed document that contains fewer origin details. Those controls change public evidence without necessarily changing the content management system.

A headless WordPress architecture creates a deeper separation. The visible website may be rendered by React, Next.js, Astro, another framework, a native application, or an edge service. WordPress may provide content during a build, through a private API, from another hostname, or behind a proxy. Checking the public frontend reveals what that frontend discloses; it cannot identify a private content service that is never referenced publicly. A static export may also contain content originally authored in WordPress while no live WordPress application serves the page.

Custom and multisite installations introduce more variation. WordPress can live in a subdirectory, use domain mapping, serve media from another hostname, expose an API at a discovered route, or place theme and plugin assets behind a shared content domain. ClockTools uses the official API relation when published and derives a conventional API root from visible content paths, but it deliberately limits requests instead of brute-forcing every common location.

Is An Exposed WordPress Version A Security Result?

No. A disclosed version is inventory evidence rather than a vulnerability finding. ClockTools reads a version only when generator metadata or the REST API generator explicitly names WordPress and supplies a version. It does not guess the core version from arbitrary ?ver= query parameters on scripts and styles because those values can describe a theme, plugin, build, cache, or unrelated release. Avoiding a guess is more useful than displaying a precise but false version.

A visible current version does not prove that plugins, themes, credentials, permissions, hosting, backups, or custom code are secure. A hidden version does not prove security either. Owners should use authenticated update management, WordPress Site Health, tested backups, monitoring, least-privilege access, multifactor authentication, and an authorized security assessment. Technology detection can identify public exposure, but it cannot evaluate the full security posture from one anonymous page.

How Are Privacy, Safety, And Request Limits Handled?

The website address reaches the ClockTools Worker because an external page cannot be inspected reliably from every browser. API responses are marked no-store, and only a short optional recent list is kept in local browser storage. Browser cookies, authorization headers, login sessions, and credentials are never forwarded. Query strings are removed before the target request to reduce the chance of sending a signed parameter, personal identifier, campaign token, or accidental secret.

The detector fetches the submitted public page, one REST index candidate, and at most one public theme stylesheet. Each body has a strict byte limit, each operation shares a deadline, and redirect depth is capped. Every redirect hostname is checked through public DNS again. Localhost, private networks, reserved addresses, malformed hosts, credential-bearing targets, unsupported schemes, loops, and unsafe redirect destinations are blocked before an outbound request is allowed.

Use the tool only for public websites. Do not submit private dashboards, reset links, preview links, signed downloads, access tokens, intranet hosts, or personal identifiers. The detector does not grant permission to test a system, bypass controls, or scan for vulnerabilities. If a target blocks anonymous requests, the honest result is restricted or inconclusive. ClockTools does not evade the control or repeatedly mutate the target.