Jump to content

Sodium

Members
  • Posts

    23
  • Joined

  • Last visited

Everything posted by Sodium

  1. Hello, The Prestashop caching of CSS and JS files has been an issue for quite sometimes reguarding SEO. To summerize, when the CCC option is activated in prestashop, the system creates dynamic cached and compressed files. The problem is that those are frequently deleted and replaced with new files with new names. The result is that when Search Engines crawl the website, they keep in their archives pages with a reference to CSS and JS files that are going to be deleted and will return an error eventualy. Because of that, the cached version of the pages in Google display the content without CSS because Google doesn't keep it in memory. I tought i read in some changelog that this had been fixed but the problem is the present on my 1.6.1.4 shop and i had to disable CSS. Is it because my theme is not compatible, is the fix still in developpment or did i dream the whole thing ? Thanks,
  2. Hello, Looking at Prestashop's pages with CSS and Javascript deactivated, i see a lot of useless content put there to displayed dynamicly with JavaScript. For example, in the basket block, you can find the texts "Product added succesfully", "There is 0 products in your basket" and "There is 1 product in your basket". In a product page, there is the string "Date of availability : 0000-00-00". I could probably go on for ages but basicly, Prestashop is putting a lot of useless placeholders that should be loaded only if required on page load or with Ajax. I'm wondering how this could affect the SEO of a website. I see two majors problems : - A lot of useless content offers less place for the actual content and crawlers may get confused about what the important sections of the page are - Semantically speaking, those make absolutly no sense. A sentence followed immediatly by it's contrary isn't easy to understand even for a human. True, only the relevant content is displayed to the user, but crawlers analyse mostly the HTML code
  3. Un nom de domaine n'est jamais enregistré avec les www, c'est un sous-domaine, ça n'a aucun rapport. Par contre, le www correspond dans l'esprit du grand-public à un site web, l'adresse principale du site devrait donc sauf exception toujours les contenir et le nom de domaine seul rediriger vers les www.
  4. Je vais aller dans le même sens, tous les ouvrages que j'ai lu sur le SEO conseillent sans ambiguité de séparer les mots d'une url par un tiret, ce qui permet aux moteurs de recherche de les repérer. S'il est vrai qu'en théorie, Google mène une grande campagne pour éviter le spam de mots-clés dans les domaines, ceux-ci ressortent pourtant encore nettement dans les résultats de recherche, indiquant que ceux-ci restent un paramètres important. Dans tous les cas, les pénalités de Google sont là pour éviter la maniupulation des résultats avec du contenu de mauvaise qualité. Si ton contenu n'est pas de mauvaise qualité, il n'y a pas de raison de ne pas suivre les pratiques permettant d'optimiser ton référencement. Par contre, le nom que tu as choisi aura très peu de poids, je ne sais pas ce que tu vends mais tu devrais plutôt envisager quelque chose commme vetements-la-banane ou chaussures-la-banane.
  5. Comme je le disais, cela n'est pas possible avec Prestashop actuellement, sauf bidouillages dans le core du système que je déconseillerais. Un sitemap ne va pas diminuer le nombre de pages indexées. Il faudrait voir ton site parce que là comme ça ce n'est pas facile d'y comprendre quoi que ces soit ...
  6. Ce n'est pas mon idée, il s'agit des recommandations de bonnes pratiques généralement reconnues pour de la gestion de site multilingue Pour ce qui est du sitemap, si en effet il n'est pas indispensable au référencement d'un site, il s'agit d'un plus non négligeable quand le nombre de pages devient conséquent. Puisqu'il permet de spécifier la date de dernières modifications de chaque page, il fournit une indication précieuse aux crawlers qui savent alors quelles pages visiter en priorité.
  7. C'est assez simple en théorie. Tu crées deux domaines ou deux sous-domaines qui pointent vers le même répertoire sur ton hébergement. Ca peut être fr.tonsite.com et de.tonsite.com tout comme ça peut être www.tonsite.fr et www.tonsite.de, et en fonction de l'url que les visiteur utilisent, tu leurs sers le site dans la langue appropriée. L'avantage c'est que Google considère qu'il s'agit de deux sites différents, et il n'y a donc pas de risque de conflits de dupplicate content etc. Ca c'est en théorie, en pratique prestashop ne permet pas de faire ça. Tu peux spécifier plusieurs url pour ta boutique mais il va toujours te rediriger vers la principale. C'est un gros manquement qui je l'espère fera partie d'une version pas trop éloignée.
  8. Je ne parle pas de faire un deuxième site mais de faire en sorte qu'il soit considéré comme un deuxième site. Si tu as le français sur fr.tonsite.com et l'anglais sur en.tonsite.com, Google les considèrera comme deux sites séparé et n'aura donc pas à se poser la question de quel contenu est en quel langue, quel contenu est la traduction de quel autre contenu, etc. Toute la partie technique derrière ne change rien, tu as toujours un site, une admin, juste plusieurs domaines pour y accéder. Mais encore une fois, ce n'est pas possible dans prestashop, du mmoins pas sans du bidouillage qui me paraît hasardeux. Le code est à mettre dans header.tpl oui.
  9. Alors, déjà il faut savoir que la gestion multilingue dans Prestashop est loin d'être optimale. Idéalement, on crée un domaine ou un sous-domaine différent par langue pour que Google les considère comme des sites séparés. Avec la structure de Prestashop qui crée simplement un dossier par langue, il peut y avoir confusion et certaines pages peuvent être considérées comme du contenu duppliqué. Une première étape serait pour moi j'ajouter des balises hreflang qui permettent de spécifier les différentes versions d'une même page. Pero, j'ai ajouté ce code dans l'entête de mon thème : {if count($languages) > 1} {foreach from=$languages key=k item=language name="languages"} <link rel="alternate" hreflang="{$language.iso_code}" href="{$link->getLanguageLink($language.id_lang)}" /> {/foreach} {/if}
  10. Hello, I've seen someone having the same problem early in the topic but i didn't find an answer. Using smartblog on a multilingual website, the language block doesn't correctly translate the post url. At first, the route en/blog/{post_id}_{slug} would translate to de/module/smartblog/details?id_post={id_post} I managed to get it a little better by adding this route in the module : 'module-smartblog-details' => array ( 'controller' => 'details', 'rule' => $alias.'/{id_post}_{rewrite_link}', 'keywords' => array ( 'id_post' => array('regexp' => '[_a-zA-Z0-9-\pL]*', 'param' => 'id_post'), 'rewrite_link' => array('regexp' => '[_a-zA-Z0-9-\pL]*','param'=>'rewrite_link') ), 'params' => array ( 'fc' => 'module', 'module' => 'smartblog', ), ) Now the url format is correct but the slug is not translated. I've been twisting my brain a whole day on this, any help would be welcome. Here's the shop url : http://smartphone-accessoires.fr/fr/blog/6_wiko-highway-pure-4g-et-le-highway-star-4g
  11. Tu racontes vraiment n'importe quoi. Au delà d'être contrairement à toi un développeur compétent, j'ai également de bonnes connaissances en SEO, tu ne me tromperas pas avec des affirmations bidons pour te sauver la face. J'encourage toute personne ici à ne jamais toucher à l'un de ses modules. Rien de bon ne peut sortir d'un personnage tenant des propos pareil. Engagez un développeur d'Europe de l'Est. Quitte à avoir du travail de bidouilleur, autant le payer moins cher.
  12. Je comprends mieux pourquoi tous les modules sont aussi mal codés du coup Il est malheureux de constater que le domaine du web est pourri par tant d'amateurs se vendant comme professionels et experts, générant des heures de boulot pour les gens compétents passant derrière... Et encore une fois, rendre son code valide ne génère AUCUN travail supplémentaire. Celà révèle uniquement votre manque de maîtrise. Le web, c'est un métier ... Par ailleurs, votre site est introuvable dans Google en tapant son nom et le logo dans votre header ne renvoie pas à la page d'accueuil puise vous avez oublié d'ouvrir votre balise lien : <div id="logo"> <img src="http://presta-seo.fr/wp-content/uploads/2013/09/logo-prestaseo.png" alt="PRESTASEO" /> </a> Mais c'est sûr, la validation est une perte de temps
  13. Il n'y a pas que le SEO dans la vie, un site c'est un tout. Vendre ses services quand on n'est pas capable de fournir un code propre est innacceptable. Que veux-tu dire par essayer ? Très sérieusement, qu'est-ce qui pourrait bien poser un problème majeur à l'obtention de cette validation ? Il faut se souvenir de mettre des alt à ses images (même pas besoin qu'ils contiennent du texte) et c'est à peu près tout. Le reste, ne pas mettre d'élément block dans des éléments inline par exemple, découle de la logique et un bon intégrateur le fera par défaut, W3C ou pas. Quand j'envoie une page au validateur, je veux peut-être avoir une ou deux balises mal fermées mais c'est tout, dans la majeure partie des cas elle est clean sans effort supplémentaire. À la limite il y a quelques attributs ayant disparus de la norme HTML5, sur les iframes notamment qui peuvent poser problème, règles que l'on pourra outrepasser au besoin sans concéquences ...
  14. Tout comme un bon rédacteur doit respecter les règles de grammaire et un bon développeur back-end les règles strictes de son langage, un intégrateur professionnel se doit de respecter les normes W3C. Encore une fois, ça ne coûte rien et ça évite de passer à côté de balises mal fermées et autres problèmes de ce genre. Votre commentaire ne veut rien dire. HTML5 ne répond plus à la norme XML mais une majorité des critères restent valables. Par ailleurs, respecter la syntaxe XML permet de garder un code plus propre et encore une fois, ça ne demande pas de travail supplémentaire (à part si c'es trop fatiguant de fermer ses balises et d'entourer les attributs de guillemets ...) Microsoft et Google font bien ce qu'ils veulent. Une armée de développeurs experts peut se permettre d'enfreindre les règles une fois celles-ci maîtrisées. Mais bon, c'est sûr que l'abence de respect des règles et normes chez Microsoft n'a jamais créé de soucis pour qui que ce soit hein ...
  15. Le W3C c'est important pour montrer que l'on fait du travail de professionnel et pas du bricolage, d'autant plus qu'un paquet d'erreurs secondaires peuvent cacher un problème sérieux. Une bonne raison de rendre son site valide W3C, c'est qu'il n'y a priori aucune raison pour qu'il ne le soit pas. Il n'y a rien de contraignant dans ses règles et il faut presque le faire exprès pour déclencher des erreurs.
  16. Il n'y a pas grand-chose à développer. Il y a peu j'ai installé pour un client un module assez cher d'une agence partenaire Prestashop. Résultat j'ai passé des heures à nettoyer du code HTML illisible et bourré de style en ligne (j'ai fini par renoncer à le rendre valide W3C), corriger des erreurs dans le PHP, corriger des traductions et je découvre encore régulièrement qu'il me génère des URL inutiles qui sont référencées comme contenu duppliqué. Quand je contacte le support, il essaye de me convaincre que les bugs et mauvais fonctionnement sont des features ("Ah oui, le module génère cette url là, il suffit d'aller la désactiver dans webmaster tools...). Je ne dis pas que c'est le cas de ton travail, mais jusqu'à présent je n'ai pas vu un module ou thème payant codé par des gens compétents. Déjà que le code de Prestashop en lui-même est limite ...
  17. Installer un module prestashop c'est un peu la boîte de pandore à chaque fois. Les développeurs n'ont souvent pas la moindre notion du respect des standards et des bonnes pratiques SEO.
  18. Hello, I installed a products review module and it offers only two options : Display reviews only in the current language or display all reviews. I'd prefair an in-between solution like displaying only the stars with a button showing the details in foreing languages, but what is the less-worst option ? I know that for a good SEO, a page should only be in one language, but i suppose the crawlers are able to detect a users generated section of this kind. It would be a pitty not to display them since they can increase the conversion rate. Any toughts on this ? Thanks
  19. Bonjour et merci de votre réponse. Peut-être aurais-je du préciser que je suis développeur PHP à la base. Voici le test que j'ai effectué : $query = $pdo->prepare('SELECT * FROM ps_customer'); for($i=0 ; $i<500 ; $i++) { $query->execute(array()); set_time_limit(1000); } $timerEnd = microtime(true); Ce test prend environ 10 secondes sur le sql perso, 40 sur le sql privé. Je ne pense pas que la différence du temps d'accès, j'ai constaté que le sql privé est très mou du genou même dans Phpmyadmin. Dans ce cas, quel est l'intérêt de ce SQL privé ? Les seuls retours que j'ai trouvés datent de plusieurs années. J'ai posé la question à OVH mais ils mettent trois jours pour donner la moindre réponse ... Passer sur un VPS, pourquoi pas mais mieux vaut être certain que mes soucis proviennent bien d'un manque de puissance brute et pas d'un soucis dans la base de données. Au delà des plantages dans l'admin Prestashop, le site est très rapide en front end, pas de problème de ce côté. L'hébergement mutualisé semble d'ailleurs plus rapide que mon serveur local alors que tout mon hardware est à la pointe (mais peut-être n'est-ce pas comparable).
  20. Am I really the only have having ever had this problem ? I managed to restore my shop but the problem has not gone away. Deleting my old categories, even after clearing old product associations still results in most of my products and active categories to vanish.
  21. Bonjour, Je poste ce sujet car après pas mal de recherche, il est très difficile de trouver des informations complètes et surtout à jour sur le sujet. Un hébergement OVH mutualisé comprend trois types de bases de données : 4 bases "perso", une base "pro" et un sql privé qui est je suppose un VPS dédié à une installation mySQL de 128mo de RAM. Rencontrant énormément de soucis avec mon site Prestashop (beaucoup d'actions dans l'admin aboutissant à des timeouts ou des erreurs "mySQL has gone away") malgré un nombre de produits très raisonnable, j'ai testé une migration de ma base de données vers le sql privé. Problème : les performances ne semblent pas au rendez-vous. En effectuant un test maison de 500 requêtes SELECT sur une table, le SQL privé met près de 4 fois plus de temps à terminer la tâche. Après, peut-être que mon test n'est pas fiable, peut-être que le gain de performances se situent ailleurs, peut-être plus sur la fiabilité et l'endurance que sur la vitesse pure, j'aimerais avoir des retours d'autres utilisateurs de Prestashop. Quant au SQL pro, est-il plus performant que le SQL perso ? À première vue, la seule différence semble être la taille maximum de la base de données, ce qui est encore loin d'être un soucis avec les malheureux 25mo occupés par ma boutique. Merci d'avance.
  22. Hello, I've redone my prestashop website in the past weekds and upgraded from 1.5.x to 1.6.0.11. The categories hierachy has also been redone and basicly, when i deleted the old unused categories (to which produts were still linked but not as main category), almost all of the other categories vanished. My structure was like this : - Category 1 -- Subcategory 1 -- Subcategory 2 -- Subcategory 3 -- Old unused category 1 -- Old unused category 2 -- Old unused category 3 ... - Category 2 - Category 3 Even the categories 2 and 3 disapeared although they were in a parent category. So my questions are : - How the **** did that happen ? - I have a backup of the database, how can i fix this without messing with other important stuff like new clients, orders etc ... Can i simply resteore the ps_category_ tables ?
  23. Bonjour, Je viens de mettre à jour ma boutique vers la version 1.6.0.11 et je constate que dans la liste des produits, prestashop me dit que plus de 75% de mes produits sont en rupture de stock. Pourtant, si je filtre par produits en ruputre de stock, ceux-ci ne représente que 60 sur 300 environ. D'où ce chiffre provient-il ? Merci d'avance.
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More