URLs propres du pauvre, contre Mod_Rewrite
Dans l'entreprise où je travaille, nous nous préparons à concevoir un nouveau site Web et il y a un certain désaccord sur la manière de nettoyer les URL. Au cours de la dernière année, nous avons apporté de petites améliorations à notre site Web existant en prévision d'une refonte à grande échelle, qui impliquait les URLs propres de Poor Man's.
Exemple:http://www.example.com/products/widgets/index.php
http://www.example.com/products/sprockets/index.php
Pour le nouveau site, on parle d'utiliser mod_rewrite:
- L'utilisateur demande
http://www.example.com/products/widgets/ - mod_rewrite les envoie à
http://www.example.com/index.php?page=products/widgets - index.php les envoie à la page réelle
http://www.example.com/products/widgets.php
Je ne vois pas comment tout ce rigamaroll ajoute de la valeur. L'employé en faveur de mod_rewrite affirme que moins de répertoires équivaut en quelque sorte à une maintenance plus facile.
Aucune de nos pages existantes n’utilise des variables dans la chaîne de requête. Tout le contenu est dans les fichiers eux-mêmes. Nous prévoyons de mettre du contenu dans la base de données, comme les communiqués de presse et les salons professionnels futurs, mais la grande majorité des pages n'utilisera que PHP pour inclure du code HTML commun, comme en-tête, pied de page, etc. la navigation. Je serais certainement prêt à utiliser mod_rewrite pour un contenu dynamique comme celui-là.
Y at-il un gros avantage qui me manque que nous devrions utiliser mod_rewrite pour tout? Les URL propres du pauvre homme sont-elles suffisantes pour les parties de notre site ne contenant pas de base de données?
Le processus en 3 étapes que vous avez décrit ci-dessus semble redondant et inutile, comme indiqué ci-dessus. Si à l'étape 3, index.php les amène à la page "réelle", alors pourquoi même s'embêter avec mod_rewrite? Faire cela annulera les avantages offerts par mod_rewrite. À savoir une URL conviviale pour les moteurs de recherche et une maintenance plus facile du site. Si vous vous arrêtez à la deuxième étape, vous tirerez parti de mod_rewrite en ne conservant qu'une seule page. Toutefois, il peut servir un nombre pratiquement illimité de pages et être transparent pour l'utilisateur et les moteurs de recherche, car ils ne voient que l'URL de l'étape 1.
C'est un mythe que "/ pagename" ou "/pagename.htm" sont meilleurs pour les moteurs de recherche que "/pagename.php". Au moins chez Google, il n’ya absolument aucune base pour cela (et je suppose aussi les autres). De même, même "index.php? Page = pagename" n'a pas besoin d'être réécrit comme "/ pagename" - les moteurs de recherche peuvent comprendre ces URL sans aucun problème, et Google est même allé sur l'enregistrement qu'il préfère que les utilisateurs ne réécrivent pas inutilement ( http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html ). Donc, à condition de ne pas créer d'URL sans fin avec des paramètres d'URL, les URL réécrites ne sont pas nécessairement plus conviviales pour les moteurs de recherche que les URL non réécrites .
Cela dit, les utilisateurs peuvent préférer les URL de Nice aux URL laides/complexes. Si votre principal souci est d'avoir de belles URL dans les résultats de recherche, je jetterai un coup d'œil au microformat de chapelure que Google prend maintenant en charge ( http://googlewebmastercentral.blogspot.com/2010/09/rich-snippets- testing-tool-améliorations.html ), car ils offrent souvent une expérience utilisateur encore meilleure en ce qui concerne les URL dans les résultats de la recherche. Cela ne résoudra pas le problème des utilisateurs souhaitant créer des liens vers des URL de belle apparence, mais à condition que vos URL ne soient pas complexes à l'infini (et que vos exemples ne le soient pas), cela ne fera probablement pas une différence mesurable si vous les réécrivez pour cela. cas d'utilisation. S'il n'y a pas de différence mesurable, cela n'a probablement aucun sens de passer du temps à concevoir et à maintenir une telle configuration.
Ce que vous appelez les "URLs propres du pauvre" ne sont que des URL propres implémentées via le système de fichiers. Vous pouvez avoir ces types d'URL en utilisant mod_rewrite, tout comme vous pouvez avoir le deuxième type d'URL sans mod_rewrite.
Les URL propres correspondent exactement à ce que le nom implique: des URL propres ou d'aspect propre. Tous les deux
http://yoursite/foo/bar
et
http://yoursite/foo/bar.php
sont des URL propres. Le terme "nettoyer les URL" ne spécifie aucune implémentation particulière. Vous pouvez implémenter des URL propres en générant des pages .html en cache chaque fois que le site est mis à jour si vous le souhaitez. mod_rewrite vous permet simplement de découpler la structure d'URL de la structure de fichiers sans redirections ni cadres.
D'après ce que cela ressemble, vous n'exécutez actuellement aucun site géré par une base de données. Et bien que techniquement, il puisse être qualifié de site Web dynamique, il est probablement davantage du côté statique du spectre si vous utilisez principalement PHP juste pour inclure des en-têtes/pieds de page. C'est bien pour les petits sites qui ont rarement besoin de mises à jour, mais à mesure que votre site s'agrandit, vous devez mettre en place un vrai CMS.
Là où mod_rewrite brille, c'est quand vous commencez à prendre en compte la maintenabilité. Au lieu d'avoir des centaines de fichiers php pour chaque page de produit (avec beaucoup de code redondant), vous pouvez simplement avoir un seul script qui gère toutes les demandes. Mais si vous n'avez plus de correspondance individuelle entre les fichiers .php et les pages Web affichées, vous devrez utiliser quelque chose comme mod_rewrite pour acheminer intelligemment les demandes de page tout en conservant l'illusion de la structure du fichier/répertoire. Là.
Ce n’est donc pas le sous-répertoire supplémentaire qui devrait vous inquiéter. C'est le fait que vous créez un script .php distinct pour chaque page de votre site.
"Nettoyer les URL" signifie souvent pas de fichier ext; cela permet de cacher les détails de la mise en œuvre au spectateur. L’avantage de cela réside dans le fait que vous décidez de déplacer votre site de PHP vers Ruby sur Rails, sans changer une seule URL.
Maintenant, s'il est possible de faire fonctionner votre site avec ASP.net et d'avoir des noms de fichiers se terminant par .php si vous voulez garder vos URLS intactes, il semble plus logique de les faire de manière à ce que le problème ne se pose jamais. .
http://www.example.com/news/2010/10/our-new-url-system/
Cela peut toujours être une bonne URL, même si vous modifiez complètement l’architecture sous-jacente, ou si vous passez de fichiers statiques à des fichiers dynamiques .. ou inversement.
Comme on l'a dit, avoir .php ou ?page= n'a pas vraiment d'importance. Ce qui fait est important si vous faites quelque chose comme ceci:
http://www.example.com/index.php?page=13
Il me semble que tout votre contenu dans une base de données serait beaucoup plus rapide et facile à gérer que de creuser dans un système de fichiers volumineux chaque fois que vous devez effectuer des mises à jour. Comme John Mueller l'a mentionné ci-dessus, l'URL de Nice ne fera pas une grande différence dans votre classement. Toutefois, vous souhaitez envisager d'utiliser Mod_Rewrite pour conserver vos URL existantes et leur valeur. IE si:
example.com/widgets/index.php a 1 000 liens pointant vers ce site et que vous le changez en exemple.com/pages/widgets.php, vous risquez de perdre beaucoup de cette valeur (vous pouvez bien sûr la rediriger, mais ou non cela passera la même valeur)
Si vous continuez à servir du contenu statique, continuez d'utiliser le système de fichiers. Si vous le convertissez en contenu dynamique, utilisez Mod_Rewrite pour conserver la structure actuelle de votre URL. Ou, s'il n'est pas possible de conserver la structure actuelle, utilisez Mod_Rewrite pour créer une structure stable pour les futures mises à jour.