programacion

Muchas veces se plantean las redirecciones de tipo 301 como una alternativa viable (algunos hasta se atrevían a asegurar que la mejor) para modificar la estructura de URL sin ver resentido el valor de PageRank. Se comentó inclusive, durante largo tiempo, que este tipo de redirección transfería el PageRank por completo. Sin embargo, parece ser que no es tan así.

Aparentemente, a pesar de la insistencia de algunos profesionales por la teoría de que el PageRank se pasaba íntegro, desde Google confesaron “oficialmente” (a través del infalible Matt Cutts) la pérdida (a veces mayor, a veces menor) de este valor que se produce “en el camino”.

Además, la entrevista donde Matt explica este concepto dio lugar a que comentara algunas otras situaciones. Por ejemplo, el tratamiento de las direcciones con contenido duplicado: ante varias páginas de esta clase, en ausencia de indicaciones claras (llámese cannonical, noindex, etc.) Google privilegiará a una de ellas, con las consecuencias que esto puede acarrear.

También comentó que, actualmente, el rastreo de un website está condicionado por dos factores básicos: los valores de PageRank de sus páginas y la capacidad del servidor para manejar conexiones en simultáneo. De acuerdo a las conclusiones que Google saque de estos parámetros, determinará una frecuencia y una “cantidad” de rastreo.

Si bien la mayor parte de las veces, el spider que ingresa a un website para navegar las páginas pertenece a un buscador, la realidad es que no faltan robots maliciosos que se dediquen a descargar indiscriminadamente contenido y ha recopilar información de modo clandestino.

Normalmente, el uso del archivo “robots.txt” es inútil, porque directamente es salteado, por lo que “.htaccess” constituye la única barrera para detenerlos. Una manera bastante común es forzar el error 403 ante su intento. El siguiente código encierra algunos de los bots malignos más conocidos:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule .* - [F]

Lista extraída de: http://www.enespanol.com.ar/2006/04/03/tutorial-de-htaccess/#7

Aunque a simple vista pueda parecer bastante sencillo de utilizar, un archivo “.htaccess” guarda grandes posibilidades. Por lo tanto, resulta lógico que de su uso puedan desprenderse algunas situaciones colaterales conflictivas. Los dejamos con algunos consejos básicos a seguir en la estructuración de este interesantísimo fichero.

El primero de ellos, común también al campo de la programación, es mantener su código ordenado. Utilizar comentarios comenzando con “#” que describan situaciones especiales u observaciones, es fundamental para entender lo escrito durante una revisión o en la medida que aumenta su complejidad.

Otro punto muy importante es el tamaño del “.htaccess”. No debe pasarse por alto el hecho de que un servidor procesa estas líneas ante cada petición, por lo que este factor condicionará notablemente la velocidad de respuesta a un usuario que se encuentra navegando el sitio web.

Finalmente, también es un deber tomar en cuenta el sistema de herencia que utiliza este archivos. Dentro de las posibilidades de configuración, es posible aplicar un “.htaccess” por directorio, caso en el que serán reemplazadas con estas reglas las que haya implementado el archivo perteneciente al directorio raíz. Si se desean crear reglas generales, debe tenerse cuidado en no “pisar” estas directivas globales con directivas locales.

En el anterior artículo, comentamos un poco la definición más básica del archivo “.htaccess” y una de sus posibilidades más conocidas, la restricción de acceso web a un directorio y/o fichero, combinada también con el permiso a IPs determinadas. Esta vez trataremos un poco sobre otro caso bastante común: la personalización del “Error 404”.

Se denomina de esa forma al error que devuelve un servidor cuando se intenta acceder a una página que ya no está en la dirección que se requiere o que directamente no existe. Es posible dejar el mensaje por defecto, pero si queremos mostrar una estructura más profesional, es buena idea crear un mensaje personalizado que mantenga el aspecto del web y permita volver atrás con un simple botón.

Para redireccionar cualquier “Error 404” a una página personalizada, basta con abrir el archivo “.htaccess” (o crearlo en caso de que no exista ya) y escribir lo siguiente:

ErrorDocument 404 /directorioEjemplo/error404.html

Obviamente, habrá que cambiar nombres de acuerdo a como le hayamos programado. Esto resulta interesante, porque además, bastará con cambiar el número “404” por cualquiera para redireccionar otros errores.

Es importante el peso de la página personalizada, porque en algunas versiones de Internet Explorer toda página de 404 menor a los 512 bytes es redireccionada hacia su buscador propio, perdiéndose la visita.

