Datos de Autocarga de WordPress: Qué son y cómo limpiarlos

La Salud del Sitio había estado marcando un problema crítico en uno de mis sitios durante meses: Las opciones cargadas automáticamente podrían afectar el rendimiento.

Lo ignoré. El sitio funcionaba bien.

Entonces alguien me preguntó por qué el panel de administración tardaba casi diez segundos en cargarse cuando la página de inicio aparecía al instante. Así que, finalmente, revisé el tamaño de la carga automática y encontré megabytes de opciones en la base de datos, la mayoría escritas por plugins que había desinstalado hacía años.

Lo frustrante es que la mayoría de los consejos sobre este tema están desactualizados. WordPress 6.6 cambió la forma en que funciona la carga automática, y la consulta que casi todas las guías publican ahora devuelve el número incorrecto.

Muchos de los consejos de limpieza estándar tampoco reducen el tamaño de la carga automática, por razones ocultas en el núcleo de WordPress.

En esta publicación, te mostraré qué son los datos de carga automática de WordPress, cómo medirlos correctamente en una instalación moderna, qué se puede eliminar de forma segura y cómo limpiarlos sin romper tu sitio.

Aquí están los puntos clave:

• Los datos de carga automática se cargan en cada solicitud que llega a WordPress, incluidas las páginas de administración, las llamadas REST y los trabajos cron, por lo que el almacenamiento en caché de páginas nunca te lo oculta.
• WordPress marca un problema crítico de Salud del Sitio por encima de 800 KB de opciones cargadas automáticamente, que es lo más parecido a un límite oficial que encontrarás.
• La consulta SQL en la mayoría de las guías ahora subestima el recuento. WordPress 6.6 reemplazó los antiguos valores de carga automática sí/no con cinco valores posibles, por lo que filtrar por autoload='yes' omite filas más nuevas.
• Borrar transitorios expirados apenas cambia el tamaño de tu carga automática. Los transitorios creados con una fecha de expiración no se cargan automáticamente en primer lugar, por eso los plugins de limpieza de bases de datos parecen no hacer nada aquí.
• La verdadera hinchazón suelen ser las opciones huérfanas de plugins, dejadas atrás por plugins que eliminaste hace años, ya que nada las limpia automáticamente.
• El Optimizador de DB de Duplicator mide el tamaño de la carga automática como parte de su puntuación de salud de la base de datos, lo que lo convierte en la forma más fácil de seguir el número a lo largo del tiempo. Borrar opciones cargadas automáticamente sigue siendo un trabajo manual.
• Desactivar la carga automática es más seguro que eliminar. Los datos permanecen en la base de datos en caso de que un plugin los necesite, y el cambio es reversible.
• Nunca edites wp_options sin una copia de seguridad actual. Estás trabajando en la única tabla que puede dejar tu sitio web completamente inactivo.
• Si el tamaño de carga automática vuelve a aumentar en pocos días tras una limpieza, un plugin lo está reescribiendo en cada ejecución, y no habrá limpieza que valga.

Tabla de Contenidos

¿Qué son los datos de carga automática en WordPress?

Cada sitio de WordPress almacena sus ajustes en una tabla de base de datos llamada wp_options. La URL de tu sitio vive ahí. También lo hace tu lista de plugins activos, los ajustes del tema y la configuración de casi todos los plugins que has instalado.

Cada fila de esa tabla tiene una columna llamada autoload. Esa columna responde a una pregunta: ¿debe WordPress cargar esta fila en cada página individual o solo cuando algo la solicita?

Cuando la respuesta es sí, la opción se carga automáticamente. Eso es todo lo que significa el término. Se carga automáticamente, la necesite o no la página actual.

WordPress hace esto por una buena razón. En lugar de ejecutar una consulta de base de datos separada cada vez que un plugin solicita un ajuste, obtiene todas las opciones de carga automática en una sola consulta al inicio de la solicitud y las mantiene en memoria. Una consulta es mejor que unos cuantos cientos pequeñas.

Esto es lo que normalmente termina almacenado como opciones de carga automática:

• Ajustes principales sin los cuales tu sitio no puede funcionar, como siteurl, home, active_plugins, template y stylesheet
• Configuración de plugins, a menudo almacenada como un único array serializado grande por plugin
• Claves de licencia y datos de activación de plugins y temas premium
• Respuestas de API cacheadas que un plugin guardó como una opción normal en lugar de un transient adecuado
• Restos de plugins que eliminaste, que nada limpia por sí solo
• Transients creados sin tiempo de expiración, que se cargan automáticamente por defecto

El diseño está bien. Es la acumulación lo que causa problemas.

¿Por qué los datos de carga automática ralentizan tu sitio?

Cada solicitud que llega a WordPress paga por el tamaño de tu carga automática. Esto afecta no solo a las vistas de página de los visitantes, sino también a las pantallas de administración, las llamadas a la API REST, los trabajos de WP-Cron, las solicitudes AJAX y cada tarea en segundo plano que tus plugins activan.

El coste no es solo la consulta. Los valores de las opciones se almacenan serializados, por lo que PHP tiene que deserializarlos todos en memoria en cada carga. Una tabla de carga automática de 3 MB significa que tu sitio reconstruye 3 MB de arrays PHP antes de que muestre una sola palabra de contenido.

Eso es memoria y CPU, en cada solicitud, para siempre.

El caché de páginas no ayuda aquí. Una caché sirve a los visitantes una página HTML terminada, por lo que esas solicitudes se saltan WordPress por completo. Las tuyas no.

Aquí es donde una tabla de carga automática hinchada se manifiesta primero:

• wp-admin se siente lento mientras que el front-end se mantiene rápido, ya que las páginas de administración nunca se cacheadan
• El editor de bloques se ralentiza al guardar o cargar porque cada solicitud del editor pasa por una carga completa de WordPress
• Los carritos y el proceso de pago de WooCommerce van lentos, ya que esas páginas están excluidas del caché por diseño
• Los usuarios conectados obtienen un sitio más lento que los demás, lo que hace que el problema sea difícil de reproducir
• Los trabajos de Cron se acumulan, porque cada uno soporta la misma sobrecarga

Si tu host alguna vez te dijo que la base de datos se ve bien mientras tu panel de control se arrastra, esta es la razón habitual. El tamaño de autoload no aparece en las métricas que la mayoría de los hosts revisan.

Sin embargo, quiero ser honesto sobre el alcance. La hinchazón de autoload rara vez es lo único que ralentiza un sitio, y eliminarla no rescatará un sitio con un host lento e imágenes no optimizadas.

Es solo la parte que casi nadie revisa, y crece silenciosamente cada mes que mantienes tu sitio en funcionamiento.

¿Cuántos datos de carga automática de WordPress son demasiados?

Busca esta pregunta y obtendrás cinco respuestas diferentes. Algunas guías dicen 300KB, otras dicen 1MB.

WordPress 6.6 marcó la línea para todos. La Salud del Sitio ahora muestra un problema crítico cuando tus opciones totales de autoload exceden los 800KB.

Así es como interpreto los rangos en la práctica:

• Menos de 800KB: saludable. La Salud del Sitio se mantiene en silencio y no tienes nada que perseguir.
• 800KB a 1MB: vale la pena echarle un vistazo. Estás por encima del umbral principal y normalmente son uno o dos plugins los que lo causan.
• 1MB a 3MB: un problema real. Espera pantallas de administración notablemente más lentas, especialmente en hosting compartido.
• Más de 3MB: algo está escribiendo activamente basura de forma programada, y la limpieza no servirá hasta que lo encuentres.

Puedes aumentar el umbral con el filtro site_status_autoloaded_options_size_limit, pero eso solo oculta la advertencia. Las consultas siguen ejecutándose con el mismo tamaño.

El tamaño por sí solo tampoco te dice todo. Cien filas huérfanas pequeñas valen menos tu atención que un array serializado de 2MB de un plugin de slider que dejaste de usar en 2022.

Persigue a los mayores infractores, no al recuento.

Una pieza más de buen comportamiento que vale la pena conocer: desde WordPress 6.6, cualquier opción nueva de más de 150KB se establece para no cargarse automáticamente por defecto.

