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

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

 

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

 

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

 

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

 

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 ?

 

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 ?