SEO técnico para sitios JavaScript: rastreo, renderizado e indexación

Lectura ejecutiva

Conclusiones principales

• El contenido crítico debe estar disponible sin interacción obligatoria.
• Los enlaces necesitan un elemento a con href resoluble.
• Estado, canonical y robots deben ser coherentes en el HTML inicial.
• Prueba origen, DOM renderizado e inspección del buscador.

Las aplicaciones JavaScript pueden aparecer en buscadores, pero el camino entre URL y contenido tiene más puntos de fallo. El crawler debe acceder, recibir una respuesta adecuada, descubrir recursos, ejecutar código cuando sea necesario, construir contenido y evaluar la versión renderizada.

La guía de JavaScript SEO de Google describe rastreo, renderizado e indexación. Google usa Chromium, pero el renderizado puede entrar en una cola, los recursos bloqueados pueden impedir contenido y otros bots tienen capacidades diferentes.

Entiende qué llega en el HTML inicial

Inspecciona la respuesta sin ejecutar JavaScript:

• title y meta description;
• canonical y robots;
• h1 y contenido principal;
• enlaces internos;
• datos estructurados;
• información de producto o artículo;
• estados de error;
• hreflang cuando corresponda.

Si el HTML contiene solo un contenedor vacío y scripts, toda comprensión depende del renderizado. Puede funcionar para Google, pero aumenta complejidad, tiempo y diferencias entre crawlers.

Renderizado en servidor, generación estática o un enfoque híbrido hacen que el contenido crítico esté disponible antes.

Usa URLs reales para cada contenido

Cada página descubrible necesita una URL estable y compartible. Filtros, pestañas y estados solo necesitan URL propia cuando representan contenido útil e indexable.

Evita cargar páginas distintas solo con fragmentos como #/producto. Usa History API para el enrutamiento cliente y mantén el servidor capaz de responder directamente a cada URL.

Prueba acceso directo, actualización, compartir y navegación sin depender de una sesión anterior.

Crea enlaces rastreables

El patrón más confiable es:

<a href="/es/blog/core-web-vitals-campo-laboratorio">Datos de campo y laboratorio</a>

Un div con onClick, un botón que cambia la ruta o un enlace sin href puede funcionar para una persona y fallar en descubrimiento, teclado o apertura en nueva pestaña.

Usa botón para acción y enlace para navegación. Garantiza que el destino exista en el HTML renderizado sin necesitar scroll o clic.

Devuelve estados HTTP significativos

Las SPA a veces devuelven 200 para todas las rutas, incluso productos eliminados y errores. Esto crea soft 404.

El servidor debe devolver 200 para contenido disponible, redirecciones adecuadas, 404 para recursos inexistentes, 410 para eliminación permanente intencional, códigos de acceso para contenido restringido y 5xx para fallos reales.

Un mensaje “no encontrado” dentro de una respuesta 200 no sustituye el estado.

Define metadata estable

Title, description, canonical y robots deben representar la URL actual. En navegación cliente, confirma que se actualicen y no hereden valores anteriores.

La canonical debe ser absoluta y coherente entre HTML inicial, renderizado, sitemap y enlaces. No la uses como solución universal para paginación o filtros.

Evita comenzar con noindex y retirarlo por JavaScript. Google advierte que puede omitir el renderizado después de encontrar noindex.

No escondas contenido detrás de interacción

Google no desplaza ni hace clic como una persona. Lazy-loading debe cargar al entrar en el viewport, no solo después de un botón o gesto.

Contenido principal, productos y enlaces no deben depender exclusivamente de scroll infinito sin URLs, “cargar más” sin enlaces alternativos, hover, gesto de carrusel o API llamada solo tras una interacción.

La guía de lazy-loading de Google recomienda implementaciones sin acciones del usuario para exponer contenido relevante.

Trata renderizado y rendimiento juntos

Enviar todo por el cliente aumenta red y CPU. Aunque el crawler ejecute el código, usuarios pueden sufrir LCP lento e INP alto.

Pregunta por componente si necesita interactividad, si puede renderizarse en servidor, cargarse después, evitar hidratación, si está en el camino crítico o depende de terceros.

Server Components, islas de interactividad y generación estática reducen JavaScript. La arquitectura debe responder a datos, personalización y experiencia.

Mantén contenido consistente

El contenido del crawler debe corresponder al del usuario. Diferencias legítimas por dispositivo, ubicación o login deben preservar la intención.

Evita contenido completo en servidor que desaparece después de hidratar, títulos divergentes, canonical cambiada por el cliente, errores de API que eliminan contenido, skeleton permanente y datos estructurados sobre información ausente.

Los problemas de hidratación pueden dejar correcto el HTML inicial y romper la interfaz final. Inspecciona ambas capas.

Prueba origen y renderizado

1. solicita la URL y registra estado y HTML;
2. desactiva JavaScript como diagnóstico;
3. renderiza en navegador limpio;
4. compara contenido, enlaces, metadata y schema;
5. revisa consola y red;
6. prueba mobile y desktop;
7. usa inspección de URL y HTML renderizado;
8. valida páginas correctas, vacías, eliminadas y con error de API.

Una captura no prueba que los enlaces sean rastreables. Un HTML correcto no prueba que la hidratación preservó el contenido.

Monitorea deploys y regresiones

Cambios de framework, rutas, middleware y consentimiento pueden afectar todo el sitio. Automatiza estado, title, canonical, robots, h1, contenido, enlaces, schema, errores de hidratación y sitemap para templates críticos.

Integra la checklist de lanzamiento y prueba la URL publicada.

Observación: categorías devuelven un shell vacío; productos y enlaces aparecen solo después de una API cliente. Si falla, la respuesta sigue en 200 y sin contenido. Acción: renderizar título, descripción, primera página de productos y paginación en servidor; devolver error adecuado cuando no haya datos. Aceptación: contenido y enlaces existen en el HTML inicial, la navegación cliente funciona y los errores usan estados coherentes.

SEO para JavaScript no exige abandonar aplicaciones modernas. Exige reducir dependencias innecesarias, usar patrones de la plataforma y verificar lo que cada agente recibe.

Respuestas directas

Preguntas frecuentes

¿Google ejecuta JavaScript?

Sí. La documentación de Google describe fases de rastreo, renderizado e indexación con Chromium. Aun existen colas y limitaciones, y otros bots pueden no ejecutar la aplicación.

¿SSR garantiza SEO?

No. SSR mejora disponibilidad inicial, pero URLs, canonical, estados, enlaces, contenido y calidad siguen necesitando implementación correcta.

¿Puedo definir canonical con JavaScript?

Google puede procesarla, pero recomienda consistencia y prefiere definirla en HTML cuando sea posible.