Questo è il forum di assistenza tecnica di WPML, il plug-in multilingue di WordPress.
La sua lettura è permessa a tutti, ma la pubblicazione è riservata esclusivamente ai clienti di WPML. Il team di WPML risponde sul forum 6 giorni su 7, 22 ore su 24.
Lingue: Inglese (English )Spagnolo (Español )Italiano (Italiano )
Fuso orario: Europe/Madrid (GMT+02:00)
Ho verificato il comportamento e in realtà la pagina cinese esiste, ma il suo slug non è /rooms/ bensì:
link nascosto
Quindi quando viene aperto /zh-hans/rooms/, WordPress non trova una pagina con quel permalink in cinese e applica il fallback verso la lingua predefinita (inglese), reindirizzando a /rooms/.
Questo non indica necessariamente un problema di mapping nelle tabelle icl_translations.
Ti ho preparato un breve video dove ti mostro tutto passo per passo e ti spiego il comportamento nel dettaglio. link nascosto
Ciao Paola, grazie per il video. Ho fatto dei test seguendo la tua indicazione sugli slug tradotti per risolvere il redirect verso l'inglese.
Tuttavia, ho riscontrato un problema critico: quando provo a uniformare lo slug in 'rooms' per l'Italiano (o altre lingue), il sistema va in collisione e reindirizza l'utente dall'Italiano direttamente verso la versione Rumena, invece di restare sulla pagina corretta.
Per evitare disservizi agli utenti, ho ripristinato manualmente tutti gli slug originali (es. camere per l'Italiano, 客房 per il Cinese) e rigenerato i permalink per stabilizzare la navigazione.
A questo punto, visto che il problema del redirect verso l'inglese persiste per le lingue straniere, ti chiedo di intervenire per:
Risolvere il conflitto nel database che causa il 'salto' dall'Italiano al Rumeno quando si usa lo slug rooms.
Forzare la sincronizzazione delle traduzioni (attualmente molte appaiono con l'icona blu rotante di 'lavoro in corso') per garantire che ogni lingua punti al proprio slug corretto senza fallback.
Lingue: Inglese (English )Spagnolo (Español )Italiano (Italiano )
Fuso orario: Europe/Madrid (GMT+02:00)
Il problema si presenta quando utilizziamo lo stesso slug per lingue diverse: è in quel caso che avviene il redirect.
Per poter analizzare meglio la situazione, mi dai il permesso di installare il plugin Check Conflicts? In questo modo posso attivare e disattivare i plugin senza influire sul sito in produzione.
Avrei inoltre bisogno di installare anche il plugin Adminer, così da poter accedere al database e verificare se ci sia qualcosa di non corretto direttamente a livello di database.
Lingue: Inglese (English )Spagnolo (Español )Italiano (Italiano )
Fuso orario: Europe/Madrid (GMT+02:00)
Ho modificato lo slug sia per l’italiano sia per il rumeno in modo che abbiano lo stesso slug, così da poter riprodurre il problema nelle stesse condizioni.
Da parte mia ora funziona correttamente.
Puoi verificare anche tu, per favore, se dal tuo lato è tutto ok?
Ciao Paola, ho analizzato la sitemap completa del sito (caalvise.com/sitemap_index.xml) e ho trovato un'incoerenza importante che potrebbe spiegare i 469 errori di redirect su Google Search Console.
La pagina "Rooms" ha slug diversi a seconda della lingua:
Italiano, Rumeno, Arabo, Cinese → /rooms/ (slug inglese, modificato durante i fix)
Tedesco, Francese, Olandese, Spagnolo, Portoghese, Ceco, Polacco, Turco, Russo, Giapponese → slug tradotto nella lingua locale (/zimmer/, /chambres/, /kamers/, ecc.)
Inoltre, la pagina cinese Rooms (/zh-hans/客房/) non appare nella sitemap, pur esistendo nel database.
Prima di procedere con qualsiasi azione su Google Search Console (Validate Fix, reinvio sitemap, ecc.), avrei bisogno di capire:
Struttura definitiva degli slug: dobbiamo uniformare tutte le lingue sullo slug inglese /rooms/ oppure ripristinare gli slug tradotti per tutte le lingue?
Stato del database: nella tabella icl_translations, ci sono ancora trid duplicati o entry orfane che puntano a post_id inesistenti?
Pagina cinese: perché /zh-hans/客房/ non compare nella sitemap pur esistendo nel database?
Non toccherò nulla finché non avrò la tua conferma sulla direzione da prendere. Grazie mille!
Lingue: Inglese (English )Spagnolo (Español )Italiano (Italiano )
Fuso orario: Europe/Madrid (GMT+02:00)
Se desideri avere lo slug tradotto per le pagine (che in effetti è la soluzione più corretta in un sito multilingue), puoi farlo senza alcun problema.
Mi avevi però segnalato che il problema si presentava quando utilizzavamo lo stesso slug tra le lingue. Per questo motivo ho impostato temporaneamente lo stesso slug, così da poter riprodurre e verificare il comportamento.
Se ora con lo slug tradotto tutto funziona correttamente, puoi tranquillamente mantenerlo tradotto.
Fammi sapere come preferisci gestire gli slug delle pagine:
– slug tradotto per ogni lingua
– oppure lo stesso slug anche nelle traduzioni
Ciao Paola, preferisco mantenere lo slug tradotto per ogni lingua — è la soluzione più corretta per la SEO. Puoi confermarmi che il database è ora stabile con questa configurazione e che non ci sono più conflitti latenti?
Lingue: Inglese (English )Spagnolo (Español )Italiano (Italiano )
Fuso orario: Europe/Madrid (GMT+02:00)
Ciao!
Perfetto, in questo modo eviterai anche molti problemi con i reindirizzamenti.
Ti chiedo quindi di aggiungere lo slug tradotto a ogni pagina e di avvisarmi quando avrai finito, così potrò verificare che sia tutto configurato correttamente.
Ho testato in navigazione anonima circa la metà delle lingue del sito (turco, tedesco, francese, spagnolo, portoghese, olandese) e tutti gli URL tradotti caricano correttamente la pagina nella lingua giusta.
Tuttavia ho notato che i vecchi URL (es. /it/rooms/, /zh-hans/rooms/) invece di redirezionare al nuovo slug tradotto, vanno tutti a /rooms/ (inglese). È normale o c'è ancora qualcosa da sistemare nel database?
Volevo anche chiederti una conferma generale: il problema originale dei redirect errati tra lingue (es. cinese → portoghese) è stato completamente risolto a livello di database? Possiamo considerare il ticket chiuso o ci sono ancora interventi pendenti?
Grazie mille!
Lingue: Inglese (English )Spagnolo (Español )Italiano (Italiano )
Fuso orario: Europe/Madrid (GMT+02:00)
Ciao!
Sì, quello che stai vedendo è normale.
Quando accedi a un URL che non esiste più (come ad esempio /it/rooms/ o /zh-hans/rooms/), WordPress prova automaticamente a fare un redirect verso lo slug più simile che trova. In questo caso trova /rooms/, che è lo slug della pagina in inglese, e quindi ti porta lì. Questo comportamento non dipende da WPML ma dal sistema di redirect canonici di WordPress.
Dato che ora hai già aggiornato gli slug tradotti per ogni lingua (/camere/, /الغرف/, /客房/, ecc.), la navigazione corretta è tramite quei nuovi URL, e sembra che funzionino correttamente.
Ciao Paola, grazie per la spiegazione sui redirect di WordPress, è chiaro.
Volevo però una conferma sulla domanda principale: il problema originale dei redirect errati tra lingue diverse (es. cinese che reindirizzava al portoghese) è stato completamente risolto nel database? Le tabelle icl_translations sono ora corrette e senza entry orfane?
Grazie!
