Son varios los motivos que nos pueden llevar a necesitar reescribir las URLs de nuestras páginas o aplicaciones web. Principalmente podríamos destacar los siguientes:
-
Ha cambiado el dominio de la web y queremos llevar a los visitantes del viejo al nuevo dominio. Esto es habitual en compañías que cambian el nombre de su marca comercial.
-
La URL es demasiado complicada y queremos cambiarla por una más sencilla de leer, memorizar o transmitir por los usuarios.
-
Queremos potenciar el SEO de la página añadiendo palabras clave del contenido a la URL.
-
Tenemos distintas versiones de la página dependientes del dispositivo o navegador del usuario, y queremos redirigirlo al más adecuado.
-
La dirección originalmente incluye caracteres poco amigables como el punto o la coma, y al convertirlo a formato URL (%2C, %2F y similares) corremos el riesgo de que el enlace se parta si se copia a mano.
En cualquiera de los casos, del mismo modo que las empresas invierten bastante tiempo y dinero en conseguir un buen dominio para su web, sería interesante dedicar también algo de ese esfuerzo al resto de la URL, ya que eso dará una imagen de profesionalidad y ayudará a los visitantes a recordarla.
Pero existen muchas maneras de llevar a nuestros usuarios a la nueva URL, cada una con sus ventajas e inconvenientes. ¿Es incómodo para el usuario? ¿Traspasará Google la popularidad (pagerank) de la página original a la nueva, o me penalizará por ello? ¿Es reversible?
La peor solución, requerir intervención del usuario
Imaginad que tenéis un documento con recetas de cocina en el escritorio de vuestro ordenador compartido, al que en un alarde de originalidad llamasteis “Recetas.odt”. Cada vez que alguien de tu familia quiere hacer un rico plato abre el documento y accede a las recetas. Pero un buen día decides que ese nombre es demasiado genérico, y que quieres renombrar tu documento como “Recetas de cocina saludables para toda la familia.odt”, y que en lugar de en el escritorio lo vas a guardar en “C:/recetas/”. Y, para que tu familia se dé cuenta, dejas en el escritorio un nuevo documento llamado “Recetas.odt”, como el antiguo, cuyo único contenido es:
He guardado el documento en un sitio mejor. Ahora está en C:/recetas/Recetas de cocina saludables para toda la familia.odt
Lo habrás hecho con toda la buena intención, pero has obligado a tus familiares a abrir dos documentos distintos en lugar de uno. Es más, puede que hayan leído el primero, no lo hayan entendido y hayan perdido el interés por abrir el segundo. ¿Parece una mala opción, verdad? Pues, por sorprendente que parezca, eso es lo que hacen muchos en internet.
Entidades tan importantes como la Agencia Española de Meteorología usan este horrible método de dejar la url antigua con un texto avisando de la nueva, tal y como podéis ver en esta “predicción” del tiempo.
Lo que se encuentra el usuario
El ejemplo del documento con las recetas nos da una idea de lo mala que es esta solución desde el punto de vista de la usabilidad, pero es que desde la óptica del SEO es un desastre:
-
No se transmite nada del pagerank de la página original a la nueva.
-
Tienes el doble de páginas para el mismo contenido (en teoría), por lo que los buscadores considerarán cada una de ellas menos interesante.
-
Al ver que tu primer resultado no es bueno, mucha gente dejará de enlazarte, perdiendo parte del pagerank que ya tenías ganado.
Los meta tags
En los albores de Internet, antes de que existiese AJAX y el concepto de aplicación web apenas existía en las mentes de algunos pioneros, la web era vista como una colección de páginas estáticas, sin apenas interacción. Sin embargo, era probable que alguna de esas páginas que sólo contenían texto y enlaces necesitase actualizarse (por ejemplo, la portada de un periódico conforme iban saliendo nuevas noticias).
La solución se incorporó al propio lenguaje HTML en forma de etiqueta de metadatos, informando al navegador que cada cierto tiempo debía recargar la página para ver si había nueva información disponible. Por ejemplo, para recargar una página cada hora, incluiríamos en la cabecera esta etiqueta:
<meta http-equiv="Refresh" content="3600">Pero esta técnica degeneró y se permitió que, aparte de los segundos de espera antes de recargar, se pudiera incluir una url distinta, del modo que la recarga se convertía en redirección. Estableciendo un tiempo de 0 segundos, la redirección era teóricamente instantánea.
<meta http-equiv="Refresh" content="0;url=http://m.genbetadev.com">Entre las pegas de este método está el errático funcionamiento del botón de retroceder dependiendo del navegador (algunos consideran que estás en la misma página e impiden volver atrás, mientras otros te llevan a la original provocando una nueva redirección), o el hecho de tener que descargar el primer documento html completo aunque no vayas a visualizarlo, lo que puede provocar que la redirección no sea tan instantánea como desearíamos. Por estos y otros motivos, el World Wide Web Consortium desaconseja el uso de esta etiqueta desde el año 2000.
Y de nuevo, a pesar de lo desaconsejado del método, nos encontramos con entidades de bastante peso como la Real Academia Española que usan esta técnica, tal y como podemos comprobar usando la búsqueda de una palabra mediante su buscador integrado en Firefox. Y encima la redirección tarda 10 segundos, en los que un usuario normal puede que ya haya cerrado la pestaña al encontrarse con esto:
Además, desde el punto de vista de la optimización para buscadores, tiene los mismos defectos que el anterior caso: todo el pagerank de la url original se desperdicia y el buscador considerará que existen dos páginas que rivalizan en contenido.
Redirección por JavaScript, un trabajo típico de spammers
¿Que el W3C desaconseja usar el <meta>? Pues se la colamos por JavaScript.
Algo así debieron pensar los que empezaron a usar el famoso lenguaje de script para conseguir que el usuario acabase visitando una página distinta de aquella a la que había accedido. El código es muy similar al de las etiquetas <meta>, con la sutil diferencia de expresar el tiempo en milisegundos en lugar de en segundos.
<script type="text/javascript">
function redirection(){
window.location ="http://m.genbetadev.com";
} setTimeout ("redirection()", 0);
</script>
Con prácticamente los mismos inconvenientes que el hecho de utilizar los metas y la pega particular de no funcionar para aquellos que hayan desactivado JavaScript, esta táctica también ha sido vista con malos ojos por parte de los buscadores, ya que es de uso habitual por parte de los spammers.
Y es que, según en qué punto de la carga de la página se ordene la redirección, se puede llegar a mostrar por completo tanto la página original como la de destino, lo que supone el doble de soportes para colarle anuncios al usuario. Y como los rastreadores de los buscadores no ejecutarán el JavaScript, la página de inicio puede estar llena de keywords para aparecer en las búsquedas, mientras la de destino no tiene nada que ver con ellas.
Y lo que es peor, al hacer uso del window.location, se puede jugar con los padres, hijos, ventanas con nombre, etc. haciendo que la navegación se convierta en algo engorroso para el usuario, por lo que es posible encontrarte con que han desactivado en su navegador este tipo de redirecciones.
Redirección en el servidor y los códigos 300
Así que, por fin, descartamos todas las soluciones ingenuas y pasamos al método correcto (y más potente) de realizar estas redirecciones. Todas las soluciones anteriores estaban codificadas en el propio HTML de la respuesta, obligando al navegador a descargar un documento que no es el que le interesa, para a continuación realizar una petición extra para acceder a la nueva dirección.
Lo correcto es que sea el servidor quien avise de esa redirección, devolviendo al navegador un código de estado HTTP mucho más liviano que una página completa, para que el navegador (o su usuario, o el robot-araña de un buscador) decida por su cuenta si la próxima vez quiere acceder a través de la URL vieja o solicitar directamente la de destino.
Para ello, en lugar del típico código de estado 200 (encontrado, OK), o el odiado 404 (documento no encontrado), devolveremos un código de la familia de los 300. En el próximo artículo veremos los dos métodos principales para hacerlo (programáticamente en el código de nuestra aplicación o vía configuración del servidor), así como las implicaciones semánticas que tiene dar al navegador una u otra respuesta.
Vía | Smashing Magazine – Introduction to URL Rewriting
En GenbetaDev | Guía visual de los códigos de estado HTTP y su influencia SEO
