Skip to content
7 min lectura Desarrollo Web

JavaScript SEO: React, Next.js, Vue y los errores que matan tu trafico

JavaScript SEO: React, Next.js, Vue y los errores que matan tu trafico

JavaScript SEO: React, Next.js, Vue y los errores que matan tu tráfico

El JavaScript moderno ha transformado la forma en que construimos experiencias web. Frameworks como React, Next.js, Vue y Nuxt permiten crear interfaces rápidas, dinámicas y visualmente atractivas. Pero hay un problema que muchos equipos de desarrollo descubren demasiado tarde: lo que el usuario ve no es necesariamente lo que Google indexa.

En nuestra experiencia con más de 300 proyectos de SEO técnico, hemos visto cómo sitios con un desarrollo brillante perdían hasta el 70% de su tráfico orgánico por errores evitables en la implementación de JavaScript. Este artículo recoge los fallos más frecuentes y las soluciones concretas que aplicamos en cada framework.

SSR vs CSR: la decisión que define tu visibilidad

Antes de entrar en errores concretos, es fundamental entender la diferencia entre Server-Side Rendering (SSR) y Client-Side Rendering (CSR), porque aquí empieza todo.

Con CSR, el servidor envía un HTML prácticamente vacío —un div raíz y un bundle de JavaScript— y el navegador del usuario se encarga de renderizar todo el contenido. El problema es que Googlebot, aunque puede ejecutar JavaScript, lo hace en una segunda ola de indexación que puede tardar días o incluso semanas. Mientras tanto, Google ve una página vacía.

Con SSR, el servidor genera el HTML completo antes de enviarlo al navegador. Googlebot recibe el contenido final desde el primer momento, sin esperar a ninguna ejecución de JavaScript. Esto significa indexación inmediata, metadatos correctos y contenido completo desde la primera visita del crawler.

  • CSR puro (React SPA, Vue SPA): Alto riesgo de problemas de indexación. Solo recomendable para aplicaciones privadas o dashboards.
  • SSR (Next.js con App Router, Nuxt 3): Contenido disponible para crawlers desde el primer request. La opción más segura para SEO.
  • SSG (Static Site Generation): HTML pre-generado en tiempo de build. Ideal para contenido que no cambia frecuentemente.
  • ISR (Incremental Static Regeneration): Combina lo mejor de SSG y SSR. Páginas estáticas que se regeneran bajo demanda.

Cómo renderiza Googlebot el JavaScript (y sus limitaciones reales)

Google utiliza una versión de Chromium para renderizar JavaScript, pero con restricciones importantes que muchos desarrolladores desconocen:

  • Cola de renderizado: El renderizado de JavaScript no es inmediato. Las páginas entran en una cola y pueden tardar entre horas y semanas en ser procesadas.
  • Sin interacción de usuario: Googlebot no hace clic, no hace scroll, no dispara eventos hover. El contenido que depende de interacción del usuario es invisible para el crawler.
  • Tiempo límite: Si tu JavaScript tarda más de 5 segundos en renderizar, Googlebot puede abandonar la página con contenido incompleto.
  • Sin almacenamiento local: localStorage, sessionStorage y cookies de sesión no están disponibles entre rastreos.
  • Presupuesto de rastreo: Cada página con JavaScript pesado consume más recursos del crawl budget que una página con HTML estático.

Los 7 errores más comunes que destruyen el tráfico orgánico

1. Meta tags renderizados solo en cliente

Este es, con diferencia, el error más frecuente y más dañino. Si tu title, meta description y etiquetas Open Graph se inyectan mediante JavaScript en el cliente, Googlebot puede no verlas en la primera ola de indexación. Hemos auditado sitios donde el 100% de los snippets en Google mostraban el título por defecto del template en lugar del título real de cada página.

Solución: Asegúrate de que todas las meta tags se rendericen en el servidor. En Next.js App Router, usa el objeto metadata o la función generateMetadata en tus layouts y páginas. En Nuxt 3, utiliza useHead() o useSeoMeta() dentro del setup del componente.

2. Lazy loading agresivo en contenido above the fold

El lazy loading es una técnica excelente para mejorar el rendimiento, pero aplicarlo al contenido que aparece en la primera pantalla visible es contraproducente. Hemos visto e-commerce donde las imágenes principales de producto y los títulos H1 estaban lazy-loaded, resultando en un LCP (Largest Contentful Paint) desastroso y contenido que Google no siempre capturaba.

Solución: Nunca apliques lazy loading a imágenes, textos o elementos que están above the fold. En Next.js, usa priority en el componente Image para las imágenes principales. Reserva el lazy loading para el contenido que aparece al hacer scroll.

3. Contenido cargado tras interacción del usuario

Tabs, acordeones, botones de «ver más» y contenido que solo aparece tras un clic: Googlebot no va a interactuar con estos elementos. Si tu contenido más valioso está detrás de una interacción, está oculto para el buscador.

