[article] Comment faire des liens en dur dans son annuaire

Olivier Duffez (admin)
Membre du personnel
Suite à l’article sur les redirections sauvages, nous avons beaucoup discuté dans le forum à propos des annuaires qui font des redirections au lieu de faire des liens en dur (c’est-à-dire des liens classiques sans redirection ni JavaScript). Voici ce qu’il faut savoir concrètement à propos de ces liens et de ces redirections…

Il existe plusieurs façons de faire des liens sur une page A pour mener à une page B :
  • un lien en dur classique ;
  • un lien en dur accompagné d’une action JavaScript ;
  • un lien en JavaScript seulement ;
  • une redirection à base de balise meta refresh ;
  • une redirection serveur code 301 ;
  • une redirection serveur code 302.
Seuls les deux premières façons permettent d’améliorer le référencement de la page B. Dans le cas où la page A fait partie d’un annuaire, il est donc essentiel que le webmaster utilise de bons liens, sinon cet annuaire perdra une partie de son utilité (en tout cas du point du vue du référencement).

Un lien en dur classique est de la forme :
HTML:
<a href="http://www.site-b.com/page-b.htm">Page B</a>
Un clic sur un lien de ce type mène directement l’internaute ou le robot vers la page B.

Un lien en dur accompagné d’une action JavaScript est de la forme :
HTML:
<a href="http://www.site-b.com/page-b.htm"  onclick="action-javascript">Page B</a>
Un clic sur un lien de ce type effectué dans un navigateur qui gère le JavaScript va exécuter l’action JavaScript nommée ici symboliquement « action-javascript » puisqu’elle est prioritaire sur le lien défini par l’attribut href. En général cette action a pour objectif de comptabiliser le clic à des fins statistiques avant de rediriger l’internaute vers la page de destination finale via une redirection JavaScript qui peut par exemple être de la forme suivante :

HTML:
<script language="javascript" type="text/javascript"> <!-- window.location.replace("http://www.site-b.com/page-b.htm"); --> </script>
Un clic sur un lien de ce type (un lien en dur accompagné d’une action JavaScript) effectué dans un navigateur qui ne gère pas le JavaScript mène directement l’internaute ou le robot vers la page B (située dans cet exemple à l’adresse ). Ce type de lien est tout à fait compatible avec les robots des moteurs tels que Googlebot puisque l’attribut href de la base a est très bien renseignée.

Un lien en JavaScript seulement est de la forme :
HTML:
<a href="#" onclick="action-javascript">Page B</a>
(Notez qu’il peut y avoir d’autres formes de liens JavaScript mais le principe reste le même).

Un clic sur un lien de ce type effectué dans un navigateur qui gère le JavaScript va exécuter l’action JavaScript nommée ici symboliquement « action-javascript ».Un clic sur un lien de ce type effectué dans un navigateur qui ne gère pas le JavaScript ne va rien produire.

De la même façon, ce type de liens est incompatible avec les robots tels que Googlebot (il y a des exceptions…) et donc ce lien sera ignoré par les moteurs. Il ne fournit donc pas de backlink et n’améliore pas le PageRank de la page B.

Les liens gérés par des redirections
Consultez la page sur les redirections pour connaître les détails sur chaque type de redirection. En pratique, les redirections sont souvent mal gérées par les moteurs de recherche, si bien qu’un lien par redirection ne permet pas souvent de transmettre du PageRank et d’améliorer le positionnement de la page liée.

Si la redirection est gérée par le serveur (avec un code 301 ou 302) alors l’internaute ne voit pas d’étape de redirection (l’URL cliquée n’est pas l’URL de la page finale mais entre les deux il ne voit aucune page).

Si au contraire la redirection est gérée par le client (le navigateur) sous forme de balise meta refresh ou de code JavaScript, alors l’internaute a le temps de voir la page intermédiaire avant d’être redirigé sur la page de destination finale.Le problème est que de nombreux CMS et des outils d’annuaires fonctionnent via des redirections 302.

Tous les webmasters qui s’y connaissent un peu en HTML ou PHP peuvent certainement supprimer ces redirections afin de faire des liens directs en dur dans leur annuaire. S’ils veulent vraiment compter les visites, ils peuvent le faire en ajoutant un événement JavaScript dans la balise a (action onclick).

J’espère que cette série d’articles aura réussi à faire prendre conscience aux webmasters d’annuaires ou de CMS qu’il serait souhaitable de modifier légèrement leur site pour offrir de véritables liens, revenant ainsi à la vocation première d’un annuaire.
 
WRInaute occasionnel
Bonsoir,

petite question, un lien du type :

h**p://www.***********.com/jump.php?sid=2&url=http://url-du-site.com

peut il etre considéré comme un lien en dur? Je ne vois pas ce cas dans l'article.
Si je regarde une page contenant de tels liens avec Lynx, il semble que oui mais j'aimerais avoir un avis éclairé.
Merci et bonne soirée
 
WRInaute discret
epsilon74 a dit:
Bonsoir,

petite question, un lien du type :

h**p://www.***********.com/jump.php?sid=2&url=http://url-du-site.com

peut il etre considéré comme un lien en dur? Je ne vois pas ce cas dans l'article.
Si je regarde une page contenant de tels liens avec Lynx, il semble que oui mais j'aimerais avoir un avis éclairé.
Merci et bonne soirée
Je ne vois pas comment ça pourrait être considéré comme un lien en dur. Pour google c'est juste un lien vers jump.php avec une variable normée url...

