Solucionar el error 404 en WordPress tras migración

El error 404 tras migración en WordPress

El error 404 después de migrar un WordPress suele indicar que el servidor, WordPress o ambos no están resolviendo correctamente una URL que antes existía o que debería existir. En muchas migraciones el contenido sigue en la base de datos, pero fallan los enlaces permanentes, las reglas de reescritura, la ruta del sitio, el dominio, el certificado o la caché. Por eso no basta con comprobar si la portada carga. Hay que revisar páginas internas, entradas, categorías, productos y adjuntos.

En el ámbito general y también en España, esta incidencia aparece con frecuencia tras mover una web entre proveedores, cambiar de HTTP a HTTPS, sustituir el dominio principal o replicar una instalación desde un entorno de staging. Es común que el sitio parezca funcional durante unas horas y que el problema solo se detecte cuando llegan usuarios reales, rastreadores o campañas ya activas. Cuanto antes se identifique la causa exacta, menor será el impacto sobre SEO, conversiones y soporte.

• Un 404 puede afectar solo a ciertas URLs o a casi toda la web interna.
• La portada cargando no demuestra que la migración esté completa.
• El problema puede estar en WordPress, en el servidor o en el DNS.
• Las migraciones con cambio de dominio requieren revisar redirecciones y rutas absolutas.
• El impacto suele ser mayor en tiendas, landings y contenidos indexados.

Diagnóstico inicial del 404 y señales útiles

El primer paso es confirmar el alcance real del error. Conviene anotar si el 404 aparece en entradas, páginas, productos, medios, categorías o archivos concretos. También debe revisarse si afecta a usuarios conectados y no conectados, si aparece en móvil y escritorio, y si es consistente o intermitente. Un comportamiento irregular suele apuntar a caché, CDN, propagación DNS o reglas distintas entre servidor y aplicación.

Las señales útiles incluyen mensajes de Search Console sobre páginas no encontradas, avisos del hosting, cambios recientes en PHP, modificación del dominio principal, incremento de errores en logs, picos de CPU por bucles de redirección y tickets previos donde consten cambios de plugins o de estructura. Las comprobaciones deben ser prudentes. Por ejemplo, abrir enlaces de prueba, revisar ajustes de enlaces permanentes sin guardar todavía, verificar valores de URL del sitio y consultar logs antes de desactivar componentes en producción.

• Comprobar varias URLs reales con 404 y varias que sí cargan para acotar el alcance.
• Revisar Search Console, alertas del hosting y registros de errores del servidor.
• Confirmar si hubo cambios recientes de dominio, SSL, PHP, plugins o reglas de caché.
• Comparar la URL afectada con su slug, tipo de contenido y estructura de enlaces permanentes.
• Evitar acciones bruscas al inicio, como restauraciones parciales o borrados masivos sin copia previa.

Causas habituales del 404 tras migrar y cómo confirmarlas

La causa más habitual es que las reglas de enlaces permanentes no se hayan regenerado correctamente tras la migración. En Apache esto suele relacionarse con el archivo .htaccess y con la capacidad de WordPress para escribir o aplicar reglas. En Nginx interviene la configuración del servidor, ya que WordPress no puede resolver por sí solo las reescrituras si la directiva no está bien implementada. Otra causa muy común es que los valores de WordPress Address y Site Address no coincidan con el nuevo dominio o protocolo.

También son frecuentes las migraciones incompletas, donde faltan tablas, uploads, tipos de contenido o serializaciones correctas en la base de datos. Si la portada funciona pero las páginas internas no, conviene revisar primero la estructura de enlaces permanentes. Si unas URLs antiguas responden y otras no, puede haber redirecciones mal construidas, slugs alterados, taxonomías no registradas o reglas personalizadas perdidas durante el cambio. Confirmar cada hipótesis evita aplicar remedios genéricos que retrasan la resolución.

