Logo
You
Code

Friendly URLs o URLs amigables

Autor hectormainar.com - http://www.youcode.com.ar/wiki/friendly-urls-o-urls-amigables-47

Hoy hablaré de otro recurso clave a optimizar dentro de nuestro sitio para tener una página con posibilidades de pelear en las páginas de resultados de búsqueda para una palabra clave. Son las URL, y su importancia es vital para el SEO, para definir la estructura del sitio y para mejorar la forma en la que el usuario visualiza la página web. La cantidad de posibilidades en torno a las URL internas de nuestro sitio es infinita, y en este artículo daré una guía sobre como generar URLs amigables pa

 


URLs y SEO


Una URL (Uniform Resource Locator) o dirección de internet está formada por varias partes:



protocolo://máquina/fichero

En nuestro caso, al tratarse de web, el protocolo se corresponderá siempre con http y la máquina se expresará habitualmente como la combinación:



subdominio.dominio.extension

Nuestro nombre de dominio va a influenciar en buena parte la palabra clave principal para la que nuestra web se indexará, especialmente en su portada. Google ha ido indicando paulatinamente una pérdida del peso de este elemento en el algoritmo de posicionamiento, pero lo cierto es que tener una palabra clave interesante para nuestro ámbito en el dominio supone sin duda todavía una cierta ventaja sobre nuestros competidores en igualdad de condiciones de otros factores. Por ello, en ocasiones es interesante prescindir un poco del branding de nuestra compañía para orientar nuestra web a una palabra clave muy marcada. Aunque el dominio forma parte de la URL, el objetivo principal de este artículo es el hablar de la siguiente parte de la dirección, la que hace referencia al fichero que cargamos una vez hemos localizado la máquina a la que deseamos acceder. Por ello, no incidiré en el tema del dominio y pasaré completamente de largo los subdominios, sobre cuyo uso para crear una estructura web adecuada para seguir una estrategia SEO adecuada para un sitio web complejo se pueden llenar páginas y páginas debido a que nos permiten aislar partes de nuestro sitio para que los buscadores la tengan en cuenta como páginas independientes.


URLs amigables


Antiguamente, cuando las páginas aún se hacían en HTML estático, el significado de la parte de después del dominio en la URL era evidente: hacía referencia a la ruta de un fichero desde la raíz de directorios de la web. Así, esa parte contenía la carpeta donde se encontraba el fichero que estábamos viendo, y su nombre de archivo. En el desarrollo, lo más fácil acababa siendo dar nombres lógicos al fichero, y con ello las palabras clave se obtenían de forma natural. Google daba más importancia a los ficheros cuanto más cerca de la raíz estuvieran, con lo cual era interesante crear carpetas para organizar la estructura de los archivos de la web pero no pecar de utilizar rutas demasiado largas. Una URL habitual para una página de HTML podía ser:



http://www.dominio.com/contacto.html

Con la llegada de los lenguajes de servidor (PHP, ASP…), estas URL se tornaron complejas, del estilo de:



http://www.dominio.com/index.php?id=23&order=asc&item=32&cat=33

Los factores técnicos para indicar los datos a extraer de una base de datos y para seleccionar el tipo de página a mostrar tomaron el control frente a las hasta entonces URLs, por defecto amigables sin necesidad de premeditarlas demasiado. Con URLs de este tipo, la dirección web ya no aporta nada sobre el contenido de la página: los motores de búsqueda no saben qué es ese id23, ni esa sarta de parámetros colocados tras ellos. Los buscadores quieren direcciones interesantes, como:



http://www.dominio.com/artes-marciales/karate-declarado-deporte-olimpico

Así, tenemos el problema de que Google no encuentra en ese primer formato de dirección nada que le interese, y que inicialmente con un lenguaje de servidor no sabremos actuar respecto a la segunda dirección. Por suerte, estos lenguajes y los servidores nos dan métodos para interpretar ese segundo formato de dirección, como veremos en este post. Pero antes…


