Versiones de webs móviles inteligentes

Según voy leyendo y probando en algunos sitios, me doy cuenta de que a los buscadores no les gustan tanto las versiones móviles de los sitios como podría parecer. Esto no significa que no haya que hacer versiones para dispositivos móviles, pero deberían ser la misma web que la original, tratada con CSS y en una versión especial en otro dominio o subdominio. Al menos estas últimas versiones siempre quedarán degradadas a un último plano a la hora de hacer SEO.

Y teniendo en cuenta esto Google tiene un sistema para que no sea necesario crear ediciones especiales en dispositivos móviles muy antiguos, Identifying relevant portions of a document, un sistema por el cuál cuando un usuario introduce una búsqueda desde un dispositivo de este tipo, la consulta se analiza con unos pesos distintos y se devuelve un resultado adaptado a la consulta.

¿Qué significa esto? Pues que primero se analiza la consulta, se entiende mejor qué quiere conseguir el usuario (si visitar un sitio o conseguir información) y una vez analizado se recupera la parte más importante del documento y se le devuelve organizada al usuario en una versión más sencilla. Con esto se podría paginar el contenido para adaptarlo a la cantidad de caché que tiene el dispositivo, por ejemplo, y dividir una página normal en varias para que el usuario sea capaz de gestionarlo con su terminal.

El proceso sería el siguiente:

Básicamente funciona como comentaba antes. El usuario hace una búsqueda, le aparecen los resultados, y al elegir uno de ellos se analiza el contenido de la página, se extrae y ordena la información, se adapta al terminal móvil, y se le devuelve la información concreta del documento elegido.

El sistema funciona siempre y cuando el documento tenga una buena arquitectura, ya que la detección se hace gracias a los distintos nodos que hay en la página, de forma que la anidación de nodos y los pesos de los mismos cobran una vital importancia.

Este proceso seguiría los pasos siguientes (de forma que se puede extraer a información de forma correcta):


Y ahora que ya se ha sacado la información importante de la página y sus nodos, lo que queda es convertir y adaptar ese contenido al del dispositivo en cuestión:

Un sistema bastante sencillo de adaptar los resultados de búsqueda y los contenidos al usuario, aunque siempre en conflicto con los creadores del propio sitio que perderían la identidad del mismo, publicidad y otra serie de elementos de la página (aunque, eso sí, en un dispositivo bastante antiguo o con pocas capacidades).

Google Quality Rater: utilidad del documento

Para los que no lo sepan, Google desde hace muchos años contrata a gente que suele trabajar desde casa en la revisión de calidad de los resultados de búsqueda. Incluso, muchos de los que hace unos años eran “los mejores SEO” tenían a algún familiar muy directo metido a trabajar en este tema (de ahí ser tan buen SEO y ahora ya no serlo tanto). A cada Quality Rater de Google se le en entregan las General Guidelines (PDF) en la que se explica el funcionamiento de la plataforma de calificación además de los diferentes puntos donde se detalla qué es y no es calidad, además de qué es y no spam.

Aunque esta última versión (la 3.18 de marzo de 2011) tampoco lleva muchos cambios con respecto a la anterior, lo principal es el concepto de “sin utilidad”. Este documento no te ayuda a hacer SEO, sino que te ayuda a diferenciar lo que Google considera qué es y qué no es calidad en un resultado de búsqueda para una búsqueda concreta, dependiendo de muchos factores.

La utilidad de la landing page es la de medir cuánto de útil es la página para lo que el usuario intenta encontrar. Páginas útiles son de ayuda para los usuarios. Páginas inútiles son de poca ayuda. La utilidad es el aspecto más importante para la calidad de un motor de búsqueda y es lo más importante a tener en cuenta cuando evalúes una página web.

Existen varios niveles de utilidad:

  • Vital (vital): Son lo que podríamos llamar “páginas que han de estar ahí sí o sí”.
  • Useful (útil): Página muy útil para el usuario.
  • Relevant (relevante): La página es de ayuda para la mayoría de los usuarios.
  • Slightly Relevant (algo relevante): La página no es de gran ayuda pero está relacionada con la búsqueda y algunos usuarios pueden encontrarle utilidad.
  • Off-Topic or Useless (sin relación o inútil): La página puede ser útil para uno o ningún usuario.
  • Unratable (inclasificable): La página no puede ser evaluada.

Lo primero que hay que hacer es entender la consulta de búsqueda que está haciendo el usuario. Por ejemplo, si busca [fedex] lo más probable es que quiera hacer un seguimiento de un paquete, si busca [ebay] querrá visitar el sitio o comprar o vender algún producto; si busca [calendar] puede que busque imprimir o prsonalizar un calendario, encontrar un calendario con fechas destacadas o encontrar un servicio de calendarios en línea.

Por otro lado hay que tener en cuenta el idioma con su peculiaridad geográfica. Por ejemplo no es lo mismo buscar [football] en inglés de Estados Unidos que [football] en inglés de Reino Unido, ya que en el primer caso hablaríamos de “fútbol americano” (similar al rugby) y en el segundo hablamos de “fútbol” (en inglés, lo que es soccer).

Otro detalle a tener en cuenta es que una consulta de búsqueda puede tener varios significados. Y para ello se utilizan tres clasificaciones:

  • Dominant interpretation: Es lo que la mayoría de usuarios tienen en mente cuando hacen esa consulta de búsqueda.
  • Common interpretations: A veces no hay una interpretación principal, por lo que caben muchas posibles válidas. Por ejemplo palabras con varias acepciones.
  • Minor interpretations: Son el resto de interpretaciones que puede tener una búsqueda, no habitual pero igualmente válida.

Los usuarios también, cuando realizan una búsqueda, pueden tener en mente la acción que quieren hacer. Es por esto que las búsquedas se clasificarían de 3 formas distintas, el Do-Know-Go:

  • Action intent (Do): El usuario quiere realizar una acción (descargar, jugar, enviar algo, comprar…)
  • Information intent (Know): El usuario busca información sobre algo.
  • Navigation intent (Go): El usuario quiere visitar alguna página en concreto.

Otro detalle a tener en cuenta es el idioma del documento en cuestión. Para cada idioma se puede asignar que la página está en ese idioma, en uno “razonable”, en inglés o desconocidos:

  • Task Language: El idioma es el mismo que el que realiza la consulta.
  • Acceptable Language: Un idioma aceptable para la región desde la que se consulta. Por ejemplo, un idioma que la mayoría de la población sea capaz de entender.
  • English: Si el documento está completamente o parcial en inglés. Sí, el inglés siempre tiene una predominancia especial.
  • Foreign Language: Si el documento está el otro idioma que no corresponde a los casos anteriores.
  • None of the above: No es posible identificar el idioma del documento.

Todo esto nos dejaría un panel bastante similar a este:

Esto sería más o menos de forma general los detalles a tener en cuenta para determinar la relevancia y calidad de un sitio, pero no es todo. Antes de seguir voy a revisar con detalle cada uno de los puntos de relevancia, en los que hay mucho más a explicar que el breve resumen anterior.

Vital

La opción “vital” se utiliza en 2 situaciones claras: la consulta de búsqueda es inequívocamente el resultado de búsqueda; la otra es que la consulta de búsqueda haga referencia a una marca, producto, negocio, lugar, etc… de forma predominante para esa búsqueda. En cualquiera de los casos ha de ser una interpretación dominante, de forma que no puede haber ninguna duda en la respuesta.

En el caso de que la búsqueda sea navigacional (Go), si la consulta de búsqueda coincide con el sitio se convierte en vital. Incluso, si la búsqueda hace referencia a una subpágina también se convertiría.

Otro de los casos especiales es el de las búsquedas de personas. Hay consultas que son obvias y predominantes como [george bush] o [bill clinton] que serían vitales, pero otras genéricas como [bob smith] no tienen una interpretación clara, por lo que no pueden serlo. Personas que no son “famosas” pero son conocidas en un sector determinado por alguna razón también pueden llegar a tener un elemento vital. Las páginas oficiales de las personas siempre son vitales, incluso para gente que no es famosa pero sí que puede ser relevante en un sector. Las páginas oficiales de grupos de personas (música, organizaciones, etc) pueden también considerarse vitales. Las páginas de redes sociales nunca son vitales.

Las páginas oficiales de un sitio web que está en varios idiomas también pueden considerarse vitales en cada uno de esos idiomas. Los sitios en las que la búsqueda coincide con el dominio no tienen porqué considerarse vitales; un ejemplo podría ser [diabetes] y que exista el [diabetes.com], pero al ser una consulta genérica con múltiples interpretaciones no se puede hacer vital dicho dominio.

Dentro de las opciones de Vital existen:

  • Appropiate Vital: La versión de la página coincide completamente con el idioma, país, etc de lo que el usuatio ha consultado.
  • International Vital: Si la página es de esas de “elige tu país” o “elige tu idioma”. También se puede considerar la versión en inglés de la web oficial como este caso.
  • Other Vital: Aunque el idioma o país no coincida con lo que debiera, pero esa versión cuadra al máximo con lo que el usuario necesita.

Useful

Una página útil es aquella que ofrece un resultado de mucha calidad y que “cuadra” con la búsqueda. Normalmente son páginas en las que uno puede confiar y donde las fuentes de información son correctas, por lo que no contienen spam.

En este caso, muchas páginas relacionadas con una consulta pueden ser clasificadas aquí. Páginas de rumores, sitios populares, vídeos, páginas de redes sociales pueden marcarse como útiles en esta sección.

Relevant

Los resultados relevantes son aquellos que contienen información útil para algunos usuarios; son páginas con algo menos de valor que las útiles. Estas páginas entran dentro de la consulta de búsqueda pero pueden ser difíciles de comprender, pueden estar desactualizadas, con una fuente poco reconocida o cubrir sólo una parte de lo que se consulta.

