wp-config.php en producción: guía de configuración segura

📅 Publicado el 19 de octubre, 2026 · Por Equipo RedServicio

Configurar wp-config.php correctamente es uno de los pasos más importantes al poner un sitio WordPress en producción, ya que este archivo controla el acceso a tu base de datos, las claves de cifrado y múltiples ajustes de seguridad críticos. En esta guía aprenderás qué debes revisar, qué constantes activar o desactivar y qué errores evitar para que tu web sea estable y esté protegida desde el primer día. Y si buscas un entorno donde aplicar todo esto sin complicaciones, recuerda que RedServicio ofrece hosting optimizado para WordPress con soporte técnico 24/7.

¿Qué es wp-config.php y por qué es crítico en producción?

El archivo wp-config.php es el corazón de la configuración de WordPress: se ubica en la raíz de tu instalación y contiene, entre otros datos, el nombre de usuario, la contraseña y el host de tu base de datos. Si alguien consigue acceder a este archivo, obtiene control total sobre tu sitio, por eso su protección no es opcional.

Además de las credenciales de conexión, wp-config.php define constantes globales que modifican el comportamiento de WordPress: la tabla de prefijos, el modo de depuración, los límites de revisiones o la memoria disponible. Un error de sintaxis en este archivo provoca la caída inmediata de toda la web (el temido white screen of death), así que siempre haz una copia de seguridad antes de editarlo.

• Ubicación: raíz de WordPress (public_html o subcarpeta), accesible vía FTP o gestor de archivos del panel de hosting.
• Permisos recomendados: 400 o 440, para que solo el propietario pueda leerlo.
• Protección extra: puedes moverlo un nivel por encima de la raíz web; WordPress lo localiza automáticamente.

En un entorno de producción, cualquier cambio en este archivo debe planificarse: prueba primero en un entorno de staging y documenta cada modificación que realices.

Cómo configurar wp-config.php: claves de seguridad, salts y prefijo de base de datos

El bloque más delicado de la configuración son las credenciales de la base de datos y las claves de seguridad (salts). Estas últimas cifran las cookies de sesión de usuarios y administradores, y deben generarse siempre desde el servicio oficial https://api.wordpress.org/secret-key/1.1/salt/, que crea valores únicos y aleatorios.

Ejemplo de configuración básica

Dentro de wp-config.php deberías tener un bloque similar a este, con tus propios valores:

• define( ‘DB_NAME’, ‘mi_base_de_datos’ );
• define( ‘DB_USER’, ‘usuario_bd’ );
• define( ‘DB_PASSWORD’, ‘contraseña_segura’ );
• define( ‘DB_HOST’, ‘localhost’ );
• define( ‘AUTH_KEY’, ‘valor-generado-aleatorio’ ); (y las siete claves restantes: SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, etc.)

Otro punto clave es el prefijo de base de datos. Por defecto WordPress usa wp_, algo que los atacantes conocen bien. Cambiarlo a un prefijo aleatorio como x7k2_ dificulta los ataques de inyección SQL automatizados. Si tu sitio ya está instalado, no cambies el prefijo directamente en wp-config.php: necesitarás renombrar también las tablas en la base de datos, idealmente con un plugin de migración o mediante phpMyAdmin con copia previa.

Finalmente, apunta los datos de conexión de tu hosting a mano: si alguna vez migras de proveedor, tener este bloque documentado te ahorrará horas de trabajo. En RedServicio, por ejemplo, los datos de conexión a la base de datos MySQL se encuentran claramente indicados en el panel de cliente.

Desactivar el modo depuración (WP_DEBUG) antes de lanzar tu web

Uno de los errores más frecuentes al pasar de desarrollo a producción es dejar activado el modo depuración. La constante WP_DEBUG hace que WordPress muestre en pantalla todos los avisos, warnings y errores de PHP, información valiosa para el desarrollador pero peligrosa en un sitio público: puede revelar rutas de servidor, nombres de plugins y detalles internos que facilitan ataques.

Configuración recomendada en producción

• define( ‘WP_DEBUG’, false ); — desactiva la visualización de errores.
• define( ‘WP_DEBUG_LOG’, true ); — registra los errores en el archivo wp-content/debug.log.
• define( ‘WP_DEBUG_DISPLAY’, false ); — asegura que nada se muestre al visitante.

Con esta combinación, los errores siguen quedando registrados para que puedas revisarlos, pero el visitante nunca los ve. Recuerda proteger o desactivar el acceso público a debug.log desde el .htaccess, ya que contiene información sensible.