¿Qué nos aporta una URL amigable?


Una URL amigable o Friendly URL nos aporta numerosas ventajas en nuestro sitio web:



  • Al disponer de palabras clave, el buscador puede interpretar su contenido.

  • Cuando se enlazan sin más texto alternativo que la URL –una práctica muy habitual-, el texto de enlace contiene palabras clave para las que nos posicionaremos en buscadores.

  • Son recordables por humanos, e interpretables por personas antes de acceder a la web.

  • Nos permiten jerarquizar las páginas del sitio y organizarlas en categorías mejor que utilizando ficheros PHP al uso.

  • Ocultan cómo está programada la página web, que parámetros recibe, etcétera: el usuario no llega a ver jamás la dirección del fichero que se está cargando.

  • Por pura cuestión estética, los enlaces son más atractivos al copiarlos, leerlos, publicarlos en anuncios…La web da aspecto de ser más limpia y profesional.


Consejos para generar los textos de las URL amigables



  • Mantén las direcciones relativamente cortas.

  • Haz que aparezcan las palabras clave para las que quieres posicionar la web.

  • No intentes introducir en la URL más palabras claves que las puramente lógicas e importantes para el artículo.

  • Separa las palabras, idealmente con guiones altos, nunca con espacios (pues se convierten al enlazar la web en signos como %20), y recomendablemente no con guiones bajos (al no verse tradicionalmente en los enlaces al coincidir con el subrayado del enlace, los buscadores decidieron no interpretarlo como un separador de palabras válido, aunque las cosas están cambiando). No uses tampoco el signo “+” para separar palabras, pues suele utilizarse para separar valores de un parámetro GET.

  • Evita las mayúsculas y acentos, suelen dar problemas al copiarlos de forma errónea en URLs. En general, cuanto más simple sea la codificación que utilices, menos  problemas dará en aplicaciones externas no siempre preparadas para codificaciones internacionales.

  • Evita los puntos cerca del final de la dirección, que puedan generar ficheros como .com, .exe… que puedan malinterpretarse por el navegador.

  • Elimina los artículos, preposiciones y palabras que no aporten valor.

  • Puedes forzar a que las direcciones acaben en .html. Antiguamente se hacía para que no se supiera que era una web dinámica, hoy no es en absoluto necesario.


Son solo consejos, y la antítesis a varios de ellos la encontrarás curiosamente en una de las páginas mejor posicionadas del mundo, Wikipedia, que utiliza acentos en sus direcciones, guiones bajos, mayúsculas…


Cuando no utilizar URLs amigables


Es muy difícil e innecesario que una página web tenga URLs amigables para todo. Pensando puramente en posicionamiento, existen varios casos donde no merece la pena prestar atención al formato de las URL:



  • Si una página no es relevante para que esté indexada en Google o sea compartida, pues los datos proceden de una consulta puntual y casi irrepetible.

  • Cuando su contenido está restringido dentro de una zona de usuario, a la que no se va a acceder desde enlaces externos ni buscadores, y cuya ruta el usuario no va a tener intención de memorizar.

  • Cuando su contenido se invoca siempre desde Ajax.

  • Cuando una URL dependa de tantos parámetros que sea imposible generar una URL amigable sin ellos.


 


Cómo se pasa de una URL amigable a un código PHP


La magia detrás de una URL amigable radica en buena parte en los archivos .htaccess de Apache(existen alternativas para otro tipo de servidores, pero hablaré exclusivamente de Apache por ser el más frecuente). Los ficheros htaccess nos permiten establecer configuraciones personalizadas para carpetas concretas de nuestro servidor, modificando parámetros de la configuración del mismo sólo para los ficheros localizados en esta carpeta. Entre los numerosos usos de .htaccess, uno de los más frecuentes es el establecer redirecciones de unos ficheros a otros mediante el módulo de Apache mod_rewrite.


Para comprobar si tienes instalado el módulo mod_rewrite, crea un fichero con extensión .php que contenga el siguiente texto:



<?php phpinfo(); ?>

Este comando muestra toda la información sobre tu configuración de servidor. Carga ese documento desde el navegador, y dentro del epígrafe Loaded Modules deberías ver mod_rewrite. De no ser así, debes activar el módulo editando el fichero httpd.conf de tu servidor apache (busca ese fichero y edítalo) para descomentar la siguiente línea eliminándole el corchete y reiniciando el servidor.



#LoadModule rewrite_module modules/mod_rewrite.so

Una vez tengas mod_rewrite instalado, llega el momento de crear un fichero de nombre .htaccess(con el punto inicial) en la carpeta donde se encuentre tu web. En él, vamos a comenzar a definir redirecciones.


Un fichero .htaccess de redirecciones es similar al siguiente.



Options +FollowSymlinks
RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{HTTP_HOST} ^dominio\.com
RewriteRule (.*) http://www.dominio.com/$1 [R=301,L]

RewriteRule !(estatica).+$ index.php

Las dos primeras líneas activan el sistema de reescritura de URLs (la opción FollowSymLinks es un requisito para que mod_rewrite funcione, y aunque suele estar activado en el servidor lo incluyo en el .htaccess por si acaso).



RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f

En las siguientes líneas estamos definiendo condiciones, y reglas de rescritura en caso de que se cumplan. En la línea 3, mediante la orden



RewriteCond %{REQUEST_FILENAME} !-f

Obligamos a que si un fichero existe como tal (por ejemplo, estamos cargando una imagen que sí existe y que no debe pasar por PHP), se va a servir ese fichero en lugar de realizar ningún tipo de redirección.


A continuación todo se va a basar en expresiones regulares. Una expresión regular es una forma de expresar una condición o patrón que se prueba en una cadena (en este caso, el nombre de la URL a cargar) para que si la cadena encaja en el patrón probado realizar una acción concreta (en este caso, redirigir a un fichero). Las expresiones regulares son un mundo rico y complejo de primeras, así que si no estás demasiado puesto deberías leer el artículo de la Wikipedia que sirve de introducción a esta herramienta presente en la mayoría de los lenguajes de programación:http://es.wikipedia.org/wiki/Expresi%C3%B3n_regular . La web http://www.regular-expressions.info/ofrece también numerosa y detallada información sobre estas expresiones en diversos lenguajes.


Siguiendo con nuestro fichero htaccess, en las líneas 4 y 5 lo que estamos definiendo es una condición para que en caso de que lo primero que aparezca en el host a cargar sea directamente el nombre del dominio (sin www), lo redirigemos en la regla a su equivalente con www, para unificar todas nuestras direcciones para su uso forzado de la forma con www aunque el visitante no las escriba. Si generas un fichero htaccess es una buena idea incorporar este par de líneas a él.



RewriteCond %{HTTP_HOST} ^dominio\.com
RewriteRule (.*) http://www.dominio.com/$1 [R=301,L]

Observa como estamos realizando redirecciones permanentes 301 mediante la coletilla final, forzando así a que Google indexe la dirección con WWW en lugar de la que no las tiene, para indicar que la página ya no existe en la otra ubicación. Existen varios flags que podemos colocar en este punto, siendo los más habituales:



  • Con el parámetro R podemos indicar un tipo de redirección, como el 301 de redirección permanente en este caso. Por defecto, si no se indica esto, es 302 (movido temporalmente).

  • L: En caso de que se cumpla con este patrón y se realice la redirección, ya no se continúan analizando el resto de redirecciones del htaccess. 

  • NC: Indica que el patrón se encaja de forma “case insensitive”, es decir, dará igual escribir la URL en mayúsculas o minúsculas.


La siguiente línea es una condición de ejemplo en la que definimos cómo deseamos redirigir unas direcciones escritas por el visitante a los ficheros que deseemos que interpreten las órdenes para generar la web a mostrar. Imaginemos que tenemos varias carpetas estáticas (estatica1,estatica2…) que no deseamos tratar con PHP pues tenemos en ellas alojadas páginas en HTML. La orden indica que cualquier fichero que no comience con la cadena “estatica” va a cargar en su lugar el fichero index.php.



