El archivo wp-config.php es uno de los archivos más importantes de cualquier instalación de WordPress. Contiene la configuración necesaria para conectar WordPress con la base de datos y permite definir diferentes parámetros relacionados con seguridad, desarrollo, rendimiento y funcionamiento del sitio.
Pero precisamente por su importancia, no deberíamos convertirlo en una colección de fragmentos de código copiados de Internet.
En esta guía veremos qué contiene el archivo wp-config.php, cómo se crea, qué configuraciones pueden resultar útiles y qué precauciones debemos tomar antes de modificarlo.
Importante: antes de modificar wp-config.php, realiza una copia del archivo y asegúrate de disponer de una copia de seguridad recuperable de la web. Un error de sintaxis en este archivo puede impedir que WordPress cargue correctamente.
¿Qué es el archivo wp-config.php?
wp-config.php es el archivo principal de configuración de WordPress. Normalmente se encuentra en el directorio raíz de la instalación y se genera durante el proceso de instalación.
Entre otras cosas, contiene las credenciales de conexión con la base de datos, las claves de autenticación, el prefijo de las tablas y diferentes constantes que permiten modificar el comportamiento de WordPress.
Precisamente por contener información sensible, debemos proteger este archivo y evitar compartir públicamente su contenido real.
Si necesitas pedir ayuda técnica, no publiques una copia completa de tu wp-config.php sin eliminar previamente contraseñas, claves, salts y cualquier otra credencial.
Cómo se crea wp-config.php
En una instalación convencional, WordPress genera wp-config.php durante el proceso de configuración inicial después de introducir los datos necesarios para conectarse con la base de datos.
También podemos crearlo manualmente utilizando como base el archivo wp-config-sample.php, renombrándolo como wp-config.php e introduciendo nuestra configuración.
No recomiendo sustituir un wp-config.php existente por otro archivo genérico. Una instalación puede contener constantes añadidas por el hosting, plugins, herramientas de desarrollo o por la propia arquitectura del proyecto.
Configuración de la base de datos
Uno de los bloques fundamentales contiene los datos que WordPress necesita para conectarse con la base de datos:
define( 'DB_NAME', 'nombre_base_de_datos' );
define( 'DB_USER', 'usuario_base_de_datos' );
define( 'DB_PASSWORD', 'contraseña_base_de_datos' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );Los valores exactos dependen del servidor y de la base de datos utilizada. No copies estos valores literalmente: deben corresponder con las credenciales reales de tu instalación.
Y, evidentemente, nunca publiques en un tutorial, foro, ticket o captura de pantalla una contraseña real de la base de datos.
Claves y salts de autenticación
WordPress utiliza diferentes claves y salts para reforzar la seguridad de cookies, sesiones y mecanismos de autenticación.
define( 'AUTH_KEY', 'valor-aleatorio' );
define( 'SECURE_AUTH_KEY', 'valor-aleatorio' );
define( 'LOGGED_IN_KEY', 'valor-aleatorio' );
define( 'NONCE_KEY', 'valor-aleatorio' );
define( 'AUTH_SALT', 'valor-aleatorio' );
define( 'SECURE_AUTH_SALT', 'valor-aleatorio' );
define( 'LOGGED_IN_SALT', 'valor-aleatorio' );
define( 'NONCE_SALT', 'valor-aleatorio' );Estos valores deben ser largos y aleatorios. WordPress dispone de un generador oficial para obtener claves adecuadas para una instalación.
Cambiar estas claves invalida las sesiones existentes, por lo que puede ser útil como medida de respuesta ante determinados incidentes de seguridad.
No es necesario regenerarlas periódicamente sin una razón concreta.
Prefijo de las tablas de WordPress
Otra configuración habitual es el prefijo utilizado por las tablas de la base de datos:
$table_prefix = 'wp_';Es posible utilizar otro prefijo durante la instalación.
Sin embargo, cambiar wp_ por otro valor no debe considerarse por sí solo una medida de seguridad suficiente.
La seguridad de WordPress depende de muchas capas y no deberíamos confiar en ocultar nombres o modificar valores predecibles como mecanismo principal de protección.
Configurar WP_DEBUG correctamente
Si trabajas en desarrollo web con WordPress, una de las constantes que utilizarás con frecuencia es WP_DEBUG.
define( 'WP_DEBUG', true );En un entorno de desarrollo nos ayuda a detectar errores, avisos y problemas de compatibilidad.
Pero existe una diferencia importante entre registrar errores para poder investigarlos y mostrarlos públicamente a cualquier visitante.
En producción normalmente debemos evitar que los mensajes de depuración aparezcan directamente en pantalla.
define( 'WP_DEBUG', false );Cuando necesitamos diagnosticar un problema en producción podemos utilizar una estrategia de logging adecuada al caso, evitando exponer información técnica innecesaria al visitante.
Limitar las revisiones de WordPress
WordPress almacena revisiones de entradas y páginas para que podamos recuperar versiones anteriores del contenido.
En sitios con mucho contenido podemos establecer un límite:
define( 'WP_POST_REVISIONS', 5 );En este ejemplo WordPress conservará un máximo de cinco revisiones por contenido.
También es posible desactivarlas:
define( 'WP_POST_REVISIONS', false );Personalmente prefiero limitar las revisiones antes que eliminarlas completamente, ya que pueden resultar muy útiles para recuperar cambios accidentales.
Además, reducir revisiones no debería presentarse como una solución mágica de rendimiento. Si existe un problema real de base de datos, debemos diagnosticar qué tablas, consultas o procesos están generando el problema.
Vaciar automáticamente la papelera
También podemos controlar cuánto tiempo permanece el contenido en la papelera antes de eliminarse definitivamente:
define( 'EMPTY_TRASH_DAYS', 7 );En este caso, los elementos permanecerán siete días en la papelera antes de su eliminación.
El valor adecuado dependerá de cada proyecto. Reducirlo simplemente para “optimizar WordPress” no tiene demasiado sentido si no existe una necesidad concreta.
Desactivar el editor de archivos de WordPress
WordPress puede permitir editar archivos de plugins y temas desde el propio panel de administración. En muchos proyectos prefiero desactivar esta posibilidad:
define( 'DISALLOW_FILE_EDIT', true );Esto reduce una vía de modificación directa del código desde el panel y también evita cambios accidentales realizados desde esos editores.
Pero debemos entender exactamente qué hace esta medida: no impide por sí sola que los archivos puedan modificarse mediante otros mecanismos si alguien consigue acceso suficiente al servidor, al sistema de archivos o a otras credenciales.
Es una capa de hardening, no una solución completa de seguridad.
Bloquear instalaciones y actualizaciones desde WordPress
Existe una configuración todavía más restrictiva:
define( 'DISALLOW_FILE_MODS', true );Esta constante bloquea modificaciones relacionadas con plugins, temas y actualizaciones desde WordPress.
No recomiendo activarla indiscriminadamente. Tiene sentido principalmente en instalaciones donde las actualizaciones y despliegues se gestionan mediante un proceso externo o controlado.
Si la activamos en una instalación convencional sin comprender sus consecuencias, podemos terminar dificultando precisamente el mantenimiento que necesitamos realizar.
En mi guía sobre cómo actualizar WordPress con seguridad explico el procedimiento que recomiendo para backups, staging, compatibilidad, pruebas y rollback.
Configurar la memoria disponible para WordPress
WordPress permite solicitar determinados límites de memoria mediante constantes como:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Los valores anteriores son solamente un ejemplo y no deberían copiarse como una recomendación universal.
Además, esto no significa que WordPress pueda superar los límites establecidos por PHP o por el proveedor de alojamiento. La configuración efectiva depende también de la infraestructura del servidor.
Y aumentar memoria tampoco corrige automáticamente un plugin que consume recursos de forma anormal. Si necesitamos incrementar continuamente los límites para mantener una web funcionando, deberíamos investigar la causa.
WP-Cron: cuándo sustituirlo por un cron del servidor
WordPress utiliza WP-Cron para ejecutar tareas programadas. A diferencia de un cron tradicional del sistema, su ejecución normalmente se activa a partir de solicitudes al sitio.
En determinados proyectos podemos decidir sustituir este comportamiento por una tarea programada directamente en el servidor.
Para ello podemos desactivar la ejecución convencional de WP-Cron:
define( 'DISABLE_WP_CRON', true );Pero existe una condición fundamental: si desactivamos WP-Cron debemos configurar correctamente el mecanismo que lo sustituirá.
No debemos simplemente desactivarlo.
Plugins, publicaciones programadas, procesos de WooCommerce y otras funcionalidades pueden depender de estas tareas. Si no existe una alternativa ejecutándolas, podemos provocar fallos que inicialmente no parecen relacionados con este cambio.
Reparar la base de datos de WordPress
WordPress dispone de una herramienta de reparación de la base de datos que puede habilitarse temporalmente:
define( 'WP_ALLOW_REPAIR', true );Esta opción debe utilizarse cuando realmente necesitamos realizar una intervención sobre la base de datos.
Una vez terminada, debemos eliminar o desactivar esta constante. No recomiendo mantener esta funcionalidad habilitada permanentemente.
wp-config.php no es un plugin de rendimiento
En Internet encontramos listas de supuestos “trucos para acelerar WordPress” que consisten en copiar numerosas constantes dentro de wp-config.php.
Debemos tener cuidado con este tipo de recomendaciones.
No podemos asumir que añadir una constante cualquiera hará que el servidor comprima CSS, JavaScript o HTML, active GZIP, implemente una caché completa o solucione un problema de rendimiento.
Estas funcionalidades pueden depender de WordPress, PHP, servidor web, caché de página, caché de objetos, CDN, plugins y de la propia infraestructura.
Si tu objetivo es mejorar velocidad, recomiendo empezar por diagnosticar el sistema completo. En mi guía sobre cómo aumentar la velocidad de WordPress explico este enfoque con más detalle.
wp-config.php tampoco es un plugin de seguridad
Podemos aplicar medidas interesantes de hardening desde wp-config.php, pero ninguna constante convierte por sí sola una instalación en un WordPress seguro.
La seguridad debe trabajarse por capas.
- mantener WordPress, plugins y temas actualizados;
- controlar usuarios y privilegios;
- utilizar credenciales adecuadas;
- proteger archivos y configuración;
- realizar copias de seguridad;
- monitorizar el sistema;
- analizar y proteger el tráfico que recibe la web.
Una instalación perfectamente configurada puede seguir recibiendo intentos de acceso, bots, exploraciones automatizadas, flood y otras formas de tráfico abusivo.
Huuguu Flood Blocker como capa adicional de protección
Para trabajar específicamente sobre esa capa desarrollé Huuguu Flood Blocker, orientado a proteger WordPress frente a flood, bots, spam, abuso automatizado y accesos maliciosos.
Son problemas diferentes. wp-config.php nos permite controlar determinados aspectos de la configuración de WordPress; una herramienta de protección del tráfico trabaja sobre el comportamiento de las solicitudes que llegan a la instalación.
Hardening, actualizaciones, protección del tráfico, backups y monitorización deben entenderse como capas complementarias.
La infraestructura también condiciona wp-config.php
Algunas configuraciones que definimos en WordPress dependen directamente del entorno donde está alojado el proyecto.
Memoria, PHP, cron, caché y diferentes límites no pueden analizarse correctamente ignorando la infraestructura.
Por eso no me gusta tratar WordPress y hosting como dos mundos completamente independientes.
En la infraestructura que utilizo para mis proyectos trabajo conjuntamente configuración, rendimiento, monitorización, copias y protección del tráfico. Si necesitas una infraestructura administrada para tu proyecto, puedes consultar mi hosting protegido para WordPress.
wp-config.php en desarrollo, staging y producción
En proyectos profesionales podemos necesitar configuraciones diferentes para desarrollo, staging y producción.
Credenciales, depuración, caché, servicios externos y determinadas opciones pueden variar dependiendo del entorno.
Por ejemplo, mostrar información de depuración puede ser útil mientras desarrollamos una funcionalidad y completamente inadecuado en la web pública.
También debemos tener especial cuidado al copiar una instalación de producción hacia staging o desarrollo, porque podemos estar trasladando credenciales y otros datos sensibles a un entorno con políticas de acceso diferentes.
Por eso, dentro de un proyecto de desarrollo WordPress, wp-config.php debe tratarse como parte de la arquitectura de la aplicación y no simplemente como un archivo que configuramos durante la instalación y olvidamos para siempre.
Antes de modificar wp-config.php
Como resumen práctico, antes de copiar una constante dentro del archivo me haría estas preguntas:
- ¿Qué hace exactamente esta configuración?
- ¿WordPress la soporta realmente o pertenece a un plugin o plataforma concreta?
- ¿Necesito aplicarla en este proyecto?
- ¿Puede afectar a plugins, WooCommerce, tareas programadas o actualizaciones?
- ¿Depende de alguna configuración del servidor?
- ¿Tengo una copia del archivo antes de modificarlo?
- ¿Sé cómo revertir el cambio si WordPress deja de funcionar correctamente?
Si no sabemos responder qué hace una constante, probablemente todavía no deberíamos añadirla.
Conclusión: un wp-config.php “vitaminado” no es el que tiene más código
wp-config.php es mucho más que el archivo que contiene la contraseña de la base de datos. Permite controlar aspectos importantes del funcionamiento de WordPress y adaptar determinadas configuraciones al entorno y a las necesidades de cada proyecto.
Pero un buen wp-config.php no es el que acumula más constantes.
Es el que contiene solamente las configuraciones que el proyecto necesita, aplicadas sabiendo exactamente qué hacen y cómo afectan al resto del sistema.
Seguridad, rendimiento y mantenimiento no se consiguen acumulando snippets. Requieren entender WordPress, el servidor, los plugins, el tráfico y las dependencias existentes entre todas esas capas.
Si necesitas ayuda con una instalación, puedes consultar mis servicios para WordPress. Para proyectos con necesidades específicas, también trabajo con desarrollo a medida para WordPress.
