Wordpress non gestisce nativamente la funzionalità multilingua ma è possibile realizzare il sito vs sito in più lingue utilizzando vari approcci differenti:
Approcci possibili
Multisite (una installazione per lingua)
Crei un network WordPress e un “sito” per ogni lingua (es.example.com/it,example.com/en).
Pro: isolamento pulito dei contenuti, performance prevedibili, permessi separati, plugin/tema configurabili per lingua.
Contro: manutenzione più articolata (backup, utenti, plugin), relazioni tra contenuti manuali se non supportate da plugin dedicati.Plugin multilingua su singolo sito
Tutte le lingue convivono nella stessa installazione. Opzioni più diffuse:Polylang: leggero, ottimo per blog/siti corporate; estensione a pagamento per WooCommerce.
WPML: completo, include traduzione stringhe, media, workflow; più “pesante”.
TranslatePress: traduzione visuale dal front-end, supporto MT (da rivedere/redigere).
Pro: una sola installazione da gestire, linking tra traduzioni semplice.
Contro: lock-in da plugin, possibili impatti su performance in siti molto grandi.
Multisite + plugin di collegamento (es. MultilingualPress)
Ibrido: benefici di Multisite con collegamento “nativo” tra versioni tradotte.
Pro: scalabilità, nessun contenuto duplicato nel DB di un solo sito.
Contro: costo/licenza, setup più tecnico.Headless/Jamstack
WordPress solo come CMS; front-end (Next.js/Nuxt) gestisce i18n.
Pro: massima libertà su UX/performance, routing i18n su misura.
Contro: richiede team con competenze da sviluppo front-end moderno e DevOps.
Come scegliere (decision quick-guide)
Sito piccolo/medio senza e-commerce: Polylang o TranslatePress.
Sito complesso o con molto flusso redazionale: WPML (workflow, TM, stringhe).
Portale enterprise o network di brand/paesi: Multisite (con o senza MultilingualPress).
Team con skill React e focus performance/SEO avanzata: Headless.
Struttura URL e SEO internazionale
Struttura consigliata: sottocartelle per lingua (
/it/,/en/, …). In alternativa sottodomini (it.example.com) o domini ccTLD. Mantieni una sola strategia ovunque.hreflang: obbligatorio per evitare contenuti duplicati tra lingue e far capire a Google la variante corretta. I plugin citati lo gestiscono; verifica anche la versione “x-default”.Sitemap per lingua: meglio separare ed elencarle in
robots.txt.Slug, title e meta tradotti: non lasciare slugs inglesi su pagine italiane e viceversa.
Redirect iniziale per lingua del browser: se lo usi, fallo solo alla prima visita, salva preferenza (cookie) e non indicizzare la pagina di redirect.
Contenuti davvero localizzati: evita traduzioni “letterali”; adatta esempi, misure, valute, date.
Note per WooCommerce
Lingua ≠ valuta: valuta, tasse e spedizioni possono variare per paese, non solo per lingua. Valuta e tasse vanno gestite con plugin specifici (multi-currency, geolocalizzazione).
Prodotti e attributi: traduci titoli, descrizioni, attributi e termini (paio/pack, taglie, materiali).
URL prodotto e categorie: traduci slug e ricontrolla i 301 se cambi struttura.
Email transazionali: predisponi template per lingua (ordine, spedizione, resi).
Ricerca e filtri: assicurati che l’indice (es. Elastic/Algolia) sia separato per lingua o includa il campo lingua nei documenti.
Workflow di traduzione
Glossario e guida di stile per coerenza terminologica.
Processo a step: bozza → traduzione → revisione → QA (link, moduli, formati numeri/date).
Stringhe di tema/plugin: usa
.po/.mo(Loco Translate) o il modulo “String Translation” del tuo plugin i18n.Media: valuta se duplicare o riutilizzare; in molti casi le stesse immagini bastano, ma cura i testi ALT per lingua.
Performance e caching
Cache per lingua: varia la cache per path (
/it/,/en/) e per cookie se usi redirect alla prima visita.CDN: regole di purge e invalidation consapevoli della lingua.
Ricorda il Vary: evita di variare su
Accept-Languagelato server quando non serve, per non esplodere la cache.
Checklist di avvio rapido
Scegli struttura URL e plugin/architettura.
Definisci lingue, glossario e stile.
Imposta
hreflang, sitemap per lingua e meta.Traduci menu, widget, footer, form, email.
Traduci slugs e controlla i 301.
Configura cache/CDN per lingua.
QA completo (contenuti, moduli, pagamenti, ricerca).
Monitora Search Console per ogni lingua/property.
Errori comuni da evitare
Mescolare sottocartelle e sottodomini senza motivo.
Lasciare meta/slug non tradotti.
Redirect forzato ad ogni visita (esperienza pessima + problemi di indicizzazione).
Non separare la cache per lingua.
Affidarsi solo alla MT senza revisione umana.
Se ti interessa, posso aggiungere una tabella comparativa rapida tra Polylang/WPML/TranslatePress/Multisite (pro, contro, costi tipici, compatibilità WooCommerce) o adattare l’articolo al tuo caso d’uso specifico.
Nessun commento:
Posta un commento