Feed aggregator

Webmaster Level: All

Update on February 2, 2012: The new Google+ badge is now out of preview and available to all users on all sites.

When we launched Google+ pages in November, we also released Google+ badges to promote your Google+ presence right on your site. Starting today in developer preview (and soon available to all your users), we're adding more options for integrating the Google+ badge into your website. You can configure a badge with a width that fits your site design and choose a version that works better on darker sites. You'll also see that Google+ badges now include the unified +1 and circle count that we added to Pages last month.


If you’re still considering whether to add a Google+ badge on your website, consider this: We recently looked at top sites using the badge and found that, on average, the badge accounted for an additional 38% of followers. When you add the badge visitors to your website can discover your Google+ page and connect in a variety of ways: they can follow your Google+ page, +1 your site, share your site with their circles, see which of their friends have +1’d your site, and click through to visit your Google+ page.

The Google+ Badge makes it easy for your fans to find and follow you on Google+. With these additional options, we hope it's even easier to create a badge that fits your website.

Follow the conversation on Google+.

Posted by Lucy Hadden, Software Engineer, Google+

Los sitemaps informan a Google acerca de las páginas de tu sitio.  La función de sitemaps de las Herramientas para webmasters de Google te proporciona información sobre los sitemaps que envías, por ejemplo, cuántas URL de sitemaps se han indexado o si alguno de tus sitemaps contiene un error. Recientemente hemos añadido aún más información. Echémosle un vistazo:


La página de sitemaps muestra información en función del tipo de contenido. Actualmente, las estadísticas que se muestran de forma más destacada son las relativas a la Web, los vídeos, las imágenes y las noticias. De esta forma, puedes ver cuántos elementos de cada tipo se han enviado (si los hubiera) y, en algunos tipos de contenido, también mostramos cuántos elementos se han indexado.  Con estas mejoras, la nueva página de sitemaps sustituye a la función del laboratorio de sitemaps de vídeo, que desaparecerá.

Otra mejora es la capacidad de probar un sitemap. A diferencia de un envío real, en el proceso de prueba no se envía el sitemap a Google, únicamente se comprueba si contiene errores. Para probar un sitemap es necesario que Googlebot lo recupere en tiempo real, un proceso que normalmente tarda unos segundos en completarse. Ten en cuenta que la prueba inicial no es exhaustiva y es posible que no detecte todas las incidencias; por ejemplo, los errores que solo se pueden identificar una vez se han descargado las URL no se detectarán en el proceso de prueba.

Además de la prueba inmediata, también tenemos una nueva forma de revelar errores que muestra de manera más adecuada los tipos de incidencias que contiene un sitemap.  En lugar de repetir el mismo tipo de error varias veces en un sitemap, ahora los errores y advertencias se agrupan y se muestran algunos ejemplos de los mismos. De este modo, en el caso de los archivos de índice de sitemaps, hemos añadido errores y advertencias procedentes de los sitemaps secundarios que incluye el índice de sitemaps. Ya no tendrás que hacer clic en cada uno de los sitemaps secundarios.

Por último, hemos cambiado el funcionamiento del botón para eliminar los sitemaps. Ahora, estos se eliminan de las Herramientas para webmasters, tanto de tu cuenta como de las cuentas de los demás propietarios del sitio. Ten en cuenta que si eliminas un sitemap de las Herramientas para webmasters, no significa que Google no lo lea o procese. Para eliminar totalmente un sitemap y evitar que sea procesado, te recomendamos que elimines el archivo o bien que lo bloquees mediante robots.txt.

Para obtener más información sobre los sitemaps en las Herramientas para webmasters y el funcionamiento de estos, visita nuestro Centro de asistencia. Si tienes alguna pregunta, consulta el foro de ayuda para webmasters.

Escrito por Kamila Primke, ingeniera de software, Herramientas para webmasters de Google. Publicado por Miguel Silva Rodrigues.

Nivel de webmasters: intermedio


Uno de los principales obstáculos de cualquier embudo de conversión es rellenar un formulario online: los procesos de registro y de compra se basan en los formularios, que constituyen un paso fundamental y complejo en el cumplimiento de los objetivos del sitio. Para muchos usuarios, los formularios online consisten en la introducción repetida de información habitual (por ejemplo, nombres y direcciones) en diferentes sitios de toda la Web, es decir, una tarea tediosa que provoca que muchos se den por vencidos y abandonen el proceso por completo.

La función Autocompletar de Google Chrome y otros proveedores de completado de formularios ayudan a romper esta barrera. Para ello, recuerdan la información habitual de los perfiles y rellenan previamente los formularios con estos valores. Sin embargo, los webmasters no han podido garantizar hasta el momento que Google Chrome y otros proveedores de completado de formularios puedan analizar los formularios de forma correcta. Existen algunos estándares, pero imponen cargas muy pesadas en la implementación del sitio web, por lo que no se suelen utilizar en la práctica.

Nos complace poder anunciar hoy la admisión en Chrome de un nuevo atributo experimental de tipo de autocompletado para los campos de formularios que permite a los desarrolladores web etiquetar texto de forma inequívoca y seleccionar campos con tipos de datos habituales como, por ejemplo, el nombre completo o la dirección. Con este atributo, los desarrolladores web pueden generar conversiones en sus sitios al marcar sus formularios para autocompletado sin necesidad de cambiar la interfaz del usuario ni el servidor.



Solo hay que añadir un atributo al elemento de introducción de datos, por ejemplo, el campo de dirección de correo electrónico puede tener una apariencia similar a la siguiente:

<input type=”text” name=”field1” x-autocompletetype=”email” />
Hemos trabajado en este diseño junto con otros proveedores de autocompletado. Al igual que sucede con cualquier propuesta en fase inicial, esperamos que cambie y evolucione a medida que la comunidad de estándares web nos envíe sus comentarios. No obstante, creemos que esto es un buen punto de partida para la discusión sobre cómo admitir de la mejor forma posible los formularios que se completan automáticamente en la especificación HTML5. Por ahora, este nuevo atributo se ha implementado en Google Chrome como x-autocompletetype para indicar que todavía se encuentra en fase experimental y que no es un estándar, igual que ocurre con el atributo webkitspeech que publicamos (en Inglés) el verano pasado.

Para obtener más información, puedes leer el texto completo de la especificación propuesta (en Inglés), realizar preguntas en el foro de ayuda para webmasters o puedes compartir tus comentarios en el debate sobre estandarización.

Texto original de Ilya Sherman, publicado por Miguel Silva Rodrigues.

Como equipo responsable de miles de páginas web informativas de Google, la misión del equipo de webmasters es ofrecer consejos y sugerencias basados en sus conocimientos como webmasters experimentados.

