marbuildsCuaderno de lanzamiento / edición 1.1 / septiembre 2026

Antes de publicar
tu web.

26 comprobaciones para pasar de «parece que funciona» a una revisión con evidencia.

Aprende qué revisar, dónde mirar y cómo decidir si un punto está resuelto.

Para quienes construyen y mantienen webs. Con referencias técnicas y contexto de privacidad España/UE.

26 comprobaciones

01Funcionamiento / Buena práctica

Recorrido completo probado

Completar la tarea principal y sus estados de espera, éxito, error y reintento sin pérdida ni duplicación.Pendiente

Cuándo aplicaToda web; los casos dependen de su propósito.

Matiz que importaPago, registro o envíos si no existen.

Dónde mirar

Navegador y entorno de pruebas

Cómo comprobarlo

  1. Escribe una tarea: enviar una consulta y verla recibida.
  2. Prueba éxito, error y reintento con datos ficticios.
  3. Comprueba el resultado receptor y que no haya duplicados.

Qué debería quedar demostrado

Caso de aceptación con resultado observado. En integración, usar entorno de prueba y confirmar recepción, no solo HTTP 200.

Guarda esta evidencia

Registro de la tarea, entorno, fecha y resultado receptor.

Consulta la fuente

MDN, Introduction to cross-browser testingW3C WAI, identificación de errores
02Funcionamiento / Buena práctica

Enlaces al destino correcto

Verificar navegación y destinos reales, incluidas anclas y enlaces externos críticos.Pendiente

Cuándo aplicaSi hay enlaces.

Matiz que importaSitio sin enlaces, salvo salida/retorno necesarios.

Dónde mirar

Páginas, menú, pie y correos transaccionales

Cómo comprobarlo

  1. Inventaría destinos principales, incluidos enlaces dentro de textos.
  2. Abre cada uno y comprueba contenido, idioma y ancla.
  3. Repite enlaces críticos en móvil.

Qué debería quedar demostrado

Recorrer enlaces, comparar URL y contenido esperado. Un 200 en una página equivocada falla.

Guarda esta evidencia

Tabla origen → destino esperado → destino observado.

Consulta la fuente

MDN, Introduction to cross-browser testingGoogle, códigos HTTP
03Funcionamiento / Buena práctica

404 con salida útil

Una ruta desconocida responde 404; 410 corresponde a una retirada permanente conocida. La página de error ofrece una salida útil.Pendiente

Cuándo aplicaWeb servida por HTTP con rutas.

Matiz que importaNo obliga a ilustración o diseño custom.

Dónde mirar

Panel Red del navegador, documento principal

Cómo comprobarlo

  1. Abre una ruta inventada dentro de tu dominio.
  2. Comprueba el estado HTTP inicial, además del mensaje visual.
  3. Usa el enlace de recuperación y verifica su destino.

Qué debería quedar demostrado

GET a ruta inexistente, comprobar status y enlace útil. No confundir navegación cliente con respuesta inicial.

Guarda esta evidencia

Estado 404 para desconocida y captura de una salida útil.

Consulta la fuente

Google, códigos HTTPMDN, 410 Gone
04Funcionamiento / Referencia WCAG

Móvil sin recortes

Contenido y funciones siguen disponibles con reflow, zoom y uso táctil.Pendiente

Cuándo aplicaWeb dirigida a personas.

Matiz que importaExcepciones bidimensionales WCAG, como algunos mapas o tablas.

Dónde mirar

Modo adaptable y un teléfono real

Cómo comprobarlo

  1. Revisa el contenido a 320 píxeles CSS de ancho.
  2. Amplía texto y prueba orientación y teclado virtual.
  3. Completa la tarea principal sin perder controles.

Qué debería quedar demostrado

320 CSS px, zoom, orientación, teclado virtual y controles principales; dispositivo real antes de certificar móvil.

Guarda esta evidencia

Ancho, zoom, dispositivo y recorrido probado.

Consulta la fuente

