WordPress o sito su misura: quale conviene davvero?

Quando si chiede un preventivo per un sito, prima o poi arriva la domanda: WordPress o sito su misura? Per chi non lavora nel digitale può sembrare una scelta tecnica da delegare del tutto, e in parte lo è. Dietro però ci sono conseguenze molto pratiche: quanto sarà facile aggiornare il sito, quanto costerà aggiungere una funzione, quanto dipenderai da plugin o fornitori esterni, quanto sarà semplice far crescere il progetto fra due o tre anni.

La buona notizia è che per scegliere bene non serve capire il codice: basta partire da quello che il sito deve fare. WordPress non è automaticamente la scelta economica, un sito su misura non è automaticamente la migliore, e una piattaforma pronta non è automaticamente poco professionale.

Nella nostra realizzazione di siti web lavoriamo con WordPress, Next.js, React, Shopify e WooCommerce, perché risolvono problemi diversi. La scelta dipende da obiettivi, autonomia, complessità, integrazioni e ciclo di vita del progetto, non dalla moda del momento.

WordPress o sito su misura: cosa sono davvero

WordPress è un sistema di gestione dei contenuti: un pannello da cui modificare pagine, articoli, immagini e altre informazioni senza intervenire ogni volta sul codice. A chi compra il sito non serve conoscere PHP, database o temi. Serve sapere che WordPress offre un ecosistema enorme di strumenti già esistenti e una gestione editoriale che moltissime persone conoscono.

Può però essere usato in modi molto diversi. Un sito costruito con un tema comprato e decine di plugin è WordPress; un sito con design originale, tema sviluppato apposta, campi editoriali su misura e pochi plugin selezionati è sempre WordPress. Sono due prodotti diversi, e dire «è fatto in WordPress» non basta a capire qualità, prezzo o prestazioni.

«Su misura», a sua volta, non significa che ogni riga venga inventata da zero. Significa che struttura, interfaccia e funzioni vengono progettate attorno al problema, invece di partire dai limiti di un tema o di una piattaforma. Nel nostro lavoro può voler dire Next.js e React, ma al cliente il nome interessa relativamente. La differenza pratica è che una dashboard particolare, un configuratore, un flusso di prenotazione proprietario, un'area riservata o un'interazione molto specifica si costruiscono attorno alla funzione, senza cercare un plugin che faccia «quasi» la stessa cosa.

Wonder Creators è un esempio semplice. Il sito doveva dimostrare il mestiere di uno studio creativo attraverso layout, interazioni e un portfolio costruito nel formato dei contenuti social. Lì il progetto custom dava libertà reale perché il sito doveva comportarsi in un modo che faceva parte del posizionamento dell'azienda, non perché Next.js sia migliore in assoluto.

Quando conviene WordPress per un sito aziendale

WordPress funziona bene quando il sito ha una struttura editoriale chiara: un sito aziendale, uno studio professionale, una struttura sanitaria, un magazine o un blog, servizi locali, cataloghi relativamente semplici, siti che il cliente aggiorna spesso. Se l'azienda pubblica articoli, modifica servizi, aggiorna specialisti o carica contenuti in autonomia, un pannello editoriale familiare è un vantaggio enorme. In sintesi, WordPress è spesso la scelta forte quando:

• il progetto è principalmente editoriale;
• chi gestisce il sito deve aggiornare molti contenuti;
• le funzioni richieste sono mature e standard, coperte da plugin affidabili;
• il budget non giustifica software proprietario;
• serve un ecosistema facile da trasferire ad altri fornitori.

Medica Palau usa WordPress. Il progetto gestisce tredici specializzazioni, contenuti in otto lingue e prenotazione per prestazione e specialista, e non sarebbe diventato «più professionale» riscritto con un framework diverso: la piattaforma funziona perché è coerente con ciò che la struttura deve gestire. La domanda da fare non è quale sia la tecnologia più moderna, ma quale crei meno attrito per quel progetto. WordPress non è una soluzione di serie B; è uno strumento.

Dove WordPress comincia a stare stretto

Il limite arriva quando, per ottenere il comportamento desiderato, bisogna sovrapporre troppi strumenti: un plugin per il booking, uno per i campi personalizzati, uno per l'area riservata, uno per sincronizzare il gestionale, uno per l'automazione e uno per correggere le prestazioni degli altri. Più del numero, pesa la dipendenza. Ogni componente ha un autore, aggiornamenti, compatibilità e regole proprie, e se una funzione centrale del business nasce collegando cinque plugin che non sono fatti per lavorare insieme, il risparmio iniziale si trasforma in manutenzione.

