Référencement



sophie
3 juillet 2010

Apparences trompeuses pour Google Analytics

J’étais en train de préparer un rapport de Google Analytics et je comparais mes données à celles d’il y a 15 jours… Me voilà donc en comparaison de la source de trafic.

Hum je regarde vite vite mes copie d’écran et me dis que j’ai perdu un peu de trafic de moteur de recherche. Puis en écrivant mon analyse et en reprenant les chiffres je me rends compte que c’est plutot l’inverse… J’ai gagné 7%, comment ce fait-il que j’ai cru voir l’inverse ???

La réponse est simple. Au lieu d’attribuer une couleur à un type de source Google a attribué la couleur au %.

trafic google analyticstrafic google analytics

Alors ouvrez-bien les yeux pour ne pas vous tromper.





François Viens
23 février 2010

Quelques bases du URL Rewrite

Pour des questions SEO, il est intéressant de maîtriser certaines techniques de réécriture d’adresses sous Apache avec les fichiers .htaccess. Si l’adresse ne change pas dans la barre d’adresse du navigateur, on parle de redirection interne. Si l’adresse change, on parle de redirection externe, souvent des redirections retournant le code HTTP 301 indiquant que la ressource est déménagée à la nouvelle adresse de façon permanente. Les redirections internes sont les plus complexes à comprendre car intangibles, elles permettent de créer une structure complètement virtuelle pour un site Web qui lui serait généré à partir du même fichier PHP. WordPress en est un bon exemple!

Il faut garder en tête que le mod_rewrite est appelé chaque fois qu’une demande HTTP est faite sur un fichier. Il faut donc être concis et s’assurer des limites de notre fichier .htaccess pour éviter des comportements incompréhensibles. Le plus complexe dans le URL Rewriting c’est les expressions régulières. Plusieurs règles de base peuvent être mises en place sans trop de connaissance en expressions régulières mais la science des URL Rewriting prend toute son ampleur lorsqu’on y ajoute un peu de « pattern matching »!

Le texte ci-dessous représente principalement une traduction des passages les plus intéressants des 2 sources citées à la fin de l’article.

Contenu de base du fichier .htaccess

Un fichier .htaccess de réécriture d’adresse de base devrait contenir ces lignes. La ligne Options +FollowSymlinks n’est que très rarement utile car elle permet de suivre les liens symboliques à l’intérieur des bornes définies par le <Directory> de votre serveur Apache. En contrepartie, chez certains hébergeurs, la présence de cette ligne donnera une erreur interne de serveur (500). La solution la plus simple est de laisser la ligne si le serveur ne retourne pas d’erreur, s’assurant que d’éventuels besoins seront comblés automatiquement ou de commenter la ligne si le serveur retourne une erreur. Pour faire un commentaire dans un fichier .htaccess, ajoutez simplement un # en début de ligne.

Options +FollowSymLinks
 
RewriteEngine On
RewriteBase /

Dans le cas où votre projet est dans un sous-répertoire, il faut ajuster le RewriteBase en conséquence pour que les règles commencent à l’intérieur de ce répertoire.

Flags

Mais qu’est-ce que c’est ces lettres entre crochets []? C’est des « flags » indiquant certaines instructions supplémentaires au moteur de réécriture d’adresse d’Apache. En voici une liste des principaux « flags » :

  • R=code : Indique une redirection. Le code est le code HTTP que vous désirez retourner. Souvent le code 301 est utilisé pour indiquer que l’adresse demandée n’existe plus et a été remplacée par la nouvelle adresse. Si aucun code n’est spécifié, le code 302 sera retourné, celui-ci indiquant qu’il s’agit d’une redirection temporaire.
  • L : Indique que si cette règle est respectée, ne pas tenter d’autres règles, arrêter immédiatement avec celle-ci. Très utile pour permettre de mettre les règles les plus précises en début de fichier allant vers les moins précises et arrêter le traitement aussitôt qu’une règle correspond à l’adresse demandée.
  • NC : Fait en sorte que la règle ne doive pas nécessairement respecter la case (majuscule, minuscule)
  • QSA : Permet de conserver les paramètres d’une adresse et d’en ajouter d’autres. Par exemple, avec la règle suivante RewriteRule fr/nouvelles.html$ nouvelle.php?lang=fr , si l’URL demandé est fr/nouvelles.html?page=2 , nouvelle.php n’aura pas accès à la valeur du paramètre page, seulement la valeur de lang. Si au contraire on ajoute [QSA], les paramètres lang et page seront disponibles dans le fichier PHP.
  • S=num : Permet de sauter les « num » prochaines règles si la règle en cours est respectée. Permet de faire une sorte de IF ELSE bouetteux… la dernière règle du premier S étant S=X, X étant le nombre de régles à sauter dans la portion « else ».
        (if)
        RewriteRule … [S=2]
           RewriteRule …
           RewriteRule … [S=1]
        (else)
           RewriteRule …
        (endif)
        Lecture normale des règles suivantes…    
  • NE : Permet d’éviter d’escaper des caractères spéciaux lors d’une redirection ce qui arrive automatiquement sinon. Ainsi, RewriteRule /test/(.*) /page?q=repertoire%3d$1 [R,NE] redirigera ‘/test/bobo’ sur l’URL suivante ‘/page?q=repertoire=bobo’.
  • N : Permet de relancer le traitement des règles de réécriture, mais pas avec l’URL de départ mais plutôt avec l’URL transformé par les premiers passages… À éviter, risque de boucles infinies.
  • F : Permet de forcer le retour d’une erreur HTTP 403 : Forbidden sur une page ou un ensemble de page respectant une RewriteConds
  • B : Apache traduit les caractères « url escapés » en caractère standard. La règle RewriteRule ^(.*)$ index.php?show=$1 réécrira /C++ vers index.php?show=/C++ mais va également réécrire /C%2b%2b vers index.php?show=/C++ car les + auront été « dé-escapés »! L’utilisation du flags B vous assurera que /C%2b%2b deviendra index.php?show=/C%2b%2b et /C++ restera index.php?show=/C++.
  • C : Permet de lier une règle avec la règle suivante et ainsi de suite si le C est présent sur les règles suivantes. Si la règle est respectée, le traitement continue de façon normal et le flag est ignoré. Si la règle n’est pas respectée, toutes les règles liées à celle-ci ne seront pas considérées.
  • CO=NAME:VAL:DOMAIN[:LIFETIME[:PATH[:SECURE[:HTTPONLY]]]]’ : Permet de créer un cookie! Il s’agit d’une fonctionnalité intéressante mais rarement utilisée… Le prochain développeur à travailler sur votre projet risque de chercher l’emplacement de la création du cookie longtemps dans le code! NAME est le nom du cookie, VAL sa valeur, DOMAIN le domaine « .test.com » sur lequel le cookie doit être actif, LIFETIME la durée de vie en minute, PATH le répertoire où le cookie est effectif, SECURE « true » ou « 1″ fait en sorte que le cookie est effectif seulement sous https, HTTPONLY « true » ou « 1″ fait en sorte que le cookie n’est pas manipulable par du javascript.
  • NON COUVERT ICI : DPI, E=VAR:VAL, G, H=Content Handler, NS, P, PT, T

Forcer la présence des www

Bien que les www. ne sont pas du tout nécessaires pour qu’une page Web fonctionne, les internautes néophytes sont tout de même habitués à leur présence. Le plus important à retenir est que www. agit de façon similaire à un sous-domaine (site.domain.com). D’avoir du contenu accessible avec et sans les www. peut causer un problème de dupplication de contenu ce qui n’est pas idéal pour les moteurs de recherche. Une façon d’éviter est de regarder combien de pages sont présentes dans les index des moteurs de recherche avec et sans les www. (site:domain.com). S’il y a plus de pages avec www., forcez la présence du www., sinon, retirez les www. . Dans les 2 cas, faisant des redirections retournant le code HTTP 301 (déplacement permanent), les adresses fautives seront éventuellement remplacées dans les index des moteurs de recherche.

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^www.domain.com$ [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

Retirer les www

Il est parfois préférable de se départir des www pour rendre les adresses plus courtes. En tant que tel, les www. n’ajoute aucune valeur. Si un site n’est pas déjà bien référencé dans les moteurs de recherche, il peut être intéressant de forcer le retrait des www.

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^domain.com$ [NC]
RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]

Forcer la présence du www sans « hardcoder » le domaine

Il peut parfois arriver que plusieurs domaines soient effectifs sur un même compte d’hébergement, bien que c’est en gérale une mauvaise pratique que le même contenu puisse être accessible à partir de différents noms de domaine. Dans un tel cas, plutôt que d’inscrire le nom de domaine dans la règle forçant la présence du www., une règle générale peut être mise en place :

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^www.[a-z-0-9]+.[a-z]{2,6} [NC]
RewriteCond %{HTTP_HOST} ([a-z-]+.[a-z0-9]{2,6})$     [NC]
RewriteRule ^/(.*)$ http://%1/$1 [R=301,L]

Arrêter des loops de redirections

Bien que non recommandé, il peut arriver que nos règles créées des boucles infinies de redirections sur le serveur. Partant du principe que chaque appel HTTP fait une requête au fichier .htaccess, vous pouvez altérer ce fichier avec le code suivant pour arrêter la boucle.

RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [L]

Déjouer la cache des navigateurs

Trop souvent on doit dire « Avez vous vidé votre cache? »… Une façon de régler ce problème est d’utiliser une règle de réécriture d’adresse permettant de conserver toujours le même nom de fichier pour les feuilles de styles et les fichiers javascript sur le disque mais d’ajouter un numéro de version dans le nom de fichier dans le HTML. Ainsi /skin/js/script-VERSION.js pointe vers /skin/js/script.js et /skin/css/styles-VERSION.css vers /skin/css/styles.css

RewriteRule ^skin/(js|css)/([a-z]+)-([0-9]+).(js|css)$ /skin/$1/$2.$4 [L]

Retirer le Query_String

Il est très fréquent de voir des sites pour lesquels page.html et page.html?param=bobo affiche le même contenu… Ceci peut causer des problèmes de contenu duppliquer et nuire au référencement de votre site Web. Une façon de régler le problème est de se départir du QUERY_STRING et il suffit simplement d’ajouter un ? à la fin de votre règle.

RewriteRule bobo.html$ bobo.php? [R=301,L]

Documents sauvegardés en base de données

Vous pouvez simuler la présence d’un document PDF ou Word ou autres dans un répertoire donné et utiliser cette règle pour appeler un script en charge de servir le document en provenance de la base de données /getdoc.php

RewriteRule ^docs/(.+)$  /getdoc.php?file=$1.pdf [L,NC,QSA]

Afficher par défaut dans la langue du visiteur (navigateur)

Il arrive très souvent qu’on doive afficher le contenu d’un site multilangue dans la langue du navigateur du visiteur par défaut. Une façon d’y parvenir est d’utiliser le « flag » ENV permettant d’assigner une variable d’environnement.

RewriteCond %{HTTP:Accept-Language} ^.*(es|fr|en).*$ [NC]
RewriteRule ^(.*)$ - [env=prefer-language:%1]

On est fermé! Permettre de bloquer l’accès à un fichier à une période donnée de la journée.

Concept à utiliser que si nécessaire… Rendre indisponible du contenu de votre site à une certaine heure pourrait faire en sorte que ce contenu soit retiré des index des moteurs de recherche si ceux ci visitent votre site à cette heure.

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
# S'il est 17h, on ferme
RewriteCond %{TIME_HOUR} ^17$
RewriteRule ^.*$ - [F,L]

Changer les underscore (_) par des tirets (-)

Pour des raisons SEO, les tirets sont plus efficaces que les underscores car ils permettent de séparer une chaîne de caractères en plusieurs mots, plutôt que d’être considéré comme un seul mot. Pour cette raison, l’utilisation de underscrore dans les URL est généralement à éviter. La régle suivante fonctionne pour des URL présentant jusqu’à 5 underscores…

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
 