• Enlaces permanentes no regenerados o reglas de reescritura ausentes.
• Valores de sitio y dominio mal definidos en WordPress o en la base de datos.
• Migración incompleta de base de datos, medios o tipos de contenido personalizados.
• Redirecciones antiguas que siguen activas y apuntan a rutas inexistentes.
• Configuración del servidor distinta entre origen y destino, sobre todo en Nginx.

Seguridad, malware y cambios no previstos en URLs

Aunque el error 404 tras migración suele ser un problema de rutas y configuración, no debe descartarse un componente de seguridad. Hay casos en los que un plugin vulnerable, credenciales expuestas o permisos incorrectos han permitido cambios no autorizados en reglas, archivos o usuarios. También es posible que una limpieza previa, hecha con prisas, haya eliminado archivos esenciales o fragmentos de configuración necesarios para resolver URLs.

Los síntomas compatibles con una incidencia de seguridad incluyen redirecciones extrañas, usuarios administradores desconocidos, modificaciones recientes de archivos sin explicación, URLs que devuelven 404 solo en ciertas condiciones o avisos del proveedor sobre malware. La respuesta debe ser razonable y sin alarmismo: copia de seguridad antes de tocar, rotación de contraseñas, revisión de usuarios, comprobación de permisos, auditoría básica de plugins y temas, y análisis de integridad del sitio. Si hay sospecha fundada, conviene preservar evidencia técnica antes de limpiar o restaurar.

• Revisar si existen usuarios nuevos, cambios de permisos o archivos modificados sin trazabilidad.
• Comprobar plugins y temas desactualizados o con historial de vulnerabilidades conocidas.
• Rotar contraseñas de WordPress, hosting, FTP, base de datos y panel de control si procede.
• Guardar una copia íntegra antes de eliminar archivos o pasar herramientas de limpieza.
• Aplicar hardening básico para reducir riesgo de reinfección o nuevos cambios no autorizados.

Caché, rendimiento y estabilidad durante la corrección

Resolver un 404 tras migración exige controlar la caché y mantener la estabilidad. Una página puede seguir mostrando 404 por caché de plugin, servidor, proxy o CDN aunque la corrección ya esté hecha. Del mismo modo, un sitio con recursos muy ajustados puede responder con errores intermitentes que se confunden con incidencias de URL. Por eso interesa distinguir entre un 404 real, un contenido en caché y una caída por saturación.

La actuación recomendable es limpiar cachés de forma ordenada y en el momento oportuno, no al azar. Primero se confirma la causa, después se aplica la corrección y por último se purgan las capas necesarias. También conviene vigilar consumo de CPU, memoria PHP y límites de procesos si la migración coincide con cambios de versión, compresión o reglas de seguridad. Un entorno estable ayuda a verificar si el 404 se ha resuelto de verdad o si solo cambia de comportamiento según la capa que responde.

• Identificar si existe caché a nivel de plugin, servidor, CDN o navegador.
• Purgar cachés solo después de aplicar la corrección para validar el resultado real.
• Revisar límites de PHP, memoria y procesos si el sitio responde de forma irregular.
• Comprobar códigos HTTP y cabeceras para distinguir 404 reales de respuestas cacheadas.
• Evitar cambios simultáneos de rendimiento y URLs que dificulten el diagnóstico.

Plugins, temas y actualizaciones que alteran rutas

Algunos plugins y temas registran tipos de contenido, taxonomías, endpoints, slugs personalizados o reglas de reescritura que pueden dejar de funcionar tras una migración. Esto es frecuente en constructores visuales, plugins SEO, membresías, academias, directorios y tiendas. Si durante el traslado se actualizó WordPress, PHP o varios plugins a la vez, puede haberse producido un conflicto de compatibilidad que no existía en el entorno original.

