Perdieron el 80% de su índice en Google en dos semanas

Me llamaron a finales de enero. En las dos primeras semanas de diciembre, su sitio (por encima de un millón de URLs) había perdido el 80 % del índice de Google. Abrimos GSC y quedaban 200.000.

Perder 800.000 URLs en quince días da la misma sensación que cuando miras tu cuenta bancaria y ves una transferencia que no recuerdas haber hecho. La diferencia es que en SEO el agujero no salta a la cara hasta que llega la factura: tráfico cayendo, queries que rotaban con normalidad y han desaparecido del informe, un panel de Páginas en GSC que parece una rampa de skate. De las que bajan, no de las que vuelven a subir.

No fui el primero al que llamaron. Antes hubo alguien que entendió bien el diagnóstico (”hay basura en el índice”) y se fue al martillo más obvio del manual: robots.txt.

Por el camino acabaron rompiendo, sin enterarse, las campañas de Google Ads del cliente. Te hablo de este drama más abajo.

Cuando aterrizan este tipo de marrones, la petición es casi siempre la misma: “hay que recuperar todas las URLs en el índice”. Y esa ambición es, casi siempre, la que te ha metido en el lío.

No te preocupes, en esta entrega te cuento la solución en detalle.

Suscríbete ahora

Lo que hicimos cuando entramos al proyecto fue lo contrario. Y conviene contarlo en orden porque el resultado se entiende mejor desde el proceso.

En las dos primeras semanas recuperamos cerca de la mitad de lo perdido limpiando con tijera, no con manguera. La semana siguiente sumamos otro 25 %. El último 25 % no lo recuperamos: decidimos no hacerlo. Cuando entendimos qué URLs no merecían volver, dejarlas fuera del índice era la solución, no una asignatura pendiente. Indexar por indexar es ruido con timestamp encima; lo estratégico fue elegir qué dejar fuera y defenderlo.

Estrategia es, muchas veces, ser capaz de renunciar a lo que, de manera realista, no puedes aspirar. Apostar por maximizar lo que puede dar resultados, en lugar de invertir diez veces ese esfuerzo para levantar algo que quizá no consigas levantar.

Hay un tipo de web donde lo de “indexar más” se paga muy caro: plataformas cuyo producto son datos que caducan o se pierden actualidad. Listados de precios que cambian cada día, fichas que rotan cada semana, catálogos por feed, información corporativa actualizada... Marketplaces, directorios, portales de empleo, comparadores, B2B con inventario vivo. Si tu negocio se parece a alguno, la pregunta que define tu SEO no es “cómo rankeo más”, es “qué debería estar en el índice y qué no”.

Suscríbete ahora

Qué es “fresco” de verdad (y qué es ruido)

Freshness no es poner un lastmod de hoy en el sitemap y esperar palmaditas.

Google sabe distinguir entre un cambio real de contenido y un timestamp de adorno porque lo han dicho ellos más de una vez.

Search Engine Journal lo recordaba hace pocos días en What Search Engines Trust Now: Authority, Freshness & First-Party Signals: motores con IA por medio reevalúan de forma continua tres señales (autoridad como entidad reconocible, freshness como mantenimiento real y no fecha, y datos first-party como evidencia propia).

Traducción a la práctica: un evergreen sin mantenimiento envejece y un sitio que “publica mucho” sin sustancia no sube por volumen. He puesto en negrita eso último a propósito. Porque es así.

Cuenta como fresco lo que ha cambiado de verdad: nueva información, datos actualizados, estructura revisada, una URL que responde a una intención que exige actualidad (precios, stock, normativa, resultados). El usuario que llega desde Google se encuentra algo vigente, no una ficha con datos de hace tres meses que tu feed dejó de actualizar.

NO cuenta como fresco:

• Regenerar miles de URLs con el mismo template cada noche para que el lastmod cambie. Es una de las peores ideas que puede tener un SEO. Absurdo, de hecho.

• Indexar páginas de búsqueda interna (variaciones parametrizadas sin contenido propio). Peligro, Will Robinson.

• Dejar en el índice fichas de productos descatalogados con un “no disponible” donde estaba el botón de compra.