El núcleo tomó esa decisión porque las opciones de autoload sobredimensionadas eran un problema de rendimiento muy común. Se puede filtrar a través de wp_max_autoloaded_option_size, aunque aumentarlo es una mala idea.

Esa protección solo se aplica de ahora en adelante. Cualquier cosa que ya esté en tu base de datos de antes sigue cargándose automáticamente exactamente como siempre lo hizo.

Por qué la mayoría de las guías de carga automática ahora te dan el número incorrecto

Durante la mayor parte de la historia de WordPress, la columna autoload contenía uno de dos valores: yes o no. Simple. Cada tutorial escrito sobre datos de autoload se basaba en esa suposición.

WordPress 6.6 lo reemplazó con cinco valores posibles:

• on: explícitamente configurado para autoload, y siempre lo estará
• off: explícitamente configurado para no autoload, y nunca lo hará
• auto: no se dio ninguna preferencia explícita, por lo que WordPress decide (y actualmente lo carga automáticamente)
• auto-on: WordPress decidió dinámicamente que debería cargarse automáticamente
• auto-off: WordPress decidió dinámicamente que no debería, generalmente porque el valor es superior a 150KB

Las filas existentes no se migraron. Las opciones creadas antes del cambio conservan sus valores originales de yes y no, que el núcleo trata como equivalentes a on y off.

Por lo tanto, cualquier sitio que haya estado funcionando durante la actualización 6.6 ahora contiene una mezcla de valores antiguos y nuevos en la misma columna.

Mucha gente te dirá que ejecutes una consulta filtrada por autoload='yes'. En un sitio moderno, esa consulta omite silenciosamente cada opción escrita desde la 6.6, junto con cualquier cosa del núcleo marcada como auto o auto-on.

Obtienes un número. Simplemente no es tu número, y siempre es demasiado bajo.

La solución es verificar contra cada valor que WordPress trata como autoloading. El núcleo expone exactamente esa lista a través de wp_autoload_values_to_autoload(), que devuelve yes, on, auto-on y auto por defecto.

¿Qué consulta SQL deberías ejecutar en su lugar?

Si tienes acceso a phpMyAdmin o a la herramienta de base de datos de tu host, estas dos consultas te dirán casi todo lo que necesitas. Ejecútalas contra la base de datos de tu sitio en la pestaña SQL.

Antes de ejecutar nada contra wp_options, crea una copia de seguridad. Estas dos consultas solo leen datos y no cambian nada, pero la siguiente sección te hará editar filas, y es mejor prevenir que curar.

Empieza con tu tamaño total de autoload:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb,

COUNT(*) AS option_count

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

Eso devuelve tu total en kilobytes junto con un recuento de cuántas opciones están involucradas. Compáralo con el umbral de 800 KB de la última sección.

Luego averigua qué es lo responsable:

SELECT option_name,

ROUND(LENGTH(option_value) / 1024, 2) AS size_kb,

autoload

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')

ORDER BY LENGTH(option_value) DESC

LIMIT 20;

Esto te da las veinte opciones autoloaded más grandes por nombre, con sus tamaños individuales y su valor de autoload actual. En la mayoría de los sitios, las tres o cuatro primeras filas representan la mayoría del problema.

Dos cosas a tener en cuenta antes de copiar estas:

• Tu prefijo de tabla podría no ser wp_. Muchas instalaciones usan algo personalizado por razones de seguridad. Comprueba wp-config.php para ver el valor de $table_prefix y cámbialo en la consulta.
• Multisitio funciona de manera diferente. Cada sub-sitio tiene su propia tabla de opciones (wp_2_options, wp_3_options, y así sucesivamente), además de una tabla wp_sitemeta para toda la red. Necesitarás revisarlas por separado.

Si prefieres usar la línea de comandos, WP-CLI maneja ambos trabajos en una línea cada uno. Esto devuelve tu total en bytes:

wp option list --autoload=on --format=total_bytes

Y esto lista las opciones autoloaded con sus tamaños almacenados:

wp option list --autoload=on \

--fields=option_name,autoload,size_bytes \

--format=table

No todo el mundo quiere tocar una consola de base de datos, y no tienes por qué. La siguiente sección cubre dos rutas que se mantienen dentro del panel de administración de WordPress.