Si nunca has probado o analizado el uso de tu sitio web, pregúntate si realmente sabes si el sitio resulta útil para los usuarios a los que está dirigido. Si no estás seguro, ¿por qué no lo compruebas? Por ejemplo, ¿sabías que los usuarios se desplazan hacia abajo en la página una media de 5,9 veces más que hacia arriba, lo que significa que, a menudo, el contenido de la página se "pierde" una vez que se ha pasado? Para obtener más información, consulta la página sobre descubrimientos relacionados con el desplazamiento, en la que Jakob Nielsen informa de que a los usuarios no les importa desplazarse por una página, pero dentro de unos límites.

Comprueba también las estadísticas: ¿quieres saber a qué se deben los indicadores de tiempo breve de permanencia o los porcentajes de rebote elevados de algunas de tus páginas?

Primero, piensa en el usuario

El inicio de un proyecto web, ya sea un proyecto totalmente nuevo o una actualización de uno existente, es un buen momento para hacerse preguntas como estas:

• ¿Cómo podrán acceder los usuarios al sitio web (desde casa, desde la oficina o de camino a algún lugar)?
• ¿Qué conocimientos tecnológicos tienen esos usuarios?
• ¿Hasta qué punto están familiarizados con el tema del sitio web?

Las respuestas a algunas de estas preguntas pueden ser de gran ayuda a la hora de tomar decisiones iniciales relacionadas con el diseño.

Por ejemplo, si es probable que los usuarios se encuentren en un ambiente ruidoso, que tengan una conexión lenta o que estén en la carretera y tengan poco tiempo para buscar la información que necesiten del sitio, lo más adecuado será utilizar un diseño sencillo con una finalidad única. Además, si el contenido está destinado a usuarios con pocos conocimientos técnicos, debes asegurarte de que no sea demasiado difícil acceder a él (puedes obtener buenos resultados utilizando elementos de animación, pero solo si los usuarios los aprecian y si no es demasiado difícil acceder al contenido).

Aunque no se realice ninguna prueba, crear un perfil de usuario básico (o "persona") puede ayudar a adaptar el diseño a los usuarios (no hace falta que el perfil incluya una biografía exhaustiva: es suficiente con que contenga alguna información básica sobre los patrones de comportamiento del usuario).

Una prueba sencilla

Una prueba no tiene que ser algo costoso: los amigos y familiares pueden ser recursos de gran utilidad. A continuación te proponemos algunas sugerencias.

• Tamaño del grupo de prueba: cinco personas son usuarios suficientes para encontrar incidencias habituales relacionadas con el diseño y con la navegación (consulta el artículo de Jakob Nielsen sobre por qué es suficiente con utilizar un grupo de prueba pequeño).
• Elección de los evaluadores: puede ser útil recurrir a un grupo de evaluadores con diferentes habilidades técnicas, pero debes asegurarte de centrarte solamente en las tendencias (por ejemplo, si más del 50% de los evaluadores ha experimentado una misma incidencia relativa a la facilidad de uso, es probable que se trate de una incidencia común y no de una incidencia que afecte a una sola persona).
• Lugar de realización de la prueba: si es posible, ve a casa del usuario y observa cómo utiliza el sitio (comprueba cómo suele navegar por Internet cuando se encuentra relajado y en su entorno natural). También puedes llevar a cabo una prueba remota si no puedes desplazarte en persona (hemos oído que las quedadas de Google+ funcionan muy bien en estos casos). Para obtener más información sobre el uso de las quedadas de Google+, haz clic aquí.
• Metodología de la prueba: basándote en los objetivos de tu sitio, define cuatro o cinco tareas sencillas que se puedan llevar a cabo en tu sitio web y deja que el usuario intente completarlas. Pide a los evaluadores que hablen en voz alta para que puedas comprender mejor sus experiencias y sus razonamientos.
• Elementos de evaluación: es posible emplear prototipos básicos en imágenes en las que se pueda hacer clic o en formato de documento (por ejemplo, PDF) o utilizar HTML para probar las interacciones básicas sin tener que construir un sitio completo para las pruebas. De esta forma, se pueden probar diferentes formas de navegar y distintos diseños para ver los resultados que ofrecen antes de implementarlos.
• Elementos que no se deben evaluar: hay que centrarse en la funcionalidad (más que en los elementos de diseño gráfico). Dado que los puntos de vista suelen ser subjetivos, generalmente solo se reciben comentarios útiles referentes al diseño cuando se realizan pruebas cuantitativas en las que participa un gran número de usuarios (más de 200) a menos que, por ejemplo, los colores que se utilicen en el sitio dificulten la lectura del contenido (en cuyo caso, los comentarios pueden ser útiles). Una forma de obtener comentarios útiles sobre el diseño puede ser proponer cinco o seis palabras clave descriptivas y pedir a los usuarios que elijan las que consideren más representativas. 

En conjunto, las pruebas básicas son más útiles para evaluar la funcionalidad de un sitio web (es decir, la facilidad para encontrar información y las interacciones habituales con el sitio).

Lecciones aprendidas

Por si aún no tienes claro si realizar pruebas e investigaciones merece realmente la pena, a continuación te ofrecemos algunos datos sencillos que hemos confirmado con usuarios reales y que no conoceríamos si no hubiéramos interactuado con esos usuarios y observado cómo utilizan nuestras páginas o no hubiéramos analizado el tráfico de nuestros sitios web.

• Ten cuidado cuando utilices diseños en los que se oculte o muestre contenido: al utilizar secuencias de comandos para expandir y contraer pasajes largos de texto, hemos observado que el usuario no suele darse cuenta de que hay contenido adicional disponible, concretamente cuando se "esconde" el contenido JavaScript al buscar en la página (por ejemplo, con la habitual combinación de teclas Ctrl + F).

Modelo de diseño probado que muestra contenido
"comprimido" en la parte inferior izquierda

Diseño final de página con enlaces de anclaje en la parte superior
y contenido en el cuerpo principal de la página

• Cuida el estilo del texto: el texto de los botones, de los enlaces y de los encabezados es lo que más llama la atención a los usuarios cuando examinan la página. Evita el uso de "Más información..." en el texto de los enlaces (los usuarios parecen mostrarse reacios a hacer clic en un enlace que supone aprender algo). En vez de eso, intenta utilizar una descripción literal del contenido al que remite el enlace y asegúrate de que el texto del enlace tenga sentido y sea fácil de entender fuera de contexto, ya que así es como se lee frecuentemente. Presta atención a la forma de escribir e intenta que el texto de los botones sea descriptivo, atractivo e interesante.