Estas páginas deben ser útiles para los usuarios aunque incluyan “otros temas”. Las páginas han de tener una buena calidad y, de media, son buenas páginas.

Slightly Relevant

Este punto de poca relevancia hay que marcarlo cuando la página no tiene mucha relevancia para la mayoría de los usuarios, pero sí para algunos. Estas páginas pueden tener una menor calidad o contenidos menos útiles; incluso pueden ser páginas que sirvan a una menor interpretación, tener información desactualizada, ser muy general…

Las versiones móviles de un sitio siempre han de marcarse como esta opción, ya que suelen ser versiones de páginas de escritorio.

En algunas ocasiones una página puede encajar en esta opción si tiene “buena pinta” con contenido mínimamente útil. En otros casos páginas que copian contenidos de otros sitios pueden considerarse en esta opción; también lo son aquellas páginas que tienen contenido útil pero que vienen de alguien sin autoridad. Incluso, algunas de estas páginas podrían llegar a macarse como spam.

No todas las páginas que copian pueden considerarse de baja calidad. Si la página está bien organizada y es de ayuda para los usuarios, y en este caso incluye poca cantidad de anuncios y parece estar creada para ayudar, puede considerarse de ayuda.

Off-Topic or Useless

Estas son aquellas páginas que no tienen nada que ver con la consulta de búsqueda o no son útiles para ningún usuario. Aquí podríamos incluir aquellas páginas en la que sólo hay publicidad pero el contenido es mínimo o inexistente. Si los enlaces conducen a páginas en las que sólo hay otros enlaces o anuncios también se deben considerar inútiles. Muchas de estas páginas incluyen elemento de spam.

Unratable

Son aquellas páginas que no es posible evaluar. Se pueden considerar de este tipo en base a dos posibilidades.

Unratable: Didn’t Load

El contenido no carga y suelen recibir algún tipo de mensaje de error desde el servidor. En este caso nos podemos encontrar páginas en blanco, que las redirecciones no funcionan, con avisos de “malware” o con errores de carga de certificados. En estos casos en los que hay avisos nos e debe marcar ni como spam ni como malware. Las páginas con códigos 401, 403, 404, 500 o 503 entran dentro de esta clasificación. En el caso de que la página cargue, aunque los enlaces en ella no funcionen, hay que valorar la página, no los enlaces.

En este caso hay que copiar o especificar el error que aparece en la página / servidor por el que no se puede validar la página.

Unratable: Foreign Language

Cuando el documento no está en ninguno de los idiomas aceptables hay que marcar esta opción. La única excepción es que el documento sea Vital.

Una vez revisadas todas las opciones posibles, hay que tener en cuenta que una de las bases a la hora de evaluar una página es la intención del usuario. Lo primero es relación la utilidad de la página con lo que el usuario quiere. Con esto valoraríamos de la forma que hemos visto. El siguiente punto es tener en cuenta la localización. En este caso siempre primará lo que el usuario haya introducido en el cajetín de búsqueda sobre la geolocalización que pueda dar el sistema. También hay que tener en cuenta que en muchas ocasiones la versión en inglés puede ser de gran ayuda en resultados en los que la calidad es baja o la página en general no tiene valor. De todas formas hay países en los que el inglés no es un idioma muy utilizado, por lo que en esos casos esta no será una opción. Otro detalle es que, por ejemplo, búsquedas técnicas sí que pueden serlo, al igual que otros idiomas pueden serlo para otros temas.

Los resultados de enciclopedias o de diccionarios en muchos casos pueden ser útiles, aunque hay otros casos en los que no lo son. Otras consultas pueden ir relacionadas con la búsqueda de listas de elementos. En estos casos los resultados de búsqueda o páginas con listados de elementos más concretos pueden ser una buena solución.

Otro tipo de consultas que podemos encontrar son aquellas que incluyen algún tipo de error ortográfico. Que sea incorrecta no significa que no pueda ser tratada de la misma forma que el resto. Aún así, hay que tener en cuenta que algunas búsquedas pueden haber sido forzadas a escribirse de forma incorrecta, no podemos dar por hecho nada. Una búsqueda como [my sapce] queda claramente marcado como Vital el sitio de [myspace.com].

Otro tipo de búsqueda son las búsquedas de URL. Normalmente este tipo de consultas llevan el nombre de una web, o un dominio, o una URL completa. En ocasiones hay direcciones que se plantean que no funcionan, son las llamadas “imperfect URL queries”. Esto significa que aunque se evalúa el contenido de la página, también hay que observar la dirección URL para ver si tiene relación con lo que el usuario consulta. En este caso se pueden dar resultados Vitales siempre y cuando la consulta coincida con el resultado. Aquí también podemos encontrar las búsquedas de tipo “sitio web”, que son aquellas en las que la intención principal del usuario hace referencia a un sitio web; por ejemplo [kayak], [ebay], [addicting games]… hay casos que aunque el sitio web corresponde con la consulta, la búsqueda es un tanto genérica, por lo que no se puede valorar como Vital.