Questo non fa dei plugin il male, come certe discussioni online lasciano intendere. Un plugin valido risolve in modo affidabile un problema complesso che sarebbe inutile riscrivere: pagamenti, SEO, form, sicurezza ed e-commerce hanno strumenti maturi proprio perché migliaia di siti hanno esigenze simili. Il guaio è usarli come risposta a ogni richiesta, finché una funzione semplice richiede tre estensioni o il progetto dipende da plugin abbandonati o sovrapposti. Il criterio è una domanda: questa dipendenza ci fa risparmiare complessità, o la sta solo nascondendo?

Quando il sito è quasi un software

C'è un punto in cui chiamarlo «sito» diventa riduttivo: account utenti, dashboard, pagamenti ricorrenti, gestione degli ordini, CRM, automazioni, ruoli differenti, dati aggiornati in tempo reale, console multi-sede. A quel punto si parla anche di prodotto digitale, e spingersi sul custom ha senso quando:

• l'esperienza digitale è parte del prodotto;
• ci sono integrazioni specifiche;
• servono account, ruoli o dashboard;
• il sito deve comportarsi in modo molto particolare;
• le funzioni proprietarie sono un vantaggio competitivo;
• adattarsi a una piattaforma costerebbe più che costruire la funzione.

hoopit riunisce otto moduli: menu QR, prenotazioni, asporto, automazioni WhatsApp, CRM, inventario, analytics e gestione multi-sede. Trattarlo come una normale installazione di sito vorrebbe dire partire dalla domanda sbagliata: qui servono logiche, dati e interfacce progettate, cioè il territorio dello sviluppo di app e prodotti digitali. Un esempio ancora più netto è AVOY, con proprietà, esperienze, attività, mappe, channel manager, Guest Portal e concierge AI: più che una brochure con molte pagine, è una piattaforma.

Tra i due estremi ci sono molte strade

C'è però l'equivoco opposto: «custom» non vuol dire progetto da multinazionale. Anche un sito relativamente piccolo può beneficiare di un design su misura se identità, posizionamento o percorso utente sono molto specifici, a patto di non confondere il design su misura con un'intera piattaforma software custom. Chi si chiede se fare un sito WordPress o un sito personalizzato immagina spesso due scatole separate, mentre le combinazioni sono molte:

• WordPress con design sviluppato su misura;
• Shopify con tema personalizzato;
• frontend custom collegato a un CMS;
• sito completamente custom;
• piattaforma pronta quasi senza personalizzazioni.

Molti progetti sono ibridi: un CMS gestisce i contenuti, un frontend personalizzato li presenta, un servizio esterno gestisce i pagamenti, un altro la newsletter, un booking engine le disponibilità. Non serve costruire tutto, e non serve nemmeno accettare tutto ciò che offre una piattaforma. Progettare vuol dire anche decidere cosa comprare, cosa integrare e cosa costruire.

E-commerce e booking hanno logiche proprie

Se il progetto vende online, la domanda si allarga. WooCommerce permette di costruire l'e-commerce dentro WordPress, Shopify offre un ecosistema gestito e toglie molta manutenzione tecnica, un e-commerce custom ha senso quando checkout, catalogo, integrazioni o modello di business seguono logiche fuori standard. La scelta dipende da catalogo, mercati, spedizioni, pagamenti, gestione interna, integrazioni e crescita prevista, non dal logo della piattaforma che piace di più. Nella pagina sull'e-commerce trattiamo il progetto come un sistema: vendita, catalogo, pagamenti e operatività dopo l'ordine.

Nel turismo la risposta è spesso ibrida. Il sito può essere gestito con un CMS relativamente standard e affidare la prenotazione a un booking engine specializzato; oppure il frontend è personalizzato e dialoga con sistemi esterni; oppure, se il prodotto lo richiede, booking e gestione si costruiscono direttamente.

Per Punta Falcone Resort la cosa importante non è la tecnologia raccontata al cliente: è che due strutture stiano sotto lo stesso brand e che la prenotazione diretta sia centrale. È lo stesso principio che seguiamo nel lavoro per hotel e resort e per il turismo in Sardegna.

Chi aggiornerà il sito dopo il lancio?

Questa domanda cambia parecchio la scelta, quindi conviene rispondere subito. Se ogni settimana vanno aggiunti articoli, persone, prodotti, offerte o eventi, l'esperienza editoriale conta molto, e WordPress è forte proprio qui. Anche un sito custom può avere un CMS semplice, progettato sui contenuti dell'azienda; la differenza è il costo di costruirlo e mantenerlo. Per un'azienda con tre pagine che cambiano due volte l'anno può non avere senso un sistema editoriale sofisticato, per una redazione o una struttura con aggiornamenti quotidiani è l'opposto.

