Checklist antes de lanzar tu web: lo que reviso siempre antes de publicar

Crear una web es relativamente fácil. Puedes partir de una plantilla, pedir a una IA que genere la estructura y tener algo visible en pocos días.

Publicarla de forma profesional es otra cosa.

Una web preparada para recibir clientes debe explicar bien el negocio, funcionar en móvil, proteger los datos, cargar con rapidez y permitir completar sus acciones principales sin errores. Si vende, además tiene que cobrar correctamente, controlar el stock y enviar las confirmaciones correspondientes.

Esta es la lista que utilizo antes de publicar mis propios proyectos. No busca alcanzar una perfección imposible. Busca evitar fallos importantes que después cuestan ventas, tiempo o problemas legales.

Primero: define qué puede salir mal

No todas las webs necesitan la misma revisión.

Un portfolio personal tiene menos riesgo que una tienda. Una página de servicios puede limitarse a recibir formularios, mientras que una plataforma con usuarios debe gestionar sesiones, permisos y datos privados.

Antes de revisar colores o animaciones, define el recorrido principal:

¿Qué debe poder hacer una persona sin encontrar ningún problema?

Puede ser solicitar presupuesto, reservar una cita, comprar un producto o acceder a una cuenta.

Después identifica qué ocurriría si ese recorrido fallara. Esta tabla permite ordenar prioridades:

Lo decorativo puede mejorarse después. Lo que afecta a dinero, datos o acceso debe resolverse antes.

1. Legal y privacidad: que los textos describan la web real

Copiar el aviso legal de otra empresa no soluciona nada. Tus páginas legales deben coincidir con tu actividad, los formularios instalados y los proveedores que utilizas.

Identifica correctamente al titular

Si prestas servicios económicos desde España, la LSSI exige que determinados datos puedan consultarse de forma permanente, fácil, directa y gratuita. Esto puede incluir el nombre o denominación social, domicilio, correo de contacto, NIF e información clara sobre impuestos y gastos cuando se muestran precios.

Antes de publicar compruebo que el titular del aviso legal coincide con quien emitirá las facturas y que el correo de contacto funciona. También reviso que no queden nombres, direcciones o proveedores heredados de una plantilla.

Informa cuando recojas datos

Un formulario sencillo ya puede recoger nombre, correo, teléfono, dirección IP o información escrita por el usuario.

La AEPD recomienda informar por capas: un resumen junto al formulario y una política completa enlazada desde ese mismo punto. La primera capa debería identificar al responsable, explicar la finalidad, indicar la base jurídica y señalar cómo ejercer los derechos.

No siempre necesitas una casilla obligatoria para que el usuario “acepte la política de privacidad”. Informar y obtener consentimiento son cosas distintas. Cuando el consentimiento sea realmente la base del tratamiento —por ejemplo, para enviar comunicaciones comerciales— debe recogerse de forma específica, separada y mediante una acción afirmativa; las casillas premarcadas no son válidas.

En la práctica, reviso que un formulario de contacto no suscriba automáticamente a nadie a una newsletter y que los campos solicitados sean realmente necesarios.

Configura las cookies según lo que uses

Una web que solo utiliza cookies estrictamente necesarias no necesita fingir una elección que no existe. En cambio, si instala analítica no exenta, publicidad o seguimiento, esos sistemas deben esperar a que el usuario decida.

La AEPD establece que aceptar y rechazar deben presentarse en un formato destacado y al mismo nivel, sin hacer que rechazar resulte más complicado.

Además de mirar el banner, abro las herramientas del navegador y compruebo qué solicitudes se realizan antes de pulsar ningún botón. Un banner correcto visualmente no sirve si Google Analytics, Meta Pixel u otros scripts ya se han cargado.

Cuando una web utiliza AdSense para publicar anuncios personalizados en el Espacio Económico Europeo, Reino Unido o Suiza, Google exige una plataforma de gestión del consentimiento certificada e integrada con el TCF de IAB. La certificación de Google no sustituye el cumplimiento legal del editor.

Revisa las condiciones si vendes

