Distinguer une absence d’indexation d’un manque de visibilité
Vous venez de mettre votre site WordPress en ligne, mais vous ne le trouvez pas dans Google. Commencez par distinguer trois étapes : Google découvre une adresse, explore son contenu, puis décide éventuellement de l’indexer. L’affichage pour une recherche donnée vient ensuite. Une page indexée peut rester difficile à trouver pour une expression concurrentielle.
Rechercher le nom commercial du site ne suffit donc pas à conclure à une panne d’indexation. L’opérateur site: peut donner des indices, mais sa liste n’est pas exhaustive et son nombre de résultats n’est pas un compteur fiable de toutes les pages indexées. Pour une adresse importante, utilisez l’inspection d’URL dans la Search Console lorsque vous y avez accès.
Le résultat recherché est d’identifier le stade où les pages essentielles se trouvent, de corriger un obstacle confirmé et de faciliter leur découverte. Aucune procédure ne garantit leur présence ni une date de classement. N’achetez pas un service promettant une indexation immédiate avant d’avoir vérifié si la page est simplement nouvelle, inaccessible, exclue volontairement ou déjà connue sous une autre adresse.
Choisir quelques pages témoins et leur adresse définitive
Préparez un petit relevé de lancement : l’accueil, une page importante de service ou de présentation et un contenu éditorial représentatif, si le site en possède. Utilisez leurs adresses publiques définitives, sans lien de prévisualisation ni paramètre lié à votre session. Le nombre de pages de cet échantillon est un choix de travail, pas une exigence de Google.
Pour chacune, notez sa date de publication, le domaine attendu et ce qu’un visiteur doit réellement lire. Distinguez la version HTTPS, la présence éventuelle de www, le sous-dossier et la langue. Une ancienne adresse qui redirige et la page finale ne sont pas la même URL à inspecter.
Ce relevé vous évite de mélanger les résultats de plusieurs variantes pendant les corrections. Il sert aussi à comparer un défaut général et une seule page isolée. Ne cherchez pas à faire indexer chaque résultat de recherche interne, chaque archive ou chaque URL technique. Priorisez les contenus qui apportent une réponse utile et que vous avez effectivement décidé de rendre publics. Gardez les espaces privés et la préproduction hors de ce périmètre.
Vérifier ce qu’un visiteur non connecté reçoit vraiment
Ouvrez les pages témoins dans une session sans connexion WordPress. Vérifiez le contenu complet et l’adresse finale, pas seulement un titre ou une page d’attente. Un administrateur peut voir un aperçu ou contourner une restriction que Google rencontrera. Une page accessible seulement après connexion ne répond pas aux conditions d’accès public nécessaires à son indexation ordinaire.
Dans Pages, Toutes les pages, ou Articles, Tous les articles, confirmez que chaque contenu prévu pour le lancement est publié et non resté en brouillon, en attente ou privé. Si une protection est volontaire, conservez-la. Un mot de passe ne doit pas être retiré d’un document confidentiel dans le seul but d’augmenter un total d’URL indexées.
Sur WordPress autohébergé, ouvrez aussi Réglages, Lecture et relevez l’état de la demande de découragement de l’indexation. Une case cochée fournit un indice de configuration à traiter pour les seules pages réellement destinées au public. Elle ne constitue pas un mécanisme de confidentialité. Si la page affiche une erreur, un défi de protection ou une redirection inattendue, résolvez d’abord ce trajet avant de demander une nouvelle exploration.
Ouvrir la propriété Search Console correspondant au site
La Search Console permet de consulter les informations que Google fournit sur votre site. Vous devez disposer d’un accès autorisé à la propriété concernée. Si un prestataire la gère déjà, demandez-lui de vous accorder l’accès adapté au lieu de créer une propriété concurrente avec un compte que l’organisation ne maîtrise pas.
Dans le sélecteur de propriétés, choisissez le domaine ou le préfixe correspondant aux pages témoins. Une propriété de préfixe d’URL est limitée au préfixe exact, protocole compris. Une propriété de domaine couvre plus largement les protocoles et sous-domaines. L’absence de données dans une propriété HTTP ne démontre rien sur une page HTTPS située hors de son périmètre.
Si aucune propriété adaptée n’existe, ouvrez le sélecteur, puis Ajouter une propriété et choisissez le type correspondant à vos accès. Cette opération organise votre suivi ; elle ne publie pas le site et ne provoque pas son indexation. Conservez l’identité du compte propriétaire et la personne qui gère les accès. N’utilisez pas les identifiants Google d’un collègue pour pouvoir terminer un diagnostic.
Valider une nouvelle propriété sans changer la destination du domaine
Pour une propriété de domaine, la validation passe par les DNS. Ce parcours convient si vous contrôlez la zone DNS ou si son responsable peut intervenir. Il ajoute une preuve de propriété ; il ne demande pas de déplacer le site vers un autre serveur. Les interfaces varient selon le gestionnaire DNS, donc utilisez aussi ses instructions pour le champ Hôte ou Nom.
Si vous ne disposez pas de ces droits, utilisez une méthode proposée pour une propriété de préfixe d’URL ou obtenez l’accès à une propriété existante. Ne modifiez pas des enregistrements de messagerie ou l’adresse du serveur pour essayer de valider la Search Console.
- Dans l’écran de validation, récupérez l’enregistrement TXT propre à votre propriété lorsque cette méthode est proposée.
- Chez le gestionnaire de la zone DNS active, ajoutez un enregistrement TXT avec le nom demandé ; à la racine, le fournisseur peut demander @ ou un champ vide.
- Collez la valeur complète fournie par Google, sans remplacer un autre enregistrement existant.
- Enregistrez, puis revenez à la Search Console et cliquez sur Valider. Si la preuve n’est pas encore détectée, vérifiez la zone utilisée et laissez le délai de prise en compte nécessaire.
- Conservez l’enregistrement de validation après réussite : le retirer peut faire perdre la preuve de propriété.
Consulter d’abord le dernier état connu d’une page
Dans la propriété correcte, collez l’adresse complète d’une page témoin dans la barre d’inspection en haut de la Search Console. Consultez l’état et le motif détaillé de non-indexation, puis notez la date d’exploration lorsqu’elle est disponible. Ce premier résultat décrit les informations connues de Google ; il ne représente pas automatiquement la page actuelle.
Comparez la date à votre mise en ligne. Si elle précède le retrait d’une page d’attente, le résultat peut encore refléter cet ancien état. Ne changez pas de nouveau toute la configuration pour corriger une observation historique. Conservez ce point de comparaison avant de lancer le test actif.
Si Google indique une autre URL canonique, relevez-la plutôt que d’envoyer immédiatement la même page sous plusieurs variantes. L’inspection doit aider à choisir une action précise. Reprenez ensuite une deuxième page témoin pour savoir si le motif se retrouve à l’échelle du lancement ou concerne seulement un contenu.
Comparer avec le test de l’URL active
Depuis le résultat d’inspection, cliquez sur Tester l’URL active. Lisez le résultat actuel et comparez-le à celui conservé précédemment. Si l’outil permet d’afficher la page testée, vérifiez que son contenu correspond à votre lancement plutôt qu’à une page d’attente. Une réussite indique seulement que ce contrôle n’a pas trouvé certains obstacles ; elle ne garantit pas l’indexation.
Notez séparément la date du test et celle de la dernière exploration connue. Si l’obstacle historique a disparu, le prochain enjeu peut être la prise en compte de la nouvelle version. Si le même blocage est encore présent, corrigez-le avant toute demande répétée.
Gardez les URL finales stables pendant cette comparaison. Changer à chaque essai le domaine, le titre et le chemin rend les résultats difficiles à interpréter. Si vous découvrez une redirection, identifiez aussi sa cible en ouvrant normalement l’adresse publique ; ne supposez pas que le test actif décrit nécessairement l’ancienne adresse saisie.
Choisir une correction d’après le motif confirmé
Un motif noindex conduit à rechercher la consigne d’exclusion encore envoyée. Si la seule cause confirmée est la case native de Réglages, Lecture, sur un site réellement prêt pour le public, décochez la demande de découragement puis cliquez sur Enregistrer les modifications. Refaites le test ; d’autres réglages de page ou en-têtes peuvent encore exclure le contenu. Gardez la valeur initiale pour revenir sur cette seule modification si le lancement doit être annulé.
Un blocage robots.txt concerne l’exploration : examinez la règle applicable au chemin, sans remplacer tout le fichier par un modèle générique. Une redirection ou une autre page canonique peut expliquer que la variante inspectée ne soit pas indexée séparément. Une erreur du serveur demande de rétablir une réponse normale avec l’hébergement.
Priorisez le motif qui empêche effectivement la page témoin d’être traitée. Évitez d’appliquer ensemble une nouvelle extension SEO, un changement de permaliens, une suppression de robots.txt et une purge générale. Après chaque correction, vérifiez le même contenu et gardez la trace de son effet. Une exclusion volontaire d’une page technique ne doit pas être transformée en incident de lancement.
Passer un site WordPress.com prêt au lancement en mode public
Sur WordPress.com, une page peut sembler prête dans votre compte alors que le site entier est encore en mode Coming Soon ou Private. Ce parcours concerne uniquement un site dont vous avez validé la publication. Vérifiez d’abord qu’aucun contenu confidentiel ou document de travail n’y deviendra accessible.
Dans le tableau de bord du site, ouvrez Réglages, Lecture, puis Site Visibility. Si le site est déjà lancé, sélectionnez Public et cliquez sur Save Changes. Lorsqu’il n’a pas encore été lancé, suivez plutôt l’action de lancement proposée dans cet espace. Ne choisissez pas un changement d’offre comme solution par défaut à une simple visibilité non publique.
Ouvrez ensuite l’accueil et les pages témoins sans connexion pour vérifier ce que les visiteurs reçoivent. Si une ancienne page d’attente persiste, examinez d’abord le cache concerné. Pour revenir à l’état de visibilité précédent, utilisez ce même écran, tout en sachant que des visiteurs ou robots ont pu voir le contenu pendant son ouverture. Rendre de nouveau le site privé ne retire pas instantanément toutes les traces déjà diffusées.
Donner un chemin de découverte aux pages essentielles
Si la page est publique mais encore peu connue, vérifiez qu’on peut la rejoindre depuis une page accessible du site. Un contenu présent uniquement dans votre administration ou dans un document privé n’offre pas le même chemin de découverte qu’un lien public. Pour ce premier contrôle de lancement, choisissez un lien utile au lecteur, sans transformer tout le pied de page en catalogue.
Le résultat attendu est un lien ordinaire qui ouvre la bonne page dans une visite sans connexion. Cela facilite sa découverte sans garantir que Google la retiendra. Conservez le texte initial de la page source pour annuler ce seul ajout si l’emplacement ne convient pas.
- Dans Pages, ouvrez une page publique pertinente que les visiteurs peuvent déjà atteindre.
- Dans un bloc Paragraphe, rédigez une courte phrase qui présente réellement la page de destination.
- Sélectionnez les mots décrivant cette destination, utilisez le bouton Lien ou Ctrl+K, puis insérez son adresse publique définitive.
- Validez le lien et enregistrez la page avec l’action habituelle de mise à jour.
- Dans une session déconnectée, ouvrez la page source et suivez le lien. Corrigez sa destination si vous arrivez sur une prévisualisation, une connexion ou une erreur.
Signaler le sitemap déjà disponible
Un sitemap est un fichier qui signale des URL à explorer. Il peut aider pour un nouveau site, mais sa lecture ne garantit pas l’indexation de chaque page. WordPress possède un système natif, habituellement accessible à wp-sitemap.xml à la racine publique de l’installation ; une extension ou une configuration peut le remplacer ou le désactiver. Utilisez l’adresse réellement disponible, pas un nom supposé universel.
Ouvrez ce sitemap sans connexion et confirmez qu’il concerne le domaine final. Si un système SEO gère déjà ce fichier, conservez ce responsable plutôt que d’installer un deuxième générateur. Une erreur de lecture ou des URL de préproduction demandent une correction de ce système avant l’envoi.
Dans la propriété Search Console appropriée, ouvrez Sitemaps. Avec les droits de propriétaire requis, saisissez l’adresse du fichier dans Ajouter un sitemap, puis cliquez sur Envoyer. Revenez lire l’état et les détails éventuels. Un statut de lecture réussie valide le traitement du fichier, pas celui de toutes ses pages. Si vous retirez ensuite une entrée du rapport pour annuler un mauvais envoi, Google n’oublie pas pour autant les URL qu’il a déjà découvertes.
Demander une exploration ciblée après les vérifications
Pour quelques pages importantes que vous contrôlez, l’inspection d’URL propose Demander une indexation. Cette action nécessite un propriétaire ou un utilisateur disposant d’un accès complet à la propriété. Employez-la après avoir vérifié que le contenu est public et que l’obstacle connu est corrigé, plutôt que pour tenter de contourner une exclusion encore active.
Sélectionnez l’adresse finale dans l’inspection, puis utilisez Demander une indexation et lisez la confirmation ou le motif de refus. Notez la date dans votre relevé de lancement. Si la demande est acceptée, elle constitue une demande de traitement, pas une promesse d’inclusion. L’exploration peut prendre plusieurs jours ou semaines et toutes les pages demandées ne seront pas nécessairement indexées.
Les demandes individuelles sont soumises à un quota ; les répéter pour la même URL n’accélère pas l’exploration. Pour beaucoup d’adresses, préférez le sitemap existant. Il n’y a pas de bouton de retour qui annule une exploration déjà effectuée : vérifiez donc le caractère public du contenu avant l’envoi. Ne transmettez jamais de liens privés de prévisualisation dans l’espoir de faire découvrir la future page.
Si la page est explorée mais toujours non indexée
L’état Explorée, actuellement non indexée signifie que Google a déjà consulté la page sans la retenir dans l’index à ce stade. Détectée, actuellement non indexée correspond à une adresse connue mais pas encore explorée. Ne transformez pas ces deux situations en diagnostic automatique de sanction ou en certitude qu’un plugin manque.
Lorsque l’accès fonctionne, relisez la page comme un visiteur : répond-elle à une question précise, avec les informations promises par son titre ? Une page de service contenant seulement deux phrases de remplacement, un catalogue de démonstration ou un texte dupliqué depuis un autre site mérite un travail éditorial avant une nouvelle demande. Ajoutez les informations nécessaires à la décision du lecteur, pas du texte pour atteindre un nombre de mots supposé favorable.
Comparez également les variantes proches : plusieurs pages presque identiques peuvent avoir peu de raison d’être indexées séparément. Identifiez leur rôle avant d’effacer ou de rediriger quoi que ce soit. Conservez les contenus originaux pendant cette analyse et faites valider les regroupements. Aucun score SEO ni longueur arbitraire ne garantit qu’une page sera finalement choisie.
Vérifier les restrictions particulières sans supposer une sanction
Dans la Search Console, consultez les rapports Actions manuelles et Problèmes de sécurité lorsqu’un signal le justifie, notamment pour un domaine réutilisé ou une ancienne installation. Une action manuelle signalée demande de lire son motif, de corriger le problème et de suivre le parcours de réexamen correspondant. Une demande d’indexation ordinaire ne remplace pas cette procédure.
Un problème de sécurité appelle un traitement du site et de ses accès avant de chercher à accélérer sa découverte. Les exemples d’URL fournis sont des indices à examiner, pas nécessairement la liste complète de tout ce qui est touché. Faites conserver les preuves et utilisez un canal privé pour les informations sensibles.
Un rapport vide ne prouve pas que toutes les conditions de classement sont remplies ; il vous évite simplement d’inventer une action signalée qui n’existe pas dans cet écran. Sur un lancement ordinaire sans autre indice, ne commencez pas par changer de domaine ou réinstaller WordPress. Appuyez chaque intervention sur une observation et gardez les responsables du contenu, de la sécurité et de l’hébergement informés de leur périmètre.
Suivre le lancement avec des critères vérifiables
Reprenez votre relevé après les corrections : chaque page témoin doit afficher le bon contenu sans connexion, conserver son adresse définitive et présenter un état technique cohérent. Notez les tests actifs, l’envoi éventuel du sitemap et les demandes individuelles. Vérifiez plus tard l’état connu de Google, avec sa date, plutôt que de répéter les mêmes actions à quelques minutes d’intervalle.
La résolution technique et la décision d’indexation sont deux résultats à consigner séparément. Vous pouvez avoir retiré une page d’attente et validé l’accès sans que Google ait encore retenu le contenu. Inversement, une ancienne version peut rester connue alors que le site actuel a de nouveau un problème. Cette distinction rend le suivi plus utile qu’un simple compteur vert.
Pour demander de l’aide, fournissez les URL finales des pages témoins, leur date de lancement, le type de propriété, les motifs d’inspection et les modifications effectuées. Ne partagez ni compte Google, ni accès DNS, ni sauvegarde de la base. Précisez si le site est auto-hébergé, sur WordPress.com ou dans un multisite. Le dossier permet de traiter l’obstacle réel, sans promettre une date d’indexation ni refaire les réglages déjà vérifiés.
Tester le lancement avec trois URL précises
Prenez l’accueil, une page de service et une page de contact. Par exemple, relevez la racine du domaine, /reparation/ et /contact/. Ajoutez éventuellement une page volontairement réservée comme témoin des exclusions. Pour chaque adresse publique, notez la réponse finale, le premier texte réellement reçu, la présence d’une directive noindex et la possibilité d’atteindre la page en suivant un lien. Faites l’essai sans compte connecté. Une page d’attente peut répondre avec un statut 200 et rester une mauvaise réponse pour ce contrôle.
Si vous avez accès à un terminal, remplacez l’adresse ci-dessous par l’URL publique exacte. Sous Windows, utilisez curl.exe si votre shell interprète curl autrement. La commande fait une requête GET, suit les redirections, montre les en-têtes de chaque réponse et met le HTML final dans un fichier local. Lisez le dernier bloc d’en-têtes pour repérer X-Robots-Tag. Ouvrez ensuite le fichier comme texte pour chercher la balise robots, la canonique et un texte attendu. Cette commande utilise l’accès ordinaire d’un visiteur. Search Console sert à tester l’accès de Google à cette URL.
curl -sS -L -D - -o page-temoin.html https://exemple.test/reparation/Refaire les mêmes observations après chaque correction
Dans un essai local sur WordPress, l’accueil et la page de service renvoyaient déjà le bon contenu. Tant que le réglage natif décourageait les moteurs, la page de service portait noindex. Après modification de ce seul réglage, la consigne a disparu, le sitemap natif est devenu accessible et le lien depuis l’accueil menait toujours à la même page. Le retour au réglage initial a rétabli noindex. L’essai vérifie la réponse du site de test à un visiteur, ainsi que la présence d’un chemin de découverte. Il faut une URL publique autorisée et une propriété Search Console pour observer la situation dans Google.
Appliquez le même raisonnement sur votre échantillon. Si l’accueil est normal mais que /reparation/ répond en 404, corrigez l’adresse ou la publication de cette page. Si plusieurs pages publiques renvoient toutes une consigne d’exclusion, identifiez d’abord le réglage commun. Si la page de contact est la seule absente des menus et que le reste fonctionne, créez un lien depuis une page publique utile et vérifiez sa destination. Pour chaque intervention, gardez une copie de la règle, du lien ou du réglage précédent afin de pouvoir rétablir ce seul changement.
Décider à partir de l’inspection et de son horodatage
Dans Search Console, ouvrez Inspection de l’URL pour la page de service. Si l’état connu indique une exclusion par noindex mais que le test de l’URL active voit maintenant le bon contenu et autorise l’indexation, notez l’heure du changement et la date de la dernière exploration connue. Une différence entre ces observations peut correspondre à un état historique. Vous pouvez demander une exploration pour cette URL importante avec les droits nécessaires, puis revoir le relevé après un nouvel examen.
Si l’état connu indique « Détectée, actuellement non indexée », vérifiez le lien depuis une page déjà accessible et la présence de l’URL finale dans le sitemap pertinent. Si Google indique avoir déjà exploré cette URL sans l’indexer, comparez la page à une autre qui remplit la même fonction. Vérifiez en particulier qu’elle répond à un besoin distinct, présente le contenu attendu et désigne la bonne URL canonique. Corrigez un problème observé avant de soumettre de nouveau une demande. Si l’URL est déjà indexée, utilisez ensuite le rapport Performances de la propriété et ses filtres de page pour examiner les impressions disponibles. Une URL peut être indexée et apparaître rarement pour les requêtes que vous suivez.
