URL Rewrite Smack-Down : .htaccess contre 404 Handler

Simon

il y a 4 ans

Tout d’abord, un rappel rapide : le raffinement d’URL et la redirection 301 peuvent tous deux être effectués dans .htaccess fichiers, ou dans votre gestionnaire 404. Si vous n’êtes pas complètement au courant du fonctionnement général des réécritures d’URL et des 301, cet article vous aidera certainement. Et si vous n’avez pas lu le post de la semaine dernière sur la double personnalité de RewriteRule, c’est probablement une documentation utile pour comprendre le post d’aujourd’hui.

Le “raffinement d’URL” est le processus consistant à montrer des URL lisibles et riches en mots clés à l’utilisateur final (et à Googlebot) tout en utilisant en réalité des URL plus laides et souvent paramétrées dans les coulisses pour générer le contenu de la page.

Ici, tu fais NE PAS faire une redirection 301.

(Pas clair sur la redirection, 301s contre 302s, etc.? Il y a de l’aide qui vous attend ici dans le centre de connaissances SEOmoz.)

Les 301 sont effectués lorsque vous avez vraiment déplacé la page et que vous voulez vraiment que Googlebot sache où se trouve la nouvelle page.

Vous admettez à Googlebot qu’il n’existe plus à l’ancien emplacement.

Vous demandez également à Googlebot de créditer la nouvelle page de tout le jus de lien que l’ancienne page avait gagné dans le passé.

Par exemple, vous avez peut-être migré votre site Web vers un nouveau système de gestion de contenu et toutes les pages ont des URL quelque peu différentes de celles qu’elles avaient avant le déplacement.

Si vous êtes satisfait de la gâchette, vous pourriez sauter à la conclusion que Réécrire la règle est l’arme de choix pour le raffinement d’URL et les redirections 301. Vous POUVEZ certainement utiliser Réécrire la règle pour ces tâches, et la syntaxe regex est certainement un moyen puissant d’accomplir des transformations d’URL assez complexes. Et vraiment, si vous comptez utiliser Réécrire la règlevous devriez probablement l’utiliser dans votre httpd.conf fichier à la place.

La documentation Apache contient un excellent résumé des cas où il ne faut pas utiliser .htaccess.

Contenu de la page

Ne craignez pas le gestionnaire 404

Tout d’abord, vous tous qui tremblez à l’idée de créer votre propre gestionnaire 404 personnalisé, prenez un Valium. Ce n’est pas si difficile. Si vous avez réussi à faire fonctionner RewriteRule et que vous avez vécu pour raconter l’histoire, vous n’aurez aucune difficulté à créer un gestionnaire d’erreurs 404 personnalisé.

C’est juste une page Web qui affiche une sorte de message “introuvable”, mais cela vous donne l’occasion de jeter un œil à la page qui a été demandée, et si vous pouvez “l’enregistrer”, vous redirigez l’utilisateur vers la page qu’il recherchons avec juste une ligne ou deux de code.

Si ce n’est pas le cas, le statut HTTP 404 est renvoyé, ainsi que la manière dont vous souhaitez que la page apparaisse lorsque vous leur dites que vous n’avez pas trouvé ce qu’ils cherchaient.

Soit dit en passant, avoir votre propre gestionnaire 404 vous donne la possibilité de divertir votre utilisateur, au lieu de simplement le faire s’apitoyer sur lui-même. Consultez cet article de Smashing Magazine sur les pages créatives 404.

Avoir un bon sens de l’humour pourrait inspirer l’amour et la loyauté d’un client qui, autrement, pourrait être vexé par le 404.

Voici un exemple de gestionnaire 404 en ASP. Note importante: n’utilise pas Réponse. Redirection — il fait un 302, pas un 301 !

Pour PHP, vous devez ajouter une ligne à votre fichier .htaccess pointant vers l’endroit où vous avez placé votre gestionnaire 404 :

ErreurDocument 404 /my-fabulous-404-handler.php

Ensuite, dans ce fichier PHP, vous pouvez obtenir l’URL qui n’a pas été trouvée via :

$requête = $_SERVER[‘REDIRECT_URL’];

Ensuite, utilisez n’importe quelle logique PHP pour analyser l’URL et déterminer où envoyer l’utilisateur.
Si vous pouvez le rediriger avec succès, définissez :

