URL propres du pauvre vs 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 façon 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 URL propres ™ du pauvre.

Exemple:
http://www.example.com/products/widgets/index.php

http://www.example.com/products/sprockets/index.php

Pour le nouveau site, il est question d'utiliser mod_rewrite:

1. L'utilisateur demande http://www.example.com/products/widgets/
2. mod_rewrite les envoie à http://www.example.com/index.php?page=products/widgets
3. index.php les envoie à la vraie page 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 prétend que moins d'annuaires équivaut en quelque sorte à une maintenance plus facile.

Aucune de nos pages existantes n'utilise de variables dans la chaîne de requête. Tout le contenu se trouve 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 prochains salons auxquels nous assisterons, mais la grande majorité des pages n'utiliseront que PHP pour inclure du HTML commun comme l'en-tête, le pied de page et la navigation. Je serais certainement prêt à utiliser mod_rewrite pour un contenu dynamique comme celui-ci.

Y a-t-il un gros avantage qui me manque que nous devrions utiliser mod_rewrite pour tout? Les Poor Man's Clean URLs ™ sont-elles suffisantes pour les parties autres que la base de données de notre site?

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 "vraie" page, alors pourquoi s'embêter avec mod_rewrite? Faire cela annulera les avantages que mod_rewrite offre. À savoir, une URL conviviale pour les moteurs de recherche et une maintenance plus facile du site. Si vous vous arrêtez à l'étape deux, vous bénéficiez de mod_rewrite en n'ayant qu'une seule page à gérer, mais 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 à 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'y a certainement aucune base à cela (et je suppose que les autres aussi). De même, même "index.php? Page = nom de page" n'a pas besoin d'être réécrit en "/ nom de page" - les moteurs de recherche peuvent comprendre ces URL sans aucun problème, et Google a même déclaré qu'il préférait que les utilisateurs ne réécrivent pas. les 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 de belles URL à des URL laides / complexes. Si votre principale préoccupation est d'avoir de belles URL dans les résultats de recherche, je jeter un œil au microformat de fil d'Ariane que Google prend désormais en charge ( http://googlewebmastercentral.blogspot.com/2010/09/rich-snippets-testing-tool- améliorations.html ) car celles-ci peuvent souvent offrir une expérience utilisateur encore meilleure en ce qui concerne les URL dans les résultats de recherche. Cela ne résoudra pas le problème des utilisateurs qui souhaitent créer des liens vers des URL attrayantes, mais à condition que vos URL ne soient pas infiniment complexes (et vos exemples ne le sont pas), cela ne fera probablement pas de 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 consacrer du temps à la conception et au maintien d'une telle configuration.

Ce que vous appelez les «URL propres du pauvre» n'est 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 sont exactement ce que leur nom implique - des URL qui sont propres ou qui paraissent propres. Tous les deux

http://yoursite/foo/bar

et

http://yoursite/foo/bar.php

sont des URL propres. Le terme «URL propres» ne spécifie aucune implémentation particulière. Vous pouvez implémenter des URL propres en générant des pages .html mises en cache chaque fois que le site est mis à jour si vous le souhaitez. mod_rewrite vous permet simplement de dissocier la structure d'URL de la structure de fichier sans redirection ni trame.

D'après ce que cela ressemble, vous n'exécutez pas actuellement un site basé sur une base de données. Et bien qu'il puisse techniquement être qualifié de site Web dynamique, il est probablement plus à l'extrémité statique du spectre si vous utilisez principalement PHP uniquement pour inclure des en-têtes / pieds de page. C'est bien pour les petits sites qui ont rarement besoin d'une mise à jour, mais à mesure que votre site s'agrandit, vous devrez implémenter un vrai CMS.

Lorsque mod_rewrite brille, c'est lorsque 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 script unique qui gère toutes les demandes. Mais si vous n'avez plus de mappage un à un des fichiers .php réels vers les pages Web affichées, vous devrez utiliser quelque chose comme mod_rewrite pour router intelligemment les demandes de page tout en conservant l'illusion de la structure de fichier / répertoire en cours 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 aucune extension de fichier; il permet de masquer les détails de l'implémentation à la visionneuse. L'avantage de cela est que lorsque vous décidez de déplacer votre site de, disons, PHP vers Ruby on Rails, vous pouvez le faire sans changer une seule URL.

Maintenant, bien qu'il soit possible d'exécuter votre site avec ASP.net et d'avoir des noms de fichiers se terminant par .php si vous souhaitez conserver vos URL intacts, il semble plus logique de les faire de telle sorte que le problème ne se pose jamais. .

http://www.example.com/news/2010/10/our-new-url-system/

Peut toujours être une bonne URL, même si vous changez complètement l'architecture sous-jacente, ou passez de fichiers statiques à des fichiers dynamiques .. ou l'inverse.

Il me semble que tout votre contenu dans une base de données serait beaucoup plus rapide et plus facile à gérer, puis à fouiller dans un grand système de fichiers chaque fois que vous avez besoin de faire des mises à jour. Comme John Mueller l'a mentionné ci-dessus, la belle URL ne fera pas une énorme différence dans votre classement, cependant, 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 lui et vous changez cela en exemple.com/pages/widgets.php vous risquez de perdre beaucoup de cette valeur (vous pouvez bien sûr la rediriger, mais il est discutable que ou pas qui passera la même valeur)

Ma recommandation serait que si vous continuez à servir du contenu statique, continuez à utiliser le système de fichiers, si vous le convertissez en contenu dynamique, utilisez Mod_Rewrite pour garder votre structure d'URL actuelle intacte. Ou s'il n'est pas possible de maintenir la structure actuelle, utilisez Mod_Rewrite pour créer une structure qui sera stable pour les futures mises à jour.

Comme cela a été dit, avoir .phpou ?page=n'a pas vraiment d'importance. Ce qui importe, c'est que si vous faites quelque chose comme ça:

http://www.example.com/index.php?page=13