Por lo general, los websites que uno construye terminan alojados en servidores contratados a empresas de hosting, ya que usualmente es un costo excesivo el mantenimiento de un servidor propio. Es así que muchas veces la respuesta del site a los requerimientos de un visitante no están en nuestras manos.

En ocasiones puede pasar que, buscando información o actualizando la ya disponible, un buscador husmee constantemente el sitio requiriendo accesos constantes al servidor. Cada petición exige una carga de trabajo que, si se repite excesivamente por un lapso prolongado de tiempo, ralentizará notablemente la velocidad de nuestro sitio.

Si se está en esa situación, una buena manera de disminuir este efecto es el siguiente código:

User-agent: MSNBot
Crawl-delay: 30

Escribiendo esas líneas, se imparte un intermedio de 30 segundos entre peticiones, lo que hará el ritmo más “soportable”.

Cómo explicamos anteriormente, un sitemap puede ser de gran utilidad en el proceso de indexación. Para incluir una referencia al mapa de sitio, bastará con el siguiente código:

Sitemap: www.misitioweb.com/docs/sitemap.xml

Es importante destacar que las instrucciones brindadas a los buscadores en el archivo robots.txt no son más que sugerencias. Los bots de buscadores las respetarán, pero es posible que robots programados para ingresar por fuerza bruta hagan caso omiso. Para trabajar sobre esas situaciones, se utiliza el archivo “.htaccess”, sobre el cuál hablaremos en una próxima serie de artículos.

En muchas webs actuales, y por sobretodo en los blogs, es muy común encontrarse con varias URL distintas para acceder al mismo artículo o post. Por lo tanto, en un blog de cocina podrá accederse de distintas maneras a la receta de salsa boloñesa escrita el 20 de Marzo de 2010:

cocinablog.com/recetas/salsa-bolognesa (permalink básico y principal)
cocinablog.com/2010/03/ (permalink del archivo del mes de Marzo)
cocinablog.com/recetas/ (permalink de la categoría en que se incluyó el artículo)
cocinablog.com/recetas/salsa-bolognesa/page/2 (permalink de la segunda página con comentarios)

Si los buscadores se encuentran indexando tanta cantidad de vías distintas para el mismo contenido, penalizan seriamente al website. Es muy difícil que un post de un blog sea limitado a una sola vía de acceso, por lo que resulta absolutamente imprescindible restringir la entrada del spider a las “direcciones extra”.

Para acotar las direcciones que indexa un spider, la mejor opción obviamente es el uso de “robots.txt”. Sin embargo, es necesario tener suma precaución, sobretodo en el uso de los comodines. Puede ser realmente peligroso porque por ejemplo, se puede errar en el bloqueo de direcciones.

En la próxima entrega, trabajamos sobre la inclusión de un sitemap y el uso de ancho de banda del servidor.

Como veíamos en el anterior artículo, mediante el parámetro “Disallow” es posible manejar las restricciones que se imponen a cada spider o a todos ellos a la vez. En ocasiones, es posible que deseemos restringir la entrada a todo el sitio o permitirla, por lo que bastará con escribir:

Disallow: /

o bien

Disallow:

Los robots tomarán la ausencia de un valor para el parámetro como la posibilidad de navegar el website libremente. También existe la posibilidad de restringir varias carpetas o archivos puntuales, cada uno a un crawler diferente. Veamos el ejemplo de restricción al crawler de Google de tres archivos y una carpeta:

User-agent: Googlebot
Disallow: /enlaces.html
Disallow: /fotos/galeria1.html
Disallow: /fotos/galeria2.html
Disallow: /docs/

Google no podrá acceder a los archivos “enlaces.html”, “galeria1.html” y “galeria2.html”, ni a la carpeta “docs”.

A medida que avanzamos en la complejidad de los permisos, entran en juego los comodines que podremos usar. Uno de ellos lo hemos visto ya (*) y el otro ($) pasaremos a visualizarlo en el siguiente ejemplo:

