Restyling di un sito Internet: step da seguire per un aggiornamento senza intoppi

Cosa mi aspetta se volessi rifare un sito ? Quali sono gli step fondamentali per fare un restyling grafico e tecnico di un sito Web ? Quando e perche’ e’ piu conveniente fare un restyling del nostro sito Internet ? Queste ed altre domande spesso non hanno una valida risposta. Vediamo di fare un po’ di chiarezza, senza alcun interesse commerciale che puo’ veicolare il nostro libero discernimento.

Di sicuro il panorama digitale e’ il futuro. Tutto sta andando verso il digitale. Spesso le realta’ che hanno iniziato agli albori del Web, non avendo subito alcun restyling, sono rimaste talmente indietro da essere superata da freschezza nei contenuti, originalita’ e tecnologia. E’ quindi giusto interrogarsi e, una volta esaminati tutti gli aspetti tecnici ed economici valutare il restyling.

Perche’ fare un restyling ? Ovviamente per aumentare la produttivita’ e la brand identity visto che il Web rappresenta l’immagine che l’azienda fa percepire all’esterno. Troppo spesso si trovano multinazionali che hanno siti a dir poco inguardabili perche’ fatti troppo tempo fa e non piu’ reale immagine dell’azienda che dovrebbero rappresentare.
Dall’analisi interna, dai feedback di partner e clienti ed analizzando la concorrenza si riesce a capire se e’ il caso di sottoporre il sito ad un’analisi tecnica specializzata per capire dove e come intervenire.

Se da un lato potrebbe essere piu’ “facile” per un SEO lavorare su un sito “anziano”, per il tecnico che dovra’ eseguire il restyling potrebbe essere un lavoro piu’ arduo perche’ magari certe tecnologie sono sorpassate (Es. ASP e’ stato ormai abbandonato a favore dell’ASP.NET) o perche’ sul sito e’ presente un catalogo prodotti che, nonostante l’analisi abbia portato evidenti difetti, riesce ad essere spinto con campagne Media o Pay Per Click ed altre metodologie che portano gli utenti ad acquistare. Come fare per migliorarsi in questi casi ?

L’analisi ed il piano d’azione sono quindi fondamentali per capire come intervenire cercando di ridurre al minimo i tempi dello switch. Nel “peggiore dei casi” gli step fondamentali possono essere riassunti nei seguenti:
– pianificazione degli interventi
– realizzazione del sito in un’ambiente analogo al definitivo accessibile solo agli addetti ai lavori ed al cliente per gli opportuni feedback
– messa offline del sito attuale
– allineamento db (vecchio —> nuovo)
– allineamento files (vecchio –> nuovo)
– allineamento struttura tabelle
– verifica ecommerce
– ultima verifica funzionalita’ prima del puntamento dei DNS
– puntamento DNS (vecchio –> nuovo)
– agg.to vecchio server
– messa offline sito nuovo
– allineamento db (nuovo —> vecchio)
– allineamento files (nuovo –> vecchio)
– ultima verifica funzionalita’ prima del puntamento dei DNS
– puntamento DNS (nuovo –> vecchio)

Questo potrebbe essere un piano di lavoro efficace per un sito che ha sopra un e-commerce e che necessita, oltre che dell’aggiornamento grafico e tecnico, anche dell’aggiornamento della macchina evidenziato da PEN test sull’architettura che ospita il sito. Se e’ infatti fondamentale rispettare alcune linee guida fondamentali (Es. OWASP) e’ anche opportuno tenere presente che la macchina che ospita il sito, debba essere prestante ed aggiornata onde evitare spiacevoli sorprese.

Nella prima fase e’ bene definire gli interventi da fare, eventualmente che linguaggio di sviluppo utilizzare (PHP, ASP.NET, JSP etc. etc.) ed appoggiarci allo sviluppo su una macchina o virtual host sulla stessa macchina. Supponendo di dover aggiornare anche la macchina e’ bene sviluppare su un’altra macchina di appoggio con software il piu’ possibile identico a quello che sara’ la macchina definitiva, onde evitare problemi.

Una volta individuata la macchina virtuale temporanea di appoggio e’ doveroso fornire al cliente gli strumenti per vedere il sito durante tutte le fasi dello sviluppo. E’ quindi opportuno configurare la macchina con software adeguato e con la replica allo stato attuale del sito, per poter operare in autonomia.

Una volta terminato lo sviluppo e ricevuto l’ok del cliente alla messa online del sito, opportunamente rivisto tecnicamente e graficamente per raggiungere gli obiettivi prefissati, dovremo inizialmente mettere offline il vecchio sito in tutte le sue parti, presentando una index temporanea che spiega agli utenti il motivo della messa offline ed eventuali recapiti alternativi (Es.: Telefono, Fax, Indirizzi mail per eventuali ordini o richieste informazioni specifiche). In questa fase e’ bene comunicare sui canali alternativi (Facebook, Forum, Chat) l’operazione in corso per tranquillizzare gli utenti.

E’ quindi necessario allineare i database e tutti i files dal sito vecchio a quello nuovo in modo da avere una situazione identica alla messa offline del sito. In tal modo ci assicuriamo che tutti gli interventi fatti nel vecchio pannello di controllo, i caricamenti di immagini, prodotti, i nuovi ordini, le nuove iscrizioni etc. etc. vengano correttamente replicate sul nuovo sito e non si subiscano perdite o problemi con i clienti che avevano effettuato gli acquisti nel sito vecchio, durante il periodo necessario al restyling.
Solitamente, su macchine linux, queste operazioni vengono fatte con un rsync dei dati (Es. del comando rsync da lanciare sulla macchina di appoggio: rsync -a –delete bitubit.it:/var/www/vhosts/bitubit.it/httpdocs/ /var/www/html/www.bitubit.it/) e con un mysqldump e conseguente ricaricamento sul sito nuovo.
Es. da eseguire nella macchina di appoggio:
ssh www.bitubit.it mysqldump –password=<PSW> –single-transaction  –user=<USER> –add-drop-table –databases BITuBIT  > /home/BACKUP/BITuBIT.sql
mysql -u<USERLOC> -p<PSWLOC> -hlocalhost < /home/BACKUP/BITuBIT.sql

