bakery.example

El certificado HTTPS es válido: los navegadores muestran una conexión segura.

Por qué es importante

Si su certificado falta o no es válido, los navegadores muestran a sus visitantes un aviso de «No seguro» o «La conexión no es privada», y muchos se irán antes de contactarle o de comprar.

Quién puede corregirlo

Su proveedor de alojamiento o su desarrollador web · detectado aquí: Cloudflare (sitio web), WordPress (sitio web)

Qué hacer

Este resultado no requiere ningún cambio. Conserve la configuración que funciona y utilice estos pasos para verificarla.

Cómo comprobar la corrección

Abra su sitio web en una ventana de navegación privada: debería cargarse sin avisos y mostrar el candado. Después, vuelva a ejecutar esta comprobación: este punto debería indicar «Correcto».

{
  "verified": "true",
  "protocol": "TLSv1.3",
  "not_after": "Dec 29 08:00:00 2026 GMT",
  "not_before": "Sep 30 08:00:00 2026 GMT"
}

Recomendaciones de MDN Web Docs (en inglés)

El certificado es válido y no está próximo a caducar.

Por qué es importante

Cuando su certificado caduca, los navegadores bloquean a sus visitantes con un aviso de seguridad a pantalla completa, por lo que su sitio web queda en la práctica fuera de servicio hasta que se renueve.

Quién puede corregirlo

Su proveedor de alojamiento (los certificados suelen renovarse automáticamente) · detectado aquí: Cloudflare (sitio web), WordPress (sitio web)

Qué hacer

Este resultado no requiere ningún cambio. Conserve la configuración que funciona y utilice estos pasos para verificarla.

Cómo comprobar la corrección

Tras la renovación, vuelva a ejecutar esta comprobación: la fecha de caducidad debería ser posterior y este punto debería indicar «Correcto».

{
  "days_remaining": 88,
  "expires_at": "2026-12-29T08:00:00+00:00"
}

Recomendaciones de Let's Encrypt (en inglés)

Su sitio web no envía este ajuste de protección (cabecera HTTP) a los navegadores.

Por qué es importante

Sin HSTS, los navegadores de sus visitantes pueden intentar primero la versión sin cifrar de su sitio, que puede interceptarse en redes compartidas como una wifi pública.

Quién puede corregirlo

Su proveedor de alojamiento o su desarrollador web · detectado aquí: Cloudflare (sitio web), WordPress (sitio web)

Qué hacer

Active HSTS solo cuando HTTPS funcione de forma fiable en todo su sitio: los navegadores lo recuerdan, incluso después de retirarlo. Pida primero a su proveedor de alojamiento la cabecera Strict-Transport-Security con una duración corta (max-age=300, cinco minutos) y después auméntela de forma gradual hasta al menos 180 días (max-age=15552000), idealmente un año (max-age=31536000). Añada includeSubDomains o preload solo cuando todos los subdominios funcionen con HTTPS: son difíciles de deshacer.

Cómo comprobar la corrección

Vuelva a ejecutar esta comprobación: este punto debería indicar «Correcto». Después, compruebe que sus páginas principales siguen cargándose con normalidad.

Match: (http.host eq "YOUR_HOSTNAME" and ssl)
Operation: Set static
Header: Strict-Transport-Security
Value: max-age=300

{
  "header": "strict-transport-security",
  "value": ""
}

Recomendaciones de MDN Web Docs (en inglés)

Su sitio web no envía este ajuste de protección (cabecera HTTP) a los navegadores.

Por qué es importante

Una política de seguridad de contenido (Content Security Policy) indica a los navegadores qué scripts y recursos puede cargar su sitio. Sin ella, el código malicioso introducido en su sitio (por ejemplo, a través de un plugin vulnerable) se ejecuta libremente en los navegadores de sus visitantes y puede robar lo que escriben.

Quién puede corregirlo

Su desarrollador web · detectado aquí: Cloudflare (sitio web), WordPress (sitio web)

Qué hacer

Esto requiere cuidado, porque una política demasiado estricta puede estropear su sitio. Pida a su desarrollador que haga una lista de los scripts, las fuentes tipográficas y los servicios que usa su sitio (analítica, pagos, chat) y que pruebe una política en modo «report-only» (solo informar), que señala los problemas sin bloquear nada. Pase a aplicarla solo cuando sus páginas clave funcionen, y tenga lista la configuración anterior para restaurarla.

Cómo comprobar la corrección

Vuelva a ejecutar esta comprobación: este punto debería indicar «Correcto». Después, pruebe sus páginas clave (formulario de contacto, pago, reservas) para asegurarse de que nada ha dejado de funcionar.

Match: http.host eq "YOUR_HOSTNAME"
Reporting-Endpoints: csp="OWNER_APPROVED_HTTPS_REPORT_ENDPOINT"
Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; report-to csp

{
  "header": "content-security-policy",
  "value": ""
}

Recomendaciones de MDN Web Docs (en inglés)

A algunas cookies les falta Secure, o a una cookie de inicio de sesión o de sesión le falta HttpOnly; pregunte para qué sirve cada una.

Por qué es importante

Las cookies pueden mantener iniciada la sesión de sus visitantes o de su personal. Sin el atributo Secure, una cookie puede viajar sin cifrar, y sin HttpOnly un código malicioso en la página puede leerla, lo que podría permitir a alguien apropiarse de una sesión.

Quién puede corregirlo

Su desarrollador web · detectado aquí: Cloudflare (sitio web), WordPress (sitio web)

Qué hacer

Pregunte a su desarrollador para qué sirve cada cookie. Las cookies de inicio de sesión y de sesión deberían tener tanto Secure como HttpOnly. Algunas cookies, como las de los banners de consentimiento o de analítica, necesitan legítimamente que la página pueda leerlas, así que no las cambie todas a la vez: pruebe primero el inicio de sesión y sus integraciones, y conserve una forma de revertir los cambios.

Cómo comprobar la corrección

Vuelva a ejecutar esta comprobación y revise la lista de cookies con su desarrollador. Después, confirme que el inicio de sesión y las demás funciones siguen funcionando.

{
  "cookies": [
    {
      "name": "wp_lang",
      "secure": false,
      "http_only": false,
      "session": false
    }
  ]
}

Recomendaciones de MDN Web Docs (en inglés)

No había ningún archivo security.txt disponible en la ubicación estándar.

Por qué es importante

Si alguien descubre un problema de seguridad en su sitio web, un archivo security.txt le indica cómo contactar con usted. Sin él, un aviso útil puede no llegarle nunca o llegar a la persona equivocada.

Quién puede corregirlo

Su desarrollador web o el responsable de su sitio web · detectado aquí: Cloudflare (sitio web), WordPress (sitio web)

Qué hacer

Publique un archivo de texto plano en /.well-known/security.txt en su sitio HTTPS. Necesita una línea Contact: con una dirección que alguien revise (por ejemplo, mailto:security@su-dominio.example) y una línea Expires: con una fecha futura en formato RFC 3339 (como 2027-12-31T23:59:59Z). Programe un recordatorio para actualizarlo antes de esa fecha, e incluya solo datos de contacto que esté dispuesto a hacer públicos.

Cómo comprobar la corrección

Abra https://su-dominio/.well-known/security.txt en un navegador: debería mostrar el archivo de texto con su contacto y una fecha futura. Después, vuelva a ejecutar esta comprobación. Si añade una línea Canonical:, esta debe incluir exactamente esa dirección.

Recomendaciones de IETF RFC (en inglés)

Los visitantes que escriben la dirección sin https:// son enviados al sitio seguro.

Por qué es importante

Los visitantes que escriben su dirección sin «https://» pueden quedarse en una página sin cifrar, donde lo que leen o escriben (como los datos de un formulario de contacto) puede ser visto o alterado, por ejemplo en una red wifi pública.

Quién puede corregirlo

Su proveedor de alojamiento o su desarrollador web · detectado aquí: Cloudflare (sitio web), WordPress (sitio web)

Qué hacer

Este resultado no requiere ningún cambio. Conserve la configuración que funciona y utilice estos pasos para verificarla.

Cómo comprobar la corrección

En una ventana privada, escriba su dirección empezando por http://: debería llegar a la versión https:// de la misma dirección. Después, vuelva a ejecutar esta comprobación: este punto debería indicar «Correcto».

Recomendaciones de Let's Encrypt (en inglés)

Su sitio web envía este ajuste de protección a los navegadores.

Por qué es importante

Sin este ajuste, los navegadores pueden adivinar qué tipo de archivo reciben, de modo que un archivo subido o etiquetado por error podría ejecutarse como código en los navegadores de sus visitantes.

Quién puede corregirlo

Su desarrollador web o su proveedor de alojamiento · detectado aquí: Cloudflare (sitio web), WordPress (sitio web)

Qué hacer

Este resultado no requiere ningún cambio. Conserve la configuración que funciona y utilice estos pasos para verificarla.

Cómo comprobar la corrección

Vuelva a ejecutar esta comprobación: este punto debería indicar «Correcto». Después, compruebe que sus páginas siguen viéndose y funcionando con normalidad.

{
  "header": "x-content-type-options",
  "value": "nosniff"
}

Recomendaciones de MDN Web Docs (en inglés)

Su dominio recibe correo, pero no publica ningún registro SPF, por lo que cualquiera puede enviar con más facilidad correos que dicen proceder de usted.

Por qué es importante

SPF enumera los servicios autorizados a enviar correo en nombre de su dominio. Sin él, o con varios registros SPF contradictorios, los delincuentes pueden enviar con más facilidad correos en su nombre, y es más probable que sus correos legítimos acaben en spam.

Quién puede corregirlo

Su administrador de correo y quien gestiona su DNS · detectado aquí: Google Workspace (correo electrónico), Cloudflare (DNS)

Qué hacer

Haga una lista de todos los servicios que envían correo por usted: su proveedor de buzones, pero también los formularios del sitio web, los boletines y las herramientas de facturación o de reservas. Mantenga exactamente un registro SPF que los cubra a todos, con los valores que documenta cada proveedor; fusione los duplicados en lugar de añadir un segundo registro. No sustituya las entradas existentes por un registro estricto de «bloquearlo todo», o sus correos legítimos podrían ser rechazados.

Cómo comprobar la corrección

Cuando el cambio de DNS se haya aplicado, vuelva a ejecutar esta comprobación: este punto debería indicar «Correcto». Después, envíe un correo de prueba desde cada servicio y compruebe que las cabeceras del mensaje recibido muestran spf=pass.

TXT en el dominio de envío SPF:
v=spf1 include:_spf.google.com ~all

Recomendaciones de IETF RFC (en inglés)

Su política DMARC es «p=none»: informa de los correos falsos, pero sigue dejándolos pasar. Después de revisar sus informes, pase a «p=quarantine» y luego a «p=reject».

Por qué es importante

Sin una política DMARC, los delincuentes pueden enviar con más facilidad correos que parecen proceder de su empresa, y los proveedores de correo no tienen ninguna instrucción para bloquearlos. Si existen varios registros DMARC, no se aplica ninguno.

Quién puede corregirlo

Su administrador de correo y quien gestiona su DNS · detectado aquí: Google Workspace (correo electrónico), Cloudflare (DNS)

Qué hacer

Primero, configure SPF y DKIM para todos los servicios que envían correo por usted. Después, publique un único registro DMARC (_dmarc.su-dominio) con p=none y una dirección de informes que alguien revise: así supervisa sin bloquear. Tras unas semanas de informes sin problemas, pase gradualmente a p=quarantine y después a p=reject; endurecer la política demasiado pronto puede bloquear sus propios correos.

Cómo comprobar la corrección

Cuando el cambio de DNS se haya aplicado, vuelva a ejecutar esta comprobación: este punto indica «Correcto» cuando la política es p=quarantine o p=reject. Después, compruebe en los informes DMARC que sus correos legítimos superan la validación.

TXT en _dmarc.YOUR_MAIL_DOMAIN:
v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_ADDRESS

