Aller au contenu

Cariboo

Membre+
  • Compteur de contenus

    3 376
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Cariboo

  1. Le risque est important de recevoir une action manuelle. Ce n'est pas un "blacklistage" à proprement parler, le blacklistage n'existe qu'en cas de pénalité "pure spam" et pour se la prendre cette pénalité il faut violer les guidelines sérieusement et spammer Google comme un sagouin. Pour sortir d'une action manuelle, il faut passer par une demande de réinclusion ce qui suppose de justifier aux yeux de Google qu'on a fait des efforts pour faire le ménage dans les liens manipulés, et désavouer les liens manipulés restants. Le process est long et délicat, en général les webmasters ne réussissent pas à faire lever l'action manuelle du premier coup et on perd des plumes en référencement même après la levée de la sanction. Par ailleurs, les liens créés sont probablement annulés automatiquement par Google. Ce qui signifie que le rapport qualité prix de ce type de logiciels n'est peut-être pas si bon que cela...
  2. Ok, donc le site est bien sorti du purgatoire... Je ne pense pas que tes 13 urls en erreur 500 suffisent à provoquer ton trou d'air de visibilité. Après cela mérite d'être corrigé. Mes outils ne m'indiquent aucun backlink pour ton site. La première des choses à faire pour regagner la première page c'est d'obtenir des backlinks pointant vers ton site ASAP. Là j'ai l'impression que les quelques liens que vous aviez ont disparu du net.
  3. Bonjour, Je suis allé voir rapidement : certaines des pages piratées sont encore dans l'index de Google. As-tu vérifié le statut de ton site dans l'onglet "sécurité et actions manuelles" de la Google Search Console ? Peux-tu nous dire ce que tu vois si tu cliques sur le lien "problèmes de sécurité".
  4. Normalement oui, mais pas tant que Google pense que ton site pose un problème de sécurité. Donc il vaut mieux vérifier que Google sait que le problème a été réglé. De toute façon, l'accès à la Search Console, c'est super utile.
  5. Ah ! Il faut commencer par cela alors : il faut que tu t'authentifies en tant que propriétaire du site selon l'une des méthodes décrites ici : https://support.google.com/webmasters/answer/9008080?hl=fr
  6. Bonjour, Oui cela arrive régulièrement de perdre de la visibilité en cas de piratage. C'est tout à fait normal. Et cela a duré longtemps. Donc l'impact est forcément plus sérieux. As-tu accès à la Google Search Console pour voir si tu as un avertissement dans la rubrique "problème de sécurité". Si c'est le cas, tu ne peux pas remonter normalement dans les classements, il faudra demander la réinspection de ton site.
  7. Ah tiens ! J'avais oublié cet article ... lolodev>Tu peux préciser ta demande ?
  8. 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
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. Meilleurs voeux 2016 à tous les membres !
  14. 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"
  15. 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.
  16. 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 ;-)
  17. 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.
  18. 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).
  19. 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.
  20. 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.
  21. 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.
×
×
  • Créer...