Aller au contenu

Jan

Hubmaster
  • Compteur de contenus

    2 304
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Jan

  1. Justement Le Juge, c'est cette différence de résultats en fonction de l'IP du client que je n'ai jamais constatée. Certes Google.com va rediriger vers Google "Français" les utilisateurs qui ont une IP en France, et inclure dans leurs requêtes le paramètre hl=fr. En revanche, en spécifiant hl=en (qui est la valeur par défaut utilisée par Google pour servir les internautes US) Google.com m'a toujours montré les même résultats depuis la France et depuis les US (pour un même datacenter bien évidemment). Bref d'après moi, google.com fait de la "géo-redirection", et pas du "géo-cloaking". La spécificité de ce que voit un Français par rapport à un américain tient au fait que Google.com lui sert les résultats de Google.fr. Et dans ce cas, oui, les sites hébergés en France bénéficient d'un "bonus". Mais ceci n'arrive évidemment jamais aux internautes US (cible de Nicolas). As-tu une expérience différente?
  2. Ma (petite) expérience avec le référencement ciblé US me porte à penser que la localisation du serveur n'a aucune importance sur Google aux US. Les américains utilisent google.com, qui contrairement à google.fr pour la France ou google.co.uk pour le Royaume Uni n'est pas un google local pour les US, mais google international. Il n'y a donc pas de prime à l'hébergement aux US. A partir du moment où ton site est en anglais, même hébergé en France, c'est bon. En revanche si tu vises aussi le Royaume Uni avec ce site, un hébergement (ou une IP) UK (ou un domaine en co.uk) sont un bonus sur Google.co.uk (encore une fois sans être un handicap pour sortir sur les requêtes faites des US). Ca me parait donc être le meilleur choix. Il semble en aller différemment sur Yahoo et Live. Donc si tu te soucies de ces moteurs (Y! n'est pas négligeable aux US), un hébergement US pourrait constituer un bon investissement (à confirmer quand même).
  3. Après ton premier if..else qui lit le cookie, la langue est stockée dans la variable $lang. C'est donc cette variable $lang qu'il faut tester dans ton deuxième if..else, et non plus $_GET['lang'], qui n'est pas le cookie mais la variable passée dans l'url
  4. Bonjour, Dans ses pages de résultats, Google propose en général une Version HTML des fichiers pdf indexés (par le lien "Version HTML" sous le titre du document). Pourtant cette version HTML n'est pas proposée pour tous les pdf. Exemple: pas de version HTML pour le 8ème document (-web.princeton.edu/sites/ogc/Tax2006/061040.pdf) sur cette requête: http://www.google.com/search?q=form+1040+f...G=Google+Search Y-at'il un encodage ou une configuration particulière à mettre dans les documents pdf pour éviter que Google n'en propose une version html?
  5. Le PR auquel nous, simples mortels , avons accès est celui de la toolbar. Il n'est mis à jour par Google qu'épisodiquement (tous les 3 mois environ). Une page non indexée et qui affiche pourtant un PR a de très grande chances d'avoir été indexée, d'avoir obtenu un PR... puis d'avoir été désindexée. La prochaine mise à jour du PR devrait reflèter cet état (PR=0).
  6. Il serait intéressant que tu précises un peu la technique que tu comptes mettre en place. La solution ne me semble pas si simple. Si tu te contentes de rediriger sur la base de la langue du HTTP ACCEPT, l'accès aux autres langues sera impossible pour tes visiteurs (et les robots). Puisque tu veux qu'il soit possible pour un visiteur déjà présent sur le site, il faut y adjoindre une autre condition: - le referer (mais ce n'est pas fiable à 100%) - un cookie (mais ce n'est pas fiable à 100%) - ou une variable passée par POST lors du clic sur un drapeau Malheureusement, Googlebot visite sans referer, n'accepte pas les cookies, et ne valide pas les formulaires. J'ai donc tendance à penser que dans ton cas, il faut traiter les robots des moteurs de recherche différemment des visiteurs humains. Ce qui nécessite de les identifier (sur leur user-agent ou leur adresse IP). Ensuite: Si c'est un robot => on ne redirige pas, et le bot peut tout indexer grâce aux liens internes du site Sinon (c'est un humain) => on redirige en fonction du langage si le visiteur arrive sur le site
  7. Une mise à jour des backlinks est en cours sur http://72.14.207.101/ Pas encore visible sur les datacenters de l'outil du Hub, mais ça ne saurait tarder
  8. C'est effectivement ce que je commencerais par faire. Subsiste ensuite le problème de fond: comment faire référencer des pages au contenu dupliqué? Il faudrait sans doute essayer d'ajouter une part de contenu original dans ces pages. Quelques pistes: un résumé ou commentaire que tu pourrais ajouter sur chacun des articles agrégés, ou encore ouvrir tes pages aux commentaires des visiteurs de ton site.
  9. Bonjour, Ton site est indexé par Google, mais souffre d'un gros problème: toutes tes pages, sauf une, sont dans l'index complémentaire (vois la mention "Résultat complémentaire" à côté de l'URL dans les pages de résultats de Google): http://www.google.fr/search?hl=fr&rlz=...rcher&meta= Dans ces conditions, elles n'ont aucune visibilité dans Google. Le trafic généré par Google sur le site est sans doute proche de zéro. Ton site est victime de ce problème "par construction", dans son principe même. Le contenu dupliqué est le plus sûr moyen d'envoyer un site dans cet enfer qu'est l'index complémentaire Bien sûr il y a des exceptions (l'exemple de skippy?). Avec un site un peu ancien, puissamment backlinké, on peut s'en sortir (et sortir dans google) avec du contenu dupliqué. Le principe est que c'est le plus fort qui "tue" les autres. Si ton site est suffisamment puissant, c'est lui qui peut sortir dans google au détriment des sites auxquels il a piqué le contenu (c'est ailleurs une technique de déréférencement des concurrents très classique). Comme le dit skippy, ton problème est sans doute agravé par les sous domaines: au lieu d'avoir un site avec beaucoup de pages, google considère que tu as plusieurs sites avec peu de pages, donc peu puissants. Tu mentionnes l'existence d'un sitemap. Ces sitemap xml sont à mon avis le plus gros piège tendu par google aux webmasters. Une page doit être indexable naturellement par ses backlinks. "Forcer" l'indexation de pages trop faiblement linkées par un sitemap est le meilleur moyen de les envoyer direct dans l'index complémentaire (manque de "PR juice" comme disent les anglo saxons). En plus ce sitemap gêne au diagnostic de ton site. Tes pages ont-elles été indexées naturellement ou seulement grace au sitemap? Impossible à dire a priori. La première chose à faire sur ton site amha: le sitemap => à la poubelle Dernier point sur ta page d'accueil: tu as créé toi même un contenu dupliqué entre le www et l'url sans www: http://www.google.fr/search?q=%22Bienvenue...29&filter=0 Résultat: les 2 sont dans l'index complémentaire. A corriger par une redirection 301 de l'une vers l'autre.
  10. Personnellement j'irais mollo dans les changements. Le risque de perdre les positions sur les mots-clés que tu cites me parait réel en cas de refonte profonde. Ceci dit si ton client veut développer le trafic de son site à terme, et se positionner sur de nouveaux mots-clés, c'est sans doute une étape indispensable. Mais il faut qu'il soit prêt à encaisser une chute pendant quelques semaines. C'est vrai que le site est une frame, mais la noframe a du contenu
  11. Merci pour ta réponse utilisabilisation mais mon problème vient du fait que c'est une page d'Amazon que je veux inclure, et non une page que je maitrise. Comme l'explique l'article que tu cites sur Alsa, on l'inclut par <object>. Mais pour cacher les scrollbars, il faut appliquer une CSS à la page incluse. Et là ça coince
  12. Bonjour, je cherche à intégrer une bannière Amazon dans une page xhtml strict. Problème, le code fourni par amazon est une <iframe>, et donc non valide. Connaissez-vous une solution pour intégrer cette pub amazon sans <iframe>? Merci.
  13. Personnellement, je ne suis pas de règle absolue en la matière. Tout dépend du site, de son ancienneté, de sa popularité, de sa taille et de la richesse du contenu des pages. Le branding peut être une bonne raison pour inclure le nom du site dans les titres. En revanche, pour un site récent, peu populaire en terme de backlinks et au contenu un peu faible, je vois un risque à utiliser systématiquement un titre du type "monsite.com: mots clés". Cette structure accentue la similarité des pages à faible contenu et peut, ou pourrait dans un avenir proche, déclencher des pénalités pour "signe extérieur de spamdexing" (ce type de titres est fréquent dans les sites générés automatiquement). Pour un "petit" site (ou un MFA) qui n'ontient aucun backlink naturel, je suis donc adepte de titres du type "expression clé" qui permet d'obtenir du trafic des moteurs sans aucun effort de référencement ou presque, en visant comme "expression clé" non pas les mots-clés les plus convoités, mais leurs dérivés de "la longue traine". En revanche, pour un site riche en contenu et populaire (comme par exemple le Hub) aucun souci avec les titres du type "monsite.com: mots clés". D'ailleurs ce genre de site parviendrait même à se positionner sans que la balise title soit renseignée
  14. La page: http://autos.yahoo.com/used-cars/forsale.html En cache de Google: http://72.14.209.104/search?q=cache:autos....rs/forsale.html Ils forcent légèrement sur le mot-clé "used cars" Il s'agit de cloaking sur user agent visible en "empruntant" les UAs des bots des principaux moteurs dans votre navigateur: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp) msnbot/1.0 (+http://search.msn.com/msnbot.htm) Je poste ici plutôt qu'en public, pour ne pas montrer du doigt
  15. Sandbox ou pas, quel que soit le nom qu'on leur donne, les pénalités pour "signes extérieurs de suroptimisation" existent, et peuvent toucher des sites anciens. Pour affiner un peu la compréhension de ce qui se passe pour ces sites, il serait intéressant de savoir s'ils ont chuté sur plusieurs mots-clés ou un seul, et de combien de places est cette chute (-30? -950? autre?)
  16. Bonjour, La solution n°1 me semble la meilleure, pour les raisons que tu invoques. En août, tu auras ainsi un NDD déjà "rôdé". L'indexation du contenu important sera alors plus facile, surtout si les backlinks sont au rendez-vous.
  17. Pour l'anecdote, visible sur 64.233.161.104 A suivre sur l'outil du Hub...
  18. En même temps, il faut se mettre à leur place. Quand on a un tel succès dans Google, c'est tentant de rentabiliser D'autant qu'un tel trafic coute cher à wikipédia en bande passante et que beaucoup d'utilisateurs du wiki se déclarent prêts à payer. L'embauche de Matt Cutts annonce sans aucun doute un tournant dans le modèle économique de wikipédia.
  19. Apparemment, payer deviendra une possibilité pour obtenir un lien sans "nofollow" sur wikipédia". Kewwwwl
  20. Ce qui devait arriver est arrivé. Quand Matt Cutts a annoncé qu'il allait s'attaquer au spamdexing, ça a forcément énervé la darkseoteam. Quand la sandbox est apparue, le darkseoteam s'est rebellée en déréférençant le blog de Matt. Mais quand Matt, à force d'intox, a fini par réussir à faire croire à (presque) tout le monde que le contenu était roi, qu'il fallait faire des pages pertinentes et originales, bref, qu'il fallait vraiment bosser pour truster les premières places de google, la coupe était pleine. La darkseoteam ne pouvait que réagir face à un tel mensonge et ce petit "défaçage de chetron" n'est que la manifestation d'une sanction bien méritée. Maintenant qui sera le plus fort dans cette lutte sans merci? La réponse est incertaine. Il se dit que MattCutts s'apprêterait à quitter Google pour Wikipédia, qui est à la recherche d'un "business model" visant à rendre son contenu payant (c'est pour cet été). Matt Cutts est certainement l'homme de la situation. Mais alors quid de Google et de sa spam team laissée à l'abandon? Il se dit qu'un français serait justement en lice pour le remplacer. Son identité est gardée secrète, mais certains noms circulent déjà... Vous voyez tous certainement à qui tout le monde pense
  21. A priori rien ne permet de distinguer Analytics d'un vrai crawl de Googlebot (même user agent, même IP). Je ne vois pas de solution pour l'instant... mais je cherche
  22. Ton site me semble déjà pas mal optimisé. 3 petits détails quand même: - Grace aux CSS tu pourrais faire en sorte que le contenu original de chaque page soit au dessus du code du menu (répété dans toutes les pages) dans le code source. - Les liens de retour vers ta page d'accueil renvoient vers index.php. Il vaudrait mieux qu'ils renvoient vers / - Le texte des liens de retour vers ta home sont intitulés "home" ou "accueil". Pourquoi ne pas les intituler "Guadeloupe"?
  23. Bravo arnoweb2! Il va falloir améliorer les scripts de cloaking pour corriger cette faille via analytic rico, il y a au moins une autre bonne raison d'utiliser le cloaking: éviter de se faire voler son contenu. Le "duplicate content" peut faire des ravages sur le référencement d'un site. Et les "scrappers" sont légion ces temps-ci
  24. Je vois un risque d'injection de code dans ton script. Il n'empêche pas, a priori, de faire appel à un script hébergé sur un autre domaine: <a href="mondomaine/mapage.php?monjs=http://siteattaquant.com/scriptmalicieux">attaque</a> Si j'héberge scriptmalicieux.js sur siteattaquant.com, je peux m'amuser un peu avec ta page Il me semblerait prudent que ton php interdise l'appel à des scripts externes.
×
×
  • Créer...