¿Qué es el archivo wp-config.php y cómo optimizarlo por seguridad?

Hay archivos que hacen ruido y archivos que gobiernan en silencio. En WordPress, wp-config.php pertenece a la segunda especie: no presume, no aparece en el panel de administración, no tiene botones bonitos ni gráficos de colores. Pero si cae en malas manos, el sitio entero queda expuesto como una casa con la puerta abierta y un cartel luminoso que dice: “las llaves están debajo del felpudo”.

El archivo wp-config.php es una de las piezas más sensibles de cualquier instalación de WordPress. Contiene credenciales de base de datos, claves criptográficas, configuraciones de depuración, rutas, ajustes de memoria, reglas para actualizaciones y varias constantes capaces de endurecer —o debilitar— la seguridad del sitio. Es pequeño, sí. Pero también lo es una cerilla antes de incendiar un bosque.

Optimizarlo no consiste en añadir líneas al azar copiadas de algún foro de 2011, ese museo involuntario de soluciones que ya nacieron cansadas. Consiste en entender qué hace cada directiva, cuándo conviene aplicarla y qué riesgos evita. Porque la seguridad en WordPress no es un amuleto; es una arquitectura.

Mapa rápido del artículo 🧭

• Qué es exactamente wp-config.php
• Dónde se encuentra y cómo lo carga WordPress
• Estructura del archivo: zonas críticas
• Medidas esenciales para protegerlo
• Optimización avanzada y buenas prácticas
• Errores frecuentes que conviene evitar
• Checklist profesional de endurecimiento

Qué es el archivo wp-config.php en WordPress

wp-config.php es el archivo principal de configuración de WordPress. Se genera durante la instalación —a partir de wp-config-sample.php— y le dice al sistema cómo conectarse a la base de datos, qué claves de seguridad usar, qué prefijo tienen las tablas, cómo gestionar la depuración y qué comportamientos internos deben activarse o bloquearse.

Dicho de forma sencilla: si WordPress fuera un teatro, wp-config.php no sería el actor principal ni el decorado. Sería el regidor oculto entre bastidores, con la lista de entradas, luces, telones y salidas de emergencia. Nadie lo aplaude. Todos dependen de él.

Entre sus responsabilidades principales están:

• Definir las credenciales de conexión a la base de datos MySQL o MariaDB.
• Configurar el juego de caracteres y la colación de la base de datos.
• Establecer las claves únicas de autenticación y salts de WordPress.
• Definir el prefijo de las tablas de la base de datos.
• Activar o desactivar el modo de depuración.
• Controlar actualizaciones automáticas, edición de archivos y modificaciones desde el panel.
• Ajustar memoria PHP, rutas temporales, SSL en administración y otros comportamientos avanzados.

Por eso, cuando hablamos de seguridad WordPress, proteger wp-config.php no es una recomendación decorativa. Es una prioridad operativa.

Dónde se encuentra wp-config.php y cómo lo carga WordPress 📁

En una instalación típica, el archivo está en el directorio raíz de WordPress, junto a carpetas como wp-admin, wp-content y wp-includes.

/public_html/
├── wp-admin/
├── wp-content/
├── wp-includes/
├── wp-config.php
├── wp-load.php
└── index.php

WordPress lo carga mediante wp-load.php. Y aquí aparece una característica interesante: si no encuentra wp-config.php en el directorio raíz, WordPress busca un nivel por encima. Esto permite, en algunos servidores, mover el archivo fuera del directorio público.

/home/usuario/
├── wp-config.php
└── public_html/
    ├── wp-admin/
    ├── wp-content/
    ├── wp-includes/
    └── index.php

La idea es elegante: lo importante no queda expuesto directamente al navegador. Como guardar el pasaporte en una caja fuerte en lugar de dejarlo sobre la mesa del bar. Aunque, claro, hay servidores donde moverlo rompe rutas, despliegues o herramientas de gestión. La seguridad, por desgracia, no siempre acepta atajos teatrales.

Importante: mover wp-config.php un nivel por encima puede funcionar en instalaciones clásicas, pero no siempre es viable en entornos gestionados, multisite, configuraciones con Composer, Bedrock, despliegues automatizados o paneles de hosting restrictivos. Antes de hacerlo, crea una copia de seguridad y prueba en un entorno de staging.

Estructura básica de wp-config.php: lo que debes conocer

Un archivo wp-config.php estándar contiene varias secciones. Algunas son evidentes; otras parecen inocentes hasta que alguien las configura mal y el sitio empieza a comportarse como una brújula junto a un imán.

1. Credenciales de la base de datos

define( 'DB_NAME', 'nombre_base_datos' );
define( 'DB_USER', 'usuario_base_datos' );
define( 'DB_PASSWORD', 'contraseña_segura' );
define( 'DB_HOST', 'localhost' );

Estas constantes permiten que WordPress se conecte a la base de datos. Si un atacante obtiene estos datos, puede leer, modificar o borrar contenido, usuarios, opciones, pedidos de WooCommerce, configuraciones de plugins y prácticamente cualquier cosa almacenada en la base de datos.

Aquí se impone una regla sobria: el usuario de base de datos debe tener solo los privilegios necesarios. Para una instalación normal de WordPress se requieren permisos como SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX y DROP en ciertos momentos, especialmente durante instalaciones y actualizaciones. En entornos muy controlados, algunos administradores reducen privilegios después del despliegue, aunque esto exige disciplina técnica y pruebas cuidadosas.

2. Charset y colación

define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

utf8mb4 es la opción recomendada en instalaciones modernas porque permite almacenar correctamente caracteres Unicode completos, incluidos emojis 😄, símbolos especiales y alfabetos variados. La antigua codificación utf8 de MySQL no es un UTF-8 completo; irónico, ¿verdad? Se llama utf8, pero no soporta todo UTF-8. Un nombre impecable para una verdad a medias.

En la mayoría de sitios conviene dejar DB_COLLATE vacío para que WordPress determine la colación adecuada según la base de datos.

3. Claves de autenticación y salts

define( 'AUTH_KEY',         'frase-unica-y-larga' );
define( 'SECURE_AUTH_KEY',  'frase-unica-y-larga' );
define( 'LOGGED_IN_KEY',    'frase-unica-y-larga' );
define( 'NONCE_KEY',        'frase-unica-y-larga' );
define( 'AUTH_SALT',        'frase-unica-y-larga' );
define( 'SECURE_AUTH_SALT', 'frase-unica-y-larga' );
define( 'LOGGED_IN_SALT',   'frase-unica-y-larga' );
define( 'NONCE_SALT',       'frase-unica-y-larga' );

Estas claves protegen cookies de sesión, nonces y mecanismos de autenticación. Funcionan como condimentos criptográficos: no se ven en el plato, pero sin ellos todo queda peligrosamente plano. Deben ser largas, aleatorias y únicas para cada sitio.

WordPress ofrece un generador oficial de claves en:

https://api.wordpress.org/secret-key/1.1/salt/

Consejo práctico: si sospechas que un sitio ha sido comprometido, regenerar las salts cerrará las sesiones activas de todos los usuarios. No elimina malware ni repara archivos, pero corta cookies existentes, como cambiar las cerraduras después de perder un llavero.

4. Prefijo de tablas

$table_prefix = 'wp_';

El prefijo por defecto es wp_. Cambiarlo durante una instalación nueva puede reducir ciertos ataques automatizados que asumen nombres de tabla estándar, aunque no debe venderse como una muralla inexpugnable. Es más bien una cortina adicional. Útil, sí; milagrosa, no.

En sitios existentes, modificar el prefijo requiere actualizar nombres de tablas y referencias internas en la base de datos, especialmente en tablas como options y usermeta. Si se hace mal, el sitio puede perder acceso a usuarios, roles o configuraciones. Aquí conviene operar con copia de seguridad, staging y manos tranquilas.

5. Punto de carga de WordPress

if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}

require_once ABSPATH . 'wp-settings.php';

Esta parte define la ruta absoluta del sitio y carga el núcleo de WordPress. Normalmente no se toca. Manipularla sin necesidad es como ajustar el motor de un coche con una cuchara: posible en una novela absurda, mala idea en la vida real.

