Respuesta breve
Antes que un problema de diseño, una migración es un problema de contabilidad. Lo que se compra es el inventario de URL y un mapa de redirecciones ya probado, y investigar una caída de tráfico es otro encargo distinto.
Nadie tiene la lista de direcciones, y esa lista es el encargo
Una migración se discute como si fuera diseño o alojamiento, y en realidad se decide en la contabilidad. Todo sitio con un par de años encima arrastra un conjunto de direcciones que nadie inventarió: las que indexan los buscadores, las que enlazan terceros, las que llevan boletines viejos y esa que sigue citando un PDF olvidado en la carpeta de descargas de alguien. El conjunto creció de página en página, sin acta ninguna, y buena parte la levantó una persona que hace tiempo que no trabaja en la empresa. Nadie lo puso por escrito porque nunca hizo falta, hasta el día en que hace falta entero.
Conviene aclarar de entrada que el inventario no es el sitemap. El sitemap solo enseña aquello que el sistema actual admite tener, y eso deja fuera bastante. El inventario se compone cruzando fuentes: el archivo sitemap, un rastreo completo del sitio en producción, doce meses de registros del servidor, las páginas que los buscadores declaran conocer, las páginas de entrada que la analítica llegó a registrar y las direcciones que reciben enlaces desde fuera. Ninguna de esas fuentes está completa por su cuenta, y cada una rescata direcciones que a las demás se les habían escapado.
Un inventario que sirva no es un listado, es una tabla. Cada dirección quiere su código de respuesta actual, si está indexada o no, las sesiones e impresiones del último año, el número de dominios externos que la enlazan, la canónica que declara y la plantilla que la generó. Con esas columnas delante, un responsable resuelve en una tarde lo que sin ellas se convierte en un mes de reuniones. Sin ellas, la lista se queda en lista y las decisiones no llegan a tomarse nunca.
Puesto así, la factura se entiende mejor: lo que se paga es el inventario y la plantilla nueva viaja de acompañante. Un diseño dura lo que dura, el framework se reescribe, el proveedor se cambia, y ninguno de los tres se lleva el inventario consigo, porque el inventario no describe cómo está ordenado por dentro el panel de administración sino qué se ve del sitio desde la calle. Ese mismo archivo sirve para la mudanza de este año y para las que vengan después, y quien herede el proyecto abrirá un documento en vez de ponerse a excavar.
Dos columnas, un código de respuesta y miles de decisiones
Por presentación, el mapa de redirecciones es el documento más soso del proyecto: a la izquierda la dirección antigua, a la derecha la nueva y en una tercera columna el código de respuesta. Su dificultad no está en el formato sino en el fondo, porque cada fila encierra un criterio que alguien tiene que fijar. Un sitio de unos miles de direcciones acumula unos miles de criterios menudos que hasta ese momento nadie había tenido que formular en voz alta.
Las filas se reparten en tres familias. Están las de uno a uno, donde la página existe a ambos lados y mantiene su sentido; están las fusiones, cuando varias páginas antiguas se refunden en una porque aquella separación ya no describe el negocio; y están los cierres, en los que no hay destino honesto y fingir que lo hay solo lleva al visitante a una página que no contesta su pregunta. La primera familia se resuelve con reglas de patrón siempre que la estructura lo permita, y a mano quedan únicamente las excepciones. Esa disciplina es la que impide que el mapa crezca hasta volverse inmanejable.
El código de respuesta de la tercera columna decide más de lo que aparenta. Permanente significa: traslada la dirección y olvida la antigua. Temporal significa justo lo contrario, conserva la antigua y vuelve a pasar por aquí más adelante. La respuesta de contenido eliminado afirma que la página ha terminado su vida, mientras que un no encontrado no afirma nada en absoluto: es silencio, y detrás del silencio caben por igual un cierre deliberado y un servidor con hipo. Qué código va en cada fila lo decide el mapa; quien lo implemente después se limita a ejecutarlo.
La virtud operativa del mapa es que admite prueba antes de que el sitio nuevo esté publicado. Se lanza cada dirección del inventario contra la capa de redirecciones del entorno de pruebas y se anota la respuesta, buscando cuatro vicios concretos: bucles, cadenas en las que una redirección aterriza sobre otra, saltos que acaban en una página de error y filas que despachan discretamente todo el tráfico a la portada. Mientras esa ejecución completa no se haya hecho, lo que hay encima de la mesa es un borrador y no un mapa.
El gráfico no distingue lo que tiraste de lo que se rompió
Hay tráfico que se pierde por decisión propia y no por avería. Retirar toda una capa de páginas de etiquetas vacías, dar de baja una línea de producto que ya no se vende o quitar un idioma que se dejó de atender resta sesiones, y las tres cosas se hicieron a conciencia. El gráfico, sin embargo, no está al corriente: quince días después del lanzamiento, el recorte deliberado y la redirección rota trazan la misma pendiente en el mismo informe.
La única defensa fiable consiste en dejar escrita de antemano la parte planificada, y eso cabe en una columna más del inventario: no se migra, con el motivo anotado al lado. Rellenada antes de publicar, la primera semana posterior se resuelve con aritmética en lugar de con opiniones. Se sabe cuánto se pensaba perder, se mide cuánto se ha perdido de verdad, y la diferencia entre las dos cifras deja de ser una discusión sobre culpas para convertirse en una lista de errores a corregir.
Sin esa columna, el guion posterior se repite proyecto tras proyecto. Uno afirma que el tráfico ha bajado, otro replica que la mayor parte estaba prevista y, como ninguno puede demostrar su versión, el equipo invierte dos semanas en volver a deducir decisiones que ya había tomado una vez. La avería de verdad aprovecha esas dos semanas para seguir escondida dentro del ruido, y cuando por fin asoma ya no se arregla en una tarde.
El efecto sobre quien lee el informe pesa lo mismo. Avisar antes de tocar nada de que se va a retirar a propósito una franja concreta de tráfico de bajo valor es un plan; contar exactamente lo mismo tres semanas después de que las cifras se muevan es una excusa, y suena a excusa aunque sea verdad de principio a fin. Rellenar la columna cuesta una hora de trabajo y compra justo esa diferencia de credibilidad.
WordPress a estático: la factura la marcan las direcciones, no la plantilla
En el catálogo esta línea figura como «Pasar de WordPress a estático sin perder SEO», dentro de Migraciones, con dificultad Con experiencia, a $800 – $3 000 o 35 000 – 90 000 ₽ y una horquilla de 20-40 horas. Lo prometido está escrito sin ambigüedad: el mismo sitio cargando en medio segundo, sin interrumpirse por las actualizaciones de complementos, sin exigir alojamiento pago y con las posiciones conservadas porque todas las URL y redirecciones se transfieren una a una.
Esa última cláusula es la que se come las horas, y conviene detenerse en ella. WordPress fabrica familias enteras de direcciones que el editor jamás creó a propósito: archivos de autor, archivos por fecha, páginas de adjuntos, puntos finales de feeds, paginación de comentarios y el producto completo de categorías por etiquetas. Cada familia exige su regla en el mapa, y redactar esas reglas es trabajo de inventario y no de maquetación; de hecho la capa visual suele despacharse antes que ninguna otra parte del encargo.
Cualquiera puede hacer a mano la aritmética que sugiere la horquilla publicada: veinte a cuarenta horas puestas frente a $800 – $3 000 dan un rango amplio, y es amplio porque en cada extremo hay un sitio distinto y no un descuento distinto. Sirva como ejemplo de razonamiento sobre las cifras que el propio catálogo publica; no es una medición sacada de ningún proyecto real ni debe leerse como una tarifa por hora.
El otro sumidero de horas es el comportamiento del sitio, no sus textos. Un WordPress con años encima arrastra un puñado de funciones sostenidas por complementos: formularios, buscador interno, comentarios, descargas cerradas, área de usuarios. Cada una obliga a una decisión explícita, reproducirla, sustituirla por un servicio externo o retirarla, y todas esas decisiones caen dentro del mismo inventario que las direcciones, porque varias de esas funciones tienen direcciones propias que también hay que resolver.
Tilda y Wix: primero exportar, después programar
La línea equivalente se llama «Dejar Tilda/Wix por tu propio código», comparte categoría Migraciones y dificultad Con experiencia, y se cotiza a $500 – $1 500 o 25 000 – 70 000 ₽ con una horquilla de 15-30 horas. Su descripción no se anda con rodeos: el mismo sitio, sin la suscripción mensual del maquetador, con plena propiedad del código y sin restricciones de funciones, y con el ahorro de esa suscripción pagando el trabajo en 6-12 meses.
La diferencia con el caso de WordPress aparece ya en el punto de partida: un maquetador no te entrega una lista, te entrega un sitio. El enrutamiento es suyo, hay páginas que solo existen en estados visibles dentro del editor y la exportación descargable casi nunca coincide con el conjunto de páginas al que llega el público. El inventario, por tanto, se rastrea desde fuera en vez de leerse desde dentro, y después se contrasta con la analítica y con la cobertura de búsqueda; hasta que ese cotejo no está hecho no hay lista con la que trabajar.
La cláusula de propiedad pesa más sobre el mapa de redirecciones que sobre el código en sí. Mientras el sitio vive en un maquetador, el esquema de URL es una característica del producto de otro; en cuanto la mudanza termina pasa a ser tuyo, y entonces sí puedes decidir que los productos cuelguen de un prefijo y los artículos de otro, y además hacerlo cumplir. Reordenar así es exactamente el trabajo de fusión y cierre descrito más arriba, y sale mucho más barato hacerlo una sola vez durante la mudanza que abrir una segunda migración un año después.
Puestas las dos horquillas una junto a otra dicen algo que conviene leer bien: salir de un maquetador se cotiza en 15-30 horas, la mudanza de WordPress en 20-40, y ambas llevan la misma dificultad Con experiencia. Esa distancia no dictamina qué plataforma resulta más agradable de manejar, sino cuántas familias de direcciones generadas deja cada una para que el mapa las absorba.
Ese mes de soporte no es un extra: viene dentro de la línea
Para este riesgo el catálogo reserva una línea propia: «Migración del sitio sin pérdida de tráfico», categoría Migración, dificultad Avanzado, a $700 – $3 000 o 30 000 – 100 000 ₽. Su duración está redactada de forma poco corriente, 2 a 5 días de preparación más un mes de soporte, y es esa segunda mitad la que casi todos los compradores intentan tachar del presupuesto. También es la que determina si la primera mitad ha servido para algo.
Lo que se compra en los días de preparación es el inventario y el mapa; lo que se compra en el mes es el choque de ese mapa contra internet. Los rastreadores no siguen tu calendario, siguen el suyo. Aparecen direcciones que no figuraban en ninguna fuente porque quien las enlaza es un único sitio externo y nadie más. Y reglas que en el entorno de pruebas funcionaban sin un rasguño cambian de comportamiento en cuanto la misma petición atraviesa una CDN, una capa de caché y una redirección configurada en el alojamiento.
«Cualquier pérdida se ve el primer día y no al cabo de un trimestre», dice la descripción, junto con que todas las URL coinciden y que las redirecciones son válidas y están verificadas. Ese primer día hay que leerlo como requisito de organización y no como promesa comercial: obliga a que alguien mire de verdad las respuestas de error en los registros, repase las cadenas de redirección y compare el tráfico plantilla por plantilla, en lugar de quedarse contemplando una única cifra global.
La comparación por plantillas es justo lo que separa un mes útil de un mes ceremonial. Una cifra global plana esconde sin esfuerzo un tipo de página que se hunde mientras otro sube, porque el promedio se traga los dos movimientos y devuelve calma. Como el inventario ya anota qué plantilla generó cada dirección, el documento del que salió el mapa sirve además de panel de seguimiento sin coste añadido, que es el mejor argumento para levantarlo bien a la primera.
Investigar una caída es recorrer el mismo expediente en sentido inverso
La cuarta línea del catálogo es «Investigación de caída de tráfico y plan de recuperación», categoría Recuperación y dificultad Avanzado, con el diagnóstico presupuestado en $500 – $2 500; el catálogo en ruso lo formula como un diagnóstico de 25 000–70 000 ₽ y deja los trabajos de recuperación como proyecto aparte. El plazo va partido igual que el precio: 1–3 días para diagnosticar, y el trabajo derivado del plan por su cuenta.
Conviene decirlo en voz alta, porque el encargo equivocado se firma a menudo. Una migración arranca con la lista de direcciones ya en la mano y con una fecha que has elegido tú. Una investigación arranca con una curva y con nada más: qué direcciones se movieron y desde qué día son justo las dos cosas que tiene que averiguar. Lo que en una migración viene dado, en una investigación hay que producirlo.
Los candidatos que nombra la descripción son cuatro: una actualización de algoritmo, un error técnico, la pérdida de páginas o los clics que se marchan a las respuestas de IA. La pregunta que los separa es siempre la misma, qué franja del sitio se movió. Un fallo técnico tiene el borde nítido y no suele salirse de una plantilla. La pérdida de páginas se ve como direcciones que abandonan la cobertura. Una actualización arrastra clases enteras de consultas sin mirar plantillas. Y los clics que se van a las respuestas de IA dejan las impresiones donde estaban y cambian su proporción con los clics. Todo eso es un método para leer las pruebas que ya tienes; ninguna de esas cuatro frases dice con qué frecuencia aparece cada causa.
La horquilla de 1–3 días define alcance tanto como calendario. Un diagnóstico está obligado a terminar, y a terminar con una causa con nombre, las pruebas que la sostienen y un plan ordenado por prioridades. Cuando una investigación se alarga semanas sin nombrar nada, ha dejado de ser diagnóstico y se ha vuelto una iguala mensual, que es otro producto, con otro precio y otras expectativas.
El diagnóstico se presupuesta solo porque la reparación aún no tiene alcance
Parece un intento de vender dos veces y es exactamente lo contrario. El catálogo pone precio al diagnóstico por separado, $500 – $2 500, y deja por escrito que los trabajos de recuperación van como proyecto aparte; la razón es simple, sin causa nombrada la reparación carece de alcance. Recuperar páginas borradas, reescribir contenidos que una actualización devaluó o corregir una regla de servidor que empezó a devolver el código equivocado son tres encargos sin nada en común salvo el gráfico que te llevó hasta ellos.
Si las líneas de migración se presupuestan antes de empezar es porque su alcance cabe en una lista: se cuentan las direcciones, se miran las plantillas y el mapa se estima antes de firmar. El día cero de una caída no ofrece lista ninguna. Por eso, quien cierra un precio de recuperación antes del diagnóstico o infla la cifra para cubrirse ante el peor escenario o directamente adivina, y las dos salidas acaban costándole al comprador más que pagar por delante de uno a tres días de diagnóstico.
Cuatro respuestas debería dejar un diagnóstico que valga su precio: qué cambió, cuándo, a qué parte del sitio afectó y qué hacer al respecto, con la acción más barata y reversible colocada la primera. Un primer punto caro e irreversible delata que el diagnóstico todavía no ha terminado. Ordenar por riesgo en lugar de por ambición es lo que mantiene el plan dentro de lo que un equipo pequeño puede ejecutar en una semana normal, y lo caro siempre puede esperar al paso siguiente.
Queda un desenlace que nadie pide pero que existe: la caída es real, está explicada y revertirla no compensa económicamente. Es un resultado legítimo, y alcanzarlo en tres días cuesta muchísimo menos que alcanzarlo tras tres meses de trabajo sin rumbo. Es también, dicho sea de paso, el escenario en el que separar la pérdida planificada de la accidental ahorra más dinero.
Mantener el inventario sale barato; rehacerlo, no
Investigar una caída posterior a una mudanza consiste, en buena medida, en rehacer el inventario que tendría que haberse levantado antes de mover nada. La pregunta pasa a ser qué había antes, que es estrictamente más difícil que qué hay ahora, y hay que contestarla con fuentes parciales cuando el sistema original ya está apagado y su alojamiento cancelado por innecesario.
Ninguna fuente de reconstrucción llega entera. Las copias archivadas del sitio vienen incompletas y sin fecha página a página. Algún sitemap antiguo asoma de vez en cuando en el control de versiones, siempre que alguien se molestara en subirlo. La analítica conserva páginas de entrada hasta donde le alcanza la ventana de exportación, y los informes de cobertura de búsqueda caducan por su cuenta. Como los fragmentos no encajan entre sí hay que conciliarlos, y conciliarlos es precisamente la tarea que un inventario hecho a tiempo habría borrado del presupuesto.
La asimetría sostiene el argumento entero. Con el sitio antiguo todavía en pie, levantar el inventario es una tarea que termina: las fuentes responden y el resultado se contrasta contra un sistema en marcha. Apagado el sitio, la misma tarea deja de tener final, porque nunca hay forma de saber si la última dirección encontrada era de verdad la última. Y las que se quedan fuera son exactamente las que nadie vigila, que es también la razón de que una investigación se estire por encima de los tres días previstos.
El consejo práctico es de lo más aburrido. Guarda el inventario y las reglas de redirección en el mismo repositorio que el sitio, en un formato que una persona pueda leer, y actualízalos cada vez que cambien las direcciones. Es un archivo, no una plataforma, y mantenerlo no cuesta nada: sobrevive a los rediseños y a los cambios de proveedor, y es lo que separa una investigación de dos días de una excavación de tres semanas contra un sistema que ya no existe.
Qué línea del catálogo te toca según de dónde vengas
Empecemos por el caso más frecuente. Si el CMS y las direcciones ya te pertenecen y lo que duele es la velocidad, la fragilidad de los complementos o la factura del alojamiento, tu línea es la mudanza de WordPress: $800 – $3 000 o 35 000 – 90 000 ₽, 20-40 horas, dificultad Con experiencia dentro de Migraciones. Nadie va a inventar direcciones nuevas; el encargo consiste en trasladar una a una las que ya existen y verificar que la compilación nueva las sirve todas. El diseño nuevo va detrás.
Si el enrutamiento lo gobierna un maquetador que además te pasa factura todos los meses, la línea es salir de Tilda o Wix: $500 – $1 500 o 25 000 – 70 000 ₽, 15-30 horas, con la misma dificultad y la misma categoría. El catálogo describe el resultado como plena propiedad del código sin restricciones de funciones, y sitúa el ahorro de la suscripción como lo que paga el trabajo en 6-12 meses.
Si lo arriesgado es el cambio en sí, un dominio nuevo, un diseño nuevo o un CMS distinto en un sitio al que el tráfico de búsqueda le importa, la línea es «Migración del sitio sin pérdida de tráfico»: $700 – $3 000 o 30 000 – 100 000 ₽, dificultad Avanzado, 2 a 5 días de preparación más un mes de soporte. Lo que se compra ahí no es obra: es el inventario, el mapa verificado y alguien vigilando el resultado mientras se asienta.
Y cuando el tráfico ya se ha marchado, ninguna de las tres líneas anteriores te sirve todavía: toca la de recuperación, $500 – $2 500 por un diagnóstico de 1–3 días, con la reparación presupuestada después como proyecto propio. Encargar una migración para curar una caída solo reconstruye el sitio alrededor de una avería que nadie ha identificado. Y encargar un diagnóstico para una mudanza que aún no ha ocurrido devuelve un informe sobre un sitio que pronto dejará de tener esa forma.
Preguntas frecuentes
¿Qué recibo exactamente antes de que el sitio nuevo se publique?
Dos documentos, más la prueba que los valida. El primero es el inventario: todas las direcciones que expone el sitio antiguo, con su tráfico, sus enlaces externos y su plantilla anotados fila a fila. El segundo es el mapa de redirecciones, donde cada una de esas direcciones recibe un destino y un código de respuesta. La línea «Migración del sitio sin pérdida de tráfico» reserva para ello 2 a 5 días de preparación más un mes de soporte a $700 – $3 000, y son esos días de preparación los que se dedican a redactar ambos documentos y lanzarlos contra el entorno de pruebas.
¿Cuánto cuesta pasar de WordPress a un sitio estático y cuánto tarda?
El catálogo lo sitúa en $800 – $3 000, o 35 000 – 90 000 ₽, con una horquilla de 20-40 horas, dentro de Migraciones y con dificultad Con experiencia. Lo que la descripción se compromete a entregar es el mismo sitio cargando en medio segundo, ya sin roturas por actualizaciones de complementos ni necesidad de alojamiento pago, y con las posiciones intactas porque las URL y las redirecciones se transfieren una a una y no de forma aproximada.
¿Merece la pena salir de Tilda o Wix si el sitio ya funciona?
La respuesta económica está en el catálogo: dejar Tilda o Wix para tu propio código cuesta $500 – $1 500, o 25 000 – 70 000 ₽, con una horquilla de 15-30 horas, y la descripción sostiene que el ahorro de la suscripción paga el trabajo en 6-12 meses. La otra mitad de la respuesta no se mide en dinero, sino en propiedad del esquema de URL, que es lo único que permite reordenar las direcciones una vez en lugar de seguir viviendo dentro del enrutamiento de otro.
Mi tráfico cayó el mes pasado. ¿Eso se resuelve con una migración?
Primero se diagnostica; migrar viene después, si es que viene. El catálogo cotiza la línea de recuperación en $500 – $2 500 por un diagnóstico de 1–3 días y saca los trabajos de restauración a un proyecto aparte. Ese diagnóstico empieza descartando entre las cuatro causas que enumera la descripción: una actualización de algoritmo, un error técnico, la pérdida de páginas o los clics que se van a las respuestas de IA. Reconstruir el sitio sin haber nombrado antes la causa se limita a mudar la avería a la versión nueva.