• Prueba las páginas con una conexión más lenta: prueba tus páginas en diferentes redes (por ejemplo, intenta explorar tu sitio web utilizando la red Wi-Fi de una cafetería o de la casa de un amigo), especialmente si es probable que los usuarios a los que está dirigido tu sitio vean las páginas con una conexión doméstica que no sea tan rápida como la de tu oficina. Hemos observado una mejora considerable en las métricas de porcentaje de clics (CTR) y tiempo de permanencia en el sitio en algunos casos al crear animaciones con secuencias de comandos mucho más sencillas y rápidas. (Consejo: utiliza la herramienta Page Speed Online de Google para comprobar el rendimiento si no tienes acceso a una conexión a Internet más lenta). 

Así pues, si en el futuro te ves inmerso en un ciclo de desarrollo que parece no tener fin, podrás ahorrarte algo de tiempo si realizas algunas investigaciones preliminares examinando el perfil de los usuarios y haciendo algunas pruebas básicas que te ayuden a elegir la arquitectura y el diseño más adecuados para tu sitio.

Nos encantaría que contaras tu experiencia en la sección de comentarios. ¿Has llevado a cabo pruebas de facilidad de uso de sitios web? Si lo has hecho, ¿cómo fueron y qué trucos sencillos y económicos te permitieron sacarles el máximo partido?

En esta ocasión un usuario, Damian, lanza una pregunta sobre los anuncios en banners en forma de imagen y si es necesario añadirles un "nofollow" en estos casos. ¿Te interesa la respuesta? ¿Sí? Pues entonces te aconsejamos ver la respuesta de Matt Cutts.

¿Debería añadir "nofollow" a anuncios en banners?

Nota: Os recuerdo que los vídeos tienen subtítulos en español y estos deberían aparecer por defecto.

Transcripción de: ¿Debería añadir "nofollow" a anuncios en banners? 

Hemos recibido una pregunta de Damian, desde la blogosfera. Es esta: "Si alguien compra un enlace de texto desde mi sitio web, añado una etiqueta "nofollow" para que sepáis que es un enlace pagado. ¿Debo hacer lo mismo con los banners a base de imágenes?"


En general, cuando hablamos de banners publicitarios, la gran mayoría de ellos se venden mediante intercambios o en distintas redes de anuncios que ya bloquean nuestros robots rastreadores. Porque no quieren que los robots rastreen sus banners publicitarios. No quieren que los robots alteren sus impresiones ni sus recuentos de clics, ni nada por el estilo.


Así que, si estás usando algún tipo de paquete de banners publicitarios estándar, en la mayoría de los casos, los redireccionamientos irán a través de cosas que están bloqueadas por robots.txt o que, de algún modo, los motores de búsqueda no pueden rastrear. Esto es perfecto: no necesitas preocuparte en absoluto en ese caso.


Si vendes directamente el enlace por ti mismo y la única diferencia es que uno es una imagen y el otro es un enlace de texto. Si alguien ha pagado por ese enlace específicamente, entonces, sí, yo pondría nofollow en el enlace. Aunque sea un enlace en una imagen. Sin embargo, de nuevo, en la mayor parte de los casos, Google maneja los banners típicos y este tipo de cosas muy bien, de modo que no afectan a la clasificación de las páginas y todo funciona correctamente. Por lo tanto, si este es el caso, yo no me preocuparía por la situación. 

Publicado por Esperanza Navas, equipo de Calidad de búsqueda

Los webmasters comentan sistemáticamente que tienen que priorizar su tiempo. Algunos de ellos administran decenas o cientos de sitios de clientes; otros tienen que encargarse de sus propios negocios y solo pueden dedicar una hora al mantenimiento del sitio web mientras gestionan tareas relacionadas con las finanzas y el inventario. Para ayudar a priorizar las tareas, las Herramientas para webmasters de Google van a introducir el concepto de "estado del sitio" y por ello hemos rediseñado la página principal de las Herramientas para webmasters de Google para poder resaltar los sitios que presentan incidencias de estado. De esta forma, podrás ver fácilmente las necesidades a las que debes prestar más atención sin tener que hacer clic en todos los informes de las Herramientas para webmasters de Google relativos a cada sitio que gestiones.

A continuación puedes ver la apariencia de la nueva página principal:



Como puedes comprobar, los sitios con incidencias de estado se muestran en la parte superior de la lista. (Si lo prefieres, siempre podrás volver a ordenar tus sitios alfabéticamente). Para consultar las incidencias específicas que hayamos detectado en un sitio, haz clic en el icono de estado del sitio o en el enlace "Comprobar estado del sitio" situados junto al sitio en cuestión:


Hemos decidido que esta primera versión de dicha página solo estará disponible para los usuarios que tengan 100 o menos sitios en la cuenta de las Herramientas para webmasters (verificados o sin verificar), pero ampliaremos la disponibilidad a todas las cuentas en un futuro. Si tienes más de 100 sitios, puedes ver la información de "estado de sitio" en la parte superior del panel de cada uno de tus sitios web.

En estos momentos incluimos tres tipos de incidencias en la comprobación de estado del sitio:

1.¿Hemos detectado software malintencionado en el sitio?
2.¿Se han eliminado páginas importantes a través de nuestra herramienta de solicitud de eliminación de URL?
3.¿Se ha utilizado el archivo robots.txt para impedir que se rastreen algunas de tus páginas más importantes?

 Puedes hacer clic en uno de estos elementos para obtener más información sobre las incidencias detectadas en tu sitio. Si el icono de estado del sitio y el enlace "Comprobar estado del sitio" no aparecen junto a un sitio, es posible que no hayamos detectado ninguna de estas incidencias en el sitio (¡felicidades!).

Una cosa sobre las "páginas importantes": como sabes, si accedes a "Información del sitio > Acceso de rastreadores > Eliminar URL", puedes obtener una lista completa de todas las URL que se hayan eliminado. Asimismo, puedes ver todas las URL que no hemos podido rastrear porque se ha utilizado el archivo robots.txt en "Diagnóstico > Errores de rastreo > Restringida por robots.txt". Sin embargo, dado que los webmasters en ocasiones bloquean o eliminan contenido intencionadamente, solo nos interesaba indicar la posibilidad de que se produzcan incidencias de estado del sitio en los casos en los que consideremos que has bloqueado o eliminado una página de forma accidental. Por ese motivo, nos hemos centrado en las "páginas importantes". En estos momentos estamos consultando el número de clics que las páginas consiguen (que puedes ver en "Tu sitio en la Web > Consultas de búsqueda") para determinar la importancia. Además, es posible que incorporemos otros factores a medida que las comprobaciones de estado del sitio evolucionen.

Obviamente estas tres incidencias (software malintencionado, URL eliminadas y URL bloqueadas) no son las únicas cuestiones que pueden afectar al estado de un sitio web, por lo que en un futuro esperamos ampliar las comprobaciones que utilizamos para determinar el estado de un sitio. Asimismo, ten en cuenta que no hay ningún sustituto para tu propio juicio y conocimiento con relación al estado de tu sitio. No obstante, esperamos que estos cambios te ayuden a descubrir de un modo más rápido y sencillo las principales incidencias de tus sitios sin tener que examinar en profundidad todos los datos e informes.