User-agent: Googlebot
Disallow: /noticias/*
Disallow: /descargas/*
Disallow: /*.pdf$
Disallow: /info/*/page/*

Con los primeros dos “Disallow” estamos restringiendo la indexación de direcciones que comiencen con “noticias/” y “descargas/” (muy útil para blogs). La tercer línea elimina de la indexación los documentos PDF y la cuarta se encarga de evitar al buscador las páginas que sólo se diferencian en los comentarios (contenido duplicado).

En la siguiente entrega trabajamos sobre el contenido duplicado.

Continuando un poco con las ventajas de modificar el fichero de texto “robots.txt”, podemos señalar también la posibilidad de eliminar el contenido duplicado de la indexación. Esto no es algo muy revisado en la mayoría de los casos, pero evitar que el robot de un buscador caiga en sectores que albergan el mismo contenido puede ser realmente perjudicial para nuestro ranking.

También es buena idea complementar la manipulación de “robots.txt” con el diseño de sitemap (mapa del sitio). Estos contienen un listado de las páginas del sitio o documentos a los cuáles el crawler puede acceder para recopilar información. Generalmente se presenta siguiendo un orden jerárquico, algo útil tanto para la indexación como para la navegación del usuario final.

Básicamente, para comenzar a trabajar con el fichero “robots.txt” es necesario crearlo, en lo posible dentro de la carpeta raíz del website (donde se encuentra el archivo “index.html” generalmente). A partir de aquí, tenemos una serie de parámetros con los cuales modificar el comportamiento de un spider.

Hay dos parámetros básicos que no se pueden evitar. El primero es “User-agent”, con el cual se especifica para que bot estamos planteando los permisos. El otro es “Disallow”, con el cual denegamos el acceso a una carpeta del website. Si queremos prohibir la entrada a una carpeta, a todos los buscadores, basta con escribir:

User-agent: *
Disallow: /nombreCarpeta/

Donde “nombreCarpeta” irá el nombre de la carpeta que deseemos restringir. Si dejamos el “*”, la regla será para todos los spiders. De lo contrario, deberemos especificar uno en particular.

Continúa en la tercera entrega.

Finalizamos esta serie sobre negocios en Internet con la segunda parte de los servicios virtuales, el segmento que está moviendo el dinero más importante en este mercado. Tal como comentábamos en los artículos anteriores, “la red” es hoy una notable fuente de dinero disponible para implementar diversas maneras de conseguirlo.

Sin lugar a dudas, la más curiosa y la menos profesional de las que hemos analizado son los juegos de apuestas y casino. Muchísimas personas están dedicadas plenamente a lucrar con este “negocio”, sobretodo abocados al Póker y el Blackjack, juegos que poco lugar le dejan al azar. La alternativa es no ser el jugador, sino “la casa”, aunque hay un mayor esfuerzo inicial.

Otra posibilidad son los servicios personales, tipo característico de trabajo de los famoso empleados “freelance”. En este lugar se ubican redactores periodísticos, traductores, investigadores, beta-testers y hasta profesores virtuales, entre otros. También pueden formar parte de este mercado los programadores, de los cuáles hablaremos en el siguiente párrafo.

La programación de software es el sector principal en el que se vuelcan los expertos en informática. Ha experimentado un amplio crecimiento debido a la globalización que ha tomado este trabajo gracias a la masificación de Internet. La comercialización lleva un tiempo considerable, pero es fundamental para lograr resultados.

Continuaremos con la idea del artículo anterior comenzando por un punto bastante importante: “keyword density” o la densidad de nuestra palabra clave. No es más que la cantidad de veces que se repite por todo el sitio esta palabra, no solo en texto propiamente dicho sino también en el código (head, metas, etc.), en proporción al resto de los términos. Existen herramientas para analizar este punto y optimizarlo tanto como sea posible, sin excedernos.

Siguiendo con el tema de las palabras clave, existen formas de resaltar su relevancia ante el análisis de los motores de búsqueda. Una manera efectiva de lograr esto es transformar el formato de las keyword a la fuente Arial y la densidad Negrita (Bold en inglés), preferentemente mediante CSS.

En otro orden, es importante también medir el uso de las animaciones Flash. Aunque desde Adobe y desde Google aseguran que la visibilidad de estos archivos es confiable, la realidad es que las páginas programadas en HTML/ASP/PHP/etc. habitualmente les sacan ventaja. Flash es un excelente complemento, pero generalmente no constituye la mejor opción para construir todo un website.

Finalmente, nunca está de más revisar la ubicación geográfica de los servidores que contratamos para el servicio de hosting. Hace ya un tiempo que los buscadores implementan geolocalización. Tranquilamente podríamos encontrarnos con que una web de dominio .br (Brasil), cuyos servidores de alojamiento están en Australia, recibe mejores resultados en Google Australia que en Google Brasil. Preferentemente nuestro servidor debe estar donde esté nuestro target.

La primera parte de esta serie en: http://www.publicidadeninternet.biz/seo/ajustando-detalles-el-orden-del-...