Disparition dans Google

[magnetophone]

Bonjour,


Depuis quelques mois (juin ou juillet), mon site a disparu de Google.

Auparavant, quand je tapais son nom sans les extension, j'arrivais en première position, le nom de mon site étant un mon simple. Chaque fois que je tapais le nom avec les extensions, tout se passait bien, et je pouvais voir les autres sites qui référencaient le mieux.

Et depuis juin environ, plus rien.

J'ai donc regardé sur WRI, lu pas mal de choses intéressantes, même si je n'ai pas tout compris (je suis programmeur, pas référenceur), et j'ai essayé de déterminer le pourquoi du comment. J'ai par exemple essayé de déterminer le "PR", via la Toolbar, mais je n'ai jamais trouvé le fichier indiqué dans le forum.

Bref, j'ai essayé de faire le tour de la question, mais je n'arrive pas à trouver ce qui se passe.

Une idée sur la disparition subite après des années de présence sans problème ?


Merci,
Pascal.

 

[moutyk]

Salut

La cause peut etre multiple

Si tu donnais ton adresse dans un premier temps !

Merci

bye

 

[magnetophone]

l'adresse de mon site : http://www.magnetophone.com/


merci.

 

[JPC]

Bien, déjà ta page d'accueil a un PR de 4, tu as 99 pages connues par google
https://www.google.fr/search?sourceid=na ... hone%2Ecom

Bon, par contre il semble avoir perdu tes titres et contenus; là, moi, je ne sais pas pourquoi...

 

[magnetophone]

merci !!!

Pour les titres, j'ai testé avec un autre site que je fréquente assidument, et ils ont ce même problème de titre.

J'ai regardé dans mes stats, et le nombre de visiteurs venant par Google, a été divisé par 100 entre mai et juillet. On voit presque le jour où la disparition a eu lieu (entre le 5 et le 10 juin).

Etrange. Dois je soumettre une nouvelle fois l'URL de mon site dans Google ?



merci,
pascal.

 

[JPC]

Je ne pense pas qu'une ressoumission soit utile...

Ce problème me dépasse, mais , à priori, des gens de vianetworks ont eu le cas y'a quelque temps, et depuis peu, ils semblerait que ça arrive à des sites hebergés chez ovh comme toi ...
enfin, c'est mon avis, ça n'engage que moi; je ne suis pas specialiste dan ce problème...

 

[mahefarivony]

Bien, déjà ta page d'accueil a un PR de 4

chez moi il a une belle barre grise

 

[mahefarivony]

re-moi

1- sur ta page d'accueil, je vois ceci
:arrow: <meta http-equiv="refresh" content="12; URL=http://www.magnetophone.com/magnetophone/">
comment qu'il interprete ca google ?

2- tes liens sont de la forme
/magnetophone/?PHPSESSID=fab56693a0780b4ef2433f14adcde052... google ne les suivra jamais (fais une recherche sur WRI avec PHPSESSID dans le bloc violet en haut a droite)

3- tu es bien généreux en faisant 3 liens externes dès ta page d'accueil... mais bon, il restera pas grand chose (de PR) pour tes pages a toi

les blemes d'indexation sur ovh en ai jamais entendu parler (lien ?) mais bon, si c'etait vraiment le cas, pas de bol, ton site accumule les handicaps

 

[gascogne]

Bonjour,
chez moi tu as bien le PR 4 mais au bout de quelques seconde ta page est redirigée automatiquement sur http://www.magnetophone.com/magnetophone/ donc je sais pas si ca peut avoir un rapport sinon je vois pas ?

Désolé on a édité en meme temps

 

[magnetophone]

intéressant ça, l'histoire de la redirection.

je vais l'enlever pour tester.

sinon, les 3 liens externes sur la page, sont des liens correspondant à des sous projets du site. vous me conseillez de les enlever tout de même ?

avant, ils étaient en /nomduprojet/ et il y avait une redirection http://nomduprojet/ sur la page /nomduprojet/.