¿Cómo comprobar el tamaño de carga automática de tu WordPress?

No puedes arreglar lo que no has medido, y querrás medir de nuevo después de cada cambio que hagas.

Hay tres maneras de obtener el número, dependiendo de lo cerca que quieras estar de la base de datos.

Opción 1: Salud del sitio (la ruta más rápida)

WordPress ya comprueba esto por ti. Ve a Herramientas » Salud del sitio y abre la pestaña Estado, luego busca Las opciones autoloaded podrían afectar al rendimiento en la lista.

Expándela y obtendrás tu tamaño total.

La pega es que esta comprobación solo aparece una vez que superas los 800 KB. El silencio no significa que estés en cero; significa que estás por debajo del límite. También te da una única instantánea sin historial y sin forma de actuar sobre lo que te muestra.

Opción 2: Puntuación de Salud de DB Optimizer (La más fácil de seguir)

Si quieres rastrear el tamaño de autoload a lo largo del tiempo en lugar de comprobarlo una vez, DB Optimizer lo pone en un panel.

Abre DB Optimizer y obtendrás una puntuación de salud de la base de datos de 0 a 100. Cinco barras codificadas por colores desglosan la puntuación: sobrecarga de tablas, transitorios, revisiones, tamaño de autoload y elementos de papelera.

Permíteme aclarar lo que hace y lo que no hace. DB Optimizer mide tu tamaño de autoload y lo informa. No borra las opciones cargadas automáticamente.

Eliminar datos cargados automáticamente sigue siendo un trabajo manual, y lo explicaré a continuación.

Lo que sí limpia son las revisiones de entradas, borradores automáticos, contenido en la papelera, comentarios de spam, transitorios caducados, pingbacks, trackbacks y caché de oEmbed. Esos realmente merecen ser limpiados. Son simplemente un problema diferente del autoload.

Antes de comenzar una limpieza manual, no está de más hacer una limpieza rápida de la base de datos. Abre la pestaña Limpieza y ejecuta todas las optimizaciones disponibles.

Luego, ve a la pestaña Tablas. Optimiza todas las tablas con sobrecarga.

Pulsa Actualizar Puntuación en el panel y observa qué sucede con el tamaño de autoload:

• La puntuación aumenta notablemente: los transitorios que no caducan formaban parte de tu problema y has eliminado parte de él.
• La puntuación apenas se mueve: tu hinchazón son opciones de plugins huérfanas, y ninguna herramienta de limpieza las tocará. Ve directamente a los métodos manuales.
• La puntuación aumenta y vuelve a bajar en unos días: un plugin activo está reescribiendo las opciones cargadas automáticamente en cada ejecución.

Este último caso merece ser detectado a tiempo. Te ahorra tener que limpiar las mismas filas cada mes y preguntarte por qué nada se mantiene.

DB Optimizer también te advierte cuando no tienes una copia de seguridad reciente y enlaza directamente a la creación de una. Está incluido gratis con los planes Duplicator Pro y Elite, para que puedas mantener tu sitio seguro y funcionando sin problemas.

Opción 3: Ejecuta la consulta tú mismo (la más precisa)

Los comandos SQL y WP-CLI de la sección anterior te dan el número exacto y la lista completa clasificada, sin ningún umbral que te oculte nada.

Esta es la ruta que uso cuando estoy a punto de cambiar algo, porque es la única que te muestra el valor de autoload actual de cada fila. Necesitas eso antes de empezar a editar.

¿Por qué una limpieza de base de datos no arregló tu tamaño de autoload?

Aquí está el consejo que encontrarás en casi todos los artículos sobre este tema: limpia tus transitorios y tu tamaño de autoload disminuirá.

Es mayormente incorrecto, y el núcleo de WordPress es donde puedes demostrarlo.

Mira lo que hace set_transient() cuando crea un transitorio. Si pasas un tiempo de expiración, WordPress almacena ese transitorio con autoload establecido en falso. Solo los transitorios creados sin fecha de expiración se cargan automáticamente, y esos son la minoría.

