Checklist QA web: cómo probar una web antes del lanzamiento

Una checklist QA web es la lista de pruebas que una web debe superar antes del lanzamiento: contenidos, enlaces, formularios, dispositivos, velocidad, accesibilidad, SEO básico, consentimiento, seguridad, analítica y copias de seguridad. Recórrela en un orden fijo, anota cada fallo en un único sitio, corrige, vuelve a probar y lanza solo cuando no quede nada bloqueante. Esta guía recoge la checklist completa por áreas, un proceso de QA numerado, una tabla de tipos de prueba con quién las hace y cuándo, y las respuestas a las preguntas que más hacen los clientes.

Última actualización: 19 de octubre de 2026.

¿Qué es el QA de una web y por qué importa?

El control de calidad (QA) es la revisión planificada de una web frente a lo que debe hacer, antes de que los visitantes reales encuentren los fallos por ti. No es un repaso rápido de la página de inicio en el portátil del desarrollador. Es un conjunto de pruebas, hechas en dispositivos y navegadores reales, con un registro de lo que falló y la prueba de que se corrigió.

Importa porque el lanzamiento es el momento en que todos juzgan la web a la vez: clientes, buscadores y cualquiera que compruebe si tus formularios te llegan. Un formulario de contacto roto, un banner de cookies que carga rastreadores antes del consentimiento o una página que no se desplaza en un móvil concreto pueden costar más que toda la fase de pruebas.

En Odduel, agencia de creatividad y tecnología en Barcelona y São Paulo, el QA forma parte de cada proyecto de diseño y desarrollo web, no es un extra al final. Buena parte de las comprobaciones repetitivas (rastreo de enlaces, capturas en muchos anchos, revisión del diseño en varios idiomas) la hacen scripts, para que las personas dediquen su tiempo al criterio: si se lee bien, si transmite lo que debe, si funciona para quien usa el teclado o un lector de pantalla.

En resumen: el QA convierte una web que funciona en una pantalla en una web que funciona para todos. Necesita una checklist escrita, dispositivos reales, un registro de fallos y una segunda pasada después de corregir. Empiézalo cuando los contenidos sean definitivos, no la mañana del lanzamiento. Y reserva tiempo para las correcciones que va a encontrar.

¿Cuándo empezar a probar una web?

Las pruebas deben empezar mucho antes de la última semana. Algunas comprobaciones corresponden al diseño (contraste, tamaño de las zonas táctiles, orden de los encabezados), otras al desarrollo (formularios, diseño adaptable), y la pasada completa va al final, cuando los contenidos son definitivos.

Una regla útil: no se puede terminar el QA con textos provisionales. Los titulares reales son más largos, las fotografías reales pesan más y las páginas legales reales cambian el pie de página. Planifica la pasada completa después de cerrar los contenidos y deja margen para una ronda entera de correcciones y nuevas pruebas. Si trabajas con un entorno de pruebas, prueba allí primero y repite las comprobaciones críticas en la dirección real justo después del lanzamiento, porque los servidores, las cachés y los certificados cambian.

Si aún estás decidiendo cómo se va a construir la web, nuestra guía de desarrollo web explica las fases anteriores a esta.

La checklist QA web, área por área

Cada área recoge qué probar. Marca cada línea como superada, fallida o no aplicable, y anota cada fallo con la dirección de la página, el dispositivo, el navegador y una captura.

Contenidos y textos

• Cada página tiene su texto definitivo: nada de lorem ipsum, nada de “XX”, ninguna nota de borrador.
• La ortografía y la gramática están revisadas en cada idioma de la web.
• Nombres, direcciones, teléfonos y horarios coinciden exactamente con tus otros perfiles.
• Fechas, precios y razones sociales están al día y son coherentes en todas las páginas.
• Las imágenes son las versiones finales, bien recortadas en todos los anchos y con un texto alternativo útil.
• Los encabezados siguen un orden lógico: un H1 por página, luego H2 y luego H3.
• Las páginas legales (privacidad, cookies, aviso legal) están publicadas y enlazadas desde el pie de página.
• Ninguna palabra queda sola en la última línea de un titular en los anchos habituales.

