Frameworks JavaScript del lado del cliente para SEO
React, Vue, Angular, Svelte y SolidJS comparten un problema de SEO: el renderizado del lado del cliente envía un shell vacío, y un patrón de solución: gestión del head más una estrategia de renderizado.
Idiomas
React, Vue, Angular, Svelte y SolidJS son bibliotecas de UI que, de forma predeterminada, envían un shell HTML casi vacío y construyen la página en el navegador (renderizado del lado del cliente). Eso significa que los rastreadores reciben una página en blanco hasta que se ejecuta JavaScript: Google puede renderizarla, pero en una cola retrasada, y otros rastreadores (Bing y los bots de IA) son mucho menos fiables. La solución es la misma para los cinco: (1) un paquete de gestión del head para que existan metaetiquetas por ruta y (2) una estrategia de renderizado: prerenderizado, SSR o migración al meta-framework correspondiente. Este hub explica el problema y la solución compartidos y después enlaza con los análisis detallados de cada framework.
TL;DR — React, Vue, Angular, Svelte y SolidJS son herramientas que los desarrolladores usan para crear sitios interactivos. De forma predeterminada, envían al navegador una página HTML casi vacía y después construyen el contenido real con JavaScript. Es excelente para los usuarios, pero arriesgado para el SEO: un rastreador puede llegar a una página en blanco. La solución es la misma para todos: gestionar
<title>y las metaetiquetas por página y asegurarse de que el contenido exista en el HTML antes de que se ejecute JavaScript.
Qué son los frameworks del lado del cliente
Los frameworks del lado del cliente pueden renderizar el contenido de una ruta en el navegador después de una respuesta HTML inicial. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: MDN: Client-side frameworks Google puede renderizar JavaScript, pero la disponibilidad de recursos y el renderizado también influyen en lo que se procesa. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript SEO basics
Un framework del lado del cliente es una biblioteca de JavaScript que construye la página en el navegador de tu visitante. Los cinco que encontrarás con más frecuencia son React, Vue, Angular, Svelte y SolidJS. Son la base de la mayoría de las aplicaciones web y los paneles de control modernos.
La clave está en la expresión del lado del cliente. De forma predeterminada, estos frameworks envían un archivo HTML pequeño que se parece aproximadamente a esto:
<body>
<div id="root"></div>
<script src="/bundle.js"></script>
</body>No hay contenido en ese HTML: solo un contenedor vacío y un script. El navegador descarga el script, lo ejecuta y después aparecen el titular, el texto, los enlaces y todo lo demás. Este comportamiento predeterminado se llama renderizado del lado del cliente (CSR), y un sitio construido así suele llamarse aplicación de una sola página (SPA).
Por qué esto es un problema para el SEO
Un rastreador de búsqueda no es una persona que hace clic. Cuando Googlebot u otro rastreador obtiene tu página, lo primero que recibe es ese shell vacío. Si el rastreador no ejecuta tu JavaScript, ve una página en blanco: no hay contenido que indexar.
Google puede ejecutar JavaScript, por lo que normalmente acaba viendo tu contenido. Pero:
- Ocurre con retraso (el renderizado es un paso independiente que se procesa en una cola).
- Otros rastreadores — Bing y los rastreadores de IA que alimentan herramientas como ChatGPT — son mucho menos fiables al ejecutar JavaScript.
Que «funcione en mi navegador» no significa que «los motores de búsqueda puedan verlo».
La solución es la misma para los cinco
Independientemente del framework que hayas elegido, la solución tiene dos partes:
- Gestiona el head. Cada página necesita su propio
<title>y su propia meta description. Una aplicación CSR sencilla tiene un solo archivo HTML, así que, sin ayuda, todas las páginas comparten el mismo título. Cada framework tiene un paquete pequeño que resuelve esto (hay más información en la pestaña Avanzado). - Elige una estrategia de renderizado. Introduce el contenido en el HTML antes de que se ejecute JavaScript mediante prerenderizado (generar HTML estático con antelación), renderizado del lado del servidor (SSR) o el traslado al meta-framework correspondiente (Next.js para React, Nuxt para Vue y otros).
¿Quieres conocer los detalles de cada framework — qué paquete de head usar, qué opción de renderizado elegir y cómo gestiona Google estas aplicaciones? Cambia a la pestaña Avanzado y luego ve a la guía específica de tu framework.
TL;DR — React, Vue, Angular, Svelte y SolidJS son bibliotecas de UI que usan renderizado del lado del cliente de forma predeterminada: envían un shell HTML casi vacío y construyen el DOM en el navegador. El problema de SEO es idéntico en los cinco casos: los rastreadores reciben un shell vacío y el contenido solo existe después de que se ejecuta JS. Google renderiza estas aplicaciones, pero con un proceso retrasado y en cola; Bing y los rastreadores de IA son mucho menos fiables. La solución también es idéntica: (1) gestión del head (un paquete por ruta para
<title>y las metaetiquetas) y (2) una estrategia de renderizado (prerenderizado, SSR o migración al meta-framework correspondiente). Las diferencias entre frameworks son principalmente qué paquete y qué estrategia usar; cada análisis detallado se ocupa de ellas a continuación.
Son bibliotecas, no frameworks completos — y esa es la raíz del problema
La arquitectura de cada framework varía, así que el renderizado en el cliente no es un fallo automático de indexación. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: MDN: Client-side frameworks El renderizado en el servidor o el prerenderizado reduce la dependencia de que el JavaScript se ejecute en el rastreador, sin garantizar la indexación. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript SEO basics
React, Vue, Angular, Svelte y SolidJS son principalmente bibliotecas de renderizado de UI. Su función es convertir tus datos en un DOM y mantenerlo sincronizado a medida que cambia el estado. De forma predeterminada, ese DOM se construye en el navegador: eso es exactamente lo que hace que se sientan rápidas y parecidas a una aplicación, y exactamente lo que crea el problema de SEO.
Una compilación predeterminada envía un shell HTML con un nodo de montaje vacío (<div id="root">, <div id="app">, <app-root>) y un paquete de JavaScript. Todo lo que le importa a un motor de búsqueda —títulos, texto principal, enlaces internos y datos estructurados— lo inyecta ese paquete después de descargarse y ejecutarse. Antes de que se ejecute JS, no hay nada.
Esto es el renderizado del lado del cliente: el comportamiento de serie de las bibliotecas sin meta-framework ni paso de prerenderizado durante la compilación. No es un error; es el punto de partida predeterminado. Pero «predeterminado» no significa «permanente» ni «universal»: cambia según la versión y el CLI o starter que hayas usado, y dos rutas de la misma aplicación pueden acabar con modos de renderizado distintos según cómo se haya construido cada una (una página de marketing prerenderizada y un panel dejado como CSR puro). No des por sentado el comportamiento de un framework por su nombre: comprueba qué entrega realmente una ruta concreta en una compilación concreta.
El problema compartido: un shell vacío
Google explica explícitamente que procesa las aplicaciones JS en fases —rastreo, renderizado e indexación— y que “without rendering Google might not see that content.” (traducción) «sin renderizado, Google podría no ver ese contenido». En una aplicación CSR, todo el contenido está detrás de ese paso de renderizado. De ahí se desprenden tres consecuencias:
- El renderizado se retrasa y la espera no es fija. El renderizado es un paso independiente que se pone en cola después del rastreo. Google documenta el rastreo, el renderizado y la indexación como tres fases distintas, pero no se compromete con un tiempo de espera universal para todas las páginas. El retraso varía según la URL y los recursos de Google disponibles en ese momento; tu contenido no existe para la indexación hasta que se completa el renderizado, tarde lo que tarde en esa página.
- Los rastreadores que no son de Google no están garantizados. Bing renderiza JavaScript de forma irregular y la mayoría de los rastreadores de IA (los bots que obtienen páginas para los LLM y la búsqueda con IA) ejecutan poco JavaScript o nada. Son empresas distintas con infraestructuras distintas, así que nada de esto se puede generalizar a partir de la documentación de Google: verifica el comportamiento actual de cada proveedor en lugar de suponer que coincide con el de Google o con la prueba del año pasado. Un sitio que solo usa CSR corre el riesgo de ser casi invisible para los rastreadores que no renderizan, y los rastreadores de IA representan una proporción creciente del tráfico.
- Faltan metadatos por página. Un solo archivo HTML implica un solo
<title>y una sola meta description para todas las rutas, a menos que gestiones activamente el head por ruta.
La solución compartida, parte 1: gestión del head
Como una SPA tiene un único documento HTML, necesitas código que actualice el head del documento cuando el usuario (y el renderizador del rastreador) se desplaza entre rutas. Todos los frameworks tienen un paquete canónico o una API incorporada para esto:
- React →
react-helmet-async(o la API de metadatos del framework si has migrado a Next.js). - Vue →
@unhead/vue(el motor de las utilidades de SEO de Nuxt). - Angular → los servicios incorporados
TitleyMetade@angular/platform-browser: no necesitas ninguna dependencia adicional. - Svelte → el elemento incorporado
<svelte:head>. - SolidJS →
@solidjs/meta(y SolidStart para la ruta SSR).
La gestión del head te proporciona metaetiquetas correctas y únicas, pero por sí sola no resuelve el problema del shell vacío. Las etiquetas siguen apareciendo solo después de que se ejecuta JS. Por eso también necesitas la parte 2.
La solución compartida, parte 2: una estrategia de renderizado
Para incluir contenido real (y las etiquetas del head) en el HTML antes de que se ejecute JavaScript, puedes elegir uno de tres enfoques. Este es el orden según cuánto riesgo de SEO elimina cada uno:
- Prerenderizado / generación estática (SSG). Genera HTML estático para cada ruta durante la compilación. Es la opción de menor riesgo para contenido que no cambia por solicitud. Cada biblioteca tiene una ruta de prerenderizado (por ejemplo, el prerenderizado incorporado de SolidJS y los plugins de prerenderizado de Vue y Angular).
- Renderizado del lado del servidor (SSR). Renderiza el HTML en el servidor por solicitud y después hidrátalo en el navegador. Aquí entran los meta-frameworks: Next.js (React), Nuxt (Vue), Angular SSR (antes Angular Universal), SvelteKit (Svelte) y SolidStart (SolidJS). Para la mayoría de los sitios de contenido que necesitan posicionarse, adoptar el meta-framework correspondiente es la solución más limpia.
- Mantener el CSR completo, pero hacerlo rastreable. A veces es aceptable para superficies similares a una aplicación que están detrás de un inicio de sesión y no necesitan posicionarse, pero es un mal valor predeterminado para todo lo que quieras incluir en las búsquedas.
Toma esta decisión por ruta, no por aplicación. Una página de marketing y un panel con sesión iniciada dentro de la misma base de código pueden encajar razonablemente en filas distintas de esa lista. Para cada ruta, pregunta:
- Salida: ¿el contenido debe estar en la respuesta inicial o está bien que aparezca después de que se ejecute JS?
- Frescura: ¿es lo bastante estable para generarlo una vez (prerenderizado) o cambia en cada solicitud (SSR)?
- Personalización: ¿es distinto para cada visitante? El prerenderizado no puede ayudar aquí; debes elegir entre SSR y CSR.
- Costo del servidor: el SSR añade cómputo en cada solicitud; el prerenderizado concentra ese costo en la compilación.
- Dependencia de JS: ¿cuánto depende la utilidad de la ruta de que se ejecute JavaScript en el cliente?
- Comportamiento ante fallos: si JS falla o está bloqueado, ¿la ruta se degrada a algo utilizable o a nada?
La decisión es la misma independientemente del framework: ¿este contenido necesita posicionarse o ser citado? Si la respuesta es sí, introdúcelo en HTML renderizado en el servidor o prerenderizado. Si es una interfaz de aplicación puramente interactiva, el CSR está bien.
Cómo gestiona Google estas aplicaciones (y por qué otros no lo hacen)
Google puede renderizar cada uno de estos frameworks: ejecuta un Chrome headless actualizado y ejecuta tu JS. Pero lo hace en una cola aplazada, y el renderizador es sin estado (no conserva cookies ni localStorage, no usa service workers y no interactúa: no hará scroll ni clic). Por eso, además de elegir framework, se aplican las mismas reglas de JS-SEO del hub de JavaScript SEO: enlaces <a href> reales, paridad entre el DOM sin renderizar y el renderizado, ningún contenido detrás de una interacción y ningún noindex inyectado por JS.
Fuera de Google, la situación es peor. El renderizado de JS de Bing es más irregular y los rastreadores de IA, en gran medida, no renderizan. En una aplicación CSR, eso puede significar que tu contenido exista para Google (con el tiempo), pero no para Bing ni para las herramientas de IA con las que cada vez más personas buscan. El SSR o el prerenderizado cierran esa brecha para todos, no solo para Google: es el argumento más sólido para no publicar contenido que dependa únicamente del CSR.
Los cinco frameworks de un vistazo
| Framework | Predeterminado | Gestión del head | SSR / meta-framework | Nota de SEO |
|---|---|---|---|---|
| React | CSR | react-helmet-async | Next.js (Metadata API) | La SPA que prioriza CSR más común; Next.js es la solución SEO estándar |
| Vue | CSR | @unhead/vue | Nuxt (useSeoMeta()) | Nuxt usa SSR de forma predeterminada; Vue puro necesita prerenderizado o Nuxt |
| Angular | CSR (SPA) | servicios incorporados Title/Meta | Angular SSR (antes Universal) | SPAs grandes; Angular moderno añade SSR e hidratación incremental |
| Svelte | CSR (Svelte) / SSR (SvelteKit) | <svelte:head> | SvelteKit (SSR predeterminado) | SvelteKit usa SSR por defecto: cuidado con la trampa estática ssr:false |
| SolidJS | CSR | @solidjs/meta | SolidStart | Reactividad granular; SolidStart añade SSR y prerenderizado |
El patrón es coherente: un valor predeterminado CSR, un paquete para el head y una estrategia de renderizado (normalmente el meta-framework correspondiente). Lo que cambia son los nombres y algunos bordes problemáticos.
Dónde seguir: análisis detallados de cada framework
Este hub es el mapa. Cada framework tiene su propia guía con los paquetes, la configuración y las particularidades específicas:
- React SEO: por qué React, que prioriza CSR, crea riesgo de indexación, React Router y la History API,
react-helmet-asyncy cuándo recurrir a Next.js. - Vue SEO: el valor predeterminado CSR de Vue 3,
createWebHistory(),@unhead/vue, el prerenderizado sin meta-framework y cuándo Nuxt es la opción adecuada. - Angular SEO: los valores predeterminados SPA de Angular,
@angular/ssr, los servicios incorporadosTitleyMeta, el prerenderizado y la hidratación incremental. - Svelte SEO: Svelte frente a SvelteKit, SSR predeterminado en SvelteKit,
<svelte:head>, la trampa deadapter-static+ssr: falsey sus implicaciones para los rastreadores de IA. - SolidJS SEO: el valor predeterminado CSR de SolidJS,
@solidjs/meta, SolidStart para SSR y prerenderizado, y cómo su modelo granular afecta al resultado renderizado.
Para los propios modos de renderizado (CSR, SSR, SSG, ISR, hidratación y renderizado dinámico) y las reglas generales de renderizado/paridad, consulta el hub principal de JavaScript SEO.
Resumen de IA
Una síntesis de la versión Advanced:
- Un punto de partida compartido. React, Vue, Angular, Svelte y SolidJS usan renderizado del lado del cliente de forma predeterminada: un shell HTML casi vacío (
<div id="root">+ un paquete) que construye el DOM en el navegador. Ese valor predeterminado cambia según la versión, el starter y el meta-framework, y puede variar entre rutas de la misma aplicación; comprueba qué entrega realmente una ruta concreta en lugar de suponerlo por el nombre del framework. - Google lo renderiza, pero la espera no es fija. El renderizado es un paso independiente que se pone en cola después del rastreo, pero Google no se compromete con un retraso universal para todas las páginas: varía según la URL. Además, el renderizador no tiene estado y no hará scroll ni clic.
- Los demás rastreadores no están garantizados. Bing renderiza JS de manera irregular y la mayoría de los rastreadores de IA no renderizan en absoluto. Son empresas distintas, así que nada de esto se puede generalizar a partir de la documentación de Google: verifica el comportamiento actual de cada proveedor.
- Una solución compartida en dos partes. (1) Gestión del head: un paquete por ruta para
<title>y las metaetiquetas:react-helmet-async(React),@unhead/vue(Vue),Title/Metaincorporados (Angular),<svelte:head>(Svelte),@solidjs/meta(SolidJS). (2) Una estrategia de renderizado: prerenderizado/SSG, SSR o migración al meta-framework correspondiente (Next.js / Nuxt / Angular SSR / SvelteKit / SolidStart). - La gestión del head por sí sola no basta: las etiquetas siguen apareciendo solo después de que se ejecuta JS; aún necesitas una estrategia de renderizado para llenar el shell.
- Decide por ruta, sopesando el momento de salida, la frescura, la personalización, el costo del servidor, la dependencia de JS y el comportamiento ante fallos, no por aplicación. Si una ruta necesita posicionarse o ser citada, introdúcela en HTML renderizado en el servidor o prerenderizado. Si solo es UI de aplicación detrás de un inicio de sesión, el CSR está bien.
Documentación oficial
Documentación de fuentes primarias de los motores de búsqueda y los frameworks.
- Conceptos básicos de JavaScript SEO: las fases de rastreo → renderizado → indexación, los enlaces rastreables y las pruebas del HTML renderizado.
- Solucionar problemas de JavaScript relacionados con la búsqueda: gestión de soft-404 después del enrutamiento del cliente, History API y restricciones del renderizador.
- Guía detallada de cómo funciona la Búsqueda de Google: dónde se sitúa el renderizado entre el rastreo, la indexación y la publicación.
Bing / Microsoft
- Serie bingbot: JavaScript, renderizado dinámico y cloaking: la perspectiva de Bing sobre el renderizado de JS y por qué existe el renderizado dinámico.
Los frameworks (head + renderizado)
- Documentación de React: la biblioteca que popularizó la SPA que prioriza CSR; consulta también metadatos de Next.js.
- Vue.js — Renderizado / SSR y utilidades SEO de Nuxt.
- Angular — Renderizado del lado del servidor y los servicios
Title/Meta. - SvelteKit — Opciones de página (SSR/prerenderizado) y
<svelte:head>. - SolidStart — SSR y prerenderizado y
@solidjs/meta.
Citas de la fuente
Declaraciones registradas que fundamentan el problema y la solución compartidos del CSR. Cada enlace de un motor de búsqueda es un enlace profundo que salta al pasaje citado.
Google — el renderizado y por qué importa el shell
- “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (traducción) «Google procesa las aplicaciones web JavaScript en tres fases principales: 1. Rastreo 2. Renderizado 3. Indexación.» Salta a la cita
- “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (traducción) «El renderizado es importante porque los sitios web suelen depender de JavaScript para llevar contenido a la página y, sin renderizado, Google podría no verlo.» Salta a la cita
- “Google can only discover your links if they are <a> HTML elements with an href attribute.” (traducción) «Google solo puede descubrir tus enlaces si son elementos HTML <a> con un atributo href.» — se aplica al router de todos los frameworks. Salta a la cita
- “Google Search does not interact with your page.” (traducción) «La Búsqueda de Google no interactúa con tu página.» — el renderizador no hará scroll ni clic para revelar contenido. Salta a la cita
Patrick Stox (mi propio trabajo — JavaScript SEO: una guía definitiva)
- “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (traducción) «Cualquier configuración de SSR, renderizado estático y prerenderizado será adecuada para los motores de búsqueda.» — es la idea transversal de todos los frameworks de este hub.
- El renderizador aplica la directiva de robots más restrictiva entre el HTML sin renderizar y el renderizado; por eso un framework que inyecta
noindexen el cliente puede sacar una página del índice aunque el shell indiqueindex.
Lista de comprobación de SEO para frameworks del lado del cliente
Funciona igual para React, Vue, Angular, Svelte y SolidJS:
- Sabes si tu aplicación usa CSR, SSR o prerenderizado actualmente (comprueba Ver código fuente: ¿el contenido está en el HTML sin procesar o solo hay un nodo de montaje vacío?).
- El contenido que debe posicionarse o ser citado está en el HTML renderizado en el servidor o prerenderizado, no se inyecta solo después de que se ejecuta JS.
- Gestionas el
<title>y la meta description por ruta (con un paquete para el head o una API incorporada), y son únicos por página en el HTML renderizado. - Los enlaces del router son anclas reales
<a href>(enrutamiento con History API, no con fragmentos#ni cononclicken un<div>). - JavaScript y CSS no están bloqueados en
robots.txt(Google no renderizará archivos bloqueados). - No hay contenido condicionado a un scroll, clic o hover.
- Las vistas de «no encontrado» del cliente devuelven un
404real o llevannoindex(no shells soft-404). - Ningún JS inyecta un
noindexque contradiga el HTML sin renderizar (Google aplica la directiva más restrictiva). - Has tenido en cuenta los rastreadores de Bing y de IA, no solo Google: SSR/prerenderizado es la única respuesta fiable para ellos.
- Has verificado el resultado en Inspección de URL (HTML renderizado + captura de pantalla + consola), no solo en tu propio navegador.
Estas comprobaciones agrupan varias salidas distintas en una sola página. Verifica cada fase por separado: una ruta puede superar una fase y fallar la siguiente:
| Fase | Qué comprobar |
|---|---|
| Respuesta directa (JS desactivado/bloqueado) | Obtén la URL con JS desactivado. ¿Aparecen tu encabezado y el texto principal únicos o solo el nodo de montaje? |
| Fragmentos transmitidos (si hay streaming) | ¿Llega el contenido progresivamente o un fragmento lento retrasa todo lo que viene después? |
| DOM renderizado (JS ejecutado) | Después de ejecutar el paquete, ¿el DOM final está completo: encabezados, enlaces y datos estructurados? |
| Hidratación | ¿El cliente toma el control correctamente o aparecen errores de consola o discrepancias de hidratación? |
| Navegación del cliente | ¿Un cambio de ruta dentro de la aplicación actualiza la URL, el título y la canonical igual que una carga directa? |
| Códigos de estado | ¿Una ruta 404/410/5xx real devuelve ese estado directamente y no solo un mensaje renderizado en el cliente dentro de un 200? |
| Metadatos | ¿El <title>, la description, la canonical y la directiva de robots renderizados son correctos por ruta, y no solo están presentes? |
Frameworks → la solución de un vistazo
| Framework | Renderizado predeterminado | Gestión del head | SSR / meta-framework | Ruta de prerenderizado |
|---|---|---|---|---|
| React | CSR | react-helmet-async | Next.js | SSG de Next.js / react-snap |
| Vue | CSR | @unhead/vue | Nuxt | nuxi generate de Nuxt / plugin de prerenderizado |
| Angular | CSR (SPA) | Title / Meta incorporados | Angular SSR (antes Universal) | prerenderizado de ng build |
| Svelte | CSR (Svelte) / SSR (SvelteKit) | <svelte:head> | SvelteKit | adapter-static (cuidado con ssr:false) |
| SolidJS | CSR | @solidjs/meta | SolidStart | prerenderizado de SolidStart |
La solución en dos partes (memorízala)
- Gestión del head →
<title>y metaetiquetas únicas por ruta. - Estrategia de renderizado → prerenderizado (SSG), o SSR, o el meta-framework correspondiente. La gestión del head por sí sola no llena el shell vacío.
Escala de riesgo (de menor a mayor riesgo de SEO)
| Enfoque | Riesgo de SEO | Cuándo |
|---|---|---|
| Prerenderizado / SSG | Más bajo | Contenido estable por solicitud |
| SSR (meta-framework) | Bajo | Contenido dinámico o por solicitud que debe posicionarse |
| Hidratación (isomórfica) | Bajo | Híbrido de aplicación y contenido |
| CSR completo | Más alto | UI de aplicación detrás de un inicio de sesión que no necesita posicionarse |
Comprobación de la realidad de los rastreadores
| Rastreador | ¿Ejecuta tu JS? |
|---|---|
| Googlebot | Sí, pero retrasado, en cola y sin estado |
| Bingbot | De forma irregular |
| Rastreadores de IA (LLM / búsqueda con IA) | En su mayoría no |
El contenido que solo usa CSR es una apuesta en todas partes salvo Google, e incluso allí se retrasa. El SSR o el prerenderizado eliminan la apuesta para todos.
Problemas habituales de SEO en frameworks del lado del cliente
Las herramientas de búsqueda muestran una página vacía o solo el shell de la aplicación
Síntoma: el HTML sin renderizar contiene solo un elemento de montaje como #root, #app o app-root, mientras que la página visible contiene el texto real. Causa probable: la ruta se renderiza completamente en el cliente. Solución: prerenderiza las rutas estables o traslada la ruta al meta-framework del framework que admita SSR. Confirma la solución obteniendo la URL con JavaScript desactivado y encontrando su encabezado y texto principal únicos en la respuesta.
Todas las rutas tienen el mismo título o canonical
Síntoma: varias URL muestran vistas diferentes, pero exponen el mismo título, description o canonical. Causa probable: el shell HTML compartido controla el head y los cambios de ruta no lo actualizan. Solución: usa la API de head específica del framework y configura los metadatos a partir de los datos de la ruta. Confirma que el DOM final de cada ruta contiene una canonical autorreferente y su propio título.
Los enlaces funcionan para los usuarios, pero los rastreadores no descubren las rutas
Síntoma: la navegación funciona en el navegador, pero las rutas enlazadas siguen sin descubrirse. Causa probable: los controladores de clic en botones o elementos div sustituyen a las anclas rastreables. Solución: renderiza enlaces <a href="..."> reales y deja que el router los mejore. Confirma que el destino aparece como un href en el DOM renderizado sin hacer clic.
La consola muestra errores de hidratación o contenido discrepante
Síntoma: el HTML renderizado en el servidor o prerenderizado parece correcto, pero la consola del navegador registra advertencias de hidratación o el contenido parpadea y cambia justo después de cargar. Causa probable: la salida del servidor y el primer renderizado del cliente no coinciden, a menudo por el formato de fecha o configuración regional, identificadores aleatorios o código que depende de window durante el renderizado inicial. Solución: haz que el servidor y el cliente rendericen de forma determinista con la misma entrada; mueve la lógica exclusiva del navegador para que se ejecute después de la hidratación y no durante ella. Confirma la solución cargando la ruta con JS activado y comprobando que no haya errores de hidratación en la consola.
Una ruta cambia de estado en el navegador, pero la URL directa no coincide
Síntoma: al hacer clic por la aplicación se muestra una página funcional, pero solicitar esa misma URL directamente (o después de actualizar) devuelve un resultado diferente: un shell genérico, un código de estado incorrecto o metadatos obsoletos. Causa probable: la navegación del cliente actualiza la vista del navegador sin un controlador de ruta equivalente en el servidor, por lo que el estado que existe después de la transición del cliente nunca fue una página real que se pudiera solicitar de forma independiente. Solución: asegúrate de que cada ruta a la que pueda llegar un usuario también se pueda solicitar directamente y devuelva el mismo contenido, estado y metadatos. Confirma la solución cargando la URL desde cero (sin hacer clic), primero con JS desactivado y después activado.
Pon a prueba tus conocimientos: frameworks del lado del cliente
Cinco preguntas rápidas sobre el problema y la solución de SEO compartidos por React, Vue, Angular, Svelte y SolidJS. Elige una respuesta para cada una y luego comprueba.
Recursos que merecen tu tiempo
Mis escritos relacionados
- JavaScript SEO: una guía definitiva — mi guía completa sobre renderizado, paridad del DOM, la regla de la directiva más restrictiva y la elección de una configuración de renderizado. Es la base de todos los frameworks de este hub.
- La guía para principiantes de SEO técnico — dónde encajan el renderizado del lado del cliente y el SEO de JavaScript en el panorama general.
Mis ponencias
- Cómo funciona la búsqueda (SlideShare) — mi recorrido por el rastreo, el renderizado, la indexación y la clasificación. (Se aplica mi descargo de responsabilidad permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa ni exacta».)
Desde la industria
- web.dev — Renderizado en la Web — la explicación canónica del equipo de Chrome sobre CSR frente a SSR, SSG e hidratación; el mejor modelo mental independiente del framework para la parte de estrategia de renderizado.
- Google Search Central — Conceptos básicos de JavaScript SEO — documentación oficial de fuente primaria sobre el proceso de rastreo → renderizado → indexación y los enlaces rastreables.
- Google Search Central — Solucionar problemas de JavaScript relacionados con la búsqueda — soft-404s después del enrutamiento del cliente y la History API, problemas con los que se encuentra todo router de una SPA.
- Lista de reproducción de JavaScript SEO de Martin Splitt — serie de vídeos oficial de Google sobre cómo gestiona las aplicaciones JS, independiente del framework.
- Hub de JavaScript SEO de Onely — artículos técnicos detallados sobre renderizado y auditoría de JS-SEO de una agencia especializada.
Registro de cambios
Actualizado el 8 ago 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Actualizado el 17 jul 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.