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

Una checklist 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. Las comprobaciones están agrupadas en doce áreas y vienen en una plantilla de Excel y Google Sheets para tu gestor de proyectos. Las últimas secciones tratan la ronda de revisión con el cliente, para que no acabe en treinta correos y capturas sin contexto.

¿Qué es una checklist web?

Una checklist web (o checklist QA web) es una lista estructurada de comprobaciones de calidad que el equipo pasa a una web antes del lanzamiento para confirmar que las páginas cargan, los formularios llegan, el diseño aguanta en dispositivos reales, los buscadores pueden indexarla y se cumple lo legal. QA significa control de calidad (quality assurance); la checklist hace que sea repetible y no dependa de la memoria de nadie.

No es lo mismo que la revisión del cliente. El QA es el equipo comprobando su propio trabajo frente a lo especificado; la aceptación del cliente viene después, en las pruebas de aceptación. Hacer primero el QA significa que el cliente revisa una web que ya funciona y solo tiene que juzgar si es lo que quería.

¿Cómo se usa una checklist web?

No le pases la lista entera a una sola persona. Repártela por áreas, prueba en un entorno de pruebas igual al real, apunta cada incidencia en un único sitio con captura y URL, y después corrige y vuelve a probar solo lo que ha cambiado. Marca lo que no aplique como «no aplica» en vez de borrarlo, para que la lista te sirva en el siguiente proyecto.

1. Asigna cada área a alguien: quien desarrolla 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 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 lo que ha cambiado: más un repaso rápido a formularios y pago, que es donde un arreglo suele romper otra cosa.

¿Qué debe incluir una checklist web?

Cubre doce áreas: funcionalidad, formularios, enlaces, responsive y dispositivos, navegadores, rendimiento, SEO básico, accesibilidad, contenidos y textos, legal y cookies, analítica, y las comprobaciones propias de WordPress o del gestor de contenidos que use la web. Las listas de abajo son las mismas que trae la plantilla descargable.

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

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

12. WordPress y gestor de contenidos

• WordPress, el tema y los plugins actualizados; plugins y temas sin uso eliminados
• Ningún usuario «admin» por defecto; todas las cuentas con contraseña fuerte y el rol adecuado
• Modo depuración desactivado en la web publicada (WP_DEBUG en false)
• Enlaces permanentes con la estructura de URL acordada
• Copias de seguridad automáticas programadas y una restauración probada
• La cuenta de edición del cliente puede editar las páginas que va a mantener

La lista de accesibilidad cubre lo básico; el estándar completo son las pautas WCAG del W3C. Para el rendimiento, PageSpeed Insights da los mismos datos de laboratorio y de campo que usa Google.

¿Cómo se organiza la revisión con el cliente y los testers?

Manda un mensaje breve con el enlace de pruebas, las páginas que revisar y una fecha; pide una incidencia por aviso, cada una con la URL, el dispositivo, qué ha pasado y qué esperaba; clasifica una vez al día en errores, cambios de contenido y peticiones nuevas; y cierra el círculo pidiendo que revisen solo lo corregido.

La checklist te dice qué revisar. Lo que suele fallar es cómo te llegan las incidencias: un correo de cuarenta líneas, dos audios de WhatsApp y un PDF con flechas sobre la captura de otra página, seguido de una 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: qué páginas, hasta cuándo y cómo avisar. Por ejemplo: «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. Nuestra plantilla de reporte de errores está lista 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; son alcance del proyecto, no QA.
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 Google Tag Manager) y aparece un botón de feedback. Quien revisa lo pulsa, el navegador pide permiso para capturar la pestaña y dibuja 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 tu gestor de proyectos: una incidencia en Jira, una tarjeta en Trello, una tarea en ClickUp, Asana o Wrike, un elemento en monday.com, una página en Notion, un mensaje en Slack o Discord, o un email a tu equipo.

¿Qué se puede automatizar en el QA de una web?

Automatiza lo mecánico: enlaces rotos con un rastreador, rendimiento con PageSpeed Insights o Lighthouse, SEO básico con un rastreador o tu plugin de SEO, y parte de la accesibilidad con un comprobador automático. Deja a las personas lo que una herramienta no juzga: dispositivos reales, contenido real, si los textos y los precios son correctos y cómo lo vive el cliente.

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.

¿Qué revisar en las primeras 48 horas tras el lanzamiento?

Repite las pruebas de formularios en el dominio definitivo, confirma el SSL y la redirección con y sin www, comprueba que la analítica registra visitas reales, envía el sitemap en Search Console, haz una copia de seguridad y deja el botón de feedback activo un par de semanas para que el cliente avise de lo que vea cuando lleguen las visitas reales.

• 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

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.