Seus URLs existentes não são alterados. Versões traduzidas são adicionadas ao lado delas, então nada que você já publicou se move ou quebra.
Nada muda em suas páginas originais
exemplo.com/preco/ continua funcionando exatamente como antes, no mesmo URL, no mesmo idioma. Universally adiciona exemplo.com/es/preco/ ao lado dela.
Isso significa:
- Nenhum link existente, interno ou externo, quebra
- Nenhum ranking de busca existente é perturbado, porque a página não se moveu
- Seu idioma de origem permanece na raiz, sem prefixo
Quais links um visitante segue
Em uma página traduzida, os links internos são reescritos para manter o visitante em seu idioma. De /es/preco/, um link para /recursos/ se torna /es/recursos/, para que a navegação não retorne silenciosamente ao idioma de origem.
Alguns caminhos não devem ser reescritos, como URLs de ativos, endpoints de API e feeds. Estes estão listados em Excluir Localização de Links. Veja Excluir localização de links.
Como os visitantes chegam a uma página traduzida
Através do seletor de idioma, ou por um link para o URL traduzido, ou a partir de resultados de busca, já que as páginas traduzidas são indexadas por direito próprio.
Não há redirecionamento automático com base no idioma do navegador. Nada lê a preferência de idioma do navegador, então um visitante de primeira viagem que chega à sua URL raiz recebe seu idioma de origem, independentemente do que o navegador solicitar. Se você quiser redirecionamento baseado em idioma, ele deve ser implementado em sua própria camada de borda ou servidor.
Isso é deliberado em vez de uma falha: o redirecionamento automático de idioma é uma fonte comum de problemas, pois substitui uma escolha explícita e os rastreadores de busca veem algo diferente dos usuários.
O idioma que um visitante escolheu é lembrado
A própria escolha de um visitante é outra questão, e este é o comportamento a saber antes de configurar um cache.
Visualizar qualquer URL traduzida armazena esse idioma em um cookie universally_lang por 30 dias. Enquanto ele estiver definido, uma solicitação para um URL sem prefixo de idioma é redirecionada para a mesma página no idioma armazenado. Assim, um visitante recorrente em sua URL raiz não recebe o idioma de origem, ele recebe o seu.
O caminho de volta é o link do idioma de origem do seletor, que carrega ?universally_switch=source. Isso limpa o cookie e retorna o visitante ao URL sem prefixo. Um link simples para o URL de origem não o limpa, então o redirecionamento acontece novamente.
O redirecionamento é ignorado para caminhos do sistema WordPress (/wp-admin/, /wp-json/, wp-login.php e o resto), para qualquer coisa que pareça um arquivo (sitemap.xml, robots.txt, favicon.ico), e para caminhos em Excluir Páginas.
Como a resposta em um URL sem prefixo agora depende do visitante, este é o único comportamento do Universally que um cache de página inteira realmente quebra. Veja Cache e CDNs.
Redirecionamentos que o Universally realiza
Cinco, e vale a pena conhecê-los quando você estiver depurando um 301 ou 302 inesperado:
| Redirecionamento | Status |
|---|---|
| Um caminho excluído solicitado em sua URL traduzida, enviado para a página original, string de consulta preservada | 301 |
/es sem a barra final, enviado para /es/ |
301 |
| Uma URL sem prefixo para um visitante com um idioma armazenado, enviado para esse idioma | 302 |
?universally_switch=source, enviado para a URL limpa após limpar o idioma armazenado |
302 |
| Qualquer redirecionamento do WordPress em uma página traduzida mantém o prefixo de idioma em seu destino | inalterado |
Veja Excluir páginas para o primeiro.
Se você alterar uma URL em seu site
No WordPress, isso é em grande parte tratado para você. O prefixo de idioma é removido antes que o WordPress roteie a solicitação, portanto, um redirecionamento existente de /old-page/ para /new-page/ também é acionado para /es/old-page/, e o prefixo é recolocado no destino: o visitante acessa /es/new-page/, ainda em espanhol. Isso cobre plugins de redirecionamento e qualquer outra coisa que redirecione através do WordPress.
Dois casos ainda precisam de sua própria regra para o caminho prefixado:
- Redirecionamentos na configuração do seu servidor web ou CDN, que veem
/es/old-page/conforme ele chega - Redirecionamentos escritos em PHP com uma chamada
header()bruta em vez de através do WordPress