Un factor más a tener en cuenta es la edad de la página que se está consultando. En este caso las páginas más antiguas o las más nuevas no tienen porqué ser mejores o peores, pero sí que habrá que valorar la información que incluyen según los valores anteriores. En el caso de que se trate de un evento podemos determinar si la edición anterior o siguiente es la mejor. Por ejemplo, si hay un evento anual y se realiza la búsqueda unos pocos meses después, la versión correcta es la pasada, pero si falta poco tiempo para el evento, la versión nueva es la mejor.

Cuando nos encontramos con páginas de resultados de búsqueda, hay que valorarlas como se haría el resto. El único detalle es que si el cajetín de búsqueda está vacío hay que marcarlo como Off-Topic or Useless.

El caso de los vídeos el sistema de calificación es similar. Para empezar hay que comprobar correctamente el idioma del mismo, y después revisar la utilidad del mismo… en el caso de canciones, bandas sonoras, películas o eventos que hablan de lo que se está buscando, pero no es lo que se está buscando, la calidad es nula.

Pero las consultas, además de las generales, pueden ir geolocalizadas, de forma que la forma de valorar los resultados puede variar dependiendo de una serie de casos.

La geolocalización puede darse porque el usuario incluya un dato geográfico en la consulta de búsqueda (una ciudad, un código postal…) o porque el propio Google tenga asignada una localización (ya sea por la configuración de Google, que el usuario puede adaptar, o por la geolocalización móvil, detectando el lugar desde el que se conecta).

A partir de este momento el “SEO tradicional” desaparecería ya que la valoración de utilidad de los documentos cambia completamente, ya que ha de hacerse desde el punto de vista de ese lugar, de gente que vive en ese sitio. Por norma general, las páginas locales, la de gente que vive cerca del lugar reciben una alta valoración. Si una empresa u organización tiene una edición local de su empresa/producto para ese lugar se convertiría en Appropriate Vital.

En una siguiente entrada hablaré de la parte de SPAM y de lo que se considera que se puede y no se puede hacer (spam, pornografía, códigos maliciosos…), además de temas que tienen que ver con la geolocalización (más en profundidad de lo que he comentado)… pero eso será en otra ocasión.

Google Quality Raters:

Historial de contenidos duplicados

En la red existen multitud de documentos a rastrear; los buscadores van reindexándolos y descubriendo los nuevos según van revisitándolos. Pero existe el problema de encontrar documentos duplicados ya sea completa o pacialmente. Además, hay documentos que cambian con mucha frecuencia. Incluso, puede ser que simplemente el documento vaya cambiando una parte del mismo (la publicidad, los enlaces recomendados o algún bloque aleatorio…), lo que podría implicar tener dicho documentos con sólo la variable parcial del mismo.

Otro problema que nos podemos encontrar es el de el rastreo sesgado. Esto suele pasar en los blogs, donde un mismo documento se encuentra en varios sitios pero en una de las páginas encontramos una versión del mismo y en otra parte encontramos una versión actualizada, lo que significa que el indexador se encuentra con las dos versiones del mismo documento, pero el sistema no identifica que son el mismo, con la diferencia de que uno se ha actualizado y el otro no, lo que genera que se marque como contenido duplicado.

Y como esto es algo que no gusta a los usuarios (y mucho menos a los propios buscadores), Google dispone de un sistema, Updating search engine document index based on calculated age of changed portions in a document, que corrige esta situación.

Por un lado tenemos que al recibir un documento, comparándolo con una versión anterior, podemos determinar que parte del documento permanece sin cambios y cuál no, lo que nos puede dar una forma de sacar la edad del fragmento del documento que no ha cambiado. Si esto lo hacemos histórico, podemos disponer de un historial de versiones del documento sabiendo qué parte es la inicial y generando un código único para identificar esta parte del contenido (checksum).

En este momento, cuando se rastrea un documento de nuevo se plantea que el sistema, en ese momento compare el documento nuevo rastreado con una versión que se dispone actualmente, y en base a esa zona parcial se tenga en cuenta si es igual o una versión actualizada. También se podría comparar el resto del documento para ver si ha variado en el tiempo o no. Con este sistema se recalculan los checksum y se determina la edad de cada parte y si ha variado en el tiempo, evitando así los contenidos duplicados.

Cuando se recibe un documento (630) se le asigna una edad (600). Este sistema analiza cualquier elemento dentro del documento (direcciones, meta-etiquetas, cabeceras, códigos de estado…) hasta determinar la edad del documento y de esta forma establecerla (640). Una vez determinado, tan sólo falta pasarlo por el identificador (610) y determinar si la información es nueva (650) o no lo es (660). En el caso de que sea información ya procesada anteriormente, se pasa por la calculadora de checksum (620) y se almacena para su posterior proceso. Otra opción sería la de realizar una lista de secuencias históricas (Longest Common Subsequence -LCS-) de las distintas partes de un documento en vez de extraer sólo lo que se considera la parte importante del mismo. En este caso se compara las edades de pequeñas partes del documento para comparar cada una de las edades de los bloques de forma histórica.

