Prima di rifare il sito aziendale: obiettivi, contenuti e processi da analizzare

Rifare il sito aziendale non dovrebbe iniziare dalla scelta del nuovo layout, del CMS o del fornitore. Prima di progettare le pagine è utile chiarire che cosa il sito deve ottenere, a chi deve rivolgersi, quali contenuti deve ospitare, quali azioni deve favorire e con quali processi e sistemi aziendali deve dialogare.

Questo passaggio è importante soprattutto quando il progetto non riguarda un semplice aggiornamento grafico. Se cambiano struttura, contenuti, URL, moduli, tracciamenti o integrazioni, il rifacimento interessa anche marketing, commerciale, dati e organizzazione.

Una buona analisi iniziale consente quindi di trasformare una richiesta generica — “dobbiamo rifare il sito” — in un insieme di obiettivi e requisiti comprensibili prima che inizi lo sviluppo.

Quando ha senso rifare un sito aziendale

Non esiste una scadenza universale oltre la quale un sito debba essere sostituito.

Il rifacimento può diventare opportuno quando il sito non rappresenta più correttamente l’azienda, l’offerta è cambiata, gli utenti faticano a trovare informazioni importanti oppure la struttura non supporta più le attività di marketing e commerciali.

Altri motivi possono riguardare limiti tecnici, difficoltà di gestione dei contenuti, esigenze di integrazione con altri sistemi, problemi di esperienza mobile, prestazioni o accessibilità.

La presenza di uno di questi elementi non significa però automaticamente che sia necessario ricostruire tutto. In alcuni casi può essere sufficiente intervenire su una parte del sito. La prima decisione consiste proprio nel capire quale problema si vuole risolvere e quanto è esteso.

Restyling grafico e rifacimento del sito non sono la stessa cosa

Un restyling modifica principalmente la presentazione visiva: colori, tipografia, immagini, componenti e organizzazione grafica.

Un rifacimento più ampio può invece coinvolgere:

• architettura delle informazioni;
• contenuti e pagine;
• percorsi di navigazione;
• funzionalità;
• moduli e raccolta dei contatti;
• sistemi di analytics;
• integrazioni con CRM o altri software;
• struttura degli URL;
• piattaforma tecnologica;
• prestazioni, accessibilità e sicurezza.

La distinzione è importante perché cambia il tipo di analisi necessaria. Se il problema riguarda struttura e processi, cambiare soltanto l’aspetto può lasciare irrisolte le criticità principali.

Partire dagli obiettivi, non dalla grafica

Prima di decidere come sarà il nuovo sito è utile rispondere a una domanda più semplice: che ruolo deve svolgere per l’azienda?

Un sito può avere obiettivi diversi. Può presentare servizi, generare richieste commerciali, supportare la rete vendita, distribuire documentazione, facilitare il contatto con determinate figure aziendali oppure combinare più funzioni.

“Essere più moderni” è un’indicazione troppo generica per guidare un progetto.

Un obiettivo più utile potrebbe essere, per esempio:

• rendere comprensibili servizi complessi;
• facilitare la richiesta di un preventivo;
• indirizzare pubblici differenti verso contenuti specifici;
• migliorare la raccolta dei lead;
• supportare attività SEO e content marketing;
• permettere al team interno di aggiornare alcune informazioni con maggiore autonomia.

Non tutti questi obiettivi richiedono le stesse pagine o le stesse funzionalità.

Collegare gli obiettivi alle azioni da misurare

Un obiettivo diventa più utile alla progettazione quando viene associato a un comportamento osservabile.

Se il sito deve generare opportunità commerciali, occorre decidere quali azioni sono significative: invio di un modulo, richiesta di contatto, prenotazione, download di un documento o un’altra interazione coerente con il processo commerciale.

Google Analytics 4 distingue gli eventi dalle azioni considerate particolarmente importanti per l’attività, definite “eventi chiave”.

Questo non significa che Google Analytics debba stabilire gli obiettivi dell’azienda. Il principio è l’opposto: prima si decide cosa conta per il processo aziendale, poi si configura la misurazione necessaria.

Capire destinatari e percorsi prima di progettare le pagine

Un sito aziendale raramente parla a un unico interlocutore.

Un potenziale cliente che conosce già l’impresa cerca informazioni diverse rispetto a chi arriva da Google per la prima volta. Un responsabile tecnico può avere esigenze differenti da un imprenditore o da un responsabile acquisti.

Per questo, prima dell’architettura delle pagine, conviene individuare almeno:

• i principali destinatari;
• i loro bisogni informativi;
• le informazioni necessarie per valutare l’offerta;
• le azioni che ci si aspetta possano compiere;
• gli eventuali ostacoli lungo il percorso.

