Caso studio di rinnovamento del sito: Douzu Carry Service, azienda di trasporti di Miyazaki — cosa abbiamo ereditato dal vecchio sito, e come

La cosa più temibile in un rinnovamento del sito è che, mentre l’aspetto diventa nuovo, il posizionamento nei motori di ricerca e il percorso di contatto si rompano silenziosamente. Questa volta prendiamo come esempio il progetto di rinnovamento di «Douzu Carry Service», un’azienda di trasporti di Miyazaki, per fare il punto su cosa abbiamo definito prima ancora di toccare il design.

Quando si parla di rinnovamento del sito, la discussione inizia spesso dalle bozze di design o dall’aspetto della home page. Ma quando il vecchio sito ha già un traffico di ricerca o backlink significativi, ci sono cose da decidere prima del design, altrimenti diventa difficile tornare indietro in seguito. Sono la progettazione degli URL e il modo di ereditare le informazioni del vecchio sito.

Questo articolo prende come esempio il rinnovamento di «Douzu Carry Service», un’azienda di trasporti di Miyazaki specializzata in traslochi individuali, consegne a lunga distanza e trasporto refrigerato, e riassume i passaggi concreti seguiti. Una panoramica sintetica è disponibile in il caso studio che riassume la struttura di Douzu Carry Service, ma questo articolo approfondisce ulteriormente i dettagli.

Da notare che questo articolo non presenta cifre di impatto come variazioni nel numero di visite o richieste di contatto. Ciò che possiamo riportare qui si limita ai fatti — cosa è stato fatto, e con quali passaggi — perché i dati numerici sui risultati non fanno parte delle fonti di questo articolo.

1. Panoramica del progetto — Prima / Dopo

Iniziamo dal quadro generale.

Le principali pagine statiche — home, elenco servizi, trasloco, trasporto refrigerato, consegna in giornata, trasloco in struttura per anziani, prezzi, informazioni aziendali, FAQ e contatti — insieme alle nove pagine di area per Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima ed Ebino, hanno mantenuto l’URL invariato durante il rinnovamento. Ciò che è cambiato principalmente è stato il trattamento degli URL privi di significato del vecchio blog e di uno script residuo inutilizzato.

Inoltre, il design del nuovo sito è stato costruito sulla base del design system pubblicato dall’Agenzia Digitale giapponese (Digital Agency). Saltare la fase di progettazione del design da zero ci ha permesso di destinare lo sforzo risparmiato al lavoro di progettazione degli URL e migrazione dei contenuti trattato in questo articolo. La logica di questo approccio è illustrata in «Perché KomuraSoft costruisce i siti web sul design system dell’Agenzia Digitale — costi contenuti e qualità possono coesistere».

Se dovessimo riassumere in un solo punto questo caso, sarebbe questo: abbiamo completato l’inventario di URL e contenuti prima di toccare il design visivo, e solo dopo abbiamo iniziato. I capitoli seguenti illustrano questo processo passo per passo.

2. Il primo passo non è stato il design, ma un inventario degli URL

La prima cosa prodotta all’avvio del rinnovamento non è stata una bozza di design, ma una tabella di inventario che elencava tutti gli URL del vecchio sito.

Nello specifico, abbiamo catalogato in modo esaustivo quanto segue.

• Pagine statiche (home, elenco servizi, trasloco, trasporto refrigerato, consegna in giornata, trasloco in struttura per anziani, informazioni aziendali, informativa sulla privacy, FAQ, prezzi, blog, contatti)
• Le nove pagine di area (Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima, Ebino)
• I singoli articoli del vecchio blog (oltre 100, da rubriche locali ad articoli pratici su traslochi individuali e a lunga distanza)
• «File che non sono pagine ma restano pubblicamente accessibili», come robots.txt, sitemap.xml, il file di verifica della proprietà di Search Console e il vecchio script di invio moduli (php/submit.php)

Solo dopo aver realizzato questo inventario abbiamo potuto costruire una tabella di mappatura che decidesse, URL per URL, cosa fare sul nuovo sito. Nella tabella di mappatura di questo progetto, abbiamo suddiviso la decisione in due grandi categorie.

Le pagine statiche, le pagine di area e gli URL degli articoli del blog attualmente significativi sono stati tutti impostati come keep (invariati). D’altra parte, gli URL con stringhe casuali prive di significato numerate automaticamente dal sistema (del tipo /blog/5lmln1lx0x/) e i nomi di file con data come post20210721.html sono stati progettati per reindirizzare con 301 verso nuovi URL di articoli con uno slug significativo.

