El 8 de septiembre, durante un rato, Search Console mostró páginas en estado “Rastreada, actualmente no indexada” que estaban perfectamente indexadas. Portadas de sitios enteros, incluidas. El susto fue considerable y varios equipos empezaron a mover cosas antes de entender qué pasaba.
Al día siguiente John Mueller lo confirmó en Bluesky: “Lo verifiqué con el equipo, y fue un blip corto que se resolvió rápido durante la noche, antes de que se publicaran estos posteos. Está bueno que sea fácil chequear cosas como la indexación de la portada. Perdón por la confusión.”
Y agregó una frase que conviene tener a mano: “No todo problema potencial es un incendio por el que haya que dejar todo.”
Qué pasó exactamente
Los primeros en verlo fueron Ryan Tree y Glenn Gabe, que reportaron en X sitios de clientes figurando como no indexados cuando sí lo estaban. Matthew Mellinger, que extrajo datos de la API de Search Console justo durante la ventana del error, llegó a ver hasta un 20% de las URLs de algunos sitios chicos pasando de indexadas a “Rastreada, actualmente no indexada”, con más incidencia en páginas viejas o finas.
Ese detalle es el más instructivo de todo el episodio. Los datos extraídos por API durante un bug de reporte quedan guardados y parecen legítimos. Nadie los marca como sospechosos después. Si ese pull alimentó un tablero o un informe mensual, el error sigue ahí.
El protocolo de verificación
Cuatro pasos, en orden, antes de tocar nada ante un salto brusco en cualquier informe de cobertura.
Verificar manualmente. Tomar cinco o seis URLs de las que figuran con problema y revisarlas con la herramienta de inspección de URL. Si Google dice que están indexadas y aparecen al buscarlas con site:, el problema es de reporte.
Chequear la portada. Es el atajo que sugiere Mueller y funciona: si la home de un sitio activo figura como no indexada, casi con certeza es un bug. Ningún sistema desindexa una portada sana de un día para el otro.
Mirar si le pasa a otros. Search Engine Roundtable, las cuentas de Google Search Central y los foros de la industria suelen registrar estos incidentes en horas. Un problema que le pasa a todo el mundo no es un problema del sitio.
Esperar veinticuatro horas antes de actuar. La mayoría de los bugs de reporte se resuelven solos. Los cambios hechos en pánico durante la ventana del error son los que después cuesta revertir.
Cuándo sí es una señal real
El riesgo de un episodio así es el opuesto al del susto: que la próxima vez se descarte como bug algo que no lo es. “Rastreada, actualmente no indexada” es una de las categorías más informativas de Search Console cuando el dato es bueno.
Tres formas de distinguirla de un error de plataforma.
Es gradual, no instantánea. Un bug aparece de golpe y se va de golpe. Un problema real crece a lo largo de semanas.
Es selectiva. Afecta a un tipo de página —el archivo viejo, las páginas de etiqueta, una plantilla programática— y no a la portada ni a las notas nuevas.
Sobrevive a la verificación manual. Las URLs revisadas una por una efectivamente no están en el índice.
Cuando se cumplen las tres, hay algo que atender, y suele ser inflación de archivo: contenido que existe pero no justifica un lugar en el índice. Mueller viene insistiendo en que los sistemas pueden perder confianza en un sitio “en base a las páginas viejas”, y este es exactamente el indicador donde eso se ve primero.
Once días después, otro (y este sin confirmar)
El 11 de septiembre apareció un segundo problema en el mismo informe: a varios sitios les faltaba un bloque de datos viejos de junio de 2026 en el reporte de indexación de páginas. A diferencia del episodio del 8, este no tuvo confirmación de Google al cierre de esta nota: no hay declaración de Mueller ni aviso en el panel de estado.
La diferencia importa y es justamente el punto. Frente al bug del 8 se podía esperar sin hacer nada porque había una confirmación explícita de que era un blip de reporte. Frente al del 11 no hay tal cosa, y ahí el protocolo de verificación deja de ser una formalidad: es lo único que separa un hueco en el reporte de una pérdida real de indexación. Chequear la URL en vivo, contrastar con analytics y con logs, y recién después decidir.
Dos incidentes en el mismo informe en menos de dos semanas dejan además una consecuencia práctica: cualquier auditoría que use junio de 2026 como línea de base está apoyada sobre datos que pueden estar incompletos. Conviene revalidar ese período contra una fuente propia antes de sacar conclusiones de tendencia.
Lo que conviene dejar montado
Dos cosas, baratas las dos.
Un registro de incidentes con fecha. Cada vez que Google confirma un bug de reporte, anotarlo con la ventana horaria. Dentro de seis meses, cuando alguien mire una serie histórica y encuentre un pico raro, ese registro es la única forma de saber si fue real.
Marcar los pulls de API afectados. Si el equipo extrae datos de Search Console de forma automática, vale la pena poder invalidar un rango de fechas a mano. Es media hora de desarrollo que evita decisiones tomadas sobre datos que Google mismo desautorizó.
Fuente: Search Engine Roundtable, 9 de septiembre de 2026, sobre la confirmación de John Mueller en Bluesky.
