Florent V.

... Wikipédia est un site édité par la Wikimedia Foundation, Inc. (organisation à but non lucratif -- sur la homepage de Wikipédia, on peut lire: «Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., association de bienfaisance régie par le paragraphe 501©(3) du code fiscal des États-Unis.»). http://wikimediafoundation.org/wiki/Home Wikia est un site édité par l'entreprise Wikia, Inc. http://www.wikia.com/wiki/Wikia%2C_Inc. Faudrait voir à pas écrire des bêtises, hein. (Et oui, je sais, il y a des proximités, par exemple le mot «wiki» et une terminaison en «-a», ou le fait que Wikia soit une société de Jimbo Wales.)

Et si le spammeur a son propre serveur SMTP, hmm?

La plus fiable, pas vraiment. Le serveur utilisé peut avoir une IP qui était préalablement attribuée à un spammeur (même un spammeur pas intensif ou quelqu'un qui faisait de l'e-mailing avec une base mal entretenue), et l'IP peut se retrouver sur liste noire chez certains webmails ou fournisseurs d'accès, par exemple. De plus, il faut bien choisir les copains à qui on laisse l'accès au serveur SMTP, parce que si eux ne sont pas réglo ça peut faire mal pour tout le monde... (Du moins c'est ce que j'ai retenu des conversations et conseils de certains spécialistes, mais j'ai peut-être compris de travers.) Sauf erreur de ma part, il me semble que la solution la plus fiable est de passer par un (bon) prestataire e-mailing qui travaille de près les questions de classement en spam des messages qu'il envoie. Je pense à des services type Email Vision (pas forcément les meilleurs, hein, mais c'est le nom qui m'est venu à l'esprit). Problème: c'est pas donné. Le serveur dédié bien géré peut être une solution efficace (je le souhaite en tout cas à ceux qui l'utilisent!), mais ça n'est à priori pas la plus fiable. Edit: grillé par Wefficient.

Je vois mal comment ça pourrait être pénalisé dans ce cas précis. C'est une solution techniquement un peu bricolée, mais RAS côté problèmes de référencement (à ma connaissance). Mais si tu n'es pas à l'aise avec cette technique, tu peux simplifier un peu avec un petit script JS externe ou dans le head de ta page, du type: window.onload = function() { if (!document.getElementById) return false; if (!document.getElementById("inscript")) return false; document.getElementById("inscript").style.display = "none"; } (Normalement c'est juste mais je suis nul en Javascript, faut vérifier que ça marche...). Le but est de cacher le bloc (enfin, de le passer en display: none) une fois que la page est chargée. Par contre, si tu utilises déjà Javascript sur tes pages il est probable que tu aies déjà un script lancé lors de l'évènement window.onload. Utiliser une fonction telle que addLoadEvent serait une bonne chose: function addLoadEvent(func) { var oldonload = window.onload; if (typeof window.onload != 'function') { window.onload = func; } else { window.onload = function() { oldonload(); func(); } } } // Ici le reste de tes fonctions JS, et si l'une d'entre elles utilise window.onload il faudra passer par la fonction addLoadEvent à la place. addLoadEvent(function() { if (!document.getElementById) return false; if (!document.getElementById("inscript")) return false; document.getElementById("inscript").style.display = "none"; });

Bonjour, Faire porter ses liens (élément HTML a) sur du texte plutôt que sur un input de type "button". Ça devrait améliorer l'ergonomie du menu, et peut-être résoudre certains problèmes de liens inactifs (constatés notamment avec Internet Explorer 6 et 7). Pour le reste, je ne commente pas la qualité globale du site, sinon on y passe la nuit.

+1 Si la «page d'intro» ne propose aucune fonctionnalité (exemple typique de fonctionnalité utile: le choix de la langue), et sauf cas très particulier, on aura intérêt à la virer purement et simplement. Un peu de lecture (en anglais): http://www.seomoz.org/blog/how-to-convince...d-a-splash-page Une traduction partielle en français: http://www.go-referencement.org/accessibil...plash-page.html