RewriteRule !.(html|php)$ - [S=4] # on skip les 4 règles suivantes si ce n'est pas un appel à du HTML ou PHP
RewriteRule ^([^_]*)_([^_]*)_([^_]*)_([^_]*)_(.*)$ $1-$2-$3-$4-$5 [E=uscor:Yes]
RewriteRule ^([^_]*)_([^_]*)_([^_]*)_(.*)$ $1-$2-$3-$4 [E=uscor:Yes]
RewriteRule ^([^_]*)_([^_]*)_(.*)$ $1-$2-$3 [E=uscor:Yes]
RewriteRule ^([^_]*)_(.*)$ $1-$2 [E=uscor:Yes]
 
RewriteCond %{ENV:uscor} ^Yes$
RewriteRule (.*) http://domain.com/$1 [R=301,L]

Réduire le vol de bande passante

Il n’est pas rare de voir des sites faire référence directement à une image, une animation flash ou autre mais de façon intégrée à leur contenu. Le résultat est que vous fournissez la bande passante pour le média transmis.

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www.)?domain.com/.*$ [NC]
RewriteRule .(gif|jpg|swf|flv|png)$ /dev/null [R=302,L]

Redirection pour une adresse IP précise

Il arrive souvent qu’on doive ajouter une règle dans un fichier .htaccess et il peut être tentant de la faire directement sur le serveur… Bien entendu, dans certains cas, une erreur de manipulation peut causer des problèmes! C’est pourquoi il peut être intéressant de tester une règle en spécifiant notre adresse IP dans une condition préalable… Ainsi, seulement les requêtes en provenance de cette adresse IP seront considérées.

RewriteCond %{REMOTE_ADDR} ^1.1.1.1$
RewriteRule ^$ http://www.domain.com/testderedirectionjustepourmoi.html? [L]

Contrôle du comportement du HTTPS

Je trouve pratique qu’une section sécurisée d’un site ne soit pas simplement sur https://www.lesite.com… Par exemple, dans le cas de paiement en ligne pour une boutique, l’utilisation d’un sous-domaine secure.lesite.com, lui étant disponible seulement sous HTTPS me paraît un scénario beaucoup plus sympathique… Les règles suivantes permettent d’avoir un contrôle sur une zone bien précise pour le HTTPS et s’assurent que cette zone n’est disponible qu’avec HTTPS

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} secure.lesite.com(.*)$
RewriteRule ^(.*)$ https://secure.lesite.com/$1 [R=301,L]

RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} !^secure.lesite.com
RewriteRule ^(.*)$ https://secure.lesite.com/$1 [R=301,L]

Page 404

Le fichier .htaccess peut également servir à définir une page d’erreur 404 par défaut.

ErrorDocument 404 404.html

Sources





marie-andree
8 décembre 2009

Mise au point sur les splash pages (Page tunnel)

Il y a 20 ans, fumer était « in » et bien vue. Maintenant, tout le monde sait que fumer n’est pas bon. Autrefois, avoir une splash page (ou page tunnel, page d’entrée, page d’introduction) était à la mode. Maintenant, il est prouvé que ce genre de pratique n’est pas recommandé (sauf pour certains cas précis). Pourquoi faire cette analogie? Parce qu’il existe encore des gens qui veulent des splash pages pour les mauvaises raisons.

Une splash page peut être utile. En voici quelques exemple :



1- Afficher une mise en garde





2- Afficher un message important ou une nouveauté





3- Choisir une langue et/ou un pays





4- Choisir une version et/ou une préférence





5- Présenter une image très artistique





6- Afficher un mode d’emploi





En dehors de ces exemples, une splash page peut s’avérer dommageable.

La splash page n’a pas très bonne réputation parce qu’elle…

… offre habituellement très peu de contenu textuel et un accès limité aux autres pages du site. Par conséquent, elle diminue considérablement le référencement.

retarde d’une page l’accès à l’information. Elle oblige à cliquer pour accéder à la page d’accueil (la page la plus importante). Il y a donc un clic de trop. Let’s get to the point!

… peut être longue à télécharger et du même coup, faire fuir le visiteur.

nuit à la liberté de l’usager. Il doit obligatoirement passer par cette page.

n’est pas toujours appréciée des visiteurs. La visite débute donc avec une note négative.

… présente souvent une animation flash que les visiteurs s’empressent de skipper!

En conclusion, une splash page devrait être évitée à moins d’avoir une bonne raison.






marie-andree
19 novembre 2009