Un’altra cosa rientrata in questo processo decisionale è stata php/submit.php, uno script di destinazione dell’invio rimasto sul vecchio sito. Abbiamo verificato che non fosse referenziato da alcun modulo nell’HTML pubblicato, e che i canali di contatto effettivamente funzionanti fossero solo i tre sistemi telefono, email e preventivo LINE — lo abbiamo quindi giudicato uno «script residuo abbandonato» e lo abbiamo impostato per reindirizzare con 301 a /contact/ (approfondiamo il contesto di questa decisione nel prossimo capitolo e nel capitolo 5).

Per la progettazione dei redirect, abbiamo applicato senza eccezioni due regole.

• Risolvere ogni redirect in un solo hop (mai creare una catena di redirect)
• Integrare nel build un controllo che verifichi che l’URL di destinazione esista realmente (per evitare l’incidente di un 301 verso un URL inesistente)

Fissare questo inventario e questa tabella di mappatura prima ancora di considerare il design significa che le fasi successive di implementazione e creazione dei contenuti possono procedere sulla solida base di «cosa mettere su quale URL», riducendo le rilavorazioni. Questo non riguarda solo questo progetto — è una procedura di base che si applica altrettanto direttamente a qualsiasi rinnovamento di un vecchio sito che abbia già backlink o traffico di ricerca.

3. Una checklist di conservazione per non «perdere» contenuti

In parallelo al lavoro di progettazione degli URL, abbiamo costruito una checklist di conservazione dei contenuti per verificare che tutte le informazioni scritte sul vecchio sito potessero essere riprodotte senza eccezioni sul nuovo.

In un rinnovamento, piccoli testi promozionali e numeri possono sparire silenziosamente nel processo di rinnovamento del design. Se ciò che sparisce sono informazioni che influenzano direttamente la decisione di contattare — prezzi, orari di apertura, contatti, punti di forza chiave — questo può portare proprio alla situazione in cui il sito ha un aspetto migliore ma le richieste di contatto calano.

Abbiamo quindi annotato, per ogni pagina principale, le informazioni indispensabili del vecchio sito da conservare. Ecco una parte di ciò che includeva.

Con questa checklist a disposizione, abbiamo confrontato una per una le pagine vecchie e nuove prima del lancio del nuovo sito, confermando che nessun elemento fosse andato perso. Il punto chiave è che abbiamo garantito, tramite una lista anziché con l’intuito o la memoria, che il «materiale decisionale» — prezzi, orari, punti di forza — fosse riportato intatto nonostante il cambio di design.

4. SEO locale — la progettazione delle nove pagine di area

Tra le pagine ereditate dal vecchio sito ci sono nove pagine individuali, una per ciascuna delle seguenti aree: Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima ed Ebino.

Queste pagine di area esistono come punto di atterraggio per le query di ricerca che includono un nome di luogo, del tipo «[nome del luogo] + trasloco» o «[nome del luogo] + consegna». Per un servizio come il trasporto o il trasloco, dove il bacino di utenza è legato a regioni specifiche, svolgono il ruolo di catturare la domanda di ricerca legata al nome del luogo che la sola home page o pagina prezzi non riesce a intercettare completamente.

Osservando la tabella di mappatura degli URL, tutte e nove le pagine da /area/miyazaki/ a /area/ebino/ sono state classificate come keep (nessun cambio di URL), e il rinnovamento non ha toccato questa struttura. Accanto a esse, ci sono anche numerosi articoli del blog legati a ciascuna area che trattano nomi di luoghi locali specifici — i quartieri della città di Miyazaki o di Miyakonojo, per esempio — formando una struttura in cui le pagine di area e gli articoli del blog si completano a vicenda.

Pagine come queste pagine di area — il tipo prodotto moltiplicando solo il nome del luogo in un formato altrimenti identico — rischiano, se il contenuto è scarno, di sembrare copie riciclate della stessa pagina sia ai motori di ricerca sia ai lettori. In questo caso, la divisione dei compiti è stata ereditata dal vecchio sito: le pagine di area stesse gestiscono il livello dell’area, mentre gli articoli del blog coprono individualmente il dettaglio a livello di quartiere all’interno di ciascuna area. Questa struttura evitava già la «scarsità» tipica delle pagine prodotte in massa. Il rinnovamento ha lasciato questa struttura intatta e ha mantenuto invariati gli URL.

5. Consolidamento di canali di contatto dispersi

Il modo in cui abbiamo trattato php/submit.php, menzionato nel capitolo 3, è stata anche una decisione importante dal punto di vista dell’organizzazione del percorso di contatto.

Esaminando il vecchio sito, abbiamo confermato che solo i seguenti tre sistemi funzionavano realmente come canali di contatto pubblicamente disponibili.

