Desarrollo de software, IA y webs en Barcelona · Soporte 365 días
17 de octubre de 2026

¿Tu web se cae al enviar la newsletter? Caché, parámetros de campaña y robots

Envías la newsletter con las novedades del mes, los clientes empiezan a hacer clic y, a los pocos minutos, la web va lenta o deja de responder. Justo cuando más visitas llegan. Es una consulta habitual en tiendas online y webs con mucho catálogo, y casi nunca se arregla contratando un servidor más potente.

Esta semana lo hemos resuelto en una tienda online con un catálogo grande, como la de la librería online que migramos a WooCommerce. Te contamos qué pasaba y qué conviene revisar en tu web.

El problema: cada clic de la campaña se salta la caché

Una web con WordPress, WooCommerce u otro gestor no monta cada página desde cero en cada visita. Guarda una copia ya preparada (la caché) y la sirve en un instante. Mientras la caché funciona, el servidor aguanta mucho tráfico sin esfuerzo.

Las herramientas de email marketing como Mailchimp o Brevo añaden parámetros a cada enlace para medir la campaña: utm_source, utm_campaign, mc_cid, mc_eid… Para muchas configuraciones de caché, /producto/ejemplo/ y /producto/ejemplo/?utm_source=newsletter&mc_eid=… son dos páginas distintas. Como el identificador cambia para cada suscriptor, cada clic pide una página que no está guardada y el servidor tiene que generarla entera, con todas sus consultas a la base de datos.

Con unos cientos de clics en pocos minutos, el servidor se queda sin procesos libres. La web no se cae por las visitas en sí, sino porque ninguna de ellas aprovecha la caché.

La solución: ignorar los parámetros de campaña al cachear

La caché tiene que tratar esas direcciones como la misma página. En la práctica:

  • Configurar la caché del servidor o del plugin para que descarte utm_*, mc_*, fbclid, gclid y similares al decidir qué copia servir.
  • Mantener los parámetros en la dirección que ve el navegador, para que Google Analytics y la herramienta de email sigan midiendo la campaña.
  • Probarlo primero en un entorno de pruebas y después en producción, comprobando que la primera visita genera la copia y las siguientes la reutilizan.

Es un cambio pequeño, pero hay que hacerlo con cuidado: si la caché ignora parámetros que sí cambian el contenido (filtros, paginación, idioma), servirá páginas equivocadas.

El otro sospechoso: robots que no deberían estar ahí

Al revisar los registros del servidor apareció un segundo problema que no tenía nada que ver con la newsletter: buena parte del tráfico eran robots. Algunos son útiles, como Google, Bing o los que generan las vistas previas en redes sociales. Otros solo copian el catálogo, prueban formularios o consultan la API de la tienda sin descanso.

Los más molestos se hacen pasar por un navegador normal o incluso por Googlebot. No se pueden bloquear por el nombre que dicen tener, porque mienten.

Lo que aplicamos:

  • Lista de robots permitidos. Buscadores y servicios que aportan algo pasan sin trabas, para no perder posicionamiento.
  • Bloqueo de robots falsos. Si un robot dice ser de un buscador pero no viene de sus direcciones, se bloquea.
  • API cerrada a anónimos. Las rutas de la API que la web pública no necesita dejan de responder a quien no ha iniciado sesión.
  • Firmas de navegador obsoletas. Muchos programas de copia masiva se identifican con versiones antiguas de Chrome que ya casi nadie usa. Se filtran.
  • Reto de Cloudflare para el tráfico sospechoso, sin molestar al visitante normal.

Vigilancia para que no vuelva a pasar

Los robots cambian cada semana, así que una lista fija se queda vieja pronto. Por eso dejamos un vigilante: un proceso que revisa los accesos, avisa por email cuando aparece un robot nuevo y bloquea automáticamente los que se hacen pasar por otros. Quien mantiene la web decide con datos si el nuevo visitante pasa o no.

Además, cada caída queda diagnosticada: a qué hora fue, qué peticiones la provocaron y qué se ha cambiado. Así se distingue una campaña sin caché de un ataque o de un fallo del propio servidor.

Qué revisar en tu web antes de la próxima campaña

  • Abre un enlace de tu última newsletter y compara cuánto tarda la página con y sin los parámetros. Si con ellos tarda más, probablemente no sale de la caché.
  • Pide a tu proveedor de hosting los registros de acceso de un día con campaña y mira cuántas peticiones llevan utm_ o mc_.
  • Revisa qué parte de tus visitas son robots y cuáles te aportan algo.
  • Comprueba que la caché excluye el carrito, la cuenta de cliente y el pago, y que incluye todo lo demás.
  • Ten un sistema de avisos. Enterarte por un cliente de que la web no carga, en plena campaña, es lo peor que puede pasar.

No siempre hace falta más servidor

Ante una web lenta, lo primero que se suele proponer es ampliar el servidor. A veces es necesario, pero aquí habría sido pagar más para seguir generando miles de páginas que podían salir de la caché. Primero se mide y después se decide.

Si tienes una tienda online o una web con mucho catálogo y notas que se resiente con cada campaña, podemos revisarla. Lo hacemos dentro de nuestro servicio de mantenimiento y soporte, con medidas de cloud y ciberseguridad y sin tocar el trabajo de SEO que ya tienes. Trabajamos con empresas de Barcelona y de toda la provincia: cuéntanos qué te pasa y lo vemos.

Hablemos

Cuéntanos tu proyecto y te decimos cómo lo haríamos

Sin compromiso. Analizamos lo que necesitas, te proponemos la solución y un presupuesto cerrado. Trabajamos en toda la provincia de Barcelona, en persona o en remoto.

  • Un solo equipo para software, IA, web, sistemas y soporte
  • Propuesta cerrada y código propiedad de tu empresa
  • Mantenimiento y soporte los 365 días del año
  • C/ Ramón Llull, 15 · 08330 Premià de Mar (Barcelona)
  • 93 752 02 71
  • [email protected]

Pide tu presupuesto

Te respondemos personalmente. Tus datos solo se usan para contestarte.

Privacidad
Llamar Presupuesto