El noindex que viajó desde staging · Serpion 011

Me llegó el caso un martes por la mañana. Una tienda de suplementos deportivos que acababa de estrenar web nueva. Llevaban semanas preparando la migración: diseño revisado, catálogo reordenado, fichas de producto reescritas. Todo listo.

El día del lanzamiento salió bien, sin errores visibles, sin caídas de servidor, sin redirecciones rotas. pasaron los días y la web no aparecía en Google. No encontrábamos ninguna página indexada. Ni la home, ni el catálogo, ni las fichas que antes sí posicionaban. El equipo técnico revisó lo básico a nivel visual y de funcionamiento, y no encontró nada fuera de sitio.

Esto no me cuadraba. Si la estructura era nueva, si los contenidos estaban ahí y si el servidor respondía bien, la pista tenía que estar en otro sitio.

Lo que las señales decían sobre el noindex tras la migración

Lo primero que me llamó la atención fue eso: que no hubiera ni una URL indexada. No era una caída parcial ni un problema de visibilidad en ciertas secciones. Era todo. Como si Google hubiera decidido ignorar el sitio entero después de la migración. En casos así, las señales de exclusión suelen estar escondidas en algún punto del proceso, pero cuesta saber dónde si todo parece funcionar. Algo estaba diciéndole al buscador que no entrara, o que entrara y no se quedara.

Empecé por donde siempre: Google Search Console. La propiedad estaba verificada y el sitemap enviado. Hasta ahí, correcto. Pero el informe de Páginas de Search Console mostraba en su superficie: cero páginas indexadas. Todas las URLs del sitio aparecían bajo estados de exclusión. Las impresiones orgánicas llevaban semanas en cero. Ni un solo clic, ni una sola consulta registrada desde el día del lanzamiento.

Lo siguiente fue comprobar el sitemap. Había una hipótesis que tenía sentido: que las URLs declaradas en el sitemap siguieran apuntando al entorno de desarrollo, al subdominio de pruebas que usaron durante la fase de construcción. Si fuera así, Google estaría intentando rastrear direcciones que ya no existían o que no correspondían con la web en producción. Abrí el archivo XML y revisé las entradas una por una.

<url>
  <loc>https://www.ejemplo-suplementos.com/creatina-monohidrato</loc>
  <lastmod>2025-04-12</lastmod>
</url>
<url>
  <loc>https://www.ejemplo-suplementos.com/proteina-whey-isolate</loc>
  <lastmod>2025-04-12</lastmod>
</url>

Las URLs del sitemap eran correctas. Todas apuntaban al dominio de producción, con rutas limpias y fechas de modificación coherentes. Nada apuntaba al entorno de staging. Descarté esa línea. El sitemap no era el problema.

Volví a Search Console y miré con más detalle el estado de exclusión. La mayoría de URLs compartían el mismo motivo de rechazo. No era un error de servidor, no era un problema de redirección ni un soft 404. Era una exclusión activa, declarada desde el propio sitio. Google estaba procesando una instrucción que alguien —o algo— le había dado.

Dónde empezaba a aparecer la sombra del noindex en las señales

Aquí fue donde la investigación cambió de dirección. Lancé un rastreo con Screaming Frog contra el dominio de producción. De las 347 URLs rastreadas, todas devolvían código 200. El servidor respondía bien. Los tiempos de carga eran normales. El contenido se renderizaba. No había errores de acceso, ni bloqueos en el robots.txt, ni cadenas de redirección. Pero el rastreador detectó algo que encajaba con lo que Search Console estaba diciendo: cada una de esas páginas llevaba una directiva de exclusión en el HTML.

No se trataba de una o dos páginas sueltas. Eran todas. Desde la home hasta la última ficha de producto. Eso descartaba un error puntual o una configuración parcial. Era algo global, algo que se estaba aplicando a nivel de plantilla o de configuración del sistema.

La pista buena no estaba en lo que faltaba, sino en lo que sobraba. Google no estaba fallando. Estaba obedeciendo.

El pasajero que nadie revisó antes de salir a producción

Fui directamente al código fuente de la web en producción. Abrí la home, una página de categoría y dos fichas de producto. En las cuatro, dentro del <head>, encontré lo mismo:

<meta name="robots" content="noindex">

