Migració de WordPress a estàtic
Queda't el web. Retira el servidor de sota.
El teu web va lent, cau justament quan arriba trànsit, demana actualitzacions cada setmana i et cobra un allotjament tots els mesos. El problema no és el teu web: és el servidor que té a sota. Nosaltres generem les teves pàgines un cop i les servim des de la xarxa d'AWS, sense cap màquina per mantenir. Mateix disseny, mateixes URL, mateix CMS per al teu equip, i res per actualitzar, res que caigui ni res que puguin piratejar.
- Sense servidorRes per actualitzar, res que caigui
- 99,9 %SLA de disponibilitat d'AWS
- 0 €/mesAllotjament gratis amb trànsit normal
Què canvia de debò
Quatre problemes que deixen de ser-ho
No són quatre millores. Són quatre categories de fallada que una arquitectura estàtica elimina en comptes de mitigar.
La velocitat deixa de dependre del teu allotjament
Una pàgina de WordPress es munta a cada petició: arrenca PHP, es consulta la base de dades, els plugins filtren la sortida i al davant hi ha una memòria cau intentant desfer-ho tot. Una pàgina estàtica es va muntar al build i ja és en un node de CDN a prop del teu visitant. No hi ha memòria cau per escalfar, ni plugin que retardi el primer byte, ni diferència entre la teva pàgina més ràpida i la més lenta.
S'han acabat les trucades de «el web ha caigut»
AWS respatlla S3 i CloudFront amb un SLA de disponibilitat del 99,9 %, i això ja és més del que et signa el teu allotjament actual. Però el que de debò canvia és que no queda servidor on caure: sense base de dades, sense procés PHP i sense màquina al camí, allò que tomba un web WordPress —una consulta desbocada, un límit de memòria, l'actualització d'un plugin, el pic de trànsit del dia que vas sortir a la premsa— ja no té on passar.
La seguretat passa a ser l'estat per defecte
No s'executa PHP en cap petició, o sigui que no hi ha res per executar. No hi ha base de dades on injectar, ni un panell d'accés al teu domini públic on fer força bruta, ni un plugin al camí que carregui el pròxim CVE. El bucket és privat i se serveix a través de CloudFront: l'única cosa que hi ha a internet és una carpeta de fitxers que no poden fer res.
L'allotjament desapareix de les teves despeses fixes
Deixes de pagar una màquina que està ociosa la major part del dia. CloudFront regala 1 TB de trànsit i 10 milions de peticions al mes de manera permanent, que és més del que consumeix un web corporatiu normal, o sigui que servir-lo costa 0 €. L'únic que queda a la factura són cèntims d'emmagatzematge. I si un dia tens molt trànsit, pagues transferència per les visites que t'estan donant alguna cosa, no un pla de servidor que vas contractar per endavant per si de cas.
Un exemple real
Vam començar fent-nos-ho a nosaltres
El web que estàs llegint era WordPress. La seva home enviava 212 KB d'HTML, 48 fulls d'estil i 23 scripts, perquè estava muntada en un maquetador visual que afegeix una petició per cada comoditat.
El nou es genera estàticament i se serveix des d'una CDN: el mateix contingut, una fracció del pes i cap servidor al camí de la petició. Es van portar totes les pàgines, els 785 articles i la taxonomia sencera, en anglès, espanyol i català, en més de mil URL.
Per això podem parlar-ne amb xifres en comptes d'adjectius, i per això les parts incòmodes d'una migració són coses amb què ja ens hem trobat nosaltres, no coses que descobrirem al teu web.
La pregunta de debò
«I això com s'edita?»
És l'objecció de sempre, i mereix una resposta directa i no una frase tranquil·litzadora, inclosa la part en què la resposta és que no.
El teu equip manté un CMS. El que no manté és un servidor.
Combinem el build estàtic amb Pages CMS, un editor sostingut per Git. El teu equip entra amb GitHub, edita en un panell d'administració normal amb camps de debò —text, imatges, llistes, pujades— i desa. Desar fa un commit al teu repositori, CI reconstrueix el web i la CDN serveix la pàgina nova. No hi intervé cap desenvolupador ni s'obre cap tiquet. Aquest web funciona exactament així.
Què es perd: la vista prèvia visual d'arrossegar i deixar anar.
Pages CMS edita contingut estructurat, no un llenç. Qui edita canvia els camps que componen una pàgina en comptes de moure caixes per sobre, i veu el resultat en un build de vista prèvia i no en directe dins l'editor.
Què es guanya en el seu lloc: cada edició és un commit.
Historial complet, un autor per cada canvi i la possibilitat de revertir qualsevol cosa amb un clic, inclosa la pàgina que algú va esborrar sense voler. No hi ha base de dades del CMS per fer-ne còpia, ni CMS per mantenir apedaçat, ni manera que una edició de contingut tombi el web, perquè el que s'està servint és l'últim build que va sortir bé.
A qui li diem que es quedi com està.
Si la feina principal del teu equip de màrqueting és compondre maquetes de pàgina noves cada setmana, un CMS sostingut per Git els frenarà. Això és un cost real i no un detall, i és la raó principal per la qual a alguns els traiem la idea abans que es comprometin, i no després.
Com es fa la migració
El risc d'una migració és al cercador, no a l'enginyeria
Un web nou que t'enfonsa el posicionament t'ha costat més del que costava el servidor. Així que tot el procés gira sobre una condició: res no surt a producció fins a demostrar que el web nou equival al vell, pàgina per pàgina.
Inventari i auditoria
Rastregem el web en producció i n'extraiem els sitemaps i el contingut per REST per construir la llista completa del que existeix: cada URL, les seves metadades, la seva canònica, les seves alternatives d'idioma i el que ja redirigeix. És el document contra el qual es mesura tota la resta, i és teu tant si tires endavant com si no.
Reconstruir les plantilles
El teu disseny, reconstruït com a plantilles d'un generador estàtic en comptes de com un theme. Aquí és on surt el pes de pàgina: el marcatge del maquetador, els fulls d'estil dels plugins i els scripts que es carregaven a totes les pàgines tant si les feien servir com si no.
Migrar el contingut
Pàgines, entrades, mèdia, categories, etiquetes i traduccions es mouen com a contingut estructurat, amb scripts i no a còpia i enganxa. El volum és justament el motiu: uns quants centenars d'entrades són feina per a un script que s'executa igual totes les vegades, no per a dues setmanes de reescriptura a mà.
Demostrar l'equivalència abans del canvi
Les URL es mantenen idèntiques sempre que poden. Tot el que s'ha de moure rep un 301. Títols, descripcions, canòniques, dades estructurades i hreflang es comparen pàgina per pàgina amb el web antic, i els enllaços interns es resolen contra el build nou perquè cap no acabi en un 404. És una condició per publicar, no una tasca de neteja posterior.
Canviar i entregar
El DNS passa a CloudFront, el mapa de redireccions entra a l'edge i es vigila Search Console durant la transició. Reps el repositori, el compte d'AWS, el CMS i la documentació. L'allotjament antic es cancel·la quan hi estiguis conforme, no abans.
Què inclou
El que és teu l'endemà del canvi
El repositori i el compte d'AWS
Tots dos teus des del primer commit. El web el construeix CI a partir de codi que tens tu, sobre infraestructura definida com a codi al teu compte. En cap moment el teu web viu dins dels nostres sistemes i costa de recuperar.
El mapa de redireccions, a l'edge
Cada URL antiga que responia el web anterior, mapejada i servida com un únic 301 des de CloudFront. Un salt i no una cadena: una redirecció que torna a redirigir és un salt que Google compta i una anada i tornada que el teu visitant espera.
Formularis que continuen funcionant
Els formularis de contacte i de consulta passen a un endpoint serverless petit amb protecció antispam, en comptes de mantenir viu un servidor sencer per acceptar un POST. Els enviaments es validen a la frontera i arriben a la bústia o al CRM on arribaven abans.
Analítica i etiquetes, recablejades
Tag Manager, gestió del consentiment i esdeveniments de conversió traslladats i verificats disparant, perquè els informes on viu el teu equip no es quedin en silenci la setmana del canvi.
Accessibilitat i SEO tècnic
Recorreguts amb teclat, estats de focus, contrast i semàntica provats i no afirmats. Canòniques, sitemaps, dades estructurades i hreflang generats pel build en comptes de mantinguts a mà o per un plugin.
Documentació i traspàs
Escrita perquè un desenvolupador nou sigui productiu sense haver d'agendar temps amb nosaltres, i una sessió amb qui edita sobre el CMS que farà servir de debò.
Preguntes freqüents
El que es pregunta abans de comprometre's
Perdrem posicionament?
No si la migració es fa bé, i és justament aquí on la majoria de redissenys fan mal. Les URL es mantenen idèntiques sempre que es pot, tot el que s'ha de moure rep un 301 servit a l'edge de la CDN, i les metadades es comparen pàgina per pàgina amb el web antic abans del canvi, no per mostreig després.
La comparació d'equivalència és una condició per publicar. Si una pàgina no quadra, el canvi espera.
I la nostra botiga WooCommerce?
Un checkout no és un problema estàtic, i no farem veure el contrari. Cistelles, comptes amb sessió, estoc en viu i fluxos de pagament necessiten alguna cosa en execució, així que una botiga transaccional o es queda on és o passa a una API de comerç darrere d'un front estàtic: un projecte més gran que aquest i amb un altre cas de negoci.
On encaixa aquest servei en una botiga és en tot el que l'envolta: les pàgines de màrqueting, les de categoria i contingut, el blog i les landings, que solen ser la major part del web i tot el trànsit. Si la teva botiga és el web sencer, et proposaríem construir-la bé en comptes d'això.
I si una part del nostre web ha de ser dinàmica de debò?
Llavors aquella part rep una API petita i la resta es queda estàtica. Un cercador, una àrea de socis, un calendari de reserves, una calculadora de preus: cada cosa és un endpoint concret i no una raó per mantenir una instal·lació sencera de WordPress en marxa servint pàgines que no canvien mai. El nostre propi formulari de contacte funciona així.
Quant triga una migració?
Un web corporatiu es mesura normalment en setmanes. Un fons de contingut gran depèn de quantes URL i quants idiomes, que és exactament per al que serveix l'inventari del primer pas: reps l'abast i el cost per escrit abans de comprometre't, i no una forquilla que després s'eixampla.
Quant costarà mantenir-lo després?
Amb trànsit normal de web corporatiu, 0 € al mes d'entrega: CloudFront inclou de manera permanent 1 TB de transferència i 10 milions de peticions al mes, i un web corporatiu rarament s'acosta a aquest sostre. Per ser exactes, zero del tot no és: l'emmagatzematge a S3 són uns cèntims i la zona de DNS ronda els 0,50 $ al mes. Comparat amb el que pagues ara de servidor, manteniment i llicències de plugins, és soroll. Amb molt trànsit sí que hi ha cost de transferència, i escala amb les teves visites. Durant la revisió modelem les teves xifres reals a partir de la teva analítica actual, en comptes de donar-te una mitjana.
Podem fer marxa enrere si no ens convenç?
Sí, i és una pregunta legítima. El web antic continua dret i sense tocar fins que hi estiguis conforme, el DNS és l'única cosa que es mou, i revertir-ho et deixa exactament on eres. Res de la migració no és destructiu amb el que tens ara.
Això només val per a WordPress?
No. WordPress és el cas habitual, però el mateix enfocament serveix per a Drupal, Joomla, un maquetador visual o un PHP escrit a mà que ningú no gosa tocar des de fa sis anys. El que importa és si les pàgines són essencialment iguals per a totes les visites, no què les va generar.
Envia'ns el teu web actual
Et direm què el frena, quant costaria servir-lo en estàtic i si la migració et compensa, abans que gastis res.