Redirections

Quand vous renommez une page ou un post, vous ne voulez pas que les anciens liens cassent. Chinaski garde les anciennes URL fonctionnelles avec des redirections, et cette page explique comment elles sont créées, comment elles se comportent, et les formats d'export pour votre hébergeur.

Comment fonctionnent les redirections

Votre site publié est du HTML statique, donc Chinaski implémente les redirections de deux manières :

1. À l'ancienne URL, le site fourni une minuscule page qui dit au navigateur « ce contenu a déménagé » et envoie le lecteur directement vers le nouvel emplacement, avec un vrai lien quand JavaScript est désactivé. Les moteurs de recherche voient un lien canonique pointant vers la nouvelle URL, pour que les anciennes pages ne concurrencent pas les nouvelles dans les résultats.
2. Un fichier de règles de redirection: généré à chaque build, que votre proxy d'hébergement peut lire (voir les formats d'export ci-dessous), pour que les serveurs modernes puissent répondre avec une vraie redirection au lieu de la page de repli.

Les redirections sont par langue : chaque ancien slug appartient à une langue spécifique, et pointe vers la destination dans cette même langue.

Le contenu en ligne gagne toujours : si une page ou un post publié existe déjà à l'ancien slug, aucune redirection n'est générée pour lui : le contenu lui-même est servi.

Ce qui se passe automatiquement

Vous ne gérez habituellement pas les redirections à la main :

• Renommer le slug d'une page ou d'un post publié crée une redirection pour l'ancienne URL automatiquement.
• Changer le préfixe d'URL des posts de blog (par exemple déplacer /journal/ vers /blog/) redirige automatiquement chaque post publié depuis son ancien chemin de préfixe.
• La racine du site redirige vers votre index de blog ou votre page d'accueil choisie si aucune page racine n'existe.
• La canonisation de domaine : si votre URL de site est example.com, une règle est générée qui envoie le trafic www.example.com (ou inversement), correct pour que les moteurs de recherche n'indexent qu'une seule orthographe de votre domaine.

Créer une redirection manuellement

La section Redirects de la zone admin permet d'en ajouter une manuellement. Ce que vous fournissez :

• L'ancien slug et le nouveau slug (où les anciens liens devraient atterrir).
• La langue à laquelle elle s'applique.
• Le type : page ou post.
• Des notes optionnelles, un drapeau actif, et un code de statut (301/302/307).

La validation veille sur vous :

• Ancien slug, nouveau slug, et langue sont requis, et une redirection ne peut pas pointer vers elle-même.
• Vous ne pouvez pas créer deux redirections pour le même ancien slug dans la même langue.
• Les chaînes sont réduites : si la destination de votre nouvelle redirection a déjà sa propre redirection, votre redirection est réécrite vers la destination finale, pour que les lecteurs ne rebondissent pas à travers plusieurs sauts. Si cela reviendrait à l'ancien slug, la redirection est refusée comme circulaire.

Avant de sauvegarder, vous pouvez tester une paire candidate ancien-slug/nouveau-slug : le test rapporte la destination finale, la chaîne complète de redirection qu'elle traverserait, si elle forme une boucle, et si l'ancienne URL a actuellement du contenu en ligne.

Redirections de motif

Pour migrer une section entière d'un coup, utilisez une redirection de *motif* : un ancien slug se terminant par * (comme products/*) correspond à chaque slug de contenu avec ce préfixe. Un placeholder $1 dans le nouveau slug transmet le reste correspondant : par exemple, products/* → catalogue/item-$1 mappe products/red-sweater vers catalogue/item-red-sweater. Les motifs fonctionnent dans la sortie du site statique ; ils n'apparaissent que là et dans l'éditeur de redirections, pas dans les fichiers d'export d'hôte (la syntaxe de motif de chaque hôte diffère).

Actions en masse dans la zone admin

Depuis la liste des redirections vous pouvez sélectionner plusieurs entrées et les supprimer, activer, ou désactiver en une action ; le site se reconstruit ensuite pour que les redirections prennent effet.

Le log 404 sert aussi de source de redirections : les chemins qui ont manqué au site (selon le log 404 agrégé) peuvent être transformés en redirections en masse : remplissez la destination de chaque ligne, soumettez, et les doublons sont immédiatement signalés pendant que les lignes valides sont créées (et enregistrées dans le journal d'audit). Un rebuild est alors déclenché.

La gestion des redirections peut être restreinte par votre compte : un éditeur sans « redirects » parmi ses types de contenu autorisés n'a pas d'accès de gestion à cette section.

Formats d'export

Chaque build avec une URL de site définie écrit deux fichiers au sommet de la sortie construite :

• _redirects (format Netlify) : une règle par ligne : chemin source, URL de destination complète, et code de statut. Les hébergeurs et passerelles qui comprennent le format Netlify peuvent servir ces règles directement, évitant le rebond meta-refresh.
• _redirects.caddy (snippet Caddy) : directives redir prêtes à inclure dans le bloc de site de votre Caddyfile.

Les deux respectent les mêmes règles : seules les redirections actives sont exportées, le contenu en ligne à l'ancien slug est sauté, et les changements de préfixe de blog sont inclus avec un statut permanent. L'imposition du domaine canonique (envoyer l'hôte alternatif www/apex vers votre domaine canonique) est ajoutée à _redirects comme son propre bloc étiqueté, réécrit proprement à chaque build pour que des builds répétés ne dupliquent jamais les règles.

Une nuance : le code de statut que vous choisissez s'applique aux serveurs lisant les fichiers d'export. La page statique meta-refresh redirige toujours instantanément ; l'hébergeur statique ne peut pas définir un code de statut personnalisé sur un simple fichier HTML. Utilisez un proxy qui consomme les exports quand les codes exacts (comme des déplacements temporaires, 302/307) comptent pour les moteurs de recherche.