Una tienda debe explicar antes del pago quién vende, qué se compra, cuál es el precio total, qué impuestos se aplican, cuánto cuesta el envío y cómo funcionan las devoluciones.

Si vendes contenido digital descargable, no basta con escribir que “no admite devoluciones”. Para aplicar la excepción al desistimiento, el inicio de la descarga debe producirse con consentimiento expreso previo y con el reconocimiento de que se pierde ese derecho, además de facilitar la confirmación correspondiente.

Esta guía sirve como control general, pero no sustituye una revisión jurídica adaptada al negocio.

2. Seguridad: no confundas ocultar con proteger

HTTPS es imprescindible, pero no convierte una web en segura por sí solo.

Comprueba el acceso privado

Un panel no está protegido porque utilice una dirección difícil, esté fuera del menú o tenga noindex.

noindex solo sirve para indicar a los buscadores que una página no debe aparecer en los resultados. Para protegerla necesitas autenticación y autorización real en el servidor. Cada operación sensible debe comprobar quién realiza la solicitud y si tiene permiso para ejecutarla. Google, además, necesita poder rastrear una URL para detectar su directiva noindex.

Pruebo el panel sin sesión, con una sesión caducada y llamando directamente a sus rutas. Ocultar un botón administrativo en el navegador no protege la API que hay detrás.

Saca las claves del repositorio

Las claves privadas de Stripe, secretos de webhooks, contraseñas y tokens no deben aparecer en el código público.

En Cloudflare, los secretos de producción se gestionan como bindings cifrados y los valores locales pueden guardarse en .dev.vars o .env. Estos archivos no deben subirse al repositorio.

También busco secretos en commits antiguos, registros de errores, capturas y archivos de ejemplo. Cuando una clave se ha publicado, no basta con borrarla: hay que revocarla y generar otra.

Valida en el servidor

Las restricciones del formulario mejoran la experiencia, pero pueden saltarse enviando una petición manual.

El backend debe validar tipo, formato, longitud y significado del dato. No basta con comprobar que una cantidad es numérica: también debe verificarse que no sea negativa, que exista stock y que el usuario tenga permiso para modificarla. OWASP recomienda validar toda entrada externa antes de procesarla.

Configura las cabeceras con cuidado

Cabeceras como HSTS, Content Security Policy, X-Content-Type-Options o Referrer-Policy pueden reducir determinados riesgos, pero no deberían copiarse sin probarlas.

Una CSP demasiado estricta puede bloquear Stripe, imágenes, fuentes o analítica. HSTS puede afectar a subdominios si se activa con una configuración amplia. OWASP recomienda adaptar estas medidas al proyecto y considerar primero un modo de informe para CSP antes de bloquear recursos.

Ten una copia que puedas restaurar

“Tengo backups” no es suficiente.

Necesitas saber qué se respalda, con qué frecuencia, durante cuánto tiempo y cómo se recupera. La prueba real consiste en restaurar una copia en un entorno controlado.

La primera restauración no debería hacerse durante una incidencia.

3. Rendimiento: optimiza la experiencia, no una puntuación

PageSpeed Insights es útil para detectar problemas, pero obtener un resultado verde no garantiza aparecer primero en Google. Las Core Web Vitals forman parte de la evaluación de la experiencia, junto con muchas otras señales.

Antes de lanzar reviso especialmente las imágenes. Deben tener un tamaño razonable, estar comprimidas y declarar width y height para reservar su espacio y reducir movimientos durante la carga.

Las imágenes situadas fuera de la primera pantalla pueden utilizar loading="lazy". La imagen principal, en cambio, no debería retrasarse de esa forma si es el elemento que determina el LCP. En algunos casos puede beneficiarse de fetchpriority="high", pero no conviene aplicar esa prioridad a todo.

También compruebo que no se descarguen seis pesos tipográficos cuando la web solo utiliza dos, que los scripts no esenciales no bloqueen la carga y que una librería no se haya añadido para resolver una interacción de diez líneas.

La prueba debe realizarse en móvil. Google utiliza principalmente la versión móvil del contenido para indexar y posicionar, y recomienda el diseño responsive como la configuración más sencilla de mantener.

4. SEO técnico: permite que Google encuentre la versión correcta

