Google para Periodistas | 1: Cómo encuentran información los buscadores o vida de una araña cibernética

Por qué se supone que un periodista necesita saber estas cosas

Edición Junio 2019

Google: amalo u odialo, pero si eres periodista no lo puedes ignorar. Es utilizado en el 70 por ciento de las búsquedas web en todo el mundo, en el 90 por ciento en Europa y en el 95 por ciento en España. ¿Es necesario saber cómo funciona Google si eres un periodista o un comunicador? Ciertamente no a nivel ingeniero, es decir, para poder clonarlo y montar otro Google, pero sí a nivel conceptual.

Por ejemplo, alguna vez he leído artículos de prensa que daban a entender que usando Google estás consultando la web en su totalidad y, además, en tiempo real, o sea, estás viendo la web tal como es en ese mismo momento. Ambas cosas son falsas ¿Es esto importante? Creo que sí, y en todo caso es un error, y se supone que el aspecto diferencial del periodismo profesional es el rigor.

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 de toda la web como respuesta. Ya es un problema que esto lo crean los usuarios, pero aún más si este usuario fuera un periodista.

Google no es toda la web

Google no es la totalidad de la web, y cuando buscamos en Google, no lo hacemos en la web del presente, sino en la web tal como era en algún momento del pasado. La comparación con la velocidad de la luz, aunque exagerada, se vuelve inevitable.

Cuando miramos al cielo, no vemos las estrellas tal como son ahora, sino tal como eran en el pasado. En ese caso, el responsable de ese desajuste es la velocidad de la luz, en el caso de Google es el tiempo que sus arañas tardan en visitar y copiar cada nueva información que se publica en la web, y en ningún caso es instantáneo. Los desajustes de tiempo en cada caso están ajustados a las dimensiones respectivas. Horas, días o semanas en el caso de Internet y Google, y minutos o milenios en el caso del universo y sus estrellas.

Esto quiere decir que, en el mejor de los casos puede haber un desajuste de horas en relación a la información de actualidad publicada por los principales medios, a los que Google monitoriza varias veces al día. Pero en cambio, puede ser de días o semanas con otros sitios, por importantes que sean.

Por supuesto, hay sitios que Google no visita nunca, porque de alguna manera están desconectados de los demás sitios. No reciben enlaces de sitios importantes y nunca han formado parte de los índices de Google.

Además, Google crea barreras geográficas de facto para nosotros al ponderar de forma muy superior resultados locales y en la lengua que cree que entendemos mejor. Hay varias razones para poder decir que Google no es la totalidad de la web, y otro ejemplo es el siguiente: ¿saben ustedes que si no desean ser indexados por Google (o por cualquier buscador) solamente tienen que poner una línea de texto en su servidor y Google pasará olímpicamente de su sitio? ¿Les suena esto con relación a la queja de los editores de prensa por aparecer en los resultados Google?

Creo que si eres periodista, incluso si no sueles informar sobre tecnologías, debes tener alguna noción sobre cómo funcionan los buscadores. La mínima, si quieren, pero suficiente para no trasladar ideas equivocadas al lector. Si eres periodista en temas tecnológicos, entonces es imprescindible y si eres periodista de investigación (de acuerdo, si adoras la idea de poder hacer periodismo de investigación algún día) entonces te arriesgas innecesariamente a hacer peor tu trabajo si no sabes cómo funcionan los buscadores.

A favor y en contra de Google

La  primera entrega de esta serie (Google para periodistas) se centra en cómo Google y los buscadores en general recorren e indizan la web para encontrar información. En otras entregas: examinamos cómo organizan las páginas de resultados, la búsqueda avanzada, y no faltará una dedicado a las alternativas a Google.

¿Qué es una araña (en la web)?

En el contexto de las tecnologías de la Web, una araña es un programa que explora la Web de forma sistemática con dos objetivos: (1) interactuar con servidores de sitios web para encontrar información y (2) obtener nuevas direcciones (URL) para añadir a su lista de enlaces pendientes de revisar. Las expresiones crawler, spider yrobot (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.

Por tanto, para ayudarnos a situar al spider en el contexto de las tareas de un buscador, revisar cuál es la lista de tareas típicas del mismo probablemente nos resultará útil (la primera es la del spider):

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 negrita: 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.

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 spiders: «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).

