Da WordPress a CMS proprietario: come abbiamo ricostruito tnsolutions.it

Ci sono progetti che si raccontano meglio di qualsiasi brochure, perché il cliente e il fornitore sono la stessa azienda. Questo è il nostro: la ricostruzione completa di tnsolutions.it, passato in venticinque anni da un sito HTML scritto a mano a Joomla, poi a WordPress, e oggi a una piattaforma proprietaria costruita su tecnologie open, con la nostra infrastruttura sotto e il nostro ecosistema AI dentro.

Non è un restyling. È un cambio di categoria: da sito web a sistema editoriale indipendente, progettato per reggere la crescita dell'azienda invece di rincorrerla.

In questo caso di studio raccontiamo l'architettura, le scelte tecniche, i problemi veri che abbiamo incontrato e come li abbiamo risolti. È lo stesso metodo che applichiamo sui progetti dei nostri clienti — con la differenza che qui possiamo mostrarvi tutto.

Il punto di partenza: venticinque anni e tre generazioni di tecnologia

Il sito che abbiamo sostituito non era il primo. Era il terzo.

Si è cominciato con un sito in HTML scritto a mano, quando un sito aziendale era un insieme di file caricati via FTP e ogni modifica passava da chi sapeva scrivere il codice. Poi è arrivato Joomla, che per la prima volta ha permesso di aggiornare i contenuti senza toccare i file — e con lui è arrivata la prima struttura di indirizzi generata da un programma invece che decisa da una persona. Infine WordPress, con cui il sito è cresciuto fino a diventare l'archivio che è oggi: centinaia di articoli, pagine di servizio, contenuti tradotti, materiali di campagne concluse da tempo.

Ogni passaggio ha lasciato la sua sedimentazione. Indirizzi con la forma del CMS che li aveva generati, sezioni che nel sistema successivo non esistevano più, pagine raggiungibili da due percorsi diversi perché due generazioni li avevano costruiti in modo diverso. Nessuno di questi era un errore al momento in cui è nato: sono il prezzo normale di un sito che accompagna un'azienda per venticinque anni.

È anche il motivo per cui la parte più lunga del progetto non è stata scrivere il nuovo sito, ma capire cosa c'era nel vecchio — e quel lavoro lo raccontiamo più avanti, perché è la parte che decide se un patrimonio di posizionamento sopravvive a una migrazione o si disperde.

Il problema, alla fine, non era WordPress. WordPress è un ottimo strumento, e lo installiamo tuttora per i clienti quando è la scelta giusta: lo raccontiamo in un altro caso di studio, la migrazione di un CMS da Joomla a WordPress. Il problema era il divario fra quello che un CMS generalista dà per impostazione predefinita e quello che serviva a noi.

Perché WordPress stava diventando un limite

Le ragioni si sono accumulate lentamente, e sono le stesse che sentiamo raccontare dalle aziende che ci chiamano.

Ogni funzione in più era un plugin in più. Un modulo per la SEO, uno per le traduzioni, uno per la cache, uno per i moduli di contatto. Ognuno con il proprio ciclo di aggiornamenti, le proprie incompatibilità e la propria superficie esposta. La manutenzione smetteva di essere "aggiornare il sito" e diventava "far convivere dodici componenti scritti da autori diversi".

Il tetto prestazionale era strutturale. Su una pagina generata a ogni richiesta, con temi e plugin che iniettano CSS e JavaScript ciascuno per conto proprio, si ottimizza fino a un certo punto: oltre, si sposta soltanto il problema. Gli indicatori che Google usa per valutare l'esperienza di pagina non si spostavano più.

Il controllo sull'HTML era indiretto. Marcatura dei dati strutturati, gestione delle lingue alternate, indirizzi canonici: tutte cose che passavano da impostazioni di plugin, non da decisioni nostre. Quando un dettaglio non tornava, non c'era un file da correggere — c'era un pannello da interpretare.

Il flusso editoriale non rispecchiava il nostro lavoro. Pubblicare in due lingue, tenere allineate le versioni, verificare che ogni contenuto avesse i suoi metadati completi: operazioni ripetute a mano, quindi soggette a dimenticanze.

A un certo punto la domanda si è ribaltata. Non più "come ottimizziamo WordPress", ma "cosa costruiremmo, se il sito fosse un prodotto".

L'obiettivo: non un sito, una piattaforma

Abbiamo scritto gli obiettivi prima di scrivere il codice. Sono cinque, e ognuno ha guidato decine di scelte successive.

1. Indipendenza tecnologica. Nessun blocco su un fornitore o su un ecosistema di estensioni. Tutto ciò che usiamo è open source, sostituibile e in casa nostra.
2. Qualità visiva coerente. Un'immagine aziendale unica su ogni pagina, non l'effetto collage di un tema personalizzato a strati.
3. Velocità misurabile, sui parametri che i sistemi di analisi di Google osservano davvero — non sulla sensazione soggettiva di "sito veloce".
4. Esperienza mobile di livello portale, perché è da lì che arriva la maggioranza delle visite.
5. Un CMS proprietario che ci permetta di gestire contenuti, traduzioni e dati strutturati come processi, non come compilazione manuale di campi.

L'architettura, dall'esterno verso l'interno

La piattaforma è organizzata in strati. Ogni strato ha un compito solo e può essere sostituito senza toccare gli altri: è il principio che rende un sistema manutenibile a distanza di anni.

Il perimetro: pfSense davanti a tutto

Il traffico non arriva mai direttamente all'applicazione. Passa prima da un firewall pfSense, che governa cosa entra, verso quale rete e con quali regole. È lo stesso approccio che progettiamo per i nostri clienti nel servizio di gestione e installazione firewall: la rete pubblica e le reti interne sono mondi separati, e il passaggio fra i due è un punto di controllo esplicito, non una conseguenza della configurazione predefinita.

La segmentazione ha una conseguenza pratica poco intuitiva: il servizio web non è raggiungibile dall'esterno. Ascolta solo su un canale interno, e l'unico componente che può parlargli è il reverse proxy. Anche riuscendo a raggiungere l'indirizzo pubblico su una porta non prevista, non c'è nulla in ascolto.

Il rilevamento delle intrusioni con Hector LIS

Sopra il perimetro lavora Hector LIS, il componente del nostro ecosistema che si occupa del sistema di rilevamento delle intrusioni (IDS). La differenza fra un firewall e un IDS è il tipo di domanda che si pongono: il firewall chiede "questo traffico è permesso?", l'IDS chiede "questo traffico, pur permesso, somiglia a un attacco?".

Il valore sta nel secondo. Un sito pubblico riceve ogni giorno tentativi automatici di sondaggio: indirizzi che cercano pannelli di amministrazione di altri sistemi, file di configurazione, credenziali dimenticate. Sono rumore di fondo di Internet, ma diventano informazione quando qualcuno li correla, li classifica e li conserva. È esattamente ciò che fa Hector LIS, e che nel nostro caso ha già permesso di riconoscere e archiviare campagne di scansione mirata con la loro firma temporale.

Su questa parte ci fermiamo qui, di proposito: la descrizione dettagliata di una difesa è essa stessa un'informazione utile a chi attacca.

Server virtuali e separazione degli ambienti

Tutto gira su infrastruttura virtualizzata, con la stessa logica che applichiamo nei progetti di virtualizzazione server: risorse assegnate per ruolo, istantanee prima di ogni intervento rilevante, possibilità di riportare indietro una macchina in minuti anziché in giornate.

Gli ambienti sono due e non comunicano: uno di sviluppo e collaudo, uno di produzione. Sembra un'ovvietà e invece è la scelta che ha evitato più problemi di ogni altra. Ogni modifica nasce sull'ambiente di collaudo, viene verificata lì — resa a schermo compresa, non solo "il codice compila" — e solo dopo raggiunge la produzione.

Alcune configurazioni restano deliberatamente diverse fra i due ambienti. Un esempio concreto: lo strumento interno che analizza lo stato SEO del sito, in produzione interroga il dominio pubblico reale, mentre in collaudo lavora su una copia locale. Uniformare i due comportamenti sembrerebbe ordine; in realtà farebbe generare traffico di analisi verso il sito vivo da una macchina che non è quella di produzione. Sono divergenze documentate, non dimenticanze.

La catena della cache

La velocità di un sito non nasce da un'ottimizzazione, nasce da una catena: ogni anello assorbe una parte del lavoro, e quello che arriva in fondo è pochissimo.

Il punto interessante non è la presenza della cache, che ha chiunque. È la gestione dell'invalidazione, cioè il momento in cui una copia va buttata. Una cache che non si svuota al momento giusto è peggio di nessuna cache: mostra dati vecchi e fa dubitare di tutto il sistema.

