Solucionar el error 404 en WordPress tras migración

Cuando aparece un error 404 wordpress tras migración, lo habitual es que la web siga cargando parcialmente pero algunas URLs de entradas, páginas, categorías o productos hayan dejado de resolverse correctamente. En la práctica, suele deberse a un desajuste entre la estructura de URLs guardada por WordPress, las reglas de reescritura del servidor, el cambio de dominio o ruta, o referencias antiguas que siguen en base de datos, caché o CDN.

La revisión inicial más útil consiste en comprobar si el fallo afecta a todo el contenido o solo a determinadas rutas, verificar la URL del sitio y la URL de WordPress, regenerar los enlaces permanentes y confirmar que Apache o Nginx están aplicando la configuración correcta para la nueva ubicación del proyecto. Antes de crear redirecciones en bloque, conviene identificar si el problema es estructural o si solo quedan URLs antiguas pendientes de normalizar.

Por qué aparece el error 404 en WordPress tras una migración

WordPress no sirve las URLs amigables únicamente desde la base de datos. Para que una URL como /blog/mi-entrada/ funcione, intervienen varios elementos: la estructura de permalinks, el valor de siteurl y home, las reglas de reescritura y la configuración del servidor web. Si uno de esos puntos no queda alineado tras la migración web, la petición puede terminar en una respuesta 404.

Algunos escenarios frecuentes en España son el cambio de dominio principal, el paso de HTTP a HTTPS, la salida de un subdirectorio a la raíz del dominio, la clonación desde un entorno de staging o el traslado entre hostings con stacks distintos. En esos casos, conviene pensar el problema en capas: URL pública, WordPress, servidor, caché y rastreo.

• La base de datos puede conservar rutas antiguas o absolutas que apuntan al dominio anterior.
• Los enlaces permanentes pueden no haberse regenerado correctamente tras el traslado.
• En Apache puede faltar o estar desactualizado el archivo .htaccess, o no aplicarse mod_rewrite según el hosting.
• En nginx wordpress, las reglas equivalentes dependen de la configuración del servidor y no se generan desde WordPress.
• Plugins de caché, caché de servidor o CDN pueden seguir sirviendo versiones antiguas de rutas ya modificadas.
• Puede haber URLs realmente inexistentes porque la estructura cambió y ahora requieren redirecciones wordpress bien planificadas.

No todos los 404 tras migrar wordpress significan lo mismo. A veces el contenido existe pero la reescritura falla; otras veces la URL pedida ya no corresponde con ningún recurso válido y lo correcto es redirigir o asumir el 404 si la página se eliminó de forma deliberada.

Qué revisar primero antes de tocar archivos o redirecciones

Antes de editar archivos, crear reglas o instalar plugins, merece la pena acotar el alcance real del problema. Esta fase ahorra tiempo y evita encadenar cambios sobre una causa mal diagnosticada.

Si la portada responde y el panel de administración funciona, pero casi todas las URLs internas devuelven 404, suele ser razonable sospechar primero de la reescritura y de la estructura de permalinks. Si solo fallan algunas rutas antiguas, conviene revisar cambios de slugs, taxonomías, plugins desactivados o reglas de redirección inexistentes.

También interesa confirmar que el contenido realmente existe en el nuevo entorno. En migraciones desde staging o copias parciales, puede ocurrir que se haya restaurado una base de datos anterior, que falten adjuntos o que determinadas tablas no correspondan con el estado más reciente del sitio.

Otro punto práctico: no confundas un 404 del servidor con una página 404 generada por WordPress o por el tema. La apariencia visual puede ser similar, pero técnicamente el origen no siempre es el mismo. Revisar los encabezados HTTP o los registros del servidor ayuda a distinguirlo cuando el caso se complica.

Cómo comprobar y regenerar los enlaces permanentes

