Cada semana aparece alguien que quiere trasladar un sitio real — uno con tráfico, backlinks, unos cuantos años de confianza acumulada en Google — a un creador con IA. No es una idea nueva ni un prototipo. Es un negocio existente con algo que perder. Eso es un trabajo distinto a empezar desde un mensaje en blanco, y la mayor parte del dolor que he visto viene de tratarlo como si fuera el mismo trabajo de todos modos.
Hay tres formas en que esto sale mal con la frecuencia suficiente como para predecir el ticket de soporte antes de terminar de leer el asunto. La forma correcta no es ingeniosa. Es simplemente a lo que se llega una vez que se dejan de cometer estos tres errores.
Error uno: volcar el contenido antiguo y esperar que la estructura se acomode sola
El instinto tiene sentido. Tienes un sitio, tiene palabras, así que pegas las palabras en el chat y le pides al creador que "lo mejore". Lo que sale suele ser un sitio que se ve nuevo y se lee viejo — los mismos párrafos de servicio interminables, los mismos tres encabezados haciendo el trabajo de quince, ahora envueltos en una plantilla más bonita. El creador hizo lo que pediste. Pediste que lo redecorara, no que lo repensara.
El desastre aparece unas seis semanas después, cuando el posicionamiento del sitio nuevo queda exactamente donde estaba el del antiguo, o ligeramente por debajo. Nada mejoró porque nada de la arquitectura de información real cambió — la misma página plana para un servicio que debería haber sido tres páginas, el mismo contenido de preguntas frecuentes ausente que lleva un año posicionando el sitio de un competidor. Una capa de pintura fresca en una casa con el número equivocado de habitaciones sigue siendo el número equivocado de habitaciones.
Tuve una clienta con una página de "Servicios" de 4.000 palabras que cubría once ofertas distintas. Quería migrarla tal cual porque "siempre ha funcionado". No había funcionado — no posicionaba para nada específico porque trataba de todo a la vez. Migrarla fielmente solo habría producido una versión más bonita de la misma página que no posicionaba.
Lo que realmente funciona aquí es tratar la migración como una auditoría antes de ser una construcción. Introduce el contenido antiguo, pero pide primero un inventario de contenido: qué páginas existen, para qué está tratando de posicionar cada una en realidad, dónde dos temas están apiñados en una sola URL y dónde un tema queda disperso en cinco. Ese inventario se convierte en el plan. El sitio antiguo es una fuente, no una plantilla.
Error dos: olvidar que las URLs son lo que Google realmente confía
Este es el costoso. Una migración de sitio que cambia la estructura de URLs sin mapear las rutas antiguas a las nuevas — incluso cuando el contenido nuevo es genuinamente mejor — desecha años de señal acumulada. Los backlinks apuntan a un 404. Google tiene que volver a rastrear y ganarse de nuevo la confianza en páginas que ya confiaba bajo otra dirección. El tráfico directo desde marcadores antiguos y firmas de correo termina en un callejón sin salida.
He visto a gente notar esto solo después del lanzamiento, cuando el panel de analítica muestra un desplome en lugar de un repunte. Para entonces la solución son redirecciones añadidas a posteriori, lo cual recupera parte de la pérdida pero no toda — la brecha entre "la URL se movió" y "alguien lo notó y lo arregló" se mide en semanas de valor perdido que no se recuperan.
| Enfoque antiguo | Qué se rompe | Qué hacer en su lugar |
|---|---|---|
| Dejar que el creador genere la estructura de URLs que mejor encaje con el diseño nuevo | Cada backlink entrante y marcador ahora apunta a un 404 | Exportar primero el mapa del sitio antiguo, mapear cada URL existente a su equivalente nuevo antes de empezar a construir |
| Redirigir solo la página de inicio y dejar que las páginas internas den 404 | Las páginas profundas cargan su propio valor de enlace individual — perderlas una a una se suma | Aplicar redirección 301 a cada URL antigua relevante, incluso las que se fusionan en una página más amplia |
| Añadir redirecciones "después, una vez que esté en línea" | Los rastreadores y los usuarios que hacen clic llegan a callejones sin salida justo en la ventana en la que el tráfico es más volátil | Las redirecciones se activan en el mismo momento en que se lanza el sitio nuevo, no después |
Nada de esto es exótico. Es una hoja de cálculo con dos columnas, hecha antes de que nadie toque el creador. Es simplemente el paso que la gente se salta porque es aburrido y la construcción en sí es la parte divertida.
Error tres: el cambio radical sin forma de volver atrás
El tercer fallo no tiene nada que ver con el contenido ni con las URLs — se trata de cómo ocurre realmente el cambio. Alguien construye el sitio nuevo, le gusta lo que ve en la vista previa, y apunta el dominio hacia él esa misma tarde. Sin período de pruebas, sin comparación lado a lado con tráfico real, sin plan para lo que pasa si algo está roto y la vista previa no lo detectó — un formulario de contacto que falla en silencio, un flujo de pago que funciona en pruebas pero se atasca con volumen real de pagos, una página que se ve bien en escritorio y se rompe en el modelo exacto de teléfono que usa la mitad de tus clientes.
El desastre aquí es del tipo más ruidoso porque es inmediato. Las bandejas de soporte se llenan. Alguien actualiza la analítica cada diez minutos viendo cómo una gráfica va en la dirección equivocada, y revertir significa volver a redirigir el DNS, lo cual a su vez tarda en propagarse, lo que significa que la mala experiencia persiste incluso después de haber decidido revertir.
La solución es poco glamorosa: bajar el TTL del DNS uno o dos días antes del cambio para que cualquier reversión se propague rápido si es necesario, ejecutar el sitio nuevo en un subdominio de vista previa o pruebas primero y realmente usarlo como lo haría un cliente, y mantener el alojamiento del sitio antiguo activo e intacto durante al menos un par de semanas después del cambio en lugar de eliminarlo apenas el nuevo esté en línea. Esa última parte cuesta unos pocos dólares de alojamiento a cambio de un seguro real. La gente se lo salta porque cancelar el plan antiguo se siente como cerrar un ciclo, y cerrar ciclos se siente como progreso.
Cómo se ve realmente la forma correcta
En conjunto, nada de esto es más trabajo que las versiones equivocadas — es la misma cantidad de trabajo en otro orden. Audita antes de reconstruir. Mapea las URLs antes de lanzar. Prueba antes de hacer el cambio, y mantén una vía de vuelta durante un par de semanas después de hacerlo. El sitio que resulta al final no solo se ve más nuevo. Conserva todo lo que el antiguo ya se había ganado, que era todo el propósito de migrar en lugar de empezar de cero.
