SEO técnico en Next.js: qué revisar antes de publicar

Next.js facilita muchas partes del SEO técnico.

Tiene una API de metadata, generación de sitemap y robots, Server Components, optimización de imágenes y distintas formas de renderizar una página.

Pero puedes utilizar todo eso y publicar igualmente una web con canonicals contradictorias, idiomas mal conectados, páginas inexistentes que responden con 200 o contenido que Google apenas puede descubrir.

El framework resuelve herramientas.

La implementación sigue siendo tuya.

Esta es la lista que revisaría antes de publicar un proyecto con App Router.

Metadata: cada página tiene que describirse correctamente

Next.js permite definir metadata estática con metadata o generarla a partir de datos con generateMetadata.

Revisaría:

• title propio y descriptivo para las páginas importantes;
• description coherente con el contenido real;
• metadataBase bien configurado si utilizas URLs relativas en metadata;
• canonical correcta;
• Open Graph cuando importa cómo se comparte la página.

No utilizaría generateMetadata simplemente porque existe.

Si la información es estática, metadata es más sencillo.

En páginas dinámicas —un producto, un proyecto o un artículo— generateMetadata permite construir esos datos a partir del contenido.

En versiones actuales de Next.js, determinada metadata dinámica puede enviarse mediante streaming. Next.js documenta que Googlebot interpreta esa metadata después del render y mantiene un tratamiento distinto para bots que necesitan encontrarla directamente en el <head>.

No lo utilizaría como excusa para dejar de comprobar qué termina generando realmente cada URL.

Canonicals: coherencia, no un parche para cualquier URL

Una canonical indica qué URL prefieres dentro de un conjunto de páginas duplicadas o muy similares.

En una web normal comprobaría que:

• las páginas principales tienen una canonical coherente;
• sitemap, enlaces internos y canonical no se contradicen;
• las variantes realmente duplicadas apuntan al destino correcto;
• los enlaces internos utilizan directamente la URL que quieres conservar.

No utilizaría canonicals como sustituto de cualquier problema de indexación.

Un filtro, una combinación de parámetros y una paginación no son automáticamente el mismo caso.

De hecho, Google recomienda no usar la primera página de una secuencia paginada como canonical de las demás, sino dar a cada página su propia URL canónica.

Antes de poner una canonical hacia otra URL, la pregunta es:

¿estas dos páginas representan realmente el mismo contenido o uno muy parecido?

Hreflang: conectar las versiones que realmente existen

En una web multilingüe revisaría:

• que cada idioma declare las demás versiones correspondientes;
• que los enlaces sean recíprocos;
• que cada página también se incluya a sí misma;
• que los códigos de idioma y región sean válidos;
• que las URLs declaradas sean completas, con dominio;
• que ninguna URL declarada termine en 404 o redirect;
• y que un slug traducido apunte a su equivalente real, no simplemente al mismo path con otro prefijo.

Next.js permite hacerlo con alternates.languages.

También puede incluir alternates dentro del sitemap.

No necesitas utilizar todos los métodos disponibles a la vez: para Google son equivalentes.

Lo importante es que la familia de URLs sea correcta y fácil de mantener.

Si utilizas una versión por defecto para idiomas no contemplados, puedes declarar también x-default.

Sitemap, robots e indexabilidad son cosas distintas

Un sitemap debería representar las URLs que realmente quieres presentar a los buscadores.

No metería:

• redirects;
• 404;
• borradores;
• páginas que deliberadamente llevan noindex;
• variantes duplicadas que no quieres conservar.

Next.js permite generar sitemap.ts y robots.ts, pero que esos archivos existan no significa que estén bien configurados.

También conviene separar conceptos.

robots.txt controla principalmente el rastreo.

noindex indica que una página no debe aparecer en resultados.

Y una zona realmente privada necesita autenticación o control de acceso: noindex no convierte una URL pública en privada.

Redirects y errores: que la respuesta HTTP diga la verdad

Cuando cambia una URL, la antigua debería llevar directamente a la nueva.

Sin A → B → C.

Mejor A → C.

Con los redirects permanentes de next.config (permanent: true), Next.js utiliza actualmente un 308. Si en algún caso necesitas otro código, se puede indicar con statusCode.

