Remi

A partir du moment où l'include est fait, le bout de code ne fait plus vraiment partie de l'autre site. Par contre, il me semblait qu'OVH en mutualisé avait bloqué les includes par http (ce qui serait en tout cas une bonne chose) mais dans ton cas, tu peux contourner le pb si l'include est sur le même plan en mettant l'adresse sous la forme "/home/toncompte/www/.... "

Bon, ça m'apprendra à ne pas répondre trop vite... C'est tout de même bizarre ce truc. Vous avez remarqué les titres? Le fait qu'un robots.txt se retrouve indexé n'est-il pas le résultat d'une erreur quelconque? Par exemple, j'ai vu un site où un rewriting trop général perturbait l'accès à robots.txt.

Non. Pourquoi? Tu veux mettre des mots-clés dedans ?

Le formulaire ne marche que pour des pages qui n'existent plus. Pour déréférencer une page, le problème reste entier. Ce que dit Stéphane m'a étonné, parce j'avais l'impression que robots.txt marchait mieux que les META : moi, je ne vois pas passer le robot dans des répertoires interdits. Par contre pour déréférencer certaines pages (des gros plan d'images, parce que j'ai peur qu'il considère toutes ces pages comme du duplicate content), j'ai voulu ruser pour aller plus vite et je les ai renommées et mis les nouvelles en META "noindex,follow". Et bien, non seulement il a mis plusieurs mois pour m'enlever les pages en 404, mais en plus il m'a indexé quand même les nouvelles. Peut-être que mon erreur est de mettre 'follow'... Je ne sais pas pourquoi j'ai mis follow d'ailleurs...

Mutualisé chez qui ? quelle mutuelle ? Sinon: si c'est toi qui fais tourner awstats en local, alors oui c'est possible, c'est même assez facile Si ce n'est pas toi, il faut demander à ton hébergeur, mais la réponse est certainement 'non' si tu es sur plusieurs plans. (J'ai bien connu 5438765, c'est de ta famille ?)

Google respecte généralement bien les limitations robots.txt . Par contre, si tu as dans un premier temps laissé l'accès libre à un répertoire, puis ensuite limité l'accès par une instruction robots.txt (ou par un 'noindex'), là il va mettre des mois à enlever les pages de l'index. D'une manière générale, Google est très lent pour enlever des pages de l'index.

Oui, relance le transfert tout de suite. OVH rajoutera un an à ta date d'expiration. D'autre part, il me semble que l'on ne peut pas transférer un NDD juste avant son échéance, non ?

Je ne suis pas daltonien et j'ai aussi beaucoup de mal à lire les textes. La fonte est trop serrée et n'incite pas à la lecture.

D'un autre côté... si les BL ne sont plus affichés dans leur totalité et si les BL ne sont plus pris en compte comme avant, si les PR ne sont plus affichés, c'est peut-être entre autres à cause de ce genre de "partenariat"

Pour le PR qui ne change pas: Oui, c'est normal... A une époque, backlinks et PR étaient recalculés en même temps lors des fameuse "google dances" (ce qui avait pour invariable résultat de créer une fébrilité certaine chez les webmasters ces jours-là...) Maintenant, ce n'est plus le cas... On suppose que le PR est calculé assez souvent en interne, mais Google ne l'affiche plus. Les Backlinks ne sont plus affichés dans leur totalité... En fait, en y réfléchissant, on peut dire que tout fout le camp. On patauge, on conjecturise...

Ca semble monter un peu mais apparemment ce n'est pas encore cette fois que l'on va récupérer la liste complète de nos BL.

J'utilise la traditionnelle fenètre d'authentification windows.

Sous IE, tu peux aller dans Outils -> Gérer les modules complémentaires pour vérifier que le plug-in n'est plus chargé (c'est l'endroit où, par ex., on peut activer/désactiver Flash facilement)

Et sous IE6 toujours, l'aperçu avant impression est plutôt bouleversé, mais ça si j'ai bien compris c'est l'éternel problème...

Pour ma part, j'ai surtout eu une augmentation de Firefox au premier semestre, mais c'est stable depuis: (sites plutôt grand public) -Janvier 2004: explorer : 93% - Moz-Fox-Netscp : 4,8% ---- Juin 2004: explorer : 91% - Moz-Fox-Netscp : 6,4% Octobre 2004: explorer : 91% - Moz-Fox-Netscp : 6,0% Netscape étant passé de 2 à 1% sur la période et la répartition Mozilla/Firefox étant 50-50 maintenant.

Dan, ce que tu dis m'étonne car personnellement je fais comme Findel l'a décrit et cela fonctionne très bien (sur une page d'erreur speciale). Cela dépendrait-il de la configuration Apache ? (ou alors je n'ai pas compris le problème...)

Peu importe le moyen de paiement: à partir du moment où tu touches des revenus d'une activité, tu dois les déclarer et donc être dans un statut donné. Si tu n'envisages pas d'avoir des salariés, il vaut mieux te mettre en profession libérale. Tu peux compter grosso modo 25 à 35% de charges sociales diverses, avec un minimum qui doit se situer aux alentours de 2000 - 3000 euros (par an). Après, tu as l'impôt sur le revenu, mais ça c'est un peu comme tout le monde...

A mon humble (petit) avis... dans un tel cas, il faut mieux tout effacer et recommencer, c'est à dire renommer ton php pour pouvoir mettre ton php initial (ici index.php...!) en 404.

Pour faire simple: 1. Recopier le fichier awstats.mondomaine.conf en awstats.quotodien.conf (où 'mondomaine' est le nom de ton domaine si tu as personnalisé tes paramètres ou alors awstats.model.conf si tu as gardé le nom par défaut) 2. Dans le batch qui lance le calcul, tu inséres en fin de procédure les opérations suivantes: - supprimer le fichier awstats102004.quotidien.txt (ou '102004' est le numéro du mois en cours) - awstats.pl -config=quotidien -update - awstats_buildstaticpages.pl -config=quotidien (avec autres params utilisés pour ton calcul normal) C'est le principe global, maintenant il peut y avoir des variantes possibles suivant la façon dont tu lances le calcul des stats (une ou plusieurs fois par jour, en local ou sur le serveur, etc...) mais le principe est là: supprimer une fois par jour le fichier où awstats stocke ses résultats.

Un des fondements d'Awstats est de fonctionner en cumul mensuel. Si tu veux des infos plus précises sur le dernier jour, tu peux faire comme moi: en plus des traitements normaux, je fais tourner une fois avec un conf que j'ai appelé quotidien.conf: Avant de faire tourner, je delete le fichier txt produit au dernier traitement et comme cela je n'ai que les infos du jour.

Moi, c'est -cw qui change et lui seul. Il en manque toujours autant... (ce sont les nouveaux qui semblent s'ajouter) Sur les nouveaux sites, rien, nada, que ce soit sur -cw ou sur les autres.

Ce sont des gens qui surfent avec frontpage ou avec un soft qui cherche les extensions Fontpage. Y'en a toujours dans les logs, ça fait plein de 404. Rien à faire de spécial.

Tu auras noté que j'ai nuancé ma phrase, j'ai dit "ce que je pense être le meilleur", parce que j'espère avoir le droit de porter des jugements et d'avoir des opinions, sans avoir besoin de me référencer à un mouvement quelconque... Ce n'est pas très gentil d'ajouter cela... Le problème est différent: Beaucoup de boîtes font des sites au kilomètre, c'est le classique "qualité vs quantité". Et pour répondre à Laurent: Si... dans une certaine mesure, les standards tranchent (ou du moins ils donnent l'impression de trancher): il suffit de se référer au nom choisi "transitional".

Il doit certainement être loué à quelqu'un. Ils ont tous un nom de ce genre les dédiés d'OVH.

Merci pour le lien, mais je ne vois pas comment on "remonte la piste" dans le cas d'un serveur dédié. Dans ton exemple, on tombe toujours sur OVH, on voit pas à qui appartient le dédié, non ?