Ahí estaba. Una etiqueta noindex activa en cada página del sitio. No era un error de código ni una directiva parcial mal aplicada. Era una instrucción explícita y global que le decía a cualquier buscador: no indexéis nada de lo que encontréis aquí. Y Google la estaba teniendo en cuenta durante el proceso de indexación.

Cuando una web tiene un noindex en su HTML, el rastreador puede visitarla, leer su contenido y procesar sus enlaces, pero no la incluirá en el índice. Es como si la página existiera para el robot pero no para los resultados de búsqueda. No importa lo bueno que sea el contenido ni lo limpia que esté la estructura: si la señal dice que no se indexe, no se indexa.

Lo que había pasado era claro. Durante la fase de desarrollo, el equipo técnico configuró el entorno de staging con esa directiva para evitar que Google rastreara e indexara una versión incompleta del sitio. Es una práctica habitual y correcta. El problema fue que, al pasar la web a producción, nadie eliminó esa etiqueta. La directiva viajó desde staging hasta el dominio definitivo sin que nadie la detectara.

En Search Console, las páginas aparecían con el estado «Excluida por una etiqueta noindex». Todo encajaba. No era un fallo del servidor, ni un problema de DNS, ni una mala configuración del sitemap. Era una instrucción heredada de un entorno que ya no existía, pero cuya huella seguía marcando cada URL del proyecto.

Los bloqueos que más daño hacen no son los que fallan. Son los que funcionan exactamente como alguien los configuró, solo que el contexto ha cambiado y nadie se ha acordado de retirarlos.

Devolver la web al radar del buscador

Con el diagnóstico confirmado, la corrección técnica era directa: había que eliminar la etiqueta noindex de todas las páginas. Pero antes de tocar nada, necesitaba entender cómo se estaba inyectando esa directiva. Si era una línea hardcodeada en cada plantilla, había que editarlas una por una. Si venía de una configuración global del CMS o del sistema, bastaba con cambiar un ajuste.

Revisé la configuración interna del panel de administración y encontré una opción general de visibilidad. Estaba activada la casilla que pedía a los buscadores que no indexaran el sitio. Eso generaba la etiqueta noindex a nivel global, insertándola automáticamente en el <head> de cada página renderizada. Una sola casilla estaba manteniendo toda la web fuera del índice.

Desactivar la señal sin dejar cabos sueltos en el camino

La primera tentación era desmarcar esa opción y dar el caso por cerrado. Pero había un matiz que no podía ignorar. Si además de la configuración global existían directivas noindex puestas manualmente en plantillas específicas —como a veces ocurre en entornos de staging donde se refuerza el bloqueo por si acaso—, desactivar solo la opción general no iba a ser suficiente. Esas líneas manuales seguirían ahí, bloqueando páginas concretas sin que la configuración del panel lo reflejara.

Antes de ejecutar el cambio, volví al rastreo de Screaming Frog y filtré por la columna de directivas meta robots. Comprobé que las 347 URLs mostraban exactamente la misma etiqueta, sin variaciones. No había directivas diferentes en páginas sueltas ni cabeceras HTTP con X-Robots-Tag que pudieran añadir una capa adicional de bloqueo. La señal venía exclusivamente de la configuración global.

Desactivé la opción en el panel de administración. Refresqué la home, abrí el código fuente y confirmé que la etiqueta ya no aparecía. Repetí la comprobación en tres fichas de producto y en la página de categoría principal. Limpio en todos los casos. El noindex había desaparecido.

Después fui a Search Console. Usé la herramienta de inspección de URLs para solicitar la indexación de las páginas principales: la home, las categorías de producto más relevantes y las fichas con más potencial de búsqueda. No tenía sentido solicitar las 347 de golpe —Search Console limita las solicitudes de inspección—, así que arranqué por las que más urgían.

A los diez días, las primeras URLs empezaron a aparecer indexadas. A las tres semanas, la mayor parte del catálogo ya estaba disponible en los resultados de búsqueda. Los primeros clics empezaron a llegar por consultas de marca y de producto.

Una directiva heredada había mantenido toda la web invisible durante semanas. La corrección técnica fue sencilla, pero el daño ya estaba hecho: semanas de retraso en la indexación de un proyecto que debería haber empezado a captar tráfico desde el primer día. A veces, lo que más retrasa una migración no es lo que se construye de nuevo, sino lo que no se limpia del entorno anterior.