Como hemos señalado antes, las tres 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.
3. Añadir nuevas URL a la lista de enlaces para revisar,

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.cualquiercosa.com

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

www.cualquiercosa/index.html

o expresiones equivalentes como:

cualquiercosa/inicio.html

Lo que sucede es que, en la práctica, los servidores buscan de modo automático un archivo tipo index.html cada vez que el navegador les envía una petición de información de la forma abreviada www.cualquiercosa.com (es decir, el propio servidor añade la parte final omitida «index.html»).

Como ya hemos dicho, y dependiendo de la configuración del servidor, la parte omitida puede ser «inicio.html» (en lugar de index) o index.shtml (en lugar de .html), 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.html»).

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

www.ejemplo.com/productos/index.html

www.ejemplo.com/asistencia/index.html

www.ejemplo.com/acercade/index.html

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/acercade/memoria20019.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:

Que, a su vez, genera la nueva URL que el robot del buscador añadirá a su lista de enlaces pendiente de visitar:

www.ejemplo.ar/index.html

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, existían dos procedimientos por los cuales se podían enviar altas a un motor de búsqueda:
   1. Gratuito
   2. Mediante pago (ya en desuso)

En la forma gratuita, que es casi la única forma actual si exceptuamos alguna oferta que roza el fraude, el responsable 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, ya en desuso, era necesario realizar un pequeño 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 solía 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, por ejemplo para Estados Unidos).

Web scraping

Otro motivo por el cual los robots acceden a los servidores para solicitar páginas web es para copiar los contenidos, Scraping significa algo así como escarbar. La copia de contenidos hecha con técnicas de scraping implica copiar contenidos como decimos, pero a la vez analizarlos y volcarlos en formatos que permitan su análisis y reutilización en hojas de cálculo o en bases de datos.

Un objetivo del scraping puede ser hacer estudios o investigaciones. Por ejemplo, el periodismo de investigación utiliza técnicas de scraping para analizar documentos como pdf con informaciones oficiales, por ejemplo, datos estadísticos oficiales procedentes de la Administración pública.

Por desgracia, el objetivo de la investigación no es el único, ni mucho menos, sino que muchas robots hacen scraping con el fin de copiar contenidos y reutilizarlos en otros sitios como si fueran propios.

Interactuar con los sitios

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 más o menos 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 inicios de la década, 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 por varias razones: por un lado, al aumento del ancho de la banda de los servidores, ha seguido un aumento en paralelo del número de robots que circulan por Internet.

Por otro lado, existe el llamado crawl budget, que es algo así como la administración del presupuesto de tiempo que el robot de Google o de Bing destina a cada sitio. Interesa que el tiempo que estos robots tienen programado para nuestro sitio lo aprovechen al máximo, por lo cual, conviene evitar que pierdan el tiempo indexando contenidos sin interés.

Por último, sigue siendo necesario disponer de la posibilidad de excluir directorios enteros del servidor de la curiosidad de los robots (spiders) a voluntad del administrador del sitio. Siempre puede suceder que tengamos directorios con información que preferimos que no quede indexada y, por tanto, que no aparezca en los resultados de los buscadores.

Debe decirse que esto no implica que tales directories y la información que contienen quede a salvo de la indiscreción ajena. El malware (software malicioso) no sigue las indicaciones de ningún protocolo, y si la información está publicada en un servidor sin barreras (password) alguien la podría descargar si conoce la ruta, usando programas de descarga.

Protocolo de exclusión de robots

Como sea, al menos buscadores como Google y Bing, que son los que utilizan la inmensa mayoría de los usuarios, acatan las instrucciones del protocolo de exclusión de robots. El funcionamiento del mismo es de extrema sencillez. Las instrucciones del protocolo 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, ya que los robots únicamente lo buscarán aquí.

A partir de este momento, 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.

Por cierto, en el lenguaje del protocolo robots.txt, “User-agent” significa robot o crawler, por la teoría según la cual, un robot es un agente, es decir, un robot actúa siguiendo las órdenes de quien lo ha programado (usuario).

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

