Cómo solucionar el error “El enlace que seguiste ha expirado” en WordPress

El error "The link you followed has expired" en WordPress se activa cuando una carga de archivo o envío de formulario supera uno o más límites de tiempo de ejecución de PHP — específicamente upload_max_filesize, post_max_size, max_execution_time o memory_limit. WordPress no puede recuperarse correctamente de estos rechazos del lado del servidor, por lo que muestra este mensaje genérico en lugar de un error PHP específico.

La solución requiere aumentar los valores de esas directivas PHP a través de la capa de configuración que exponga su entorno de alojamiento: php.ini, .htaccess, wp-config.php o una interfaz de panel de control. El método que funcione depende completamente de su nivel de acceso al servidor — acceso root SSH, cPanel administrado o un entorno compartido restringido requieren cada uno un enfoque diferente.

Por qué ocurre realmente este error

Comprender la causa raíz evita aplicar la solución incorrecta. Cuando WordPress procesa una carga, el navegador envía una solicitud POST multiparte a wp-admin/async-upload.php o wp-admin/update.php. PHP evalúa la solicitud contra cuatro límites independientes antes de que WordPress ejecute una sola línea de código de aplicación:

• upload_max_filesize — límite máximo para cualquier archivo individual cargado
• post_max_size — límite para todo el cuerpo POST, que debe ser *mayor* que upload_max_filesize
• max_execution_time — segundos máximos de reloj que puede ejecutarse un proceso PHP
• memory_limit — RAM disponible para el proceso PHP; el procesamiento de imágenes y la instalación de temas consumen mucha memoria

Si se supera cualquiera de estos límites, PHP termina silenciosamente la solicitud. WordPress recibe una respuesta vacía o malformada y muestra "The link you followed has expired." El error no es un bug de WordPress — es PHP aplicando la política del servidor.

Causas comunes en la práctica:

• Instalar un tema premium (a menudo 5–30 MB) en un alojamiento compartido con un límite de carga predeterminado de 2 MB
• Cargar un archivo CSV de importación de productos de WooCommerce
• Instalar un paquete de plugin que incluye recursos integrados
• Restaurar un sitio desde un archivo de copia de seguridad a través del panel de WordPress
• Ejecutar un script de importación de larga duración que alcanza el límite de tiempo de ejecución

Tabla de referencia rápida de directivas PHP

Regla crítica: post_max_size siempre debe configurarse con un valor mayor que upload_max_filesize. Si configura upload_max_filesize = 128M pero deja post_max_size = 8M, las cargas seguirán fallando porque primero se alcanza el límite del cuerpo POST.

Método 1: Editar php.ini (recomendado para VPS y servidores dedicados)

Este es el método más fiable y permanente. En un entorno de Alojamiento VPS o Servidor Dedicado donde tiene acceso root o sudo, usted controla la configuración PHP directamente.

Localice el archivo php.ini activo:

php --ini | grep "Loaded Configuration File"

O desde dentro de un sitio WordPress, cree un archivo temporal:

<?php phpinfo(); ?>

Busque la fila Loaded Configuration File en la salida, luego elimine el archivo inmediatamente después.

Edite las directivas:

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Después de guardar, reinicie PHP-FPM o Apache para aplicar los cambios:

# For PHP-FPM (most common on modern stacks)
sudo systemctl restart php8.2-fpm

# For Apache with mod_php
sudo systemctl restart apache2

# For Nginx + PHP-FPM
sudo systemctl restart nginx php8.2-fpm

Verifique que los nuevos valores entraron en vigor:

php -r "echo ini_get('upload_max_filesize');"

Caso especial a tener en cuenta: En servidores que ejecutan múltiples versiones de PHP (una configuración común en cPanel), hay un php.ini separado para cada versión. Editar el incorrecto no tiene ningún efecto. Confirme qué versión de PHP está usando WordPress antes de editar.

Método 2: Usar .htaccess (alojamiento compartido Apache)

Si está en alojamiento compartido sin acceso directo a php.ini, y su servidor ejecuta Apache con mod_php o suPHP, puede anular las directivas PHP por directorio usando .htaccess.

Acceda al directorio raíz de WordPress mediante FTP, SFTP o el administrador de archivos de su alojamiento. Abra .htaccess y añada el siguiente bloque:

<IfModule mod_php.c>
    php_value upload_max_filesize 128M
    php_value post_max_size 256M
    php_value max_execution_time 300
    php_value max_input_time 300
    php_value memory_limit 256M
</IfModule>

Guarde y suba el archivo, luego pruebe su carga.

Advertencias importantes:

• Este método no funciona en servidores que ejecutan PHP-FPM, CGI o FastCGI. En esas configuraciones, las directivas php_value en .htaccess causarán un error 500 Internal Server Error porque el módulo Apache que maneja PHP no es mod_php. Si ve un error 500 después de guardar, elimine esas líneas inmediatamente.
• En servidores Nginx, .htaccess se ignora por completo. Use php.ini o un archivo de anulación de usuario php.ini en su lugar.
• Algunos alojamientos administrados deshabilitan explícitamente AllowOverride para directivas PHP, haciendo que este método sea ineficaz incluso en Apache.

Método 3: Añadir directivas a wp-config.php

Este método usa la función ini_set() de PHP para anular directivas en tiempo de ejecución. Funciona independientemente del tipo de servidor web, pero está sujeto a las restricciones open_basedir y disable_functions del alojamiento — algunos proveedores bloquean ini_set() por razones de seguridad.

Abra wp-config.php en la raíz de WordPress y añada las siguientes líneas antes del comentario /* That's all, stop editing! Happy publishing. */:

@ini_set( 'upload_max_size',    '128M' );
@ini_set( 'post_max_size',      '256M' );
@ini_set( 'max_execution_time', '300'  );
@ini_set( 'max_input_time',     '300'  );
@ini_set( 'memory_limit',       '256M' );

El @ suprime los errores si ini_set() está deshabilitado, evitando una pantalla en blanco. Sin embargo, si el alojamiento ha bloqueado estos valores a nivel de servidor usando php_admin_value, las llamadas a ini_set() se ignoran silenciosamente — los valores no cambiarán.

Cómo verificar que realmente funcionó:

Instale el plugin gratuito Query Monitor y compruebe la pestaña del entorno PHP, o añada una llamada temporal a phpinfo(). Si los valores siguen mostrando los límites anteriores, ini_set() está siendo anulado a un nivel superior y necesita usar un método diferente.

Método 4: Ajustar la configuración PHP en cPanel

Para entornos de alojamiento administrados a través de cPanel — incluyendo VPS con cPanel — puede modificar los límites PHP a través de la interfaz gráfica sin tocar ningún archivo.

Pasos:

1. Inicie sesión en cPanel.
2. Navegue a Software y haga clic en MultiPHP INI Editor.
3. Seleccione la raíz del documento de su sitio WordPress en el menú desplegable.
4. Localice y actualice los siguientes campos:

• upload_max_filesize → 128M
• post_max_size → 256M
• max_execution_time → 300
• memory_limit → 256M

1. Haga clic en Apply.

Alternativamente, use Select PHP Version (PHP Selector) si su alojamiento usa CloudLinux. En la pestaña Options, las mismas directivas están disponibles como controles deslizantes o campos de entrada.

Lo que cPanel hace en segundo plano: Escribe un archivo .user.ini (para PHP-FPM) o modifica .htaccess (para mod_php) en la raíz de su documento. Si posteriormente edita manualmente esos archivos, puede sobrescribir los cambios de cPanel — tenga en cuenta este conflicto.

Método 5: Crear o editar un archivo .user.ini (entornos PHP-FPM)

Este es el método que la mayoría de los tutoriales omiten, pero es el enfoque correcto para PHP-FPM — que es el manejador PHP predeterminado en prácticamente todas las configuraciones de alojamiento modernas, incluidos los entornos basados en Nginx.

Cree un archivo llamado .user.ini en el directorio raíz de WordPress con el siguiente contenido:

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Súbalo al mismo directorio que wp-config.php. PHP-FPM analiza periódicamente los archivos .user.ini — el TTL de caché está controlado por user_ini.cache_ttl, que por defecto es 300 segundos (5 minutos). Los cambios no son instantáneos. Si necesita efecto inmediato, reinicie PHP-FPM.

sudo systemctl restart php8.2-fpm

Nota de seguridad: El archivo .user.ini no debe ser accesible desde la web. Añada esto a su .htaccess si está en Apache:

<Files ".user.ini">
    Require all denied
</Files>

En Nginx, añada un bloque de ubicación para denegar el acceso:

location ~ /.user.ini {
    deny all;
}

Método 6: Contactar a su proveedor de alojamiento

Si ninguno de los métodos anteriores produce un cambio en los valores PHP que verificó con phpinfo() o Query Monitor, el proveedor está aplicando límites a nivel del pool PHP-FPM o mediante directivas php_admin_value en la configuración del servidor — ambos no pueden ser anulados por ningún archivo accesible al usuario.

En este caso, contacte al soporte y solicite aumentos específicos. Proporcione los nombres exactos de las directivas y los valores objetivo. Si el proveedor se niega o impone un límite máximo que no cumple sus requisitos, considere migrar a un plan de Alojamiento VPS donde usted controla completamente la configuración PHP.

