Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Administrador Medios Frontend

Los enlaces permanentes de WordPress devuelven 404 tras cambiar de hosting

Repara enlaces 404 tras migrar WordPress revisando reglas de reescritura, Apache o Nginx, document root y URLs canónicas.

Cuando la portada y wp-admin funcionan pero las entradas y páginas devuelven 404, el nuevo servidor normalmente no dirige las URLs amigables hacia index.php. La configuración de Apache o Nginx, el document root o la ruta de una instalación en subdirectorio pueden diferir del hosting anterior.

No cambies todos los slugs: el contenido suele seguir en la base de datos.

Identifica de dónde procede el 404

Solicita un enlace roto y conserva cabeceras y cuerpo. Compáralo con un archivo estático inexistente y con /?p=POST_ID.

Interpreta:
/?p=ID funciona -> contenido correcto, fallo de reescritura
ambos fallan -> problema más amplio de URL, datos o routing
404 con marca del servidor -> WordPress no recibe la petición
404 del tema -> la petición sí llega a WordPress

Prueba el dominio canónico exacto mediante HTTPS.

Conserva la configuración actual

Guarda una copia de .htaccess y, si tienes acceso, del virtual host de Apache o Nginx. Anota el document root y si WordPress reside en un subdirectorio.

No pegues reglas genéricas encima de directivas de seguridad, idiomas o multisite. En hosting gestionado, consulta la asignación activa desde cPanel, Plesk o el proveedor.

Regenera las reglas de Apache

Con Apache, mod_rewrite y AllowOverride habilitados, visita Ajustes > Enlaces permanentes y guarda sin cambiar la estructura.

Las reglas habituales para una instalación raíz se parecen a:

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Usa las reglas que WordPress genere para esa instalación. Subdirectorios y multisite necesitan variantes distintas.

Configura Nginx explícitamente

Nginx ignora .htaccess. Su bloque de servidor suele necesitar un fallback con try_files:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Valida y recarga mediante controles autorizados. No añadas bloques location duplicados ni expongas archivos PHP. Algunos hostings requieren que soporte modifique la plantilla.

Comprueba el document root

Confirma que el dominio apunta al directorio que contiene el index.php y wp-config.php de esta instalación. Una raíz incorrecta puede servir una portada copiada mientras todas las rutas internas fallan.

Los alias y dominios adicionales de cPanel o Plesk pueden cambiar durante la migración. Compara configuración y copias antes de mover archivos.

Alinea URLs y subdirectorios

Revisa home, siteurl, constantes y el posible caso en que el núcleo vive en /wordpress pero la URL pública usa /. Mantén correctamente el front controller.

Sustituye dominios o rutas con una herramienta compatible con serialización, nunca con SQL sin procesar. En multisite, verifica las rutas y reglas específicas de la red.

Revisa proxy y caché

Cloudflare o el hosting pueden conservar respuestas 404. Repara primero el origen, purga las URLs afectadas y repite la prueba con la caché caliente.

Las reglas de proxy deben conservar ruta y query string. Compara origen y respuesta pública mediante identificadores de petición. Evita enviar al costoso proceso de WordPress todos los recursos estáticos inexistentes.

Preserva redirecciones existentes

Antes de reemplazar reglas, inventaría los 301 de slugs antiguos, dominios, barra final e idiomas. Reaplícalos en un orden que no evite WordPress ni cree bucles.

No conviertas cada 404 en una redirección a la portada: eso produce soft 404, perjudica el SEO y oculta enlaces realmente rotos.

Trata multisite e idiomas por separado

Una red multisite necesita reglas generadas para su arquitectura, DNS y SSL wildcard cuando corresponda. Los idiomas /es/ y /ca/ también deben resolverse antes de localizar la entrada.

Prueba administración de red, cada sitio, REST, medios y dominios mapeados. No uses un ejemplo de sitio único para una red.

Verifica contenido y SEO

Prueba entradas, páginas, categorías, feeds, REST, paginación, medios y URLs realmente inexistentes. Comprueba canonicals y redirecciones.

Después de migrar, vigila los registros 404 y Search Console. La reparación termina cuando las URLs indexadas antiguas muestran su contenido y las rutas inexistentes conservan un 404 real.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia