Quan la portada i wp-admin funcionen però les entrades i pàgines retornen 404, el servidor nou normalment no dirigeix les URLs amigables cap a index.php. La configuració d’Apache o Nginx, el document root o la ruta d’una instal·lació en subdirectori poden ser diferents dels de l’allotjament anterior.
No canviïs tots els slugs: habitualment el contingut continua a la base de dades.
Identifica l’origen del 404
Sol·licita un enllaç trencat i conserva’n les capçaleres i el cos. Compara’l amb un fitxer estàtic inexistent i amb /?p=POST_ID.
Interpreta:
/?p=ID funciona -> contingut correcte, problema de reescriptura
tots dos fallen -> problema més ampli d'URL, dades o routing
404 amb marca del servidor -> WordPress no rep la petició
404 del tema -> la petició arriba a WordPressFes la prova amb el domini canònic exacte i HTTPS.
Conserva la configuració actual
Desa una còpia de .htaccess i, si hi tens accés, del virtual host d’Apache o Nginx. Anota el document root i si WordPress és en un subdirectori.
No enganxis regles genèriques damunt de directives de seguretat, idiomes o multisite. En un hosting gestionat, consulta l’assignació activa a cPanel, Plesk o al proveïdor.
Regenera les regles d’Apache
Amb Apache, mod_rewrite i AllowOverride habilitats, visita Configuració > Enllaços permanents i desa sense modificar l’estructura.
Les regles habituals d’una instal·lació a l’arrel s’assemblen a:
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]Utilitza les regles que WordPress genera per a la instal·lació concreta. Els subdirectoris i multisite necessiten variants diferents.
Configura Nginx explícitament
Nginx ignora .htaccess. El bloc de servidor sol necessitar un fallback amb try_files:
location / {
try_files $uri $uri/ /index.php?$args;
}Valida i recarrega mitjançant controls autoritzats. No afegeixis blocs location duplicats ni exposis fitxers PHP. En alguns hostings, suport ha de modificar la plantilla.
Comprova el document root
Confirma que el domini apunta al directori que conté l’index.php i wp-config.php d’aquesta instal·lació. Una arrel incorrecta pot servir una portada copiada mentre totes les rutes interiors fallen.
Els àlies i dominis addicionals de cPanel o Plesk poden haver canviat durant la migració. Compara configuració i còpies abans de moure fitxers.
Alinea URLs i subdirectoris
Revisa home, siteurl, les constants i el possible cas en què el nucli viu a /wordpress però la URL pública utilitza /. Mantén correctament el front controller.
Substitueix dominis o rutes amb una eina compatible amb serialització, no amb SQL sense processar. En multisite, verifica les rutes i regles pròpies de la xarxa.
Revisa el proxy i la memòria cau
Cloudflare o l’allotjament poden conservar respostes 404. Repara primer l’origen, purga les URLs afectades i repeteix la prova amb la memòria cau calenta.
Les regles de proxy han de conservar ruta i query string. Compara origen i resposta pública. Evita enviar tots els recursos estàtics inexistents al procés de WordPress.
Preserva les redireccions existents
Abans de reemplaçar regles, inventaria els 301 de slugs antics, dominis, barra final i idiomes. Reaplica’ls en un ordre que no eviti WordPress ni generi bucles.
No enviïs tots els 404 a la portada: això crea soft 404, perjudica el SEO i amaga enllaços realment trencats.
Tracta multisite i idiomes per separat
Una xarxa multisite necessita regles adequades a la seva arquitectura, i DNS o SSL wildcard quan correspongui. Les rutes /es/ i /ca/ també s’han de resoldre correctament.
Prova administració de xarxa, cada lloc, REST, mitjans i dominis mapats. No utilitzis regles d’un lloc únic en una xarxa.
Verifica contingut i SEO
Prova entrades, pàgines, categories, feeds, REST, paginació, mitjans i URLs inexistents. Comprova canònics i redireccions.
Després de migrar, vigila els registres 404 i Search Console. La reparació acaba quan les URLs indexades mostren el contingut previst i les rutes inexistents mantenen un 404 real.