C'è poi il costo delle persone che gestiranno il sito. Se per pubblicare una pagina servono ogni volta due ore di un developer, quel tempo è un costo operativo, e una piattaforma più cara all'inizio che permette al team di lavorare in autonomia può costare meno nel tempo. Vale anche il contrario: se l'azienda aggiorna il sito due volte l'anno, un pannello editoriale sofisticato può essere un investimento senza ritorno.

Conta anche la formazione. WordPress lo conoscono moltissime persone, quindi è facile trovare chi sappia usarlo; un CMS custom può essere più semplice proprio perché mostra solo i campi necessari, ma richiede una breve formazione specifica. Una redazione che pubblica ogni giorno, un resort che aggiorna camere e offerte stagionali e un SaaS che gestisce dati in tempo reale hanno esigenze diverse, e nessuna risposta vale per tutti.

Velocità, SEO e sicurezza non dipendono dal nome

Un sito WordPress può essere molto veloce, uno in React molto lento, uno su Shopify può avere ottime prestazioni o essere appesantito da script di marketing. La velocità dipende dalla qualità dello sviluppo, dall'hosting, da immagini e font, dalla quantità di JavaScript, da plugin, script di terze parti, tracking, animazioni e struttura delle pagine. Scegliere Next.js non assegna automaticamente un punteggio alto su PageSpeed, e scegliere WordPress non condanna il sito. Per questo misuriamo le prestazioni durante il progetto e non dopo, con il metodo che descriviamo nella guida al test di velocità del sito.

Per la SEO vale lo stesso: conta ciò che il motore di ricerca riesce a leggere e comprendere, cioè HTML disponibile, URL, title, contenuti, link interni, dati strutturati, prestazioni, canonical e sitemap. Un WordPress configurato bene può produrre tutto questo, come un sito custom o una piattaforma pronta; cambia quanto controllo hai sul risultato e quanta fatica serve per mantenerlo. Nel nostro lavoro di SEO il framework è una parte del sistema, non la strategia.

Sulla sicurezza, dire «WordPress è insicuro» aiuta poco. Viene attaccato spesso anche perché è diffusissimo, ma un sito aggiornato, con plugin selezionati, accessi protetti, backup e hosting corretto è un'altra cosa rispetto a un sito dimenticato per quattro anni, con estensioni abbandonate e password condivise. Un progetto custom riduce alcune superfici e ne crea altre, e se gestisce account, dati, pagamenti o API la sicurezza pesa ancora di più.

Anche il custom ha dipendenze: librerie, framework, hosting, API, database e pacchetti che vengono aggiornati e richiedono manutenzione. Il suo vantaggio è controllare meglio quali dipendenze esistono e come sono organizzate attorno al prodotto, non eliminarle, ed è per questo che non venderemmo mai un sito custom «senza manutenzione». La domanda utile è chi lo mantiene, e con quale processo.

Prima di firmare: proprietà e domande al fornitore

Ci sono siti tecnicamente ottimi che diventano un problema il giorno in cui il cliente vuole cambiare fornitore: dominio intestato all'agenzia, hosting senza accesso, plugin acquistati su account di terzi, repository non consegnato, analytics non di proprietà del cliente. Non dipende da WordPress o dal custom, dipende dal contratto e dal metodo. Alla consegna dovresti sapere chi possiede:

• dominio e hosting;
• codice e database;
• account Google;
• licenze;
• fotografie e contenuti;
• credenziali.

Per noi è una regola semplice: il progetto deve poter continuare a esistere anche se domani cambia il fornitore. Quando confronti due preventivi, quindi, non chiedere solo «con cosa lo fate?». Chiedi perché hanno scelto quella soluzione, cosa potrai modificare da solo e cosa richiederà il loro intervento, quali costi ricorrenti ci sono, cosa succede se vuoi cambiare fornitore, come si aggiungono una lingua o un servizio esterno, come vengono gestiti aggiornamenti e sicurezza. Una risposta chiara vale più di un elenco di tecnologie, e se la motivazione non è comprensibile a chi gestisce l'azienda, probabilmente la decisione non è ancora stata tradotta in un beneficio reale.

Poco budget o poco tempo: riduci il perimetro