Une fois pour toute : Mythes et réalités de la balise META DESCRIPTION et META KEYWORDS

Il m’arrive encore de croiser des clients qui me demandent d’ajouter des meta tags dans leur site Web pour améliorer leur référencement. J’aurais pensé qu’en 2009 tout le monde saurait à quoi servent réellement ces balises. Mais bon…

Cet article s’adresse donc à tous les clients néophytes ou tous les novices dans ce domaine.

La balise meta description

La balise meta description, qui consiste à décrire le contenu de la page, est prise en compte par Google mais uniquement pour l’affichage des résultats. Cette balise n’a aucun impact sur le positionnement. Je répète, cette balise n’a aucun impact sur le positionnement. Il est donc inutile de penser qu’on peut améliorer le référencement en ajoutant cette balise dans les sites web.

Objectif premier : donner envie aux internautes de cliquer !

Une bonne balise meta description contribue à augmenter le taux de clic. Les moteurs en affichent environ 170 caractères. Cette balise doit être explicite et incitative à cliquer sur le lien. Il est important de noter que cette balise doit être obligatoirement différente sur chacune des pages puisqu’elle doit représenter le contenu de la page sur laquelle elle se trouve. Il est inutile d’y insérer une panoplie de mots clés. Cela changeras en rien le référencement.



Si votre site ne contient aucune balise meta description, Google se chargera d’en créer une pour vous. Il prendra, dans la balise body, le texte le plus rapproché … qui n’est pas nécessairement le plus « marketing ».

Je vous invite donc à rédiger des balises meta description au minimum sur vos pages d’accueil si vous n’avez pas le temps d’en faire des personnalisée sur chacunes de vos pages.

La balise meta keywords

La balise meta keywords, qui consiste à lister des mots clés, est complètement ignoré par Google.  Tout le monde ensemble : Cette balise est complètement inutile pour le référencement sur Google. Toutefois, d’après John Mueller, elle serait pris en compte par d’autres moteurs de recherche et/ou annuaires. Il n’est donc pas mauvais d’en avoir une personnalisée sur chaque page. Si j’étais vous, je ne passerais pas trop de temps là-dessus.

En conclusion

Si un « spécialiste » du référencement vous conseil fortement d’ajouter des meta keywords pour améliorer votre référencement sur Google, sauvez-vous en courant! Ou encore, si vous tombez sur un article qui promouvoit les bienfaits de ces balises pour le référencement, vérifiez la date de celui-ci :P

Pour plus d’information, consultez le Google Webmaster Central Blog.






marie-andree
6 novembre 2009

Comment bien rédiger la balise TITLE

La balise TITLE fait partie des points à tenir en compte lors d’une optimisation pour le référencement organique. À mon avis, elle est ultra importante. Voici la recette pour des TITLE optimisés et efficaces :

***Avoir un maximum de 65 caractères***

Google affiche seulement les 65 premiers caractères du TITLE, incluant les espaces, les virgules, /, etc. Il est donc inutile de rédiger un TITLE de plus de 65 caractères.

***Être différent sur chaque page***

Chaque page est unique et doit, par conséquent, avoir un TITLE unique. De plus, 2 pages ayant un même TITLE pourrait mélanger l’usager lors de sa recherche sur google. Il doit pouvoir différencier les pages dans les résultats de recherche.

***Inclure des mots clés ciblés***

Évidemment, qui dit référencement dit mots clés. Les mots clés du TITLE devraient être ceux des h1 et h2 de la page en question. À savoir que les H1 et les H2 ont bien été rédigés! En résumé, un bon mot clé doit être présent dans la page et doit être un mot que les futurs usagers chercherons sur google. Notez qu’un nom d’entreprise n’est pas nécessairement un mot clé. Par exemple, Votre maison sur son 36 est un nom peu connu. Rare seront les gens qui chercherons ce nom. Il vaut mieux donc avoir le mot clé home staging en premier plutôt que le nom de d’entreprise.

***Contenir les mots les plus importants en premier***

L’ordre des mots dans le TITLE est important. Plus il est en premier, plus il a une valeur.

***Vérifier l’orthographe des mots***

Les mots clés ont-ils des accents ou pas? Pluriel? Majuscule?