Aller au contenu

Cariboo

Membre+
  • Compteur de contenus

    3 370
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Cariboo

  1. Bonsoir à tous, Je publie ces jours-ci un article qui résume les découvertes que j'ai pu faire depuis quelques mois sur les méthodes de détection du link spam par les moteurs. Un grand nombre d'articles scientifiques sont parus depuis deux ans sur le sujet. A l'heure ou Google est entré officiellement en croisade (avec Matt Cutts dans le rôle du héraut) contre les manipulateurs de son pagerank, j'ai trouvé intéressant de faire le point sur les avancées dans ce domaine, et sur les conséquences à en tirer en matière de pratique de netlinking pour les mois, voire les années à venir. Comme l'article commençait à devenir très long, j'ai décidé de le découper en morceaux et de le publier sous forme de feuilleton Ce soir, premier épisode : La détection du link spam, un challenge pour les moteurs (première partie) Le deuxième épisode est pour dimanche : il y sera question de toute une série de ranks avec des noms rigolos (Spamrank, Badrank, Trustrank, Topical Trustrank, Truncated Pagerank etc...)
  2. Entité nommée

    Ah tiens ! J'avais oublié cet article ... lolodev>Tu peux préciser ta demande ?
  3. Varnish et Googlebot

    Sur les versions les plus courantes de Varnish, on fait ce que l'on appelle du "warming" de cache. On lance un script qui appelle les pages pour les charger dans le cache avant qu'un utilisateur ou un robot les demande. On utilise la fonctionnalité varnishreplay https://www.varnish-cache.org/docs/3.0/reference/varnishreplay.html Un article qui détaille comment faire : http://info.varnish-software.com/blog/warming-varnish-cache-varnishreplay
  4. Temps de téléchargement GSC

    Google n'a jamais communiqué sur ce qui était réellement compris dans le "download time", mais oui, c'est forcément le temps de téléchargement mesuré par un crawler, donc un time to last byte (le temps pour télécharger le code HTML) en excluant les temps de rendition dans le navigateur et probablement aussi certaines ressources comme les js/css externes. Dans la pratique, les temps communiqués par Google sont souvent plus faibles que ce que l'on mesure avec Screaming Frog : leur infrastructure est optimisée pour le crawl, ça se voit
  5. url canonique, multi-langues

    Il faut faire attention avec les canonical et les hreflang, car leurs objectifs sont diamétralement opposés. Dans ce cas particulier, il faut pointer OBLIGATOIREMENT vers l'url de destination de la balise canonical, car sinon, Google risque de traiter bizarrement ce cas. Mais le plus important, c'est de s'assurer que les liens dans les balises HREFLANG sont bien symétriques entre les différentes versions. Et la balise canonical n'est à placer que si la "traduction" de la page existe. Si elle n'existe pas, cela génère une erreur, et comme d'habitude, s'il y'a trop d'erreurs, Google risque de mal interpréter les hreflangs.
  6. Oui, les "reviews" influent sur le positionnement des pages Google My Business. Mais ce n'est que l'un des critères, il y'en a d'autres ! Et des critères plus impactants, comme le nombre de fois où un établissement est mentionné dans les annuaires. Et surtout, l'adresse physique du magasin, l'optimisation du NAP, des catégories etc... Pour les témoignages bidonnés : disons que la répression des fraudes est parfois plus efficace sur ce point que Google, à mon avis. Rappelons que c'est illégal. Quant à la qualité : c'est du contenu généré par les utilisateurs, donc personne ne s'attend à avoir de la qualité partout et tout le temps.
  7. Création Marketplace

    Monter une marketplace, c'est un gros chantier, je comprend que tu cherches quelque chose de tout prêt. La plupart des solutions évoquées plus haut sont plutôt des marketplaces pour gérer des ventes de produits, là tu es proche de la vente de services, tu risques donc d'avoir à adapter sérieusement les plateformes pour que ça te convienne. Et je suppose qu'il s'agit de clients récurrents, donc les besoins ce serait plutôt des fonctionnalités B2B que B2C. Je connais une solution pro : Mirakl B2B. http://www.mirakl.fr/marketplace-b2b/ Le périmètre fonctionnel me semble coller plus à tes besoins.
  8. Bonne année à tous !

    Meilleurs voeux 2016 à tous les membres !
  9. Bonjour à tous me revoilà !

    Bonjour Christophe Et bon retour parmi nous
  10. Me revoilà

    Un revenant ! Bienvenue Naelone
  11. Je me présente

    Bienvenue sur le Hub !
  12. Quel outil pour un e commerce

    Garde Prestashop. Au moins tu ne seras pas limité et avec un peu de travail tu auras exactement le site dont tu as besoin, et non celui qui a été pensé par un prestataire en solution SAS. Déjà, dans Prestashop, tu peux créer n'importe quelle valeur pour l'attribut "taille". Si la taille XXL n'existe pas déjà, il suffit de la créer. Voir l'aide ici : http://doc.prestashop.com/pages/viewpage.action?pageId=11272378#Ajouterdesproduitsetdescatégoriesdeproduits-Ajouterdesdéclinaisonsduproduit C'est expliqué dans la partie "méthode manuelle"
  13. Dans tous les cas, renvoyer autre chose que 503 dans un contexte d'indisponibilité est une mauvaise idée. Pour les autres urls : un renvoi massif de 503 diminue le rythme de crawl et de recrawl de Google, c'est ce que j'observe parfois. Mais pendant ce temps les autres urls restent indexées donc les effets de bord sont minimes (ne pas renvoyer 503 par contre, cela va engendrer beaucoup plus de problèmes) Attention, deux jours c'est déjà limite, il faut que tu réduises ton temps d'indispo au maximum. Au bout d'un certain temps (quelques jours, le délai précis est inconnu) Google va considérer que ta 503 doit être interprétée comme une 404. Tu trouveras les conseils de Google ici : https://googlewebmastercentral.blogspot.fr/2011/01/how-to-deal-with-planned-site-downtime.html Pour t'assurer que les bots interprètent bien ta 503, et pour éviter les effets de bord, il faut que tu penses bien à ajouter le champ header http:// retry after.
  14. code http 304 pour les robots

    Non ce n'est pas en coûteux en ressources. L'info sur la date de dernière modification est renvoyée au navigateur (ou au bot) dans le header http:// Avec des pages dynamiques générées avec un langage orienté serveur, on met à jour le champ Last Modified avec un bout de script. Ex de champs header pour gérer les champs de mise en cache en php : $fp = fopen($_SERVER["SCRIPT_FILENAME"], "r"); $etag = md5(serialize(fstat($fp))); fclose($fp); header("Cache-Control: must-revalidate"); header("Last-Modified: ".gmdate("D, d M Y H:i:s", $SelectS['timestamp'])." GMT"); header('Etag: '.$etag); header("Expires: -1"); A chaque fois que le script est appelé, le bon champ last modified est généré. Evidemment, si la page ne change pas vraiment à chaque fois, il faut utiliser un script adapté. La fonction MD5 sert pour créer un etag unique pour une version de page, ce qui permet de piloter une autre fonction de cache ;-)
  15. code http 304 pour les robots

    En fait, le code 304 n'est renvoyé que si le navigateur envoie une requête http:// dite "conditionnelle" au serveur web. Inutile de se préoccuper des robots vs utilisateurs, cela fonctionne tout seul. Ce que fait Googlebot, c'est d'envoyer régulièrement des requêtes conditionnelles en appelant le champ "if modified since". Si le serveur répond que la page n'a pas changé, il passe son chemin et réessaie plus tard. Si la page a changé, Googlebot téléchargera la page complète. Supporter les requêtes conditionnelles pour un serveur web diminue beaucoup la charge du serveur causée par les bots, et favorise l'exploration du site. La requête du bot ressemble à ça : GET /index.html HTTP/1.0 User-Agent: Mozilla/5.0 From: something.somewhere.net Accept: text/html,text/plain,application/* Host: www.example.com If-Modified-Since: Wed, 19 Oct 2005 10:50:00 GMT Si la page répond 304, alors le bot sait que la page n'a pas été modifiée. Et s'il répond 200, elle a été modifiée, et la nouvelle page est tout bonnement téléchargée. Nota Bene : un reverse proxy style Varnish est paramétré pour gérer les 304 par défaut.
  16. Thin affiliate

    Il ne s'agit pas d'une mise à jour, mais de plusieurs mises à jour, qui ont été détectées avant l'apparition de Penguin, toujours au moment du lancement de la saison de Noël : entre le 15 novembre et le 20 décembre. Ces mises à jour n'ont jamais été officialisées par Google. Elles étaient caractérisées par un chamboulement des pages de résultat sur des requêtes marchandes, avec un nettoyage massif des thin affiliates, c'est pour cela que l'on a parlé de mises à jour "thin affiliates". A mon avis c'est une dénomination assez abusive, car ces changements d'algorithmes ne ciblaient pas QUE les thin affiliates. En réalité, Google semble tout bonnement mettre à jour son algorithme pour améliorer ses résultats en vue de la peak season, en une ou plusieurs fois, cela semble un pattern récurrent depuis plusieurs années maintenant (cf les mises à jour de l'année dernière). Ces mises à jour de fin d'année ont toujours un volet "spécial requêtes marchandes" comme la phantom update du 17 novembre dernier. Dans la pratique ces mises à jour ont des caractéristiques différentes année après année. Il y'a aussi apparemment un filtre algorithmique qui semble attaquer spécifiquement les sites de type "thin affiliates" (déjà vu à l'oeuvre plusieurs fois). Les "thin affiliates" sont des sites d'affiliation sans valeur ajoutée, dont le modèle consiste à capter du trafic SEO pour le revendre aux affiliants. Reconnaître ces sites faisait l'objet d'une partie des anciens guides du quality rater (pas du dernier, je ne sais pas pourquoi).
  17. Demat deoc'h !

    Bienvenue sur ce forum ! :-)
  18. Je donne une astuce testée sur pas mal de plateformes pour régler le pb du crawl des facettes. La façon 100% efficace d'empêcher le crawl d'urls, c'est d'utiliser le fichier robots.txt. Mais au départ on ne peut pas, parce que tantôt la syntaxe correspond à une url que l'on veut voir crawler et indexée, tantôt à une syntaxe que l'on veut bloquer... La solution c'est d'utiliser deux syntaxes d'urls selon les cas : - la syntaxe que l'on veut bloquer. En général c'est la syntaxe brute, genre url technique http://www.domaine.com/search.asp?cat=123&sku=458&taille=44 et on bloque tout se ce qui commence par search... - la syntaxe que l'on veut voir crawler et indexer : et pour cela on réécrit l'url : http://www.domaine.com/r/search.asp?cat=123&sku=458&taille=44mais on peut aussi en profiter pour avoir une url plus "pretty" A chaque fois que l'on affiche sur le site un lien que l'on veut voir crawler et indexer : on le présente avec la syntaxe réécrite. Pour les autres cas : la syntaxe brute. Et hop le tour est joué. C'est compatible avec l'astuce de captain_torche (qui est aussi une vraie bonne pratique que je recommande) : pour accéder aux pages filtrées, tu auras deux chemins : - le formulaire qui te fait atterrir sur la syntaxe brute. Comme cela, si un petit malin copie colle l'url de ta page filtrée par facettes sur un autre site, et Google découvre l'url, Google ne crawlera toujours pas cette syntaxe - les liens en dur présents dans la navigation (menus, suggestions etc...) qui utilisent la syntaxe réécrite Et pour info : le message sur le nombre anormalement élevé d'urls est bien lié aux urls crawlables, découvertes sur le site, et n'a rien à voir avec l'indexation.
  19. Tu as raison de me corriger, mais "rendition" est hélas le terme de jargon inventé pour traduire "rendering"... On a aussi des "temps de rendition" (rendering times), des "serveurs de rendition" Grrr... Franglais, quand tu nous tiens. Comme toi j'aime pas trop le terme, c'est pour cela que je l'ai placé entre guillemets.
  20. Contenu Ajax indexé

    La méthode recommandée par Google à présent n'est plus d'utiliser les hashbangs ("#!" se lit "hash bang" en anglais) mais la méthode pushstate en HTML5. C'est plus facile à implémenter. Mais la méthode des hashbangs continue de fonctionner jusqu'à plus ample informé. C'est juste que Gary Illyes et John Mueller (l'équipe de Google basé à Zurich) ne sont pas fans des hashbangs. Il faut dire que c'est bien lourdingue comme méthode.
  21. Petipoiver

    Bienvenue sur le Hub PPV
  22. Google sait générer une "rendition" de la page en appliquant les CSS et en executant les javascripts, donc il sait ce que le webmaster montre par défaut (et aussi ce qu'il masque). Cela fait un moment qu'on les soupçonne de traiter les contenus masqués par défaut de manière subtilement différente (en ne leur donnant pas le même poids). Là, John Mueller a juste confirmé que Google avait peut être récemment été un peu plus loin, en allant jusqu'à écarter le contenu masqué (en ne l'indexant plus). Est-ce sytématique ? Pas du tout, les tests montrent le contraire. Est-ce même fréquent : pas du tout. En général, le contenu reste indexé. J'ai l'impression qu'il faut un autre facteur pour que le contenu masqué ne soit pas indexé. Lequel ? Mystère, on n'a pas encore trouvé... mais on cherche ;-)
  23. Google, d'après Zineb, a déployé en France son algorithme Pigeon (celui qui a chamboulé les résultats locaux aux US en juin 2014 et dans les pays anglophones en déc 2014). Cela date d'il y'a quelques jours. J'avais analysé la mise à jour en juillet aux US, et elle a eu un sérieux impact dans certaines niches. En France... Je ne sais pas. Pour mes clients pour lesquels le référencement local est important, l'impact est peu évident. Et pour vous. Vous avez vu quelque chose ?
  24. Pour info ce n'est pas Google qui a appelé cette mise à jour Pigeon. Mais le site Searchengineland.com. En france, Pigeon c'est pas super positif comme nom. D'ailleurs Gary Illyes de Google a récemment officiellement demandé à ses boss de communiquer sur les "vrais" noms des updates utilisés en interne. Il a pas trop apprécié le nom "mobilegeddon" pour l'update du 21 avril. Par contre il n'a toujours pas eu l'autorisation de le faire... Il a clairement indiqué que ce délai provenait d'un problème de bureaucratie chez Google.
  25. En fait, ouvrir un autre compte n'est pas si simple car : - soit on veut que l'argent soit toujours versé au même endroit, et dans ce cas, Google fait le rapprochement (en identifiant l'adresse, le mail, le compte bancaire, la société, l'ip du demandeur...) et le nouveau compte va être tout aussi blacklisté (d'ailleurs c'est simple : on n'arrive pas à obtenir sa validation) - soit on passe par un compte tiers très différent, mais évidemment c'est beaucoup plus compliqué de récupérer l'argent Sinon Arlette, le terme "négociation" n'est peut être pas approprié. On peut au mieux demander la réouverture du compte une fois que l'on a identifié l'origine du problème (pas toujours évident). Négocier suppose un niveau de dialogue que les échanges de mail avec les équipes d'Adsense atteignent rarement. Déjà il faut passer la barrière des mails automatiques, et les réponses sont tellement "le réglement c'est le réglement" que ça vire en général au dialogue de sourds.
×