Scelta agenzia

Il sito è davvero tuo? 5 controlli per non restare ostaggio di chi te l'ha fatto

5 verifiche concrete per sapere se il tuo sito web è davvero di tua proprietà: dominio, hosting, codice, account analytics, design files.

Stefano Prandi — 2026-05-29

C'è un fenomeno tutto italiano, talmente diffuso da meritarsi un nome proprio: il sito ostaggio. Funziona così. Un'azienda paga un sito, lo usa per anni, lo considera suo. Poi un giorno vuole cambiare web designer — magari per costi, magari per qualità, magari perché il vecchio non risponde più alle mail. E scopre che il dominio è intestato al fornitore, l'hosting è sul suo account, il codice non c'è da nessuna parte, gli account Google sono tutti sotto il suo indirizzo personale.

Risultato: o resti dove sei, o ricominci da zero. Si chiama lock-in, ed è uno dei motivi per cui in Italia si vedono ancora così tanti siti vecchi di dieci anni — non perché funzionino bene, ma perché cambiarli costa il doppio.

In questo articolo ti do cinque controlli concreti per capire se il tuo sito è davvero tuo. Spoiler: probabilmente almeno uno dei cinque ti farà saltare sulla sedia. Va bene, è il momento giusto per scoprirlo.

Controllo 1: Dominio — chi risulta intestatario?

Il dominio è la cosa più importante. Se perdi quello, perdi la mail, perdi il traffico, perdi i posizionamenti su Google. Il sito si può rifare in due settimane; un dominio attivo da otto anni, no.

Cosa fare in 3 minuti:

Vai su whois.com e cerca il tuo dominio.
Guarda la sezione "Registrant" o "Registrante".
Verifica chi è il proprietario.

Devono comparire i tuoi dati (nome, indirizzo, azienda, partita IVA per i domini .it). Se invece vedi il nome del tuo web designer, della sua società o di un'agenzia terza, il dominio non è tuo. Punto.

Attenzione anche al campo "Admin Contact" e "Tech Contact": possono essere del fornitore (è normale per la gestione tecnica), ma il Registrant deve essere tu. Se trovi scritto "WhoisGuard", "Privacy Protected" o "Domain Privacy Service", il dominio è schermato — non significa che non sia tuo, ma significa che senza l'accesso al pannello del registrar non puoi dimostrarlo.

Se non sei tu intestatario: chiedi formalmente, per iscritto, il trasferimento del dominio a un tuo account presso il registrar che preferisci (Aruba, Register.it, Cloudflare Registrar, ecc.). Serve il codice EPP/AUTH e lo sblocco del dominio. È un diritto del registrante, ma in pratica solo il registrante può autorizzarlo — quindi se non sei tu, dipendi dalla buona volontà del fornitore.

Controllo 2: Hosting — il piano è in nome tuo?

L'hosting è la macchina su cui gira il sito. Se l'account è del web designer, ogni mese il tuo sito vive grazie alla sua carta di credito. Se domani litigate, lui può semplicemente smettere di pagare. Quindici giorni dopo il sito è offline.

Cosa controllare:

Accedi al pannello dell'hosting (Plesk, cPanel, dashboard cloud).
Verifica l'intestatario della fattura: deve essere la tua azienda.
Verifica il metodo di pagamento: dovrebbe essere tuo (carta aziendale, bonifico SEPA dal tuo conto, addebito su PayPal aziendale).
Verifica gli utenti con accesso amministrativo.

Esiste una configurazione comune e perfettamente legittima: il web designer ha un suo hosting "reseller" e ti vende uno spazio dentro. Va bene, ma a una condizione — deve essere chiaro nel contratto che puoi richiedere il trasferimento del sito su un hosting tuo in qualsiasi momento, con un preavviso ragionevole (15-30 giorni) e senza penali.

Bandiera rossa: se paghi un canone annuale "tutto compreso" e nessuno ti ha mai mostrato la fattura dell'hosting, probabilmente non hai un account intestato a te. Stai pagando un servizio gestito, non un hosting tuo.

Controllo 3: Codice sorgente — esiste una copia accessibile?

Qui le cose si fanno serie. Il codice del sito — il tema WordPress custom, il bundle React, le configurazioni del CMS — può esistere in tre stati:

Sul server e basta. Pessimo. Se il server crasha o l'hosting viene chiuso, sparisce tutto.
Sul server + repository Git privato del designer. Meglio per lui, peggio per te. Lui può ricostruire, tu no.
Sul server + repository Git accessibile a te + backup .zip periodici. Configurazione corretta.

Cosa chiedere oggi al tuo fornitore:

Un .zip aggiornato dell'intera installazione (file + database SQL export).
L'accesso in lettura al repository Git, se esiste (GitHub, GitLab, Bitbucket).
La documentazione di build: come si compila, quali sono le dipendenze, dove sono le variabili d'ambiente.

Sul piano legale c'è poi la questione del copyright. In Italia il codice sorgente è opera dell'ingegno tutelata dalla L. 633/1941 (artt. 64-bis e seguenti). In assenza di contratto specifico, l'autore resta titolare dei diritti patrimoniali e ti concede una licenza d'uso. Per essere davvero proprietario del codice serve una clausola di cessione dei diritti patrimoniali d'autore, scritta nera su bianco. Senza, puoi usare il sito ma tecnicamente non puoi farlo modificare da un altro professionista senza autorizzazione.

In pratica: chiedi sempre, in fase di contratto, la cessione esplicita del codice realizzato su misura per te.

Controllo 4: Google Analytics, Search Console, Tag Manager

Questi tre account valgono come l'oro per due ragioni: contengono anni di dati storici, e sono lo strumento con cui Google capisce che il sito è tuo (Search Console certifica la proprietà).

Verifiche concrete:

Google Analytics 4 → Amministrazione → Gestione utenti dell'account

Il tuo account Google (idealmente aziendale, non Gmail personale) deve avere ruolo Amministratore.
Se hai solo "Editor" o "Analista", puoi vedere i dati ma non gestire utenti — quindi non puoi rimuovere il web designer dopo aver chiuso il rapporto.

Google Search Console → Impostazioni → Utenti e autorizzazioni

Devi essere Proprietario verificato (non "Proprietario delegato").
Il modo di verifica deve essere uno che controlli tu: meta tag nel sito va bene solo se il sito è tuo, meglio il record DNS sul dominio (che presuppone — di nuovo — che il dominio sia tuo).

Google Tag Manager → Amministrazione → Utenti del Container

Ruolo Amministratore sul container.
Ruolo Amministratore sull'account che contiene il container.

Cosa fare se gli account sono del designer: chiedere il trasferimento della proprietà a un account a te intestato. È un'operazione tecnica di 5 minuti, va concessa. Se viene rifiutata, è una bandiera rossa molto grossa.

GDPR bonus: se il designer ha accesso ai dati degli utenti del tuo sito (newsletter, form contatti, ecommerce), deve essere nominato Responsabile del trattamento ex art. 28 GDPR, con contratto scritto. In sua assenza, sei tu Titolare a essere esposto alle sanzioni.

Controllo 5: Design files — Figma, font, asset

L'ultima cosa che la gente controlla, ma quella che ti fa bestemmiare di più quando manca. I file sorgente del design — quelli aperti in Figma, Sketch, Adobe XD, Illustrator — contengono:

Le icone vettoriali originali (non i PNG renderizzati).
I componenti e le librerie di stile.
I font con le rispettive licenze.
Le mockup di pagine che non sono finite nel sito ma che potrebbero servire dopo.

Cosa chiedere:

File .fig (Figma), .sketch, .xd, .psd, .ai consegnati come archivio scaricabile o duplicato sul tuo account Figma/Adobe.
Elenco font usati con la dicitura della licenza (Google Fonts open source? Adobe Fonts a pagamento? Font con licenza desktop e non web?).
Asset originali (foto custom, illustrazioni vettoriali): cessione esplicita o licenza d'uso documentata.

Sulle immagini attenzione doppia: se il designer ha usato stock photo, deve averle acquistate con una licenza estesa che permetta l'uso commerciale per il tuo brand. Le licenze "Personal" o "Editorial Only" su Unsplash+ o Shutterstock non valgono per un sito commerciale, e la fattura del designer non ti copre — sei tu come pubblicatore a essere responsabile.

Cosa fare se scopri di NON averli — tre mosse

Hai fatto i cinque controlli e i risultati non sono confortanti. Niente panico, ma niente neanche tempo da perdere.

Mossa 1 — Richiesta formale per iscritto. Una PEC (o raccomandata) al tuo fornitore in cui chiedi: trasferimento dominio entro X giorni, copia integrale del codice e del database, trasferimento titolarità account Google a un tuo indirizzo. Sii civile ma chiaro. Spesso basta questo.

Mossa 2 — Se non risponde, scrivi al registrar. Per il dominio puoi rivolgerti direttamente al registrar e — se sei in grado di dimostrare di essere il committente che ha pagato la registrazione (fatture, bonifici, scambi mail) — aprire una controversia. Per i .it esiste la procedura di riassegnazione presso il NIC. Per gli altri TLD vale l'UDRP/URS dell'ICANN.

