Aller au contenu

yep

Hubmaster
  • Compteur de contenus

    278
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par yep

  1. Clair, car avoir 25 sites ayant la même configuration est impossible : peut-être sur le plan de la structure HTML des documents, mais rarement sur les URL et le contenu proposé.
  2. Synonymes de domaines : aire, apanage, attribution, bien, bien foncier, cadre, campagne, cercle, champ, clos, compétence, département, diagramme, district, enclos, espace, estancia, étendue, exploitation, fazenda, ferme, fief, genre, habitation, hacienda, héritage, intervalle, latifundia, limite, matière, monde, orbite, ordre, partie, patrimoine, pays, possession, propriété, rayon, région, ressort, royaume, secteur, spécialité, sphère, succession, surface, terrain, terre, univers. En bref, un domaine est une zone qui regroupe des données/informations du même thème. C'est pourquoi effectivement avoir des mots clés dans son domaine le rend forcément pertinent sur ces mots clés. Tu peux donc avoir plusieurs domaines comportant chacun des mots clés mais ne propose pas le même contenu, ce qui serait de la duplication de contenu sanctionnable par les moteurs de recherche car cela augmente leur index sans le rendre pertinent. Après stratégiquement rien n'empêche l'achat de noms de domaines proches/similaires mais redirige les vers LE site le plus légitime via des redirections 301, cela pour éviter le squatting de noms de domaine (typosquatting, etc.).
  3. si tu utilises la GGtoolbar, tu as ta réponse
  4. la meta content-language est un équivalent HTTP (http-equiv non ?) de toute façon, la langue se spécifie, selon les normes, sur la balise html : <html lang="fr"> donc change l'IP d'hébergement et cette implémentation HTML (que tu peux également coupler avec l'instruction de langue en HTTP) et cela pourrait peut-être changer quelque chose
  5. Google met en place un système de masque pour analyser les URL potentielles d'une page et peut du coup, si les URL sont simplement écrites dans un code JS, "suivrent" ces URL, mais en aucun cas n'interprète le JS.
  6. mouais ... utilisez vous le _ (tiret bas) dans la langue française pour séparer vos mots clés ? le _ n'est qu'une invention des développers
  7. si tu proposes http://www.monsite.com/semaine32/index.asp et http://www.monsite.com/semaine32/alors alors que c'est le même contenu proposé, c'est : - de la duplication de contenu - une mauvaise gestion de l'identification de tes ressources publiées (gestion des URL) - une mauvaise gestion du maillage (certains liens pointent vers http://www.monsite.com/semaine32/index.asp d'autres vers http://www.monsite.com/semaine32/). Pour corriger cela, met d'abord en place une redirection de http://www.monsite.com/semaine32/index.asp vers http://www.monsite.com/semaine32/ (ex : http://c00lman.free.fr/redirection-301-et-...ate-content.php à appliquer en ASP). Ensuite, vérifie ton maillage et fait pointer tout tes liens vers http://www.monsite.com/semaine32/. Enfin, dans un robots.txt, place les URL que tu ne veux pas indexer (*/index.asp).
  8. peut-être n'as tu pas le droit d'utiliser cette marque et que Google en a été mis au courant ? faire un lien vers le document de référence te sauvera-t-il peut être ? du moins cela pourrait être considéré comme pertinent aux yeux de Google car tu partages auprès de tes internautes LA ressource, gage de pertinence.
  9. "> Pourquoi techniquement Wikipédia arrive en première position?" parce que ce n'est pas un critère technique, c'est grâce à son contenu ! "Rien ne permet de dire que Google décide sciemment de favoriser Wikipedia. De tels résultats peuvent aussi s'expliquer par le simple fait que l'encyclopédie universelle - de part sa structure, son contenu, la popularité de ses pages, etc - montre de réelles dispositions à plaire à l'algo de Google." Google tente de classer et restituer des documents. Ceux permettant de répondre généralement à la demande de l'internaute sont ceux de types enclycopédiques, il est donc normal que Wikipédia soit bien plus visible qu'une simple page. Par ailleurs, le web a été fait avant tout pour échanger des documents, or la majorité des pages ne sont pas créées dans cette optique de partager une véritable information pouvant répondre à des besoins de recherches. En prennant en compte cette problématique, les pages ne seront plus simplement des plaquettes commerciales mais permettront réellement de répondre à des besoins.
  10. Une implémentation plus simple est de te créer un controleur (par exemple dans un fichier index.php) qui traite les URL demandées et donc fait la correspondance entre URL et identifiant de base de données. Ainsi par ton htaccess tu rediriges tout vers ton fichier index.php et celui-ci publie le contenu en fonction du REQUEST_URI Pas mal de frameworks fonctionnent comme cela : par exemple symfony
  11. Pour être plus fin, en fait tu communiques à l'utilisateur via du 301 (dans les entêtes HTTP) que ton document est déplacé définitivement. Sinon parce que tu renseignes également l'emplacement du nouveau document (location:nouvelle url) et parce que le navigateur a paramétré les redirections automatiques (car ce n'est pas le serveur qui fait la redirection, c'est bien le navigateur/spider), alors, lors de la demande du document par l'internaute/le spider, celui-ci sera redirigé vers le nouveau document.
  12. Une URL est un identifiant ayant une sémantique fixe (car c'est une URI avant tout). Une URL ne devrait donc pas avoir d'indentifiant de base de données.
  13. pas forcément, de toute façon, comme toutes les requêtes et opérateurs (site:, link:, etc.), les résultats de recherche sont bridées.
  14. en gros, trois axes de travail : - technique (publication des contenus), une philosophie : le respect des standards - popularité ou comment faire en sorte que tes documents soient les ressources de références sur leur domaine - contenu : le seule véritable critère influançant directement la popularité et nécessitant d'être correctement publié pour être analysé/retranscrit/positionné
  15. et tout dépend du nombre de résultats par page (perso je navigue avec 100 liens)
  16. Tu devrais mettre en place des redirections 301 des anciennes pages vers les nouvelles plutôt que de proposer du 404. Cela permet de mettre à jour plus rapidement l'index des moteurs tout en transmettant une partie de l'ancienne popularité de la page vers la nouvelle et donc d'atténuer le passage à ta nouvelle version du site. Le must c'est toutefois de gérer correctement les URL de manière pérenne.
  17. Peut-être devrais-tu te renseigner sur ce qu'est l'encodage de caractères. Ton problème semble être simple, tes pages proposent de l'ISO-8859-1 alors que ton sitemap est en UTF-8, ou vice versa. A toi d'encoder correctement ces caractères. Pour info : http://openweb.eu.org/articles/jeux_caracteres/
  18. Alors conçoit tes URL en amont. La réécriture d'URL est un système palliatif déployé en surcouche de ton application. Si ton application gérait correctement tes URL (comme des identifiants sémantiques, donc avec une structure de mots clés) nativement, tu n'auraias pas à pallier un mauvais déploiement. Un petit tour par ici serait pas mal.
  19. les extensions de fichiers ne sont pas pertinentes : http://www.la-grange.net/w3c/Style/URI
  20. avant de te lancer dans l'achat d'une prestation visant à optimiser ton PR, je te conseille fortement de lire cet article : http://www.outil-referencement.com/blog/in...hp/346-pagerank En bref, le PR n'est pas un critère de positionnement mais bel est bien un indice retranscrivant une certaine popularité.
  21. yep, merci pour le lien mais j'ai déjà parcouru ce site et j'y ai pas trouvé la réponse. Beaucoup de ressource parlent de l'utilisation de "cdata-section-elements" avec l'élément xsl:output. Mais la valeur de cet attribut ne semble être que le nom des balises affectées par la non-conversion. Or je ne peux identifier l'ensemble de mes balises que par le biais de son identifiant HTML (id="toto"). L'appel à un identifiant dans cet attribut pourrait faire l'affaire, si oui cela s'écrit comment ? cdata-section-elements="id(idname)" ? Sinon je peux également utiliser <xsl:copy-of ...> mais mon contenu XML n'est plus exploitable en tant que CDATA.
  22. Bonjour, Je tente simplement d'obtenir un rendu HTML via le couple XML/XSL. Cependant le résultat obtenu ne répond pas à mes attentes : les balises HTML proposées en CDATA sont retranscrites en entités HTML. <!-- Code XML --> <xml> <content> <![CDATA[contenu texte + balises <html>]]> </content> </xml> <!-- Code XSL --> ... <xsl:value-of select="xml/content" /> ... <!-- Rendu HTML --> ... contenu texte + balises <html> ... Quelles sont les instructions à fournir pour pouvoir obtenir en rendu des balises HTML et non ces entités ? Merci par avance
  23. deux choses : gère HTTP correctement (http://www.outil-referencement.com/blog/index.php/353-entetes-http-referencement) et déploie des URL (http://www.la-grange.net/w3c/Style/URI)
  24. euh, si tu veux contrôler le rendu graphique de tes documents, ne le laisse pas faire par les agent-logiciels (Opéra, FireFox, etc.), donc respecte les standards web. En effet, si les DOCTYPE ne sont pas renseignés et respectés, les navigateurs passent en mode Quirks, ce qui signifient qu'ils font leur sauce et advienne que pourra du rendu graphique ; m'enfin pour le fun http://openweb.eu.org/.
  25. ça fonctionne merci bien
×
×
  • Créer...