Abbiamo affrontato il problema con scadenze diverse per natura del contenuto — una mappa di reindirizzamenti si aggiorna in un minuto, una sitemap in un'ora — e con azzeramento immediato al salvataggio dai pannelli di gestione. Chi pubblica non deve sapere che esiste una cache: pubblica, e il sito è aggiornato.

Una scelta che vale la pena dichiarare: la cache in memoria vive dentro il processo dell'applicazione, non su un servizio separato. Per un sito di questa dimensione è la soluzione più semplice che funziona, e ogni componente in meno è un componente che non si rompe e non va aggiornato. Il giorno in cui servissero più istanze a condividere la stessa copia, lo strato si sostituisce senza toccare il resto — è il vantaggio di averlo tenuto isolato.

Prestazioni: cosa guarda Google e cosa abbiamo fatto

I sistemi di analisi di Google misurano quanto ci mette la pagina a diventare utile, non quanto pesa. Abbiamo lavorato su tutta la catena.

Compressione delegata al livello giusto. Un errore frequente è lasciare che sia l'applicazione a comprimere: il risultato è che il proxy si limita a inoltrare quello che riceve e l'algoritmo più efficiente non entra mai in gioco. Spostando la compressione sul reverse proxy, la stessa pagina è passata da 37,4 KB a 30,2 KB, il 19% in meno, a parità assoluta di contenuto.

CSS critico dentro l'HTML. Il foglio di stile necessario alla prima schermata viaggia con la pagina, così il browser non deve aprire una seconda connessione prima di poter disegnare qualcosa.

Immagini in formato moderno, dimensionate per lo spazio che occupano davvero, con caricamento differito per tutto ciò che sta sotto la piega.

Meno JavaScript che gira all'avvio, ottenuto spostando in basso il codice che serve solo dopo l'interazione.

Il CMS proprietario: cosa fa, che prima non si poteva fare

Il cuore del progetto è il sistema di gestione dei contenuti. Non è un tema su un CMS esistente: è un'applicazione nostra, costruita attorno al modo in cui lavoriamo.

• Contenuti e traduzioni come coppie collegate. Ogni pagina e ogni articolo conoscono la propria versione nell'altra lingua. Da questo legame nascono automaticamente le dichiarazioni per i motori di ricerca: nessuno le scrive a mano, quindi nessuno se le dimentica.
• Dati strutturati generati dal contenuto. Le informazioni che i motori leggono in forma di dati — tipo di pagina, domande frequenti, video, organizzazione — sono prodotte dal sistema a partire da ciò che è pubblicato, non compilate in un campo separato che con il tempo diverge dal testo.
• Verifiche di qualità integrate. Il pannello segnala in tempo reale ciò che manca: una descrizione assente, un titolo troppo corto, una pagina senza corrispondente nell'altra lingua. La qualità editoriale diventa una lista da chiudere, non una speranza.
• Governo dei reindirizzamenti dall'interfaccia, con verifica delle catene: nessun indirizzo può puntare a un altro che a sua volta rimanda altrove.
• Ricerca interna che ignora gli accenti: chi cerca "virtualizzazione" e chi scrive "virtualizzazione" senza accenti trova le stesse cose, con i risultati ordinati per pertinenza reale — titolo prima del corpo, corrispondenza esatta prima di quella parziale.

L'archivio come albero, non come elenco

La schermata dei contenuti è il punto in cui si capisce la differenza rispetto a un CMS generalista. Le pagine si vedono nella loro gerarchia reale, divise per lingua, con lo stato di pubblicazione e — accanto a ognuna — se la versione nell'altra lingua esiste o manca.

Quel piccolo indicatore "manca EN" accanto a una pagina è il motivo per cui il sito non ha buchi di traduzione: non è una verifica che qualcuno deve ricordarsi di fare, è una condizione visibile in elenco. E il pulsante accanto avvia la localizzazione assistita, che è cosa diversa da una traduzione automatica: produce una prima versione nella lingua di destinazione, che una persona rivede prima della pubblicazione.

Il controllo di qualità come pannello, non come speranza

La seconda schermata è l'analisi SEO integrata. Non è un servizio esterno collegato: è un motore nostro che percorre l'intero sito, ne misura tredici dimensioni di qualità — pagina, dati strutturati, accessibilità, architettura, profondità dei contenuti, velocità, internazionalizzazione — e confronta il risultato con quello dei concorrenti diretti.

Il valore non sta nel numero. Sta in tre dettagli: l'analisi dichiara il proprio perimetro (quante URL, da quali fonti), si confronta con la corsa precedente dicendo cosa è migliorato e cosa è peggiorato, e trasforma i rilievi in un elenco di cose da fare invece che in un rapporto da interpretare. È lo stesso lavoro che un consulente esterno fatturerebbe a giornata, disponibile su richiesta e ripetibile.