quelle est la meilleure solution d'après vous ?


merci pour votre aide en tout cas,

pascal.

 

[mahefarivony]

quelle est la meilleure solution d'après vous ?

virer les phpsessid, tant que tu ne le feras pas, google n'ira pas plus loin que ta page d'accueil

 

[Remi L.]

On ne voit rien sous Lynx :
Après un gros bricolage de cookie, bel écran noir.

 

[Kmacleod]

La redirection source du Pb : niet
J'ai crée un jeu de questionnaires ou pour arriver à la question suivante il y a une redirection avec un timing qui est inférieur aux 12 secondes.
Et google passe bien sur ces questions là, il répond à coté mais je m'en doutais un peu :lol:
Il a certes mis du temps à indexer ces pages là, mais en tout cas la redirection est bel et bien suivie. La redirection avec timing zero est à proscrire cependant :evil:
kmacleod

 

[JPC]

pour ovh, ben en fait, j'ai du me faire cette reflexion à partir du seul post de fupap
https://www.webrankinfo.com/forum/t/resultat-dune-requete-sans-titre-ni-description.3649/
parceque je n'en ai pas trouvé d'autre...

l'utilisation des sessions, ok, ça n'est pas recommandé, s'il met en ligne de nouvelles pages, gg n'ira peut etre pas les voir...Ceci dit, les pages de son site sont connues, même plus loin que l'accueil... le problème c'est que google n'a plus les titres et description; vous pensez que c'est lié ?

par contre Remi a raison, si en lybnx on ne voit rien, google voit aussi des pages vides !
http://www.delorie.com/web/lynxview.cgi ... one.com%2F
et
http://www.delorie.com/web/lynxview.cgi ... tophone%2F

heu, moi, je n'ai pas vu pourquoi dans la source...

 

[Remi L.]

Il n'y a quasiment pas de texte dans la page, juste un copyright apparamment... Mais c'est vrai que même le copyright on le voit pas.

D'autre part, sans vouloir critiquer, il y a un piti problème de programmation: quand on refuse les cookies, le truc se met en boucle et on accède à rien du tout.
Ah ces cookies...
c'est énervant...
J'aime *pas* les cookies... :wink:

 

[magnetophone]

En fait, j'ai une redirection dans la première page à la connexion, après gestion d'un cookie et de l'initialisation de la session, en php.
J'ai déjà ce problème avec validator.w3.org, qui reçoit une erreur 302 et s'arrête. J'ai cherché une solution à ce problème, mais je n'ai pas trouvé. Une idée peut-être ?

En tout cas, quand je désactive ça, ça passe sous lynx. Et il est fort probable que ce soit ce problème qui est perturbé google, cette gestion du cookie date de fin mai, début juin....


