Un Re­w­ri­teE­n­gi­ne es un co­m­po­ne­n­te de software de un servidor web que permite re­es­cri­bir o re­di­re­c­cio­nar URL. Su de­no­mi­na­ción está compuesta por los términos pro­ce­de­n­tes del inglés “rewrite” (re­es­cri­bir) y “engine” (máquina, motor). El más conocido es el mod_rewrite del servidor HTTP Apache, aunque también otros se­r­vi­do­res web como nginx o lighttpd disponen de estas funciones.

Este módulo de re­es­cri­tu­ra encuentra apli­ca­ción cuando, por ejemplo, hay que tra­n­s­fo­r­mar una dirección URL in­ma­ne­ja­ble, como las que generan los sistemas de gestión de co­n­te­ni­dos, en URL amigables. Los motivos saltan a la vista. Veamos estas dos di­re­c­cio­nes:

"http://ejemplo.com/a/index.php?title=ti­tu­lo­de­la­pa­gi­na"

"http://ejemplo.com/articulo/ti­tu­lo­de­la­pa­gi­na"

Las di­re­c­cio­nes generadas té­c­ni­ca­me­n­te, como la primera, son difíciles de recordar por los usuarios, pero un Re­w­ri­teE­n­gi­ne permite que el mismo recurso esté di­s­po­ni­ble de forma paralela bajo una dirección URL mucho más sencilla, como vemos en la segunda línea.

De esta forma, un in­te­r­nau­ta también puede hacer uso de este URL para ir a la página co­rre­s­po­n­die­n­te. Cuando el servidor web recibe una petición de este tipo, el Re­w­ri­teE­n­gi­ne reescribe au­to­má­ti­ca­me­n­te el URL según el esquema que usa el servidor in­te­r­na­me­n­te (primera dirección del ejemplo anterior).

Podría decirse que el software crea una especie de capa de ab­s­tra­c­ción que se sitúa entre los URL que el proyecto web utiliza a nivel interno y aquellos que se muestran de forma pública en la red; esto es lo que permite mostrar un esquema de di­re­c­cio­nes unitario y amigable in­de­pe­n­die­n­te­me­n­te de los re­qui­si­tos técnicos. Mientras que in­te­r­na­me­n­te la dirección dinámica puede seguir usándose, el usuario tiene la po­si­bi­li­dad de acceder a una página con una dirección apa­re­n­te­me­n­te estática, cuya ventaja radica en que sigue siendo válida incluso cuando se realicen cambios internos en la jerarquía de los archivos.

Otro de los be­ne­fi­cios de los Re­w­ri­teE­n­gi­ne para los ope­ra­do­res web es que permite im­ple­me­n­tar desvíos en función de de­te­r­mi­na­das co­n­di­cio­nes. Esto pe­r­mi­ti­ría, por ejemplo, co­n­fi­gu­rar una re­di­re­c­ción para im­ple­me­n­tar una acción de geo­ta­r­ge­ti­ng o para mostrar páginas web op­ti­mi­za­das es­pe­cí­fi­ca­me­n­te para ciertos te­r­mi­na­les, basándose en la ide­n­ti­fi­ca­ción del agente de usuario o en la dirección IP del cliente que realizó la petición. Aquí suele usarse una re­di­re­c­ción 301 que garantiza, a pesar del fu­n­cio­na­mie­n­to en paralelo de páginas móviles adi­cio­na­les o de versiones en di­fe­re­n­tes idiomas, que se almacene úni­ca­me­n­te una versión en el índice del buscador. En cualquier caso habría que di­s­ta­n­ciar­se de prácticas como el cloaking, con la cual se optimizan páginas web ex­clu­si­va­me­n­te en función de la araña del buscador para lograr un buen po­si­cio­na­mie­n­to.

Cómo se utiliza un Re­w­ri­teE­n­gi­ne

Un software de URL rewriting dispone de varios comandos para la ma­ni­pu­la­ción de URL que se pueden in­tro­du­cir en di­fe­re­n­tes lugares del software del servidor web. Mod_Rewrite, el software del servidor web Apache, puede uti­li­zar­se en un co­n­te­ne­dor de di­re­c­to­rios dentro de httpd.conf, en un apartado del Vi­r­tua­lHo­st o dentro del archivo .htaccess. En el servidor nginx la re­es­cri­tu­ra de URL se nota en el archivo de co­n­fi­gu­ra­ción /etc/nginx/nginx.conf, y en lighttpd se puede hacer en el archivo de la co­n­fi­gu­ra­ción del vHost /etc/lighttpd.conf.

