Halte aux mythes!

WRInaute passionné
Cette nuit, j'ai parcourru le forum à la recherche de posts à recommander et je suis tombé sur des discussions récentes ou anciennes qui m'ammenent à publier ces précisions à l'attention de tous les wenmasters débutants.

1 - Concernant l'url rewriting:

On lit ça et là que l'url rewriting est dangereux pour le référencement car les moteurs devinnent que la technique est utilisée pour ajouter des pages artificiellement, en gros, un site avec 100.000 pages html est louche pour les moteurs de recherche.

Arrétons les bétises! Un moteur ou un internaute n'a aucun moyen de savoir si le site est rewrité ou pas!!!

Les seuls cas ou cela peut se deviner sont:
- site partiellement rewrité (exemple WRI)
- site utilisant un source public et connu (exemple PHPBB pour WRI)
- site ou l'accés aux infos sur le serveur est public et non protégé (genre apache-status ou phpinfo) et encore, cela ne prouve en aucun cas que le rewriting est utilisé mais seulement possible.

De plus, un site totalement et bien rewrité accroit la sécurité face aux tentative d'injection de variables dans vos script php (sans rewriting, les variable sont visibles et cela necessite certaines précautions)

Conclusion: Le rewriting n'est pas pénalisant pour le référencement. En proposant une arborescence et des url lisibles, il facilite le travail des bots et l'indexation des pages. (notez bien que je ne me prononce pas sur l'amélioration du positionnement dans les résultats de recherche car cela est une autre histoire qui ne depends pas de la technique d'url rewriting mais de son utilisation)

2 - l'url rewriting à toutes les sauces

Une question récurrente sur WRI est "comment eviter qu'un site XXX utilise les images du site YYY" et la réponse régulièrement apportée et "url rewriting".

Le fichier htaccess sert à faire autre chose que du rewriting! Il sert avant tout à modifier localement la configuration apache.

Pour eviter que les fichiers contenues dans un répertoire soient utilisées par d'autre sites, mettez un hthaccess de ce type dans le répertoire:

<Files *>
Order Allow, Deny
Deny from all
Allow from .mondomaine.com
</Files>

Par défaut, Apache applique les restrictions du fichier .htaccess à l'ensemble des fichiers du répertoire dans lequel il se trouve ainsi qu'à tous les fichiers contenus dans ses sous-répertoires. Si vous souhaitez protéger uniquement des fichiers jpg, remplacer "*" par "*.jpg".


3 - Concernant les urls absolus et relatives

Là aussi, on lit de tout et la plupart du temps il y a confusion entre url absolus et relatives. Il n'est pas nécéssaire d'ajouter http://www.example.com pour faire une url absolue!

/mondossier/mapage.html est une url absolue
mondossier/mapage.html est une url relative

Il est vrai que apache fait la conversion de relatif en absolue mais il le fait en présence d'un contexte. Sortie de son contexte (c.a.d. la page ou l'url est utilisée), une url relative ne veut plus rien dire.

En terme de référencement, il n'y a aucune raison technique, objective (et même subjective) pour que l'une ou l'autre de ces écritures pénalise ou améliore le référencement. Par contre, il est probable qu'avec une url relative, le bot doit effectuer une opération de conversion en tenant compte du contexte ce qui doit forcement augmenter les temps d'indexation (imaginez un deep crawl sur un site de 100.000 pages comprennant 20 urls relative par page!)

Conclusion: urls relatives ou absolues ne changent en rien votre référencement. Cependant, suivez les conseils des moteurs de recherches pour faciliter le travail des bots et utilisez des url absolues. :wink:

4 - ne pas confondre référencement, indexation et positionnement!

En effet ce sont des choses différentes. L'indexation est la prise en compte d'une page par un moteur de recherche, le positionnement c'est la position de cette page pour une requete donnée, le référencement c'est l'ensemble des actions à mener pour obtenir une indexation de ses pages ainsi qu'un positionnement de celle-ci dans les moteurs de recherche sur des mots clés définis. (je fais volontairement un raccourci en ne traitant que ces trois actions).

Il y a des tonnes de choses que l'on peut faire pour améliorer l'indexation de ces pages en terme d'efficacité, de rapidité d'indexation, de quantité de page indéxées qui ne modifieront en rien le positionnement!!!

Les actions pour ameliorer l'indexation de ses pages sont objectives (liens de navigation, syntaxe du code, lien vers ces pages, contenu de la page etc.. etc...). Les actions pour améliorer son positionnement sont bien plus subjectives (choix des mots clés, adéquation avec la thématique de la page, backlinks etc...) et surtout les résultats sont bien plus fluctuants pour l'unique raison que vous n'êtes pas tout seul sur le web!

Il est trés étrange qu'un webmasters qui poste "j'étais premier et maintenant je suis 15éme" n'imaginent jamais que les 14 webasters qui lui sont passé devant ont pu faire ce qu'il fallait pour cela...(si, si, le webmaster est nombriliste :wink: )

Conclusion: Une bonne indexation est obtenue par l'utilisation de techniques (généralement identifiées). Un bon positionnement, c'est une lutte de tous les instant contre des concurrents et il n'y a aucune recette miracle !

5 - Hors google, point de salut pour un site.

La aussi, même si google est de loin le premier outils de recherche sur le web, il y a des tonnes de sites qui vivent trés bien avec 10% de trafic venant de google! Alors pas de panique si vous n'étes pas dans le top dix, cela ne veut pas dire que votre site est sans intérêt (et puis, les sites dans le top dix,ne sont pas pour autant dignes d'interêt! :wink: )

Les moteurs de recherche ne font pas tout, c'est l'interet que porte un internaute à un site qui importe. Posez-vous la question de savoir si en terme de gain de trafic, il vaut mieux passer des heures en optimisation de référencement pour gagner hypothétiquement quelques places dans les résultats de recherche, ou bien consacrer ces mêmes heures à travailler les contenus de son site?

On ne le redira jamais assez, travaillez vos contenus, au lieu de regarder vos stats toutes les 5 minutes. (Lorsque vous aurez des employés pour s'occuper de votre site, là vous pourrez passer votre temps à regarder les stats en fumant le cigare un bon verre à la main :wink: )

Voilà. J'espère ne pas vous avoir soulé avec mes recommendations parfois vindicatives :oops: , mais en parcourrant WRI cette nuit, j'ai failli avoir une attaque! :D
 
Olivier Duffez (admin)
Membre du personnel
j'en connais un qui va gagner des recommandations... Bravo et merci cela sera utile à beaucoup de monde sur WRI.
 
WRInaute accro
fandecine a dit:
Arrétons les bétises! Un moteur ou un internaute n'a aucun moyen de savoir si le site est rewrité ou pas!!!
Ben ça dépend, car chez OVH j'ai un Content-Location: qui apparait dans les en-têtes retournés et qui donne la vraie URI.
Est-il possible de ne pas le faire s'afficher, genre une ligne dans le htaccess ?
 
WRInaute impliqué
Excellent cet article. Juste un commentaire : ça aurait été mieux d'utiliser example.com et non exemple.com qui est un vrai site Web.
 
WRInaute passionné
un membre éminant de wri me signale par MP qu'il n'est pas d'accord avec ma définition "d'url absolue" (il ne m'en voudra pas de répondre sur le forum plutôt que pa MP car la réponse permetra d'éclairer le sujet).

Il me propose cette définition:

"Les URL absolues sont des adresses URL complètes, incluant le protocole de serveur (qui est généralement http:// pour les pages Web)"

Et dans l'absolu (sans jeux de mots :wink: ) je suis d'accord.

Maintenant, remettons nous dans le contexte et supposons que nous soyons un bot. Pour acceder au pages web, le bot utilise effectivement le protocole http. J'ai préparé un exemple pour illustrer mes propos.

Soit la page -http://www.fan-de-cinema.com/joke/page.html (vous pouvez la voir, elle est en ligne. Losque que je regarde son source à l(aide de mon navigateur préféré je vois bien les deux urls du lien "absolu" et du lien "relatif". Contrairement à ce que j'ai dit par précipitation, apache ne fait aucune conversion (c'est le navigateur qui la fait!)

Dans le source on voit:

Code:
<a href="index.php">lien relatif</a>
et
Code:
<a href="/index.php">lien absolu</a>

Si on survolle les liens avec la souris, on voit dans la barre de status du navigateur l'url re-écrite avec le nom de domaine dans les deux cas.

Maintenant, voici le source d'un script qui accede à page.html , l'ouvre et lit son contenu comme le ferait un bot et recopie le contenu à l'acran.

Code:
<?php 
$fd = fopen("http://www.fan-de-cinema.com/joke/page.html", "r");
if ($fd) { 
    while (!feof($fd)) $raw .= fread($fd,32000); 
    fclose( $fd ); 
    echo $raw;
}
?>
ce script est en ligne à l'adresse -http://www.fan-de-cinema.com/koke/bot.php

Que constate t'on? Que le script (le bot) voit la même chose que le navigateur.

Maintenant le bot doit analyser les urls.

Dans le cas du lien que j'apelle "relatif" il doit utiliser le domaine du site et le nom de la page en cours pour reconstituer l'url compléte de façon exacte.

Dans le cas du lien que j'apelle "absolu" il ne doit utiliser que le domaine du site.

Voilà ce que je voulais dire. Dans un des cas, le calcul de l'url est plus simple. J'aurais du preciser "url relative par rapport au site" et "url absolue par rapport au site".

Maintenant, je pousse le raisonnement plus loin. Le bot doit analyser des url internes au site et externe. Si une url commence par "/" elle est forcement interne. Si on commence toutes les urls par "http://" le bot est obligé d'analyser l'url pour savoir si elle est interne ou externe.

Certain dirons que c'est un détail, mais lorsque l'on conçoit un algo de parsing et d'analyse, c'est la prise en compte de tous ces détails qui fera la différence de rapidité de traitement. Que ceux qui ne sont pas convaincus fasse un tel algo, il verons ce que je veux dire! :wink:

D'ailleurs, je suis prét à relever le défis suivant:

Faire un concourt de script php qui crawle un site à partir de la racine pour en extraire tous les liens (internes et externes). Le gagnant sera celui dont le script effectue l'analyse dans le temps le plus court! :D

note: Pfv3, j'ai corrigé example.com :wink:
 
WRInaute occasionnel
Je rajouterais un détail, très important à mon gout !

Arretez de faire des sites pour Google, faites le pour les visiteurs ! Si votre site comporte de partout des mots cachés, des fermes de liens et autres dans le but d'améliorer votre positionnement, vous serez peut être premier sur Google (avant blacklistage) mais les visiteurs que Google vous aménera ne serront pas intéressé par votre site poubelle, et en conclusion votre place dans Google ne vous apportera rien !
 
WRInaute discret
D'accord avec ce post, enfin normalement tout le sait ça mais ici ça devient un peu noobland donc ça fait pas de mal....

Sinon pas d'accord avec le dernier point, si on parle référencement en France il n'y a que Google, les autres moteurs n'ont quasiment aucun intérêt.

Bien entendu il n'y a pas que le référencement mais le sujet du forum c'est le référencement hein...
 
WRInaute occasionnel
Fandeciné est en forme en ce moment, et on va pas se plaindre !

J'apprécie notamment le 5eme point, très important à mon goût.

Je me marre à chaque fois que je vois des gens se vanter d'avoir 90% de leur traffic venant de Google.
A leur place, je me remettrais en cause pour comprendre pourquoi les visiteurs ne reviennent pas...

Le site qui m'assure le meilleur chiffre d'affaire ne dépasse pas les 1% de visiteurs venant de Google...
 
WRInaute passionné
ManiaGames a dit:
Arretez de faire des sites pour Google, faites le pour les visiteurs !

Pourquoi opposer les deux ?
J'estime qu'un site bien conçu pour le référencement sera également plus clair pour les visiteurs.
Par exemple, plutôt que de cacher des liens dans la balise <noscript> les placer intelligement dans le texte de la page, etc.
 
WRInaute occasionnel
Fab le Fou a dit:
Par exemple, plutôt que de cacher des liens dans la balise <noscript> les placer intelligement dans le texte de la page, etc.

Si on cache un lien, j'estime que c'est pour ne pas le montrer au visiteur non ? Donc dans ce cas, ce lien n'a aucune raison d'exister
 
WRInaute passionné
s'cusez moi, je sort de la sieste, je suis encore dans le brouillard!

Fab le Fou a dit:
Pourquoi opposer les deux ?
J'estime qu'un site bien conçu pour le référencement sera également plus clair pour les visiteurs.

Bon remettons les choses dans l'ordre:

un site plus clair pour les visiteurs sera bien conçu pour le référencement :wink:

ou quelque chose comme ça :D
 
WRInaute passionné
si tu insiste!

oscar.jpg
 
Nouveau WRInaute
ManiaGames a dit:
Je rajouterais un détail, très important à mon gout !
Arretez de faire des sites pour Google, faites le pour les visiteurs !

Je confirme ! Après avoir perdu en temps fou a regarder mes stats et à essayer de monter dans les moteurs, j'ai gagné... 300 visiteurs/jour. Alors j'ai organisé un concours gratuit, et j'ai gagné 3000 visiteurs/jour et plein de backlinks... Le tout en une semaine. Bref ce concours a affolé les visiteurs, pas les robots :wink:

PS: Excellent post Fandecine !
 
WRInaute impliqué
Une adresse du type
Code:
/repertoire/mapage.htm
est normalement appelée 'base relative', c'est à dire une adresse qui prend comme point d'ancrage la base du NDD.
C'est un intermédiaire (bien pratique) entre l'adressage absolu et l'adressage relatif.

Sinon, il n'est pas tout à fait exact de dire que l'URL rewriting est indétectable...
Il est indétectable s'il est bien écrit. Or c'est loin d'être toujours le cas car il faut bien reconnaître que beaucoup de personnes recopient des régles d'URL rewriting qu'ils lisent ici et là...
Je n'invente rien en disant cela et au moins un moteur l'a découvert depuis quelques mois (les webmasters qui ont l'habitude de surveiller leurs fichiers de logs 404 l'auront certainement remarqué :wink: )
 
WRInaute accro
je crains qu'il n'ait pas besoin de cela pour détecter les sites URL rewrités ... ce sont à peu près les seuls à avoir des url du type : -www.ndd.ext/nom-de-la-page-une-fois-rewrite.php ... :lol:

Ceci dit qu'il les détecte ou pas, quelle importance ? Google ne pénalise pas les sites URL Rewrités que je sache ... sur son blog, matts cutts (GoogleGuy) les appelle même les "URL moteurs friendly", qu'ils envisagent même de les privilégier dans le traitement des redir 302 ... :wink:
 
WRInaute accro
Hello fandecine,

super post nocturne ... fais nous des insomnies plus souvent (enfin si madame fandecine veut bien) ... :lol:

fandecine a dit:
3 - Concernant les urls absolus et relatives

Là aussi, on lit de tout et la plupart du temps il y a confusion entre url absolus et relatives. Il n'est pas nécéssaire d'ajouter http://www.example.com pour faire une url absolue!

/mondossier/mapage.html est une url absolue
mondossier/mapage.html est une url relative

Il est vrai que apache fait la conversion de relatif en absolue mais il le fait en présence d'un contexte. Sortie de son contexte (c.a.d. la page ou l'url est utilisée), une url relative ne veut plus rien dire.
nous en avions longuement discuté ici (mais tu es pardonné car tu étais tout juste inscrit à l'époque :D ) ... je pensais comme toi et pourtant (lire la discussion) ... :wink:

fandecine a dit:
En terme de référencement, il n'y a aucune raison technique, objective (et même subjective) pour que l'une ou l'autre de ces écritures pénalise ou améliore le référencement. Par contre, il est probable qu'avec une url relative, le bot doit effectuer une opération de conversion en tenant compte du contexte ce qui doit forcement augmenter les temps d'indexation (imaginez un deep crawl sur un site de 100.000 pages comprennant 20 urls relative par page!)

Conclusion: urls relatives ou absolues ne changent en rien votre référencement. Cependant, suivez les conseils des moteurs de recherches pour faciliter le travail des bots et utilisez des url absolues. :wink:
en fait ce n'est pas tout à fait un mythe mais une recommandation de GoogleGuy sur WMW relayée par Kendo (lire ici) ... :wink:
 
WRInaute accro
Cendrillon a dit:
je crains qu'il n'ait pas besoin de cela pour détecter les sites URL rewrités ... ce sont à peu près les seuls à avoir des url du type : -www.ndd.ext/nom-de-la-page-une-fois-rewrite.php ... :lol:
Non, sur le site de mon www, j'ai bien des url de ce genre, mais sans rewriting.
Par contre, sur d'autres sites, j'ai du rewriting mais il est renvoyé comme en-tête le Content-Location: et cela pourrait poser des problèmes de spam de moteurs qui recherchent des failles.
Déjà que ceux qui recherchent des fichiers / répertoires _vti, msoffice ou asp sur un serveur apache :lol: je me crois obligé de les aider en leur renvoyant un code 301 sur google :lol: je ne vais pas le faire en plus pour ceux qui voudraient trouver des failles dans mes scripts.
Perso, je trouve plus explicite une url de ce genre pour le visiteur
 
WRInaute passionné
Cendrillon a dit:
Ceci dit qu'il les détecte ou pas, quelle importance ? Google ne pénalise pas les sites URL Rewrités que je sache ... sur son blog, matts cutts (GoogleGuy) les appelle même les "URL moteurs friendly", qu'ils envisagent même de les privilégier dans le traitement des redir 302 ... :wink:

D'ailleurs l'url rewriting est manifestement utilisé pour "blogger" donc...
 
WRInaute impliqué
Pfiou, lendemain de fête difficile, mais j'ai réussi à comprendre le post, quoi que le titre me paraisse pas forcement adapté (ça me rapelle un thread ...). Je croyais qu'on aller descendre GG, ou le père noël (ben c'est un mythe aussi).

Par contre, j'en ai encore appris.

Et dis moi, "Fandecine", prends pas de risque avec ta santé :wink:

Dors un peu plus et tu risquera moins de crise cardiaque 8)
 
WRInaute passionné
Aller, pour les détectives en herbe, vous allez sur le site de mon profil et vous me dites si vous pouvez trouver des élément objectifs et catégoriques pour dire que telle ou telle page est rewrité! :D

Je suis un peu charette aujourd'hui, mais dés que j'ai du temps je vous direz comment s'aranger avec apache pour qu'ils garde ceratins secrets pour lui... :wink:
 
Olivier Duffez (admin)
Membre du personnel
intéressant Yannick, c'est un bon résumé en effet ;-)

Par contre si tu pouvais nous éclairer sur le fait que le rapport contenu / code HTML influe sur le référencement, ça m'intéresserait.

Olivier
 
WRInaute impliqué
Comme toute théorie, elle est difficile à démontrer.

J'ai souvent remarqué que des passages construction en tableau -> construction en CSSP apportait des bienfaits niveau positionnement. Ceci découle surement de cela.
 
WRInaute passionné
Est-ce que cela ne contribue pas à faciliter le travail des robots en ayant une page plus légère, et dont le code est moins brouillon ?

Cela serait un peu la même logique que celle des url absolues, évoquée plus haut.
 
WRInaute passionné
fandecine a dit:
Aller, pour les détectives en herbe, vous allez sur le site de mon profil et vous me dites si vous pouvez trouver des élément objectifs et catégoriques pour dire que telle ou telle page est rewrité! :D

Alors! personne veut jouer avec moi? :cry: :cry: :cry:

Faut dire que j'ai corsé le problème. En lisant mes header, on peut même pas sovoir que j'utilise php! :D

fandecine a dit:
Je suis un peu charette aujourd'hui, mais dés que j'ai du temps je vous direz comment s'aranger avec apache pour qu'ils garde ceratins secrets pour lui... :wink:

Aller, je vous donne quand même la solution.

Comme je l'ai dit plus haut, le htaccess ne sert pas qu'à faire du rewriting! :wink:

Ont peut aussi s'en servir pour modifier le contenu de ses headers.

Par exemple, j'ai rajouté dans les headers des pages du site de mon profil:

Code:
Author: jr multimedia

J'ai aussi masqué les valeurs de X-Powered-By et Set-Cookie.

Comment j'ai fait?

Tout simplement en rajoutant ceci au fichier htaccess:

Code:
Header append Author "jr multimedia" 
Header unset  X-Powered-By
Header unset  Set-Cookie

La synaxte est simple: Header set|unset|add|append en-tête valeur ou Header unset en-tête

Les plus curieux peuvent consulter la doc appache (module mod_header).

note:
Code:
Le module optionnel d'en-têtes permet la personnalisation des en-têtes HTTP de réponse. Des champs d'en-têtes peuvent être ajoutés, remplacés ou supprimés. Les directives dans ce document ne sont disponibles que si Apache est compilé avec le module mod_headers.c. 

Les directives Header sont interprétées juste avant qu'une réponse ne soit envoyée par le gestionnaire (handler) approprié. Ceci signifie que certains champs d'en-tête qui sont ajoutés juste avant que la réponse soit envoyée ne pourront être supprimés ni surchargés. Ceci concerne des champs tels que Date: et Server:

Eh non! on ne peut pas masquer le type de son serveur et la date de la requte! :wink:

Alors, qui maintient qu'un url rewriting est toujours détectable! :lol: :lol: :lol:
 
WRInaute impliqué
:) Personne n'a dit qu'il était toujours détectable... et de toute façon, ce n'est pas par les en-têtes (mais plutôt en observant les réponses à des requêtes pas ou mal prévues par le webmaster).

Et comme disait Cendrillon, il n'y a aucun intérêt à détecter l'UR et je ne pense pas que les "bizarreries" de Slurp aient pour pour objectif premier de détecter l'UR... C'est plutôt pour détecter les sites qui ont réponse à tout... :wink:

Quant au détournement de l'UR pour placer plein de mots-clés, les moteurs ont certainement d'autres outils basés sur la simple analyse de l'URL en elle-même (nombre de tirets, poids des mots, etc...) et que ce soit de l'UR ou pas est tout compte fait assez secondaire.
 
Nouveau WRInaute
Voilà, avec toutes ces histoires qu'on nous fait là,je ne sais plus quoi penser.

Juste une petite vérification, pensez vous que url rewritting apliqué sur les pages du site qui se trouve dans mon profil ( et la signature aussi ) , en particulier pour le forum phpbb ,peut aider google ou pas ? juste pour etre sûr que google va bien me dire "hello" j'indexe tes pages :
 
WRInaute passionné
Pour illustrer le point 5 de mon sujet, voici l'évolution du traffic moyen journalier total comparé au traffic moyen journalier généré par google.fr d'un site que je ne nommerais pas! :wink:
traffic.gif


On y voit clairement qu'il y a d'autres sources de visiteurs que Google, sources, je vous le garantie plus fiables et durables!

J'espère que cela aidera les trés nombreux wrinautes qui ont les yeux rivés sur la valeur de leur PR ou de leurs BL sur l'ensemble des DC à se poser les vrais questions! :mrgreen: Pour info, le site mesuré à un PR de 4 seulement! :lol: :cry: (je ne sais plus si il faut en rire ou en pleurer! :wink: )
 
WRInaute discret
fandecine a dit:
fandecine a dit:
Aller, pour les détectives en herbe, vous allez sur le site de mon profil et vous me dites si vous pouvez trouver des élément objectifs et catégoriques pour dire que telle ou telle page est rewrité! :D

Alors! personne veut jouer avec moi? :cry: :cry: :cry:

si c'est pour jouer, je suis toujours partante :)
-http://tisha.weezyhost.com/
pas certaine que l'adresse restera valide longtemps. le script consomme tout de même beaucoup de resource. et les hébergeurs gratuit détestent.

fandecine a dit:
On lit ça et là que l'url rewriting est dangereux pour le référencement car les moteurs devinnent que la technique est utilisée pour ajouter des pages artificiellement, en gros, un site avec 100.000 pages html est louche pour les moteurs de recherche.

si c'est possible, j'aimerais quelques unes des adresses où je pourrais lire les arguments sur les dangers d'utiliser mod_rewrite.

merci à l'avance

tisha
 
WRInaute passionné
Tisha a dit:
si c'est pour jouer, je suis toujours partante :)
-http://tisha.weezyhost.com/
pas certaine que l'adresse restera valide longtemps. le script consomme tout de même beaucoup de resource. et les hébergeurs gratuit détestent.

Le candidat est une candidate! :wink:

Alors allons-y! :D

url: -http://www.fan-de-cinema.com/joke/test1/page.html
Source:
Code:
<head>
<title>page</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body>
	<h1>Ceci est une page statique</h1>
</body>
</html>
Resultat de ton test: ADRESSE RÉÉCRITE taux de concordance: 50%

PERDU! Page 100% statique sans rewritting :lol:

url: -http://www.fan-de-cinema.com/joke/test2/page.html
Source: identique au precedent
Resultat de ton test: ADRESSE RÉÉCRITE taux de concordance: 59%

PERDU! Page 100% statique sans rewritting :lol:

url: -http://www.fan-de-cinema.com/joke/test3/page.html
Source: identique au precedent
Resultat de ton test: ADRESSE RÉÉCRITE taux de concordance: 68%

PERDU! Page 100% statique sans rewritting :lol:

url: -http://www.fan-de-cinema.com/joke/test4/page.php
Source:
Code:
<head>
<title>page</title>
</head>

<body>
	<?php echo "<h1>Ceci est une page dynamique</h1>";?>
</body>
</html>
Resultat de ton test: PAGE STATIQUE taux de concordance: 72%

PERDU! Page dynamique sans rewritting :lol:


url: -http://www.fan-de-cinema.com/joke/test4/page.html
Source: identique à test4/page.php
Resultat de ton test: PAGE STATIQUE taux de concordance: 72%

PERDU! Page dynamique avec rewriting (c'est la même page que test4/page.php) :lol:

La seule différence dans ces tests c'est la modifications des headers.

Alors! d'autres candidats? :D

PS: Tisha, si tu as des problèmes avec ton hébergeur pour le script, contacte moi par MP, je te ferais une petite place, histoire qu'il reste en ligne! :wink:
 
WRInaute discret
fandecine a dit:
Le candidat est une candidate! :wink:

Alors allons-y! :D

url: -http://www.fan-de-cinema.com/joke/test1/page.html
Source:
Code:
<head>
<title>page</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body>
	<h1>Ceci est une page statique</h1>
</body>
</html>
Resultat de ton test: ADRESSE RÉÉCRITE taux de concordance: 50%

PERDU! Page 100% statique sans rewritting :lol:
HTTP/1.1 200 OK
Date: Sun, 26 Feb 2006 12:22:06 GMT
Server: Apache/2.0.54
Last-Modified: Sun, 26 Feb 2006 09:53:52 GMT
ETag: "684fc-a9-92500c00"
Accept-Ranges: bytes
Content-Length: 169
Author: jr multimedia
X-Powered-By: PHP 4.0.2
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Pour que X-Powered-By: PHP 4.0.2 s'affiche, il faut soit
a) PHP est utilisé
b) Tu as ajouté le champs.

fandecine a dit:
url: -http://www.fan-de-cinema.com/joke/test2/page.html
Source: identique au precedent
Resultat de ton test: ADRESSE RÉÉCRITE taux de concordance: 59%

PERDU! Page 100% statique sans rewritting :lol:
HTTP/1.1 200 OK
Date: Sun, 26 Feb 2006 12:30:24 GMT
Server: Apache/2.0.54
Last-Modified: Sun, 26 Feb 2006 09:56:45 GMT
Accept-Ranges: bytes
Content-Length: 96
Author: jr multimedia
X-Powered-By: PHP 4.0.2
Connection: close
Content-Type: text/html; charset=ISO-8859-1

même chose pour X-Powered-By: PHP 4.0.2, le champs ETag a probablement été enlevé.

fandecine a dit:
url: -http://www.fan-de-cinema.com/joke/test3/page.html
Source: identique au precedent
Resultat de ton test: ADRESSE RÉÉCRITE taux de concordance: 68%

PERDU! Page 100% statique sans rewritting :lol:
HTTP/1.1 200 OK
Date: Sun, 26 Feb 2006 12:38:05 GMT
Server: Apache/2.0.54
Last-Modified: Sun, 26 Feb 2006 09:58:13 GMT
Content-Length: 169
Author: jr multimedia
X-Powered-By: PHP 4.0.2
Connection: close
Content-Type: text/html; charset=ISO-8859-1
X-Pad: avoid browser bug

X-Powered-By ajouté, ETag enlevé. Ne perds ton temps a modifier les champs retournés pour faire croire qu'une page statique soit dynamique. Le but est beaucoup plus l'inverse: faire croire que c'est une page parfaitement statique dans le cas du dynamisme avec ou sans réécriture.

fandecine a dit:
url: -http://www.fan-de-cinema.com/joke/test4/page.php
Source:
Code:
<head>
<title>page</title>
</head>

<body>
	<?php echo "<h1>Ceci est une page dynamique</h1>";?>
</body>
</html>
Resultat de ton test: PAGE STATIQUE taux de concordance: 72%

PERDU! Page dynamique sans rewritting :lol:
HTTP/1.1 200 OK
Date: Sun, 26 Feb 2006 12:45:56 GMT
Server: Apache/2.0.54
Author: jr multimedia
Accept-Ranges: bytes
ETag: 684fc-18c-643d00c0
Content-Length: 96
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Là par contre, tu sembles avoir trouvé une combinaison intéressante de champs. Il manque Last-Modified et le contenu de ETag doit-être entre guillet il me semble... et il est préférable d'avoir un ETag absent plutôt qu'un contenu erroné. Content-Length par contre doit-être présent et retourner un contenu absoluement exact. Il manque un Last-Modified, de préférence avec une date fixe qui change de temps en temps pour la date du moment du changement. Pas un problème pour une base de données. J'ai jamais essayé avec header, mais je suppose que ça fonctionnerait. Ce test revèle tout ce qu'il faut pour les entêtes.

fandecine a dit:
La seule différence dans ces tests c'est la modifications des headers.
C'est la base. Comme ton dernier test révèle quelque chose de + qu'intéressant concernant les entêtes. Alors penses comme un athé que je connais qui a fait baptiser son nouveau né: "au cas où ça serait vrai".

fandecine a dit:
Alors! d'autres candidats? :D
héééé, les candidates elllllles :) macho ;) je veux jouer, je veux jouer, je veux jouer!!! zut, zut, zut!!! :cry:

La réécriture ne peut pas être l'accusée, mais elle serait plutôt le témoin. Pour les grands noms dans le domaine des moteurs de recherche, la définition de spammer est: "spammer: dès qu'un webmaster change un mot sur une page d'un site en pensant au positionnement". Bien entendu, cette définition donne + l'esprit que la lettre.

Si un filtre de ce genre existe il n'est pas seul et il est dans une logique de détection globale. Désolée, mais les serveurs mal configurés seront testés positivement et, j'en suis certaine, les grands maîtres de google/yahoo/msn dormiront très bien même en sachant avoir de faux positifs. Les dommages collatéraux sont surement leurs lot quotidien, tant que c'est dans une proportion acceptable.

Personnellement, si j'avais un résultat de + 90% sur environ 20 millions de tests, pour un filtre quelconque... ce serait une implémentation assurée...+ de 90% des spammers non encore détecté dehors? oui, oui, oui, ou est-ce que je signe !!!

fandecine a dit:
PS: Tisha, si tu as des problèmes avec ton hébergeur pour le script, contacte moi par MP, je te ferais une petite place, histoire qu'il reste en ligne! :wink:
J'ai fait ce script en Février 2005 pour le suggérer dans une discussion ici d'ailleurs. Je n'avais pas le désir de le faire évoluer et je n'ai toujours pas l'intention de le faire évoluer, bien qu'il ait besoin de 2 phases supplémentaires pour être complet. Actuellement, il analyse l'entête retournée et un peu le contenu de la page. En oubliant le raffinement nécessaire sur l'implémentation actuelle, il aurait aussi besoin de

1) regarder d'autres pages du même domaine (probalement via les liens de la page analysée)
2) tenter 1 ou 2 requêtes fausses (grace à une déduction de partie changeante de l'url)
3) et le plus dur, la pondération de tout ça.


J'aimerais quelques adresses où il y a des arguments sur les dangers de mod_rewrite dans un référencement. Si toi ou tout autre personne a ça sous la main. Pour moi, j'aimerais beaucoup approfondir le "pourquoi" plus que le "comment".

tisha
 
WRInaute passionné
Tu sais tisah, je pense que le rewriting ne pénalise en rien un site web auprés des moteurs de recherche. Et c'est parce que je n'ai jamais rien lu de convaincant pour me prouver le contraire que je continue à penser la même chose. Je ne peux donc pas te donner de lien vers des artiocles qui tendraient à pouver le contraire. :wink:

Quant à mes petites démo, le seul but est de montrer que l'on peut facilement modifier les headers de ses pages et ainsi faire passer une page pour ce qu'elle n'est pas auprès de n'importe quel bot. :D

Seule une analyse humaine peut déterminer à coup sûr l'utilisation du rewriting. Et je ne vois toujours pas pourquoi rewriting doit forcement dire spam. Le rewriting permet d'augmenter la sécurité d'un site web en masquant par exemple les varibles utilisée par les scripts, ce qui est en soit, une raison suffisante pour le mettre en oeuvre.
 
Nouveau WRInaute
Salut FDC!

S'il pouvait y avoir plus d'articles de ce genre: ayant du contenu et ne favorisant pas la Googlemania (créer des sites pour google), ce serait merveilleux (pas utopique).

Mais je vois déjà, les webmasters vivant de la "mane" Google qui m'en voudront de t'encourager.

Félicitations !!

Pour ce qui est du sujet, il est claire que depuis que j'utilise l'Url rewriting, les visiteurs de mon site restent plus longtemps et reviennent. Et je certifie que ce n'est pas google bot qui revient.
J'ai l'impression qu'ils se sentent moins "perdu". Vu le fouillis on comprend...
 
WRInaute discret
Mais oui FDC

J'ai l'impression que pas mal de gens mélangent dans le même concept cloaking et url-rewriting, d'où pas mal d'incompréhensions.

Le post de FDC est un modèle de sagesse, nous avons là un webmaster blanchi sous le harnais en tout cas.

Ce qu'il dit est très vrai et je le constate de plus en plus. Du coup ma Googlite (consultation obsessionnlle compulsive de GG) est soignée, je me recentre sur les contenus des sites que je fais et je reviens aux bons vieux 'coups de comm' d'avant et le nombre de visiteurs, s'il n'est pas croissant, est beaucoup plus qualifié.
 
WRInaute discret
Effectivement, tout ceci apparait plus que fort intéressant.
Merci Fandeciné.
<HS>j'aimerais avoir un peu plus de temps pour explorer ton site dans les thèmes m'intéressant</HS>

Ceci mis à part, j'aimerais apporter une petite précision, toute petite:
dans ta réponse à Tisha, celle où tu analyses sa participation, tu déclares une page dynamique car elle utilise PHP.
je ne suis pas d'accord !

en ôtant les tags php et l'instruction, cela ne changerait strictement rien à la page.

A mon sens, pour qu'une page mérite l'appellation "dynamique", il faut que son contenu puisse changer, ne serait-ce qu'un minimum, sans que l'on ait à réécrire quoi que ce soit dans la page. :wink:
 
WRInaute discret
oui excellent post que je me rappelle avoir déja lu il y a un bout de temps et qui m'avait bien aidé

oui comme tu dis on peut rajouter l'indispensable patience à avoir, il faut savoir laisser mijoter et observer et ne pas tout modifier tous les jours névrotiquement :D

je rajouterais aussi une chose au sujet des liens réciproques :

sur un tuto de WRI, on peut lire que dire que les liens réciproques nuisent au référencement est une fausse rumeur

c'est vrai dans un sens, mais sur le blog de Matt cuts, il parle de déclassement d'un grand nombre de sites à cause de deux raisons principales : excessive reciprocal links et bad outlinks / inlinks

le premier cas désigne donc l'excès de liens réciproques, mais ou commence et ou s'arrete l'excès ?

faut il moins de 50% de liens réciproques ? on peut souvent lire aussi "dans une limite raisonnable", d'autant plus que ces liens sont pondérés, on peut avoir un gros lien utile au ref et réciproque et 50 liens sans intéret pour le ref non réciproques.

Dans ce cas on pourrait etre quand meme taxé d'"excessive reciprocal links" ? ...

Dorénavant donc j'évite autant que je peux , voire meme complètement

Vive les liens croisés ! (pour l'instant :wink: )
 
WRInaute discret
fandecine a dit:
Arrétons les bétises! Un moteur ou un internaute n'a aucun moyen de savoir si le site est rewrité ou pas!!!

et bien si, il y a bien une solution de le savoir ;-)

mais ca ne marche pas forcément à tous les coups ;-) .....

il suffit de voir si la page renvoit un header content-lenght
ou un connexion - close sur le keep alive

dans ces cas là, on peut présumer que la page est "dynamique"
et du coup, si l'extension est .htm, estimer que c'est de l'url rewriting ...

je ne sais pas si ca fait la meme chose quand on fait du server side include

j'ai pas pris le temps de regarder
 
WRInaute passionné
ysimon a dit:
fandecine a dit:
Arrétons les bétises! Un moteur ou un internaute n'a aucun moyen de savoir si le site est rewrité ou pas!!!

et bien si, il y a bien une solution de le savoir ;-)

mais ca ne marche pas forcément à tous les coups ;-) .....

il suffit de voir si la page renvoit un header content-lenght
ou un connexion - close sur le keep alive

dans ces cas là, on peut présumer que la page est "dynamique"
et du coup, si l'extension est .htm, estimer que c'est de l'url rewriting ...

je ne sais pas si ca fait la meme chose quand on fait du server side include

j'ai pas pris le temps de regarder

tu as bien lu le post!? :wink:

Je recommence :D

soit deux pages qui renvoient un content close et un content-lenght:

-http://www.fan-de-cinema.com/joke/test4/page.html
header
Code:
HTTP/1.1 200 OK
Date: Thu, 08 Jun 2006 12:23:17 GMT
Server: Apache
Last-Modified: Sun, 26 Feb 2006 09:53:52 GMT
ETag: "684fc-a9-92500c00"
Accept-Ranges: bytes
Content-Length: 169
Author: jr multimedia
X-Powered-By: PHP 6.3.25
Connection: close
Content-Type: text/html; charset=ISO-8859-1

-http://www.fan-de-cinema.com/joke/test4/page.html
Code:
HTTP/1.1 200 OK
Date: Thu, 08 Jun 2006 12:19:50 GMT
Server: Apache
Author: jr multimedia
Accept-Ranges: bytes
ETag: 684fc-18c-643d00c0
Coucou: il y a un piège!
Content-Length: 96
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Pourtant, l'une est dynamique l'autre pas! l'une est rewrité l'autre non!

Les headers ont leur fait dire ce que l'on veut! Regarde bien, il y a un intru dans chacun des deux headers! :lol: :lol: :lol:

Aller, celui qui trouve l'intru de la première page je .... luis fait une grosse bise. :wink:
 
WRInaute discret
fandecine a dit:
-http://www.fan-de-cinema.com/joke/test4/page.html
header
Code:
HTTP/1.1 200 OK
Date: Thu, 08 Jun 2006 12:23:17 GMT
Server: Apache
Last-Modified: Sun, 26 Feb 2006 09:53:52 GMT
ETag: "684fc-a9-92500c00"
Accept-Ranges: bytes
[b]Content-Length: 169[/b]
Author: jr multimedia
X-Powered-By: PHP 6.3.25
[b]Connection: close[/b]
Content-Type: text/html; charset=ISO-8859-1

-http://www.fan-de-cinema.com/joke/test4/page.html
Code:
HTTP/1.1 200 OK
Date: Thu, 08 Jun 2006 12:19:50 GMT
Server: Apache
Author: jr multimedia
Accept-Ranges: bytes
ETag: 684fc-18c-643d00c0
Coucou: il y a un piège!
[b]Content-Length: 96
Connection: close[/b]
Content-Type: text/html; charset=ISO-8859-1

je ne sais pas quel outil tu utilises pour lire tes headers
car normalement, quand on est en connection keep alive au niveau du client, le serveur renvoit soit un connection : keep alive avec un content-lenght

le connection: close avec le content-lenght spécifié en meme temps n'est pas ce qui devrait se produire avec un client de type keep alive

d'ailleurs, actuellement, sur ta page, avec un internet explorer, en keep alive, voila les headers que j'ai

Code:
HTTP/1.1 200 OK
Date: Thu, 08 Jun 2006 13:44:23 GMT
Server: Apache
Author: jr multimedia
Accept-Ranges: bytes
ETag: 684fc-18c-643d00c0
Coucou: il y a un piège!
Content-Type: text/html; charset=ISO-8859-1
Age: 0
Transfer-Encoding: chunked

ce qui, à mon sens, tendrait à montrer, en absence de content-lenght, que c'est une page dynamique ...
 
WRInaute passionné
ysimon a dit:
d'ailleurs, actuellement, sur ta page, avec un internet explorer, en keep alive, voila les headers que j'ai

Code:
HTTP/1.1 200 OK
Date: Thu, 08 Jun 2006 13:44:23 GMT
Server: Apache
Author: jr multimedia
Accept-Ranges: bytes
ETag: 684fc-18c-643d00c0
Coucou: il y a un piège!
Content-Type: text/html; charset=ISO-8859-1
Age: 0
Transfer-Encoding: chunked

ce qui, à mon sens, tendrait à montrer, en absence de content-lenght, que c'est une page dynamique ...

Et pour l'autre page, qu'est ce que tu obtiens?

ysimon a dit:
je ne sais pas quel outil tu utilises pour lire tes headers
-www.wannabrowser.com

Solution du jeux:

Pour la deuxième page, l'intru c'est:
Coucou: il y a un piège!

Pour la première, je suis le seul webmaster au monde à disposer de PHP en version 6! :wink:

:D :D :D
 
WRInaute accro
fandecine a dit:
Pour la première, je suis le seul webmaster au monde à disposer de PHP en version 6! :wink:
Excellent 8) je ne l'avais même pas remarqué...
J'ai perdu ma bise :wink:
 
Nouveau WRInaute
très bonne remarque

Je suis 100% d'accord avec ce post.

Il faudrait bien apprendre aux editeurs de sites que l'utilité de leur bébé est le meilleur des réferencement.
 
Nouveau WRInaute
Pour un des premiers articles que je lis sur le forum, je suis bien content de m'etre inscrit !
Bravo, clair, net, precis, voilà une bonne chose de faite
 
Nouveau WRInaute
Je rejoins l'idée de ce post.

Du contenu et encore du contenu !

Même si aux vus des résultats Google, celui-ci n'est pas toujours le 1er critère, mais il faut avouer que c'est de mieux en mieux.
 
WRInaute discret
Je partage cet avis moi aussi : du contenu, du contenu et encore du contenu. Ne pas oublier qu'on fait un site pour les internautes pas pour des robots d'indexation :wink:
 