• Telefono (0120-931-677, orario di accettazione 8:00–20:00)
• Email
• Preventivo LINE

D’altra parte, lo script di destinazione dell’invio php/submit.php restava nel codice, ma non era referenziato da alcun modulo nell’HTML pubblicato. In altre parole, era uno «script residuo» in realtà non più utilizzato. Su questa base, il nuovo sito consolida i tre canali — telefono, email e preventivo LINE — sulla pagina /contact/, e qualsiasi accesso a php/submit.php è progettato per reindirizzare con 301 a /contact/.

Quando i canali di contatto sono dispersi tra più pagine e script, è facile perdere traccia, proprio nel momento del rinnovamento, di quali siano effettivamente in uso. Questo approccio — identificare prima quali canali funzionano realmente, poi consolidarli, come abbiamo fatto qui — vale anche come principio generale per rivedere il percorso tra home page, pagine di servizio e pagina di contatto. Abbiamo trattato questa idea anche in un articolo precedente, «Le tre cose da correggere per prime su un sito che non riceve richieste di contatto», che vale la pena consultare.

6. Pulizia dei vecchi domini — gestione di un dominio di landing page abbandonato

Le aziende come quelle di trasporti, che hanno creato landing page separate per ciascun servizio, a volte si ritrovano, senza troppo accorgersene, con i domini dispersi in più punti. Anche in questo caso, abbiamo dovuto sistemare i seguenti domini.

Il terzo caso in particolare è una lezione importante. Il contenuto della vecchia landing page per il trasporto refrigerato — i suoi punti di forza su veicoli dotati di unità frigorifere a −20 °C, disponibilità 24 ore su 24 e 7 giorni su 7, e consegne programmate e su percorso — è già stato migrato a /refrigerated/ sul nuovo sito. Ma poiché il vecchio dominio stesso non è più risolvibile, probabilmente a causa di una registrazione DNS scaduta, non c’è modo di impostarvi un redirect 301. La lezione è che se lasci un dominio senza manutenzione e senza rinnovo, rischi di perdere improvvisamente, un giorno, l’autorità dei backlink e il traffico di ricerca del marchio accumulati su di esso.

Se la tua azienda gestisce landing page di servizio su domini separati e sta valutando un rinnovamento, ti consigliamo di non limitarti a decidere dove consolidare il contenuto, ma di verificare contemporaneamente anche lo stato contrattuale del vecchio dominio — se il rinnovo è ancora attivo e se il suo DNS è ancora vivo. Poter ancora impostare un redirect 301 mentre il recupero è possibile fa una differenza reale su quanto facilmente l’autorità accumulata potrà essere riportata in seguito.

7. Verifica prima del lancio e attività post-lancio

Prima di lanciare il nuovo sito, abbiamo eseguito i seguenti controlli.

• Confronto con la checklist di conservazione dei contenuti costruita nei capitoli 2 e 3 (le pagine vecchie e nuove hanno elementi corrispondenti)
• Verifica dal vivo dei redirect 301 (inviare effettivamente richieste e confermare che restituiscano i codici di stato e le destinazioni attese)
• Conferma che il file di verifica della proprietà di Search Console restituisca correttamente un 200
• Conferma che i file necessari per il lancio, come robots.txt, sitemap.xml e _headers, siano effettivamente pubblicati

Ci sono anche attività da gestire dopo il lancio.

• Reinviare sitemap.xml a Search Console
• Usare lo strumento di ispezione URL per confermare individualmente che gli URL con ID del vecchio blog e i nomi di file .html con data reindirizzino con 301 come previsto
• Nell’arco di diverse settimane, controllare nel report di copertura se i vecchi URL, in precedenza in 404 o esclusi dall’indice, arrivano a essere riconosciuti come «Redirect»

Un progetto di rinnovamento non finisce con il lancio — conviene pianificarlo partendo dal presupposto che è veramente completo solo dopo aver monitorato i redirect e confermato che il motore di ricerca li abbia correttamente riconosciuti dopo il lancio.

8. Riepilogo — regole generali per non fallire un rinnovamento

Distillando il ragionamento tratto da questo caso Douzu Carry Service in idee che si applicano ugualmente ad altri progetti di rinnovamento, si ottiene quanto segue.