(et merci pour le lien pour lynx, ça m'évitera de demander à un ami de le faire pour moi)

pascal.

 

[JPC]

Bien vu Rémi !!!
en effet, les moteurs n'accepte pas les cookies, et ton site part en vrille...

il sert à quoi ton cookie ?
Pourquoi ne pas le poser que lorsque la personne est identifiée?

 

[magnetophone]

en effet, les moteurs n'accepte pas les cookies, et ton site part en vrille...

il sert à quoi ton cookie ?
Pourquoi ne pas le poser que lorsque la personne est identifiée?

Cela permet d'identifier l'utilisateur, avec (bientot) une fonction de reconnaissance automatique. Mais pour le moment, il ne sert pas à grand chose, je vais le virer, et on verra après.
Va falloir que je revoie toute la nouvelle version alors... bouhouhouh...
A moins que je mette un truc spécial pour les robots...

Du genre HTTP_USER_AGENT != Bot { cookie }, non ?


Merci pour vos infos et votre aide en tout cas.


pascal.

 

[magnetophone]

Bon, le cookie est plus ou moins viré.
En fait, je faisais le test suivant :

if (!$cookie->get("User"))
{
$cookie->set("User", $moncookie);
header("Location: ./");
exit;
}
else
{
$session->set("User", $cookie->get("User"));
}

j'ai supprimé le header location (et le exit), ça devrait mieux aller maintenant.

Par contre, le cookie est quand même testé et initialisé. Cela peut il toujours perturbé les robots ? Si oui, je vais ajouter un test sur le HTTP_USER_AGENT pour qu'il n'initialise pas le cookie s'il tombe sur un robot.


merci.
pascal. ça progresse.

 

[JPC]

Ben, heu, honnetement, c'est pas conseillé ! ça pourrait etre considéré comme du spamdexxing; parceque le code pour un robot serait different du code pour un visiteur classique...
Et puis aussi, ben, se faire une liste exhaustive de tous les agents des robots, ça me parait difficile...

Et enfin, parceque je deteste les rustines, et que ça en serait une, la chose à faire, c'est de ne pas obliger le visiteur à accepter les cookies...

PS : au fait, pour la reconnaissance automatique du visiteur, c'est pareil, il faut qu'il se soit identifié une première fois sur ton site, c'est à ce moment là qu'il faut poser le cookie et démarrer la session...

<edité pour rajouter le PS et correction d'une faute d'orthographe>

 

[George Abitbol]

Ben, heu, honnetement, c'est pas conseillé ! ça pourrait etre considéré comme du spamdexxing; parceque le code pour un robot serait different du code pour un visiteur classique...

Ca s'appellerait plutôt du cloaking, même si là, à mon avis, on en est loin.

Fred

 

[magnetophone]

Ben, heu, honnetement, c'est pas conseillé ! ça pourrait etre considéré comme du spamdexxing; parceque le code pour un robot serait different du code pour un visiteur classique...

je vois. Mais comment un robot peut il faire la différence ?
En laissant le cookie, cela risque t il de perturber le robot ?
(Bon, il me reste à virer le phpsessid, mais si ça doit passer par un cookie...

PS : au fait, pour la reconnaissance automatique du visiteur, c'est pareil, il faut qu'il se soit identifié une première fois sur ton site, c'est à ce moment là qu'il faut poser le cookie et démarrer la session...

Exactement, mais j'avais en attendant ajouter un compteur de visite pour mes stats... . Et donc la première fois que le visiteur arrive, je dépose un cookie avec le numéro de session, plus une chaine compte le nombre de visites.
Bref, je sais que c'est pas glop, mais bon, je testais, je pensais pas que ce serait le bordel avec Google.

Faut il maintenant que je soumette les URLs (parce que forcément, tous les projets sont touchés vu qu'ils sont tous construits sur le même script... :-(

 

[JPC]

oui, en effet, du cloaking pas du spamdexxing, mais bon, en imaginant qu'un moteur fasse des controle à partir d'une ip inconnue et d'un agent inconnu egalement,je pense qu'il pourrait considérer ça comme du cloaking ? enfin, c'est clair pour le moment, il y a peu de risques...

le cookie en lui même ne perturbe pas le robot, à condition que ton script ne tourne pas en rond parceque le visiteur ou robot a refusé ton cookie...

ressoumettre les url, ben heu, non, je ne crois pas que ce soit necessaire,
je pense que gg va vite voir que ton site a changé et le crawler...

 

[magnetophone]

le cookie en lui même ne perturbe pas le robot, à condition que ton script ne tourne pas en rond parceque le visiteur ou robot a refusé ton cookie...

ressoumettre les url, ben heu, non, je ne crois pas que ce soit necessaire,
je pense que gg va vite voir que ton site a changé et le crawler...

ok.

bon, on va attendre alors, je vais faire encore quelques modifications pour virer le phpsessid et essayer de corriger les URL pour les rendre un peu plus statique, et hoplà, ce devrait être bon alors, non ?

encore merci pour votre aide et votre temps.


pascal.

 

[JPC]

heu, oui, déjà on peut voir ton site en refusant les cookies, c'est largement mieux ;-)

Sans les PHPSESSID, google visitera ton site plus simplement...

toutefois,avec le delorie, on ne voit toujours pas la page de ton sous-repertoire magnetophone.... Dsl, je ne suis pas specialiste lynx, je ne sais pas pourquoi...

 

[Remi L.]

Cela permet d'identifier l'utilisateur, avec (bientot) une fonction de reconnaissance automatique.

Moi, je suis facile à reconnaître, j'ai un grain de beauté sous le pied gauche.
Mon numéro de carte d'identité est 4525.25632.87
Est-ce que cela va suffire pour me reconnaître ?


On veut pas être identifié automatiquement...! 8)

Une bonne utilisation des cookies, c'est celle que fait WRI : On s'enregistre si on le désire, et le cookie est bien utile pour voir les messages écrits depuis notre dernier passage... ça ok, c'est du bon cookie.
99% des cookies ne servent à rien et c'est énervant de savoir qu'ils sont là à espionner tout ce qu'on fait.
Donc si tu vires les cookies, tu feras avancer l'humanité vers des jours meilleurs, des printemps qui chantent, et des petits oiseaux qui... euh, ben qui chantent aussi.

 

[magnetophone]

heu, oui, déjà on peut voir ton site en refusant les cookies, c'est largement mieux ;-)

c'est clair. j'espère que ça va améliorer la situation avec Google. qui est passé 6 fois cette nuit.... j'espère que ça va continuer comme ça

Sans les PHPSESSID, google visitera ton site plus simplement...

il faut que je regarde ça de plus près. mais il y a un truc étrange. parce que je développe sous Safari et Mozilla (pour Mac), puis je teste sous IE (Mac et Win), Opera (Mac et Win) et Mozilla (Mac), et je n'ai jamais fait attention à ce problème. Sous Safari, je n'ai pas ce phpsessid... Il faut que j'approfondisse ça.

toutefois,avec le delorie, on ne voit toujours pas la page de ton sous-repertoire magnetophone.... Dsl, je ne suis pas specialiste lynx, je ne sais pas pourquoi...

J'ai vu ça. Je cherche, parce que je ne comprends pas, toutes les pages du site (la rubrique offline par exemple fonctionne) sont construites sur le même modèle, qui passe par un même script qui construit la page. Va falloir que je trouve le problème, c'est carrément embêtant.


merci.


pascal.

 

[JPC]

il faut que je regarde ça de plus près. mais il y a un truc étrange. parce que je développe sous Safari et Mozilla (pour Mac), puis je teste sous IE (Mac et Win), Opera (Mac et Win) et Mozilla (Mac), et je n'ai jamais fait attention à ce problème. Sous Safari, je n'ai pas ce phpsessid... Il faut que j'approfondisse ça.

Et bien si ton navigateur accepte les cookies, il n'a pas de raison de te mettre un PHP_ SESSID, alors, commence par refuser les cookies, et tu le verras ;-)

bon courage pour la page qui ne s'affiche pas en Lynx...

 

[magnetophone]

Et bien si ton navigateur accepte les cookies, il n'a pas de raison de te mettre un PHP_ SESSID, alors, commence par refuser les cookies, et tu le verras ;-)

Sur IE6 qui accepte les cookies, le PHPSESSID apparait....
Bon, sinon, j'ai regardé, j'ai passé les deux paramètres

ini_set('session.use_only_cookies', false);
ini_set('session.use_trans_sid', false);

comme indiqué dans un forum sur WRI, mais cela ne fonctionne pas plus...
Je les ai pourtant placé directement en première ligne de mon script, mais cela ne change, dans ma class session, pareil, bref, je ne vois pas quoi faire.

et dans tous les cas un ini_get('session.use_only_cookies') me retourne toujour true.

y aurait il une limitation chez OVH pour ne pas modifier ce paramètre ? j'ai posé la question à la hotline, on verra bien.

bon courage pour la page qui ne s'affiche pas en Lynx...

Merci.
j'ai pas encore trouvé, surtout que cela touche une rubrique et pas les autres.
(et Google semble revenir, avec 3 pages supplémentaires aujourd'hui...



merci,
pascal.

 

[JPC]

heu, j'y connais pas grand chose, mais

ini_set('session.use_only_cookies', false);

ça ne devrait pas être à true ?
ne mettre l'identifiant de session que dans les cookies, pas dans l'url ?...

 

[magnetophone]

heu, j'y connais pas grand chose, mais

ini_set('session.use_only_cookies', false);

ça ne devrait pas être à true ?
ne mettre l'identifiant de session que dans les cookies, pas dans l'url ?...

ooopssss... pardon. j'ai bêtement copié le code trouvé dans le forum, mais en fait, oui, j'ai mis à true bien évidemment.
le problème est que cela ne fonctionne pas, mais surtout, après le ini_set de session.use_only_cookies à false, suivi de ini_get de session.use_only_cookies me retourner toujours true.



pascal.

 

[mahefarivony]

et bin, ca m'a bien l'air compliqué tout cela.

c'est pas comme en phpBB ? y a juste la fonction append_sid() a commenter dans la page includes/sessions.php en 30 secondes top chrono et roule jeunesse...

non ?

 

[JPC]

heu, là, je ne te suit pas...

'session.use_only_cookies' : j'ai mis à true bien évidemment

ini_get de session.use_only_cookies retourne toujours true

ben oui, si tu viens de le mettre à true ;-)
j'espère que c'est pas trans_sid que t'as mis à true, sinon, c'est normal qu'en acceptant les cookies tu ais la session dans l'url...

 

[JPC]

et moi, en IE 6 en acceptant les cookies, j'ai pas le PHPSESSID...
par contre, je l'ai toujours en refusant les cookies

 

[magnetophone]

Bon, je me suis emmêlé les pinceaux, voici un copier-coller du code :

ini_set('session.use_trans_sid', false);
ini_set('session.use_only_cookies', true);

si je fais un ini_get('session.use_trans_sid'), j'ai true.

je ne vois pas d'où cela peut venir.

 

[magnetophone]

bon courage pour la page qui ne s'affiche pas en Lynx...

mmmhhhh.... j'ai passé 2 heures avec delorie pour trouver la raison et....
j'ai craqué, j'ai installé lynx sur ma machine (mac os x) et...
ça marche.


voilà.
pascal.

 

[JPC]

ha ?? et ben desolé alors !...

 

[magnetophone]

ha ?? et ben desolé alors !...

pas de problème, ça faisait longtemps que je voulais l'installer... du coup, j'ai 11 navigateurs sur mon mac, et 5 sur mon pc....

par contre, pour le phpsessid, je sèche complètement... un problème chez ovh avec ça ?

 

[magnetophone]

ça revient doucement dans google.... c'est cool...
déjà quand je tape magnetophone.... yeah yeah yeah !


merci pour votre aide à tous.

(bon, le passage de phpsessid pose un problème chez ovh apparemment)



pascal.

 

[mahefarivony]

fais gaffe, wri est capable de passer devant toi :twisted:

 

[magnetophone]

bonjour à tous,


merci pour votre aide précieuse sur le fonctionnement de google et son référencement des pages dynamique avec sessions. j'ai corrigé tout ça, et depuis hier soir, c'est la folie complète, google est déjà passé sur une centaine de pages...

donc, encore merci beaucoup !!!


pascal. très content d'avoir réglé ce problème.

 

[JPC]

Honnêtement, je suis bien content pour toi !
Et tu t'en sors avec tes sessions et tes cookies quand tu en as besoin ?

 

[prof-particulier]

Bon, je me suis emmêlé les pinceaux, voici un copier-coller du code :

ini_set('session.use_trans_sid', false);
ini_set('session.use_only_cookies', true);

si je fais un ini_get('session.use_trans_sid'), j'ai true.

je ne vois pas d'où cela peut venir.

cela fonctionne ? ca permet de ne jamais afficher le sessid dans l'url ?
parce que moi avec IE 6 des fois ca s'affiche