Redirections d'URL

Restructurer un site retire des URL. Sans redirection, la seule réponse possible sur un chemin retiré est un 404, et chaque lien indexé, favori et backlink qui pointe vers lui se casse.

Le tableau redirects déclare ces chemins retirés et l'endroit où chacun vit désormais :

redirects:
  - from: /products/platform
    to: /
  - from: /products/partner
    to: /partner
  - from: /login
    to: /_admin/login
    status: 302

Propriétés d'une règle

Les chaînes de requête ne font pas partie de la clé de correspondance. Une chaîne de requête entrante est préservée et reportée sur la cible ; il est donc inutile d'en encoder une dans from. Si to porte déjà sa propre chaîne de requête, l'entrante y est ajoutée avec &.

Choisir un statut

Gestion des langues

Un from est mis en correspondance de la même façon que les chemins de pages sont écrits. Une règle nue correspond au chemin brut et à chacune de ses variantes préfixées par une langue, et un to de type chemin hérite de la langue de la requête — une seule règle sert donc toutes les locales, et un visiteur français atterrit sur le remplacement français, jamais sur l'anglais :

redirects:
  - from: /pricing
    to: /plans

Cette unique règle répond à /pricing, /en/pricing et /fr/pricing, en envoyant chacun respectivement vers /plans, /en/plans et /fr/plans.

Pour ne cibler qu'une seule locale, écrivez le segment de langue dans from. Une règle dont le chemin commence déjà par un code de langue configuré est mise en correspondance littéralement :

redirects:
  - from: /fr/tarifs
    to: /fr/plans

Un to absolu est utilisé tel quel, sans aucune gestion de langue, puisqu'il quitte entièrement l'application.

N'écrivez pas à la main la règle pour un chemin sans préfixe

Un /docs nu qui répond 404 alors que /en/docs est servi est le seul cas où une règle de redirection paraît évidente et se révèle destructrice. Le moteur s'en charge déjà — voir URL sans segment de langue — et les deux formes écrites à la main sont désormais rejetées au décodage, car from est mis en correspondance indépendamment de la locale et revendique donc aussi les URL localisées bien vivantes :

{ from: '/docs', to: '/en/docs' }
  /docs      → 301 /en/docs        le cas que vous vouliez
  /en/docs   → 301 /en/en/docs     la doc anglaise en ligne, désormais un 404
  /fr/docs   → 301 /fr/en/docs     la doc française en ligne, désormais un 404

Recourir à localizeTarget: false corrige le double préfixe et crée pire encore — la règle renvoie désormais l'URL en ligne vers elle-même :

{ from: '/docs', to: '/en/docs', localizeTarget: false }
  /docs      → 301 /en/docs        le cas que vous vouliez
  /en/docs   → 301 /en/docs        boucle de redirection infinie du navigateur
  /fr/docs   → 301 /en/docs        la doc française, inaccessible

Les deux passaient autrefois sovrium validate et cassaient la zone de documentation à l'exécution. Elles y échouent désormais — voir Validation.

Priorité

Les redirections sont évaluées après les ressources statiques et avant les pages :

1. Un fichier réel du répertoire public — une règle de redirection ne peut jamais détourner une ressource servie.
2. Les règles de redirection.
3. La résolution des pages.
4. Le fourre-tout 404.

Une règle l'emporte donc toujours sur une page. Cela vaut dans les deux sens : un from qui correspond à un chemin que vous servez encore rend cette page inaccessible.

Vos règles sont également évaluées avant la canonicalisation d'URL : from est donc comparé au chemin exactement tel que le navigateur l'a envoyé, barre oblique finale comprise.

Validation

Des règles portant sur la table entière sont appliquées au décodage de la configuration, de sorte qu'une table cassée fait échouer sovrium validate au lieu de partir en production. Toutes existent pour la même raison : le serveur ne résout jamais qu'un seul saut et ne peut donc pas boucler — mais le navigateur, lui, suit chaque nouvelle règle à son tour et ne se stabilise jamais.

Les trois dernières tiennent compte de la locale et de la barre oblique finale, et sont nouvelles. { from: '/x/', to: '/x' } reste valide — elle émet /x, qui ne correspond à rien, et se termine donc. { from: '/en', to: '/en/' } est désormais rejetée : elle ne fait que dupliquer la redirection /en → /en/ du moteur lui-même.

Le contrôle sur l'option de sortie est délibérément étroit. { from: '/login', to: '/_admin/login', localizeTarget: false } est la raison d'être de localizeTarget et reste valide ; { from: '/legacy', to: '/en/docs', localizeTarget: false } est d'un goût douteux mais ne boucle pas, et n'est pas rejetée non plus.

Les cibles relatives au protocole (//example.com) sont également rejetées. Un navigateur les résout comme des URL absolues vers une autre origine, ce qui ferait de la table de redirections une primitive de redirection ouverte ; un passage de main vers une autre origine doit expliciter https:// afin que l'intention soit visible en relecture.

Pages connexes

• Métadonnées de l'application — les autres propriétés racines d'identité.
• Présentation des pages — la résolution de pages devant laquelle s'exécutent les redirections.
• Langues — les codes de langue configurés qui pilotent la correspondance par préfixe.
• SEO et métadonnées — les URL canoniques, avec lesquelles un 301 doit s'accorder.