Los transitorios caducados son, por definición, transitorios que tuvieron una expiración. Esto significa que nunca se cargaron automáticamente. Puedes eliminar cincuenta mil de ellos, reducir tu tabla wp_options en cien megabytes y mover tu número de autoload en casi nada.

Ambas limpiezas merecen la pena. Una tabla wp_options enorme ralentiza las consultas, hincha las copias de seguridad y provoca que las migraciones fallen. Es simplemente un problema diferente con una solución diferente, y confundir ambas es la razón por la que tanta gente piensa que su plugin de limpieza está roto.

¿Qué queda entonces una vez que los transitorios han desaparecido? En mi experiencia, casi siempre es una de estas opciones:

• Arrays de configuración serializados de plugins que desinstalaste. La mayoría de los plugins nunca limpian sus propios datos al ser eliminados, y esa configuración se sigue cargando automáticamente para siempre.
• Datos de licencia y activación de plugins premium, incluidos aquellos cuyas licencias caducaron hace años.
• Respuestas de API cacheadas almacenadas como opciones normales en lugar de transitorios adecuados, generalmente por plugins de feeds sociales, analíticas o SEO.
• Opciones tipo registro que crecen sin límite, donde un plugin añade datos a una única fila de opción en cada evento en lugar de usar su propia tabla.
• Transitorios que no caducan, que son la verdadera excepción aquí y el único tipo con el que una limpieza de transitorios ayudará.

Ninguna de esas se soluciona con una herramienta de un solo clic. Esa es la respuesta honesta, y es por eso que la siguiente sección requiere intervención manual.

¿Cómo se limpian los datos de carga automática de WordPress?

No existe un plugin que solucione esto con un solo clic. Borrar opciones cargadas automáticamente significa identificar filas específicas y decidir qué hacer con cada una.

Suena peor de lo que es. En la mayoría de los sitios, tres o cuatro filas representan la mayor parte del problema, por lo que tomarás tres o cuatro decisiones en lugar de cientos.

Aquí están los tres métodos, ordenados de más seguro a más complejo:

• Desactivar la carga automática para opciones pesadas: cambia el valor de una sola columna sin eliminar nada, y es completamente reversible.
• Eliminar opciones huérfanas de plugins eliminados: borra permanentemente las filas dejadas por plugins que ya no están.
• Reemplazar el plugin que sigue escribiendo datos: la única solución que funciona cuando algo está regenerando el hinchazón en cada ejecución.

Haz una copia de seguridad completa antes de empezar cualquiera de ellas. Duplicator Pro crea una copia completa de tu base de datos y archivos en pocos minutos, y su restauración de un clic significa que una mala declaración UPDATE te cuesta diez minutos en lugar de tu fin de semana.

Método 1: Desactivar la carga automática para opciones pesadas

Empieza por aquí, porque no se elimina nada. Estás cambiando el valor de una columna, y puedes revertirlo.

Toma la lista de los principales infractores de tu consulta y trabaja sobre ella. Para cada opción grande, la pregunta es si el sitio necesita esos datos en cada carga de página.

Antes de deshabilitar la carga automática, verifica cómo y dónde el plugin lee la opción. Algunos arrays de configuración son legítimamente necesarios en las solicitudes del front-end; otros son solo para el administrador o se acceden raramente y es mejor cargarlos bajo demanda.

Para detener la carga automática de una opción, actualiza su valor de carga automática:

UPDATE wp_options

SET autoload = 'off'

WHERE option_name = 'your_option_name_here'

AND autoload IN ('yes', 'on', 'auto', 'auto-on');

En WordPress 6.6+, usa off. WordPress también reconoce el valor heredado no como no cargado automáticamente, por lo que se mantiene compatible con instalaciones más antiguas.

WP-CLI lo maneja en un solo comando, y acepta on, off, yes o no:

wp option set-autoload your_option_name_here off

Los datos permanecen exactamente donde están. WordPress simplemente deja de cargarlos en cada solicitud y los recupera bajo demanda cuando algo llama a get_option() en su lugar.

Después de cada cambio, haz dos cosas: vuelve a ejecutar tu consulta de tamaño para confirmar que el número ha bajado y carga tanto tu frontend como wp-admin para confirmar que nada se ha roto.

