Avada es el tema más vendido de la historia de WordPress. También es uno de los más difíciles de abandonar. Si has llegado hasta aquí es porque tienes una web con Avada que se ha vuelto lenta, cara de mantener o simplemente imposible de editar sin pelearte con Fusion Builder, y estás valorando pasarte a Astra.
En Auditour hemos completado tres migraciones reales de Avada a Astra con todo el contenido y el posicionamiento intactos. Este artículo cuenta cómo se hace, qué se rompe por el camino y qué herramientas hemos desarrollado para que el proceso sea viable.
Por qué migrar de Avada a Astra
Avada no es un mal tema. El problema es lo que arrastra: un maquetador propio, cientos de shortcodes propietarios y una capa de opciones que sustituye a las de WordPress. La factura se paga en tres frentes.
- Rendimiento. Avada carga su framework completo en cada página. Astra pesa menos de 50 KB y no depende de librerías externas.
- Dependencia. Fusion Builder es parte del tema. Si algún día dejas Avada, todo el contenido maquetado deja de funcionar. Además el ecosistema de opciones de Avada es muy complejo y muchas veces pasas más tiempos buscando una opción que realizando la modificación.
- Mantenimiento. Cada actualización mayor de Avada obliga a revisar la web entera.
Astra, en cambio, es un tema ligero que no secuestra el contenido. Lo que escribes queda en HTML estándar, editable con el editor clásico o con Gutenberg, sin candados.
La trampa que nadie te cuenta: Fusion Builder muere con el tema
Esta es la diferencia entre migrar desde Avada y migrar desde cualquier otro tema, y conviene entenderla antes de tocar nada.
WPBakery, Elementor o Divi son plugins. Cambias de tema y siguen funcionando. Fusion Builder pertenece a Avada. En el momento en que desactivas el tema, todos los shortcodes de maquetación se imprimen en crudo en el navegador: el visitante ve [fusion_builder_container] en lugar de tu contenido.
No es un problema puntual de una página. Afecta a todo el contenido maquetado, que en una web con años de recorrido pueden ser varios cientos de entradas.
No se puede promover a producción con contenido sin convertir. Ese es el punto de partida.
La buena noticia: Avada guarda HTML real
Frente a Elementor o Divi, que serializan la maquetación en JSON dentro de tablas de metadatos, Avada guarda todo en post_content como shortcodes anidados con el HTML real dentro:
[fusion_builder_container][fusion_builder_row][fusion_builder_column type="1_1"]
[fusion_text]<h2>Título</h2><p>Texto real…</p>[/fusion_text]
[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]Quitar los envoltorios deja HTML limpio. Eso hace que la conversión automática sea viable, que es justamente lo que convierte un proyecto imposible en uno de tres días.
Cuánto contenido se puede automatizar
En las tres migraciones que hemos hecho, el reparto ha sido notablemente consistente:
| Clase | Criterio | Proporción | Tratamiento |
|---|---|---|---|
| Simple | Contenedores + fusion_text, columnas 1_1 |
~83 % | Conversión automática fiable |
| Media | Elementos con equivalente HTML directo | ~2 % | Automática con mapeo |
| Compleja | Columnas fraccionadas o elementos sin equivalente | ~15 % | Reconstrucción manual |
La clave para clasificar es simple: la única información de maquetación real son las columnas fraccionadas (type="1_2", 1_3, 2_3, 1_6…). Las columnas 1_1 son contenedores vacíos de significado que se eliminan sin pérdida.
El plugin que hemos desarrollado
Para la parte más delicada —convertir cientos de contenidos sin romper nada— desarrollamos AB Fusion Inventory, un plugin propio que hace cuatro cosas:
- Inventaría todos los contenidos con shortcodes
fusion_*y los clasifica en simple, media y compleja. - Previsualiza el resultado antes de escribir nada.
- Convierte en masa, con cuatro capas de seguridad.
- Revierte desde la misma pantalla si algo sale mal.
Las capas de seguridad importan más de lo que parece:
- Reclasifica en vivo, no se fía del escaneo cacheado.
- Aborta si detecta un contenido complejo, aunque llegue en la cola.
- Guarda copia del original en
postmetaantes de escribir. - Aborta si tras convertir queda cualquier
[fusion_*]residual.
En la última migración procesó 229 contenidos con cero errores, reduciendo el peso del HTML entre un 15 % en textos largos y un 60 % en páginas cortas, que era puro envoltorio.
Lo que se pierde en silencio
Esta es la parte que separa una migración profesional de un desastre descubierto tres semanas después. Nada de esto avisa.
El logo y el favicon
Avada los guarda en fusion_options, no en la identidad del sitio de WordPress. Al cambiar de tema desaparecen sin previo aviso. Hay que localizarlos en la biblioteca de medios antes de tocar el tema.
Añadido: WordPress exige 512 × 512 px como mínimo para el icono del sitio. Es muy habitual que la web solo tenga versiones de 32, 72 o 144 px, así que toca regenerarlo.
Los elementos globales
Cada [fusion_global id="X"] inyecta contenido que vive en el CPT fusion_element. Una página de 3 KB puede estar mostrando 30 KB reales. Al desactivar Avada esas zonas se quedan en blanco.
Las imágenes
fusion_imageframe guarda la URL desnuda, no una etiqueta <img>. Un conversor que asuma lo contrario pierde la imagen y deja la dirección como texto plano en mitad del artículo. Es el fallo más frecuente y hay que comprobarlo expresamente después de convertir.
El megamenú
Si el menú usa el megamenú de Avada (clave _menu_item_fusion_megamenu), Astra no lo reproduce. La navegación hay que rehacerla.
Otras trampas que hemos documentado
| Síntoma | Causa | Solución |
|---|---|---|
| Error crítico al abrir el editor clásico | Avada Builder activo sin el tema Avada | Desactivar Avada Builder, pero solo tras convertir todo |
| Páginas en blanco con cabecera y pie correctos | Avada Core filtrando the_content |
Desactivar Avada Core |
Páginas con varios <h1> |
fusion_title size="1" + título del tema |
Degradar a <h2> los del contenido |
| Widgets que no guardan, «respuesta no válida JSON» | El servidor bloquea /wp-json/batch/v1 |
Instalar Classic Widgets |
El proceso completo, paso a paso
- Auditoría previa. Medir cuántos contenidos usan Fusion Builder y qué CPT existen fuera de
post_content. - Congelar publicaciones. Todo lo que se publique en producción tras el clonado se pierde al promover. Hay que pactarlo el primer día.
- Clonar a staging con WP Staging, subiendo el límite «Omitir archivos mayores de» de 8 MB a 1024 MB. Ese campo deja fuera vídeos y PDF sin avisar: en un proyecto real rescató 17 MB de medios.
- Limpiar el clon: desactivar caché, firewall, optimizadores de imagen y envíos a buscadores.
- Rescatar logo, favicon y elementos globales.
- Activar Astra manteniendo Avada Builder activo, para poder revertir.
- Simulacro de conversión y validación del recuento.
- Conversión masiva con copia de seguridad de cada contenido.
- Reconstrucción manual de los contenidos complejos, agrupados por patrón.
- Desactivar Avada Builder y verificar: cero shortcodes, un solo H1 por página, cero URLs de imagen sueltas.
- Aplicar el diseño de Astra: anchos, barras laterales, banner de cabecera y colores.
- Promover a producción renombrando carpetas.
El paso a producción
Usamos el método de renombrado de carpetas, válido con la versión gratuita de WP Staging. Producción y clon conviven en la misma base de datos con prefijos distintos, así que el cambio es de carpetas más un search-replace de rutas: rápido y reversible.
Cuatro olvidos que se pagan caros:
- Dejar el
noindexpuesto. El clon viene con «Disuadir a los motores de búsqueda» marcado. Es el error más caro de toda la migración. - No guardar los enlaces permanentes. WP Staging los desactiva en el clon.
- No reinstalar los plugins excluidos del clon. WP Staging deja fuera algunos y sus carpetas no viajan.
- Reemplazar
uploadsen vez de fusionarla. Hay que usarcp -rn, nunca soltar la carpeta encima.
Y un detalle que nos costó una hora de diagnóstico: si el wp-config.php tiene un salto de línea sobrante después del ?> final, rompe setcookie() y wp_redirect(). El síntoma es desconcertante: «las cookies se han bloqueado debido a un resultado inesperado» al iniciar sesión, y wp-admin devolviendo una página en blanco de un solo byte.
Otro que conviene tener presente: al hacer el search-replace, hay que hacer dos pasadas, una por cada protocolo. Los enlaces internos antiguos escritos con http:// no los captura una búsqueda de https://. En la última migración quedaron 172 contenidos con enlaces rotos por este motivo.
Cuánto se tarda
Entre dos y tres días para una web de tamaño medio —del orden de 500 contenidos, de los cuales unos 270 con Fusion Builder—, incluyendo auditoría, conversión, reconstrucción manual, diseño y paso a producción.
El matiz importante: es un proceso mayoritariamente desatendido. No son dos días de alguien delante de la pantalla. Son dos días de reloj en los que el trabajo repetitivo —inventariar, clasificar, convertir, verificar cientos de contenidos uno a uno— se ejecuta solo, y la intervención humana se concentra en las decisiones: qué se conserva, qué se descarta, cómo queda el diseño.
Cómo trabajamos: migración asistida con Claude Cowork
Todo el proceso lo ejecutamos con la herramienta de inteligencia artificial Claude Cowork, el agente de escritorio de Anthropic, operando directamente sobre el WordPress del cliente a través del navegador.
Esto no es un detalle de marketing: cambia lo que es económicamente viable. Verificar a mano que 460 entradas tienen exactamente un <h1>, o que ninguna ha perdido una imagen por el camino, es un trabajo que nadie factura porque nadie lo hace. Un agente lo hace en minutos y sobre el cien por cien del contenido, no sobre una muestra.
En la última migración, ese barrido automático detectó y corrigió:
- 3 imágenes convertidas en texto plano por
fusion_imageframe. - 6 encabezados
<h1>duplicados heredados defusion_title. - 172 contenidos con enlaces internos apuntando todavía a la carpeta del staging.
- Un shortcode propio que hacía una llamada externa sin timeout y dejaba una página en más de 10 segundos de carga.
Ninguno de esos cuatro problemas se habría detectado con una revisión visual de unas cuantas páginas.
El reparto de responsabilidades es claro: el agente ejecuta y verifica; las decisiones irreversibles las toma una persona. Crear el clon, aprobar la conversión masiva, renombrar carpetas en producción o borrar contenido son pasos con una puerta de validación humana explícita.
Recursos que ponemos a tu disposición
Publicamos los dos materiales que usamos internamente en cada migración:
- El plugin AB Fusion Inventory, que inventaría, clasifica, previsualiza, convierte y revierte el contenido de Fusion Builder.
- El checklist completo de migración en formato Markdown, con todos los pasos desde la auditoría inicial hasta la limpieza posterior al paso a producción.
¿Merece la pena?
Depende de una sola cosa: qué proporción de tu contenido es texto corrido dentro de contenedores de ancho completo.
Si la mayoría lo es, la migración es viable y en buena parte automatizable. Si casi todo son maquetaciones complejas con columnas fraccionadas y elementos visuales, el coste se acerca al de rehacer la web desde cero, y probablemente tenga más sentido plantearlo así.
La forma de saberlo es medirlo, no estimarlo. Ese es exactamente el propósito de la fase de auditoría previa: un inventario clasificado te dice en una tarde si tu web es candidata.
Archivos que te pueden ayudar en la migración:
- Checklist Migración Avada a Astra
- ab_fusion_inventory (Para usar el plugin debes renombre de .md a .php).
¿Tienes una web con Avada y estás valorando el cambio? En Auditour hacemos la auditoría previa y te decimos con datos si tu web es candidata, cuánto contenido se puede automatizar y qué habrá que rehacer a mano. Cuéntanos tu caso o deja un comentario
