Una de las preguntas más habituales que recibimos es: „Tengo el plugin X instalado, pero el informe no lo lista.“ Eso casi siempre es comportamiento esperado, no un bug. InspectWP hace una única visita anónima a tu sitio, igual que cualquier visitante, y trabaja únicamente con lo que es visible públicamente. Este artículo explica qué significa eso en la práctica.
1. Cómo funciona la detección en líneas generales
InspectWP carga la URL que indicas exactamente una vez con un navegador headless real. Después miramos:
- El HTML renderizado y los scripts inline.
- Todos los archivos CSS y JavaScript que carga la página.
- URLs de imágenes y fuentes, en especial sus rutas.
- Cabeceras de respuesta HTTP y cookies.
- Etiquetas meta y datos estructurados.
A partir de estas señales inferimos qué plugin o tema está en uso. No iniciamos sesión en tu sitio, no accedemos a wp-admin y no leemos directamente tu directorio wp-content. Solo vemos lo que vería cualquier visitante anónimo.
2. Por qué un plugin puede ser invisible
Hay varias razones legítimas por las que un plugin no aparece:
- Es un plugin solo de backend. Muchos plugins (herramientas de administración, plugins de copias de seguridad, herramientas de staging, comprobadores SEO internos, gestores de roles) nunca generan nada en el frontend. No hay nada que detectar.
- Solo carga en páginas concretas. Un plugin de reservas puede cargar sus recursos solo en la página de reservas. Si rastreas tu home, no aparecerá. Prueba a rastrear la página donde realmente se usa el plugin.
- Solo carga para usuarios autenticados. Un plugin de área de socios puede no cargar nada para visitantes anónimos. Mismo efecto que el anterior.
- Una optimización agresiva lo está ocultando. Los plugins de caché y optimización pueden combinar, minificar o renombrar recursos hasta el punto de que el nombre original del plugin ya no sea reconocible. Ver sección 4.
- Es un plugin muy nuevo o muy de nicho. La detección funciona mejor con plugins que dejan una huella reconocible y estable. Las novedades recientes o los plugins hechos a medida pueden no estar todavía en nuestras reglas de reconocimiento.
- El plugin estaba desactivado. Un plugin desactivado no carga nada en el frontend. Vale la pena confirmarlo en Plugins → Plugins instalados.
3. Por qué un tema puede ser identificado erróneamente
La detección de temas suele ser bastante fiable, porque los temas dejan típicamente trazas claras en las rutas de los recursos (/wp-content/themes/tu-tema/...). Aun así, puede salir mal:
- Temas hijo: si usas un tema hijo, puedes ver listados tanto el padre como el hijo. Eso es correcto: WordPress carga ambos.
- Temas renombrados: algunas agencias renombran la carpeta del tema padre por motivos de marca. Si el nuevo nombre de carpeta no coincide con nada en nuestras reglas de reconocimiento, el tema aparece como „desconocido“ o con el slug renombrado.
- Page builders que traen su propio tema: algunos page builders sustituyen efectivamente al tema. El tema detectado es entonces el tema base del builder, no lo que tú esperarías.
- Multisite con sobreescritura de temas: en multisite, el tema activo puede diferir por subsitio. Asegúrate de haber rastreado la URL correcta.
4. La trampa de la optimización de recursos
Es la razón más común de plugins ausentes en sitios por lo demás normales. Plugins como WP Rocket, LiteSpeed Cache, Autoptimize, W3 Total Cache, Perfmatters u optimizadores de CDN integrados pueden hacer todo lo siguiente:
- Combinar muchos archivos CSS en uno grande con un nombre genérico como
combined-abc123.css. - Combinar muchos archivos JavaScript de la misma forma.
- Minificar y ofuscar el contenido de los archivos.
- Reescribir las rutas de los recursos hacia un CDN, eliminando el prefijo
/wp-content/plugins/.... - Inlinear el CSS crítico para que la hoja de estilos original ya no se solicite.
Cuando todo eso se ejecuta a la vez, las firmas individuales de los plugins desaparecen. El plugin sigue funcionando perfectamente en tu sitio, simplemente no podemos verlo desde fuera.
5. CDN, proxy inverso y cachés en el edge
Si tu sitio está detrás de Cloudflare, BunnyCDN, KeyCDN o de la caché en el edge de un alojamiento gestionado, la respuesta que vemos puede estar ya muy transformada. Algunas funciones del CDN (Rocket Loader, minificación automática, Mirage, Polish) modifican aún más el HTML y los recursos. Los plugins siguen estando, simplemente la huella pública ha cambiado.
6. Server-side rendering y aplicaciones JavaScript
Los sitios construidos con WordPress headless (un frontend en JavaScript que habla con WordPress vía REST o GraphQL) suelen exponer casi ninguna señal tradicional de WordPress. El frontend es esencialmente una app a medida. En esos casos, la detección de WordPress en sí, ya no digamos de plugins individuales, es limitada o imposible desde fuera.
7. Qué hacer cuando falta algo
- Rastrea la página donde realmente se usa el plugin, no solo la home.
- Rastrea como visitante no autenticado, en una pestaña privada del navegador, para ver la misma vista que ve InspectWP.
- Desactiva temporalmente la combinación de archivos en tu plugin de caché y vuelve a rastrear.
- Comprueba si el plugin está realmente generando algo en el frontend (Ver código fuente en tu navegador).
- Si tienes la certeza de que el plugin produce salida en el frontend y sigue sin aparecer, escríbenos a hello@inspectwp.com con la URL del informe y el nombre del plugin. Ampliamos nuestras reglas de reconocimiento de forma continua.