El spam update de agosto de 2026 terminó de desplegarse el 21 de agosto, después de tres días de rollout. La volatilidad siguió durante varios días más. A esta altura, los sitios afectados ya tienen datos suficientes para saber si la caída fue real o fue ruido, y la pregunta pasó a ser qué hacer.
La respuesta corta es que la recuperación de un spam update es lenta y estructural, y que las reacciones rápidas suelen empeorar el cuadro. Va la respuesta larga.
Primero, confirmar que fue el update
Antes de cambiar nada, hay que descartar las explicaciones más simples. Tres verificaciones que hacemos siempre antes de tocar un sitio.
Fechas exactas. El update corrió del 18 al 21 de agosto. Si la caída empezó el 12 o el 26, probablemente no sea eso: hubo picos de volatilidad no confirmados alrededor del 12 y 13 de agosto, y la volatilidad post-update siguió hasta fin de mes. Que un rastreador de terceros marque rojo no equivale a una confirmación de Google.
Bugs de reporte. El 8 de septiembre, Search Console reportó durante un rato páginas como “Rastreada, actualmente no indexada” cuando estaban perfectamente indexadas. Google confirmó después que fue un error de reporte resuelto en la noche. Quien haya sacado conclusiones de los datos de ese día trabajó sobre información falsa. Vale la pena chequear si la fecha de la caída coincide con algún incidente conocido.
Segmentación. Filtrar por país, por dispositivo y por sección. Una caída que aparece sólo en tráfico europeo en la sección de viajes tiene que ver con los cambios de la Digital Markets Act, no con un spam update.
Qué ataca un spam update
Google describió el de agosto como un spam update normal, aplicado a todos los idiomas y ubicaciones. Arrancó el 18 de agosto cerca de las 12:30 del mediodía hora del este y terminó el 21 a las 4:50 de la mañana. Un detalle que la compañía dejó claro y conviene retener: no apuntaba a spam de enlaces, ni cubría todas las políticas contra el spam a la vez.
Los spam updates en general van contra violaciones de esas políticas: contenido generado a escala sin valor, abuso de reputación de sitio, contenido parasitario, páginas puerta. No son core updates. Un core update reevalúa calidad general; un spam update va contra prácticas específicas.
Esa distinción define la estrategia. Ante un core update, el trabajo es mejorar la calidad general y esperar. Ante un spam update, hay que encontrar la práctica concreta que disparó el problema y eliminarla.
Las áreas a revisar en un medio
Para redacciones, cinco focos donde suelen aparecer los problemas.
Contenido de terceros alojado en el dominio. Secciones de contenido patrocinado, cupones, casinos, comparadores o apuestas publicadas bajo el dominio del medio pero producidas y controladas por un tercero. Es el patrón que la política de abuso de reputación de sitio ataca de frente, y es común en medios de la región que monetizan así.
Contenido generado a escala sin supervisión. Notas producidas con IA en volumen, traducciones automáticas publicadas sin edición, agregaciones de agencia republicadas sin aporte propio.
Subdominios y subdirectorios alquilados. Cualquier acuerdo donde un tercero publica bajo la autoridad del dominio a cambio de un pago.
Archivo programático sin mantenimiento. Plantillas generadas para coberturas viejas que quedaron indexadas. John Mueller señaló esta semana que los sistemas pueden perder confianza en un sitio “en base a las páginas viejas”.
Enlaces salientes pagos sin marcar. Especialmente en notas de contenido comercial que no llevan rel="sponsored". Google aclaró que este update no apuntaba a spam de enlaces, así que difícilmente sea la causa de una caída de agosto. Va igual en la lista porque es higiene pendiente en muchos medios y porque la próxima vez puede sí estar en el alcance.
Qué no hacer
Tres errores que vemos con frecuencia y que alargan la recuperación.
Borrar en pánico. Eliminar miles de URLs de golpe genera una masa de 404 y una reevaluación del sitio que agrega ruido justo cuando se necesita una señal limpia. Lo que corresponde es noindex en lo que sobra, salida del sitemap, y recién después decidir si conviene eliminar.
Pedir reconsideración. Las revisiones de reconsideración son para acciones manuales, que aparecen notificadas en Search Console. Un spam update es algorítmico: no hay a quién pedirle nada, y enviar una solicitud sin acción manual no hace nada.
Cambiar todo a la vez. Si se toca el contenido, la arquitectura, los enlaces y la plantilla en la misma semana, no va a haber forma de saber qué funcionó. Conviene secuenciar y documentar fechas.
Cuánto tarda
Esta es la parte que nadie quiere escuchar. La recuperación de un spam update suele requerir esperar al siguiente ciclo de actualización para que el sistema reevalúe el sitio. Entre el update de junio y el de agosto pasaron unos dos meses; no hay garantía de que ese ritmo se sostenga.
Mueller lo describió, hablando de un caso de SEO programático, en términos que aplican igual: resolverlo “suele llevar tiempo y esfuerzo significativo para demostrar el valor”. Y sugirió mirar cómo trabajan otros la recuperación de spam y core updates para dimensionar el trabajo involucrado.
Planificar en trimestres, no en semanas. Y mientras tanto, documentar cada cambio con fecha, porque cuando la recuperación llegue, la única forma de saber qué la produjo va a ser ese registro.
Fuentes: Search Engine Roundtable sobre el cierre del spam update de agosto, el bug de indexación confirmado y los comentarios de Mueller sobre recuperación.