W3C WAI, reflowW3C WCAG 2.2, Recommendation 12-12-2024
05Funcionamiento / Buena práctica

Navegadores objetivo probados

Ejecutar recorridos en los motores y versiones soportados elegidos.Pendiente

Cuándo aplicaToda web con público definido.

Matiz que importaNo hay obligación de soportar todo navegador histórico.

Dónde mirar

Matriz de soporte del proyecto

Cómo comprobarlo

  1. Define navegadores, versiones y dispositivos de tu audiencia.
  2. Repite el recorrido crítico en cada combinación elegida.
  3. Registra diferencias que impidan entender o actuar.

Qué debería quedar demostrado

Matriz Chrome/Chromium, Safari/WebKit, Firefox cuando sean objetivo; probar tareas, no solo abrir home.

Guarda esta evidencia

Matriz de soporte con fecha y resultado por combinación.

Consulta la fuente

MDN, Introduction to cross-browser testingPlaywright, navegadores
06Accesibilidad / Referencia WCAG

Teclado con foco visible

Operar funciones con teclado, orden de foco útil, sin trampas, con indicador visible.Pendiente

Cuándo aplicaControles interactivos.

Matiz que importaExcepciones de entrada dependiente de trayectoria; no eximen menús.

Dónde mirar

Teclado, menús y diálogos

Cómo comprobarlo

  1. Recorre la página con Tab y Shift+Tab.
  2. Activa cada control con su tecla adecuada.
  3. Comprueba colocación inicial y destino lógico del foco al cerrar diálogos.

Qué debería quedar demostrado

Probar teclas según control, colocación inicial del foco y destino lógico al cerrar un diálogo: normalmente el activador o un elemento coherente con la continuación de la tarea.

Guarda esta evidencia

Recorrido de foco con el control que falla identificado.

Consulta la fuente

W3C WAI, tecladoW3C WAI, foco visibleW3C, diálogo modal
07Accesibilidad / Referencia WCAG

Campos con etiquetas claras

Proveer etiquetas/instrucciones visibles y nombres accesibles asociados, incluidos errores identificables.Pendiente

Cuándo aplicaFormularios y controles que necesitan etiqueta.

Matiz que importaWeb sin entrada de datos; iconos necesitan nombre accesible por otra vía.

Dónde mirar

Formulario y árbol de accesibilidad

Cómo comprobarlo

  1. Comprueba que cada campo explica qué espera, incluso al escribir.
  2. Inspecciona nombre accesible y asociación de etiquetas.
  3. Provoca un error en pruebas y verifica instrucciones y campo afectado.

Qué debería quedar demostrado

Nombre programático, etiqueta persistente, requeridos y error textual; lector de pantalla en recorrido crítico.

Guarda esta evidencia

Etiqueta visible, nombre accesible y ejemplo de error entendible.

Consulta la fuente

W3C WAI, etiquetas e instruccionesW3C WAI, identificación de errores
08Accesibilidad / Referencia WCAG

Contraste medido

Contraste AA de texto y controles según categoría, también en temas y estados.Pendiente

Cuándo aplicaTexto/UI informativos.

Matiz que importaLogos, decoración y controles inactivos tienen excepciones concretas.

Dónde mirar

Inspector de color y estados de componentes

Cómo comprobarlo

  1. Mide texto contra su fondo real, incluidas transparencias.
  2. Repite en hover, foco, error y temas disponibles.
  3. Evalúa por separado texto y señales no textuales.

Qué debería quedar demostrado

Calcular contraste con fondo compuesto real: 4,5:1 texto normal, 3:1 grande; controles no textuales según 1.4.11.

Guarda esta evidencia

Colores, tamaño/peso, relación calculada y umbral aplicable.

Consulta la fuente

W3C WAI, contraste mínimoW3C WCAG 2.2, Recommendation 12-12-2024
09Accesibilidad / Referencia WCAG

Imágenes con alternativa útil

