Giugno 2024, una mattina di lunedì in screen share con il responsabile tecnico di una holding editoriale del Centro Italia. Sul suo monitor: sei tab del browser, una per ogni CMS delle sei testate del gruppo. Sei wp-admin diversi, sei plugin set diversi, sei coppie di credenziali. Per pubblicare uno stesso comunicato stampa cross-testata, la sua caporedattrice doveva fare il login sei volte. Unificare 6 testate editoriali in una redazione tecnica non è un esercizio di brand consolidation: è un problema di piattaforma, di sync e di permessi multi-tenant. In quattro mesi abbiamo portato il gruppo da sei silos a un hub unico, con i sei frontend pubblici WordPress intoccati. Negli altri post di Fieldwork racconto i case study reali del lavoro Romiltec.
Unificare 6 testate editoriali: il contesto e i sei stack ereditati
Il gruppo (lo chiamerò per tutto il post un gruppo editoriale italiano con 6 testate, come da accordo con il cliente) era nato per acquisizioni successive nel decennio 2014-2022. Una holding editoriale italiana con sei testate su pubblici diversi (verticali generaliste e settoriali). Ognuna con la propria storia tecnica:
- Tre testate su WordPress 5.x con plugin commerciali diversi per editorial workflow, SEO e media management
- Una testata su WordPress 6.x con un editor custom React costruito anni prima da un’agenzia esterna che non esisteva più
- Una testata su un CMS proprietario PHP scritto anni prima e non più presidiato dal dev originale
- Una testata appena migrata su WordPress headless con frontend Next.js e backend WP REST
Sei stack, sei pipeline di pubblicazione, sei sistemi di permessi, sei policy di backup, sei domini con configurazioni Cloudflare disallineate. Numeri operativi del network: decine di migliaia di articoli, oltre venti redattori interni più una rete di freelance, milioni di pageview/mese sull’aggregato (numero loro, non nostro).
Il problema non era il volume: era che la redazione centrale, formalmente nata nel 2023 dopo l’ultima acquisizione, non esisteva tecnicamente. Esisteva una lista di Google Sheets condivisa fra caporedattrici, dove tracciavano a mano cosa stavano scrivendo le altre.
Unificare 6 testate editoriali parte dalla discovery: due settimane in screen share
Il primo lavoro non è stato scrivere codice. Sono state due settimane di screen share con tre persone chiave del cliente: il CTO della holding, una caporedattrice senior che gestiva il calendario editoriale cross-testata, un sysadmin esterno in retainer che aveva il keyring di tutti gli accessi.
Ho aperto un repo discovery/ con sei file Markdown, uno per testata. Per ognuna abbiamo mappato:
- Stack tecnico (versione PHP, versione WP, plugin attivi, cron job, webhook)
- Schema dei contenuti (post type, custom fields, tassonomie, relazioni autori-articoli)
- Pipeline di pubblicazione (chi può cosa, in che stato, con quali approvazioni)
- Endpoint pubblici (REST API esposta o no, webhook verso terzi, integrazioni con tool di analytics)
- Telemetria (cosa logghiamo, dove, con che retention)
Alla fine delle due settimane il cliente aveva il primo documento tecnico unificato della sua piattaforma editoriale dopo dieci anni. Già quel documento, da solo, ha pagato il mese: il CTO della holding ha potuto smettere di chiedere la stessa cosa al sysadmin per la sesta volta in tre anni.
La scelta architetturale: hub centrale, frontend pubblici intoccati
La tentazione naturale sarebbe stata convincere il cliente a migrare le sei testate sotto un’unica installazione WordPress Multisite, omogeneizzando lo stack. L’avevamo proposto come opzione A. Sul tavolo è durata 24 ore.
Tre motivi tecnici per cui è caduta:
- Le sei testate hanno SEO consolidato indipendentemente da anni. Riscrivere i frontend pubblici significava rischiare regressioni sul ranking organico durante la migrazione, su un fatturato pubblicitario che il gruppo non poteva permettersi di toccare.
- Il CMS proprietario PHP della testata di cronaca aveva integrazioni custom con un sistema di feed agenziali (ANSA, AGI) costato anni di tuning. Riscriverlo in WP avrebbe richiesto un progetto a sé, fuori scope e fuori budget.
- Le redazioni delle sei testate non volevano cambiare lo strumento con cui lavoravano ogni giorno. Cambiare pelle a sei redazioni in parallelo è un rischio di adozione che, su un team di 22 persone più freelance, vince sempre sull’efficienza tecnica del Multisite.
L’opzione B che abbiamo costruito: un hub editoriale centrale AI Multisite, con sync bidirezionale verso le sei installazioni esistenti via REST API. Le redazioni continuano a usare i loro CMS quando vogliono. Ma chi lavora cross-testata (caporedattrice senior, social, ufficio stampa) entra una volta sola nell’hub e gestisce tutte e sei.
Architettura tecnica per unificare 6 testate editoriali
Lo schema concreto, a fine progetto:
┌──────────────────────┐
│ AI Multisite Hub │
│ (Laravel + Vue 3) │
└──────────┬───────────┘
│ REST sync bidirezionale
┌────────────┬───────┼────────┬────────────┬─────────────┐
│ │ │ │ │ │
┌────▼───┐ ┌────▼───┐ ┌─▼──┐ ┌──▼───┐ ┌────▼────┐ ┌────▼────┐
│ WP 5.x │ │ WP 5.x │ │WP6 │ │CMS PHP│ │ WP-head │ │ WP 5.x │
│ cronaca│ │ life │ │tech│ │ legacy│ │ sport │ │ food │
└────────┘ └────────┘ └────┘ └───────┘ └─────────┘ └─────────┘
Hub. Laravel 12, MariaDB 11, Redis per cache e queue, Typesense come motore di ricerca cross-testata. Frontend Vue 3 con Vuetify, dashboard unica per la caporedattrice senior. RBAC granulare via spatie/laravel-permission: chi può vedere cosa, su quali testate, con quali permessi.
Sync layer. Per le cinque testate WordPress (incluso il headless), il sync gira sopra l’endpoint wp/v2 della WordPress REST API, con application passwords dedicate per ogni testata e rate limiting client-side per non saturare i server delle redazioni nelle ore di chiusura. Per il CMS proprietario PHP della testata di cronaca, abbiamo scritto un adattatore custom: 380 righe di PHP che esponevano tre endpoint compatibili con il contratto interno dell’hub (lista articoli, singolo articolo, push articolo).
Schema dei contenuti unificato. Il modello centrale dell’hub usa entità neutre (Publication, Author, Article, Revision, MediaAsset) che si mappano via configurazione sui post type e custom field di ogni testata. Le tassonomie disallineate fra le sei (categorie, tag, sezioni) sono diventate facet calcolati in Typesense, non normalizzate forzatamente nel DB.
Identity. Single sign-on via OAuth2 Passport, con login federato dell’hub che viene proxato verso le installazioni WP per le operazioni che richiedono di scrivere come autore. Gli account redazionali esistenti sulle sei WP sono stati linkati uno a uno con gli utenti dell’hub via tabella di mapping; nessun forced merge, nessuna cancellazione.
I quattro mesi di rollout, testata per testata
Niente big bang. Le sei testate sono entrate sull’hub in sequenza, una ogni due o tre settimane, secondo l’ordine di rischio e complessità tecnica:
- Testata food (WP 5.x, plugin minimi). La più semplice, scelta come pilota. Una settimana di import storico, una settimana di sync live in observe-only, una settimana di cut-over. La caporedattrice food è stata la prima a usare l’hub in produzione.
- Testata lifestyle (WP 5.x). Stesso pattern, due settimane.
- Testata tech consumer (WP 5.x). Tre settimane: schema dei custom field più articolato, integrazioni con un’API di prezzi e affiliazioni che ci ha richiesto un secondo passaggio di sync.
- Testata sport (WP headless). Quattro settimane: il REST API era già il canale primario per il frontend Next.js pubblico, abbiamo dovuto sincronizzarci con la cache di Vercel del cliente per evitare race condition tra hub e frontend.
- Testata intrattenimento (WP 6.x con editor React custom). Tre settimane: l’editor custom non parlava al REST WP standard. Abbiamo aggiunto un middleware lato hub che traduceva il payload dell’editor verso il modello interno, lasciando l’editor pubblico intoccato.
- Testata cronaca (CMS proprietario PHP). Sei settimane: la più complessa. Abbiamo scritto e testato l’adattatore custom in staging per due settimane, fatto sync in observe-only per altre due, cut-over in due. Senza l’esperienza con WP-head della testata sport non saremmo entrati in tempo.
In totale: 17 settimane dalla call di kickoff al completamento della migrazione di tutte e sei. Sopra al budget di 4 mesi, sotto al budget di 5. Il delta lo abbiamo assorbito noi su un compromesso preso a metà: l’integrazione con Matomo Microservice (analytics cross-testata in tempo reale) l’abbiamo consegnata un mese dopo, fuori dal pacchetto base.
I numeri del progetto: unificare 6 testate editoriali in concreto
A fine 2024, sei mesi dopo il go-live completo:
- Tempo medio per pubblicare un comunicato cross-testata: da ~75 minuti (login multipli più copy/paste manuale fra CMS) a ~9 minuti (pubblicazione singola con propagazione async sulle testate selezionate)
- Numero di Google Sheet attivi per il calendario editoriale: da 4 a 0
- Articoli al mese gestiti dall’hub: ~2.400 (in linea con il volume precedente, non era obiettivo aumentarlo)
- Pageview pubbliche aggregate: invariati, l’obiettivo era preservarli, non crescerli
- Account redazionali sull’hub: 27 (i 22 interni più 5 freelance ricorrenti), con permessi RBAC granulari per testata
I numeri di pageview totali del network AI Multisite (45M visite/mese, gennaio 2026) includono questa holding e altri partner: il dato del singolo cliente lo lascio dentro il loro PnL.
Cosa mi sono portato a casa dall’unificare 6 testate editoriali
Tre cose, dette al senior dev sulla call di chiusura del progetto.
Prima. I frontend pubblici di una testata editoriale storica sono asset SEO, non codice. Vanno toccati solo quando il valore del cambio di stack supera in modo provato il rischio di regressione organica. In questo caso non lo superava: sync bidirezionale e hub centrale erano la scelta corretta, anche se architetturalmente meno elegante di un Multisite unico.
Seconda. Le redazioni non si convincono con l’argomento dell’efficienza tecnica. Si convincono lasciandole lavorare con lo strumento che già conoscono e dando in più, sopra, qualcosa che prima non avevano. La redazione tecnica unificata l’hanno adottata in tre settimane perché non gli abbiamo tolto niente.
Terza. Su sei testate eterogenee con sei stack diversi, il punto di ingegneria più alto è l’adattatore custom verso il CMS legacy: 380 righe scritte bene possono valere quanto un anno di refactor mancato. Riscrivere il legacy non era nel budget né nel valore percepito dal cliente. Adattarsi al legacy con una superficie minima esposta verso l’hub sì.
Il responsabile tecnico oggi ha una sola dashboard aperta sul monitor invece di sei tab. La caporedattrice senior ha un calendario editoriale centrale che si aggiorna da solo. Le redazioni delle sei testate continuano a scrivere come scrivevano. Per noi di Romiltec, quei quattro mesi di Fieldwork sono diventati la base di pattern multi-tenant che oggi usiamo come standard sui nuovi onboarding di AI Multisite.