WRInaute impliqué
Re: très bonne remarque

vardonthierry a dit:
Je suis 100% d'accord avec ce post.

Il faudrait bien apprendre aux editeurs de sites que l'utilité de leur bébé est le meilleur des réferencement.
le bouche a oreille fonctionne pas mal aussi.... il suffit de regarder mySpace, niveau optimisation c'est vraiment pas terrible, mais un gros buzzqui amène des millions de contributeurs c'est plus fort que toutes optimisations imaginables
 
Nouveau WRInaute
complément

J'aimerai juste rajouter que le rewriting à un autre interet, s'il est bien fait l'url de vos pages est beaucoup plus agréable qu'une url à la con du genre

toto.asp?i=12&r=234$o=1234

qui peut devenir

/mot1/mot2/mot3/toto.htm

plus agréable pour vous pour les visiteurs et pour les moteurs qui apprécie particulièrement les sites dont l'organisation en répertoire est claire et riche.
 
WRInaute discret
Très bien parlé Fandecine !!

:D

J'ai encore et toujours appris des choses intéressantes sur l'URL Rewriting. J'étais encore ( :oops: ) à penser que les moteurs de recherche "n'aimaient" pas trop ça...

En gros, si j'ai bien compris:

Peu importe que l'on ait vraiment une arborescence de dossiers, mais ce qui compte, c'est d'avoir hiérarchisé correctement conceptuellement les pages web que l'on veut exposer à l'internaute. Ce faisant, on est sûrs de pouvoir ré-écrire l'URL comme il faut (i.e. avec une arborescence de dossiers correcte et cohérente).

Par exemple, si l'on prend un site parlant de voitures, avec des ferraris, et notamment la célèbre F40. Peu importe que l'on crée réellement un dossier voiture, puis un autre ferrari, puis notre page f40.html. Si l'on a une base de données, par exemple, indiquant que la page F40 doit appartenir à la catégorie voiture > ferrari, on est alors capable de ré-écrire une arborescence du type :

Code:
http://www.mondomaine.com/voitures/ferrari/f40.htm

Est-ce bien comme ça qu'il faut le voir ? :?:

Merci à tous d'avance
 
WRInaute discret
yeca a dit:

Je suis d'accord avec lui quand il dit que respecter les standards web permet de diminuer le ration contenu / (totalité du code).

C'est une des raisons pour laquelle j'écris mes sites en respectant les standards, ça augmente le ratio contenu/totalité du fichier et augmente ainsi la pertinence du contenu.
Un autre avantage d'un site respectueux des standards, pour les internautes cette fois-ci, est que le poids des pages diminuant, l'affichage est plus rapide, et la bande passante diminuée.
La page étant plus légère, elle est lue plus rapidement par les robots.

A ce propos, il me vient une question : est-ce que le temps moyen que passe le robot à scanner une page web, rapporté à la taille moyenne du contenu de la page est pris en compte d'une façon ou d'une autre? :eek:. Cela pourrait, à mon sens, être un bon indicateur pour les robots...
 
WRInaute passionné
Dargoan06, l'url rewriting est en effet un moyen efficace de structurer et hierarchiser l'organisation des pages de ton site. Attention toutefois à éviter la redondance. L'exemple que tu donne n'est valable que si le site en exemple parle aussi de moto de camions... sinon, le dossier virtuel "voitures" est inutile et ne fait qu'alonger les url.

Pour ce qui est des standards, leur respect n'allége pas le poids de la page, bien au contraire. Si tu prends une page xhtml strict et que tu supprime les mises entre guillemets des paramétres des tags html tu auras une page bien plus légère :wink:

Par contre, le respect des standards léve de nombreuses ambiguités et permet ainsi au navigateur d'interpréter le code plus rapidement. :D
 
WRInaute discret
fandecine a dit:
Dargoan06, l'url rewriting est en effet un moyen efficace de structurer et hierarchiser l'organisation des pages de ton site. Attention toutefois à éviter la redondance. L'exemple que tu donne n'est valable que si le site en exemple parle aussi de moto de camions... sinon, le dossier virtuel "voitures" est inutile et ne fait qu'alonger les url.
C'est vrai, tu as tout à fait raison.

Pour ce qui est des standards, leur respect n'allége pas le poids de la page, bien au contraire. Si tu prends une page xhtml strict et que tu supprime les mises entre guillemets des paramétres des tags html tu auras une page bien plus légère :wink:
Je pensais pour ma part, mais ce n'était pas explicite, au cas typique suivant : en html façon soupe, c'est de la programmation avec plein de <table>, <tr> et <td> imbriqués de façon délirante !! Avec les standards web, on a plus tendance à fractionner une page en section, soit en <div>. Du coup, le fichier s'allège car le code html est bien moins lourd :lol:.

Ceci étant, je pensais également à un article intéressant que j'avais lu qui compare justement le poids des pages qui précise beaucoup ce que je veux dire :
h**p://css.alsacreations.com/Faire-une-mise-en-page-sans-tableaux/Petite-comparaison-entre-les-tableaux-et-les-standards
 
WRInaute discret
Ne serait-on pas en train de devenir un peu hors sujet, là ?

J'en profite néanmoins pour vous donner un aperçu de ce que l'on peut reprocher à cette méthode de mise en page. A noter que plus les navigateurs sont récents plus il y aura de chance que ces problèmes se corrigent... Mais il y a quelque temps un chti gars dans un centre de formation me montrait fièrement une page réalisée ainsi. Puis on va la voir avec un autre browser qu'IE et là :!: stupeur, l'horreur :twisted: Absolument indescriptible, la page était non seulement méconnaissable, mais de plus illisible. Je ne me souviens malheureusement pas de l'URL, mais je crois me souvenir qu'il s'agissait d'une grosse agence Web ( je dirais même de la région toulousaine, mais pas sûr :? ) Aujourd'hui, pour vous donner cet aperçu, voici un screen du site ci-dessus dans Opéra :roll:
Clipoperadiv.jpg

Mais ceci n'est rien en comparaison de ce que j'ai pu constater parfois.

Et encore merci à FDC
PS vais de ce pas essayer de trouver l'intrus de la première page que personne ne semble avoir encore trouvé... (pas mal le php 6 ;) dommage que j'ai pas lu au moment ou ce fut posté)
 
Haut