Siguiendo el ejemplo inicial, el camino que lleva de la primera a la segunda dirección sigue, en función de si se usa un Re­w­ri­teE­n­gi­ne en un servidor Apache, nginx o lighttpd, di­fe­re­n­tes comandos.

Re­w­ri­teE­n­gi­ne con Apache

Para usar mod_rewrite con Apache hay que activar el Re­w­ri­teE­n­gi­ne con la directiva Re­w­ri­teE­n­gi­ne on. A co­n­ti­nua­ción, se introduce la regla de re­es­cri­tu­ra Re­w­ri­te­Ru­le, en la cual se definen las in­di­ca­cio­nes de re­es­cri­tu­ra por medio de las de­no­mi­na­das “ex­pre­sio­nes regulares” („regular ex­pre­s­sio­ns“, Regex):

RewriteEngine on
RewriteRule ^/articulo/(.*)$ /a/index.php?title=$1

Si se quiere definir un desvío con una Re­w­ri­te­Ru­le, esta contiene dos pa­rá­me­tros fu­n­da­me­n­ta­les: pattern (origen) y su­b­s­ti­tu­tion (destino).

  • Pattern: este parámetro describe a los URL que han de ser re­di­re­c­cio­na­dos. Para ello se define una condición es­pe­cí­fi­ca en la forma de una cadena de ca­ra­c­te­res. Si se cumple esta condición, se realiza el desvío al URL indicado en el parámetro de destino. En nuestro ejemplo anterior este patrón co­rre­s­po­n­de al fragmento de la Re­w­ri­te­Ru­le: ^/artikel/(.*)$.
  • Su­b­s­ti­tu­tion: este describe al URL de destino. Si la re­di­re­c­ción se configura a nivel de servidor la su­b­s­ti­tu­ción afecta al URL completo. Si se realiza a nivel del di­re­c­to­rio en el archivo .htaccess o dentro del httpd.conf, solo se sustituye el fragmento del URL a partir del di­re­c­to­rio actual. En el ejemplo co­rre­s­po­n­de a este fragmento: /a/index.php?title=$1.

En la siguiente tabla se muestran los si­g­ni­fi­ca­dos de las ex­pre­sio­nes regulares uti­li­za­das en el ejemplo:

Ex­pre­sio­nes regulares Si­g­ni­fi­ca­do
^ Indica el comienzo de una secuencia.
$ Marca el final de una secuencia.
(.*) Marcador para cualquier sucesión de ca­ra­c­te­res dentro de un URL. Los pa­ré­n­te­sis guardan la sucesión en una variable.
$1 Una variable que permite acceder a valores al­ma­ce­na­dos por los pa­ré­n­te­sis en una memoria in­te­r­me­dia.

La Re­w­ri­te­Ru­le ^/articulo/(.*)$ /a/index.php?title=$1 define así la norma de que, en todos los URL que comiencen con la secuencia /articulo/(.*), este fragmento se sustituya por el esquema dinámico /a/index.php?title=$1, donde $1 equivale a la sucesión de ca­ra­c­te­res al­ma­ce­na­da en el marcador (.*). Cuando un usuario introduce el URL estático "http://ejemplo.com/articulo/ti­tu­lo­de­la­pa­gi­na" en el navegador, el servidor web la reescribe basándose en mod_rewrite de forma interna e invisible para el usuario, co­n­vi­r­tié­n­do­la en la dirección dinámica "http://ejemplo.com/a/index.php?title=ti­tu­lo­de­la­pa­gi­na";. El marcador (.*) y la variable $1 co­rre­s­po­n­den, en este caso, a la secuencia de ca­ra­c­te­res „ti­tu­lo­de­la­pa­gi­na“. Si la re­es­cri­tu­ra ha de ir vinculada a de­te­r­mi­na­das opciones que controlan el co­m­po­r­ta­mie­n­to de mod_rewrite, se notan entre corchetes a co­n­ti­nua­ción de la Re­w­ri­te­Ru­le y separadas por comillas si se trata de varias opciones. De esta manera pueden im­ple­me­n­tar­se también re­di­re­c­cio­nes externas usando los códigos de estado HTTP. La siguiente tabla muestra una selección de opciones para la Re­w­ri­te­Ru­le. La lista completa se encuentra en la página oficial de la Apache Software Fou­n­da­tion.

Opción Bandera (flag) Función
Redirect (redirigir) R La bandera [R] indica al servidor web que ha de llevar a cabo un desvío externo mediante el código de estado HTTP 302. Si se ha de enviar un código de estado diferente, se añade a la bandera con el signo ma­te­má­ti­co “igual a” (p. ej. [R=301)].
Forbidden (prohibido) F Ordena al servidor web enviar el código de estado 403 (prohibido) al navegador web.
Gone (no existe) G Ordena al servidor web tra­n­s­mi­tir al navegador el código de estado 410 y marca la página web so­li­ci­ta­da como no di­s­po­ni­ble.
Last (última) L Indica al servidor web no ejecutar más reglas tras la actual Re­w­ri­te­Ru­le.
Nocase NC Al comprobar si un URL cumple las co­n­di­cio­nes para la re­es­cri­tu­ra no se atiende a ma­yú­s­cu­las o mi­nú­s­cu­las.
Chain C Solo se tendrá en cuenta a la siguiente Re­w­ri­te­Ru­le si se cumple la condición actual.

Según estas opciones, una re­di­re­c­ción externa por medio de códigos de estado HTTP se realiza de la siguiente forma:

RewriteEngine On
RewriteRule ^paginavieja.html$ /paginanueva.html [R=301]

Junto a las Re­w­ri­te­Ru­les, con el módulo de Apache también se pueden definir las de­no­mi­na­das Re­w­ri­te­Co­n­ds, con las cuales los ope­ra­do­res web fijan las co­n­di­cio­nes adi­cio­na­les que se han de cumplir para que se pueda llevar a cabo el proceso de re­es­cri­tu­ra.

La sintaxis de una Re­w­ri­te­Co­nd sigue el siguiente esquema y se sitúa por delante de la Re­w­ri­te­Ru­le:

RewriteCond TESTSTRING CONDITION

La secuencia Te­sts­tri­ng contiene por lo general las llamadas variables del servidor definidas por un signo de po­r­ce­n­ta­je y claves: %{HTTP_HOST}. La siguiente tabla muestra una selección de variables:

Variable del servidor Si­g­ni­fi­ca­do
HTTP_USER_AGENT Se refiere al cliente que se utiliza para acceder al servidor. Esta variable suele usarse para poner a di­s­po­si­ción de di­fe­re­n­tes na­ve­ga­do­res web (agentes de usuario) una página web op­ti­mi­za­da para cada uno.
HTTP_HOST Hace re­fe­re­n­cia al nombre del host, que puede contener valores como dominio.com, su­b­do­mi­nio.dominio.com o la dirección IP.
SERVER_PORT Se refiere al puerto de destino, por ejemplo, 80 para HTTP o 443 para HTTPS. Esta variable permite a los ope­ra­do­res web desviar a las visitas a una conexión segura.
REMOTE_ADDR Hace alusión a la dirección IP de un usuario con acceso al servidor web. Suele usarse para bloquear ataques de spam.

El siguiente ejemplo muestra una Re­w­ri­te­Co­nd, que vincula la Re­w­ri­te­Ru­le co­n­se­cu­ti­va a la dirección IP de un usuario con acceso al servidor:

RewriteCond %{REMOTE_ADDR} 173.45.68.79

URL rewriting con nginx

El servidor web nginx también soporta de forma nativa la re­es­cri­tu­ra de URL, realizada asimismo con ayuda de ex­pre­sio­nes regulares. El comando de re­es­cri­tu­ra se añade se­n­ci­lla­me­n­te, siguiendo la sintaxis nginx, en un bloque { [...] } en el archivo de co­n­fi­gu­ra­ción del servidor web /etc/nginx/nginx.conf:

location /articulo {
 rewrite ^/articulo/(.*)$ /index.php?title=$1 last;
}

La secuencia location/articulo indica que la re­es­cri­tu­ra hace alusión al su­b­di­re­c­to­rio “articulo”. Las ex­pre­sio­nes regulares que se usan aquí son las mismas que se utilizan en el servidor de Apache, y se in­tro­du­cen con el comando rewrite. La bandera last indica que la re­es­cri­tu­ra es interna y se ejecuta sin re­di­re­c­ción. Las banderas también están di­s­po­ni­bles para un desvío temporal o pe­r­ma­ne­n­te:

Bandera (flag) Si­g­ni­fi­ca­do
last Los URL se re­es­cri­ben in­te­r­na­me­n­te. No hay re­di­re­c­ción.
redirect El usuario es desviado te­m­po­ra­l­me­n­te mediante el código 302-Redirect a una nueva dirección.
permanent Con el código 301-Redirect se re­di­re­c­cio­na al usuario de forma pe­r­ma­ne­n­te a la nueva dirección.

Si no se utiliza ninguna bandera, nginx indica por defecto el código HTTP de error 500.

Re­es­cri­tu­ra con lighttpd

En este caso, el proceso de URL rewriting se realiza a partir de la función url.rewrite-TYP, donde el marcador TYP re­pre­se­n­ta las opciones di­s­po­ni­bles para la co­n­fi­gu­ra­ción de la re­es­cri­tu­ra:

Opción de co­n­fi­gu­ra­ción Si­g­ni­fi­ca­do
url.rewrite-once Solo se reescribe una vez. Una vez se ha en­co­n­tra­do el pattern y se ha reescrito en función de su­b­s­ti­tu­tion, no se realizan más mo­di­fi­ca­cio­nes.
url.rewrite-repeat Se di­fe­re­n­cia del primero en que en este caso a la primera mo­di­fi­ca­ción sí pueden seguir otras re­es­cri­tu­ras.

Como en un servidor lighttpd también se utilizan las mismas ex­pre­sio­nes regulares que en mod_rewrite, la sintaxis sigue ese­n­cia­l­me­n­te el modelo que ya conocemos:

url.rewrite-once = (
 "^/articulo/(.*)$" => "/index.php?title=$1"
)

Si, en lugar de una re­es­cri­tu­ra interna se ha de ejecutar una re­di­re­c­ción externa, en lighttpd no se usa el módulo de re­es­cri­tu­ra, sino un módulo de re­di­re­c­ción, aunque, primero, los URL han de pasar por el módulo de re­es­cri­tu­ra antes de pasar el de re­di­re­c­ción.

Re­es­cri­tu­ra de URL con Microsoft IIS

La pla­ta­fo­r­ma Microsoft Internet In­fo­r­ma­tion Services (IIS) no posee ningún software nativo de re­es­cri­tu­ra, pero se puede añadir po­s­te­rio­r­me­n­te al servidor web con la extensión Modul IIS URL Rewrite 2.0. De esta forma, los usuarios de Microsoft también pueden poner a di­s­po­si­ción de sus visitas URL amigables sin tener que ade­n­trar­se en la gestión interna de archivos. Una vez de­s­ca­r­ga­da, esta extensión de re­es­cri­tu­ra se integra en la interfaz IIS Manager, donde se pueden in­tro­du­cir Re­w­ri­te­Ru­les en una interfaz de usuario gráfica. Este módulo también utiliza ex­pre­sio­nes regulares para definir patterns y su­b­s­ti­tu­tio­ns.

URL rewriting y op­ti­mi­za­ción para los bu­s­ca­do­res

La po­si­bi­li­dad de tra­n­s­fo­r­mar URL pa­ra­me­tri­za­das en di­re­c­cio­nes más ac­ce­si­bles es origen de una discusión a propósito de las funciones de mod_rewrite, así como de las versiones en otros se­r­vi­do­res, en relación con el SEO. ¿Pueden evaluarse los URL amigables como factor de ranking? No hay pruebas ine­quí­vo­cas de que haya una relación directa, pero está claro que existe un efecto indirecto. Al contrario que las di­re­c­cio­nes demasiado crípticas, las URL re­es­cri­tas permiten a los usuarios deducir a dónde dirige un enlace de­te­r­mi­na­do, de tal forma que la re­es­cri­tu­ra puede ser utilizada para construir confianza y aumentar, así, la tasa de clics. Y no solo eso, puesto que las palabras clave de búsqueda se muestran en negrita en los URL en la lista de re­su­l­ta­dos, lo que añade una mo­ti­va­ción adicional a hacer clic en una dirección y no en otra.

Ir al menú principal