Alternativa adecuada al propósito: equivalente para imágenes informativas, identificación o alternativas específicas para pruebas, CAPTCHA y experiencias sensoriales; decoración ignorada.Pendiente

Cuándo aplicaImágenes, gráficos y contenido no textual significativo.

Matiz que importaDecoración con alt vacío. No revelar una respuesta de prueba o CAPTCHA en el alt; aplicar las excepciones y alternativas de WCAG 1.1.1.

Dónde mirar

Imágenes en su contexto de lectura

Cómo comprobarlo

  1. Decide si informa, activa una acción o decora.
  2. Comprueba qué entiende alguien que no ve la imagen.
  3. Añade equivalente detallado si el gráfico transmite más de lo que cabe en un alt.

Qué debería quedar demostrado

Revisar cada uso en contexto, no solo presencia de atributo. Gráficos complejos requieren equivalente completo.

Guarda esta evidencia

Función de la imagen y alternativa elegida.

Consulta la fuente

W3C WAI, árbol de decisión altW3C, contenido no textual
10Rendimiento / Buena práctica

Carga, respuesta y estabilidad

Evaluar rendimiento de carga, interacción y desplazamientos; corregir cuellos materiales.Pendiente

Cuándo aplicaToda web; medición adaptada al contenido.

Matiz que importaSin datos reales no se puede emitir veredicto de campo.

Dónde mirar

Herramientas de rendimiento y datos de campo

Cómo comprobarlo

  1. Define perfil de red/dispositivo y presupuesto antes de medir.
  2. Repite carga y tareas; identifica el recurso o trabajo costoso.
  3. Distingue medición de laboratorio de experiencia real.

Qué debería quedar demostrado

Fijar antes presupuestos y criterios por recorrido; repetir medición con perfil declarado y comprobar resultados dentro de esos límites. Para declarar CWV buenos de campo: LCP ≤2,5 s, INP ≤200 ms y CLS ≤0,1 al percentil 75, separando móvil y escritorio. Sin muestra suficiente queda sin verificar. Corregir imágenes, fuentes y JS según evidencia.

Guarda esta evidencia

Perfil, mediciones repetidas y mejora comparada con el presupuesto.

Consulta la fuente

web.dev, Web Vitalsweb.dev, Image performance
11Seguridad / Buena práctica

HTTPS sin contenido inseguro

Transporte cifrado con certificado válido y recursos sin mixed content.Pendiente

Cuándo aplicaWeb pública.

Matiz que importaNo implica activar preload o includeSubDomains a ciegas.

Dónde mirar

Dirección, certificado y panel Red

Cómo comprobarlo

  1. Comprueba HTTPS válido y ausencia de contenido mixto.
  2. Para navegación, revisa redirección desde HTTP cuando proceda.
  3. En APIs, comprueba rechazo o desactivación de HTTP sin enviar credenciales reales.

Qué debería quedar demostrado

HTTPS válido y sin contenido mixto. En navegación pública, redirigir HTTP cuando proceda; en APIs, rechazar o deshabilitar HTTP según superficie, sin depender de redirección para proteger solicitudes.

Guarda esta evidencia

URLs, transporte observado y ausencia de recursos inseguros en la muestra.

Consulta la fuente

OWASP, TLS
12Seguridad / Buena práctica

Secretos de servidor fuera del cliente

Credenciales reservadas al servidor no se incluyen en HTML, JavaScript, mapas de fuente ni respuestas al navegador.Pendiente

Cuándo aplicaIntegraciones con secretos; clasificar claves antes.

Matiz que importaClaves publicables y tokens legítimos de sesión del propio usuario tienen otro modelo de protección; no son automáticamente filtraciones de secretos de servidor.

Dónde mirar

Configuración del servidor y artefacto enviado al navegador

Cómo comprobarlo

  1. Clasifica claves públicas, tokens del usuario y secretos de servidor.
  2. Revisa el artefacto compilado y respuestas, sin imprimir valores sensibles.
  3. Si se expuso un secreto de servidor, revoca o rota y retira la exposición.

