Avec App Router, nous choisissons entre app/robots.txt statique et app/robots.ts ou app/robots.js généré.
Nous privilégions le statique si possible
Une politique simple limite les dépendances runtime.
Pour la génération, nous utilisons MetadataRoute.Robots
import type { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
return { rules: { userAgent: '*', allow: '/' }, sitemap: 'https://example.com/sitemap.xml' }
}
Nous contrôlons cache et dynamic
Le comportement de cache dépend de l’implémentation de la route générée. Nous comparons toujours le code au fichier publié.
Les previews privés demandent un vrai contrôle d’accès
Nous utilisons authentification et évitons un Sitemap: pointant vers un host de preview.
Nous vérifions le déploiement
Nous ouvrons /robots.txt, utilisons le validator et testons des URL dans le tester.
Comportement actuel de l’App Router
Next.js accepte app/robots.txt statique et app/robots.ts / app/robots.js généré avec MetadataRoute.Robots. Les routes metadata générées peuvent être mises en cache selon leur implémentation. Nous vérifions donc version du framework et réponse publique au lieu de supposer un recalcul à chaque requête.
Nous privilégions le statique pour une politique stable. La génération n’est utile que lorsqu’elle apporte une vraie valeur, par exemple plusieurs groupes de crawlers ou un hostname contrôlé par environnement. Nous évitons les API externes dans cette route.
Les erreurs que nous testons au release
Sitemap pointant vers une preview, middleware/proxy interceptant /robots.txt, conflit entre fichier statique et route générée, cache ancien et branche staging active en production. Le smoke test vérifie statut, content-type, body et hostname du sitemap sur le domaine public.
Nous rendons le hostname de production explicite
Lorsque sitemap ou canonical dépendent d’une variable d’environnement, nous préférons une valeur de production explicite à un host reconstruit depuis une requête quelconque. /robots.txt fait partie de nos smoke tests : statut, content-type, corps et hostname sont vérifiés après chaque déploiement. Une configuration manquante doit échouer tôt plutôt que publier silencieusement une URL de preview.