Como detalle, simplemente haciendo peticiones HEAD (y no GET) se podría llegar a determinar de forma parcial si es necesaria la reindexación de esos contenidos o no, con la consecuente reducción de ancho de banda para ambas partes.

El siguiente paso afecta a un sistema de rastreo que busque contenidos concretos (y no rastree sitios de forma general). En este caso este sistema sesgado lo que analizará será las distintas versiones del documento en base al checksum del mismo y determine si un contenido ha variado o no, además de encontrar contenidos duplicados por la similitud de dicho código. De la misma forma se pueden agrupar contenidos en cluster y analizarlos internamente.

El siguiente paso es el de encontrar los elementos duplicados si los hubiese. Para ello se pueden procesar dos fases, una primera que busca contenidos de forma interna y otra que busca contenidos en distintos sitios de la red. En este caso se usa el sistema de comparación de checksum para determinarlo.

La forma de determinar si un documento en concreto (por ejemplo, revisándolo al día siguiente) han cambiado o se ha mejorado sería esta. La idea es sacar la parte importante (el artículo o contenido en sí) del documento y generar un identificador. En la siguiente visita se volvería a extraer esa misma parte y se comprobaría si se mantiene, sin tener en cuenta, en este ejemplo, que la publicidad ha cambiado y por tanto no haría falta reindexarlo.

Y de la misma forma que se puede revisar un único documento, se pueden revisar documentos distintos.. en este caso analizaríamos un documento y se le asignaría unos fragmentos. Con el tiempo vemos que el documento ha cambiado, añadiendo una nueva parte… pero el identificador sigue siendo el mismo ya que el contenido principal permanece igual… en este caso, sí que podemos encontrar otros documentos que disponen del mismo identificador, por lo que esos documentos quedarían relegados a no ser indexados, a aparecer en el índice secundario o simplemente a no tenerse en cuenta.

Y aquí tenemos como resumen el proceso completo paso a paso…

Como conclusión podemos sacar que los documentos que se actualizan con frecuencia no son siempre aquellos que van actualizando su contenido de forma completa, por lo que no han de ser rastreados y actualizados con tanta frecuencia como parece. Además, al determinar las partes importantes de las páginas se genera un sistema antispam y de detección de contenidos duplicados que ayuda a reducir en gran cantidad el índice secundario (y primario) del buscador.

Formas de propagar la relevancia entre documentos

Es de muchos conocido el algoritmo del PageRank (Google), que básicamente lo que calcula es la relación entre documentos en base a la cantidad de enlaces que tienen entre ellos y, en base a esto, calcular el peso de la información a la hora de ofrecer resultados de búsqueda. Con esto se puede llegar a realizar una clasificación de todos los datos de la red de redes aún teniendo en cuenta que hay páginas sin enlaces, generando una imagen instantánea de la red.

Pero aunque este es el algoritmo más conocido, existen otros dos algoritmos igual de interesantes. Uno de ellos es HITS (Ask), que se basa en el principio de que si un documento enlaza a otros documentos importantes, ese documento es importante por sí mismo. Con esto se divide la importancia del peso no sólo en los enlaces sino en los llamados “hub” y “authority”. Un “hub” se mide en base a la “authority” que le supone el resto de “hub”, lo que supone una gran diferencia con respecto a PageRank que sólo tiene en cuenta los enlaces entrantes y salientes. Además, HITS puede modificar el valor de los “hub” en base a las visitas que tiene y en el CTR.

El último sistema que se ha tenido en cuenta hasta ahora es DirectHIT (Go), que se basa en el historial del usuario, en cómo ha navegado en el pasado para eliminar aquello que no le interesa y potenciar lo que sí le interesa. Si un usuario en anteriores visitas al realizar una consulta de búsqueda ha acabado pulsando en el tercer resultado, en las siguientes visitas se le potenciará dicho resultado, haciendo subir los siguientes y bajando los anteriores para seguir probando.

La mayor parte de estos sistemas utilizan unos algoritmos de aprendizaje para aprender formas de entrenar la información que se incluye en las consultas de búsqueda. Esto acaba generando un ranking propio de los documentos que, a su vez hay que incorporar a los algoritmos anteriores para acabar generando unos resultados de calidad. Estos sistemas acaban usando las funciones de ranking de búsquedas, las funcionalidades y la relevancia y entrenamiento obtenido en base a las capacidades de los usuarios.

Y aquí es donde entra Microsoft (principalmente su equipo de China) en el que se ha buscado un sistema para ayudar a calcular los pesos de documentos que no tienen todavía relevancia pero que deberían tenerla, según se explica en Training a ranking function using propagated document relevance.

A method and system for propagating the relevance of labeled documents to a query to the relevance of unlabeled documents is provided. The propagation system provides training data that includes queries, documents labeled with their relevance to the queries, and unlabeled documents. The propagation system then calculates the similarity between pairs of documents in the training data. The propagation system then propagates the relevance of the labeled documents to similar, but unlabeled, documents. The propagation system may iteratively propagate labels of the documents until the labels converge on a solution. The training data with the propagated relevances can then be used to train a ranking function.

Pero ¿cómo se puede dar peso a un documento que aparentemente es nuevo? Pues básicamente por las similitudes con otros documentos anteriormente validados y con su peso asignado; es decir, que si un documento se parece a otro que aparece bien posicionado (sin ser contenido duplicado) se tiene en cuenta y se le asigna un valor pre establecido similar al anterior para poder entrar en el “círculo vicioso” de alguno de los algoritmos anteriores (principalmente en una fase semilla el de DirectHIT).

Aunque este sistema está desarrollado por Microsoft recuerda mucho a lo que en muchas ocasiones hemos visto en Google, que un sitio, al poco de ser lanzado se pone en los primeros puestos y al cabo de unas semanas “empieza a desaparecer”. Este sistema equivaldría a esas pruebas en la que, si el contenido es de calidad se mantiene durante más tiempo primando más la forma que tiene el usuario de navegar y de leer dicha información sobre el algoritmo primario de PageRank que se basa más en la “antigüedad” y la cantidad de enlaces.

Una vez se ha realizado la primera fase de buscar documentos similares para darles valor hay que propagarlos y aplicar el sistema de ranking. El objetivo es generar unos resultados que sean similares pero no idénticos, como podría ser el Sequential Minimal Optimization de John Platt. En este punto comenzaríamos el proceso para regenerar el grafo y añadir los nuevos documentos que se han rastreado mientras se prueban los que aparecen en los resultados de búsqueda.

¿Afecta Google Analytics al SEO?

Seguro que alguna vez te has preguntado ¿afectará poner Google Analytics al SEO de mi sitio? Pues ahora tenemos la respuesta oficial, y es que Google ha conseguido una patente que permite reorganizar los resultados de búsqueda parcialmente dependiendo de las estadísticas… es decir, que si Google quiere, puede. Y es que ha conseguido la Methods and apparatus for employing usage statistics in document retrieval en la que se mejoran los resultados de búsqueda dependiendo, total o parcialmente, de las estadísticas de uso.

Systems and methods consistent with the present invention address this and other needs by identifying compounds based on the overall context of a user query. One aspect of the present invention is directed to a method of organizing a set of documents by receiving a search query and identifying a plurality of documents responsive to the search query. Each identified document is assigned a score based on usage information, and the documents are organized based on the assigned scores.

Internet es muy grande, y como crece también a una velocidad vertiginosa, hay que buscar nuevos métodos para elegir qué contenidos se rastrean e indexan antes que el resto. Los usuarios navegan normalmente siguiendo un grafo determinado, partiendo habitualmente de sitios de alta calidad o de motores de búsqueda. Lo bueno y lo malo de esto es que los sitios que son gestionados por humanos son difíciles de gestionar y mantener, por lo que los buscadores han de determinar de muchas maneras cuál es la relevancia correcta de estos sitios web.

Y es que la forma habitual de determinar la relevancia de un sitio es encontrando un matching entre los términos de búsqueda y el contenido de las propias páginas, además de la estructura y enlaces internos y externos del sitio. Pero estos sistemas son fácilmente manipulables por los diseñadores de sitios web, además que las páginas nuevas reciben menos enlaces que las viejas, por lo que el sistema de pesos de los enlaces también queda obsoleto.

Una consulta de búsqueda puede ser de texto, audio, vídeo o información gráfica. El buscador detecta la lista de documentos que son relevantes para esa consulta de búsqueda. La forma de identificar los documentos depende de muchos factores (como he comentado antes, los del SEO histórico), a los que habría que agregar el de uso de dicho documento, ya sea de forma total o parcial. Esto podría ser en valores absolutos o relativos al resto de documentos. La información se podría almacenar en el propio sistema de búsqueda como en sistema externos accesibles.

The usage information comprises both unique visitor information and frequency of visit information. The usage information may be maintained at client and transmitted to search engine. The location of the usage information is not critical, however, and it could also be maintained in other ways. For example, the usage information may be maintained at servers, which forward the information to search engine; or the usage information may be maintained at server if it provides access to the documents (e.g., as a web proxy).

Una vez se ha aplicado este “filtrado” y organización, los resultados se reordenan según su puntuación, ya sea de forma única por estadísticas o unido a otros factores (lo más probable). La puntuación sobre el uso del documento vendría a ser la frecuencia de la visita multiplicado por los usuarios únicos multiplicado por la navegación.

Para determinar todo este sistema se ha de tener en cuenta la información recogida directamente sobre los números absolutos o relativos de la frecuencia de visita de un documento. En este caso el RAW representaría la cantidad de veces que se ha visitado el documento, o las visitas que ha tenido en un tiempo determinado, o el cambio del número de veces que se ha visitado en un periodo de tiempo… Una vez tenemos esta información debemos filtrarla y procesar para sacar una muestra significa que sea la que realmente os aporte, eliminando “basura” de la información completa. Con toda esta información que tenemos ahora podemos sacar el peso real de la acción. Con este tipo de filtrados podríamos sacar la información según una geolocalización, el navegador, el usuario… dando más peso a las visitas de un país, idioma o cualquier otra cosa según convenga al documento o al sistema de ordenación de la “edición” del propio buscador. Es decir, si buscas en google.es las visitas de España a ese documento tendrían más peso que las visitas de Rusia.

Y si antes se tenía en cuenta la frecuencia de las visitas a un documento, ahora se tienen en cuenta los propios usuarios. El funcionamiento sería exactamente el mismo que en el punto anterior, aunque aquí en vez de frecuencia tenemos usuarios. Eso sí, aquí se eliminarían los robots de búsqueda, afiliaciones, etc… cualquier cosa que elimine valor real a los datos. Aún así, volveríamos a tener datos de peso de habitantes de un lugar o de otro, si el usuario viene de una navegación de “favoritos”, tráfico directo, de referencia, etc…

Y para acabar, un ejemplo relacionado con “el tiempo”. Un documento ha sido mostrado 40 veces en el último mes, 15 visitas de ellas por sistemas automáticos. En el segundo caso 30 visitas en el último mes, 10 de ellas desde Alemania. El último documento, enlazado desde los otros dos documentos, se ha mostrado 4 veces en el último mes. Según esto, tenemos que el primer documento tiene 3 veces la palabra “weather”, el siguiente 2 veces y el último 1 vez.

Si siguiéramos el sistema de ordenación tradicional, el que ordena según el número de enlaces, los documentos se ordenarían 3º (2 enlaces entrantes), 2º (1 enlace entrante) y 1º (sin enlaces entrantes). Pero siguiendo el sistema nuevo que utiliza datos de uso (en este caso sin filtrar) tendríamos: el 1º (tiene 40 visitas), el 2º (tiene 30 visitas) y el 3º (tiene 4 visitas). Pero si aplicásemos un sistema de filtrado en el que se eliminan los robots y se da el doble de peso a los usuarios de Alemania, tendríamos una ordenación tal que: 2º (40 visitas, 10 de Alemania que cuentan doble), 1º (25 visitas, eliminando las 15 de robots) y 3º (4 visitas).

Sin duda el planteamiento y las posibilidades son enormes ya que tiene cierta lógica dar peso a páginas que ya tienen muchas visitas, pero eso también implicaría que sólo los sitios con mucho tráfico aparecieran en los primeros puestos de búsquedas, algo que degradaría de forma automática a aquellos nuevos sitios que aparecen en la red de redes.

Respuestas a consultas de búsqueda

Hace ya muchos años que los buscadores son capaces de responder a preguntas, normalmente elementos sencillos que facilitan lo que el usuario está buscando. Y es por eso que Microsoft se ha hecho con Presenting instant answers to internet queries que básicamente, como su nombre indica, se queda con los llamados “onebox” de respuesta directa.

El sistema es sencillo… el usuario realiza una consulta de búsqueda y, dependiendo de lo que se esté buscando (mediante palabras clave o combinaciones) se devuelve el resultado directamente.

One or more computer-storage media having computer-executable instructions embodied thereon for performing a method of providing a response to a query request, the method comprising: receiving the query request that includes query terms from a requester, wherein the requester is not registered to receive the response; referencing data submitted by a user authorized to submit the data, which data include potential responses to the query request, such that the data include the following modules that have been validated as valid modules that are in a file format compatible with a format of a type selected from Extensible Markup Language (XML), Comma Separated Values (CSV), and Tab Delimited, (1) a data module that includes information to be used to provide a potential response to a given search query, wherein the potential response includes a subject, a term and a term value, (2) a feed-mapping module that provides a translation for the information of the data module to be interpreted regardless of the formatting of the information, (3) a display-mapping module that provides a preferred presentation style for the potential response, and (4) a query-matching module that includes at least one trigger phrase associated with the potential response, such that the trigger phrase initiates the potential response; identifying the potential response based on a pattern match between the query terms and the query-matching module, wherein the information of the identified potential response is extracted utilizing the feed-mapping module; and presenting the extracted information to the requester such that the extracted information is presented according to the display-mapping module.

El Libro de las Almas

Hace un par de semanas os comentaba que me había acabado de leer La Biblioteca de los Muertos, y que me había pedido la continuación de ese libro, El Libro de las Almas. Pues bien, no ha durado ni 10 días entre mis manos que ya me lo he fundido.

Si la anterior entrega estaba bien, esta casi que me ha gustado más. Se supone que se puede leer sin necesidad de haber leído el anterior, pero, la verdad, hay que leer el anterior para comprender al 100% el porqué los personajes son como son y hacen lo que hacen.