Uno de los pasos más seguros y habituales es revisar la configuración de enlaces permanentes. WordPress guarda la estructura elegida y, al volver a guardar estos ajustes, intenta regenerar las reglas que necesita para resolver las URLs amigables. Esto puede corregir un error 404 wordpress cuando el problema está en la reescritura, pero no sustituye a una revisión completa del servidor ni corrige URLs antiguas por sí solo.

1. Entra en el panel de WordPress y revisa la estructura activa en Ajustes > Enlaces permanentes.
2. Confirma que la opción elegida coincide con la estructura que tenía el sitio antes de la migración, salvo que el cambio sea intencional.
3. Guarda de nuevo la configuración sin introducir cambios innecesarios.
4. Prueba varias URLs reales en una ventana privada del navegador tras vaciar cachés.

Si la migración incluyó un cambio de dominio o de ruta, conviene revisar además que la base de datos no mantenga referencias absolutas al entorno anterior. Esto es especialmente importante en imágenes, constructores visuales, opciones serializadas y algunos plugins que almacenan URLs completas. Una actualización incompleta de esas referencias no siempre genera 404 en todas las páginas, pero sí puede dejar rutas rotas de forma parcial.

Cuando el fallo persiste después de regenerar permalinks, no es buena idea seguir repitiendo el proceso como si fuese una solución universal. A partir de ese punto, tiene más sentido validar el archivo htaccess wordpress si el servidor usa Apache, o la configuración de bloques y reescritura si usa Nginx.

Qué hacer con .htaccess en Apache y con la configuración en Nginx

Aquí conviene separar claramente ambos entornos. WordPress no gestiona igual Apache que Nginx. En Apache, las URLs amigables suelen depender de reglas en .htaccess. En Nginx, las reglas equivalentes se definen en la configuración del servidor y no se escriben desde WordPress.

Si el hosting usa Apache

Lo razonable es comprobar si existe el archivo .htaccess en la raíz correcta del sitio y si contiene reglas coherentes con una instalación estándar de WordPress. Después de guardar los enlaces permanentes, WordPress suele intentar regenerarlo, pero esto depende de permisos de escritura y de cómo esté montado el alojamiento.

También conviene verificar que la instalación está apuntando a la carpeta adecuada y que el servidor permite aplicar reescrituras según su configuración global. En algunos hostings, el archivo existe pero no se está leyendo como se espera, o hay reglas heredadas de una web anterior que interfieren con el comportamiento actual.

Si el hosting usa Nginx

En Nginx, guardar los enlaces permanentes en WordPress no basta si el bloque de servidor no está preparado para resolver las URLs amigables hacia el punto de entrada correcto. Aquí la revisión no pasa por .htaccess, sino por la configuración real del servidor o del panel del proveedor, según el stack disponible.

Además, en algunos entornos administrados hay varias capas: Nginx frontal, caché de aplicación y reglas adicionales del hosting. Por eso, si una URL devuelve 404 en producción pero funciona en el panel o en una ruta directa, no conviene asumir que WordPress es el origen del fallo sin revisar la capa de servidor.

No mezcles configuraciones de Apache y Nginx en la misma intervención. Añadir o corregir un .htaccess no resolverá una incidencia que depende únicamente de Nginx, y viceversa.

Cómo detectar URLs afectadas y errores de rastreo en Search Console

Search Console es útil para diagnosticar el alcance del problema y validar si Google sigue rastreando URLs antiguas, pero no corrige el fallo por sí misma. Su valor está en ayudarte a distinguir entre incidencias aisladas, patrones de URLs rotas y errores heredados de la migración.

Lo más práctico es revisar qué rutas aparecen como no encontradas, desde cuándo se detectaron y si pertenecen al dominio actual o al anterior. Si el error se concentra en una carpeta antigua, en URLs con protocolo HTTP o en estructuras previas de categorías, ya tienes una pista clara sobre el tipo de ajuste pendiente.

