Vous ouvrez Google Search Console et vous constatez que la page d’accueil est indexée deux fois: en tant que site.ru/ et en tant que site.ru/index.php. Ou site.ru/index.html. Pour un moteur de recherche, il s’agit de deux URL différentes avec un contenu identique. Résultat: l’autorité de la page est divisée en deux entre les doublons, le classement chute et le budget d’exploration est gaspillé.

Le problème est aussi vieux que le Web. Le mécanisme est simple: par défaut, le serveur renvoie index.html ou index.php lorsqu’on appelle la racine via la directive DirectoryIndex, mais il ne bloque pas l’accès direct à site.ru/index.php. Du point de vue d’Apache, les deux adresses sont légitimes. Mais le moteur de recherche voit deux pages différentes avec un contenu identique et commence à deviner laquelle classer.

Voici trois façons de mettre en place une redirection 301 des fichiers d’index vers la racine: du .htaccess universel à Cloudflare en passant par Nginx. Avec en prime une méthode de vérification qui prend deux minutes.

💡 Aperçu rapide:

• Ajoutez des règles mod_rewrite dans le .htaccess pour intercepter les requêtes vers index.html et index.php
• Pour WordPress et les CMS, utilisez une redirection PHP dans le fichier d’entrée index.php (elle survit aux mises à jour des permaliens)
• Vérifiez le résultat avec curl -I ou redirectchecker.com (la réponse doit être 301 Moved Permanently)
• Parcourez les liens internes du site et remplacez /index.php par / dans les menus, les logos et les widgets

Pourquoi les doublons de fichiers d’index nuisent à votre site

Quand un visiteur tape site.ru dans la barre d’adresse, Apache substitue silencieusement index.html ou index.php conformément à DirectoryIndex. Le navigateur affiche la page, l’adresse reste propre et l’utilisateur ne remarque pas la substitution.

Mais si un lien vers le chemin complet site.ru/index.php existe déjà quelque part, le robot d’exploration le suit, voit le même contenu que sur site.ru/ et enregistre un doublon. D’où vient un tel lien? Les possibilités sont nombreuses: un ancien article sur un site tiers, un partenaire qui a indiqué la mauvaise URL, un plugin de partage social qui a généré un partage avec index.php à la fin, ou même le développeur qui a ajouté href="/index.html" dans la navigation lors de l’intégration.

Ce que l’on constate en pratique:

• Équité des liens divisée. Les backlinks sont répartis entre / et /index.php au lieu de s’accumuler sur une seule page canonique.
• Gaspillage du budget d’exploration. Le robot passe du temps à explorer des doublons au lieu de parcourir les sections utiles du site.
• Pertinence diluée. Le moteur de recherche ne comprend pas laquelle des deux pages afficher dans les résultats et peut alterner entre elles, les statistiques de comportement utilisateur sont faussées et le classement devient instable.

La situation est tout à fait maîtrisable. Elle se résout en mettant en place une redirection 301 permanente de index.html et index.php vers la racine /. Voyons les méthodes disponibles.

Méthode 1: redirection via.htaccess sur Apache

Le fichier .htaccess se trouve à la racine du site. S’il n’existe pas, créez un fichier texte avec un point au début du nom; n’importe quel client FTP ou gestionnaire de fichiers d’hébergement peut le faire.

Ouvrez .htaccess et repérez la ligne RewriteEngine On. Si elle n’y est pas, ajoutez-la comme toute première ligne après les commentaires. Elle active le module mod_rewrite responsable de toutes les redirections.

Sous RewriteEngine On, ajoutez les règles. Voici un jeu minimal fonctionnel:

1
RewriteEngine On
2
 
3
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
4
RewriteRule ^index\.php$ https://%{HTTP_HOST}/ [R=301,L]
5
 
6
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.html\ HTTP/
7
RewriteRule ^index\.html$ https://%{HTTP_HOST}/ [R=301,L]

Voici comment cela fonctionne ligne par ligne:

• RewriteCond %{THE_REQUEST} vérifie la chaîne de requête originale envoyée par le navigateur au serveur. Elle contient explicitement /index.php ou /index.html, ce qui est exactement ce que nous capturons.
• RewriteRule redirige la requête vers la racine du domaine avec un code 301 (redirection permanente). Le drapeau L (last) arrête le traitement des règles suivantes.
• %{HTTP_HOST} substitue automatiquement le domaine du site; vous n’avez pas besoin de le saisir manuellement. Le protocole est explicitement spécifié comme https://.

Remarque cruciale: n’utilisez pas la construction simplifiée Redirect 301 /index.php /. La directive Redirect de mod_alias boucle sur les fichiers d’index. Après la redirection vers /, Apache substitue à nouveau index.php via DirectoryIndex, la règle se déclenche encore et le navigateur renvoie une erreur de boucle infinie. La combinaison RewriteCond + RewriteRule via mod_rewrite analyse spécifiquement la requête originale (%{THE_REQUEST}), pas celle réécrite par les règles internes, donc aucune boucle ne se produit.

