Danger de l'url rewriting

[code]

Bonjour,

un mauvais rêve m'a agité cette nuit (ou un cauchemar plutot ) :

Tout le monde ici sera d'accord sur l'intérêt de pratiquer l'url rewriting pour des pages comportant plusieures variables et ce afin d'améliorer (sensiblement) ses positions.

Seulement voilà.
Considérons la page suivante : .../motclé-1234.html

motclé est un mot clé généré grâce à l'url rewriting et qui reprend par exemple un mot clé important du titre
1234 est l'id de la page

La page d'origine en php serait donc la suivante : .../motsansinteret.php?id=1234

Maintenant imaginons que la page rewritée soit n° 1 sur Google sur des requetes très concurentielles

Donc des concurrents s'intéressent de plus près à mon site. Ils remarquent que celui-ci est rewrité


Imaginons maintenat un très méchant concurrent qui veuille ma peau. Il se fait la remarque suivante :

motclé-1234.html appelle la meme page que nimportequelmot-1234.html

il décide donc de créer un site qui s'appelera un "killer de concurrent" et sur lequel il va creer des centaines de liens de ce type :

mot1-1234.html ; mot2-1234.html ; mot3-1234.html ... etc et qui renvoient tous à la meme page à savoir motclé-1234.html


Parce que c'est un teigneux, il va réitérer l'opération sur 10 autres sites créés pour l'occasion mais il prendra soin que ces sites ne soient pas liés entre eux et pas sur le même bloc C et pas non plus hébergés dans les mêmes pays et tout cela afin de créer à sa victime un duplicate content impressionnant

Enfin, une fois que les bots auront indexé les pages de ses sites "killer de concurrent", il va régulièrement utiliser l'outil de spam report de google pour dénoncer le site de sa victime.

Au bout d'un moment, Google ne va-t-il pas considérer le site victime sous un autre oeil et se pencher sur son cas ?

Déclassement du site, voire blacklistage.

Vous allez me dire c'est du Spielberg, et puis de toute façon les sites "killer de concurrent" finiront par être démasqués... etc...

Oui mai en attendant, Google peut très bien dans un premier temps se laisser piéger, quitte à réintégrer le site victime par la suite.
Mais c'est ça que je trouve inquiétant. Car les boulettes et Google, ce n'est pas imcompatible. Pire, la lenteur, voire très grande lenteur de réaction de ce moteur depuis maintenant des mois ne laisse rien présager de bon en cas de coup dur. Et quid des pages indexées à cause du méchant killeur de concurrent. Je vois encore dans l'index des pages qui ont plus d'un an et qui n'existent plus !
Sans compter que pour un webmaster, même 2 mois de blacklistage peut être une catastrophe.

Bref, je me dis que l'url rewriting doit être utilisé seulement si on ne peut pas faire autrement. C'est la réflexion que j'avais lancée dernièrement sur un autre topic concernat phpbb ou je me posais la question de l'intérêt de de rewriter phpbb pour remplacer "viewtopic.php?t=1234" par "viewtopic-1234.html"

Après cette nuit, je me dis que le type de rewriting cité juste au dessus, n'apporte rien, ne vaut pas le cout car il n'apporte meme pas de mot clé dans l'url.
Pire : l'url rewriting représente selon moi une faille énorme de la sécurité d'un site, la possibilité de perte de controle par le webmaster.

De toute façon j'ai tendance à me mefier de tous les bidouillages servant à améliorer artificiellemnt son classement. L'url rewriting est bien un bidouillage car on trafique la page d'origine en cachant sa véritable identité. Tout cela à cause des moteurs qui nous poussent à toujours vouloir grapiller des places aux autres, on joue sans cesse avec des techniques de passe-passe toujours à la limite
Peut être que dans 2 ans, l'url rewriting sera compris par les bots et même pénalisé !

Enfin, dites moi si j'ai déliré

[rtb]

rewriting ou pas, il peut etre fait cela même avec une simple page html, je vois pas trop le rapport avec le danger de mettre en place le rewriting sur son site, je dois être mal révéillé

[blason]

raisonement logique, mais faut vraiement que le gars soit teigneux et ai du temps et/ou de l'argent a perdre pour creer des dizaines de duplicate content sur des dizaines de serveurs hebergés dans des dizaines de pays... meme sur requetes tres concurantielles ... j'ai des doutes et a mon avis il y a plus de chances de se faire ecraser en traversant la rue que d'etre victime d'une telle machination ..... donc dort tranquillement et mets tes mechants reves/cauchemards a la poubelle (click droit> envoyer vers...)

[twin]

Houla, dés le matin...
Mais comme le dis blason, il faut que le concurrent est vraiment du temps à perdre pour ce genre de chose. Je ne pense pas que certains webmaster en soient arrivées jusqu'ici...

[Leonick]