Non occorre costruire buyer persona artificialmente dettagliate. Serve invece comprendere chi deve trovare cosa e con quale logica.

Dalle esigenze degli utenti all’architettura informativa

L’architettura informativa organizza contenuti e relazioni tra le pagine.

Non dovrebbe derivare soltanto dall’organigramma interno dell’azienda. La struttura deve aiutare gli utenti a riconoscere rapidamente dove trovare l’informazione che cercano.

Per esempio, una divisione aziendale può essere perfettamente comprensibile internamente ma poco significativa per un potenziale cliente. Al contrario, organizzare alcune sezioni in base ai problemi, ai servizi o ai casi d’uso può rendere più semplice la navigazione.

La scelta dipende dal contesto, ma deve essere intenzionale.

Fare l’inventario dei contenuti esistenti e di quelli mancanti

Uno degli errori più semplici da commettere durante il rifacimento è progettare il nuovo sito e occuparsi dei contenuti solo alla fine.

Testi, fotografie, documenti, video e schede di servizio influenzano invece la struttura stessa delle pagine.

Prima del redesign è utile costruire un inventario dei contenuti esistenti e chiedersi:

• quali sono ancora corretti;
• quali devono essere aggiornati;
• quali sono duplicati o non più utili;
• quali informazioni importanti mancano;
• chi possiede le informazioni necessarie;
• chi dovrà approvare i nuovi contenuti.

Decidere cosa mantenere, aggiornare, eliminare o creare

Rifare il sito non significa trasferire automaticamente tutto ciò che esiste nel precedente.

Una pagina può generare traffico organico, essere utilizzata dai clienti, ricevere collegamenti esterni oppure svolgere una funzione commerciale anche se internamente viene considerata poco importante.

Prima di eliminarla è quindi necessario valutarne il ruolo.

Allo stesso modo, mantenere indiscriminatamente ogni contenuto storico può trasferire nel nuovo sito problemi di ridondanza, informazioni obsolete e una struttura diventata poco chiara.

La migrazione dei contenuti dovrebbe essere una decisione editoriale, non una semplice operazione di copia.

Analizzare processi, funzionalità e integrazioni

Il sito non termina necessariamente quando un utente preme “Invia”.

Un modulo può attivare una notifica, alimentare un CRM, assegnare un contatto a una persona, generare una richiesta di assistenza o entrare in un processo commerciale più articolato.

Questi passaggi devono essere conosciuti prima dello sviluppo.

Tra le domande utili:

• dove devono arrivare i dati raccolti;
• quali informazioni sono realmente necessarie;
• chi prende in carico la richiesta;
• quali strumenti sono già utilizzati dall’azienda;
• quali integrazioni devono essere mantenute o introdotte;
• quali eventi devono essere misurati;
• chi deve poter modificare determinati contenuti.

Cosa succede dopo un modulo di contatto?

Immaginiamo un sito B2B con un modulo “Richiedi informazioni”.

Graficamente il requisito sembra semplice. Dal punto di vista del processo può invece richiedere decisioni su campi, consenso, destinatari, assegnazione commerciale, CRM, notifiche, misurazione e gestione delle richieste non valide.

Se queste domande vengono affrontate solo a sito quasi completato, è più probabile dover modificare funzionalità e flussi già sviluppati.

Analizzare il processo prima permette invece di progettare il sito in funzione del lavoro reale dell’organizzazione.

Definire i requisiti del nuovo sito

Dopo aver chiarito obiettivi, utenti, contenuti e processi è possibile trasformare le informazioni raccolte in requisiti.

Può essere utile dividerli almeno in quattro gruppi.

Requisiti strategici: quale ruolo ha il sito, a quali pubblici si rivolge e quali obiettivi deve sostenere.

Requisiti contenutistici: quali informazioni devono essere presenti, chi le produce e come devono essere organizzate.

Requisiti funzionali: moduli, ricerche, aree riservate, integrazioni, automazioni, lingue o altre funzioni necessarie.

Requisiti tecnici: gestione dei contenuti, prestazioni, compatibilità, accessibilità, sicurezza, misurazione e requisiti collegati alla visibilità organica.

Prestazioni e sicurezza non dovrebbero essere considerate semplicemente rifiniture finali. I Core Web Vitals, per esempio, misurano aspetti dell’esperienza reale relativi a caricamento, reattività e stabilità visiva; Google raccomanda buone prestazioni, ma precisa che ottenere buoni punteggi non garantisce da solo migliori posizioni nei risultati di ricerca.

Anche sul fronte della sicurezza, OWASP raccomanda di definire requisiti e controlli già nella pianificazione e progettazione, adattandoli al rischio e alle caratteristiche dell’applicazione.