La historia continúa donde se quedó el libro anterior… un tiempo después, eso sí, pero con la misma filosofía temporal de ir cruzando varias historias en distintos puntos de la historia. Los protagonistas son los mismos y la historia continúa. Básicamente ahora uno de los libros de la Biblioteca aparece por el mundo en una subasta y se quiere saber cómo ha llegado hasta ahí. Así que básicamente es la historia de lo que le ha pasado al libro desde su redacción hasta su adquisición.

Así que nada, la última vez os recomendé el libro y ahora os recomiendo la continuación que, como digo, casi me ha gustado más que el anterior.

Tras la WordCamp Sevilla 2011

Como ya sabéis muchos de vosotros este fin de semana he estado en la WordCamp Sevilla 2011. Las WordCamp son los eventos oficiales de WordPress en los que suele ir gente de Automattic, la empresa que hay detrás de este grandísimo software, además de usuarios y desarrolladores de la plataforma.

Durante el fin de semana estuve dando un par de charlas, una sobre Google Panda y WordPress, en la que comenté como reducir la cantidad de URL que genera WordPress perdiendo el mínimo tráfico posible, y sabiendo que en la nueva versión el propio sistema, a sabiendas de esto, va a incorporar mejoras de forma automática para que no afecte negativamente. La otra charla, de un nivel técnico más elevado, trató sobre WordPress Performance Optimization, comentando dos temas principales: la infraestructura para montar algo que soporte cientos de miles de visitas diarias y otra parte con plugins (y más sencillo de implementar) que ayuden a mejorar el rendimiento y la seguridad de la plataforma.

El evento fue durante dos días (sábado y domingo) el primer día dedicado más a aquellos que utilizan la plataforma y el segundo a los que administran o desarrollan sobre la plataforma. ¿Cosas que he aprendido? Pues el tema de los Child Themes, algo bastante sencillo que se aplicó hace poco, pero, como me he dedicado más desde WordPress 3 al rendimiento que al desarrollo de temas se me había pasado. A parte de eso, la seguridad, ataques y demás que cada vez hay más, mantener pocos plugins y bien testeados y que todo lo que se desarrolle sea internacionalizable.

Una de las cosas que comenté en mi presentación fue sobre la desaparición de MyISAM en las futuras versiones de MySQL, concretamente (por las últimas noticias que tengo) a partir de la versión 5.6 ya sólo vendrá INNOdb, algo que considero muy razonable, ya que las bases de datos deben ser relacionales. Esto implica un cambio de paradigma en WordPress donde las tablas no están relacionadas. Como experiencia personal, INNOdb aún no soporta FullTEXT (parece que la siguiente versión lo hará) por lo que se puede migrar de MyISAM a INNOdb teniendo en cuenta esta pérdida. Este sitio ya tiene aplicado este tipo de base de datos y lo cierto es que mejora ciertamente el rendimiento y al estar relacionada evita ciertas cagadas a la hora de eliminar contenidos.

Como último detalle para futuras WordCamp en España propondría a los organizadores tener alguna sala para hacer talleres de 2-3 horas, muy en plan práctico. Me parece genial meter charlas de media hora que son muy dinámicas pero, creo, que eso evita poder enseñar muchas cosas con código interesantes para que la gente pueda aplicarlo. Hacer un taller de 3 horas (montar un WordPress desde cero y configurarlo, plugins esenciales y configuración, escalar WordPress, creación de Child Themes…) podría estar bien para aquellos que tiene un nivel muy muy bajo o muy muy alto de la plataforma, aunque fuera pagando un extra de algunos euros para subvencionar los ponentes (que no es lo mismo dar una charla de media hora que hacer unos talleres).

Algunos ya sabréis que a finales de noviembre está previsto que se organice una WordCamp en Madrid, así que, si no falla nada, por allí nos veremos.

WordPressformance Optimization #WordCampSev 2011

Ayer ya di la charla de Google Panda y WordPress y hoy ha tocado la charla de WordPress Performance Optimization, que he reducido a WordPressformance.

La charla de hoy ha tratado de cómo montar una infraestructura más organizada en sitio que necesitan alto rendimiento, ya que está claro que montar un WordPress en la misma máquina el Apache, SQL y PHP pues como que no es lo mejor…

Así que nada, aquí os dejo la presentación en PDF para los que queráis descargarla.

WordPress y Google Panda #WordCampSev 2011

Entre hoy y mañana se está celebrando el WordCamp Sevilla 2011 y voy a dar 2 charlas… la primera de ellas se llama WordPress y Google Panda y, como ya podéis supones habla de la relación que hay entre el nuevo algoritmo Google Panda y WordPress (.org).

Os dejo la presentación descargable en PDF.

Como comentario a destacar (que he de analizar en una versión de pruebas que tengo) es que me han comentado que WordPress 3.3 incluirá grandes mejoras en cuanto a qué indexa y que no indexan los buscadores en determinadas URL de WordPress. Habrá que verlo y en base a eso analizar hacia dónde va el SEO de WordPress.