Redirecionamentos

Quando você renomeia uma página ou post, não quer que links antigos quebrem. O Chinaski mantém URLs antigas funcionando com redirecionamentos, e esta página explica como eles são criados, como se comportam e os formatos de exportação para seu host.

Como os redirecionamentos funcionam

Seu site publicado é HTML estático, então o Chinaski implementa redirecionamentos de duas maneiras:

Na URL antiga, o site entrega uma pequena página que avisa ao navegador "este conteúdo mudou de lugar" e envia o leitor direto para a nova localização, com um link apropriado quando o JavaScript está desligado. Os mecanismos de busca veem um link canônico apontando para a nova URL, então páginas antigas não competem com as novas nos resultados.
Um arquivo de regras de redirecionamento, gerado a cada build, que o proxy da sua hospedagem pode ler (veja os formatos de exportação abaixo), para que servidores modernos possam responder com um redirecionamento apropriado em vez da página de fallback.

Os redirecionamentos são por idioma: cada slug antigo pertence a um idioma específico e aponta para o destino naquele mesmo idioma.

Conteúdo vivo sempre vence: se uma página ou post publicado já existe no slug antigo, nenhum redirecionamento é gerado para ele; o próprio conteúdo é servido.

O que acontece automaticamente

Você normalmente não gerencia redirecionamentos à mão:

Renomear o slug de uma página ou post publicado cria um redirecionamento para a URL antiga automaticamente.
Mudar o prefixo de URL dos posts do blog (por exemplo, mover /journal/ para /blog/) redireciona automaticamente cada post publicado do seu caminho de prefixo antigo.
A raiz do site redireciona para o índice do seu blog ou para sua página inicial escolhida se nenhuma página raiz existir.
Canonicalização de domínio: se a URL do seu site é example.com, uma regra é gerada que envia o tráfego de www.example.com (ou vice-versa), o que é correto para que os mecanismos de busca indexem apenas uma grafia do seu domínio.

Criando um redirecionamento manualmente

A seção de Redirecionamentos da área administrativa permite adicionar um manualmente. O que você fornece:

O slug antigo e o slug novo (para onde os links antigos devem cair).
O idioma ao qual se aplica.
O tipo: página ou post.
Notas opcionais, uma flag de ativo e um código de status (301/302/307).

A validação protege você:

Slug antigo, slug novo e idioma são obrigatórios, e um redirecionamento não pode apontar para si mesmo.
Você não pode criar dois redirecionamentos para o mesmo slug antigo no mesmo idioma.
Cadeias são colapsadas: se o destino do seu novo redirecionamento já tem seu próprio redirecionamento, o seu é reescrito para o destino final, para que os leitores não quiquem por vários saltos. Se isso formaria um círculo de volta ao slug antigo, o redirecionamento é recusado como circular.

Antes de salvar, você pode testar um par candidato de slug-antigo/slug-novo: o teste informa o destino final, a cadeia completa de redirecionamentos que ele percorreria, se forma um loop e se a URL antiga tem atualmente conteúdo vivo.

Redirecionamentos com padrão

Para migrar uma seção inteira de uma vez, use um redirecionamento com padrão: um slug antigo terminando em * (como products/*) corresponde a todos os slugs de conteúdo com esse prefixo. Um placeholder $1 no slug novo repassa o restante correspondido; por exemplo, products/* → catalogue/item-$1 mapeia products/red-sweater para catalogue/item-red-sweater. Padrões funcionam na saída estática do site; aparecem apenas ali e no editor de redirecionamentos, não nos arquivos de exportação para hosts (a sintaxe de padrão de cada host difere).

Ações em massa na área administrativa

Na lista de redirecionamentos você pode selecionar várias entradas e excluí-las, ativá-las ou desativá-las em uma única ação; o site é reconstruído depois, para que os redirecionamentos entrem em vigor.

O log de 404 também serve como fonte de redirecionamentos: caminhos que estiveram ausentes do site (conforme o log de 404 agregado) podem ser transformados em redirecionamentos em massa. Preencha o destino de cada linha e envie; duplicatas são sinalizadas instantaneamente enquanto as linhas válidas são criadas (e registradas no log de auditoria). Um rebuild é então acionado.

O gerenciamento de redirecionamentos pode ser restringido pela sua conta: um editor sem "redirects" entre seus tipos de conteúdo permitidos não recebe acesso de gerenciamento a esta seção.

Formatos de exportação

Cada build com uma URL de site definida escreve dois arquivos no topo da saída construída:

_redirects (formato Netlify): uma regra por linha: caminho de origem, URL completa de destino e código de status. Hosts e gateways que entendem o formato Netlify podem servir essas regras diretamente, evitando o quique de meta-refresh.
_redirects.caddy (snippet Caddy): diretivas redir prontas para incluir no bloco de site do seu Caddyfile.

Ambos respeitam as mesmas regras: apenas redirecionamentos ativos são exportados, conteúdo vivo no slug antigo é pulado, e mudanças de prefixo do blog são incluídas com status permanente. A imposição de domínio canônico (enviando o host alternativo www/apex para seu domínio canônico) é anexada ao _redirects como seu próprio bloco rotulado, reescrito de forma limpa a cada build, para que builds repetidos nunca dupliquem regras.

Uma nuance: o código de status que você escolhe aplica-se aos servidores que leem os arquivos de exportação. A página estática de meta-refresh sempre encaminha instantaneamente, pois o host estático não pode definir um código de status personalizado em um arquivo HTML simples. Use um proxy que consuma as exportações quando códigos exatos (como movimentos temporários, 302/307) importam para os mecanismos de busca.