Reducir el tamaño de un sitio WordPress implica eliminar capas de complejidad acumuladas con el tiempo: plugins que quedaron obsoletos, páginas sin tráfico, bases de datos infladas con revisiones y spam, imágenes sin comprimir que pesan más que todo el resto. El resultado es un sitio más rápido, más barato de mantener, y más fácil de escalar.
En 30 segundos
- Un sitio WordPress «engordo» con los años acumula plugins sin uso, revisiones de posts, imágenes sin comprimir y páginas que nadie visita — todo eso tiene un costo real en velocidad y hosting.
- La base de datos es el problema más subestimado: en sitios activos de 2+ años, limpiarla puede reducir su tamaño entre un 20% y un 50%.
- Las imágenes representan el 60-80% del peso de página — antes de tocar código, convertí a WebP e implementá lazy loading.
- El flujo correcto es: auditar → eliminar → optimizar → cachear. Hacerlo al revés (cachear primero) esconde el problema sin resolverlo.
- Convertir una web corporativa compleja a un blog editorial puede reducir el mantenimiento semanal de horas a minutos, si se hace con redirecciones 301 correctas.
Qué es downsizing en WordPress y cuándo tiene sentido hacerlo
El downsizing de un sitio WordPress es el proceso de reducir su complejidad técnica y su peso físico: menos plugins activos, base de datos más limpia, estructura de páginas más simple, menos funcionalidades que nadie usa. No es lo mismo que «optimizar velocidad» (aunque tiene ese efecto), y tampoco es tirar todo a la basura.
Hay tres escenarios donde esto aparece seguido en 2026:
- Web corporativa que mutó a blog: empezaste con 200 páginas de servicios, precios, landing pages por campaña. Ahora el negocio cambió y el blog de artículos es lo que genera tráfico real. El resto es lastre.
- Sitio heredado de un freelancer anterior: tiene 40 plugins activos, cinco de ellos hacen lo mismo, y nadie sabe qué pasa si se desactiva alguno (spoiler: en la mayoría de los casos, nada).
- Reducción de costos de hosting: cuando el plan de hosting está limitado por disco o transferencia, y la solución es limpiar en vez de upgradear.
La diferencia que vale marcar: reducir el peso físico (GB de archivos, MB de base de datos) no es lo mismo que reducir la complejidad lógica (cantidad de plugins, páginas, taxonomías). Idealmente hacés los dos. Pero si solo tenés tiempo para uno, empezá por la complejidad lógica: los plugins son los que más impactan en tiempo de carga, no el tamaño de la BD.
Cómo auditar tu sitio WordPress antes de tocar nada
No empieces a borrar plugins al azar. Primero, un diagnóstico.
El punto de partida es la lista de lo que tenés activo: plugins instalados (activos e inactivos), cantidad de páginas y posts, tamaño de la librería multimedia, tamaño de la base de datos. En WordPress, el Tablero > Herramientas > Estado del sitio te da una radiografía básica. Para más detalle, Query Monitor o Health Check & Troubleshooting te dicen qué está consumiendo recursos.
Del lado del tráfico, Google Analytics (o el buscador de tu proveedor de hosting) te muestra qué páginas no tuvieron ninguna visita en los últimos seis meses. En sitios con 100+ páginas, es normal encontrar que el 40% del contenido no recibe tráfico orgánico ni directo. Esas son candidatas a redirigir y archivar, no a mantener activas.
Anotá tres números antes de arrancar:
- Tamaño de la base de datos (en phpMyAdmin o en el panel de tu hosting)
- Tiempo de carga de la homepage (Google PageSpeed Insights o GTmetrix)
- Cantidad de plugins activos
Esos tres números son tu línea de base. Con ellos vas a poder medir si lo que hacés después sirvió para algo.
Reducir plugins: metodología para no romper nada
Ponele que tenés 35 plugins activos. No es una exageración, es lo que encontrás en sitios con dos o más años sin revisión. Cada plugin es código PHP que se ejecuta en cada carga de página, incluso si ese plugin hace algo que el usuario nunca ve. En crear plugins personalizados para funcionalidades específicas profundizamos sobre esto.
El método que funciona es este: desactivar, esperar, medir, eliminar.
- Desactivá el plugin (no lo borres todavía)
- Esperá 48 horas y revisá que nada se rompió visualmente y que los formularios, menús y funcionalidades clave siguen andando
- Comparás el tiempo de carga antes y después
- Si no pasó nada en dos días y no hay mejora notable: eliminá el plugin definitivamente
¿Qué plugins son casi siempre bloat innecesario? Los constructores visuales que se instalaron «para probar» y nunca se usaron en producción. Los plugins de compartir en redes sociales que generan peticiones externas en cada carga. Los plugins de estadísticas propias cuando ya tenés Google Analytics. Los plugins de sliders, carruseles o popups de campañas viejas.
Un sitio bien configurado funciona con 10 a 15 plugins críticos. SEO, caché, seguridad, formularios de contacto, backups, y poco más. Todo lo que esté fuera de esa lista merece una justificación concreta.
Optimizar la base de datos: el trabajo sucio que más rinde
La base de datos de WordPress acumula basura con el tiempo. No porque WordPress sea malo, sino porque su configuración por defecto prioriza no perder datos sobre no guardar datos innecesarios.
Qué acumula una BD típica de dos años activos:
- Revisiones de posts: cada vez que guardás un artículo, WordPress guarda una copia. Por defecto, guarda todas. Un blog con 300 artículos puede tener 3.000 revisiones almacenadas.
- Comentarios spam: aunque los tengas en moderación, el registro de los spam queda en la tabla
wp_comments. - Transients expirados: datos temporales que plugins generan y a veces no limpian al expirar.
- Metadata huérfana: cuando borrás un post, la metadata asociada (campos personalizados, datos de plugins) a veces queda flotando en
wp_postmeta.
Según casos documentados en sitios en producción, una limpieza bien hecha puede reducir el tamaño de la base de datos entre un 20% y un 50% en sitios con varios años de operación.
Para hacerlo, WP-Optimize y WP-Sweep son las herramientas más usadas. Ambas tienen versión gratuita que alcanza para la mayoría de los casos. Configurá la limpieza de revisiones para mantener solo las últimas 3 o 5 versiones por post (editando wp-config.php con define('WP_POST_REVISIONS', 5);) y programá el mantenimiento automático semanal.
Antes de cualquier limpieza de BD: backup completo. No es negociable.
Simplificar la estructura: de web corporativa a blog editorial
Este es el caso más complejo porque involucra decisiones de arquitectura, no solo limpieza técnica.
Cuando tiene sentido: tenés un sitio con 150+ páginas estáticas que se actualizaron por última vez hace dos años, el equipo que las mantenía ya no existe, y el 80% del tráfico orgánico viene de los últimos 30 artículos del blog. Mantener toda esa estructura es costoso y no produce resultados. Tema relacionado: proteger formularios en tu sitio reducido.
El flujo para hacerlo bien:
- Identificar qué páginas tienen tráfico real: cualquier página con más de 100 visitas en los últimos seis meses merece quedarse o tener una redirección a algo equivalente.
- Redirigir, no eliminar: las páginas sin tráfico no se borran sin más; se redirigen con 301 a la sección más relevante del sitio. Google transfiere la autoridad del enlace y el usuario no cae en un 404.
- Cambiar la homepage: de landing estática a feed del blog. En WordPress: Ajustes > Lectura > Tu página de inicio muestra > Tus últimas entradas.
- Reducir taxonomías: si tenés 40 categorías y 200 etiquetas, simplificá. Más de 10-15 categorías activas suele ser señal de que la arquitectura de contenido no está bien pensada.
El mapa de redirecciones es la parte que más se subestima. Documentar todas las URLs que van a cambiar antes de ejecutar cualquier cambio estructural te ahorra semanas de problemas con SEO y con usuarios que llegaron a páginas viejas desde bookmarks o redes sociales.
Imágenes y multimedia: donde está la mayor ganancia de peso
Las imágenes representan entre el 60% y el 80% del peso de una página web típica. Es el área donde una hora de trabajo da los resultados más visibles.
Las acciones con mejor relación esfuerzo-resultado:
- Convertir a WebP: el formato WebP pesa en promedio un 30% menos que JPEG con la misma calidad visual. Plugins como ShortPixel o Imagify hacen la conversión en batch sobre imágenes ya subidas.
- Lazy loading: cargar imágenes solo cuando el usuario llega a verlas. WordPress lo activa por defecto desde la versión 5.5 con el atributo
loading="lazy", pero vale verificar que no esté deshabilitado por algún plugin. - Redimensionar antes de subir: una foto de 4000x3000px subida a un blog que la muestra a 800px de ancho es un desperdicio que nadie nota visualmente pero todos pagan en velocidad de carga.
- Borrar imágenes huérfanas: imágenes en la librería multimedia que no están referenciadas en ningún post ni página. Media Cleaner las detecta automáticamente.
Para videos: no los alojés en WordPress. Subí a YouTube o Vimeo y embebé. Un video de 50MB alojado localmente puede costar tanto en transferencia como todo el resto del sitio junto.
Resultado esperado: reducción de 30% a 50% en el peso de carga de páginas, con LCP (Largest Contentful Paint) mejorando entre 0.5 y 1.5 segundos según el estado inicial del sitio. Si estás en un hosting como donweb.com que soporta LiteSpeed, la combinación de imágenes optimizadas con caché de servidor da resultados especialmente buenos.
Caché y minificación: el último paso, no el primero
Acá está el error más común: instalar un plugin de caché como primer paso para «acelerar el sitio», sin haber hecho ninguno de los pasos anteriores.
La caché oculta problemas, no los resuelve. Si tu sitio carga en 6 segundos sin caché y con caché carga en 2.5 segundos, el problema sigue siendo que cargá en 6 segundos para usuarios que no están en caché (robots de Google, primer visitante después de limpiar caché, páginas dinámicas).
El orden correcto es: reducir complejidad → optimizar imágenes → limpiar BD → implementar caché.
Una vez que hiciste los pasos anteriores, LiteSpeed Cache (si el hosting lo soporta) o WP Super Cache son las opciones más efectivas. La configuración mínima que da resultados: caché de páginas completas activado, minificación de CSS y JavaScript combinados, caché de objetos si el hosting tiene Redis disponible. Cubrimos ese tema en detalle en automatizar procesos editoriales sin código.
Valores objetivo para Core Web Vitals post-optimización en 2026:
| Métrica | Valor objetivo (bueno) | Valor típico antes de optimizar |
|---|---|---|
| LCP (Largest Contentful Paint) | Menos de 2.5 segundos | 4-8 segundos |
| INP (Interaction to Next Paint) | Menos de 100ms | 200-500ms |
| CLS (Cumulative Layout Shift) | Menos de 0.1 | 0.2-0.4 en sitios con ads o iframes |
Errores comunes al reducir el tamaño de un sitio WordPress
Error 1: Borrar páginas sin redirigir. El 404 destruye la autoridad de dominio acumulada y manda a los usuarios al vacío. Toda página con más de un enlace externo merece una redirección 301. El plugin Redirection hace el seguimiento automático de 404s y permite crear reglas de redirección sin tocar código.
Error 2: Eliminar el tema inactivo equivocado. WordPress mantiene siempre un tema de reserva (Twenty Twenty-Four, por ejemplo). Si eliminás todos los temas secundarios y el tema activo falla por un update, WordPress queda con pantalla en blanco. Mantené siempre al menos un tema de fallback instalado.
Error 3: Hacer todo en producción. Las simplificaciones estructurales grandes, como cambiar la homepage o eliminar taxonomías masivamente, hacelas primero en un entorno de staging. WP Staging (el plugin) o el staging que ofrece tu hosting permiten probar cambios sin afectar el sitio live. ¿Cuántas veces alguien hizo «una limpieza rápida» en producción y terminó con el sitio caído dos horas? Demasiadas.
Error 4: Confundir «desactivar» con «haber eliminado el problema». Un plugin desactivado no ejecuta código PHP en el frontend, pero sus tablas siguen en la base de datos y sus archivos siguen ocupando disco. Desactivar es el primer paso, eliminar es el definitivo.
Esto se conecta con Downsizing website to blog, donde lo explicamos en detalle.
Si tu sitio web pasó a ser principalmente un blog, Downsizing website to blog explora cómo optimizar esta transición.
Si querés profundizar en esto, tenemos un análisis completo sobre Downsizing website to blog.
Si reducís tu web, Downsizing website to blog te muestra cómo hacerlo sin perder seguridad.
Preguntas Frecuentes
¿Cuántos plugins son demasiados en WordPress?
No hay un número mágico, pero 10 a 15 plugins activos es un rango manejable para la mayoría de los sitios. Lo que importa no es la cantidad sino el tipo: un plugin de seguridad bien configurado vale más que cinco plugins de optimización que se pisan entre sí. Si tenés más de 20 plugins activos y no podés justificar para qué sirve cada uno, es momento de auditar.
¿Qué pasa si elimino un plugin en WordPress?
Si el plugin no estaba haciendo nada visible, no pasa nada. Si estaba generando shortcodes, los verás como texto plano en las páginas donde se usaban. Si manejaba funcionalidades de formularios, pagos o integraciones externas, esas funciones dejan de operar. Por eso el proceso correcto es: desactivar primero, esperar 48 horas verificando que todo funcione, y solo entonces eliminar definitivamente. Lo explicamos a fondo en agregar funciones con plugins gratuitos.
¿Cómo reducir el tamaño de la base de datos de WordPress sin riesgos?
Hacé un backup completo antes de cualquier operación. Después, usá WP-Optimize o WP-Sweep para limpiar revisiones de posts, comentarios spam y transients expirados. Configurá el límite de revisiones en wp-config.php con define('WP_POST_REVISIONS', 5); para que no vuelva a acumularse. Programá esta limpieza semanal o mensual según la actividad del blog.
¿Conviene convertir mi web WordPress a solo blog?
Depende de dónde viene el tráfico real. Si el 80% de tus visitas orgánicas llegan al blog y las páginas estáticas tienen años sin actualización ni visitas, simplificar tiene sentido. El requisito es hacer el mapa de redirecciones antes de eliminar estructura. Si las páginas estáticas tienen backlinks externos o histórico de tráfico, redirigí a contenido equivalente en vez de borrar.
¿Cuánto puede mejorar la velocidad con estas optimizaciones?
En sitios con varios años sin mantenimiento, la combinación de limpieza de plugins + optimización de imágenes + limpieza de BD puede reducir el tiempo de carga en 40% a 60%. El mayor salto suele venir de las imágenes (conversión a WebP + lazy loading) y de eliminar plugins pesados que hacen peticiones externas. Medí antes y después con GTmetrix o PageSpeed Insights para tener números concretos.
Conclusión
Reducir el tamaño de un sitio WordPress no es un proyecto de un día, pero tampoco requiere tocar código ni contratar a nadie. El flujo es claro: auditás lo que tenés, eliminás lo que no sirve, optimizás imágenes y base de datos, y recién al final configurás caché para potenciar lo que ya está limpio.
El error más caro es hacer esto al revés: poner caché sobre un sitio con 40 plugins y 2GB de BD sin limpiar, y pensar que el problema está resuelto porque el score de PageSpeed subió diez puntos.
Si estás pensando en convertir una web corporativa compleja en un blog editorial simple, el trabajo extra está en el mapa de redirecciones, no en la parte técnica. Hacelo bien desde el principio y te ahorrás meses de problemas de SEO.