Accanto ci sono i pannelli per i reindirizzamenti — con verifica automatica delle catene — per l'indicizzazione, per la copertura territoriale dei servizi, per i certificati e per la chat. Ognuno nasce da un problema vero incontrato lavorando, non da una lista di funzionalità decisa a tavolino.

SEO tecnica: architettura, non espedienti

L'obiettivo dichiarato era non perdere nulla del posizionamento costruito in vent'anni, e possibilmente guadagnare. Il lavoro si è concentrato su quattro fronti.

Indirizzi stabili e coerenti. Ogni contenuto ha un solo indirizzo valido, dichiarato come tale. Le forme alternative — con o senza barra finale, con o senza prefisso — convergono tutte su quello, con un solo passaggio.

Sitemap divise per natura. Invece di un unico file enorme, sei file tematici: pagine, aree di servizio, articoli italiani, articoli inglesi, immagini, video. Un crawler capisce prima cosa sta guardando, e noi ci accorgiamo prima se una sezione perde pezzi.

Lingue dichiarate correttamente. Le versioni alternate si dichiarano a vicenda solo quando sono davvero la stessa pagina in un'altra lingua. Collegare due contenuti diversi perché parlano dello stesso tema è una dichiarazione falsa, e i motori la trattano come tale.

Contenuti accessibili anche agli assistenti AI. Oltre alle sitemap classiche pubblichiamo file descrittivi pensati per i sistemi conversazionali, e non blocchiamo i loro crawler. Le persone oggi cercano anche così: chiudere la porta significa sparire da un canale intero.

Venticinque anni di indirizzi da normalizzare

È la parte del progetto che nessuno vede e che vale più di tutte. Un sito passato per tre generazioni di tecnologia accumula indirizzi rotti come una casa accumula scatole in cantina: percorsi con la forma del CMS che li aveva generati, pagine spostate, sezioni chiuse, contenuti prodotti da estensioni non più installate, link esterni che puntano dove non c'è più nulla.

Ignorarli significa buttare via autorevolezza acquisita: un collegamento da un sito autorevole verso una pagina che risponde "non trovata" è valore che si disperde.

Il criterio che abbiamo seguito merita una nota, perché è controcorrente. Non tutto va reindirizzato. Un indirizzo che non ha un equivalente sensato deve rispondere "non esiste": mandarlo alla pagina iniziale è un rimando ingannevole, che i motori riconoscono e trattano come tale. Reindirizzare è un atto di corrispondenza, non un modo per far sparire gli errori dai rapporti.

Un secondo criterio riguarda i contenuti doppi. Ripulendo l'archivio abbiamo trovato pagine sopravvissute in due versioni sullo stesso argomento: la vecchia, generica, e quella riscritta. Due indirizzi che competono sulla stessa ricerca si tolgono forza a vicenda. Le abbiamo consolidate, mandando la versione superata su quella buona: l'autorevolezza si somma invece di dividersi.

L'identità visiva: il cervello di Hector in home page

Un'azienda che costruisce intelligenza artificiale non può avere un sito che somiglia a quello di chiunque altro. Da qui la scelta che più caratterizza il portale: l'animazione del cervello di Hector, che pulsa nella prima schermata della home page.

Non è una decorazione presa da una libreria. È un motore grafico scritto su misura — circa 900 righe che disegnano su tela digitale una rete di neuroni e fibre, con impulsi che la percorrono e un indicatore di stato che segnala il sistema attivo. La palette è quella del marchio, e il movimento è lento e continuo: deve leggersi come qualcosa che pensa, non come un'animazione che si ripete.

Il motivo dell'integrazione è preciso. Hector non è un servizio comprato e rivenduto: è il nostro ecosistema, e la home page doveva dirlo prima di qualunque testo. Un visitatore capisce in due secondi che qui l'intelligenza artificiale non è una voce di listino ma un prodotto — e la stessa entità che vede pulsare è quella con cui può parlare, aprendo la chat qualche riga più sotto.

Sette versioni prima di quella giusta

La parte istruttiva è come ci siamo arrivati, perché è il tipo di lavoro che di solito nessuno racconta.