La primera línea de instrucción, User-agent, sirve para indicar si la misma se aplica únicamente a algún robot o spider en concreto, lo que no es el caso en el ejemplo, porque el asterisco, *,  significa que la instrucción es válida para todos. La segunda línea de instrucción, Disallow sirve para indicar qué directorio queda excluido de la inspección del robot, y si no se indica nada, como en el ejemplo anterior, es no hay ningún contenido bloqueado.

Esta sería una opción razonable para un sitio que queremos que sea indexado, ya que se supone que las empresas están interesadas en que les visiten los robots de Google y de Bing (o de Yandex o Baidu según la zona geográfica) y que pongan la información en sus índices para que sitio sea encontrado.

La opción exactamente contraria, según la cual todo queda bloqueado, y por tanto nada será indexado por parte de ningún robot sería la siguiente:

Obsérvese que la única diferencia es la barra inclinada, /, que indica que ningún directorio debe ser indexado. El asterisco en User-agent, por su parte sigue indicando que afecta a todos los robots.

Este eficaz gráfico procedente de Vary muestra de forma clara la enorme diferencia entre las dos instrucciones marcada por una sola diferencia: la barra inclinada (fuente: Vary.com)

Sin embargo, lo más normal es que el administrador de un sitio quiera que la mayor parte del contenido sea indexado, salvo algunos directorios en concreto. En este caso, el fichero robots.txt podría tener este contenido:

La instrucción anterior, evitará que los motores (al menos, los motores como Google o Bing) indexen el contenido del directorio denominado subidas (donde se supone que subimos documentos, por ejemplo y no queremos que los indice ningún robot).

Una instrucción del archivo robots.txt puede referirse a robots concretos para excluirlos de todo el sitio, como en el siguiente caso:

En la instrucción anterior, vemos que el robot Orthogaffe tiene expresamente prohibido el acceso al sitio.

También es posible incluir instrucciones que permiten expresamente (Allow) el acceso a un directorio directorio concreto. Por ejemplo, la siguiente instrucción permite expresamente al robot de Google para imágenes el acceso a uno de los directorios del sitio:

Recordemos que Allow es solamente reconocido por Google. Todas las combinaciones anteriores son posibles, esto es podemos bloquear partes concretas a todos los robots o podemos bloquear todo el sitio a un solo robot, etc.

¿Qué aspecto tiene un archivo robots.txt completo? En la captura que sigue, vemos el que presenta el sitio Moz (no siempre son tan completos)

Vemos que, además de algunos “Disallow”, utiliza también la directiva Allow. Por último, vemos que en el caso de Moz han preferido no referirse a ningún robot concreto y simplemente han puesto la lista de directorios permitidos y excluidos. Vemos también que las dos primeras líneas se han utilizado para proporcionar el camino de acceso a los sitemaps de Moz

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, cosa que es bastante normal, como ya hemos señalado a efectos de optimizar el tiempo que los robots dedican a visitar nuestro sitio (crawl budget).

Lo más importante es que los modernos gestores de contenidos, como WordPress, disponen de plugins que generan un archivo robots.txt, y en este caso, uno de los más utilizados, por ejemplo,  es el plugin Yoast SEO.

En cualquier caso, es muy importante tener en cuenta que el malware, esto es robots que persiguen hacer daño de alguna forma (p.e. piratear io hackear un sitio) no respetan el protocolo robots.txt. Tampoco sirve para ocultar ni para proteger información confidencial. La única forma de evitar que alguien vea información confidencial es, simplemente, no subirla a nuestro sitio o, en caso de que queramos subirla por algún motivo, protegerla mediante password si usamos un CMS que lo permite, etc.

Por último, aunque la sintaxis de robots.txt es muy sencilla es mejor no manipular este archivo sin conocimientos técnicos por las implicaciones de indexación que conlleva. Una mala configuración puede hacer que perdamos visibilidad, o que queden fuera de la indexación subdirectorios que en realidad nos interesa mucho que sean indexados. El consejo por tanto, es dejar esta tarea a nuestro webmaster o utilizar un plugin de calidad y eficacia probada, como Yoast si usamos una instalación de WordPress.

