Cuando abres una web, solo ves el resultado: un diseño, un formulario, un botón de pago. Debajo hay una torre de tecnologías que alguien decidió usar. Saber cuáles son no es curiosidad geek: es información que cambia propuestas, detecta oportunidades y, en algunos casos, salva proyectos.
Esta guía te enseña las técnicas reales que usamos en QueUsan para auditar el stack de cualquier web pública. No son secretos: son las mismas técnicas que aplicarían un auditor serio, un competidor espabilado o un comercial que hace sus deberes antes de una reunión.
Qué se puede detectar realmente
Empecemos por lo que sí es posible sin tocar el servidor:
- CMS: WordPress, Shopify, Wix, Webflow, Drupal, Joomla, Ghost…
- Plugins y versiones exactas en WordPress (sí, incluso las que el autor intenta ocultar)
- Tema (WordPress) o theme engine (Shopify Liquid, Ghost Handlebars…)
- Builder: Elementor, Divi, Bricks, Gutenberg puro…
- Analytics: GA4, Hotjar, Meta Pixel, Mixpanel, Plausible…
- Pagos: Stripe, PayPal, Redsys, Bizum, Klarna…
- CDN y hosting real (con matices si hay Cloudflare)
- Fuentes, frameworks JS, stack mobile (PWA, AMP)
- Servidores de correo (Google Workspace, Microsoft 365, Zoho, self-hosted…)
Y lo que no se puede detectar sin acceso: versión exacta del CMS (salvo en muchos WordPress, ver más abajo), base de datos, cron jobs internos, plugins de seguridad desactivados…
Lo que dice el HTML
Abre cualquier web, pulsa Ctrl+U y mira el HTML. En los primeros 100 kilobytes suele haber más información de la que un dueño imagina:
- Meta generator:
<meta name="generator" content="WordPress 6.4.2">. La versión, servida en bandeja. Muchos plugins de seguridad lo quitan, pero incluso así queda un patrón. - Comentarios HTML:
<!-- This site is optimized with the Yoast SEO plugin v21.0 -->. Leales como un perro. - Clases del <body>:
page-template-default page-id-47 theme-astra elementor-kit-5. Ahí tienes el tema (theme-astra) y que usa Elementor. - Rutas a /wp-content/plugins/*: cada hoja de estilos CSS cargada delata el plugin y, en muchos casos, la versión en el query string (
?ver=2.8.1). - <link rel="https://api.w.org/">: delata WordPress incluso si el meta generator está oculto.
Trucos rápidos desde la consola del navegador:
// Lista todos los scripts y su src
[...document.scripts].map(s => s.src).filter(Boolean);
// Lista los CSS cargados
[...document.styleSheets].map(s => s.href).filter(Boolean);Lo que dicen las cabeceras HTTP
Abre DevTools → Network → clic en la primera request. Fíjate en Response Headers:
Server: LiteSpeedonginx/1.24.0: software del servidor.X-Powered-By: PHP/8.2.10: versión de PHP.Set-Cookie: wordpress_logged_in_*: WordPress.X-Litespeed-Cache,CF-Ray,X-Cache: HIT from Varnish: capas de cache y CDN.Content-Security-Policy: los dominios permitidos son una mina (GA, Stripe, Intercom, Typeform…).
Desde terminal: curl -sI https://midominio.com | head -40. Dos segundos, toda la info.
Lo que dice el DNS
Los registros DNS son públicos y cuentan la infraestructura sin pedir permiso:
- NS (nameservers): si apuntan a
ns1.hostinger.com, ya sabes el hosting principal. Si apuntan a*.cloudflare.com, hay CDN delante. - MX:
smtp.google.com→ Google Workspace.*.protection.outlook.com→ Microsoft 365.mx.zoho.eu→ Zoho. - TXT:
v=spf1 include:_spf.google.com ~all,google-site-verification=…. Confirmación extra de proveedores. - CNAME:
shops.shopify.com,app.webflow.com,cname.vercel-dns.com. Saltan a la vista.
Herramienta favorita: dig +short NS midominio.com, dig MX midominio.com. Si no tienes dig, MXToolbox funciona igual.
Lo que delata el JavaScript
Cada librería JS deja huella:
window.jQueryowindow.$→ jQuery (WordPress clásico).window.React,window.__NEXT_DATA__→ Next.js.window.Vue→ Vue/Nuxt.window.dataLayer→ Google Tag Manager.window.gtag→ GA4 instalado directamente.window.Intercom,window.HubSpotConversations→ chat/CRM.window.elementorFrontend→ Elementor (Free o Pro, luego lo afinas).
La API REST de WordPress
Aquí está el tesoro que los dueños olvidan blindar. La ruta /wp-json/ devuelve un JSON con todos los namespaces registrados, y cada plugin serio registra el suyo. Ejemplo real:
GET https://midominio.com/wp-json/
{
"namespaces": [
"wp/v2",
"yoast/v1",
"woocommerce/v3",
"rank-math/v1",
"elementor/v1",
"wpforms/v1"
]
}Traducción: WordPress + Yoast + WooCommerce + Rank Math + Elementor + WPForms. En 400 ms de request. Esta es una de las técnicas que usa el motor de QueUsan por defecto.
El truco del readme.txt
Cada plugin serio publica un readme.txt en su raíz, y en WordPress se sirve en /wp-content/plugins/NOMBRE-PLUGIN/readme.txt. Ese archivo trae la versión estable en la línea "Stable tag":
=== Yoast SEO ===
Stable tag: 21.0
Tested up to: 6.4Correlacionas los plugins detectados por la REST con los readme.txt de esa ruta y tienes la versión exacta de cada plugin. Tratamos el procedimiento entero en la guía sobre detectar la versión exacta de un plugin.
Cloudflare: qué sí y qué no
Cuando hay Cloudflare entre tú y el servidor real, verás una IP de Cloudflare (cualquiera en los rangos 104.16.0.0/12, 172.64.0.0/13, etc.). Pero:
- Los emails (registros MX) casi siempre apuntan al servidor real, porque Cloudflare no hace MX proxy por defecto.
- Subdominios viejos (
dev.,old.,mail.,cpanel.) a veces están sin proxy y filtran la IP. - Certificados SSL históricos (Certificate Transparency logs) revelan subdominios.
Desarrollamos cada técnica en el artículo sobre ver la IP real detrás de Cloudflare.
Herramientas útiles
Además de las manuales de arriba, estas automatizan el grueso:
- QueUsan: el motor que construimos. Detecta WordPress + versión de plugins vía REST y readme.txt, decodifica emails de Cloudflare, correlaciona con GeoIP y genera un score accionable.
- BuiltWith: histórico potente (desde 2015), gratuito para 1 web/día.
- Wappalyzer: extensión de navegador de toda la vida. Open source.
- WhatRuns: alternativa a Wappalyzer, con notificaciones de cambios.
- SecurityTrails: histórico de DNS (oro para OSINT).
Los errores que todo el mundo comete
De los más repetidos cuando alguien empieza a "investigar" stacks:
- Fiarse del meta generator. Se quita en 5 segundos. Cruza siempre varias señales.
- Asumir que la IP pública es el servidor real. Si hay Cloudflare, casi nunca lo es.
- Medir versión del CMS por una cabecera. Las cabeceras de
x-powered-bysuelen ser basura. La versión real se infiere por rutas internas. - Ignorar el DNS. Mucha gente va directo al HTML sin mirar MX ni NS. Pierde la mitad del cuadro.
- Tratar subdominios como una curiosidad. Son la ruta más fácil para encontrar la IP real y versiones antiguas de stack.
¿Es legal escanear webs ajenas?
Corto: sí, siempre que solo accedas a lo que es público. Leer el HTML de una web pública es lo mismo que mirar un escaparate. El problema viene cuando:
- Intentas autenticarte sin permiso (fuerza bruta, credenciales adivinadas).
- Provocas carga anómala (miles de requests por minuto).
- Usas datos personales recopilados para spam o venta sin base legal (RGPD).
QueUsan envía a lo sumo 20-30 requests por escaneo, respeta robots.txt cuando el dueño nos lo pide y nunca intenta autenticarse. Esa es la frontera.
Conclusión
Saber qué tecnologías usa una web es uno de esos conocimientos que parecen opcionales hasta que los necesitas: una propuesta, una auditoría, una negociación, una sospecha. Las técnicas están al alcance de cualquiera con un navegador y un terminal. Las herramientas como QueUsan ahorran el trabajo pesado de correlacionar 20 señales en 200 ms.
Los siguientes cuatro artículos de este pillar entran a fondo en los casos más útiles: