Más allá de PageRank: el camino hacia métricas prácticas

Al igual que cualquier ciberciudadano con curiosidad, tengo Google alert configurado para que me envíe un correo electrónico cada vez que mi nombre se mencione online. Por lo general, recibo un lento goteo debido a mis entradas en el foro, entradas en el blog y tweets. Pero sin duda y con distancia, el tema más popular de estas alertas durante los dos últimos años ha sido mi mención, un tanto despreocupada, de que habíamos eliminado los datos de distribución de PageRank de las Herramientas para webmasters de Google [inglés] en una de nuestras versiones de 2009.

El hecho de que haya gente que, dos años después, siga escribiendo sobre ello (generalmente con algo así como "Noticias sorprendentes de Susan Moskwa:..."), realmente demuestra hasta qué punto se ha convertido PageRank en una estadística decisiva para algunos webmasters. Incluso los propietarios de sitios menos experimentados con quienes he podido hablar a menudo, han oído hablar sobre y quieren conocer más sobre PageRank ("PR") y lo que significa para su sitio. No obstante, tal como dije en mi fatídica entrada de foro, el equipo del Blog Webmasters Central lleva años insistiendo en que los webmasters no deben centrarse demasiado en PageRank como métrica para representar el éxito de su sitio web. Hoy querría explicar esta posición más detalladamente y ofrecer algunas opciones relevantes y utilizables con las que ocupar vuestro tiempo en cuanto dejéis de realizar el seguimiento de vuestro PR.

¿Por qué PageRank?
En 2008, Udi Manber, VP de ingeniería de Google, escribió en el Blog oficial de Google [inglés]:
"La parte más famosa de nuestro algoritmo de clasificación es el PageRank, un algoritmo desarrollado por Larry Page y Sergey Brin, fundadores de Google. Hoy en día todavía se usa PageRank, pero ahora forma parte de un sistema mucho mayor".
PageRank pudo ser un rasgo diferencial de Google como motor de búsqueda cuando se fundó en 1998, pero teniendo en cuenta el ritmo de cambios descrito por Manber (lanzando alrededor de 9 mejoras por semana en promedio), hemos tenido una oportunidad notable de aumentar y refinar nuestros sistemas de clasificación a lo largo de la última década. PageRank ya no es (si es que alguna vez lo fue) la esencia y el fin de la clasificación.

Dando un vistazo a la información general sobre la tecnología de Google, se aprecia que uno de los ingredientes más importantes de los resultados de las búsquedas es la relevancia. Entonces, ¿por qué no se ha gastado tanta tinta en describir la importancia de la relevancia como en describir la de PageRank? Creo que se debe a que PageRank es un número, mientras que la relevancia no lo es. Ambos, la relevancia y PageRank, incluyen una gran cantidad de factores complejos (contexto, intención del usuario que busca, popularidad, fiabilidad), pero mientras que resulta fácil representar la evolución del PageRank a lo largo del tiempo y presentarla al director general en cinco minutos, no resulta tan fácil hacerlo con la relevancia. Considero que la concreción de PageRank es el motivo de que se haya convertido en una métrica decisiva de semejante importancia a lo largo de los años. Pero solo porque algo sea fácil de seguir, no por ello significa que represente con precisión lo que sucede en un sitio web.

¿Qué queremos realmente?
Mi propuesta es que ninguno de nosotros se preocupe realmente de PageRank como objetivo final. PageRank es solo un sustituto de lo que queremos lograr para que nuestros sitios web tengan mayores ingresos, atraigan a más lectores, generen más consultas de compradores potenciales, consigan más registros en boletines, etc. Centrarse en PageRank como métrica del éxito logrado solo funciona si asumimos que cuanto mayor es PageRank mayor es la clasificación, que con ello se conseguirá atraer más tráfico hacia el sitio web y que eso hará que haya más gente haciendo-lo-que-sea-que-queremos-que-haga en un sitio web. Por encima de estos supuestos, recordemos que el PageRank que se muestra en la Barra de Google se actualiza unas cuantas veces al año y que podemos reducir el PageRank que se muestra en algunos sitios si creemos que se dedican a prácticas de spam. Así que el PR que se ve públicamente es distinto del que utiliza el algoritmo realmente para la clasificación. Entonces... ¿por qué preocuparse por un número que se aleja tres pasos de tu objetivo actual, cuando puedes medir directamente lo que deseas alcanzar? Encontrar métricas directamente relacionadas con los objetivos de un negocio permite centrarse en mejorar estos objetivos.

Si no realizo un seguimiento de PageRank, ¿de qué debería hacerlo?
Mirad las métricas que se correspondan directamente con ganancias relevantes para vuestro sitio web o vuestro negocio en lugar de centraros solamente en los indicadores de clasificación. Consideremos también las métricas que se actualizan a diario o semanalmente en lugar de números (como PageRank) que sólo se actualizan unas cuantas veces al año. Estas últimas métricas son demasiado lentas como para aclarar qué cambios pueden haber influido en que una cifra suba o baje (suponiendo que la actualización de un sitio se haga con mayor frecuencia que unas cuantas veces al año). Aquí tenéis tres sugerencias para comenzar. De todas ellas se puede realizar el seguimiento mediante servicios como Google Analytics o las Herramientas para webmasters de Google.

  1. Indice de conversión
  2. Porcentaje de rebote
  3. Porcentaje de clics (CTR)

Indice de conversión
Una "conversión" se produce cuando un visitante hace lo que se desea que haga en un sitio web. Una conversión puede consistir en completar una compra, registrarse para recibir un boletín electrónico o descargar un artículo sobre un tema. El índice de conversión es el porcentaje de visitantes a un sitio que se convierten (completan una conversión). Es el ejemplo perfecto de una métrica que, a diferencia de PageRank, está directamente relacionada con los objetivos de un negocio. Cuando los usuarios completan una conversión, hacen algo que beneficia directamente a una organización de forma medible. En cambio, el PageRank es a la vez difícil de medir con precisión (según se explicaba anteriormente) y está expuesto a subidas o bajadas sin que ello implique un efecto directo sobre un negocio.

Porcentaje de rebote
Un "rebote" sucede cuando alguien visita un sitio web y, a continuación, se va sin visitar ninguna otra página del sitio. El porcentaje de rebote es el porcentaje de visitas a un sitio en que el visitante rebota. Un porcentaje de rebote puede indicar que los usuarios opinan que el sitio no es atractivo, porque llegan, echan un vistazo y se van directamente. Analizar los porcentajes de rebote de las distintas páginas de un sitio puede ayudar a identificar el contenido cuyo rendimiento no está a la altura y a señalar qué zonas de un sitio necesitan un trabajo adicional. Después de todo, no importa cuán elevada sea la clasificación de un sitio, si la mayoría de los usuarios se van nada más llegar.

Porcentaje de clics (CTR)
En el contexto de resultados de búsquedas orgánicas, el porcentaje de clics mide cuán a menudo los usuarios hacen clic en un sitio en relación con las veces que el sitio aparece en los resultados de búsquedas. Un CTR bajo significa que, por muy elevada que sea la clasificación, los usuarios no están haciendo clic en el sitio. Esto puede indicar que no creen que el sitio pueda cubrir sus necesidades, o que hay algún otro sitio que tiene mejor aspecto. Una forma de mejorar el CTR es observar los títulos y los fragmentos del sitio que aparecen en los resultados de búsqueda: ¿resultan atractivos? ¿representan con precisión el contenido de cada URL? ¿ofrecen a los usuarios que buscan una razón para hacer clic en cada página? A continuación se indican algunos consejos para mejorar los fragmentos. La sección de Sugerencias en HTML de las Herramientas para webmasters de Google también puede señalar qué páginas necesitan atención. Una vez más, recordemos que no importa cuán elevada sea la clasificación de un sitio si los usuarios que lo buscan no quieren hacer clic en él.

Se han dedicado blogs y libros enteros a explicar y explorar las métricas web, así que me excusadme que estas explicaciones sean sólo superficiales. El sitio del evangelista de la analítica web Avinash Kaushik [inglés] es un lugar excelente por donde comenzar para todos aquellos que quieran profundizar en estos temas. Pero espero haberos convencido por lo menos de que existen formas más directas, eficientes y controlables de medir el éxito de un sitio aparte de PageRank.

Una nota final: algunos propietarios de sitios están interesados en el PR de su sitio porque la gente no comprará enlaces en su sitio a menos que el PageRank sea elevado. Comprar o vender enlaces con el fin de pasar PageRank infringe nuestras Directrices para webmasters y lo más probable es que tenga consecuencias negativas para un sitio web. Es por ello que a) lo desaconsejo por completo, y b) no os sorprenda que no estemos interesados en ayudaros a aumentar el PageRank de vuestro sitio si éste es vuestro objetivo declarado.

Estaremos encantados de oír qué métricas os resultan útiles y prácticas para vuestro sitio web. Os invitamos a compartir historias de éxito con nosotros con vuestros comentarios aquí o en el Foro de ayuda para webmasters.

viernes, 29 de julio de 2011

Soporte para rel="canonical" en las cabeceras HTTP

Partiendo de vuestros comentarios, nos satisface anunciar que, ahora, la búsqueda web de Google utiliza las relaciones establecidas por el enlace rel="canonical" especificadas en las cabeceras HTTP conforme a la sintaxis descrita en la sección 5 de la IETF RFC 5988 [inglés]. Los webmasters pueden usar las cabeceras HTTP rel="canonical" para indicar la URL canónica tanto para documentos HTML como para otros tipos de contenido como los archivos PDF.

Para ver la cabecera HTTP rel="canonical" en acción, imaginemos la situación de un sitio web que ofrece un artículo en forma de página HTML y de archivo PDF para descargar como alternativa, en estas dos URL:

  • http://www.example.com/white-paper.html
  • http://www.example.com/white-paper.pdf

En este caso, el webmaster puede indicar a Google que la URL canónica para el PDF para descargar es el documento HTML, usando la cabecera HTTP rel="canonical" al solicitar el archivo PDF. Por ejemplo:

GET /white-paper.pdf HTTP/1.1
Host: www.example.com
(... resto de peticiones de cabeceras HTTP...)

HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <http://www.example.com/white-paper.html>; rel="canonical"
Content-Length: 785710
(... resto de respuestas de cabeceras HTTP...)

Otra situación frecuente en que las cabeceras HTTP rel="canonical" pueden ser útiles, es el caso en que un sitio web sirve un mismo archivo desde distintas URL (por ejemplo, al usar una red de distribución de contenido) y el webmaster desea indicar a Google cuál es la URL preferida.

Google admite actualmente estos elementos de enlace en cabeceras únicamente para la búsqueda web de Google. Cuando veamos cómo usan los webmasters estos elementos, esperamos añadir más funciones relacionadas con ellos en nuestras productos. Podéis encontrar más información en los artículos de nuestro Centro de asistencia sobre canonicalización y el elemento rel="canonical". Si tienes más preguntas, no dudes en preguntar en nuestro Foro de ayuda para webmasters.

jueves, 21 de julio de 2011

Nuevas Instant Pages

Las nuevas Instant Pages [inglés] es una nueva función destinada a ayudar a los usuarios a encontrar resultados para sus búsquedas aún más de prisa. En algunos casos, incluso al instante. La funcionalidad de Instant Pages se basa en la tecnología de previsualización que estamos integrando en Chrome. La búsqueda web de Google la pone en marcha cuando estamos muy seguros de qué resultados son la mejor respuesta a la búsqueda del usuario.