Cómo proteger wp-config.php por seguridad 🛡️

La protección de wp-config.php debe abordarse por capas. Ninguna medida aislada basta. La seguridad seria se parece a un bosque maduro: raíces, troncos, sombra, humedad, equilibrio. Si solo plantas un árbol de plástico, da igual lo verde que parezca.

1. Restringe los permisos del archivo

Los permisos definen quién puede leer, escribir o ejecutar el archivo. En Linux, los valores más habituales para wp-config.php son:

Comando típico por SSH:

chmod 400 wp-config.php

O, si el servidor necesita acceso de grupo:

chmod 440 wp-config.php

Atención: no existe un permiso universal perfecto. Depende de cómo ejecute PHP tu servidor: Apache con mod_php, PHP-FPM, LiteSpeed, hosting compartido, contenedores, usuario del sistema, grupos, etc. Si al cambiar permisos aparece una pantalla blanca o errores de conexión, revierte y consulta la configuración del servidor.

2. Bloquea el acceso directo desde el navegador

En condiciones normales, un archivo PHP no debería mostrarse como texto plano. El servidor lo interpreta. Pero si hay una mala configuración, una copia temporal, un fallo de despliegue o una extensión alterada, el riesgo deja de ser hipotético.

En Apache, puedes añadir esta regla al archivo .htaccess del directorio raíz:

<files wp-config.php>
    order allow,deny
    deny from all
</files>

En servidores Apache modernos también puede usarse:

<Files "wp-config.php">
    Require all denied
</Files>

En Nginx, una regla habitual sería:

location ~* wp-config.php {
    deny all;
}

Como siempre, prueba la sintaxis antes de recargar el servidor:

nginx -t
systemctl reload nginx

3. Mueve wp-config.php fuera del directorio público si tu entorno lo permite

Si WordPress está instalado en public_html, puedes situar wp-config.php un nivel superior. WordPress lo buscará ahí automáticamente en instalaciones estándar.

Ventaja: aunque el directorio público sufra una configuración incorrecta, el archivo queda fuera del alcance directo del navegador.

Desventajas posibles:

• Algunos hostings gestionados no lo permiten.
• Puede interferir con scripts de despliegue o copias de seguridad.
• En instalaciones multisite o personalizadas conviene validarlo con cuidado.
• Herramientas de seguridad o mantenimiento podrían no detectarlo correctamente.

Es una buena práctica, pero no una religión. La diferencia importa: una buena práctica se evalúa; una religión se obedece incluso cuando rompe producción.

4. Desactiva la edición de archivos desde el panel

WordPress permite editar archivos de temas y plugins desde el administrador. Es cómodo. También es una de esas comodidades que, vistas desde seguridad, parecen diseñadas por alguien que confía demasiado en la humanidad.

Para desactivar el editor integrado, añade antes de la línea que carga wp-settings.php:

define( 'DISALLOW_FILE_EDIT', true );

Esto impide que usuarios con acceso administrativo modifiquen archivos desde el panel. Si una cuenta admin es comprometida, el atacante tendrá menos facilidad para insertar puertas traseras en temas o plugins.

5. Valora bloquear instalaciones y actualizaciones desde el panel

Una medida más estricta es:

define( 'DISALLOW_FILE_MODS', true );

Esta constante desactiva la instalación, actualización y modificación de plugins, temas y archivos desde el administrador. Es recomendable en entornos profesionales donde las actualizaciones se gestionan mediante Git, Composer, CI/CD o un flujo controlado.

No la actives a ciegas en sitios pequeños si no tienes un procedimiento alternativo de mantenimiento. La seguridad que impide actualizar también puede convertirse en vulnerabilidad diferida: hoy te protege del cambio; mañana te deja con un plugin obsoleto esperando su turno como fruta madura.

6. Desactiva el modo debug en producción

Durante desarrollo, WP_DEBUG es un aliado. En producción, puede convertirse en un indiscreto cronista de errores internos, rutas del servidor y avisos sensibles.

define( 'WP_DEBUG', false );

Configuración recomendada para producción:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );

Para entornos de staging o desarrollo, una configuración más útil sería:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

