Sitemap Next.js in 404: quattro verifiche in dev e produzione

Prima di modificare la configurazione della sitemap Next.js, individua l’URL che restituisce l’errore. La sitemap, la fonte dei suoi dati e una pagina prodotto elencata nell’XML possono fallire indipendentemente. Uno screenshot con un errore 404 non basta a capire dove intervenire.

Il 12 ottobre 2026 Neaptide ha verificato quattro casi controllati. Un indirizzo errato della sitemap ha restituito 404; una fonte non disponibile ha provocato un 500 perché il nostro codice generava esplicitamente un’eccezione; una sitemap con un prodotto ritirato ha restituito 200, mentre il prodotto restituiva 404. Le correzioni hanno funzionato sia con next dev sia con una build di produzione locale. In questi casi non abbiamo osservato differenze tra i due ambienti.

Il test svolto prima della stesura

L’ambiente usa Next.js 15.5.22, React e React DOM 19.2.6, Node v25.2.1 e due prodotti fittizi. Abbiamo fissato protocollo, codice, raccoglitore e lockfile prima delle misure, installato le dipendenze in una directory isolata ed eseguito next dev insieme a next build seguito da next start. Una fonte HTTP locale fornisce i prodotti. La produzione è locale: non è un test di Vercel.

Quattro casi generano sette varianti: un controllo funzionante e tre coppie prima/dopo. Due ambienti e due passaggi producono 28 risposte di sitemap, più 36 risposte delle pagine elencate e due controlli della fonte. Sono 66 osservazioni HTTP ripetute, non 66 URL distinti. Abbiamo salvato corpi, intestazioni e hash. Il controllo XML verifica il parsing e il namespace urlset, senza validazione XSD completa.

Lo stato della sitemap non ha rivelato tutti i guasti

Una fonte in 404 ha prodotto un 500 nel nostro codice

La sitemap dinamica interroga una fonte JSON controllata. Prima della correzione, /missing-catalog.json restituiva 404. Il codice seguente controlla response.ok e genera un’eccezione. Questa ha prodotto un 500 su /dynamic-bad/sitemap.xml. Il risultato dipende dalla nostra gestione dell’errore: Next.js non converte necessariamente ogni 404 della fonte in un 500.

// lib/catalog.js
export async function fromFeed(path) {
  const response=await fetch(`http://127.0.0.1:8800${path}`,{cache:'no-store'});
  if(!response.ok) throw new Error(`Controlled catalog source returned HTTP ${response.status}`);
  const rows=await response.json();return entries(rows.map(row=>row.slug));
}

È bastato sostituire il percorso della fonte con /catalog.json: /dynamic-ok/sitemap.xml ha restituito 200 con due prodotti raggiungibili. Entrambe le varianti usavano già force-dynamic e cache: 'no-store'. L’attivazione del rendering dinamico non era la correzione verificata. Nella tua applicazione, registra lo stato della fonte e consulta i log prima di modificare la cache.

// app/dynamic-ok/sitemap.js
import {fromFeed} from '../../lib/catalog';
export const dynamic='force-dynamic';
export default async function sitemap(){return fromFeed('/catalog.json');}

Verifica il percorso generato dalla posizione del file

Il file app/catalog/sitemap.js ha generato /catalog/sitemap.xml. La richiesta a /sitemaps/catalog.xml ha restituito 404. Richiedere la route effettiva ha dato 200 senza cambiare il codice. Anche il controllo app/sitemap.js nella radice restituiva 200. Questi percorsi seguono la convenzione dei file documentata da Next.js. Le sitemap suddivise con generateSitemaps non sono state testate.

app/sitemap.js          → /sitemap.xml
app/catalog/sitemap.js  → /catalog/sitemap.xml

• Next.js · sitemap

Una sitemap in 200 può contenere una pagina in 404

La variante stale-before esportava tutti i record editoriali, incluso /products/retired. L’XML era analizzabile e la sitemap restituiva 200, ma il prodotto ritirato restituiva 404. Filtrare per published prima di generare gli URL ha lasciato una voce, /products/widget-a, raggiungibile in 200. Abbiamo eliminato il record non pubblicato, senza reindirizzarlo né sostituirlo con un altro prodotto.

// app/stale-after/sitemap.js
import {editorialRecords,entries} from '../../lib/catalog';
export default function sitemap(){return entries(editorialRecords.filter(row=>row.published).map(row=>row.slug));}

Il campo published non basta a stabilire l’indicizzabilità. In un catalogo reale, verifica anche che gli URL scelti siano le pagine canoniche desiderate e possano essere indicizzati. Le pagine del test includono volutamente noindex/nofollow: qui misuriamo la disponibilità delle route.

Segui l’URL che fallisce nel sistema

Parti da una richiesta GET all’indirizzo esatto della sitemap inviata. Salva stato e corpo prima di seguire i reindirizzamenti. Il percorso seguente è una guida pratica; i rami XML non valido e guasto specifico dell’hosting sono raccomandazioni, non ulteriori casi misurati.

1. La sitemap restituisce 404: confronta l’indirizzo richiesto con la route effettiva e la posizione del file. In S3, correggere l’indirizzo ha risolto l’errore.
2. La sitemap restituisce 5xx: esamina l’errore del server e la risposta della fonte. In S2, la fonte assente provocava un’eccezione; correggerne il percorso ha risolto il guasto.
3. La sitemap restituisce 200: analizza il corpo e il namespace della radice. Se ricevi HTML o XML malformato, esamina la route che produce la risposta. Non abbiamo simulato questo caso.
4. L’XML è analizzabile: richiedi gli URL loc e controllane gli stati. In S4, questo ha rivelato il prodotto ritirato che un controllo della sola sitemap avrebbe ignorato.
5. Il guasto compare solo sull’hosting: confronta commit, percorso richiesto, variabili d’ambiente e accesso alla fonte con next build e next start. Poi esamina routing e log del deployment. Il nostro test locale non ha isolato difetti dell’hosting.

Google raccomanda URL assoluti e le pagine preferite che vuoi mostrare nei risultati. L’invio della sitemap è un suggerimento, non una garanzia di scansione. Dopo il deployment, consulta gli errori di elaborazione nel rapporto Sitemap di Search Console; una risposta locale corretta non dimostra l’esito per Google.

• Google · sitemap

Ripeti le verifiche nello stesso ambiente

Scarica l’archivio e segui README.txt. Avvia la fonte locale, installa le dipendenze fissate ed esegui dev e produzione sulle porte 8801 e 8802. Il raccoglitore salva la matrice senza seguire reindirizzamenti né visitare siti esterni. Abbiamo confrontato l’archivio con il codice fissato e rieseguito il suo raccoglitore sui server originali ancora attivi: tutte le 28 firme della sitemap coincidevano. Non era una seconda installazione pulita dei server.

Metodo, dati ed esempio eseguibile

• Risultati e osservazioni · JSON
• Metodo e limiti · TXT
• Ambiente, lockfile e raccoglitore · ZIP
• Risposte HTTP originali e log · ZIP

I difetti sono stati introdotti intenzionalmente per studiare la diagnosi; non indicano quanto siano frequenti sui siti reali. Non abbiamo testato CMS reali, invalidazione della cache, middleware, rewrites, CDN o Vercel, né misurato indicizzazione, posizioni o citazioni nelle IA. Una segnalazione storica su Next.js RC/Windows/Prisma ha contribuito a formulare la domanda; questo ambiente non riproduce né risolve quel caso.

• Next.js · issue #72808

• Audit SEO Next.js
• Come indagare l’indicizzazione su Google