109 controles automáticos en cada análisis

Transporte cifrado, cabeceras de protección, secretos olvidados en el código y backends expuestos: donde los sitios hechos deprisa (sobre todo los creados con IA) se hacen daño de verdad.

• Redirección automática a HTTPS. La versión http:// debe llevar de inmediato a https://, o el tráfico puede viajar en claro.
• Validez del certificado TLS. Certificado caducado o no válido = aviso de "sitio no seguro" en el navegador y visitantes que huyen.
• Contenido mixto HTTP en páginas HTTPS. Scripts o imágenes cargados en claro dentro de una página cifrada abren la puerta a manipulaciones.
• HSTS (Strict-Transport-Security). Le dice al navegador que use siempre HTTPS, incluso en la primera visita.
• Caducidad del certificado TLS. Te avisamos si el certificado caduca dentro de 30 días: al caducar, el sitio se bloquea de golpe para todos.
• Registro SPF (anti-spoofing de email). Sin SPF cualquiera puede enviar email en nombre de tu dominio, y los tuyos acaban en spam.
• Política DMARC del dominio. Le dice a los servidores de correo qué hacer con el email falsificado: ausente o solo en observación, el spoofing pasa.
• Librerías JS con CVE conocidas. jQuery, Bootstrap, Lodash y otras en versiones con vulnerabilidades documentadas públicamente (con identificador CVE).
• Librerías JS al final de su vida (EOL). Librerías sin soporte (AngularJS, Vue 2): los nuevos fallos nunca recibirán un parche.
• Content-Security-Policy. La defensa principal contra scripts inyectados (XSS): sin ella, un script hostil puede hacer cualquier cosa.
• Protección contra clickjacking (X-Frame-Options). Impide que tu sitio se enmarque dentro de páginas fraudulentas para robar clics.
• MIME sniffing (X-Content-Type-Options). Evita que el navegador "adivine" los tipos de archivo y ejecute contenido que no debería.
• Referrer-Policy. Controla cuánta información de navegación filtras a sitios de terceros.
• Permissions-Policy. Restringe el acceso a cámara, micrófono y sensores por parte de scripts de terceros.
• Divulgación de la versión del software del servidor. Anunciar la versión de tu servidor o framework entrega a los atacantes la lista de exploits que probar.
• Archivo .env accesible públicamente. El archivo con contraseñas y claves API descargable por cualquiera: uno de los errores más graves (y más comunes).
• Carpeta .git accesible públicamente. Una carpeta .git expuesta permite a cualquiera descargar todo tu código fuente, secretos incluidos.
• Source maps expuestos en producción. Los mapas de depuración revelan el código original, a menudo con comentarios y secretos.
• Claves AWS en código público. Una access key de AWS en el bundle de JavaScript = otra persona disparando tu factura en la nube.
• Claves secretas de Stripe en código público. Una clave secreta de Stripe expuesta permite reembolsos, cargos y acceso a los datos de pago.
• Claves API de Google expuestas. Claves de Google sin restricciones pueden generar costes y abusos en tus servicios.
• Clave service-role de Supabase expuesta. La clave service-role se salta todas las reglas de seguridad de la base de datos: en el frontend es un desastre.
• Row Level Security de Supabase. Tablas legibles sin login: verificamos que las reglas RLS protejan de verdad tus datos (solo el hecho, nunca los datos).
• Reglas de acceso a la base de datos Firebase. Realtime Database con reglas abiertas = datos de todos los usuarios públicos. Lo comprobamos sin descargar nada.
• Solidez de la Content-Security-Policy. Una CSP con ’unsafe-inline’ o fuentes abiertas parece protección pero no detiene nada: la falsa seguridad es peor que ninguna.
• Aislamiento de la ventana (Cross-Origin-Opener-Policy). Impide que una página abierta desde tu sitio mantenga el control de tu pestaña.
• Flags de seguridad de las cookies (Secure, HttpOnly, SameSite). Sin estos flags, una cookie de sesión es legible por JavaScript y se adjunta a las peticiones de otros sitios: robo de cuentas y CSRF.
• Integridad de los scripts de terceros (SRI). Si el CDN que aloja una librería es comprometido (le pasó a polyfill.io, más de 100k sitios), sin integrity el navegador ejecuta el código sustituido.
• Envío de formularios sobre conexión cifrada. Un formulario que envía a http:// desde una página https:// manda los datos en claro, y el navegador avisa al usuario al enviar.
• Enlaces externos protegidos (rel="noopener"). Sin noopener la página que abres puede cambiar la dirección de tu pestaña mientras el usuario mira hacia otro lado.
• Firma DKIM de los correos. Sin DKIM tus correos se autentican peor y acaban más veces en spam; con él, el destinatario verifica que el mensaje es realmente tuyo.
• Informes DMARC (rua). Una política DMARC sin dirección de informes es ciega: no sabes quién escribe en tu nombre y nunca puedes endurecerla.
• Cifrado obligatorio entre servidores de correo (MTA-STS). Entre servidores el TLS es opcional: sin MTA-STS un atacante puede forzar el envío en claro y leer el correo en tránsito.
• DNSSEC. Firma las respuestas DNS del dominio: sin ello se puede desviar a los visitantes a un servidor que no es el tuyo.
• Registro CAA. Declara qué autoridades pueden emitir certificados para tu dominio. Sin él, cualquier CA del mundo puede emitir uno a tu nombre.