No agrupes veinte cambios y luego pruebes. Si algo sale mal, querrás saber qué fila lo hizo.

Una cosa a tener en cuenta: si una opción vuelve a cargarse automáticamente después de una actualización de un plugin, ese plugin está reescribiendo el valor en la activación o actualización. Tu cambio no falló; fue sobrescrito.

Eso merece un ticket de soporte con los desarrolladores del plugin, y es una fuerte señal de que te diriges al Método 3.

Método 2: Eliminar opciones huérfanas de plugins eliminados

La eliminación es permanente, por lo que este método requiere más cuidado que el anterior.

Trabaja en tu lista de los principales infractores y empareja cada nombre de opción con el plugin que lo creó. La mayoría usa un prefijo reconocible, aunque no todos son obvios.

Busca el nombre de la opción antes de tocarlo, ya que un nombre que parece abandonado a veces pertenece a algo que todavía se está ejecutando.

Luego confirma que el plugin realmente se ha ido.

Desactivado no es desaparecido. Un plugin desactivado todavía tiene sus archivos en el disco y recuperará su configuración cuando lo reactives, por lo que eliminar sus opciones a mitad de la desactivación simplemente pierde tu configuración.

Antes de eliminar una opción, verifica que has seleccionado la fila exacta que pretendes eliminar. Esta consulta de solo lectura muestra el ID de la opción, el nombre, el estado actual de carga automática y el tamaño almacenado sin cambiar nada:

SELECT option_id, option_name, autoload, LENGTH(option_value) AS size_bytes

FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Una vez que estés seguro, elimina la fila:

DELETE FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Nunca ejecutes un DELETE con un comodín LIKE en esta tabla a menos que hayas leído cada fila que coincide primero. Un patrón que parece específico puede coincidir con mucho más de lo que esperas, y wp_options es la única tabla donde un error derriba todo el sitio en lugar de romper una sola función.

Cuando no puedas identificar una fila en absoluto, no la elimines. Cambia su carga automática a desactivada usando el Método 1 y déjala ahí.

Obtienes el beneficio completo de rendimiento, los datos sobreviven y puedes revertirlo en segundos si algo resulta necesitarlo.

Este es el punto en el que la copia de seguridad deja de ser una formalidad. Estás eliminando filas de la tabla más importante de tu base de datos de WordPress, y la URL de recuperación ante desastres de Duplicator Pro restaurará el sitio incluso si una consulta incorrecta te bloquea el acceso a wp-admin.

Método 3: Reemplazar el plugin que sigue escribiendo en él

Si el tamaño de tu carga automática vuelve a superar 1 MB a los pocos días de una limpieza, deja de limpiar. Algo se está escribiendo activamente en cada ejecución, y estarás haciendo esto para siempre.

Los sospechosos habituales, según lo que sigo encontrando:

• Plugins de sliders y constructores de páginas que almacenan enormes matrices de configuración serializadas
• Plugins de análisis y estadísticas que registran en una fila de opciones en lugar de su propia tabla
• Plugins de seguridad que guardan registros de eventos como opciones
• Gestores de redirección abandonados, donde cada regla de redirección vive en una opción en crecimiento
• Plugins de feeds sociales que almacenan en caché las respuestas de la API como opciones de carga automática simples

Encontrar al culpable es más fácil de lo que parece. Anota tus principales infractores, espera unos días y vuelve a ejecutar la consulta. Lo que haya crecido es tu respuesta.

Cambiar un plugin en un sitio en producción es donde esto se vuelve arriesgado, y es la única parte de este proceso que nunca haría primero en producción.

Duplicator Pro te permite convertir cualquier copia de seguridad completa del sitio en un sitio de staging con unos pocos clics, sin una cuenta de hosting separada ni transferencias manuales de archivos.

Prueba el reemplazo allí, confirma que el sitio todavía funciona y que el tamaño de autoload se mantiene estable, luego haz el cambio en producción.

¿Cómo evitar que los datos de carga automática de WordPress vuelvan a aparecer?

