WordPress para periódicos y revistas:
cuando publicar todo el día rompe el sitio
Atendemos portales de noticias que publican ochenta notas al día con doce personas entrando al panel simultáneamente. Conocemos el patrón exacto de fallo de un medio digital porque llevamos años arreglándolo.
Un medio no es una web corporativa
Una página de empresa cambia tres veces al año. Un periódico cambia tres veces por hora. Esa simple diferencia lo rompe todo.
El caché, que en cualquier otro sitio web es la solución mágica, en un medio suele ser el problema principal: si cachéas de forma agresiva, un editor publica una nota urgente (Breaking News) y no aparece en portada. Si decides no cachear para mantener el sitio "en vivo", el servidor se cae estrepitosamente el día que una nota local se vuelve nacional o viral.
Súmale a esa ecuación lo demás:
- Un archivo con decenas de miles de entradas históricas.
- Una docena de cuentas con permisos de administrador haciendo consultas pesadas.
- Anuncios (Programmatic) que cargan desde cuatro redes de terceros distintas.
- Una redacción que sube fotos directamente desde el teléfono a la biblioteca de medios sin pasarlas por Photoshop.
Portada y Últimas 24h
- Caché de tiempo de vida corto (TTL).
- Purga automática e inmediata al publicar o editar.
- Optimizado para lectores recurrentes diarios.
Archivo Histórico (2012-2023)
- Caché perimetral ultra-agresivo (Edge).
- TTL de semanas o meses.
- Desvía el 80% del tráfico SEO lejos de PHP y MySQL.
Entre la caída del servidor y la nota que no aparece hay una configuración de arquitectura correcta (Caché de dos velocidades), y casi ningún medio que auditamos la tiene implementada de inicio.
El patrón que se repite en todos los diarios regionales
Lo hemos visto tantas veces que en la primera llamada ya sabemos qué preguntar. El ciclo de la muerte SEO en los medios locales funciona así:
1. Se llena el servidor. El proveedor de hosting avisa que se acabó el espacio en disco o el límite de base de datos.
2. La limpieza impulsiva. Alguien decide borrar notas viejas para hacer sitio. Eliminan dos mil, tres mil entradas del archivo de 2014 a 2016; las más antiguas, justificando que "esas ya no las lee nadie".
3. El colapso silencioso. Al mes siguiente, el tráfico general del portal cae en picada y nadie en la redacción entiende por qué.
¿Por qué cayó? Porque esas notas antiguas sí las veía alguien: Google. Y ahora tienes tres mil URLs en el índice del buscador devolviendo errores 404 de golpe. URLs que estaban enlazadas internamente y que recibían enlaces de otros diarios, cortadas de tajo, sin una sola redirección (301).
El choque entre Sistemas y SEO
Lo que hace que este error sea epidémico es el perfil de quien administra el sitio. En un periódico regional, el responsable técnico suele ser el jefe de Sistemas (IT): alguien que sabe muchísimo de servidores físicos, redes locales y cuentas de correo. Él mira Analytics y el dashboard de AdSense, porque de ahí sale la nómina.
Pero la consola de Google Search Console no la abre nunca. Y es justo ahí donde Google lleva meses mandando alertas rojas de "Páginas no encontradas (404)". Cuando entramos a rescatar un diario, lo primero que pedimos es acceso a Search Console. En la mitad de los casos, ni siquiera está creada.
Los picos virales no son el problema; la falta de plan sí
Un medio digital normal vive con un tráfico predecible y estable hasta que, de pronto, un martes a las 11:00 am, ya no. Una nota se vuelve viral, un hecho de nota roja local capta atención nacional, y el portal recibe en dos horas las visitas que normalmente recibe en un mes.
En un hosting convencional (compartido o VPS sin tunear), esto choca contra un muro de concreto: el límite de procesos concurrentes (PHP Workers). Cuando la cola se llena, el servidor tira la toalla y el lector que hace clic en Twitter ve una pantalla blanca o un terrible "Error 503 Service Unavailable".
Un medio serio necesita saber tres cosas antes de que explote la noticia: 1) Cuál es su techo técnico real medido en visitas por segundo, 2) Qué componente colapsa primero cuando se alcanza ese techo (¿La base de datos? ¿El ancho de banda?), y 3) Qué elementos de la portada se pueden "apagar" temporalmente y en caliente para mantener la nota principal viva.
Los anuncios te están costando el posicionamiento
Esta es la charla difícil que tenemos que tener con todo medio que vive de la publicidad programática. Las redes de anuncios inyectan scripts pesados de terceros, insertan banners dinámicos que empujan el texto mientras se dibuja la página, y secuestran el hilo principal del teléfono móvil justo cuando el lector intenta hacer scroll.
1. Más Banners
Se insertan más scripts publicitarios para intentar subir la recaudación mensual.
2. Caída Técnica
Las métricas CLS (saltos visuales) e INP (retraso en clics) entran en zona roja.
3. Penalización SEO
Google degrada el posicionamiento en Discover y resultados de búsqueda.
Cae el tráfico base, baja la recaudación, y el medio decide inyectar aún más banners.
No te vamos a pedir que quites la publicidad, sabemos perfectamente que de ahí pagas la nómina. Lo que hacemos como ingenieros es domarla: reservamos el espacio exacto (min-height) de cada bloque antes de que cargue para que el texto no salte, diferimos los anuncios que no están en la primera pantalla, y medimos qué red de relleno te está costando más de lo que te aporta. (A veces, esa quinta red remanente te paga $4 USD al mes pero retrasa la carga de todas tus noticias un segundo entero).
Las dos capas de caché que colapsaron el portal
Un periódico de alcance estatal nos contactó porque el portal estaba lentísimo, con errores aleatorios, y nadie en la redacción sabía por qué. Estaban pagando la capa más alta de WordPress.com Business, y un asesor previo, en un intento desesperado de darles velocidad, les había plantado Cloudflare con reglas totales por encima.
Tenían dos monstruos de caché empresarial compitiendo. Cada uno servía contenido por su cuenta con su propia idea de "qué es lo más reciente". Los editores publicaban la nota de portada y no salía. Entraban en pánico, purgaban Cloudflare, y la nota seguía invisible porque el caché inferior la retenía.
La intervención de rescate:
- Sacamos a Cloudflare de la ruta del proxy (dejándolo como gestor DNS).
- Revisamos el módulo de optimización nativo (Jetpack) que el medio ya estaba pagando en su plan y que nadie había configurado correctamente.
- Purgamos de treinta (30) plugins a solo siete (7) estrictamente necesarios.
- Encontramos videos altísimos en peso subidos directo a la biblioteca, cuando su licencia ya incluía un terabyte de VideoPress que llevaba dos años desperdiciándose.
Ese portal no necesitaba comprar más herramientas "mágicas". Necesitaba que un ingeniero entendiera y orquestara las que ya estaban pagando.
Lo que implementamos en un medio
Caché de dos velocidades
Perimetral agresivo y duradero para tu hemeroteca y archivo, y un caché corto para la portada con purga automática vía API cada vez que un editor presiona el botón de "Actualizar".
Rescate del Archivo
Localizamos con scripts todas las URLs que están devolviendo 404, decidimos con tu equipo cuáles merecen redirección 301 a categorías y recuperamos desde la Wayback Machine el contenido de valor que borraron por error.
Flujo Editorial y Roles
Revisamos por qué doce practicantes tienen permisos de 'Administrador' absoluto. Bajamos a cada miembro de la redacción al rol de 'Editor' o 'Autor' que realmente necesita, protegiendo el núcleo de la web.
Imágenes en Origen (Al vuelo)
Logramos que los reporteros sigan subiendo fotos enormes desde el iPhone en la calle, pero que el servidor las intercepte, las convierta a formato WebP/AVIF y las redimensione antes de guardarlas, sin que nadie tenga que acordarse de hacerlo a mano.
Cómo empezamos el rescate
Escríbenos
Por WhatsApp con el dominio del periódico. En la primera respuesta gratuita ya te diremos qué vimos desde fuera (servidor, cabeceras, bloqueos de red) y si presentas los síntomas del patrón clásico.
Diagnóstico Base
Se cobra (y se descuenta íntegro del proyecto si avanzamos). Aquí entramos a las tripas del sitio, conectamos Search Console, medimos cuellos de botella y armamos el plan de contingencia.
Estabilización
Si el portal está caído o bajo ataque DDoS (muy común en medios), el orden se invierte: primero contenemos y levantamos la web con un proxy inverso, y después diagnosticamos quién o qué lo tiró.
Lunes a viernes, 8:00 a 20:00. Fines de semana atendemos emergencias (sabemos perfectamente que en un medio las caídas suelen ocurrir en sábado o domingo).
Preguntas frecuentes de redacción
Sí hay remedio. Esas URLs 404 siguen existiendo en el índice de Google y en los enlaces que otros sitios te hicieron en el pasado. Se puede levantar un mapeo, redirigir lo que tiene un equivalente actual (categorías) y recuperar desde Wayback Machine las notas exclusivas que valga la pena salvar. Cuanto antes atajemos la hemorragia, mejor, pero rara vez es un caso perdido por completo.
A veces sí, y te lo sustentaremos con logs de errores y métricas. Pero antes de pedirte que pagues un servidor más caro, revisamos si el problema es el tamaño del plan o es lo que le estás pidiendo al plan que procese. Hemos resuelto más crisis de periódicos apagando consultas inútiles a la base de datos que comprando más memoria RAM.
No, ese no es el objetivo. Lo que se reduce es el lastre técnico: redes secundarias que rinden poco dinero pero cuestan muchos recursos de carga. Tu inventario principal de anuncios (los banners rentables) se mantiene intacto, pero los inyectamos en el DOM (la estructura de la página) de forma que no destruyan la experiencia del lector ni penalicen el índice de Google.
Sí, administramos tanto medios autoalojados (DigitalOcean, AWS, Kinsta) como medios en la plataforma comercial de WordPress.com Business/Commerce. Conocemos al dedillo los límites de su arquitectura corporativa y sabemos exactamente qué herramientas de optimización ya tienes incluidas en tu mensualidad y no estás utilizando.
Sí. En casos de caída total ("White screen of death" o ataques DDoS), el protocolo se invierte: primero trabajamos para levantar el portal y restablecer el servicio a los lectores, y una vez estabilizado, nos sentamos a auditar por qué se cayó y cómo blindarlo a futuro.