l'indicible blog » SEO http://www.lindicible.com/blog <!--:en-->the details of the inexpressible<!--:--><!--:fr-->les détails de l'ineffable<!--:--> Thu, 01 Jul 2010 14:20:33 +0000 http://wordpress.org/?v=2.9.2 fr hourly 1 Comment ajouter automatiquement un slash en fin d’URL http://www.lindicible.com/blog/2010/05/03/comment-ajouter-automatiquement-un-slash-en-fin-durl/ http://www.lindicible.com/blog/2010/05/03/comment-ajouter-automatiquement-un-slash-en-fin-durl/#comments Mon, 03 May 2010 20:55:23 +0000 Matt http://www.lindicible.com/blog/?p=548 Après de longues et fastidieuses recherches pour ajouter automatiquement un slash ( ‘/’ ) à la fin des adresses de mes sites web, j’ai pensé que certains pourraient profiter du fruit de ces recherches…

Pour ceux qui se demanderaient quel est le but de la manœuvre, il s’agit encore une fois d’un souci de référencement.
En effet, pour un moteur de recherche, http://www.siteweb.com/nom et http://www.siteweb.com/nom/ ne sont pas équivalents. Ceci est hérité d’une époque où /nom représentait un fichier et /nom/ un répertoire. Rien alors n’empêchait d’avoir au même endroit un répertoire et un fichier du même nom.

Aujourd’hui, on a pris l’habitude de rendre les URIs plus clairs et plus simples pour les utilisateurs, et la plupart du temps on s’arrange pour que http://www.siteweb.com/nom et http://www.siteweb.com/nom/ renvoient sur la même page.
Une fois encore, le risque est de se retrouver avec deux pages considérées comme des doublons par les moteurs de recherche, diluant le référencement global de la page.
Pour éviter cela, on va donc chercher à avoir une page canonique, et à renvoyer l’autre sur celle-ci.

Il existe plusieurs façons de faire ça, la plus simple étant probablement l’usage de l’attribut « canonical » récemment introduit par Google.
Pour référence, il s’agit d’introduire un tag du type <link rel="canonical" href="http://www.creation-de-sites-web.com/w3c.php?quality=high"> dans la balise <head> de la page en question. Ainsi, plusieurs URLs pourront pointer sur cette page, mais Google sera informé que c’est l’adresse indiquée dans ce href qui fait référence.

Une autre méthode consiste à systématiquement rediriger le visiteur sur l’adresse de page que l’on souhaite mettre en avant.
Ceci peut se faire au niveau de la page elle même (par exemple en php), mais il est probablement beaucoup plus approprié de le faire au niveau du serveur web (Apache) ou d’un fichier .htaccess.

On a alors plusieurs outils à notre disposition, liés à mod_alias et mod_rewrite (pensez à vérifier qu’ils sont bien activés sur votre hébergement avant de commencer à expérimenter! Ce n’est pas toujours le cas)

Mes expérimentations m’ont fait passer de RewriteRule à RedirectMatch, puis de retour sur RewriteRule pour un résultat qui m’a enfin paru satisfaisant.
En guise de documentation, je vous invite à visiter la documentation Apache, notamment les liens suivants :
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritelog

Sans plus de préambule, voici ma solution :

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_URI} (^/blog/.*)$  [NC]
RewriteRule ^.*$ - [NC,L]

RewriteRule ^(.+[^/])$  %{REQUEST_URI}/  [R=301,L]

RewriteRule ^.*$ index.php [NC,L]

Détaillons un petit peu :

RewriteEngine On

On s’assure que le moteur de ré-écriture d’URL est allumé. S’il n’est pas disponible, on aura généralement une erreur 500.

On va ensuite tester différents cas de figure :

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_URI} (^/blog/.*)$  [NC]
RewriteRule ^.*$ - [NC,L]

Si le lien pointe vers un fichier de taille non nulle (-s = sized file)
ou bien
que le lien pointe vers un lien (-l = link)
ou bien
que le lien pointe vers un répertoire (-d = directory)
ou bien que l’URI commence par /blog/ sans tenir compte de la casse (NC = Not Case-sensitive)
alors on va remplacer l’URL par elle même (-) et ignorer les règles suivantes (L = Last rule)

RewriteRule ^.*[^/]$  %{REQUEST_URI}/  [R=301,L]

