jnj

bonjour, excellente synthèse mais si quelques points ne me paraissent peut être pas tout à fait justes d'après mes propres campagnes de mesure. je ne suis pas persuadé que un échange de liens footer à footer entre A et B soit acceptable dans l'exemple de l'échange de liens à 3 sur A, B et C. en théorie des graphes, cela ferme la boucle, donc l'échange tripartite devient immédiatement flagrant. j'éviterais personnellement une telle fermeture de boucle trahissant la relation entre A et B. JnJ

salut, je ne suis pas modérateur , mais tu aurais plus de réponses en postant dans ce fil plutôt que ici :: web master : URL rewriting et autres .htaccess

hello j'ai testé sur un site pour vérifier :: une redirection 301 perd son efficacité (en référencement bien sur) au bout d'un laps de temps se mesurant en mois. (quelques mois) à éviter donc. Il vaut mieux mettre le ou les liens à jour vers la bonne URL dès que possible pour éviter un duplicate content il y a aussi "no index , no follow" en meta tout simplement je doute que le poids d'une page dupliquée et gérée en link canonical ait une quelconque influence en positionnement. Cela me parait illogique mais je n'ai pas testé à+

salut, je découvre ce fil un peu tard. voici ma modeste contribution le code de 4 ans de Dan est efficace. il en existe des variantes sur quelques autres forum mais le code de Dan est le + complet et le mieux écrit. MAIS : cela revient à fournir à Google une page avec une URL et laisser les internautes naviguer avec d'autres URL => dans un point de vue c'est du duplicate content potentiel mais le user agent ne voit qu'une URL donc non. => dans un autre point de vue c'est du cloaking : n URL pointent vers une même page physique. Mais les URL sont différentes puisque phpsessid les différencie. Donc on revient sur du duplicate content et de toute façon seule une page est visible de Google Google, en mode "vérification et lutte contre le cloaking" , en comparant le résultat d'une indexation pourra comparer le contenu de l'URL "propre" et celui des URL "enrichies" Question : soit une même URL , propre ou affectée de phpsessid et de passage de paramètres. Ces URL sont elles du cloaking ? C'est à dire N même URL présentées à Google ou à des internautes avec une seule page physique ? Ma réponse mais je suis ouvert à toute discussion : non. Google considère que ce sont des URL différentes, que les pages à URL enrichies ne sont pas indexées et même si il considère que non, si VOUS AVEZ A PEU PRES LE Même CONTENU, il ne considèrera pas cela comme du cloaking. il semble que la nuance pour lui porte sur l'existence dans son index d'une URL et que strictement la même URL ait un contenu différent quand son bot "officiel" accède à cette même URL. je suis preneur de tout avis

je viens de faire une campagne de vérif du respect du W3C multilangue par Google , vous savez cette société si à cheval sur les balises ALT pour les malvoyants. Il en a rien à f<censuré>e !!!! il prend en compte la balise lang de toute la page, s'il y en a pas il calcule une langue et c tout donc ne jamais mélanger les langues sur une même page du texte balisé anglais dans une page native fr est ignoré du moteur US et UK - pour lui c du français. bon ...... je vais corriger mon support de cours multi langue en l'annotant : respecter le W3C uniquement si vous en avez rien à faire de Google sur les textes insérés dans d'autres langues.

le site pour qui j'ai fait cette manip est passé ensuite à une langue / une page et à l'époque cela ressortait je peux tester sur un de mes sites en PR5 et voir ce qui se passe tiens pourquoi pas à suivre ...

voici quelques extraits du cours que je donne. A priori Google est capable de comprendre cela. Il y a de nombreux cas où il est nécessaire de baliser la langue utilisée Je pense que la citation de matt cutts est bidon et là pour se simplifier la vie. en effet, ce sont les malvoyants (rappelez vous la balise ALT des images) qui ont le plus besoin pour leurs périphériques spéciaux de ces balises linguistiques. Et Google est censé respecter un minimum la norme WAI. < meta http-equiv="Content-Language" content="fr" /> # langue native de la page : français < meta http-equiv="Content-Language" content="fr,en" /> # langues natives de la page : français et English La déclaration bilingue fr / en ci dessus est valide pour une page d'accueil bilingue. Elle n'est pas faite pour une page qui serait en français avec juste une citation en English par exemple ou pour une formation d'anglais destinée à des francophones. En HTML et XHTML, on peut définir qu'une partie de la page est dans une langue autre que celle(s) définie(s) en meta. Il faut aussi encadrer les segment de code quand la langue change CODE <html lang="fr" xml:lang="fr"> que nous déclinerons sous cette forme : <html lang="en" xml:lang="en"> <head> <title>English page</title> </head> <body> . . . text in english, default language of this page . . . <span lang="fr" xml:lang="fr > Du texte en français au milieu d'une page en langue anglaise </span> . . . text in english . . . quelques variantes : <p lang="es">...texte en espagnol...</p> <em lang="en">some english sentences</em>

Well le problème peut venir d'où ? le point commun entre la grande majorité de ces pages différentes sanctionnées, "propres", c'est leur relatives petites tailles face à un menu de gauche relativement important. des pages sont passées de visibles avec PR5 à invisibles PR0 ! sans rien faire ! et sans spamdexing ????

cherubin, non tu ne peux pas mettre un xml lang:en et faire la page en français à 95% 1 - tu peux mixer les 2 langues et même y ajouter du chinois mais tu dois le signaler 2 - ta balise est incomplète - tu dois signaler en XML et en HTML - les 2 technologies. 3 - tu ne peux choisir qu'une langue dans la structure descriptive - en clair si tu indiques tout en haut lang="en", TITLE et toutes les balises / meta avant body devront être en ENglish exclusivement ce sont les règles du W3C et Google les suit. Si tu ne les respectes pas, tu ne peux pas préjuger de la réaction de Google et des éventuelles pénalités qui vont avec.

thick, le menu de gauche, le bandeau du haut, bref des éléments récurrents communs à toutes les pages du site sont du duplicate content Donc on peut parfaitement avoir une page avec un contenu unique et être en duplicate content Exemple : bandeau, balises ALT et TITLE des visuels du bandeau, menu généré par un classique .php pèse 200 mots significatifs Si la partie "unique" de la page contient peu de mots, un formulaire simple de contact par exemple, elle bascule en page sanctionnée. la part unique de la page n'est pas assez importante face à la part récurrente dupliquée n fois de la page. Question age du ndd, il est exact , pour le moment, que les sites jeunes de moins de 2 ans ont ces problèmes et que je n'ai rien sur les sites plus agés Social et Google oui, je pense comme thick. Depuis des années GG accumule des infos via la GG bar. mais une immense majorité de gens ne l'ont pas et ne l'auront jamais ce qui limite l'usage de ces données par GG indiscutablement Google met l'internaute au centre de ses algorithmes c clair depuis des années. Juste qu'ils commencent à passer à l'offensive maintenant

Cherubin, il y a des anomalies dans ton site la pénalité Google est peut être provisoire voici : un title en langue anglaise et le reste du site en français : perso j'évite ce genre de blague avec un robot vu que tu as un xml:lang="en" en haut de page , un title en anglais et la page en français derrière. la page provisoire en latin a été indexée. De mon expérience, quand il tombe sur des anomalies, statistiques ou autre, Google fait n'importe quoi ou il met en des pénalités provisoires. Suffit de faire le ménage dans les anomalies et tout revient dans l'ordre ensuite. Sinon tu auras enlevé des psites expliquant des pénalités contre ton site. JnJ

Merci Thick et cherubin aucune des pages sanctionnées n'a de contenus répétés sauf bien sur le bandeau du haut et le menu de gauche. La "camme" comme tu dis est exclusive à chaque fois les noms de domaine ont de mémoire un an et quelques pour l'un et deux et quelques pour l'autre Les optimisations de toutes ces pages sont standards. rien n'est poussé sauf 'l'URL qui est travaillé en mot clef. Et les autres pages baties sur la même architecture n'ont pas été sanctionnées - elles ont plus de contenu. Hasard ?? je n'ai pas l'impression. qu'est ce que : "une dose de social sur des URL" je ne connais pas le terme.

bonjour thème de ce fil : Google a t il changé son algorithme de détection de duplicate content et donc de l'application des pénalités associées ? je présente la situation Sur plusieurs sites de mes clients ou de sites que je gère, je constate des pénalités inexpliquées : pas de spamdexing , pas de liens loués ou autre techniques sanctionnées par Google sur ces pages. Les pages sont isolées au sein de chaque site. Ces pages avaient du PR dans la Googlebar et depuis , disons début avril, de nombreuses pages sont passées de PR vert quelque chose à gris Pire, quand je cherche cette page via des mots clefs , Google ne la donne jamais en réponse. Dans certains tests, il me propose 5 pages en SERP sur le web mondia via une requete sur 15 mots clefs. Et la page du site qui est référencée sur sur ces mots clefs n'est pas proposée en SERP. Dès que je mets un peu de guillements pour forcer casse et mots consécutifs, hop elle sort dans la SERP. => symptôme typique d'un black list partiel de la page. Des comme cela j'en ai entre 0 et quelques dizaines par site. différentes campagnes de tests et mesures m'ont conduit à suspecter un changement d'algorithme chez Google et un des symptômes en est l'application très rapide de pénalités pour duplicate content Pour être transparent : - je n'expliquerai pas encore pourquoi j'en suis arrivé à cette conclusion (histoire de ne pas influencer ceux qui accepteront de me répondre ou de faire des tests de leurs côtés) - je communiquerai plus tard les raisons ayant amenées à cette conclusion - il y a d'autres changements qui basculent des pages "propres" depuis des années en googlebar grisée avec des pénalités. Je les ai détectées mais pour le moment je ne les ai pas encore toutes identifiées clairement. - un autre symptôme de l'ensemble de ces changements : la variation en PR , en général à la baisse, sur les pages d'un site. le contexte étant posé, Mes questions à la communauté des référenceurs professionnels ou amateurs avertis : 1 - avez vous constaté de tels "phénomènes" ? 2 - avez vous essayé de déterminer le pourquoi ? 3 - avez vous d'autres idées sur la cause de ces applications de pénalités ? au plaisir de partager ces informations Cordialement

Bonjour Le PR a plusieurs utilités : - il chiffre très grossièrement le nombre de liens et la qualité globale de ces liens, internes ou externes. - il sert de levier. Exemple : une page d'accueil a un PR de 0 et plusieurs niveaux de pages en arborescence - elles ne seront pas explorées par Google. ou pas toute. Ce même site avec une page d'accueil à PR3 verrait toutes ses pages rapidement indexées - il est utile quand on joue finement en échanges de liens internes dans un même site. Trop compliqué à expliquer comment et pourquoi. - quand on avait un PR sur la googlebar et que d'un coup il devient grisé => la page a des sanctions par Google. Faut chercher pourquoi. les variations brutales de PR sont dues à la chasse aux liens non naturels par Google juste une chose : il n'existe aucune définition claire d'un lien loué chez Google. Il y a une définition bidon sur le blog de matt Cutts et c'est tout. Google juge à son aune ce qui est loué ou non. Donc vous pouvez n'avoir aucun lien loué de votre avis et Google de penser le contraire

hello mettre les accents ! les résultats sont presque les même avec ou sans MAIS : - il y a un an et demi il n'y avait aucune différence - actuellement il y en a un peu - et demain .. ??? rappel : Google a déposé un brevet , dit trustrank, qui indique sa volonté à terme de "noter" la qualité syntaxique, grammaticale etc. des contenus. En clair, mieux c'est écrit, mieux ce sera positionné dans l'index. dernier point : ne pas oublier : é n'est é mais é bon dépannage de PC

