Noindex Bloquea la Ejecución de JavaScript en Google

Si el HTML inicial trae noindex, Google puede saltarse el render y no ejecutar JavaScript. No confíes en JS para quitar noindex. Mueve la lógica al servidor.

TL;DR

• Si Google ve noindex en el HTML o cabeceras de la primera respuesta, puede no renderizar y tu JS no corre.
• Quitar noindex con JS no es fiable. La página puede quedar fuera del índice.
• Si quieres indexar, no envíes noindex en la respuesta inicial. Maneja errores del lado servidor.
• Usa códigos HTTP apropiados (4xx/5xx) para estados de error; evita 200 + noindex temporal.
• Revisa también X‑Robots‑Tag en cabeceras: misma regla.
• Auditoría: HTML original → cabeceras → intención (indexar/no) → patrón correcto.

Qué cambió

• Google aclaró que, al encontrar noindex, puede omitir renderizado y ejecución de JS.
• Implementaciones que dependen de JS para remover noindex son frágiles: Googlebot podría no llegar a ese paso.
• Impacto directo en SPAs/SSR/ISR y sitios que condicionan indexación a eventos de cliente o APIs.

Idea clave: si existe la posibilidad de que la URL deba indexar, el HTML base nunca debe traer noindex.

Antipatrones que debemos evitar

• 200 OK + <meta name="robots" content="noindex"> y luego JS que la quita “si carga el contenido”.
• Colocar noindex por falta temporal de datos (falló una API) esperando que “en el próximo crawl” todo esté bien.
• Inyectar noindex desde A/B testing, consent managers o tag managers en cliente.
• Usar setTimeout/hydration para cambiar el <meta> de robots.
• Confiar en prerender del navegador para validar; Google puede comportarse distinto.

Patrones correctos (según intención)

Si la URL debe indexar

• Respuesta inicial sin noindex (ni en HTML ni en X‑Robots‑Tag).
• Renderiza contenido crítico en HTML base (SSR/SSG/ISR). El JS mejora, no “arregla”.
• Si no hay datos aún, muestra un estado vacío indexable (texto y enlaces válidos) o responde 503 si es una caída global.

Si la URL no debe indexar

• Devuelve 4xx/410 cuando el recurso ya no existe.
• Devuelve 403/401 para contenido detrás de login; evita puertas traseras con 200.
• Usa noindex permanente solo si la decisión es estable (p. ej., ambientes de prueba bloqueados por IP + noindex redundante).

Si la indexación depende de una condición de negocio

• Evalúa la condición en servidor y elige: 200 indexable o 4xx/5xx. No mezcles 200 + noindex temporal.

Dónde mirar en una auditoría

1. HTML original (URL Inspection → Ver HTML o curl): ¿hay <meta name="robots" content="noindex">?
2. Cabeceras HTTP: ¿hay X‑Robots‑Tag: noindex?
3. Framework (Next/Nuxt/Vue/React): ¿el noindex se inyecta en cliente?
4. Tag/Consent managers: ¿alguna etiqueta puede inyectar noindex?
5. Errores de datos: ¿APIs intermitentes disparan noindex?
6. Pruebas: ¿la URL se ve indexable en navegador, pero no en HTML original?

Ejemplos de implementación

HTML que bloquea (evitar)

<!-- Evitar: Google puede no renderizar ni ejecutar JS -->
<meta name="robots" content="noindex">
<script>
// Más tarde intentamos quitarlo...
document.querySelector('meta[name="robots"]').setAttribute('content','index,follow');
</script>

Node/Express: cabecera correcta según estado

app.get('/ficha/:id', async (req, res) => {
const data = await api.getFicha(req.params.id);
if (!data) {
return res.status(404).send('No encontrada');
}
// Página indexable: no enviar X‑Robots‑Tag noindex
res.set('X-Robots-Tag', 'index, follow');
res.render('ficha', { data });
});

Apache: bloquear ambientes de prueba

# En staging, bloquea por IP y refuerza con noindex (estable)
<RequireAll>
Require ip 10.0.0.0/8
</RequireAll>
Header set X-Robots-Tag "noindex, nofollow"

Next.js (SSR): decidir en servidor

export async function generateMetadata({ params }) {
const data = await getData(params.slug);
if (!data) {
return { robots: { index: false, follow: false } }; // No enviar HTML indexable
}
return { robots: { index: true, follow: true } };
}

Casos típicos y qué hacer

• Ecommerce: si una categoría queda vacía, responde 200 indexable con alternativas o 404 si ya no existe; nunca 200 + noindex provisional.
• Programmatic SEO: evita “publicar primero con noindex y luego quitarlo con JS”. Publica completo o usa cola de publicación.
• Internacional: noindex en páginas con hreflang rompe el conjunto; decide en servidor qué versiones existen.
• Portales/medios: si falla el feed, devuelve 503 temporal con Retry‑After.

Cómo testear correctamente

• Inspección de URL (GSC) → Ver HTML original y cobertura.
• Crawl con render (Screaming Frog/Sitebulb) + captura de HTML base vs DOM.
• Logs: confirma si Googlebot regresa a renderizar o se queda en el HTML inicial.
• Diff por plantilla: identifica si el patrón de noindex viene de una o dos plantillas.

FAQ rápidas

¿Puedo usar JavaScript para cambiar noindex?
No es fiable. Si Google decide no renderizar, tu JS no corre.

¿Y si necesito ocultar la página hasta que haya datos?
Decide en servidor: 404/204/503. No envíes 200 + noindex temporal esperando “arreglo” por JS.

¿Sirve noindex en X‑Robots‑Tag?
Sí, pero aplica la misma regla: si lo ve en la primera respuesta, puede no renderizar.

¿Cómo manejo entornos de staging?
Restringe por IP/Auth y, si quieres, añade noindex estable. Nunca dependas de JS para activarlo/desactivarlo.

¿Cómo explico esto a negocio?
noindex en la primera respuesta equivale a un “no procesar”. Si hay posibilidad de indexar, no lo envíes.

¿Lo vemos en tu sitio?

• Podemos auditar en 48h: cobertura, cabeceras, plantillas y logs.
• Empieza aquí: Consultoría SEO · Servicios SEO · Experto en SEO Perú.