Por defecto, si WP_DEBUG_LOG está en true, WordPress puede escribir en wp-content/debug.log. Ese archivo no debería quedar accesible públicamente. Mejor aún: en versiones modernas puedes indicar una ruta personalizada fuera del directorio público.

define( 'WP_DEBUG_LOG', '/ruta/privada/logs/wordpress-debug.log' );

7. Fuerza SSL en el área de administración

Si tu sitio tiene HTTPS correctamente configurado —y en 2026 no tenerlo ya suena como enviar contraseñas en una postal— puedes forzar SSL en el administrador:

define( 'FORCE_SSL_ADMIN', true );

Esto ayuda a que las sesiones del panel viajen cifradas. También debes asegurarte de que las URLs del sitio usan HTTPS en Ajustes > Generales, de que el certificado es válido y de que no hay contenido mixto.

8. Cambia las claves SALT tras incidentes o migraciones sensibles

Regenerar las claves de seguridad es especialmente recomendable cuando:

• Un administrador abandona el proyecto y no había una gestión clara de accesos.
• Detectas actividad sospechosa.
• Has restaurado una copia desde un proveedor no completamente confiable.
• El sitio ha estado infectado.
• Se ha filtrado el repositorio o una copia del archivo.

Al cambiar las salts, todos los usuarios deberán iniciar sesión de nuevo. Es una molestia pequeña comparada con dejar sesiones antiguas respirando en la sombra.

9. Evita incluir wp-config.php en repositorios públicos

Jamás subas credenciales reales a GitHub, GitLab, Bitbucket u otros repositorios, aunque el repositorio sea “privado”. Lo privado en Internet a veces se parece a una cortina fina frente a una ventana iluminada.

Buenas prácticas:

• Incluye wp-config.php en .gitignore.
• Usa un archivo wp-config-sample.php sin secretos reales.
• Gestiona credenciales mediante variables de entorno cuando el entorno lo permita.
• Rota contraseñas si alguna vez fueron expuestas.

Ejemplo de .gitignore:

wp-config.php
.env
*.sql
*.sql.gz
wp-content/debug.log

Optimización avanzada de wp-config.php para seguridad y rendimiento ⚙️

Optimizar wp-config.php no significa convertirlo en un cajón de sastre. Cada constante debe tener una razón. Un archivo limpio es más fácil de auditar, y en seguridad la claridad no es un lujo: es munición.

1. Define el entorno del sitio con WP_ENVIRONMENT_TYPE

WordPress permite declarar el tipo de entorno:

define( 'WP_ENVIRONMENT_TYPE', 'production' );

Valores aceptados:

• local
• development
• staging
• production

Esto ayuda a temas, plugins y configuraciones personalizadas a comportarse de forma distinta según el entorno. Por ejemplo, activar logs en staging y ocultarlos en producción.

2. Controla actualizaciones automáticas con criterio

WordPress puede actualizarse automáticamente. Esto ha salvado incontables sitios de vulnerabilidades conocidas, aunque también ha producido algún susto en instalaciones con plugins frágiles, esos castillos de naipes con panel de opciones.

Para habilitar actualizaciones automáticas mayores del núcleo:

define( 'WP_AUTO_UPDATE_CORE', true );

Para permitir solo actualizaciones menores, que suelen ser de mantenimiento y seguridad:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Para desactivarlas:

define( 'WP_AUTO_UPDATE_CORE', false );

¿Qué conviene? Depende del tipo de sitio:

3. Limita revisiones de entradas

Las revisiones son útiles, pero en sitios con mucho contenido pueden aumentar el tamaño de la base de datos. Para limitar cuántas revisiones guarda WordPress:

define( 'WP_POST_REVISIONS', 5 );

Para desactivarlas por completo:

define( 'WP_POST_REVISIONS', false );

No recomiendo desactivarlas en sitios editoriales. Una revisión perdida puede ser la diferencia entre recuperar un texto y mirar la pantalla con la serenidad fingida de quien acaba de borrar tres horas de trabajo. Me pasó una vez escribiendo sobre cafeteras italianas, asunto menor para la humanidad, tragedia considerable para mi paciencia.

4. Ajusta el intervalo de autoguardado