Qué debería quedar demostrado

Revisar ruta de datos y bundle con detector que no imprima valores. Si hay exposición, revocar/rotar antes de limpiar.

Guarda esta evidencia

Inventario por categoría y comprobación sin valores de credenciales.

Consulta la fuente

OWASP, Secrets Management
13Seguridad / Buena práctica

Permisos donde haya acceso

Servidor autoriza cada acción y objeto privado conforme a la política de acceso.Pendiente

Cuándo aplicaDatos o acciones restringidos.

Matiz que importaContenido deliberadamente público; no obliga a login en toda página.

Dónde mirar

Política de acceso y entorno aislado

Cómo comprobarlo

  1. Define quién puede hacer qué sobre cada tipo de recurso.
  2. Prepara usuarios y recursos ficticios existentes, con relaciones diferentes.
  3. Prueba casos permitidos y denegados, incluidos cambios de rol.

Qué debería quedar demostrado

En entorno controlado, definir matriz acción/recurso/rol/relación, con recursos sintéticos cuya existencia se compruebe. Probar permisos permitidos y denegados, anónimo, roles superiores y recursos propios, ajenos o compartidos según la política. Un 404 con recurso inexistente no prueba autorización.

Guarda esta evidencia

Matriz acción/recurso/relación con resultado esperado y observado.

Consulta la fuente

OWASP, Authorization
14Seguridad / Buena práctica

Entradas validadas en servidor

Validación estructural y semántica antes de procesar entradas no confiables.Pendiente

Cuándo aplicaFormularios, APIs e integraciones que reciben datos.

Matiz que importaWeb puramente estática sin entradas a un servidor propio; revisar proveedor si delegado.

Dónde mirar

Entrada del servidor o proveedor responsable

Cómo comprobarlo

  1. Define tipos, límites y reglas de negocio de los campos.
  2. Prueba casos válidos e inválidos directamente en entorno aislado.
  3. Verifica rechazo antes de efectos externos y mensajes útiles al usuario.

Qué debería quedar demostrado

Casos válidos e inválidos saltando el navegador, sin efectos externos, en entorno de prueba.

Guarda esta evidencia

Casos de prueba y resultado, sin correos ni pagos reales.

Consulta la fuente

OWASP, Input Validation
15Seguridad / Buena práctica

Límites contra abuso

Defensas proporcionales contra spam y consumo, aplicadas donde se ejecuta el trabajo.Pendiente

Cuándo aplicaFormularios, autenticación y operaciones abusables/costosas.

Matiz que importaNo exige CAPTCHA para leer una página ni promete detener todo bot.

Dónde mirar

Operación que consume recursos

Cómo comprobarlo

  1. Identifica qué puede generar spam, coste o carga.
  2. Define límites y comportamiento cuando se alcanzan.
  3. Ensaya de forma acotada en pruebas, incluyendo usuarios legítimos.

Qué debería quedar demostrado

Prueba acotada en staging de límite, concurrencia, reinicio y falso positivo; comprobar validación de challenge si existe.

Guarda esta evidencia

Límite acordado, consumo observado y caso de falso positivo.

Consulta la fuente

OWASP, Denial of Service
16Seguridad / Buena práctica

Dependencias con avisos revisados

Inventario actualizado, versiones reproducibles y triaje de vulnerabilidades relevantes.Pendiente

Cuándo aplicaWeb con dependencias, CMS, plugins o pipeline.

Matiz que importaSin dependencias de app, sigue existiendo plataforma y proceso de mantenimiento.

Dónde mirar

Dependencias, plugins y plataforma

Cómo comprobarlo

  1. Identifica las versiones que realmente se despliegan.
  2. Consulta avisos y determina qué afecta a tu uso.
  3. Actualiza o documenta tratamiento y responsable del riesgo.

Qué debería quedar demostrado

Comparar lockfile/build y avisos vigentes; verificar alcance y corrección, no contar alertas como explotación.

Guarda esta evidencia