El SEO técnico no crea demanda por sí solo. Su función es evitar que una configuración incorrecta impida descubrir o interpretar el contenido.

Cada página importante debería tener un título específico, una descripción útil, un encabezado principal claro y una URL estable.

Después reviso cuatro elementos:

Google utiliza las canonicals, redirecciones y URLs incluidas en el sitemap como señales para elegir la versión principal de un contenido duplicado. El sitemap ayuda al rastreo, pero no garantiza la indexación.

Los datos estructurados deben describir lo que realmente aparece en la página. Añadir Organization, Article, Product o BreadcrumbList puede ayudar a Google a comprender el contenido, pero no garantiza un resultado enriquecido.

También verifico la propiedad en Search Console, envío el sitemap e inspecciono al menos la home, una página de servicio y un artículo.

5. Accesibilidad: pruébala sin ratón

Una auditoría automática detecta parte de los problemas, pero no puede decidir si un menú resulta comprensible o si el texto alternativo explica correctamente una imagen.

Empiezo recorriendo toda la web con Tab, Shift + Tab, Enter y Escape. El foco debe seguir un orden lógico y verse en todo momento.

WCAG 2.2 establece una relación mínima de contraste de 4,5:1 para texto normal y exige que los elementos operables mediante teclado dispongan de un indicador de foco visible.

Los formularios necesitan etiquetas asociadas a sus campos. Un placeholder desaparece al escribir y no sustituye a un label.

Las imágenes informativas deben tener un texto alternativo que explique su función. Las puramente decorativas deberían utilizar alt="" para evitar ruido innecesario en los lectores de pantalla.

También compruebo el zoom al 200 %, la orientación horizontal y la preferencia de movimiento reducido. Una animación atractiva no debería impedir que alguien utilice la página.

6. Prueba el recorrido completo

Una página puede parecer terminada y no realizar ninguna acción.

Por eso no doy por probado un formulario cuando aparece un mensaje verde. Envío una consulta y compruebo que llega a la bandeja correcta, con un remitente reconocible y toda la información necesaria.

En una tienda realizo una compra completa en modo de prueba. Compruebo precio, IVA, envío, variante, stock, pago, webhook, creación del pedido y correo de confirmación.

Después pruebo el camino contrario: tarjeta rechazada, producto agotado, doble clic, dirección incompleta y error del proveedor de pagos.

Un pago correcto demuestra que existe un camino que funciona. No demuestra que el sistema gestione bien los fallos.

También abro todos los enlaces principales, pruebo la página 404 y reviso la consola del navegador. Una 404 visualmente correcta debe devolver realmente un código 404, no un 200.

7. El lanzamiento continúa después de publicar

El mensaje “Deployment successful” solo confirma que el despliegue terminó.

Durante las primeras 24 horas reviso formularios, pagos, correos, logs y consumo de servicios. Durante la primera semana observo qué dudas tienen los usuarios y dónde abandonan.

Configuro como mínimo:

• Analítica para las acciones importantes.
• Registro de errores.
• Monitor de disponibilidad.
• Alertas del proveedor.
• Search Console.

Los logs no deberían almacenar contraseñas, tokens, datos completos de tarjetas ni información personal que no sea necesaria.

Checklist final antes de pulsar “Publicar”

La regla de oro

Ninguna web se publica completamente terminada. La mía tampoco.

Siempre aparecerán textos que pueden aclararse, nuevos dispositivos, errores poco frecuentes y funciones que ya no aportan.

La checklist no busca retrasar el lanzamiento. Busca separar lo que debe resolverse antes de publicar de lo que puede mejorarse después con datos reales.

Antes de lanzar deben estar resueltos la privacidad, la seguridad básica, los formularios, los pagos y el recorrido principal.

Después puedes mejorar la conversión, el contenido, el posicionamiento y los detalles visuales.

Mi criterio es este:

Publica cuando el recorrido principal sea fiable, la información sea honesta y puedas detectar y corregir lo que falle.

El lanzamiento no es el final del proyecto. Es el momento en el que empiezas a comprobar cómo funciona fuera de tu pantalla.