La mejor práctica es trabajar con staging antes de tocar producción, registrar cambios y validar compatibilidades. Si el problema ha aparecido tras actualizar, conviene identificar qué componente genera las rutas afectadas y probar con una secuencia controlada. Desactivar todo de golpe en una web activa puede agravar el impacto. Es preferible aislar por bloques, revisar changelogs, comparar versiones y regenerar reglas cuando proceda. Si un plugin crítico fue eliminado, habrá que verificar qué URLs dependían de él y cómo reconstruirlas sin perder posicionamiento ni funcionalidad.

• Usar staging para probar migraciones, actualizaciones y cambios de slugs antes de publicarlos.
• Registrar versiones, fechas y orden de activación para mantener control de cambios.
• Revisar plugins que crean URLs propias, como WooCommerce, membresías o portfolios.
• Consultar compatibilidad con la versión de PHP y WordPress en el nuevo entorno.
• Si hay conflicto tras actualizar, aislar componentes de forma gradual y documentada.

Hosting, dominio y DNS en España tras una migración

En España, como en otros mercados, los proveedores de hosting ofrecen configuraciones muy diferentes en DNS, caché de servidor, versión de PHP, SSL y reglas de seguridad. Tras una migración, un error 404 puede deberse a propagación incompleta, al dominio apuntando a un directorio distinto, a una instalación en subcarpeta no resuelta o a reglas antiguas del entorno anterior que no existen en el nuevo. También puede intervenir el certificado si hay saltos entre HTTP y HTTPS o redirecciones encadenadas.

Conviene revisar registros DNS, directorio raíz asignado, versión de PHP, módulos o equivalentes de reescritura, límites de recursos y sistemas de caché del proveedor. Si la web envía correo transaccional, también interesa confirmar que formularios y avisos siguen funcionando después del cambio, ya que una migración defectuosa puede ocultar incidencias paralelas. El enfoque debe ser general, porque cada proveedor aplica condiciones y paneles distintos. Por eso siempre hay que contrastar la configuración concreta del servicio contratado.

• Verificar que el dominio y los DNS apuntan al destino correcto y ya propagado.
• Confirmar el directorio raíz, el SSL activo y el protocolo final que debe responder.
• Revisar versión de PHP, límites de recursos y cachés a nivel de servidor.
• Comprobar si Apache o Nginx requieren ajustes distintos para las reescrituras.
• Validar correo transaccional, formularios y notificaciones si la migración afectó al entorno completo.

Pruebas, accesos y documentación técnica del caso

Sin pruebas y sin accesos adecuados, la corrección del 404 se vuelve lenta e incierta. Lo razonable es reunir primero los datos mínimos para reproducir el fallo y mantener trazabilidad. Esto incluye accesos al administrador, panel del hosting, gestor de archivos o SSH cuando exista, base de datos, DNS si hubo cambio de dominio y herramientas de analítica o monitorización. También conviene saber si hay CDN, firewall o proxy delante del sitio.

En ámbito general, la documentación útil es la que permite responder qué cambió, cuándo cambió y qué evidencia dejó ese cambio. Cuanto mejor se conserve la secuencia de eventos, más fácil será decidir entre regenerar enlaces, ajustar servidor, restaurar una pieza concreta o corregir redirecciones. La falta de documentación no impide actuar, pero aumenta el riesgo de soluciones parciales y pérdida de tiempo.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins activos y changelog de la migración.
• Evidencias técnicas: logs del servidor, capturas, URLs afectadas, copias de seguridad y export de base de datos.
• Listado de URLs críticas con 404, incluyendo páginas, entradas, productos y recursos adjuntos.
• Acceso al panel del hosting, DNS, SSL y reglas de caché o CDN si están activas.
• Confirmación del origen y destino de la migración, con fechas y responsables de los cambios.

Plan de acción ordenado para resolver el 404

El orden de trabajo importa. Primero hay que contener el problema y evitar cambios improvisados. Después conviene hacer copia del estado actual, aunque esté fallando, porque puede contener evidencia o configuraciones que expliquen la incidencia. A continuación se diagnostica la causa principal: URLs del sitio, enlaces permanentes, reglas del servidor, DNS, contenido migrado, plugins que registran rutas y capas de caché. Solo entonces se aplica la corrección específica y se valida con una muestra de URLs representativas.