Un'animazione continua compete con il browser proprio nella finestra in cui la pagina deve diventare utilizzabile. Le prime versioni funzionavano benissimo su una macchina da lavoro e peggioravano in modo netto i parametri di reattività sul profilo mobile rallentato con cui Google valuta i siti. Abbiamo cambiato approccio sette volte, e ogni volta abbiamo rimisurato invece di fidarci dell'impressione:

• avviarla subito costava troppo alla reattività iniziale;
• rimandarla a fine caricamento la faceva comparire quattro secondi dopo il testo, con un effetto "appiccicato" peggiore del problema;
• riempire l'attesa con un segnaposto grafico risolveva l'estetica ma aggiungeva un elemento inutile sugli schermi piccoli.

La soluzione è arrivata da una misura, non da un'idea: il costo riguardava soltanto il ramo mobile, ed era proprio il contesto in cui l'animazione si vedeva peggio — centinaia di punti compressi in poca larghezza. Su schermi piccoli lo script quindi non viene nemmeno richiesto: niente rete, niente elaborazione, nessun costo per tutta la vita della pagina. Su desktop parte subito, con una dissolvenza d'ingresso di poco più di due secondi che la fa emergere invece di accenderla di colpo.

Tre dettagli finali, che sono quelli che fanno la differenza fra un effetto e un lavoro fatto bene:

1. Non sposta nulla. L'elemento vive fuori dal flusso del documento, quindi comparire non fa saltare il testo — uno dei parametri che Google misura esplicitamente.
2. Rispetta chi chiede meno movimento. Se il dispositivo dichiara quella preferenza di sistema, l'animazione si adegua.
3. Il disegno è stato spostato fuori dal thread principale dove il browser lo consente, così l'interfaccia resta reattiva mentre la rete neurale continua a pulsare.

È un singolo elemento decorativo. Gli abbiamo dedicato lo stesso metodo che dedichiamo a un firewall: ipotesi, misura, verifica.

Esperienza d'uso e mobile

Il sito è stato disegnato partendo dal telefono, non adattandolo dopo. Menu raggiungibili con il pollice, azioni di contatto sempre a portata, contenuti che si riorganizzano invece di rimpicciolirsi, contrasti verificati sui criteri di accessibilità.

Un dettaglio che raccontiamo perché ha richiesto più discussione del previsto: le animazioni. Sono state tenute — perché un sito completamente statico comunica trascuratezza — ma rispettano la preferenza di sistema di chi chiede meno movimento. Chi ha attivato quella impostazione sul proprio dispositivo vede il sito fermo. È una riga di codice e nessuno la nota, ed è esattamente il tipo di attenzione che distingue un lavoro fatto bene.

Hector: la chat AI del sito e le sue API

Sul sito è attiva la chat di Hector, il nostro assistente conversazionale. Non è un widget comprato e incollato: è un componente del nostro ecosistema Hector, collegato alla piattaforma attraverso API dedicate.

La differenza pratica rispetto a un chatbot generico sta in tre punti.

Conosce i nostri contenuti. Ogni pagina e ogni articolo hanno accanto, nel database, una loro rappresentazione numerica del significato — un vettore. Quando arriva una domanda, il sistema cerca i contenuti più vicini per senso, non per parola, e li mette davanti al modello. Non è un modello che improvvisa su ciò che ricorda: è un modello a cui vengono consegnati i documenti pertinenti, presi dal sito.

Passa la mano quando serve. Una conversazione può essere presa in carico da una persona del nostro team, con continuità. L'assistente automatico gestisce le domande frequenti, il tecnico interviene dove serve competenza vera.

I dati restano nostri. Le conversazioni vivono sulla nostra infrastruttura, dentro il perimetro descritto sopra. È il motivo per cui abbiamo costruito Hector invece di adottare un servizio esterno: per un'azienda che si occupa di sicurezza informatica, mandare le conversazioni dei propri clienti su una piattaforma di terzi sarebbe una contraddizione.

I problemi che abbiamo incontrato, e come li abbiamo risolti

Un caso di studio senza problemi è una brochure. Ecco i quattro più istruttivi.

Il certificato prima del DNS, non dopo. Il vecchio sito aveva attiva una direttiva che impone ai browser di usare esclusivamente la connessione cifrata, con memoria di sei mesi. Conseguenza: nell'istante in cui il nome di dominio ha iniziato a puntare al nuovo server, chi aveva visitato il sito prima non poteva raggiungerlo in chiaro nemmeno per un istante — e il certificato sul nuovo server non c'era ancora. La lezione, ora scritta nella nostra procedura: con quella direttiva attiva, il certificato si emette prima dello spostamento, mai dopo.

