I tuoi URL esistenti non vengono toccati. Le versioni tradotte vengono aggiunte accanto ad essi, quindi nulla di ciò che hai già pubblicato si sposta o si interrompe.
Nulla cambia nelle tue pagine originali
example.com/pricing/ continua a funzionare esattamente come prima, allo stesso URL, nella stessa lingua. Universally aggiunge example.com/es/pricing/ accanto ad esso.
Ciò significa:
- Nessun link esistente, interno o esterno, si interrompe
- Nessun posizionamento di ricerca esistente viene disturbato, perché la pagina non si è spostata
- La tua lingua di origine rimane alla radice, senza prefisso
Quali link segue un visitatore
Su una pagina tradotta, i link interni vengono riscritti per mantenere il visitatore nella sua lingua. Da /es/pricing/, un link a /features/ diventa /es/features/, in modo che la navigazione non torni silenziosamente alla lingua di origine.
Alcuni percorsi non dovrebbero essere riscritti, come gli URL delle risorse, gli endpoint API e i feed. Questi sono elencati in Escludi localizzazione link. Vedi Escludi localizzazione link.
Come i visitatori raggiungono una pagina tradotta
Tramite il selettore di lingua, o tramite un link all'URL tradotto, o dai risultati di ricerca, poiché le pagine tradotte vengono indicizzate a pieno titolo.
Non ci sono reindirizzamenti automatici basati sulla lingua del browser. Nulla legge le preferenze linguistiche del browser, quindi un visitatore che arriva per la prima volta al tuo URL principale ottiene la tua lingua di origine, indipendentemente da ciò che chiede il suo browser. Se desideri un reindirizzamento basato sulla lingua, questo deve essere implementato a livello del tuo edge o server.
Questo è deliberato piuttosto che una lacuna: il reindirizzamento automatico della lingua è una fonte comune di problemi, perché sovrascrive una scelta esplicita e i crawler di ricerca vedono qualcosa di diverso dagli utenti.
La lingua scelta da un visitatore viene ricordata
La scelta del visitatore è un'altra questione, ed è questo il comportamento da conoscere prima di configurare una cache.
La visualizzazione di qualsiasi URL tradotto memorizza quella lingua in un cookie universally_lang per 30 giorni. Finché è impostato, una richiesta a un URL senza prefisso di lingua viene reindirizzata alla stessa pagina nella lingua memorizzata. Quindi un visitatore di ritorno al tuo URL principale non ottiene la lingua di origine, ottiene la sua.
La via del ritorno è il link alla lingua di origine del selettore, che porta ?universally_switch=source. Questo cancella il cookie e riporta il visitatore all'URL senza prefisso. Un semplice link all'URL di origine non lo cancella, quindi il reindirizzamento si ripete.
Il reindirizzamento viene saltato per i percorsi di sistema di WordPress (/wp-admin/, /wp-json/, wp-login.php e il resto), per qualsiasi cosa che assomigli a un file (sitemap.xml, robots.txt, favicon.ico) e per i percorsi in Escludi pagine.
Poiché la risposta a un URL senza prefisso dipende ora dal visitatore, questo è l'unico comportamento di Universally che una cache a pagina intera interrompe veramente. Vedi Caching e CDN.
Reindirizzamenti che Universally esegue
Cinque, ed è utile conoscerli quando si esegue il debug di un reindirizzamento imprevisto 301 o 302:
| Reindirizzamento | Stato |
|---|---|
| Un percorso escluso richiesto al suo URL tradotto, inviato alla pagina originale, stringa di query preservata | 301 |
/es senza la barra finale, inviato a /es/ |
301 |
| Un URL senza prefisso per un visitatore con una lingua memorizzata, inviato a quella lingua | 302 |
?universally_switch=source, inviato all'URL pulito dopo aver cancellato la lingua memorizzata |
302 |
| Qualsiasi reindirizzamento di WordPress su una pagina tradotta mantiene il prefisso della lingua sulla sua destinazione | invariato |
Vedi Escludi pagine per il primo.
Se cambi un URL sul tuo sito
Su WordPress questo è in gran parte gestito per te. Il prefisso della lingua viene rimosso prima che WordPress gestisca la richiesta, quindi un reindirizzamento esistente da /old-page/ a /new-page/ viene attivato anche per /es/old-page/, e il prefisso viene ripristinato sulla destinazione: il visitatore atterra su /es/new-page/, ancora in spagnolo. Questo copre i plugin di reindirizzamento e qualsiasi altra cosa che reindirizza tramite WordPress.
Due casi necessitano ancora della propria regola per il percorso con prefisso:
- Reindirizzamenti nella configurazione del tuo web server o CDN, che vedono
/es/old-page/all'arrivo - Reindirizzamenti scritti in PHP con una chiamata
header()grezza anziché tramite WordPress