Hay un asesino silencioso detrás de buena parte de la basura indexada en sitios que cuentan con un catálogo vivo: el slug se calcula sobre un dato que cambia (nombre del recurso, título, identificador, campo editable cualquiera).

Cuando ese dato se actualiza y nadie configura la redirección 301 desde la URL antigua, cada edición rutinaria deja una URL nueva en el índice y una URL vieja camino del 404. Multiplicado por el catálogo entero, esa rotación silenciosa es una de las fuentes más prolíficas de URLs zombi y de hits desperdiciados de Googlebot. Y casi nadie la detecta hasta que el daño ya está hecho, porque cada cambio individual parece inocuo.

Suscríbete ahora

El framework que uso para decidir qué hacer con cada URL

Para cada tipo de URL del sitio, me hago cinco preguntas:

1. Esta URL responde a una intención de búsqueda real y diferenciada. No es una variante parametrizada de otra que ya responde mejor.

2. El contenido va a estar vigente el tiempo suficiente para que Google la rastree, la indexe y alguien la encuentre. Si caduca antes de que Googlebot vuelva, no merece estar.

3. Indexar esta URL refuerza o debilita la señal del resto del sitio. Si cada URL nueva diluye el crawl budget de las que sí convierten, el coste es mayor que el beneficio.

4. El contenido es útil. Si está anticuado, mejor desindexar, incluso aunque responda a una intención de búsqueda genuina. Ruido. Fuera.

5. Casos de thin content descarado. Si no lo puedes enriquecer de manera clara, mejor eliminar. Es preferible tener menos puntos de entrada desde Google, que dejar indexadas cosas que no son útiles.

Si la respuesta a cualquiera de las cinco es “no” o “depende, pero tirando a no”, esa URL sale del índice.

Cada URL que indexas sin criterio compite contra las que sí deberían rankear. Tu sitio acaba compitiendo contra sí mismo en Google. Decidir qué dejar fuera del índice es la decisión on-page con más impacto real.

Técnicas que recomiendo usar

• noindex en meta robots: para páginas que deben existir (el usuario accede) pero no deben rankear. El clásico para resultados de búsqueda interna, filtros facetados sin volumen, páginas de usuario. La avaricia estropea muchos proyectos.

• Canonical: cuando hay variantes (paginación, parámetros de orden, filtros combinados) que apuntan al mismo contenido principal. Obvio, ¿verdad? Pues no lo parece.

• Sitemap por segmento: uno para evergreen (marca, categorías, guías) y otro para inventario vivo (fichas que rotan). Así puedes monitorizar en GSC cómo indexa Google cada grupo por separado.
  Y separado por idiomas, no te olvides. En general, a más dividido y ordenado lo tengas, más fácil te será analizar la indexación del proyecto. Yo suelo dividir mis sitemaps por mercado, idioma y tipo de página.

• IndexNow: útil cuando tienes tramos de catálogo que rotan rápido y quieres bajar latencia entre publicación y rastreo. Esta misma semana, Fabrice Canel (Bing) se ofrecía a ayudar al Internet Archive a adoptar IndexNow para respaldar contenido fresco. Guiño curioso: la misma tecnología que resuelve rastreo en producción sirve para archivar memoria. Tela.

• Monitorización: cruce periódico de URLs indexadas (GSC “Páginas” → sitemap) frente a URLs activas en tu sistema. Si la diferencia crece, tienes un problema de higiene que no se arregla con un core update favorable.

• robots.txt: para bloquear el rastreo de secciones enteras que no deberían consumir crawl budget. Bloquear rastreo no garantiza desindexación si las URLs ya estaban indexadas. Y de toda la lista es la herramienta que más cara sale cuando se usa mal. Voy a ello.

• Si necesitas desindexar, haz uso de respuestas 410 selectivas. Con cuidado.

Suscríbete ahora

El error más caro (y la parte que afecta a Google Ads)

El error más caro que he visto en consultoría no es técnico. Es de criterio. ”Cuantas más URLs en Google, mejor” tiene una variante con el mismo peso: “Cuantas menos, mejor”. O su versión más eficiente: “si es lo justo que necesito, MEJOR QUE MEJOR”.

