Idiomas

Redirecciones JavaScript

Qué es una redirección JavaScript, cómo el pipeline de renderizado de Google la trata de manera diferente a un 301 del lado del servidor, cuándo es un último recurso aceptable, y cómo implementarla y detectarla — además de dónde encajan el meta refresh y la API History.

Publicado por primera vez: 27 jun 2026 · Última actualización: 11 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2
1 señal de evidencia en esta página

Una redirección JavaScript envía a usuarios y rastreadores a una nueva URL con código del lado del cliente (window.location.replace() o .href). Es el tipo de redirección menos confiable porque Google solo la ve después del renderizado, que puede retrasarse o fallar por completo, sin un cronograma fijo en ningún caso. El orden oficial de preferencia de Google es del lado del servidor (301/302/307/308) → meta refresh → JavaScript, y sus documentos dicen claramente: solo use redirecciones JS si no puede hacer las otras dos. Una vez que Google la interpreta correctamente, el destino se convierte en una señal de canonicalización, pero eso no es una garantía comprobada de resultados idénticos de PageRank o clasificación en comparación con un 301, así que trátela como un último recurso en lugar de un reemplazo equivalente. Úselas en plataformas restringidas sin acceso al servidor, para páginas de error SPA que apunten a un 404 real, y poco más. Si debe usar una, use window.location.replace() en el <head>, elimine la URL de origen de su sitemap y apunte los enlaces internos al destino final. El meta refresh es una redirección separada a nivel de HTML, y history.pushState()/replaceState() no son redirecciones en absoluto.

TL;DR — Una redirección de JavaScript es una redirección del lado del cliente (window.location.replace(), .href, .assign()) que Google solo procesa después del renderizado — fase tres de rastreo → renderizado → indexación. Una 301 del lado del servidor se ve en el momento del rastreo; una redirección de JS espera en la cola de renderizado, y Google no da un plazo fijo para esa espera — puede ser rápida o puede tardar mucho, y el renderizado puede fallar por completo. El orden de preferencia documentado por Google es del lado del servidor → meta refresh → JavaScript, y los documentos dicen que se deben usar redirecciones de JS solo cuando no se pueden hacer las otras dos. Una vez que Google las interpreta correctamente, el destino se convierte en una señal de canonicalización permanente — incluso Google las usó en su propio blog cuando nada más funcionó — pero eso no es prueba documentada de resultados idénticos de PageRank o posicionamiento en comparación con una 301, por lo que son un último recurso, no una señal de spam. Los usos legítimos son plataformas restringidas sin configuración de servidor y páginas de error de SPA que apuntan a un 404 real. Implementa con window.location.replace() en el <head>, elimina la fuente de tu sitemap, reorienta los enlaces internos y confirma que Googlebot puede obtener el JS. El meta refresh es a nivel de HTML (0s = permanente, cualquier retraso = temporal), y history.pushState()/replaceState() no son redirecciones en absoluto.

Qué cuenta como redirección de JavaScript

La navegación por script depende del renderizado y la ejecución, por lo que no es equivalente a nivel de protocolo que una redirección HTTP. 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 redirects El procesamiento es posible, no una garantía de tiempo exacto o 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: Redirects and Search

Una redirección de JavaScript navega el navegador a una nueva URL con código del lado del cliente. Los métodos comunes y cómo difieren:

  • window.location.replace("url") — navega y elimina la URL original del historial de sesión. Este es el que se debe usar: el botón de atrás omite la fuente de la redirección en lugar de devolver al usuario directamente.
  • window.location.href = "url" — navega pero mantiene la original en el historial, por lo que el botón de atrás regresa a la página que redirige (y puede crear un bucle). document.location.href y window.location.assign("url") se comportan de la misma manera.
  • history.pushState() / history.replaceState() — no son redirecciones. Reescriben la barra de direcciones sin ninguna navegación o señal HTTP, por lo que los rastreadores no las tratan como redirecciones. Las SPA las usan para cambios de URL dentro de la aplicación; necesitan enlaces <a href> reales (o navegaciones reales) para ser rastreables.

La línea divisoria que importa: .replace(), .href y .assign() todos desencadenan una navegación real del documento (la diferencia entre ellos es solo lo que sucede con el historial de sesión), mientras que pushState()/replaceState() nunca navegan en absoluto — tocan el estado del historial y la barra de direcciones y nada más. Ninguno de los cuatro es un 301 HTTP; “redirección” aquí es una abreviatura de navegación del lado del cliente, no un código de estado.

