¿Es WP? Detector de WordPress

¿Qué es la herramienta Is It WP?

Is It WP es un detector de WordPress que comprueba si un sitio web público expone evidencia reconocible de WordPress. En lugar de depender de una cadena copiada, ClockTools compara señales independientes de los encabezados HTML, HTTP devueltos, el descubrimiento oficial de la API REST, el espacio de nombres principal wp/v2, wp-content y wp-incluye rutas de activos, nombres de scripts principales, enlaces de publicación, cookies de respuesta y encabezados de pingback. El resultado mantiene el veredicto junto a la evidencia para que el usuario pueda ver exactamente qué se encontró y qué no estaba disponible.

La herramienta responde a más que la pregunta específica es este sitio WordPress. Muestra una puntuación de señal transparente de WordPress, cualquier pista de versión pública, la URL final después de las redirecciones, la respuesta HTTP, la cantidad de HTML inspeccionados, temas detectados y complementos, metadatos de hojas de estilo de temas públicos, espacios de nombres REST y el borde que manejó la verificación. Esa evidencia puede ayudar a los desarrolladores a estudiar una pila pública, a las agencias a revisar una migración, a los propietarios a verificar la divulgación accidental y a los investigadores a comparar plataformas de contenido sin iniciar sesión en el objetivo.

La detección de tecnología tiene un límite importante. Una página pública se puede almacenar en caché, enviar mediante proxy, exportar como estática HTML, transformar mediante una CDN o servir mediante una interfaz sin cabeza. Las herramientas de seguridad pueden eliminar rutas y metadatos comunes de WordPress. Por lo tanto, un resultado sin señal significa que la respuesta comprobada no expuso una pista reconocida en ese momento. No puede probar que WordPress esté ausente de cada backend privado, origen, proceso de construcción o canalización de contenido conectado al sitio.

¿Qué señales pueden confirmar WordPress?

La señal legible por máquina más potente es un índice API REST de WordPress que publica el espacio de nombres o las rutas principales de wp/v2. WordPress describe su API REST como distribuida porque cada sitio de soporte expone su propia API. La plataforma también define una relación de descubrimiento oficial denominada https://api.w.org/. Esa relación se puede publicar en un elemento de enlace HTML o en un encabezado de enlace HTTP y puede señalar a un cliente a la raíz API correcta incluso cuando la instalación no utiliza la URL raíz obvia.

Los metadatos del generador que nombran explícitamente a WordPress son otra señal fuerte y pueden incluir una versión pública. Muchos propietarios de sitios y complementos de seguridad lo eliminan, por lo que su ausencia es una prueba normal y no negativa. Los recursos públicos bajo wp-content y wp-includes proporcionan evidencia de respaldo independiente. Los scripts principales reconocibles, como los emoji de WordPress, los archivos incrustados, los ganchos, la internacionalización o el polyfill, hacen que un hallazgo de ruta de recursos sea más específico que una oración aleatoria que simplemente mencione WordPress.

Las pistas de publicación tradicionales añaden pesos más pequeños. Un enlace RSD puede apuntar hacia xmlrpc.php, un manifiesto de Windows Live Writer puede identificar una configuración de publicación familiar, un encabezado X-Pingback puede anunciar XML-RPC y las cookies de respuesta anónima pueden usar prefijos de WordPress, wp-settings o WooCommerce. Cada pista se puede desactivar, cambiar de nombre, almacenar en caché o copiar, por lo que ClockTools nunca permite que un encabezado débil decida el veredicto completo. La evidencia independiente es más útil que una firma frágil.

¿Cómo funciona el detector de temas de WordPress?

Los temas de WordPress a menudo exponen archivos públicos debajo de /wp-content/themes/theme-slug/. ClockTools recopila esas referencias de recursos del HTML marcado, las agrupa por slug y cuenta cuántos activos públicos apuntan a cada directorio. Un sitio puede exponer legítimamente más de un tema cuando un tema secundario depende de un tema principal, cuando permanece un activo antiguo almacenado en caché o cuando un componente carga un recurso desde otro directorio de temas. La babosa pública sin procesar permanece separada de un nombre para mostrar verificado.