duplicate content : la page "en trop" a été virée de l'index.

URL rewriting / .htaccess == grosse différence entre ovh et les autres : wamp etc. : IL FAUT CECI : RewriteRule ^/([-_a-zA-Z0-9]+).... etc. la suite de la règle alors que sur les autres ceci suffit : RewriteRule ^([-_a-zA-Z0-9]+).... etc. la suite de la règle faut le / (slash) aposé par apache en début de string ^/( sur OVH sinon cela ne fonctionne pas. j'en ai bavé 2 heures pour arriver à cela !! vieux post auquel je réponds mais bon, je dois pas être le seul à me faire piéger en espérant que cela en aide quelques uns jnj

Merci Dan il y a un inconvénient à avoir un www.monsite.com et un www.monsite.com/index.php le PR qui est plus utile que ce bien des SEO croient est partagé entre ces 2 URL + dup content "toléré" par Google qui a l'habitude de ce genre de gaffe et qui donc en général ne sanctionne pas PR moindre = moindre profondeur de traitement => d'où mon attachement à vouloir faire cette régle ensuite coder en dur l'URL au lieu de index supprime toute la souplesse relative ! donc mon site sur mon serveur de dev ne sera jamais identique à celui en ligne d'où source d'erreurs et de bogue ! Pire, avec du PHP c'est carrément l'enfer Bref vu ton expérience sur OVH , si tu n'as pas toi de solution je ne vois pas qui pourrait en avoir une ! cela m'impose donc de garder un index.php en service et donc une perte en positionnement tant que ce site et quelques autres d'ailleurs sont chez OVH => je ne passerai plus une seule commande en hébergement à OVH et je vais même migrer mes sites ailleurs 1 par 1 dernier point : je ne suis pas d'accord avec toi mais peut être que nous avons raison tous les deux en effet : - le .htaccess est local donc : sousdomaine.monsite.com part directement sur le répertoire associé SANS regarder le .htaccess de / et là il y a lecture du .htaccess du sous domaine dans son répertoire => il n'y a pas de routage du index.php de ce sous domaine vers le / du domaine en tout cas chez Nuxit.net mais au vu des différences de réactions de .htacccess selon CHAQUE hébergeur, tu as peut être raison chez OVH (je ne compte pas vérifier vu que j'ai déjà bien assez d'ennuis avec leur gestion farfelue du .htaccess) Ce qui est à la fois drôle et regrettable mais bon that's life ... encore merci à suivre ....

Bonjour Google sur un blog officiel (celui de Matt Cutts) recommande aux SEO (nous donc) d'avoir une adresse de site "canonical" (voir blog de Matt Cutts ; mot clef = canonical) http://www.mattcutts.com/blog/seo-advice-u...nonicalization/ je cite le dico du net : http://www.dicodunet.com/definitions/refer...l-canonique.htm "L'adresse officielle d'une page web, celle qu'il est préférable d'utiliser pour accéder au contenu correspondant. Description de URL canonique Définir une URL canonique est la méthode adoptée par Google pour éviter les doublons dans les résultats de recherche et pour alléger le traitement des données. L'objectif est d'éviter de traiter séparément des adresses différentes correspondant, en fait, à la même page. La façon dont cette technique est mise en oeuvre actuellement fait intervenir le PageRank et éventuellement le type de redirection." chez OVH, c'est impossible ! J'explique RewriteEngine on # # route index.php vers [url="http://www.monsite.com"]http://www.monsite.com[/url] -- le ? apres le / empeche parasite QSA # ne marche pas sur OVH : conflit avec directindex index.php je suppose -- RewriteRule ^(.*)index\.php$ [url="http://www.monsite.com/"]http://www.monsite.com/[/url]? [R=301,L] dans .htaccess, cette règle qui fonctionne chez nuxit.net par exemple redirige toute demande de index.php vers http://www.monsite.com l'adresse canonique et unique est donc http://www.monsite.com mais je peux avoir des index.php beaucoup plus souple dans le code du site ainsi le code de mon serveur de devet du site sont identiques et maintenance facile chez OVH, j'ai une boucle infinie et au final une erreur de redirection avec message d'erreur : impossible ... je pense que index est rerouté sur le site ... qui se fait rerouter vers index avec une ré écriture d'URL par ovh je ne suis pas sur en tout nada comment faites vous de votre côté ? quelqu'un a t il rencontré le pb ? Merci J & J

Merci au milieu de la nuit j'ai compris que le problème venait de QSA et en cherchant j'ai trouvé via des forum et le mode d'emploi apache que pour bloquer QSA qui est d'office mis en service meme si on ne l'appelle pas, il faut le bloquer par un ? à la fin de la chaine de remplacement pour diverses raisons, je ne peux pas employer le redirect permanent - j'ai besoin des expressions régulières pour gérer les multiples URL à rediriger et en plus elles contiennent des caractères spéciaux donc ... exemple RewriteRule ^(.*)\.htm$ /accueil-intermediaire.php? [R=301,L] Le ? derriere le .php bloque l'arrivée de l'argument ID=4 etc. maintenant cela reste propre.

Bonsoir je me heurte à un probleme de .htaccess que je ne trouve documenté nul part voici le contexte je change d'hébergeur et en mêm temps je refonds mon site sur le nouvel espace, je mets un .htaccess qui va rerouter les anciennes pages vers les nouvelles un redirectmatch 301 permet de rediriger sur une expression reguliere ceci par exemple fonctionne RedirectMatch 301 /visuel_approche_globale_commerciale_et_marketing.htm /approche-globale-marketing-commerciale.php un outil de tracage de header HTTP me donne "HTTP/1.1 301 Moved Permanently etc. " bref, c OK MAis : RedirectMatch 301 ^/fiche_reference\.htm(.*)$ http://dev-ventes.nuxit.net/references.php donnent l'impression de fonctionner MAIS en fait à la fin il y a : .php?ID=2 (il y ajout de la fin de la chaine trouvée en expression régulière et l'outil de HTTP header donne le même resultat => Google va prendre en redirect 301 une URL inexistante ! je ne comprends pas pourquoi il y a greffe de ces 4 caractères ?ID=2 derrière le .php je suis preneur de toute idée svp car là je cale et je ne pige pas. Merci **EDIT Administrateur (TheRec)** Merci d'utiliser les BB Codes adéquats pour présenter ton code. Plus d'informations en cliquant sur "Aide BB Code" en dessous de la liste d'émoticons lors de la rédaction d'un message.

Personnellement j'utilise un logiciel de traduction (pas celui de Google !!!) puis je corrige puis je paye un étudiant pour qu'il relise et corrige je limite les couts et je sauve une grande partie de la qualité je ne fais que des phrases simples et courtes séparées par un point. cela allège le travail de l'étudiant, il bosse plus vite et mieux le logiciel arrive à mieux traduire

pour avoir été client de plusieurs de ces cyber supermarchés, le caddie est toujours nettement plus cher. Normal : - un gars parcourt un entrepot avec un caddie et le remplit à votre place - un autre met tout en carton - un 3ième livre coute plus cher que - un gars met en linéaire des tonnes de marchandises - vous remplissez vous même votre caddie - vous passez à la caisse - vous transférer vous même votre caddie dans le coffre

juste un probleme possible avec google analytics en confidentialité Google alloue PR et quelques bricoles intéressantes à un site sur la base d'algorithmes dont je ne débattrais pas ici. si ton site fait des choses qui ont une "tendance" à gruger Google, c clair que mettre le site en GG analytics n'est peut être pas la meilleure des choses pour vivre heureux , vivons caché (de Google ??) ouaff

Bonsoir, Aexae la société de gardiennage / sécurité ??