Inventario, aviso evaluado, decisión y fecha de revisión.

Consulta la fuente

OWASP, Vulnerable Dependency Management
17Datos personales / Contexto legal

Solo los datos necesarios

Recoger datos necesarios para finalidades definidas y con base válida.Pendiente

Cuándo aplicaDatos personales bajo RGPD España/UE; minimización también como buena práctica fuera.

Matiz que importaSin tratamiento personal no se aplica RGPD por este motivo; comprobar logs y proveedores antes.

Dónde mirar

Inventario de datos

Cómo comprobarlo

  1. Lista campos, registros y proveedores.
  2. Relaciona cada dato con una finalidad y base aplicable.
  3. Elimina recogidas que no puedas justificar.

Qué debería quedar demostrado

Inventario campo/finalidad/base/destino; quitar campos no justificables.

Guarda esta evidencia

Dato → finalidad → base → destino.

Consulta la fuente

RGPD, texto oficial publicado en BOE
18Datos personales / Contexto legal

Conservación y borrado definidos

Definir plazos/criterios y ejecutar supresión o anonimización cuando corresponda, incluidas excepciones y copias.Pendiente

Cuándo aplicaDatos personales conservados dentro del ámbito RGPD.

Matiz que importaNo significa borrado inmediato absoluto ni eliminar obligaciones de conservación.

Dónde mirar

Calendario de conservación

Cómo comprobarlo

  1. Define plazo o criterio para cada grupo de datos.
  2. Incluye proveedores y tratamiento de copias.
  3. Ensaya vencimiento o supresión con datos ficticios.

Qué debería quedar demostrado

Calendario verificable y prueba sintética de vencimiento/supresión; restauración no debe reactivar datos que debían eliminarse.

Guarda esta evidencia

Plazo, responsable y resultado de una prueba de eliminación.

Consulta la fuente

RGPD, texto oficial publicado en BOE
19Datos personales / Contexto legal

Información al recoger datos

En recogida directa, facilitar información del tratamiento al obtener datos, salvo excepciones aplicables. En origen indirecto, aplicar plazos y excepciones del artículo 14.Pendiente

Cuándo aplicaRecogida de datos personales RGPD; art. 14 si origen indirecto.

Matiz que importaNo obliga universalmente a una URL con nombre concreto.

Dónde mirar

Lugar de recogida e información de privacidad

Cómo comprobarlo

  1. Recorre los puntos donde obtienes datos directamente.
  2. Comprueba que la información refleja operaciones reales.
  3. Para datos de otra fuente, revisa plazos y excepciones del art. 14.

Qué debería quedar demostrado

Recorrer formulario/entrada y contrastar información, destinatarios, derechos y plazos con operaciones reales.

Guarda esta evidencia

Punto de recogida y versión de la información comprobada.

Consulta la fuente

RGPD, texto oficial publicado en BOE
20Datos personales / Contexto legal

Consentimiento cuando corresponda

Antes de cookies/tecnologías no exentas, elección válida y rechazo/retirada efectivos.Pendiente

Cuándo aplicaEspaña: LSSI 22.2 y tratamiento RGPD asociado.

Matiz que importaTecnologías estrictamente necesarias y supuestos exentos documentados; sin tecnologías afectadas no exige banner.

Dónde mirar

Red y almacenamiento en perfil limpio

Cómo comprobarlo

  1. Inventaría cookies y otras tecnologías y su finalidad.
  2. Comprueba antes de elegir, aceptar, rechazar y retirar, si corresponde.
  3. Documenta por qué algo se considera exento.

Qué debería quedar demostrado

Perfil limpio, antes/aceptar/rechazar/retirar: inspeccionar red y almacenamiento. Que no haya cookies no excluye otros identificadores.

Guarda esta evidencia

Tecnología, finalidad, activación observada y condición aplicable.

Consulta la fuente

AEPD, guía de cookiesLSSI, texto consolidado BOEAEPD, medición de audiencia, enero 2024
21Descubrimiento / Buena práctica

