« La cobertura de Google StreetView crece: Australia, Japón y más ciudades de EE.UU. | Google añade funciones de la tecnología de cookies DoubleClick a AdSense »

7 Aug, 2008 a las 07:59 por Stephan Spencer

Redirecciones: Buenas, malas y condicionales

Cuando haces cambios a un sitio web, una de las consideraciones debería ser cómo utilizar las “redirecciones” para alertar los buscadores de tus cambios para evitar cualquier consecuencia negativa en tu ranking de búsqueda. Si estás cambiando páginas de sitio, de plataforma CMS o solo quieres evitar el contenido duplicado y disolución de PageRank, querrás emplear redirecciones para no malgastar el valor de los enlaces (PageRank) que tu sitio ha adquirido. Hay varias formas de redirigir, y es importante que lo hagas bien si quieres aprovechar los beneficios SEO sin el riesgo de violar las reglas de los buscadores (como en el caso de “redirecciones condicionales”).

Programadores y administradores de sistemas que no saben de SEO normalmente prefieren una “redirección provisional,” también conocida como una “redirección 302.” Desgraciadamente estas redirecciones no trasladan su valor de enlaces desde la URL redirigida a la URL de destino. No es que los programadores son neglegentes a próposito. Simplemente es un caso de “no saber lo que no saben.” Solo hay que explicarles con cortesía que lo que tienen que hacer realmente es utilizar una “redirección permanente,” o una “redirección 301.” Si preguntan por qué diles “porque el consultor de SEO lo dice.”

¿Qué serían algunos de los casos prácticos para una redirección 301? Mencioné algunos en el primer párrafo, pero examinemos algunos casos en detalles… Generalmente, si vas a cambiar URLs, querrás emplear redirecciones 301, por ejemplo si vas a cambiar de dominio (marcaantigua.com a nuevamarca.com). O si migras a un nuevo sistema de gestión de contenido (CMS), haciendo que todos las URLs de tus páginas cambian. Querrás hacer esto aunque estás “jubilando” ciertas páginas a una URL archivo (por ejemplo, la guia de regalos para navidad una vez que han acabado las navidades– aunque yo también defendería que deberías mandar esa URL sin fecha de caducidad para que acumule más valor de enlace para las ediciones futuras y NO hacer ninguna redirección).

Habrá situaciones cuando querrás mitigar los efectos de 301s cuando múltiples URLs responden a los mismo contenidos, así creando múltiples copias de la misma página en el índice del buscador. El contenido duplicado es malo en si, pero más importante es el asunto de “dilución de PageRank,” cuando los votos (enlaces) se diluyen entre varias versiones en lugar de acumular en una sola, única, “canónica” URL. Esto puede hacer cuando los códigos de seguimiento se añaden a la URL (por ejemplo, “?source=SMXad”). Un ejemplo actual de copias duplicadas de páginas con un código de seguimiento agregado a la URL que se indexa en Google se encuentra aquí– la ironía es que es un sitio de Google (sí, nos pasa a todos ¡incluso a Google!). O cuando no se ordena de forma sistemáticamente a los parametros esenciales (por ejemplo “?subsection=5&section=2″ versus “?section=2&subsection=5″). O cuando se utilizan parámetros como banderas pero la preferencia no cambia el contenido de forma sustancial (por ejemplo “?photos=ON” versus “?photos=OFF”). O cuando múltiples dominios o subdominios responden a una petición con el mismo contenido pero sin redirección (por ejemplo, “jcpenney.com/jcp/default.aspx” y “www1.jcpenney.com/jcp/default.asp” y “jcp.com/jcp/default.asp” y “jcpenny.com/jcp/default.asp” en contraste con “www.jcpenney.com/jcp/default.asp“). En todos los casos, las redirecciones 301 que apuntan a una URL canónica podrían salver el día.

Normalmente se puede escribir una única “regla” de redirección para un número amplio de URLs. Eso se llama “coincidencia de patrones” y te permite utilizar comodines (como el asterisco) y guarda una parte de la URL solicitada en la memoria para luego utilizarla en la redirección. Esto es posible si estás utilizando tanto un servidor web Apache o Microsoft IIS. Considera algunos de los ejemplos de arriba, y como manejar los con el módulo Apache de mod_rewrite (viene con Apache):

# Cambiar el nombre de dominio
RewriteCond %{HTTP_HOST} tiredoldbrand\.com$ [NC]
RewriteRule ^(.*)$ http://www.newbrand.com/$1 [R=301,QSA,L]

# Quitar parámetro de seguimiento (pero la URL trackeada sigue registrando en tu programa de analítica). Supone que no hay otros parámetros.
RewriteCond %{QUERY_STRING} ^source=
RewriteRule ^(.*)$ $1 [R=301,L]