Esta tecnología de previsualización se encontraba en Chrome Dev Channel y pasó rápidamente a estar en versión beta.

Puedes ver Instant Pages en acción en este vídeo:


En Google estamos obsesionados por la velocidad. Hemos visto una y otra vez cómo el aumento de la velocidad aparente se plasma directamente en el aumento de la satisfacción y de la implicación del usuario [inglés]. Instant Pages ayuda a los visitantes a llegar a tu sitio más rápidamente. Al poner en marcha Instant Pages para tu sitio web, los usuarios pueden comenzar a interactuar con tu sitio casi de forma inmediata, sin tener que esperar a que se carguen el texto y las imágenes. Sólo ponemos en marcha Instant Pages cuando estamos muy seguros de que tu sitio es el resultado exacto que los usuarios están buscando. El tráfico de búsqueda se medirá en las Herramientas para webmasters de Google exactamente igual que antes de introducir esta característica, de modo que sólo contarán los resultados en que el usuario haya visitado realmente el sitio. Este verano dedicaremos un tiempo a recoger vuestras opiniones antes de introducir esta característica en las versiones estables de Chrome.

La inmensa mayoría de sitios funcionarán correctamente al ser previsualizadas en Chrome. Si quieres más información sobre cómo funciona la previsualización en Chrome o sobre cómo puedes detectar que tu sitio se previsualiza, consulta la entrada sobre previsualización en el blog Chromium [inglés].

jueves, 14 de julio de 2011

Informes de Google +1 en las Herramientas para webmasters de Google y Google Analytics

Han sido unas semanas muy agitadas en Googleplex con los lanzamientos de los botones +1 para los sitios de búsqueda de Google en todo el mundo y el comienzo del proyecto Google+ [inglés].

Tanto el botón +1 como el proyecto Google+ tienen que ver con el hecho de facilitar la conexión con la gente en la que confías online. El botón +1 aporta las recomendaciones de amigos y contactos de confianza directamente a la búsqueda de Google, permitiendo a los usuarios que adoran el contenido de tu sitio web recomendarlo en el momento que lo tienen delante.

Pero cuando estás al cargo de la gestión de un sitio web, por lo general esto no se hace realidad hasta que puedes medirlo. Así que estamos satisfechos de decir que tenemos algo más que lanzar: los informes que muestran el valor de los botones +1 para tu sitio web.

En primer lugar, las métricas de +1 disponibles en las Herramientas para webmasters de Google te pueden mostrar cómo afecta el botón +1 al tráfico que llega a tus páginas.


  • El informe de impacto sobre la búsqueda te da una idea de cómo afectan los +1 al tráfico procedente de las búsquedas orgánicas. Puedes averiguar si tu tasa de accesos cambia al usar recomendaciones personalizadas para ayudar a destacar tu contenido. Para ello, puedes comparar los clics y las impresiones en los resultados de las búsquedas con y sin anotaciones +1. Sólo mostraremos estadísticas sobre variaciones en la tasa de acceso cuando haya impresiones suficientes como para realizar una comparación significativa.
  • El informe de actividad muestra cuántas veces se ha hecho +1 en tus páginas, desde botones situados en tu sitio web y en otras páginas (como en la búsqueda de Google).
  • Finalmente, el informe de audiencia muestra datos agregados geográficos y demográficos sobre los usuarios de Google que han hecho +1 en tus páginas. Para proteger la privacidad, sólo damos información sobre audiencia cuando hay un número significativo de usuarios que han hecho +1 en páginas de tu sitio.

El menú Métricas +1 del lado izquierdo de la página te permite acceder a estos informes. Si todavía no has verificado tu sitio web en las Herramientas para webmasters de Google, puedes seguir estas instrucciones para acceder.

