
Empieza por lo que las personas ya pueden encontrar
El inventario debe mostrar qué páginas existen, para qué sirven y cómo llegan las personas hasta ellas. Reúne las direcciones del sitio actual e identifica los contenidos, imágenes y documentos asociados. Una migración resulta más fácil de evaluar cuando existe una lista concreta de lo que debe seguir funcionando.
Cuando abordé el paso de mi sitio en WordPress a una aplicación, primero pedí un análisis del sitio existente y un inventario de las páginas. Conservar las direcciones formaba parte del encargo. Eso obliga a mirar lo que ya está publicado antes de decidir cómo organizar el nuevo proyecto.
La página de inicio rara vez representa todo el trabajo. Hay artículos antiguos que siguen siendo útiles, páginas de servicios, contactos, documentos descargables y páginas legales que solo aparecen en el pie. Si el inventario depende únicamente del menú principal, parte de ese patrimonio puede desaparecer sin que nadie haya tomado esa decisión.
El sitemap ayuda a descubrir direcciones, pero no lo trataría como prueba de que la lista está completa. Añadiría una exportación de contenidos y, cuando existan, registros de visitas y enlaces recibidos. También guardaría una copia consultable del sitio antiguo para aclarar diferencias durante la revisión.
Este inventario conecta con el diagnóstico antes de proponer un plan de marketing: primero entender qué existe y qué función desempeña. Una página con pocas visitas puede contener información necesaria para alguien que está a punto de contactar con la empresa. El volumen, por sí solo, no decide su destino.
Para preparar el siguiente paso, consulta Desarrollar aplicaciones con IA.
Asigna un destino explícito a cada dirección
Cada URL antigua debe tener una decisión registrada: mantener la misma página, dirigir a un contenido equivalente o retirarla por un motivo definido. Evita dejar esta elección implícita en el trabajo de la IA. La correspondencia entre origen y destino es un documento de decisión que después orienta la implementación y las pruebas.
Piensa en un ejemplo hipotético: una empresa tiene una página sobre formación presencial y decide reorganizar la navegación. Si la oferta sigue siendo la misma, cambiar el menú no obliga a cambiar la dirección. Puede actualizar la presentación y conservar la ruta que clientes y colaboradores ya conocen.
Si dos páginas se sustituyen realmente por otra más completa, la correspondencia debe apuntar a esa sustituta. Una redirección permanente puede servir para ese cambio. Enviar indiscriminadamente todas las direcciones antiguas a la página de inicio deja al visitante sin el contenido que buscaba y oculta decisiones que deberían revisarse individualmente.
También hay contenidos que dejan de tener sentido. Retirarlos exige una decisión editorial, en lugar de intentar crear equivalencias artificiales. En la tabla registraría el motivo y quién lo validó. Así, la persona que prueba puede distinguir una retirada intencionada de una página olvidada en la transferencia.
Incluye las direcciones que ya circulan fuera del sitio. Imagina un QR impreso en un folleto o un enlace enviado en una propuesta comercial. El equipo puede corregir el menú en segundos, pero no puede recuperar todos los materiales distribuidos. Conservar ese acceso tiene valor práctico aunque no aparezca en una conversación sobre diseño.
Entrega a la IA requisitos que se puedan comprobar
El encargo de implementación debe reunir el inventario, las decisiones sobre URL y criterios observables para cada tipo de página. Explica qué debe aparecer, quién puede editar y qué ocurre en los formularios. Pide a la IA que identifique dudas antes de convertir suposiciones en comportamientos de la nueva aplicación.
Yo separaría contenido, presentación y operación. El contenido incluye títulos, texto, imágenes e idioma; la presentación define cómo mostrarlos; la operación abarca edición, solicitudes recibidas y permisos. Un aspecto parecido al original no demuestra que estas tres partes se hayan transferido correctamente al nuevo sistema.
Un requisito útil sería: “Este artículo debe abrirse en la dirección indicada, mostrar el texto completo y mantener los enlaces internos útiles.” Otro sería: “Este formulario necesita validar los campos y mostrar una confirmación coherente con lo que se ha registrado realmente.” Son condiciones que alguien puede observar sin adivinar intenciones.
Antes de construir, aplica el mismo cuidado que propongo al planificar una aplicación con Claude Code. La IA necesita conocer los límites del proyecto, los datos necesarios y lo que depende de una decisión tuya. Pedir una copia visual de un sitio deja demasiadas preguntas sobre su funcionamiento sin responder.
También definiría cómo actualizará los contenidos el equipo después de la migración. Si cambiar una descripción pasa a exigir modificar código, puede aparecer un coste de mantenimiento imprevisto. Una aplicación a medida solo resuelve el proceso cuando la persona responsable puede utilizarla en las condiciones reales del negocio.