• Compara muestras de URLs con 404 para ver si comparten patrón.
• Comprueba si esas URLs siguen enlazadas desde menús, módulos del tema o plugins.
• Valida si Google está solicitando versiones antiguas por un cambio de dominio o estructura sin redirección adecuada.
• Usa la información de cobertura como apoyo al diagnóstico, no como sustituto de la revisión técnica.

Si necesitas una referencia oficial, Google mantiene documentación de ayuda para la gestión de errores de rastreo y validación en Search Console. Aun así, la corrección siempre debe hacerse en WordPress, en el servidor o en las reglas de redirección correspondientes.

Además de Search Console, si tienes acceso a logs del servidor o a herramientas de analítica, conviene cruzar datos. A veces Google ya detectó el patrón, pero los usuarios reales están golpeando otras rutas distintas que no aparecen aún en los informes.

Cuándo aplicar redirecciones y cuándo no basta con ellas

Las redirecciones son apropiadas cuando una URL antigua ha cambiado a otra equivalente y quieres conservar la experiencia del usuario y la señal SEO de esa ruta. Son especialmente útiles tras cambios de dominio, de estructura de categorías, de slugs o al pasar de un subdirectorio a la raíz.

Sin embargo, las redirecciones wordpress no deberían usarse para tapar un problema global de reescritura. Si todas las páginas internas responden con 404 porque el servidor no está resolviendo bien las URLs amigables, crear cientos de redirecciones solo añade complejidad y no ataca la causa principal.

Cuándo sí conviene redirigir

• Cambio de dominio con correspondencia clara entre URLs antiguas y nuevas.
• Migración de HTTP a HTTPS con rutas equivalentes.
• Cambio de slugs o taxonomías por reestructuración editorial.
• Eliminación de una página sustituida por otra de intención equivalente.

Cuándo no basta con redirigir

• Cuando el sitio genera 404 masivos por reglas de reescritura rotas.
• Cuando la base de datos mantiene URLs internas antiguas que siguen incrustadas en contenido o ajustes.
• Cuando hay caché o CDN sirviendo respuestas obsoletas.
• Cuando el servidor está apuntando a una raíz incorrecta o a una configuración previa.

En algunos casos mixtos, primero se estabiliza la resolución técnica de WordPress y después se diseña el mapa de redirecciones necesario. Ese orden suele ser más limpio que intentar compensar con reglas un problema que todavía no está bien definido.

Checklist final para confirmar que la migración ha quedado estable

Una vez aplicados los ajustes, conviene cerrar la incidencia con una validación ordenada. La estabilidad no se confirma solo porque una o dos URLs vuelvan a abrir; interesa verificar el comportamiento del conjunto.

• La URL de WordPress y la URL del sitio coinciden con el dominio, protocolo y ruta finales.
• Los enlaces permanentes cargan correctamente y las URLs principales responden sin 404.
• Apache o Nginx aplican la configuración adecuada al entorno actual.
• No quedan reglas heredadas que rompan rutas nuevas o generen bucles.
• La caché del plugin, del servidor y de la CDN se ha vaciado y vuelto a comprobar.
• Las URLs antiguas críticas redirigen de forma coherente cuando corresponde.
• Search Console muestra una tendencia estable y las incidencias nuevas se reducen tras la corrección.
• Se han revisado muestras de páginas, entradas, categorías, adjuntos y formularios.

Como cierre editorial: los 404 después de una migración suelen concentrarse en unos pocos frentes repetidos, como cambios de dominio mal rematados, permalinks sin regenerar, reglas de servidor incompletas, caché persistente o rutas antiguas que siguen vivas en la base de datos. El error habitual es aplicar redirecciones o tocar archivos sin haber delimitado antes si el problema es global, parcial o puramente de rastreo.

Si ya has revisado WordPress, servidor y caché y aún aparecen URLs rotas, el siguiente paso razonable es hacer una auditoría técnica breve de migración para confirmar qué capa está fallando. En ese punto, contar con soporte wordpress o un plan de mantenimiento wordpress puede ayudarte a estabilizar la web sin seguir acumulando parches.