3Destiny: sitio corporativo en WordPress, desplegado en la nube del cliente
Tema propio sin page builder, migración con wp-cli y un corte de DNS sin tiempo de caída visible
Sitio corporativo de una agencia argentina de realidad aumentada, realidad virtual e IA. Tema de WordPress hecho a medida y publicado el 17-sep-2026 en la infraestructura AWS del cliente, con 37 de 37 comprobaciones en verde tras el corte.
Contexto
La agencia necesitaba reemplazar su sitio anterior por uno con sus cuatro verticales (farma, capacitación, e-commerce, marketing), casos de éxito con métricas, blog y formulario de contacto. Tenía que publicarse en su propio servidor de AWS y sin poner en riesgo lo que ya funcionaba: 132 direcciones del sitio viejo, cinco subdominios que no se tocaban y el correo de la empresa, que comparte la zona DNS con el sitio.
Solución
Tema propio sobre Gutenberg + ACF, sin constructores: casos de éxito como tipo de contenido propio, plantilla por vertical, blog y formulario que guarda en el panel y abre WhatsApp.
El despliegue se hizo con la secuencia que fijó el cliente: primero el sitio entero en un subdominio de prueba del mismo servidor de producción, validado con el dominio definitivo forzado en el navegador; después el equipo del cliente movió un único registro DNS.
Arquitectura
Copia de seguridad del servidor, guardada fuera de él
Subida de archivos con sumas de verificación iguales en origen y destino (230 MB)
Importación de la base con wp-cli: 2622 reemplazos de dominio
Validación en el subdominio de prueba con el dominio definitivo forzado
El equipo del cliente mueve un único registro DNS
37 comprobaciones desde afuera con el DNS real: 37/37
Piezas
- Tema WordPress propio (PHP 8.3, Gutenberg + ACF, Rank Math)
- AWS EC2 del cliente, con acceso por SSM (Session Manager)
- Route 53 (DNS) + certificado Let's Encrypt con challenge DNS, renovación automática
- wp-cli para migrar la base y reescribir el dominio
- Correo saliente por el servicio de correo de Amazon
Decisiones técnicas
Tema propio, sin page builder
Por qué: control total del HTML, que es lo que permite Accesibilidad 100 y SEO 100.
Trade-off el equipo edita dentro de los bloques y campos definidos; un cambio de diseño nuevo necesita desarrollo.
Desplegar en la nube del cliente, no en un hosting mío
Por qué: el cliente queda dueño de su servidor, su DNS y sus accesos; se entró por Session Manager, sin abrir SSH.
Trade-off cada acceso y el corte dependen de su equipo de sistemas.
Ensayo completo en un subdominio del mismo servidor
Por qué: se valida sobre la máquina real, y el sitio anterior sigue publicado hasta el minuto del corte.
Trade-off deja ajustes temporales (bloque de configuración, certificado y registro del subdominio) que hay que desarmar después.
Comprobaciones scriptadas antes y después del corte
Por qué: lo que más se rompe sin que nadie lo vea es el correo; MX, SPF, DKIM y DMARC se compararon con una línea base tomada días antes.
Trade-off tiempo de preparación antes del corte.
Correcciones de migración por script, sobre todo el contenido
Doce imágenes no cargaban por nombres de tamaños heredados del gestor anterior; el script revisa todos los artículos, no solo los afectados, y quedó en el procedimiento.
Trade-off más tiempo que arreglar a mano los tres artículos visibles.
Resultados
- Publicado el 17-sep-2026
- 37/37 comprobaciones con el DNS real tras el corte
- 132/132 direcciones del sitio anterior redirigen según el mapa
- 131/131 imágenes de artículos cargando
- 22/22 pruebas en navegador real (11 rutas, celular y escritorio), sin peticiones a terceros
- Registros de correo idénticos a la línea base
- Lighthouse: SEO 100 · Accesibilidad 100 · Buenas prácticas 100
- 155 funciones de prueba en la suite del tema
Stack
- WordPress
- PHP 8.3
- Gutenberg + ACF
- Rank Math
- JavaScript vanilla
- AWS EC2 + SSM
- Route 53
- Let's Encrypt
- wp-cli