Una vez corregido el fallo, el trabajo no termina. Hay que verificar redirecciones, revisar Search Console, monitorizar errores 404 residuales y confirmar que no se han roto formularios, compras, páginas de campaña o integraciones. Si la web tiene tráfico o facturación, este paso es especialmente importante. El objetivo no es solo hacer que una URL cargue, sino recuperar coherencia técnica y reducir el riesgo de recaída.

• Contener y documentar el problema antes de realizar cambios sucesivos en producción.
• Crear una copia del estado actual y asegurar acceso a archivos, base de datos y hosting.
• Diagnosticar la causa principal con pruebas sobre URLs, reglas, dominio, DNS y caché.
• Aplicar la corrección mínima necesaria y verificar con una muestra amplia de contenidos.
• Monitorizar después con logs, Search Console y revisión funcional de áreas críticas.

Si ya se ha actuado o la web está en urgencia

No es raro llegar a una incidencia cuando ya se han hecho varios intentos de solución. Quizá se instaló un plugin de seguridad, se restauró una copia parcial, se cambió de hosting, se editó functions.php, se borró un plugin crítico o se intentó limpiar malware sin copia. En esos escenarios, lo más importante es frenar nuevas acciones impulsivas y reconstruir la cronología. Cada intervención puede haber modificado reglas, usuarios, slugs, permisos, tablas o cachés.

La cautela principal es no perder evidencia técnica. Si se sobrescriben archivos, se purgan todos los registros o se restauran copias incompletas en cadena, el diagnóstico se complica mucho. En urgencias conviene estabilizar primero lo esencial, preservar el estado actual y comparar contra la última versión conocida como correcta. Solo así podrá decidirse si conviene revertir, reparar sobre el sitio existente o rehacer parte de la migración con un procedimiento controlado.

• Detener nuevas modificaciones si ya se han probado varias soluciones sin trazabilidad clara.
• Guardar copia del estado actual antes de restaurar, limpiar o eliminar más componentes.
• Reconstruir la cronología de cambios para detectar qué intervención precedió al 404.
• Evitar tocar functions.php, reglas o base de datos sin un criterio verificable y reversible.
• Priorizar estabilización y evidencia técnica antes de aplicar medidas más agresivas.

Preguntas frecuentes

Estas dudas aparecen con frecuencia cuando el error 404 surge después de mover una instalación. La clave es diferenciar entre fallo de contenido, de URL y de configuración.

P: ¿Si la portada carga, la migración está bien hecha?

R: No necesariamente. Es habitual que la home responda mientras fallan entradas, páginas internas, productos o categorías por reglas de reescritura, slugs o configuraciones del servidor.

P: ¿Guardar de nuevo los enlaces permanentes suele resolverlo?

R: Puede resolver muchos casos, pero no todos. Si el problema está en Nginx, en el dominio, en una migración incompleta o en un plugin que genera rutas, hará falta revisar más elementos.

P: ¿Es buena idea restaurar una copia sin más?

R: Solo si se sabe qué se restaura y por qué. Una restauración parcial o desalineada con DNS, base de datos o archivos puede mantener el 404 o introducir errores adicionales.

P: ¿El 404 tras migración afecta al SEO?

R: Sí, especialmente si afecta a URLs indexadas, productos, categorías o páginas enlazadas externamente. Cuanto más tiempo permanezca el error y peor sea la redirección, mayor suele ser el impacto.

P: ¿Cuándo conviene pedir una revisión técnica?

R: Cuando el fallo afecta a muchas URLs, hay cambios acumulados, no se dispone de copia fiable o intervienen hosting, DNS, caché y plugins a la vez. En esos casos, el diagnóstico previo suele ahorrar tiempo y riesgos.