La limpieza no es un trabajo de una sola vez, porque los datos de autoload de WordPress crecen como un efecto secundario del mantenimiento normal del sitio. Cada plugin que pruebas deja algo atrás.

Algunos hábitos evitan que se te escape de nuevo:

• Revisa tu puntuación mensualmente, o después de cualquier lote de cambios de plugins. El panel de control de DB Optimizer hace que esto sea un trabajo de diez segundos, pero Site Health funciona bien si prefieres no añadir un plugin.
• Elimina los plugins correctamente en lugar de desactivarlos. Desactivarlos deja todas las opciones en su lugar. Eliminar al menos le da a un plugin bien construido la oportunidad de limpiar, aunque muchos todavía no lo hacen.
• Revisa la opción antes de desinstalar. Si sabes que un plugin deja datos atrás, anota los nombres de sus opciones mientras todavía está instalado y es fácil de identificar.
• Instala menos plugins. Es el consejo menos satisfactorio de esta lista y el más efectivo. Cada plugin que no pruebas es un dato de autoload que nunca tienes que limpiar.
• Mantén una copia de seguridad actual en ejecución según un horario, para que la limpieza de la base de datos sea una decisión de bajo riesgo en lugar de una nerviosa.
• Vigila Site Health en lugar de esperar a que el sitio se sienta lento. Para cuando notes el retraso, normalmente ya has superado los 2 MB.

Preguntas Frecuentes (FAQs)

Los datos de carga automática de WordPress son un hábito de mantenimiento, no una solución única.

La hinchazón de la carga automática es el costo acumulado de cada complemento que tu sitio ha intentado alguna vez. Vale la pena reflexionar sobre ello, porque replantea el problema.

No es un error ni una señal de que hayas hecho algo mal. Es el residuo ordinario de ejecutar un sitio de WordPress durante algunos años, y nada en WordPress lo limpia por ti.

Prefiero ser directo sobre el trabajo que implica. Editar wp_options manualmente conlleva un riesgo real, las herramientas disponibles medirán el problema más fácilmente de lo que lo solucionarán, y volverás aquí en seis meses si sigues instalando complementos (lo cual harás).

Establece un recordatorio, comprueba el número trimestralmente y trátalo como cualquier otra tarea de mantenimiento.

Aquí hay una cosa más que vale la pena hacer y que aún no he mencionado: comprueba el tamaño de tu carga automática justo antes de una migración. Es la forma más barata posible de reducir un archivo de copia de seguridad y acortar el tiempo de importación en el otro extremo.

Una tabla wp_options hinchada es una de las razones más comunes por las que una importación de base de datos se detiene o caduca en un nuevo host, y es realmente frustrante depurar una migración fallida. Diez minutos de limpieza antes de exportar lo evitan por completo.

Antes de tocar wp_options, asegúrate de que tu sitio esté protegido.

Limpiar los datos de carga automática significa ejecutar sentencias UPDATE y DELETE contra la única tabla que puede poner todo tu sitio fuera de línea. Un comodín mal colocado en una consulta, y te encontrarás con una pantalla en blanco sin forma de acceder a wp-admin para solucionarlo.

Duplicator Pro convierte ese error recuperable en lugar de un desastre. Haz una copia de seguridad completa antes de empezar y restaura en minutos con un solo clic si algo sale mal.

Su URL de recuperación ante desastres devuelve un sitio a la normalidad incluso cuando WordPress está completamente bloqueado, que es exactamente el escenario que crea una mala consulta de base de datos. ¡Pruébalo hoy mismo!

Si esta publicación te hizo pensar en qué más hay en tu base de datos, estas guías valen la pena leerlas a continuación.

• Cómo eliminar todas las transitorios en WordPress (4 métodos)
• Cómo optimizar tu base de datos de WordPress: Consigue un sitio rápido en 10 pasos
• Limpieza de la base de datos de WordPress: una guía para principiantes para eliminar la basura
• 7 señales de advertencia de la base de datos de WordPress que la mayoría de los propietarios de sitios pasan por alto
• ¿Cómo arreglar una base de datos de WordPress lenta: una lista de verificación de 4 pasos?
• Mantenimiento de la base de datos de WordPress: Qué hacer semanal, mensual y trimestralmente