Les modifications dans .htaccess prennent effet instantanément; Apache relit le fichier à chaque requête et aucun redémarrage du serveur n’est nécessaire.

Méthode 2: redirection PHP pour WordPress et les CMS

Sur les sites utilisant WordPress, Joomla, Drupal et d’autres CMS, modifier .htaccess est risqué: le CMS le réécrit lors de la mise à jour des permaliens, du changement de structure d’URL ou de l’activation de plugins SEO. Vos règles peuvent disparaître à la prochaine sauvegarde des paramètres.

Pour WordPress, il existe une approche plus résiliente: une redirection directement dans le fichier d’entrée index.php. Il se trouve à la racine de l’installation du CMS et s’exécute à chaque requête, avant le chargement du cœur.

Ouvrez le index.php de WordPress et ajoutez tout au début, juste après la balise d’ouverture <?php:

1
<?php
2
// 301 redirect from index.php to root
3
if ($_SERVER['REQUEST_URI'] === '/index.php') {
4
    header('Location: /', true, 301);
5
    exit();
6
}
7
 
8
// Standard WordPress code follows
9
define('WP_USE_THEMES', true);
10
// ...

Pour les sites en PHP pur sans CMS, la logique est la même: placez le code dans le fichier d’entrée index.php à la racine du répertoire public. Si votre site utilise les deux fichiers d’index (index.php et index.html), ajoutez une vérification similaire pour index.html au début du même script.

Pourquoi cette méthode est plus fiable que la modification de .htaccess pour un CMS:

• Le code réside dans un fichier PHP que le CMS ne touche pas lors de la mise à jour des paramètres de permaliens.
• La vérification $_SERVER['REQUEST_URI'] capture spécifiquement l’URL demandée, pas celle réécrite par les règles internes de WordPress.
• exit() garantit l’arrêt de l’exécution; pas une seule ligne au-delà ne sera exécutée.

Sur les projets à fort trafic, la redirection PHP est légèrement plus rapide que la variante .htaccess: mod_rewrite n’a pas besoin de se lancer pour analyser des expressions régulières, ce qui économise des millisecondes à chaque requête.

Méthode 3: Cloudflare, Nginx et autres serveurs

Cloudflare. Si votre site passe par Cloudflare, vous pouvez configurer la redirection au niveau du CDN sans toucher du tout aux fichiers du serveur. Allez dans Rules → Redirect Rules et créez une règle:

• Champ: URI Path
• Opérateur: equals
• Valeur: /index.php
• URL de redirection: https://yourdomain.com/
• Code de statut: 301

Ajoutez une règle similaire pour /index.html. L’avantage: la redirection se déclenche sur les serveurs edge de Cloudflare et la requête n’atteint même jamais votre hébergement. L’inconvénient: le domaine doit être délégué aux NS de Cloudflare.

Nginx. Les sites sous Nginx n’utilisent pas .htaccess. Les règles sont ajoutées au fichier de configuration du serveur, généralement /etc/nginx/sites-available/yourdomain:

1
location = /index.php {
2
    return 301 https://yourdomain.com/;
3
}
4
 
5
location = /index.html {
6
    return 301 https://yourdomain.com/;
7
}

Après modification, vérifiez la syntaxe avec nginx -t et appliquez les changements: systemctl reload nginx.

LiteSpeed / OpenLiteSpeed. Le serveur prend en charge .htaccess avec les mêmes règles mod_rewrite qu’Apache; la méthode 1 fonctionne sans changement. Vous pouvez également utiliser le mécanisme de redirection intégré dans le panneau d’administration LiteSpeed WebAdmin.

IIS (Windows Server). Pour les sites sous IIS, la redirection se configure via le module URL Rewrite dans web.config:

1
<rule name="Redirect index.php to root" stopProcessing="true">
2
    <match url="^index\.php$" />
3
    <action type="Redirect" url="/" redirectType="Permanent" />
4
</rule>

Ajoutez une règle similaire pour index.html.

Comment vérifier que la redirection fonctionne

La méthode la plus fiable est la ligne de commande. Exécutez:

1
curl -I https://yourdomain.com/index.php

La première ligne de la réponse doit être HTTP/1.1 301 Moved Permanently et l’en-tête Location doit indiquer la racine du site. Répétez l’opération pour index.html. La page d’accueil à la racine / doit répondre avec le code 200.

Outils de vérification alternatifs:

• Redirect Checker (redirectchecker.com) affiche la chaîne complète de redirection avec les codes de réponse, pratique pour un diagnostic rapide sans terminal.
• Google Search Console → Inspection d’URL (l’outil d’inspection et de test): montre comment Googlebot voit la page après la redirection et si elle est disponible pour l’indexation.