Si l’on est toujours là, c’est que les conditions précédentes n’ont pas été remplies.
On est donc pas en présence d’un fichier/lien/répertoire ni d’une entrée du blog (que nous avons mis ici à titre d’exemple d’un élément d’arborescence à exclure… A noter que les blogs comme Wordpress ont leur propre système de ré-écriture d’URLs).
On va alors remplacer tout ce qui ne finit pas par un / ( soit ^.*[^/]$ en expression régulière ) par l’adresse visée suivie d’un / ( %{REQUEST_URI}/ ) et faire une redirection externe sur cette adresse (R = Redirect, 301 = le code d’erreur que l’on souhaite envoyer ).
Ceci sera notre dernière règle (L = Last), afin d’éviter qu’elle ne soit remplacée par une autre avant que la redirection n’ait été prise en compte (ça n’a l’air de rien, mais j’ai du perdre un certain nombre de cheveux avant de comprendre ça!)

Enfin, dans le cadre de nos projets à URLs customisées, on va généralement renvoyer tout le reste sur le fichier index.php qui s’occupera de l’interpréter : 

RewriteRule ^.*$ index.php [NC,L]

Peut-être y a-t-il de meilleures façons de procéder. Si c’est le cas, je serai ravi de les découvrir.
Quoi qu’il en soit, n’hésitez pas à laisser un commentaire, ça fait toujours plaisir ;)

]]> http://www.lindicible.com/blog/2010/05/03/comment-ajouter-automatiquement-un-slash-en-fin-durl/feed/ 0 DOMDocument et UTF-8, un problème de charset en php http://www.lindicible.com/blog/2009/10/18/domdocument-et-utf-8-un-probleme-de-charset-en-php/ http://www.lindicible.com/blog/2009/10/18/domdocument-et-utf-8-un-probleme-de-charset-en-php/#comments Sat, 17 Oct 2009 23:44:11 +0000 Matt http://www.lindicible.com/blog/?p=481 Aujourd’hui, nous allons voir comment manipuler des éléments du DOM avec php.
Nous prendrons pour exemple une fonction très pratique mais pourtant apparamment bien difficile à trouver : commenter ajouter un attribut spécifique à des éléments HTML.
Ceci peut-être utile par exemple pour ajouter un attribut rel= »nofollow » à des liens pour signaler aux moteurs de recherche qu’ils n’ont pas à les suivre, tout en laissant ces liens accessibles pour vos utilisateurs. D’un point de vue référencement, ça peut être bien pratique puisque cela vous évite de voir votre PageRank être dispersé vers tous les liens présents sur vos pages.

Pour arriver à ce but, nous allons rencontrer plusieurs problèmes assez vicieux. Commençons par une fonction aboutie, pour faire gagner du temps au plus vifs d’entre vous :

function addAttribute($context, $tag, $attribute, $value)
{
	$initialEncoding = mb_detect_encoding($context);
	if( $initialEncoding != 'UTF-8' ){
		$context = utf8_encode($context);
	}

	$doc = new DOMDocument("4.01", "utf-8");

	$contentPrefix = '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><title>required meta for utf-8 handling!</title><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>';
	$contentSuffix = '</body></html>';

	$doc->loadHTML($contentPrefix . $context . $contentSuffix);

	$elements = $doc->getElementsByTagName($tag);

	if(!is_array($value)){
		$value = array($value);
	}

	foreach($elements as $element)
	{

		foreach($value as $currentValue)
		{
			$alreadySet = false;

			if($element->hasAttribute($attribute))
			{

				$attributeCurrentValue = $element->getAttribute($attribute);

				$attributeCurrentValues = explode(' ', $attributeCurrentValue);

				foreach( $attributeCurrentValues as $attributeCurrentValue )
				{
					if($attributeCurrentValue == $currentValue){
						$alreadySet = true;
					}
				}
				if(!$alreadySet){
					$element->setAttribute($attribute, implode(' ', $attributeCurrentValues) . ' ' . $currentValue);
				}
			} else {
				$element->setAttribute($attribute, $currentValue);
			}
		}
	}

	$output = mb_substr($doc->saveHTML(), 236, -16);

	if( $initialEncoding != 'UTF-8' ){
		mb_convert_encoding($output, $initialEncoding, 'UTF-8');
	}

	return $output;
}

Explications

$initialEncoding = mb_detect_encoding($context);
	if( $initialEncoding != 'UTF-8' ){
		$context = utf8_encode($context);
	}