Una vez que hayas solucionado cualquier incidencia de estado del sitio que hayamos marcado, deberán transcurrir unos días hasta que la advertencia desaparezca de tu cuenta de las Herramientas para webmasters de Google, ya que tenemos que volver a rastrear el sitio, consultar los cambios que hayas realizado y, a continuación, procesar esta información a través de la Búsqueda web de Google y las Herramientas para webmasters de Google. Si la advertencia sobre el estado del sitio sigue apareciendo tras una semana aproximadamente, es posible que la incidencia no se haya solucionado. No dudes en solicitar ayuda para localizar la incidencia en el foro de ayuda para webmasters... y envíanos tu opinión.

Publicado por Susan Moskwa, Webmaster Trends Analyst.

Hace unos meses lanzamos un programa piloto sobre informes de Optimización en motores de búsqueda en Google Analytics, el cual estaba basado en la información de Consultas de búsqueda de las Herramientas para webmasters. Gracias a los comentarios y opiniones de nuestros usuarios del programa piloto, hemos hecho varias mejoras y estamos muy contentos de anunciar que dichos informes están ya disponibles para todo el mundo en la sección de Fuentes de tráfico de Google Analytics.

• Palabras clave: impresiones, clics, posición e información de CTR diario de las 1000 primeras palabras de búsqueda
• Página de destino: impresiones, clics, posición e información de CTR diario de las 1000 primeras páginas de destino
• Resumen por ubicación: impresiones, clics y CTR por país.

Todos estos informes de Optimización en motores de búsqueda cuentan con los filtros avanzados de Google Analytics, así como de las propiedades de visulaización para un análisis más en profundidad. Con las dimensiones secundarias, puedes ver la información sobre tu sitio web de formas que no son posibles en las Herramientas para webmasters.

Para activar estos informes de Optimización en motores de búsqueda para un determinado sitio web, debes ser tanto el propietario de la web verificada en las Herramientas para webmasters, como el administrador de la misma en Google Analytics. Una vez activados, los administradores podrán elegir qué perfiles pueden ver esos informes.

Si tienes algún comentario o sugerencia, por favor háznolo saber a través del Foro para webmasters.

Publicado por Christina Chen, Product Manager

Las redirecciones 301 siempre generan muchas preguntas, así que esta vez desde Dinamarca, jacob le pregunta a Matt Cutts sobre cuánto tiempo se debe dejar una redirección 301 en un cambio de dominio. ¿Estás en el mismo caso que Jacob y no sabes la respuesta? Pues haz clic en el vídeo y escucha las recommendaciones de Matt.

¿Cuánto tiempo dejar una redirección en un cambio de dominio?

Nota: Os recuerdo que los vídeos tienen subtítulos en español y estos deberían aparecer por defecto.

Transcripción de: ¿Cuánto tiempo dejar una redirección en un cambio de dominio?

La pregunta de hoy es de Jacob, de Dinamarca. Jacob quiere saber: "Si tengo un nuevo dominio y quiero redirigir www.viejodominio.com a www.nuevodominio.com, ¿cuánto tiempo debo mantener el redireccionamiento antes de comenzar a usar el dominio antiguo para otra cosa? ¿Sólo hasta que se haya rastreado una vez?"

Bien. Esto es algo sobre lo cual las políticas de los motores de búsqueda pueden cambiar con el tiempo, puesto que vemos cómo evoluciona la Web, o vemos que los webmasters tienen problemas... y cosas por el estilo. Puedo contaros mi experiencia al trasladarme de mattcutts.com a dullest.com y de dullest.com de nuevo a mattcutts.com. Al volver, utilicé un redireccionamiento 301. Y tardó un periodo de varias semanas porque, recordad: el redireccionamiento 301 tiene lugar a nivel de página. Así que, solo porque aparezca el 301 en una página del dominio antiguo, no significa que todo el dominio se haya trasladado al completo. 

Lo que hice es ejecutar el redireccionamiento de modo que todas y cada una de las páginas se redirigía de dullest.com a mattcutts.com. así que había sido una transición completa. Y realmente no me preocupé de dullest.com durante varias semanas. Tal vez un par de meses. Cuando volví a consultar Google Analytics, en esos momentos todo el tráfico había cambiado de dullest.com a mattcutts.com.

Por consiguiente, en un plazo de unas cuantas semanas, o varias semanas, tal vez alrededor de un par de meses, por ejemplo, podríamos ver que el sitio se ha movido por completo. Pero si recibimos información contradictoria, como que algunas páginas devuelven un código 200, que es un OK, mientras que otras devuelven un redireccionamiento 301 o permanente, entonces no sabemos a ciencia cierta qué significa eso.

Ciertamente, hace poco he visto algunas situaciones en que un sitio dijo: "Me he cambiado de viejodominio.com a nuevodominio.com", pero se olvidaron de añadir un subdominio. Así que se servían 200 desde el subdominio antiguo. Por consiguiente, no se puede asumir que, oh, todo va a funcionar automáticamente y mágicamente, a la perfección.

Tenemos una herramienta en las Herramientas para webmasters de Google donde es posible indicar que un sitio se ha movido de un lugar a otro. Así que es posible hacer eso para los 301 a nivel de cada página. Pero yo no asumiría que basta con que se rastree una sola vez. Realmente, el robot de Google y Google necesitan ganar la confianza suficiente como para saber que, de veras, un sitio se ha movido completamente del lugar viejo al nuevo. En definitiva, puede llevar un poco de tiempo, pero si todo va bien, al cabo de un tiempo todo acaba por ponerse al día

Publicado por Esperanza Navas, equipo de Calidad de búsqueda

De vez en cuando creemos oportuno recordar a los webmasters y/o dueños de páginas web cuál es la postura de Google ante los enlaces de pago. No solo porque cada día hay cientos, sino miles, de nuevas páginas web, cuyos webmasters empiezan a familiarizarse con Internet, los motores de búsqueda y sus políticas, sino también por las preguntas alrededor de este tema que recibimos en nuestro Foro de ayuda para webmasters.

Teniendo en cuenta que nuestro objetivo es presentar a los usuarios resultados equitativos y precisos, y que este tipo de técnicas tiene la intención de manipular los mismos, nos ustaría aclarar una vez más algunos puntos sobre este tema:

• Si un webmaster decide comprar y/o vender enlaces con el objetivo de manipular la clasificación, es decir pasar PageRank, nos reservamos el derecho de proteger la calidad de nuestros resultados de búsqueda.

