Siddartha

Je ne jure plus que par Opéra .. Mais il est vrai que Safari même la bêta sous Win dépasse de loin en exécution Javascript et affichage HTML juste TOUS les autres navigateurs !!

Il existe Isapirewrite pour faire de la réécriture d'url avec un serveur IIS et de l'asp. http://www.isapirewrite.com/ et son tutoriel

Il te suffit juste de refaire une redirection supplémentaire (.htaccess ou httpd.conf) avec une règle de réecriture de style : RewriteRule /repertoire /repertoire/

Ah oui en effet sacré décalage, merci Arlette pour le PDF Merci également Monique pour les liens, je vais potasser tout ca pour finir de rendre le site ok pour tout le monde ! De ce que je lis sous IE5 Mac, ca va quand même être la mission !

Hello Dudu, Je n'ai malheureusement pas la version de Safari à te donner puisque j'ai utilisé le mac d'une autre société profitant de l'occasion pour tester. L'url est easyvoyage.com si tu as le temps de tester !

Bonjour, Je viens de passer l'ensemble de mes sites professionnels en Xhtml 1.0 strict. Le rendu est terrible en terme de clarté de code, facilité de maintenance et réduction du poids des pages, mais nous avons encore un souci : les versions en xhtml 1.0 strict s'affichent correctement sous IE, FF et du Opera, mais impossible d'avoir un affichage correct sous Mac avec IE ou Safari. Je n'ai pas réussi à trouver des docs explicites sur les rendus sous Mac. Je pensais (à tort) que le xhtml 1.0 strict passerait sans souci sur les Macs. Y'a t il des particularités à prendre en compte (dom, margin particulière ou autres ?) Merci d'avance !

Hello Cleden, Je ne te conseille pas de charger la mule même sur un sous domaine. Si le nom de domaine est déjà bien connu, fais indexer 'normalement' ton sous domaine, et attends quelques temps de voir comment réagit ton sous-domaine avant de charger la mule Le sous-domaine sera bien considéré comme un nouveau site, mais peut profiter de l'ancienneté d'un vieux domaine. Pour ce que tu appeles sandbox, je n'ai pas de réponses, mais charger la mule est la meilleure manière d'y tomber dedans

Et du coup, il surcharge encore plus son serveur qui a défaut d'exécuter des règles dans le .htaccess va exécuter du php d'abord puis faire la redirection. Thick, on parle de 70 rules ? Vas y sans inquiétude, arriver à la 3 000 ème, tu pourras t'inquièter, avant Mr Apache gère tranquillement ce genre de choses

Le warez, c'est mal

Ah bien vu .. Donc Google va se servir des utilisateurs qui personnalisent leur outil Google pour faire du comportemental et de l'estimation de trafic à la Alexa.. Je désactive immédiatement ce bordel chez moi aussi

Une fois n'est pas coutume, je vais prêcher pour ma paroisse, le tuto que tu cherches est là : dns wildcarding !

Tu me fais peur là Jan .. Je sais que Google tient compte depuis quelques temps du trafic des sites pour les positionner également, mais de là à afficher clairement les stats .. T'es sur que ca pas une extension ie ou ff qui te fait ca ? Sinon ==> Screenshot dédiouu !!!

Hello Fupap Apparemment, tu sembles être en voie de disparition .. Tu devrais vérifier avec un site:www.dns.com inurl:www.dns.com dns si beaucoup de tes pages sont dans ce cas ou pas. Si c'est seulement la home, c'est possible que tu sois victime d'une redirection malsaine d'un annuaire qui te référence et qui a une plus grande popularité ..

Et avec un petit ServerAlias *.domain.com domain.com Ca éviterait la création des deux VirtualHost non ? J'utilise uniquement cà de mon côté lorsque j'ai besoin de sous-domaines à la volée. Ca donnerait donc juste : <VirtualHost *> ServerName www.domain.com DocumentRoot /home/domain/www/ ServerAlias *.domain.com domain.com UseCanonicalName off ErrorLog /home/domain/logs/error.log CustomLog /home/domain/logs/access.log combined User domain Group www-data ScriptAlias /cgi-bin/ /home/domain/cgi-bin/ <Directory /home/domain/www/> AllowOverride All Options -Indexes +ExecCGI Order Deny,Allow Allow from all </Directory> </VirtualHost> J'ai enlevé le "VirtualDocumentRoot /home/domain/$1 qui est une directive pour le mod_vhost_alias mais dont tu n'as pas besoin pour faire ce que tu veux si j'ai tout bien compris

