En el mundo del posicionamiento orgánico (SEO), la confianza se construye en años y se pierde en segundos.
Esto pasó en abril de 2021. Durante el primer trimestre de ese año habíamos logrado un crecimiento sostenido: gracias a una estrategia agresiva de optimización técnica, las métricas de nuestro cliente VTR (una de las Telcos más grandes de Chile) estaban dando frutos.
- Clics diarios: de unos 450 en enero a más de 700 a comienzos de abril, con peaks sobre 850.
- Impresiones diarias: de alrededor de 30 mil a cerca de 48 mil en el mismo período.
Fig 1: Enero a abril de 2021 en Search Console. El crecimiento de meses se estrelló contra el suelo en la semana del 19 de abril, y volvió.
Estábamos en el mejor momento del proyecto. Y entonces, alguien en el cuarto de servidores “apretó el botón equivocado”.
La cronología del silencio (El error humano)
El incidente técnico fue grave, pero el incidente de comunicación fue letal.
- Lunes 19 de abril: El equipo interno del cliente detecta “anomalías”. El tráfico empieza a tambalearse. No nos informan.
- Miércoles 21, 09:49 AM: 48 horas después del inicio del desastre, recibimos un correo: “Chicos, una auditoría dice que tenemos 6.059 enlaces rotos. ¿Pueden revisar?”.
48 horas en internet es una eternidad. Para un crawler de Google, es tiempo suficiente para decidir que tu sitio ha muerto.
La investigación forense: El servidor caprichoso
Al recibir la alerta, la primera reacción fue de escepticismo. Navegué por el sitio desde mi navegador: Status 200 OK. Todo cargaba rápido.
Para verificar, corrí un rastreo estándar con Screaming Frog. Resultado: Todo verde. El sitio respondía correctamente.
¿Cómo podía una auditoría reportar 6.000 errores en un sitio que yo veía funcionar perfectamente?
La prueba del User-Agent
Sospeché inmediatamente de un bloqueo a nivel de servidor (WAF o CDN). Para probarlo, ejecutamos una batería de pruebas de suplantación de identidad (Spoofing), configurando a Screaming Frog para que se presentara como Googlebot Smartphone.
Fig 3: La misma auditoría, pero simulando ser Googlebot. El servidor bloquea todo con “404 Not Found”.
Los resultados de la auditoría manual revelaron una discriminación absurda:
| User-Agent Simulado | Respuesta del Servidor | Interpretación |
|---|---|---|
| Navegador (Chrome) | ✅ 200 OK | El sitio funciona para humanos. |
| Screaming Frog Spider | ✅ 200 OK | Permitido. Screaming Frog ve el sitio. |
| Bingbot | ✅ 200 OK | Permitido. Bing ve el sitio. |
| DuckDuckBot | ✅ 200 OK | Permitido. DuckDuck ve el sitio. |
| Yahoo! Slurp | ✅ 200 OK | Permitido. Yahoo ve el sitio. |
| Googlebot Smartphone | ❌ 404 Not Found | Bloqueado. Google no ve el sitio. |
El diagnóstico fue quirúrgico: El servidor (Oracle) tenía una regla de configuración corrupta que atacaba específicamente al User-Agent del buscador más importante del mundo, mientras dejaba pasar a bots menores y a humanos.
Esto hacía el problema invisible para los monitores de uptime estándar, pero catastrófico para Google Search Console, que empezó a reportar que nuestras URLs ya no existían.
Fig 4: Google Search Console confirmando que no puede acceder a las páginas.
El diagnóstico (11:58 AM) y la burocracia (30 horas)
En menos de dos horas desde la notificación, teníamos la causa raíz aislada. Enviamos un informe técnico detallando que el bloqueo se producía a nivel de headers.
Sin embargo, el proveedor de infraestructura entró en un ciclo de validaciones internas. Tardaron 30 horas en aplicar el parche. En total, el sitio estuvo “invisible” para Google durante casi 4 días (Lunes a Jueves).
El impacto: ¿Qué pasa cuando Google deja de verte?
Las gráficas de esos días son aterradoras. La caída no fue una pendiente suave; fue un acantilado vertical.
Fig 5: El momento exacto del desplome de clics orgánicos.
El impacto fue múltiple:
-
Desindexación masiva: Google empezó a eliminar páginas del índice porque “no existían”.
Fig 6: Búsqueda de comando ‘site:’. Google ya no mostraba resultados. -
Pérdida de oportunidad: El tráfico de descubrimiento (No-Brand) se fue a cero.
Fig 7: Caída libre de impresiones.
El escenario contrafactual
Mira el final del gráfico de la Fig 1: en cuanto el proveedor corrigió la regla, el tráfico volvió a los niveles previos en cosa de una semana. Google volvió a rastrear, encontró las páginas donde siempre estuvieron, y las restituyó.
Ese es el verdadero valor del diagnóstico rápido. Un bloqueo de cuatro días se recupera; uno de varias semanas es otra historia, porque Google deja de visitar con la misma frecuencia un sitio que lleva tiempo respondiendo 404, las páginas salen del índice de a poco, y recuperar posiciones perdidas es mucho más lento y más incierto que conservarlas.
Cómo no volver a enterarte por un correo
La lección operativa es que el monitoreo de disponibilidad tiene que mirar el sitio con los ojos de Google, no solo con los de un humano. Basta con un chequeo automático que pida las páginas clave dos veces, como navegador y como Googlebot, y avise si las respuestas difieren:
curl -s -o /dev/null -w "%{http_code}" https://tusitio.cl/curl -s -o /dev/null -w "%{http_code}" -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://tusitio.cl/Si el primero da 200 y el segundo 404, tienes el incidente de este artículo detectado en minutos, no en 48 horas. Súmale las alertas de Search Console y una alerta de caída de clics armada con su API, y el próximo bloqueo no llega por correo de un cliente.
Conclusión: Lo que no se mide como robot, no existe
Este caso demuestra por qué la tecnología no puede estar divorciada de la visión comercial.
El equipo de IT del proveedor veía sus dashboards de “Uptime” en verde. Para ellos, no había incidente. Solo una visión técnica enfocada en negocio pudo detectar que, aunque las luces de la tienda estaban encendidas, la puerta tenía un candado digital para el cliente más importante del mundo.