• La progettazione degli URL viene prima, il design viene dopo. Per un vecchio sito con traffico di ricerca o backlink già esistenti, finalizza l’inventario completo degli URL e la tabella di mappatura verso i nuovi URL (mapping 301) prima ancora di considerare il design visivo.
• Non lanciare senza un inventario dei contenuti. Conferma il «materiale decisionale» come prezzi, orari di apertura, contatti e punti di forza con una checklist che confronta una per una le pagine vecchie e nuove, prima del lancio.
• Mantieni solo i canali effettivamente in uso. Se trovi un modulo o uno script di invio inutilizzato, verifica cosa sta realmente accadendo, poi consolidalo nel canale ancora attivo.
• Abbina ogni redirect a un singolo hop e alla verifica dell’esistenza della destinazione. Non creare mai catene, e disponi di un meccanismo che non mandi mai verso un URL inesistente.
• Ripulisci i domini finché sono ancora attivi. Lascia un dominio separato per una landing page di servizio senza manutenzione, e una registrazione DNS scaduta può renderlo irrecuperabile — costandoti proprio l’opportunità di riportare avanti l’autorità accumulata.

Un rinnovamento del sito non è semplicemente il lavoro di rinfrescare il design — è anche, a sua volta, un lavoro di progettazione che consiste nel capire come riportare avanti l’autorità di ricerca e il percorso di contatto accumulati nel tempo. Una panoramica sintetica di questo caso è riassunta in «il caso studio che riassume la struttura di Douzu Carry Service», che vale la pena consultare.

Se hai preoccupazioni simili riguardo alla progettazione degli URL o al riporto dei contenuti esistenti, possiamo lavorare insieme sull’inventario del vecchio sito nell’ambito di una consulenza di sviluppo siti web.

Articoli correlati

• Il caso studio che riassume la struttura di Douzu Carry Service
• Perché KomuraSoft costruisce i siti web sul design system dell’Agenzia Digitale — costi contenuti e qualità possono coesistere
• Le tre cose da correggere per prime su un sito che non riceve richieste di contatto
• Sviluppo siti web
• Contatti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Da cosa dovrebbe iniziare un rinnovamento del sito?

Non da una bozza di design, ma da una tabella di inventario che elenca tutti gli URL del vecchio sito. Questo significa catalogare in modo esaustivo le pagine statiche, le pagine di area e gli articoli del blog, oltre ai «file che non sono pagine ma restano pubblicamente accessibili», come robots.txt, il file di verifica della proprietà di Search Console e gli script di invio dei moduli. Da qui si costruisce una tabella di mappatura che decide, URL per URL, se mantenerlo invariato o reindirizzarlo (301). Fissare questa base fin dall'inizio riduce le rilavorazioni nelle fasi successive di implementazione e creazione dei contenuti.

Quali sono i punti chiave nella progettazione dei redirect per evitare un calo del posizionamento nei motori di ricerca durante un rinnovamento?

Mantieni invariati gli URL significativi — pagine statiche, pagine di area, ecc. — e reindirizza con un 301 solo gli URL privi di significato, numerati automaticamente dal sistema, verso nuovi URL con uno slug significativo. Come regole di progettazione, applichiamo senza eccezioni due punti: ogni redirect si risolve in un solo hop, senza creare catene, e il processo di build include un controllo che verifica che l'URL di destinazione esista realmente, per evitare l'incidente di un 301 verso un URL inesistente. Dopo la pubblicazione, monitoriamo Search Console per diverse settimane finché non riconosce i redirect.

Perché un rinnovamento a volte finisce per far calare le richieste di contatto?

Perché, nel processo di rinnovamento del design, le informazioni che influenzano direttamente la decisione di contattare — prezzi, orari di apertura, contatti, punti di forza — possono sparire silenziosamente senza che nessuno se ne accorga. Come contromisura, costruiamo una checklist di conservazione dei contenuti che annota, per ogni pagina principale, le informazioni indispensabili del vecchio sito (piani tariffari, orari di accettazione, servizi offerti, ecc.), per poi confrontare una per una le pagine vecchie e nuove prima della pubblicazione. Il punto chiave è garantirlo con una lista, non con la memoria o l'intuito.

Va bene lasciare abbandonata una landing page inutilizzata su un dominio separato?

Lasciarla abbandonata è rischioso. In questo caso, il vecchio dominio della landing page per il trasporto refrigerato non era più risolvibile, probabilmente perché il suo DNS era scaduto — e anche se il contenuto era già stato migrato al nuovo sito, non restava alcun modo per impostare un redirect 301 dal vecchio dominio. Se lasci un dominio senza manutenzione e senza rinnovo, rischi di perdere improvvisamente, un giorno, l'autorità dei backlink e il traffico di ricerca del marchio accumulati su di esso. Quando valuti un rinnovamento, verifica sia lo stato contrattuale del vecchio dominio sia se il suo DNS è ancora attivo, e imposta il redirect 301 finché il recupero è ancora possibile.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.