Enlaces y navegación

• Un rastreador no encuentra enlaces internos rotos (ningún error 404).
• Los enlaces externos abren la página correcta y siguen funcionando.
• El menú principal, el menú del pie y las migas de pan funcionan en todas las páginas.
• Las direcciones antiguas de la web anterior redirigen con un 301 a las nuevas.
• Los enlaces de teléfono llaman, los de correo se abren con la dirección correcta y los de mapa abren la ruta.
• La página 404 existe, está diseñada y ayuda al visitante a encontrar el camino de vuelta.

Formularios

• Cada formulario se envía y el mensaje llega al buzón correcto.
• El visitante ve una confirmación clara, y el correo de confirmación, si lo hay, llega y se lee bien.
• Los campos obligatorios, los mensajes de error y la validación funcionan, también con el formulario vacío.
• Los errores se anuncian con claridad y el foco pasa al primer campo incorrecto.
• La protección contra el spam funciona sin bloquear a personas reales.
• La casilla de consentimiento, donde haga falta, no viene marcada y enlaza a la política de privacidad.
• Los datos del formulario se guardan o se reenvían solo donde indica tu política de privacidad.

Navegadores y dispositivos

• Versiones actuales de Chrome, Safari, Firefox y Edge en escritorio.
• Safari en iPhone y Chrome en Android, en móviles reales, no solo en un emulador.
• Anchos habituales, de móviles pequeños a pantallas de escritorio grandes, en vertical y en horizontal.
• Táctil: los menús se abren y se cierran, nada depende del paso del ratón y las zonas táctiles son lo bastante grandes.
• Las animaciones y los efectos de scroll se comportan bien y respetan el ajuste del sistema de movimiento reducido.
• La web sigue funcionando, en lo básico, cuando un script no se carga.

Rendimiento y Core Web Vitals

• Mide las tres Core Web Vitals que Google describe en su documentación de Search Central: Largest Contentful Paint (carga), Interaction to Next Paint (respuesta) y Cumulative Layout Shift (estabilidad visual).
• Prueba las páginas más pesadas, no solo la de inicio: un artículo largo, una galería, una ficha de producto.
• Las imágenes están en formatos modernos, con el tamaño del espacio que ocupan y con carga diferida por debajo de la primera pantalla.
• Las fuentes están alojadas en tu servidor o precargadas, con una fuente de reserva que evita que las líneas salten.
• La caché y la compresión están activadas, y los archivos estáticos tienen una vida de caché larga.
• Ningún script de terceros bloquea el primer pintado.

Accesibilidad

• Revisa con las WCAG 2.2 nivel AA, la pauta vigente del W3C, como objetivo de trabajo.
• Cada página se puede usar solo con el teclado, con un indicador de foco visible.
• El contraste del texto llega a 4,5:1 en el texto normal y a 3:1 en el texto grande, sobre el color de fondo real.
• Las imágenes llevan un texto alternativo que las describe, y las decorativas, un alt vacío.
• Los campos de formulario tienen etiqueta y los errores no se indican solo con el color.
• Una prueba con lector de pantalla (VoiceOver o NVDA) en los recorridos clave: inicio, un servicio, el formulario de contacto.
• Si vendes productos o determinados servicios a consumidores de la UE, comprueba si te afecta la Ley Europea de Accesibilidad: la Directiva (UE) 2019/882 se aplica desde el 28 de junio de 2025, con exenciones para las microempresas que prestan servicios.

SEO básico

• Cada página tiene un título y una meta descripción únicos.
• Las direcciones son cortas, en minúsculas y con guiones; nuestra guía de URL optimizadas para SEO explica cómo elegirlas.
• Cada página incluye un enlace canónico, y las páginas traducidas llevan hreflang.
• Existe un sitemap XML y solo recoge las páginas que quieres que se encuentren.
• El robots.txt permite rastrear la web real y no queda ningún “noindex” olvidado del entorno de pruebas.
• Los datos estructurados (organización, artículos, migas de pan) se validan sin errores.
• La imagen y el título para compartir aparecen bien al pegar un enlace en una app de mensajería.