On commence par détecter le format d’encodage actuellement utilisé dans le contexte fourni.
On le stocke pour pouvoir retourner la version modifiée dans le même format, et on le converti en UTF-8.
Pourquoi UTF-8 ? Ce format a l’avantage (énorme) de gérer tous les caractères, y compris les caractères accentués ou spéciaux de différents langages.

	$doc = new DOMDocument("4.01", "utf-8");

On crée ensuite un nouvel objet DOM, au constructeur duquel on passe deux paramètres : la version du document que l’on va utiliser (typiquement « 1.0″ pour du XML et « 4.01″ pour du HTML), et le jeu de caractères de ce document (charset).

	$contentPrefix = '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><title>required meta for utf-8 handling!</title><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>';
	$contentSuffix = '</body></html>';

	$doc->loadHTML($contentPrefix . $context . $contentSuffix);

On va ensuite ajouter un header au contexte passé. En effet, même si on a défini les valeurs attendues pour le document fourni, celles-ci seront effacées par le document si ces headers ne sont pas fournis. Et je peux vous assurer que lorsqu’on ne sait pas ça, il y a de quoi s’arracher les cheveux !! C’est sans doute le point le plus vicieux de la manipulation.
On peut ensuite charger le contenu dans cet objet DOM.

	if(!is_array($value)){
		$value = array($value);
	}

Cette fonction prévoit de pouvoir ajouter plusieurs valeurs à un attribut donné. Si l’argument passé à la fonction est une chaine de caractères, on la transforme donc en tableau.

Je ne m’attarderai pas sur le reste de la fonction en elle même, qui est assez explicite.
Notez simplement que l’on préserve les valeurs déjà existantes en les stockant dans un tableau, et que l’on vérifie avant d’ajouter la valeur de l’attribut si elle n’existe pas déjà.

	$output = mb_substr($doc->saveHTML(), 236, -16);

On va ensuite sauvegarder le résultat obtenu, et retirer les préfixe et suffixe que l’on avait ajouté grâce à une fonction gérant les caractères multibytes. En effet, un substr classique ne fonctionnerait pas convenablement avec certains caractères, puisque l’on est ici en UTF-8 qui utilise plusieurs octets pour stocker certains d’entre eux.

	if( $initialEncoding != 'UTF-8' ){
		mb_convert_encoding($output, $initialEncoding, 'UTF-8');
	}

	return $output;

Il est temps de remettre le résultat obtenu dans son jeu de caractère d’origine et de retourner le résultat.

Et… Voila!

]]> http://www.lindicible.com/blog/2009/10/18/domdocument-et-utf-8-un-probleme-de-charset-en-php/feed/ 0 Ré-écriture d’URL et SEO http://www.lindicible.com/blog/2008/12/08/re-ecriture-durl-et-seo/ http://www.lindicible.com/blog/2008/12/08/re-ecriture-durl-et-seo/#comments Mon, 08 Dec 2008 21:39:26 +0000 Matt http://www.lindicible.com/blog/?p=82 Vous avez décidé d’utiliser la ré-écriture d’url pour rendre vos URL plus lisibles et ‘amicales’ pour l’utilisateur. C’est probablement une bonne chose, étant donné que les moteurs de recherche eux aussi les préfèrent ainsi. Mais attention, il y a certains écueils à éviter !

En effet, avec ce type de configuration, on ne fait plus bien la distinction entre contenu et répertoire… et les robots non plus! Du coup, http://www.mondomaine.com/example et http://www.mondomaine.com/example/ renvoient généralement sur le même contenu, mais sont vus comme deux pages différentes par les moteurs de recherche.

On a alors dilution du référencement, et les doublons sont de la partie. Quelle Horreur !

Nous avons déjà traité un problème similaire à propos des noms de domaines multiples dans un précédent article. La solution sera ici du même ordre.

Pour éviter tout souci de doublon, il vous faudra vous assurer que les adresses sans slash de fin (comme http://www.mondomaine.com/example) renvoient sur la même adresse avec slash de fin (comme http://www.mondomaine.com/example/) avec une erreur 301 (page définitivement déplacée).

Pour ce faire, il s’agira de procéder comme dans l’exemple ci dessous, à l’aide d’un fichier .htaccess ou en modifiant la configuration du serveur web :

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_URI} !-d
	RewriteCond %{REQUEST_URI} !(.*)/$
	RewriteRule ^(.*)$ http://www.mondomaine.com/$1/ [L,R=301]