WordPress guarda borradores automáticamente. Puedes modificar el intervalo en segundos:

define( 'AUTOSAVE_INTERVAL', 120 );

El valor por defecto suele ser 60 segundos. Aumentarlo puede reducir pequeñas escrituras en sitios con muchos editores, aunque no esperes milagros de rendimiento por cambiar una sola constante. La optimización real se parece más a afinar una orquesta que a tocar una campana.

5. Configura la memoria PHP para WordPress

Desde wp-config.php puedes solicitar más memoria para WordPress:

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

WP_MEMORY_LIMIT afecta al front-end y operaciones generales. WP_MAX_MEMORY_LIMIT se usa para tareas administrativas más pesadas, como actualizaciones o procesamiento de imágenes.

Esto no sustituye la configuración del servidor. Si PHP tiene un límite inferior en php.ini o en el panel del hosting, WordPress no podrá superar ese techo. Pedir 512M cuando el servidor concede 128M es como pedirle a un vaso que contenga un río.

6. Desactiva el cron interno si usas cron real del servidor

WordPress ejecuta tareas programadas mediante WP-Cron, que se dispara con visitas al sitio. En webs con poco tráfico puede retrasarse; en webs con mucho tráfico puede ejecutarse más de lo deseable.

Para desactivar el disparador interno:

define( 'DISABLE_WP_CRON', true );

Luego debes crear una tarea cron real en el servidor, por ejemplo cada 5 minutos:

*/5 * * * * wget -q -O - https://tudominio.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

O usando PHP CLI si está disponible:

*/5 * * * * php /ruta/a/public_html/wp-cron.php >/dev/null 2>&1

Esto mejora la previsibilidad de tareas como publicaciones programadas, emails, limpiezas, sincronizaciones y procesos de WooCommerce.

7. Reubica directorios sensibles solo si sabes lo que haces

Algunas constantes permiten personalizar rutas:

define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/wp-content' );
define( 'WP_CONTENT_URL', 'https://tudominio.com/wp-content' );

También se puede modificar la carpeta de plugins o uploads con filtros y constantes específicas. Sin embargo, mover rutas centrales puede generar incompatibilidades con plugins mal escritos que asumen ubicaciones por defecto. Y sí, existen. Muchos. Como piedras en un camino antiguo.

En proyectos empresariales puede tener sentido dentro de una arquitectura planificada. En sitios convencionales, no suele ser necesario.

8. Usa variables de entorno para credenciales

En entornos modernos, especialmente con contenedores, despliegues automatizados o plataformas cloud, es preferible no escribir secretos directamente en el archivo. Puedes leerlos desde variables de entorno:

define( 'DB_NAME', getenv( 'DB_NAME' ) );
define( 'DB_USER', getenv( 'DB_USER' ) );
define( 'DB_PASSWORD', getenv( 'DB_PASSWORD' ) );
define( 'DB_HOST', getenv( 'DB_HOST' ) );

Esto facilita la separación entre código y configuración. También permite rotar credenciales sin modificar archivos versionados.

Precaución: asegúrate de que las variables de entorno no queden expuestas mediante páginas de diagnóstico, errores PHP, paneles inseguros o archivos de información como phpinfo(). La discreción técnica es una virtud poco vistosa, pero rentable.

Ejemplo de wp-config.php endurecido

Este ejemplo no debe copiarse sin adaptación. Úsalo como referencia para ordenar ideas y revisar tu instalación.

<?php
/**
 * Configuración base de WordPress con ajustes de seguridad.
 */

/** Base de datos */
define( 'DB_NAME', 'nombre_base_datos' );
define( 'DB_USER', 'usuario_seguro' );
define( 'DB_PASSWORD', 'contraseña_larga_y_unica' );
define( 'DB_HOST', 'localhost' );

define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

/** Claves únicas y salts */
define( 'AUTH_KEY',         'genera-una-clave-unica' );
define( 'SECURE_AUTH_KEY',  'genera-una-clave-unica' );
define( 'LOGGED_IN_KEY',    'genera-una-clave-unica' );
define( 'NONCE_KEY',        'genera-una-clave-unica' );
define( 'AUTH_SALT',        'genera-una-clave-unica' );
define( 'SECURE_AUTH_SALT', 'genera-una-clave-unica' );
define( 'LOGGED_IN_SALT',   'genera-una-clave-unica' );
define( 'NONCE_SALT',       'genera-una-clave-unica' );

