SEO técnico en aplicaciones Next.js: errores frecuentes y checklist

Next.js facilita mucho el SEO técnico, pero no lo garantiza. Una aplicación puede verse perfecta en el navegador y, aun así, entregar a los buscadores páginas vacías, títulos duplicados o URLs que compiten entre sí. Esta es una lista de puntos para revisar antes de dar por listo para indexarse un sitio construido con Next.js.

El contenido tiene que existir en el HTML

El error más caro es depender de JavaScript del lado del cliente para mostrar el texto principal. Google puede renderizar JavaScript, pero lo hace en una fase posterior al rastreo y no todos los buscadores ni herramientas de vista previa lo hacen. Si el título, la descripción de un producto o el cuerpo de un artículo solo aparecen después de una petición en el navegador, estás apostando a que alguien ejecute ese código.

Con el App Router, la regla es sencilla: el contenido indexable se renderiza en componentes de servidor y, siempre que se pueda, se prerenderiza en build. Los componentes cliente quedan para la interacción: filtros, buscadores, menús. Una prueba rápida es desactivar JavaScript en el navegador o revisar el código fuente de la respuesta con curl: lo que no está ahí, no lo des por indexado.

Un caso típico son los catálogos con filtros. Si el listado completo se dibuja solo en el cliente, el HTML inicial no contiene ningún enlace a las fichas. Es mejor que el servidor entregue el listado completo y que el cliente añada el filtrado encima.

Metadata única por ruta

Cada URL indexable necesita un title y una description propios. En Next.js se definen con el objeto metadata en páginas estáticas y con generateMetadata en rutas dinámicas, a partir de los mismos datos que alimentan la página.

Errores frecuentes:

• Definir la metadata solo en el layout raíz, de modo que todas las páginas heredan el mismo título.
• Títulos genéricos como «Proyecto» o «Blog» sin el nombre del contenido.
• Descripciones que no describen la página, sino la marca.
• Olvidar Open Graph y Twitter Cards: no afectan al ranking, pero sí a cómo se comparte el enlace.

Una plantilla de título en el layout (template: "%s — Marca") evita repetir el sufijo y mantiene la consistencia.

Canonicals absolutos y una sola versión de cada URL

Una misma página puede ser accesible desde varias URLs: con y sin www, con barra final o sin ella, con parámetros de seguimiento o de filtros. Si no indicas cuál es la versión preferida, el buscador elegirá por ti.

Conviene:

1. Elegir un dominio canónico y redirigir el alternativo con un 301.
2. Declarar en cada página un canonical absoluto (con protocolo y dominio). En Next.js, metadataBase en el layout raíz y alternates.canonical en cada ruta.
3. Hacer que las páginas filtradas por parámetros (?categoria=…) apunten a la URL base, salvo que quieras posicionarlas como páginas propias con contenido diferenciado.

El canonical es una señal, no una orden: Google lo combina con otras, como las redirecciones y los enlaces internos. Por eso es importante que todo apunte en la misma dirección.

Sitemap, robots.txt y noindex no son lo mismo

Son tres herramientas distintas que a menudo se confunden:

Herramienta	Para qué sirve	Para qué no sirve
sitemap.xml	Listar las URLs que quieres que se descubran e indexen	Forzar la indexación
robots.txt	Controlar qué se rastrea	Impedir la indexación o proteger contenido
noindex	Pedir que una página no aparezca en los resultados	Ocultar información privada

Un detalle que suele pasarse por alto: si una página tiene noindex pero está bloqueada en robots.txt, el rastreador nunca llega a leer la etiqueta y la URL podría seguir apareciendo en los resultados si hay enlaces hacia ella. Para que noindex funcione, la página tiene que poder rastrearse.

Y lo más importante: robots.txt no es un control de acceso. Un panel administrativo o un borrador se protegen con autenticación en el servidor, no con una línea en un archivo público que, además, indica dónde está lo que quieres esconder.

En Next.js, app/sitemap.ts y app/robots.ts generan ambos archivos desde código, así que pueden leer el mismo catálogo que las páginas. Así evitas listar en el sitemap URLs que ya no existen o páginas que marcaste como noindex.

Datos estructurados que digan la verdad

JSON-LD ayuda a los buscadores a entender qué hay en la página: una persona, un artículo, una ruta de navegación. Los tipos más útiles en un sitio personal o de producto suelen ser Person, WebSite, BreadcrumbList y BlogPosting.

Dos reglas prácticas:

• Marca solo lo que el usuario puede ver en la página. Declarar valoraciones, precios o reseñas que no existen incumple las directrices y puede acabar en una acción manual.
• Escapa el contenido al insertarlo en un <script type="application/ld+json"> para evitar inyecciones de HTML.

Rendimiento: medir con datos reales

Las Core Web Vitals son las métricas de experiencia que Google usa como señal: LCP (carga del contenido principal), INP (respuesta a la interacción) y CLS (estabilidad visual). Los umbrales de una experiencia «buena» se miden en el percentil 75 de las visitas reales: LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos.

En Next.js, las mejoras con más impacto suelen ser:

• next/font para cargar tipografías sin bloquear el renderizado ni provocar saltos.
• next/image con dimensiones fijas y sizes correctos, y priority solo en la imagen principal.
• Mover a componentes de servidor todo lo que no necesita interacción, para reducir el JavaScript que se envía.
• Evitar librerías pesadas para efectos que se resuelven con CSS.

Lighthouse sirve para detectar problemas en el laboratorio, pero la referencia final son los datos de campo, como los del informe de Core Web Vitals en Search Console.

Previews y entornos de prueba

Los despliegues de vista previa son una fuente frecuente de contenido duplicado. Si una URL de preview se filtra y se indexa, compite con la de producción. La solución es que solo el entorno de producción permita la indexación: el resto debe responder con noindex, idealmente decidido por una variable de entorno y no por un cambio manual antes de cada lanzamiento.

Checklist

• El contenido principal aparece en el HTML de la respuesta, sin depender de JavaScript del cliente.
• Cada página indexable tiene título y descripción únicos.
• metadataBase está configurado y cada ruta declara un canonical absoluto.
• El dominio alternativo redirige al canónico con un 301.
• El sitemap se genera desde los mismos datos que las páginas y excluye las URLs con noindex.
• robots.txt no bloquea páginas que llevan noindex, y nada privado depende de él.
• El JSON-LD describe solo información visible y verdadera.
• Las imágenes tienen dimensiones fijas y las fuentes se cargan con next/font.
• Los entornos de preview no son indexables.
• Las Core Web Vitals se revisan con datos de campo después del lanzamiento.