Sitemap de Next.js con error 404: cuatro pruebas en dev y producción

Antes de cambiar la configuración del sitemap de Next.js, identifica qué URL falla. El mapa del sitio, la fuente que lo genera y una ficha de producto incluida en el XML pueden fallar por separado. Una captura de una página 404 no permite localizar el problema.

El 12 de octubre de 2026, Neaptide probó cuatro casos controlados. Una dirección de sitemap incorrecta devolvió 404; una fuente inaccesible provocó un 500 porque nuestro código lanzaba una excepción; un sitemap con un producto retirado devolvió 200, mientras que el producto devolvió 404. Las correcciones funcionaron tanto en next dev como en una compilación local de producción. No observamos diferencias entre ambos modos en estos casos.

Qué probamos antes de escribir esta guía

El entorno utiliza Next.js 15.5.22, React y React DOM 19.2.6, Node v25.2.1 y dos productos ficticios. Fijamos el protocolo, el código, el recopilador y el archivo de bloqueo antes de medir; instalamos las dependencias en un directorio aislado y ejecutamos next dev junto con next build seguido de next start. Una fuente HTTP local sirve los registros. La producción es local: no es una prueba de Vercel.

Cuatro casos generan siete variantes: un control correcto y tres pares antes/después. Dos modos y dos rondas dan 28 respuestas de sitemap, más 36 respuestas de las páginas incluidas y dos comprobaciones de la fuente. Son 66 observaciones HTTP repetidas, no 66 URL únicas. Guardamos cuerpos, cabeceras y hashes. La revisión del XML comprueba su análisis y el espacio de nombres urlset, sin validación XSD completa.

El estado del sitemap no detectó uno de los fallos

Una fuente en 404 causó un 500 en nuestro código

El sitemap dinámico consulta una fuente JSON controlada. Antes de corregirla, /missing-catalog.json devolvía 404. El código siguiente comprueba response.ok y lanza una excepción. Esa excepción produjo un 500 en /dynamic-bad/sitemap.xml. El resultado depende de nuestro tratamiento del error; no significa que Next.js convierta cualquier 404 de una fuente en 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));
}

Cambiar la ruta de la fuente a /catalog.json fue suficiente: /dynamic-ok/sitemap.xml devolvió 200 con dos productos accesibles. Ambas variantes ya usaban force-dynamic y cache: 'no-store'. Activar el renderizado dinámico no fue la corrección probada. En tu aplicación, registra el estado de la fuente y consulta los logs antes de cambiar la caché.

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

Comprueba la ruta que genera la ubicación del archivo

El archivo app/catalog/sitemap.js generó /catalog/sitemap.xml. Solicitar /sitemaps/catalog.xml devolvió 404. Solicitar la ruta real dio 200 sin cambiar el código. El control app/sitemap.js en la raíz también devolvió 200. Estos caminos siguen la convención de archivos documentada por Next.js. No probamos mapas divididos con generateSitemaps.

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

• Next.js · sitemap

Un sitemap con 200 puede contener una página 404

La variante stale-before exportaba todos los registros editoriales, incluido /products/retired. El XML se podía analizar y el sitemap devolvía 200, pero el producto retirado devolvía 404. Filtrar por published antes de generar las URL dejó una entrada, /products/widget-a, que devolvía 200. Eliminamos el registro no publicado; no lo redirigimos ni sustituimos por otro producto.

// 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));}

El campo published no determina por sí solo la indexabilidad. En un catálogo real, comprueba también que sean las páginas canónicas deseadas y que puedan indexarse. Las páginas del entorno de prueba incluyen noindex/nofollow de forma intencionada: este experimento mide disponibilidad de rutas.

Sigue la URL que falla a través del sistema

Empieza con una petición GET a la dirección exacta del sitemap enviado. Guarda el estado y el cuerpo antes de seguir redirecciones. Este recorrido es una guía de diagnóstico; las ramas de XML inválido y fallos exclusivos del alojamiento son recomendaciones, no casos adicionales medidos.

1. El sitemap devuelve 404: compara la dirección solicitada con la ruta real y la ubicación del archivo. En S3, corregir la dirección resolvió el fallo.
2. El sitemap devuelve 5xx: revisa el error del servidor y la respuesta de la fuente. En S2, la fuente inexistente provocaba una excepción; corregir su ruta solucionó el problema.
3. El sitemap devuelve 200: analiza el cuerpo y el espacio de nombres de la raíz. Si recibes HTML o XML mal formado, investiga la ruta que genera la respuesta. No simulamos este caso.
4. El XML se puede analizar: solicita las URL loc y revisa sus estados. En S4, esto detectó el producto retirado que una comprobación del sitemap habría pasado por alto.
5. El fallo aparece solo en el alojamiento: compara el commit, la ruta solicitada, las variables de entorno y el acceso a la fuente con next build y next start. Después revisa el enrutamiento y los logs del despliegue. Nuestro experimento local no aisló ningún defecto de alojamiento.

Google recomienda URL absolutas y las páginas preferidas que quieres mostrar en los resultados. Enviar un sitemap es una indicación, no una garantía de rastreo. Tras el despliegue, consulta los errores de procesamiento en el informe Sitemaps de Search Console; una respuesta local correcta no demuestra el resultado de Google.

• Google · sitemap

Repite las pruebas con el mismo entorno

Descarga el archivo y sigue README.txt. Inicia la fuente local, instala las dependencias fijadas y ejecuta dev y producción en los puertos 8801 y 8802. El recopilador guarda la matriz sin seguir redirecciones ni rastrear sitios externos. Verificamos el archivo frente al código fijado y repetimos su recopilador contra los servidores originales en ejecución: coincidieron las 28 firmas de sitemap. No fue una segunda instalación limpia de los servidores.

Método, datos y ejemplo ejecutable

• Resultados y observaciones · JSON
• Método y limitaciones · TXT
• Entorno, dependencias y recopilador · ZIP
• Respuestas HTTP originales y logs · ZIP

Los fallos se introdujeron de forma intencionada para estudiar el diagnóstico; no muestran su frecuencia en sitios reales. No probamos una CMS real, invalidación de caché, middleware, rewrites, CDN ni Vercel, ni medimos indexación, posiciones o citas de IA. Un informe histórico de Next.js RC/Windows/Prisma ayudó a formular la pregunta; este entorno no reproduce ni resuelve aquel caso.

• Next.js · issue #72808

• Auditoría SEO de Next.js
• Cómo investigar la indexación de Google