Disons que pour le premier SES à Paris, on était en droit de s'attendre à des ingénieurs Google, Yahoo ou Msn qui aurait détaillé certaines parties techniques et pas les intervenants habituels en effet .. Sauf qu'on est en France, aucun 'vrai' technicien aux prises de l'algo directement à part chez Msn (mais prévu, je ne sais pas si encore arrivé), et que donc, on va avoir du blabla commercial alors que les SES sont réputés pour être technique, ce qui manque cruellement en France. Résultat, un non évènement finalement, qui ressemble fortement, comme l'a noté Gilbert, a du déjà vu .. A 900 euros l'évènement, ca sera sans moi

Cette option supprime l'action d'un filtre portant sur l'ancienneté du site, mais c'est tout. La position que tu vois donc avec cette option n'est donc pas ta position réelle. Pour tes positions et vu le yoyo ambiant de ce moment, je patienterais encore un peu avant de prendre une décision ou d'en tirer une quelconque conclusion.

Ce n'est pas que sur invitation. La plupart des gros annonceurs en liens sponsorisés ont été contacté par MSN et dans quelques jours, vous pourrez voir les premiers annonceurs en live sur leur solution de liens sponsorisés. Je ne sais pas si j'ai le droit de dévoiler la date ou pas, mais il ne s'agit plus que de quelques jours ...

Apparemment ton problème ne vient pas de là .. Par contre, si ton hébergeur à changé quelque chose au niveau des redirections et cie, ca peut expliquer le changement. Il faudrait que tu nous copies ici le contenu de ton virtual host Apache pour tonblog.com. Le problème est plutôt là je pense.

Bonjour, C'est ce qu'à annoncé Rani Assaf, directeur technique d'Iliad et donc de Free. Les Freenautes l'ont pris au mot et tous les passionnées de technique ont déjà signé la pétition (dont je fais partie ) ! Si vous être Freenaute, Freeboxé ou Freeboxable et que vous êtes aussi intéressé, il vous suffit de venir signer la pétition sur le site IPv6 pour Tous ! ! Signez la pétition !

Le fichier .htaccess n'est qu'une extension du fichier de configuration Apache : httpd.conf. Donc si tu ne veux pas utiliser l'option .htaccess, il ne reste plus qu'à rajouter ces lignes dans ton httpd.conf .. Ce qui suppose que tu y ai accès et que tu as un serveur dédié ?