• Somos bastantes precisos a la hora de detectar los enlaces de pago y tomar acción sobre ellos, tanto de forma algorítmica como manual, así que si sospechas que hay algún sitio web comprando y/o vendiendo enlaces siempre puedes decírnoslo a través de nuestro rediseñado informe de spam.

• Google actúa sobre todos los sitios con la misma contundencia y rigor, sin importar la popularidad o el tamaño del sitio web. En algunos casos los efectos de nuestras acciones pueden que no sean visibles con efecto inmediato como explicamos en este artículo.

Así que... ¿qué hacer?

Si un webmaster decide comprar y/o vender enlaces y no quiere que esto repercuta de forma negativa en el posicionamiento de su sitio web puede utilizar el rel=“nofollow”, o bien redireccionarlos a través de una página que esté bloqueada en el archivo robots.txt, y así ceñirse a las Directrices de calidad de Google para webmasters. Por otra parte, también es un buen momento para compartir con vosotros este artículo sobre enlaces orgánicos y recordaros que existen muchas formas de conseguir enlaces de calidad para vuestros sitios web.

Así que si crees que tu web ha sido penalizada por comprar y/o vender enlaces, la mejor forma de actuar es corregir primero esta infracción para que los enlaces no pasen PageRank y luego enviar el formulario de reconsideración explicando cuál era la situación y cómo la has solucionado. Si tenéis alguna pregunta sobre ésto podéis acudir a nuestro foro para webmasters.

Publicado por Esperanza, equipo de Calidad de búsqueda

Tras escuchar vuestros comentarios al respecto, pronto ofreceremos métricas del porcentaje de impresiones a nivel del grupo de anuncios para las Redes de Búsqueda y de Display. Por ejemplo, tras el lanzamiento, podrás utilizar los datos del porcentaje de impresiones del grupo de anuncios para identificar mejor los grupos de anuncios con rendimiento alto que no estén captando la mayoría de las impresiones disponibles.
En las próximas semanas, verás tres columnas nuevas en la pestaña Grupos de anuncios:

1. Porcentaje de impresiones: es el porcentaje de impresiones que recibió el anuncio dividido por la cantidad estimada de impresiones que podría haber recibido según los requisitos.
2. Porcentaje de impr. perdidas (clasificación): es el porcentaje de impresiones perdidas debido al Ranking del anuncio. Recuerda que el Porcentaje de impr. perdidas (clasificación) no se mostrará si alcanzaste o estás a punto de alcanzar el presupuesto para la totalidad o parte de un día determinado (también conocido como "presupuesto limitado") durante el período que deseas examinar. 
3. Porcentaje de impr. de concordancia exacta: (solo Red de búsqueda) es el porcentaje de impresiones que recibieron tus anuncios de las búsquedas que coincidieron de manera exacta con tu palabra clave dividido por la cantidad estimada de impresiones de concordancia exacta que podrías haber recibido.

Además de brindar métricas más detalladas, también planeamos actualizar nuestros algoritmos para proporcionar métricas más exactas del porcentaje de impresiones de la campaña.  Como resultado, debes tener en cuenta algunos cambios importantes:

1. Estadísticas detalladas a nivel de la campaña: debido a que estamos mejorando nuestros algoritmos, actualizaremos todas las métricas del porcentaje de impresiones a nivel de la campaña hasta mayo de 2011. Por lo tanto, ya no podrás ver las métricas del historial del porcentaje de impresiones a nivel de la campaña anteriores a mayo de 2011. Si deseas mantener un registro de los datos del porcentaje de impresiones de las campañas anteriores a mayo de 2011, deberás descargar un informe antes del 30 de enero de 2012.
2. Actualizaciones una vez al día: para poder calcular tus métricas del porcentaje de impresiones con más exactitud, actualizaremos todas las métricas del porcentaje de impresiones una vez al día (aproximadamente, al mediodía, hora del pacífico [GTM-8]). Como resultado, los datos de impresiones que verás no reflejarán el porcentaje de impresiones del día actual y, además, es posible que no incluyan el porcentaje de impresiones del día anterior (según la hora del día en que generes el informe).  

Estos cambios comenzarán a implementarse para todos los anunciantes a nivel mundial el 30 de enero de 2012. Por lo tanto, empieza a buscarlos en tu cuenta pronto. Una vez que estos cambios estén activos, podrás encontrar información más detallada en el Centro de asistencia de AdWords. 
Autor Alexandra Kenin. Publicado por Asier Ríos

A partir de hoy, empezaremos a implantar actualizaciones en tus métricas del porcentaje de impresiones, lo que incluye nuevas métricas de porcentaje de impresiones para grupos de anuncios y también métricas revisadas de porcentaje de impresiones de campaña.  También hemos cambiado la frecuencia con la que se actualizarán estos datos, que será una vez al día. Estas actualizaciones entrarán en vigor globalmente para todas las cuentas en los próximos días. Para obtener más información sobre el porcentaje de impresiones, consulta el Centro de Asistencia de AdWords.
Publicado por Asier Ríos.

Webmaster Level: Intermediate to Advanced

As the web evolves, Google’s crawling and indexing capabilities also need to progress. We improved our indexing of Flash, built a more robust infrastructure called Caffeine, and we even started crawling forms where it makes sense. Now, especially with the growing popularity of JavaScript and, with it, AJAX, we’re finding more web pages requiring POST requests -- either for the entire content of the page or because the pages are missing information and/or look completely broken without the resources returned from POST. For Google Search this is less than ideal, because when we’re not properly discovering and indexing content, searchers may not have access to the most comprehensive and relevant results.

We generally advise to use GET for fetching resources a page needs, and this is by far our preferred method of crawling. We’ve started experiments to rewrite POST requests to GET, and while this remains a valid strategy in some cases, often the contents returned by a web server for GET vs. POST are completely different. Additionally, there are legitimate reasons to use POST (e.g., you can attach more data to a POST request than a GET). So, while GET requests remain far more common, to surface more content on the web, Googlebot may now perform POST requests when we believe it’s safe and appropriate.

We take precautions to avoid performing any task on a site that could result in executing an unintended user action. Our POSTs are primarily for crawling resources that a page requests automatically, mimicking what a typical user would see when they open the URL in their browser. This will evolve over time as we find better heuristics, but that’s our current approach.

Let’s run through a few POSTs request scenarios that demonstrate how we’re improving our crawling and indexing to evolve with the web.

Examples of Googlebot’s POST requests

• Crawling a page via a POST redirect
  <html>
    <body onload="document.foo.submit();">
      <form name="foo" action="request.php" method="post">       <input type="hidden" name="bar" value="234"/>
      </form>
    </body>
  </html>
• Crawling a resource via a POST XMLHttpRequest
  In this step-by-step example, we improve both the indexing of a page and its Instant Preview by following the automatic XMLHttpRequest generated as the page renders.
  
  
  1. Google crawls the URL, yummy-sundae.html.
  2. Google begins indexing yummy-sundae.html and, as a part of this process, decides to attempt to render the page to better understand its content and/or generate the Instant Preview.
  3. During the render, yummy-sundae.html automatically sends an XMLHttpRequest for a resource, hot-fudge-info.html, using the POST method.
     <html>
       <head>
         <title>Yummy Sundae</title>
         <script src="jquery.js"></script>
       </head>
       <body>
         This page is about a yummy sundae.
         <div id="content"></div>
         <script type="text/javascript">
           $(document).ready(function() {
             $.post('hot-fudge-info.html', function(data)
               {$('#content').html(data);});
           });
         </script>
       </body>
     </html>
  4. The URL requested through POST, hot-fudge-info.html, along with its data payload, is added to Googlebot’s crawl queue.
  5. Googlebot performs a POST request to crawl hot-fudge-info.html.
  6. Google now has an accurate representation of yummy-sundae.html for Instant Previews. In certain cases, we may also incorporate the contents of hot-fudge-info.html into yummy-sundae.html.
  7. Google completes the indexing of yummy-sundae.html.
  8. User searches for [hot fudge sundae].
  9. Google’s algorithms can now better determine how yummy-sundae.html is relevant for this query, and we can properly display a snapshot of the page for Instant Previews.

Improving your site’s crawlability and indexability

General advice for creating crawlable sites is found in our Help Center. For webmasters who want to help Google crawl and index their content and/or generate the Instant Preview, here are a few simple reminders:

• Prefer GET for fetching resources, unless there’s a specific reason to use POST.
• Verify that we're allowed to crawl the resources needed to render your page. In the example above, if hot-fudge-info.html is disallowed by robots.txt, Googlebot won't fetch it. More subtly, if the JavaScript code that issues the XMLHttpRequest is located in an external .js file disallowed by robots.txt, we won't see the connection between yummy-sundae.html and hot-fudge-info.html, so even if the latter is not disallowed itself, that may not help us much. We've seen even more complicated chains of dependencies in the wild. To help Google better understand your site it's almost always better to allow Googlebot to crawl all resources.
  
  You can test whether resources are blocked through Webmaster Tools “Labs -> Instant Previews.”