Mossa 3 — In parallelo, comincia a ricostruire. Anche nel caso peggiore, hai sempre un'opzione: rifare. Un sito vetrina ben fatto si rifà in 4-6 settimane su un dominio nuovo (o sul vecchio una volta sbloccato). Costa, ma ti libera per sempre. E questa volta, lo fai bene.

Contratto sano: 5 clausole da inserire all'inizio

Prevenire vale dieci volte curare. Quando firmi con un nuovo professionista, pretendi queste cinque cose:

Intestazione dominio al committente, sempre. Il fornitore è solo Tech Contact.
Cessione dei diritti patrimoniali d'autore sul codice custom realizzato su misura.
Consegna materiali a fine progetto: .zip completo del sito, dump del database, file design sorgente, elenco font con licenze.
Account Google di proprietà del committente dal giorno 1, con il fornitore aggiunto come Amministratore (rimovibile).
Clausola di uscita: tempi e modi per il trasferimento del sito a un altro fornitore o a un hosting di proprietà del committente, senza penali.

Sono cinque righe nel contratto, ma cambiano completamente l'equilibrio di potere.

In sintesi

Se hai un sito attivo da più di due anni, oggi è un buon giorno per fare questi cinque controlli. Il WHOIS del dominio richiede 30 secondi. Verificare gli utenti su Analytics richiede 2 minuti. Aprire una mail al fornitore per chiedere il backup richiede 5 minuti.

Vale la pena ora, perché il giorno in cui ti servirà la verità sulla proprietà del tuo sito sarà esattamente il giorno in cui — per qualche ragione — il rapporto col fornitore si sarà già rotto. E in quel momento sarà tardi.

Se vuoi capire meglio cosa chiedere a un professionista prima di firmare, ho scritto due guide collegate: Cosa chiedere in un preventivo per un sito web e Come scegliere chi ti fa il sito: 10 domande. Letti insieme, ti danno il quadro completo: come scegliere bene all'inizio, cosa pretendere durante il lavoro, e come restare padrone del tuo sito anche dopo.

Hai dubbi sul tuo sito attuale? Puoi scrivermi e ti aiuto a fare i cinque controlli sopra in mezz'ora di videocall — gratuita. Niente vendita di servizi, solo una mano per capire se sei in una situazione sana o se hai un problema da risolvere. Mi trovi su stepdesign.prandi.net o su stimoweb.prandi.net.

FAQ

Come verifico se il dominio è intestato a me?

Fai un WHOIS lookup su whois.com o sul sito del registrar (es. Register.it, Aruba, GoDaddy). Nella sezione 'Registrant' devono comparire i tuoi dati personali o quelli della tua azienda, non il nome del web designer o di una sua società. Se vedi 'privacy protected', chiedi al registrar di confermare l'intestatario reale. In Italia, per i .it, il NIC.it fornisce l'estratto ufficiale dell'assegnatario.

Posso cambiare web designer senza perdere il sito?

Sì, ma solo se possiedi tre cose: dominio intestato a te, accesso all'hosting (o pagamento diretto del piano), copia integrale del codice sorgente. Se manchi anche solo di una, il nuovo professionista dovrà ricostruire pezzi del sito o trattare con il precedente. Per questo i controlli vanno fatti prima di rompere il rapporto, non dopo.

Chi è il titolare degli account Google Analytics e Search Console?

Il titolare deve essere un account Google a te intestato (idealmente un account aziendale). Verifica in Analytics su Amministrazione → Gestione utenti: tu devi avere ruolo 'Amministratore', non 'Editor' o 'Visualizzatore'. In Search Console su Impostazioni → Utenti e autorizzazioni il tuo account deve risultare 'Proprietario', non 'Proprietario delegato'.

Il codice sorgente del mio sito è mio per legge?

Dipende dal contratto. In assenza di clausole esplicite, il copyright del codice resta in capo all'autore (il web designer), che ti concede una licenza d'uso. Per diventare proprietario del codice serve una clausola di cessione dei diritti patrimoniali d'autore (art. 12 e seg. L. 633/1941). Senza quella clausola puoi usare il sito ma non modificarlo né farlo modificare ad altri senza autorizzazione.

Cosa devo chiedere prima di chiudere con un web designer?

Una checklist di transizione: copia .zip del sito completo, export del database, credenziali hosting trasferite a un account intestato a te, dominio sbloccato e codice EPP/AUTH per il trasferimento, esportazione utenti dagli account Analytics/GSC/Tag Manager con tuo account come Proprietario, file sorgenti del design (Figma/Sketch/PSD), elenco font con relative licenze. Tutto per iscritto, prima del saldo finale.

Richiedi un preventivo