RewriteRule !(estatica).+$ index.php

Al definir la expresión regular, podemos definir también patrones que capturaremos para pasar como parámetro GET al fichero indicado:



Rewriterule ^noticia/(.+) index.php?modulo=noticias&id=$1

De este modo, escribir http://www.dominio.com/noticia/22 sería equivalente a escribirhttp://www.dominio.com/index.php?modulo=noticias&id=22 . Aunque el fichero noticia/22 no existe físicamente en el servidor, devolverá el resultado de la página generada por la ruta de redirección que hemos indicado.


En este ejemplo he mostrado un único parámetro pero se pueden añadir tantos bloques variables como se desee en la ruta, cuyas subexpresiones encajadas podremos utilizar o no para construir la URL a la que redirigimos (es decir, el patrón indicado puede tener varias subexpresiones, y no pasar todas ellas al fichero PHP). En las subexpresiones, podemos verificar cadenas de caracteres, tipos de parámetros (numéricos, texto…). Todo al final se basa en estos parámetros, con lo cual cuanto más hábil se sea con las expresiones regulares más posibilidades tendremos de generar reglas de redirección complejas que nos permitan conseguir nuestros objetivos. De todos modos, la complejidad de validar rutas con expresiones regulares es quizás uno de los usos más sencillos que podemos dar a estas expresiones, con lo cual no debe asustarnos el enfrentarnos a generar ficheros htaccess sin dominarlas por completo.


Formatos de URL amigable y su explotación


Con las posibilidades que las expresiones regulares nos aportan, existen varias formas de tratar las URLS amigables. La forma más básica quizás sea el utilizar un formato similar a este:



RewriteRule ^noticia-([0-9]+)/[A-Z0-9_-]+\.html$ /noticias.php?id=$1 [L]

Es decir, las URLs serían del formato:



http://www.dominio.com/noticia-28/karate-declarado-deporte-olimpico.html

En este caso, disponemos de un fichero php para cada tipo de contenido o sección, y recibimos un parámetro que indica el identificador del fichero a leer u otros parámetros. Algo similar sería organizar los contenidos como si se encontraran realmente en carpetas por secciones, por ejemplo:



RewriteRule ^noticias/([0-9]+)/[A-Z0-9_-]+$ noticias.php?id=$1 [L]

Es decir, noticias para:



http://www.dominio.com/noticias/28/karate-declarado-deporte-olimpico

A nivel de código PHP tanto una como otra opción utilizan una organización de ficheros PHP algo anticuada, y resulta mucho más habitual, sin modificar la URL, pasar al visitante por un fichero index.php que efectúe labores de bootstrap. Por ejemplo, con una redirección como:



RewriteRule ^noticias/([0-9]+)/[A-Z0-9_-]+\.html$ index.php?modulo=noticias&id=$1 [L]

Dispondríamos de un fichero PHP en el que mediante un switch podríamos discernir entre los módulos a cargar, para incorporar el código u objetos necesarios para procesar la petición.


Otra posibilidad es redirigir las URL directamente a un único fichero sin parámetros:



RewriteRule !(css|images|js).+$ index.php

Por ejemplo, en este caso redirigimos todo salvo las carpetas de imágenes, estilos y javascripts a un fichero de bootstrap. Desde ese fichero, podríamos acceder a la URL original del navegador desde la variable  $_SERVER["REQUEST_URI"]. Procesando esa variable con PHP podríamos saber qué contenido debemos servir sin problemas. 

Todas estas formas de URLs vistas hasta el momento tienen un problema: la URL no es única. Por ejemplo, en el primero de los casos vistos hasta ahora, todas estas URL devolverían la misma noticia:



http:/ /www.dominio.com/noticia-28/karate-dimite-presidente-federacion
http:/ /www.dominio.com/noticia-28/aaaa
http:/ /www.dominio.com/noticia-28/justin-bieber-nuevo-cantante-foo-fighters 