Indexación intencional

Las páginas públicas que se desea indexar son accesibles al crawler y no se excluyen por error; las demás usan control adecuado.Pendiente

Cuándo aplicaSitios cuya presencia en buscadores importa; privacidad siempre se protege con acceso real.

Matiz que importaNo exige indexar todo ni crear sitemap/robots en todos los sitios.

Dónde mirar

HTML, cabeceras y herramientas del buscador

Cómo comprobarlo

  1. Decide qué páginas quieres hacer descubribles.
  2. Comprueba respuesta, robots, noindex y enlaces.
  3. Revisa canonical y sitemap cuando sean pertinentes.

Qué debería quedar demostrado

GET, robots, noindex/X-Robots-Tag, enlaces, canonical y sitemap según caso; Search Console solo con acceso autorizado.

Guarda esta evidencia

URL → intención → señales observadas.

Consulta la fuente

Google Search Central, sitemapsGoogle Search Central, robots.txtGoogle, noindex
22Descubrimiento / Referencia WCAG

Título descriptivo por página

Elemento title descriptivo de tema/propósito, coherente con idioma y contenido.Pendiente

Cuándo aplicaPáginas HTML.

Matiz que importaNo exige longitud fija, meta keywords ni títulos artificialmente distintos para URLs equivalentes.

Dónde mirar

Título del documento por ruta

Cómo comprobarlo

  1. Abre cada plantilla y mira el título de la pestaña.
  2. Comprueba que describe el tema o tarea de esa página.
  3. Revisa idioma y navegación que cambie el contenido.

Qué debería quedar demostrado

Ver título servido y final de cada plantilla/ruta; distinguir páginas equivalentes y diferentes.

Guarda esta evidencia

Ruta → título observado → propósito.

Consulta la fuente

Google Search Central, títulosW3C, título de página
23Descubrimiento / Buena práctica

Vista previa comprobada

Enlace compartido presenta título, descripción/imagen adecuados y recursos accesibles al destinatario.Pendiente

Cuándo aplicaPáginas públicas que se comparten.

Matiz que importaPrivadas no deben filtrar contenido por OG.

Dónde mirar

Metadatos y vista previa del canal

Cómo comprobarlo

  1. Revisa título, tipo, URL e imagen de Open Graph.
  2. Comprueba que el recurso sea accesible al consumidor.
  3. Prueba el canal elegido, teniendo en cuenta su caché.

Qué debería quedar demostrado

Revisar metadatos en HTML y recurso; probar destino social sin publicar, teniendo en cuenta caché.

Guarda esta evidencia

Metadatos y vista previa observada en el destino.

Consulta la fuente

Open Graph protocol
24Operación / Buena práctica

Errores con alerta útil

Detectar fallos relevantes y notificarlos a un responsable, sin exponer secretos o datos innecesarios.Pendiente

Cuándo aplicaWeb mantenida; alcance proporcional, también monitor externo en estáticas.

Matiz que importaNo obliga a una marca de analítica ni captura de cada clic.

Dónde mirar

Registro de errores y canal de aviso

Cómo comprobarlo

  1. Elige fallos que necesitan actuación y su responsable.
  2. Genera un evento sintético en pruebas.
  3. Comprueba que llega un aviso útil, sin datos innecesarios.

Qué debería quedar demostrado

Error sintético controlado, evento identificable y alerta recibida; comprobar redacción y retención.

Guarda esta evidencia

Evento, hora, aviso recibido y responsable.

Consulta la fuente

OWASP, Logging
25Operación / Buena práctica

Recuperación del despliegue ensayada

Recuperar un servicio funcional con una versión conocida compatible o con un procedimiento de corrección hacia delante comprobado.Pendiente

Cuándo aplicaDespliegues que pueden fallar.

Matiz que importaNo revierte datos ni esquemas automáticamente; cambio irreversible necesita plan específico.

Dónde mirar

Procedimiento de recuperación