/** Prefijo de tablas */
$table_prefix = 'wp7x_';

/** Entorno */
define( 'WP_ENVIRONMENT_TYPE', 'production' );

/** Seguridad del administrador */
define( 'FORCE_SSL_ADMIN', true );
define( 'DISALLOW_FILE_EDIT', true );

/**
 * Usar con cuidado:
 * define( 'DISALLOW_FILE_MODS', true );
 */

/** Debug en producción */
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );

/** Rendimiento y mantenimiento */
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 120 );
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

/**
 * Activar solo si existe un cron real en el servidor:
 * define( 'DISABLE_WP_CRON', true );
 */

/** Ruta absoluta */
if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}

require_once ABSPATH . 'wp-settings.php';

Qué no debes guardar en wp-config.php

Aunque wp-config.php es un archivo de configuración, no debería convertirse en un almacén caótico de secretos y parches. Hay cosas que no conviene meter ahí sin criterio.

• Tokens de APIs externas si puedes gestionarlos mediante variables de entorno o un gestor de secretos.
• Funciones personalizadas extensas que pertenecen a un plugin propio o al archivo functions.php.
• Código copiado de fuentes dudosas.
• Contraseñas antiguas comentadas “por si acaso”. Ese “por si acaso” suele ser el epitafio de muchas auditorías.
• Configuraciones duplicadas que contradicen constantes ya definidas.

Errores frecuentes al editar wp-config.php

Editar este archivo exige precisión. Un espacio mal colocado rara vez destruye el mundo, pero una comilla omitida puede dejar tu sitio inaccesible. La informática tiene ese encanto severo: perdona conceptos torpes, pero castiga signos diminutos.

1. Añadir constantes después de wp-settings.php

Muchas configuraciones deben declararse antes de esta línea:

require_once ABSPATH . 'wp-settings.php';

Si las añades después, WordPress ya habrá cargado su configuración y la constante podría no surtir efecto.

2. Dejar errores visibles en producción

Mostrar errores PHP al público puede revelar rutas internas, nombres de plugins, versiones o detalles de la infraestructura. En producción, los errores deben registrarse de forma privada, no exhibirse como medallas.

3. Usar contraseñas débiles para la base de datos

La contraseña de base de datos debe ser larga, aleatoria y única. No reutilices credenciales del panel de hosting, FTP, correo o administrador de WordPress.

4. Hacer cambios sin copia de seguridad

Antes de tocar wp-config.php, descarga una copia del archivo y asegúrate de tener respaldo de la base de datos. Si tienes staging, úsalo. Si no lo tienes, al menos trabaja con acceso FTP/SFTP o SSH disponible para revertir rápidamente.

5. Confundir endurecimiento con acumulación de trucos

No todo snippet mejora la seguridad. Algunos están obsoletos, otros son redundantes y unos cuantos rompen funciones necesarias. La buena configuración es selectiva. La mala, en cambio, colecciona líneas como quien colecciona paraguas rotos.

Cómo editar wp-config.php de forma segura paso a paso 🧰

1. Crea una copia de seguridad del archivo y de la base de datos.
2. Accede por SFTP, SSH o administrador de archivos confiable. Evita editar desde herramientas inseguras.
3. Descarga el archivo y guárdalo con un nombre claro, por ejemplo wp-config-backup-antes-cambios.php.
4. Edita con un editor de código, no con procesadores de texto como Word.
5. Revisa comillas, punto y coma y paréntesis.
6. Sube el archivo manteniendo permisos adecuados.
7. Prueba el front-end, el login y el panel.
8. Consulta logs si algo falla.

Recomendación profesional: si gestionas sitios de clientes, documenta cada cambio realizado en wp-config.php. Fecha, motivo, constante modificada y resultado. No es burocracia: es memoria externa para cuando algo falle un viernes a las 18:47, que es cuando las cosas suelen descubrir su vocación dramática.

