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

Si tu mets ceci dans le code de ces 70 anciennes pages, tu évites de ralentir ton serveur en surchargeant le .htaccess :

<?php 
header("Status: 301 Moved Permanently", false, 301); 
header("Location: http://www.new-domain.com/new-directory/new-file-name.html"); 
exit(); 
?>

Jean-Luc

<{POST_SNAPBACK}>

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,

    On va la faire simple:

        * trouvez 10 000 personnes intéressées par ce gadget et prêtes à payez 1 euros par accès IPv6 par mois (et à moi et je vous le fais,

        * trouvez 100 000 personnes intéressées par ce gadget et vous l'avez gratuitement.

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é ?

Pierre, tu fais allusion au blockrank là ? Attention, ça sort des labos de Microsoft, on ne sait pas déjà si c'est utilisé sur MSN, alors chez Google, cela fait un pas de plus qu'il vaut mieux, à mon avis, franchir avec prudence.

Même chose pour le PR négatif : un terme dangereux (genre sandbox) qu'un coup de rasoir d'Occkham peut éliminer. Tant qu'on a pas d'éléments sur un algo spécial, mieux vaut s'en tenir aux filtres "à l'ancienne" qui expliquent déjà pas mal de choses.

<{POST_SNAPBACK}>

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

10.4.17 416 Requested Range Not Satisfiable

A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)

When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type.

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.