header(“HTTP/1.1 301 Déplacé définitivement”);
en-tête (“Emplacement : http://www.acmewidgets.com/purple-gadgets.php”);

Et c’est là que ça devient un peu poilu en PHP. Il n’y a aucun moyen réel de transférer le contrôle vers une autre page Web dans les coulisses – sans dire au navigateur ou à Googlebot via 301 que vous le transférez à l’autre page. Mais vous pouvez utiliser l’appel exiger() à la volée pour extraire le code de la page cible. Assurez-vous simplement de définir d’abord le code HTTP sur 200 :

entête(‘HTTP/1.1 200 OK’);

Et vous devez être prudent tout au long de votre site pour utiliser include_once() à la place de comprendre() pour vous assurer de ne pas extraire un fichier commun deux fois. Une autre option consiste à utiliser boucle pour saisir le contenu de la page cible comme s’il se trouvait sur un serveur distant, puis régurgitez le code HTML dans le flux en faisant écho à ce que vous obtenez en retour. Un peu dangereux si vous essayez de déposer des cookies, cependant…

Et, si vous avez vraiment besoin d’envoyer un 404 :

en-tête(‘HTTP/1.0 404 Introuvable’);

Très important: veillez à vous assurer que vous renvoyez le bon code HTTP à partir de votre gestionnaire 404. Si vous avez trouvé une bonne page de contenu que vous souhaitez afficher, renvoyez un 200. Si vous avez trouvé une bonne correspondance et que vous souhaitez que Googlebot connaisse ce nom de page au lieu de ce qui a été demandé, faites un 301. Si vous ne le faites vraiment pas n’ayez pas une bonne correspondance, assurez-vous d’envoyer un 404. Et assurez-vous de tester les codes de réponse réels reçus – je suis un grand fan du plug-in HttpFox Firefox.

Facilité de débogage

C’est là que le gestionnaire 404 gagne vraiment mon affection. Comme il ne s’agit que d’une autre page Web, vous pouvez afficher des résultats partiels de votre manipulation de chaîne pour voir ce qui se passe.

Ne codez pas la redirection tant que vous n’êtes pas sûr que tout le reste fonctionne. Au lieu de cela, crachez simplement l’URL qui est entrée, l’URL que vous essayez de fabriquer et de rediriger, et toutes les chaînes intermédiaires qui vous aident à tout comprendre.

Avec Réécrire la règlele débogage consiste en gros à coder votre expression regex, à mettre les drapeaux, puis à voir si cela a fonctionné.

L’URL arrive-t-elle en casse mixte ? Les barres obliques… vers l’avant ? Inverse? Ai-je besoin d’échapper à ce personnage… ou n’est-ce pas That Special ?

Vous volez à l’aveuglette. Ça marche, ou ça ne marche pas.

Si vous luttez avec Réécrire la règle expressions régulières, Rubular a un bel éditeur/testeur de regex.

Flexibilité de programmation

Avec Réécrire la règlevous devez faire tout le travail dans la seule ligne de regex.

Et bien que regex soit élégant, puissant et devrait être vénéré par tous, vous voudrez parfois faire une logique de réécriture d’URL plus complexe qu’une simple substitution intelligente.

Dans votre gestionnaire 404, vous pouvez appeler des fonctions pour faire des choses comme convertir des paramètres numériques dans votre URL source en mots et vice versa.

Accès à votre base de données

Si vous travaillez avec un grand site basé sur une base de données, vous souhaiterez peut-être rechercher des éléments dans votre base de données pour convertir des paramètres en mots.

Et puisque le gestionnaire 404 n’est qu’une autre page Web, vous pouvez faire avec votre base de données tout ce que vous feriez sur n’importe quelle autre page Web.

Par exemple, j’avais un site Web de voyage où les destinations, les îles et les hôtels étaient tous identifiés dans la base de données par des identifiants numériques. La page brute qui affichait le contenu d’un hôtel devait également indiquer le pays et l’île sur lesquels se trouvait l’hôtel.

L’URL brute d’une page d’hôtel spécifique aurait pu ressembler à :

/hotel.asp?dest=41&island=3&hotel=572

Alors que la “jolie URL” de cet hôtel aurait pu ressembler à :

/hôtels/Hawaii/Maui/Grand-Wailea/

Lorsque la “jolie URL” ci-dessus était demandée par le client, mon gestionnaire 404 décomposait l’URL en sections :

rechercher la 2ème section dans le tableau des destinations (Hawaï = 41)
rechercher la 3ème section dans la table des îlots (Maui = 3)
en regardant la 4ème section dans la table d’hôtel (Grand Wailea = 572)

Ensuite, j’appellerais la fonction ASP Serveur.Transfert transférer l’exécution à /hotel.asp?dest=41&island=3&hotel=572 pour générer le contenu.

Maintenant, gardez à l’esprit que vous voudrez probablement générer le liens à vos jolies URL à partir des identifiants de la base de données, plutôt que de les coder en dur. Par exemple, si vous avez une page qui répertorie tous les hôtels de Maui, vous obtiendrez tous les identifiants d’hôtels de la base de données des hôtels où le destinations = 41
et île = 3et que vous voulez écrire les liens comme /hôtels/Hawaii/Maui/Grand-Wailea/. Les fonctions que vous écrivez pour ce faire vont être très, très similaires
à celles dont vous avez besoin pour décoder ces URL dans votre gestionnaire 404.

Dernier point mais non le moindre : vous pouvez suivre les 404 qui vous surprennent (c’est-à-dire les vrais 404) en demandant à la page de vous envoyer un e-mail ou d’enregistrer les URL 404 dans un tableau.
dans votre base de données.

Performance

Pour la plupart des gens, la performance de faire le travail en .htaccess ne va pas être significatif.

Mais si vous faites du raffinement d’URL pour un site massif, ou si vous avez renommé une énorme liste de pages sur votre site, il y a quelques choses que vous voudrez peut-être savoir, surtout avec Google qui utilise maintenant la vitesse de chargement des pages comme l’un des ses facteurs de classement.

Toutes les demandes sont évaluées dans .htaccessque les URL nécessitent ou non une manipulation/redirection.

Cela inclut vos fichiers CSS, vos images, etc.

En déplaçant votre réécriture/redirection vers votre gestionnaire 404, vous évitez que votre code de correspondance de modèle d’URL ne vérifie chaque fichier demandé à votre serveur Web – seules les URL qui ne peuvent pas être trouvées telles quelles atteindront le gestionnaire 404.

Cela dit, notez que vous pouvez faire correspondre des motifs dans .htaccess pour les pages que vous ne voulez PAS manipuler, et utilisez le L drapeau pour arrêter le traitement tôt dans .htaccess pour les URL qui ne nécessitent pas de traitement particulier.

Même si vous vous attendez à ce que presque toutes les pages demandées aient besoin d’un démêlage d’URL (conversion en page paramétrée), n’oubliez pas les fichiers image, les fichiers Javascript, CSS, etc. L’approche du gestionnaire 404 évitera d’avoir les URL de ces composants de page vérifiés par rapport à vos modèles de conversion à chaque fois qu’ils sont récupérés.

Un cas particulier

OK, peut-être que ce cas n’est pas si spécial – c’est assez courant, en fait. Disons que nous sommes passés à une structure de nouvelles jolies URL à partir d’anciennes URL paramétrées.

Non seulement nous devons pouvoir passer d’une jolie URL -> URL paramétrée pour générer le contenu de la page pour l’utilisateur, mais nous voulons également rediriger le jus de lien de tous les anciens liens URL paramétrés vers les nouvelles jolies URL.

Dans la page Web paramétrée proprement dite (par ex. hôtel.asp dans l’exemple ci-dessus), nous voulons faire une redirection 301 vers la jolie URL. Nous allons prendre chacun des paramètres numériques, rechercher la destination, l’île et le nom de l’hôtel, et fabriquer notre jolie URL, et 301 pour cela. Là, link juice tout sauvegardé…

Mais nous devons faire attention à ne pas entrer dans une boucle infinie, convertissant d’avant en arrière et d’avant en arrière :

Lorsque cela se produit, Firefox propose un message indiquant que vous avez fait quelque chose de si stupide qu’il ne va même pas prendre la peine d’essayer d’obtenir la page. Ils le disent si poliment : “Firefox a détecté que le serveur redirige la requête vers [URL] d’une manière qui ne s’achèvera jamais.”

Soit dit en passant, il est tout à fait possible que ce même problème se produise via Réécrire la règle déclarations – je le sais par expérience personnelle 🙁

Ce n’est en fait pas si difficile à résoudre. Dans ASP, lorsque le gestionnaire 404 passe le contrôle à la page hotel.asp, la chaîne de requête commence désormais par “404; http“. Ainsi, dans hotel.asp, nous voyons si la chaîne de requête commence par 404, et si c’est le cas, nous continuons simplement à afficher la page. Si elle ne commence pas par 404;http, nous renvoyons 301 à la jolie URL.