Con el archivo correctamente configurado, tendrás la base sólida sobre la que construir el resto de medidas de endurecimiento, que veremos en las siguientes partes de esta guía.

Ajustes de rendimiento: caché, revisiones y Papelera en wp-config.php

La seguridad no lo es todo. Configurar wp-config.php también te sirve para afinar el rendimiento de tu WordPress desde el servidor, sin tener que depender siempre de plugins.

Activar o desactivar la caché nativa

WordPress trae una caché básica de objetos que puedes habilitar con esta línea:

define('WP_CACHE', true);

¿Qué hace exactamente? Le indica a WordPress que cargue archivos avanzados de caché (los que generan plugins como WP Super Cache, por ejemplo). Si ya usas un plugin de caché, probablemente él mismo añadió la línea. Comprueba que no acabes con dos idénticas.

Limitar las revisiones de entradas

Cada vez que guardas en el editor, WordPress crea una revisión. Y otra. Y otra más. Con los meses, tu base de datos engorda por unas tablas que casi nadie consulta. Merece la pena poner un límite:

define('WP_POST_REVISIONS', 5);

O si trabajas con un sistema de control de versiones externo, puedes quitarlas del todo:

define('WP_POST_REVISIONS', false);

Controlar la Papelera

Por defecto, la papelera se vacía cada 30 días. Puedes acortar ese ciclo:

define('EMPTY_TRASH_DAYS', 7);

Cuidado con una cosa: un valor de 0 desactiva la papelera por completo. Lo que borres, desaparece. Sin vuelta atrás. Solo te lo recomiendo si tienes copias de seguridad automáticas en las que confíes de verdad (en RedServicio las incluimos de serie en todos los planes de hosting, por eso podemos permitirnos decírtelo).

Aumentar la memoria disponible

¿Tu web lleva WooCommerce o una colección larga de plugins? Sube el límite de memoria:

define('WP_MEMORY_LIMIT', '256M');

Errores comunes al configurar wp-config.php (y cómo evitarlos)

Nadie está a salvo. He visto fallar este archivo a administradores con años de experiencia, y casi siempre por las mismas razones:

• Editar el archivo con un procesador de textos: Word o Google Docs meten caracteres invisibles (BOM, codificaciones raras) que rompen el PHP sin que lo veas. Usa un editor de código, siempre. VS Code o Notepad++ sobran.
• Dejar espacios o líneas antes de la etiqueta <?php: con eso te aparecen errores del tipo «headers already sent». Revisa que antes de esa primera línea no haya absolutamente nada.
• Colocar las directivas después de require_once ABSPATH . ‘wp-settings.php’; Esa línea tiene que ser la última, sin excepción. Lo que escribas debajo no se ejecuta. Simplemente se ignora.
• Guardar credenciales en el archivo y subirlo a un repositorio público: antes de hacer commit a GitHub, usa variables de entorno o un .gitignore que excluya wp-config.php. Las claves de base de datos en un repositorio público son un regalo para cualquiera.
• Permisos demasiado abiertos: el archivo debe quedar en 400 o 600. Con 644, cualquier usuario del servidor podría leerlo. Piénsalo un momento.
• No hacer copia de seguridad antes de editar: basta un carácter de más para tirar la web entera. Descarga una copia funcional antes de tocar nada. Cuesta diez segundos.

Conclusión: checklist final para tu wp-config.php en producción

A estas alturas ya tienes lo necesario para configurar wp-config.php de forma segura y eficiente. Antes de dar la tarea por cerrada, repasa esta lista:

1. Credenciales de base de datos correctas y probadas en un entorno de staging.
2. Claves únicas de seguridad (SALT) generadas desde la API oficial de WordPress.
3. Prefijo de tablas personalizado, distinto de wp_.
4. WP_DEBUG desactivado y log de errores en un archivo fuera de la raíz pública.
5. SSL forzado con FORCE_SSL_ADMIN.
6. Edición de archivos deshabilitada con DISALLOW_FILE_EDIT.
7. Revisiones y Papelera ajustadas para no inflar la base de datos.
8. Permisos del archivo en 400 o 600 y copia de seguridad guardada fuera del servidor.

Un wp-config.php bien configurado es la primera línea de defensa de tu WordPress y, también, el cimiento de su rendimiento. Son quince minutos de trabajo que te ahorran la mayoría de problemas de seguridad y estabilidad que verás nunca. ¿Y si prefieres no complicarte? En RedServicio ofrecemos hosting optimizado para WordPress con soporte 24/7 en español, listo para echarte una mano con la configuración y el mantenimiento de tu web, a cualquier hora.