Checklist de lanzamiento de una web: 60 comprobaciones antes de publicar

El día antes de publicar una web siempre tiene algo de víspera de estreno. El diseño está aprobado, los textos están revisados, todo el mundo tiene ganas de verla en marcha. Y justo por eso es el momento en que más fácil resulta pasar por alto un detalle: el formulario que envía los correos a una dirección de pruebas, la etiqueta que impide a Google indexar la web, la página de política de privacidad que se quedó con el texto de la plantilla.

En el estudio llevamos más de veinte años publicando webs y hemos aprendido que la tranquilidad del lanzamiento no depende de la memoria de nadie, sino de una lista. La que compartimos aquí es la que usamos de verdad, agrupada en nueve bloques y con 60 comprobaciones. Algunas te parecerán obvias. Precisamente por eso están: lo obvio es lo que más se olvida con las prisas.

La lista está pensada para webs corporativas, de servicios y de contenidos. Si tu proyecto es una tienda online, úsala como base y añade las comprobaciones de compra y pago que comentamos al final.

01Antes de empezar: cómo usar esta checklist

Tres consejos para que la revisión sea eficaz:

• →Reparte los bloques. Quien ha diseñado revisa mejor el bloque técnico de otro, y viceversa. Los ojos frescos encuentran más cosas.
• →Revisa en el entorno de pruebas (la versión de la web que aún no es pública, lo que se suele llamar staging) todo lo que se pueda, y deja para el día del lanzamiento solo lo que depende del dominio definitivo.
• →Apunta, no arregles sobre la marcha. Primero se recorre la lista y se anotan los fallos con su prioridad; después se corrigen. Así nadie se queda a medias en un bloque.

021. Contenido y textos (8 comprobaciones)

• →1. No queda texto de relleno («lorem ipsum») ni contenido de ejemplo en ninguna página, plantilla o ventana emergente.
• →2. Todos los textos han pasado una revisión ortográfica y de estilo por alguien distinto de quien los escribió.
• →3. Los datos de contacto (teléfono, correo, dirección, horario) son correctos y coinciden en toda la web y con la ficha de Google.
• →4. Los precios, fechas, cifras y nombres propios están verificados.
• →5. Cada página tiene un único titular principal que dice de qué trata.
• →6. Los enlaces internos llevan a donde dicen y no hay ninguno roto.
• →7. Los enlaces externos se abren correctamente y apuntan a páginas vigentes.
• →8. Los textos pequeños están revisados: botones, mensajes de formulario, página 404, aviso de cookies, pie de página.

032. Diseño y dispositivos (7 comprobaciones)

• →9. La web se ve bien en móvil, tableta y escritorio, revisada en dispositivos reales y no solo en el simulador del navegador.
• →10. Se ha probado en Chrome, Safari, Firefox y Edge, y en Safari de iPhone, que suele dar sorpresas propias.
• →11. No hay desbordamientos horizontales en móvil (nada se sale por la derecha).
• →12. Las imágenes se ven nítidas, bien recortadas y en su versión para móvil cuando la tienen.
• →13. El favicon y el icono para la pantalla de inicio del móvil están configurados.
• →14. Las imágenes para compartir en redes (Open Graph) aparecen correctamente al pegar un enlace en WhatsApp, LinkedIn o Facebook.
• →15. Los estados interactivos funcionan: menús, desplegables, carruseles, pestañas, botones en hover y en foco.

043. Formularios y funcionalidades (7 comprobaciones)

• →16. Cada formulario se ha enviado de verdad y el mensaje llega a la dirección correcta, no a una de pruebas.
• →17. La persona que envía el formulario recibe una confirmación clara en pantalla y, si procede, un correo.
• →18. Los correos que envía la web no acaban en la carpeta de spam (el dominio tiene SPF, DKIM y DMARC configurados).
• →19. Los mensajes de error de los formularios se entienden y explican cómo corregir.
• →20. La protección antispam está activa sin entorpecer a las personas.
• →21. Las integraciones funcionan en el entorno real: reservas, CRM, boletín, mapas, chat, pagos.
• →22. La búsqueda interna, si existe, devuelve resultados útiles y muestra algo sensato cuando no encuentra nada.

054. SEO y migración (10 comprobaciones)

• →23. La web no bloquea a los buscadores: no queda la etiqueta noindex del entorno de pruebas ni un Disallow: / en el archivo robots.txt.
• →24. Cada página tiene un título (title) único de unos 50 a 60 caracteres y una meta descripción propia.
• →25. Las URL son legibles, en minúsculas y con guiones.
• →26. Cada página tiene su etiqueta canónica apuntando a sí misma (salvo excepciones intencionadas).
• →27. El sitemap XML existe, solo incluye páginas indexables y está enlazado desde robots.txt.
• →28. Si es un rediseño, todas las URL antiguas redirigen con un 301 a su equivalente nueva.
• →29. Los datos estructurados (organización, negocio local, productos, preguntas frecuentes) son válidos según la prueba de resultados enriquecidos de Google.
• →30. Las imágenes tienen nombres de archivo descriptivos y texto alternativo.
• →31. Si la web es multidioma, las etiquetas hreflang están bien configuradas en todas las versiones.
• →32. La versión con y sin «www», y con y sin «https», terminan todas en una única dirección.

Así debería quedar un robots.txt de producción sencillo. El del entorno de pruebas suele llevar un Disallow: / que bloquea todo, y es justo la línea que no debe viajar a la web pública:

User-agent: *
Allow: /
Sitemap: https://www.tudominio.es/sitemap.xml

Para revisar este bloque en profundidad, en la guía de SEO técnico explicamos cada punto, y si es un rediseño, en cómo rediseñar una web sin perder SEO contamos cómo preparar el mapa de redirecciones.

065. Rendimiento (6 comprobaciones)

• →33. Las Core Web Vitals están en verde en las plantillas principales: LCP de 2,5 s o menos, INP de 200 ms o menos y CLS de 0,1 o menos, medidos con PageSpeed Insights.
• →34. Las imágenes están en formatos modernos (AVIF o WebP), con tamaños adaptados a cada pantalla y carga diferida fuera del primer pantallazo.
• →35. Las fuentes se cargan con font-display: swap u optimización equivalente y solo con los pesos que se usan.
• →36. Los scripts de terceros (chats, píxeles, widgets) son los imprescindibles y se cargan sin bloquear la página.
• →37. La caché del navegador y la compresión (Brotli o gzip) están activas en el servidor.
• →38. Los vídeos de fondo tienen una imagen de reserva, están comprimidos y no llevan sonido automático.

076. Accesibilidad (7 comprobaciones)

• →39. El contraste del texto cumple el mínimo de WCAG 2.2: 4,5:1 para texto normal y 3:1 para texto grande.
• →40. Toda la web se puede recorrer con el teclado, en un orden lógico y con el foco siempre visible.
• →41. Las imágenes informativas tienen texto alternativo y las decorativas lo tienen vacío.
• →42. Los campos de formulario tienen etiquetas visibles asociadas, no solo un texto de ejemplo dentro del campo.
• →43. Los objetivos táctiles miden al menos 24×24 px, como pide WCAG 2.2.
• →44. La estructura de encabezados es ordenada (un H1, luego H2, H3) y el idioma de la página está declarado.
• →45. Las animaciones respetan la preferencia de movimiento reducido del sistema.

En la guía de qué es la accesibilidad web explicamos el porqué de cada uno de estos puntos.

087. Legal y privacidad (6 comprobaciones)

• →46. El aviso legal incluye los datos de identificación que exige la Ley de Servicios de la Sociedad de la Información (LSSI): titular, NIF, domicilio, contacto y, si procede, datos registrales.
• →47. La política de privacidad describe los tratamientos reales de la web (formularios, boletín, analítica) conforme al RGPD.
• →48. La política de cookies refleja las cookies que realmente instala la web.
• →49. El banner de cookies permite aceptar y rechazar con la misma facilidad, y ninguna cookie no técnica se instala antes del consentimiento.
• →50. Los formularios informan de la finalidad del tratamiento y enlazan a la política de privacidad.
• →51. Las imágenes, tipografías, vídeos y música tienen licencia para el uso que se les da.

Para el detalle del consentimiento y la configuración de la analítica, en la guía sobre RGPD y cookies en tu web lo explicamos paso a paso, con las indicaciones de la AEPD.

098. Dominio, seguridad y técnica (6 comprobaciones)

• →52. El certificado SSL está activo y toda la web carga por HTTPS, sin avisos de contenido mixto.
• →53. Los registros DNS del dominio están revisados, incluidos los del correo, para que el cambio no afecte a los buzones.
• →54. Hay una copia de seguridad completa de la web nueva y, si es un rediseño, de la anterior.
• →55. Los accesos de administración usan contraseñas robustas y doble factor, y se han eliminado los usuarios de prueba.
• →56. CMS, plugins y dependencias están actualizados a su última versión estable.
• →57. La página 404 personalizada funciona y ofrece caminos para seguir navegando.

109. Analítica y seguimiento (3 comprobaciones)

• →58. La analítica registra visitas en tiempo real desde el dominio definitivo y respeta el consentimiento.
• →59. Las conversiones clave (formularios, llamadas, clics en WhatsApp, compras) están configuradas como eventos y se han probado.
• →60. La web está verificada en Google Search Console (y en Bing Webmaster Tools) y el sitemap está enviado.

11El día del lanzamiento, paso a paso

Con la lista revisada, el día del lanzamiento sigue un guion corto:

1. 01Copia de seguridad de la web actual y de la nueva.
2. 02Publicación en el servidor definitivo o cambio de DNS, a primera hora de un día laborable.
3. 03Comprobación de que el dominio carga con HTTPS y redirige a la versión única.
4. 04Revisión rápida de robots.txt, etiquetas noindex y sitemap en producción.
5. 05Envío de un formulario de prueba y verificación de la recepción.
6. 06Prueba de una muestra de redirecciones antiguas.
7. 07Comprobación de la analítica en tiempo real.
8. 08Envío del sitemap en Search Console.
9. 09Aviso al equipo y, cuando todo está confirmado, anuncio en redes y a clientes.

12Después de publicar: la primera semana

Un lanzamiento no termina el día que se publica. Durante la primera semana revisamos a diario la cobertura en Search Console, los errores 404 que aparecen en los registros, la llegada de formularios y el comportamiento en la analítica. A las cuatro semanas hacemos una revisión más completa con datos reales. Es el momento de ajustar lo que solo se ve cuando la web está viva.

En SIMA cada web que publicamos pasa por esta lista y por esa primera semana de vigilancia, y después la acompañamos con nuestro servicio de mantenimiento web para que siga en forma. Si estás a punto de lanzar una web y quieres una segunda mirada antes de publicar, escríbenos y la repasamos contigo.