79 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.

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.

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.