Por qué Google desindexa páginas (y cómo diagnosticarlo con un rastreo)
La curva de tráfico de la última semana parece un acantilado. Páginas que ayer rankeaban han desaparecido. site:tudominio.com en Google devuelve una fracción de lo que solía. No has cambiado nada, o eso sientes. ¿Te suena? No estás solo. Cualquier semana, los foros de SEO técnico están llenos del mismo post: “1800 páginas desindexadas de la noche a la mañana, ¿qué pasó?”
La noticia honesta es que “desindexada” casi nunca tiene una sola causa y casi siempre es diagnosticable. El trabajo no es el pánico, es el triaje. Esta guía recorre lo que la palabra significa realmente, las ocho causas que explican la mayoría abrumadora de los casos, una comprobación basada en rastreo de 15 minutos que encuentra la tuya, qué hacer con cada causa y cómo volver a meter las páginas en el índice.
”Desindexada” significa en realidad tres cosas distintas
Antes de arreglar nada, ordena la terminología. Las tres situaciones se confunden constantemente y piden respuestas distintas.
Estaba indexada, ahora ha caído. Google tenía tu URL en el índice, la mostraba en los resultados y luego la quitó. Este es el caso del acantilado. También es el caso en el que un cambio técnico o de calidad suele explicar la caída, y donde a menudo se puede revertir.
Rastreada, actualmente no indexada. Google ha bajado la página pero ha decidido no incluirla en el índice. En Search Console aparece como “Rastreada, actualmente sin indexar” o “Detectada, actualmente sin indexar”. La página existe, el rastreador la encontró, pero Google juzgó que no merecía estar en el índice. Aquí la solución suele ser calidad de contenido, enlazado interno o una señal de contenido duplicado, no un bloqueo técnico.
Nunca indexada. La URL nunca estuvo en el índice. Puede ser una página nueva a la que Google no ha llegado, una bloqueada por robots.txt, una con noindex desde el primer día o simplemente una huérfana sin posibilidad de descubrimiento.
El informe Indexación de páginas de Search Console es el lugar más limpio para distinguirlas. Ábrelo antes de hacer nada y mira en qué cubo están tus URLs perdidas. La ruta de arreglo de “Enviada e indexada” a “Rastreada, actualmente sin indexar” es muy distinta de la ruta para “Excluida por etiqueta noindex”.
Esta guía se centra sobre todo en el primer caso, “estaba indexada, ahora ha caído”, que es de lo que tratan la mayoría de los reportes de “1800 páginas desaparecidas”.
Las ocho causas que explican casi todos los casos
La desindexación masiva casi siempre tiene una de estas ocho causas detrás. La lista va en el orden aproximado en que las compruebo, porque algunas son mucho más comunes que el resto.
1. Se ha desplegado una meta noindex o cabecera X-Robots-Tag por error. Es la causa única más común de “páginas desindexadas de la noche a la mañana”. Un entorno de staging se subió a producción con <meta name="robots" content="noindex"> aún en la plantilla. Una actualización de plugin del CMS volteó un valor por defecto. Una cabecera en el CDN empezó a servir X-Robots-Tag: noindex. Las páginas siguen resolviendo, el contenido se ve bien, pero Google ve la directiva y las elimina en el siguiente rastreo. Comprueba tanto el <head> HTML como las cabeceras de respuesta HTTP, porque cualquiera puede llevar el noindex.
2. robots.txt empezó a bloquear las URLs. Una nueva línea Disallow: /, una ruta demasiado amplia o un CDN que empezó a servir un robots.txt distinto. Un matiz importante: un bloqueo de robots.txt no suele sacar una página del índice, solo impide rastreos futuros. Pero combinado con un re-rastreo reciente o con la incapacidad de reconfirmar un noindex, puede llevar a caídas. Comprueba siempre el robots.txt actual y renderizado que ve Google, no el archivo de tu repositorio. La guía completa de robots.txt y rastreadores de IA cubre los errores de sintaxis que rompen el archivo en silencio.
3. Etiquetas canonical apuntando a otro sitio. Un rel="canonical" que apunta a la home, a una sola página hub o a una versión de idioma equivocada colapsa las entradas del índice contra el destino canonical. Las páginas siguen siendo accesibles técnicamente, simplemente ya no se consideran el documento canónico. Especialmente cruel porque todo lo demás de la página se ve bien. La guía de etiquetas canonical cubre los patrones que se tuercen.
4. Códigos de estado que han echado a las URLs. Las páginas que empiezan a devolver 404 o 410 se quitan. Las que devuelven 5xx suficiente tiempo, también. Los soft 404, donde la URL responde 200 pero la página está vacía o dice “no encontrada”, reciben el mismo trato. Un número sorprendente de acantilados de desindexación se rastrea a un despliegue que rompió un handler de rutas y empezó a devolver 404 en toda una sección.
5. Un entorno de staging o dev desplegado por error en producción. El despliegue salió con la plantilla de staging, el robots.txt de staging, los meta tags de staging o todo a la vez. El sitio parece vivo pero sus señales de indexación están invertidas.
6. Conflictos de hreflang. Un setup de hreflang mal cableado puede hacer que Google consolide versiones de idioma o tire las equivocadas. La guía de implementación de hreflang es donde verificar el tuyo.
7. Una acción manual o reevaluación por core update. Menos común que las causas técnicas, pero muy real. Una acción manual aparece en Search Console bajo “Seguridad y acciones manuales”. Un core update es invisible pero su huella es reconocible: un descenso amplio y gradual de rankings e indexación que coincide con una ventana de actualización anunciada por Google y suele golpear primero el contenido fino o de baja confianza. Cubrimos la versión “tranquila” de esto en la guía del mito del año en el título y la verdad del core update una vez descartadas las causas técnicas.
8. Contenido fino, duplicado o autogenerado que Google decidió que no merecía estar indexado. Aparece sobre todo como “Rastreada, actualmente sin indexar”. La solución es editorial: podar, fusionar o mejorar sustancialmente las páginas afectadas.
El ochenta por ciento de las historias de “páginas desindexadas de la noche a la mañana” se rastrea a las causas uno a cinco. Trabaja esa lista siempre primero.
Diagnostícalo con un rastreo: triaje de 15 minutos
Search Console por sí sola es lenta en sitios grandes. La forma más rápida de encontrar tu causa es rastrear la sección afectada tú mismo y filtrar agresivamente. El camino:
Paso 1: confirma el síntoma en Search Console (2 minutos).
- Abre Indexación de páginas. Anota los cubos en los que están tus URLs. “Excluida por etiqueta noindex”, “Bloqueada por robots.txt”, “Soft 404”, “No encontrada (404)”, “Página alternativa con etiqueta canónica adecuada”, “Duplicada, Google eligió una canónica distinta del usuario” y “Rastreada, actualmente sin indexar” apuntan cada uno a una causa distinta de la lista de arriba.
- Abre Inspección de URL para una URL perdida concreta. La línea de veredicto y el panel de detalles de indexación son el diagnóstico más útil de Search Console.
Paso 2: rastrea el sitio y filtra (8 minutos). Ejecuta un rastreo de tu dominio y filtra los resultados en este orden:
- Páginas que sirven
noindexen el HTML o en la cabeceraX-Robots-Tag. Aunque haya una sola fila aquí en un patrón de URL a nivel de plantilla, basta para explicar una caída masiva. - Códigos de estado distintos de 200. Saca a la luz cada 3xx, 4xx, 5xx. Busca patrones: una sección entera devolviendo 404, una página de categoría en un bucle de redirección, un pico de 5xx.
- Canonical apuntando a otro sitio. Filtra páginas donde la URL canónica no sea la misma URL de la página. Luego comprueba si la canónica es intencional. Sitios enteros se desindexan por una canónica global apuntando a la home.
- Bloqueada por
robots.txt. Saca a la luz cada URL que el rastreador saltó porrobots.txt. Cruza con tu sitemap.
Paso 3: compara sitemap vs rastreo vs índice (3 minutos). Un sitemap limpio, el conjunto de URLs que el rastreador alcanzó con 200 y el conjunto que Search Console reporta como indexado deberían solaparse mucho. El delta cuenta la historia:
- URLs en el sitemap pero no rastreadas → problema de descubrimiento o de robots.txt
- URLs rastreadas pero no indexadas → problema de calidad, canónica o noindex
- URLs indexadas pero no en el sitemap → frescura del sitemap (menos urgente)
Paso 4: mira los logs del servidor para el tráfico de bots (2 minutos). Si tienes acceso a los logs, grep por Googlebot en las últimas 72 horas y mira si está visitando las URLs afectadas. Una caída repentina de la frecuencia de rastreo en una sección es ya una señal. También es el único sitio donde puedes confirmar si los rastreadores de IA y los bots de búsqueda están realmente llegando a lo que crees. La misma rutina forma parte de cualquier auditoría sana de crawl budget.
La mayoría de causas se revelan en el paso 2. Los casos en sitios grandes que tardan más suelen reducirse a un problema de canonical o hreflang repartido fino por muchas páginas.
Cómo arreglar cada causa
Una vez identificada la causa, la solución suele ser corta.
Noindex dejado en producción: quita la etiqueta o la cabecera. Confirma con curl -I para la cabecera y view-source: para el HTML. Pide indexación para una URL de muestra en Search Console. La mayoría de páginas vuelven en días, las secciones grandes tardan más porque Google rastrea en su propio calendario.
Bloqueo de robots.txt: edita el archivo, despliega, verifica con el probador de robots.txt de Search Console o pidiendo tudominio.com/robots.txt desde un navegador. Luego reenvía el sitemap para empujar un re-rastreo.
Canonical equivocado: corrige el valor de rel="canonical" para que apunte a la propia página, o al destino canonical real. Ojo con las canónicas inyectadas por plugins SEO o ajustes del CMS, no solo a las de la plantilla.
Errores 4xx / 5xx: arregla el problema de routing o de servidor subyacente. Para retiradas permanentes intencionales, 410 es más rotundo que 404; ambos funcionan. Para soft 404, o restaura contenido con sustancia o devuelve realmente 404.
Staging desplegado a producción: revierte. Después audita cómo pasó: un noindex / robots.txt de staging nunca debe llegar.
Conflictos de hreflang: la guía de hreflang lista las cinco roturas habituales. La mayoría se reducen a anotaciones no recíprocas o códigos de región equivocados.
Acción manual: abre el informe de acciones manuales, lee el hallazgo concreto, arréglalo y envía una solicitud de reconsideración. Sé honesto en la solicitud: las disculpas vagas no pasan.
Reevaluación de calidad / core update: la solución es editorial y más lenta. Identifica las páginas afectadas, decide cuáles merecen reescrituras sustanciales, cuáles fusionar o podar y cuáles dejar en paz. La guía del mito del año en el título y del core update cubre el playbook largo.
Volver a meter las páginas en el índice
Una vez arreglada la causa, la página no vuelve sola. Puedes acelerar la re-indexación:
- Solicita indexación en la Inspección de URL para páginas de alto valor. Está limitada, úsala para plantillas y hubs, no para cada URL.
- Reenvía el sitemap. Esto empuja a Google a re-rastrear las URLs que contiene. Si el sitemap está obsoleto, arréglalo primero. La guía de sitemap XML cubre el paso de validación.
- Refuerza los enlaces internos hacia las URLs afectadas. A veces las páginas desindexadas también estaban huérfanas o enlazadas débilmente. Unos pocos enlaces internos bien puestos desde páginas hub sanas ayudan al re-descubrimiento.
- Ten paciencia. Los sitios pequeños suelen re-indexar en pocos días. Los sitios grandes con miles de URLs caídas tardan semanas en que el índice se ponga al día, aunque todo esté arreglado.
¿Problema técnico o penalización? Cómo distinguirlos
Esta pregunta sale cada vez y la respuesta casi siempre es “técnico, no penalización”. La prueba rápida:
- Acción manual: habrá un aviso en el informe de acciones manuales. Si el informe está vacío, no es una acción manual.
- Algorítmico / core update: el descenso es gradual, amplio y coincide con una ventana de actualización conocida de Google. Otros sitios de tu sector ven movimientos similares en las mismas fechas.
- Técnico: el descenso es repentino, el momento suele coincidir con un despliegue o un cambio de plataforma, y el informe de Indexación de páginas de Search Console apunta a una causa concreta (
noindex, bloqueo de robots, 404, canonical).
El caso técnico es de lejos el más común. La mayoría de los posts de “Google me ha penalizado” resultan ser un noindex que se subió dos días antes de que cayese el tráfico.
Prevención: checklist de indexación antes de cada despliegue
La mayoría de los incidentes de desindexación son prevenibles. Una checklist corta antes del despliegue caza los peores:
- El HTML de producción no debe llevar
noindexen ninguna página que deba estar en el índice. CI puede grepear esto. - El
robots.txtde producción no debe llevarDisallow: /. CI puede bajarlo y verificar. - Producción debe responder con 200 (o 301 intencional) en una lista de URLs críticas. CI puede curlear y asertar.
- Las cabeceras
X-Robots-Tagen URLs clave no deben llevarnoindex. - Las etiquetas canónicas en una muestra de URLs deben apuntar a sí mismas (o a una canónica intencional).
- El sitemap desplegado coincide con las URLs en vivo.
Un rastreo externo nocturno que rompa el build si alguna de estas comprobaciones empeora es lo más parecido a una red de seguridad real. La checklist de auditoría SEO técnica cubre la auditoría recurrente más amplia.
Conclusión
La desindexación masiva se siente como una catástrofe y normalmente no lo es. En la mayoría abrumadora de los casos la causa es técnica, es identificable en menos de 15 minutos con un rastreo más el informe de Indexación de páginas de Search Console, y la solución es corta. El pánico es el enemigo del triaje. Empieza por la lista de las ocho causas, corre el diagnóstico de cuatro pasos, arregla lo que encuentres y pide re-indexación sobre una muestra de URLs de alto valor.
Si quieres correr ese rastreo de 15 minutos ahora mismo, descarga Seodisias y apúntalo a tu sitio. Rastrea localmente en tu máquina sin límite de URLs y saca a la luz cada etiqueta noindex, cada código de estado distinto de 200, cada canonical apuntando a otro sitio y cada URL bloqueada por robots.txt en una sola pasada. Sin subir nada, sin registro, todos los datos se quedan contigo. Compara lo que encuentra con tu informe de Indexación de páginas en Search Console y la causa casi siempre está en la diferencia entre los dos.