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.