Checklist web: más de 60 comprobaciones antes de lanzar

Una checklist QA web es la lista de comprobaciones que haces antes de publicar una web, para que no sea el cliente (o peor, sus clientes) quien descubra el formulario que no llega, el enlace roto o el banner de cookies que falta. Aquí tienes la checklist completa, ordenada por áreas y lista para copiar en tu gestor de proyectos, y al final cómo organizar la ronda de revisión con el cliente sin acabar con 30 correos y capturas sin contexto.

Cómo usar esta checklist QA web

No le pases la lista entera a una sola persona. Repártela:

1. Asigna cada área a alguien. El desarrollador se queda con funcionalidad y rendimiento; diseño o el PM, con responsive y contenidos; alguien ajeno al proyecto, con formularios y recorridos de usuario.
2. Prueba en el entorno de pruebas con la configuración real. Mismo tema, mismos plugins, contenido definitivo y envío de correo real. Con textos de relleno se esconden la mitad de los fallos.
3. Apunta cada incidencia en un único sitio, con captura, URL y navegador. Más abajo te cuento cómo.
4. Corrige y vuelve a probar solo lo que ha cambiado, más un repaso rápido a formularios y pago, que es donde un arreglo suele romper otra cosa.

Marca lo que no aplique como «no aplica» en vez de borrarlo: así la lista te sirve para el siguiente proyecto.

1. Funcionalidad

• Todas las páginas del mapa web cargan sin errores
• El menú principal y el pie llevan a las páginas correctas
• El buscador devuelve resultados lógicos (y gestiona el «sin resultados»)
• Acceso de usuarios, recuperación de contraseña y área privada funcionan
• Tienda: añadir al carrito, cambiar cantidades, cupón, pago en modo prueba y correo de confirmación
• Reservas, calculadoras, filtros, sliders y demás elementos interactivos funcionan
• Existe una página 404 con diseño y enlaces de vuelta
• El favicon aparece en la pestaña del navegador

2. Formularios

• Todos los formularios se envían y muestran un mensaje de confirmación claro
• Los envíos llegan al correo o CRM correcto (el del cliente, no el tuyo)
• Los campos obligatorios y los mensajes de error tienen sentido
• Las respuestas automáticas salen con el texto y el remitente correctos
• Hay protección antispam (honeypot, reCAPTCHA o similar)
• El alta en la newsletter añade el contacto a la lista correcta
• La subida de archivos acepta los formatos y tamaños previstos

3. Enlaces

• Ningún enlace interno roto (pasa un rastreador como Screaming Frog o un plugin de enlaces rotos)
• Ningún enlace apunta al dominio de pruebas
• Los enlaces externos funcionan
• Los teléfonos usan tel: y los correos mailto:
• Los iconos sociales llevan a los perfiles reales del cliente, no a los de la demo del tema
• Si es un rediseño, las URL antiguas redirigen (301) a las nuevas

4. Responsive y dispositivos

• Revisa cada plantilla en móvil, tableta, portátil y pantalla grande
• Prueba en al menos un iPhone y un Android reales, no solo con las herramientas del navegador
• El menú se abre y se cierra bien en pantallas táctiles
• El texto se lee sin hacer zoom y los botones se pulsan con facilidad
• No hay scroll horizontal en móvil
• Las imágenes no salen estiradas, mal recortadas ni pixeladas
• Los pop-ups y el banner de cookies se pueden cerrar en pantallas pequeñas

5. Navegadores

• Últimas versiones de Chrome, Safari, Firefox y Edge
• Safari en iOS (no se comporta igual que en escritorio)
• Cualquier navegador que use mucho el público del cliente (míralo en su analítica actual)
• Tipografías, animaciones y cabeceras fijas se comportan igual en todos

6. Rendimiento

• Pasa PageSpeed Insights a la home y a la plantilla más pesada
• Imágenes comprimidas y con un tamaño razonable (WebP o AVIF si se puede)
• Caché y CDN configurados si el hosting lo permite
• Sin plugins, scripts ni fuentes que no se usan cargando en todas las páginas
• Sin vídeos pesados en reproducción automática en móvil

7. SEO básico

• Cada página tiene un título y una meta descripción únicos
• Un solo H1 por página y encabezados en orden lógico
• Quitado el «Disuadir a los motores de búsqueda» o el noindex en la web publicada
• robots.txt permite el rastreo y existe un sitemap XML
• Las URL canónicas apuntan al dominio definitivo
• Redirecciones 301 desde las URL antiguas (sin ellas un rediseño pierde posiciones)
• Imagen y título Open Graph para redes sociales
• Web dada de alta en Google Search Console y sitemap enviado tras el lanzamiento

8. Accesibilidad básica

