SEO para JavaScript: asegúrate de que los enlaces sobrevivan al renderizado

Google renderiza JavaScript con un Chromium de última generación. El problema rara vez es el renderizado en sí. Suelen ser enlaces que nunca se convierten en anclajes, y páginas que dependen de un estado que el crawler no tiene.

Equipo de investigación de ArchiLinks · Actualizado 2026-10-29

Un puente que conecta cimientos de piedra con estructuras de vidrio representando la supervivencia de los enlaces

Lo que ve un crawler

Googlebot utiliza un Chromium de última generación desde mayo de 2019. Esto resolvió la duda sobre si puede ejecutar JavaScript moderno.

Los riesgos prácticos son más antiguos: el renderizado ocurre después del rastreo y puede retrasarse, el contenido detrás de clics o inicios de sesión nunca aparece, y un enlace creado desde un manejador onclick en un div no es un enlace. Antes de verificar backlinks en páginas web que has movido recientemente a un front end en React, confirma que esas páginas muestren su contenido en la respuesta cruda o en el HTML renderizado.

SSR, SSG, CSR: qué cambia para los enlaces

Enfoque	Contenido en la primera respuesta	Enlaces internos como anclajes	Adecuado para
SSR (Next.js, Nuxt)	Sí	Sí, si usas anclajes reales	Páginas públicas con datos cambiantes
SSG o prerenderizado	Sí	Sí	Documentación, blogs, páginas de marketing
Aplicación de una sola página (SPA) en CSR	No, estructura vacía	Solo después de renderizar	Paneles de control detrás de un inicio de sesión
Híbrido (SSR para la página principal, CSR para la aplicación)	Por ruta	Por ruta	La mayoría de los productos con una parte pública

Prueba uno: HTML sin procesar frente a HTML renderizado

Si los enlaces clave aparecen en la primera respuesta, la cuestión queda resuelta. Si no, compara con un renderizado headless.

bash

# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20

# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '

Un jardinero inspeccionando raíces de árboles representando las verificaciones de salud de backlinks externos

Donde entran los enlaces externos

Un error de renderizado oculta tu contenido. No borra los enlaces que otros sitios ya te han dado.

Tras una migración a Next.js, Vite o un CMS headless, ejecuta toppages para el host y prueba los 20 URLs más enlazados para verificar su estado, canonical y contenido visible. Hazlo primero. Si una página con 40 dominios enlazantes devuelve una estructura vacía o un 404 del lado del cliente, corrígelo antes que nada, porque ahí es donde llega tu autoridad. La página de equidad entre enlaces internos y externos muestra cómo comparar esa lista con tus enlaces internos, y la lista de verificación de migración integra la prueba dentro de un plan de lanzamiento.

Los frameworks importan menos que la disciplina. Express con un motor de plantillas, un tema de WordPress y un enrutador de aplicaciones de Next.js pueden servir enlaces rastreables. Todos también pueden fallar si un equipo despliega anclas que solo existen después de un clic.

Lista de verificación de enlaces y renderizado

La navegación y la paginación utilizan <a href>, no manejadores de clic en otros elementos.
Cada ruta devuelve un código de estado real. Las pantallas de 404 suaves deben devolver 404.
Un noindex o canonical inyectado por JavaScript coincide con el de la respuesta del servidor.
El contenido de respaldo en la primera respuesta es la página real, no un spinner que Google pueda indexar.
El código de autenticación no redirige a los rastreadores en rutas públicas.
Los archivos CSS y JS necesarios para el renderizado no están bloqueados en robots.txt.
La carga diferida utiliza IntersectionObserver o atributos de carga nativos, no eventos de desplazamiento.

Lectura de las evidencias de Search Console

Search Console responde a la mayoría de las preguntas sobre renderizado si consultas el informe adecuado. Utiliza Inspección de URL y luego Ver página rastreada.

Compara tres cosas: el HTML que Google obtuvo, la captura de pantalla y los recursos de la página que no se cargaron. Una página que parece completa en tu navegador pero vacía en la captura de pantalla suele estar bloqueada por un error de script o un recurso no permitido, y la solución está en tu compilación, no en tu contenido.

Recuerda el retraso. Un cambio que publiques hoy aparecerá en la herramienta de inspección solo después de que Google vuelva a rastrear la URL, lo cual puede tardar días.

Cuándo vale la pena el SSR

Páginas públicas que deben posicionar: sí. Dashboards: no.

Si una ruta debe atraer tráfico orgánico, sirve el contenido en la primera respuesta. Si está detrás de un inicio de sesión, evita la complejidad. Elige por ruta y no por proyecto, y documenta la decisión para que el siguiente desarrollador no la deshaga.

Usa la prueba de Resultados enriquecidos y la Inspección de URL para comparar la salida renderizada.
Prueba con la prueba en vivo de Search Console después de cada actualización del framework.

Dos casas en una colina mostrando renderizado prerrenderizado versus del lado del cliente

¿Se requiere renderizado en el servidor, o es suficiente con el prerenderizado?

El renderizado en el servidor es opcional. Es una forma de hacer que la primera respuesta contenga lo que necesita un crawler. Muchos sitios públicos lo logran con prerenderizado, una compilación estática o un renderizado en el servidor para las páginas que importan, y dejan las partes con inicio de sesión sin tocar.

