Google me dit que ma page est bien indexée mais bloquée par robots.txt

[zakuli]

Bonjour,

J'ai du mal à faire en sorte que les pages de mon site puissent apparaissent sur une interrogation d'un navigateur.

Pourtant lorsque je mets à disposition mon sitemap, google (https://search.google.com/search-console/sitemaps/info-drilldown?resource_id__ ...) me dit le traitement du sitemap est réussi !

Quand j'inspecte une des pages concernées (https://search.google.com/search-console/inspect?resource_id=...) , google me dit que la page est bloquée par le fichier robots.txt

Pourtant quand je soumets la page au testeur du fichier robots.txt (https://www.google.com/webmasters/tools/robots-testing-tool?hl=fr&siteUrl=...), le test dit que ma page est autorisée !

Je ne comprends pas pourquoi

• d'un côté ma page est autorisée par mon mon robots.txt
• mais de l'autre bloquée aussi par mon fichier robots.txt ????

Que faut il que je fasse maintenant ?

Merci de vos réponses
Cordialement

 

[nantesweb]

Cela peut-être plusieurs choses :

• La façon dont est rédigé le robots.txt
• Un blocage Htaccess (dans ce cas j'ai déjà vu qu'il ne faisait pas la différence)
• Une interdiction dans le CMS via la base ou une meta

A regarder

En tout cas je viens de découvrir que la priorité est au robots.txt

En effet je viens de me rendre compte sur un des mes sites en devenir que j'avais carrément bloqué l'indexation ! La case "interdire aux moteurs d'indexer ce site" était toujours cochée. Pourtant je suis dans les résultats de recherche même en troisième page.

Mais comme j'avais autorisé spécifiquement Google dans le robots.txt, il n'a pas tenu compte de la meta, intéressant...

 

[WebRankInfo]

Que faut il que je fasse maintenant ?

indiquer ici l'URL de la page concernée

 

[zakuli]

Bonjour et merci à tous les deux de me répondre aussi vite.
l'URL est https://www.armor-vietnam.com
Je vous ai mis le robots.txt, j'ai voulu y ajouter le sitemap (nommé 3.xml sur le site) mais les extension .xml sont refusées. J'ai voulu le transférer avec l'extension .txt, mais sans résultat.
Cordialement
Jacques

 

[zakuli]

Ah désolé pour les trois fichiers 3.txt un suffisait; mais je ne voyais pas qu'il avait déjà été transféré

 

[WebRankInfo]

je ne demande pas le nom de domaine mais l'URL précise de la page indexée malgré le blocage du robots.txt

en tout cas ce robots.txt me semble bien trop compliqué. Pourquoi interdire tout ça ?

 

[cthierry]

Heu ton site n'est pas accessible à la racine là. La première fois, il m'a envoyé sur "armor-vietnam.com/art_edi_page.php?ap_id=1" et en enlevant les paramètres, je n'ai plus rien hormis une feuille de style basique.

 

[zakuli]

Bonjour à vous trois,

Bien que le sitemap ait été validé par google et que toutes les pages qui y sont inscrites soient déclarées autorisées par le test url/robot, toutes les pages existantes dans le sitemap (ex: https://www.armor-vietnam.com/art_edi_art.php?a=3&a_id=5554) sont indiquées bloquées par la console et donc n'apparaissent pas dans l'indexation de Google.

Le robot interdit l'entrée dans tous les répertoires où il n'y a pas de page à éditer : Seules sont autorisée les url passant par art_edi_art (associé à un n° d'article) et art_edi_page (associé à une page : en général ces pages éditent une liste de vigniettes qui donnent accés à des articles)

Désolé, je sais que mon site est compliqué, en fait il s'agit d'une petite plateforme pouvant supporter plusieurs associations et où chaque site d'association est paramétré (mise en forme, données des asso, ...) en base de données et où tous les textes d'articles sont eux aussi en base de données.
Les fichiers php ne sont là que pour donner des fonctionnalités à la plateforme, et à priori aucun de ces fichiers ne supporterai une page web sans accès à la base de données.
Jusqu'à récemment les sites web concernés n'étaient qu'un lien interne aux associations, tous les membres connaissaient parfaitement l'adresse de leur site et le besoin d'indexation par Google n'était pas nécessaire !

Pour Thierry, effectivement dès l''entrée dans le site, une page est attribuée via la base de donnée, et aucune page ne pourra être éditée sans cette redirection. D'ailleurs pour la majeure partie des associations la page d'entrée est : ap_id=1. Mais le paramétrage pourrait permettre de spécifier une autre page.

Je sais que ce site n'est sans doute pas bien écrit et il mériterait une refonte complète mais tout en gardant la plateforme multisite, ce qui nous permet de mettre à disposition de nos petites associations peu argentées un site internet pour une dizaine d'euros et avec de multiples fonctionnalités utiles pour elles (gestion des membres, comptabilité, droits permettant à certains membres de publier des articles, salons, annuaires ...)

Ceci dit, je comprendrais très bien qu'au vu de la qualité de programmation et de la complexité de la plateforme, vous décidiez de renoncer à m'aider.

Cordialement
Jacques

 

[WebRankInfo]

peut-être parce que ce genre d'URL est redirigée en 302 vers un truc intermédiaire
_client.php?rtr=https%3A%2F%2Fwww.armor-vietnam.com%2Fart_edi_art.php%3Fa_id%3D5554

 

[zakuli]

Le passage par le script _client.php avait été mis en place il y a longtemps quand on avait encore des écrans à très faibles résolutions (800x600; 1024x768 ...).

Ce petit traitement récupère en php des info sur le client (taille écran, taille fenêtre ...) et me permet de tailler la page en fonction de l'écran du client.

Si vous pensez que cette redirection temporaire est la cause du problème, il va me falloir reprendre la programmation de la plateforme et tout ce qui a été mis en place en utilisant ces données client.

Aussi, y a-t-il un moyen simple de s'assurer que c'est bien une redirection en 302 qui bloque l'indexation ?

 

[WebRankInfo]

on la voit ici la 302

 

[zakuli]

Ah oui !
Donc la solution est de supprimer ce passage par les 2 fichiers permettant de récupérer les données client

Dans le premier : _client.php
<div><form name="ecran" method="post" action="<?php echo "_client_fin.php>">
<input type="hidden" name="lecran" value="Largeur d'écran"></form></div>
<script>
var ecran = document.forms.ecran;
ecran.elements.lecran.value = screen.width;
ecran.sbmit();
</script>

Dans le second : _client_fin.php
$_SESSION['ecran_larg'] = $_POST['lecran'];

Connaîtriez vous une autre solution pour récupérer des données client ?