• Las imágenes con contenido tienen texto alternativo
• El texto tiene contraste suficiente con el fondo
• Se puede navegar solo con el teclado (Tab, Intro, Esc) y se ve el foco
• Los campos de formulario tienen etiqueta, no solo placeholder
• Los enlaces dicen adónde llevan («Ver precios», no «Haz clic aquí»)
• El idioma de la página está declarado en el HTML

Si quieres ir más allá, el estándar de referencia son las pautas WCAG del W3C.

9. Contenidos y textos

• Ni rastro de lorem ipsum ni de «Página de ejemplo»
• Ortografía revisada, también en botones y mensajes de error
• Precios, horarios, direcciones y teléfonos confirmados por el cliente
• Imágenes con licencia y en su versión final
• Fechas del pie y del blog correctas
• Traducciones completas en todas las versiones de idioma

10. Legal y cookies

• Aviso legal, política de privacidad y condiciones publicados y enlazados en el pie
• El banner de cookies aparece antes de cargar cookies no esenciales y permite aceptar y rechazar
• Los formularios incluyen la casilla o el texto informativo de privacidad
• Tienda: información de envíos, devoluciones y derecho de desistimiento publicada

11. Analítica y medición

• La analítica está instalada en el dominio definitivo y recibe visitas
• Se registran las conversiones (formulario enviado, compra, clic en teléfono)
• Las etiquetas respetan el consentimiento de cookies
• El entorno de pruebas está bloqueado a buscadores y excluido de la analítica

Cómo organizar la revisión con el cliente y los testers

La checklist te dice qué revisar. Lo que suele fallar es cómo te llegan las incidencias. El escenario típico: el cliente te manda un correo con 40 líneas, dos audios de WhatsApp y un PDF con flechas sobre una captura de otra página. Y te pasas la mañana preguntando «¿en qué página?», «¿desde qué móvil?» y «¿qué esperabas ver?».

Una forma mejor de hacerlo:

1. Manda un mensaje breve con el enlace de pruebas. Di qué páginas revisar, hasta cuándo y cómo avisar. Por ejemplo:

   Hola, Marta: la nueva web ya está lista para revisar en pruebas.tudominio.es. Échale un vistazo a la home, las páginas de servicios y el formulario de contacto antes del jueves. Si ves algo raro, pulsa el botón «Give Feedback» de la parte inferior, marca el problema en la captura y escribe qué esperabas. No necesitas crearte ninguna cuenta.

2. Pide una incidencia por aviso. «El menú, el pie y el precio» en un solo mensaje son tres tareas, y una siempre se pierde.
3. Que cada aviso tenga los mismos datos: qué ha pasado, qué esperaba, URL, dispositivo y navegador, y una captura. En nuestra guía sobre cómo escribir un informe de bugs tienes una plantilla para compartir.
4. Clasifica una vez al día. Etiqueta cada aviso como error, cambio de contenido o petición nueva. Las peticiones nuevas van a otra lista: no son QA, son alcance del proyecto.
5. Cierra el círculo. Marca lo resuelto y pide a quien lo reportó que revise solo eso.

Para esto hicimos GiveFeedback.io. Pegas un script en el <head> de la web (en la ayuda hay guías para WordPress, Shopify, Wix, Squarespace, PrestaShop y otros) y aparece un botón de feedback. Quien revisa lo pulsa, el navegador pide permiso para capturar la pestaña y puede dibujar sobre la captura con flechas, recuadros, texto y subrayador. Cada aviso llega con la URL, la resolución de pantalla, el sistema operativo, el navegador y su versión, sin que nadie tenga que escribirlos.

Los avisos llegan a un panel donde los filtras por Abierto, Resuelto o Archivado, o pasan directamente a Notion o Asana como páginas o tareas. Sus límites, para que lo sepas: captura la parte visible de la página (no la página entera), no graba vídeo, no recoge los logs de consola ni de red, el botón del widget está en inglés y por ahora solo se integra con Notion y Asana.

Qué automatizar y qué revisar a mano

Las herramientas pillan rápido los errores mecánicos. Las personas pillan lo que de verdad molesta al cliente: el teléfono equivocado, la foto de la oficina antigua, el botón que nadie entiende.

Después del lanzamiento: las primeras 48 horas

• Repite las pruebas de formularios en el dominio definitivo
• Comprueba el SSL con y sin www, y que una versión redirige a la otra
• Confirma que la analítica registra visitas reales
• Envía el sitemap en Search Console
• Haz una copia de seguridad
• Deja el botón de feedback activo un par de semanas para que el cliente avise de lo que vea

Cuando el QA está hecho, falta que el cliente confirme que la web hace lo que pidió. Eso son las pruebas de aceptación, y las explicamos en la guía de pruebas de aceptación (UAT) para webs.

Copia la checklist, quita las áreas que no apliquen a tu tipo de proyecto y guárdala como plantilla. La segunda vez que la uses, el QA te llevará la mitad de tiempo, porque nadie tendrá que acordarse de qué revisar.