Para el tema candidato más sólido, el detector solicita el style.css público convencional en ese mismo directorio. Una hoja de estilo de tema de WordPress puede declarar el nombre del tema, el URI del tema, la descripción, el autor, la versión, la plantilla y el dominio del texto en su encabezado. El campo Plantilla normalmente nombra el tema principal utilizado por un tema secundario. ClockTools muestra estos campos solo cuando la hoja de estilo los devuelve y no convierte un slug de apariencia amigable en metadatos inventados.

La detección de temas puede fallar sin que signifique que WordPress esté ausente. Las herramientas de compilación pueden agrupar CSS en archivos hash, los complementos de optimización pueden combinar recursos, una CDN puede reescribir orígenes y rutas, un tema personalizado puede omitir metadatos públicos y un proxy inverso puede eliminar nombres de directorios de WordPress. Algunos temas de bloques también se basan en recursos de interfaz diferentes a los de un tema clásico. El resultado debe leerse como evidencia pública del tema de una página, no como un inventario autenticado de archivos instalados en el servidor.

¿Qué puede encontrar el detector de complementos de WordPress?

Los complementos de interfaz comúnmente cargan JavaScript, CSS, imágenes, fuentes u otros activos desde /wp-content/plugins/plugin-slug/. Los complementos imprescindibles pueden exponer archivos en /wp-content/mu-plugins/. ClockTools extrae slugs públicos únicos, retiene un recuento de referencias de activos y enumera ubicaciones habituales y de uso obligatorio por separado en su evidencia JSON. Esto puede revelar creadores de páginas visibles, herramientas de formularios, funciones comerciales, integraciones de análisis, capas de optimización u otros componentes de interfaz sin adivinar un producto a partir del diseño visual.

Un slug de activos de complemento no es un inventario completo de complementos. Los complementos solo de backend, los complementos inactivos, las herramientas de línea de comandos, las integraciones de servidores, los complementos sin activos de frontend, los directorios renombrados, los paquetes combinados, las transformaciones de CDN y las implementaciones personalizadas pueden permanecer invisibles. Una referencia almacenada en caché también puede sobrevivir brevemente después de que cambia un complemento. Los espacios de nombres REST pueden ofrecer pistas tecnológicas adicionales, pero ClockTools no llama automáticamente a cada espacio de nombres un complemento porque un tema o código de sitio personalizado también puede registrar rutas.

El detector no es un escáner de vulnerabilidades. No enumera usuarios, no intenta autenticación, no envía formularios de inicio de sesión, prueba contraseñas, ejecuta exploits, rastrea rutas de administración ni compara cada slug y versión con una base de datos de vulnerabilidades. El propietario debe verificar los componentes instalados y activos dentro del área de administración de WordPress autenticada, mantener actualizado el software compatible, revisar las copias de seguridad y utilizar un flujo de trabajo de seguridad autorizado para la evaluación de riesgos.

¿Qué significa la puntuación de señal de WordPress?

La puntuación es una ponderación de evidencia transparente de cero a cien, no una probabilidad estadística ni una medida de la participación de mercado de WordPress. Un espacio de nombres REST central confirmado aporta más que un encabezado de pingback. Los metadatos explícitos del generador aportan más que un enlace de publicación general. Varias pistas de activos, API y encabezados pueden reforzarse entre sí hasta que la evidencia llegue a un veredicto confirmado. El libro mayor muestra el estado y la explicación de cada señal para que el número sea auditable.

WordPress confirmado significa que pruebas sólidas legibles por máquina o varias señales públicas independientes identifican la plataforma. Es probable que WordPress signifique que existe evidencia de respaldo significativa, pero que no estaba disponible una señal central decisiva. La detección no concluyente significa que una respuesta restringida, fallida, parcial o ambigua no respalda una respuesta segura. No se encontraron señales públicas de WordPress significa que las respuestas verificadas no expusieron pistas reconocidas; WordPress oculto, reforzado, proxy, en caché, exportado o sin cabeza sigue siendo posible.

Una puntuación de cero debe interpretarse con cuidado. Esto no significa que haya cero por ciento de posibilidades de que WordPress. Sólo registra que no se encontró ninguna señal ponderada en las solicitudes del público acotado. Por el contrario, una puntuación alta no prueba quién es el propietario del sitio, si WordPress está actualizado, si todos los complementos visibles están activos o si la instalación es segura. La puntuación organiza la evidencia tecnológica en lugar de reemplazar el acceso directo al sistema que controla un propietario.

¿Por qué se puede pasar por alto WordPress reforzado o sin cabeza?