Quando il budget è limitato si tende a chiedere qual è la tecnologia più economica. La domanda più utile è cosa si può togliere dalla prima versione: una lingua, un'area riservata, un'integrazione non essenziale, una sezione che può arrivare dopo. Questo riduce davvero il lavoro, mentre forzare un progetto complesso dentro uno strumento inadatto per risparmiare all'inizio può aumentare il costo dopo. Prezzo e tecnologia hanno senso solo dentro un perimetro, come spieghiamo nella guida su quanto costa un sito web.

Lo stesso vale per i tempi: con poche settimane a disposizione, WordPress non è la scelta automatica. Una piattaforma pronta accelera molto se ciò che serve è già disponibile, ma un WordPress pieno di personalizzazioni può richiedere più tempo di un piccolo frontend custom, e un sito su misura può essere rapido se la struttura è semplice e il team ha già un sistema di componenti affidabile. In quanto tempo ci vuole per fare un sito web spieghiamo perché contenuti, decisioni e integrazioni pesano spesso più del framework.

Cinque domande per scegliere senza capire il codice

Se non hai mai commissionato un sito, puoi arrivare alla scelta rispondendo a queste cinque domande:

• Quanto spesso cambieranno i contenuti? Se il sito viene aggiornato di continuo, la gestione editoriale conta molto.
• Le funzioni sono standard o specifiche? Form e blog sono standard; una dashboard con logiche aziendali potrebbe non esserlo.
• Il sito deve collegarsi ad altri software? CRM, gestionale, booking, pagamenti, cataloghi, API.
• Quanto deve crescere nei prossimi anni? Aggiungere cinque articoli è diverso dall'aggiungere un marketplace.
• Chi lo manterrà? Team interno, agenzia, freelance, nessuno.

Con queste risposte un professionista dovrebbe riuscire a spiegarti la tecnologia senza rifugiarsi nei tecnicismi. Aiuta anche chiedere quanto del progetto è standard e quanto è davvero specifico. Se il novanta per cento del bisogno è già risolto bene da una piattaforma esistente, riscrivere tutto non è automaticamente un vantaggio; se proprio quel dieci per cento specifico è il cuore del business, può essere la parte che giustifica un progetto su misura.

Quanto costa cambiare idea fra un anno

Un sito non si usa solo il giorno del lancio: deve sopportare nuovi servizi, nuove campagne, nuove persone nel team e magari un nuovo mercato. Se oggi scegli una piattaforma che risolve perfettamente il progetto ma fra dodici mesi rende impossibile aggiungere la funzione più importante, il risparmio iniziale perde valore. D'altra parte non ha senso costruire una piattaforma enorme per funzioni che forse non arriveranno mai. Serve una previsione ragionevole, che guardi ai cambiamenti già nel piano aziendale: nuove funzioni probabili, più persone a gestire il sito, un catalogo che cresce, nuove lingue, nuove sedi o punti vendita, un gestionale da collegare.

Un test che usiamo spesso è immaginare la modifica più probabile fra dodici mesi. Se per farla bisogna aggirare la piattaforma, duplicare dati o sostituire metà del sistema, la scelta iniziale era troppo rigida: è lo stesso segnale che descriviamo in quando rifare un sito web, quando le nuove funzioni non entrano più nella vecchia struttura. Se invece il sito assorbe quella modifica senza cambiare natura, la base è coerente. Vale anche per i piccoli progetti: un professionista può partire con cinque pagine e sapere già che aprirà una seconda sede, un hotel che l'anno dopo aggiungerà una struttura, un e-commerce che entrerà in un secondo mercato.

Conta anche la durata prevista. Se stai validando una nuova idea, può essere più intelligente partire con uno strumento pronto, andare online presto e capire se il mercato risponde; se il prodotto è già validato e la piattaforma digitale è il centro del business, investire in un'architettura più specifica ha molto più senso. Non serve costruire oggi tutto ciò che servirà domani, ma conviene evitare una scelta che renda domani inutilmente costoso.

Quindi: WordPress o sito su misura?

Se il tuo sito deve raccontare bene un'azienda, farsi aggiornare facilmente e usare funzioni standard, WordPress può essere una soluzione eccellente. Se deve diventare una parte specifica del prodotto, automatizzare processi o fare qualcosa che le piattaforme standard gestiscono male, un progetto più personalizzato può essere la scelta corretta. In mezzo ci sono molte strade, e la tecnologia non va usata come status symbol: un sito non è migliore perché nel footer non compare WordPress, ma perché è più semplice da usare, più facile da mantenere e più adatto a ciò che l'azienda deve fare.

L'obiettivo è non pagare complessità che non serve, senza costringere il business dentro uno strumento troppo stretto. Se stai ancora definendo il progetto, raccontaci cosa deve fare davvero il sito: la tecnologia viene dopo.