Recomendaciones de IETF RFC (en inglés)

Hay registros MX publicados. No se han probado sus destinos, su disponibilidad ni la entrega en los buzones.

Por qué es importante

Los registros MX indican a otros servidores de correo dónde entregar el correo electrónico de su dominio. Si son erróneos o contradictorios, los correos de sus clientes pueden ser devueltos o perderse. Una dirección web que no se usa para el correo puede, con razón, no tener ninguno.

Quién puede corregirlo

Su proveedor de correo electrónico, o quien gestiona el DNS de su dominio · detectado aquí: Google Workspace (correo electrónico), Cloudflare (DNS)

Qué hacer

Este resultado no requiere ningún cambio. Conserve la configuración que funciona y utilice estos pasos para verificarla.

Cómo comprobar la corrección

Cuando el cambio de DNS se haya aplicado, vuelva a ejecutar esta comprobación. Después, por separado, envíe un correo de prueba hacia y desde su propio buzón para confirmar la entrega.

Recomendaciones de IETF RFC (en inglés)

Se ha encontrado una posible clave en un selector habitual. No se han probado la firma de los mensajes ni la validez de la clave.

Por qué es importante

DKIM añade una firma digital a sus correos para que los destinatarios puedan comprobar que proceden realmente de su empresa y que no han sido alterados. Sin ella, es más probable que sus correos acaben en spam y DMARC protege peor su dominio.

Quién puede corregirlo

Su administrador de correo electrónico · detectado aquí: Google Workspace (correo electrónico), Cloudflare (DNS)

Qué hacer

Este resultado no requiere ningún cambio. Conserve la configuración que funciona y utilice estos pasos para verificarla.

Cómo comprobar la corrección

Cuando DKIM esté activado y el cambio de DNS se haya aplicado, envíe un correo nuevo a una dirección externa que usted controle (no un alias ni un compañero). En las cabeceras del mensaje recibido, busque dkim=pass y anote los valores d= y s= de DKIM-Signature: s= es el selector que debe consultar en el DNS.

{
  "DKIM:google": [
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
  ]
}

Recomendaciones de IETF RFC (en inglés)

Hay un registro DS publicado; no se han validado las firmas DNSSEC ni la cadena de confianza.

Por qué es importante

DNSSEC firma digitalmente las respuestas DNS de su dominio, lo que dificulta que los atacantes desvíen a sus visitantes o su correo electrónico hacia un servidor falso. Es una capa de protección adicional, más que un requisito básico.

Quién puede corregirlo

Quien gestiona el DNS de su dominio, junto con su registrador · detectado aquí: Cloudflare (DNS)

Qué hacer

DNSSEC parece activado: su registrador publica el enlace necesario (registro DS). No hay nada que cambiar. Si traslada su DNS a otro proveedor, pida primero a ambos proveedores que planifiquen juntos el cambio de DNSSEC.

Cómo comprobar la corrección

Pida a su proveedor de DNS que confirme que DNSSEC se valida correctamente de principio a fin. Esta comprobación puede mostrar que DNSSEC está publicado, no que funciona.

Recomendaciones de ICANN (en inglés)

Hay registros CAA publicados en este nombre de host. No se han evaluado sus restricciones ni su tratamiento por parte de los proveedores de certificados.

Por qué es importante

Un registro CAA indica qué organizaciones pueden emitir certificados HTTPS para su dominio, lo que dificulta obtener un certificado fraudulento. Es opcional, y un registro erróneo puede impedir que su propio certificado se renueve.

Quién puede corregirlo

Quien gestiona su DNS, junto con su proveedor de alojamiento · detectado aquí: Cloudflare (DNS)

Qué hacer

Este resultado no requiere ningún cambio. Conserve la configuración que funciona y utilice estos pasos para verificarla.

Cómo comprobar la corrección

Pida a su proveedor de alojamiento que confirme las reglas CAA efectivas, incluidas las heredadas de su dominio principal o de alias, y que el certificado de su sitio web todavía puede renovarse.

Recomendaciones de IETF RFC (en inglés)