Volvamos al robots.txt del caso. Quien estuvo antes que nosotros entendió bien el problema (basura en el índice) y se fue a bloquear secciones enteras del sitio. El razonamiento sobre el papel tenía sentido: si quito el rastreo, dejo de gastar crawl budget en lo que no aporta. La ejecución y la toma de decisiones son lo que más cojearon.

En la lista de bloqueos había una sección que servía landings de campañas de Google Ads. El bot de Ads no podía acceder a esas URLs para revisar destino y políticas. Resultado: anuncios desaprobados, campañas en pausa, Quality Score pasando un mal rato. Todo eso ocurrió mientras el avance se reportaba como saneamiento de índice. Nadie cruzó la información hasta que el equipo de paid pidió ayuda.

Hay tres lecciones aquí.

1. La primera: el SEO técnico no termina en el sitemap. Si tu sitio tiene paid, el cruce con Ads se hace ANTES de tocar robots.txt a nivel de sección. La primera vez que lo cruzas ahorras una conversación incómoda; la segunda salvas una cuenta.

2. La segunda es más operativa y se tiende a ignorar. Una directiva en robots.txt que Google ignora pasa de bloqueo a placebo. Verificar en logs de servidor que el bot respeta tus directivas (¿cuántos hits sigue recibiendo la sección que dije que estaba bloqueada?) es parte del trabajo, no un extra que se añade después si sobra tiempo.
   En este caso, esa validación nunca se hizo. Parte del problema seguía vivo bajo una directiva supuestamente “aplicada”.

3. La tercera lección es más de fondo. El dato relevante para decidir qué se queda y qué se va casi nunca está solo en GSC. Está en la base de datos del cliente, en el feed, en logs de rastreo, en los datos de venta. Lo sacamos con scrapers propios y un cruce contra el inventario interno: qué fichas tenían información actual, cuáles llevaban meses en barbecho, cuáles eran resultados de búsqueda interna disfrazados de URL canónica.
   GSC y GA4 te dan parte de la foto. Si trabajas solo con esa parte, decides a ciegas y actúas bajo conclusiones que no aguantan un escrutinio serio.

Lo ideal es limpiar por capas: noindex para lo que tenía valor de navegación, pero no de ranking, canonical donde había variantes con la misma intención, robots.txt solo para lo que no aportaba nada al usuario y nunca se servía como destino de campaña, sitemaps por tipo y rastreo forzado para lo importante.

La consecuencia mecánica fue que el índice se recuperó en oleadas: dejamos de competir contra nosotros mismos.

La estratégica, más interesante: aceptar que un índice más pequeño y limpio vale más que un índice grande lleno de ruido. La parte del catálogo que se quedó fuera cumplía mejor su función ahí que dentro.

Checklist rápido

• Clasifica tus tipos de URL en dos o tres cubos: índice sí, índice no, evaluar caso a caso.

• Cuando la matriz no termina de cuadrar, recurre al Pareto del catálogo: ¿qué 20 % de URLs genera el 80 % del tráfico orgánico, de las conversiones o de los ingresos? Plantea sacar el resto del índice por defecto y vuelve a meter solo lo que pase un filtro explícito.

• Revisa cada trimestre la diferencia entre URLs en sitemap vs URLs indexadas en GSC. Son el mejor indicador de calidad que conozco: te permite valorar dónde y en qué Google está dispuesto a invertir dinero.

• Antes de tocar robots.txt a nivel de sección, cruza con campañas activas de Ads y con cualquier URL que se sirva como destino de paid. Lo que en SEO parece basura puede ser la landing de la campaña que más convierte.

• Después de aplicar una directiva en robots.txt o un noindex, valida en logs que Google la está obedeciendo. Una directiva escrita y no comprobada es un placebo con apariencia de control.

• No te quedes en GSC y GA4. Cruza con datos propios: inventario, feed, base de datos de productos, logs. Decidir indexación con dos fuentes de Google es decidir con un solo ojo.

• Si tu feed genera URLs nuevas a diario, documenta cuándo caducan y qué pasa con ellas (redirect, noindex, 404 limpio).

• No tomes la decisión una vez y te olvides. Los catálogos cambian. Lo que hoy era una ficha con demanda, mañana es residuo.

Suscríbete ahora