</IfModule>
  • La première ligne annonce l’utilisation d’une règle de ré-écriture, et la seconde indique le répertoire courant comme racine.
  • RewriteCond %{REQUEST_FILENAME} !-f exclut les fichiers existant de cette règle, afin qu’un slash ne leur soit pas adjoint.
  • RewriteCond %{REQUEST_FILENAME} !-d fait de même avec les répertoires existant réellement sur le site.
  • RewriteCond %{REQUEST_URI} !(.*)/$ s’occupe d’exclure les URLs finissant déjà par un slash.
  • Enfin, RewriteRule ^(.*)$ http://www.mondomaine.com/$1/ [L,R=301] rajoute un slash à la fin des URL ainsi sélectionnées, en retournant en passant le code d’erreur approprié.

Notez que vous devez placer thes règles avant celles pré-existantes pour être sûr d’avoir le comportement désiré.

]]> http://www.lindicible.com/blog/2008/12/08/re-ecriture-durl-et-seo/feed/ 1 Multiples noms de domaines et SEO http://www.lindicible.com/blog/2008/11/23/multiples-noms-de-domaines-et-seo/ http://www.lindicible.com/blog/2008/11/23/multiples-noms-de-domaines-et-seo/#comments Sun, 23 Nov 2008 21:24:45 +0000 Matt http://blog.lindicible.com/?p=60 Que faire lorsque l’on a plusieurs noms de domaines pointant sur un même site pour gérer au mieux son référencement ?

Que ce soit pour protéger les noms voisins (ex: monsite.com et mon-site.com) ou pour tirer parti des avantages des différents TLD (Top Level Domain) (ex: monsite.com et monsite.org), il y a parfois de bonnes raisons d’utiliser plusieurs noms de domaine pour un même site.

Si l’on y prend pas garde, les moteurs de recherche importants (liste exhaustive des moteurs de recherche importants:Google) peuvent considérer ces sites comme des doublons et/ou attribuer les pages à un domaine ou un autre de manière arbitraire, diluant vos résultats dans les SERP (Search Engine Result Pages). Dans tous les cas, la qualité de votre référencement en souffre.

Pour éviter ce problème, il nous faut choisir un nom de domaine principal qui servira de référence. Ceci implique l’utilisation de ce nom partout où l’on peut avoir besoin d’inscrire une URL, et la modification du comportement des domaines secondaires.

Nous allons faire en sorte que les domaines secondaires retournent le même contenu que le domaine principal, tout en prévenant les robots qu’ils ne sont pas le domaine principal. Encore une fois, les codes d’erreur HTTP vont nous être utiles : nous allons retourner un code 301 (changement d’adresse définitif) avec le contenu.

Notez qu’un code d’erreur 302 (changement d’adresse temporaire) serait beaucoup moins efficace pour ce que nous cherchons à réaliser… et c’est ce qui est envoyé par défaut lors d’une redirection !

Pour retourner ce code, il existe plusieurs méthodes. La plus simple est probablement l’utilisation de l’instruction ‘redirect’ dans la configuration du serveur web (Apache) ou dans un fichier .htaccess à la racine du serveur.

Voici l’instruction à utiliser pour rediriger l’ensemble des requêtes vers l’adresse principale :

Redirect 301 / http://monsite.com/

ou

Redirect permanent / http://monsite.com/

Vous pouvez par exemple inclure un virtual hostname pour tous les domaines secondaires de la manière suivante :

<VirtualHost *:80>
    ServerName www.monsite.org
    ServerAlias monsite.org
    ServerAlias www.mon-site.com
    ServerAlias mon-site.com
    <IfModule mod_alias.c>
        Redirect permanent / http://www.mon-site-principal.com/
    </IfModule>
</VirtualHost>

Une autre façon de réaliser ceci sans modifier la conf d’apache serait d’appliquer des RewriteRules à travers un fichier .htaccess à la racine de votre site. Par exemple :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(.*)mon-site.com$
RewriteRule ^(.*)$ http://www.mon-site-principal.com/$1 [R=301,L]

ou encore avec :

RedirectMatch 301 /blog(.*) /$1

