Hola.
Hoy voy a ofreceros unos consejos para los que estáis metidos de lleno en el mundo de WordPress. Claros y concisos.
Aunque algunos de estos consejos nacieron de problemas que me encontré hace años, he actualizado las soluciones para que tengan sentido también en instalaciones modernas de WordPress y PHP.
Así que, al lío.
⚠️ Antes de tocar nada: backup
Antes de modificar wp-config.php, archivos del servidor o la base de datos, realiza una copia de seguridad.
Si tienes la posibilidad, realiza estas pruebas primero en un entorno de desarrollo o staging y no directamente sobre la instalación de producción.
Y recuerda que algunas soluciones dependen del servidor utilizado: Apache, Nginx, PHP-FPM, hosting compartido, etc.
Modo debug en WordPress
Esto es lo primero a lo que podemos recurrir cuando falla algo y no sabemos por dónde van los tiros.
En el archivo wp-config.php podemos activar el modo debug:
define( 'WP_DEBUG', true );
Pero hoy no me quedaría únicamente con esto.
Si queremos registrar los errores y evitar que aparezcan directamente en pantalla, podemos utilizar:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
Los errores quedarán registrados normalmente en:
wp-content/debug.log
Esto es especialmente interesante en producción: podemos registrar el problema sin enseñarle al visitante información interna de nuestra aplicación.
⚠️ Ojo con dejar el debug activado
No dejes WP_DEBUG activado indefinidamente en una instalación de producción.
Además, revisa el archivo wp-content/debug.log cuando hayas terminado. Dependiendo del error, puede contener información que no debería quedar expuesta.
Debug sí. Debug eterno, no.
Ocultar la versión de PHP
Esto no convierte nuestro WordPress en inexpugnable, pero sí evita exponer innecesariamente información sobre la versión de PHP utilizada por el servidor.
PHP dispone de la directiva:
expose_php = Off
Esta directiva se configura en php.ini y evita que PHP anuncie su presencia y versión mediante determinadas cabeceras HTTP, como X-Powered-By.
💡 Información importante
Ocultar la versión de PHP es una medida de hardening, no una solución de seguridad.
Mantener PHP actualizado y utilizar una versión soportada es muchísimo más importante que esconder su número de versión.
Además, la configuración disponible dependerá de cómo esté instalado PHP en nuestro servidor. En algunos hostings no tendremos acceso al php.ini, por lo que tendremos que consultar la documentación de nuestro proveedor.
Cambiar el copyright por defecto de un tema
Si estamos utilizando un tema que permite modificar el copyright mediante una opción del personalizador, podemos recuperar ese valor desde PHP.
Por ejemplo, en OceanWP:
$copy = get_theme_mod( 'ocean_footer_copyright_text', 'SS' ) . ' © ' . date( 'Y' );
Naturalmente, esto depende del tema que estemos utilizando.
ℹ️ Cada tema es diferente
No existe una variable universal para modificar el copyright de todos los temas de WordPress.
La función get_theme_mod() recupera opciones almacenadas por el tema, por lo que el nombre de la opción dependerá de cada tema.
Eliminar el archivo readme.html
En la raíz de una instalación de WordPress podemos encontrar el archivo:
readme.html
Si accedemos a:
https://misitio.com/readme.html
podemos encontrarnos con información sobre WordPress.
¿Es una vulnerabilidad por sí mismo?
No.
Pero eliminar archivos innecesarios o restringir el acceso a información que no necesitamos publicar puede reducir cierta exposición.
💡 Hardening no significa seguridad absoluta
Eliminar readme.html no sustituye a mantener actualizado WordPress.
Es una medida secundaria. Lo importante sigue siendo mantener WordPress, plugins, temas y PHP actualizados.
¿Y qué pasa con install.php?
Aquí vamos a corregir una recomendación que tenía sentido en una instalación antigua.
No recomiendo eliminar manualmente wp-admin/install.php de una instalación moderna de WordPress como medida de seguridad general.
No debemos empezar a borrar archivos del core de WordPress porque sí.
⚠️ No borres archivos del core alegremente
Si sospechamos que existe un problema de seguridad, debemos utilizar las herramientas de hardening de WordPress y mantener el core actualizado, en lugar de modificar arbitrariamente sus archivos.
Una actualización posterior podría restaurarlos y, peor aún, podríamos terminar con una instalación incompleta.
Fatal error: Maximum execution time exceeded
Otro bonito error que puede dejarnos con cara de póker:
Fatal error: Maximum execution time of ... seconds exceeded
El problema es que un script PHP ha superado el tiempo máximo de ejecución permitido.
Podemos encontrarnos con soluciones como:
max_execution_time = 300
Pero ojo.
No siempre podremos modificar esta configuración desde .htaccess. Dependerá de cómo esté configurado PHP en nuestro servidor.
Si utilizamos PHP-FPM, por ejemplo, determinadas directivas pueden gestionarse desde la configuración de PHP/FPM o desde el propio hosting.
⚠️ No copies esto a ciegas
Antes de añadir:
php_value max_execution_time 300
a nuestro .htaccess, debemos saber cómo está funcionando PHP en nuestro servidor.
En determinados entornos, esa directiva puede provocar un 500 Internal Server Error.
Otra actualización está en proceso
Queremos actualizar WordPress, pero nos encontramos con el mensaje:
Otra actualización está en proceso.
WordPress utiliza un bloqueo temporal durante determinadas actualizaciones.
Si el bloqueo se ha quedado atascado, podemos comprobar la tabla de opciones de nuestra base de datos.
Importante: no asumamos que la tabla se llama siempre wp_options. El prefijo puede ser diferente.
Por ejemplo:
SELECT * FROM wp_options WHERE option_name = 'core_updater.lock';
Si realmente existe ese registro y estamos seguros de que no hay una actualización ejecutándose, podemos eliminarlo.
⚠️ Antes de tocar la base de datos
Haz un backup.
Y, sobre todo, no borremos filas de wp_options a lo loco: esa tabla contiene una enorme cantidad de configuración de nuestra instalación.
Fatal error: Maximum execution time de 300 segundos al importar una base de datos
Este error puede aparecernos en local al intentar importar una base de datos especialmente grande, sobre todo cuando estamos trabajando con herramientas como phpMyAdmin.
Aquí hay que distinguir dos cosas:
- El límite de ejecución de PHP.
- Los límites propios de phpMyAdmin y del servidor.
Si estamos utilizando phpMyAdmin, la configuración puede encontrarse en su archivo de configuración, dependiendo de cómo hayamos instalado la aplicación.
En lugar de modificar directamente archivos del paquete sin saber qué instalación tenemos, lo recomendable es localizar la configuración activa de phpMyAdmin y ajustar los límites correspondientes.
💡 ¿La base de datos es enorme?
Si estamos hablando de una base de datos realmente grande, quizá sea mucho mejor realizar la importación desde consola mediante herramientas como mysql o mariadb.
Para bases de datos grandes, la línea de comandos suele ser bastante más apropiada que subir un monstruo de varios cientos de megas mediante el navegador.
Evitar redirecciones 301 innecesarias
Suele ser muy habitual que escribamos URLs del tipo:
/consejos-utiles-para-wordpress
en nuestro menú de navegación o en enlaces internos.
Y luego comprobamos con una herramienta como Redirect Path que WordPress realiza una redirección 301 hacia:
/consejos-utiles-para-wordpress/
Aquí hay que hacer una pequeña corrección respecto al artículo original.
El problema no es que una URL sin / final esté “mal escrita”.
La URL canónica depende de cómo tengamos configurado WordPress y nuestro servidor.
Si WordPress utiliza una estructura con / final, enlazar directamente a esa versión puede evitar una redirección innecesaria:
/consejos-utiles-para-wordpress/
💡 La clave es la consistencia
No se trata de que una forma sea universalmente correcta y la otra incorrecta.
Lo importante es utilizar una estructura coherente en todo el sitio y enlazar preferentemente a la URL canónica.
Pantalla blanca tras instalar WordPress: la famosa pantalla de la muerte
Tanto en local como en nuestro servidor puede darse el caso de que, al instalar WordPress o realizar algún cambio, al intentar acceder al panel de administración o a la propia home nos encontremos con una pantalla en blanco.
¿Qué está pasando?
Lo primero es averiguar qué error está provocando el fallo.
Aquí vuelve a entrar en juego nuestro amigo:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
Si no podemos acceder al panel de administración, podemos desactivar temporalmente los plugins mediante FTP o mediante el administrador de archivos del hosting.
Hacemos una copia de seguridad de:
wp-content/plugins
y después podemos renombrar la carpeta:
wp-content/_plugins
Si WordPress vuelve a funcionar, ya sabemos que el problema está relacionado con uno de los plugins.
Después podemos restaurar el nombre de la carpeta y localizar el plugin conflictivo.
💡 Recovery Mode
Desde WordPress 5.2 existe el Recovery Mode, que puede detectar ciertos errores fatales provocados por plugins o temas y proporcionar un mecanismo para recuperar el acceso a la administración.
Si WordPress te ofrece entrar mediante un enlace de recuperación, úsalo antes de empezar a renombrar carpetas a lo loco.
Error estableciendo conexión con la base de datos
Este error es un clásico:
Error establishing a database connection
Aquí debemos revisar el archivo:
wp-config.php
y comprobar:
define( 'DB_NAME', 'nombre_base_datos' ); define( 'DB_USER', 'usuario' ); define( 'DB_PASSWORD', 'contraseña' ); define( 'DB_HOST', 'localhost' );
Los valores dependen de nuestro hosting.
También debemos comprobar que el servidor MySQL/MariaDB está funcionando y que el usuario tiene permisos sobre la base de datos.
⚠️ No siempre es culpa de wp-config.php
Si los datos son correctos, revisa también:
- Que MySQL/MariaDB esté funcionando.
- Que el usuario tenga permisos.
- Que
DB_HOSTsea el correcto. - Que el servidor de base de datos sea accesible.
A veces por querer ir tan rápido nos dejamos algún dato bailando.
No puedo subir imágenes a través del uploader de WordPress
Si WordPress no permite subir imágenes, no empecemos directamente poniendo permisos 777.
Primero debemos comprobar:
- Que el directorio
wp-content/uploadsexiste. - Que el usuario con el que se ejecuta PHP puede escribir en él.
- Los permisos y propietarios de los archivos.
- El límite de subida de PHP.
- El espacio disponible en disco.
- Los logs de PHP y WordPress.
Como referencia general, WordPress utiliza habitualmente directorios con permisos 755 y archivos con 644, aunque la configuración correcta depende del servidor y del propietario de los archivos.
⚠️ Y NO: 777 no es la solución universal
No utilices 777 como solución por defecto.
Dar permisos de escritura, lectura y ejecución a todo el mundo puede ocultar temporalmente el problema de permisos, pero también puede aumentar innecesariamente la superficie de ataque.
Primero averigua quién ejecuta PHP y quién es el propietario de los archivos.
Importando base de datos: Error > Incorrect format parameter
Si phpMyAdmin nos devuelve:
Incorrect format parameter
y estamos intentando importar una base de datos grande, uno de los primeros sospechosos son los límites de subida de PHP.
Podemos revisar:
upload_max_filesize = 64M post_max_size = 64M
Pero ambos valores deben ser coherentes con el tamaño real del archivo y con la configuración del servidor.
Y de nuevo:
64M significa 64 megabytes.
No tiene sentido poner:
upload_max_filesize = 10G
porque sí.
💡 Para bases de datos grandes: sal del navegador
Si la base de datos es realmente grande, considera utilizar una importación desde consola en lugar de phpMyAdmin.
Por ejemplo, con mysql o mariadb.
La línea de comandos evita muchos de los límites que aparecen cuando intentamos hacer una importación gigantesca a través de una petición HTTP.
Me redirige a local después de subir WordPress al servidor
Este es otro clásico.
Hemos trabajado en local:
http://localhost/misitio
y después de migrar WordPress al servidor, seguimos siendo enviados a nuestra instalación local.
La solución habitual está en los valores:
siteurl home
que se almacenan en la tabla de opciones de WordPress.
Por ejemplo:
SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');
Si estamos utilizando otro prefijo, debemos sustituir wp_options por el nombre correspondiente.
Podemos modificar los valores para que apunten al dominio correcto.
Otra posibilidad, especialmente útil durante una migración, es definir temporalmente:
define( 'WP_HOME', 'https://misitio.com' ); define( 'WP_SITEURL', 'https://misitio.com' );
Estas constantes sobrescriben los valores correspondientes de wp_options mientras estén definidas.
⚠️ Cuidado al reemplazar URLs durante una migración
WordPress puede contener URLs dentro de datos serializados.
No hagas un simple reemplazo masivo de texto sobre toda la base de datos sin saber lo que estás haciendo, porque puedes romper datos serializados.
Para migraciones, utiliza herramientas preparadas para WordPress o WP-CLI cuando sea posible.
Cambiar la contraseña del administrador desde la base de datos
Necesitamos hacer pruebas y no sabemos la contraseña del administrador.
Podemos recuperarla desde phpMyAdmin.
Nos dirigimos a la tabla:
wp_users
Recuerda que el prefijo puede ser diferente.
Editamos el usuario correspondiente y modificamos el campo:
user_pass
Si utilizamos phpMyAdmin, podemos seleccionar la función MD5 para generar temporalmente el valor de la contraseña.
Sí, has leído bien: MD5.
Pero aquí hay que hacer una aclaración importante.
No significa que WordPress moderno utilice MD5 como algoritmo normal de almacenamiento de contraseñas.
Este método existe como mecanismo de recuperación manual desde phpMyAdmin. Después del siguiente inicio de sesión correcto, WordPress vuelve a generar el hash utilizando un algoritmo más fuerte.
💡 Si tienes WP-CLI, mejor
Una opción mucho más limpia es:
wp user update usuario --user_pass="NuevaContraseña"
Así evitamos tocar directamente la base de datos.
¡Objeto no encontrado! Error 404 al volver a la Home desde el backend y enlaces rotos
Si estamos trabajando en local y hemos migrado un sitio que utiliza HTTPS, debemos comprobar que la URL configurada en WordPress coincide con la que estamos utilizando realmente.
Por ejemplo:
https://localhost/misitio
frente a:
http://localhost/misitio
También podemos encontrarnos con problemas relacionados con los enlaces permanentes.
Una de las soluciones clásicas es ir a:
Ajustes → Enlaces permanentes
y guardar nuevamente la configuración.
Esto hace que WordPress vuelva a generar las reglas de reescritura correspondientes.
Si estamos utilizando Apache, también debemos comprobar que mod_rewrite y .htaccess estén correctamente configurados.
Aumentar el límite de memoria
Si utilizamos algún editor como Elementor u otro plugin pesado, puede pasar que no cargue correctamente o que determinadas funciones no estén disponibles.
WordPress dispone de:
define( 'WP_MEMORY_LIMIT', '256M' );
También existe:
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
El primero está destinado principalmente al frontend y el segundo al backend.
Eso sí: aumentar la memoria de WordPress no puede superar las posibilidades reales del memory_limit de PHP configurado en el servidor.
⚠️ Más memoria no siempre significa más rendimiento
Si ponemos:
512M
pero PHP solo permite:
128M
no hemos hecho magia.
Y si una instalación consume cantidades enormes de memoria, quizá el problema real sea un plugin, un tema o una operación especialmente pesada.
reCAPTCHA v3 en localhost
Si estamos testeando nuestra web y nuestros formularios con Contact Form 7 y queremos integrar reCAPTCHA en localhost, debemos configurar correctamente el dominio utilizado por nuestra clave.
Dependiendo de la versión de reCAPTCHA y del sistema utilizado, la configuración puede haber cambiado respecto a las instrucciones antiguas de este artículo.
Por eso, en lugar de copiar una configuración concreta de hace años, debemos revisar la configuración actual de la consola de reCAPTCHA y añadir el dominio que estamos utilizando para las pruebas.
Por ejemplo, si trabajamos con:
localhost
o con un dominio local como:
miproyecto.test
debemos asegurarnos de que la configuración de la clave utilizada permite ese entorno.
💡 Consejo
Para desarrollo local suele ser mucho más cómodo utilizar un dominio como:
miproyecto.test
en lugar de trabajar directamente con una ruta del tipo localhost/miproyecto.
Esto además permite reproducir mejor determinadas configuraciones de producción.
Algunos consejos más para 2026
Y ya que estamos actualizando el artículo, añadiría unos cuantos que considero bastante más importantes hoy.
Mantén WordPress, plugins, temas y PHP actualizados
No actualices directamente en producción sin comprobar antes que todo sigue funcionando.
Si tienes posibilidad de utilizar un entorno de staging, úsalo.
Y si no, al menos:
backup → actualización → pruebas → producción.
💡 Una actualización no debería ser una apuesta
Antes de actualizar:
1. Backup.
2. Comprobar compatibilidad.
3. Actualizar.
4. Revisar errores y logs.
5. Probar el sitio.
6. Respirar.
No edites el core de WordPress
Si necesitas modificar el comportamiento de WordPress, intenta utilizar:
- hooks
- filtros
- plugins propios
- child themes cuando corresponda
Modificar directamente archivos de wp-admin o wp-includes es pedirle a la próxima actualización que se lleve nuestro trabajo por delante.
⚠️ El core no se parchea
Si necesitas modificar una funcionalidad, busca primero un hook, un filtro o una solución mediante plugin.
Tu yo del futuro te lo agradecerá.
Revisa los logs antes de empezar a tocar cosas a ciegas
Cuando algo falla, no empecemos a cambiar permisos, borrar archivos y reiniciar servidores como si estuviéramos intentando arreglar un Amstrad a martillazos.
Primero:
wp-content/debug.log
logs de PHP, logs del servidor web y, si procede, logs de la base de datos.
El error suele decirnos bastante más de lo que creemos.
💡 Regla de oro
Antes de modificar algo, mira qué está fallando.
Parece obvio, pero ahorra una cantidad absurda de tiempo.
Y si tienes WP-CLI, úsalo
WP-CLI permite administrar WordPress desde la línea de comandos y resulta especialmente útil para tareas de mantenimiento, usuarios, plugins, temas, actualizaciones y migraciones.
Por ejemplo:
wp plugin list wp theme list wp core version wp user list
Para determinadas tareas, es mucho más rápido y fiable que andar haciendo veinte clics en el panel de administración.
💡 Si trabajas habitualmente con WordPress, aprende WP-CLI
Para mantenimiento, migraciones, búsquedas, reemplazos, gestión de plugins y tareas repetitivas puede convertirse en una herramienta imprescindible.
Y cuando el panel de administración decide que hoy no quiere colaborar… suele venir especialmente bien.
En resumen
Muchos de estos problemas tienen soluciones sencillas.
Lo importante es no aplicar un parche a ciegas.
Un 777, un error_reporting(0), borrar archivos del core o meter valores gigantes en php.ini pueden hacer que el problema desaparezca temporalmente…
…hasta que descubramos que hemos creado tres problemas nuevos.
Así que:
Backup.
Logs.
Diagnóstico.
Solución.
Y después, si todo funciona:
Un merecido café. ☕
Porque sí: WordPress puede ser maravilloso.
Y también puede tocar bastante los cojones.
💡 ¿Tienes algún tip más?
No dudes en comentarlo y lo pondré en la lista.
Un saludo!.
Visitas: 3014
Automation & Data Specialist | Web Development | Data Processing & Integration