Errore del server invece di "pagina non trovata". Alcuni indirizzi di sondaggio — file di configurazione, sitemap di sistemi non più installati — producevano un errore interno anziché un onesto "non esiste". Per un motore di ricerca la differenza è sostanziale: l'errore significa "riprova", il "non trovata" significa "toglilo dalla coda". Individuata la causa, corretta, verificata sui casi reali presi dai log.

Cache che nasconde il lavoro fatto. Più volte una modifica sembrava non aver avuto effetto, e la spiegazione era sempre la stessa: la copia in cache non era ancora scaduta. Ci è costato tempo di analisi su codice che funzionava già. Da qui la scelta di documentare per ogni livello quanto dura e come si azzera.

Il rilascio che fermava il sito. Ricostruire l'applicazione sovrascrivendo la cartella usata dal processo attivo lasciava il sito inutilizzabile per la durata dell'operazione. Ora la nuova versione si costruisce accanto a quella in esercizio e le due si scambiano solo a costruzione riuscita: il fermo è passato da qualche minuto a meno di un secondo, e un rilascio fallito non tocca più nulla. Su questo aspetto, misurato con una sonda esterna durante l'intera operazione, il 98% dei campioni non ha visto alcuna interruzione.

Chi ha fatto cosa

Un progetto così non è il lavoro di un reparto: è il lavoro di persone che si parlano.

La progettazione IT e la creazione dell'infrastruttura portano la firma di Marco Ursoleo, CEO di TN Solutions. È sua la scelta architetturale di fondo — tenere tutto in casa, su tecnologie open, con il perimetro di rete disegnato prima dell'applicazione e non dopo — ed è suo il disegno degli strati che avete visto nel primo schema: dove passa il traffico, cosa lo filtra, quale componente può parlare con quale altro. La stessa mano ha guidato l'integrazione di Hector nella piattaforma: far dialogare l'ecosistema AI con il sito attraverso API dedicate, tenendo dati e conversazioni dentro la nostra infrastruttura, è stata una decisione di architettura prima ancora che di prodotto.

Non è una competenza nata per questo progetto. È la stessa che da oltre venticinque anni viene applicata sulle infrastrutture dei clienti: qui è stata rivolta verso l'interno, e il sito ne è il risultato visibile.

Attorno a quella progettazione ha lavorato il team tecnico ed editoriale: chi ha costruito il CMS e le sue interfacce, chi ha curato il design e l'accessibilità, chi ha riscritto e tradotto i contenuti, chi ha censito vent'anni di indirizzi storici uno per uno. Quest'ultima parte, in particolare, è lavoro paziente e senza gloria — mille e ottantaquattro regole non si scrivono in un pomeriggio — ed è la ragione per cui il patrimonio di posizionamento costruito negli anni è arrivato intatto dall'altra parte.

Il risultato non è di nessuno in particolare, ed è esattamente questo il punto: un'infrastruttura ben progettata, un prodotto AI proprietario e un lavoro editoriale rigoroso, tenuti insieme dalle stesse persone che rispondono al telefono quando un cliente chiama.

I numeri del progetto

Elemento	Valore
Articoli pubblicati	401, in due lingue
Pagine di servizio e istituzionali	162
Indirizzi dichiarati nelle sitemap	1.109, su sei file tematici
Regole di normalizzazione degli indirizzi	1.084
Riduzione del peso delle pagine	−19% a contenuto identico
Fermo durante un rilascio	da alcuni minuti a meno di un secondo

Ti è piaciuto questo percorso?

Se sei arrivato fin qui, probabilmente hai riconosciuto qualcosa della tua situazione: un sito che è cresciuto per stratificazioni, un CMS che chiede più manutenzione di quanta ne restituisca, un archivio di contenuti che vale e che nessuno osa toccare per paura di perdere posizioni.

Quello che abbiamo fatto per noi possiamo farlo per la tua azienda. Non necessariamente tutto, e non necessariamente subito: si può partire dalla parte che pesa di più — la messa in sicurezza dell'infrastruttura, il recupero degli indirizzi storici, le prestazioni, oppure la piattaforma editoriale completa.

Quello che portiamo non è un modello preconfezionato. È il metodo che hai appena letto: capire prima, misurare durante, verificare dopo. E la responsabilità di ogni strato, dal firewall alla pagina che il visitatore vede, in capo a un unico interlocutore.

Parliamo del tuo progetto — la prima consulenza è gratuita, e da questa pagina puoi anche aprire la chat di Hector e farci subito la prima domanda.