Nota sobre la evaluación: de forma intercalada en el texto de este artículo encontrará el enunciado de diversas actividades. Para superar esta unidad didáctica deberá realizar estas actividades redactando un informe en el que se incluyan comentarios y, en caso que sea pertinente, una captura de pantalla de cada actividad para ilustrar su realización. Para entregar este informe deberá crear un solo documento para todos las actividades de esta unidad didáctica en formato OpenOffice o Word y de un máximo de 500 Kb. A continuación podrá usar el espacio de entrega y notificación perteneciente a este grupo de unidades didácticas. La realización de forma satisfactoria de este ejercicio implicará la obtención de 0,75 créditos.

1. Introducción

En el contexto de la Web, un spider (araña) o un crawler (rastreador) es un programa que explora la Web de forma sistemática con dos objetivos principales: (1) interactuar con los servidores de sitios web para descargar página web u otros documentos y (2) obtener nuevas direcciones (URL) para añadir a su lista de enlaces pendientes de revisar. Las expresiones crawler , spider y robot (en este contexto) son equivalentes.

La simplicidad conceptual de lo anterior esconde, como suele suceder en el mundo de las tecnologías, un conjunto de operaciones cuyos detalles y casuística está lejos de ser tan simples como aparentan.

Los spiders más famosos son, sin lugar a dudas los spiders de buscadores como Yahoo, AltaVista o Google. Sin embargo, se calcula que actúan en la Web miles de spiders sirviendo a propósitos distintos. Por ejemplo, es frecuente que distintos grupos de investigación, ya sea de universidades o de corporaciones que estudian aspectos de la web dispongan de sus propios spiders para recolectar más o menos periódicamente la información que desean analizar. En esta unidad nos limitaremos a los spiders de los motores de búsqueda.