Una instalación reforzada puede eliminar los metadatos del generador, desactivar los pingbacks, restringir el índice REST, cambiar el nombre de las rutas de contenido, bloquear la automatización anónima y poner recursos detrás de una CDN. Un firewall de aplicaciones web puede devolver un desafío o una respuesta 403 al borde ClockTools mientras un visitante normal recibe la página completa. Una caché puede servir un documento transformado que contenga menos detalles de origen. Esos controles cambian la evidencia pública sin cambiar necesariamente el sistema de gestión de contenidos.

Una arquitectura de WordPress sin cabeza crea una separación más profunda. El sitio web visible puede ser representado por React, Next.js, Astro, otro marco, una aplicación nativa o un servicio perimetral. WordPress puede proporcionar contenido durante una compilación, a través de una API privada, desde otro nombre de host o detrás de un proxy. Verificar la interfaz pública revela lo que esa interfaz revela; no puede identificar un servicio de contenido privado al que nunca se hace referencia públicamente. Una exportación estática también puede contener contenido creado originalmente en WordPress mientras que ninguna aplicación de WordPress en vivo sirve la página.

Las instalaciones personalizadas y multisitio introducen más variaciones. WordPress puede vivir en un subdirectorio, usar mapeo de dominio, servir medios desde otro nombre de host, exponer una API en una ruta descubierta o colocar recursos de temas y complementos detrás de un dominio de contenido compartido. ClockTools utiliza la relación API oficial cuando se publica y deriva una raíz API convencional a partir de rutas de contenido visibles, pero limita deliberadamente las solicitudes en lugar de forzar cada ubicación común.

¿Una versión expuesta de WordPress es un resultado de seguridad?

No. Una versión divulgada es evidencia de inventario más que un hallazgo de vulnerabilidad. ClockTools lee una versión solo cuando los metadatos del generador o el generador de API REST nombran explícitamente WordPress y proporcionan una versión. No adivina la versión principal a partir de parámetros de consulta ?ver= arbitrarios en scripts y estilos porque esos valores pueden describir un tema, complemento, compilación, caché o versión no relacionada. Evitar conjeturas es más útil que mostrar una versión precisa pero falsa.

Una versión actual visible no prueba que los complementos, temas, credenciales, permisos, alojamiento, copias de seguridad o códigos personalizados sean seguros. Una versión oculta tampoco demuestra seguridad. Los propietarios deben utilizar administración de actualizaciones autenticada, estado del sitio de WordPress, copias de seguridad probadas, monitoreo, acceso con privilegios mínimos, autenticación multifactor y una evaluación de seguridad autorizada. La detección tecnológica puede identificar la exposición pública, pero no puede evaluar la postura de seguridad completa desde una página anónima.

¿Cómo se manejan los límites de privacidad, seguridad y solicitudes?

La dirección del sitio web llega al trabajador ClockTools porque una página externa no se puede inspeccionar de manera confiable desde todos los navegadores. Las respuestas de la API están marcadas como no almacenadas y solo se guarda una breve lista reciente opcional en el almacenamiento del navegador local. Las cookies del navegador, los encabezados de autorización, las sesiones de inicio de sesión y las credenciales nunca se reenvían. Las cadenas de consulta se eliminan antes de la solicitud de destino para reducir la posibilidad de enviar un parámetro firmado, un identificador personal, un token de campaña o un secreto accidental.

El detector recupera la página pública enviada, un candidato de índice REST y como máximo una hoja de estilo de tema público. Cada cuerpo tiene un límite de bytes estricto, cada operación comparte una fecha límite y la profundidad de redireccionamiento tiene un límite. Cada nombre de host de redireccionamiento se verifica nuevamente a través del DNS público. El host local, las redes privadas, las direcciones reservadas, los hosts con formato incorrecto, los destinos con credenciales, los esquemas no admitidos, los bucles y los destinos de redireccionamiento inseguros se bloquean antes de que se permita una solicitud saliente.

Utilice la herramienta sólo para sitios web públicos. No envíe paneles privados, enlaces de restablecimiento, enlaces de vista previa, descargas firmadas, tokens de acceso, hosts de intranet ni identificadores personales. El detector no otorga permiso para probar un sistema, eludir controles o buscar vulnerabilidades. Si un objetivo bloquea solicitudes anónimas, el resultado honesto es restringido o no concluyente. ClockTools no evade el control ni muta repetidamente al objetivo.