Aller au contenu

Jeanluc

Membre+
  • Compteur de contenus

    2 003
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Jeanluc

  1. Bonjour advicar, Tu fais allinurl: tv et tu as la réponse. Aucun .tv dans ces 100 pages! .tv identifie un pays (Tuvalu). Google ne semble pas tenir compte de ce que cette extension est principalement utilisée pour des sites concernant la télévision. Donc, pour le référencement, choisir .tv n'est pas équivalent à .com. Jean-Luc
  2. Une question de patience peut-être ? Maintenant site: donne déjà 36 pages. Jean-Luc
  3. Bonjour steph13, Tu pourrais préciser de quel site tu parles ? Jean-Luc
  4. Bonjour skale, Oui, Mylinea utilise un système qui bloque provisoirement le référencement après 20 (?) inscriptions. Si tu réessaies dans quelques heures, tu pourras continuer. Jean-Luc
  5. Mille mercis pour ta réponse, Xavier. Sur ma page originale, j'avais <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> mais ce n'était pas suffisant pour Firefox (ça marchait avec Opera et Internet Explorer). Avec la solution que tu as donnée, c'est impec partout. Heureusement que tu étais là. Jean-Luc
  6. Comme tu le dis, le contenu de TD n'hérite pas de BODY et c'est pareil avec mes 3 browsers. J'ai constaté aussi que, si j'associe "font-size" à TABLE, les TD juste en-dessous en héritent, mais ceux qui sont à l'intérieur d'une TABLE imbriquée n'en héritent pas. Quelqu'un pourrait-il expliquer les particularités de "font-size" et, si possible, un moyen de contourner le problème, sans répéter des "font-size" un peu partout ? Jean-Luc
  7. Bonjour, J'ai presque honte de poser une question qui me semble si basique. J'essaie de définir une taille de police (font-size) pour une page entière en l'associant à la balise "body", mais ça ne marche pas. Le "font-family" que je place à côté marche sans problème. Où est l'astuce ? Exemple : <html> <head> </head> <body style="font-size: 36px;font-family: Arial;"> <table><tr><td> Pourquoi si petit ? </td></tr></table> </body> </html> Le texte apparaît bien en "Arial", mais pas dans la taille demandée. Dois-je conclure que "font-size" n'est pas héritable ? Y a-t-il une astuce ? Jean-Luc
  8. Bonjour chon, Il y a de gros problèmes avec la structure de ta page : <html><head> (...) </head> <body link="#CC0033"> <div class="adsky"> (...) </div> <div class="haut3" align="center"> (...) </div> <div class="frame"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <body> <head> (...) </head> </body> </html> </div> <div class="bas" align="center"> (...) </div> </ul> </body> </html> Il est impossible de prévoir ce qu'un robot ou un browser va faire d'un code aussi mal structuré. Pour les "include", Google et les autres robots lisent ta page [i]http://www.jeuxgratuits.org/index.php?page=partenariat comme n'importe quel navigateur. Ils ne voient donc pas que, pour construire cette page, tu fais appel à [i]http://www.jeuxgratuits.org/partenariat.html, mais ils voient bien le contenu complet de la page (y compris les parties provenant des "include". [edit] Voir l'explication de cbastien un peu plus loin.[/edit] Jean-Luc
  9. J'ai utilisé Netscape, j'ai utilisé Internet Explorer, puis je suis passé à Opera version 7 (avec la pub pas gênante). C'était génial et beaucoup plus stable. C'est vrai que maintenant Firefox a repris une partie des caractéristiques originales d'Opera, mais je ne suis pas convaincu par la stabilité, ni la sécurité de Firefox. Je viens d'upgrader en version 8 et de faire la demande du code d'activation gratuit sur http://my.opera.com/community/party/reg.dml et je me suis enregistré directement. Les pubs ont disparu. Encore mieux! Jean-Luc Opera
  10. Vos expériences me semblent confirmer que vouloir bloquer ces accès n'est pas la bonne solution, car : - inefficace contre les spammeurs; - diminuant les performances du serveur (car chaque accès de n'importe quel internaute exécute les tests du .htaccess). Par rapport aux nombre total d'accès à nos sites, ils ne représentent qu'une proportion négligeable, si nous ne publions pas nos referrers. Si cela vous ennuie de les trouver dans vos stats, vous pouvez probablement les filtrer à ce niveau-là. Mais, à mon avis, le mieux est de "feindre l'indifférence". Ils ne spamment jamais longtemps et il en vient toujours de nouveaux. Jean-Luc
  11. Non. Cela n'a rien à voir. A ce sujet, voir http://help.yahoo.com/help/us/ysearch/slurp/slurp-11.html où Yahoo explique très bien une manière intelligente pour un moteur de traiter les redirections et d'éviter tout problème de soit-disant détournement de page. Quand Google sera devenu un peu moins dogmatique sur le sujet, le problème disparaitra instantanément. L'avantage des liens absolus pour Google est un gain de temps, car on supprime la tâche assez lourde ( x 8 milliards) de traduction du lien relatif en lien absolu. Avantage annexe non négligeable, on supprime des risques de boucles sans fin pour certains sites dynamiques mal codés. Oui, ça existe... Jean-Luc
  12. Ça économise les serveurs de Google. Comme disait je-ne-sais plus-qui, bientôt il faudra crawler le site à leur place... Jean-Luc
  13. Bonjour, Utiliser le .htaccess pour lutter contre les référants pirates n'est pas LA bonne solution. En supprimant l'accès public à la liste des référants, tu supprimes 90% de la motivation des pirates. Il est impossible de tenir à jour une liste de référants pirates et allonger le .htaccess nuit aux performances de ton site, bien plus que les quelques accès des référants pirates eux-mêmes qui ne consomment guère de ressources (1 seul hit, comme le dit Dudu). Jean-Luc
  14. En fait, je constate le problème sur deux sites chez cet hébergeur (les 2 sites sont sur des machines différentes). Donc rien à voir avec l'un ou l'autre de mes scripts. Je soupçonne plutôt une config mal faite ou peut-être un bug Apache. Normalement, ces 25 erreurs 404 en 4 jours seraient sans importance, mais j'ai peur qu'elles nuisent au référencement de ces sites. Jean-Luc P.S. tout le monde dit que PHP est mieux, plus rapide et tout et tout, et pourtant... Perl me convient toujours très bien.
  15. @kimberlyclarko : j'ai déjà une règle dans le .htaccess qui fait une redirection 301 sur tout ce qui n'est pas destiné à www.mon-domaine.com. Au départ, c'était pour éviter les accès via mon-domaine.com (sans www). Les accès erronés de Googlebot (404) sont tous précédés d'une redirection 301. @Anonymus : je dis seulement que le problème ne se présente que pour les accès de Googlebot et Mediapartners (25 fois ces 4 derniers jours), mais je pense que c'est probablement provoqué par une configuration inhabituelle ou mal faite du serveur. Mon .htaccess contient RewriteCond %{HTTP_HOST} !^www.mon-domaine.com$ RewriteRule ^(.*) http://www.mon-domaine.com/$1 [QSA,L,R=301] Il semble que, dans certains cas, quand le visiteur est un robot de Google, mon .htaccess récupère des URL d'autres domaines virtuels du même serveur. J'ai vérifié plusieurs de ces URL et elles appartiennent à des sites différents et n'ont rien de particulier ou suspect. Jean-Luc
  16. Même pas possible... Ce sont chaque jour des URL différentes. Cela va des sites éducatifs aux sites de q. Jean-Luc
  17. Bonjour stecova, Le fichier robots.txt s'adresse aux robots qui visitent le site. Son contenu doit donc présenter les répertoires comme les voient les visiteurs du site. Dans ton cas, je suppose que Disallow: /repertoire/ devrait faire l'affaire. Il vaut mieux ajouter un "/" à la fin du nom du répertoire. Jean-Luc
  18. Bonjour, Sur un site en hébergement mutualisé, Googlebot s'acharne à rechercher des fichiers qui n'existent pas sur mon site. J'ai constaté que ces fichiers existent dans d'autres domaines virtuels à la même adresse IP. Par exemple, Google recherche /machin.php?alpha=35 sur mon site. Ceci entraîne une erreur 404. Par contre, cette adresse existe bien sur un autre domaine hébergé à la même adresse. Le problème se présente quotidiennement et les confusions se font avec plusieurs adresses appartenant à plusieurs domaines virtuels différents. Ce qui est remarquable, c'est que seuls Googlebot et le robot Mediapartners souffrent de ce problème. MSNbot et Yahoo Slurp qui sont aussi très présents n'ont pas ce problème. Conséquences : - il arrive que Google place des pages de ces autres domaines virtuels dans les résultats de la commande site: avec le nom de mon site; - Google risque de dégrader mon site pour un nombre excessif d'erreurs 404. Google dit que c'est la faute à l'hébergeur, sans plus de précision. L'hébergeur dit qu'il ne voit pas ce qui cloche. Ceci pourrait vouloir dire que le problème ne se présente que quand un visiteur (robot) fait une série d'accès très rapides à deux domaines virtuels différents... Mais j'imagine que le serveur web doit pouvoir gérer cela, non ? Que faire ? Jean-Luc
  19. Bonjour ams51, C'est vrai aussi sur Google. Qu'est-ce qui te fait douter ? Jean-Luc
  20. Dans le même ordre d'idée, sur http://www.webworkshop.net/seoforum/viewtopic.php?t=7021 , ils signalent d'autres résultats très inhabituels : http://www.google.com/search?hl=en&q=on+de...G=Google+Search (voir la partie Comcast). A première vue, je me demandais si c'était une pub... Cela semble plutôt être un "cluster de 3 résultats". En tout cas, ça limite fortement le nombre de sites présents en première page. Jean-Luc
  21. Salut Magicoyo, La libre circulation des biens est une des bases de l'Union Européenne. Refuser de vendre à un client simplement parce qu'il est dans un autre pays de l'Union est certainement illégal. Comme l'a très bien dit Cariboo, si tu refuses une commande pour des raisons économiques, il n'y a pas de problème. En somme, il suffit d'adopter un langage politiquement correct... Jean-Luc
  22. D'accord avec l'utilité d'un filtre anti-duplicate, mais, dans ce cas, ce qui n'est pas logique, c'est de quand même lister l'adresse de la page. Après tout, si cette page est sans intérêt ou nuisible, il n'y a même pas de quoi conserver l'URL dans les résultats. Google m'étonnera toujours... Jean-Luc
  23. Pas tout à fait d'accord. D'habitude, les pages que Google ne liste que par leurs URL sont les pages du site qu'il n'a pas encore visitées. Comme il n'en connaît pas encore le contenu, il peut seulement en lister l'URL. Cela pourrait aussi être le cas des pages dont on interdit la mise en cache du contenu (cas rare). Les pages "duplicate" sont (à mon avis) les pages qui sont accessibles via In order to show you the most relevant results, we have omitted some entries very similar to the 75 already displayed. If you like, you can repeat the search with the omitted results included. ou Pour limiter les résultats aux pages les plus pertinentes (total : 75), Google a ignoré certaines pages à contenu similaire. Si vous le souhaitez, vous pouvez relancer la recherche en incluant les pages ignorées. en bas de la dernière page de résultats. Mais tout ceci ne change rien à tes conclusions. Les titres, contenus et descriptions doivent être les plus diversifiés possible. Jean-Luc
  24. Bonjour cindy, A mon humble avis, cette balise ne sert à rien. Tu écris "elle n'est pas compatible avec tous les moteurs". J'irais plus loin. Je dirais que, s'il existe un moteur qui en tient compte, j'aimerais savoir lequel. Il faudrait aussi s'entendre sur le sens à donner à cette balise. La balise veut-elle dire "demande de visiter au moins une fois tous les 10 jours" ou "interdiction de visiter plus d'une fois tous les 10 jours" ? Encore une chose : éviter les petites fréquences n'est certainement pas souhaitable dans tous les cas. Jean-Luc
  25. Je l'écrirais "clermont-l-herault.php" ou plutôt "clermont-l-herault.html". L'URL "clermont-l-herault.html" serait convertie par url rewriting en "ville.php?code=clermont-l-herault". Ensuite, le programme "ville.php" va lire une table où il voit que "clermont-l-herault" correspond à "Clermont-l'Hérault". Yes ? Jean-Luc
×
×
  • Créer...