URLs limpias de Poor Man vs. Mod_Rewrite

En la empresa donde trabajo, nos estamos preparando para diseñar un nuevo sitio web, y hay un cierto desacuerdo sobre cómo hacer URL limpias. Durante el año pasado, hemos estado haciendo pequeñas mejoras en nuestro sitio web existente en anticipación de un rediseño a gran escala, que ha involucrado a las URLs limpias de Poor Man's ™.

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

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

Para el nuevo sitio, se habla sobre el uso de mod_rewrite:

1. El usuario solicita http://www.example.com/products/widgets/
2. mod_rewrite los envía a http://www.example.com/index.php?page=products/widgets
3. index.php los envía a la página real http://www.example.com/products/widgets.php

No puedo ver cómo todo este rigamaroll agrega valor. El empleado a favor de mod_rewrite afirma que menos directorios de alguna manera equivale a un mantenimiento más fácil.

Ninguna de nuestras páginas existentes utiliza variables en la cadena de consulta. Todo el contenido está en los archivos reales. Estamos planeando poner algo de contenido en la base de datos, como comunicados de prensa y próximas ferias comerciales a las que asistiremos, pero la gran mayoría de las páginas solo usarán PHP para incluir HTML común como encabezado, pie de página y navegación. Definitivamente estaría dispuesto a usar mod_rewrite para contenido dinámico como ese.

¿Hay algún gran beneficio que me falta de que deberíamos usar mod_rewrite para todo? ¿Son las Poor Man's Clean URLs ™ suficientes para las partes de nuestro sitio que no pertenecen a la base de datos?

El proceso de 3 pasos que describió anteriormente parece redundante e inútil como se indicó anteriormente. Si en el paso 3 index.php los lleva a la página "real", ¿por qué molestarse con mod_rewrite? Hacer eso negará las ventajas que ofrece mod_rewrite. A saber, una URL amigable para los motores de búsqueda y un mantenimiento del sitio más fácil. Si se detiene en el paso dos, se beneficia de mod_rewrite al tener solo una página que mantener, pero puede servir una cantidad virtualmente ilimitada de páginas y ser transparente para el usuario y los motores de búsqueda, ya que solo ven la URL en el paso 1.

Es un mito que "/ pagename" o "/pagename.htm" son mejores para los motores de búsqueda que "/pagename.php". Al menos en Google, definitivamente no hay base para esto (y supongo que los demás también). Del mismo modo, incluso "index.php? Page = pagename" no necesita reescribirse como "/ pagename": los motores de búsqueda pueden entender esas URL sin ningún problema, y ​​Google incluso ha registrado que prefiere que los usuarios no reescriban innecesariamente ( http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html ). Por lo tanto, siempre que no esté creando URL infinitas con parámetros de URL, las URL reescritas no son necesariamente más amigables para los motores de búsqueda que las URL no reescritas .

Dicho esto, los usuarios pueden preferir URL agradables sobre URL feas / complejas. Si su principal preocupación es tener buenas URL en los resultados de búsqueda, echaré un vistazo al microformato de migas de pan que Google ahora admite ( http://googlewebmastercentral.blogspot.com/2010/09/rich-snippets-testing-tool- mejoras.html ) ya que a menudo pueden proporcionar una experiencia de usuario aún mejor con respecto a las URL en los resultados de búsqueda. Esto no resolverá el problema de los usuarios que desean enlaces URL atractivos, pero siempre que sus URL no sean infinitamente complejas (y sus ejemplos no lo son), es probable que no haga una diferencia apreciable si las reescribe para eso caso de uso Si no hay una diferencia medible, entonces probablemente no tenga sentido dedicar tiempo a diseñar y mantener dicha configuración.

Lo que usted denomina las "URL limpias del pobre" son solo URL limpias implementadas a través del sistema de archivos. Puede tener esos tipos de URL usando mod_rewrite, así como puede tener el segundo tipo de URL sin mod_rewrite.

Las URL limpias son exactamente lo que el nombre implica: URL que están limpias o se ven limpias. Ambos

http://yoursite/foo/bar

y

http://yoursite/foo/bar.php

son URL limpias. El término "URL limpias" no especifica ninguna implementación en particular. Puede implementar URL limpias generando páginas .html en caché cada vez que el sitio se actualice si lo desea. mod_rewrite simplemente le permite desacoplar la estructura de URL de la estructura de archivos sin redireccionamientos ni marcos.

Por lo que parece, actualmente no está ejecutando un sitio basado en bases de datos. Y aunque técnicamente podría calificarse como un sitio web dinámico, probablemente esté más en el extremo estático del espectro si está usando PHP principalmente para incluir encabezados / pies de página. Eso está bien para sitios pequeños que rara vez necesitan actualizarse, pero a medida que su sitio crezca, necesitará implementar un CMS real.

Donde mod_rewrite brilla es cuando comienzas a tener en cuenta la mantenibilidad. En lugar de tener cientos de archivos php para cada página de producto (con un montón de código redundante), simplemente puede tener un solo script que maneje todas las solicitudes. Pero si ya no tiene un mapeo uno a uno de los archivos .php reales a las páginas web mostradas, entonces necesitará usar algo como mod_rewrite para enrutar las solicitudes de la página de manera inteligente mientras mantiene la ilusión de que la estructura del archivo / directorio está allí.

Por lo tanto, no es el subdirectorio adicional lo que debería preocuparle. Es el hecho de que está creando un script .php separado para cada página de su sitio.

"URLS limpias" a menudo significa que no hay archivo ext; ayuda a ocultar detalles de implementación del espectador. La ventaja de esto es que cuando decide mover su sitio de, por ejemplo, PHP a Ruby on Rails, puede hacerlo sin cambiar una sola URL.

Ahora, si bien es posible ejecutar su sitio con ASP.net y tener nombres de archivo que terminen en .php si desea mantener su URL intacta, parece tener más sentido hacerlo de tal manera que el problema nunca tenga que surgir .

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

Siempre puede ser una buena URL, incluso si cambia completamente la arquitectura subyacente, o pasa de archivos estáticos a dinámicos ... o al revés.

Me parece que tener todo su contenido en una base de datos sería mucho más rápido y más fácil de mantener que luego buscar en un gran sistema de archivos cada vez que necesite realizar actualizaciones. Como John Mueller mencionó anteriormente, la buena URL no hará una gran diferencia en su clasificación, sin embargo, debe considerar usar Mod_Rewrite para mantener sus URL existentes y su valor. IE si:

example.com/widgets/index.php tiene 1,000 enlaces que apuntan a él y cambia eso para que sea example.com/pages/widgets.php, corre el riesgo de perder mucho de ese valor (por supuesto, puede redirigirlo, pero es discutible si o no, eso pasará el mismo valor)

Mi recomendación sería que si continúa sirviendo contenido estático continúe usando el sistema de archivos, si lo está convirtiendo en contenido dinámico use Mod_Rewrite para mantener intacta su estructura URL actual. O si no es posible mantener la estructura actual, use Mod_Rewrite para crear una estructura que sea estable para futuras actualizaciones.

Como se ha dicho, tener .phpo ?page=no importa realmente. Lo que importa es si estás haciendo algo como esto:

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