Jeanluc

Bonjour, Comme l'a dit Dadou, les caractères accentués sont possibles dans certains noms de domaine, ceux en .com ou .eu. Je n'ai rien vu pour les .fr. L'encodage des accents dans les noms de domaine ne se fait pas avec les %... contrairement au reste de l'URL. Par exemple, bébé.eu s'encode xn--bb-bjab.eu (source: Gandi). Etant donné les habitudes prises avec les noms de domaine sans accent et l'encodage surprenant des accents, peu de monde s'intéresse aux noms de domaine accentués pour le français. Il y a plus d'info technique sur le sujet sur Wikipedia, Nom de domaine internationalisé. Jean-Luc

C'est peut-être hors sujet, mais moi, j'ai un problème avec le nom du site. Je ne capte rien dans le mot "crapule" qui me fasse penser à un petit bébé mignon. Il ne me viendrait pas à l'idée d'acheter des vêtements d'enfant chez quelqu'un qui me parle de "crapule". Par comparaison, "nounoumap" dont parle Arlette est un mot créé pour l'occasion, mais parfaitement dans le ton. Il se pourrait évidemment que ce mot presque grossier en Belgique ait, en France, un côté affectueux que je ne perçois pas. AMHA. Jean-Luc

La méthode proposée fonctionne aussi bien pour 100 ou 1000 redirections si on ajoute les lignes nécessaires dans .htaccess. Si certaines redirections ne fonctionnent pas, c'est qu'elles n'ont pas été ajoutées correctement. Il faudrait plus de détail. Les redirections faites en PHP peuvent aussi être des redirections 301. La question est de savoir s'il existe des règles qui permettent d'automatiser le processus plutôt que d'encoder séparément la redirection de chaque adresse. Dans ton cas, y a-t-il des règles simples qui permettent de déterminer la page de destination à partir de l'adresse de certaines pages à rediriger ? Jean-Luc

Bonjour, Il faut aller vers une solution de ce genre: RewriteCond %{QUERY_STRING} ^reference=X&tp=Y&cdlg=fr$ RewriteRule ^Rep/anciennepage.html http://nouvndd.com/lapageX.htm? [L,R=301] S'il y a beaucoup de pages à rediriger, ça va être lourd. Cela pourrait être plus pratique de faire les mêmes redirections en PHP. Jean-Luc

@Leonick, Si cet hébergeur disparu avait aussi été le registrar, la récupération du contrôle complet des deux noms de domaine n'aurait pas été simple. Jean-Luc

Je croyais que tu avais deux sites. Il te reste à comparer les offres de différents hébergeurs (bases de données, espace disque, adresses email,...) selon tes besoins. Il n'y a de toute manière aucun problème du côté de Gandi, mais vérifie que ton nouvel hébergeur accepte que plusieurs noms de domaine pointent vers ton site. Jean-Luc

Bonjour, C'est dans ces cas-là qu'on se félicite d'avoir pris les noms de domaines ailleurs que chez l'hébergeur! Puisqu'il s'agit d'un site professionnel, il ne faut pas prendre un hébergement gratuit qui n'aura aucune obligation envers toi. Prends un hébergement mutualisé multidomaine (puisque tu as deux sites). On en trouve de très corrects à partir d'une vingtaine d'euros par an (Easy-Hebergement, OVH, PhpNux,...). Jean-Luc

Je pense qu'il y a une faute de frappe. On s'attendrait plutôt à voir RewriteCond %{REQUEST_FILENAME} !-f de sorte que tous les accès soient renvoyés sauf ceux qui aboutissent à un fichier, ce qui est habituellement le cas des images, css,... Jean-Luc

Bonjour et bienvenue sur Webmaster-Hub, Je viens de tester la redirection du deuxième résultat de recherche et c'est une 302: là tu dis à Google de conserver l'ancienne adresse. Il faudrait commencer par changer ça. Jean-Luc

Du côté d'AWStats, le vocabulaire est défini ici: http://awstats.sourceforge.net/docs/awstats_glossary.html (en anglais). Jean-Luc