Meta elemento robots

El lenguaje HTML proporciona un elemento o una directiva del tipo meta que permite complementar (o sustituir el fichero robots.txt). En realidad, se considera que el uso del meta elemento que presentaremos a continuación es más eficaz para evitar la indexación de una página que el protocolo robots.txt.

Pero hay que tener presente que este meta elemento funciona solo a nivel de página individual, aunque a partir de una página individual se puede especificar que no siga indexando los enlaces que encuentren en la misma.

Como es sabido, los elementos meta de HMTL permiten añadir metadatos a una página específica utilizando el elemento indicado con los atributos name y content.

El valor de name para este caso 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 :

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.

En la captura superior vemos la estructura del meta elementos robots. Consiste en el atributo name con el valor = “robots”, mientras que el atributo content tiene el valor “noindex, nofollow”.  Como vemos, más claro imposible: dice a los robots que no indicen esta página ni sigan las enlaces contenidos en la misma.

En la captura que sigue, de la misma fuente, Moz, veremos los componentes que podemos utilizar en la sección content:

Podemos observar algunas directivas curiosas, como la Noodyp/noydir ya obsoleta (como bien se indica), y que en su momento le decía a los buscadores como Google que no usaran la descripción del sitio presenten en el Directorio DMoz (hace tiempo en desuso) en el snippet de la página de resultados. Fue un curioso acuerdo entre Google y DMoz que duró unos años. Parece que hace siglos.

También podemos ver otras como Noimageindex o como Nosnippet para que no indicen imágenes o para que no utilicen el snippet de en la página de resultados.

Protección desde el CMS o el servidor

Además del robots.txt y de los meta elemento robots, podemos proteger el acceso a determinadas secciones o páginas de sitio mediante configuración del CMS, añadiendo passwords al acceso a ciertos contenidos.

También podemos añadir reglas al servidor para que no permita el paso de robots que tienen un comportamiento muy agresivo, programando el servidor para que bloquee peticiones muy seguidas de ficheros.

En el caso de CMS como WordPress algunos plugin de seguridad pueden hacer esta clase de configuraciones.

Las formas de hacer esta clase de programaciones o de configuraciones son dependientes de cada instalación y del CMS utilizado, por lo que escapan a los objetivos de esta Unidad, pero no queríamos dejar de señalar su existencia.

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 cómo 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.

En este contexto, ha aparecido últimamente el concepto de crawl budget, es decir, presupuesto de rastreo. Esto procede de la idea de que Google no dedica recursos ilimitados al rastreo de los sitios.

En su lugar, dedica más tiempo a los sitios de mayor autoridad en un tema y que se actualizan más. También significa que el presupuesto de rastreo que Google nos asigna quedará óptimamente aprovechado por parte de los sitios que tengan mejores estructuras de navegación, menos enlaces rotos y que diseñen mejor su sistema de enlazado interno.

Conclusiones

Algunos sitios son visitados varias veces al día, como los sitios de medios de comunicación, pero otros son visitados en intervalos de días o de semanas, otros no se visitan en absoluto (p.e. debido a un archivo robot.txt, a veces mal codificado por error) y de otros no se indizan todas las páginas, y ni siquiera indizan todo el contenido de cada página.

Otros no se indizan por mala configuración de otras opciones del servidor o del diseño de la navegación de sitio, otros no se indizan porque los administradores prefieren mantenerlos ocultos y aún otros no se abren a los buscadores por la sencilla razón de que son sitios web privados, o tienen barreras de pago, etc.

Hace tiempo que los buscadores 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.

Otras herramientas complementarias, de gran utilidad, como el Search Console, en el caso de Google o las Webmaster tools en el caso de Bing, ayudan a la adecuada relación y comunicación entre los administradores de los sitios y los buscadores.

Hemos visto que disponemos de herramientas de software como robots.txt y los metadatos o directivas robots para bloquear o permitir el acceso a páginas y directorios del sitio, lo que en todo caso no garantiza que el malware vaya a ser bloqueado por estos medios, ni mucho menos. Las directivas robots.txt y las de los metadatos son más bien para retirar contenidos del índice de los buscadores y para optimizar el crawl budget, o tiempo que el robot permanece en nuestro sitio.