Permisos, propietario y servidor: la tríada que suele olvidarse

Hablar solo de chmod es quedarse a medias. La seguridad real del archivo depende de tres factores:

• Permisos: quién puede leer o escribir.
• Propietario: qué usuario del sistema posee el archivo.
• Proceso PHP: bajo qué usuario se ejecuta WordPress.

Por ejemplo, un archivo con permisos 400 puede ser perfecto en un servidor y romper WordPress en otro si PHP no tiene lectura. En hostings compartidos, a menudo el usuario de la cuenta y el proceso PHP coinciden; en servidores VPS con PHP-FPM puede haber pools específicos por sitio. En contenedores Docker, la historia cambia otra vez.

Comandos útiles para revisar propietario y permisos:

ls -l wp-config.php

Ejemplo de salida:

-r-------- 1 usuario www-data 4096 ene 10 12:20 wp-config.php

Si necesitas ajustar propietario y grupo:

chown usuario:www-data wp-config.php

No ejecutes comandos sin entender el entorno. Cambiar propietarios de forma masiva puede dejar un sitio inservible o, peor aún, demasiado permisivo.

Protección adicional desde el servidor web

Además de bloquear wp-config.php, conviene impedir el acceso a otros archivos sensibles que suelen quedar olvidados:

• .env
• composer.json y composer.lock
• copias como wp-config.php.bak, wp-config.old, wp-config.txt
• archivos SQL exportados
• logs de depuración

Ejemplo para Apache:

<FilesMatch "(\.env|composer\.(json|lock)|wp-config\.php|.*\.sql|.*\.bak|.*\.old|debug\.log)">
    Require all denied
</FilesMatch>

Ejemplo para Nginx:

location ~* (\.env|composer\.(json|lock)|wp-config\.php|.*\.sql|.*\.bak|.*\.old|debug\.log)$ {
    deny all;
}

Especial cuidado con las copias temporales. Un administrador puede proteger wp-config.php y dejar al lado wp-config.php.save descargable como texto. La puerta blindada, sí; la ventana abierta, también. La ironía no necesita esforzarse demasiado.

wp-config.php en WordPress Multisite

En WordPress Multisite, wp-config.php incluye constantes adicionales que definen el modo red:

define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'tudominio.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Estas líneas no deben modificarse sin comprender la arquitectura de la red. Cambiar SUBDOMAIN_INSTALL, dominio principal o rutas puede afectar todos los sitios de la red. En Multisite, wp-config.php no es una llave: es un manojo entero.

Medidas especialmente importantes en Multisite:

• Desactivar edición de archivos con DISALLOW_FILE_EDIT.
• Restringir superadministradores al mínimo indispensable.
• Auditar plugins de red activos.
• Usar SSL en todos los sitios.
• Controlar subidas de archivos y tipos MIME permitidos.

Relación entre wp-config.php y plugins de seguridad

Plugins como Wordfence, iThemes Security, Solid Security, Sucuri Security o All-In-One Security pueden sugerir cambios relacionados con wp-config.php. Algunos son útiles; otros dependen del entorno.

La regla sensata es esta: permite que el plugin informe, pero no delegues el juicio. Un plugin puede detectar que wp-config.php tiene permisos 644, pero quizá no entiende del todo cómo corre PHP en tu servidor. Puede recomendar bloquear edición de archivos, lo cual suele ser correcto. Puede sugerir mover rutas, y ahí conviene respirar antes de pulsar “Aplicar”.

Los plugins de seguridad son herramientas, no oráculos. Buenas herramientas, a veces excelentes. Pero la responsabilidad final sigue siendo humana, con todo lo incómodo y noble que eso implica.

Auditoría rápida: señales de alerta en wp-config.php 🚨

Revisa tu archivo si detectas alguna de estas señales:

• WP_DEBUG activado en producción.
• Claves SALT vacías, repetidas o con textos genéricos.
• Contraseñas de base de datos simples o reutilizadas.
• Permisos demasiado abiertos, como 666 o 777.
• Código extraño, ofuscado o con funciones como eval, base64_decode o gzinflate sin motivo claro.
• Archivos duplicados accesibles públicamente.
• Constantes contradictorias o repetidas.
• Comentarios con credenciales antiguas.