Bonjour, D'accord avec les commentaires précédents. J'ajouterai qu'un outil de stats n'est jamais parfait et qu'il est important d'en comprendre les limites. AWStats: - compte comme visiteurs les robots qui ne sont pas dans sa liste de robots (utiliser la dernière version d'AWStats permet d'avoir la liste la plus à jour possible) Google Analytics: - ne voit pas les visiteurs qui ont désactivé JavaScript - est dépendant du bon fonctionnement de la connexion à son serveur - ne voit pas les visiteurs qui viennent sur les pages où on n'a pas mis de tag (c'est évident, mais on en oublie parfois) - ne donne pas de stats sur les images affichées, fichiers téléchargés,... (*) - ne voit pas les robots (*) (*) sauf si on ajoute du code qu'on fait exécuter à chaque affichage d'image, téléchargement, visite de robot,... Donc oui, les résultats seront différents et c'est normal ! Jean-Luc

Bien entendu et je ne prétends pas tout savoir non plus, mais on ne rend pas service quand on présente comme vérifiées des choses qui ne le sont pas. Je me limiterai à deux exemples: 1. Xenu Ton robots.txt contient: User-agent: Xenu's Link Sleuth 1.1c Disallow: / User-agent: Xenu's Disallow: / Le site officiel de Xenu dit: Donc robots.txt n'a aucun effet sur Xenu. 2. Turnitin Ton robots.txt contient: User-agent: TurnitinBot/1.5 Disallow: / User-agent: TurnitinBot Disallow: / La FAQ de Turnitinbot dit: Donc pour Turnitin, pas besoin du numéro de version. Jean-Luc

Bonjour, C'est une liste que tu as créée toi-même ou que tu as recopiée ? Si c'est une copie (comme je le pense), ce serait sympa d'indiquer la source. Je ne vais pas y aller par quatre chemins. Au départ, ce genre de liste a été créée par une personne compétente, puis modifiée par des personnes qui le sont moins. Finalement, c'est devenu du n'importe quoi. Questions: - Pourquoi recommandes-tu de mettre ces lignes "en premier" ? En quoi la position des lignes dans robots.txt a-t-elle de l'importance ? - Pourquoi indiques-tu un numéro de version pour certains robots ? As-tu une information précise qui indique que cela est utile ? - Pourquoi ne regroupes-tu pas les différents user-agent ? Jean-Luc

Patrick, Tu obtiens un code 304 à cause des If-Modified-Since et If-None-Match dans ta requête. J'imagine que lors du premier accès, le code était bien 404, mais cela n'a pas empêché ton outil de mémoriser la page (bizarre). Si tu refais l'essai sans ces options, tu obtiendras un code 404. Quel outil as-tu utilisé ? Peut-être un plugin, ce qui expliquerait le comportement de l'outil qui ne distingue pas les accès normaux du navigateur des accès avec l'outil activé. Jean-Luc

Bonjour, Le serveur qui abrite ce site envoie, en même temps, un code d'erreur et un contenu qui semble correct. C'est un problème à corriger pour le gestionnaire du site ou l'administrateur du serveur. Jean-Luc

Bonjour, Je n'ai pas d'explication, mais je confirme que chez moi aussi, sur ton site, pas de pub Google avec Firefox alors qu'elles apparaissent avec IE ou Opera. Jean-Luc

Je veux dire que le temps passé à modifier les .htaccess et/ou les scripts, le fait que cela compliquera éventuellement la maintenance future, l'impact de ces modifications sur les performances, tout cela représente un coût à comparer au bénéfice retiré de l'opération. Il faut aussi savoir qu'il est impossible d'éliminer tous les mauvais robots. Il y en aura quelqu'uns qui continueront à passer à travers les mailles du filet. Et les développeurs de ces robots font évoluer leurs techniques de sorte que les contremesures devront aussi évoluer pour garder le même niveau d'efficacité Jean-Luc

Ce sera obligatoirement: moteurs désirés + navigateurs désirés. Cela va faire du monde et cela ne me semble pas gérable au niveau du .htaccess. Au niveau du robots.txt, on s'adresse uniquement aux robots et on peut y placer une liste de robots autorisés à l'exclusion de tout autre. La difficulté ici est que seuls les robots "honnêtes" respectent robots.txt et les plus nuisibles n'en tiendront aucun compte. Il faut bien considérer le rapport "coût lié à la présence de ces robots" / "coût pour les éliminer". Avec les tarfis de bande passante et les prix d'hébergements actuels, il y a pas mal de cas où le mieux est d'ignorer ses robots non désirés. Jean-Luc