Las bases de cumplimiento que los reguladores (y tus usuarios) esperan de cualquier sitio europeo.

• Banner de consentimiento de cookies. Si usas cookies no técnicas necesitas un banner de consentimiento: su ausencia es la infracción más visible.
• Política de privacidad accesible. Una política de privacidad enlazada y legible es obligatoria si tratas cualquier dato personal.
• Rastreadores activos antes del consentimiento. Analytics y píxeles que se disparan antes del clic en "Aceptar" violan el GDPR: los detectamos.
• Política de cookies como documento separado. La normativa de la UE exige una política de cookies independiente con la lista, las duraciones y los terceros: un párrafo dentro de la política de privacidad no basta.
• Términos y condiciones accesibles. Obligatorios si vendes; para todos los demás son el único documento que define qué prometes y qué no.
• Datos de la empresa en el pie de página (número de IVA, razón social). La ley de la UE e italiana los exige también online, y es lo primero que comprueba cualquiera antes de confiar en ti.
• Fuentes cargadas sin enviar datos a Google. Google Fonts desde el CDN envía la IP de cada visitante a EE. UU. sin consentimiento: la infracción detrás de miles de cartas de requerimiento en la UE.
• Consentimiento de privacidad en los formularios de recogida de datos. Un formulario que pide email o teléfono sin casilla y sin aviso recoge datos sin base jurídica demostrable.

Lo que un visitante (o cliente) se encuentra de verdad: enlaces rotos, errores, callejones sin salida.

• Enlaces rotos. Enlaces que llevan a páginas que no existen: confianza a la baja, SEO penalizado.
• Errores de JavaScript en consola. Los errores en consola a menudo significan funciones rotas que nadie notó.
• Stack traces o errores técnicos visibles. Los mensajes de error en crudo en la página asustan a los usuarios y revelan detalles internos.
• Estado HTTP 404 en páginas inexistentes. Responder 200 en una dirección que no existe (soft 404) hace que Google indexe páginas vacías e inventadas.
• Página 404 personalizada. La 404 desnuda del servidor es un callejón sin salida: ningún mensaje, ningún enlace para volver al sitio.
• Canal de contacto accesible. Email, formulario o página de contacto: sin uno, el sitio pierde credibilidad (y clientes).
• Favicon presente. El icono en la pestaña del navegador y en los resultados de búsqueda: si falta, el sitio parece incompleto.
• Tiempo de respuesta del servidor. Las respuestas lentas frustran a los usuarios antes incluso de que la página cargue.
• Recorridos de usuario sin callejones sin salida. Simulamos la navegación principal: botones que no llevan a ninguna parte, flujos interrumpidos.
• El dominio recibe los correos publicados en el sitio. Direcciones @tudominio en el sitio pero ningún registro MX: esos mensajes rebotan y las peticiones de los clientes se pierden.
• Accesibilidad por IPv6. Varias redes móviles ya son solo IPv6: sin registro AAAA llegan a través de traductores, con más latencia y más fallos.
• Redundancia de los servidores de nombres. Un solo servidor de nombres es un punto único de fallo para el sitio y el correo a la vez. El estándar pide al menos dos.
• Caducidad del dominio. Un dominio caducado tumba el sitio y el correo, y pasado el periodo de gracia cualquiera puede registrarlo en tu lugar.
• Imágenes que cargan realmente. Las imágenes que responden con error dejan recuadros vacíos: en una ficha de producto es la señal de abandono más inmediata.
• Protocolo HTTP/2 o superior. En HTTP/1.1 el navegador encola las peticiones de una en una: en una página con decenas de archivos es un retraso en cada visita.

