Siti web e SEO / 04
Restyling del sito e SEO: conservare il percorso delle richieste
Il nuovo sito è curato. Un vecchio collegamento però non funziona, il cambio di lingua torna alla home e le richieste sono più difficili da seguire. Ecco cosa conservare e verificare perché il restyling aiuti davvero l’attività.
Un sito più bello può comunque perdere richieste
La nuova home è veloce, le schede sono curate e il menu mobile piace al gruppo di lavoro. Dopo qualche settimana, però, diminuiscono le richieste provenienti dalla ricerca. La causa potrebbe non essere il colore di un pulsante. Un servizio ha cambiato indirizzo, un collegamento esterno porta a una pagina mancante oppure il cambio di lingua apre sempre la home.
Un restyling modifica un sistema esistente di contenuti, collegamenti e percorsi. Prima delle bozze grafiche, chiarite cosa funziona già. Quale pagina presenta l’azienda? Quale risponde a una domanda prima dell’acquisto? Quale permette di contattarvi? La nuova struttura deve mantenere riconoscibili queste funzioni, anche quando cambia completamente il modo di mostrarle.
Gli esempi che seguono sono ipotetici, non risultati di clienti. Nessun piano di migrazione garantisce posizioni immutate nei motori di ricerca. Un inventario e verifiche ripetibili aiutano però a individuare errori evitabili prima del lancio. Un sito di qualità deve funzionare nell’uso quotidiano, oltre a fare una buona impressione.
Registrare il punto di partenza
Raccogliete gli URL dalla sitemap, dai collegamenti interni, dall’analisi delle visite e dai rapporti Search Console disponibili. Per ogni pagina importante annotate lingua, argomento, azione principale e dati utili. Non limitatevi al menu. Un vecchio articolo può ancora attirare persone interessate anche se il gruppo interno non lo considera più.
Il numero di visite non è l’unica misura del valore. Una pagina dedicata a un’integrazione specifica può raggiungere poche persone e rispondere esattamente alla loro esigenza. Un articolo generico potrebbe ottenere più traffico senza contribuire alle richieste. Esaminate i contatti e le tappe utili del percorso, rendendo visibili anche i limiti della misurazione.
Conservate titoli, descrizioni, intestazioni, testo sostanziale e collegamenti importanti. Non significa mantenere tutte le vecchie frasi. Serve una base per distinguere il cambiamento della presentazione da quello della risposta. Senza un riferimento, un calo diventa facilmente materia di supposizioni, anche quando è semplicemente scomparsa una pagina utile.
Registrare
URL, ricerche, richieste e moduli funzionanti.
Mappare
Prendere una decisione per ogni vecchio indirizzo.
Verificare
Lingue, redirect, indicizzazione e percorso di contatto completo.
Osservare
Confrontare pagine e periodi equivalenti dopo il lancio.
Se un modulo non funziona o una pagina chiave non è raggiungibile, un responsabile deve gestire la correzione o il ripristino.
Decidere il destino di ogni vecchio indirizzo
Per ciascun URL scegliete se conservarlo, spostarlo verso un equivalente, unirlo a materiale strettamente collegato o eliminarlo. La scelta deve rispettare l’esigenza originaria del visitatore. Reindirizzare tutti i servizi rimossi alla home può essere comodo da realizzare, ma raramente fornisce una risposta equivalente.
Google raccomanda reindirizzamenti permanenti lato server per le pagine trasferite e un percorso diretto alla destinazione finale. Un vecchio collegamento a un audit dovrebbe quindi aprire il nuovo audit corrispondente. Evitate passaggi intermedi inutili. Un reindirizzamento accompagna una persona, oltre a comunicare un cambiamento al motore di ricerca.
Chiedete una tabella di corrispondenza e verificate le righe sul server effettivo. Controllate stato HTTP, destinazione e assenza di cicli. Inserite alcuni vecchi percorsi linguistici e collegamenti di campagne. Un foglio corretto non dimostra che le regole pubblicate si comportino nello stesso modo.
Scorri orizzontalmente per vedere tutte le colonne.
| Situazione della pagina | Azione | Verifica |
|---|---|---|
| Indirizzo e contenuto restano | Mantenere la risposta 200 | Canonical autoreferenziale e link interni |
| Esiste una sostituta equivalente | Redirect permanente 301 o 308 | Un solo passaggio all’URL finale con risposta 200 |
| I contenuti vengono uniti | Reindirizzare alla pagina consolidata pertinente | La destinazione risponde all’intento di ricerca originale |
| Rimozione senza sostituzione | Risposta 404 o 410; rimozione dalla sitemap | Non reindirizzare tutto alla homepage |
Conservare la risposta cercata dal lettore
La vecchia pagina sull’automazione descriveva documenti, eccezioni e criteri di consegna. La nuova mostra soltanto «Costruiamo il futuro» sopra un pulsante. La composizione appare più pulita, ma chi compra non capisce più quale lavoro riceverà. Eliminare dettagli utili cambia lo scopo del contenuto, anche se il nome del servizio rimane.
Identificate l’intenzione di ogni pagina importante. La persona cerca un fornitore, confronta soluzioni, valuta i costi o prova a risolvere un problema? Scrivete per quella necessità. Le parole chiave pertinenti trovano naturalmente posto nei nomi dei servizi, negli esempi e nelle spiegazioni. Ripetere un termine non equivale a sviluppare un argomento.
Separate i temi che richiedono risposte diverse. Agenti IA, sviluppo web su misura e realizzazione di MVP possono avere pagine proprie, collegate dove serve. Il blog approfondisce le decisioni. In questo modo il lettore trova dettagli senza attraversare un testo generico che cerca di contenere ogni attività aziendale.
Assegnare un compito chiaro a ciascun tipo di pagina
La home presenta l’azienda e orienta. Una pagina di servizio descrive un incarico concreto. Un articolo aiuta a capire una scelta prima di acquistare. Quando questi compiti sono distinti, è più semplice valutare navigazione, testi e inviti all’azione. Non ogni persona è pronta a richiedere un preventivo al primo accesso.
Per un servizio spiegate a chi è adatto, cosa viene consegnato, quali informazioni servono e come si controlla il risultato. Mostrate prove reali che potete documentare. Un esempio illustrativo va dichiarato. Una grafica raffinata non trasforma numeri inventati in un caso cliente credibile.
Inserite collegamenti quando aiutano il passo successivo. Una guida sui costi dell’automazione può portare al servizio pertinente; la pagina commerciale può rimandare al calcolo dettagliato. Il testo del collegamento dovrebbe descrivere l’utilità della destinazione. Ripetere ovunque «scopri di più» rende più difficile scegliere.
Verificare il cambio di lingua nel contesto
Aprite un servizio preciso e cambiate lingua. Se esiste una traduzione corrispondente, deve apparire lo stesso argomento. Tornare alla home costringe a ripetere la ricerca. Su un articolo lungo il problema è particolarmente evidente: il lettore desidera continuare quel contenuto in una lingua più comoda.
Le annotazioni hreflang identificano versioni linguistiche o regionali collegate. I riferimenti devono essere coerenti e portare a pagine disponibili. Il tag non traduce il testo e non crea da solo rilevanza locale. Terminologia, contatti, esempi e informazioni commerciali devono essere adatti al pubblico previsto.
Lingua e paese sono decisioni differenti. Un’edizione inglese può servire più mercati. Una versione regionale ha senso quando spiega una vera differenza di offerta, condizioni o contenuto. Sostituire soltanto il nome del paese in molte pagine quasi identiche aiuta poco chi sta confrontando possibili fornitori.
Allineare gli URL canonici al sito pubblicato
L’URL canonico indica la versione preferita tra pagine duplicate o molto simili. Dopo il restyling deve corrispondere all’indirizzo pubblico previsto. Un errore nel modello può far puntare ogni servizio alla home o lasciare il dominio di anteprima. La stessa impostazione sbagliata si diffonde così a numerose pagine.
Esaminate l’HTML del server per home, servizio, articolo e traduzione. Poi controllate automaticamente tutte le pagine rilevanti. Confrontate i canonici con collegamenti interni e sitemap. Segnali contraddittori non diventano più chiari aggiungendo un altro tag senza risolvere il disaccordo.
Non raggruppate indiscriminatamente traduzioni complete sotto un canonico inglese. Una versione linguistica richiede generalmente un riferimento adeguato nella stessa lingua, mentre hreflang esprime il rapporto tra edizioni. Considerate le scelte insieme, affinché metadati, selettore linguistico e sitemap descrivano la stessa struttura.
Rendere il testo disponibile prima degli effetti
Caricate un articolo con una connessione lenta e osservate quando compaiono titolo, corpo e collegamenti. Controllate anche la risposta HTML del server. I contenuti editoriali si prestano a essere disponibili subito. La lettura non dovrebbe dipendere dal completamento di una grande animazione o da uno script estraneo alla pagina.
JavaScript può restare utile per moduli, calcolatori e interazioni pertinenti. La domanda è quali dipendenze siano davvero necessarie alla funzione principale. Distinguete il contenuto dagli arricchimenti che lo circondano. Questo permette di contenere i guasti e mantenere utilizzabile la pagina in condizioni comuni di rete e dispositivo.
Verificate che la navigazione utilizzi collegamenti reali. Le persone aprono destinazioni in un’altra scheda, copiano riferimenti e usano la tastiera. Alle destinazioni servono indirizzi validi; alle azioni servono pulsanti comprensibili. Una piccola scelta tecnica può rendere più affidabile l’intero percorso.
Partire dalla prima azione utile per migliorare le prestazioni
Un video grande o una scena tridimensionale può essere perfetto sul computer del designer. Provate la stessa pagina su uno smartphone comune con rete mobile. L’offerta si capisce presto? Il pulsante principale funziona? Il testo si sposta quando arriva una fotografia o viene caricata una nuova fonte?
I Core Web Vitals descrivono caricamento, reattività e stabilità visiva. Considerate i test di laboratorio insieme ai dati disponibili delle visite reali. Una singola prova veloce non rappresenta tutto il pubblico. Cercate gli elementi e le interazioni che producono un problema, invece di concentrarvi soltanto sul punteggio.
Riservate lo spazio dei media, controllate i caratteri e rimandate le risorse non necessarie all’inizio. Esaminate anche quanto codice client richiede una pagina da leggere. Spesso il concetto grafico può rimanere, mentre cambia l’ordine di caricamento. L’esperienza inizia prima che appaia l’ultimo effetto.
Usare le traduzioni reali nelle prove mobili
Un titolo breve in inglese può essere molto più lungo in tedesco, polacco o ucraino. Utilizzate i testi definitivi per schede, menu e pulsanti. Le parole importanti non devono sparire dietro altezze fisse o elementi decorativi. Un layout che funziona soltanto con testo provvisorio non è ancora pronto.
Completate l’azione principale su uno schermo stretto. Il pulsante della chat copre l’invio? La tastiera nasconde gli errori? Si può chiudere il menu delle lingue? Controllate le aree di tocco e il focus visibile. Questi dettagli influiscono direttamente sulla possibilità di terminare un’attività.
Un articolo lungo richiede una larghezza di lettura comoda, contrasto sufficiente e collegamenti alle sezioni. Su telefono un indice espandibile può mantenere breve l’apertura. Il lettore deve ritrovare un calcolo o una lista di controllo senza ripercorrere ogni volta l’intera guida.
Seguire una richiesta fino al responsabile
Il traffico organico serve a poco se il modulo fallisce senza segnalarlo. Provate il percorso dall’inserimento del messaggio al record finale, alla conferma e alla notifica alla persona corretta. Usate un ambiente concordato o dati chiaramente riconoscibili come test. Il messaggio di successo nel browser non dimostra da solo la ricezione.
Provate un campo mancante, un secondo clic e un errore temporaneo del server. L’utente deve capire se la richiesta è arrivata e cosa fare dopo. Conservate il testo fino alla conferma. Perdere un brief dettagliato per un problema momentaneo rovina l’esperienza anche su un sito molto curato.
Nell’analisi distinguete il clic dalla richiesta effettivamente ricevuta. Verificate duplicati e perdite durante i cambi di pagina. Se la misurazione cambia insieme al design, documentatelo. Altrimenti il confronto delle conversioni potrebbe descrivere un diverso tracciamento, non un diverso comportamento delle persone.
Fare descrivere ai metadati il contenuto visibile
Ogni pagina ha bisogno di un titolo specifico e di una descrizione coerente con argomento e lingua. Il titolo permette di riconoscere una risposta prima di aprirla. Elencare tutti i servizi dell’agenzia è generalmente meno utile che spiegare quella risorsa. Mantenete un rapporto chiaro tra risultato di ricerca e intestazione visibile.
I dati strutturati di un articolo possono indicare titolo, autore o organizzazione, date e immagine. Le informazioni devono corrispondere al materiale pubblicato. Non aggiornate date senza modifiche sostanziali e non inventate un esperto per creare autorevolezza. Una fonte comune dei contenuti facilita la coerenza.
Controllate anche l’anteprima del collegamento condiviso. Indirizzo, titolo, descrizione e immagine devono rappresentare la pagina specifica. Un articolo che sembra la home è più difficile da identificare. Questa prova può accompagnare i controlli linguistici e canonici, senza diventare un’attività dimenticata alla fine.
Separare l’anteprima dall’indicizzazione pubblica
La sitemap dovrebbe contenere gli indirizzi pubblici destinati alla scoperta. Escludete varianti accidentali di parametri, pagine di prova e URL che fanno soltanto un reindirizzamento. Richiedete le pagine e controllate le risposte. Un documento XML valido non dimostra che le sue destinazioni funzionino.
Bloccare l’indicizzazione può essere corretto nell’ambiente di anteprima. Prima del lancio, assicuratevi che quelle impostazioni non rimangano sui contenuti pubblici. Esaminate robots.txt, metadati e intestazioni HTTP. Hanno funzioni differenti; una singola opzione nel pannello non descrive sempre tutta la configurazione.
Le aree private richiedono un controllo degli accessi indipendente. Noindex non è autenticazione. Un inventario delle pagine di marketing permette di distinguerle da amministrazione e account clienti. In questo modo una modifica generale non viene applicata involontariamente a percorsi con finalità molto diverse.
Fare una verifica piccola ma completa al lancio
Scegliete esempi di ogni modello importante: home, servizio, articolo, contatto, traduzione e vecchio indirizzo reindirizzato. Apriteli dopo la pubblicazione sul dominio effettivo. Controllate testo, stato, lingua, canonico e azione principale. Una build riuscita non prova che dominio e ambiente siano configurati correttamente.
Provate moduli e notifiche nella modalità concordata. Credenziali dei servizi e domini autorizzati possono differire dall’anteprima. Individuate chi può correggere un’integrazione guasta. Il piano di lancio deve includere questa responsabilità operativa, non fermarsi al caricamento dei file.
Conservate un modo pratico per ripristinare la versione precedente e stabilite quando usarlo. Una richiesta impossibile da inviare richiede una reazione diversa da un piccolo errore di spaziatura. Questa distinzione mantiene la discussione concentrata sull’effetto per il cliente, invece che su singole schermate.
Confrontare condizioni confrontabili dopo il restyling
Partite dalle evidenze tecniche: pagine irraggiungibili, reindirizzamenti errati, variazioni nell’indicizzazione e moduli difettosi. Passate poi a ingressi, ricerche e contatti completati. Il traffico complessivo può nascondere un calo in una lingua o un servizio mentre un altro cresce.
Considerate stagionalità, campagne e cambiamenti dell’offerta. Se prezzi, acquisizione e design cambiano nello stesso momento, l’attribuzione sarà limitata. La base iniziale aiuta a separare regressioni tecniche evidenti da movimenti più ampi. Esplicitate questo limite, invece di attribuire tutto alla nuova grafica.
Non ricostruite pagine per ogni oscillazione giornaliera. Raccogliete prove adatte alla decisione. Non serve però aspettare una tendenza statistica quando un URL importante restituisce errore o un modulo non funziona. Correggete il difetto osservabile e misurate successivamente l’andamento generale.
Chiedere un sito che il gruppo possa mantenere
Insieme al design chiedete inventario dei percorsi, corrispondenze degli URL, regole linguistiche, risultati delle verifiche e istruzioni di pubblicazione. Sono strumenti per la prossima persona che farà una modifica. Devono spiegare le scelte e permettere di lavorare, non semplicemente riempire un documento.
Aggiungete un articolo non pubblicato e cambiatene il titolo. Controllate insieme pagina, scheda e metadati. Se la stessa informazione viene copiata a mano in più posti, aumenta la possibilità di divergenze. Una buona struttura editoriale rende ripetibile il risultato corretto nelle attività ordinarie.
Assegnate infine la responsabilità delle revisioni e dei collegamenti interrotti. Il restyling è una pubblicazione nella vita del sito. La sua qualità si vede di nuovo quando arriva un servizio, si amplia una lingua o si corregge una guida. La consegna deve permettere all’azienda di compiere questi cambiamenti con consapevolezza.
Prima di iniziare
- Salvare URL importanti, contenuti e dati iniziali.
- Concordare corrispondenze degli URL, percorsi linguistici e criteri di accettazione.
- Verificare configurazione di ricerca e percorso completo della richiesta sul dominio pubblico.
Nota editoriale. Gli esempi illustrano una scelta o una prova; non sono risultati di clienti.