Cómo comprobarlo

  1. Define el mecanismo compatible: volver atrás o corregir hacia delante.
  2. Ensáyalo fuera de producción incluyendo configuración y datos afectados.
  3. Verifica tarea crítica, integridad y tiempo aceptable.

Qué debería quedar demostrado

Ensayar en entorno aislado el mecanismo elegido, rollback compatible o corrección hacia delante; comprobar tarea crítica, integridad y tiempo aceptable. Incluir configuración, servicios y compatibilidad de migraciones.

Guarda esta evidencia

Versión, pasos, duración y resultado funcional.

Consulta la fuente

Vercel, Instant RollbackAWS OPS06-BP01, cambios fallidos
26Operación / Buena práctica

Copias restauradas, si guardas

Restaurar los datos/activos persistentes que no se regeneran, con integridad y pérdida/tiempo aceptables.Pendiente

Cuándo aplicaBD, CMS, subidas o estado persistente de valor.

Matiz que importaSin estado externo irregenerable, el build recuperable puede bastar; Git no guarda una BD por arte de magia.

Dónde mirar

Copias y entorno de restauración

Cómo comprobarlo

  1. Identifica datos o activos que no puedas regenerar.
  2. Restaura una copia en un destino aislado.
  3. Comprueba integridad, datos conocidos y tiempo/pérdida aceptables.

Qué debería quedar demostrado

Restauración aislada, consultar datos sintéticos conocidos, comprobar integridad y RPO/RTO.

Guarda esta evidencia

Copia usada, datos recuperados y tiempos medidos.

Consulta la fuente

AWS Reliability REL09-BP04

La decisión de publicar.

Los 26 puntos combinan buenas prácticas, referencias de estándares y obligaciones que dependen del caso. Aplicar todos indiscriminadamente puede añadir trabajo sin resolver un riesgo.

Si ocurre estoQué hacer
Falla una tarea esencial o se exponen datos o secretos.Trátalo como bloqueo del recorrido o superficie afectada. Corrige y repite la prueba antes de exponerla.
Falta evidencia de un punto aplicable.Mantenlo pendiente. Define quién lo comprobará y con qué entorno.
El punto no corresponde a tus funciones.Marca «No aplica» y registra la razón. Revísala cuando cambie el producto.
Es una mejora no crítica de presentación.Priorízala según propósito e impacto. Documenta la decisión sin convertirla en cumplimiento demostrado.

Prueba el resultado, no la instalación.

Instalar analítica no prueba que recibas alertas. Tener una copia no prueba que puedas restaurarla. Añadir un banner no prueba que se respete la elección.

Cuándo ampliar esta guía.

Este es un punto de partida de lanzamiento, no una auditoría exhaustiva. Algunas webs requieren revisiones específicas:

Tu web incluye…Amplía la revisión a…Referencia
Cuentas, sesiones o contenido de usuariosAutenticación, sesión, CSRF, autorización y exposición de información.OWASP ASVS
Entradas que se muestran, consultan o suben como archivosCodificación contextual, consultas parametrizadas y seguridad de subidas.OWASP Input Validation
Pagos o contrataciónImportes, estados, reintentos, proveedores y obligaciones comerciales aplicables.LSSI, España
Vídeo, audio o interacciones complejasSubtítulos, alternativas y criterios de accesibilidad de la experiencia completa.WCAG 2.2

Notas de uso y fuentes.

Cada ficha enlaza la documentación que respalda el control. Las instrucciones de comprobación son una síntesis práctica: no son citas literales ni una certificación otorgada por esas organizaciones.

Los apartados de datos delimitan principios y preguntas de revisión para España/UE. La aplicación jurídica depende de actividad, tratamiento y jurisdicción; esta guía no sustituye su evaluación. WCAG es una referencia técnica y no se convierte aquí en una obligación legal universal.

Revisión editorial: 14 septiembre 2026. Selección, condiciones y guía práctica: marbuilds. No se incluyen datos ni auditorías privadas de webs reales.