Finalmente, también puedes ver cómo comparten los usuarios tu contenido usando otros botones aparte del botón +1, usando el seguimiento del Social Plug-in en Google Analytics [inglés]. Una vez configurado JavaScript para Analytics, el informe de implicación social te ayudará a comparar los distintos tipos de acciones de compartición que se producen en tus páginas.


  • El informe de implicación social te permite saber cómo cambia el comportamiento de tu sitio debido a las visitas que incluyen clics en botones +1 u otras acciones de tipo social. Esto te permite, por ejemplo, determinar si la gente que hace +1 en tus páginas durante una visita pasa más tiempo en tu sitio que la gente que no lo hace.
  • El informe de acciones sociales te permite realizar un seguimiento del número de acciones sociales (clics en +1, tweets, etc.) realizadas en tu sitio, todo desde un mismo lugar.
  • El informe de páginas sociales te permite comparar las páginas de tu sitio para ver cuáles impulsan el mayor número de acciones de tipo social.

Si usas la versión predeterminada del código más reciente de seguimiento de Google Analytics, al añadir botones +1 a tu sitio [inglés] automáticamente activamos el seguimiento del Social Plug-in para botones +1 en tu cuenta. Puedes habilitar el seguimiento de otros plug-ins [inglés] de carácter social en tan sólo unos simples pasos.

Los informes de actividad social son sólo el principio. A medida que la gente encuentra nuevas formas de interacción en la web, buscamos nuevos tipos de informes que ayuden a los propietarios de los negocios a entender el valor que las acciones sociales tienen sobre su actividad de negocio. Así que, ya sabéis: ¡+1 de utilidad para vuestros datos!

martes, 12 de julio de 2011

Seguridad en sitios web para webmasters

A los usuarios se les enseña a protegerse de programas maliciosos mediante la instalación de programas antivirus sofisticados pero, a veces, también confían sus datos personales a sitios web como el tuyo, en cuyo caso es importante proteger sus datos. Proteger tus propios datos también es importante. Si tienes una tienda online, no querrás que te roben.

A lo largo de los años, las empresas y los webmasters han aprendido (a menudo por las malas) que la seguridad de las aplicaciones web no es ninguna broma. Hemos visto fugas de contraseñas debidas a ataques de Inyección SQL, robo de cookies con XSS y sitios web vulnerados por hackers debido a negligencias en la validación de los datos de entrada.

Hoy os mostraremos algunos ejemplos de cómo se puede atacar una aplicación web, para que puedas aprender de ello. Con este fin, usaremos Gruyere, una aplicación intencionadamente vulnerable que también usamos internamente para formación sobre seguridad. No pruebes la vulnerabilidad de los sitios web de otras personas sin su permiso, puesto que podría considerarse un ataque (hacking), pero te damos la bienvenida (e incluso te animamos) a hacer pruebas en Gruyere.

Manipulación del estado del cliente (Client State): ¿qué sucede si altero la URL?

Imaginemos que tienes un sitio de alojamiento de imágenes y que usas una secuencia de comandos en PHP para mostrar las imágenes subidas por los usuarios.

http://www.example.com/showimage.php?imgloc=/garyillyes/kitten.jpg

Pues bien, ¿qué sucederá si cambio la URL por algo así y userpasswords.txt es un archivo de verdad?

http://www.example.com/showimage.php?imgloc=/../../userpasswords.txt

¿Obtendré el contenido de userpasswords.txt?

Otro ejemplo de manipulación de estado del cliente se produce cuando no se validan los campos de los formularios. Por ejemplo, imaginemos que tienes este formulario:



Parece que el nombre de usuario del remitente se almacena en un campo oculto. Bueno, ¡esto es genial! ¿Significa que si cambio el valor de ese campo por el de otro nombre de usuario puedo enviar el formulario como si fuese ese otro usuario? Bien podría suceder. Aparentemente, los datos introducidos por el usuario no se autentican con, por ejemplo, ningún token que se pueda verificar en el servidor.
Imagina la situación si ese formulario formase parte de un carrito de la compra y modificásemos el precio de un artículo de 1000 USD por 1 USD para, después, enviar el pedido.

