Il web design aziendale efficace non è un problema estetico: è un progetto tecnico che integra architettura dati, tracciamento conversioni, performance misurabili (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1) e SEO strutturale fin dal giorno zero. Un sito aziendale che non converte quasi sempre ha un problema di progettazione — non di traffico. Questo articolo spiega cosa deve contenere un progetto di web design B2B serio, quali deliverable pretendere, quali red flag contrattuali riconoscere e come valutare un preventivo prima di firmare.
Web design per aziende
Risposta rapida (per valutare un preventivo in 60 secondi): un progetto web B2B è “completo” solo se include target Core Web Vitals misurabili, piano di misurazione GA4+GTM, architettura SEO (URL + redirect plan + template mapping + schema), requisiti WCAG 2.1 AA, SLA manutenzione e ownership/accessi consegnati al cliente.
Il tuo sito è online da due anni, riceve visite, ma i contatti non arrivano. Oppure: stai per commissionare un nuovo sito e hai ricevuto tre preventivi con cifre che vanno da 2.000 a 25.000 euro — senza capire cosa giustifichi la differenza. Entrambe le situazioni nascono dallo stesso punto cieco: confondere il web design con la parte visiva del progetto. La grafica è una componente. L’architettura dati, il tracciamento eventi, la struttura URL, il piano di redirect, la velocità reale su mobile, la sicurezza e la manutenzione post-lancio sono le altre — e sono quelle che determinano se il sito genera business o resta una vetrina costosa.
Se il preventivo che hai in mano non menziona GA4, GTM, schema markup, redirect plan, SLA di manutenzione e ownership degli accessi, stai guardando un documento incompleto. Quello che segue è il framework per capire cosa manca.
Perché le performance non sono un “plus” ma un requisito di progetto misurabile
Google ha reso pubbliche le soglie dei Core Web Vitals che determinano l’esperienza utente e influenzano il ranking: LCP (Largest Contentful Paint) ≤ 2,5 secondi, INP (Interaction to Next Paint) ≤ 200 millisecondi, CLS (Cumulative Layout Shift) ≤ 0,1. A queste si aggiunge il TTFB (Time to First Byte), che Google Search Central indica come soglia ≤ 800 ms per un’esperienza accettabile. Questi non sono numeri da ottimizzare “dopo il lancio”. Sono vincoli di progettazione.
Il problema è strutturale. La maggior parte dei siti aziendali viene costruita scegliendo un tema WordPress premium, caricando immagini non compresse, aggiungendo plugin per ogni funzionalità e pubblicando senza mai aprire PageSpeed Insights. Il risultato tipico: LCP sopra i 4 secondi su mobile, CLS che salta a 0,3 per banner e font non precaricati, INP che supera i 500 ms per JavaScript bloccante. Il sito è “bello” ma lento. E lento significa che gli utenti se ne vanno prima di vedere il form di contatto.
Nei siti che gestiamo con Orosfera — 8 domini WordPress in produzione a maggio 2026 — le performance vengono definite come vincolo nel brief di progetto, non come task di ottimizzazione post-lancio. Concretamente: il tema viene scelto (o sviluppato) in funzione del peso base sotto i 200 KB di CSS+JS critico, le immagini passano per una pipeline di conversione WebP/AVIF con lazy loading nativo, i font vengono precaricati con <link rel="preload"> e il subset viene limitato ai caratteri latini effettivamente usati.
Cosa chiedere nel preventivo:
- Soglie CWV garantite al lancio — il fornitore deve specificare i target LCP, INP, CLS e come intende misurarli (PageSpeed Insights, CrUX, Lighthouse CI)
- Strategia di gestione immagini: formato, compressione, lazy loading, CDN
- Audit pre-lancio con report Lighthouse allegato al deliverable finale
- Piano di monitoraggio post-lancio (chi controlla le performance dopo 30, 60, 90 giorni)
Se il preventivo non menziona nessuna di queste voci, il fornitore non sta progettando un sito performante. Sta assemblando componenti. La differenza si vede nei dati di conversione dopo 90 giorni.
Un dato che riscontriamo spesso: siti con LCP sopra i 4 secondi su mobile hanno tassi di rimbalzo significativamente più alti rispetto agli stessi siti dopo ottimizzazione sotto i 2,5 secondi. Non è una correlazione teorica — è un pattern che osserviamo nei dati GA4 dei progetti che seguiamo.
Accettazione deliverable performance (pre go-live): cosa deve esserci nel report
- Elenco URL testate (almeno: home + 1 servizio + 1 articolo + contatti) con data e device.
- Misura doppia: Lighthouse (lab) + PageSpeed Insights/CrUX (field) dove disponibile.
- Target dichiarati: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, TTFB ≤ 800 ms.
- Azioni correttive se un target non è rispettato (es. riduzione JS, ottimizzazione immagini, font preload) con owner e scadenza.
GA4, GTM e tracciamento conversioni: perché devono essere nel progetto, non nel post-lancio
Ecco l’errore più frequente che vediamo nei progetti web aziendali: il sito viene costruito, pubblicato, e solo dopo qualcuno chiede “come misuriamo i risultati?” A quel punto si installa GA4 in fretta, si configura qualche evento base e si perde la finestra critica dei primi 30-60 giorni — quelli in cui i dati servirebbero di più per capire se la struttura funziona.
Non funziona così.
Il tracciamento è un requisito architetturale, non un accessorio. Deve essere progettato insieme alla struttura del sito, perché le decisioni di design impattano direttamente su cosa puoi misurare. Esempio concreto: se il form di contatto è un plugin WordPress che non espone eventi al dataLayer di GTM, dopo il lancio dovrai modificare il codice del plugin o sostituirlo — con costi e tempi non previsti.
Checklist di deliverable che il progetto web deve includere prima del lancio:
- Piano di misurazione — documento che definisce: obiettivi di business → KPI → eventi GA4 → trigger GTM. Non “installiamo Analytics”. Un piano.
- Configurazione GA4 con stream dati, eventi personalizzati (form_submit, click_telefono, scroll_depth, download_pdf), e conversioni marcate
- Container GTM configurato e testato in modalità debug prima del go-live, con tag per GA4, eventuali pixel pubblicitari, e consent mode v2 per GDPR (Reg. UE 2016/679)
- Micro-conversioni definite — non solo “ha compilato il form”, ma: ha scrollato oltre il 75% della pagina servizi, ha cliccato sul numero di telefono, ha aperto la mappa, ha visitato almeno 3 pagine in sessione
- Test di funzionamento documentato: screenshot del debug GTM che mostra ogni evento sparato correttamente su ogni template del sito
Questo è il punto di svolta. Un sito senza tracciamento configurato al lancio è un investimento senza strumento di misura. Non sai cosa funziona, non sai cosa no, e ogni decisione successiva diventa un’opinione invece che un dato. Se il tuo fornitore attuale ti ha consegnato un sito senza un container GTM configurato, il problema non è il traffico — è che stai volando senza strumenti. L’analisi dei dati parte dal setup, non dall’interpretazione.
Quanto al budget: la configurazione GA4+GTM per un sito aziendale con 5-15 template e 8-12 eventi personalizzati richiede tipicamente 2-4 giorni di lavoro tecnico. Se il preventivo non include questa voce, o la liquida con “installiamo Google Analytics”, è una red flag contrattuale.
SEO come architettura dati, non come “ottimizzazione” post-lancio
La SEO in un progetto di web design aziendale non è un servizio aggiuntivo. È una decisione architetturale che si prende prima di scrivere la prima riga di codice. Quando la struttura URL, la gerarchia dei template, il piano di redirect e lo schema markup vengono definiti dopo il lancio, il costo di correzione è tipicamente 3-5 volte superiore rispetto alla progettazione iniziale — perché ogni modifica strutturale richiede redirect, aggiornamento del sitemap, riscansione da parte di Google e potenziale perdita temporanea di posizionamento.
Cosa deve contenere la componente SEO del progetto web:
Mapping dei template. Ogni tipo di pagina (homepage, servizio, caso studio, blog post, landing, contatti) deve avere un template con struttura heading definita (H1, H2, H3), posizione del contenuto principale, sidebar o meno, schema markup specifico. Un sito con 7 template ben progettati scala meglio di uno con 30 pagine costruite con lo stesso layout generico.
Struttura URL. Le URL devono essere definite nel brief di progetto: piatte o gerarchiche, con o senza categoria, con convenzioni di naming coerenti. Modificare le URL dopo il lancio significa creare redirect 301 — e ogni redirect è una piccola perdita di segnale che si accumula. La corretta indicizzazione dipende da scelte fatte in fase di progettazione, non di manutenzione.
Piano di redirect. Se il nuovo sito sostituisce uno esistente, il piano di redirect 301 è un deliverable obbligatorio. Deve mappare ogni URL del vecchio sito verso la corrispondente nel nuovo. Gli URL senza corrispondenza vanno gestiti con 410 (Gone) se il contenuto è stato rimosso intenzionalmente, o con redirect verso la pagina più pertinente. Un piano di redirect incompleto causa errori 404 che Google Search Central documenta come segnale negativo per l’esperienza utente.
Schema markup. Ogni template deve avere il markup strutturato appropriato in JSON-LD: Organization per la homepage; LocalBusiness solo se esiste una sede fisica aperta al pubblico con NAP (name-address-phone) coerente su sito e profili; Article per i blog post; FAQPage per le pagine con domande frequenti; BreadcrumbList per la navigazione. Esempio minimo per la homepage:
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Organization", "name": "Nome Azienda", "url": "https://www.esempio.com", "logo": "https://www.esempio.com/logo.png", "contactPoint": { "@type": "ContactPoint", "telephone": "+39-XXX-XXXXXXX", "contactType": "customer service", "availableLanguage": "Italian" }
}
</script>Prevenzione della cannibalizzazione. Due pagine che competono per la stessa keyword si elidono a vicenda. Il piano editoriale e la mappa dei contenuti devono essere definiti prima di creare i template — non dopo aver pubblicato 40 pagine e scoperto che 6 si sovrappongono. Su un progetto gestito a inizio 2026, abbiamo scoperto tre pagine servizio che competevano per la stessa query: 6 settimane di cannibalizzazione prima che il fix (consolidamento + redirect 301) producesse effetti visibili in Search Console. La consulenza SEO integrata nel progetto web previene esattamente questo scenario.
Conversion design: cosa significa progettare pagine che generano contatti (non solo visite)
Un sito aziendale che riceve 2.000 visite al mese e genera 3 contatti ha un tasso di conversione dello 0,15%. Lo stesso sito, con interventi sulla struttura delle landing page, sulla posizione e il copy delle CTA, e sulla riduzione degli step nel form, può ragionevolmente arrivare allo 0,8-1,2%. La differenza tra 3 e 20 contatti al mese non è traffico — è design orientato alla conversione.
Dipende. Sempre.
Dipende dal settore, dal valore del lead, dalla complessità del servizio. Ma ci sono principi che funzionano trasversalmente, e che il progetto web deve incorporare nel design dei template, non aggiungere dopo con plugin o popup.
Definizione degli eventi di conversione. Prima di disegnare una singola pagina, il progetto deve rispondere: cosa conta come conversione? Per un’azienda B2B tipica, la gerarchia è: compilazione form di contatto (macro-conversione) → click su numero di telefono → click su WhatsApp → download PDF/catalogo → scroll oltre il 75% di una pagina servizio (micro-conversioni). Ogni evento deve avere un valore stimato e un trigger GTM associato — come descritto nella sezione precedente.
Criteri di qualità dei template landing/servizio. Ogni pagina servizio deve avere:
- H1 che contiene la keyword primaria e comunica il beneficio — non il nome del servizio
- Paragrafo di apertura che descrive il problema del cliente, non le caratteristiche del servizio
- CTA above the fold — visibile senza scroll su mobile (viewport 375×667 px)
- Prova sociale: testimonianza, caso studio, numero di clienti serviti, certificazioni
- Form con massimo 4-5 campi (nome, email, telefono, messaggio, consenso GDPR)
- Tempo di caricamento ≤ 2,5 secondi LCP su mobile
L’errore più frequente che vediamo è questo: pagine servizio costruite come brochure — descrizione dell’azienda, lista di servizi, foto del team, footer. Nessun form visibile senza scrollare 3 schermate. Nessun numero di telefono cliccabile. Nessuna urgenza o motivo per agire adesso. Il risultato è prevedibile: il visitatore legge, annuisce, e chiude il tab. L’esperienza utente non è un concetto astratto — è la sequenza di decisioni che porta (o non porta) al contatto.
Sotto 5 pagine servizio, un sito B2B non ha abbastanza superficie di conversione. Oltre 20 pagine servizio senza un’architettura chiara, il sito disperde l’attenzione. La soglia operativa che usiamo nei progetti Orosfera: 7-12 pagine servizio ben strutturate coprono il 90% delle query commerciali di una PMI italiana tipica.
Red flag contrattuali: 9 clausole che il preventivo deve esplicitare
Il preventivo di un sito web aziendale è un contratto tecnico, non un listino prezzi. Se il documento che hai ricevuto è una pagina con tre voci — “design”, “sviluppo”, “pubblicazione” — e un totale, non hai un preventivo. Hai un’intenzione generica. Le controversie più frequenti tra aziende e fornitori web nascono da ciò che il preventivo non diceva.
Queste sono le clausole che devono essere esplicitate per iscritto:
- Ownership del codice e dei contenuti. Chi possiede il sito dopo il pagamento? Il codice custom, il tema, le immagini, i testi sono di proprietà del cliente o del fornitore? Se il fornitore usa un tema proprietario e non trasferisce la licenza, il cliente è vincolato a vita. Questo deve essere scritto nel contratto.
- Accessi completi. Il cliente deve ricevere: credenziali admin WordPress (o CMS equivalente), accesso FTP/SFTP, accesso al pannello hosting, accesso al registrar del dominio, proprietà GA4, proprietà Search Console, accesso al container GTM. Se il fornitore “gestisce tutto” senza condividere gli accessi, il cliente non possiede realmente il proprio sito.
- Ambiente di staging. Le modifiche devono essere testate su un ambiente separato prima di andare in produzione. Il preventivo deve specificare se l’ambiente di staging è incluso e per quanto tempo resta disponibile.
- SLA di manutenzione post-lancio. Cosa succede dopo la consegna? Aggiornamenti WordPress core, plugin, tema: chi li fa, con quale frequenza, a quale costo? Un sito WordPress non aggiornato per 6 mesi diventa un rischio di sicurezza informatica concreto.
- Backup e disaster recovery. Frequenza dei backup (giornaliero, settimanale), dove vengono conservati (stesso server = inutile in caso di crash), procedura di ripristino e tempo stimato (RTO).
- Numero di revisioni incluse. “Revisioni illimitate” non esiste. Il preventivo deve specificare quanti cicli di revisione sono inclusi per il design e per lo sviluppo, e il costo di revisioni aggiuntive.
- Conformità GDPR. Il sito deve essere conforme al Regolamento UE 2016/679: cookie banner con consenso granulare, privacy policy, gestione dei dati del form di contatto. Dal 2025, anche l’European Accessibility Act (Direttiva UE 2019/882) impone requisiti di accessibilità per i servizi digitali — il preventivo deve indicare il livello WCAG target (minimo AA).
- Tempi di consegna con milestone. Non “6-8 settimane”. Un cronoprogramma con date: brief → wireframe → design → sviluppo → contenuti → test → staging → go-live. Ogni milestone con deliverable specifico e approvazione del cliente.
- Costi ricorrenti separati. Hosting, dominio, licenze plugin premium, manutenzione, certificato SSL: queste voci devono essere separate dal costo di sviluppo e quantificate per anno.
Se il preventivo che hai in mano non copre almeno 7 di queste 9 voci, hai un margine di rischio significativo. Non è questione di sfiducia verso il fornitore — è questione di chiarezza contrattuale che protegge entrambe le parti.
Quando il web design “perfetto” non produce risultati: i limiti reali del progetto
Questo approccio non funziona quando manca il contenuto. Un sito con architettura impeccabile, performance eccellenti e tracciamento configurato ma con testi generici copiati dalla brochure aziendale del 2019 non posizionerà su Google e non convertirà. Il content marketing non è un layer opzionale — è il carburante senza il quale il motore non parte.
Abbiamo testato questo su un progetto a maggio 2026: sito WordPress con LCP a 1,8 secondi, schema markup completo, GA4+GTM configurati, 12 template ottimizzati. Traffico organico dopo 90 giorni: marginale. Il motivo era semplice — le 8 pagine servizio avevano testi da 150 parole ciascuna, senza keyword research, senza struttura heading, senza risposta alle domande che i potenziali clienti cercano effettivamente. Abbiamo dovuto riscrivere tutti i contenuti con un piano editoriale basato su analisi del target e query reali da Search Console. I risultati sono arrivati dopo ulteriori 60 giorni.
Il punto è questo.
Un progetto web che non include la strategia contenuti nel perimetro di lavoro è un progetto incompleto. Non basta “lasciare spazio per i testi” nei template. I contenuti devono essere progettati insieme alla struttura — keyword per keyword, template per template, con un piano che definisce cosa scrivere, per chi, e con quale obiettivo di posizionamento.
Altro limite reale: oltre 12 componenti interconnessi (plugin, integrazioni API, CRM, booking system, e-commerce, multilingua), la complessità del progetto cresce in modo non lineare. Ogni componente aggiuntivo aumenta il rischio di conflitti, rallentamenti e costi di manutenzione. Su un progetto con 14 componenti interconnessi, una modifica al form aveva rotto silenziosamente il routing del CRM — e lo abbiamo scoperto solo al deploy, con 3 giorni di debug per un campo rinominato nel CSV di input. La soglia pratica: se il tuo sito richiede più di 12 plugin attivi su WordPress, serve una valutazione architetturale seria prima di procedere.
Come affrontiamo un progetto web in Orosfera: dalla diagnosi alla manutenzione
Il nostro processo parte da un’analisi che non riguarda il design. Prima di toccare Figma o WordPress, Maximilian Figel — AI SEO & Data Architect di Orosfera — esegue un audit strutturale che include: analisi delle query esistenti in Search Console (se il sito è già online), mappatura dei competitor SERP per le keyword commerciali principali, definizione dell’architettura URL e del piano di redirect, e stesura del piano di misurazione GA4+GTM.
Il brief di progetto che consegniamo al team di sviluppo contiene:
- Mappa dei template con struttura heading, schema markup e keyword target per ciascuno
- Wireframe orientato alla conversione con posizione CTA, form e prova sociale definiti
- Soglie CWV come vincolo di progettazione (non come obiettivo di ottimizzazione)
- Container GTM pre-configurato con eventi personalizzati per ogni template
- Piano contenuti per le prime 12 settimane post-lancio
Dai dati GSC degli 8 siti che seguiamo in Orosfera, il pattern più ricorrente nei siti che ci vengono affidati dopo un lancio fallito è l’assenza di almeno 3 dei 9 elementi contrattuali descritti sopra. Il costo di correzione post-lancio è sistematicamente superiore al costo di progettazione iniziale. Per questo il nostro workflow di content marketing integra la verifica SEO e performance in ogni fase — non come audit finale, ma come checkpoint continuo.
Hai bisogno di una valutazione concreta sul tuo progetto web? Contattaci — rispondiamo al telefono o su WhatsApp, senza form intermedi.
Checklist operativa: cosa deve contenere un preventivo web serio
| Area | Deliverable richiesto | Red flag se assente |
|---|---|---|
| Performance | Target CWV (LCP, INP, CLS) + report Lighthouse pre-lancio | Il fornitore non misura la velocità |
| Tracciamento | Piano misurazione + GA4 + GTM configurati + test debug | Non saprai mai se il sito funziona |
| SEO | Struttura URL + schema markup + redirect plan + mappa template | SEO “aggiunta dopo” = costo doppio |
| Conversione | Wireframe con CTA, form, prova sociale + eventi conversione definiti | Sito vetrina senza lead generation |
| Contenuti | Piano editoriale per le prime 12 settimane + keyword mapping | Template vuoti che non posizionano |
| Contratto | Ownership, accessi, SLA, backup, revisioni, GDPR, accessibilità | Rischio di lock-in o controversie |
| Timeline | Cronoprogramma con milestone, deliverable e approvazioni | Nessun controllo sui tempi di consegna |
| Costi ricorrenti | Hosting, dominio, licenze, manutenzione quantificati per anno | Sorprese economiche post-lancio |
Questa tabella non è teoria. È la lista che usiamo internamente per valutare i preventivi che i clienti ci portano in fase di second opinion. Se il documento copre 6 aree su 8, è un buon preventivo. Sotto 5, servono integrazioni prima di firmare.
Accettazione consegna (allegati minimi da pretendere)
- Report CWV pre go-live con data, device e elenco URL testate (home + 1 servizio + 1 articolo + contatti).
- Export configurazione tracking: elenco eventi GA4, trigger GTM e screenshot debug che prova l’attivazione su ogni template.
- Pacchetto accessi/ownership: credenziali admin CMS, hosting, registrar dominio, proprietà Search Console e GA4, accesso GTM con ruolo Pubblica.
Per un’analisi specifica del tuo preventivo o del tuo sito attuale, scrivici o mandaci un messaggio: ti risponde un umano, non un chatbot.
Domande frequenti sul web design aziendale
Quanto costa realisticamente un sito web aziendale con tutti i deliverable descritti?
Un progetto web B2B completo — con architettura SEO, tracciamento GA4+GTM, performance ottimizzate, piano contenuti e documentazione contrattuale — si colloca tipicamente tra 8.000 e 20.000 euro per un sito da 15-30 pagine. I preventivi sotto i 3.000 euro quasi sempre escludono tracciamento, SEO strutturale e manutenzione. Il prezzo dipende dalla complessità dei template, dalle integrazioni richieste (CRM, booking, e-commerce) e dal volume di contenuti inclusi nel perimetro.
Quanto tempo serve per completare un progetto web aziendale fatto bene?
Un sito aziendale con 7-12 template, contenuti originali e configurazione completa richiede tipicamente 8-14 settimane dalla firma del contratto al go-live. Le variabili principali sono la velocità di approvazione del cliente (ogni ciclo di revisione aggiunge 5-7 giorni) e la complessità delle integrazioni. Progetti “in 2 settimane” esistono, ma sacrificano quasi sempre tracciamento, SEO e contenuti — elementi che poi costano di più da aggiungere dopo.
Posso usare il mio hosting attuale o devo cambiarlo?
Dipende dalle performance dell’hosting. Se il TTFB supera gli 800 ms o l’hosting non supporta PHP 8.2+, HTTP/2 e certificato SSL gratuito, il cambio è consigliato. Un hosting condiviso da 3 euro/mese può funzionare per un sito da 10 pagine con poco traffico, ma diventa un collo di bottiglia sopra le 500 visite giornaliere. L’hosting è un costo ricorrente che impatta direttamente sulle performance — va valutato nel progetto, non dato per scontato.
Come verifico che il fornitore mi abbia consegnato tutti gli accessi?
Al go-live, dovresti avere: login admin WordPress con ruolo Administrator, credenziali FTP/SFTP, accesso al pannello hosting (cPanel, Plesk o equivalente), accesso al registrar del dominio con possibilità di trasferimento, proprietà GA4 con ruolo Editor, proprietà Search Console verificata, accesso al container GTM con ruolo Pubblica. Se manca anche uno solo di questi, il sito non è completamente sotto il tuo controllo. Chiedi per iscritto prima del saldo finale.
Il mio sito attuale ha 200 pagine: come gestisco la migrazione senza perdere traffico?
La migrazione richiede un piano di redirect 301 completo che mappi ogni URL del vecchio sito verso la corrispondente nel nuovo. Per 200 pagine, il lavoro include: crawl completo del sito esistente (con un crawler tecnico o strumento equivalente), export delle URL indicizzate da Search Console, mappatura uno-a-uno, implementazione dei redirect nel file .htaccess o nel sistema di redirect del server/CMS, e verifica post-migrazione per 30 giorni. Un piano di redirect incompleto su 200 pagine può causare una perdita di traffico organico che richiede mesi per recuperare.
Devo preoccuparmi dell’accessibilità web (WCAG) per il mio sito aziendale?
Sì, e non solo per ragioni etiche. La Direttiva UE 2019/882 (European Accessibility Act) estende i requisiti di accessibilità ai servizi digitali. Il livello minimo è WCAG 2.1 AA, che richiede tra le altre cose: rapporto di contrasto testo/sfondo di almeno 4,5:1, navigazione completa da tastiera, testi alternativi per le immagini, form con label associate ai campi. Un sito non accessibile è anche un sito con usabilità compromessa per tutti gli utenti — non solo per quelli con disabilità.
Cosa succede se il fornitore chiude o smette di rispondere dopo il lancio?
Se hai tutti gli accessi (punto 2 delle red flag contrattuali), puoi trasferire il sito a un altro fornitore senza perdite. Se non li hai, sei in una situazione di lock-in che può richiedere azioni legali per recuperare il controllo del tuo dominio e dei tuoi contenuti. Per questo l’ownership e gli accessi devono essere esplicitati nel contratto — non promessi a voce. È la clausola più importante dell’intero preventivo.
Ha senso investire in web design se il mio settore ha poca concorrenza online?
Poca concorrenza online significa opportunità, non motivo per risparmiare. Un sito ben progettato in un settore con bassa competizione SERP può posizionarsi per keyword commerciali in 60-90 giorni — un tempo molto inferiore rispetto a settori saturi. Ma “ben progettato” significa con architettura SEO, contenuti mirati e tracciamento: un sito brochure non si posiziona nemmeno senza concorrenza, perché Google valuta la qualità del contenuto indipendentemente dal numero di competitor.