Si el recurso simplemente no existe y no tiene sustituto, devolver un 404 real es correcto.

En rutas dinámicas, notFound() permite manejar ese caso sin terminar mostrando una página de error con un 200.

También revisaría que ningún enlace interno siga pasando por redirects una vez terminada una migración.

Google puede ejecutar JavaScript. Eso no significa que todo dé igual

Googlebot renderiza JavaScript.

Por eso una web no deja de ser indexable simplemente porque tenga Client Components o contenido generado con JS.

Aun así, Google sigue considerando SSR y prerenderizado buenas opciones porque mejoran la experiencia para usuarios y crawlers y no todos los bots ejecutan JavaScript.

La revisión práctica es más sencilla:

¿el contenido que quieres indexar termina siendo accesible sin depender de una acción humana que el crawler no va a ejecutar?

Un acordeón no es un problema si el contenido forma parte de la página.

En cambio, si la única forma de obtener información importante es pulsar un botón que lanza una petición después, no asumiría que un crawler va a hacer ese recorrido. Google lo dice explícitamente: sus rastreadores no hacen clic en botones ni suelen ejecutar funciones que requieren una acción del usuario.

Lo mismo con los enlaces.

Si una URL importa, debería poder descubrirse mediante un enlace real con href, no únicamente mediante un manejador de clic.

Datos estructurados: solo cuando describen lo que realmente hay

No todas las páginas necesitan schema diferente.

Utilizaría JSON-LD cuando existe un tipo útil para representar el contenido visible:

• Organization o LocalBusiness;
• BlogPosting;
• BreadcrumbList;
• Product;
• u otros tipos que realmente correspondan.

El marcado debe coincidir con lo que ve una persona.

Y que pase el Rich Results Test significa que la implementación es válida para esa comprobación, no que Google vaya a mostrar necesariamente un resultado enriquecido.

Next.js recomienda incluir JSON-LD mediante un <script type="application/ld+json"> normal.

Si el objeto incorpora contenido externo o generado por usuarios, también hay que tratar esos valores de forma segura antes de serializarlos.

Imágenes y rendimiento

next/image resuelve muy bien muchos casos habituales:

• tamaños responsivos;
• lazy loading por defecto;
• reserva de espacio;
• optimización de formatos y dimensiones.

Pero tampoco es una regla de "toda imagen tiene que utilizar next/image".

Para las imágenes que forman parte del contenido sí suele tener mucho sentido.

En las imágenes principales revisaría especialmente que no estés retrasando el elemento que termina siendo LCP.

En Next.js 16, priority quedó obsoleto. Existen preload, loading="eager" y fetchPriority, y la elección depende del caso; la propia documentación recomienda normalmente eager o fetchPriority="high" antes que precargar sin necesidad.

También revisaría:

• alt útil en imágenes con contenido;
• alt="" en las puramente decorativas;
• dimensiones/proporción correctas;
• sizes cuando una imagen responsive lo necesita;
• scripts de terceros;
• fuentes;
• y Core Web Vitals reales.

No por conseguir un 100.

Para evitar que una decisión técnica convierta una página sencilla en algo innecesariamente pesado.

Si quieres entrar en las métricas, lo explicamos aparte en Core Web Vitals.

Después de publicar

Antes de dar una web por terminada comprobaría:

1. Search Console configurado.
2. Sitemap accesible y enviado.
3. Las páginas importantes son rastreables e indexables.
4. Canonical y hreflang salen como esperábamos.
5. Redirects y 404 responden con el estado correcto.
6. No quedan enlaces internos rotos o pasando innecesariamente por redirects.
7. Los datos estructurados importantes validan.
8. La web funciona igual de bien en móvil y escritorio.

Después empieza la parte que una checklist no puede resolver: si hemos construido las páginas que realmente necesitábamos.

Puedes tener una implementación técnica impecable y una arquitectura que no responde a ninguna búsqueda útil.

Por eso el SEO técnico es una base, no la estrategia completa.

Si necesitas trabajar ambas partes desde el principio, es lo que planteamos en Web + SEO.