# Cambiar orden de parámetros
RewriteCond %{QUERY_STRING} ^subsection=([0-9]+)&section=([0-9]+)$
RewriteRule ^(.*)$ $1?section=%2&subsection=%1 [R=301,L]

# Redirigir el subdominio sin www a www
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,QSA,L]

Los ejemplos de cambian un poco si estás con Microsoft IIS Server. Por ejemplo, si utilizas en plugin ISAPI_Rewrite para IIS Server, utiliza “RP” en lugar de “R=301.”

A veces, no es posible encontrar coincidencias de patrón y hace falta una tabla de búsqueda. Esto se hace fácilmente se logra con crear un archivo de texto y hacer referencia a ello con la directiva “RewriteMap”. Puedes hacer referencia a un guión que hace una búsqueda-y-reemplazar avanzado, en lugar de un archivo de texto, como esto:

# búsqueda-y-reemplazar la parte de consulta de la URL, con mi propio script de Perl
RewriteMap scriptmap prg:/usr/local/bin/searchandreplacescript
RewriteCond %{QUERY_STRING} ^(.+)$
RewriteRule ^(.+)$ $1?${scriptmap:%1} [R=301,L]

¿Te interesan estas cosas de empollón y quieres saber más sobre cómo encontrar patrones compatibles y reescribir reglas? Entonces igual querrás ver este PowerPoint de mi presentación sobre “el desenredo de URLs” de SMW West.

Hay otro tipo de redirección que habría que mencionar– “la redirección condicional.” Y viene con una advertencia: te puede buscar problemas con Google. Matt Cutts, director del equipo de spam en Google, nos advertió en su presentación durante SMX Advanced que la gente que utiliza las redirecciones condicionales corre el riesgo de una penalización o prohibición en Google. Para los que no conocen el término, se refiere a mostrar un 301 de forma selectiva a las arañas de los buscadores, como Googleblot. Evidentemente, cuando empiezas a mostrar contenidos distintos a los humanos que a las arañas (sí, las redirecciones cuentan), entras en territorio peligroso con los buscadores. Puedes tener las intenciones más puras y de “sombrero blanco”, pero el riesgo está allí. Imagina el ejemplo de arriba de dos URLs con contenidos muy parecidos, una tiene “photos=OFF” y la otra “photos=ON”– y ambas reciben enlaces. Podrías sostener que para eliminar la filtración de contenido duplicado y la dilución de PageRank, las dos versiones se deberían fundir en una, pero solo para Googlebot. Después de todo, si rediriges TODAS las peticiones, los usuarios que no tienen banda-ancha potente no podrían elegir cargar los iconos thumbnail de productos. Pero eso es una elección falsa. No necesitas una redirección en primer lugar, ni hablar de una condicional. Puedes añadir rel=nofollow a todos los enlaces que apuntas a las URLs de photos=OFF, así no se “gasta” el valor de enlaces en esa versión. Entonces hace que photos=ON sea implícito para que las fotos cargan cuando no se especifica el parámetro, y quita photos=ON de las URLs de los enlaces internos.

O piensa en la necesidad de guardar un parámetro de tracking en la URL durante toda la sesión del usuario. Con utilizar una redirección condicional, se puede redirigir las arañas que solicitan la URL de tracking a la URL canónica (o sea, la URL sin parámetro)– así manteniendo la integridad de tu sistema de seguimiento para los visitantes pero sin que sobren copias para los buscadores y arañas. Pero de nuevo, insisto en que puedes encontrar otra forma de arreglar esto sin utilizar las redirecciones condicionales. Por ejemplo, podría guardar el parámetro de seguimiento en un cookie a la vez que hace una redirección no-condicional a la URL canónica, cuando llega la petición para una URL trackeada.

Desde luego las redirecciones condicionales pueden resolver problemas complicados para empresas legítimas. De hecho, uno de los vendedores minoristas más grandes utiliza estas redirecciones condicionales, lo descubrí el día antes de SMX. Está redirigiendo condicionalmente las peticiones de bots que quieren URLs afiliadas a las URLs canónicas de producto, para captar el valor de los enlaces de sus afiliados. Parece una estrategia inteligente. Pero es muy arriesgado.

En lugar de eso, el vendedor podría redirigir TODOS los visitantes–humanos y arañas– a la URL canónica sin el ID de afiliado. Esto no gustará a algunos afiliados porque verán que el vendedor ahora manda PageRank al comerciante. ¿Sabes qué? El afiliado puede elegir no pasar PageRank; simplemente tiene que hacer un “no follow” con los enlaces. Así resulta que gestionar los afiliados con 301s incondicionales y recordarles que pueden hacer un nofollow con los enlaces, es simplemente cuestión de relaciones públicas.

