Saltar al contingutCECO LabDigital lab / web engineering
Mi Casa Autosuficiente

Guia / Arquitectura web

Quan convé migrar de WordPress a Astro

Migrar de WordPress a Astro no és una millora automàtica. Té sentit quan el problema real és l'arquitectura, el manteniment o el pes d'una web principalment editorial, i quan les funcions dinàmiques es poden conservar, substituir o separar sense empitjorar el flux de treball. La decisió correcta comença per entendre què fa avui la web, no per triar framework.

Autoria editorial · CECO LabActualitzat · 02/10/2026WordPress · Astro · SEO

01 / Decisió

Quan Astro pot encaixar millor

01

La web és sobretot editorial

Blogs, guies, landings i directoris amb canvis de contingut controlats poden aprofitar una sortida estàtica o híbrida sense mantenir un CMS PHP complet per servir cada visita.

02

El frontend depèn massa del tema i plugins

Si cada ajust de disseny exigeix lluitar amb capes de tema, constructor i plugins, una arquitectura basada en components pot reduir dependències i fer més previsible el manteniment.

03

Necessites control del codi i del desplegament

Astro encaixa quan el projecte ja treballa amb Git, build, QA i desplegaments verificables, i l'equip accepta que una part més gran del sistema viu al repositori.

04

Les funcions dinàmiques són acotades

Formularis, cerca, calculadores o integracions concretes es poden resoldre com a serveis separats o interaccions locals. Si tota l'operació depèn del panell WordPress, cal valorar-ho amb molta més cura.

02 / Inventari

Abans de tocar el disseny: inventaria el WordPress real

Una migració segura comença amb una llista de tot el que existeix i de tot el que rep trànsit. No n'hi ha prou amb copiar el menú. Cal inventariar URLs públiques, continguts, mitjans, formularis, taxonomies, redireccions, canonicals, dades estructurades, usuaris i qualsevol funció que depengui de plugins.

  • Separa pàgines editorials, fitxes comercials, categories, arxius, adjunts i endpoints; no assumeixis que tot necessita una pàgina equivalent.
  • Marca quines URLs tenen enllaços externs, impressions o trànsit abans de decidir si es mantenen, es redirigeixen o han de retornar 404.
  • Identifica funcions dinàmiques reals: comptes, comentaris, formularis, pagaments, cerca, membres, automatitzacions i integracions.
  • Conserva un mapa origen → destí i prova'l sobre el build candidat abans de canviar el domini.
  • No copiïs automàticament scripts, schemas comercials, shortcodes o dades de plugins si la funció que representaven ja no existeix.

03 / URLs i SEO

El SEO es protegeix amb URLs i equivalència, no amb el framework

Canviar WordPress per Astro no obliga a canviar les URLs. Si una URL conserva el mateix contingut i intenció, mantenir-la evita una migració SEO innecessària. Quan una URL sí que canvia, Google recomana preparar un mapa i utilitzar redireccions permanents de servidor cap al destí final, evitant cadenes. Canonical, sitemap, enllaçat intern i respostes 404 també s'han de validar sobre el lloc nou.

Què ha d'incloure el mapa de migració

  • URL antiga, URL nova o decisió explícita de retirar-la.
  • Codi HTTP esperat: 200, 301/308 o 404 real.
  • Title, description, canonical i indexació prevista.
  • Imatges i altres assets que formen part del contingut indexable.
  • Enllaços interns que encara apunten a una ruta antiga.

04 / Cas real

Cas real: Mi Casa Autosuficiente

En Mi Casa Autosuficiente la migració es va tractar com un canvi d'arquitectura i d'abast, no com una còpia mecànica del WordPress. Es va inventariar la superfície pública, es van separar els continguts editorials de funcions comercials que ja no s'havien de presentar com a actives, i el canvi al domini principal només es va donar per tancat després de validar el build i el HTTPS real de Hostinger.

  • El domini principal serveix ara Astro i manté una arquitectura editorial centrada en energia, hort urbà i aigua.
  • Les eines pràctiques que no necessiten servidor funcionen directament al navegador.
  • La migració va distingir entre preservar una URL útil, redirigir-la i retirar-la; no es va assumir que tot el llegat mereixia ser republicat.
  • La publicació es valida amb build, comprovacions de navegació/SEO i smoke sobre el HTTPS real, no només amb una compilació local.
  • La fitxa pública del projecte mostra el resultat actual; la trastienda de migració queda reservada a documentació tècnica com aquesta guia.

05 / Checklist

Checklist abans del canvi

  1. 01

    Inventaria totes les URLs i funcions públiques abans de construir la substitució.

  2. 02

    Decideix què es conserva, què es redirigeix i què es retira amb una raó explícita.

  3. 03

    Compara titles, canonicals, metadades, sitemap, robots i enllaçat intern del candidat.

  4. 04

    Prova mòbil, formularis, eines, 404 i assets sobre un host real de staging.

  5. 05

    Canvia producció només quan puguis verificar la revisió exacta desplegada i monitoritza Search Console després del tall.

06 / Quan no migrar

Quan no migraria a Astro

No migraria només perquè Astro sigui més nou o perquè una puntuació de rendiment sembli atractiva. Si l'equip necessita editar-ho tot des d'un backoffice WordPress, depèn fortament de WooCommerce o plugins difícils de substituir, té fluxos de membres complexos o no disposa d'un procés de build i manteniment del codi, WordPress pot continuar sent l'opció més eficient. També existeix l'opció intermèdia de conservar WordPress com a CMS headless.