captain_torche

Quel est le problème dont tu parles ? Le seul souci que je peux voir sous IE6, c'est la transparence des onglets qui est mal gérée, car l'image est un PNG.

Personnellement, je cumule mise en cache et réécriture d'urls. En gros, voilà ce que je fais : - Mes règles de réécriture pointent tous vers le même fichier, qui incluera différentes pages en fonction des paramètres qui lui sont passés - Dans ce fichier, je récupère l'url telle qu'elle est envoyée au navigateur. - Je vérifie l'existence d'un fichier de ce nom dans mon répertoire cache. - Si le fichier n'existe pas, ou s'il est trop vieux, je le (re)crée - J'affiche le contenu du fichier L'avantage, c'est que je n'ai pas besoin de faire un cronjob pour générer ces pages : le premier utilisateur à la demander la génèrera, et les autres bénéficieront de la version cachée.

Ce n'est pas parce que les robots n'utilisent pas JS qu'ils ne voient pas la même chose. En l'état, en cliquant sur un lien, le contenu change de la même manière, il n'y aura donc pas de souci.

Personnellement, je préfère n'avoir qu'un seul h1 par page; il sert selon moi à définir le titre du document (la page elle-même). Mais je sais que cela est sujet à contreverse En tout cas, rien n'empèche techniquement d'avoir quinze h1 dans une page.

ASC : on peut par exemple se référer à cette page : http://www.seomoz.org/article/search-ranking-factors#f6 Il n'y a pas d'analyse détaillée pour chaque paramètre, mais les conclusions de nombreux référenceurs permettent de se faire une bonne idée de la chose.

On peut aussi tester de manière empirique différents noms de répertoires pour l'administration (je doute qu'ils le fassent, hein, c'est juste une méthode possible).

Alors ... Tout d'abord, les balises Hn servent à hiérarchiser un document. Ce sont ses titres, sous-titres, etc. Dans cette optique, il n'est pas illogique d'avoir plusieurs h2 ou h3 dans un même document. Les balises hn sont des balises de type block. Par conséquent, il est tout à fait possible d'y imbriquer d'autres balises, comme dans toutes autres balises de type block (p, form, div, etc). Y mettre une image à la place d'un texte n'est préjudiciable en rien, bien que cela puisse être moins performant pour le référencement. Pour finir, le nombre de balises importe vraiment peu, tant que le contenu reste acceptable. En ce qui concerne le référencement, il semblerait que seules les balises h1 aient un véritable poids supplémentaire pour les moteurs de recherche.

Le souci (à part le souci de référencement), c'est que tu n'affiches le disclaimer que lors d'un accès à la homepage du site. Je ne sais pas s'il existe une législation pour ça, mais il me semblerait logique que ce même disclaimer s'affiche lors du premier accès au site, quelle que soit la page d'entrée. Dans cette optique, tu pourrais générer le disclaimer en JavaScript, par exemple, et enregistrer un cookie pour ne l'afficher qu'une seule fois. De cette manière, tu n'aurais pas ce souci de référencement, Google ayant directement accès au contenu.

Ha, effectivement, j'avais pas pensé aux en-têtes. C'est une solution, également Même s'ils doivent inspecter le code source pour identifier les scripts utilisés.

J'imagine que c'est une analyse du code source. Par contre, dans ce cas je ne vois pas comment ils pourraient détecter des systèmes tels que SPIP.

Il me semble qu'une option soit disponible dans Youtube, pour empêcher les vidéos de se trouver ailleurs que sur leur site. Malheureusement, cela impliquerait que ton site non plus ne pourra pas utiliser la vidéo. Youtube part d'un principe communautaire, il faut jouer le jeu Par contre, je te rassure sur un point : il n'y aura pas de duplicate content. C'est le contenu textuel du site qui est pris en compte pour ça, pas les vidéos ou les images.

Non, tu crées juste le répertoire sessions à la racine de ton site, sans toucher au reste.

Sur un hébergement free, tu dois créer manuellement un répertoire "sessions" à la racine de ton FTP.

Il semblerait que la fonctionnalité n'existe pas encore, mais le script elabel semble faire ce que je cherche à obtenir. je me bats contre quelques derniers bugs, mais ça me semble très correct.

Je ne pense pas qu'ajouter une balise fasse planter le principe du sitemap, non (mais bon, c'est totalement empirique, je n'ai pas testé). Dans cette optique, tu pourrais éventuellement te générer ton plan via un script, mais comment comptes-tu gérer les éventuelles subdivisions, rubriques, etc ?

Non, tu ne peux pas ajouter de label, ni aucune autre balise non prévue. Pourquoi voudrais-tu le faire, d'ailleurs ? Un fichier Sitemap sert juste à trouver des pages, seule l'url en est donc une information pertinente. En ce qui concerne les autres informations (titre, contenu, etc), le moteur les trouvera de lui-même lors de sa visite sur la page.

Non, il s'agit bien d'Acrobat, à ne pas confondre avec Acrobat Reader, gratuit, qui ne peut pas modifier les fichiers PDF.

On retombe de toutes manières sur le principe du début : - les internautes débutants ne sauront que faire des images, à part les mettre en fond d'écran ou les imprimer pour un exposé (ou les utiliser sur un skyblog). - les internautes confirmés sauront déjouer toute tentative d'obstruction. Le watermark est effectivement une solution plus intelligente, tant qu'elle ne gêne pas la consultation "normale" du site.

Comme tu le dis, tous les documents sont à ton nom : de ce côté, tu n'as rien à craindre. Mais comme tu étais membre de l'asso au moment où tu as fait le site, il faudra sans doute éplucher les statuts de l'association pour déterminer la paternité du code.

Aurais-tu un lien vers la page incriminée ?

Le site est-il chez un hébergeur gratuit ou payant ? Dans la seconde alternative, qui est renseigné comme contact administratif ? Qui a payé l'hébergement ? J'ai eu un souci du même genre il y a quelques temps, quelques réponses sur ce sujet peuvent t'être utiles : litige pour un site bénévole.

TrocWeb, je confirme, j'ai également eu l'accès à la page hier via chrome. Le souci avec une méthode comme celle-ci, c'est que les moteurs de recherche ont chacun un user-agent qui leur est propre. Google (pour ne citer que lui) ne pourra donc pas accéder au contenu. Quitte à interdire l'accès à tout le monde sauf à une certaine élite utilisant IE (car c'est bien de ça qu'il s'agit), autant n'autoriser l'accès qu'après validation d'un mot de passe, non ?

100 visiteurs, c'est pas énorme. Surtout que la quasi-totalité du contenu (les vidéos) n'est pas hébergée chez free.

Parweb : les serveurs Free ne sont pourtant pas réputés pour leur rapidité. Le souci également, c'est qu'aucun contrat ne lie Free à l'utilisateur; ils sont libres de supprimer les pages quand bon leur semble, sans justification. Il me semble que c'est arrivé à quelques sites avec de fortes fréquentations, il y a quelques temps. D'autant que là, le nom de domaine ne correspond vraiment pas à la thématique du site. Le meilleur serait de prendre un hébergement payant (mais jamais très cher), et de rediriger les anciennes pages, hébergées chez free, vers les nouvelles.

yhugo : le souci, c'est que tu sembles partir du principe que toute personne sans JavaScript est un aveugle. Or, ce n'est pas le cas ! Il arrive que des entreprises limitent l'utilisation de JavaScript par sécurité, ou qu'il soit désactivé pour une raison ou une autre. On peut même imaginer un bug dans ton code ... qui rendrait de fait ta page incompréhensible à tout le monde ! Je mets personnellement le contenu après le header et les menus, les moteurs de recherche n'ont pour l'instant jamais eu de problèmes avec ça : ils savent trouver le contenu pertinent. Quant aux liens d'évitement, j'avoue ne quasi jamais les utiliser.