Proteger tu aplicación frente a este tipo de ataques no es fácil. Echa un vistazo a la tercera parte de Gruyere [inglés] para ver algunos consejos sobre cómo defender tu aplicación.

Cross-site scripting (XSS): los datos introducidos por el usuario no son de fiar


Una URL simple e inofensiva:
http://google-gruyere.appspot.com/611788451095/%3Cscript%3Ealert('0wn3d')%3C/script%3E
¿Es realmente inofensiva? Si descodificamos los caracteres codificados con el signo de porcentaje, obtenemos:

<script>alert('0wn3d')</script>

Al igual que muchos sitios web con páginas de error personalizadas, Gruyere está diseñada para incluir el componente de la ruta dentro de la página HTML. Esto puede generar problemas de seguridad, como XSS, puesto que introduce el código introducido por el usuario tal como está en la página HTML de la aplicación web. Podríamos pensar, "bueno, es solo un cuadro de advertencia, ¿y qué?". El problema es que si puedes inyectar un cuadro de advertencia, puedes, con toda probabilidad, inyectar otra cosa, también, y tal vez aprovechar para robarte las cookies y usarlas para acceder a tu sitio como si fueses tú.

Otro ejemplo es cuando no se limpian las entradas del usuario. Imaginemos que escribo un comentario en tu blog. Se trata de un comentario muy simple:

<a href=”javascript:alert(‘0wn3d’)”>Click here tos see a kitten</a>

Si otros usuarios hacen clic en mi inocente enlace, tendré sus cookies:



Puedes ver cómo resolver las vulnerabilidades por XSS en tu propia aplicación web e intentar resolverlas en la segunda parte de Gruyere [inglés] o, si eres un desarrollador avanzado, mirar las características sobre escapado automático en sistemas con plantillas de la que hablamos en nuestro blog sobre seguridad online [inglés].

Falsificación de petición en sitios cruzados (XSRF): ¿debería aceptar las solicitudes procedentes de diablos.com?

Oh, vaya, una imagen rota. No puede ser peligrosa: está rota, al fin y al cabo, lo cual significa que la URL de la imagen devuelve un código 404 o tiene un formato incorrecto. ¿Pero es siempre así?

¡No! La fuente de una imagen se puede especificar con cualquier URL, sea cual sea su tipo de contenido. Puede ser una página HTML, un archivo JavaScript, u otro recurso potencialmente malicioso. En este caso, la fuente es la URL de una simple página:



Esta página sólo funcionará si tengo una sesión iniciada y algunas cookies asignadas. Puesto que realmente tenía una sesión iniciada en la aplicación, cuando el navegador ha intentado recuperar la imagen accediendo a la URL de fuente, también ha eliminado mi primer fragmento. Esto no suena particularmente peligroso, pero si conozco un poco la aplicación también podría invocar una URL que elimine el perfil de un usuario o permita a un administrador otorgar permisos a otros usuarios.

Para proteger tu aplicación de XSRF no deberías permitir nunca que las acciones de cambio se soliciten vía GET. El método POST se inventó para este tipo de peticiones de cambio de estado. Este cambio por si solo podría mitigar el ataque anterior, pero por lo general no basta y es necesario añadir algún valor impredecible a todas las solicitudes que supongan un cambio de estado para prevenir las acciones de XSRF. Si quieres más información sobre XSRF puedes ir directamente a Gruyere [inglés].

Inclusión de Cross-site script (XSSI): todas tus secuencias de comandos nos pertenecen

En muchos sitios es posible actualizar dinámicamente el contenido de una página mediante peticiones de JavaScript asincrónicas que devuelven datos JSON. A veces JSON puede contener datos sensibles que, si no se toman las precauciones debidas, un hacker podría robar.

Imaginemos la situación siguiente: hemos creado una páginas HTML estándar y te enviamos el enlace. Puesto que confías en nosotros, visitas el enlace que te hemos enviado. La página contiene tan solo unas cuantas líneas:

