Jump to content

Sodium

Members
  • Posts

    23
  • Joined

  • Last visited

Contact Methods

Profile Information

  • First Name
    Jean
  • Last Name
    Jean

Sodium's Achievements

Newbie

Newbie (1/14)

0

Reputation

  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.
×
×
  • Create New...

Important Information

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