Los fundamentos para que te encuentren en Google y presentarte bien cuando se comparte tu enlace.

• Etiqueta <title> de la página. El título es lo primero que muestra Google: ausente o vacío, eres invisible.
• Meta description. La descripción bajo el título en los resultados de búsqueda: sin ella, Google decide por ti.
• Estructura de los encabezados H1. Un solo H1 claro por página: cero o demasiados confunden a los motores de búsqueda.
• Jerarquía de los encabezados (h1 → h2 → h3). Los encabezados no deben saltarse niveles: la jerarquía correcta es el mapa que Google y los lectores de pantalla usan para entender la página.
• URL canónica. Evita que la misma página aparezca como duplicada, diluyendo tu posicionamiento.
• Archivo robots.txt. Le dice a los motores de búsqueda qué pueden rastrear: su ausencia es señal de descuido.
• robots.txt no bloquea a los motores de búsqueda. Un "Disallow: /" olvidado del staging borra el sitio de Google, y desde la página no se ve.
• Sitemap declarado en el robots.txt. La directiva Sitemap: es como un rastreador que no te conoce encuentra enseguida todas las páginas.
• Sitemap XML. El mapa del sitio ayuda a Google a encontrar e indexar todas tus páginas.
• Datos estructurados JSON-LD (schema.org). Le dicen a Google y a los asistentes de IA qué eres: sin ellos, ningún resultado enriquecido en la SERP.
• Formato de los datos estructurados JSON-LD. Un bloque JSON-LD con un error de sintaxis o sin @context/@type se descarta en silencio: markup inútil.
• Vista previa social (Open Graph). Sin Open Graph, un enlace compartido se ve desnudo en redes sociales y chats: sin imagen, sin título.
• Idioma declarado de la página. El atributo lang ayuda a los motores de búsqueda y a los lectores de pantalla a entender el contenido.
• Viewport para móviles. Sin el meta viewport el sitio se ve minúsculo en el móvil: penalización móvil inmediata.
• Indexabilidad en los motores de búsqueda. Un noindex olvidado (común en los sitios generados) te borra de Google.
• Acceso de los rastreadores de IA (ChatGPT, Claude, Perplexity). Si el robots.txt los bloquea — a menudo un valor por defecto del CDN — tu sitio no puede ser citado en las respuestas de los asistentes.
• Identidad del negocio en los datos estructurados. El nodo Organization o LocalBusiness le dice a los motores (y a las IA) quién eres: sin él te resumen sin citarte.
• Longitud del title en los resultados de búsqueda. Más allá de 65 caracteres Google lo corta, por debajo de 25 lo reescribe: en ambos casos el título que elegiste no es el que leen los usuarios.
• Longitud de la meta description. Demasiado corta y Google la sustituye, demasiado larga y la corta a media frase: es tu único espacio publicitario gratuito.
• Completitud de la vista previa social (imagen, texto, URL). Open Graph parcial = vista previa mutilada: sin og:image el enlace compartido se muestra como un recuadro de solo texto.
• Vista previa en X/Twitter (Twitter Card). Sin twitter:card el enlace en X sale desnudo en vez de con la vista previa grande.
• Declaración de idiomas alternativos (hreflang). En un sitio multilingüe, un hreflang incorrecto hace competir las versiones entre sí y lleva a los usuarios al idioma equivocado.

La velocidad que perciben de verdad tus usuarios, medida con Google PageSpeed.

