Il link italiano puntava all’inglese. Come abbiamo corretto Wix Multilingual
La pagina italiana dei progetti di NourVerse si apriva all’indirizzo corretto. Nel codice pubblicato, però, il collegamento hreflang riservato all’italiano indicava la pagina inglese. Per chi cambiava lingua dal menu tutto poteva sembrare a posto. Il segnale che il sito forniva ai motori di ricerca raccontava una storia diversa. Ecco come abbiamo isolato il problema e quali controlli abbiamo ripetuto dopo la modifica.
Parti da una pagina interna
Apri la pagina Progetti e annota l’indirizzo completo. Passa all’italiano con il selettore e verifica titolo, contenuto e indirizzo. Su NourVerse la coppia da confrontare era /portfolio in inglese e /it-it/portfolio in italiano. Apri entrambi gli indirizzi anche in una finestra privata, così puoi osservare la prima visita senza la preferenza linguistica già salvata.
Ripeti il percorso da una pagina che contiene un’azione, come il modulo di contatto. Cambia lingua mentre sei sulla pagina. Controlla se resti sulla stessa funzione e se i campi obbligatori, il pulsante e i messaggi di errore si leggono nella lingua scelta.
Confronta canonical e hreflang
Nel codice HTML della pagina pubblicata cerca rel="canonical" e i link con hreflang. Il canonical della pagina italiana indicava già /it-it/portfolio. L’alternativa it-IT, invece, indicava /portfolio. Scrivi il valore atteso e quello trovato per ogni lingua. Ripeti il controllo su tutte le versioni, perché i rimandi tra le traduzioni devono essere coerenti in entrambe le direzioni.
Il nostro sito usava it-IT come formato regionale sia per la versione inglese principale sia per quella italiana. Abbiamo impostato en-IT per l’inglese e mantenuto it-IT per l’italiano. Sulle quattro versioni pubblicate di Progetti, l’alternativa it-IT ha quindi iniziato a indicare /it-it/portfolio ed en-IT ha indicato /portfolio. È un risultato specifico della configurazione di questo sito. Per diagnosticare un altro sito, parti dai link che il CMS genera davvero.
Prova il selettore ai lati dei punti di cambio layout
Abbiamo verificato il menu anche a 337, 899 e 1.348 pixel nel browser. A 899 pixel siamo passati dall’italiano all’arabo e abbiamo aperto il menu. A 337 pixel abbiamo raggiunto il modulo arabo: i campi seguivano la direzione da destra a sinistra e la pagina non scorreva orizzontalmente. Misurare anche appena prima e dopo il cambio di layout aiuta a trovare sovrapposizioni tra selettore e menu.
Fai un passaggio con la tastiera. Tab deve raggiungere il selettore, Invio deve aprirlo e il focus deve restare visibile. In arabo prova un campo che contiene cifre e un indirizzo e-mail. Su un telefono reale controlla anche la tastiera a schermo e l’orientamento orizzontale. Nel registro separa le prove su dispositivo dalle misure in emulazione.
Conserva un controllo che puoi ripetere
Per ogni riga salva pagina di partenza, lingua, indirizzo atteso, indirizzo ottenuto, canonical ed esito. Se il problema è visibile nel menu, controlla prima la destinazione del selettore. Se l’indirizzo e il contenuto sono corretti ma la lingua alternativa è errata, esamina i metadati generati dal CMS. Ripeti la riga dopo ogni modifica e allega una schermata soltanto se aiuta a ricostruire il difetto.
Inizia con quattro righe per la pagina Progetti, una per lingua. Aggiungi poi le pagine che portano a un’azione: contatto, download o prenotazione. Il controllo è concluso quando puoi aprire ogni versione direttamente e raggiungerla anche dal selettore, con il relativo indirizzo confermato nel codice pubblicato.
Comments