Meta refresh (<meta http-equiv="refresh" content="0;url=...">) a menudo se agrupa con las redirecciones de JS, pero es una directiva HTML que se analiza antes de que JavaScript se ejecute — una categoría separada y más confiable, cubierta a continuación.

Cómo procesa Google una redirección de JavaScript

Este es el punto clave. El proceso de Google funciona por etapas, y una redirección de JS y una redirección del lado del servidor se detectan en diferentes momentos:

  1. Rastreo — Googlebot obtiene la URL y lee el HTML sin procesar. Una 301/302/307/308 del lado del servidor se ve aquí mismo.
  2. Cola de renderizado — las páginas que devuelven 200 esperan para ser renderizadas. Los documentos de Google señalan que la página “may stay on this queue for a few seconds, but it can take longer than that.” (traducción) «puede permanecer en esta cola durante unos segundos, pero puede tardar más que eso.» Google no publica un plazo de nivel de servicio fijo más allá de eso, así que trata la espera como impredecible — puede ser rápida, o puede alargarse — en lugar de asumir un número específico de días o semanas.
  3. Renderizado + indexación — Chromium sin interfaz gráfica ejecuta el JavaScript. Este es el primer momento en que existe una redirección de JS en lo que respecta a Google.

La misma idea que planteo en Rastreo y en SEO de JavaScript se aplica aquí: el renderizado es un paso separado de la obtención, y cualquier cosa que dependa de él hereda ese retraso y ese riesgo.

Y el riesgo es real. Google: “While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (traducción) «Aunque Google intenta renderizar cada URL que Googlebot rastreó, el renderizado puede fallar por varias razones. Esto significa que si configuras una redirección de JavaScript, Google podría nunca verla si el renderizado del contenido falló.» (Google Search Central) Durante la ventana antes de que se procese la redirección — y para siempre, si el renderizado falla — Google puede mantener la página fuente vacía en su índice.

El orden de preferencia oficial de Google

La documentación de redirecciones establece una jerarquía de la más a la menos confiable:

  1. Redirecciones del lado del servidor — 301/308 (permanentes), 302/307 (temporales). Las mejores para todo: se ven en el momento del rastreo, sin ambigüedad.
  2. Meta refresh — a nivel de HTML. Un meta refresh de 0 segundos se trata como una redirección permanente (como un 301); cualquier meta refresh retrasado se trata como temporal.
  3. Redirecciones de JavaScript — último recurso.

Google lo expresa así: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (traducción) «Usa redirecciones de JavaScript solo si no puedes hacer redirecciones del lado del servidor o mediante actualización meta». Las redirecciones permanentes pasan al destino la señal que indica cuál es la URL principal; las temporales mantienen la original en los resultados. (La interacción con la elección de la URL principal se explica en Elección de URL principal).

¿La equidad de enlaces se transmite?

La documentación de redirecciones de Google enumera la navegación de ubicación de JavaScript entre sus métodos de redirección permanente, y dice que el destino se convierte en la señal de canonicalización una vez que Google lo ha interpretado — por lo que la afirmación plana “JS redirects don’t pass PageRank” (traducción) «las redirecciones JS no transmiten PageRank» es falsa. Lo que la documentación no establece es que el resultado sea idéntico, inmediato o tan confiable como un 301 del lado del servidor — describe la señal canónica, no una garantía de un flujo de PageRank equivalente, clasificación o sincronización. El marco honesto: un 301 transmite la señal en el momento del rastreo con casi certeza; una redirección JS la transmite solo si y cuando el renderizado tiene éxito, y Google no promete que el resultado coincida uno a uno con el de un 301. Esa brecha — no la equidad perdida — es el costo real de elegir JavaScript.

Esto también es por lo que las redirecciones JS no son un desencadenante de penalización por sí solas. Solo se convierten en un problema de spam cuando se usan para cloaking — mostrar a los rastreadores una página y redirigir a los usuarios a algo diferente, o enviar a usuarios móviles a un dominio no relacionado. La política de redirecciones engañosas de Google trata sobre esa intención, no sobre la técnica.

Cuándo una redirección de JavaScript es la herramienta adecuada