Solución: Renderiza todo el contenido en el HTML inicial y usa CSS para controlar la visibilidad. El contenido en acordeones y tabs debe estar presente en el DOM desde el inicio.

4. URLs dependientes de hash o estado del cliente

Las rutas con hash (#/productos/zapatos) o que dependen del estado del navegador no son rastreables por Google. Cada URL que quieras indexar debe ser accesible con un request HTTP directo.

5. Canonical tags dinámicos mal implementados

Cuando el canonical se genera en el cliente, puede apuntar a URLs incorrectas durante la primera ola de rastreo. En sitios con paginación o filtros, esto genera problemas de contenido duplicado a gran escala.

6. Sitemaps que apuntan a páginas que requieren JavaScript

De nada sirve tener un sitemap perfecto si las URLs que contiene devuelven un HTML vacío al crawler. Google las descubrirá, las visitará, verá un esqueleto y las catalogará como páginas sin contenido.

7. Errores en el hidratación (hydration mismatch)

Cuando el HTML del servidor no coincide con lo que genera el JavaScript en el cliente, se producen errores de hidratación. Esto puede causar que el contenido se re-renderice completamente en el cliente, perdiendo el beneficio del SSR.

Guía específica por framework

Next.js con App Router

  • Usa Server Components por defecto. Solo marca como ‘use client’ los componentes que realmente necesitan interactividad.
  • Implementa generateMetadata para meta tags dinámicos en cada ruta.
  • Usa generateStaticParams para pre-generar páginas de producto o categoría.
  • Configura revalidate para ISR según la frecuencia de actualización de tu contenido.
  • El middleware de Next.js se ejecuta en el edge: úsalo para redirecciones y hreflang, no para contenido.

Nuxt 3

  • Activa SSR por defecto en nuxt.config.ts (viene activado, pero muchos lo desactivan por comodidad).
  • Usa useFetch o useAsyncData en vez de llamadas fetch en onMounted: las primeras se ejecutan en el servidor.
  • Implementa useSeoMeta para gestionar meta tags de forma limpia y server-side.
  • Las rutas de Nuxt con prerender: true en routeRules generan HTML estático en build.

React SPA sin framework SSR

Si tienes una SPA pura con React Router y no puedes migrar a Next.js, tus opciones son:

  • Pre-rendering con servicios como Prerender.io: Genera snapshots HTML para crawlers. Funcional pero añade complejidad y coste.
  • Migración progresiva a Next.js: Es la inversión más rentable a largo plazo.
  • React Server Components con un setup custom: Posible pero complejo de mantener sin un framework.

Por qué en ZDS construimos con Astro

Para nuestros propios proyectos y los de clientes donde el rendimiento SEO es prioritario, utilizamos Astro con SSR. Astro envía cero JavaScript por defecto al navegador, renderiza todo en el servidor y permite integrar componentes de React, Vue o Svelte solo donde se necesita interactividad. El resultado es un rendimiento perfecto en Core Web Vitals y una indexación inmediata sin ningún truco adicional.

No es que los demás frameworks sean malos —Next.js y Nuxt son herramientas excelentes— pero requieren una configuración cuidadosa para SEO. Astro elimina la mayoría de estos problemas por diseño.

Checklist final: JavaScript SEO en 2026

  • Verifica que tu HTML renderizado en servidor contiene todo el contenido, meta tags y enlaces.
  • Usa View Source (no Inspeccionar Elemento) para ver lo que recibe Google.
  • Testea tus URLs con la herramienta de Inspección de URLs de Google Search Console.
  • Monitoriza el informe de Estadísticas de Rastreo para detectar problemas de renderizado.
  • Asegúrate de que tu sitemap solo contiene URLs que devuelven HTML completo.
  • Evita lazy loading en contenido above the fold.
  • Comprueba que los canonical tags se generan en el servidor.

El JavaScript SEO no es una disciplina aparte: es SEO técnico aplicado a la realidad del desarrollo web moderno. Si tu stack tecnológico no está alineado con los requisitos de indexación, ninguna estrategia de contenido o de enlaces va a compensar el tráfico que estás dejando sobre la mesa.

¿Tu web JavaScript no rinde en Google como debería? En ZDS llevamos más de una década resolviendo exactamente este tipo de problemas. Descubre nuestros servicios de SEO técnico o contacta con nuestro equipo para una auditoría de tu implementación.

Consejo: Usa server-side rendering (SSR) para contenido critico. Los motores de busqueda mejoraron con JS pero no son perfectos.
Necesitas ayuda?Nuestro equipo analiza tu situacion y propone un plan personalizado. Solicitar consultoria gratuita →

¿Necesitas ayuda con tu estrategia?

Nuestro equipo analiza tu situación y te propone un plan personalizado. Sin compromiso.

Solicitar consulta gratuita
Manuel Riveiro

Manuel Riveiro

CEO & Digital Strategist — ZDS

20+ años de experiencia en SEO, performance marketing y herramientas de IA. Fundador de ZDS y B2 Performance, con sede en Barcelona y Herdecke.