NouveauBlack Friday : 50 % de réduction sur votre premier paiement
Dépannage WordPress

404 sur chaque page sauf la page d'accueil

Un modèle très spécifique avec une liste très courte de causes. Vos messages existent encore ; le routeur devant eux n'est pas routage.

404 Not Found — the requested page could not be found.

Réponse rapide

La page d'accueil est l'URL qui ne nécessite aucune règle de réécriture, c'est pourquoi elle est la seule survivante. Confirmez en demandant un message avec une chaîne de requête au lieu de son permalien — si cela charge, le contenu est bien et le calque de réécriture est le problème entier.

Diagnostic

Les causes les plus probables d’abord.

Parcourez la liste dans l’ordre. Vérifiez chaque cause avant de modifier quoi que ce soit : les correctifs diffèrent et une supposition coûte plus cher qu’une commande.

CauseComment vérifierCorrectif
Règles de réécriture en stale ou manquantesLa forme de la chaîne de requête d'un post charge et le joli permalien ne fait pas. Rien sur le contenu ne diffère entre les deux requêtes.Régénérer les règles. Enregistrer les paramètres permalink le fait par l'interface; sur la ligne de commande, c'est un appel unique.
Le serveur web n'envoie pas de chemins inconnus à WordPressLe 404 est la page propre du serveur Web plutôt que celle du thème. WordPress n'a jamais couru, donc il ne peut pas l'avoir produit.Ajoutez le fallback du contrôleur avant afin que tout chemin qui n'est pas un fichier réel soit remis à index.php. Sans cela, seule la racine du document résout.
AutoriserOverride est désactivé donc .htaccess est ignoréSur Apache, le fichier existe et est correct et il ne change pas du tout.Activer le Survol d'Automne pour le répertoire, ou déplacer les règles équivalentes dans l'hôte virtuel où elles sont toujours lues.
Une structure permalien que le site ne peut servirLe problème a commencé immédiatement après que la structure permalien a changé, et revenir à des permaliens simples restaure tout.Choisissez une structure et régénérez les règles. Une catégorie principale ou une base de type post-type personnalisé qui se heurte à un chemin de page existant est le piège habituel.
Guide

Corriger l’erreur, étape par étape.

Les commandes supposent un accès à WP-CLI et au terminal. Si vous n’en disposez pas, chaque étape explique comment procéder depuis le tableau de bord ou via SFTP.

  1. Prouvez que le contenu est toujours là

    Si cela se charge, rien n'est perdu et la correction est entièrement dans le calque de réécriture.

    curl -sS -o /dev/null -w '%{http_code}\n' 'https://example.com/?p=1'
  2. Régénérer les règles

    La première chose à essayer, et souvent la dernière.

    wp rewrite flush --hard
    wp rewrite list --format=count
  3. Vérifiez que le serveur est en fait retourné à index.php

    C'est la forme nginx. Sans elle, seuls les chemins qui existent sur le disque sont servis.

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }
  4. Restaurer un .htaccess connu sur Apache

    Le bloc stock. Si l'écriture ne change rien, L'Autorisation est désactivée et le fichier est ignoré.

    # BEGIN WordPress
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    # END WordPress
  5. Confirmer qu'un permalien réel résout maintenant

    Demandez à WordPress une URL qu'elle a générée elle-même, il n'y a donc aucune chance de tester un chemin qui n'a jamais existé.

    wp post list --post_type=post --posts_per_page=1 --field=url | xargs -I{} curl -sS -o /dev/null -w '%{http_code}\n' {}
Sur MagicWP

Ce que la plateforme prend en charge.

Le rechute du contrôleur frontal fait partie de la configuration nginx de chaque site dès sa création, de sorte que la version la plus courante de ce dernier, un serveur qui ne sert que les fichiers qui existent sur le disque, ne peut pas se produire. Il n'y a pas de .htaccess dans le chemin de requête à ignorer, écrasé par un plugin, ou perdu dans une restauration, parce que les règles vivent dans la propre configuration du serveur du site plutôt que dans un fichier à l'intérieur du webroot.

Questions fréquentes

Questions fréquentes.

J'ai perdu mes postes ?
Non. Le test de la chaîne de requête le prouve : le même post que 404s à ses charges permalink par ID. Seule la correspondance entre URL et contenu est cassée.
Pourquoi la page d'accueil fonctionne-t-elle encore ?
C'est la racine du document, donc il n'a pas besoin de réécriture pour être trouvé. Chaque autre URL dépend de la règle qui manque, c'est exactement pourquoi l'échec a cette forme.
J'ai fait le vide et rien n'a changé.
Cela indique une couche : le serveur ne livre pas des chemins inconnus à WordPress du tout. Flushing réécrit ce que WordPress sait, ce qui est inutile si la requête ne l'a jamais atteint.
Un plugin aurait pu causer ça ?
Oui — tout ce qui enregistre un type de poste ou de taxonomie personnalisé ajoute des règles, et l'ajouter sans rinçage laisse les nouvelles URLs 404ing jusqu'à ce que les règles soient reconstruites.
Erreurs associées

Si le problème vient d’ailleurs.

Ces erreurs peuvent se présenter de façon similaire dans le navigateur.