Resumen rápido: Los frameworks de JavaScript rompen el SEO por defecto. El renderizado del lado del cliente significa que los motores de busqueda ven una página vacia, y los rastreadores de IA ni siquiera ejecutan JavaScript. Next.js (con Server Components y la Metadata API) es la mejor opcion para SEO ahora mismo. Nuxt le sigue de cerca para equipos que trabajan con Vue. Las SPAs de React puro nunca deberian usarse para páginas que quieras indexar. Esta guia tiene el código exacto, los errores exactos y las soluciones exactas. Sin rodeos.
La regla: Si una URL necesita posicionar en buscadores o ser citada por IA, debe entregar HTML completo en la respuesta inicial. Eso es todo. "Pero Google puede renderizar JavaScript" — si, eventualmente, de forma poco fiable, despues de una cola que puede durar dias, en una infraestructura que Google opera a un coste enorme específicamente porque demasiados desarrolladores envian cascarones HTML vacios y esperan que el motor de busqueda haga el trabajo de renderizado por ellos. Y los rastreadores de IA ni lo van a intentar.
ISR es... en realidad, dejame retroceder un momento. Solia pensar que ISR era un claro ganador frente a SSR en la mayoria de casos. Despues de ver como los bugs de revalidacion causaron que contenido obsoleto persistiera durante semanas en varios sitios de clientes, ya no estoy tan seguro. En un e-commerce de un cliente, las páginas con ISR estuvieron mostrando precios desactualizados durante 6 horas porque la revalidacion fallo silenciosamente — sin errores en los logs, sin alertas, simplemente precios incorrectos mostrados a clientes y rastreadores por igual. ISR es excelente cuando funciona. Cuando no funciona, depurar problemas de cache obsoleta es genuinamente doloroso. SSR es más predecible, aunque sea más lento.
Next.js tiene la sección más larga porque se la merece. Es el framework de React más popular, y desde que el App Router se convirtio en el predeterminado en Next.js 13+, se ha convertido en el mejor framework de JavaScript para SEO. No por poco — significativamente mejor que las alternativas.
Si estas construyendo un proyecto nuevo en 2026 y el SEO importa, usa Next.js con el App Router. Esa es la recomendación. El resto de esta sección explica por que.
Next.js tiene dos sistemas de enrutamiento. El App Router (introducido en Next.js 13, estable en 14+) y el legacy Pages Router. Ambos pueden producir buenos resultados de SEO, pero el App Router es mejor en casi todos los aspectos que importan para los motores de busqueda:
'use client'. Menos JavaScript enviado significa páginas más rapidas y HTML completo para los rastreadores.El Pages Router sigue funcionando bien. Si tienes un codebase grande sobre el, no entres en panico y migres de golpe.
Pero para proyectos nuevos? App Router, sin duda.
Antes del App Router, hacer SEO en Next.js significaba instalar next-seo y cablear manualmente las meta tags. La Metadata API — que sinceramente creo que es una de las mejores cosas del App Router, a pesar de mis quejas sobre el dolor de la migración — resuelve esto de forma limpia como una funcionalidad nativa del framework.
Metadatos estaticos para una página:
// app/about/page.tsx
import { Metadata } from 'next'
export const metadata: Metadata = {
title: 'About Us | Your Company',
description: 'We build tools that make SEO automatic.',
openGraph: {
title: 'About Us',
description: 'We build tools that make SEO automatic.',
type: 'website',
},
alternates: {
canonical: 'https://example.com/about',
},
robots: {
index: true,
follow: true,
},
}Metadatos dinamicos para páginas con parametros (posts de blog, productos, etc.):
// app/blog/[slug]/page.tsx
import { Metadata } from 'next'
type Props = { params: { slug: string } }
export async function generateMetadata({ params }: Props): Promise<Metadata> {
const post = await getPost(params.slug)
return {
title: `${post.title} | Your Blog`,
description: post.excerpt,
openGraph: {
title: post.title,
description: post.excerpt,
type: 'article',
publishedTime: post.publishedAt,
authors: [post.author.name],
images: [{ url: post.ogImage, width: 1200, height: 630 }],
},
alternates: {
canonical: `https://example.com/blog/${params.slug}`,
},
}
}
export default async function BlogPost({ params }: Props) {
const post = await getPost(params.slug)
return (
<article>
<h1>{post.title}</h1>
<p>{post.content}</p>
</article>
)
}Esto es un Server Component. Sin directiva 'use client'. Se ejecuta completamente en el servidor. El HTML que llega a Googlebot incluye el contenido completo del artículo y todas las meta tags. Cero renderizado de JavaScript necesario.
Un error que veo constantemente: los desarrolladores ponen su obtencion de datos en un componente con 'use client', lo que significa que el contenido se carga via JavaScript despues de que el HTML inicial se haya enviado. Googlebot recibe una página vacia. En serio. Mueve la obtencion de datos a Server Components o generateMetadata. Y si no estas seguro de si un componente es de servidor o de cliente, busca la directiva 'use client' al inicio del archivo — si esta ahi, nada en ese arbol de componentes estara en la respuesta HTML inicial.
El App Router de Next.js tiene soporte nativo para sitemaps. Crea app/sitemap.ts y se genera automáticamente en /sitemap.xml:
// app/sitemap.ts
import { MetadataRoute } from 'next'
export default async function sitemap(): MetadataRoute.Sitemap {
const posts = await getAllPosts()
const products = await getAllProducts()
const postEntries = posts.map((post) => ({
url: `https://example.com/blog/${post.slug}`,
lastModified: new Date(post.updatedAt),
changeFrequency: 'weekly' as const,
priority: 0.7,
}))
const productEntries = products.map((product) => ({
url: `https://example.com/products/${product.slug}`,
lastModified: new Date(product.updatedAt),
changeFrequency: 'daily' as const,
priority: 0.8,
}))
return [
{
url: 'https://example.com',
lastModified: new Date(),
changeFrequency: 'daily',
priority: 1,
},
...postEntries,
...productEntries,
]
}Para sitios con más de 50.000 URLs, usa generateSitemaps() para crear multiples archivos de sitemap. El limite de Google es de 50.000 URLs por archivo de sitemap.
Mismo patron. Crea app/robots.ts:
// app/robots.ts
import { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
return {
rules: [
{
userAgent: '*',
allow: '/',
disallow: ['/api/', '/dashboard/', '/admin/'],
},
],
sitemap: 'https://example.com/sitemap.xml',
}
}Next.js puede generar imagenes Open Graph al vuelo usando next/og (construido sobre la libreria Satori de Vercel). Esto es útil — en lugar de crear manualmente imagenes OG para cada post del blog, defines una plantilla y se renderiza en el momento de la peticion:
// app/blog/[slug]/opengraph-image.tsx
import { ImageResponse } from 'next/og'
export const size = { width: 1200, height: 630 }
export const contentType = 'image/png'
export default async function Image({
params,
}: {
params: { slug: string }
}) {
const post = await getPost(params.slug)
return new ImageResponse(
(
<div style={{
display: 'flex',
flexDirection: 'column',
justifyContent: 'center',
padding: '60px',
background: 'white',
width: '100%',
height: '100%',
}}>
<h1 style={{ fontSize: 48, fontWeight: 700 }}>
{post.title}
</h1>
<p style={{ fontSize: 24, color: '#666' }}>
{post.excerpt}
</p>
</div>
),
{ ...size }
)
}Next.js establece automáticamente la meta tag og:image apuntando a esta imagen generada. No necesitas configuración manual.
El componente next/image gestiona la carga diferida, la conversion automática a WebP/AVIF, el dimensionado responsivo y previene el desplazamiento del diseno (CLS). Todo esto afecta directamente a los Core Web Vitals, que Google usa como senal de posicionamiento.
import Image from 'next/image'
// This automatically:
// - Generates WebP/AVIF variants
// - Lazy loads below-the-fold images
// - Sets width/height to prevent CLS
// - Serves responsive sizes
<Image
src="/hero.jpg"
alt="Product screenshot showing the dashboard"
width={1200}
height={630}
priority // Above-the-fold: disable lazy loading
/>Dos cosas que los desarrolladores siempre se equivocan: olvidan priority en la imagen LCP (la imagen más grande que se ve sin hacer scroll), y usan etiquetas <img> directamente en lugar de next/image. Ambas cosas perjudican los Core Web Vitals.
Anade datos estructurados JSON-LD directamente en tus Server Components. No necesitas ningun paquete de terceros:
// app/blog/[slug]/page.tsx
export default async function BlogPost({ params }) {
const post = await getPost(params.slug)
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'Article',
headline: post.title,
description: post.excerpt,
datePublished: post.publishedAt,
dateModified: post.updatedAt,
author: {
'@type': 'Person',
name: post.author.name,
},
image: post.ogImage,
}
return (
<>
<script
type="application/ld+json"
// In Next.js Server Components, this is safe —
// the JSON is generated server-side from your own database
{...{ children: JSON.stringify(jsonLd) }}
/>
<article>
<h1>{post.title}</h1>
<p>{post.content}</p>
</article>
</>
)
}Veo estos errores en casi todos los sitios de Next.js que audito. Cada uno de ellos cuesta posiciones.
'use client' — Tu contenido se carga despues de que se ejecute el JavaScript. Googlebot ve un spinner de carga vacio. Mueve la obtencion de datos a Server Components./blog/my-post y /blog/my-post?ref=twitter ambos indexados, estas dividiendo la autoridad. Establece alternates.canonical en tus metadatos.metadata. Las páginas dinamicas necesitan generateMetadata. He visto sitios con metadatos perfectos en la página de inicio y <title>undefined</title> en cada página de producto.loading.tsx para contenido critico — El archivo loading muestra un esqueleto mientras el contenido se carga por streaming. Googlebot puede indexar el esqueleto en lugar del contenido real. Usa loading.tsx para UI no critica, no para el contenido principal de la página.router.push() para redirecciones. Los motores de busqueda no ejecutan redirecciones JavaScript de forma fiable. Usa las redirecciones de next.config.js o middleware para 301/302 del lado del servidor.Me molesta tener que escribir esta sección. Estamos en 2026. (Si todavia estas usando Create React App para un sitio publico en 2026, tenemos que hablar.) Pero los correos siguen llegando, asi que aqui estamos.
No uses una SPA de React puro para páginas que quieras indexar. Ese es todo el punto. Una SPA de React puro — Create React App, Vite con React, lo que sea — envia un cascaronHTML vacio a cada rastreador que la visita. Google podria renderizarla eventualmente. Los rastreadores de IA nunca lo haran. Usala para dashboards, paneles de administracion, cualquier cosa detrás de un login. No la uses para nada que quieras que aparezca en resultados de busqueda.
Si estas atrapado con una SPA de React y no puedes migrar a Next.js (lo entiendo — pasa), aqui tienes el enfoque con cinta adhesiva:
// Using react-helmet-async for meta tags
import { Helmet } from 'react-helmet-async'
function ProductPage({ product }) {
return (
<>
<Helmet>
<title>{product.name} | Your Store</title>
<meta name="description" content={product.description} />
<link rel="canonical"
href={`https://example.com/products/${product.slug}`} />
</Helmet>
<h1>{product.name}</h1>
</>
)
}React Helmet gestiona tus etiquetas <head>. Pero — y esto es critico — sigue ejecutandose del lado del cliente. Googlebot todavia necesita renderizar JavaScript para ver estas etiquetas. Necesitas un servicio de prerendering (Prerender.io, Rendertron, o tu propia configuración con Puppeteer) para servir HTML pre-renderizado a los rastreadores.
Esto funciona. He visto que funciona. Pero es fragil, anade latencia a las peticiones de los rastreadores, cuesta dinero, y estas luchando contra el framework en lugar de trabajar con el.
Si tu SPA tiene más de 50 páginas que necesitan indexarse — y esas páginas tienen contenido dinámico que cambia semanalmente, lo que significa que la cache del prerendering necesita invalidacion constante, lo que significa que alguien de tu equipo esta ahora manteniendo infraestructura para rastreadores en lugar de construir funcionalidades del producto — el coste de mantener una configuración de prerendering supera el coste de migrar a Next.js. He calculado esos números para clientes.
Como documentaron Addy Osmani y Jason Miller en web.dev, el prerendering tipicamente anade una latencia notable del lado del servidor por página para las peticiones de los rastreadores, y los casos limite con contenido dinámico o estados autenticados producen frecuentemente snapshots obsoletos o incorrectos. Es una estrategia puente valida, no una solucion permanente (web.dev: Rendering on the Web).
Si tu equipo trabaja en el ecosistema Vue, Nuxt es a Vue lo que Next.js es a React. La misma idea: tomar un framework del lado del cliente, anadir renderizado del servidor, gestion de metadatos y enrutamiento basado en archivos. (Debo admitir: he pasado mucho menos tiempo con Nuxt que con Next.js, asi que toma mis opiniones aqui con reservas adicionales.) La historia de SEO es solida — no tan pulida como la de Next.js en algunas areas, pero lo suficientemente cercana como para que no sea el factor decisivo entre los dos ecosistemas.
Nuxt usa renderizado universal de serie. Cada página se renderiza en el servidor en la primera carga, y luego se hidrata para la navegación del lado del cliente. No tienes que optar por activarlo. Tienes que optar por desactivarlo. Ese es el valor por defecto correcto para SEO.
El sistema de composables de Nuxt para metadatos es limpio. Dos opciones dependiendo de cuanto control necesites:
<!-- pages/blog/[slug].vue -->
<script setup>
const route = useRoute()
const { data: post } = await useFetch(`/api/posts/${route.params.slug}`)
// Option 1: useSeoMeta — type-safe, covers the common cases
useSeoMeta({
title: () => post.value?.title,
description: () => post.value?.excerpt,
ogTitle: () => post.value?.title,
ogDescription: () => post.value?.excerpt,
ogType: 'article',
ogImage: () => post.value?.ogImage,
twitterCard: 'summary_large_image',
})
// Option 2: useHead — full control over <head> tags
useHead({
link: [
{
rel: 'canonical',
href: `https://example.com/blog/${route.params.slug}`,
}
],
script: [
{
type: 'application/ld+json',
innerHTML: JSON.stringify({
'@context': 'https://schema.org',
'@type': 'Article',
headline: post.value?.title,
datePublished: post.value?.publishedAt,
}),
},
],
})
</script>
<template>
<article>
<h1>{{ post?.title }}</h1>
<p>{{ post?.content }}</p>
</article>
</template>Me gusta mucho useSeoMeta(). Es más dogmatico que la Metadata API de Next.js pero cubre el 90% de lo que necesitas con menos código repetitivo. El tipado seguro significa que tu IDE detectara erratas en los nombres de las meta tags — algo que ha causado bugs reales en proyectos en los que he trabajado.
Las routeRules de Nuxt te permiten mezclar estrategias de renderizado por ruta. Esta es un area donde Nuxt esta posiblemente por delante de Next.js en experiencia de desarrollo:
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/': { prerender: true }, // SSG — homepage
'/blog/**': { isr: 3600 }, // ISR — revalidate hourly
'/products/**': { ssr: true }, // SSR — always fresh
'/dashboard/**': { ssr: false }, // CSR — authenticated pages
'/docs/**': { prerender: true }, // SSG — documentation
}
})Un objeto de configuración, cinco estrategias de renderizado diferentes. Con Next.js, tendrias que poner export const dynamic = 'force-static' o export const revalidate = 3600 en cada archivo de página individual. (En realidad, no es del todo justo — el middleware de Next.js también puede gestionar algo de esto de forma centralizada. Pero el enfoque de Nuxt es más explicito.) (Esto me recuerda a depurar la capa de GraphQL de Gatsby a las 2 de la manana — algunos frameworks optimizan para la experiencia de desarrollo a costa de la cordura del desarrollador.) El enfoque de Nuxt escala mejor cuando tienes patrones claros a nivel de ruta.
Nuxt no tiene generación de sitemap integrada como Next.js. Necesitas el modulo @nuxtjs/sitemap (que esta mantenido oficialmente y bien soportado):
// nuxt.config.ts
export default defineNuxtConfig({
modules: ['@nuxtjs/sitemap'],
sitemap: {
sources: ['/api/__sitemap__/urls'],
exclude: ['/dashboard/**', '/admin/**'],
},
site: {
url: 'https://example.com',
},
})El modulo descubre automáticamente tus páginas estaticas a partir del enrutamiento basado en archivos. Para páginas dinamicas (posts de blog, productos), proporcionas un endpoint de API que devuelve la lista de URLs. Los archivos de indice de sitemap se generan automáticamente cuando superas las 50.000 URLs.
Si estas construyendo un blog o un sitio de documentación con Nuxt, el modulo @nuxt/content merece la pena conocerlo. Lee archivos Markdown/MDX de un directorio content/, genera páginas con soporte completo de SSG e incluye busqueda integrada. Para el SEO, el beneficio clave es que cada página de contenido se pre-renderiza como HTML estático — la entrega más rápida posible a los motores de busqueda.
Solucion: Renderiza del lado del servidor tu contenido critico. Si necesitas tener estados de carga, asegurate de que solo aparezcan para elementos de UI no criticos. Verificacion: desactiva JavaScript en Chrome DevTools (Configuración > Depurador > Desactivar JavaScript), recarga la página. Lo que ves es lo que ven la mayoria de los rastreadores. Si ves un spinner, Google también lo ve.
Los datos estructurados JSON-LD ayudan a los motores de busqueda a entender de que trata tu página. Páginas de producto sin schema Product. Posts de blog sin schema Article. Páginas de FAQ sin schema FAQPage. Cada tipo de schema ausente es una oportunidad perdida para resultados enriquecidos.
Solucion: Anade JSON-LD a cada tipo de página. Verificacion: ejecuta el test de Resultados Enriquecidos de Google en cada tipo de página. Tanto Next.js como Nuxt hacen esto sencillo — consulta los ejemplos de código anteriores. O deja que SEOJuice lo gestione automáticamente.
Usar JavaScript (window.location.href, router.push(), navigateTo()) para redirecciones en lugar de 301/302 del lado del servidor. Los motores de busqueda no siguen las redirecciones JavaScript de forma fiable. La autoridad de enlace no se transfiere. Las páginas que deberian consolidarse permanecen separadas.
Solucion: Usa redirecciones del lado del servidor. En Next.js, configuralas en next.config.js o usa middleware. En Nuxt, usa las redirecciones de routeRules. Verificacion: curl -I https://tu-sitio.com/url-antigua — deberias ver un código de estado 301 o 302 con una cabecera Location. Si ves 200 OK, la redireccion es solo del lado del cliente.
Este es el error nuevo. Incluso si tu configuración de SSR es perfecta para Googlebot, comprueba si tu robots.txt bloquea los rastreadores de IA. Algunos proveedores de CDN (especialmente Cloudflare con su boton de "AI Bot") bloquean GPTBot y rastreadores similares por defecto. Si quieres visibilidad en los motores de busqueda de IA, asegurate de que puedan acceder a tu contenido. Verificacion: curl https://tu-sitio.com/robots.txt y busca GPTBot, ClaudeBot, PerplexityBot. Si estan bloqueados y no los pusiste tu, lo hizo tu CDN.
Y una comprobacion final que cubre todo lo anterior: haz clic derecho en cualquier página, Ver código fuente. Si tu contenido esta en el HTML sin procesar, el renderizado del servidor esta funcionando. Si ves un <div id="root"></div> vacio, no funciona. Ejecuta también la auditoria SEO de Lighthouse — apunta al 100, es alcanzable con renderizado del servidor. Como escribieron Jason Miller y Addy Osmani en web.dev: las estrategias de renderizado implican compromisos reales, y no puedes asumir que tu JavaScript sera ejecutado correctamente por cada rastreador (web.dev: Rendering on the Web).
Los frameworks de JavaScript y el SEO tienen una historia complicada. Durante anos, el consejo era "simplemente usa renderizado del lado del servidor" y eso era básicamente todo. Ahora el panorama es más matizado pero también más abordable.
Next.js con el App Router es la mejor opcion para la mayoria de los equipos en 2026. Los Server Components significan que tus páginas se renderizan en el servidor por defecto, la Metadata API tiene tipado seguro y es completa, y el ecosistema esta maduro. Si estas en el ecosistema Vue, Nuxt te da los mismos beneficios fundamentales con una superficie de API ligeramente diferente.
Las SPAs de React puro no deberian usarse para páginas publicas. Estoy cansado de ver SPAs de React en sitios de marketing. Estamos en 2026. Ya deberiamos saber esto. Y no va a cambiar — de hecho, el auge de los rastreadores de IA que no ejecutan JavaScript lo hace más difícil, no más fácil.
Algo sobre lo que tengo genuina incertidumbre: la trayectoria a largo plazo de Remix frente a Next.js para SEO. La filosofia de Remix de "solo SSR, sin capa de cache" resulta atractiva por su simplicidad. A medida que la computacion en el edge se abarata, el argumento a favor de ISR (el punto intermedio de Next.js) se debilita. No apostaria en contra de Remix en 2027. Pero hoy, Next.js tiene más funcionalidades de SEO integradas, un ecosistema más grande y mejor documentación. Usa lo que resuelva tu problema ahora.
Si todo esto te parece demasiada configuración para hacerlo bien — lo es. Por eso existe SEOJuice: tu eliges la estrategia de renderizado, nosotros automatizamos el resto.
Si, pero con matices. Google usa el Web Rendering Service (un Chromium siempre actualizado) para ejecutar JavaScript. El renderizado ocurre en un segundo paso — despues del rastreo inicial — y puede tardar desde segundos hasta dias. Para sitios establecidos con alto crawl budget, suele ser rápido. Para sitios nuevos o con baja autoridad, el retraso puede ser significativo. Y lo más importante: el renderizado de Google no esta garantizado. Las páginas que dependen de interacciones JavaScript complejas, requieren autenticación o tienen errores de renderizado pueden no ser completamente renderizadas nunca. El enfoque más seguro siempre es servir HTML completo en la respuesta inicial.
Elige en función de si tu equipo escribe Vue o React, no en función de las diferencias de SEO.
El camino más rápido: anade Prerender.io o un servicio de prerendering similar como middleware. Esto intercepta las peticiones de los rastreadores y sirve HTML pre-renderizado. Se configura en aproximadamente una hora y hace que tu contenido sea visible inmediatamente para los motores de busqueda. Despues, planifica una migración gradual a Next.js — el App Router puede coexistir con las páginas existentes, asi que puedes migrar ruta por ruta en lugar de hacer una reescritura total. Empieza por tus páginas con más trafico.
no credit card required
No related articles found.