Ce cas est sous-entendu dans l'article quand l'auteur parle des redirections HTTP et meta.
 
WRInaute impliqué
Attention c'est également utilisé par certains sites pour tricher si je puis dire ainsi, surtout les sites proposant des forums gratuits, livre d'or etc ... (Les liens donnés à leurs users linkent la racine de leur ndd (Donc compté par google) et le javascript empêche cette redirection et amène les utilisateurs vers le livre d'or/forum en question.

C'est donc un peu du cloaking de liens si on peut parler ainsi ... Mais bon tant que c'est pas puni ... Why not :)
 
WRInaute discret
rituel a dit:
Attention c'est également utilisé par certains sites pour tricher si je puis dire ainsi, surtout les sites proposant des forums gratuits, livre d'or etc ... (Les liens donnés à leurs users linkent la racine de leur ndd (Donc compté par google) et le javascript empêche cette redirection et amène les utilisateurs vers le livre d'or/forum en question.

C'est donc un peu du cloaking de liens si on peut parler ainsi ... Mais bon tant que c'est pas puni ... Why not :)
En plus, il y a pas mal de monde qui n'active pas JavaScript. Ce genre de bidouilles, c'est nul à tous points de vue.
 
WRInaute discret
Ce qui se fait aussi c'est la chose suivante :

<a href="le vrai lien" onclick="clic(id)">Blabla</a>

<script language="JavaScript">
<!--
function clic(id)
{
if(document.images)
(new Image()).src="page_de_stat.php?id=" + id;
return true;
}
//-->
</script>

Les avantages :
- Lien en dur
- Les stats sont comptée
- Transparent pour tout le monde
- Si le javascript n'est pas activé, le visiteur a quand meme ce qu'il veut (vu que le href est renseigné)
 
WRInaute discret
@Rano

Oui, c'est comme ça que GG fait sur ses pages de recherche pour comptabiliser les clics.
Une bonne méthode.
 
Nouveau WRInaute
Bonjour,
je viens un peu mettre mon grain de sel dans vos discussions. Nous éditons l'annuaire INDEXA http://www.indexa.fr.
Nous faisons des redirections 302 par l'intermédiaire d'un cgi. L'intérêt est principalement de compter les clics, mais aussi pour bloquer les aspirateurs. Cela ne nuit pas aux sites inscrits chez nous car GG prend très bien en compte la redirection et mets bien à jour les backlinks, et donc sans doute le PR.
Je vois un inconvénient à faire un 301. Nous avons déjà testé cela il y a presque 3 ans (ça a pu changer). GG prenait bien en compte la redirection 301 mais ne revenait plus charger de nouveau notre cgi...normal puisque c'est une redirection permanente. Le problème c'est que nous mettons à jour les URL dans notre annuaire sans pour autant changer l'appel, c'est à dire le numéro du site. Comme GG ne reteste pas la redirection, il n'y a jamais mise à jour du lien. C'est pourquoi nous continuons à faire du 302.
Je prends note de la méthode @Rano qui me semble judicieuse.
Par contre est-ce que quelqu'un comprends comment fait Yahoo dans son guide ?
Je pense que c'est la méthode idéale.
 
WRInaute passionné
Yahoo: -http://fr.srd.yahoo.com/S=2100044912:D1/CS=2100044912/SS=2100148378/*http://btseec06.free.fr/
En gros, une URL "en dur" avec celle du site de destination en clair.
C'est peut-etre comme le jump.php dont on parlait plus haut, mais avec un rewriting?

Si les liens de redirection 301 sur les annuaires ne sont pas/plus suivis/tenus a jour par les moteurs, c'est en effet un ennui.
On note d'ailleurs que le nouvel article est bien plus dubitatif sur les 301 que les précédents sur les redirections 8O

L'idéal est que les moteurs comprennent la vraie URL de destination sans avoir a la visiter (cliquer n'est pas le bon terme, mais c'est l'idée: un robot ne clique pas, il se fait un stock d'URLs a visiter plus tard), et le systeme de Yahoo semble aller (en plus, vu la taille du site et les liens historiques des fondateurs de Google avec Yahoo -Yahoo est, avec Dmoz, un des annuaires recommandés dans les guidelines de Google-, ils ont peut-etre fait un développement particulier)
 
WRInaute accro
Quelques commentaires qui n'engagent que moi... :wink:

Indexa a dit:
Nous faisons des redirections 302 par l'intermédiaire d'un cgi. L'intérêt est principalement de compter les clics, mais aussi pour bloquer les aspirateurs.
A mon avis, il n'y a aucun rapport entre "redirection 302" et " bloquer les aspirateurs".

Indexa a dit:
Cela ne nuit pas aux sites inscrits chez nous car GG prend très bien en compte la redirection et mets bien à jour les backlinks, et donc sans doute le PR.
Je crois que ça se passe souvent comme tu le décris, mais dans un certain nombre de cas, Google remplace le site référencé par la page de l'annuaire qui fait la redirection. D'où une frustration considérable chez le webmaster du site "victime". Comme ton annuaire est payant, je suppose que tes clients n'apprécieraient pas ce genre de situation "même si c'est la faute à Google"... d'autant plus qu'il t'est possible de l'éviter.

Indexa a dit:
Je vois un inconvénient à faire un 301. Nous avons déjà testé cela il y a presque 3 ans (ça a pu changer). GG prenait bien en compte la redirection 301 mais ne revenait plus charger de nouveau notre cgi...normal puisque c'est une redirection permanente.
Tout à fait d'accord.

Indexa a dit:
Le problème c'est que nous mettons à jour les URL dans notre annuaire sans pour autant changer l'appel, c'est à dire le numéro du site. Comme GG ne reteste pas la redirection, il n'y a jamais mise à jour du lien. C'est pourquoi nous continuons à faire du 302.
C'est une solution très douteuse. Il serait préférable de ne pas réutiliser d'anciens numéros de site.

Indexa a dit:
Je prends note de la méthode @Rano qui me semble judicieuse.
En plus, c'est la solution qui, en pratique, donnera les stats les plus exactes.

Indexa a dit:
Par contre est-ce que quelqu'un comprends comment fait Yahoo dans son guide ? Je pense que c'est la méthode idéale.
Le guide Yahoo fait des redirections 302. Idéal, pourquoi ?

Jean-Luc
 
WRInaute accro
Indexa a dit:
je viens un peu mettre mon grain de sel dans vos discussions.
tu es le bienvenu Indexa, je pense qu'il est essentiel que les annuaires participent à cette discution et donnent leur point de vue sur la question, si nous voulons déboucher sur une solution constructive ... :wink:

Indexa a dit:
Nous faisons des redirections 302 par l'intermédiaire d'un cgi. L'intérêt est principalement de compter les clics, mais aussi pour bloquer les aspirateurs. Cela ne nuit pas aux sites inscrits chez nous car GG prend très bien en compte la redirection et mets bien à jour les backlinks, et donc sans doute le PR.
alors, ce serait intéressant que tu nous expliques comment vous pratiquez pour que dans votre cas, les 302 ne nuisent pas aux sites inscrits chez vous ...

Indexa a dit:
Je vois un inconvénient à faire un 301. Nous avons déjà testé cela il y a presque 3 ans (ça a pu changer). GG prenait bien en compte la redirection 301 mais ne revenait plus charger de nouveau notre cgi...normal puisque c'est une redirection permanente. Le problème c'est que nous mettons à jour les URL dans notre annuaire sans pour autant changer l'appel, c'est à dire le numéro du site. Comme GG ne reteste pas la redirection, il n'y a jamais mise à jour du lien. C'est pourquoi nous continuons à faire du 302.
enfin une première explication argumentée de non utilisation de la 301, à développer ... :wink:

n'hésites surtout pas à participer aux débats ... et j'encourage vraiment tous les éditeurs d'annuaires qui nous lisent à venir participer également ...
 
Nouveau WRInaute
Indexa a dit:
Nous faisons des redirections 302 par l'intermédiaire d'un cgi. L'intérêt est principalement de compter les clics, mais aussi pour bloquer les aspirateurs.
jeanluc a dit:
A mon avis, il n'y a aucun rapport entre "redirection 302" et " bloquer les aspirateurs".
Si si car on peut tester l'adresse ip avant d'autoriser la redirection.

jeanluc a dit:
Je crois que ça se passe souvent comme tu le décris, mais dans un certain nombre de cas, Google remplace le site référencé par la page de l'annuaire qui fait la redirection. D'où une frustration considérable chez le webmaster du site "victime". Comme ton annuaire est payant, je suppose que tes clients n'apprécieraient pas ce genre de situation "même si c'est la faute à Google"... d'autant plus qu'il t'est possible de l'éviter.
Cendrillon a dit:
alors, ce serait intéressant que tu nous expliques comment vous pratiquez pour que dans votre cas, les 302 ne nuisent pas aux sites inscrits chez vous .....
J'ai creusé ce que fait Yahoo. C'est bien une redirection 302 avec URL rewrite avant. La redirection est "propre". Sur indexa aussi et c'est pour cela que ça fonctionne. Exemple: link:http://www.jurisconsulte.net/
Pour notre redirection on fait seulement un Location: url site dans le header HTML. Ce n'est donc pas une vraie page et GG n'en tient donc pas compte. Une vraie page HTML commence par Content-type: text/html. Si on fait une rédirection par <META REFRESH> ce n'est pas "propre". Si on fait une redirection javascript en ecrivant dans sa page: <script>window.location = 'url'</script> ce n'est pas "propre" non plus.


Indexa a dit:
Le problème c'est que nous mettons à jour les URL dans notre annuaire sans pour autant changer l'appel, c'est à dire le numéro du site. Comme GG ne reteste pas la redirection, il n'y a jamais mise à jour du lien. C'est pourquoi nous continuons à faire du 302
jeanluc a dit:
C'est une solution très douteuse. Il serait préférable de ne pas réutiliser d'anciens numéros de site..
.
Oui tu as raison, on devrait réinscrire le site...mais c'est une solution plus longue à gérer donc plus couteuse. Il faudrait qu'on fasse payer les modifs, ce qu'on ne fait pas pour l'instant.

Indexa a dit:
Je prends note de la méthode @Rano qui me semble judicieuse.
jeanluc a dit:
En plus, c'est la solution qui, en pratique, donnera les stats les plus exactes.
Oui car on évite de compter les clics provenants des robots. D'un autre coté avec notre cgi on peut aussi filtrer les robots par adresse ip.

Pour le 301 il faudrait retester le comportement de GG à long terme. Je laisse cela à ceux qui ont le courage et le temps.

Cendrillon a dit:
n'hésites surtout pas à participer aux débats ... et j'encourage vraiment tous les éditeurs d'annuaires qui nous lisent à venir participer également ...
Merci pour ton accueil Cendrillon-trinity.
 
Olivier Duffez (admin)
Membre du personnel
@Rano, "ta" solution est ce que j'appelais le lien en dur accompagné d'une action javascript, que je n'avais pas détaillée comme toi : merci pour les précisions qui font bien avancer les choses.

Bienvenue à Indexa - même si je savais que vous étiez là depuis longtemps ;-)
Olivier
 
WRInaute discret
Yahoo: C'est du 302.

Code:
HTTP/1.1 302 Found => 
Date => Tue, 09 Nov 2004 17:27:03 GMT
P3P => policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
Location => http://www.yahoo.com/
Connection => close
Content-Type => text/html; charset=iso-8859-1
 
WRInaute discret
Si je comprends bien, mon annuaire sur mon site ne fait pas des bonnes rediretions:
h***p://www.****.com/annuaire/gestion/out.php?url_id=4&url=http://www.zenit.org/french/

Est-ce juste?

Si oui, connaissez-vous un annuaire en php que je pourrais installer sur mon site? Merci
 
WRInaute occasionnel
moi c'est le même probleme avec mon nouvel annuaire (en test). J'utilise Linker et les liens sont de la forme deja citée plus haut, donc à priori, non en dur. (xxxxx/jump.php?....&url=http://url-du-site.com).

Merci Rano, je viens de modifier le script de Linker avec ton code et quelques modifs supplementaires et ça fonctionne. Lien en dur et stats toujours actives. :wink:

Bonne soirée

Patrick
 
WRInaute discret
kalex a dit:
@Rano a dit:
<a href="le vrai lien" onclick="clic(id)">Blabla</a>
A mon sens c'est onclick qui fait moche. Une solution parfaitement élégante serait de séparer la structure du comportement (un peu comme XHTML/CSS le font pour la présentation) .
Un article qui parle de ça : http://www.pompage.net/pompe/separation/

Un article intéressant, mais comme il le dit au début, faut pas être anti-JavaScript ou penser que par le JavaScript. C'est comme chercher à etre 100% dans les normes W3C ou vouloir absolument ne pas les respecter par esprit de "révolté" c'est tout aussi idiot.

Je pense que l'essentiel est que le visiteur y trouve son compte. Si après tu peux le faire en respectant les normes et en le faisant le plus simplement possible tant mieux.

Chevauchement. CSS peut remplacer certaines fonctions traditionnelles de Javascript, comme les survols de souris et les menus déroulants. Je trouve l'idée intéressante et j'en discuterai dans ma prochaine chronique.
Par exemple ceci, c'est vrai qu'en CSS tu peux pratiquement mettre un :hover sur n'importe quoi... C'est bien gentil, mais pour l'instant c'est pas une solution. Rien que le fait que IE représente plus de 90% du parc des navigateurs et qu'il ne supporte pas le :hover sur div par exemple fait que c'est pas exploitable.

Javascript est un complément puissant aux pages par ailleurs accessibles en XHTML/CSS.
Là encore, va les trouver les navigateurs qui supportent le JavaScript dans le CSS, ils sont pas nombreux.


Je pense pas qu'il faille se prendre la tête sur des histoires comme ca.
Le JavaScript reste encore activé chez la plus grande majorité des surfeurs, je pense que ca reste un langage utilisable.

Maintenant si tu veux séparé le modèle la vue et controleur, c'est encore un choix, mais dans ce qui est voulu dans ce topic, ca sert strictement à rien. Tu peux t'amuser à faire un
<a href="">texte</a> et lancer une machine de JavaScript qui va y ajouter les attributs onclick et les actions que tu veux... mais alors l'intéret... faudra m'expliquer :eek:
 
WRInaute impliqué
Bonsoir a tous !
Indexa ,

Indexa a écrit:
Nous faisons des redirections 302 par l'intermédiaire d'un cgi. L'intérêt est principalement de compter les clics, mais aussi pour bloquer les aspirateurs.
jeanluc a écrit:
A mon avis, il n'y a aucun rapport entre "redirection 302" et " bloquer les aspirateurs".
Si si car on peut tester l'adresse ip avant d'autoriser la redirection.
Cela n'est qu'illusion !
Des logiciels d'aspirations ont plusieurs options avancés :
-suivre les redirections de type 302 ( redirection utilisé aussi pour des pages 404 )
-indiqué un temps entre chaque requete ( pour eviter la surcharge serveur)
-indiqué un user_agent different comme par exemple se faire passer pour un IE6

L'adresse IP utilisé en cas d'aspiration sera l'adresse IP du client, donc de n'importe quelle FAI ! Ensuite, grace a l'option avancé temps entre chaque requete, cela permet de simuler une navigation, indetectable par n'importe qu'elle script de soi disant ANTI ASPIRATION ...

jeanluc a écrit:
Je crois que ça se passe souvent comme tu le décris, mais dans un certain nombre de cas, Google remplace le site référencé par la page de l'annuaire qui fait la redirection. D'où une frustration considérable chez le webmaster du site "victime". Comme ton annuaire est payant, je suppose que tes clients n'apprécieraient pas ce genre de situation "même si c'est la faute à Google"... d'autant plus qu'il t'est possible de l'éviter.

Cendrillon a écrit:
alors, ce serait intéressant que tu nous expliques comment vous pratiquez pour que dans votre cas, les 302 ne nuisent pas aux sites inscrits chez vous .....

J'ai creusé ce que fait Yahoo. C'est bien une redirection 302 avec URL rewrite avant. La redirection est "propre". Sur indexa aussi et c'est pour cela que ça fonctionne. Exemple: link:http://www.jurisconsulte.net/
Pour notre redirection on fait seulement un Location: url site dans le header HTML. Ce n'est donc pas une vraie page et GG n'en tient donc pas compte. Une vraie page HTML commence par Content-type: text/html. Si on fait une rédirection par <META REFRESH> ce n'est pas "propre". Si on fait une redirection javascript en ecrivant dans sa page: <script>window.location = 'url'</script> ce n'est pas "propre" non plus.
j'ai essayer la requete indiqué et en regardant dans le source de cache :
-la page index d'indexa fait bien un lien en dur vers ce site ( les liens des articles )
-la page yahoo referencer comporte elle aussi QUE des liens en dur ( et oui ! )

Ensuite, en utilisant l'outils de entete HTTP de WRI, sur le lien http://www.indexa.fr/cgi-bin/goto?site=37532 ( lien vers le fameux site ) :
Voici le contenu de l'entête HTTP renvoyé par votre serveur (URL analysée : 'http://www.indexa.fr/cgi-bin/goto?site=37532') :

HTTP/1.1 302 Found
Date: Wed, 10 Nov 2004 01:12:22 GMT
Server: Apache/1.3.4 (Unix)
Location: http://www.jurisconsulte.net
Connection: close
Content-Type: text/html

Il est clair que cela montre bien le "content-type: text/html" entete utilisé par defaut par apache ...

De plus, on nous indique que yahoo fait des soi disant redirection 302 , bah j'ai regarder les pages referencer par google pour cette fameuse requete, et je n'ai trouvé que des liens en dur !
Alors j'ai decidé d'aller a ces pages via le site de yahoo, et sur cette meme page, les liens sont differents et sont de la forme cité plus haut ...
Conclusion :
-Yahoo presente des pages pour google ! bah non, en faite c'est pas la meme url :
*url avec lien en dur referencé par google : http://cf.dir.yahoo.com (Yahoo CANADA EN FRANCAIS )
*url avec lien bizarre NON referencé par google : http://fr.dir.yahoo.com (Yahoo FRANCE )
[hors sujet] et la j'ai un SCOOP ! [/hors sujets]

-Ce n'est pas le cas d'indexa qui nous indique "J'ai creusé ce que fait Yahoo", car dans le cache on trouve bien les memes liens goto?id=xxxxxx
-On remarquera que le lien n'as pas d'extension, et que la balise meta ROBOTS n'existe pas, tout comme Yahoo ...

[hors sujet] l'extension phc , c'est du PHP croisé language C ? [hors sujet]

En ce qui concerne la derniere phrase de la citation, le javascript window.location est surement le plus propre de tous cité : il n'influence en rien de lreferencement... quoique, nous avons remarqué des liens en javascript qui été suivit par google ...

edit : je vous invite a voir la requete suivante :
https://www.google.fr/search?hl=fr&...n/goto?site=37532&btnG=Recherche+Google&meta=
qui est le lien http://www.indexa.fr/cgi-bin/goto?site=37532 cité plus haut connu par google ....
Indexa a écrit:
Le problème c'est que nous mettons à jour les URL dans notre annuaire sans pour autant changer l'appel, c'est à dire le numéro du site. Comme GG ne reteste pas la redirection, il n'y a jamais mise à jour du lien. C'est pourquoi nous continuons à faire du 302
jeanluc a écrit:
C'est une solution très douteuse. Il serait préférable de ne pas réutiliser d'anciens numéros de site..

.

Oui tu as raison, on devrait réinscrire le site...mais c'est une solution plus longue à gérer donc plus couteuse. Il faudrait qu'on fasse payer les modifs, ce qu'on ne fait pas pour l'instant.

Je suppose que c'est un ID unique dis comme tels lors de la creation de la table (primary keys).
Question, en quoi cela prend plus de temps de modifier l'id, en meme temps que les autres modifications, dans la table si le numero ID est le suivant , et donc unique ....
reponse : modifier en plus la table categorie pour remplacer l'ancien ID par le nouveau ...

Indexa est un annuaire avec toutes les qualités : payant, n'ajoute rien en referencement, reserver seulement pour les entreprises ...

Ensuite , en passant par un site special qui affiche le pagerank des pages (fonctionnant tres bien pour mon site) et ne disposant pas d'autre moyen pour voir le pagerank, je contaste que ce site n'affiche pas de PR pour la plupart des pages ( PR indefenit, et pas PR0), a part pour la page index et partenaire ...
Donc je suppose que les liens d'annuaires n'ont aucune influence sur google ... ce qui fait que l'annuaire ne risque pas de recevoir des mecontentements d'autres webmasters ...
 
WRInaute passionné
Une petite parenthèse
avec les tobots tels que Googlebot
Une petite faute de frappe ds l'article :)

Sinon pour ma nouvelle version de tonguide (cf WWW) qui est en cours
j'ai mis ça pr l'annuaire :
Code:
<a href="http://www.*****.com" onclick="window.open('visite_page.php?id=id_du_site');return false;">*****</a>
Je pense que ça ne posera pas de problème pour la suivis des liens, mais pour les stats ça a l'air de marcher chez moi. Cela vous semble etre une bonne façon de compter les clics ... ou c'est trop "barbare" ?

Merci :) toujours très intéressant les articles de WRI :)

Un petit défaut tout de meme, il y a une qu'une toute petit nuance qui démontre une utilité des annuaires :
cet annuaire perdra une partie de son utilité (en tout cas du point du vue du référencement).
Meme si c'est un peu hors sujet, le but d'un annuaire n'est pas de fournir une passerelle au référencement sur les moteurs (un peu contradictoire) mais d'avoir des visiteurs ciblés. Il ne faut pas l'oublié :) (vous allez me dire, l'un n'empèche pas l'autre, c'est vrai :wink: )
 
WRInaute discret
Pour ceux comme moi qui sont nulle en php mais qui souhaite avoir un annuaire facile à installe qui utilise le rewriting et les liens dures (une petite ligne à effacer), je vous propose netref (c'est pas de la pub mais juste pour rendre service).

La seule contrainte, c'est que le compteur ne marche plus (il faut l'enver aussi), mais pour moi ce n'est pas le but rechercher et pas ma priorité...

C'est extra et ça marche sur mon site depuis hier!
 
Nouveau WRInaute
Bonjour Gamin Zone !

GAMING ZONE a dit:
Cela n'est qu'illusion !
Des logiciels d'aspirations ont plusieurs options avancés :
-suivre les redirections de type 302 ( redirection utilisé aussi pour des pages 404 )
-indiqué un temps entre chaque requete ( pour eviter la surcharge serveur)
-indiqué un user_agent different comme par exemple se faire passer pour un IE6
C'est sûr que si on veut aspirer un site on peut toujours y arriver. Cela prendra plus de temps, c'est tout. Mais il y a d'autres raisons confidentielles qui expliquent notre choix. On pourrait utiliser le javascript de @Rano mais sans être anti-javascript, on essaye d'éviter son utilisation. Il y a aussi une chose qui ne me plait pas dans ce script, c'est le new Image()).src. Il y a allocation d'une image qui ne sert à rien et il faudrait que la page appelée (en PHP dans son exemple) retourne une image, même vide. Est-ce le cas ? Est-ce compatible avec tous les navigateurs.
Donc pourquoi changer la redirection 302 alors qua ça fonctionne très bien et que GG la prend bien en compte. Tapez cache:http://www.indexa.fr/cgi-bin/goto?site=37532 pour vous en persuader.

GAMING ZONE a dit:
Il est clair que cela montre bien le "content-type: text/html" entete utilisé par defaut par apache ...
Oui Apache met le content-type: text/html par défaut mais il est après le Location: et ça change tout !

En ce qui concerne Yahoo c'est bizarre.
Dans GG on trouve des pages http://fr.dir.yahoo.com mais dans les backlinks GG fait toujours pointer sur http://cf.dir.yahoo.com. Yahoo était bien placé pour demander des comportements spécifiques à Google, mais ce n'est pas le cas de tout le monde.

GAMING ZONE a dit:
l'extension phc , c'est du PHP croisé language C ?
C'est un autre langage. Tu chercheras sur le net si ça t'intéresse.

GAMING ZONE a dit:
En ce qui concerne la derniere phrase de la citation, le javascript window.location est surement le plus propre de tous cité : il n'influence en rien de lreferencement... quoique, nous avons remarqué des liens en javascript qui été suivit par google ...
Là je maintiens que c'est une grosse erreur même si GG arrive à suivre le lien. Vous avez un exemple d'annuaire qui fait ça ?

GAMING ZONE a dit:
Je suppose que c'est un ID unique dis comme tels lors de la creation de la table (primary keys).
Question, en quoi cela prend plus de temps de modifier l'id, en meme temps que les autres modifications, dans la table si le numero ID est le suivant , et donc unique ....
reponse : modifier en plus la table categorie pour remplacer l'ancien ID par le nouveau ...
Tu crois qu'il n'y a que 2 tables pour gérer tout l'annuaire ?

GAMING ZONE a dit:
Indexa est un annuaire avec toutes les qualités : payant, n'ajoute rien en referencement, reserver seulement pour les entreprises ...
On peut s'inscrire gratuitement dans INDEXA.
Oui on accepte seulement les pro...on va pas refaire Yahoo.
La plupart des référenceurs ne sont pas de ton avis. Tu iras voir nos partenaires.
Comme le dis "tonguide" on a notre cible et notre audience (200 000 vu en octobre 2004). On n'est pas un annuaire de pages satellites créé pour les référenceurs.
Et il n'y a pas que le PR dans la vie d'un site.
 
WRInaute impliqué
Indexa,
Il y a aussi une chose qui ne me plait pas dans ce script, c'est le new Image()).src. Il y a allocation d'une image qui ne sert à rien et il faudrait que la page appelée (en PHP dans son exemple) retourne une image, même vide. Est-ce le cas ? Est-ce compatible avec tous les navigateurs.
on peut renvoyer une image de taille 1pixel * 1pixel de trame transparente.
Est-ce compatible avec tous les navigateurs ? je suppose tous les navigateurs compatible CSS , objet DOM ... mais etant donnée les differences existentes entre whaque navigateur pour interpreter ceci ...
Cependant, on pourra le faire en javascript, avec le onclick, mais la pareil, faut javascript d'activer ...

Donc pourquoi changer la redirection 302 alors qua ça fonctionne très bien et que GG la prend bien en compte. Tapez cache:http://www.indexa.fr/cgi-bin/goto?site=37532 pour vous en persuader.
Lorsque je regarde l'adresse de la page en cache, c'est l'adresse du site final, et non la page d'indexa.
De plus lorsque l'on regarde le titre et la description de la page indiqué par google ( la page precedent de la visu en cache), nous voyons le titre et la description de la page final, et non le titre et la description de la page d'indexa..
Alors nous pouvons dire que la redirection 302 à les memes symptomes qu'une meta refresh 0

Cependant, cela montre une grande difference par rapport a mon site, qui utilise une 302 pour faire du pseudo UR car mon hebergeur n'a pas UR.
Lorsque je regarde la page en cache, il indique bien l'url de la redirection 302, et non , comme le cas cité precedement, l'url de la page final.
Hyphèse : google differencie une redirection 302 se dirigeant vers ce meme domaine , d'une redirection se dirigeant vers un domaine different ...

GAMING ZONE a écrit:

Il est clair que cela montre bien le "content-type: text/html" entete utilisé par defaut par apache ...

Oui Apache met le content-type: text/html par défaut mais il est après le Location: et ça change tout !
je vous rencois sur la RFC 1945 HTTP/1.0 - HyperText Transfer Protocol, Version 1.0
L'ordre dans lequel les champs d'en-tête sont reçus n'a pas d'importance. Une "bonne habitude" consistera toutefois à envoyer les champs d'en-tête_générale en premier, suivi des champs d'en-tête_requête ou d'en-tête_réponse, puis enfin les champs d'en-tête_entité.
Par contre, je vous met en defie de me trouver une redirection 302 qui met le content-type avant location .

ensuite je vous renvoie sur https://www.webrankinfo.com/forum/t/article-le-detournement-de-page-par-redirection.15805/ qui indique les reference RFC2016, qui parle au sujet des 302 et 301 , et qui suppose que seule le proprietaire du site peut indiqué ces redirections ...
 
WRInaute discret
@Rano a dit:
...
Maintenant si tu veux séparé le modèle la vue et controleur, c'est encore un choix, mais dans ce qui est voulu dans ce topic, ca sert strictement à rien. Tu peux t'amuser à faire un
<a href="">texte</a> et lancer une machine de JavaScript qui va y ajouter les attributs onclick et les actions que tu veux... mais alors l'intéret... faudra m'expliquer :eek:
C'est simple : séparer JavaScript d'HTML (pour rappel, JavaSript est optionnel...). Avec onclick dans du code HTML, tu présumes son activation.
Maintenant, c'est pas dramatique d'utiliser onclick, c'est juste un peu moins propre et plus difficile à faire évoluer.
 
WRInaute discret
Sinon je pense que la seule bonne manière de compter les clicks c'est avec JavaScript (onclick ou équivalent). Certes, certains clicks seront perdus, mais c'est la seule manière de respecter les fondements hypertextes du Web. Vous pouvez même faire comme google, rétablir de temps en temps votre redirection HTTP afin de pouvoir pondérer les résultats. :)
 
Nouveau WRInaute
GAMING ZONE a dit:
Lorsque je regarde l'adresse de la page en cache, c'est l'adresse du site final, et non la page d'indexa.
De plus lorsque l'on regarde le titre et la description de la page indiqué par google ( la page precedent de la visu en cache), nous voyons le titre et la description de la page final, et non le titre et la description de la page d'indexa..
Alors nous pouvons dire que la redirection 302 à les memes symptomes qu'une meta refresh 0...
Oui mais c'est bien ce qu'on veut justement. Que GG ne garde pas de page intermédiaire ce qui ne dilue pas le PR et que les backlinks soient corrects. Non ? Tu ne trouveras jamais mes url de redirections dans GG...je ne fais donc aucun tord au site référencé. Ce qui n'est pas le cas pour le Meta refresh d'après l'ancienne discussion.

GAMING ZONE a dit:
je vous rencois sur la RFC 1945 HTTP/1.0 - HyperText Transfer Protocol, Version 1.0
Par contre, je vous met en defie de me trouver une redirection 302 qui met le content-type avant location .
Tu as raison l'ordre n'a pas d'importance, c'est le CRLF qui fait la distinction entre le header http et le contenu de la page. Mais comme on le disait dans ma redirection, je ne mets pas le Content-type, c'est apache qui le renseigne tout seul. J'ai testé pour essayer de mettre le Content-type avant mais il a été viré du header.

GAMING ZONE a dit:
ensuite je vous renvoie sur https://www.webrankinfo.com/forum/t/article-le-detournement-de-page-par-redirection.15805/ qui indique les reference RFC2016, qui parle au sujet des 302 et 301 , et qui suppose que seule le proprietaire du site peut indiqué ces redirections ...
Pas vu ça dans la RFC2016. Ou exactement ?
 
Nouveau WRInaute
Désolé, je fais les questions et les réponses.

Voir:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