Hay casos legítimos:

  • Plataformas limitadas. Algunos alojamientos compartidos, CDN o configuraciones de CMS no te dan acceso a reglas de redirección del lado del servidor. Una redirección JS es un respaldo válido — y notablemente, Google usó redirecciones JS en su propio blog de Webmaster porque, como dijo Gary Illyes, “that was the only thing we could use for 1:1 redirects, and it works on Google” (traducción) «eso era lo único que podíamos usar para redirecciones 1:1, y funciona en Google» (OnCrawl).
  • Manejo de errores en SPA. Google lo respalda explícitamente: “Use a JavaScript redirect to a URL for which the server responds with a 404 HTTP status code.” (traducción) «Usa una redirección de JavaScript a una URL para la que el servidor responda con un código de estado HTTP 404.» (Google Search Central) Una aplicación de una sola página que resuelve una ruta incorrecta puede redirigir a un endpoint 404 real para que Google procese el error correctamente en lugar de indexar un 404 blando.

Para migraciones de URL permanentes, esta no es la herramienta — usa un 301. Hago el mismo punto en migraciones de sitios: las redirecciones de JavaScript son un último recurso, y Google puede que nunca las vea.

Generadores de sitios estáticos: la trampa de los alias de Hugo

Una sorpresa común: el aliases: del frontmatter de Hugo históricamente ha generado páginas HTML de meta refresh, no redirecciones 301 del lado del servidor — y otros generadores estáticos han hecho cosas similares por defecto. Los valores predeterminados de los generadores cambian entre versiones, así que verifica la salida real de tu versión desplegada actual en lugar de asumir; si aliases: no te está dando 301, necesitas reglas de redirección a nivel de plataforma (_redirects de Netlify, Cloudflare Workers, vercel.json de Vercel) además de (en Hugo) disableAliases: true. Cubro esto en detalle en SEO para Hugo.

Mejores prácticas de implementación

Si una redirección de JavaScript es genuinamente tu única opción:

  • Usa window.location.replace(), no .href. Como dice Search Engine Journal, las redirecciones de JS “typically use window.location.replace() function rather than window.location.href to avoid UX redirect loops” (traducción) «normalmente usan la función window.location.replace() en lugar de window.location.href para evitar bucles de redirección en la experiencia de usuario» (SEJ).
  • Ponlo en el <head>, no en el <body>. Los navegadores analizan el HTML secuencialmente y ejecutan los scripts a medida que los encuentran, así que “position JavaScript redirects in the <head> tag rather than <body> to minimize delay” (traducción) «coloca las redirecciones de JavaScript en la etiqueta <head> en lugar de en el <body> para minimizar el retraso» (OnCrawl).
  • Redirige al destino final en un solo salto. Una redirección de JS a una página que a su vez hace un 301 a otro lugar crea una cadena; las cadenas desperdician el presupuesto de rastreo y pueden aparecer en GSC como un error de redirección.
  • Elimina la URL de origen de tu sitemap.xml. Los sitemaps deben listar URLs canónicas e indexables, no las que redirigen.
  • Reapunta los enlaces internos al destino, para que no pasen por la redirección en absoluto.
  • Asegúrate de que Googlebot pueda obtener el JS. Si la redirección vive en un script externo bloqueado por robots.txt, Google no puede renderizarlo y no verá la redirección.

Cómo detectar redirecciones de JavaScript

No se anuncian como un 301 en un encabezado, así que tienes que renderizar:

  • Un rastreador con renderizado de JS activado. OnCrawl recomienda rastrear con “JavaScript rendering enabled (5-second timeout minimum)” (traducción) «renderizado de JavaScript habilitado (tiempo de espera mínimo de 5 segundos)»; Screaming Frog y Ahrefs Site Audit pueden renderizar ambos. Sin renderizado, una página con redirección de JS simplemente parece un 200 normal.
  • Chrome DevTools. La pestaña Network (con “Preserve log”) muestra la navegación del lado del cliente; la extensión Redirect Path también lo marca.
  • En Search Console, una redirección de JS procesada con éxito aparece en Página con redirección — el mismo estado que cualquier URL redirigida, lo cual es normal para fuentes no canónicas. Sin embargo, esa etiqueta no está garantizada en ninguna comprobación dada: refleja lo que Google obtuvo, renderizó, interpretó y canonizó en el momento muestreado, así que una URL puede mostrar un estado diferente (o ningún estado de redirección todavía) entre comprobaciones sin que eso sea un error de tu parte.

Lo que yo haría realmente

Del lado del servidor primero, siempre. Meta refresh (0 segundos) cuando puedas editar el HTML pero no la configuración del servidor. JavaScript solo cuando ambas opciones estén descartadas — y entonces con window.location.replace() en el <head>, un sitemap limpio y una comprobación de que la redirección realmente se renderiza para Googlebot. Para cualquier cosa permanente o de alto valor, la fiabilidad adicional de un 301 vale casi cualquier esfuerzo para obtenerla.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.