Jump to content

Cariboo

Membre+
  • Content Count

    3370
  • Joined

  • Last visited

Everything posted by Cariboo

  1. Ah tiens ! J'avais oublié cet article ... lolodev>Tu peux préciser ta demande ?
  2. 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
  3. 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
  4. 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'err
  5. 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
  6. 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
  7. Meilleurs voeux 2016 à tous les membres !
  8. 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"
  9. 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
  10. 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['timest
  11. 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 l
  12. 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 th
  13. 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 bl
  14. 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.
  15. 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.
  16. 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é
  17. 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.
  18. 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 demand
  19. Bon, décidément, c'était un Pigeon "light" ! Oui PieceMobile, le prochain Panda risque de faire plus de dégâts (ou de faire sortir des sites du purgatoire).
  20. Back to the future ;-)

×
×
  • Create New...