¿Cómo saber con qué está hecha una web?

Una web no lleva una etiqueta que diga «hecha con WordPress, alojada en tal sitio». Pero casi todas lo cuentan sin querer. Cada herramienta deja huellas reconocibles en las rutas de sus archivos, en el código de la página y en las cabeceras que envía el servidor, y quien sabe dónde mirar puede reconstruir buena parte de la pila sin ningún acceso especial.

No es un truco de hacker. Es leer lo que el sitio publica para cualquiera que lo visite, y resulta muy útil cuando vas a heredar, rediseñar o migrar una web, o cuando quieres entender cómo trabaja la competencia.

¿Qué capas tiene una web?

Conviene separar lo que se busca, porque cada capa deja pistas distintas:

• El CMS o la plataforma: WordPress, Shopify, Wix, Drupal, Webflow… Es donde se edita el contenido.
• El framework de la interfaz: React, Next.js, Astro, Vue… Es cómo está construida la parte que ve el usuario. Un sitio puede no tener CMS y sí framework, o al revés.
• El servidor y el lenguaje: Apache, Nginx, PHP, ASP.NET.
• La CDN: una red que se pone delante del servidor para servir más rápido y filtrar ataques, como Cloudflare o Fastly.
• El alojamiento: el proveedor donde vive realmente el servidor.

¿Qué pistas deja una web?

Las cabeceras de la respuesta

Antes del HTML, el servidor envía cabeceras. Algunas son muy explícitas: Server: nginx, X-Powered-By: PHP/8.2 o X-Powered-By: Next.js. Otras delatan a la plataforma por su mera presencia: Shopify, Wix o Vercel añaden cabeceras propias con identificadores de petición, y Cloudflare marca cada respuesta con cf-ray.

Muchas webs bien mantenidas eliminan estas cabeceras a propósito, porque revelar el software y su versión ahorra trabajo a quien busque fallos conocidos. Es una de las recomendaciones que se tratan en el artículo sobre cabeceras de seguridad HTTP.

La etiqueta generator

Muchos CMS escriben en el <head> una línea como <meta name="generator" content="WordPress 6.5">. Es la pista más directa, y también la más fácil de quitar: hay plugins y temas que la borran.

Las rutas de los archivos

Aquí está la pista más fiable, porque cambiarla obligaría a reconstruir el sitio. WordPress sirve sus imágenes y scripts desde /wp-content/ y /wp-includes/. Next.js usa /_next/, Astro /_astro/, Shopify carga desde cdn.shopify.com. Mirar de dónde vienen las hojas de estilo y los scripts en el código fuente suele bastar para saber la plataforma.

Los scripts y sus atributos

Los frameworks de interfaz dejan marcas en el HTML: atributos característicos, nombres de elementos raíz, objetos de datos incrustados con nombres conocidos. Lo mismo pasa con librerías como jQuery o Bootstrap, que suelen cargarse con su nombre en la ruta.

La IP y su sistema autónomo

El dominio resuelve a una dirección IP, y cada IP pertenece a un sistema autónomo (ASN): un bloque de direcciones gestionado por una organización, con un número propio. Si el ASN es el de Amazon, Hetzner u OVH, ya sabes dónde está alojada. Si es el de Cloudflare, lo único que sabes es que hay una CDN delante.

¿Cuáles son los límites?

Ninguna detección de este tipo es completa, y conviene leerla con criterio:

• Lo que se carga después no aparece si solo se mira la primera respuesta del servidor. Un chat, un mapa o un píxel que inserta un gestor de etiquetas con JavaScript no está en el HTML inicial.
• Lo que se oculta a propósito no se ve. Quitar la etiqueta generator y las cabeceras de servidor es buena práctica, y muchos sitios lo hacen.
• La CDN tapa el alojamiento. Con Cloudflare delante, la IP real del servidor queda oculta, y es justo lo que se busca.
• Las pistas pueden engañar. Un sitio migrado puede conservar rutas antiguas, o una plantilla puede incluir librerías que ya no usa. Una sola pista es una sospecha; dos o tres coincidentes, una conclusión razonable.
• La versión exacta casi nunca es fiable desde fuera, y tampoco es lo importante. Para saber si un sitio está descuidado dice más la fecha de su último contenido que un número de versión.

¿Para qué sirve saberlo?

Antes de una migración o un rediseño. El presupuesto y el plazo cambian mucho según de dónde se parta. Mover un WordPress a otro WordPress no se parece a sacar una tienda de Wix, donde no hay acceso a la base de datos, ni a modernizar un sitio con un framework abandonado. Saber la plataforma de partida es el primer dato de cualquier estimación seria, y condiciona cosas como la migración sin perder posicionamiento.

Cuando heredas una web. Pasa con frecuencia: la agencia anterior desapareció, nadie tiene la documentación y hay que saber qué hay antes de tocar nada. La detección externa da el punto de partida mientras se consiguen los accesos.

Para entender a la competencia. Saber que un competidor usa Shopify o una plataforma a medida, o que sirve su web detrás de una CDN, dice algo de cuánto invierte y de qué puede hacer que tú no puedes. No es para copiar, sino para dimensionar.

Para valorar a un proveedor. Si te ofrecen «una web a medida» y el portafolio está hecho con un constructor de plantillas, es una pregunta legítima que hacer antes de firmar.

¿Cómo comprobar una web?

Nuestro detector de tecnología de una web hace la lectura descrita: descarga una vez la página que indiques, revisa sus cabeceras y su <head>, y te muestra el CMS, el framework, el servidor, la CDN y el alojamiento que encuentra. Cada resultado sale con la evidencia concreta que lo delata, para que puedas confirmarla tú mismo en el código fuente, y la IP del dominio se acompaña de su sistema autónomo para saber en qué proveedor vive o qué CDN la cubre.

Si el resultado sale escaso, prueba con una página interna además de la portada, y recuerda que la ausencia de pistas también es información: suele indicar un sitio que alguien ha configurado con cuidado.

---

Ninguna herramienta externa sustituye a tener los accesos y la documentación de una web. Pero diez segundos de lectura bien interpretada te dicen de dónde partes, y eso ahorra muchas preguntas en la primera reunión.