dove:
<PSW> e’ la password per l’accesso al Database nell’host vecchio
<USER>
e’ il nome utente per l’accesso al Database nell’host vecchio
<USERLOC> e’ il nome utente per l’accesso al Database sull’host nuovo
<PSWLOC>
e’ la password per l’accesso al Database nell’host nuovo

Una volta fatti gli allineamenti e’ opportuno replicare gli interventi sugli script, qualora fosse necessario, e/o modificare la struttura delle tabelle presenti nel / nei Database per allinearle con i nuovi tecnicismi. E’ bene fare in modo di ridurre al minimo questi interventi e realizzarsi strutture ex-novo (Es.: prefissi diversi per le nuove tabelle create, cartelle di lavoro differenti per i nuovi script) il tutto basandosi sull’analisi del sito esistente e sulle opportunita’ offerta dalla tecnologia sfruttata (Es.: .htaccess per gli opportuni redirect etc. etc.).
E’ anche da tenere presente che se le vecchie URL cesseranno di esistere, non e’ assolutamente immaginabile non ricordarsi che i motori di ricerca non aggiornano in tempo reale i loro dati; occorre quindi mantenere il percorso di navigazione il piu’ possibile intatto portando l’utente, e quindi il motore, in maniera trasparente dall’url vecchio al nuovo (Es.: product.php?id=69 –> restyling-sito-web.php). Questi tecnicismi sono fondamentali per non trovarsi un sito che dall’oggi al domani, subisca un notevole calo degli accessi nonostante sia migliorato tecnicamente e graficamente.

Una volta teminata questa fase, e’ bene verificare le funzionalita’ dell’ecommerce, perche’ nel frattempo il sistema di gestione dei pagamenti potrebbe aver subito un notevole miglioramento nell’usabilità, quindi il restyling e’ il momento per approfittare e passare dal vecchio al nuovo sistema di e-commerce implementato dalla banca.

Una volta effettuate tutte le verifiche e’ possibile procedere al puntamento del DNS che e’ solitamente la parte piu’ annosa e difficile da spiegare al cliente e mettere in pratica, visto che talvolta non e’ possibile gestire direttamente i DNS autoritativi o si effettuano cambiamenti da pannelli come PLESK, CPANEL etc. che non possono intervenire direttamente sui DNS autoritativi. E’ quindi opportuno verificare a priori i tempi di aggiornamento dei DNS autoritativi, anche per dare delle tempistiche realistiche al cliente per uno switch che e’ difficilmente valutabile in maniera esatta e che dipende da una miriade di fattori, non indifferenti. Solitamente la notte potrebbe essere il momento migliore per fare lo switch ma non sempre e’ cosi’ (Se in Italia e’ notte in America e’ giorno e se il prodotto viaggia su scala globale la cosa si complica!).

Una volta che il sito gira sulla nuova piattaforma e’ bene controllare gli error log in tempo reale e correggere quanto prima eventuali chiamate da altri siti verso url obsoleti, immagini non piu’ presenti ed altri piccoli errori invisibili ai piu’, ma presenti e che vanno ottimizzati al meglio per migliorare la velocita’ del sito stesso fattore determinante per un sito ben fatto e fruibile in maniera chiara.
E’ molto importante ascoltare il parere degli utenti, ossia coloro che dovranno usufruire del sito stesso e che dovranno essere guidati nel nuovo mondo a cui non erano abituati. E’ principalmente dai loro feedback che si capisce dove intervenire per migliorare la navigazione e l’esposizione dei contenuti.

Una volta certi che non sono necessari processi di rollback e che i DNS sono globalmente diffusi possiamo procedere con assoluta tranquillita’ all’aggiornamento fisico e/o software della macchina che ospitava in precedenza il sito. Una volta verificata l’installazione delle eventuali patch di sicurezza fondamentali e verificato che tutto funzioni e sia configurato in maniera analoga alla macchina che ospita il sito, si puo’ procedere con gli ultimi step inversi, ossia la messa offline del sito, la copia dei files e dei database sulla macchina appena aggiornata ed al ripristino delle funzionalita’.

Nota a margine: in alcuni casi, nonostante il charset della macchina appena aggiornata sia corretto e l’export del database sia esatto, potrebbero esserci dei problemi di visualizzazione di lettere accentate, etc. In particolare per gli apostrofi potrebbero esserci dei problemi se provengono da word o altro wordprocessor. In PHP, supponendo di avere un abstract nell’array $prodotto e’ possibile intervenire in questo modo:

$abstractPagina = utf8_encode(str_replace(‘’’,”‘”,$prodotto[‘abstract’]));
$abstractPagina = str_replace(“’”,”‘”,$abstractPagina);
$prodotto[‘abstract’] = $abstractPagina;

In taluni casi, utilizzando ad esempio Dreamweaver il carattere presente nella str_replace non viene mostrato a video ma state sereni, c’e’ e viene correttamente rimpiazzato.

Chiaramente anche in questo caso solo una volta ultimate le opportune verifiche sulla macchina aggiornata (navigazione, charset, metatag, rewrite, upload, registrazioni, pagamenti) si puo’ procedere con la messa online del sito e con l’ultimo puntamento del DNS, per poi attendere la corretta propagazione e la fine di tutti gli sforzi fatti!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.