Diagnóstico del límite que realmente está causando el error

En lugar de adivinar, use estos pasos de diagnóstico antes de aplicar cualquier solución:

Compruebe los límites PHP actuales desde la línea de comandos:

php -r "echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . PHP_EOL;
echo 'post_max_size: ' . ini_get('post_max_size') . PHP_EOL;
echo 'max_execution_time: ' . ini_get('max_execution_time') . PHP_EOL;
echo 'memory_limit: ' . ini_get('memory_limit') . PHP_EOL;"

Compruebe el registro de errores PHP para ver el fallo real:

tail -n 50 /var/log/php/error.log
# or
tail -n 50 /var/log/apache2/error.log

Busque líneas que contengan Allowed memory size, Maximum execution time o POST Content-Length. El mensaje específico le indica exactamente qué directiva debe modificar.

Compruebe el tamaño del archivo que está cargando en relación con el upload_max_filesize actual. Si el archivo es de 45 MB y el límite es de 64 MB, el límite de carga no es el problema — busque en post_max_size o memory_limit en su lugar.

Elección del método correcto: matriz de decisión

Lista de verificación técnica clave antes de considerar esto resuelto

• post_max_size está configurado más alto que upload_max_filesize — esta es la configuración incorrecta más común
• Los cambios han sido verificados con phpinfo() o php -r "echo ini_get(...)" — no solo asumidos
• PHP-FPM fue reiniciado si .user.ini o php.ini fue editado directamente
• El .user.ini o php.ini que se está editando coincide con la versión PHP que realmente sirve el sitio WordPress
• memory_limit es al menos 256M si está instalando temas grandes o realizando operaciones con muchas imágenes
• Se comprobó el registro de errores para confirmar qué límite específico causó la terminación
• Si está en un plan de Alojamiento Web Compartido, se ha confirmado el límite máximo del proveedor — algunos proveedores limitan upload_max_filesize a 64M independientemente de la configuración del usuario
• Después de corregir el error de carga, verifique que sus Certificados SSL son válidos si accede a wp-admin a través de HTTPS, ya que los errores de contenido mixto o de certificado pueden producir fallos de redirección superficialmente similares

Preguntas frecuentes

¿Por qué aparece el error incluso después de aumentar upload_max_filesize en .htaccess?

Es probable que el servidor esté ejecutando PHP mediante FastCGI o PHP-FPM en lugar de mod_php. La directiva php_value en .htaccess solo es procesada por el manejador mod_php de Apache. En configuraciones PHP-FPM, use un archivo .user.ini en el directorio raíz de WordPress en su lugar.

¿Cuál es la diferencia entre upload_max_filesize y post_max_size, y por qué importan ambos?

upload_max_filesize limita el tamaño de cada archivo individual en una carga multiparte. post_max_size limita el tamaño total de todo el cuerpo de la solicitud POST, que incluye los datos del archivo más los campos del formulario y los delimitadores. Si post_max_size es menor que upload_max_filesize, primero se alcanza el límite del cuerpo POST y PHP descarta toda la solicitud antes de que WordPress pueda evaluar el tamaño del archivo.

Las llamadas a ini_set() en wp-config.php están siendo ignoradas. ¿Por qué?

El proveedor está usando php_admin_value en la configuración del pool PHP-FPM o en el bloque del host virtual Apache. php_admin_value establece una directiva como de solo lectura desde la perspectiva de la aplicación — las llamadas a ini_set() para esas directivas se descartan silenciosamente. Solo el proveedor de alojamiento puede cambiar los valores configurados de esta manera.

¿Cómo verifico que mis cambios de configuración PHP realmente entraron en vigor?

Cree un archivo temporal en la raíz de WordPress que contenga <?php phpinfo(); ?>, acceda a él en un navegador y busque el nombre de la directiva. La columna Local Value muestra el valor efectivo para ese directorio. Elimine el archivo inmediatamente después de comprobarlo — dejar la salida de phpinfo() accesible públicamente es un riesgo de seguridad.

¿Puede este error ser causado por algo distinto a los límites de carga PHP?

Sí. La expiración de un nonce de WordPress puede producir el mismo mensaje. Los nonces de WordPress son válidos durante 24 horas de forma predeterminada. Si un usuario abre la página de carga de plugins, la deja inactiva durante más de 24 horas y luego envía el formulario, la validación del nonce falla y WordPress muestra "The link you followed has expired." En este caso, simplemente actualizar la página genera un nuevo nonce y la carga procede normalmente — no se necesitan cambios en la configuración PHP.