Prueba los recorridos antes de cambiar el sitio
La revisión debe empezar por las direcciones antiguas y recorrer el nuevo sitio como una persona que busca información o quiere actuar. Comprueba páginas completas, imágenes, descargas y formularios. Combina pruebas automáticas de la lista de URL con una revisión de los recorridos importantes, porque una respuesta técnicamente válida puede mostrar contenido equivocado.
Por ejemplo, una página puede abrirse sin errores y haber perdido la mitad del artículo. Una imagen puede existir, pero pertenecer a otro servicio. Un botón puede llevar a la página correcta en el idioma equivocado. Estos casos exigen comparar con los requisitos y el material de origen, más allá de una lista de respuestas positivas.
En los formularios, utiliza un entorno y datos de prueba que no envíen mensajes reales a clientes. Comprueba los campos obligatorios, los errores comprensibles y el resultado de un envío válido. Si existe un área privada, prueba también lo que una persona sin acceso no puede ver ni modificar.
Revisa los títulos de las páginas, las direcciones canónicas, los enlaces entre idiomas y el sitemap del nuevo sistema. Confirma además que las protecciones empleadas durante el desarrollo no impiden descubrir las páginas públicas después del cambio. La configuración de un entorno de prueba no debe pasar inadvertida al sitio final.
Repartir esta revisión ayuda a encontrar fallos distintos. Quien conoce el contenido puede identificar una omisión; quien gestiona las solicitudes puede detectar información que falta. La IA puede preparar comprobaciones y localizar diferencias, pero aceptar un cambio de contenido sigue requiriendo un criterio editorial definido que se pueda aplicar.
Haz el cambio con una forma de volver atrás y supervisar
La puesta en marcha debe tener un responsable, una copia recuperable del estado anterior y comprobaciones preparadas para el momento posterior. Define qué justificaría corregir rápidamente o volver atrás. Después supervisa errores y recorridos reales, sin interpretar una oscilación inicial de visitas como prueba automática de éxito o fracaso.
Antes del cambio, decide cómo tratar los contenidos o solicitudes que puedan llegar mientras tanto. En un ejemplo hipotético, exportar un sitio por la mañana y migrarlo por la noche puede dejar cambios pendientes. El equipo necesita saber cuándo se interrumpe la edición, cómo se transfiere la última actualización y dónde llegan las nuevas solicitudes.
La posibilidad de volver atrás también debe contemplar los datos. Restaurar la versión antigua del sitio no debería borrar los envíos recibidos en la aplicación nueva. Por eso, el plan debe indicar dónde se guardan esos registros y cómo se conciliarán si se revierte el cambio. Una copia visual no resuelve esa dependencia.
Después del cambio, supervisa páginas ausentes, destinos incorrectos y problemas comunicados por los usuarios. Compara los recorridos importantes con la lista inicial y registra lo que se ha corregido. Las pruebas previas reducen sorpresas, pero no convierten el lanzamiento en el último momento para revisar el trabajo.
Aquí es donde usar IA en el negocio más allá del chatbot tiene una aplicación concreta: ayudar a analizar, construir y verificar un cambio con tus criterios. La migración está terminada cuando los contenidos y las tareas útiles funcionan en el nuevo sistema. El aspecto visual, por sí solo, no permite aceptar el trabajo.