Cómo detectar un noindex antes de que arruine tu posicionamiento

Para detectar un noindex en producción tienes que revisar tanto el HTML como las cabeceras HTTP de las páginas importantes, y montar algo que las compare de un día para otro. Un noindex que se cuela no genera ningún error: la página carga, el checkout funciona y Google va sacando la URL de su índice a medida que vuelve a rastrearla.

La etiqueta tiene usos legítimos en páginas de agradecimiento, resultados de búsqueda interna y entornos de staging. El daño empieza cuando cae en una página que necesitas que posicione y se queda ahí semanas antes de que alguien mire.

De dónde suelen salir los noindex en producción

La mayoría son ajustes de staging que se han mudado. Los entornos de staging se mantienen fuera de Google con una meta etiqueta robots o una cabecera, y un deploy que copia configuración, variables de entorno o un volcado de la base de datos arrastra ese ajuste. En WordPress el sospechoso habitual es la casilla "Disuadir a los motores de búsqueda de indexar este sitio" en Ajustes > Lectura, marcada en staging y restaurada en producción junto con la base de datos.

Después vienen los plugins SEO. Tanto Yoast como Rank Math permiten poner en noindex un tipo de contenido o una taxonomía entera desde sus pantallas de ajustes. En Yoast es el interruptor "Mostrar [tipo de contenido] en los resultados de búsqueda", así que un solo clic o un restablecimiento de ajustes afecta a cientos de URLs a la vez.

Y luego están las cabeceras. X-Robots-Tag: noindex se puede añadir con una directiva add_header de Nginx, una regla en el .htaccess de Apache o la configuración de una CDN, y nada de eso aparece en el código fuente de la página. Un desarrollador que oculta una sección nueva mientras la construye y se olvida de la regla en el lanzamiento crea justo este tipo de noindex invisible.

Comprobar a mano si una página tiene noindex

Cuando sospeches de una URL concreta, sigue estos pasos en orden. Cada uno detecta algo que el anterior puede pasar por alto.

1. Descarga las cabeceras: curl -sI https://example.com/page/ | grep -i x-robots-tag. Cualquier línea que contenga noindex significa que la cabecera está activa, diga lo que diga el HTML.
2. Busca en el HTML servido: curl -s https://example.com/page/ | grep -i 'name="robots"'. Busca también name="googlebot", que se aplica solo a Google.
3. Si el sitio se renderiza con JavaScript, abre la herramienta Inspección de URLs de Search Console, pulsa "Probar URL publicada" y después "Ver página probada" para ver el HTML que recibe Google. La documentación de Google advierte que, cuando el HTML inicial contiene noindex, Googlebot puede saltarse el renderizado, así que un script que quite la etiqueta después no sirve de nada.
4. En el mismo resultado de inspección, "¿Se permite la indexación?" te dice si el bloqueo viene de la meta etiqueta robots o de la cabecera HTTP X-Robots-Tag.
5. Para revisar el sitio entero, rastréalo con Screaming Frog y usa el filtro Noindex de la pestaña Directives.

El informe Indexación de páginas de Search Console también agrupa URLs bajo "Excluida por la etiqueta 'noindex'". Es la fuente fiable, pero solo se actualiza cuando Google vuelve a rastrear, así que describe la semana pasada y no el día de hoy.

Frenarlo en el momento del deploy

Si controlas el pipeline de despliegue, una comprobación después de cada release a producción cuesta muy poco. Un paso de CI que ejecute los dos comandos curl de arriba contra la home y unas cuantas plantillas clave, y que haga fallar el job si alguno encuentra noindex, bloquea la fuga de staging más habitual.

No detectará un ajuste de plugin cambiado en wp-admin un martes por la tarde, ni una regla de cabecera añadida en el panel de la CDN. Ninguna de las dos cosas pasa por el pipeline.

Monitorizar los cambios que nadie despliega

Las comprobaciones manuales responden a "¿esta página tiene noindex ahora mismo?". La monitorización responde a "¿alguna página ha pasado a noindex desde ayer?", que es la pregunta que importa en sitios de clientes donde los cambios los hacen personas y sistemas que no controlas.

Deltio lee a diario las páginas del sitemap de cada sitio y registra el estado de noindex tanto en la meta etiqueta como en la cabecera X-Robots-Tag. Cuando una página que era indexable en la comprobación anterior aparece con noindex en la actual, envía una alerta por Slack y email para ese sitio con las URLs afectadas. Al ser diario, te avisa en menos de un día y no en minutos, lo que en la mayoría de los casos sigue siendo antes de que Google haya vuelto a rastrear y retirado la página. La misma comparación cubre ediciones del robots.txt, cambios de canonical y URLs que salen del sitemap. Si quieres el contexto sobre la etiqueta en sí, lee la etiqueta noindex, explicada.

Puedes probarlo en los sitios de tus clientes con una prueba gratuita de 14 días.