D'après ce que je comprends, on devrait faire un 303 pour être propre.
Mais il est indiqué que les navigateurs n'interpretent pas tous le 303 et qu'il vaut mieux faire un 302 !

Note: Many pre-HTTP/1.1 user agents do not understand the 303
status. When interoperability with such clients is a concern, the
302 status code may be used instead, since most user agents react
to a 302 response as described here for 303.
 
WRInaute impliqué
Indexa, tu indiquais une solution miracle de "redirection propre 302"
hors, j'avoue, je ne vois rien de special par rapport a une redirection impropre 302, mais peut etre tu eclaircira nos lanterne :)
Désolé d'etre bete !
 
WRInaute discret
Juste pour dire qu'il y a une faute de distraction dans la partie "Un lien en JavaScript seulement est de la forme".

"De la même façon, ce type de liens est incompatible avec les tobots (...)"

nb: n'hésitez pas à supprimer ce message une fois la correction faite :)
 
WRInaute discret
Bonjour
Très interressant tous ceci.
Mais, j'ai un problème pour les stats avec le code javascript :
Ouvrez ce lien avec firefox dans un "tab", il ne sera pas comptabilisé...

Par contre, si vous faite un clic "normal", là, il le sera.

Je sais que pas tous le monde utilise firefox, mais, quand même, le résultat est un nbr faux de clics. (bien que je suis conscient que aucune technique soit 100% juste)

Est ce que ce problème est idem pour tous, ou, est ce juste chez moi?

Edit :
Je parle de ce code javascript :
Code:
<script language="JavaScript">
function clic(k)
{
if(document.images)
(new Image()).src="/annuaire/stat.php?k="+k;
return true;
}
</script>
 
WRInaute occasionnel
Je relance la discussion la dessus, en signalant le probleme causé par le Popup blocker de IE SP2.
Si le script utilise un JS avec l'évenement onClick, il sera bloqué par le popup blocker et donc l'annuaire sera inutilisable. Avez vous des solutions pour pallier ce probleme ?
 
WRInaute occasionnel
@Rano a dit:
Ce qui se fait aussi c'est la chose suivante :

<a href="le vrai lien" onclick="clic(id)">Blabla</a>

<script language="JavaScript">
<!--
function clic(id)
{
if(document.images)
(new Image()).src="page_de_stat.php?id=" + id;
return true;
}
//-->
</script>

C'est me semble t'il la seule méthode en javascript compatible avec les dernieres versions de IE. En effet, si vous utilisez la methode décrite dans l'article Liens en dur, liens mous et redirections: mode d'emploi cité par WRI, on utilise la méthode window.open :

Code:
<A HREF="http://www.monsite.com/" ONCLICK="javascript:window.open('counter.php?id=9999','autres_parametres')" >www.monsite.com</A>

Or cette méthode ne marche pas avec le Popup Blocker installé par défaut dans IE avec SP2 ni d'ailleurs avec le popub blocker de la Google bar sous IE. :evil:
 
Olivier Duffez (admin)
Membre du personnel
zerocomplexe, peux-tu préciser le pb ? je ne vois rien d'anormal avec Firefox. Tu es redirigé vers quoi ?
 
WRInaute discret
Sur http://www.site-b.com/page-b.htm
Mon browser: firefox 1.5. J'ai essayé 3 fois, ça me l'a fait 3 fois... j'ai donc essayé avec internet explorer et ça fonctionné. et là... etrange, ça passe avec firefox aussi... y'a plus de bug... zarbi lol Ou alors j'suis fou et j'ai revé ^^ C'est surment ça d'ailleur, pourtant, je ne bois pas d'alcool, promis juré ^^ .
 
Olivier Duffez (admin)
Membre du personnel
ah ça y est j'ai compris de quoi tu parlais...
ceci n'est pas un lien sur lequel il faut cliquer, c'est un exemple de code de lien

et suite à ta remarque j'ai corrigé un truc qui ne marchait pas bien depuis l'import de mes news dans Dotclear (qui me sert depuis pour mes news)
 
WRInaute occasionnel
@Rano a dit:
Ce qui se fait aussi c'est la chose suivante :

<a href="le vrai lien" onclick="clic(id)">Blabla</a>

<script language="JavaScript">
<!--
function clic(id)
{
if(document.images)
(new Image()).src="page_de_stat.php?id=" + id;
return true;
}
//-->
</script>

Je souhaite utiliser cette fonction qui me paraitbien mais je ne connais pas le javascript et me pose la question suivante :
si le clic est fait à partir de pages multiples qui se trouvent sur différents niveaux d'arborescence fichier par rapport à la page page_de_stat.php, il ne trouve pas page_de_stat.php ???

comment faire dans le javascript pour lui indiquer de manière fixe ou se trouve cette page ?

j'espère que ma question a été claire...
 
Nouveau WRInaute
epsilon74 a dit:
moi c'est le même probleme avec mon nouvel annuaire (en test). J'utilise Linker et les liens sont de la forme deja citée plus haut, donc à priori, non en dur. (xxxxx/jump.php?....&url=http://url-du-site.com).

Merci Rano, je viens de modifier le script de Linker avec ton code et quelques modifs supplementaires et ça fonctionne. Lien en dur et stats toujours actives. :wink:

Bonne soirée

Patrick

Hello a tous , et ou peux-ton se procurer ce code, moi aussi cela m'interesse !!!
 
Discussions similaires
Haut