Privacidad, consentimiento y banner de cookies

• Ningún rastreador de analítica o de publicidad se carga antes de que el visitante lo acepte, como exigen el RGPD y las normas de ePrivacy.
• Rechazar es tan fácil como aceptar, y la elección se recuerda.
• El visitante puede cambiar su elección más tarde desde un enlace del pie de página.
• La política de cookies recoge cada cookie y cada clave de almacenamiento del navegador que la web usa de verdad.
• Los vídeos, mapas y chats integrados también esperan al consentimiento o usan un modo respetuoso con la privacidad.

Seguridad

• HTTPS en todas las direcciones, con el certificado válido y renovándose solo.
• La versión HTTP y la versión con www redirigen a una única dirección preferida.
• Las cabeceras de seguridad están configuradas (HSTS, tipo de contenido, protección de marcos, política de referencia).
• Las áreas de administración usan contraseñas robustas y verificación en dos pasos; las cuentas por defecto se eliminan.
• El software, los temas y los plugins están actualizados, y los que no se usan se eliminan.
• Los formularios y las páginas de acceso limitan los intentos repetidos.
• Ningún archivo de prueba, copia de seguridad o archivo de configuración se puede descargar desde la web.

Analítica y medición

• La analítica registra las páginas vistas y los eventos que importan (formulario enviado, llamada pulsada, compra).
• El tráfico de prueba se excluye o se marca, para que las cifras de la semana del lanzamiento sean limpias.
• El modo de consentimiento, si se usa, transmite la elección del visitante a cada etiqueta.
• Search Console y las demás herramientas para webmasters están verificadas, y el sitemap está enviado.

Copias de seguridad y vuelta atrás

• Existe una copia de seguridad completa de archivos y base de datos antes del lanzamiento, guardada fuera del servidor.
• Las copias automáticas están programadas y se ha probado de verdad al menos una restauración.
• Sabes cómo volver a la versión anterior en minutos si el lanzamiento sale mal.
• La monitorización de disponibilidad está activa y las alertas llegan a una persona que puede actuar.

¿Cómo hacer el control de calidad (QA) de una web, paso a paso?

Una checklist solo funciona dentro de un proceso. Este es el orden que seguimos.

1. Cierra los contenidos. Deja acordado que textos, imágenes y páginas legales son definitivos para esta ronda.
2. Escribe el plan de pruebas. Enumera las páginas, recorridos, navegadores, dispositivos y anchos que vas a cubrir, y quién prueba qué.
3. Lanza las comprobaciones automáticas. Rastreo de enlaces, validación HTML, análisis de accesibilidad, medidas de rendimiento, capturas en muchos anchos.
4. Haz las comprobaciones manuales. Recorre cada trayecto clave en dispositivos reales: buscar un servicio, leer un artículo, enviar un formulario, cambiar de idioma.
5. Anota cada fallo en un único sitio. Dirección, dispositivo, navegador, pasos para reproducirlo, captura y gravedad: bloqueante, grave o leve.
6. Corrige y vuelve a probar. Cada corrección la comprueba alguien distinto de quien la hizo, y se vuelve a probar la zona de alrededor.
7. Haz la revisión de lanzar o no lanzar. Lanza solo cuando no quede ningún fallo bloqueante abierto y los graves estén acordados por escrito.
8. Lanza y prueba la web real. Repite las comprobaciones críticas en la dirección real durante la primera hora: formularios, consentimiento, redirecciones, HTTPS, analítica.
9. Vigila la primera semana. Revisa los registros de errores, el registro de 404, la entrega de formularios y Search Console, y corrige lo que revelen los visitantes reales.

¿Qué pruebas necesitas y quién las hace?

No todas las pruebas necesitan un especialista, y no todas se pueden automatizar. La tabla muestra los tipos principales, quién suele hacerlos, cuándo y qué tipo de herramienta se usa.