Per l’accessibilità, le WCAG 2.2 del W3C costituiscono uno standard tecnico internazionale di riferimento per rendere i contenuti web più accessibili.

L’applicabilità di specifici obblighi normativi deve invece essere verificata separatamente in relazione all’organizzazione e al servizio interessato.

Coinvolgere gli stakeholder prima dello sviluppo

Il sito non dovrebbe essere progettato soltanto sulla base delle informazioni possedute da una persona.

A seconda dell’azienda possono essere coinvolti marketing, commerciale, direzione, IT, customer service e responsabili di specifici servizi.

Non serve convocare ogni reparto per ogni decisione. È però utile identificare:

• chi fornisce le informazioni;
• chi definisce i requisiti;
• chi approva contenuti e funzionalità;
• chi utilizzerà gli strumenti collegati;
• chi dovrà gestire il sito dopo la pubblicazione.

In questo modo eventuali vincoli possono emergere quando è ancora possibile integrarli nel progetto.

Proteggere ciò che funziona durante la migrazione

Quando il rifacimento modifica URL, struttura o contenuti già presenti sui motori di ricerca, la migrazione SEO non dovrebbe essere affrontata il giorno della pubblicazione.

Google raccomanda di preparare una corrispondenza tra vecchi e nuovi URL, aggiornare i collegamenti interni e le indicazioni canonical, predisporre la nuova sitemap e utilizzare reindirizzamenti permanenti coerenti quando gli URL cambiano. Dopo lo spostamento occorre monitorare scansione, indicizzazione e traffico secondo le indicazioni ufficiali di Google per le migrazioni dei siti.

Google segnala inoltre che durante modifiche importanti possono verificarsi fluttuazioni temporanee nei risultati mentre i nuovi URL vengono nuovamente scansionati e indicizzati.

Questo rende importante costruire prima del rifacimento un inventario degli URL e delle pagine che possiedono valore.

La SEO migration deve entrare nel progetto prima della messa online

Un piano minimo di migrazione dovrebbe chiarire:

1. quali URL esistono oggi;
2. quali continueranno a esistere;
3. quali cambieranno;
4. quale nuova pagina corrisponde a ciascun URL eliminato o modificato;
5. quali collegamenti interni devono essere aggiornati;
6. quali sitemap, canonical e impostazioni di indicizzazione devono essere controllati;
7. come verranno monitorati errori e andamento dopo il lancio.

Un reindirizzamento non deve essere utilizzato per portare indiscriminatamente tutte le vecchie pagine verso la home. Google raccomanda destinazioni pertinenti e avverte che reindirizzamenti irrilevanti possono creare problemi per utenti e motori.

L’obiettivo non è promettere che non ci sarà mai alcuna variazione di traffico, ma evitare che informazioni già disponibili vengano perse per mancanza di pianificazione.

Preparare un brief prima di chiedere lo sviluppo

A questo punto l’azienda dovrebbe essere in grado di descrivere il progetto senza partire da una richiesta generica come “ci serve un sito nuovo”.

Un brief preliminare utile può contenere:

• obiettivi del sito;
• pubblici prioritari;
• azioni principali degli utenti;
• struttura iniziale dei contenuti;
• inventario delle pagine esistenti;
• contenuti da produrre o aggiornare;
• funzionalità richieste;
• integrazioni con sistemi aziendali;
• esigenze di misurazione;
• requisiti di prestazioni, accessibilità e sicurezza;
• vincoli tecnici o organizzativi;
• responsabilità interne;
• esigenze di SEO migration.

Non è necessario che ogni requisito sia già definito tecnicamente. Il brief serve proprio a separare ciò che l’azienda deve ottenere dalle successive decisioni su come realizzarlo.

Questo permette anche di confrontare proposte e fornitori sulla base di un problema più chiaro, anziché limitarsi a confrontare layout, piattaforme o preventivi difficilmente equivalenti.

Quando può essere utile un confronto professionale

Se il rifacimento interessa soltanto alcuni elementi grafici, il progetto può essere relativamente circoscritto.

Quando invece coinvolge obiettivi commerciali, contenuti, struttura, SEO, integrazioni, analytics e processi interni, la fase preliminare assume un peso maggiore.

In questi casi può essere utile separare il momento dell’analisi da quello dello sviluppo: prima definire esigenze, priorità e requisiti; poi scegliere architettura, tecnologia e modalità di realizzazione.

È l’approccio utilizzato da DieSSe Ingegneria Digitale nei progetti di siti web professionali: partire da obiettivi, destinatari e processi prima di definire la soluzione tecnica.

Se stai valutando il rifacimento del sito aziendale e vuoi chiarire prima obiettivi, contenuti e requisiti, puoi richiedere un primo confronto con DieSSe.