Je le vois à 8 pour ma part. Sinon, mon petit site personnel sans prétention (bon ok, avec un petit peu de prétention tout de même) est resté à PR6. Je sais pas comment j'avais obtenu ce 6, et ça ne m'aurait pas fait grand chose de baisser, mais tant mieux si je le garde.

Le retour du serpent de mer. Je ne dis pas que c'est faux (c'est tout à fait possible), mais: sources, études, indices concomitants, tests systématiques?

Une remarque en passant: ça serait bien de réviser les bases de HTML et de ne plus confondre attributs, éléments et balises. - <img> est une balise; - IMG est un élément; - alt est un attribut. Bien entendu, la remarque s'adresse également aux manchots de chez Live Search, qui sont censés s'y connaitre un tout petit peu. Sur le fond: ne plus prendre en compte le contenu des attributs alt serait une erreur. Par ailleurs, ce serait une décision sans fondement. En CSS, je peux cacher un bloc de texte facilement (div#machin {position: absolute; left: -3000px;}), cela ne signifie pas qu'il ne faut plus prendre en compte le contenu des éléments div (ou de tout autre élément, d'ailleurs...). Ce qui pourrait être fait, à la rigueur, c'est de ne plus prendre en compte le texte dans les attributs alt passés N caractères. Sauf qu'il n'y a aucune restriction dans HTML sur la longueur du contenu des attributs alt, et aucune restriction chiffrée dans WCAG. Donc bon... Ce qui est sûr, ce que l'on peut utiliser les attributs alt pour placer du texte caché dans la page, et que cette pratique est susceptible d'être sanctionnée... après vérification humaine. Ceci dit, il est possible qu'un ou plusieurs moteurs fassent l'erreur de ne pas prendre en compte normalement (c'est à dire sans pondération, et bien sûr sans les ignorer) le contenu des attributs alt. D'ailleurs, si quelqu'un a connaissance d'informations fiables à ce sujet, qu'il n'hésite pas à faire tourner.

Très sage décision. Dans la foulée, je te suggère également de supprimer ton image de fond sur la page de plan du site, car elle rend le texte peu lisible. Texte sur motif = lisibilité réduite ou sérieusement mise à mal.

Il me semble que tu devrais pouvoir faire ceci: RedirectPermanent /index.html / RedirectPermanent /home.html / RedirectPermanent /home.php / ou bien ceci: RedirectPermanent /index.html /index.php RedirectPermanent /home.html /index.php RedirectPermanent /home.php /index.php Mais peut-être que Free n'est pas d'une souplesse folle...

Affirmation un peu rapide et largement contestable...

Bonjour, C'est peut-être l'occasion de découvrir les notions d'accessibilité et de non-obtrusive Javascript (Javascript non-obstructif).

Ce qui ne répond pas du tout à la question posée. La question est: les inscrits de ta base ont-ils été informés qu'en s'inscrivant ils acceptaient de recevoir des courriels promotionnels de tes (éventuels) partenaires? Si ça n'est pas le cas, une seule personne (physique ou morale) peut utiliser cette base: toi/ton entreprise. Il ne suffit pas de pouvoir dire «c'est de l'opt-in» pour avoir les coudées franches.

Pour le site lui-même c'est euh... comment dire... assez roots. Design presque inexistant, que du texte (mal mis en valeur) sur la page d'accueil, des cadres et filets qui ne sont pas raccord (aussi bien sous IE6 que Firefox2), un texte introductif un poil trop long, pas assez de respiration du texte (presque collé au bord), texte petit, doctype transitional incomplet qui fait passer les navigateurs en mode Quirks, mise en page avec énormément de tableaux inutiles, pictogrammes sans attribut alt (alternative textuelle) et sans title (infobulle au survol...), etc.

Tant qu'à faire, penser au texte alternatif (attribut alt) sur les textes en images et pictogrammes.

Ben... ça aurait plus d'intérêt d'être en haut de page 2 plutôt qu'en bas de page 1 des résultats si et seulement si une majorité des utilisateurs passait en page 2 plutôt que de descendre en bas de page 1 lors d'une recherche un peu fouillée. Or, les liens pour passer en page 2 (3, 4, ...) sont en bas de page uniquement. Il faudrait voir quels sont les usages. Mais il me semble que le fait que les liens soient en bas de page uniquement scelle la donne...

Hello, Tu peux faire un minimum d'information envers les auteurs publiés, en leur proposant : - de publier le billet uniquement sur ton site ; - de publier sur leur blog un billet court disant « j'ai publié sur TrucBidule le billet suivant : ... », en mettant peut-être un extrait.

Avec la barre d'outils Webdeveloper pour Firefox, ça devrait être possible (Information > En-têtes HTTP (Réponses)), ou encore avec tel ou tel site qui renvoie les en-têtes HTTP pour une URL précise. Par exemple avec l'outil suivant : http://web-sniffer.net/

À la question « Faut-il privilégier la pub ou les produits ? », la réponse est : les deux. Mais APRÈS avoir retravaillé le site, qui pose actuellement un grave problème de communication comme le souligne adn (site en construction, charte graphique typique du secteur touristique). On pourra également travailler sérieusement les bonnes pratiques Opquast : http://fr.opquast.com/bonnes-pratiques/ Et notamment celles définies pour les sites e-commerce : http://fr.opquast.com/bonnes-pratiques/#2 Beaucoup de boulot en perspective.

Oui, trop ou pas assez. Voici quelques questions supplémentaires en bonus : - Connais-tu la problématique de l'encodage des caractères ? Encodage réel (iso-8859-1, UTF-8, etc.), et encodage déclaré (balise META et surtout déclaration dans les en-têtes HTTP !) ? Si non, je t'invite à lire ceci. - À ton avis, est-ce que Google dispose de la technologie suffisante pour gérer correctement les encodages de caractères ? - Le fait de gérer correctement les encodages de caractères ne permettrait-il pas aux moteurs de recherche de fournir des résultats plus précis pour une langue donnée, voire de donner des résultats tout court pour les langues n'utilisant pas les caractères latins ? - Comment Google gère-t-il google.co.jp ? Voici par exemple une requête de test (caractères japonais choisis au hasard dans un texte, ça ne veut peut-être rien dire). Voilà pour la question de l'encodage des caractères et de sa gestion par les moteurs. Sur les détails, on pourra discuter des requêtes avec et sans diacritiques (accents, cédille, tréma, etc.), mais le principe général c'est : ça marche, parce que 1) c'est techniquement possible et 2) ça rentre dans le business model des moteurs (fournir des résultats pertinents...). Ensuite, pour les URL, c'est différent. Les URL ne sont pas des documents encodés, mais répondent à une norme plus restrictive. Mais ça a déjà été indiqué.

Je vais peut-être dire une bêtise, mais il me semble qu'il n'y a pas de différence.

Ton intérêt serait : - que les moteurs indexent tout tes contenus ; - mais que les URL indexées pointent vers des pages complètes. Pour ça, pas de secret, les frames ne sont pas la bonne méthode.

Tiens, ça sert à quelque chose de placer plus de 500 liens dans un sitemap ? (En dehors du débat sur : est-ce ça sert à quelque chose un sitemap...)

Dommage pour les liens HTML en display: none, tout de même. Il faudrait trouver un moyen de les afficher tout de même, par exemple comme contenu alternatif du menu en Flash : <object> <param /> <ul id="menu-alternatif"> <li>...</li> <li>...</li> </ul> </object> On peut aussi faire sensiblement la même chose avec SWFObject. Les liens directement visibles dans le pied de page, en doublon du menu Flash, pourquoi pas également.