Tipo de prueba	Quién la hace	Cuándo	Herramientas habituales
Revisión de textos	Cliente y copywriter	Tras cerrar los contenidos	Una checklist, un segundo lector
Enlaces y redirecciones	Desarrollador	Antes y después del lanzamiento	Un rastreador, los registros del servidor
Formularios y correos	Desarrollador y cliente	Antes del lanzamiento y en real	Envíos reales a buzones reales
Navegadores y dispositivos	Tester QA o desarrollador	Pasada final	Móviles reales, servicios de prueba en navegadores
Rendimiento	Desarrollador	Durante el desarrollo y en la pasada final	Lighthouse, PageSpeed Insights, datos de campo
Accesibilidad	Diseñador y desarrollador	Diseño, desarrollo y pasada final	Escáner automático, teclado, lector de pantalla
SEO básico	Responsable de SEO o desarrollador	Pasada final y día del lanzamiento	Rastreador, Search Console, prueba de datos estructurados
Consentimiento y privacidad	Desarrollador y asesor legal	Pasada final	Herramientas para desarrolladores del navegador, la política de cookies
Seguridad	Desarrollador o administrador del servidor	Antes del lanzamiento y con regularidad	Revisión de cabeceras, informes de actualizaciones, límites de acceso
Aceptación del cliente	Cliente	Último paso antes del lanzamiento	Los recorridos reales, una hoja de validación

La pauta que conviene ver: las herramientas automáticas son rápidas y exhaustivas en lo que se puede medir, y las personas hacen falta para todo lo que exige criterio. Un escáner te dirá que un botón no tiene etiqueta; solo una persona te dirá que la etiqueta confunde.

¿Cuánto tarda el QA de una web y de qué depende?

El tiempo depende del tamaño de la web, del número de plantillas e idiomas, de cuántos formularios e integraciones tenga y de cuántos dispositivos te comprometas a cubrir. Una web corporativa pequeña con un formulario se prueba bien en poco tiempo. Una web multilingüe con tienda, sistema de reservas y animaciones a medida necesita días de pasadas cuidadosas y al menos una ronda de correcciones.

Lo que más frena el QA no son las pruebas en sí, sino los contenidos que llegan tarde, la falta de un responsable claro de cada corrección y no tener una escala de gravedad acordada. Cuando todos saben qué significa “bloqueante”, la decisión de lanzar o no lanzar se vuelve sencilla.

Para una sola página de campaña la lista es más corta y la lógica del presupuesto es otra; nuestro artículo sobre cuánto cuesta diseñar una landing page explica cómo se define el alcance de esas páginas.

¿Qué suele fallar en el lanzamiento?

Los mismos fallos aparecen una y otra vez, y casi todos son baratos de detectar antes:

• Formularios de contacto que envían a un buzón de pruebas, o cuyos correos acaban en spam.
• El ajuste “disuadir a los motores de búsqueda” o una etiqueta noindex olvidados del entorno de pruebas.
• Rastreadores que se activan antes del consentimiento porque una etiqueta se añadió fuera de la herramienta de consentimiento.
• Direcciones antiguas sin redirección, de modo que los enlaces desde otras webs y los resultados de búsqueda acaban en un 404.
• Un menú o una ventana emergente que no se puede cerrar en un móvil concreto, o una página que no se desplaza.
• Imágenes subidas al tamaño original de la cámara, que hacen lenta la primera pantalla con datos móviles.
• Una caché que sigue mostrando a los visitantes la hoja de estilos antigua después de un cambio.

Todos ellos están en la checklist de arriba. Lo útil de una lista escrita es que nadie tiene que acordarse de ellos bajo presión.

Preguntas frecuentes

Si tu web está a punto de lanzarse y quieres que se pruebe como es debido, o estás planificando una web nueva y quieres el QA integrado en el trabajo desde el primer diseño, nuestro equipo de diseño y desarrollo web puede ayudarte: cuéntanos tu proyecto y veremos qué necesita tu lanzamiento.

Para seguir leyendo: Seguridad en WordPress en 2027: las amenazas y cómo resolverlas, Accesibilidad web: qué exige la Ley Europea de Accesibilidad, ¿Cuánto se tarda en hacer una web? Los plazos, fase a fase, Checklist de auditoría UX: qué revisar y cómo hacerla en siete pasos, Checklist SEO para un rediseño web: rediseña sin perder tráfico orgánico.