• Make sure to return the same content to Googlebot as is returned to users’ web browsers. Cloaking (sending different content to Googlebot than to users) is a violation of our Webmaster Guidelines because, among other things, it may cause us to provide a searcher with an irrelevant result -- the content the user views in their browser may be a complete mismatch from what we crawled and indexed. We’ve seen numerous POST-request examples where a webmaster non-maliciously cloaked (which is still a violation), and their cloaking -- on even the smallest of changes -- then caused JavaScript errors that prevented accurate indexing and completely defeated their reason for cloaking in the first place. Summarizing, if you want your site to be search-friendly, cloaking is an all-around sticky situation that’s best to avoid.
  
  To verify that you're not accidentally cloaking, you can use Instant Previews within Webmaster Tools, or try setting the User-Agent string in your browser to something like:
  
  Mozilla/5.0 (compatible; Googlebot/2.1;
    +http://www.google.com/bot.html)
  Your site shouldn't look any different after such a change. If you see a blank page, a JavaScript error, or if parts of the page are missing or different, that means that something's wrong.
• Remember to include important content (i.e., the content you’d like indexed) as text, visible directly on the page and without requiring user-action to display. Most search engines are text-based and generally work best with text-based content. We’re always improving our ability to crawl and index content published in a variety of ways, but it remains a good practice to use text for important information.

Controlling your content

If you’d like to prevent content from being crawled or indexed for Google Web Search, traditional robots.txt directives remain the best method. To prevent the Instant Preview for your page(s), please see our Instant Previews FAQ which describes the “Google Web Preview” User-Agent and the nosnippet meta tag.

Moving forward

We’ll continue striving to increase the comprehensiveness of our index so searchers can find more relevant information. And we expect our crawling and indexing capability to improve and evolve over time, just like the web itself. Please let us know if you have questions or concerns.

Written by Pawel Aleksander Fedorynski, Software Engineer, Indexing Team, and Maile Ohye, Developer Programs Tech Lead

Webmaster level: All

Sitemaps are a way to tell Google about pages on your site. Webmaster Tools’ Sitemaps feature gives you feedback on your submitted Sitemaps, such as how many Sitemap URLs have been indexed, or whether your Sitemaps have any errors. Recently, we’ve added even more information! Let’s check it out:


The Sitemaps page displays details based on content-type. Now statistics from Web, Videos, Images and News are featured prominently. This lets you see how many items of each type were submitted (if any), and for some content types, we also show how many items have been indexed. With these enhancements, the new Sitemaps page replaces the Video Sitemaps Labs feature, which will be retired.

Another improvement is the ability to test a Sitemap. Unlike an actual submission, testing does not submit your Sitemap to Google as it only checks it for errors. Testing requires a live fetch by Googlebot and usually takes a few seconds to complete. Note that the initial testing is not exhaustive and may not detect all issues; for example, errors that can only be identified once the URLs are downloaded are not be caught by the test.

In addition to on-the-spot testing, we’ve got a new way of displaying errors which better exposes what types of issues a Sitemap contains. Instead of repeating the same kind of error many times for one Sitemap, errors and warnings are now grouped, and a few examples are given. Likewise, for Sitemap index files, we’ve aggregated errors and warnings from the child Sitemaps that the Sitemap index encloses. No longer will you need to click through each child Sitemap one by one.

Finally, we’ve changed the way the “Delete” button works. Now, it removes the Sitemap from Webmaster Tools, both from your account and the accounts of the other owners of the site. Be aware that a Sitemap may still be read or processed by Google even if you delete it from Webmaster Tools. For example if you reference a Sitemap in your robots.txt file search engines may still attempt to process the Sitemap. To truly prevent a Sitemap from being processed, remove the file from your server or block it via robots.txt.

For more information on Sitemaps in Webmaster Tools and how Sitemaps work, visit our Help Center. If you have any questions, go to Webmaster Help Forum.

Written by Kamila Primke, Software Engineer, Webmaster Tools

Hoy os traemos una gran noticia. ¡Mañana, 31 de enero, lanzaremos una versión totalmente renovada del Centro de Ayuda! Desde que la introdujimos en Estados Unidos hace unas semanas, miles de usuarios de AdWords ya la han probado. ¡Y las opiniones recibidas son muy positivas!
A continuación te mostramos algunos de los cambios que empezarás a ver a partir del 31 de enero:
1. Navegación más sencilla: a partir de ahora será más sencillo navegar por el contenido utilizando el nuevo menú situado en la parte superior de cada página.



2. Información de contacto más visible: encuentra la opción necesaria para contactar con nosotros, a través del enlace ‘Contáctanos’ de la parte superior de la página.3. Más capturas de pantalla y vídeos: el contenido es más claro, por lo que podrás aprender más rápidamente cómo realizar cualquier cambio necesario en tu cuenta de AdWords.
¿Estás preparado para probar el nuevo Centro de Ayuda? Simplemente haz clic en ‘Probar la nueva interfaz’, a partir de mañana. Si no deseas explorarlo ahora mismo, siempre puedes utilizar la barra amarilla que aparecerá en la parte superior de cada página para activarlo.


Por supuesto, también podrás volver a la versión anterior en cualquier momento, a través del enlace ‘Volver a la interfaz anterior’. ¡Aunque esperamos que te guste tanto, que no querrás volver a la versión anterior!
Iremos presentando nuevas funcionalidades de manera gradual, así que estate atento a las novedades y artículos que iremos publicando durante los próximos meses.
Si deseas enviarnos cualquier comentario acerca de la nueva interfaz, por favor, hazlo a través del botón ‘Envíenos comentarios sobre la nueva interfaz’ situado en la parte inferior derecha de cualquier página del Centro de Ayuda. ¡Todo comentario será apreciado!


El equipo del Centro de Ayuda de AdWords. Publicado por Asier Ríos.

Webmaster level: All

Starting today, we’re updating our Top Search Queries feature to make it better match expectations about search engine rankings. Previously we reported the average position of all URLs from your site for a given query. As of today, we’ll instead average only the top position that a URL from your site appeared in.

An example
Let’s say Nick searched for [bacon] and URLs from your site appeared in positions 3, 6, and 12. Jane also searched for [bacon] and URLs from your site appeared in positions 5 and 9. Previously, we would have averaged all these positions together and shown an Average Position of 7. Going forward, we’ll only average the highest position your site appeared in for each search (3 for Nick’s search and 5 for Jane’s search), for an Average Position of 4.

We anticipate that this new method of calculation will more accurately match your expectations about how a link's position in Google Search results should be reported.

How will this affect my Top Search Queries data?
This change will affect your Top Search Queries data going forward. Historical data will not change. Note that the change in calculation means that the Average Position metric will usually stay the same or decrease, as we will no longer be averaging in lower-ranking URLs.

Check out the updated Top Search Queries data in the Your site on the web section of Webmaster Tools. And remember, you can also download Top Search Queries data programmatically!

We look forward to providing you a more representative picture of your Google Search data. Let us know what you think in our Webmaster Forum.

Posted by Chris Anderson, Google Analytics team, and Susan Moskwa, Webmaster Trends Analyst

Webmaster Level: Intermediate

One of the biggest bottlenecks on any conversion funnel is filling out an online form – shopping and registration flows all rely on forms as a crucial and demanding step in accomplishing the goals of your site. For many users, online forms mean repeatedly typing common information like our names and addresses on different sites across the web – a tedious task that causes many to give up and abandon the flow entirely.

Chrome’s Autofill and other form-filling providers help to break down this barrier by remembering common profile information and pre-populating the form with those values. Unfortunately, up to now it has been difficult for webmasters to ensure that Chrome and other form-filling providers can parse their form correctly. Some standards exist; but they put onerous burdens on the implementation of the website, so they’re not used much in practice.

Today we’re pleased to announce support in Chrome for an experimental new “autocomplete type” attribute for form fields that allows web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’. With this attribute, web developers can drive conversions on their sites by marking their forms for auto-completion without changing the user interface or the backend.


Just add an attribute to the input element, for example an email address field might look like:

<input type=”text” name=”field1” x-autocompletetype=”email” />

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!

Posted by Ilya Sherman, Software Engineer

(Publicado originariamente en Google Webmaster Central Blog, traducido y compartido aquí para todos nuestros webmasters)

Como parte de nuestro continuo esfuerzo por ayudaros a encontrar sitios web de calidad en los resultados de búsqueda, hemos realizado un cambio algorítmico que se centra específicamente en el diseño de una página web y en la cantidad de contenido que se ve en la página al hacer clic en un resultado.

Como hemos indicado en otras ocasiones [inglés], los usuarios se han quejado varias veces de que, al hacer clic en un resultado, era difícil encontrar el contenido en la página. Los usuarios quieren ver el contenido directamente sin tener que desplazarse por la página pasando por un montón de anuncios. Por eso, este cambio puede influir en los sitios que no tienen mucho contenido en la mitad superior de la página. Esto significa que, si un usuario hace clic en un sitio web y lo primero que ve no incluye mucho contenido y está dedicado en su mayor parte a anuncios, esto no es una buena experiencia para él. Este tipo de sitios puede que no se posicionen tan bien de ahora en adelante.

Sabemos que incluir anuncios en la mitad superior de la página es una práctica muy común para muchos sitios web (frecuentemente, estos anuncios dan buenos resultados y ayudan a los editores a rentabilizar el contenido online). Este cambio algorítmico no influye en los sitios que contienen una cantidad normal de anuncios en la mitad superior de la página sino principalmente en aquellos sitios que tienen una verdadera sobrecarga de anuncios ubicados en esta parte y que dificulta la localización del contenido real de la página. La mejora en el algoritmo influye en los sitios que tienen poco contenido o contenido no visible en la mitad superior de la página o en los sitios cuyo contenido relevante está oculto por anuncios de forma persistente.

Este cambio algorítmico se aplicará de una forma perceptible en menos del 1% de las búsquedas globales, lo que significa que, en menos de una de cada 100 búsquedas, un usuario estándar podría observar una reorganización de los resultados que aparecen en la página de búsqueda. Si crees que el cambio del algoritmo de diseño de página ha afectado a tu sitio web, piensa en cómo está organizado el espacio de la mitad superior de las páginas del sitio y si el contenido de las páginas está oculto o es difícil acceder a él por cualquier otro motivo. Puedes utilizar Browser Size, entre otras muchas herramientas, para ver el aspecto que podría tener tu sitio web con diferentes resoluciones de pantalla.

Si decides actualizar el diseño de la página, el algoritmo de diseño de página reflejará automáticamente los cambios cuando Google vuelva a rastrear y procesar un número de páginas del sitio que sea suficiente para evaluar los cambios. La duración de ese proceso dependerá de múltiples factores, entre los que se incluyen el número de páginas del sitio y el nivel de eficacia con el que Googlebot pueda rastrear el contenido. El tiempo de duración para un sitio web normal puede ser de varias semanas.

En general, nuestro consejo para los editores sigue siendo que se centren en ofrecer la mejor experiencia posible a los usuarios [inglés] en sus sitios web, no en mejoras algorítmicas específicas. Este cambio representa solo una de las más de 500 mejoras que esperamos llevar a cabo este año en las búsquedas. Como siempre, te agradecemos cualquier comentario o pregunta que quieras publicar en el Foro de ayuda para webmasters.

Publicado por Matt Cutts, ingeniero de software

Webmaster Level: All

In our ongoing effort to help you find more high-quality websites in search results, today we’re launching an algorithmic change that looks at the layout of a webpage and the amount of content you see on the page once you click on a result.

As we’ve mentioned previously, we’ve heard complaints from users that if they click on a result and it’s difficult to find the actual content, they aren’t happy with the experience. Rather than scrolling down the page past a slew of ads, users want to see content right away. So sites that don’t have much content “above-the-fold” can be affected by this change. If you click on a website and the part of the website you see first either doesn’t have a lot of visible content above-the-fold or dedicates a large fraction of the site’s initial screen real estate to ads, that’s not a very good user experience. Such sites may not rank as highly going forward.

We understand that placing ads above-the-fold is quite common for many websites; these ads often perform well and help publishers monetize online content. This algorithmic change does not affect sites who place ads above-the-fold to a normal degree, but affects sites that go much further to load the top of the page with ads to an excessive degree or that make it hard to find the actual original content on the page. This new algorithmic improvement tends to impact sites where there is only a small amount of visible content above-the-fold or relevant content is persistently pushed down by large blocks of ads.

This algorithmic change noticeably affects less than 1% of searches globally. That means that in less than one in 100 searches, a typical user might notice a reordering of results on the search page. If you believe that your website has been affected by the page layout algorithm change, consider how your web pages use the area above-the-fold and whether the content on the page is obscured or otherwise hard for users to discern quickly. You can use our Browser Size tool, among many others, to see how your website would look under different screen resolutions.

If you decide to update your page layout, the page layout algorithm will automatically reflect the changes as we re-crawl and process enough pages from your site to assess the changes. How long that takes will depend on several factors, including the number of pages on your site and how efficiently Googlebot can crawl the content. On a typical website, it can take several weeks for Googlebot to crawl and process enough pages to reflect layout changes on the site.

Overall, our advice for publishers continues to be to focus on delivering the best possible user experience on your websites and not to focus on specific algorithm tweaks. This change is just one of the over 500 improvements we expect to roll out to search this year. As always, please post your feedback and questions in our Webmaster Help forum.

Posted by Matt Cutts, Distinguished Engineer

Acabo de descubrirlo. Por pura casualidad. Hasta ahora El informe de tiempo real de Google Analytics nos daba información en bruto, la información era la que era... y punto. Pues bien. Esta mañana, por casualidad, dando al botoncito que no debía he conseguido ver la información en tiempo real de los usuarios nuevos, y luego de los que venían de tráfico orgánico, etc... un divertimento muy entretenido... y útil.  ¿Cómo se hace? de la manera mas simple del mundo. Si queremos ver cómo va el tráfico de los nuevos visitantes sólo tenemos que ir a la página principal del informe y "clicar" en la barrita de "nuevos - recurrentes"  y obtendremos la información deseada. Arriba a la derecha nos sale un cartelito que nos indica la información que estamos viendo:
Pero aún hay más. ¿Qué pasa si lo que queremos ver son los activos nuevos que vienen de tráfico de referencia? Sólo tienes que pedirlo. Vas al apartado "FUENTES DE TRÁFICO" y en la barrita "clicas" en tráfico de referencia... Arriba a la derecha te indicará lo que estás viendo:


Ahora ya puedes navegar por el informe todo lo que quieras, la información que verás será sólo la que has elegido... y no otra.
Esto es todo por hoy... por cierto ¿has comprado ya mi libro "Analítica web con Google Analytics?"

El otro día mostré en directo los pasos a seguir para hacer un mapa de calor de visitas por hora y por día de la semana con excel. Debí explicarlo muy rápido, porque  @sofisticlara tuvo que grabarlo con el iphone y hoy @noe me ha preguntado "Y eso ¿cómo se hace?" (por cierto, a ver si me pasáis la grabación) Bueno, vamos paso a paso, que no es difícil. Los pasos a seguir son:

1. Importar los datos de Google Analytics a Excel ( lo haremos de forma que los Mac-eros también puedan)
2. Preparamos los datos
3. Creamos una tabla( dinámica con los datos)
4. Utilizamos "formato condicional" y..
5. ¡ya tenemos el mapa!

        En Google analytics tenemos que situarnos en el gráfico principal (Público->Visión general) y hacer dos selecciones. La primera es de fechas. Seleccionamos una semana completa. La segunda acción es modificar la visualización del gráfico. deberemos seleccionar la visualización por Hora.
Una vez tenemos todo OK, exportamos a  "Csv para Excel" y GUARDAMOS EL ARCHIVO no abrimos directamente Excel. Para importar los datos de la forma correcta debemos ir a DATOS->DESDE TEXTO, Y seleccionar en el cuadro que nos sale "DATOS SEPARADOS POR COMAS".

Después de hacer esto tendremos dos columnas, una con las horas y otra con las visitas.si os fijáis bien las horas van de 0 a 167.Si tenemos en cuenta que cada día tiene 24 horas, algo no cuadra ¿no? Pues sí, si cuadra. de 0 a 23 es el lunes a partir de 24 es el martes... y así tendremos los 7 días de la semana con intervalos de 24 horas.. Ordenemos estos datos para obtener lo que queremos. Lo primero las horas.  En la columna horas, de 0 a 23, no hacemos nada, pero en la 24 volvemos a poner 0 y en la siguiente 2, y 3, etc hasta llegar a 23, que volvemos a empezar. Una vez completada esta "dura tarea de ctrl+c - ctrl+v " creamos una nueva columna donde ponemos el nombre del día ( lunes, martes, etc). De ésta forma ya tenemos tres columnas con toda la información de días de la semana, horas y visitas( o rebote, o nuevas visitas, o lo que queramos) Ahora llega un momento glorioso.. Hacer una tabla dinámica que organice los datos en filas y columnas. Las filas serán los días de la semana y las columnas las horas del día...
Nos vamos a INSERTAR-TABLA DINÁMICA, en el cuadro seleccionamos las tres columnas de datos enteras y ponemos "etiquetas de columnas = hora", "etiquetas de filas = días" y en "valores=suma de visitas" nos quedaría algo así...


Ya sólo nos queda un paso, poner colorines. Ésto se consigue con el "FORMATO CONDICIONAL". Seleccionamos  una fila de días, y vamos a "formato condicional"-> "escalas de color"...



Es importante que seleccionéis fila a fila, no todo junto, así os aseguráis de que los colores indican lo que queremos... Después de hacer esto ya tenéis vuestro mapa de calor. Como podréis comprobar, en mi caso, los días de la semana quedan desordenado... no he sido capaz de ponerlo por orden, si alguien se anima...
Espero que os sirva...
Por cierto ¿has comprado ya mi libro "Analítica web con google analytics" ?