Cómo revisar una web creada con IA antes de publicarla

Una IA puede crear en minutos una landing page o un formulario que parece terminado. Esa velocidad es la ventaja del vibe coding, pero también facilita confundir una buena vista previa con un producto listo. Una web puede verse impecable y tener enlaces equivocados, datos que desaparecen, errores sin explicación o una acción de servidor que confía en valores modificables.

Este control de publicación usa como ejemplo la inscripción a un taller. La persona elige una sesión, escribe su nombre y correo y recibe una confirmación. Siete controles separan el borrador generado de una versión que puedes publicar con responsabilidad. Cada uno exige una prueba observable, no la frase «debería funcionar».

1. Fija el resultado y el alcance antes de probar

Escribe una frase con el resultado obligatorio: «En móvil y escritorio, una persona interesada puede elegir un taller disponible, enviar datos de contacto válidos y recibir una confirmación inequívoca». Añade lo que no forma parte de esta versión, por ejemplo pagos, cuenta de usuario o sincronización de calendario.

Este límite evita que la IA añada funciones durante la revisión y altere lo que ya funcionaba. Un prompt bien acotado también indica la zona afectada, lo que debe permanecer igual y los criterios de aceptación. Guarda el estado inicial en el control de versiones o como vista previa con nombre para identificar exactamente lo probado.

2. Recorre el camino principal en un navegador real

Abre la web como visitante, no solo como quien lee el código. Empieza en la entrada pública, navega hasta la inscripción, elige una sesión, completa el formulario y revisa el resultado. Repite después de recargar y con una pantalla estrecha. Los enlaces, el foco, la espera y la confirmación forman parte del recorrido.

Playwright recomienda probar el comportamiento visible para la persona usuaria. Localiza un botón por su rol y nombre accesible y comprueba el mensaje de éxito visible. Una clase CSS interna no demuestra que alguien pueda encontrar o comprender la acción.

El caso correcto no basta. Prueba como mínimo un estado vacío, una entrada no válida y un fallo técnico:

• No hay sesiones: la página explica la situación y ofrece un siguiente paso útil.
• El correo es incorrecto: el campo recibe una explicación comprensible y conserva el foco.
• Hay doble clic o red lenta: la inscripción no se guarda dos veces.
• El servidor no responde: los datos no desaparecen en silencio ni se finge éxito.

3. Protege ambos lados del formulario

Los tipos de campo de HTML, required, límites razonables y respuesta inmediata ayudan a corregir errores. MDN recuerda que la validación del cliente no es una medida de seguridad completa porque una petición puede evitar la interfaz. El servidor debe imponer por separado los mismos límites de negocio.

En la inscripción, el servidor acepta solo identificadores de sesiones reales, limita la longitud de los campos, normaliza el correo de forma consciente y rechaza datos inesperados. También confirma que queda una plaza. Un valor oculto en el formulario no es una autorización.

Dibuja el recorrido de los datos: qué sale del navegador, dónde se guarda, quién puede leerlo y cuándo se elimina. Si la IA no puede obtener una respuesta clara del código y la configuración, todavía existe un riesgo abierto.

4. Comprueba teclado, semántica y mensajes

WCAG ofrece un estándar compartido para contenido web más accesible. No necesitas memorizarlo entero para una publicación pequeña, pero el recorrido principal debe ser comprensible y utilizable sin ratón. Navega con Tab, Mayús+Tab, Enter y Espacio. El foco no debe desaparecer ni quedar detrás de un diálogo.

Revisa etiquetas visibles, orden de encabezados, contraste, alternativas de imágenes y mensajes de estado. Amplía al 200 por ciento y usa una pantalla estrecha. Una auditoría automática encuentra muchos problemas básicos, pero no sustituye la prueba de teclado ni una revisión breve con lector de pantalla o con personas.

5. Inspecciona los límites de seguridad

OWASP agrupa riesgos web recurrentes como control de acceso roto, mala configuración, fallos en la cadena de suministro e inyección. Convierte esas categorías en preguntas concretas. ¿Puede una persona leer inscripciones ajenas? ¿Hay un secreto dentro del paquete del navegador? ¿Confía el servidor en un rol enviado por el formulario? ¿Están controlados los paquetes externos y las variables de entorno?

Pide a la IA que señale primero pruebas y ubicaciones antes de cambiar nada. Autenticación, pagos, información de salud u otros datos sensibles merecen una revisión con experiencia. El código generado no es inseguro por definición, pero su aspecto convincente puede ocultar supuestos sin comprobar.

6. Mide el rendimiento en dispositivos relevantes

web.dev presenta LCP, INP y CLS como Core Web Vitals estables para carga, respuesta y estabilidad visual. Son señales útiles, no un botón universal de aprobado. Mide la página real con imágenes, fuentes, scripts y servicios externos de producción.

Prueba al menos un teléfono representativo, una conexión limitada y un navegador de escritorio usado por tu público. Observa la imagen principal, scripts que bloquean, controles lentos y saltos durante la carga. Define un presupuesto pequeño, como tamaños máximos de imágenes y ninguna dependencia externa bloqueante sin justificación.

7. Prepara aprobación, observación y reversión

Antes de publicar responde tres preguntas: ¿quién aprueba?, ¿qué señales mostrarán un fallo?, ¿cómo se recupera la versión anterior? Una vista previa controlada, como la del artículo sobre ChatGPT Sites, sirve para la última revisión cuando se eligen conscientemente su público y los datos del formulario.

Publica una versión concreta y probada, no un ambiguo «estado actual». Después revisa la URL pública, el recorrido principal, los errores de servidor y los eventos reales de envío. La vuelta atrás solo es fiable cuando se conocen la versión de destino, la persona responsable y el procedimiento.

Lista compacta para publicar

• Objetivo, exclusiones y versión probada están registrados.
• Caso correcto, estado vacío, entrada no válida y fallo del servidor se probaron en navegador.
• Cliente y servidor validan; permisos y recorrido de datos son comprensibles.
• El recorrido funciona con teclado, ampliación y un teléfono relevante.
• Se revisaron secretos, variables de entorno, dependencias y puntos públicos.
• Se midió el rendimiento con recursos reales y se corrigieron regresiones críticas.
• Aprobación, observación y vuelta atrás tienen una persona responsable.

Estos controles no buscan eliminar la velocidad del trabajo asistido por IA. Protegen su ventaja real: pasar rápido de una idea a un producto útil cuyo comportamiento puedes explicar y asumir. Cuando falte una prueba, convierte esa ausencia en la siguiente tarea acotada. La iteración seguirá siendo rápida sin convertir la publicación en una apuesta.