Je ne faisais pas forcément allusion au blockrank, mais effectivement, le phénomène que j'observe serait similaire. Google ne s'intéresse, encore une fois 'semble t il', qu'à une partie de la page html selon le type de mot-clé. Ainsi, j'ai le sentiment que GG arrive à décomposer dans une structure html ou dans un contenu rédactionnel (le contenu et le contenant) les parties rédactionnelles censées être les plus pertinentes sur la recherche effectuée. Pour cela, ils peuvent se servir des élèments servant à délimiter le contenu (toute la structure html : par exemple un <div> ou un <table> remplie de links une fois dans un document est forcément un menu ou une liste de données tabulaires servant à structurer le contenu donc ayant un rôle particulier par rapport à l'ensemble du contenu du site). Il est également facile pour eux de calculer sur l'ensemble d'un site les parties html et texte redondantes sur plusieurs pages afin de les identifier et surtout de les classer comme : élèments de navigation, contenu, contenu moins important, element structurant le contenu, etc. Et du coup, google attribuerait le positionnement d'un site en fonction du bloc de contenu qu'il jugerait le plus pertinent d'aprés son analyse de la structure html et du rédactionnel. Bien sur, leur analyse a ses limites, ce qui provoque des effets de bords ou on peut observer des sites positionnés sur des requêtes hyper concurrentielle avec un simple mot-clé contenu une fois dans un footer ou un texte sans grande importance. Concernant le PR négatif, le terme est peut être un peu fort. Mais clairement, il n'est pas logique que des pages sans contenu se tapent un PR de 3/4 sur des nouveaux sites alors que ce même site avec des pages disposant d'un contenu beaucoup plus dense type tête de rubrique ne se voit qu'attribuer un PR de 2 ou 1. On pourrait se dire que finalement plus on rentre dans l'arborescence d'un site, plus Google estime que le contenu des pages est ciblé et donc plus pertinent, mais lorsque ces pages disposent d'à peine 3/4 lignes de textes, là je crie au loup De manière générale, à observer sur les pages à fort contenu, l'attribution du PR de ces pages devient complètement aléatoire et ne répond à plus aucune logique. Pour moi, c'est la preuve que son attribution est faite de manière différente, de de ce que j'ai vu, je penche en effet pour une attribution du PR, bien évidemment en fonction des BL's, mais aussi par la structure du code html, sa redondance dans un ensemble (toutes les pages d'un site) mais également le code en lui même utilisé ou on peut être pénalisé par l'utilisation de certaines balises. (deux h1 dans une page par exemple est forcément un élèment pénalisant du coup). Par ces observations, au final, je m'aperçois que Google a su faire évoluer son outil de manière radicale et qu'aujourd'hui, toutes les techniques de référencement classiques sont 'gérées' par Google. Je rejoins Jan du coup pour dire qu'effectivement et heureusement, il nous reste encore l'imagination, qui sans limite, devrait nous permettre de trouver de nouvelles techniques.

Un hébergeur qui fait du mutualisé est quand même facilement identifiable par des gens capable de monter un algo comme celui de Google. L'algo pourrait trés bien faire la différence seul et de manière automatique entre une ip qui héberge 3.000 sites et dns différents et une ip qui en héberge moins. Et de là, traiter de manière différente les sites hébergés chez Free ou OVH et les sites hébergés en plus petit nombre sur leur dédié ou autre. Si on couple cette première catégorisation avec ensuite les multiples filtres qu'ils sont capable de mettre en place sur le nb de bl vers un site, le % de lien qui contiennent tel mot clé, le comparer aux sites/annonceurs du même secteur, etc. (comme c'est déjà le cas sur les Adwords ou de multiples moyennes particulières et générales sont calculés) La vision du marché du référencement et surtout ceux qui abusent deviennent facilement identifiables et d'ailleurs le problème n'est pas l'identification d'un spammeur, mais de la manière dont on doit traiter son cas par rapport à un environnement donné. Et là, lorsque Google met en place une action contre une technique ou un élèment qu'ils ne veulent pas voir sur leur outil, on obtient des effets de bords tolérables ou non sur d'autres sites. A eux ensuite de décider ou pas si cette tolérance, ce taux d'erreurs est acceptable ou pas et de mettre en place le filtre correspondant.

La répartition du PR ne se fait plus en fonction des BLs mais aussi en fonction du contenu de la page et de la structure html adoptée. Il semblerait également que le PR négatif soit une réalité. En plus des pénalités classiques pour suroptimisation par exemple ou la page disparait de l'index jusqu'à ce que vous l'ayez désoptimisée, des élèments techniques, cachées ou répétées dans une page, peut vous faire perdre du PR. En tous les cas, encore une fois PR et backlinks ne rime plus avec positionnement bien que les BL's représentent un des critères les plus forts encore de leur algo.

Hello -ZN-, J'utilise celui de Wikipédia : Mediawiki. J'en suis satisfait pour l'utilisation que j'en fait (repository personnel) et c'est bien verouillé niveau sécu !

Voici ce que dit la rfc 2616 : http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Apparemment, si tu reçois une requête incluant des champs Range et qu'aucun n'est spécifié dans tes pages, ca foire. Mais j'avoue ne pas tout comprendre sur cette erreur.