Otro escenario que vi por primera vez hace poco es de un sitio de medios que redirige dos tipos de URLs. El primer tipo tiene parámetros de tracking para diferenciar clics en distintos enlaces que llevan al mismo contenido. La utilización de redirecciones condicionales les permite plegar duplicados y juntar PageRank. ¿Sabes qué? Si la redirección era sin condición, se podría seguir diferenciando los clics porque las URLs trackeadas seguiría registrando en los logs.

Lo mismo sería verdad si la intención del parámetro de seguimiento era para diferenciar programas de marketing / fuentes de tráfico. Cuando entra una solicitud para una URL que contiene “?source=blog,” por ejemplo, no es necesario mandar a los visitantes humanos a otro destino. Incluso si se llevara la fuente de tráfico en toda la sesión de usuario y luego si se incluyera un campo escondido en el formulario de contacto del sitio, se podría conseguir con cookies y guardar la información de fuente en una variable de la sesión. No hace falta redirección condicional.

El otro tipo de URL que se redirigía de forma condicional en esta compañía iba a sitios de socios con la misma marca. Lo has averiguado, había bastante contenido duplicado. Aquí no es tan sencillo como cambiar por una redirección no-condicional, porque se calcula la porción de ganancias publicitarias de los socios con mantener el visitante en un subdominio a parte. Una redirección no-condicional que dirige a la URLS canónica en el subdominio principal, cada sesión pasaría de múltiples páginas vistas a una sola. Los beneficios para los socios bajaría de forma importante; y los socios no estarían muy contentos. Se podría utilizar cookies para seguir la sesión entera- un cambio complicado de implementar- pero aunque lo hicieran, habría gente con Norton Internet Security o otros programas de seguridad que quitan la línea de referencia de las solicitudes de página web, así ocultando la potencial de ganacias de clics que se debe a un socio o afiliado. Un apuro. Para este problema, no he encontrado una solución.

Otro escenario donde se podría defender la redirección condicional es cuando se reescribe las URLs del sitio para ser más amables con las arañas de los buscadores. Esto puede ser una iniciativa enorme que puede tardar meses–incluso años.. para implementar en un sitio web complejo. Un vendedor de artículos de deporte al aire libre tardó dos años e invirtió más de 1000 horas de trabajo human redactado cambios para  las URLs y todavía no ha terminado. No es siempre viable reescribir todas las URLs o reemplazar cada incidencia de una URL que no sea amable con las arañas. Si el sitio es grande y el sistema CMS no es flexible, es más complicado aún. En una situación así, las redirecciones condicionales pueden ayudar a quitar duplicados y dirigir PageRank del canal a la versión más amable con la araña de cada URL, hasta que se reemplazan todas las URLs antipáticas en todo el sitio. Otra manera sería de eliminar duplicados con un robots.txt disallow (no permitir) o un meta robots noindex (no indexar) de todas las URLs no amables con arañas, pero esto no sería viable si todavía se están reescribiendo las URLs, tampoco permitiría que se traslade PageRank a la versión revisada de la URL.

Hay una solución que os dejo aquí que elimina la necesidad de redirecciones totalmente– incluso las condicionales. Es útil especialmente para seguimiento, y requiere añadir información de tracking a las URLs de tal manera que los buscadores las colapsan de forma automática. No, no requiere JavaScript. Curiosamente, nunca oigo nada de este método. El método utiliza el carácter #, que normalmente se utiliza para dirigir los visitantes a una parte áncora de la página web. Simplmente, añade un # a tu URL y a continuación el código de tracking o identificación. Por ejemplo: www.example.com/widgets.php#partner42. Los buscadores no harán caso al # y todo lo que viene después; así se agrupa PageRank y se evitan duplicados.

Espero que esto te ha hecho pensar de forma crítica en las redirecciones– las temporales, las permanentes y las condicionales– y lo que implican en el SEO. Elegir las permanentes (301) sobre las provisionales (302) si quieres trasladar el valor de los enlaces. Se debería evitar las redirecciones condicionaels, sobre todo si no puedes permitirte penalización en los buscadores. Si examinas tu necesidad de redirecciones condicionales, creo que encontrarás que realmente no te hacen falta.

Stephan Spencer es fundador y presidente de la empresa Netconcepts de marketing de búsqueda natural e inventor de la tecnología SEO GravityStream. Actualmente está escribiendo un libro de O´Reilly “El arte de SEO” con Rand Fishkin y Jessie Stricchiola. La columna 100% Orgánico se publica semanalmente en Search Engine Land en Español.

por Stephan Spencer Enlace permanente Historias relacionadas: 100% Orgánico, Columnas