Truco: Resolver problemas comunes de SEO usando la extensión URL Rewrite

Search Engine Optimization (SEO) es importante para cualquier web que quiera publicitarse. Un porcentajo muy alto que llega a los sitios viene directamente de motores de búsqueda, y mejorar la relevancia de tu sitio en esos motores hará que más usuarios visiten tu sitio desde los buscadores. Esto puede aumentar directa o indirectamente los beneficios que recibas por tu sitio web.
En el post de hoy veremos cómo podemos usar el componente gratuito URL Rewrite Extension que corrije un montón de problemas SEO que tu sitio puede tener. Se tarda menos de 15 minutos (no hace falta tocar el código) para aplicar 4 simples reglas de URL Rewrite a tu sitio, y sólo por hacerlo hará que los motores de búsqueda dirigan más visitantes y tráfico a tu sitio. Las técnicas que vamos a ver funcionan tanto para ASP.NET Web Forms como ASP.NET MVC. También funciona con todas las versiones de ASP
[Además del blog podéis seguir a Scott en twitter: twitter.com/scottgu]

Midiendo el SEO de nuestro sitio con Microsoft SEO Toolkit
Hace unos meses blogueé sobre el nuevo SEO Toolkit que hemos publicado. Es una herramienta muy útil que nos permite comprobar nuestro sitio para ver si se posiciona bien en los motores de búsqueda, y nos informa de los problemas SEO que puede tener. Recomiendo que os descarguéis la herramienta y la uséis contra cualquier sitio público en el que trabajéis. Hace realmente fácil detectar este tipo de problemas, y os dice cómo podéis solucionarlo.
Aquí tenéis un ejemplo con un informe que he hecho contra uno de mis sitios (www.scottgu.com) ántes de aplicar las reglas de URL Rewrite que veremos más tarde en el blog:

Relevancia del sitio y URL Splitting
Dos de las cosas más importantes que los motores de búsqueda evalúan cuando asignan la relevancia de un sitio son:
1- Cuantos otros sitios enlazan a tu contenido. Los motores de búsqueda asumen que si eres muy enlazado, tu contenido es muy útil de manera que la relevancia de tu sitio aumenta.
2- La unicidad del contenido que hay en tu sitio. si los motores de búsqueda encuentran que el contenido está duplicado en varios sitios en internet (o en múltiples URLs de tu sitio) entonces tu relevancia desciende.
Una de las cosas con las que querreis ser muy cuidadosos para evitarlos cuando creéis sitios publicos es no permitir diferentes urls que accedan al mismo contenido dentro de vuestro sitio. Permitirlo va a hacer que se den las dos situaciones anteriores.
En concreto, permitir que sitios externos enlacen al mismo contenido con diferentes URLs hará que vuestro page-rank disminuya. No permitir que sitios externos te enlacen de diferente forma suena fácil en la teoría - pero os preguntaréis qué significa exáctamente en la práctica para evitarlo.
4 problemas SEO comunes que podéis tener
Aquí tenéis 4 escenarios muy comunes que pueden hacer que vuestro sitio exponga inadvertidamente varias URLs al mismo contenido. Cuando esto ocurre los sitios externos terminarán enlazándote de muchas formas diferentes - y como resultado tendréis un page rank bajo.
Problema 1: Documento por defecto
IIS (y otros servidores web) soportan el concepto de "documento por defecto". Esto nos permite tener que especificar explicitamente la página que el servidor va a mostrar en cualquier raiz de un sitio, o un directorio. Esto es útil - pero significa que por defecto se accede a este contenido desde dos direcciones diferentes (lo que es malo). Por ejemplo:

http://scottgu.com

http://scottgu.com/default.aspx

Problema 2: Diferentes Casings en las URLs
Los desarrolladores web no suelen darse cuenta de que las URLs son sensibles a mayúsculas y minúsculas para los motores de búsqueda. Esto significa que los motores de búsqueda tratan las siguientes dos urls como si fuesen urls diferentes:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Problema 3: Barras al final
Imaginemos las siguientes dos URLs - pueden parecer la misma al principio, pero son un poco diferentes. Las barras del final crean una situación que hace que los motores de búsqueda trate esas dos URLs como diferentes:

http://scottgu.com

http://soctgu.com/

Problema 4: Nombres de host canónicos
Algunas veces los sitios soportan escenarios en el que las urls con el prefijo "www" son el mismo que el hostname. Esto hace que los motores de búsqueda traten esas urls como diferentes:

http://scottgu.com/albums.aspx/

http://www.scottgu.com/albums.aspx/

Como corregir estos problemas en 10 minutos (o menos) usando IIS Rewrite
Si no hemos sido cuidadosos codificando nuestros sitios, estaremos teniendo alguno de los problemas anteriores. Corregir estas siguaciones harán que nuestros sitios tengan un mejor pagerank.
Las buenas noticias es que corregir estos cuatro problemas es realmente fácil con URL Rewrite Extension. Es una herramienta totalmente gratuita para IIS 7-x (para Windows Server 2008, Windows Server 2008 R2, Windows 7 y Windows Vista. Lo bueno sobre esta extensión es que te permite corregir los problemas anteriores sin tener que cambiar ninguna línea de código de tu aplciación.
Podéis instalar el URL Rewrite Extension en menos de 3 minutos usando el Microsoft Web Platform Installer (una herramienta gratuita que viene con configuraciones por defecto para servidores web y máquinas de desarrollo). Tan sólo tenemos que hacer clic en "Install Now" en el URL Rewrite Spotlight para instalarlo en Windows Server 2008, 7 y Vista:

Una vez instalado veremos un nuevo icono de "Url Rewrite" disponible en la consola de administración del IIS 7:

Si hacemos doble clic en el icono se nos mostrará el panel de administración de URL Rewrite - que mostrará la lista de reglas configuradas para un sitio o aplicación en particular:

Fijáos que nuestra lista reglas de reescritura está vacía (que es el estado por defecto cuando instalamos la extensión). Podemos darle a "Add Rule .." de arriba a la derecha para añadir nuevas reglas para nuestro sitio.
Escenario 1: Resolver el problema del documento por defecto
Uno de los problemas que hemos visto en este post el del documento pro defecto que hace que IIS exponga dos urls para el mismo contenido. Por ejemplo:
- http://scottgu.com/
- http://scottgu.com/default.aspx
Para corregirlo añadiremos una regla que rediriga a cualquiera que navegue a la segunda dirección sea redirigido a la primera. Estableceremos una "redirección permanente" HTTP - que indicará a los motores de búsqueda que deben continuar con la redirección y usen la nueva URL a la que se ha redirigido como el identificador del contenido.
Ahora veamos como podemos crear esa regla. Comenzamos haciendo clic en el link "Add Rule". Y veremos este diálogo:

Seleccionamos la plantilla "Blank Rule" en la sección de "Inbound Rules" para crear una regla personalizada. Esto nos mostrará la siguiente ventana:

No os preocupéis - es realmente sencillo crear la regla. Los siguientes 4 pasos muestran cómo se hace:
Paso 1: Nombrar la regla.
Lo primero que haremos será darle un nombre a esta regla. Nombradla de manera descriptiva para hacer más fácil de entender y encontrar más tarde. Vamos a nombrarla como "Default Documento URL Rewrite":

Paso 2: Crear la expresión regular que encaje con la regla
El segundo paso es especificar una expresión regular que haga que esta regla se ejecute cuando llegue una URL. No os preocupéis si no sois buenos con las expresiones regulares - Yo también las odio. El truco es conocer a alguien que sea bueno con ellas o copiar/pegar de un sitio.
Aquí tenéis la regla que yo voy a introducir:
(.*?)/?Default.aspx$
Este patron coincidirá con cualquier url que termine con Default.aspx. El "(.*?)" coincide con cualquier carácter zero o más veces. La parte "/?" busca cualquier carácter "/?" zero o más veces. El símbolo "$" al final se asegura de que el patrón sólo coincidirá con strings que terminen en Default.aspx.
Combinando estos tres elementos permite a la regla trabajar no sólo con la raiz de nuestro sitio web (ej: http://scottgu.com/default.aspx) sino para cualqueir aplicación o subdirectorio del sitio (ej: http://scottgu.com/photos/default.aspx". Como hemos marcado el check box "ignore case" funcionará tanto para "Default.aspx" como para "default.aspx".

Una característica de este editor es que tenemos el botón "Test Pattern" que nos muestra un diálogo para testear unas cuantas urls con la regla que estamos configurando:

Aquí he añadido la url "products/default.aspx" y le hemos dado al botón "Test". Esto nos indicará inmediatamente si la regla se ejecutará para esa url.
Paso 3: Configurar una redirección permanente
Ahora estableceremos una acción para que ocurra cuando la url se corresponda con la URL:

En el diálogo anterior he cambiado el desplegable "Action Type" para que sea una acción "Redirect". El "Redirect Type" será un HTTP 301 de redirección permanente - lo que significa que los motores de búsqueda continuarán.
También he establecido la propiedad "Redirect URL" a:
{R:1}/
Esto indica que queremos redirigir la petición del cliente a una url nueva que no contiene el "Default.aspx". Por ejemplo, las peticiones para http://scottgu.com/default.aspx ser redirigirán a http://scottgu.com, y las peticiones http://scottgu.com/photos/default.aspx se redirigirán a http://scottgu.com/photos/
La contrucción "{R:N}", donde N>=0, es llamada como una expresión regular que hace referencia a una anterior y N es el índice de esa referencia. En el caso de nuestro patrón "(.*?)?Default.aspx$", si la url de entrada es "products/default.aspx", entonces {R:0} contendrá "products/Default.aspx" y {R:1} contendrá "products". Vamos a usar este valor {R:1}/ para redirigir a los usuarios.
Paso 4: Aplicar y salvar la regla
El paso final es hacer clic en el botón "Apply" de arriba a la derecha de la herramienta de administración del IIS - que hará que la herramienta persista la regla en el web.config de nuestra aplciación (bajo la sección de configuración ):

Como IIS 7.x y ASP.NET comparten los mismos archivos web.config, podemos copiar y pegar el código anterior en neustros web.config con Visual Studio y no tendremos que ejecutar la herramienta de configuración. Esto hace que añadir /desplegar reglas de URL Rewrite en nuestras aplicaciones ASP.NET sea realmente fácil.
Paso 5: Probar la regla
Ahora que hemos creado la regla, vamos a probarla. Probad las dos urls a mi sitio:

http://scottgu.com/

http://scottgu.com/default.aspx

Fijáos que la segunda url os redirige a la primera. Como es una redirección permanente, los motores de búsqueda continuarán a la URL siguiente y actualizarán el pagerank de http://scottgu.com incluyendo los enlaces a http://scottgu.com/default.aspx.
Escenario 2: diferentes casings en las urls
Otro problema que hemos visto es el de las diferentes mayusculas y minúsculas. De manera que los motores de búsqueda tratan de forma diferente estas dos direcciones:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Podemos resolver este problema escribiendo una regla que rediriga automáticamente a cualqueira que navegue a la primera url a la segunda (todo en minuscula). Como ántes, estableceremos una redirección permanente.
Para crear esta regla le daremos al enlace "Add Rule" del panel de administración de URL Rewrite. Y nos mostrará el siguiente diálogo otra vez:


Al contrario que en el escenario anterior (seleccionamos "Blank Rule"), en este escenario hemos seleccionado la plantilla "Enforce lowercase URLs". Cuando le damos al botón "ok" veremos un diálogo que nos pregunta si queiremos crear una regla que asegure el uso de minúsculas en las URLS:

Cuando le damos al botón "Yes" tendremos una regla pre-escrita que realiza la redirección permanente si una URL viene con caracteres en mayúsculas - y manda a los usuarios automáticamente a la versión con minúsculas:

Podemos hacer clic en el botón "Apply" para que esta regla se aplique en todas las Urls de nuestro sitio.
Como el sitio www.scottgu.com usa ASP.NET Web Forms, vamos a hacer un pequeño cambio a la regla que se ha generado - que es añadir una condición que asegura que las URLs creadas en ASP.NET para el manejador "WebResourse.axd" son excluidas de esta regla. Las URLs del manejador WebResource.axd sól ovienen desde controles de servidor emitidos por mis páginas - y nunca serán enlazados desde sitios externos. Mientras que mi sitio sigue funcionando bien si redirigimos estas urls automáticamente - no es necesrio añadir redirecciones extra a muchas de mis págnias.
Las buenas noticias son que añadiendo una condición hace que mi regla no ocurra en algunas urls. Simplemente expandimos la sección "Conditions" del formulario anterior:

Le damos al botón "add" para añadir una nueva condición. Esto nos mostrará el diálogo "Add Condition":

Hemos añadido una condición {URL} como condicion de entrada - y hemos dicho que la regla sólo se tiene que ejecutar si la url NO coincide con el patrón que contenga el string "WebResource.axd". Esto asegurará que las urls de WebResource.axd de mi sitio no redirigiran peticiones a direcciones en minúscilas.
Nota: Si tenéis recursos estáticos (como referencias a .jpg, .css, y archivos .js) en vuestro sitio que usan caracteres con mayúsculas seguramente querreis añadir condiciones adicionales a los filtros para que las peticiones no sean redirigidos (sól oañadir patrones como .jpg, .gif, .js, etc). Vuestro sitio seguirá funcionando bien si no eliminais estas redirecciones (el sitio no se rompera) pero reduciréis redirecciones innecesarias.
Cuando le damos al botón "ok" el archivo web.config quedará así:

Probando la regla
Ahora que hemos guardado la regla, vamos aprovarla. Si accedemos a estas dos urls:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Veremos que si accedemos a la primera, seremos redirigidos a la segunda url.
Escenario 3: Barras al final
Otro problema común es el de las barras al final de las direcciones que ya hemos visto anteriormente. Estas dos urls son tratadas de forma diferente por los motores de búsqueda:

http://scottgu.com

http://scottgu.com/

Podemos resolver este problema creando una regla que rediriga a cualqueir que navegue a la primera url (sin una barra al final) a la segunda que sí la tiene. Como ántes crearemos una regla de redirección permanente.
Para ello, crearemos una regla, le damos al enlace de Add Rule:

Seleccionamos la plantilla "Append or remove the trailing slash symbol".
Cuando lo seleccionamos y le damos a "ok" veremos el siguiente diálogo que nos pregunta si queremos crear una regla que rediriga a los usuarios a una url con una barra si no existe:

Cuando le damos a "ok" tendremos la regla que queremos para redirigir las urls que no vienen con una barra al final.
Como en el escenario anterior de mayúsculas y minúsculas, crearemos unas condiciones para que no se aplique esta regla para los WebResources.axd.
Cuando salvemos la regla obtendremos el siguiente web.config:

Probando la regla
Ahora que hemos salvado la regla, vamos aprobarla en neustro sitio. Probamos con las dos direccioens:

http://scottgu.com

http://scottgu.com/

Ahora si escribimos la primera URL nos redirigirá a la segunda.
Escenario 4: Nombres de host canónicos
El último problema SEO que hemos visto es el del prefijo www del hostname:

http://www.scottgu.com/albums.aspx

http://scottgu.com/albums.aspx

Podemos corregir esto añadiendo una relga que rediriga a cualquiera que navegue a la primera URl (con el prefijo www) a la segunda dirección. Como ántes crearemos una regla que haga una redirección permanente.
Para crear esta regla le damos al enlace "Add Rule". y veremos de nuevo este diálogo:

ya tenemos una plantilla para este problema "Cannonical domain name".
Cuando la seleccionamos y le damos al botón "ok" nos muestra un diálogo que nos pregunta si queremos crear una regla de redirección que rediriga a los usuarios a una dirección primaria del host:

Arriba estamos indicando la url primaria que queremos exponer en la web: scottgu.com. Cuando le damos a "ok" tendremos una regla que redirige permamentemente las urls a este dominio.
El web config se queda de esta forma:

Probando la regla
Vamos a probar la regla ahora. Vamos a acceder a la siguientes urls:

http://www.scottgu.com/albums.aspx

http://scottgu.com/albums.aspx

Fijáos que la primera URL (la que tiene el prefijo de www) es redirigida a la segunda url.
4 reglas simples para mejorar el SEO
Las cuatro reglas anterioes son muy sencillas de configurar y no deben llevar más de 15 minutos de trabajo
La belleza de usar una solución como esta es que podamos aprovecharlas sin tener que tocar el código de nuestras aplicaciones web - y sin tener que romper ningún enlace que ya existen en nuestros sitios. Los usuarios que siguen enlaces existentes serán redirigidos a las nuevas urls que queremos publicar. Y los motores de búsqueda comenzarán a darnos un pagerank mayor.
Personalizar nuestras reglas de URL Rewriting es fácil editando el web.config directamente, o con la consola de administración.

Haciendo clic en cualquiera de las relgas anteriores hará que salga el editor para personalizarlas.
Resumen
Medir y mejorar las técnicas SEO es algo que cualquier desarrollador web debe tener en cuenta. Si no lo habéis pensado, descargad y usad el SEO toolkit para analizar vuestros sitios.
Las nuevas características de rutado URL en ASP.NET MVC y ASP.NET Web Forms 4 hacen mucho más sencillo crear aplicaciones que tengan más control sobre las URLs que se publican. Herramientas como URL Rewrite Extension de las que he hablado en este post hace mucho más sencilla mejorar las URLs que se publican en nuestros sitios que ya tenemos creados - sin tener que cambiar código fuente.
El Url Rewrite Extension ofrece un montón de nuevas capacidades - más aún que sólo el SEO. Veremos más esas capacidades en futuros post.
Espero que sirva.
Scott.
Traducido por: Juan María Laó Ramos.
Artículo original.

6 pensamientos en “Truco: Resolver problemas comunes de SEO usando la extensión URL Rewrite

  1. Pingback: Serie sobre VS 2010 y .NET 4.0 « Thinking in .NET

  2. Roberto

    Excelente y muy útil articulo! Gracias a el, he descubierto este modulo para IIS fácil, útil y potente (por lo que he podido leer por ahí se puede usar para generar URL amigables, es mi próximo objetivo).

    De nuevo gracias y un saludo

    Responder
  3. Pingback: Introducción a IIS Express « Thinking in .NET

  4. Jose

    El artículo está genial y muy bien explicado. Hace poco que estoy aprendiendo programacón en PHP y ahora trato de posicionar la página que he creado. Esto sin duda me ayudará a resolver mis problemas de posicionamiento. No obstante si alguien puede echarme una mano con un análisis rápido de la misma y ver en qué la estoy cagando para posicionarme e indexarme en google, que por favor me lo diga. La web es http://www.pisoscadiz.info
    Gracias de antemano y enhorabuena por el artículo. Está muy currado.

    Responder
  5. Koldo

    Hola.

    Estoy generando con un lenguaje 4GL que no permite crear objetos con el nombre reservado Default.

    ¿Hay alguna forma usando la redirección 301 que en lugar de Default.aspx llame a Principal.aspx?

    Gracias de antemano.

    Responder
  6. Goouse

    Hola! Tenemos un problema con una pagina web, que tiene un dominio (.com) pero con contenido Español.
    Antes el mismo dominio en 2007-2008 era una pagina web chino, despues lo compramos en 2011 y ya subimos contenido en 2012. La web ha obtenido pagerank 2 en solo 4 mese. Mi pregunta es si pones en google.es la palabra ( solo el nombre de dominio sin puncto com ) no sale la pagina. Si buscas lo mismo en google.com o google int china, si que sale perfectamente!!!
    Que hay que hacer en este caso que google no se confunda mas, y que se de la cuenta que la pagina es para España aunque tiene .com ??? En la meta hemos puesto metatag lang “ES”… Que mas se puede hacer?
    Muchas Gracias! Espero vuestr@ respuesta. Un Saludo!

    Responder

Deja un comentario