Domínio canônico

Quando seu site é acessível tanto em www.example.com quanto em example.com, os mecanismos de busca veem duas cópias de cada página. O Chinaski resolve isso tornando a configuração da URL do Site canônica e gerando automaticamente uma regra de redirecionamento para o outro host a cada build. Esta página explica o que configurar, o que é gerado e o que mais vive no arquivo de redirecionamentos que o builder gerencia.

Escolhendo o host canônico

Defina a URL do Site em Configurações → Geral com seu domínio preferido por completo, incluindo o esquema, por exemplo https://example.com ou https://www.example.com. O host dessa configuração é o canônico.

A cada build, o builder escreve um bloco gerado no _redirects no topo do seu diretório de saída:

• Se o host da sua URL de Site começa com www., o domínio nu (e tudo abaixo dele) recebe redirecionamento 301 para o host www..
• Se não começa com www., o host www. recebe redirecionamento para o host nu.

O redirecionamento é permanente (301) e envia o caminho completo; apenas a autoridade muda. Nenhum outro domínio é afetado. Se você deixar a URL do Site vazia, nenhum redirecionamento de domínio canônico é gerado.

Duas coisas para saber:

• O bloco gerado é idempotente: cada build descarta qualquer bloco canônico anterior e o reescreve do zero, então builds incrementais nunca duplicam linhas.
• A regra usa a sintaxe de redirecionamento da diretiva redir do Caddy com o marcador de força-externa ! (https://www.example.com/* https://example.com/:splat 301!). Os próprios exemplos de deploy do Chinaski servem estaticamente via Caddy, que entende esse formato. Se você publicar o diretório de saída em algum lugar que espera uma sintaxe de redirecionamento diferente, revise esse arquivo antes de apontar um produto de hospedagem de terceiros para ele.

Se você mudar a URL do Site de nu para www (ou o inverso), o próximo rebuild regenera o bloco para corresponder, sem edições manuais necessárias.

Outros redirecionamentos que o builder gerencia no mesmo arquivo

O arquivo _redirects é compartilhado entre a regra de domínio canônico e os redirecionamentos que você define na área administrativa:

• Redirecionamentos de slug: quando o slug de uma página ou post é aposentado ou deliberadamente redirecionado, a URL antiga mapeia para a nova com o código HTTP que você escolher (301, 302 ou 307; 301 se não especificado). Os redirecionamentos só disparam para URLs que não resolvem mais para conteúdo vivo: se o slug antigo ainda está anexado a uma página ou post publicado, a regra é pulada para que uma URL viva não seja sequestrada.
• Redirecionamentos de mudança de prefixo: mudar o prefixo de URL dos posts redireciona automaticamente os caminhos antigos para os novos no próximo rebuild.
• Regras de redirecionamento sem padrão (pares simples slug-antigo/slug-novo) são reescritas simples de caminho que funcionam entre tipos de hospedagem. Redirecionamentos com padrão (os que usam * e placeholders de captura) são deliberadamente pulados quando o builder gera esses arquivos, porque exigem uma sintaxe que o formato simples de arquivo não expressa; regras com padrão precisam ser implementadas diretamente na configuração do seu reverse proxy.
• Um arquivo complementar _redirects.caddy também é gerado na sintaxe nativa redir do Caddy; o comentário do cabeçalho dele orienta a incluí-lo no bloco de site do seu Caddyfile se você fizer deploy com Caddy.

Consistência com as tags canônicas

A mesma URL de Site alimenta a URL canônica em cada página (<link rel="canonical"> e og:url), então o domínio para o qual seu redirecionamento envia os visitantes e o nome canônico que suas páginas declaram sempre concordam. Se você serve um site multilíngue, as URLs canônicas geradas usam a base configurada de cada idioma.

Se a URL do Site for deixada em branco, nenhum bloco de redirecionamento canônico é escrito e as tags canônicas fazem o fallback correspondente; escolha seu domínio antes de entrar no ar.