• Rendimiento de carga en móvil. Core Web Vitals vía PageSpeed (estrategia móvil, la medida que Google usa para el ranking): un sitio lento pierde visitantes y posiciones.
• Rendimiento de carga en escritorio. La misma medida con la estrategia de escritorio: en una pantalla grande, las expectativas de velocidad son aún mayores.
• Formatos de imagen modernos (WebP/AVIF). Imágenes en JPEG/PNG donde los formatos modernos pesarían mucho menos con la misma calidad.
• Peso y tamaño de las imágenes. Imágenes mal comprimidas o servidas más grandes de como se muestran: peso inútil en cada visita.
• JavaScript sin usar. Código descargado y procesado que la página nunca usa: ralentiza justo los dispositivos más lentos.
• Recursos que bloquean el renderizado. CSS y scripts síncronos que mantienen la página en blanco mientras el contenido ya estaría listo.
• Compresión de texto (gzip/brotli). Sin compresión, HTML, CSS y JS pesan el doble: el arreglo es una línea de configuración del servidor.
• Caché de los assets estáticos. Assets vueltos a descargar en cada visita en lugar de leídos desde la caché: penaliza a los visitantes que vuelven.
• Peso total de la página. Más allá de 3MB, la carga se nota en cualquier conexión que no sea perfecta.
• Core Web Vitals de usuarios reales. Los datos CrUX de los usuarios reales de Chrome del sitio: la medida que Google usa de verdad en el ranking.
• Distribución mediante CDN. Sin CDN cada visitante lo descarga todo del servidor de origen, y un pico de tráfico no tiene colchón.
• Texto visible mientras cargan las fuentes. Sin font-display el navegador mantiene el texto invisible hasta tres segundos: página maquetada pero muda.
• Carga diferida de las imágenes. Sin loading="lazy" el navegador descarga también las imágenes del final, robando ancho de banda a las que se están viendo.
• Dimensiones declaradas en las imágenes. Sin width y height el contenido salta mientras llegan las imágenes: la causa número uno de la inestabilidad que Google penaliza.
• Minificación de JavaScript y CSS. Código enviado con indentación y comentarios es peso inútil en cada visita: se arregla con un paso de compilación.

El European Accessibility Act se aplica desde el 28 de junio de 2025: la accesibilidad es una obligación legal cuyo plazo ya ha vencido. Estas comprobaciones leen el marcado de la página y encuentran las barreras más habituales.

• Texto alternativo en las imágenes. Sin alt, quien no ve la imagen pierde la información: es el primer criterio que se revisa en cualquier control de conformidad.
• Etiquetas en los campos de formulario. Un campo sin etiqueta se anuncia como «cuadro de texto» y nada más: en un formulario de pago es una barrera total.
• Nombre accesible en botones y enlaces solo de icono. Hamburguesa, X de cerrar, carrito: sin aria-label se leen como «botón» y nada más.
• Título descriptivo en los iframes. Mapas y vídeos incrustados sin title se anuncian como «marco», sin decir qué contienen.
• Encabezados en las tablas de datos. Sin <th> una tarifa se convierte en una secuencia de números sin etiqueta para quien la escucha.
• Zoom permitido en móvil. user-scalable=no impide ampliar la página: quien tiene baja visión no puede leerla desde el teléfono.
• Estructura de la página (main, nav, header). Los landmarks son el mapa que permite saltar al contenido en vez de atravesar todo el menú.
• Enlace «ir al contenido». Sin él, quien navega con teclado atraviesa cabecera y menú en cada cambio de página.
• Orden de tabulación coherente. Un tabindex positivo crea una secuencia propia que no coincide con lo que se ve en pantalla.
• Audio y vídeo con reproducción automática controlables. El audio que arranca solo se superpone a la voz del lector de pantalla y no se puede parar.
• Subtítulos en los vídeos. Sin subtítulos el habla solo está disponible para quien la oye — y para la mayoría que mira sin sonido.
• Uso correcto de los atributos ARIA. Roles inventados o aria-hidden en elementos aún enfocables empeoran las cosas en vez de mejorarlas.
• Texto de los enlaces comprensible fuera de contexto. Una lista de «haz clic aquí» no distingue nada, ni para un lector de pantalla ni para Google.
• Declaración de accesibilidad. Es el documento que declara hasta dónde llega la conformidad y cómo notificar una barrera. Para muchos sujetos es obligatorio.