Esto ocurre porque a la hora de crear la redirección tan sólo estamos teniendo en cuenta el parámetro del identificador del artículo en la base de datos, ignorando la cadena de texto posterior. Por este hecho, cualquier enlace entrante con una dirección errónea comenzaría a crear páginas duplicadas cuando los buscadores las indexen, perdiendo posicionamiento nuestro documento. Para evitarlo de forma interna, deberías tener en tu aplicación web una función que genere la URL para cada contenido, de tal forma que siempre enlacemos igual cada documento desde nuestra web. De todas formas, el enlace erróneo puede venir también del exterior y duplicar nuestro documento. Una solución fácil a este problema sería incluir una metaetiqueta canonical en el documento HTML, que indique la URL preferida para ese contenido, de tal forma que en la mayoría de buscadores se indexará con la dirección indicada en esa etiqueta. Simplemente incluye la dirección preferida generada por tu función de URLs para ese fichero en la etiqueta canonical dentro del head de tu documento:



<link href="http://www.dominio.com/noticia-28/karate-olimpico" rel="canonical" />

La solución más elegante para evitar URLs duplicadas y generar las direcciones amigables más cortas posibles es evitar directamente el uso del identificador de la base de datos. Para generar este método, al crear cualquier nuevo artículo en nuestro sitio, almacenaremos en una base de datos el alias de esa página (es decir, su dirección amigable generada a partir del título del artículo y asegurándose de que es una dirección única). De este modo, al redirigir las peticiones al fichero de bootstrap, el primer paso sería el comprobar en la base de datos si existe una dirección almacenada para esa petición, y en caso de encontrar coincidencia generar el documento indicado. Así tendríamos direcciones tan cortas como:



http://www.dominio.com/karate-declarado-deporte-olimpico

Direcciones cortas de este tipo deberían conseguirse al menos para las páginas que vamos a compartir frecuentemente con humanos: campañas de publicidad, páginas de contacto, secciones que queremos que se agreguen a favoritos… Bien sea mediante alias en bases de datos o tecleadas directamente en el htaccess, está bien tener cosas como http:/ /www.tudominio.com/escribenos o http:/ /www.tudominio.com/trabajos que pueden ser fácilmente recordadas, impresas y compartidas.


No siempre es necesario llegar a este extremo de limpieza: incluir un “directorio virtual” como podría ser http:// www.dominio.com/artes-marciales/karate-declarado-deporte-olimpico nos permite jerarquizar mejor nuestros contenidos, aportar palabras claves adicionales y simplificar el procesado de los diferentes tipos de contenido en nuestra web, al tener acceso a la URL a información sobre la categoría de la información que estamos tratando.


Por último, recuerda que las URLs amigables no sólo sirven para páginas HTML: es posible generar URLs limpias para imágenes y mejorar así su posicionamiento en el buscador de imágenes, bien enlazándolas manualmente en el htaccess o pasándolas también por un bootstrap interpretado en el servidor (cuidado con la sobrecarga).


¿Debo cambiar mis URL?


Tras leer todo el post, quizás hayas sacado algo en claro para mejorar tus URL amigables y te planteas el modificarlas. Mi consejo es que si tus direcciones no están radicalmente mal, no las cambies por ahora sino que utilices estos consejos sólo en nuevos proyectos. Si las quieres cambiar, asegúrate de que la dirección antigua sigue siendo accesible y de que generas correctamente redirecciones 301 desde esa dirección antigua a la nueva, para asegurar que se van desindexando las direcciones viejas en favor de las nuevas transmitiéndoles su linkjuice. Todo el cambio debe realizarse de golpe y con las redirecciones bien hechas desde el primer momento, no hay segundas oportunidades para hacer el cambio sin verse demasiado perjudicado si hay cualquier error.




 

http://www.youcode.com.ar/wiki/friendly-urls-o-urls-amigables-47