<script>function _feed(s) {alert("Your private snippet is: " + s['private_snippet']);}</script>

Puesto que has iniciado sesión en Gruyere y dispones de un fragmento privado, verás un cuadro de alerta en mi página que te informa sobre el contenido de tu fragmento. Como siempre, si nos las hemos arreglado para abrir un cuadro de alerta, podremos hacer lo que queramos. En este caso se trata de un simple fragmento, pero también podría haber sido tu mayor secreto.

Defender a una aplicación frente a XSSI no es demasiado difícil, pero exige pensar con cuidado. Puedes usar tokens, tal como se explica en la sección sobre XSRF, hacer que tu secuencia de comandos solo responda a peticiones POST o simplemente iniciar la respuesta JSON por "\n" para asegurarte de que la respuesta no es ejecutable.

Inyección de SQL: ¿todavía crees que lo que introducen los usuarios es seguro?

Qué sucedería si intento acceder a tu aplicación con un nombre de usuario como

MarioMartinez' ; DROP TABLE members;--

Aunque este ejemplo en particular no dejaría expuestos los datos de los usuarios, podría provocar grandes quebraderos de cabeza porque tiene la capacidad de eliminar por completo la tabla de SQL en la cual tu aplicación almacena los datos de los miembros registrados.

Por lo general, puedes proteger a tu sitio web de la inyección de código SQL pensando proactivamente sobre la introducción de datos de los usuarios En primer lugar: ¿estás seguro de que tu usuario de SQL necesita disponer de permiso para ejecutar "DROP TABLE members"? ¿No bastaría con concederle derechos de SELECT? Asignando los permisos de los usuarios cuidadosamente puedes evitar experiencias dolorosas y un montón de problemas. También puede ser útil configurar los informes de error de tal modo que no queden expuestos los nombres de las bases de datos ni de las tablas en caso de que una consulta falle.

En segundo lugar, tal como hemos aprendido en el caso XSS, los datos introducidos por el usuario no son nunca de fiar. Lo que para ti parece un formulario de inicio de sesión, es una posible puerta de acceso para un atacante. Limpia y verifica siempre la estructura de la información de entrada que se vaya a almacenar en una base de datos y, siempre que sea posible, usa instrucciones del tipo de consultas preparadas o parametrizadas, disponibles en la mayoría de las interfaces de programación de bases de datos.

Sabiendo cómo es posible atacar una aplicación web es el primer paso para entender cómo protegerla. Por este motivo, te animamos a que sigas el curso de Gruyere [inglés], aproveches otros cursos sobre seguridad web disponibles en la Google Code University [inglés]. También puedes probar Skipfish [inglés], una herramienta de prueba automática de la seguridad. Si tienes alguna pregunta más, no dudes en enviarla a nuestro Foro de ayuda para webmasters.

viernes, 8 de julio de 2011

Presentamos schema.org: los motores de búsqueda se unen para una Web más rica

Presentamos schema.org, una nueva iniciativa de Google, Bing y Yahoo! para crear y servir como base de un conjunto común de esquemas destinados al etiquetado de datos estructurados en páginas web. Schema.org es un recurso al alcance de los webmasters que deseen añadir etiquetas en sus páginas con el fin de ayudar a los motores de búsqueda a comprender mejor sus sitios web.

En Google, hace un par de años que admitimos el marcado estructurado. En 2009 introdujimos los fragmentos enriquecidos [inglés] para poder presentar mejor los resultados de las búsquedas relacionados con personas o que contuviesen opiniones. Desde entonces, hemos añadido nuevos tipos de fragmentos enriquecidos, como los de productos, eventos, recetas y mucho más.

Un ejemplo de fragmento enriquecido: un resultado de búsqueda mejorado con marcado estructurado. En este caso, el fragmento enriquecido contiene una imagen, opiniones y tiempo de cocción de una receta.
Estos elementos han sido adoptados rápidamente por la comunidad de webmasters y hoy día podemos mostrar fragmentos enriquecidos en las búsquedas más de diez veces más a menudo que cuando comenzamos hace dos años.