Avec un code d’erreur bien géré, vous vous assurez que le nom de domaine principal bénéficie de tout son potentiel. Le moteurs de recherche importants sont contents, donc vous aussi !

]]> http://www.lindicible.com/blog/2008/11/23/multiples-noms-de-domaines-et-seo/feed/ 4 404 et SEO http://www.lindicible.com/blog/2008/10/29/404-et-seo/ http://www.lindicible.com/blog/2008/10/29/404-et-seo/#comments Wed, 29 Oct 2008 20:02:17 +0000 Matt http://www.lindicible.com/blog/?p=9 Lorsque l’on cherche à optimiser son site pour obtenir un meilleur référencement sur les moteurs de recherche, on tombe très vite dans le monde souterrain du SEO (Search Engine Optimization).

Il y a dans cet univers beaucoup de bon sens et quelques trucs à savoir, ainsi que certains concepts flirtant avec le sacré, comme le célèbre PageRank de Google.

D’une manière générale, il faut comprendre de quelle manière les robots utilisés par les référenceurs voient votre site, c’est à dire en texte uniquement. Vous pouvez en avoir un bon aperçu en utilisant un navigateur texte comme lynx.

Tout ce qui peut permettre d’aider le travail de ces robots est un avantage pour vous. Utiliser du code html validé par le w3c et des feuilles de style valides ne changera pas votre pagerank mais donnera une meilleure visibilité de la structure de votre site aux robots que si vous le formatiez en utilisant des tableaux ou des div partout.

La sémantique du code html permet aux robots de distinguer le type de contenu, et de les utiliser de manière pertinente.

Par exemple, le tag <h1> doit contenir des titres de premier niveau, le tag <h2> des titres secondaires, le tag <p> des paragraphes de texte, et ainsi de suite.

Le plus important est évidemment la balise <title> de vos pages, qui doit contenir autant que possible les mots-clefs les plus importants.

La spécificité des robots par rapport aux utilisateurs ne s’arrête pas là.

En même temps que le contenu des pages, des codes d’erreurs sont émis. Ces codes sont rarement visibles pour l’utilisateur, à part le fameux 404 (page indisponible), mais ils sont importants.

Pour référence, voici une liste des codes d’erreur que les serveurs web sont susceptibles de retourner.

Imaginons que vous ayez un contenu dynamique… Certaines pages peuvent disparaitre de votre site, bien que des liens externes pointent encore dessus.

Typiquement, nous voulons rediriger l’utilisateur vers une page proche de sa requête, plutôt que de le confronter à une page d’erreur qui risque de le bloquer. Mais nous voulons aussi prévenir les moteurs de recherche que ce lien est obsolète et qu’il faut le supprimer. Dites vous bien que lorsqu’un robot tombe trop souvent sur un 404 il n’apprécie guère et cela peut avoir des conséquences sur votre référencement !

Comment résout-on cela, me direz vous ? Tout simplement, en émettant le code d’erreur approprié, tout en affichant un contenu pour l’utilisateur !

Le code 404 est le plus connu, mais cette erreur indique juste que la page n’a pas pu être jointe, pour quelque erreur que ce soit. Pour une page volontairement désactivée, nous lui préférerons l’erreur 410 qui indique que la page n’est plus disponible de manière délibérée et non suite à un problème technique.

A vous de choisir quel code d’erreur vous semble le plus à même de refléter le statut de la page…

Pour générer le code d’erreur, il va falloir modifier le ‘header’ de la page. Sous php, il s’agit d’utiliser la commande suivante :

header('HTTP/1.0 410 Gone');

Notez que le header est la toute première chose qui est émise lorsque la page est envoyée. Il doit donc être situé tout au tout début du document, avant même la déclaration du type de document (DTD).

Pas très pratique lorsque la gestion du contenu est structurée de manière à dissocier les éléments fixes de la page (comme le logo ou le menu) du contenu réel. En effet, si le script affiche le haut de la page avant de traiter la requête relative au contenu et de s’apercevoir qu’il n’existe pas, il est trop tard pour modifier le header !

Un moyen simple de contourner ce problème est d’augmenter la taille du buffer php.

Dans php.ini, modifier la ligne output_buffering :

output_buffering = 65535

Cette valeur est une valeur limite, mais généralement suffisante (si vos pages ne pèsent pas un poids déraisonnable!)

Vous pouvez désormais retourner n’importe quel type d’erreur quand vous le souhaitez, sans perturber la visite de vos utilisateurs.

]]> http://www.lindicible.com/blog/2008/10/29/404-et-seo/feed/ 2