Para bloquear el acceso con motivos de confidencialidad, hay que bloquear al acceso con passwords, y para evitar usos abusivos o los robots de malware no hay más remedio que acudir a soluciones a nivel de servidor con utilización de software de seguridad.

Por último, y regresando al robots.txt, recordar algo que ya hemos destacado en el artículo, a saber, que su configuración es altamente sencilla en apariencia pero que un pequeño error puede evitar la indexación de todo el sitio o de secciones enteras del mismo, por lo que conviene dejar la misma a personal experto o utilizar software muy fiable.

Por la misma razón, no es buena idea intentar modificar archivos sensibles como el utilísimo, pero altamente estratégico archivo .htaccess del servidor para introducir reglas para bloquear robots. Es mucho mejor configurar estas opciones siempre a través de personal experto. Nosotros las hemos señalado aquí, porque forman parte de las cuestiones que un profesional del SEO es muy conveniente que conozca, otra cosa es a quien corresponde su manipulación.

Además, y esto es algo que entenderemos mejor en otras entregas, Google tiene una política muy restrictiva con las páginas que deja ver a los usuarios. Probablemente, aunque yo me empeñe, no me dejará ver páginas de países que Google ha decidido que a mí no me interesan.

Aunque sea por motivos estadísticos, Google puede decidir que es muy raro que yo quiera ver páginas de Eslovenia, por ejemplo, y aunque haya páginas eslovenas que contienen la información que yo estoy buscando, simplemente no las mostrará en mi navegador. O las mostrará en una posición tan retrasada (p.e. a partir de la cuarta o quinta página) que es casi seguro que nunca sabré de su existencia.

He puesto este ejemplo, que puede parecer un poco forzado, porque es un caso real, en su momento, no hace demasiado tiempo, tuvimos un investigador visitante en nuestro Departamento procedente de Eslovenia, pues bien, cada vez que hacíamos consultas esperando encontrar páginas de ese país resultaba misión (casi) imposible aún poniendo palabras clave muy precisas. Google había decidido que era imposible que un usuario ubicado en España pudiera estar interesado en páginas ubicas en Eslovenia y simplemente no las mostraba. Sin más.

Espero haber podido, sino demostrar, al menos, razonar, porqué es importante que los profesionales de la comunicación conozcan, aunque sea a nivel conceptual, cómo funcionan los buscadores y, por tanto, cómo funciona Google.

Las cuatro entradas de la serie Google para periodistas y comunicadores:

• Cómo funciona un rastreador
• Cómo se determina la calidad de una página web
• Cómo funciona la búsqueda avanzada
• Buscadores alternativos a Google y cómo usarlos

Para saber más

• Fontela, Álvaro. El mejor robots.txt para WordPress – Manual explicativo del robots.txt
• García, Iván. Crawling, SEO y cosas de bots. 2016, Vídeo en YouTube: https://www.youtube.com/watch?v=FbjTv77tk1w&list=PLJTssugmHdHwrADGKRpDBXbpymVYQtexs&index=8
• Google. Especificaciones de robots.txt
• Jackson, Brian. Web Crawlers and User-Agents – Top 10 Most Popular
• Méndez, Luis. Cómo bloquear los robots indeseables en tu WordPress
• MOZ. Metadirectives
• Mendez, Pedro. 5 Plugins de WordPress para detener los malos Bots
• Parson, James. How to Block Bad Website Bots and Spiders With .htaccess Tweaks
• Posicionamiento SEO. ¿Qué es el crawl budget? https://www.posicionamiento-seo.info/que-es-crawler-budget-de-tu-site
• Rastreadores de Google
• Sexton, Patrick. The Google Bot Guide
• The Internet of Bots
• The Internet of Bots > List of bots
• Yoast SEO. robots.txt The ultimate guide.
• “Web crawler”. Wikipedia . http://en.wikipedia.org/wiki/Web_crawler

Icon made by Freepik from www.flaticon.com