Digamos que las páginas de productos y la documentación son públicas, mientras que el dashboard está detrás de un inicio de sesión. Prerrenderiza el primer grupo. Deja el dashboard del lado del cliente. Las páginas públicas entonces llevan sus enlaces en la primera respuesta, y el dashboard puede mantenerse tan complejo como sea necesario.

Prerrenderizar solo la página de inicio

Prerrenderizar la página de inicio resuelve el primer rastreo, pero deja que cada otra ruta espere al navegador. Si la página de inicio enlaza a categorías renderizadas en el cliente, los enlaces en esas páginas aún dependen de que se rendericen. Revisa cada plantilla que poseas, no solo la página principal.

Mantén una lista breve de rutas públicas con su método de renderizado. La lista mostrará las lagunas más rápido que un informe de rastreo.

¿El renderizado en el servidor cambia la visibilidad local?

El renderizado en el servidor puede cambiar la rapidez con la que aparece el primer contenido, y los lectores lo notan. No hace que una página sea relevante para una consulta local por sí sola. Esas señales provienen del contenido de la página, los detalles del negocio y los enlaces que apuntan hacia ella.

Trata el renderizado como la forma en que esas señales se vuelven legibles para un crawler, y mide los enlaces por separado con la API.

Aplicaciones Vite y React que sirven una sola estructura

Una compilación de Vite que sirve una única estructura HTML para cada ruta carga todo el trabajo en el cliente. Una aplicación así aún puede posicionar para algunas consultas, pero cada ruta pública necesita un plan: prerrenderizarla, renderizarla en el servidor o aceptar la pérdida y anotar esa decisión.

Antes de verificar los backlinks en las rutas del sitio después de una recompilación, decide cómo obtiene su contenido cada ruta pública. De lo contrario, los datos de enlaces mostrarán enlaces externos que apuntan a páginas vacías.

Probar si una ruta muestra sus enlaces

Dos pruebas responden a la mayoría de las preguntas. La respuesta cruda muestra lo que obtiene un crawler antes de que se ejecuten los scripts. El DOM renderizado muestra lo que construye un navegador después. Un enlace que aparece solo en el segundo caso sigue siendo un enlace, pero depende de que la renderización funcione correctamente.

Leer la prueba en vivo en Search Console

Ejecuta la prueba en vivo desde la Inspección de URL en una ruta a la vez. Observa el HTML renderizado y luego la lista de recursos que fallaron al cargarse. Un script bloqueado puede eliminar todo un bloque de navegación, y la página parece escuálida sin mostrar ningún error visible.

Repite la prueba después de una actualización del framework, porque un nuevo valor predeterminado puede cambiar si los enlaces se renderizan antes o después de que se ejecute un script. La guía de páginas no indexadas cubre qué hacer cuando una página renderizada sigue sin indexarse.

Cuando una ruta se renderiza pero el contenido es un indicador de carga

El contenido alternativo en la primera respuesta es más importante de lo que la mayoría de los equipos espera. Un indicador de carga o un contenedor vacío significa que la página no contiene texto para el crawler en ese momento. Coloca el título, la introducción y los enlaces principales en la primera respuesta, incluso si una lista detallada se carga más tarde.

Un contenido alternativo que sea la página real puede ser simple. Su única función es contener el contenido hasta que llegue el resto.

Mover un sitio del lado del cliente sin perder sus enlaces

Lista las rutas con enlaces externos

Ejecuta toppages para el host y anota las 50 URL principales. Prueba esas rutas primero, antes de los cambios de código, para saber qué debe conservar la recompilación.

Compara la salida cruda y la renderizada

Para cada ruta, verifica el HTML crudo y el DOM renderizado en la compilación antigua y la nueva. Anota cualquier enlace que exista en uno pero no en el otro.

Reemplaza los controladores de clic con anclas

Convierte la navegación en anclas reales con una dirección adecuada. El trabajo de velocidad puede esperar un sprint, mientras que una ancla faltante cuesta a la ruta su camino dentro del sitio.

Repite la prueba después del lanzamiento

Una semana después del lanzamiento, ejecuta la prueba en vivo en las mismas rutas y compara los resultados con los anteriores. Las diferencias muestran dónde la recompilación cambió la salida.

Códigos de estado y redirecciones en una aplicación del lado del cliente

Una aplicación de una sola página a menudo muestra una pantalla de no encontrado mientras el servidor devuelve el estado 200. Google puede tratar tal página como un 404 suave, y los enlaces externos que apuntan a la URL faltante entonces aportan poco. La solución corresponde al servidor.

Rutas desconocidas que aún devuelven 200

Devuelve un 404 real desde el servidor para cualquier ruta que no exista, y mantén la pantalla de no encontrado de la aplicación para los visitantes que llegan mediante una ruta del lado del cliente. Donde exista una reemplazo, envía un 301 en su lugar.

Verifica algunas direcciones inventadas en el host en vivo después de cada lanzamiento. El código de respuesta es lo que debes leer, no la página que ves en el navegador.

Redirecciones que se ejecutan en el navegador

Una redirección que se activa después de que la página se carga, por ejemplo, al leer un parámetro de URL dentro de un componente, es diferente de una redirección del servidor. Un crawler puede indexar la primera respuesta antes de que se ejecute la redirección. Donde una ruta se haya movido permanentemente, devuelve un 301 desde el servidor y conserva los parámetros que cambian el contenido. La receta del mapa de redirecciones muestra cómo probar esas reglas.