Dominio canónico

Cuando tu site es accesible tanto en www.example.com como en example.com, los motores de búsqueda ven dos copias de cada página. Chinaski lo resuelve haciendo que la configuración de Site URL sea canónica y generando automáticamente una regla de redirección para el otro host en cada build. Esta página explica qué configurar, qué se genera y qué más vive en el archivo de redirecciones que administra el builder.

Elegir el host canónico

Configura Site URL en Settings → General con tu dominio preferido completo, incluyendo el esquema: por ejemplo https://example.com o https://www.example.com. El host de esa configuración es el canónico.

En cada build, el builder escribe un bloque generado en _redirects, al inicio de tu directorio de salida:

• Si el host de tu Site URL empieza con www., el dominio sin prefijo (y todo lo que esté bajo él) se redirige con 301 al host www..
• Si no empieza con www., el host www. se redirige al host sin prefijo.

La redirección es permanente (301) y envía la ruta completa: solo cambia la autoridad. No se toca ningún otro dominio. Si dejas Site URL vacío, no se genera ninguna redirección de dominio canónico.

Dos cosas que debes saber:

• El bloque generado es idempotente: cada build descarta cualquier bloque canónico anterior y lo reescribe desde cero, así que los builds incrementales nunca duplican líneas.
• La regla usa la sintaxis de redirección de la directiva redir de Caddy con el marcador de fuerza externa ! (https://www.example.com/* https://example.com/:splat 301!). Los propios ejemplos de despliegue de Chinaski sirven estáticamente a través de Caddy, que entiende este formato. Si publicas el directorio de salida en algún lugar que espere una sintaxis de redirección diferente, revisa ese archivo antes de apuntar un producto de hosting de terceros hacia él.

Si cambias el Site URL de sin prefijo a www (o al revés), el siguiente rebuild regenera el bloque para que coincida: no hacen falta ediciones manuales.

Otras redirecciones que el builder administra en el mismo archivo

El archivo _redirects se comparte entre la regla de dominio canónico y las redirecciones que defines en el área de administración:

• Redirecciones de slug: cuando el slug de una página o post se retira o se redirige deliberadamente, la URL antigua se mapea a la nueva con el código HTTP que elijas (301, 302 o 307; 301 si no se especifica). Las redirecciones solo se aplican a URLs que ya no resuelven a contenido publicado: si el slug antiguo todavía está adjunto a una página o post publicado, la regla se omite para no secuestrar una URL activa.
• Redirecciones por cambio de prefijo: cambiar el prefijo de URL de los posts redirige automáticamente las rutas antiguas a las nuevas en el siguiente rebuild.
• Las reglas de redirección sin patrón (pares simples slug-antiguo/slug-nuevo) son reescrituras de ruta simples que funcionan en todos los tipos de hosting. Las redirecciones con patrón (las que usan * y placeholders de captura) se omiten deliberadamente cuando el builder genera estos archivos, porque requieren una sintaxis que el formato simple del archivo no expresa: las reglas con patrón deben implementarse directamente en la configuración de tu reverse proxy.
• También se genera un archivo complementario _redirects.caddy en la sintaxis nativa redir de Caddy; su comentario de cabecera te indica incluirlo en el bloque de site de tu Caddyfile si despliegas con Caddy.

Coherencia con las etiquetas canónicas

El mismo Site URL impulsa la URL canónica en cada página (<link rel="canonical"> y og:url), así que el dominio al que tu redirección envía a los visitantes y el nombre canónico que declaran tus páginas siempre coinciden. Si sirves un site multilingüe, las URLs canónicas generadas usan la base configurada de cada idioma.

Si el Site URL se deja en blanco, no se escribe ningún bloque de redirección canónica y las etiquetas canónicas hacen el fallback correspondiente: elige tu dominio antes de salir a producción.