¿URLs devuelven 404 tras una migración o actualización? Es un fallo habitual que penaliza SEO, rompe conversiones y suele venir de reglas de reescritura corruptas, permisos erróneos o plugins conflictivos. Se necesita un diagnóstico rápido e intervenciones seguras: identificar si falla WordPress o el servidor y aplicar correcciones que restauren rutas y minimicen downtime.
Si tu web muestra errores por .htaccess o permalinks: primero guarda un backup y regenera las reglas desde Ajustes → Enlaces permanentes; luego verifica permisos (propietario y permisos 644), comprueba mod_rewrite en Apache o try_files en Nginx, desactiva plugins conflictivos y usa WP‑CLI para forzar el flush y depurar reglas si es necesario.
Resumen del proceso: 6 pasos claros para recuperar URLs
Sigue estos pasos para recuperar URLs y evitar 404 en menos de 60 minutos.
1. Backup y prueba rápida en WP: guarda .htaccess y pulsa Guardar en Enlaces permanentes.
2. Diagnóstico servidor: comprueba mod_rewrite o try_files y prueba con curl.
3. Restaurar o regenerar .htaccess o blocks de Nginx según servidor.
4. Revisar permisos y propietario (chown).
5. Aislar plugins y usar WP‑CLI para flush y pruebas.
6. Aplicar redirecciones 301 SEO y vigilar Search Console.
Usa este resumen como checklist: cada paso es ejecutable y suele llevar entre 5 y 30 minutos según el acceso al servidor.
Paso 1: comprueba y regenera permalinks en WordPress
Pulsa Guardar cambios en Ajustes → Enlaces permanentes para forzar la regeneración.
Si WordPress puede escribir .htaccess, con frecuencia eso soluciona una proporción importante de casos de 404 tras cambiar permalinks, aunque el porcentaje exacto depende del hosting, la caché y configuraciones adicionales; siempre conviene comprobar logs y confirmar el resultado con curl o herramientas de rastreo tras el guardado.
Si la web muestra 500 o bucles, no sigas hasta tener backup del .htaccess.
¿Por qué empezar por aquí?
Regenerar reglas desde el panel reescribe las reglas que WordPress necesita.
La mayoría de problemas se resuelven pulsando Guardar y comprobando si el .htaccess cambia.
¿Cómo comprobar si funcionó con curl?
Usa este comando: curl -I -L https://tudominio/slug
Observa el código HTTP y Location. Si ves 200, el problema se arregló.
Paso 2: diagnostica si el fallo es servidor o WordPress
Haz estas comprobaciones para identificar la capa responsable en menos de 20 minutos.
Saber si falla Apache, Nginx o WordPress evita ediciones innecesarias del .htaccess.
¿Cómo testear mod_rewrite en apache?
Ejecuta: apachectl -M | grep rewrite
Si aparece rewrite_module, mod_rewrite está activo.
Si no aparece, pide al hosting que active mod_rewrite.
¿Cómo testear try_files en nginx?
Revisa el server block con nginx -T | grep try_files
Busca la línea: try_files $uri $uri/ /index.php?$args
Si falta, añade la regla y recarga nginx.
1
Regenera permalinks en WP y comprueba respuesta HTTP
2
Si falla, prueba test.html en la raíz para distinguir servidor/WordPress
3
Revisa mod_rewrite (Apache) o try_files (Nginx) y los logs
4
Aísla plugins con WP‑CLI y aplica flush_rewrite_rules()
Un flujo de diagnóstico claro evita pruebas aleatorias: primero sube un fichero estático test.html en la raíz y comprueba con curl -I https://dominio/test.html. Si devuelve 200, el servidor y vhost están funcionando; el siguiente paso es acceder a /index.php directamente y luego a una URL que debería reescribirse. Si test.html devuelve 404 o 50x, el problema es del servidor/vhost (revisa tail -n 200 /var/log/nginx/error.log o /var/log/apache2/error.log). Si test.html es 200 pero las URLs de WP devuelven 404, comprueba mod_rewrite (apachectl -M | grep rewrite) o try_files (con nginx -T | grep try_files), permisos de .htaccess (ls -la .htaccess) y aísla plugins con wp plugin deactivate --all, volviendo a activarlos uno a uno.
Documentar los resultados esperados en cada paso (200/301/404/500) acelera la resolución y evita tocar .htaccess a ciegas.
Paso 3: restaurar o recrear .htaccess en apache
Haz un backup, reemplaza con el bloque mínimo oficial y ajusta propietario y permisos.
Esto tarda entre 5 y 15 minutos si se accede por SSH o SFTP con permisos adecuados.
¿Qué .htaccess pegar en un sitio único?
Copia exactamente este bloque y guárdalo como .htaccess en la raíz:
apache
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
¿Qué hacer si WordPress no puede escribir .htaccess?
Comprueba propietario con: ls -la .htaccess
Si owner no es el usuario del servicio web, cambia: sudo chown www-data:www-data .htaccess
Fija permisos: chmod 644 .htaccess
Más allá del bloque mínimo, conviene disponer de snippets algo más completos que combinen reescritura y seguridad para .htaccess y su equivalente en Nginx. En Apache se puede añadir protección para wp-config.php y xmlrpc, forzar HTTPS/WWW y evitar listado de directorios con algo como: # BEGIN WordPress...RewriteRule . /index.php [L]# END WordPress seguido de reglas para RedirectMatch 404 /wp-config.php y Order allow,deny Deny from all. En Nginx un bloque realista incluye try_files, manejo de PHP-FPM, redirección a https y reglas para denegar acceso a archivos sensibles: location ~* /wp-config.php { deny all; }.
Incluir estos snippets listos para pegar acelera la reparación y reduce errores humanos al copiar solo el bloque mínimo.
Paso 4: configurar nginx correctamente con try_files
Edita el server block y añade try_files para reenviar a index.php cuando haga falta.
Nginx no usa .htaccess, por eso muchos artículos llevan a error si confunden ambos servidores.
Ejemplo de server block mínimo
Copia este bloque en tu virtual host y ajusta root y socket PHP:
nginx
server {
listen 80;
server_name ejemplo.com www.ejemplo.com;
root /var/www/html;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}
}
Multisite y nginx: matices necesarios
Multisite en subdirectorios funciona con try_files, pero las reglas para archivos subidos cambian.
Para multisite, añade reglas específicas para /files/ o blogs.dir según la versión de WordPress.
Para instalaciones Multisite hay consideraciones técnicas que difieren del WordPress en sitio único y conviene tratarlas de forma explícita. En multisite por subdirectorios es crucial que las reglas de reescritura permitan resolver blogs/paths y el directorio de subidas; en Apache suele añadirse una excepción para /files/ o adaptar RewriteBase cuando la red es antigua. En multisite por subdominios hay que asegurar que el vhost acepte comodines (ServerAlias *.dominio) y que los registros DNS y virtual hosts apunten correctamente.
Además, las migraciones multisite requieren comprobar que las entradas de la tabla wp_blogs y wp_site estén actualizadas, y usar WP‑CLI (por ejemplo wp search-replace) para corregir dominios y rutas en la base de datos. Ignorar estos matices provoca 404 en solo una parte de la red o rutas rotas para blogs secundarios.
Paso 5: usar WP‑CLI para debug y reparación segura
Ejecuta comandos WP‑CLI para listar reglas, forzar flush y gestionar plugins sin tocar el admin.
Estos comandos suelen tardar segundos o pocos minutos y permiten rollback rápido.
Comandos clave de WP‑CLI
bash
wp rewrite flush --hard
wp rewrite list --format=table
wp option get permalink_structure
wp plugin deactivate --all
wp plugin activate redirection
¿Cuándo usar WP‑CLI en producción?
Usar WP‑CLI cuando el panel falla o cuando hay que hacer cambios masivos con poco downtime.
Funciona bien en entornos con SSH y permisos, pero siempre haz copias de seguridad antes de ejecutar comandos en producción.
Paso 6: redirecciones 301 (SEO) y cómo aplicarlas
Aplica 301 permanentes directas y actualiza sitemap y Search Console tras los cambios.
Evita cadenas de redirección y configura canonical; esto es esencial para retener tráfico orgánico.
Plantillas para redirecciones 301
En .htaccess (Apache):
apache
RewriteRule ^old-path/?$ /new-path/ [R=301,L]
En Nginx:
nginx
rewrite ^/old-path/?$ /new-path/ permanent;
Buenas prácticas SEO tras cambiar
Mantén redirecciones inmediatas y revisa Search Console en 48-72 horas para detectar errores.
Usar Screaming Frog o herramientas de rastreo permite verificar miles de URLs en horas.
Errores que arruinan el resultado y cómo evitarlos
Evita cambiar .htaccess sin backup, asumir que es siempre problema de WP y usar permisos 777.
Estos tres errores producen bucles, 500 y exposición de seguridad con frecuencia elevada.
¿Cuál es el error más frecuente aquí?
El error más frecuente en este punto es editar .htaccess en producción sin copia previa.
Esto genera bucles de redirección y downtime que pueden durar horas.
¿Qué falla la mayoría de guías y por qué?
La mayoría de guías dicen "edita .htaccess" y no diferencian Apache de Nginx.
Esto causa que administradores confundan servidores y apliquen soluciones inútiles.
Ejemplo anónimo de caso real
Un caso habitual: tras migrar a un VPS, se conservó .htaccess del hosting anterior → site en bucle → tráfico perdido durante 12 horas hasta restaurar backup y corregir vhost.
Comparativa rápida: apache vs nginx vs plugins
Lee la tabla para decidir la mejor vía según el control que tenga sobre el servidor.
| Criterio |
Apache (.htaccess) |
Nginx (server block) |
Plugins (Redirection, Yoast) |
| Control necesario |
Acceso a .htaccess o vhost |
Acceso a server block y reload |
Solo WP admin |
| Rendimiento |
Impacto bajo, procesamiento por request |
Más eficiente a nivel global |
Añade sobrecarga a WP |
| Seguridad |
Puede blindarse con .htpasswd y reglas |
WAF + nginx config ofrecen mayor control |
Depende de plugins y actualizaciones |
Para quienes necesiten una auditoría técnica puntual con diagnóstico, plan de reparación y presupuesto claro, Josu Barrios ofrece un servicio profesional de mantenimiento que incluye prueba en staging y reporte de cambios.
Preguntas frecuentes
¿Cómo recuperar permalinks sin perder SEO?
Usa redirecciones 301 desde las URLs antiguas a las nuevas.
Actualiza sitemap.xml y notifica Google Search Console.
Evita cadenas de redirección y revisa enlaces internos.
¿Qué permisos debe tener .htaccess?
El archivo .htaccess debe ser 644 con propietario del servidor web.
Si el servidor no puede escribirlo, cambiar propietario a www-data suele resolverlo.
Nunca uses 777 porque compromete la seguridad.
¿Cómo diferencio apache y nginx si no lo sé?
Revisa headers de respuesta o pregunta al hosting.
La presencia de un archivo .htaccess sugiere que el proyecto está preparado para Apache, pero no es concluyente: Nginx no lee .htaccess, y puede existir un .htaccess legado en instalaciones que en realidad se sirven por Nginx. Verifica el servidor con comandos (apachectl -M / nginx -T) o preguntando al hosting antes de basar la reparación en ese fichero.
Si el hosting documenta server blocks, usa configuración Nginx.
¿Qué hace wp rewrite flush --hard y cuándo usarlo?
El comando forza la regeneración de reglas de reescritura.
Se usa cuando el panel no puede escribir .htaccess o cuando se gestionan muchos sitios por script.
Haz backup antes de ejecutar en producción.
¿Cómo detectar si un plugin genera reglas?
Desactiva plugins y comprueba URLs; luego reactívalos uno a uno.
WP‑CLI permite desactivar todos y reactivar selectivamente para pruebas rápidas.
Plugins habituales que modifican reglas: Redirection y algunos SEO plugins.
¿Qué hacer si después de todo siguen los 404?
Comprueba logs del servidor y PHP-FPM para errores específicos.
Valida que el vhost apunte a la carpeta correcta y que DNS esté propagado.
Si el hosting aplica CDN, revisa reglas y cache del CDN.
¿Cómo proteger .htaccess contra inyecciones?
Restringe quién puede editarlo y monitoriza cambios con inotify o Tripwire.
Busca patrones sospechosos como eval o base64 en el archivo.
Activa WAF y revisa usuarios admin de WordPress.
Pasos finales y comprobaciones antes de cerrar
Confirma que todas las URLs importantes devuelvan 200 o 301 tras los cambios.
Revisa Search Console y herramientas de rastreo durante 72 horas.
Mantén backups diarios durante la primera semana tras cambios significativos.
La evidencia apunta a que más del 43% de los sitios usan WordPress, según W3Techs, lo que hace habituales los problemas de permalinks en migraciones y cambios de servidor.
Los proveedores como OVHcloud, SiteGround y Hostinger ofrecen herramientas para revisar logs y reglas del servidor; pide acceso a esos registros si hay dudas.
⚠️ Si tras aplicar todos los pasos no hay cambio, el problema puede estar fuera del servidor o WordPress: CDN, proxy inverso o reglas del proveedor. Contacta con el soporte del hosting y adjunta logs.
