Guide robots.txt per piattaforma

Next.js robots.txt: come usiamo App Router e MetadataRoute.Robots

Il nostro flusso per app/robots.txt, app/robots.ts, MetadataRoute.Robots, sitemap, cache, preview e deployment.

Di Robots.txt Tools Editorial TeamUltima verifica 2026-10-012 min di lettura

Metodo editoriale: questa guida documenta il flusso di verifica usato dal Robots.txt Tools Editorial Team. La prima persona descrive il metodo operativo e non rivendica lavori per clienti o casi personali.

Next.js robots.txt: come usiamo App Router e MetadataRoute.Robots

Con App Router, noi scegliamo tra app/robots.txt statico e app/robots.ts o app/robots.js generato.

Preferiamo statico quando basta

Una policy semplice riduce dipendenze runtime e rende il controllo più facile.

Per la generazione usiamo MetadataRoute.Robots

import type { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
  return { rules: { userAgent: '*', allow: '/' }, sitemap: 'https://example.com/sitemap.xml' }
}

Controlliamo cache e comportamento dynamic

Le metadata route generate possono avere cache diversa in base all’implementazione. Confrontiamo sempre source e risposta pubblica.

I preview privati usano access control

Usiamo autenticazione e impediamo che Sitemap: punti a un preview host.

Verifichiamo il deployment

Apriamo /robots.txt, usiamo il validator e testiamo URL con il tester.

Comportamento attuale dell’App Router

Next.js supporta app/robots.txt statico e app/robots.ts / app/robots.js generato con MetadataRoute.Robots. Le route metadata generate possono essere cacheate in base all’implementazione, quindi verifichiamo versione del framework e risposta pubblica invece di assumere un ricalcolo a ogni request.

Per policy stabili preferiamo lo statico. Generiamo solo quando serve davvero, ad esempio per più gruppi crawler o hostname controllato dall’ambiente. Evitiamo dipendenze API esterne nella route robots.

Errori inclusi nello smoke test

Controlliamo sitemap con dominio preview, middleware/proxy che intercetta /robots.txt, conflitto tra file statico e route generata, cache vecchia e branch staging attivo in production. Il test finale verifica status, content-type, body e hostname sitemap sul dominio pubblico.

Rendiamo esplicito l’hostname di produzione

Quando sitemap o canonical dipendono da variabili d’ambiente, usiamo un valore production definito invece di ricostruire il dominio da una request generica. Inseriamo /robots.txt nello smoke test del deploy e controlliamo status, content-type, body e hostname del sitemap. Una configurazione mancante deve fallire presto, non pubblicare silenziosamente un dominio preview.

Guide correlate