Queremos continuar haciendo que la Web abierta sea más rica y útil. Sabemos que añadir estas marcas a las páginas cuesta tiempo y esfuerzo y que añadir marcas es mucho más difícil cuando cada motor de búsqueda pide datos distintos y de formas distintas. Por este motivo nos hemos unido con otros motores de búsqueda, con el fin de poder utilizar un estándar común de Sitemaps [inglés] en 2006. Con schema.org, los propietarios de los sitios pueden mejorar la forma en que sus sitios aparecen en los resultados de las búsquedas, no solo en Google, sino también en Bing, Yahoo! y, potencialmente, otros motores de búsqueda en el futuro.

Ahora vamos a analizar algunos aspectos de Schema.org relevantes para ti como webmaster:

1) Schema.org contiene muchos nuevos tipos de marcas.
Hemos añadido más de 100 nuevos tipos y trasladado todos los tipos de fragmentos enriquecidos existentes. Si has pensado en añadir marcas para fragmentos enriquecidos con anterioridad pero ninguno de los tipos existentes parecía relevante para tu sitio, vale la pena volver a mirarlo. Aquí tienes algunos tipos populares:


También puedes ver la lista completa de todos los tipos de esquemas de schema.org [inglés]. Los nuevos tipos de marcas se podrán usar en el futuro para dar formato a los fragmentos enriquecidos así como para otros tipos de mejoras destinadas a ayudar a la gente a encontrar lo que buscan más fácilmente.

2) Schema.org usa microdatos.
Históricamente, hemos empleado tres estándares distintos para el etiquetado de datos estructurados: microdatos, microformatos y RDF. Hemos decidido centrarnos en un único formato para schema.org con el fin de facilitar la labor de los webmasters y mejorar la consistencia entre los motores de búsqueda que trabajan a partir de los datos. Existen argumentos para preferir cualquiera de los estándares existentes, pero creemos que los microdatos ofrecen el equilibrio entre la posibilidad de ampliación de RDF y la sencillez de los microformatos, así que éste es el formato por el que hemos optado.

Para obtener información sobre los microdatos y las convenciones que se siguen en schema.org, consulta la Guía de inicio de schema.org [inglés].

3) Continuaremos admitiendo nuestros formatos existentes de etiquetado de fragmentos enriquecidos.
Si ya has trabajado en el etiquetado de tus páginas usando microformatos o RDF, continuaremos empleándolo. No obstante, hay un inconveniente: aunque se pueda usar el nuevo esquema de etiquetado o continuar usando los microformatos o RDF existentes, se debe evitar mezclar distintos formatos en una misma página web, porque esto podría confundir a nuestros analizadores.

4) Prueba las marcas usando la herramienta de pruebas de fragmentos enriquecidos.
Resulta muy útil probar las páginas web etiquetadas para comprobar que el análisis de los datos correspondientes se haga correctamente. Al igual que con los formatos de etiquetado de fragmentos enriquecidos anteriores, para ello se debe usar la herramienta de pruebas de fragmentos enriquecidos. Ten en cuenta que la herramienta de pruebas mostrará la información etiquetada que se ha podido extraer del análisis de la página, pero la vista previa de fragmentos etiquetados con las etiquetas de schema.org todavía no está disponible. Esta funcionalidad se añadirá en breve.

El sitio web de schema.org y la herramienta de pruebas de los fragmentos enriquecidos están escritos en inglés. No obstante, Google muestra los fragmentos enriquecidos en los resultados de las búsquedas globalmente, así que no es necesario esperar a comenzar a etiquetar páginas.

Hay más información sobre los fragmentos enriquecidos y su relación con schema.org en la sección de preguntas frecuentes (FAQ) sobre fragmentos enriquecidos en schema.org.

miércoles, 6 de julio de 2011