Si encuentras código sospechoso, no lo borres sin más si estás investigando una intrusión. Primero haz copia forense, revisa fechas de modificación, compara con backups limpios y analiza otros puntos: usuarios administradores, plugins, temas, tareas cron, wp-content/uploads, base de datos y logs del servidor.

Checklist profesional para optimizar wp-config.php ✅

• Usar contraseña de base de datos larga, única y aleatoria.
• Confirmar que DB_CHARSET está en utf8mb4.
• Regenerar claves SALT desde la API oficial de WordPress.
• Evitar el prefijo wp_ en instalaciones nuevas.
• Desactivar edición de archivos con DISALLOW_FILE_EDIT.
• Valorar DISALLOW_FILE_MODS en entornos gestionados por despliegue.
• Mantener WP_DEBUG desactivado en producción.
• Guardar logs fuera del directorio público cuando sea necesario.
• Forzar SSL en administración con FORCE_SSL_ADMIN.
• Aplicar permisos restrictivos compatibles con el servidor.
• Bloquear acceso directo mediante Apache, Nginx o reglas del hosting.
• No versionar wp-config.php con secretos reales.
• Eliminar copias temporales, backups descargables y archivos .old.
• Documentar cada cambio realizado.
• Probar todo en staging antes de aplicar en producción cuando sea posible.

Preguntas frecuentes sobre wp-config.php

¿Puedo borrar wp-config.php?

No si quieres que WordPress funcione. Sin este archivo, WordPress no sabrá cómo conectarse a la base de datos ni cargar su configuración esencial. Si se borra por accidente, deberás restaurarlo desde una copia o recrearlo con los datos correctos.

¿Cambiar el prefijo de tablas mejora realmente la seguridad?

Ayuda contra ataques automatizados simples, pero no sustituye medidas serias como actualizaciones, contraseñas robustas, permisos correctos, protección contra inyección SQL y plugins confiables. Es una capa menor, no una armadura completa.

¿Cada cuánto debo cambiar las claves SALT?

No es necesario cambiarlas cada semana. Hazlo tras incidentes, migraciones delicadas, sospecha de filtración, salida de administradores o auditorías donde no puedas garantizar que el archivo estuvo siempre protegido.

¿Es seguro editar wp-config.php desde el administrador del hosting?

Puede serlo si el panel es confiable, usa HTTPS y tu cuenta está protegida con autenticación de dos factores. Aun así, SFTP o SSH suelen ser opciones más profesionales y controlables.

¿Qué pasa si pongo mal una línea?

Puede aparecer un error fatal, una pantalla blanca o un fallo de conexión a la base de datos. Por eso es imprescindible tener una copia previa y acceso para revertir el cambio.

¿Debo usar DISALLOW_FILE_MODS?

Solo si tienes un método alternativo para actualizar WordPress, plugins y temas. Es excelente en flujos profesionales con despliegue controlado, pero puede ser incómodo o contraproducente en sitios que dependen del panel para mantenimiento básico.

Cierre: un archivo pequeño, una responsabilidad enorme

wp-config.php no es un archivo más. Es el punto donde WordPress revela sus secretos al servidor: credenciales, claves, límites, rutas, permisos implícitos, decisiones de confianza. Tratarlo con descuido es pedirle al azar que administre la seguridad, y el azar, conviene recordarlo, no firma contratos de mantenimiento.

La buena noticia es que protegerlo está al alcance de cualquier propietario o desarrollador con método: permisos correctos, acceso bloqueado, salts únicas, debug apagado en producción, edición de archivos desactivada, HTTPS forzado, copias fuera del alcance público y una saludable desconfianza hacia las soluciones mágicas.

En WordPress, como en tantas cosas, lo visible seduce y lo invisible sostiene. Los temas cambian, los plugins van y vienen, las modas de diseño brillan un verano y se marchitan al siguiente. Pero wp-config.php permanece ahí, discreto y decisivo, como una raíz bajo la tierra: si está sano, el sitio respira; si se pudre, todo lo demás empieza a inclinarse.