BookinglyTech News
Software

Monitorea robots.txt y sitemap para evitar caídas de tráfico

Un cambio accidental en robots.txt o en el generador de sitemap puede reducir el tráfico orgánico durante semanas. La solución es simple: añadir pruebas de humo a tu CI y vigilar los archivos críticos.

2 min de lecturaDev.to0 vistas

Dos accidentes SEO recurrentes son fáciles de pasar por alto: un robots.txt de staging con Disallow: / llega a producción, o una actualización de plugin cambia el generador de sitemap y desaparecen secciones completas.

El efecto no se percibe en el sitio web, pero Google lo detecta. El caché de robots.txt dura hasta 24 h y el impacto en la indexación y el tráfico puede tardar más en reflejarse. Cuando alguien pregunta por la caída orgánica, el problema ya puede estar semanas de haber ocurrido.

Qué vigilar

  • /robots.txt: simple, pequeño, casi nunca cambia. Cualquier alteración merece revisión humana.
  • Sitemap index y los child sitemaps: si el sitemap está dividido, observa el índice y los archivos que cubren las secciones más importantes.
  • Páginas clave: home, pricing y otras landing pages de alto valor. Cambios de plantilla que borren texto visible suelen pasar desapercibidos.
  • Otros archivos de control de texto: ads.txt, /.well-known/security.txt.

El monitor de texto no detecta cambios en metadatos ni encabezados: <meta name="robots" content="noindex">, X‑Robots‑Tag: noindex, rel="canonical" o etiquetas hreflang generadas por JavaScript.

Prueba de humo SEO

Incorpora un script sencillo en tu CI que se ejecute después del despliegue. El script verifica:

  1. Si el robots.txt contiene Disallow: /.
  2. Si las páginas clave devuelven encabezados X‑Robots‑Tag: noindex o meta robots noindex.
  3. El número de URLs en sitemap.xml y su coherencia con la semana anterior.
#!/usr/bin/env bash
site="https://example.com"
pages=(/ /pricing /blog)
# … (código completo del script)

Al fallar, el script devuelve un código distinto de cero, lo que hace que la pipeline se marque como fallida y notifique al equipo.

Monitoreo continuo

El script cubre despliegues, pero no actualizaciones de CMS o ediciones manuales de robots.txt. Para esos casos, un monitor de archivos como PingWhen es útil. PingWhen envía alertas cuando un archivo cambia, se cae o vuelve a estar activo.

PingWhen ofrece alertas cada 15 minutos por un precio de $9 / mes; no hay plan gratuito. Puedes apuntar su webhook a tu CI para re‑ejecutar automáticamente la prueba de humo cuando se detecte un cambio.

Ajustes y buenas prácticas

  • Si el generador añade <lastmod> en cada build, evita alertas constantes ajustando la lógica del monitor.
  • Para sitemaps grandes, cuenta las URLs en lugar de hacer diff.
  • Establece umbrales razonables: por ejemplo, 80 % del conteo de la semana pasada.

En resumen, la clave es tener pruebas de humo en el pipeline y un monitor de archivos para cambios fuera del control del CI. Así, cualquier alteración que afecte a los motores de búsqueda se detecta antes de que el tráfico comience a caer.

Historias Relacionadas