La herramienta de abajo descarga la versión pública de una sola dirección y dice qué se deduce de ella. No inicia sesión, no rastrea tu red y no adivina. Lee lo mismo que el navegador de tu visitante: el código de estado tras las redirecciones, las cabeceras, el HTML y los ficheros que ese HTML pide antes del primer pintado. Esos ficheros los descarga de verdad y los pesa, en lugar de estimarlos.
Comprobación del sitio
Mira qué muestra tu sitio en público
Danos la dirección de un sitio que gestiones. Lo descargamos como lo haría un navegador y mostramos qué se deduce de ello, junto con lo que leímos exactamente.
Qué comprobamos
Cabeceras de respuesta, tiempo hasta el primer byte, título y descripción, la dirección canónica, los encabezados de contenido, datos estructurados, imágenes, robots.txt y el mapa del sitio, y en WordPress también lo que el código de la página revela sobre los plugins instalados. Además descargamos los recursos que bloquean el primer renderizado y sumamos lo que pesan de verdad.
Qué no comprobamos
- el área de administración y todo lo que está tras un login
- la base de datos, su tamaño y su estado
- las copias de seguridad, si existen y si restauran
- las versiones de los plugins contra una base de vulnerabilidades
- cómo se comporta el sitio para un usuario con sesión iniciada
- cualquier página distinta de la única dirección que nos diste
Qué mide realmente el chequeo
La primera capa son peticiones HTTP propias desde un borde de Cloudflare: tiempo hasta el primer byte, código de estado una vez resueltas las redirecciones, cabeceras de seguridad, cabeceras de caché y compresión. La segunda capa es el propio HTML, del que salen el título, la descripción, la canónica, el número de encabezados de primer nivel, los bloques JSON-LD, el atributo de idioma y cómo están declaradas las imágenes.
La tercera capa es el peso del arranque de la página y es la que suele cambiar la conversación. El chequeo recoge de la cabecera todas las hojas de estilo y todos los scripts sin defer, es decir, exactamente lo que un navegador tiene que terminar de descargar antes de poder dibujar nada. Luego los descarga e indica la cifra real de kilobytes, separada entre CSS y JavaScript, con el tiempo del más lento y la lista de dominios ajenos de los que vienen.
En WordPress se suman unas cuantas cosas públicas por diseño que aun así sorprenden a los dueños. Las rutas de los ficheros de plugins y temas revelan qué hay instalado y en qué versión, porque el número de versión suele ir en la dirección de la hoja de estilo. El punto REST con la lista de usuarios responde sin autenticación si nadie lo ha cerrado. El fichero xmlrpc.php sigue respondiendo a menudo aunque la mayoría de instalaciones ya no lo necesita para nada.
Por qué aquí no hay puntuación
Es una decisión, no una carencia. Una puntuación invita a exactamente una pregunta siguiente, qué hago con esto, y la respuesta honesta a esa pregunta es otra auditoría. El peso no tiene ese problema. Diecinueve peticiones bloqueantes es un número que se ve bajar. Un megabyte de JavaScript antes del primer pintado apunta a un plugin concreto. Once peticiones desde dos dominios ajenos suelen apuntar a un servicio de tipografías y a un gestor de etiquetas, y ambos fueron decisiones de alguien que se pueden deshacer.
La capa tiene un techo y ese techo hay que nombrarlo. Medimos peso y tiempo de respuesta, no la experiencia de tus usuarios. Esto no es una medición de Core Web Vitals ni sustituye a ninguna. Los datos de campo se recogen de tus visitantes reales durante veintiocho días y ya son tuyos, gratis, en Google Search Console, en el informe de Core Web Vitals. Si quieres saber cómo se comporta la pasarela de pago en un móvil con mala cobertura en Valencia, ese informe es el único que responde. Nuestros números dicen qué parte de la página está detrás de lo que ese informe enseña.
Qué no puede ver el chequeo
La lista de lo que queda fuera de alcance es corta y conviene conocerla antes de tomar el resultado por una foto completa. El chequeo no entra en el escritorio, así que no sabe nada de cuentas, roles ni de quién ha entrado por última vez desde una dirección desconocida. No ve la base de datos, así que no dirá si las tablas se hinchan de transients abandonados. No revisa copias de seguridad, porque por definición no son públicas. No contrasta las versiones de plugins detectadas con una base de vulnerabilidades, así que una versión leída es un hecho y no una valoración de riesgo. Y revisa exactamente la dirección que has dado, no el sitio entero.
La vista con sesión iniciada es un hueco aparte. WordPress sirve a los usuarios identificados un conjunto de consultas completamente distinto y suele desactivar para ellos la caché de página. Una tienda que responde a un visitante en unos cientos de milisegundos puede tardar varias veces más con un cliente identificado y el carrito lleno. Un chequeo desde fuera no enseña eso, y ninguna herramienta sin acceso a la cuenta lo enseña.
Cómo leer cada clase de hallazgo
Los hallazgos de gravedad alta cuestan dinero o seguridad de inmediato. Falta de HTTPS en la dirección final, un noindex en una página que debería indexarse, un punto abierto con la lista de usuarios, cuatro o más de las cinco cabeceras de seguridad ausentes, un primer byte lento. Aquí cae también el arranque pesado: quince o más peticiones bloqueantes, o más de medio megabyte antes del primer pintado. Cada uno tiene una solución concreta, casi siempre en la configuración del servidor o en un plugin que ya tienes.
Los hallazgos de gravedad media describen un estado que aguanta un año sin caída mientras la ventaja se va perdiendo. HTML sin caché, ficheros bloqueantes servidos sin compresión, tipografías cargadas desde los servidores de Google en lugar de tu dominio, descripción ausente, ningún bloque de datos estructurados, imágenes sin dimensiones, sitemap ausente. Quien tiene tráfico estable los planifica para la próxima revisión. Quien lleva una tienda en temporada alta se lleva primero compresión, caché e imágenes, porque son las que llegan antes al carrito.
Los hallazgos de gravedad baja son sobre todo rastros que deja la pila técnica: la versión de WordPress en el generador meta, el nombre y la versión del servidor en una cabecera, varios encabezados de primer nivel en la misma página, caché corta en ficheros estáticos, imágenes sin carga diferida. Nada de esto tumba un sitio. Se ordenan junto a otro trabajo, no en lugar de él.
Las confirmaciones van aparte. Cuando la herramienta dice que las cabeceras de seguridad están completas, que el HTML volvió de caché, que hay datos estructurados y que el arranque es ligero, eso no es relleno. Responde a la pregunta que más repiten los dueños de un sitio, que es si el equipo anterior hizo su trabajo.
Cuándo la respuesta honesta es que no hay nada que hacer
Pasa más veces de lo que sugiere el mercado de herramientas de diagnóstico. Un sitio corporativo en un alojamiento decente, con WordPress al día, cabeceras completas, caché sensata y arranque ligero, no necesita nada nuestro. Si el informe solo muestra hallazgos de gravedad baja y confirmaciones, es este caso. Cierra la pestaña y vuelve dentro de medio año.
Hay además un estado intermedio en el que lo sensato es esperar. Si cambiaste de tema o de alojamiento la semana pasada, nuestros números ya describen la versión nueva mientras Search Console seguirá describiendo la vieja un mes más. No encargues trabajo a partir de dos fuentes que describen dos sitios distintos. Deja que la ventana avance primero.
Y un tercer caso: un hallazgo real que no es tuyo. Una cabecera de seguridad ausente, la falta de compresión o un HTML sin caché son muchas veces configuración del alojamiento y no del sitio. Un mensaje al soporte técnico del proveedor lo cierra más barato que cualquier proyecto.
Qué hacemos con la dirección que nos das
Descargamos páginas públicas en la dirección que envías, no iniciamos sesión en ningún sitio y no guardamos nada más que un contador anónimo de ejecuciones. El informe no va a ninguna lista de correo, porque nunca pedimos una dirección de correo. Si pasas al contacto, el formulario llega relleno con la dirección y los tres hallazgos más graves, y ves el texto entero antes de que se envíe nada.
A dónde ir si el informe encontró algo real
Los hallazgos de gravedad media que se repiten suelen significar que nadie cuida el sitio, no que haya una cosa rota, y la respuesta a eso es el mantenimiento WordPress. Arranque pesado y primer byte lento llevan a la optimización de velocidad WordPress. Punto de usuarios abierto, xmlrpc.php respondiendo y cabeceras ausentes son material para una auditoría de seguridad WordPress, porque esas tres no compensan arreglarlas de una en una.