Merci. Effectivement ça règle le problème. Jean-Luc

Bonjour, J'ai désactivé l'"éditeur visuel" de WordPress. J'utilise donc l'éditeur basique qui me permet d'insérer des tags HTML où je veux quand je veux (enfin, presque). Cet éditeur affiche une fenêtre d'une dizaine de lignes. C'est suffisant, mais malheureusement il remet à tout bout de champ le début de la page au sommet de la fenêtre. Donc quand je suis en train d'écrire la 20 ème ligne, si j'arrête de taper pendant quelques secondes, cette ligne disparaît tout à coup pour être remplacée par le début du texte. J'ai ce problème sur tous les sites WP que j'édite de cette manière. Ce n'est donc pas lié à l'emploi d'un thème ou d'un plugin particulier. J'utilise Internet Explorer. Le problème n'est pas présent avec Firefox ou Opera, mais je souhaite continuer à éditer sous IE. Quelqu'un a-t-il une astuce, une suggestion pour éviter ce problème ? Jean-Luc

Ce n'est pas exact et ma description ci-dessus n'est pas correcte parce que je pensais que tes sites étaient hébergés chez OVH. En résumé, - chez l'hébergeur, tu dois associer chaque nom de domaine hébergé à un répertoire - l'hébergeur t'indique alors les DNS correspondants à chaque domaine - ensuite, chez le registrar, tu dois associer chaque domaine aux DNS indiqués par l'hébergeur Jean-Luc

Bonsoir, Disons que tu possèdes les domaines example.es, example.de et example.fr. Chez ton hébergeur (OVH), si ce n'est pas encore fait, tu dois ajouter les différents domaines dans le Manager. Tu vas dans le domaine principal, tu choisis "Domaine & DNS", puis "Multi-Domaines", puis "Création" et tu ajoutes les différents domaines (example.es, example.de et example.fr). Tu les fais tous pointer vers le même répertoire puisque tu as décidé que ton script aiguillerait les requêtes en fonction de la langue (= en fonction du domaine), puis tu fais pareil avec les versions avec www (www.example.es, www.example.de et www.example.fr). Après quelque temps, les différents domaines ajoutés apparaissent dans la colonne de gauche du Manager. Pour chaque domaine, tu dois aller voir quels sont les serveurs DNS. Pour cela, tu cliques sur le domaine choisi dans la colonne de gauche, puis sur "Domaine & DNS, puis sur "Zone DNS" et tu notes les deux valeurs correspondants à "NS". Tu passes alors chez ton registrar (je ne sais pas si c'est OVH ou une autre firme) et, pour chaque domaine, tu indiques que tu ne veux pas de redirection, mais que tu veux choisir les DNS et tu indiques, pour chacun, les deux valeurs que tu as notées chez OVH. Le résultat de cette opération n'est pas instantané: la propagation des DNS peut aller très vite ou prendre plusieurs jours, mais si tu as suivi ces instructions, tes différents domaines vont pointer vers le même répertoire chez OVH. Pour tester le nom de domaine en PHP, utilise $_SERVER['HTTP_HOST']. Jean-Luc

Rien de plus simple. Je pense que tu te compliques la vie avec toutes ces redirections que tu voulais faire. Voici ce que je ferais: - je prends un hébergement multidomaine - je fais pointer mes domaines .fr, .es, .de, ... vers ce multidomaine - pour chaque requête, le script regarde l'extension du nom de domaine et envoie le contenu dans la langue correspondante C'est donc très simple et ici il n'est pas question de redirection (tu n'en as pas besoin), ni de test de la langue du navigateur ou de géolocalisation du visiteur. Jean-Luc

Bonjour, Il est même techniquement impossible que ces fichiers soient gardés secrets et, en même temps, accessibles au navigateur des visiteurs (c'est à ça qu'ils servent!). Par contre, cacher le contenu des répertoires est une bonne pratique. Cela se fait au moyen de la config Apache ou d'un fichier .htaccess : Options -Indexes Jean-Luc

Bonjour et bienvenue sur Webmaster-Hub, Le plus simple est de supprimer les redirections faites dans le Manager OVH et d'ajouter un .htaccess dans le répertoire racine de chaque site. Pour le contenu du .htaccess, voir ma page Plusieurs noms de domaine pour un site qui explique tout (enfin, j'espère). Jean-Luc