# websitedevelopment.biz — testo integrale > Il testo completo di ogni guida in questa lingua, così che un motore di risposta possa leggere il catalogo in una sola richiesta. Nulla di ciò manca dalle pagine visibili. ## Quando rifare il sito web (e quando no) https://websitedevelopment.biz/it/guides/quando-rifare-il-sito-web Aggiornato il 2026-08-07 · Manutenzione I rifacimenti vengono avviati spesso per il motivo sbagliato — il sito sembra datato a chi lo vede ogni giorno — e comportano un rischio reale: una ricostruzione completa azzera i segnali di ricerca accumulati, butta via la conoscenza sulla conversione, e spesso sostituisce un problema noto con uno ignoto. Questa guida copre cosa giustifica davvero un rifacimento, cosa no, e la via incrementale che dà risultati migliori sulla maggior parte dei siti. ### Le ragioni che giustificano un rifacimento Sono problemi strutturali che non si risolvono cambiando pagine, ed è questo a renderli ragioni di rifacimento anziché ragioni di miglioramento. - La piattaforma è a fine vita o non riceve più aggiornamenti di sicurezza. - Il sito non è responsive e non lo si può rendere tale senza ricostruirlo. - La struttura non corrisponde più all'attività: vendi qualcosa che l'architettura dell'informazione non riesce a esprimere. - Modificare è impossibile senza uno sviluppatore, quindi i contenuti sono vecchi per impostazione predefinita. - Le prestazioni sono strutturalmente scarse per come è stato costruito, non per qualche immagine grande. - I difetti di accessibilità stanno nei componenti stessi e non si possono rattoppare. - Una fusione o un cambio di marchio cambia il nome, non solo i colori. Nota cosa non c'è in questo elenco: «sembra datato». Quello di solito è un progetto di restyling, e i restyling costano una frazione e non portano quasi nessuno dei rischi. ### Le ragioni che non lo giustificano Ciascuna ha una soluzione meno costosa e meno rischiosa che affronta il problema vero. | «Sembra datato» | Stile visivo | Restyling: tipografia, colore, spaziature | | «Il traffico sta calando» | Problema di contenuti o tecnico | Diagnosticare prima; un rifacimento di solito peggiora le cose | | «Le conversioni sono basse» | Pagine specifiche o un modulo | Provare modifiche su quelle pagine | | «Un concorrente ha rifatto il sito» | Nulla di misurabile | Non è una ragione | | «Nuova direzione marketing» | Questione di titolarità, non il sito | Rivedere insieme i dati per prima cosa | | «Ha tre anni» | L'età non è un difetto | Correggere ciò che è misurabilmente sbagliato | ### Perché i rifacimenti completi spesso perdono traffico Un rifacimento completo cambia struttura, contenuti, URL e template contemporaneamente. Se le prestazioni calano, non puoi dire quale cambiamento l'abbia causato — e se migliorano, nemmeno. - I cambi di URL perdono i segnali accumulati a meno che ogni reindirizzamento non sia mappato correttamente. - I contenuti riscritti «per essere più concisi» rimuovono spesso proprio il testo che si posizionava. - I nuovi template possono perdere link interni, dati strutturati o metadati che i vecchi avevano. - I cambiamenti di design possono ridurre la conversione in modi che emergono solo settimane dopo. - Tutto cambia insieme, quindi attribuire dopo è tirare a indovinare. Se un rifacimento è davvero necessario, conserva la struttura degli URL e i contenuti che si posizionano ovunque puoi. Cambia l'aspetto e il codice, non gli indirizzi. ### L'alternativa incrementale Per la maggior parte dei siti una serie di modifiche mirate batte una ricostruzione: costa meno, è misurabile, e ogni passo si può annullare. - Misura prima: statistiche, Core Web Vitals, Search Console, e una manciata di sessioni utente. - Correggi prestazioni e accessibilità sui template esistenti. Di solito si ripagano da sole. - Riscrivi le pagine che ricevono traffico ma non convertono, una alla volta. - Fai un restyling: tipografia, colore, spaziature. Questo risolve il «sembra datato» a una frazione del costo. - Sostituisci i singoli template uno alla volta, conservandone gli URL. - Migliora l'esperienza di modifica perché i contenuti smettano di invecchiare. - Rimisura dopo ogni passo, così sai quale cambiamento ha prodotto cosa. Q: Ogni quanto va rifatto un sito web? A: Non esiste un intervallo corretto. Un sito ben mantenuto e migliorato in modo incrementale può funzionare per molti anni senza ricostruzione. L'innesco dovrebbe essere un problema strutturale che non riesci a correggere all'interno della costruzione attuale, non una data sul calendario. I siti rifatti ogni tre anni per prassi di solito perdono terreno ogni volta. Q: Un rifacimento migliorerà la mia SEO? A: Non di per sé, e può facilmente nuocere. Ciò che aiuta è quanto un rifacimento talvolta include: pagine più veloci, struttura migliore, contenuti migliori. Quei miglioramenti si possono fare senza rifacimento, con meno rischio. Se l'obiettivo è il rendimento nella ricerca, diagnostica la causa vera prima di impegnarti in una ricostruzione. Q: Devo conservare i miei URL in un rifacimento? A: Ovunque tu possa. Conservare gli URL elimina il rischio maggiore di una rimessa online. Se devono cambiare — una struttura davvero rotta, o un cambio di dominio — mappa ogni vecchio URL su uno nuovo preciso con un 301 e conserva quei reindirizzamenti a tempo indeterminato. Q: Quanto dura un rifacimento? A: Simile a una costruzione nuova, e spesso di più a causa della migrazione: due-cinque mesi per un sito di media dimensione. Costa raramente meno che ripartire da zero una volta contate migrazione dei contenuti, mappatura degli URL e riproduzione del comportamento esistente, il che sorprende quasi tutti quelli che si aspettano uno sconto perché hanno già un sito. ## Monitoraggio di un sito web: saperlo prima dei tuoi clienti https://websitedevelopment.biz/it/guides/monitoraggio-del-sito-web Aggiornato il 2026-08-07 · Manutenzione Il monitoraggio della disponibilità risponde a una domanda: la home risponde? La maggior parte dei guasti veri è più silenziosa. Il sito è in piedi e il modulo di contatto fallisce da tre settimane, oppure il checkout funziona per tutti tranne che per i clienti che usano un certo metodo di pagamento. Questa guida copre cosa monitorare, come fissare soglie che significhino qualcosa, e come mantenere credibili gli avvisi. ### Oltre al «è in piedi» I guasti che costano denaro sono di solito parziali. Monitora i risultati che ti interessano, non solo la risposta del server. | Disponibilità HTTP | Server giù, guasto DNS | Ogni 1–5 minuti | | Verifica di transazione | Modulo rotto, checkout rotto | Ogni 15–60 minuti | | Tasso di errore | Eccezioni in aumento dopo un rilascio | Continuo | | Scadenza del certificato | La classica interruzione della domenica mattina | Giornaliero, avviso 30 giorni prima | | Scadenza del dominio | La peggiore interruzione possibile | Giornaliero, avviso 60 giorni prima | | Core Web Vitals | Degrado lento che nessuno nota | Settimanale | | Copertura in Search Console | Pagine che escono dall'indice | Settimanale | | Dimensione di disco e database | Crescita silenziosa verso un limite rigido | Giornaliero | | Esito dei backup | Backup che hanno smesso di girare mesi fa | Giornaliero | Una transazione sintetica che invia un modulo vero a un indirizzo di prova è il monitoraggio di maggior valore per quasi ogni sito aziendale. I moduli rotti sono invisibili e costosi. ### Fissare soglie che significhino qualcosa Un monitoraggio che avvisa a ogni sussulto insegna alle persone a ignorarlo, e allora non funziona quando conta. Le soglie dovrebbero riflettere ciò che ti farebbe davvero agire. - Richiedi due o tre fallimenti consecutivi prima di avvisare, da più di una postazione. - Avvisa sul tasso di errore anziché su singoli errori: un solo 500 è rumore, un cambio di tasso è un segnale. - Imposta gli avvisi sulle prestazioni su una tendenza di più giorni, non su una singola misurazione lenta. - Separa le gravità: sito giù va a un telefono; una pagina lenta va in un riepilogo settimanale. - Indirizza gli avvisi a una persona, non a una casella condivisa di cui nessuno risponde. - Rivedi ogni avviso scattato: se non ha richiesto azione, cambia la soglia o cancella il monitoraggio. ### Cosa fare quando scatta un avviso Avere un ordine di operazioni scritto trasforma un incidente da improvvisazione in procedura, il che conta soprattutto quando chi è reperibile non è chi ha costruito il sito. - Conferma che sia reale: carica il sito tu stesso da un'altra rete. - Controlla prima l'ovvio: è stato rilasciato qualcosa, è scaduto un certificato, l'hosting segnala un incidente? - Pubblica un aggiornamento di stato se ci sono clienti coinvolti. Il silenzio è peggio di una cattiva notizia. - Ripristina il servizio prima di diagnosticare. Torna indietro sul rilascio, poi indaga con calma. - Annota cosa è successo, perché, e cosa l'avrebbe individuato prima. - Aggiungi il monitoraggio che l'avrebbe individuato. È così che l'elenco qui sopra cresce nel modo giusto. L'esito più utile di un incidente è un nuovo monitoraggio e un modo in meno perché accada in silenzio. ### Impostazioni sensate per un sito piccolo Non serve una piattaforma di osservabilità. Per quasi ogni sito aziendale questo insieme basta e si configura in un pomeriggio. - Verifica di disponibilità sulla home e su una pagina profonda, ogni cinque minuti, da due postazioni. - Un invio sintetico di modulo al giorno, a un indirizzo che una persona legge. - Avvisi di scadenza di certificato e dominio, con ampio anticipo. - Avvisi sugli errori del server dall'applicazione, con una soglia di tasso. - Un'e-mail settimanale con Core Web Vitals e copertura in Search Console. - Una conferma giornaliera che il backup è girato e che la sua dimensione sembra normale. Q: Ogni quanto controllare la disponibilità? A: Ogni uno-cinque minuti è la norma, da almeno due postazioni geografiche perché un problema di rete su un nodo di monitoraggio non ti svegli alle 3 di notte. Controlli più frequenti raramente cambiano l'esito, perché il tempo per accorgersene è piccolo rispetto al tempo per risolvere. Q: Che disponibilità dovrei aspettarmi? A: Un hosting condiviso decente offre circa il 99,9 %, cioè all'incirca nove ore di indisponibilità all'anno. Le piattaforme gestite e le buone configurazioni cloud arrivano al 99,95 % o meglio. Conta più del numero se l'indisponibilità sono minuti sparsi o una singola lunga interruzione in orario di lavoro. Q: Gli strumenti di monitoraggio gratuiti bastano? A: Per la disponibilità di un sito piccolo in genere sì: i piani gratuiti coprono una manciata di controlli a intervalli di cinque minuti. Ciò che manca di solito ai piani gratuiti sono le transazioni sintetiche e i controlli a più passaggi, cioè proprio dove sta il monitoraggio utile. Metti a budget una piccola cifra specificamente per quello. Q: Come evito l'assuefazione agli avvisi? A: Cancella i monitoraggi che non hanno mai richiesto un'azione, richiedi più fallimenti consecutivi prima di avvisare, e separa l'urgente dall'informativo. Poi rivedi ogni mese gli avvisi scattati. Un canale di avvisi che le persone silenziano è peggio di nessun avviso, perché crea la convinzione che qualcuno stia sorvegliando. ## Strategia di backup: cosa salvare e ogni quanto https://websitedevelopment.biz/it/guides/strategia-di-backup-sito-web Aggiornato il 2026-08-07 · Manutenzione Quasi tutti i siti hanno backup. Meno hanno backup che siano stati ripristinati. Lo scarto tra le due cose si scopre nel momento peggiore possibile, di solito insieme alla scoperta che al backup mancava il database, o i file caricati, o le ultime tre settimane. Questa guida copre cosa salvare, ogni quanto, dove conservarlo, e come verificare che un ripristino funzioni davvero. ### Cosa contiene un backup completo Un sito non è una cosa sola. La mancanza di uno di questi elementi rende parziale un ripristino, e un ripristino parziale è spesso peggio di nessuno perché sembra aver funzionato. - Database — contenuti, utenti, ordini, impostazioni. La parte che cambia di continuo. - File caricati — immagini, documenti, tutto ciò che utenti o redazione hanno aggiunto. - Codice applicativo — idealmente nel controllo di versione, che è una forma di backup con storico. - Configurazione — variabili d'ambiente, configurazione del server, attività pianificate, regole di reindirizzamento. - Certificati e record DNS — poco costosi da esportare, dolorosi da ricostruire sotto pressione. - Impostazioni di terze parti — URL dei webhook di pagamento, configurazione e-mail, chiavi API. La configurazione è la parte più spesso dimenticata. Un database e dei file ripristinati su un server configurato diversamente non sono lo stesso sito. ### Ogni quanto, e per quanto conservare La frequenza discende da una domanda: quanto lavoro puoi permetterti di perdere? La conservazione discende da un'altra: quanto tempo passerebbe prima che tu noti un problema? | Sito vetrina statico | Settimanale | Settimanale | 30 giorni | | Sito aziendale con blog | Giornaliera | Giornaliera | 30–60 giorni | | Sito editoriale molto trafficato | Giornaliera, o oraria | Giornaliera | 60–90 giorni | | Negozio online | Oraria o continua | Giornaliera | Oltre 90 giorni, più archivi mensili | | Applicazione web | Continua con ripristino a un istante preciso | Giornaliera | Secondo la tua politica sui dati | La conservazione conta perché esistono problemi a evoluzione lenta. Un'importazione corrotta o una compromissione silenziosa possono passare inosservate per settimane, e a quel punto una rotazione di 7 giorni contiene solo copie cattive. ### Dove conservarli La regola classica regge ancora: tre copie, su due tipi di supporto, con una fuori sede. Adattata ai siti web significa che il backup deve sopravvivere sia al guasto del server sia alla sua compromissione. - Non conservare mai l'unica copia sullo stesso server del sito. - Usa un fornitore diverso per almeno una copia, perché un guasto a livello di fornitore non porti via entrambe. - Rendi almeno una copia immutabile o a scrittura singola, perché le credenziali che fanno girare il sito non possano cancellarla. - Cifra i backup a riposo: contengono tutto, dati personali compresi. - Conserva un archivio mensile fuori dalla rotazione per i problemi a scoperta lenta. - Documenta dove sono e come si ripristina, in un posto che non sia solo il sito stesso. ### Collaudare: il passaggio che rende la cosa reale Un backup che non hai mai ripristinato è un'ipotesi. Collaudarlo richiede un'ora e la trasforma in un fatto. - Ripristina in un ambiente di preproduzione separato, non sopra il sito online. - Verifica che il database sia stato ripristinato per intero: conta le righe nelle tabelle che contano. - Verifica che i file caricati ci siano, quelli recenti compresi. - Accedi ed esegui un'attività reale: pubblicare una pagina, effettuare un ordine di prova. - Cronometra. «Quanto durerebbe un ripristino?» è una domanda a cui vuoi avere risposta in anticipo. - Scrivi la procedura perché non resti solo in capo a chi l'ha impostata. - Ripeti ogni mese e dopo ogni modifica all'hosting. Cronometra il ripristino. Sapere che dura quattro ore cambia ciò che prometti ai referenti durante un'interruzione, ed è il numero che nessuno ha quando serve. Q: Il backup del mio hosting basta? A: È una buona base e una cattiva strategia unica. I backup dell'hosting hanno tipicamente una conservazione breve, stanno sulla stessa infrastruttura, e si perdono insieme all'account in caso di contestazione di fatturazione o guasto del fornitore. Tieni una tua copia altrove: il costo è basso ed è la copia che ti servirà proprio nello scenario in cui i backup dell'hosting non aiutano. Q: Per quanto tempo conservare i backup? A: Abbastanza da coprire un problema a scoperta lenta. Trenta giorni è un minimo ragionevole, novanta è più sicuro per un negozio, e un archivio mensile tenuto per un anno costa quasi nulla. Bilancialo con gli obblighi di protezione dei dati: anche i backup che contengono dati personali sono soggetti a regole di conservazione. Q: Servono i backup se il codice è nel controllo di versione? A: Sì. Il controllo di versione copre il codice e il suo storico, e non contiene il database, i file caricati o la configurazione del server. È lì che vivono contenuti e dati dei clienti, ovvero la parte che non si può ricreare rieseguendo un rilascio. Q: Cos'è il ripristino a un istante preciso? A: La capacità di riportare il database a un momento qualsiasi, anziché all'ultima istantanea pianificata, ottenuta archiviando di continuo il registro delle transazioni. Conta quando perdere anche solo un'ora di ordini è inaccettabile. Per un sito vetrina è superfluo; per un negozio che riceve ordini di notte vale la configurazione in più. ## Sicurezza web: le pratiche che evitano la maggior parte degli incidenti https://websitedevelopment.biz/it/guides/sicurezza-sito-web-buone-pratiche Aggiornato il 2026-08-07 · Manutenzione La maggior parte delle compromissioni di siti web non è mirata. Sono scanner automatici che trovano una vulnerabilità nota in software obsoleto, o una password riusata su un account di amministrazione. Difendersi dagli attacchi ordinari copre la grande maggioranza del rischio reale. Questa guida copre le pratiche che evitano la maggior parte degli incidenti, grosso modo in ordine di effetto, e cosa fare se un sito è già compromesso. ### Le misure che evitano la maggior parte degli incidenti In ordine di quanto rischio eliminano per unità di sforzo. - Tieni il software aggiornato. La stragrande maggioranza delle compromissioni sfrutta una vulnerabilità per cui esiste una correzione. Questo singolo punto pesa più di tutto ciò che segue. - Password uniche e robuste più autenticazione a due fattori su ogni account di amministrazione, pannello di hosting, registrar di dominio e account e-mail. - Privilegio minimo. Chi redige non ha bisogno di account amministratore. Rimuovi gli account quando le persone se ne vanno. - HTTPS ovunque, con HSTS una volta che sei certo che ogni sottorisorsa sia disponibile su TLS. - Backup collaudati, conservati fuori dal server. Un backup sulla macchina compromessa viene cifrato insieme a tutto il resto. - Limita l'area di amministrazione per IP dove è praticabile, e limita sempre i tentativi di accesso. - Rimuovi ciò che non usi. Ogni plugin inattivo, tema e vecchia installazione è superficie d'attacco senza beneficio. Le vecchie installazioni dimenticate — una copia di preproduzione in /vecchio, un blog di prova in una sottocartella — sono un punto d'ingresso comune proprio perché nessuno le aggiorna. ### Input, output e le vulnerabilità classiche Sono responsabilità dello sviluppo e spiegano la maggior parte delle vulnerabilità che non siano «non hai aggiornato». | SQL injection | Legge o distrugge il tuo database | Query parametrizzate, sempre; mai concatenazione di stringhe | | Cross-site scripting | Esegue script dell'attaccante nella sessione di un visitatore | Fare escaping in output secondo il contesto; una Content-Security-Policy rigorosa | | Cross-site request forgery | Esegue azioni come utente autenticato | Token per sessione su ogni richiesta che modifica lo stato | | Abuso del caricamento file | Carica ed esegue codice | Validare il tipo dal contenuto, salvare fuori dalla radice web, non eseguire mai | | Controllo degli accessi difettoso | Gli utenti raggiungono dati non loro | Verificare l'autorizzazione lato server a ogni richiesta, non nell'interfaccia | | Esposizione di dati sensibili | Fa trapelare chiavi e credenziali | Variabili d'ambiente, mai nel repository | | Server-side request forgery | Fa chiamare al tuo server sistemi interni | Elenco di destinazioni in uscita consentite | ### Configurazione e intestazioni Misure poco costose che chiudono intere categorie di problemi, quasi tutte applicabili in pochi minuti. - Servi intestazioni di sicurezza: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options. - Disattiva l'elenco delle directory; assicurati che /.git, /.env e i file di backup non siano raggiungibili via HTTP. - Disattiva l'output dettagliato degli errori in produzione: le tracce di esecuzione sono ricognizione per l'attaccante. - Blocca l'accesso ai percorsi di amministrazione e configurazione dalla rete pubblica dove puoi. - Imposta i cookie con HttpOnly, Secure e un valore SameSite adeguato. - Tieni le dipendenze verificate; una libreria vulnerabile nella tua build è una tua vulnerabilità. - Registra gli eventi di autenticazione e allerta sugli schemi insoliti. ### Se il sito è già compromesso Qui l'ordine conta. Ripulire i file prima di cambiare le credenziali significa che l'attaccante rientra semplicemente dalla stessa porta. - Metti il sito offline o in modalità manutenzione. Non lasciarlo servire software dannoso ai visitatori. - Conserva le prove: copia i registri e un'istantanea dei file prima di cambiare qualsiasi cosa. - Cambia ogni credenziale: hosting, database, utenti di amministrazione, chiavi API, e-mail. Presumi che siano tutte note. - Ripristina da un backup precedente alla compromissione, se riesci a individuarne uno in modo affidabile. - Se non ci riesci, ricostruisci dai sorgenti e importa solo dati, mai file di origine ignota. - Correggi la vulnerabilità che li ha fatti entrare. Senza questo passaggio ripeterai l'intero processo. - Cerca la persistenza: attività pianificate, utenti di amministrazione aggiuntivi, file del nucleo modificati, contenuti iniettati. - Richiedi una revisione in Search Console se il sito è stato segnalato, e cerca pagine di spam iniettate. - Notifica gli utenti coinvolti se sono stati esposti dati personali — in molte giurisdizioni entro un termine di legge. Ripristinare un backup senza chiudere il punto d'ingresso è il motivo più comune per cui i siti vengono compromessi due volte in quindici giorni. Q: Un plugin di sicurezza è sufficiente? A: Aiuta su alcune cose — limitazione dei tentativi di accesso, sorveglianza delle modifiche ai file, un firewall di base — e non sostituisce aggiornamenti, credenziali robuste e privilegio minimo. Un sito con un plugin di sicurezza e diciotto mesi di aggiornamenti mancati non è sicuro. Sistema prima i fondamentali, poi aggiungi strumenti. Q: I siti piccoli vengono davvero attaccati? A: Di continuo, e non per chi sei. Gli scanner automatici provano ogni host raggiungibile in cerca di vulnerabilità note; i siti piccoli sono attraenti proprio perché è meno probabile che siano aggiornati. I siti piccoli compromessi vengono usati per spam, pagine di phishing e reindirizzamenti, ed è per questo che il livello di traffico del tuo sito è irrilevante rispetto al rischio. Q: Dove vanno conservati i backup? A: In un posto dove il server web non possa scrivere, idealmente presso un altro fornitore, con almeno una copia che le credenziali che fanno girare il sito non possano cancellare. I ransomware e gli attacchi distruttivi puntano proprio ai backup raggiungibili dalla macchina compromessa, ed è esattamente il momento in cui ti servono. Q: Qual è la misura di sicurezza di maggior valore? A: Applicare gli aggiornamenti con prontezza. È poco spettacolare e previene più compromissioni reali di tutto il resto messo insieme, perché gli attacchi che avvengono davvero sono sfruttamenti automatizzati di vulnerabilità note e già corrette. Al secondo posto, l'autenticazione a due fattori sugli account di amministrazione e di hosting. ## Manutenzione di un sito web: cosa comporta davvero https://websitedevelopment.biz/it/guides/guida-manutenzione-sito-web Aggiornato il 2026-08-07 · Manutenzione La manutenzione di un sito web è il lavoro che lo tiene sicuro, aggiornato e funzionante dopo il lancio. È invisibile quando viene fatta ed estremamente visibile quando non viene fatta — di solito come un'interruzione, una compromissione, o un modulo che fallisce in silenzio da un mese. Questa guida copre cosa include davvero la manutenzione, quanto costa, cosa dovrebbe specificare un contratto, e come verificare che la stai ricevendo. ### In cosa consiste il lavoro La manutenzione si divide in lavoro di routine pianificato e lavoro reattivo quando succede qualcosa. Un contratto che copre solo il secondo non è manutenzione, è assistenza. | Correzioni di sicurezza | Appena pubblicate, entro giorni | Le vulnerabilità note vengono sfruttate automaticamente | | Aggiornamenti di piattaforma e plugin | Mensili, collaudati in preproduzione | Restare indietro rende l'aggiornamento più difficile ogni mese | | Verifica dei backup | Test di ripristino mensile | Un backup non provato non è un backup | | Monitoraggio della disponibilità | Continuo | Non dovresti apprendere un'interruzione da un cliente | | Revisione dei registri di errore | Settimanale | Guasti silenziosi: moduli rotti, pagamenti falliti | | Controllo delle prestazioni | Mensile | Il peso di pagina sale in silenzio mentre si aggiungono contenuti | | Controllo dei link rotti | Trimestrale | I link esterni si deteriorano a ritmo costante | | Revisione dei contenuti | Trimestrale | Prezzi scaduti e numeri di telefono morti costano più dei bug | | Verifica delle dipendenze | Trimestrale | Le librerie abbandonate vanno sostituite prima che si rompano | ### Quanto costa Un riferimento utile è il 10–20 % del costo di realizzazione all'anno per un sito su CMS, di più per un negozio o un'applicazione. Sotto quella soglia di solito compri disponibilità anziché lavoro reale. | Piccolo sito vetrina | 50 – 200 $ | Aggiornamenti, backup, monitoraggio disponibilità, piccole modifiche | | Sito aziendale medio | 200 – 800 $ | Quanto sopra più collaudi in preproduzione, prestazioni e revisione errori | | Negozio online | 500 – 3.000 $ | Quanto sopra più monitoraggio di pagamenti e scorte, risposta più rapida | | Applicazione web | Da 1.500 $ | Quanto sopra più gestione dei rilasci e reperibilità | Un contratto economico senza rapporto è difficile da distinguere dall'assenza di contratto. Il rapporto è ciò che stai davvero comprando. ### Cosa dovrebbe specificare un contratto I contratti vaghi provocano contenziosi esattamente nel momento sbagliato. Questi punti dovrebbero essere messi per iscritto prima di firmare. - Esattamente quali attività di routine vengono svolte e con quale frequenza. - Obiettivi di tempo di risposta, distinti per gravità: sito giù, funzione rotta, cosmetico. - Le fasce di copertura, e cosa succede al di fuori. - Quante ore di modifiche sono incluse, e se le ore non usate si accumulano. - Cosa conta come modifica anziché come nuovo progetto, con esempi. - Chi ha accesso a cosa, e come viene revocato alla fine dell'accordo. - Cosa ricevi ogni mese: un rapporto vero, non una fattura. - Il preavviso e cosa accade ai tuoi dati e ai tuoi accessi alla fine. ### Farlo da soli Per un sito piccolo è del tutto ragionevole, a patto che sia pianificato e non solo desiderato. Mettilo in un calendario con una persona responsabile, perché la manutenzione fatta «quando ce ne ricordiamo» non viene fatta. - Settimanale: verifica che il sito carichi, invia il modulo di contatto, dai un'occhiata ai registri di errore. - Mensile: applica gli aggiornamenti prima in preproduzione e poi in produzione. Verifica che un backup si ripristini. - Mensile: controlla in Search Console nuovi errori di copertura e azioni manuali. - Trimestrale: passa un verificatore di link, un test di prestazione e un'analisi di accessibilità. - Trimestrale: rileggi i contenuti per prezzi, date, nomi di persone e link morti. - Annuale: verifica i rinnovi di dominio e certificato, e controlla chi ha ancora accesso. Metti i promemoria di calendario su una persona indicata per nome, non su un team. La responsabilità condivisa su un compito ricorrente diventa in modo affidabile responsabilità di nessuno. Q: Cosa succede se salto la manutenzione? A: Per un po', nulla di visibile — ed è proprio per questo che si salta. Poi accade una di tre cose: uno scanner automatico sfrutta una vulnerabilità nota, un aggiornamento diventa impossibile perché sei indietro di diverse versioni maggiori, oppure qualcosa è rotto da settimane e nessuno l'ha notato. Tutte e tre costano più di quanto sarebbe costata la manutenzione. Q: Posso usare il pacchetto di manutenzione del mio hosting? A: L'hosting gestito di solito copre il server, e spesso gli aggiornamenti del nucleo della piattaforma e i backup. Copre di rado i tuoi plugin, il tuo codice su misura, i tuoi registri di errore o i tuoi contenuti. Leggi cosa è incluso; lo scarto tra «hosting gestito» e «manutenzione del sito» è dove accadono la maggior parte degli incidenti. Q: Come faccio a sapere se la manutenzione viene fatta? A: Chiedi un rapporto mensile: cosa è stato aggiornato, cosa è stato corretto, la disponibilità, gli errori trovati e risolti, e la data dell'ultimo ripristino di backup riuscito. Se un contratto non produce alcun rapporto, non puoi distinguere una buona manutenzione dall'assenza di manutenzione — e di solito scopri quale fosse durante un incidente. Q: Gli aggiornamenti vanno applicati automaticamente? A: Le correzioni di sicurezza del nucleo della piattaforma in genere sì: il rischio di attendere supera di solito il rischio di rompere qualcosa. Gli aggiornamenti di plugin e di versione maggiore andrebbero collaudati prima in preproduzione, perché sono quelli che rompono impaginazioni e codice su misura. La ripartizione giusta dipende da quanto vale il sito per ora di indisponibilità. ## SEO per e-commerce: le pratiche che contano davvero https://websitedevelopment.biz/it/guides/seo-per-negozi-online Aggiornato il 2026-08-07 · E-commerce La SEO di un negozio differisce da quella editoriale su un punto importante: il sito genera URL da solo. Filtri, ordinamenti, varianti e paginazione possono trasformare un catalogo da 500 prodotti in 50.000 pagine indicizzabili, ed è lì che iniziano la maggior parte dei problemi SEO di un negozio. Questa guida copre come strutturare un negozio perché si posizionino le pagine giuste e quelle generate dalla macchina restino fuori dall'indice. ### Le categorie sono le tue pagine più preziose La maggior parte della domanda commerciale riguarda una categoria, non un prodotto specifico: si cerca «scarponi da trekking impermeabili» molto più di un modello particolare. Le pagine di categoria sono quindi quelle su cui vale la pena investire, e di solito sono le più povere. - Dai a ogni categoria un testo vero: una breve introduzione sopra la griglia e dettaglio utile sotto. - Allinea la categoria a come cercano le persone, non a come è organizzato il tuo magazzino. - Collega tra loro le categorie affini; una griglia di prodotti senza link editoriali è un vicolo cieco. - Tieni stabili gli URL di categoria anche quando cambia l'assortimento. L'URL sopravvive ai prodotti che contiene. - Mostra abbastanza prodotti nella parte alta perché la pagina risponda subito alla domanda. Una pagina di categoria senza testo compete solo con i titoli dei prodotti. È per questo che le pagine di categoria perdono così spesso contro siti editoriali che recensiscono gli stessi prodotti. ### Navigazione a faccette: la principale fonte di guai I filtri moltiplicano gli URL in modo combinatorio. Lasciati aperti, consumano budget di scansione, diluiscono i segnali e riempiono l'indice di quasi duplicati lenti da rimuovere. | Categoria di base | Indicizzare, autocanonica | | Filtro singolo ad alta domanda (es. marca) | Indicizzare se c'è domanda reale e prodotti a sufficienza | | Più filtri combinati | noindex, follow | | Ordinamento | noindex, oppure non creare affatto un URL distinto | | Paginazione | Indicizzare, ogni pagina autocanonica, link scansionabili veri | | Risultato filtro vuoto | noindex, e valutare la restituzione di un 404 | | Parametri di tracciamento | Rimuovere, o rendere canonico verso l'URL pulito | ### Pagine prodotto: URL, varianti e scorte Tre decisioni causano qui la maggior parte dei problemi delle pagine prodotto, e tutte e tre costano meno risolte prima del lancio. - Un URL per prodotto, non uno per percorso di categoria. Un prodotto in tre categorie non dovrebbe esistere sotto tre URL. - Varianti: una pagina prodotto indicizzabile con selezione della variante, a meno che una variante abbia una domanda davvero distinta — il colore di rado, la taglia mai. - Esaurito: tieni la pagina online con la disponibilità indicata e le alternative mostrate. Cancellarla butta via segnali di posizionamento accumulati per un prodotto che può tornare il mese prossimo. - Fuori produzione definitivamente: 301 verso l'equivalente più vicino o verso la categoria, non verso la home. - Descrizioni proprie. Il testo del produttore sta sul sito di ogni concorrente; è la definizione stessa di contenuto duplicato. - Dati strutturati con prezzo e disponibilità che corrispondano esattamente alla pagina visibile. ### Punti tecnici specifici dei negozi Si presentano su quasi ogni negozio e di rado su un sito vetrina. | Risultati della ricerca interna | noindex: sono infiniti e poveri | | Carrello e checkout | noindex, e bloccare la scansione | | Account cliente | noindex; non permettere mai l'indicizzazione delle pagine ordine | | Più valute | Un URL canonico; non creare un URL per valuta | | Più mercati | URL con prefisso più hreflang reciproco | | Recensioni | Renderle in HTML; markup delle recensioni solo per recensioni vere presenti in pagina | | Prestazioni degli elenchi | Sorvegliarle al crescere del catalogo: si degradano per prime | | Sitemap | Suddividere per tipo, e tenerle aggiornate al variare delle scorte | I feed di prodotto per gli annunci shopping non sostituiscono pagine prodotto indicizzabili. Sono sistemi separati e l'uno non posiziona l'altro. Q: I prodotti esauriti vanno rimossi? A: Non se l'articolo tornerà. Tieni la pagina, indica la disponibilità con esattezza sia nella pagina visibile sia nei dati strutturati, e proponi alternative. Cancellarla butta via link e storico di posizionamento che hai pagato. Fai un 301 solo quando il prodotto è davvero fuori produzione, e allora verso l'equivalente più vicino anziché verso la home. Q: Come gestisco i prodotti presenti in più categorie? A: Dai a ogni prodotto un unico URL canonico che non includa il percorso di categoria: /prodotti/scarpone-trekking-x anziché /scarpe/trekking/scarpone-trekking-x. Collegalo da ogni categoria pertinente. Gli URL di prodotto basati sulla categoria creano duplicati e si rompono appena riorganizzi il catalogo. Q: Servono descrizioni uniche per ogni prodotto? A: Per i prodotti che vuoi posizionare, sì. Il testo del produttore compare presso ogni concorrente che vende lo stesso articolo, quindi non c'è nulla che distingua la tua pagina. Se riscrivere 4.000 prodotti è irrealistico, comincia da quelli che generano davvero fatturato e lascia che il resto si appoggi alle pagine di categoria. Q: Le pagine di filtro vanno mai indicizzate? A: Un numero ridotto, scelto di proposito: filtri singoli che corrispondono a una domanda di ricerca reale e restituiscono un numero decente di prodotti, come una marca dentro una categoria. Dai a quelle pagine titolo e descrizione propri. Tutto il resto — combinazioni, ordinamenti, cursori di prezzo — dovrebbe essere noindex, follow. ## Integrazione del gateway di pagamento: cosa fare bene https://websitedevelopment.biz/it/guides/integrazione-gateway-di-pagamento Aggiornato il 2026-08-07 · E-commerce L'integrazione dei pagamenti sembra semplice in un tutorial ed è implacabile in produzione, perché ogni caso di errore comporta o un cliente che ha pagato e non ha ricevuto nulla, o un cliente che ha ricevuto qualcosa senza pagare. Questa guida copre come funziona il flusso, la decisione progettuale che previene la maggior parte dei problemi, e i casi da collaudare di proposito prima del lancio. ### Come funziona davvero il flusso Qualunque sia il fornitore, la forma è la stessa: il tuo server crea un'intenzione di addebito, il cliente si autentica presso il fornitore di pagamento, e il fornitore ti comunica l'esito — due volte, per due vie diverse. - Il tuo server crea un'intenzione di pagamento con importo, valuta e un riferimento al tuo ordine. - Il cliente inserisce i dati della carta in un campo o in una pagina ospitati, così i dati non toccano mai il tuo server. - Può essere richiesta un'autenticazione forte, che aggiunge un passaggio da completare. - Il fornitore riporta il cliente sul tuo sito con un esito. - Separatamente, il fornitore invia un webhook da server a server con l'esito che fa fede. - Il tuo sistema aggiorna l'ordine — dal webhook, non dal reindirizzamento. - L'evasione parte solo dopo che il pagamento è confermato. I passaggi 4 e 5 sono l'intera progettazione. Il reindirizzamento è un indizio di cosa è successo; il webhook è il fatto. ### Perché i webhook devono fare fede Il browser del cliente è un narratore inaffidabile. Può chiudersi durante il reindirizzamento, perdere la connessione, o essere manipolato. Se lo stato del tuo ordine dipende dal ritorno del cliente sulla pagina di conferma, avrai ordini pagati mai registrati. - Aggiorna lo stato dell'ordine solo da webhook verificati; tratta il reindirizzamento come un semplice messaggio all'utente. - Verifica le firme dei webhook. Un endpoint non autenticato che segna ordini come pagati è esattamente grave quanto suona. - Rendi idempotente la gestione dei webhook: i fornitori riprovano, e i duplicati arriveranno. - Rispondi in fretta ed elabora in modo asincrono; gli endpoint lenti vengono riprovati e infine disattivati. - Registra ogni payload di webhook. Le contestazioni di pagamento si risolvono con i registri. - Gestisci eventi fuori ordine, perché possono arrivare così e lo faranno. ### I casi di errore da collaudare Ciascuno di questi capita in produzione. Collaudali di proposito, con le carte di test del fornitore, prima del lancio. | Il cliente chiude la scheda dopo aver pagato | Il webhook completa comunque l'ordine; l'e-mail di conferma parte | | Carta rifiutata | Messaggio chiaro, carrello conservato, nuovo tentativo possibile | | Autenticazione forte fallita | Ordine non confermato; al cliente viene detto cosa fare | | Webhook duplicato | Ordine aggiornato una volta, non due; nessuna seconda spedizione | | Il webhook arriva prima del reindirizzamento | La pagina di conferma rispecchia l'ordine già completato | | Rimborso parziale | Totali dell'ordine ed eventuale export contabile restano coerenti | | Scorte esaurite tra pagamento ed evasione | Processo definito: rimborso, attesa o sostituzione | | Arrotondamento di valuta | L'importo addebitato corrisponde esattamente al totale mostrato | ### Perimetro, conformità e denaro Poche decisioni determinano quanto onere normativo ti assumi e quanto della transazione ti resta. - Non memorizzare mai numeri di carta. Usa campi o pagine ospitati perché i dati della carta non raggiungano mai il tuo server; così il perimetro PCI resta minimo. - Capisci la struttura delle commissioni. Percentuale più quota fissa, più conversione valuta, più commissioni sugli storni. La percentuale in evidenza non è il costo. - Verifica i tempi di accredito. I giorni fino al regolamento incidono sulla liquidità più di una piccola differenza di aliquota. - Conferma che il percorso di rimborso funzioni da capo a fondo prima del lancio, rimborsi parziali compresi. - Supporta i metodi locali che il tuo mercato usa davvero: la carta non è lo standard ovunque, e mancare il metodo locale dominante costa conversioni. - Tieni pronto un secondo fornitore se i pagamenti sono critici. I disservizi capitano e fermano del tutto il fatturato. Q: Checkout ospitato o modulo integrato? A: Il checkout ospitato è più semplice, tiene il perimetro PCI al minimo ed è mantenuto dal fornitore: per la maggior parte dei negozi è l'impostazione predefinita giusta. I campi integrati tengono il cliente sul tuo dominio e danno più controllo sull'esperienza, al costo di più codice e più responsabilità. Entrambi tengono i dati della carta fuori dal tuo server, che è la parte che conta. Q: Cosa succede se il mio endpoint webhook cade? A: I fornitori riprovano con attesa crescente, tipicamente per ore o giorni, quindi un disservizio breve si recupera da solo. Un disservizio lungo significa ordini non confermati, quindi monitora l'endpoint e fatti avvisare in caso di errore. Costruisci anche una riconciliazione quotidiana che confronti le transazioni del fornitore con i tuoi ordini: recupera tutto ciò che i tentativi hanno mancato. Q: Devo gestire l'autenticazione forte del cliente? A: Se vendi a clienti in aree che la richiedono, sì, e gli SDK moderni dei fornitori gestiscono la maggior parte del flusso. Ciò che devi gestire tu è l'esito: un ordine in attesa di autenticazione non è pagato, e trattarlo come pagato significa spedire merce mai incassata. Q: Come collaudo i pagamenti in sicurezza? A: Ogni fornitore ha una modalità di test con carte che innescano esiti specifici: rifiuto, autenticazione richiesta, frode. Percorri l'elenco completo, casi scomodi della tabella qui sopra compresi. Poi fai una piccola transazione reale in produzione prima del lancio e rimborsala, perché la modalità di test non sollecita né le tue chiavi reali né il tuo URL di webhook reale. ## WooCommerce, Shopify e Magento: un confronto pratico https://websitedevelopment.biz/it/guides/woocommerce-shopify-magento-a-confronto Aggiornato il 2026-08-07 · E-commerce Queste tre coprono la maggior parte dei progetti di negozio, e sono adatte a situazioni davvero diverse. La scelta riguarda meno le funzionalità — tutte e tre sanno vendere prodotti — e più chi mantiene il negozio e cosa succede quando i requisiti crescono. Questo confronto procede per modello operativo anziché per elenco di funzionalità, perché è questo a determinare se una piattaforma si rivela azzeccata. ### A chi si rivolge ciascuna Detto in chiaro, prima del dettaglio. | Shopify | SaaS in hosting | Team che vogliono vendere, non mantenere infrastruttura | | WooCommerce | Plugin WordPress, auto-ospitato | Siti editoriali con catalogo contenuto e competenze WordPress | | Magento / Adobe Commerce | Enterprise auto-ospitato | Cataloghi complessi, regole B2B, competenza interna o di agenzia | ### Differenze pratiche I confronti che cambiano la decisione, anziché quelli che compaiono sulle pagine di marketing. | Sforzo di avvio | Basso | Medio | Alto | | Chi applica le patch di sicurezza | Il fornitore | Tu | Tu | | Personalizzazione del checkout | Limitata per scelta progettuale | Totale | Totale | | Catalogo su larga scala | Buono | Si degrada senza lavoro | Costruito per questo | | Regole di prezzo B2B | Modulo aggiuntivo | Plugin, qualità variabile | Nativo | | Multinegozio / multimercato | Costo aggiuntivo | Scomodo | Nativo | | Costo di esercizio | Abbonamento più commissioni più app | Hosting più plugin più tempo di sviluppo | Hosting e sviluppo sostanziali | | Competenze necessarie | Operatore | Sviluppatore WordPress | Sviluppatore specializzato | ### Dove si rompe ciascuna Ogni piattaforma ha un modo di fallire che compare dopo il lancio anziché durante la valutazione. Questi sono i più frequenti. - Shopify: regole di checkout che la piattaforma non permette, e abbonamenti ad app che finiscono per superare il canone della piattaforma. Inoltre commissioni per transazione se non usi il suo prodotto di pagamento. - WooCommerce: prestazioni delle pagine di elenco al crescere del catalogo, conflitti tra plugin dopo gli aggiornamenti, ed esposizione di sicurezza quando nessuno si occupa delle patch. - Magento: il costo totale di proprietà. È potente e richiede infrastruttura ed esperienza vere; i negozi Magento sotto-dotati sono lenti e restano indietro sugli aggiornamenti. - Tutte e tre: la navigazione a faccette che genera migliaia di URL indicizzabili se non viene configurata di proposito. L'errore costoso più comune è scegliere Magento per un catalogo che WooCommerce gestirebbe, o WooCommerce per uno che richiede Magento. Entrambi gli errori emergono dopo circa un anno. ### Costi di uscita Da sapere prima di impegnarsi, perché decide se la scelta è reversibile. | Shopify | Esportazione CSV, lineare | Esportazione senza password | Esportazione, storico limitato | I prefissi di URL fissi rendono scomoda la mappatura | | WooCommerce | Accesso completo al database | Accesso completo | Accesso completo | Totalmente sotto il tuo controllo | | Magento | Accesso completo al database | Accesso completo | Accesso completo | Totalmente sotto il tuo controllo | Le piattaforme auto-ospitate sono più facili da lasciare perché il database è tuo. È un vantaggio reale dell'open source e viene raramente pesato al momento della scelta. Q: Quale costa meno? A: Per un negozio piccolo, Shopify di solito costa meno nel complesso una volta contati hosting, patch e tempo di sviluppo: l'abbonamento è visibile, i costi alternativi no. WooCommerce costa meno se usi già WordPress e hai qualcuno di competente che lo mantiene. Magento non è l'opzione economica in nessuno scenario. Q: WooCommerce va bene per cataloghi grandi? A: Può gestire migliaia di prodotti con hosting, cache e lavoro sulle query adeguati, ma quel lavoro serve: le prestazioni su pagine di elenco e filtri si degradano prima che il numero di prodotti suoni impressionante. Se il catalogo è grande e complesso dal primo giorno, vale la pena confrontarlo con piattaforme costruite per quella forma. Q: Mi serve Magento per il B2B? A: Non necessariamente, ma i requisiti B2B — prezzi per cliente, preventivi, ordini di acquisto, gerarchie di account — lì sono nativi e altrove sono moduli aggiuntivi. Se ne hai diversi, il confronto è equo. Se ne hai uno, un modulo aggiuntivo su una piattaforma più semplice costa di solito meno da possedere. Q: Posso tenere contenuti e commercio sulla stessa piattaforma? A: WooCommerce lo fa naturalmente perché WordPress è prima di tutto un sistema di contenuti. Gli strumenti per i contenuti di Shopify sono più deboli, quindi i negozi Shopify ricchi di contenuti lo affiancano spesso a un CMS separato. Se la tua acquisizione passa dai contenuti, pesalo seriamente: è una differenza pratica maggiore di quanto suggeriscano quasi tutti i confronti di funzionalità. ## Piattaforme e-commerce a confronto: come scegliere https://websitedevelopment.biz/it/guides/piattaforme-e-commerce-a-confronto Aggiornato il 2026-08-07 · E-commerce I confronti tra piattaforme invecchiano in fretta perché le funzionalità cambiano ogni trimestre. Ciò che non cambia è l'insieme di domande che decide quale categoria di piattaforma sia adatta, e i compromessi che ogni categoria assume. Questa guida confronta le categorie anziché i marchi, e dà le domande che restringono in fretta la scelta. ### Le quattro categorie Quasi ogni opzione ricade in una di queste, e la categoria decide più del marchio al suo interno. | SaaS in hosting | Solo contenuti e operatività | La maggior parte dei negozi piccoli e medi | | Open source auto-ospitato | Tutto: hosting, aggiornamenti, sicurezza | Requisiti insoliti, competenza interna | | Plugin per CMS (es. un plugin negozio) | L'intero stack, in modo leggero | Siti editoriali con un catalogo contenuto | | Commerce headless | Il front-end e lo strato di integrazione | Più canali, esperienze su misura, team più grandi | ### Le domande che restringono davvero la scelta Rispondi a queste prima di guardare qualsiasi elenco di funzionalità. La maggior parte elimina intere categorie anziché singoli prodotti. - Quanto è complesso un singolo prodotto? Varianti, opzioni configurabili e prezzi per cliente escludono gli strumenti più semplici. - Quanti mercati? Più regimi fiscali e valute sono il punto in cui le piattaforme economiche diventano care. - Con cosa deve integrarsi? Un ERP o un sistema contabile esistente è di solito il vincolo decisivo. - Chi la gestisce ogni giorno? Una piattaforma che richiede uno sviluppatore per modifiche di routine non è adatta a un'attività di due persone. - Qual è il volume di ordini realistico tra due anni? Le commissioni per transazione scalano diversamente dai canoni mensili. - Cosa succede se te ne vai? Chiedi come esportare prodotti, clienti e ordini prima di firmare qualsiasi cosa. La domanda sull'uscita è quella che nessuno pone ed è quella che fa più male dopo. Una piattaforma con strumenti di esportazione scadenti è una decisione che non potrai rivedere a poco prezzo. ### Costo totale, non costo di licenza Le piattaforme in hosting sembrano care sulla riga dell'abbonamento e spesso costano meno nel complesso una volta contati hosting, sicurezza e manutenzione. L'auto-ospitata sembra gratis e non lo è. | Abbonamento | Mensile, a scaglioni di volume | Nessuno | | Commissione per transazione | Spesso una percentuale oltre alle commissioni di pagamento | Solo commissioni di pagamento | | Hosting | Incluso | Tuo, e un negozio richiede risorse vere | | Sicurezza e PCI | In gran parte gestite | Tue, perimetro compreso | | Aggiornamenti | Automatici | Tuoi, e possono rompere le personalizzazioni | | App ed estensioni | Mensili per app, si sommano in fretta | Di solito una tantum o gratuite, più il tuo tempo | | Tempo di sviluppo | Minore per il lavoro di routine | Maggiore, continuo | ### Dove si rompe ciascuna categoria Conoscere il modo di fallire è più utile che conoscere l'elenco delle funzionalità, perché lo incontrerai al secondo anno e non durante la demo. - SaaS in hosting: un requisito di checkout che la piattaforma non consente, o abbonamenti ad app che superano in silenzio il canone della piattaforma. - Auto-ospitata: nessuno applica gli aggiornamenti di sicurezza, e il negozio viene compromesso o resta molto indietro. - Plugin per CMS: la crescita del catalogo degrada le prestazioni, e il sito non è mai stato costruito per query di scala commerciale. - Headless: il team front-end diventa un collo di bottiglia per modifiche che il marketing faceva da solo. Quasi tutti questi sono fallimenti operativi anziché tecnici. Scegli la piattaforma che la tua organizzazione può davvero far funzionare, non la più capace. Q: L'open source costa meno di una piattaforma in hosting? A: Di rado, una volta contati hosting, correzioni di sicurezza, tempo di sviluppo e il costo di un incidente. Costa meno quando hai competenza interna che altrimenti resterebbe inutilizzata, o quando hai requisiti che una piattaforma in hosting rifiuta. Confrontare la riga dell'abbonamento con zero è l'errore che lo fa sembrare ovvio. Q: Posso cambiare piattaforma più avanti? A: Sì, ed è un progetto completo: tipicamente il 30–50 % del costo di una costruzione nuova una volta contate migrazione del catalogo, mappatura degli URL e rifacimento delle integrazioni. Ecco perché la domanda sull'esportazione appartiene al processo di selezione. I prodotti di solito si esportano bene; con clienti e storico ordini si complica. Q: E il commerce headless? A: È davvero utile quando vendi su più canali o ti serve un front-end che la piattaforma non può produrre, e altrimenti è una complessità aggiuntiva notevole: front-end, strato di integrazione e loro rilascio sono tuoi. Per un negozio a canale singolo con un catalogo normale compra di solito una flessibilità che non spenderai. Q: Quale piattaforma è migliore per la SEO? A: Oggi sono ampiamente confrontabili: le differenze stanno in quanto controllo hai su URL, canonici e metadati, e nelle prestazioni del front-end. Conta di più se la tua implementazione gestisce correttamente navigazione a faccette, paginazione e stabilità degli URL di prodotto, e questa è una decisione di realizzazione su qualsiasi piattaforma. ## Sviluppo di un negozio online: la guida completa https://websitedevelopment.biz/it/guides/guida-sviluppo-negozio-online Aggiornato il 2026-08-07 · E-commerce Un negozio online è un sito web con denaro, scorte e obblighi di legge attaccati. È questo a rendere lo sviluppo e-commerce un progetto diverso da un sito vetrina: le parti che costano di più di solito non sono quelle che i clienti vedono. Questa guida copre cosa comprende davvero un progetto di negozio, cosa fa salire il costo, il lavoro operativo che parte al lancio, e gli errori costosi da disfare. ### Cosa comprende un negozio oltre la vetrina Catalogo e checkout sono la parte visibile. Sotto ci sono i sistemi che decidono se l'attività può davvero funzionare, ed è lì che finisce la maggior parte del budget in qualsiasi negozio che non sia il più piccolo. - Struttura del catalogo: categorie, varianti, attributi, kit, regole di disponibilità. - Prezzi: ivati o al netto a seconda del mercato, sconti, gruppi di clienti, valuta. - Pagamenti: almeno un gateway, più rimborsi, rimborsi parziali e gestione dei pagamenti falliti. - Spedizioni: zone, pesi, dimensioni, regole del corriere, soglie di spedizione gratuita. - Imposte: IVA in base alla destinazione, fatture con i campi che la tua giurisdizione richiede. - Scorte: disponibilità, ordini in attesa, e prenotazione durante il checkout per non vendere oltre disponibilità. - Gestione ordini: dove il personale lavora gli ordini — spesso un sistema del tutto separato. - E-mail: conferma, spedizione, rimborso, carrello abbandonato, e il loro contenuto legale. - Resi: la politica e il flusso che la mette in pratica. Chiedi presto dove il personale lavorerà davvero gli ordini. Se è il tuo ERP esistente, l'integrazione è una parte sostanziale del progetto e va nella prima stima. ### Cosa fa salire il costo Il numero di prodotti conta meno della loro complessità e del numero di sistemi con cui il negozio deve dialogare. | Catalogo | Prodotti semplici, un prezzo | Varianti, opzioni configurabili, prezzi per cliente | | Mercati | Un paese, una valuta | Più regimi fiscali, valute, lingue | | Integrazioni | Nessuna oltre il pagamento | ERP, PIM, gestione magazzino, contabilità, feed per marketplace | | Migrazione | Negozio nuovo, senza storico | Catalogo, clienti, ordini e URL esistenti | | Evasione | Un magazzino, spedizione forfettaria | Più sedi, regole del corriere, dropshipping | | Conformità | Vendita al consumatore standard | Limiti di età, licenze, merci regolamentate | ### La migrazione è un progetto a sé Cambiare piattaforma a un negozio esistente è di solito più difficile che costruirne uno nuovo, e la difficoltà sta nei dati e negli URL, non nel design. - Esporta e ripulisci il catalogo prima di ogni altra cosa. I dati esistenti sono sempre peggiori di come li si ricorda. - Decidi cosa non si sposta. I prodotti fuori produzione senza traffico non serve migrarli. - Mappa ogni vecchio URL di prodotto e categoria su uno nuovo; reindirizza con 301 e aspettati un elenco lungo. - Migra gli account cliente senza le password: imponi una reimpostazione anziché spostare hash tra sistemi. - Decidi quanto storico ordini si sposta. Spesso la risposta è «nessuno, il vecchio sistema resta in sola lettura per un anno». - Tieni i due sistemi in parallelo per una breve finestra se le scorte lo permettono, e riconcilia ogni giorno. - Sorveglia il traffico di ricerca per categoria per sei settimane; una categoria che cala è di solito un reindirizzamento dimenticato. Metti a budget tanto tempo per ripulire i dati di catalogo quanto per costruire il negozio. Nella maggior parte delle migrazioni è l'attività più pesante e quella che nessuno aveva previsto. ### Il lavoro che inizia al lancio Un negozio è un sistema operativo per un'attività, non un progetto che finisce. Questi costi sono continui e mancano di frequente nel primo budget. | Contenuti di prodotto | Nuove linee, nuove fotografie, nuove descrizioni | | Accuratezza delle scorte | Vendere oltre disponibilità costa più di qualsiasi anomalia di sviluppo | | Aggiornamenti di pagamento e piattaforma | I gateway dismettono API secondo il loro calendario | | Correzioni di sicurezza | I negozi sono un bersaglio per i dati di pagamento; le patch non sono facoltative | | Frodi e storni | Le regole vanno tarate al variare del mix di ordini | | Modifiche alle norme fiscali | Aliquote e soglie cambiano per giurisdizione, a volte ogni anno | | Prestazioni | La crescita del catalogo degrada per prime le pagine di elenco | Q: Quanto costa costruire un negozio online? A: Un piccolo negozio su piattaforma in hosting con un tema leggero può partire attorno ai 5.000 $. Un negozio di media dimensione con design proprio e una o due integrazioni sta tipicamente tra 20.000 e 60.000 $. Cataloghi grandi con integrazione ERP e più mercati vanno ben oltre. La migrazione di solito aggiunge il 30–50 % rispetto a una costruzione nuova equivalente. Q: Piattaforma in hosting o auto-ospitata? A: Le piattaforme in hosting si occupano di sicurezza, perimetro PCI e scalabilità a fronte di un canone mensile e spesso di una percentuale sulle transazioni, al costo di limiti di personalizzazione. L'auto-ospitata dà controllo totale, e manutenzione e onere di conformità sono tuoi. Per la maggior parte dei negozi piccoli e medi l'hosting è la scelta a minor rischio; l'argomento per l'auto-ospitata cresce con i requisiti insoliti e il fatturato. Q: Mi serve un sistema di gestione ordini separato? A: Sotto qualche decina di ordini al giorno l'amministrazione della piattaforma di solito basta. Sopra, o con più canali di vendita, un sistema dedicato si ripaga in fretta. La domanda da risolvere prima della costruzione è dove risieda il dato di scorta che fa fede, perché questo decide quale sistema informa l'altro. Q: Qual è l'errore più comune nel costruire un negozio? A: Trattare imposte e spedizioni come configurazione anziché come requisiti. Sono regole di business con casi limite — soglie, zone, carrelli misti, beni digitali — e scoprirli all'ottava settimana riscrive il checkout. Mettili per iscritto durante l'analisi iniziale, con esempi dei casi scomodi. ## Struttura degli URL per la SEO: le regole che contano ancora https://websitedevelopment.biz/it/guides/struttura-url-per-la-seo Aggiornato il 2026-08-07 · SEO Gli URL sono un piccolo fattore di posizionamento e un grande fattore di usabilità e manutenzione. Il loro valore vero è la stabilità: un URL che non devi mai cambiare è un URL che conserva i suoi link, le sue posizioni e i suoi segnalibri. Questa guida copre le regole che contano ancora, quelle che non contano più, e come cambiare un URL quando è davvero necessario. ### Le regole che vale la pena seguire Sono coerenti tra i motori e, cosa più importante, negli anni: riguardano tanto la manutenzione quanto il posizionamento. - Solo minuscole. Alcuni server trattano /Pagina e /pagina come URL diversi, creando duplicati per sbaglio. - Trattini tra le parole, non trattini bassi né maiuscole alternate. - Brevi e descrittivi. Se qualcuno legge l'URL a voce alta, dovrebbe poter indovinare la pagina. - Non servono parole vuote: /guide/pianificazione-sito-web batte /guide/come-pianificare-un-sito-web-per-la-mia-azienda. - Nessuna estensione di file sulle pagine di contenuto. /chi-siamo, non /chi-siamo.php: nasconde l'implementazione e sopravvive a una migrazione. - Una decisione canonica sulla barra finale, imposta con un reindirizzamento. - ASCII dove praticabile; gli URL non ASCII funzionano ma vengono codificati alla copia, il che è brutto e fonte di errori. La proprietà più preziosa è la stabilità. Un URL leggermente imperfetto che non cambia mai vale più di uno ottimizzato che cambia due volte. ### Cosa non conta più molto Diverse convinzioni di lunga data sugli URL hanno oggi un effetto limitato, e seguirle può perfino nuocere. | Gli URL a corrispondenza esatta si posizionano meglio | Marginale nel migliore dei casi; accumulare sembra spam | | Una struttura di cartelle profonda segnala gerarchia | La profondità di clic conta, quella del percorso quasi no | | Le date negli URL aiutano la freschezza | Fanno sembrare vecchio un contenuto senza tempo | | Più corto è sempre meglio | Descrittivo batte laconico; /p/4821 non aiuta nessuno | | Sottodominio o sottocartella è decisivo | Le sottocartelle sono più semplici da gestire; entrambi possono funzionare | | Le stringhe di query non si indicizzano | Si indicizzano, ma moltiplicano i duplicati: preferisci percorsi puliti | ### Schemi di URL multilingua Per un sito in più lingue, lo schema degli URL è tra le cose più difficili da cambiare dopo, perché interagisce con hreflang, i canonici e ogni reindirizzamento che scriverai. | Sottocartella | sito.com/it/guide | Il più semplice; un dominio accumula tutta l'autorità | | Sottodominio | it.sito.com/guide | Separazione più netta; più configurazione, segnali divisi | | Dominio nazionale | sito.it/guide | Segnale locale più forte; un sito a parte da gestire | | Parametro | sito.com/guide?lang=it | Da evitare: segnali deboli e rischio di duplicati | Qualunque cosa scegli, decidi separatamente se tradurre lo slug. Slug tradotti aiutano la pertinenza locale; slug identici sono più semplici da mantenere. Entrambe le scelte si difendono — cambiare idea dopo no. ### Cambiare un URL senza perdere traffico A volte un cambiamento è davvero necessario. La procedura è meccanica, e saltare un passaggio è da dove se ne va il traffico. - Verifica che ne valga la pena. Un cambio di URL costa sempre qualcosa; un miglioramento marginale di formulazione lo ripaga di rado. - Mappa vecchio su nuovo, uno a uno. Ogni vecchio URL riceve una destinazione precisa, non una pagina di categoria. - Implementa 301, non 302, e verifica che ciascuno restituisca un solo salto. - Aggiorna i link interni perché puntino direttamente al nuovo URL. Non affidarti ai tuoi stessi reindirizzamenti. - Aggiorna la sitemap e lascia i reindirizzamenti a tempo indeterminato: i link esterni non vengono mai aggiornati. - Sorveglia la copertura in Search Console e il rapporto delle pagine principali per quattro-sei settimane. - Aspettati un calo, e indaga solo se continua ad aggravarsi dopo un mese. Q: Devo inserire parole chiave negli URL? A: Inserisci le parole che descrivono la pagina, che di solito sono le parole chiave. Ciò che non devi fare è accumulare varianti: /servizi-sviluppo-web-sviluppo-web-economico è peggiore di /servizi-sviluppo-web sotto ogni aspetto, incluse le persone che lo vedono nei risultati. Q: Sottodominio o sottocartella per un blog? A: Sottocartella, nella maggior parte dei casi. sito.com/blog è più semplice da gestire, condivide i segnali accumulati dal dominio e non richiede una configurazione tecnica a parte. I sottodomini hanno senso quando la sezione è davvero un'applicazione distinta, ha un team distinto, o deve girare su un'infrastruttura diversa. Q: Per quanto tempo tenere i vecchi reindirizzamenti? A: A tempo indeterminato. Costano quasi nulla da mantenere e i link esterni ai tuoi vecchi URL non verranno mai aggiornati. Ciò che dovresti fare è ridurre periodicamente le catene create da migrazioni successive, perché ogni vecchio URL punti direttamente alla destinazione attuale in un solo salto. Q: I parametri negli URL danneggiano la SEO? A: Non sono dannosi di per sé, ma moltiplicano in fretta URL quasi duplicati: parametri di ordinamento, filtro e tracciamento possono generare migliaia di varianti di una pagina. Usa percorsi puliti per tutto ciò che vuoi indicizzare, e rendi canoniche o metti in noindex le varianti con parametri. ## Sviluppo di un sito multilingua: struttura, URL e flusso di lavoro https://websitedevelopment.biz/it/guides/sviluppo-sito-multilingua Aggiornato il 2026-08-07 · CMS Aggiungere lingue a un sito è di rado solo traduzione. Cambia la struttura degli URL, aggiunge un insieme di tag reciproci che si rompono in silenzio, e introduce un flusso di contenuti in cui una pagina diventa dodici pagine che possono divergere. Questa guida copre le decisioni strutturali, i requisiti tecnici, e il flusso di lavoro che impedisce alle traduzioni di invecchiare. ### Decidi per primo lo schema degli URL È la decisione costosa da revocare, perché tocca ogni URL, ogni reindirizzamento e ogni tag hreflang del sito. | Sottocartella | sito.com/it/guide | La maggior parte dei siti: il più semplice, un dominio accumula autorità | | Sottodominio | it.sito.com/guide | Infrastruttura separata o team separati | | Dominio nazionale | sito.it/guide | Forte impegno locale, e un sito a parte da gestire | | Parametro | sito.com/guide?lang=it | Da evitare: segnali deboli, rischio di duplicati | Qualunque cosa scegli, decidi separatamente se lo slug viene tradotto. Slug tradotti aiutano la pertinenza locale; slug identici sono più semplici da mantenere. Entrambe le scelte si difendono — cambiare idea dopo no. ### I requisiti tecnici Ciascuno di questi fallisce in silenzio, ed è per questo che tanti siti multilingua non hanno un hreflang funzionante pur avendo i tag. - hreflang reciproco. Ogni pagina di un insieme linguistico elenca tutte le altre, se stessa compresa. Un riferimento inverso mancante fa scartare il gruppo. - Codici coerenti. Lo stesso codice nell'HTML e nella sitemap. Due codici per una pagina rompono l'insieme. - x-default che punta al selettore di lingua o alla versione predefinita. - Attributi lang e dir corretti sull'elemento html di ogni versione. - Canonico autoreferenziale per lingua — non rendere mai canoniche le traduzioni verso l'originale. - Nessun reindirizzamento automatico per IP o lingua del browser. Rompe la scansione e scavalca una scelta deliberata; proponi invece un suggerimento. - Metadati tradotti. Titoli e descrizioni nella lingua di destinazione, non in quella di partenza. ### Un flusso di traduzione che regge Il modo di fallire non è la prima traduzione, è la quinta modifica alla pagina italiana che non raggiunge mai le altre undici. - Modella le traduzioni come versioni collegate di un unico elemento di contenuto, così il sistema sa che vanno insieme. - Tieni traccia di quali traduzioni sono superate rispetto alla fonte, e mostralo nell'interfaccia di modifica. - Decidi cosa succede quando manca una traduzione: ripiegare sulla lingua predefinita, o non pubblicare affatto quell'URL. - Non pubblicare mai un URL privo di traduzione: una pagina resa a metà in un'altra lingua è peggio di nessuna pagina. - Tieni una data di revisione per lingua, non per elemento di contenuto. - Dai contesto a chi traduce: una schermata o un'anteprima batte un foglio di calcolo di stringhe. - Decidi chi è responsabile di ogni lingua. Le lingue senza responsabile invecchiano per prime. La traduzione automatica come punto di partenza va bene; pubblicarla senza revisione no. Un output non rivisto si legge come non rivisto, ed è esattamente il tipo di contenuto di scarso valore su cui i motori sono sempre più espliciti. ### Oltre il testo La traduzione è la parte che tutti mettono a budget. Queste sono le parti che vengono dimenticate e causano errori visibili. | Date e numeri | Formato e separatori differiscono per area | | Valuta | Simbolo, posizione e convenzioni di arrotondamento | | Indirizzi e numeri di telefono | Ordine dei campi e regole di validazione | | Nomi | L'ordine di nome e cognome non è universale | | Lunghezza del testo | Tedesco e finlandese si allungano; le impaginazioni devono cedere | | Direzione di lettura | Arabo ed ebraico richiedono proprietà CSS logiche | | Immagini con testo | Serve una versione per lingua, oppure nessun testo nell'immagine | | Pagine legali | I requisiti differiscono per giurisdizione, non solo per lingua | Q: Devo reindirizzare automaticamente i visitatori alla loro lingua? A: No. Il reindirizzamento automatico per IP o lingua del browser interferisce con la scansione — un crawler da un paese può non vedere mai le altre versioni — e scavalca scelte deliberate, cosa irritante per chi legge in una seconda lingua. Mostra un suggerimento che si possa chiudere e lascia decidere alla persona. Q: La traduzione automatica è accettabile? A: Come prima bozza sì, e fa risparmiare denaro vero. Pubblicata senza revisione umana produce contenuti che si leggono come generati da una macchina, cosa che tocca sia le persone sia la valutazione di qualità della ricerca. L'approccio pragmatico è traduzione automatica più una revisione madrelingua, soprattutto per pagine che vendono o spiegano qualcosa di importante. Q: Cosa rompe hreflang più spesso? A: Tag non reciproci: la pagina A elenca la B, la B non elenca la A, e l'intero gruppo viene ignorato. Al secondo posto, codici discordanti tra HTML e sitemap. Entrambi si evitano generando hreflang da un'unica fonte che fa fede anziché mantenendo due elenchi. Q: Devo tradurre tutto il sito? A: No, e una traduzione parziale è normale. Traduci ciò che ha domanda in quel mercato e lascia che il resto esista solo nella lingua di partenza. Ciò che non devi fare è pubblicare un URL vuoto o tradotto a metà: o la pagina esiste correttamente in quella lingua, o non esiste affatto. ## Ottimizzare la velocità di un sito: un ordine di lavoro pratico https://websitedevelopment.biz/it/guides/ottimizzare-la-velocita-del-sito Aggiornato il 2026-08-07 · SEO Il lavoro sulla velocità ha una forma di Pareto marcata: una manciata di correzioni spiega la maggior parte del miglioramento sulla maggior parte dei siti, e sono quasi sempre immagini, risposta del server e script di terze parti. Questa guida copre in che ordine lavorare, come misurare se un cambiamento ha aiutato, e le ottimizzazioni che di solito non valgono lo sforzo. ### Misura prima di cambiare qualsiasi cosa Ottimizzare senza misurare significa correggere ciò che è più facile anziché ciò che è lento. Due misurazioni, poi al lavoro. - Procurati dati sul campo di visitatori veri: il rapporto Core Web Vitals in Search Console, o il tuo monitoraggio. - Esegui un test di laboratorio sui tre template più importanti, limitato a un telefono di fascia media in 4G. - Annota i numeri prima di iniziare. Senza un riferimento non puoi dire se un cambiamento ha aiutato. - Individua la risorsa singola più grande e la richiesta bloccante più grande di ogni template. - Annota a parte il Time to First Byte: se supera gli 800 ms, nessun lavoro sul front-end ti salverà. ### L'ordine che rende Grosso modo per miglioramento ottenuto per ora di sforzo, per un tipico sito editoriale o vetrina. | Ottimizzare e dimensionare correttamente le immagini | Grande | Basso | | Rimuovere gli script di terze parti inutilizzati | Grande | Basso: è soprattutto un compito politico | | Attivare cache e un CDN | Grande | Basso | | Correggere CSS e JS che bloccano il rendering | Medio-grande | Medio | | Ridurre il bundle JavaScript | Medio-grande | Medio-alto | | Correggere query di database lente | Grande dove si applica | Medio | | Ottimizzare il caricamento dei font | Medio | Basso | | Minificare e comprimere le risorse testuali | Piccolo | Basso: di solito già attivo | | Micro-ottimizzare i selettori CSS | Trascurabile | Non ne vale la pena | ### Immagini: di solito il guadagno più grande Sulla maggior parte dei siti le immagini sono la parte prevalente del peso di pagina, e la maggior parte viene servita diverse volte più grande di come viene mostrata. È il miglioramento grande meno costoso disponibile. - Servi WebP o AVIF; entrambi sono ampiamente supportati e tipicamente più leggeri del 25–50 % rispetto al JPEG a parità di qualità. - Genera più dimensioni e usa srcset con sizes perché i telefoni scarichino file di dimensione telefono. - Non servire mai un'immagine da 2000 px in uno spazio da 400 px: questo singolo errore è estremamente comune. - Carica in differita tutto ciò che sta sotto la piega, e nulla sopra. - Automatizzalo nella build o nel CMS. Le immagini ottimizzate a mano smettono di esserlo la prima volta che qualcun altro ne carica una. - Rimuovi i metadati; l'EXIF della fotocamera può pesare decine di kilobyte per file. L'automazione è il punto. Una passata di ottimizzazione una tantum si degrada nel giro di mesi mentre si aggiungono contenuti, e nessuno se ne accorge finché il peso di pagina non è raddoppiato. ### Script di terze parti e server Sono le due aree in cui il problema è di solito organizzativo anziché tecnico: nessuno è responsabile del gestore di tag, e nessuno è responsabile della scelta di hosting. | Gestore di tag con tag sconosciuti | Verificare ogni tag; cancellare tutto ciò che nessuno sa giustificare | | Widget di chat caricato su ogni pagina | Caricarlo all'interazione, o solo dove serve assistenza | | Più strumenti di statistiche | Tenerne uno; ciascuno è uno script completo e una connessione | | Script di test A/B che blocca il rendering | Spostarlo lato server, o accettare uno sfarfallio e caricarlo async | | TTFB lento su hosting condiviso | Aggiungere cache di pagina intera; passare a un piano superiore se persiste | | Query di database senza cache | Mettere in cache quelle costose; aggiungere indici per quelle frequenti | | Nessun CDN | Aggiungerne uno: è la correzione di latenza globale meno costosa che esista | Gli script di terze parti sono la fonte più affidabile di rallentamenti inspiegabili, perché cambiano senza avvisarti e stanno fuori dal tuo processo di rilascio. Q: Qual è un buon tempo di caricamento? A: Gli obiettivi utili sono le soglie dei Core Web Vitals anziché un singolo numero di caricamento: LCP sotto 2,5 secondi e Time to First Byte sotto 800 ms. Il tempo di caricamento totale è una misura scadente perché una pagina può essere usabile molto prima che ogni risorsa finisca, e inutilizzabile molto prima di quello su un dispositivo lento. Q: Un sito più veloce aumenta le conversioni? A: In genere sì, e l'effetto è maggiore dove le pagine sono attualmente lente e i visitatori stanno su reti mobili. Il guadagno da tre secondi a due è molto maggiore di quello da uno e mezzo a uno. Se il tuo sito è già veloce, investi lo sforzo in contenuti e chiarezza: il ritorno è migliore. Q: I plugin di cache risolvono tutto? A: Risolvono bene una cosa vera — il lavoro ripetuto del server per la stessa pagina — e possono creare problemi nuovi, in particolare con utenti autenticati, carrelli e moduli. Inoltre non fanno nulla contro immagini sovradimensionate e script di terze parti, che di solito sono i problemi maggiori. Utili, non sufficienti. Q: Il rendering lato server conviene per la velocità? A: Se oggi le tue pagine vengono rese solo nel browser, sì: il rendering lato server o la generazione statica elimina un giro completo prima che compaia il contenuto, e nel frattempo aiuta l'indicizzazione. Se le tue pagine sono già HTML servito, la domanda non si pone: il beneficio ce l'hai già. ## Core Web Vitals: cosa sposta davvero i numeri https://websitedevelopment.biz/it/guides/core-web-vitals-per-sviluppatori Aggiornato il 2026-08-07 · SEO I Core Web Vitals sono tre misurazioni sul campo di come si percepisce una pagina: quanto ci mette a comparire il contenuto principale, quanto si muove durante il caricamento, e quanto in fretta risponde all'input. Sono un segnale di posizionamento e, cosa più importante, sono correlati al fatto che le persone restino. Questa guida copre cosa misura ciascuna metrica, le cause precise dietro i punteggi scarsi, e le correzioni che spostano i dati sul campo e non solo i punteggi di laboratorio. ### Cosa misurano le tre metriche Ciascuna ha una soglia per «buono» e un piccolo numero di cause abituali. Nota che il numero che conta per il posizionamento sono i dati sul campo di visitatori veri, non un punteggio di laboratorio dal tuo portatile. | LCP | Sotto 2,5 s | Tempo fino al disegno dell'elemento visibile più grande | Immagine di testata non ottimizzata, server lento, CSS che blocca il rendering | | CLS | Sotto 0,1 | Quanto si muove l'impaginazione durante il caricamento | Immagini senza dimensioni, banner inseriti, font web tardivi | | INP | Sotto 200 ms | Reattività all'interazione dell'utente | Lunghe attività JavaScript che bloccano il thread principale | Gli strumenti di laboratorio misurano un caricamento su una macchina. I dati sul campo sono il 75° percentile di visite reali, che comprende telefoni vecchi su reti scadenti — proprio i visitatori più propensi ad andarsene. ### Correggere l'LCP L'LCP è quasi sempre un'immagine o un titolo bloccato dietro qualcos'altro. Procedi in ordine; i primi due punti risolvono la maggior parte dei siti. - Individua il vero elemento LCP nei dati sul campo. Ottimizzare l'immagine sbagliata è lo sforzo sprecato più comune. - Non caricare mai in differita l'immagine dell'LCP. Dalle invece fetchpriority="high". - Servila in un formato moderno alla dimensione in cui viene mostrata, con srcset per gli schermi più piccoli. - Precarica il font usato dal testo dell'LCP e usa font-display: swap perché il testo non sia invisibile durante l'attesa. - Togli dall'head il CSS e il JavaScript che bloccano il rendering; incorpora il CSS critico se la pagina è abbastanza piccola. - Riduci il Time to First Byte con cache e un CDN: nessun lavoro sul front-end compensa un server lento. - Taglia gli script di terze parti nel percorso critico. Ciascuno è una risoluzione DNS, una connessione e un file imprevedibile. ### Correggere il CLS Lo spostamento dell'impaginazione è quasi del tutto evitabile e le correzioni costano poco. È anche la metrica che i visitatori avvertono più fisicamente: è ciò che fa toccare la cosa sbagliata. - Imposta gli attributi width e height su ogni immagine e video perché il browser riservi lo spazio. - Riserva spazio per pubblicità, incorporamenti e iframe con un contenitore a rapporto d'aspetto fisso. - Non inserire mai contenuto sopra quello esistente dopo il caricamento: i banner dei cookie vanno in basso, o sovrapposti. - Allinea le metriche del font di ripiego a quelle del font web, o usa size-adjust, perché lo scambio non ricomponga la pagina. - Evita di animare proprietà di impaginazione. Anima transform e opacity, che non provocano ricalcolo. - Dai alle sezioni caricate dinamicamente una min-height perché non si espandano da zero. ### Correggere l'INP L'INP ha sostituito il First Input Delay ed è più difficile, perché misura ogni interazione della visita anziché solo la prima. Un INP scarso è quasi sempre troppo JavaScript in esecuzione sul thread principale. | Grande bundle analizzato al caricamento | Suddividere il codice; caricare solo ciò che serve alla pagina | | Attività lunghe oltre i 50 ms | Spezzare il lavoro in blocchi e restituire il thread principale | | Gestori di evento costosi | Applicare il debounce e togliere il lavoro pesante dal percorso di interazione | | Tag di terze parti pesanti | Caricare dopo l'interazione, o rimuovere: verifica cosa rende ciascuno | | DOM grande (oltre 10.000 nodi) | Virtualizzare gli elenchi lunghi; semplificare il markup molto annidato | | Sollecitazione dell'impaginazione nei gestori | Raggruppare letture e scritture anziché alternarle | Sui siti editoriali la correzione INP di maggior valore consiste di solito nel cancellare JavaScript anziché ottimizzarlo. Chiediti cosa rende ogni script; i gestori di tag accumulano script che nessuno ricorda di aver aggiunto. Q: Quanto incidono i Core Web Vitals sul posizionamento? A: Sono un segnale reale ma moderato, e agiscono da spareggio anziché da sostituto della pertinenza. Una pagina veloce sull'argomento sbagliato non supera una pagina più lenta che risponde alla domanda. L'argomento più forte per correggerli è comportamentale: pagine lente e che saltano perdono visitatori prima ancora che entri in gioco il posizionamento. Q: Perché il mio punteggio Lighthouse è buono e i dati sul campo scarsi? A: Perché Lighthouse simula un caricamento sulla tua macchina con la tua connessione, e i dati sul campo sono il 75° percentile di visite reali, telefoni di tre anni su reti mobili congestionate compresi. Quando i due divergono, contano i dati sul campo. Usa gli strumenti di laboratorio per diagnosticare, non per dare voti. Q: Devo correggere tutte e tre le metriche? A: Correggi quelle che stanno fallendo, nell'ordine di ciò che vivono i tuoi visitatori. Il CLS è di solito il meno costoso da correggere e il più fastidioso per gli utenti, quindi è un buon punto di partenza. L'LCP ha l'effetto maggiore sul fatto che le persone aspettino. L'INP conta di più sui siti interattivi e di meno sugli articoli statici. Q: Quanto ci vuole perché i miglioramenti si vedano? A: I dati sul campo sono una finestra mobile di 28 giorni, quindi un movimento significativo richiede circa quattro settimane da quando una correzione raggiunge tutti i visitatori. Non giudicare un cambiamento dopo tre giorni. Controlla invece subito le metriche di laboratorio per confermare che la correzione abbia fatto ciò che ti aspettavi. ## Migrazione di CMS: come trasferirsi senza perdere traffico https://websitedevelopment.biz/it/guides/guida-migrazione-cms Aggiornato il 2026-08-07 · CMS Una migrazione di CMS sposta i contenuti da un sistema a un altro. Il rischio non è tecnico — esportazioni e importazioni sono problemi risolti — ma è che lungo il percorso cambino struttura, URL e metadati, e i motori di ricerca notano tutti e tre. Questa guida copre la sequenza che preserva il traffico, la verifica che dovrebbe venire per prima, e cosa sorvegliare dopo. ### Verifica prima di spostare qualsiasi cosa Migrare tutto è il comportamento predefinito e di solito la scelta sbagliata. Quasi tutti i siti si portano dietro una lunga coda di pagine senza traffico, senza link e senza scopo, e spostarle importa il problema nel nuovo sistema. - Scansiona il sito esistente per ottenere ogni URL che esiste davvero. - Estrai dodici mesi di traffico per URL, più i link in entrata. - Classifica ogni pagina: migrare così com'è, riscrivere, unire a un'altra, o eliminare. - Tutto ciò che ha traffico o link deve avere una destinazione. Il resto può andare. - Annota quali pagine portano dati strutturati, campi su misura o template insoliti. - Esporta i metadati — titoli e descrizioni — a parte. È il bene più spesso perduto in una migrazione. Unire pagine povere in pagine più forti durante una migrazione è uno dei pochi esiti SEO affidabilmente positivi dell'intero esercizio. Reindirizza quelle unite verso la sopravvissuta. ### Modella i contenuti prima di importarli La tentazione è ricreare esattamente la vecchia struttura. Questo importa i vecchi compromessi. Modella i contenuti come dovrebbero essere, poi fai corrispondere i vecchi dati. | Tipi di contenuto | Cosa differisce davvero: pagina, articolo, prodotto, persona, evento | | Campi | Campi strutturati anziché un blocco di HTML dove è praticabile | | Tassonomie | Quali categorie ed etichette sopravvivono; quasi tutti i siti ne hanno troppe | | Media | Dove risiedono i file e se i percorsi cambiano | | Autori e date | Conservare le date di pubblicazione vere; non riportarle tutte a oggi | | Metadati | Titoli, descrizioni e canonici mappati in modo esplicito | | Tabella dei reindirizzamenti | Vecchio URL su nuovo URL, uno a uno, costruita strada facendo | Azzerare le date di pubblicazione all'importazione è un incidente comune e distrugge in un colpo il segnale di freschezza dell'intero archivio. ### Conserva gli URL, e reindirizza ciò che non puoi Il fattore che più determina se una migrazione costa traffico. - Conserva la struttura degli URL esistente a meno che non sia davvero rotta. «Il nuovo CMS preferisce un altro schema» non è una ragione sufficiente. - Dove gli URL devono cambiare, mappa uno a uno — mai verso una pagina di categoria né verso la home. - Usa reindirizzamenti 301, e verifica che ciascuno sia un solo salto. - Reindirizza anche i file media. Le immagini accumulano link e compaiono nella ricerca immagini. - Conserva i reindirizzamenti a tempo indeterminato; i link esterni non vengono mai aggiornati. - Collauda la tabella dei reindirizzamenti in preproduzione con l'elenco completo prima del lancio, non con un campione. ### Il lancio e le sei settimane successive La migrazione non finisce al passaggio. La maggior parte dei problemi diventa visibile nel mese seguente. - Lancia quando puoi sorvegliare. Non di venerdì, non prima di una festività. - Verifica subito robots.txt, meta robots, canonici e sitemap in produzione. - Passa l'elenco completo dei reindirizzamenti contro la produzione e cerca 404 e catene. - Invia la nuova sitemap in Search Console e sorveglia la copertura ogni giorno per una settimana. - Confronta le pagine principali con il periodo precedente; una pagina che cala nettamente ha di solito una causa precisa. - Sorveglia i registri del server per i 404 dei crawler: trovano gli URL dimenticati prima delle statistiche. - Aspettati oscillazioni per due-sei settimane; indaga su un calo che continua ad aggravarsi dopo un mese. - Tieni il vecchio sistema in sola lettura per un po', per poter verificare cosa conteneva una pagina. Q: Perderò traffico di ricerca migrando? A: Aspettati un calo di alcune settimane anche facendo tutto correttamente: i motori devono riscansionare e rivalutare. Con reindirizzamenti puliti e contenuti conservati, il traffico torna normalmente al livello precedente in due-sei settimane. Una perdita permanente si riconduce quasi sempre a reindirizzamenti dimenticati, contenuti modificati, o pagine eliminate in silenzio. Q: Devo rifare il design nello stesso momento? A: È allettante e rende la diagnosi molto più difficile: quando il traffico si muove, non puoi dire se sia stata la migrazione o il design. Se puoi separarli, migra prima con i template esistenti, conferma la stabilità, poi rifai il design. Se devono andare insieme, sii ancora più rigoroso nel conservare URL e contenuti. Q: Come migro contenuti che non si trasferiscono in modo pulito? A: C'è sempre contenuto che resiste all'automazione: impaginazioni su misura, widget incorporati, tabelle fatte a mano. Individuali durante la verifica e metti a budget tempo manuale. Provare ad automatizzare l'ultimo 5 % costa di solito più che farlo a mano, e dà risultati peggiori. Q: Devo tenere in funzione il vecchio CMS? A: Tienilo raggiungibile ma non pubblico per qualche mese: in sola lettura, bloccato ai motori, su un indirizzo interno. È prezioso per verificare cosa diceva una pagina quando qualcosa sembra sbagliato. Poi dismettilo come si deve: un'installazione pubblica abbandonata è un rischio di sicurezza. ## Checklist di SEO tecnico per chi sviluppa siti web https://websitedevelopment.biz/it/guides/checklist-seo-tecnico Aggiornato il 2026-08-07 · SEO Il SEO tecnico è la parte del lavoro sui motori che vive nel codice anziché in un piano editoriale. È in gran parte una checklist, e la maggior parte è verificabile anziché opinabile. Questa guida è quella checklist, raggruppata per il problema che ogni voce previene, con gli errori abbastanza frequenti da meritare di essere nominati. ### Controllo dell'indicizzazione L'obiettivo qui è che siano indicizzate esattamente le pagine che vuoi, e nient'altro: niente copie di preproduzione, niente permutazioni di filtri, niente duplicati per la stampa. - Un solo nome host canonico; ogni altra variante vi reindirizza con un 301, HTTP e il gemello con o senza www compresi. - Un canonico autoreferenziale su ogni pagina indicizzabile. - noindex, follow sulle pagine povere o duplicate: risultati della ricerca interna, combinazioni di filtri, pagine di ringraziamento. - Non bloccare mai nel robots.txt una pagina che porta un noindex: il tag non potrà mai essere letto, e l'URL resta nell'indice. - Preproduzione bloccata con autenticazione HTTP, non solo con robots.txt. - Gestione dei parametri decisa: quali stringhe di query creano una pagina distinta e quali no. noindex e un blocco nel robots.txt fanno cose opposte e si annullano. Se vuoi che una pagina sparisca, consenti la scansione perché il noindex possa essere visto. ### Reindirizzamenti e codici di stato I reindirizzamenti sono il punto in cui i rilanci perdono traffico in silenzio. I guasti sono meccanici e facili da collaudare prima del lancio. | Pagina spostata definitivamente | 301 alla pagina equivalente | 302, oppure reindirizzamento alla home | | Pagina eliminata, nessun equivalente | 410 o 404 | Soft 404: una pagina «non trovato» che restituisce 200 | | Temporaneamente non disponibile | 503 con Retry-After | Restituire 200 con un messaggio di errore | | Varianti con e senza barra finale | Una forma canonica, l'altra con 301 | Entrambe che servono lo stesso contenuto con 200 | | Vecchio dominio | 301 mappata pagina per pagina | Tutto alla nuova home | | Catene di reindirizzamenti | Ridurre a un solo salto | A → B → C → D, con perdita di segnale a ogni passo | ### Paginazione, faccette e duplicazione Le pagine di elenco generano i maggiori problemi di indice, perché una manciata di filtri può produrre migliaia di combinazioni di URL che sembrano tutte quasi duplicate. - Pagine paginate: link scansionabili veri, ogni pagina autocanonica; non rendere canonica la pagina 2 verso la pagina 1. - Combinazioni di filtri: noindex, follow per impostazione predefinita; indicizza solo le poche che corrispondono a una domanda di ricerca reale. - Ordinamenti: non creare mai un nuovo URL indicizzabile. Stesso contenuto, sequenza diversa. - Identificatori di sessione e parametri di tracciamento: rimuovili, o rendi canonico verso l'URL pulito. - Duplicati per la stampa o di tipo AMP: canonico verso la versione principale. - Prodotti in più categorie: un solo URL canonico, collegato da tutte. Una navigazione a faccette lasciata aperta è la causa più comune di gonfiore dell'indice, e si riassorbe lentamente. Prevenirla in fase di costruzione costa molto meno che disfarla dopo. ### Dati strutturati e impostazione internazionale Due aree in cui un errore meccanico disattiva in silenzio l'intera funzionalità. | Markup Article | Solo su articoli veri, con date vere | Date di freschezza inventate fanno ignorare la funzionalità | | Markup Product | Prezzo e disponibilità devono corrispondere alla pagina | La discrepanza provoca un'azione manuale | | Markup FAQ | Solo per domande visibili sulla pagina | Il contenuto nascosto è una violazione delle linee guida | | Briciole di pane | Devono corrispondere al percorso visibile | Percorsi divergenti vengono semplicemente ignorati | | hreflang | Reciproco su ogni pagina dell'insieme | Tag unidirezionali fanno scartare l'intero gruppo | | Codici hreflang | Lo stesso codice nell'HTML e nella sitemap | Due codici diversi per la stessa pagina rompono il gruppo | | x-default | Punta al selettore di lingua o alla versione predefinita | Se manca si perde il comportamento di ripiego | Q: Come trovo problemi di SEO tecnico su un sito esistente? A: Scansionalo con un crawler da scrivania e confronta il risultato con la tua sitemap e con la copertura in Search Console. Dove i tre elenchi non concordano stanno i problemi: URL nella scansione ma non nella sitemap, URL indicizzati ma non nella scansione, e pagine escluse per motivi che non avevi previsto. Q: Le catene di reindirizzamenti contano davvero? A: Sì, per due motivi. Ogni salto aggiunge latenza per gli utenti veri, e i crawler smettono di seguirle dopo pochi. Dopo un paio di migrazioni è comune trovare catene profonde quattro o cinque livelli che nessuno aveva pianificato. Riducile perché ogni vecchio URL punti direttamente alla destinazione finale in un solo salto. Q: Devo mettere in noindex le pagine di tag e categoria? A: Solo se sono davvero povere. Una pagina di categoria con una descrizione vera, un elenco curato e link interni è una pagina d'ingresso legittima e spesso forte. Una pagina di tag con due articoli e nessun testo è gonfiore dell'indice. Giudica ogni template su quanto risponda a una domanda che qualcuno pone davvero. Q: Cosa rompe hreflang più spesso? A: Tag non reciproci. Se la pagina inglese elenca l'alternativa italiana ma quella italiana non elenca l'inglese, il gruppo viene scartato. Il secondo guasto più comune è dichiarare un codice nell'HTML e uno diverso nella sitemap per la stessa pagina. Genera entrambi dalla stessa fonte perché non possano divergere. ## WordPress, Webflow o sviluppo su misura https://websitedevelopment.biz/it/guides/wordpress-webflow-o-su-misura Aggiornato il 2026-08-07 · CMS Per un sito aziendale, la maggior parte delle decisioni si riduce a queste tre. Non sono concorrenti in senso stretto: si adattano a team, budget e propensione alla manutenzione diversi. Questa guida le confronta per modello operativo, costo su tre anni e difficoltà di uscita, che sono i fattori che decidono davvero se la scelta si rivela azzeccata. ### Le tre in una tabella Il riepilogo, prima del dettaglio. | Modello | Open source auto-ospitato | Costruttore visuale in hosting | Il tuo codice, il tuo hosting | | Modifica | Buona, familiare a molti | Controllo visuale eccellente | Buona quanto la costruisci | | Chi lo mantiene | Tu | Il fornitore | Tu | | Estensibilità | Ecosistema di plugin molto ampio | Limitata, in miglioramento | Illimitata | | Prestazioni | Dipendono molto dalla realizzazione | Generalmente buone | Buone quanto paghi | | Costo di esercizio | Hosting più plugin più tempo di sviluppo | Abbonamento per sito | Hosting più tempo di sviluppo | | Uscita | Accesso completo al database | L'esportazione è limitata e con perdite | È il tuo codice | ### Dove ciascuna è davvero forte Scegliere in base al punto di forza che corrisponde alla tua situazione è più affidabile che scegliere in base alla debolezza che temi. - WordPress: siti editoriali, blog, siti che hanno bisogno di un plugin specifico, team con competenze WordPress, e tutto ciò in cui un grande ecosistema evita sviluppo su misura. - Webflow: siti di marketing centrati sul design dove il controllo visuale conta e non c'è nessuno a mantenere l'infrastruttura. Buono anche per team che devono pubblicare in fretta pagine d'ingresso. - Su misura: applicazioni, integrazioni insolite, obiettivi rigorosi di prestazioni o accessibilità, o un sito che è esso stesso il prodotto. Il disallineamento più comune è un team piccolo che sceglie lo sviluppo su misura per un sito vetrina. Non è sbagliato tecnicamente; è semplicemente denaro che renderebbe di più investito in contenuti. ### Costo su tre anni, onestamente Una forma approssimativa anziché numeri precisi, per un sito aziendale di media dimensione. | Realizzazione | Basso-medio | Basso-medio | Alto | | Hosting | Basso-medio | Incluso nell'abbonamento | Basso-medio | | Licenze e plugin | Continue, crescono nel tempo | Incluse, a scaglioni d'uso | Minime | | Manutenzione | Media, continua | Bassa | Media | | Tempo di sviluppo per le modifiche | Basso per i contenuti, medio per le funzionalità | Basso | Medio | | Costo del rischio | Compromissione se non aggiornato | Cambi di prezzo e politica del fornitore | Dipendenza da una persona chiave | ### Difficoltà di uscita Quanto sia difficile andarsene dovrebbe far parte della decisione, perché determina se la scelta è reversibile. - Su misura: in linea di principio il più facile — hai codice, database e hosting. Il rischio è la documentazione e se qualcun altro può lavorarci. - WordPress: lineare. I contenuti si esportano bene; il lavoro sta nel ricostruire ciò che facevano i plugin. - Webflow: il più difficile. Puoi esportare HTML e CSS statici, ma i contenuti del CMS, i moduli e le interazioni non seguono, quindi andarsene equivale a ricostruire. Poni la domanda sull'uscita durante la selezione, non durante una controversia. È la domanda meno costosa da fare e la più costosa da aver saltato. Q: Quale è migliore per la SEO? A: Tutte e tre possono essere eccellenti, e tutte e tre possono essere scarse. Ciò che conta è HTML reso lato server, controllo su titoli e canonici, URL puliti, sitemap, dati strutturati e velocità. WordPress ti dà plugin per questo, Webflow lo integra con qualche limite, il su misura dà controllo totale e responsabilità totale. La qualità della realizzazione pesa più della scelta di piattaforma. Q: WordPress è poco sicuro? A: Il nucleo di WordPress è mantenuto attivamente ed è ragionevolmente sicuro. La maggior parte delle compromissioni viene da plugin obsoleti, temi abbandonati e credenziali di amministrazione deboli. Un WordPress aggiornato con pochi plugin e autenticazione a due fattori va bene; un sito con quaranta plugin che nessuno aggiorna no, ed è una scelta di manutenzione, non una proprietà della piattaforma. Q: Webflow regge un sito grande? A: Regge bene i siti editoriali di media dimensione e ha limiti sul numero di elementi del CMS e sulla struttura delle raccolte che vale la pena confrontare con il tuo modello di contenuto reale prima di impegnarti. Per un catalogo grande e complesso o molta logica su misura è di solito lo strumento sbagliato — non perché sia debole, ma perché non punta a quello. Q: Quando conviene lo sviluppo su misura? A: Quando il sito fa qualcosa di specifico della tua attività contro cui gli strumenti standard fanno resistenza: un configuratore, un percorso di prenotazione insolito, un'integrazione profonda con i tuoi sistemi operativi, o requisiti rigorosi di prestazioni e accessibilità. Un design distintivo da solo è raramente una ragione sufficiente, perché un tema su misura su un CMS lo ottiene per molto meno. ## Basi SEO nello sviluppo web: cosa integrare dall'inizio https://websitedevelopment.biz/it/guides/basi-seo-sviluppo-web Aggiornato il 2026-08-07 · SEO Buona parte del SEO non è affatto marketing: sono decisioni prese durante lo sviluppo, poco costose in fase di costruzione e care in seguito. La struttura degli URL, la strategia di rendering, il collegamento interno e i metadati modificabili rientrano tutti in questa categoria. Questa guida copre cosa integrare fin dall'inizio, grosso modo in ordine di quanto sia doloroso aggiungerlo dopo. ### Assicurati che il sito possa essere scansionato e indicizzato Tutto il resto è irrilevante se i motori non riescono a raggiungere o leggere le tue pagine. È anche qui che si concentrano gli errori del giorno del lancio. - Il robots.txt di produzione consente la scansione. La copia di preproduzione non deve essere rilasciata con esso. - Nessun tag noindex sfuggito e riportato dalla preproduzione. - Ogni pagina ha un URL canonico autoreferenziale, ed esiste un solo nome host canonico. - Il contenuto è nell'HTML o reso lato server. Se compare solo dopo l'esecuzione del JavaScript, l'indicizzazione diventa più lenta e meno affidabile. - Una sitemap XML che elenchi solo URL indicizzabili e canonici, non varianti filtrate o paginate. - Ogni pagina indicizzabile ha almeno un link interno. Le pagine orfane vengono scansionate a malapena. - Codici di stato coerenti: 200 per le pagine vere, 404 per quelle mancanti, 301 per quelle spostate. Il fallimento di lancio più comune in questo elenco è il robots.txt di preproduzione che arriva in produzione. Controllalo dall'esterno della tua rete il giorno del lancio. ### Una struttura che i motori possano leggere Le decisioni strutturali sono quelle dolorose da cambiare dopo, perché cambiarle significa reindirizzamenti e perdita dei segnali accumulati. | Schema di URL | Breve, minuscolo, con trattini, stabile | Alto: reindirizzamenti e segnali persi | | Gerarchia dei titoli | Un H1, nessun livello saltato | Basso | | Collegamento interno | Pilastri che collegano le pagine di dettaglio e viceversa | Medio | | Paginazione | Link scansionabili, non solo JavaScript | Medio | | Navigazione a faccette | noindex sulle combinazioni di filtri | Alto: il gonfiore dell'indice si riassorbe lentamente | | Versioni linguistiche | URL con prefisso più hreflang reciproco | Molto alto | ### Metadati che il tuo team possa davvero modificare Un errore ricorrente in realizzazione è generare titoli e descrizioni da un template senza modo di sovrascriverli. Sei mesi dopo il marketing deve cambiare il titolo di una pagina e la risposta è un ticket allo sviluppo. - Tag title modificabile per pagina, con un valore predefinito generato sensato. - Meta descrizione modificabile, con un contatore di caratteri visibile nel CMS. - Titolo, descrizione e immagine Open Graph modificabili per i link condivisi. - Dati strutturati sui template che li supportano: Article, Product, FAQ, Breadcrumb, Organization. - Un interruttore noindex per pagina, per le pagine che devono esistere ma non posizionarsi. - Canonico automatico, con sovrascrittura manuale per il caso raro che ne abbia bisogno. Marca solo ciò che è davvero visibile sulla pagina. Dati strutturati che descrivono contenuti che un visitatore non può vedere sono una violazione delle linee guida, non una scorciatoia. ### Velocità e stabilità come requisiti di realizzazione L'esperienza di pagina fa parte della realizzazione, non di un progetto di ottimizzazione successivo. Aggiungere velocità a un sito finito di solito significa disfare decisioni anziché aggiungere codice. | Largest Contentful Paint | Sotto 2,5 s | Dare priorità all'immagine di testata, evitare risorse che bloccano il rendering | | Cumulative Layout Shift | Sotto 0,1 | width e height sulle immagini, spazio riservato per gli incorporamenti | | Interaction to Next Paint | Sotto 200 ms | Meno JavaScript e non bloccare il thread principale | | Peso di pagina | Il più basso che il design consenta | Formati di immagine moderni, nessuna libreria inutilizzata | | Time to First Byte | Sotto 800 ms | Cache, un CDN e query di database sensate | Q: Il SEO deve stare nel brief di sviluppo? A: Le parti tecniche sì: scansionabilità, struttura degli URL, metadati modificabili, dati strutturati, obiettivi di prestazione e la mappa dei reindirizzamenti. La strategia dei contenuti e la costruzione di link sono lavoro a parte con un profilo diverso. Mettere i requisiti tecnici nel brief significa che vengono quotati anziché scoperti dopo il lancio, quando costano diverse volte tanto. Q: Un framework JavaScript danneggia il SEO? A: Può, se le pagine vengono rese solo nel browser. I motori eseguono JavaScript ma in ritardo e non sempre completamente, quindi il rendering solo lato client rende l'indicizzazione più lenta e meno affidabile. Il rendering lato server o la generazione statica elimina il problema. Per un sito editoriale la risposta più semplice è di solito mettere il contenuto nell'HTML. Q: Quanto tempo dopo il lancio prima di vedere traffico di ricerca? A: Per un dominio nuovo, tipicamente settimane per l'indicizzazione e mesi prima di posizioni significative: i siti nuovi non si posizionano in fretta indipendentemente dalla qualità tecnica. Per il rilancio di un sito esistente con reindirizzamenti puliti, conta due-sei settimane di oscillazione prima di riassestarsi intorno al livello precedente. Q: Mi serve un plugin SEO? A: Su un CMS, un plugin è un modo comodo per dare alla redazione il controllo su titoli, descrizioni, canonici e sitemap. Non è una strategia, e il suo output predefinito non sostituisce qualcuno che decida di cosa debba parlare ogni pagina. Su uno sviluppo su misura la stessa funzionalità di solito viene scritta direttamente e risulta più leggera. ## CMS headless o tradizionale: quale è adatto al tuo sito? https://websitedevelopment.biz/it/guides/cms-headless-o-tradizionale Aggiornato il 2026-08-07 · CMS Un CMS tradizionale conserva i contenuti e produce le pagine. Un CMS headless conserva i contenuti e li consegna tramite un'API, lasciando interamente a te il rendering. Quella singola differenza si ripercuote su tutto: anteprima, costo, struttura del team e con quanta rapidità una persona del marketing può cambiare una pagina. Questa guida copre cosa guadagni, cosa perdi, e dove sta la via di mezzo. ### La differenza vera Tutto il resto discende da dove avviene il rendering. | Rendering | Il CMS produce l'HTML | Lo fa il tuo front-end | | Template | Dentro il CMS | Nel tuo codice | | Anteprima | Integrata e fedele | Devi costruirla | | Canali | Un sito web | Sito, app, totem, qualsiasi cosa possa chiamare un'API | | Libertà sul front-end | Limitata dal CMS | Totale | | Tempo fino alla prima pagina | Rapido | Lento: nulla appare finché non lo costruisci | | Chi serve per un cambio di impaginazione | Spesso la redazione | Chi sviluppa | ### Cosa perdi passando all'headless Le funzionalità che un CMS tradizionale offre gratis sono quelle che mancano, e di solito si scoprono dopo aver deciso. - L'anteprima. La redazione si aspetta di vedere la pagina prima di pubblicare. Nell'headless è una funzionalità che costruisci e mantieni. - La composizione delle pagine. Disporre blocchi su una pagina è un problema risolto nei sistemi tradizionali e un cantiere in quelli headless. - Menu e navigazione. Anche questi diventano qualcosa che modelli e costruisci tu. - I moduli. Con l'API non arriva alcun costruttore di moduli. - Reindirizzamenti e gestione degli URL. A tuo carico. - L'ecosistema di plugin. Campi SEO, sitemap, reindirizzamenti: tutto diventa sviluppo su misura. - La rapidità delle piccole modifiche. «Sposta su quella sezione» smette di essere un compito della redazione. Lo schema ricorrente nei progetti headless deludenti è un team marketing che prima poteva cambiare una pagina da solo e ora apre ticket. ### Quando l'headless è la scelta giusta Si adatta a una forma di problema precisa, e fuori da quella forma è flessibilità costosa. | Contenuti mostrati in un sito e in un'app mobile | Forte: è il caso centrale | | Più siti che condividono una fonte di contenuti | Forte | | Requisiti di front-end che il CMS non può soddisfare | Forte | | Esiste già un team front-end dedicato | Buona | | Sito di marketing con un team piccolo | Scarsa: perdi rapidità e guadagni ticket | | Sito editoriale con frequenti cambi di impaginazione | Scarsa | | «È l'approccio moderno» | Non è una ragione | ### La via di mezzo Alla maggior parte dei siti serve meglio qualcosa tra i due estremi. - CMS tradizionale con tema su misura. Controllo totale del front-end, e anteprima e composizione continuano a funzionare. - CMS tradizionale usato in modo headless per una sola superficie. Il sito resta reso dal CMS; l'app consuma un'API. - CMS headless con un generatore di siti statici. La redazione ha una buona interfaccia, il sito è statico e veloce; l'anteprima richiede lavoro. - CMS ibrido. Sistemi che offrono sia pagine rese sia un'API — spesso la risposta pragmatica. - Generatore statico con editor basato su git. Costo e rischio molto bassi per contenuti che sono soprattutto documenti. Un tema su misura su un CMS tradizionale ti dà la maggior parte della libertà di front-end per cui si passa all'headless, senza rinunciare ad anteprima, composizione ed ecosistema. Q: L'headless è migliore per le prestazioni? A: Può esserlo, perché controlli esattamente cosa viene inviato — ma il guadagno viene dalla generazione statica e da un front-end leggero, non dall'API. Un CMS tradizionale ben costruito con cache adeguata e tema su misura è veloce lo stesso. Le prestazioni sono conseguenza di come costruisci, non di dove sono conservati i contenuti. Q: L'headless è migliore per la SEO? A: Neutro nel migliore dei casi, e peggiore se le pagine vengono rese solo nel browser. Tutto ciò che serve al SEO tecnico — HTML reso lato server, canonici, sitemap, dati strutturati, reindirizzamenti — nell'headless devi implementarlo tu, mentre i sistemi tradizionali hanno plugin maturi. L'headless va bene per la SEO con disciplina e delude senza. Q: La redazione può vedere un'anteprima con l'headless? A: Sì, ma la costruisci tu: una modalità anteprima nel front-end che recuperi i contenuti in bozza e li mostri. Mettila a budget esplicitamente. I progetti che saltano l'anteprima finiscono con la redazione che pubblica in produzione per vedere come viene, che è esattamente ciò che un CMS dovrebbe evitare. Q: Quanto costa l'headless rispetto al tradizionale? A: La costruzione iniziale è tipicamente più alta, perché stai costruendo il front-end più le funzionalità che un CMS tradizionale includeva. I costi di esercizio possono essere più bassi, soprattutto con la generazione statica. La differenza maggiore nel lungo periodo è che più modifiche di routine richiedono tempo di sviluppo, un costo continuo che non compare nel preventivo di realizzazione. ## Ti serve un sistema di design per il tuo sito? https://websitedevelopment.biz/it/guides/sistema-di-design-per-siti-web Aggiornato il 2026-08-07 · Web design Un sistema di design è un insieme di componenti riutilizzabili e le regole per usarli. Su un sito grande con più persone che fanno modifiche elimina moltissimo lavoro decisionale duplicato. Su un sito vetrina di cinque pagine è un costo senza ritorno. Questa guida copre dove passa la linea, cosa contiene davvero un sistema minimo utile, e cosa fare invece quando un sistema completo non si giustifica. ### Quando si ripaga e quando no Il valore nasce dalla ripetizione: la stessa decisione presa una volta invece di quaranta, e in modo coerente. Se la ripetizione non c'è, non c'è nemmeno il valore. | Sito vetrina di cinque pagine, un designer, modifiche rare | No: basta una pagina di guida di stile | | Un sito, più template, modifiche occasionali ai contenuti | Leggero: token e una tavola di componenti | | Sito più applicazione che condividono un marchio | Sì: la superficie condivisa è dove nasce la deriva | | Più siti in un'unica organizzazione | Sì: è il caso più netto | | Test A/B frequenti e pagine di campagna | Sì: la velocità di assemblaggio è il guadagno | | Ricostruzione prevista entro un anno | Non ancora: costruisci il sistema insieme alla ricostruzione | ### Il sistema minimo utile La maggior parte del beneficio viene da un piccolo nucleo. Si costruisce in giorni, non in mesi, e basta per la maggior parte dei siti che ne hanno bisogno. - Token: colore, scala tipografica, scala di spaziatura, raggi, ombre, breakpoint — nominati, non numeri fissi. - Tipografia: livelli di titolo e stili di testo corrente con il loro comportamento adattivo. - Pulsanti e link: ogni stato — normale, hover, focus, attivo, disabilitato, in caricamento. - Controlli dei moduli: campo, elenco, area di testo, casella, opzione, più gli stili di errore e di aiuto. - Schede ed elenchi: i due o tre contenitori di contenuto ricorrenti che il tuo sito usa davvero. - Navigazione: intestazione, piè di pagina, briciole di pane, paginazione. - Riscontro all'utente: stato vuoto, stato di errore, stato di caricamento, messaggio di successo. Gli stati sono la parte che si salta e quella che conta di più. Un componente definito solo nel suo stato normale restituisce ogni caso limite a chi lo sta implementando. ### Il costo di manutenzione che nessuno preventiva Un sistema di design è un prodotto con utenti, e ha bisogno di un responsabile. Senza, deriva: il sito acquisisce componenti che il sistema non ha, il sistema conserva componenti che nessuno usa, e dopo un anno le persone lavorano attorno al sistema anziché con esso. - Qualcuno ne è proprietario e decide cosa entra. Un sistema in mano a un comitato smette di cambiare. - Un percorso documentato per proporre un nuovo componente, così le persone lo estendono anziché aggirarlo. - Il versionamento, perché un cambiamento non alteri in silenzio ogni pagina in una volta. - Un audit periodico di ciò che è nel sito in produzione ma non nel sistema: quello scarto è la misura di salute. - La cancellazione. I componenti inutilizzati sono un costo, non un valore. ### Alternative più leggere Se il caso per un sistema completo non c'è, esistono passi meno costosi che catturano buona parte del beneficio di coerenza. | Proprietà personalizzate CSS per colore, tipografia e spaziatura | Ore | Qualsiasi sito: è il pavimento | | Una singola pagina di guida di stile viva dentro il sito stesso | Un giorno | Siti piccoli con collaboratori occasionali | | Libreria di componenti nel CMS o nello strato dei template | Giorni | Team di contenuto che assemblano pagine | | Framework CSS affermato, con tematizzazione leggera | Giorni | Strumenti interni e schermate di amministrazione | | Sistema di design completo e documentato | Settimane o mesi | Più prodotti o più team | Una pagina di guida di stile viva dentro il sito vero batte un documento: usa lo stesso CSS, quindi non può discostarsi dalla realtà senza rompersi in modo visibile. Q: Posso usare un sistema di design già pronto? A: Sì, e per gli strumenti interni di solito è la scelta giusta: il marchio conta poco e ottieni subito componenti accessibili e collaudati. Per un sito di marketing pubblico il compromesso è che il tuo sito somiglia a ogni altro che usa lo stesso sistema, quindi la maggior parte delle organizzazioni lo tematizza pesantemente, e a quel punto parte del risparmio di manutenzione svanisce. Q: Chi dovrebbe essere responsabile del sistema di design? A: Una persona indicata per nome, con il contributo di design e sviluppo. Una responsabilità condivisa tra design e ingegneria suona collaborativa e in pratica significa che nessuno decide, quindi il sistema smette di evolvere e le persone lo aggirano. Chi ne è responsabile non deve costruire tutto; deve dire sì e no. Q: Che differenza c'è tra una guida di stile e un sistema di design? A: Una guida di stile documenta l'aspetto: colori, caratteri, uso del logo. Un sistema di design comprende quello più componenti funzionanti, i loro stati, le regole per combinarli e di solito il codice. Una guida di stile ti dice come appaiono le cose; un sistema di design ti dà i pezzi e ti dice quando usare ciascuno. Q: Come evito che diventi obsoleto? A: Rendilo il percorso di minor resistenza e verifica lo scarto. Se usare il sistema è più lento che scrivere CSS estemporaneo, le persone scriveranno CSS estemporaneo. Elenca periodicamente i componenti presenti nel sito in produzione e assenti dal sistema: un elenco che cresce significa che il sistema non serve chi costruisce le pagine, e questo è un problema di progettazione del sistema stesso. ## Diventare sviluppatore web: un percorso realistico https://websitedevelopment.biz/it/guides/diventare-sviluppatore-web Aggiornato il 2026-08-07 · Assumere sviluppatori Diventare sviluppatore web significa imparare un insieme preciso e finito di cose e poi dimostrare di portare a termine il lavoro. Imparare è ben documentato e gratuito; la parte difficile è costruire la prova che qualcuno dovrebbe pagarti. Questa guida copre un ordine di apprendimento realistico, tempi onesti, cosa serve davvero a un portfolio, e come si trovano i primi clienti. ### Cosa imparare, in ordine L'ordine conta più del ritmo. Ogni strato rende comprensibile il successivo, e saltare avanti produce profili che copiano soluzioni ma non sanno diagnosticare problemi. - HTML, sul serio. Semantica, moduli, accessibilità. La maggior parte dei profili professionali ha lacune qui e si vede nel loro lavoro. - CSS, sul serio. Modello a scatola, flexbox, grid, proprietà personalizzate, impaginazione adattiva. È qui che chi inizia diventa davvero utile più in fretta. - Fondamenti di JavaScript. Il linguaggio in sé e il DOM, prima di qualsiasi framework. - Controllo di versione. Git, rami, pull request. Non negoziabile per lavorare con chiunque. - Come funziona il web. HTTP, codici di stato, cache, DNS, TLS. È ciò che separa la diagnosi dal tirare a indovinare. - Un linguaggio back-end e SQL. Uno qualsiasi tra quelli diffusi; i concetti si trasferiscono. - Un CMS o un framework, scelto in base al lavoro che esiste vicino a te. - Il rilascio. Portare un sito su un hosting vero, con dominio e certificato. La profondità in HTML e CSS è sottovalutata e immediatamente vendibile. Chi sa costruire interfacce veloci, accessibili e adattive è più richiesto di chi conosce tre framework in superficie. ### Quanto ci vuole davvero Con uno studio costante di 15-20 ore a settimana. Il tempo pieno comprime questi tempi, e nulla comprime l'ultima riga. | Basi di HTML e CSS | 1–2 mesi | Costruire una pagina statica da un progetto grafico | | Impaginazione adattiva e basi di JavaScript | 3–5 mesi | Costruire un piccolo sito con interazione | | Primo progetto vero | 5–8 mesi | Consegnare qualcosa per qualcun altro | | Profilo junior assumibile | 8–14 mesi | Contribuire a una base di codice con supervisione | | Lavorare in autonomia | 2–3 anni | Portare avanti un piccolo progetto dall'inizio alla fine | | Profilo senior | Oltre 5 anni | Prendere decisioni architetturali e avere ragione spesso | Il passaggio che si sottovaluta è «consegnare qualcosa per qualcun altro». Costruire per sé insegna la sintassi; costruire per un cliente insegna perimetro, riscontri, scadenze e il fatto che i requisiti cambiano. ### Cosa deve mostrare un portfolio Tre o quattro progetti finiti, online e ben spiegati battono venti cloni di tutorial. Ciò che viene giudicato è se porti a termine le cose e se capisci ciò che hai costruito. - URL online, non schermate. Deve funzionare quando qualcuno fa clic. - Un breve testo per progetto: il problema, le tue decisioni, cosa faresti diversamente. - Almeno un progetto vero con un utente vero, anche non retribuito: un'attività locale, un'associazione, un ente di volontariato. - Prove di qualità: veloce, accessibile, funziona su telefono. Le persone controllano. - Il tuo sito, fatto bene. È la prima cosa che chiunque guarda e la più facile da fare bene. - Codice in un repository pubblico con commit leggibili e un README che spieghi come avviarlo. ### Trovare i primi clienti I primi due o tre sono quelli difficili. Dopo, la maggior parte del lavoro arriva per passaparola, il che significa che finire bene conta più del marketing. - Comincia da persone che già conosci. Quasi ogni primo lavoro retribuito è arrivato così. - Scegli una nicchia anziché restare generalista. «Siti per studi dentistici» si vende molto meglio di «siti». - Risolvi un problema preciso e costoso — la velocità di un sito, una verifica di accessibilità, una migrazione — anziché offrire tutto. - Fatti pagare dal primo progetto, anche poco. Il lavoro gratuito viene valutato di conseguenza e attira perimetro illimitato. - Metti per iscritto perimetro e condizioni di pagamento prima di iniziare, per quanto piccolo sia l'incarico. - Chiudi come si deve: passaggio di consegne, documentazione, un'offerta di manutenzione. È questo a produrre il secondo cliente. - Chiedi una segnalazione quando il cliente è più soddisfatto, cioè subito dopo il lancio. Q: Serve una laurea in informatica? A: No, e una buona parte di chi lavora nello sviluppo web non ce l'ha. Una laurea aiuta in alcune grandi organizzazioni e in ruoli più vicini all'informatica che allo sviluppo web. Per la maggior parte del lavoro web la prova di progetti finiti conta più dei titoli — ma ti servono i fondamentali che un percorso di studi avrebbe dato, imparati in altro modo. Q: Front-end o back-end per primo? A: Front-end, in quasi tutti i casi. Vedi risultati subito, il che sostiene la motivazione, ed è la strada più breve per essere utile a qualcuno. Una volta che sai costruire interfacce come si deve, i concetti back-end sono più facili da imparare perché capisci già a cosa servono i dati. Q: È troppo tardi per iniziare? A: No, e chi cambia carriera spesso se la cava bene perché porta una conoscenza di settore che ad altri manca: commercialisti che costruiscono per commercialisti, insegnanti che costruiscono per le scuole. Il mercato dei profili junior generalisti è affollato; quello di chi capisce un settore preciso e sa costruire lo è molto meno. Q: Devo imparare presto un framework? A: Impara prima i fondamentali. I framework cambiano ogni pochi anni e sono molto più facili da prendere in mano quando capisci cosa stanno astraendo. Chi ha imparato un framework senza il linguaggio sottostante tende a essere efficace dentro i suoi schemi e bloccato fuori, e quel soffitto arriva in fretta. ## Che cos'è un CMS e ti serve davvero? https://websitedevelopment.biz/it/guides/che-cos-e-un-cms Aggiornato il 2026-08-07 · CMS Un sistema di gestione dei contenuti permette a chi non scrive codice di creare e modificare pagine. È tutta qui la proposta di valore, ed è reale — ma non è gratis, perché un CMS è software da ospitare, aggiornare e mettere in sicurezza per tutto il tempo in cui il sito esiste. Questa guida copre cosa ti dà davvero un CMS, quando l'onere vale la pena, e cosa usare quando non la vale. ### Cosa offre un CMS Oltre a «modificare le pagine», queste sono le capacità che stai comprando — e vale la pena elencarle, perché quasi tutte le decisioni sul CMS si prendono senza verificare quali servano davvero. - Modificare senza rilasciare. Cambiare un testo e pubblicare subito. - Contenuti strutturati. Campi anziché un blocco di HTML, così i contenuti si riusano e si mostrano in modo coerente. - Gestione dei media. Caricare una volta, usare ovunque, con ridimensionamento automatico. - Utenti e permessi. Redazione, revisione e approvazione con diritti diversi. - Flusso di lavoro. Bozze, anteprime, programmazione, cronologia delle versioni. - Ricerca e navigazione generate automaticamente dai contenuti. - Estensibilità. Moduli, commercio, traduzioni tramite un ecosistema. Se ti serve solo la prima voce di questo elenco e una persona fa modifiche due volte l'anno, un CMS è molto meccanismo per un piccolo compito. ### L'onere che nessuno menziona all'inizio Un CMS è un'applicazione in funzione, il che significa che ha un profilo di costo continuo, che qualcuno modifichi il sito o no. | Correzioni di sicurezza | I sistemi diffusi vengono sondati di continuo; gli aggiornamenti non sono facoltativi | | Manutenzione dei plugin | Ogni estensione è un altro aggiornamento e un'altra possibile falla | | Hosting | Un'applicazione con database richiede più di file statici | | Lavoro sulle prestazioni | Le pagine dinamiche hanno bisogno di cache per essere veloci | | Aggiornamenti di versione | Le versioni maggiori possono rompere temi e personalizzazioni | | Formazione | La redazione deve saperlo usare senza rompere le impaginazioni | ### Quando ti serve e quando no Il fattore decisivo è la frequenza di modifica moltiplicata per il numero di persone che devono fare modifiche. | Team marketing che pubblica ogni settimana | Sì: è esattamente il caso per cui esiste un CMS | | Sito di cinque pagine modificato due volte l'anno | No: un sito statico costa meno ed è più sicuro | | Documentazione mantenuta dallo sviluppo | No: file nel controllo di versione funzionano meglio | | Negozio online | Sì, e una piattaforma commerce anziché un CMS generico | | Pagine d'ingresso per campagne | Sì: la velocità di pubblicazione è tutto il senso | | Sito con più tipi di contenuto e traduzioni | Sì: la struttura è ciò in cui un CMS è bravo | ### Le alternative Per i siti che cambiano di rado esistono opzioni con costi di esercizio molto più bassi e quasi nessuna superficie d'attacco. - Generatore di siti statici. Contenuti in file, compilati in HTML, rilasciati su un CDN. Veloce, economico e quasi nulla da attaccare — ma modificare richiede un flusso tecnico, a meno di aggiungere uno strato di editing. - Generatore statico più un editor basato su git. Modifica non tecnica sopra i file, mantenendo l'output statico. - CMS headless più generazione statica. La redazione ottiene un'interfaccia gradevole; il sito pubblico resta statico. - HTML scritto a mano. Del tutto ragionevole per un piccolo sito vetrina che davvero non cambia mai. - Costruttore di siti. La modifica è il prodotto; il compromesso è portabilità e prestazioni. La via statica elimina un'intera categoria di rischio: non c'è database in cui iniettare né accesso di amministrazione da forzare. Per un sito che cambia ogni mese, è un risparmio significativo. Q: WordPress è la scelta predefinita? A: È la più diffusa, e la diffusione porta un ecosistema enorme, molte persone che lo conoscono, e una quantità proporzionalmente grande di attenzione automatizzata da parte di chi attacca. Si adatta bene ai siti editoriali. Non è automaticamente giusto per applicazioni, commercio complesso, o siti il cui contenuto sono soprattutto dati strutturati anziché pagine. Q: Che differenza c'è tra un CMS e un costruttore di siti? A: Un CMS gestisce i contenuti e di solito lascia la presentazione a template che tu o chi sviluppa controllate. Un costruttore unisce contenuto e impaginazione in un unico strumento visuale. I costruttori sono più rapidi per chi non è tecnico e più difficili da lasciare, perché le decisioni di impaginazione vivono dentro il prodotto anziché in codice che ti appartiene. Q: Posso aggiungere un CMS a un sito statico esistente? A: Sì, ed è un'evoluzione comune: o un CMS headless che alimenta i template esistenti, o uno strato di editing basato su git sopra i file attuali. Di solito è meno lavoro di una migrazione completa, perché template e URL restano dove sono. Q: Quanti plugin sono troppi? A: Non c'è un numero fisso, ma ogni plugin è un aggiornamento da applicare, un possibile conflitto e una possibile vulnerabilità. Una disciplina utile è giustificare ciascuno rispetto a ciò che rende: se fa risparmiare un'ora l'anno e richiede attenzione trimestrale, ti sta costando. I siti con quaranta plugin ne portano quasi sempre diversi che nessuno sa spiegare. ## Domande da fare a uno sviluppatore web prima di ingaggiarlo https://websitedevelopment.biz/it/guides/domande-da-fare-a-uno-sviluppatore-web Aggiornato il 2026-08-07 · Assumere sviluppatori La maggior parte delle domande poste in un primo colloquio riguarda la tecnologia, e la tecnologia è la parte che conta meno per la riuscita del progetto. Le domande che predicono l'esito riguardano processo, proprietà e cosa succede quando qualcosa va storto. Questa guida elenca quelle domande, raggruppate per ciò che rivelano, con una nota su com'è fatta una buona risposta. ### Sul lavoro in sé Stabiliscono se hanno capito il tuo progetto o stanno descrivendo la loro offerta standard. | Che domande avete sulla nostra attività? | Qualsiasi. Il silenzio qui è il segnale negativo più forte che esista | | Mostratemi un sito in produzione della nostra scala | Un URL, non un'immagine; idealmente non il loro pezzo da vetrina | | Cosa fareste di diverso dal nostro sito attuale? | Osservazioni precise, segno che hanno guardato | | Qual è la parte più rischiosa di questo progetto? | Una risposta onesta: di solito contenuti o integrazioni | | Cosa non è incluso in questo preventivo? | Un elenco preciso dato volentieri | | Quanto ci vorrà, e cosa lo determina? | Un calendario con dipendenze, non un numero isolato | ### Sul processo Separano chi ha un modo di lavorare ripetibile da chi improvvisa. - Dove è conservato il codice, e avremo accesso dal primo giorno? - Come arriva una modifica dalla vostra macchina al sito in produzione? - Dove revisioniamo il lavoro prima che vada online? - Con che frequenza vedremo gli avanzamenti, e in che forma? - Chi esattamente farà il lavoro, e cosa succede se quella persona non è disponibile? - Come collaudate: browser, dispositivi, accessibilità, prestazioni? - Cosa vi serve da noi, ed entro quando? La domanda sul rilascio è la più rivelatrice di tutte. Una risposta che comporti il trascinare file in un client FTP ti dice che non c'è controllo di versione, né preproduzione, né possibilità di tornare indietro. ### Su cosa succede dopo Il periodo di cui nessuno chiede durante la presentazione e che interessa tutti sei mesi dopo. - A chi appartengono codice, dominio e account di hosting dopo il lancio? - Quale assistenza è inclusa dopo il lancio, per quanto tempo, e cosa conta come difetto? - Quanto costa dopo una piccola modifica, e in quanto tempo? - Offrite manutenzione, cosa comprende, e riceviamo un rapporto? - Se smettiamo di collaborare, cosa riceviamo e in quanto tempo? - Un altro fornitore può subentrare? Quale documentazione esiste? - Da quali servizi di terze parti dipenderà il sito, e chi li paga? ### Risposte che dovrebbero chiudere la conversazione Rare, ma da riconoscere subito. | «Garantiamo posizioni in prima pagina» | Nessuno può; è ignoranza o disonestà | | «Il dominio lo teniamo sul nostro account» | Ti rende ostaggio | | «Non serve la preproduzione, stiamo attenti» | Tutti stanno attenti; quello non è un processo | | «Sui siti piccoli non usiamo il controllo di versione» | Nessuno storico, nessun ritorno indietro, nessun secondo fornitore | | «Il prezzo vale solo se firmate oggi» | Le tattiche di pressione predicono il rapporto di lavoro | | «Il SEO è incluso», senza dettagli | O non significa nulla o si sta insinuando un servizio a parte | | «I dettagli li vediamo strada facendo» | Con un prezzo fisso, quello diventa un tuo problema | Q: Qual è la domanda più utile? A: «Come arriva una modifica dalla vostra macchina al sito in produzione?» Chiunque sia competente risponde in una frase, e la risposta rivela se esistono controllo di versione, preproduzione, revisione e ritorno indietro. Tutto il resto dell'elenco sul processo tende a discenderne in una direzione o nell'altra. Q: Devo chiedere di tecnologie specifiche? A: Solo dove hai un vincolo reale: un sistema esistente, una piattaforma che il tuo team già usa. Altrimenti la tecnologia è una loro decisione, e chiederne invita una risposta pensata per impressionare. Chiedi piuttosto quali risultati produce: quanto veloce, quanto manutenibile, chi altri potrebbe lavorarci. Q: Come verifico bene una referenza? A: Chiedi di un problema anziché della soddisfazione: «cosa è andato storto, e come l'hanno gestita?» Ogni progetto ha qualcosa. Una referenza che non sa citare nulla o ha avuto un progetto banale o non è del tutto sincera. Chiedi anche se li richiamerebbe per un progetto più grande, domanda più tagliente di quella sulla soddisfazione. Q: È scortese chiedere di proprietà e recesso? A: No, e un fornitore professionale se lo aspetta. Entrambe le parti guadagnano dal sapere come stanno, e le risposte sono brevi. Il disagio davanti a queste domande è di per sé un'informazione: di solito significa che l'assetto standard ti è meno favorevole di quanto dovrebbe. ## Accessibilità web: da cosa cominciare https://websitedevelopment.biz/it/guides/guida-accessibilita-web Aggiornato il 2026-08-07 · Web design Il lavoro sull'accessibilità ha una lunga lista di criteri e un breve elenco di cose che spiegano la maggior parte delle barriere reali. Partire dall'elenco breve porta rapidamente utenti veri sul tuo sito; partire da un audit completo di solito produce un documento che nessuno lavora. Questa guida copre da cosa cominciare, come collaudarlo tu stesso in un pomeriggio, e perché i widget di sovrapposizione non sono la scorciatoia che vendono. ### Gli interventi a maggiore effetto Sono le barriere che impediscono del tutto di completare un'attività, anziché renderla un po' più difficile. Correggile prima di qualsiasi cosa figuri in un elenco più lungo. - Accesso da tastiera. Ogni elemento interattivo raggiungibile con Tab e azionabile con Invio o Spazio, in un ordine sensato, con un anello di focus visibile. Se il sito si usa solo con il mouse, nient'altro in questo elenco conta. - Alternative testuali. Testo alternativo sensato sulle immagini che portano informazione; alt vuoto su quelle decorative. Un alt assente non è la stessa cosa di uno vuoto. - Etichette dei moduli. Una vera