Un nuevo motor para el sitio en un día, con cada página comprobada

Reconstruimos nuestro propio sitio sobre un motor nuevo y lo pusimos en producción en un solo día de trabajo. Cada URL, cada enlace y cada etiqueta para buscadores quedó exactamente donde estaba, el correo siguió funcionando todo el tiempo, y el sitio salió de esto pudiendo hacer algo que el anterior nunca pudo: operar un embudo de ventas.

Aquí EVDevs fue su propio cliente, así que podemos mostrar el trabajo completo.

El punto de partida

evdevs.com era un sitio estático bilingüe, generado por un script de Python y subido a mano a un hosting compartido. Tenía página principal, hub de Servicios, oferta para startups, portafolio con casos de estudio, un blog con 36 artículos en cada idioma y documentos de ventas públicos.

Funcionaba, pero cada cambio había que subirlo antes de poder revisarlo, así que los cambios esperaban. Y un embudo necesita cosas que un generador estático hace mal: un formulario que califique y registre el origen, una página de gracias que registre la conversión, agenda de llamadas, la entrega al CRM y lead magnets.

La reconstrucción: comprobada, no a ojo

Movimos el sitio a Astro. El contenido pasó a Markdown y JSON con un esquema validado, así que títulos, descripciones, categorías y fechas se revisan en cada build. El sitio completo se genera en unos 1,3 segundos.

El sitio anterior siguió en línea, sin tocarlo, hasta que el nuevo alcanzó la paridad, y la paridad se midió, no se juzgó a ojo. Un script comparó cada página de las dos versiones en cuatro cosas:

• La URL, para no perder ninguna página ni ningún enlace entrante.
• El texto visible, para que nada se cayera ni cambiara en la mudanza.
• Cada enlace, para que la navegación y el enlazado interno sigan intactos.
• Las etiquetas del head (canonical, hreflang y meta), que los buscadores leen para entender cada página.

Las 111 URLs y el sitemap coincidieron. Así una migración es segura para el posicionamiento: Google ve el mismo sitio en las mismas direcciones. Usamos el mismo enfoque en los rediseños de clientes, como contamos en Rediseñar sin perder lo que posiciona.

La comparación también encontró un defecto en el sitio anterior: los títulos con dos puntos se mostraban con comillas literales. La reconstrucción lo corrigió.

El cambio: mover el sitio, no tocar el correo

El sitio nuevo se fue a Vercel, primero en una dirección privada de prueba. El DNS del dominio se maneja en Cloudflare, y el cambio fue deliberadamente acotado:

• Solo los registros del sitio, para el dominio sin prefijo y www, pasaron a Vercel; www ahora redirige al dominio sin prefijo.
• El correo, el webmail y el panel del hosting se quedaron en el proveedor de siempre. Sus nombres se convirtieron en registros directos antes del cambio, para que no siguieran al sitio por accidente.
• El sitio anterior sigue en su lugar. Volver atrás significa restaurar dos registros DNS.

Después del cambio revisamos el resultado, no el panel: cada página del sitemap, 115 para entonces, carga por HTTPS desde Vercel; www y el http simple redirigen al dominio seguro; el webmail y el panel siguen con certificados válidos; y un lead de prueba enviado desde el sitio en vivo fue aceptado y enviado.

Por qué fue posible en un día

La velocidad vino del método, no de atajos. Exportamos el contenido con un script en vez de reescribirlo, construimos los tipos de página como componentes y dejamos que una comparación automática hiciera la revisión que una persona no puede hacer en 111 páginas. Los ingenieros decidieron qué comparar, qué contaba como coincidencia y cuándo hacer el cambio; la máquina hizo la repetición. A eso nos referimos con experiencia humana, velocidad de máquina.

Si tu sitio necesita una base nueva pero no puede darse el lujo de perder sus URLs, su posicionamiento o un día de correo, así se ve el trabajo: reconstruir en paralelo, comprobar la paridad página por página y luego mover solo lo que tiene que moverse.