En plus, avec du duplicate content, ce n'est pas le blacklistage, mais une seule page est indexée. C'est vrai que ça pourrait être avec une url qui ne nous convient pas. genre /produit-de-m..1234

[code]

En plus, avec du duplicate content, ce n'est pas le blacklistage, mais une seule page est indexée. C'est vrai que ça pourrait être avec une url qui ne nous convient pas. genre /produit-de-m..1234

Certes sans aller jusqu'au blacklistage, le probleme du duplicat content peut etre serieux et nuire gravement au positionnement d'un site.

D'ailleurs ne dit-on pas : "le duplicat content tue" ou encore "faire du duplicat content nuit gravement à la santé" ... d'un site ?

[code]

rewriting ou pas, il peut etre fait cela même avec une simple page html, je vois pas trop le rapport avec le danger de mettre en place le rewriting sur son site, je dois être mal révéillé

et bien non justement, car aevc l'url rewriting tel que je l'ai décris, c'est l'id qui renvoit à la page, le mot clé qui précède n'a aucune importance et il peut être n'importe quoi. Ce qui signifie qu'en changeant ce mot clé mais en conservant la meme id, il y a théoriquement (et physiquement) une infinité de pages rewritées qui renvoie à la meme et unique page qui est en php à l'origine.

Une simple page html, comme tu le dis, est simple, donc unique. Si tu appelles la page par une autre url, étant donné que tu ne fais pas appel à une quelconque variable, et bien tu appelle tout simplement une autre page.
Donc aucun risque.

[mrPringle]

Enfin, quand on rewrite, c'est bien de faire un minimum de vérifs aussi.

[netsys]

Enfin, quand on rewrite, c'est bien de faire un minimum de vérifs aussi.

Effectivement c'est ce qu'il faut faire, une vérification !

Je me suis aperçu que cela était une des faiblesses de l'ur de pouvoir appeler une même page de plusieurs manières différentes.

Cela pouvais servir à un concurrent malhonnete mais également faire l'objet d'un bl naturel mal renseigné.
Cela m'empechait également de renommer mes pages puisque l'ur utilise les mots clés et que je ne suis pas arrivé à faire un 301 entre 2 ur rewrité, le serveur me rajoutant inévitablement la variable avec ? à la suite de ma réécriture.

Ma solution a donc été de vérifier si la page appelée correspond avec l'url qu'elle doit avoir. Si c'est pas la cas, je redirige en php (301) vers la bonne url.

[Tilt]

Très bonne solution, de détecter si l'url correspond ou non. Il suffit pour cela de rewriter en ajoutant une variable:
/mot-clé-1234.htm
devient
/script.php?id=1234&url_rewriting=1

Et en testant si la variable "url_rewriting" a la valeur 1, on sait de suite si la bonne url a été utilisée ou non. Sinon => redirection.

[netsys]

Dans le cas de réécriture automatique tu ne peux choisir
d'ajouter ton test de rewrit, il sera ajouté peu importe le mot clé !

En fait j'utilise $_SERVER['REQUEST_URI'] pour détecter le nom de la page appelée.


mon 800 ème message

[tonguide]

C'est relativement simple à vérifier ...

Tu fais un rewrite sur le titre, hors, le titre, tu l'as toujours quand t'es sur la page ...
Donc tu repasses ta fonction sur ton titre pour recupérer le titre rewrité. Tu transmets une variable en GET avec la valeur du rewrite

Et tu finis par comparer les 2, si c'est ok, tu laisses, si c'est pas ok, requete SQL + recup du titre + redirection 301 vers la bonne url.

[netsys]

Comme dit tonguide c'est pas très compliqué à vérifier.

1. Récupération du nom de la page appelée avec $_SERVER['REQUEST_URI']

2. Construction de l'url telle qu'elle devrait être

3. Vérification des 2 : si pas identiques alors redirection 301 (en php) vers la bonne url qui a été calculée dans l'étape 2.

[Tilt]

Dans le cas de réécriture automatique tu ne peux choisir
d'ajouter ton test de rewrit, il sera ajouté peu importe le mot clé !

En fait j'utilise $_SERVER['REQUEST_URI'] pour détecter le nom de la page appelée.


mon 800 ème message

En effet, la variable $url_rewrite doit en fait contenir le mot-clé.

Si je place une Rewrite Rule dans le .htaccess du type (en simplifiant):
/(.*)-([0-9]{1,})/ script.php?id=$2&mot-cle=$1

Alors seules les urls rewritées vont transmettre la bonne valeur pour $url_rewrite (le mot-clé).

Le test de cette variable a lieu ensuite en php.

[code]

C'est génial les gars, j'avais pas pensé à ça !

Mais à mon avis la solution la plus simple est celle avec le REQUEST_URI, qui par ailleurs est la moins lourde à appeler