Après avoir mis en place la redirection, il est crucial de vérifier les liens internes de votre site. Assurez-vous que les menus, le logo (qui renvoie généralement vers la page d’accueil), le fil d’Ariane et les blocs d’articles connexes pointent vers /, et non vers /index.php. Un seul lien interne cassé peut recréer le doublon que vous venez de supprimer. Faites une recherche dans le code source du site: ouvrez n’importe quelle page, appuyez sur Ctrl+U et cherchez href="/index.php" ou href="/index.html". Remplacez chaque occurrence par href="/".

Vidéo: une courte explication des redirections 301 par Google

Une vidéo de quatre minutes de Google Search Central, indispensable si vous configurez des redirections pour la première fois. John Mueller explique comment le moteur de recherche traite les redirections permanentes et s’il existe une limite à leur nombre:

⁉️🤔 Foire aux questions

Que se passe-t-il si je ne mets pas du tout en place de redirection depuis index.php?

Le moteur de recherche choisira une version canonique de lui-même, mais pas nécessairement celle que vous souhaitez. Une partie de l’équité des liens ira au doublon et les deux URL pourront alterner dans les résultats de recherche. Il n’y a pas de menace directe de pénalité, mais le classement sera inférieur à ce qu’il pourrait être avec une structure propre. John Mueller de Google a souligné à plusieurs reprises que la canonicalisation via rel="canonical" est une indication pour le moteur de recherche, pas une directive. Google peut ignorer la canonique et choisir une page différente s’il la juge plus pertinente. Une redirection 301 est une directive: elle garantit le transfert de poids et exclut le doublon de l’index.

Puis-je utiliser Redirect 301 /index.php / au lieu de mod_rewrite?

Techniquement oui, mais pour les fichiers d’index, c’est dangereux. Après la redirection vers /, Apache substitue à nouveau index.php via DirectoryIndex, la règle Redirect se déclenche encore, ce qui entraîne une boucle infinie et le navigateur coupe avec une erreur ERR_TOO_MANY_REDIRECTS. RewriteCond avec la vérification %{THE_REQUEST} n’a pas ce problème: elle analyse la requête originale du navigateur, pas celle réécrite par les règles internes du serveur.

Dois-je mettre en place une redirection si le site ne fonctionne qu’en HTTPS?

Oui. HTTPS et les doublons d’index sont deux problèmes indépendants. Même avec une redirection HTTP→HTTPS en place et un rel="canonical" correct, une requête directe vers https://site.ru/index.php renverra un code 200 sans redirection. Les règles de la méthode 1 couvrent les deux protocoles: RewriteRule spécifie explicitement https:// dans l’URL cible.

Comment vérifier que la redirection n’a pas cassé le site?

Trois points de contrôle: 1) la page d’accueil s’ouvre à la racine / sans redirection (curl -I doit renvoyer 200); 2) les URL avec index.php et index.html renvoient 301 et mènent à /; 3) l’administration WordPress (/wp-admin/) fonctionne sans boucle. Ce dernier point est critique: une règle mal écrite dans .htaccess peut intercepter les requêtes vers index.php à l’intérieur de l’administration et casser la connexion. La construction de la méthode 1 est sûre: elle vérifie une correspondance exacte de l’URI et ne touche pas à /wp-admin/index.php.

Qu’en est-il des autres fichiers d’index comme index.aspx ou index.py?

Le mécanisme est le même: copiez le bloc RewriteCond + RewriteRule, remplacez l’extension et ajoutez-le au .htaccess. Pour les extensions non standard, assurez-vous que le fichier existe physiquement à la racine et qu’il est listé dans DirectoryIndex; sinon, le serveur ne pourra de toute façon pas le servir comme fichier d’index et aucune redirection ne sera nécessaire.

Gérer les doublons de fichiers d’index: checklist finale

Mettre en place une redirection 301 de index.html et index.php vers la racine est une tâche qui prend «cinq minutes de travail, des années de protection». La règle vit dans .htaccess ou index.php de manière transparente et ne nécessite aucune maintenance lorsque vous changez de design ou que vous migrez vers un autre hébergement.

Étapes à suivre après avoir effectué les modifications:

• Vérifiez la redirection via curl -I ou redirectchecker.com; la réponse doit être 301.
• Assurez-vous que la page d’accueil s’ouvre à la racine avec un code 200.
• Cherchez href="/index.php" et href="/index.html" dans le code source des pages; remplacez chaque occurrence par href="/".
• Dans Google Search Console, lancez une inspection de la page d’accueil; le robot doit voir un 200 et l’URL canonique sans /index.php.

Après cela, les doublons disparaîtront progressivement du rapport «Couverture» dans Search Console et l’équité des backlinks se concentrera sur une seule page canonique. Le résultat n’est pas instantané (le moteur de recherche a besoin de temps pour réexplorer), mais il est inévitable.