Audit gratuito
Non sai se il tuo sito valga una migrazione?
Trenta minuti sul tuo WordPress: le tue pagine, cosa sta davvero indicizzando Google, come sono impostate le lingue e da quali plugin non riesci a uscire. Il piano resta tuo comunque.
Guarda l'Accelerator di migrazione →
Per quel che vale: questo sito — ogni landing, ogni post, cinque lingue — è Astro su Cloudflare Pages. Non abbiamo scelto lo stack per il lavoro dei clienti tenendo il nostro sito in un posto più indulgente. È tutta la prova che offro. Prendi l'argomento per quello che vale, non per i nostri numeri.
## Le due decisioni che tutti rimandano, e costano entrambe
Le migrazioni si vendono con velocità e posizionamento. Le due cose che davvero determinano se il sito nuovo sarà migliore fra tre anni non compaiono quasi mai nella conversazione commerciale.
**La prima è l'indicizzazione.** Chiedi al tuo team quali URL del sito attuale Google può indicizzare. Nella maggior parte delle installazioni WordPress nessuno sa rispondere, perché la risposta è spalmata tra un plugin SEO, il robots.txt, le impostazioni degli archivi e ciò che il tema ha deciso sulle pagine di tag e autore. Così i siti pubblicano in silenzio migliaia di URL paginati, filtrati e quasi duplicati, e il crawl budget se ne va su pagine che nessuno voleva posizionare. Una migrazione è l'unico momento in cui puoi rendere tutto esplicito: una decisione per template, scritta nel codice, dove cambiarla è una modifica rivista e non un interruttore che qualcuno sposta alle sei di sera. Fallo durante lo spostamento o erediterai la stessa nebbia su uno stack più veloce.
**La seconda è la lingua.** Multilingua su WordPress significa un plugin che trasforma ogni pagina in un duplicato che qualcuno deve tenere sincronizzato: è esattamente per questo che le agenzie lo fanno pagare come sovrapprezzo e trattano una terza lingua come una complicazione. Modellata bene, ogni lingua è una rotta con il proprio file di contenuto, l'hreflang si genera dal contenuto stesso e una traduzione mancante emerge quando il sito viene costruito, non quando la trova un cliente. Quell'inversione — da "le traduzioni si allontanano in silenzio" a "le traduzioni falliscono ad alta voce" — vale più in tre anni di qualsiasi punteggio Lighthouse.
E la terza, quella che invece tutti ricordano ma troppo tardi: conserva gli URL. Tutti. La mappa dei redirect non è burocrazia della migrazione, è la migrazione. Costruiscila nella prima settimana partendo dall'inventario reale di Search Console, non da un'ipotesi su cosa contenga la sitemap.
## Tre cose che si rompono quando sparisce il database
Nessuno ti vende una migrazione elencando ciò che smette di funzionare, quindi eccolo l'elenco. Tutte e tre si risolvono, e tutte e tre costano meno risolte di proposito che di corsa la settimana dopo il lancio.
**La ricerca interna.** La ricerca di WordPress è una query al database. Togli il database e non c'è più nulla da interrogare. La soluzione è un indice di ricerca statico — Pagefind è lo strumento su cui finisce la maggior parte dei siti Astro: legge il sito già costruito dopo ogni build, scrive un indice compatto accanto e il browser scarica solo i frammenti che corrispondono a ciò che qualcuno ha digitato. È abbastanza veloce da mostrare i risultati mentre scrivi, e non costa nulla mantenerlo perché non c'è un server di mezzo.
**I moduli.** Senza PHP non c'è la funzione di invio email, quindi il tuo modulo di contatto ha bisogno di una destinazione. Su Cloudflare è una piccola funzione sulla loro rete: riceve il modulo, filtra lo spam con Turnstile — che, a differenza di un CAPTCHA, di solito non chiede nulla al visitatore — e consegna il messaggio a un servizio email come Resend o SendGrid. Oppure salti tutto e punti il modulo su HubSpot, che è quello che la maggior parte dei team marketing ha già.
**I soft 404 e i loop di redirect.** È quella che costa traffico in silenzio. Se qualcuno chiede una pagina che non esiste, il sito deve rispondere con un 404 vero e non reindirizzare gentilmente alla home con un codice di successo — Google legge quel secondo comportamento come un "soft 404" e peggiora il modo in cui scansiona l'intero dominio. Sui siti multilingua è peggio: forza HTTPS, aggiungi la barra finale, aggiungi il prefisso di lingua e hai già concatenato tre redirect per una sola visita. Tutto questo va risolto in un unico salto, deciso una volta. È noioso da fare bene e costoso da fare male.
## Dove sta andando tutto questo
La cosa interessante non è che WordPress perda due punti percentuali. È che i requisiti di un sito aziendale sono cambiati sotto i piedi di tutti nello stesso momento: leggibile dalle macchine per impostazione predefinita, abbastanza veloce da entrare in una risposta generata, e abbastanza economico da modificare perché il tuo team smetta di trattare il sito come un progetto trimestrale.
Alcuni team ci arriveranno con WordPress, con disciplina e una lista di plugin molto corta. Più team decideranno che il modo più semplice di non avere nulla da patchare è non avere nulla in esecuzione.
Transform by Epinium
Ti diremo se ti conviene restare su WordPress
L'audit di migrazione mappa le tue pagine, la tua indicizzazione, le tue lingue e le tue dipendenze dai plugin, e ti dà uno scope fisso e una data fissa. Se la risposta onesta è che migrare non conviene al tuo sito, è quella la risposta che ricevi — e il piano è tuo in ogni caso.
Prenota l'audit di migrazione →
## Domande frequenti
### WordPress sta morendo nel 2026?
No. Muove ancora circa il 41% di tutti i siti e circa il 59% di quelli con un CMS riconoscibile. È cambiata la direzione: dopo quindici anni di crescita perde uno o due punti l'anno. Per gran parte del mondo WordPress resta l'opzione predefinita. I team che se ne vanno sono in genere quelli che pubblicano a volume, in più lingue e con supporto tecnico disponibile.
### Che cos'è esattamente un sito "ai-native"?
Un sito i cui contenuti sono leggibili dalle macchine senza browser. In pratica: HTML renderizzato lato server con semantica pulita, contenuti che non dipendono da JavaScript per comparire, un file llms.txt che descrive il sito ai modelli linguistici e, spesso, una versione Markdown di ogni articolo. Più che una categoria di prodotto è un insieme di proprietà — e un sito statico le ottiene quasi tutte gratis.
### Possiamo far scrivere un'IA direttamente nel sito?
In sicurezza sì — ma solo quando i contenuti hanno uno schema. Se ogni tipo di contenuto dichiara i suoi campi e i suoi tipi, un agente può generare o aggiornare voci e ciò che è malformato fallisce la validazione prima di arrivare a un visitatore, con la modifica che arriva come un diff che qualcuno approva. Eseguire la stessa automazione contro un WordPress con page builder significa modificare markup generato e campi serializzati nel database: è così che i team finiscono a ripristinare backup invece di risparmiare tempo.
### Come si mantiene il controllo di ciò che viene indicizzato?
Decidendolo per template, nel codice, prima che il sito vada online. Archivi di tag, archivi di autore, serie paginate e viste filtrate ricevono ciascuno una risposta esplicita — indicizzare, redirigere o ritirare — e sitemap, canonical e regole robots si generano dalla build invece di essere modificati a mano. La prova pratica è se qualcuno del tuo team sa dire oggi quali pattern di URL sono indicizzabili senza aprire la schermata delle impostazioni di un plugin.
### Posso tenere WooCommerce se passo ad Astro?
Dentro Astro no, ed è il criterio di esclusione più netto di tutta la decisione. Uno store transazionale sta su Shopify o su un backend di commercio headless, con Astro come front end se lo desideri. Se WooCommerce è dove atterrano i tuoi ricavi, migra il sito di contenuti attorno e lascia stare il checkout.
### Come pubblicherà il nostro team marketing senza wp-admin?
Due strade percorribili. File Markdown su git con un editor visuale sopra, adatta a team un po' tecnici e a costo zero. Oppure un CMS headless — Sanity, Contentful, Decap, Keystatic — che dà ai redattori un'interfaccia familiare e si collega alla stessa build. Pubblicare avvia una ricostruzione; sul nostro sito ci vuole meno di un minuto per l'intero sito.
### Che fine fanno i nostri plugin?
Ognuno viene mappato sul suo sostituto prima di iniziare, oppure viene segnalato. I form passano a HubSpot o a un endpoint serverless. I metadati SEO diventano frontmatter tipizzato che fa fallire la build quando è sbagliato. Cache e CDN sono la piattaforma di hosting stessa. I plugin di sicurezza non servono più perché non c'è runtime da attaccare. Ciò che non ha equivalente deve emergere nell'audit, non alla terza settimana.
### Astro va bene per un sito da migliaia di pagine?
È lì che si guadagna lo stipendio — questo sito ci gira sopra, in cinque lingue e con diverse migliaia di pagine. Le content collection danno contenuti tipizzati e validati, quindi una data malformata o un alt mancante rompe la build invece di mandare in produzione una pagina rotta. Più grande è il catalogo, più conta: nessuno rilegge a mano la pagina 1.800.
### Abbiamo già investito molto in un page builder. Cambia i conti?
Alza il costo della migrazione, perché l'output del builder va ricostruito come componenti, non esportato. Alza anche il costo di restare, perché quel markup è di solito la cosa più pesante della pagina e la meno leggibile per i crawler. Il costo affondato non è un argomento in nessuna direzione: confronta i prossimi tre anni di entrambe le opzioni, non i tre passati.
### Da quale dimensione ha senso?
A grandi linee: più di qualche centinaio di pagine, o più di una lingua, o un team che pubblica ogni settimana ed è frenato dallo stack attuale. Sotto quella soglia, irrobustire il WordPress esistente è di solito la spesa migliore. Lo diciamo negli audit più spesso di quanto la gente si aspetti.
### Quanto dura una migrazione?
Un sito di contenuti da qualche centinaio di pagine richiede in genere quattro settimane dal kickoff al cutover. Migliaia di pagine, più lingue o un CMS headless sopra portano a sei o otto. L'audit degli URL della prima settimana è ciò che rende la stima realistica invece che ottimistica.