Actividad 1: Acceda al artículo de Wikipedia dedicado a spiders ( http://en.wikipedia.org/wiki/Web_crawler ) y consulte la definición. Compruebe la equivalencia de términos como spider, crawler y otros en los tres primeros párrafos de definición del concepto.

2. Contexto

Muchos usuario consideran que, cuando llevan a cabo una búsqueda, ésta tiene lugar en tiempo real: es decir, implícitamente suponen que el motor de búsqueda rastrea o examina las páginas web para cada pregunta y ofrece una selección de las mejores páginas como respuesta.

Naturalmente, esta imagen es imposible. Dado el tamaño de la Web no existe, ni se prevé que exista, un sistema de información capaz de esta proeza. En todo caso, lo que hacen los motores de búsqueda es consultar un índice local (“local” desde el punto de vista del motor de búsqueda) que facilita el acceso a las características de las páginas y otros documentos que antes descargó para el motor en cuestión uno de sus más atareados componentes: el spider .

Ahora bien, para ayudarnos a situar al spider en el contexto de las tareas de un motor, recordar cuál es la lista de tareas típicas del mismo probablemente nos resultará útil:

1. Acceder a sitios web, localizar y descargar documentos

2. Extraer el contenido textual (y multimedia) de los documentos descargados

3. Analizar e indizar el contenido de los documentos para construir los índices del motor

4. Realizar el análisis de enlaces de cada página y otorgar alguna medida de popularidad (PageRank, WebRank, etc. a cada página)

La cuestión es que, de las cuatro operaciones mencionadas, es justamente la primera de todas (la que hemos destacado en cursiva: Acceder a sitios web, etc.) la que corresponde al spider y que nosotros discutiremos desglosándola en otras dos: gestionar listas de enlace e interactuar con los sitios. Para esta última función, cada spider necesita una denominación específica (su nombre) que utiliza para identificarse delante del sitio y cuya actividad queda registrada en los archivos de actividad ( logs ) del sitio.

3. Robots

Los spiders forman parte de una clase más amplia de programa denominados agentes o robots . Los programas agentes se caracterizan por dos cosas: tener un cierto grado de autonomía y actuar en representación de un usuario (o de una tercera entidad). Por ello, existe aún una tercera denominación para los spyders: "agentes de usuario" ( user-agents ) como tendremos ocasión de comprobar más adelante.

La autonomía significa que pueden interactuar con otros agentes o sistemas sin necesidad de suspender su actividad en espera de instrucciones detalladas del usuario. El hecho de que actúen “en representación de...” es lo que les otorga su nombre de agentes precisamente. En este caso, los spiders son robots cuya misión es rastrear la web y descubrir información en representación de los motores de búsqueda (cada motor tiene sus spiders particulares).

Actividad 2: Entre en esta dirección del Search Engine Dictionary: http://www.searchenginedictionary.com/spider-names.shtml e intente localizar los nombres de los spiders de los tres motores de búsqueda siguientes: Google, AltaVista y AlltheWeb

Como hemos señalad antes, las dos tareas típicas de un spider son las siguientes:

1. Gestionar listas de enlaces (URLs)

2. Acceder e interactuar con sitios web para descargar páginas o documentos

Gestionar enlaces

En la Web, cada documento (sea una página HTML o un documento unitario) está asociado a un enlace. La página principal del sitio es una URL aparentemente del estilo:

www.lluiscodina.com

que en realidad corresponderá a un enlace o URL del estilo:

www.lluiscodina.com/index.htm

Lo que sucede es que, en la práctica, los servidores buscan de modo automático un archivo index.htm cada vez que el navegador les envía una petición de información de la forma abreviada www.unsitiodeejemplo.com (es decir, el propio servidor añade la parte final omitida "index.htm"). Dependiendo del servidor, la parte omitida puede ser "inicio.htm" (en lugar de index) o index.shtml (en lugar de .htm), etc., o cualquier otra posibilidad definida en la configuración del servidor". Nosotros supondremos para los ejemplos que siguen que el servidor está configurado en la opción más simple ("index.htm").

La cuestión es que, en la supuesta página www.ejemplo.com/index.htm existirá un serie de enlace a otras páginas del mismo sitio, por ejemplo, “Productos”, “Asistencia”, “Quiénes somos”, etc, dando lugar por ejemplo a una serie de URL como esta:

www.ejemplo.com/productos/index.htm

www.ejemplo.com/asistencia/index.htm

www.ejemplo.com/quienesSomos/index.htm

Igualmente, si el sitio proporciona acceso a documentos en otros formatos, esto significa que contendrá URL como estas:

www.ejemplo.com/productos/presentacion.ppt

www.ejemplo.com/asistencia/tutorial.pdf

www.ejemplo.com/quienesSomos/memoria2007.pdf

Por último, probablemente el sitio contendrá enlaces a páginas de otros sitios web. En este caso, tales páginas aparecerán, a nivel de código fuente de esta forma:

... <a href:”http:// www.ejemplo.ar/index.htm > Delegación en Argentina </a> ...

Que, a su vez, genera la nueva URL:

www.ejemplo.ar/index.htm

Por tanto, debemos tener claro que, para el spider un documento es siempre un enlace (técnicamente, una URL), y por tanto el primer componente del spider es, necesariamente un sistema que le permita gestionar enlaces: a saber, cómo adquirir enlaces y cómo gestionarlos de manera que, por ejemplo, otorgue prioridades sobre qué enlace se visita primero, qué enlaces (páginas) se visitan más a menudo, cómo evitar hacer el mismo trabajo varias veces (por ejemplo, visitando la misma página en intervalos de tiempo muy cortos).

Por otro lado, como los motores de búsqueda generalistas aspiran a “controlar” toda la Web, su principal preocupación es de dónde obtener los enlaces para alimentar a su spider.

Actualmente, existen dos formas por las cuales el gestor de URLs de un spider obtiene sus enlaces:

1. Enlaces de páginas web analizadas Hemos visto un ejemplo según el cual, el hecho de que un spider entre en www.ejemplo.com proporciona al spider una lista de enlaces adicionales de dos tipos: enlaces del mismo sitio, que analizará de forma más o menos interactiva si el sitio no es muy grande, y enlaces a nuevos sitios, que añadirá a su lista de nuevos enlaces para visitar. Podríamos preguntarnos de dónde procedieron los primeros enlaces. La respuesta es fácil: cada vez que aparece un nuevo motor de búsqueda, éste inicia sus actividades necesariamente con una lista más o menos larga de URL que han introducido en el spider los creadores del buscador. La lista puede tener miles o puede tener millones de URL en función del trabajo previo de los desarrolladores del buscador, los recursos para obtener esas URL, etc.

2. Enlaces proporcionados (submitted URLs) Los gestores y responsable de sitios web pueden rellenar los formularios ad-hoc de los principales motores de búsqueda para dar a conocer (dar de alta), al menos, la URL de la página principal de su sitio (y en caso necesario, las URLs de las principales secciones del mismo). A su vez, existen dos procedimientos por los cuales se pueden enviar altas a un motor de búsqueda:

   Gratuito

   Mediante pago

   En la forma gratuita, el responde de un sitio web accede a un formulario específico del motor y entra los datos (típicamente, la URL de la página principal) del sitio sin necesidad de pago ni desembolso alguno. En cambio, en la fórmula de pago, es necesario realizar un desembolso (de entre 10 y 50 euros) previo para que el motor realice el alta de la página principal del sitio o de otras páginas adicionales del sitio.

   En el primer caso, en compensación a la ventaja evidente de la gratuidad (y de la ausencia de gestiones) se encuentra el hecho de que el motor de búsqueda no garantiza resultados: ni el plazo para proceder al alta, que puede demorarse hasta un mes, ni la exhaustividad del análisis del sitio, del que pueden quedar páginas sin indizar, ni la frecuencia de actualización del índice del sitio.

   En el segundo caso, a cambio del desembolso, el motor suele garantizar la inclusión en un plazo breve (típicamente 48 horas), un análisis más completo del sitio y una mayor frecuencia de actualización del sitio.

   Google nunca ha practicado la modalidad de pago por inclusión, mientras que Yahoo la ha practicado en ocasiones para su directorio y actualmente es una opción voluntaria para su motor de búsqueda en algunos mercados (por ejemplo, en el momento de preparar esta unidad no estaba disponible en España).

Actividad 3: Vaya a Google, entre en la página principal de ayuda y localice la función correspondiente a dar de alta un sitio. Compruebe si debe realizarse algún desembolso o, por el contrario, es gratuita.

Interactuar con los sitios

Protocolo de exclusión de robots

En los años noventa, los spiders representaron un auténtico problema para los servidores de sitios web. En aquella década había disponible solamente una fracción ínfima del ancho de banda del que se dispone hoy en la mayor parte del mundo. Además, el software y el hardware de los servidores proporcionaba también un menor rendimiento.

Por todo ello, los spiders de los motores podían llegar a causar graves problemas a los servidores. Las insistentes visitas de un spider para descargar los documentos de un sitio podían provocar un mal rendimiento (o el colapso momentáneo) del servidor de cara a los usuarios “reales” del sitio. Además, pronto los administradores de los sitios descubrieron hasta qué punto podía resultar indiscreto subir documentos al servidor o intentar mantener directorios enteros del sitio para colocar información reservada, ya que los spiders descargaban (y mandaban a indizar) cualquier cosa que encontrasen en el servidor cumpliendo su misión de robots disciplinados y sistemáticos.

Por todo ello, se desarrolló el llamado “Protocolo de exclusión de robots”, bajo cuyo pomposo nombre se escondía un simple procedimiento (en plena vigencia) que permite al administrador de un sitio excluir el análisis de los spiders (robots) de ciertos directorios o de todo el sitio; o prohibir a robots concretos el acceso al sitio.

Por un lado, ya no padecemos la carestía de ancho de banda de los años 90, y por otro lado, los programadores de los spiders han creado una generación de robots mucha más eficiente que genera menos carga para los servidores. Sin embargo, el protocolo tiene plena vigencia aunque solamente sea por la posibilidad de excluir directorios enteros del servidor de la curiosidad de los robots (spiders) a voluntad del administrador del sitio.

El funcionamiento del protocolo es de extrema sencillez. Las instrucciones del mismo se sitúan en un archivo de texto (de nombre robots.txt ) que, a su vez, se coloca en el directorio principal (directorio raíz) del sitio.

Se supone que los robots (spiders en este caso) deben leer el archivo antes de empezar a interactuar con el sitio y descargar documentos. Si el sitio no posee este archivo, se entiende que el robot no tiene limitación ninguna para rastrear el sitio (se aplica el viejo principio del “el que calla, otorga”).

Si el sitio dispone del archivo robots.txt , se supone que el robot simplemente obedecerá las directrices del mismo. Hasta donde se sabe, los spiders de los principales buscadores obedecen las directrices.

La versión más simple del archivo robots.txt es la siguiente:

User-agent: * Disallow:

La primera instrucción sirve para indicar si la misma se aplica únicamente a algún spider ( User-agent ) en concreto (no es el caso) o se aplica a todos en general ( * significa que la instrucción es válida para todos). La segunda instrucción ( Disallow ) sirve para indicar qué directorio (o directorios) queda excluido de la inspección del robot.

Por tanto, la versión del fichero robots.txt indica que no hay ningún directorio del servidor excluido y que tal indicación es válida para todos los spiders. Dicho de otro modo: cualquier spider puede indizar la totalidad del servidor. Esta es la opción más habitual, por otro lado. Lo normal es que las empresas estén interesadas en que les visiten cuantos más spiders mejor (significa que aparecerán en más índices de búsqueda) y en que indizen cuanta más información mejor.

Sin embargo, pudiera suceder que el administrador de un sitio quisiera excluir un directorio de la curiosidad de los buscadores. En este caso, el fichero robots.txt podría tener este contenido:

User-agent: * Disallow: /debates/

La instrucción anterior, evitará que los motores (al menos, los motores más conocidos, como Google o Yahoo) indicen el contenido del directorio debates .

No es necesario incluir un archivo robots.txt en el sitio autorizando expresamente que el sitio se puede indizar, ya que se considera que la ausencia de un fichero robots.txt equivale a la autorización. Sin embargo, se considera recomendable colocar el archivo aunque sea para confirmar que el sitio se puede indizar, ya que es el primer documento que el spider pedirá a nuestro servidor. Naturalmente, será obligado ponerlo en el caso que deseemos excluir alguna parte o todo el servidor del análisis de los spiders.

Actividad 4: Vaya al sitio oficial que mantiene el protocolo de exclusión de robots: http://www.robotstxt.org/ y acceda a la página Robots exclusion para conocer el contenido del protocolo original.

Elemento robots

El lenguaje HTML proporciona un elemento del tipo meta que permite complementar (o sustituir el fichero robots.txt ). Como es sabido, los elementos meta de HMTL permiten añadir meta datos a una página utilizando el elemento indicado con los atributos name y content. El valor de name siempre debe ser “robots” , y el de content dependerá de lo que se quiera transmitir al robot. De este modo, una página web puede contener esta etiqueta en su código fuente en la sección head :

<meta name=”robots” content=”noindex, nofollow” />

Como es fácil de deducir, estamos diciendo a todo y cualquier robot que acceda a la página que ni debe indizar la página ni debe seguir los enlaces que pueda contener la misma. Naturalmente, podemos indicar lo contrario: index y follow , pero este es el comportamiento por defecto y por tanto no sería necesario indicarlo.

Prioridades y estrategias

El programador de un spider debe considerar aún otros aspectos en su relación con los sitios web. Las opciones típicas que debe afrontar se refieren, en primer lugar, a la necesidad de desarrollar algoritmos que aseguren que el spider visita con más frecuencia los sitios que se actualizan así mismo con mayor frecuencia.

En segundo lugar, los spiders deben incorporar estrategias de análisis que les permitan explorar tanto en amplitud como en profundidad un sitio, sin quedar atrapados por largo tiempo en el mismo sitio, así que deben incorporar algoritmos sobre como tomar decisiones ante sitios a la vez muy amplios y muy profundos, de manera que no colapsen el servidor pero puedan acceder a la mayor parte del contenido del mismo si no en el mismo día o en días sucesivos.

En realidad, la casuística es enorme: cómo tratar con sitios que son muy enlazados, con sitios gestionados mediante sistemas de gestión de contenidos cuyas direcciones (URL) se generan de forma automática (en lugar de ser direcciones estáticas); cómo tratar enlaces incluidos en instrucciones JavaScript (por ejemplo, para generar menús desplegables); cómo tratar las altas manuales en su formulario al efecto, etc.

Actividad 5: Vaya a la página de Google dedicada a webmasters. Compruebe la disponibilidad de diversas herramientas que Google pone a disposición de los administradores de sitios.

4. Conclusiones

Algunos motores, notablemente, Google, han afrontado la complejidad de las tareas que deben abordar sus robots mediante la creación de herramientas específicas (p.e. Sitemaps) destinadas a ser usadas por los administradores de sitios pero que sirven, por un lado, para que su spider “entienda” mejor el sitio y realice una indización exhaustiva tanto en amplitud como en profundidad y, por otro lado, para que el administrador del sitio pueda saber en todo momento cómo ha sido visto y analizado su sitio por parte del spider. Es decir, a cambio de dar algo de "poder" a los administradores de sitios en relación con el spider, el spider de Google a su vez puede interpretarlo mejor. Entendemos que se trata de una medida muy sabia por parte de Google. Lo mejor sería, sin embargo, que esta clase de procedimientos se consensuaran y adoptaran entre todos los motores y se llegase a un estándard, cosa que se ha iniciado recientemente con la propuesta de Google de hacer un estándard del sistema denominado Sitemaps (www.sitemaps.org).

Por tanto, aunque es de suponer que los spiders de los buscadores harán cada vez mejor su trabajo, no dejará tampoco de ser necesario que los responsables de los sitios tengan un cierto conocimiento de las características de esta clase de robots y de los problemas que deben afrontar.

5. Bibliografía

Menezer, F. “Web crawling” En: Liu, B. Web data minig: Exploring hyperlinks, contents, and usage data . Berlin: Springer, 2007

Ties, D.; Davies, D. “How spiders work” En: The Search Engine Marketing Kit. Melbourne: Sitepoint, 2007

“Web crawler”. Wikipedia . http://en.wikipedia.org/wiki/Web_crawler