Por qué no se clonó la web existente
El objetivo era modernizar el ecosistema digital de una academia online formado por WordPress, WooCommerce y Moodle. La plataforma acumulaba contenido histórico, páginas duplicadas, campañas vencidas, varios constructores visuales y productos separados para representar precios distintos.
Clonar producción habría trasladado también clientes, pedidos, sesiones, credenciales y deuda técnica. Se optó por reconstruir WordPress desde cero en un entorno completamente aislado, utilizando producción únicamente como fuente de lectura y migrando de forma selectiva el conocimiento que seguía teniendo valor.
Aislamiento como propiedad de la arquitectura
El entorno de desarrollo recibió raíces web, bases, usuarios SQL, sesiones, cachés y tareas cron propias. Los pagos, el correo general y la indexación quedaron bloqueados automáticamente mientras el sistema se identificara como staging.
También se creó un Moodle de desarrollo con código, datos, base, sesiones y cron independientes. Edwiser Bridge se configuró para que WordPress y Moodle de pruebas apuntaran exclusivamente entre sí, sin compartir tokens ni modificar el aula real.
Este diseño evita depender de recordar qué botón no debe pulsarse: los errores más graves quedan impedidos por el propio entorno.
Separar presentación, dominio y servicios
La solución se organizó en tres capas:
- Presentación: tema hijo de Impreza, plantillas, CSS, JavaScript y componentes editables con WPBakery.
- Dominio: tipos de contenido, estructura de cursos, casos de éxito, shortcodes y reglas comerciales en plugins propios.
- Servicios: WooCommerce, Moodle, correo, pagos, caché, analítica y SEO.
Migración editorial con criterio
El inventario encontró 39 páginas, 509 artículos, 12 productos, 118 variaciones, 952 medios y 15 convocatorias históricas estructuradas. La migración conservó contenido, catálogo y medios necesarios, pero excluyó clientes, pedidos, pagos, mensajes, sesiones y secretos.
Se revisaron también bloques del constructor anterior, porque parte del contenido visible no residía en el cuerpo normal de las páginas. Campañas caducadas, instrucciones de la pandemia y afirmaciones normativas no verificables salieron del índice; las URL con valor histórico se redirigieron a destinos vigentes.
Los precios, fechas y condiciones cambiantes se desacoplaron del texto siempre que fue posible. Las referencias normativas se orientaron hacia fuentes oficiales para evitar que una cifra escrita quedara obsoleta.
Diseño mantenible y accesible
El tema hijo reúne cabecera, pie, portada, plantillas de página, blog, búsqueda, error 404 y WooCommerce. Un pequeño sistema de diseño con variables CSS normaliza anchos, colores, radios, sombras, tipografía y espaciado.
La navegación se reorganizó según las intenciones reales del visitante. En móvil, los submenús tienen controles independientes con aria-expanded; en escritorio se eliminó la zona muerta que cerraba el desplegable antes de poder seleccionarlo.
Quince cuadros históricos de resultados existían únicamente como imágenes. Se transformaron en contenido estructurado con año, especialidad, estadísticas y alumnado, mostrado mediante acordeones HTML nativos. Diez testimonios en vídeo se integraron en un carrusel accesible con teclado, gesto táctil y una rejilla de respaldo sin JavaScript.
WooCommerce sin duplicar el negocio
La instalación anterior utilizaba productos distintos para público general y antiguo alumnado. Esa decisión complicaba catálogo, mantenimiento, analítica y SEO.
Se desarrolló un plugin de dominio que mantiene una ficha pública por curso y calcula la tarifa según producto, variación, rol, validación manual o compras previas completadas. El precio se recalcula en producto, carrito y pedido, queda registrado en la línea de compra y separa la caché según elegibilidad.
El primer pago de una matrícula no convierte automáticamente a la persona en antiguo alumno. Cuando existen roles específicos procedentes de la plataforma educativa, estos prevalecen sobre el simple historial de compra.
Las fichas se reconstruyeron con título completo, imagen, bloque de compra, variaciones comprensibles y descripción directa. Los importes visibles se obtienen de WooCommerce, evitando copiar precios en varias páginas. Stripe quedó preparado, pero sin claves reales ni pruebas de cobro fuera de un futuro entorno sandbox autorizado.
Un blog histórico que pueda mantenerse
Los 509 artículos conservaron su valor editorial, pero recibieron una presentación coherente con publicación destacada, buscador, filtros responsive, paginación, tiempo de lectura y contenidos relacionados.
Las metadescripciones, frases clave y enlaces internos se normalizaron. El contenido antiguo útil se conservó y el material que podía reutilizarse más adelante quedó inventariado de forma privada en lugar de borrarse sin criterio.
SEO sobre el HTML real
Yoast quedó como única fuente general de títulos, canonical, Open Graph, Twitter Cards, sitemap y Schema, evitando duplicados con otros plugins. Se trabajaron H1, metadescripciones, redirecciones, enlaces internos, textos alternativos y datos estructurados de organización educativa, web, breadcrumbs, productos y cursos.
Un rastreo de 562 URL renderizadas no detectó errores en respuestas, títulos, descripciones, H1, metadatos sociales, JSON-LD, enlaces hacia producción ni imágenes de contenido sin alternativa textual.
El SEO local quedó condicionado a disponer de dirección, horario, coordenadas y perfiles oficiales verificables. No se inventaron datos comerciales ni se presentó llms.txt como una solución garantizada para buscadores con IA.
Rendimiento, seguridad y operación
La caché de página y navegador excluye carrito, checkout, cuenta y cookies de WooCommerce. Esto corrigió un caso en el que algunas sesiones recibían un carrito vacío desde caché.
Se generaron WebP, se declararon dimensiones, se aplicó carga diferida y se redujeron dependencias remotas. En una portada cacheada el TTFB observado pasó aproximadamente de 0,39 s a 0,02 s, sin presentar esa medición aislada como una auditoría completa de Core Web Vitals.
Un plugin obligatorio independiente del tema desactiva XML-RPC y contraseñas de aplicación, rechaza autenticación Basic en REST, elimina información de versión, aplica cabeceras y centraliza los bloqueos de correo, pagos e indexación en staging.
Automatización y resolución de incidencias
Se desarrollaron 48 utilidades PHP y JavaScript para reconstruir contenido y repetir auditorías de respuestas, SEO, imágenes, referencias a producción, anchuras, desbordamientos, traducciones, navegación, blog, productos, carrito, precios e integración con Moodle.
Las pruebas cubrieron escritorio, portátil, tableta y móvil hasta 390 píxeles. Las operaciones de compra y reconocimiento de alumnado utilizaron datos temporales y transacciones reversibles, retirados al finalizar.
Durante el trabajo aparecieron varios problemas que exigieron actuar sobre su causa:
- El administrador sin estilos se debía a respuestas 403 sobre recursos combinados; se desactivó la concatenación sin rebajar ModSecurity.
- El carrito vacío procedía de una caché que no separaba sesiones; se excluyeron rutas y cookies sensibles.
- El catálogo estaba oculto por un modo «próximamente» activado al instalar; se abrió solo el catálogo, manteniendo pagos bloqueados.
- Las fichas dejaban huecos por una jerarquía estrecha; se creó una plantilla hija específica.
- Los resultados históricos no eran accesibles porque solo existían como capturas; se modelaron como datos editables.
Estado real
El entorno dispone de WordPress y Moodle aislados, contenido editable, navegación simplificada, blog histórico mantenible, catálogo responsive, reglas propias de precios, integración educativa, SEO técnico, caché, seguridad y un conjunto reproducible de auditorías.
Permanecen pendientes la aprobación visual y editorial, la revisión jurídica, las licencias necesarias, la prueba de Stripe con sandbox, el SMTP definitivo, los datos verificados de SEO local y el plan autorizado de publicación y reversión. Producción, pagos reales e indexación pública no se modificaron como parte de esta fase.
Lo que aprendí
- Una migración selectiva puede conservar valor sin heredar usuarios, secretos y deuda técnica.
- Los bloqueos de entorno son más fiables que una lista de precauciones manuales.
- La lógica comercial debe sobrevivir al tema y al constructor visual.
- Menos productos públicos pueden representar mejor un catálogo con varias tarifas.
- Convertir imágenes en datos mejora a la vez accesibilidad, edición, móvil y SEO.
- Las auditorías sobre HTML renderizado encuentran problemas que el panel de un plugin no puede detectar.