Notícies SEO

Hoy presentamos la compatibilidad con el marcado schema.org para los logotipos de organizaciones, una forma de conectar tu sitio con una imagen icónica. Queremos que puedas especificar la imagen que debemos usar como tu logotipo en los resultados de búsqueda de Google.

Mediante la Organization markup, de schema.org, puedes indicar a nuestros algoritmos la ubicación de tu logotipo preferido. Por ejemplo, una empresa cuya página principal sea www.example.com puede agregar el siguiente marcado con los elementos de página visibles de dicha página principal:

<div itemscope itemtype="http://schema.org/Organization"> 
  <a itemprop="url" href="http://www.example.com/">Inicio</a>
  <img itemprop="logo" src="http://www.example.com/logo.png" />
</div>

Este ejemplo indica a Google que esta imagen corresponde al logotipo de organización de la página principal que también se incluye en el marcado y que, siempre que sea posible, se debe usar en los resultados de búsqueda de Google. Este tipo de marcado es una señal muy potente para ayudar a que nuestros algoritmos muestren esta imagen de forma preferencial por encima de otras, por ejemplo al mostrar el Knowledge Graph a la derecha basado en las consultas de los usuarios.

Y como siempre, no dudes en exponernos tus preguntas en el Foro de ayuda para webmasters.


Escrito por RJ Ryan, Google Engineer Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Las páginas principales de los sitios web multinacionales y multilingües a veces están configuradas para dirigir los usuarios a páginas localizadas, ya sea a través de redirecciones o cambiando el contenido para reflejar el idioma del usuario.
Hoy vamos a presentar una nueva anotación rel-alternate-hreflang compatible con Google y Yandex que el webmaster puede utilizar para especificar dichas páginas web

Para ver esto en acción, vamos a ver un ejemplo. El sitio web example.com tiene contenido dirigido a usuarios de todo el mundo de la siguiente manera:

Error 1. rel = canonical en la primera página de una serie paginada

Imagina que tienes un artículo que abarca varias páginas:

• example.com / articulo? story = cupcake-news & page = 1
• example.com / articulo? story = cupcake-news & page = 2
• ... etcétera

Especificar un rel = canonical de la página 2 (o cualquier otra página posterior) a la página 1 no es correcto uso de rel = canonical, ya que no son páginas duplicadas. El uso del rel = canonical aquí causaría que el contenido de las páginas 2 y más adelante no se indexen en absoluto.

El contenido (por ejemplo,“cookies are superior nutrition” and “to vegetables”) se pierde cuando se especifica rel = canonical de la segunda y tercera páginas a la primera página de la serie.

En los casos de contenido paginado, se recomienda o que el rel = canonical en las páginas de la serie apunten a una versión en una sola página del artículo, o utilizar el marcado paginación rel = "prev" y rel = "next".

rel = canonical en páginas de una serie apuntando a la vista única de las páginas

Si rel = canonical para vista única de las todas las páginas no se designa, se puede utilizar el contenido paginado rel = "prev" y rel = markup "siguiente".

Error 2. URL absolutas escritas erróneamente como direcciones URL relativas


La etiqueta <link>, al igual que muchas etiquetas HTML, acepta tanto URLs relativas como absolutas . URLs relativas incluyen una ruta "relativa" a la página en concreto. Por ejemplo, "images / cupcake.png" indica como ir "desde el directorio actual al subdirectorio "images" , y luego a "cupcake.png". URL absolutas especificar la ruta completa, incluyendo el http://.

Especificando <link rel=canonical href="example.com/cupcake.html" /> (URL relativa, ya que no tiene "http://") implica que la URL canónica elegida es http://example.com/example.com/cupcake.html a pesar de que es casi seguro que no era esa la intención. En estos casos, los algoritmos pueden ignorar el rel = canonical especificado. En última instancia, esto significa que lo que esperabas lograr con el rel = canonical no funcionará.

Error 3. Designaciones no intencionadas o múltiples designaciones del rel = canonical

De vez en cuando, vemos designaciones rel = canonical que creemos que no son intencionadas. En casos muy raros, vemos algún error tipográfico, pero más comúnmente vemos que algún webmaster con poco tiempo o algo de prisa copia una plantilla de una página web sin cambiar el objetivo del rel = canonical. Lo que hace que las páginas del sitio con el rel = canonical de esos webmasters apunten al sitio del autor plantilla.

Si utilizas una plantilla, asegúrete de que no copias también la especificación rel = canonical.

Otro problema puede ocurrir cuando las páginas incluyen varios enlaces rel = canónica a diferentes URL. Esto ocurre con frecuencia cuando se combinan plugins SEO que a menudo insertan un enlace rel = canonical predeterminado, posiblemente sin el conocimiento del webmaster que ha instalado el plugin. En los casos al haber múltiples declaraciones de rel = canonical, Google probablemente ignorará todos los rel = canonical causando que cualquier beneficio que un legítimo rel = canonical podría haber ofrecido se pierda.

En ambos tipos de casos, revisar el código fuente de la página te ayudará a corregir el problema. Asegúrate de revisar toda la sección de la cabecera ya que los enlaces rel = canonical pueden encontrarse dispersos.

Comprueba el comportamiento de plugins revisando el código fuente de la página.

Error 4. Categoría o página de destino especifica con un rel = canonical a un artículo destacado

Supongamos que un webmaster tiene un sitio sobre postres. El sitio web tiene páginas con categorías útiles como "pastry" y "gelato". Cada día las páginas de estas categorías cuentan con un artículo destacado único. Por ejemplo, la página de destino de la categoria "pastry" pudo desplegar el artículo de la página "red velvet cupcakes". Debido a que la página de categoría "pastry" tiene casi el mismo contenido que la página "red velvet cupcake”, el webmaster agrega un rel = canonical desde la página de la categoría a la página del artículo individual.

Si aceptáramos esta rel = canonical, entonces la página de la categoría "pastry" no aparecería en los resultados de búsqueda.
Esto debido a que las señales rel = canonical indican a los motores de búsqueda que se prefiere mostrar la URL canónica de la página del artículo individual en lugar del duplicado. Sin embargo, si se desea que los usuarios puedan encontrar tanto la página de la categoría como el artículo destacado, lo mejor es tener sólo una auto-referencia rel = canonical a la página de la categoría, o ninguna en absoluto.

Recuerda que la designación canónica también implica la URL preferida para ser mostrada. Evita agregar un rel = canonical de una página de categoría o el aterrizaje de un artículo destacado.

Error 5. rel = canonical en el <body>

La etiqueta de enlace rel = canonical sólo debería aparecer en el "<head>" (cabecera) de un documento HTML. Además, para facilitar el análisis del HTML, es bueno incluir el atributo rel = canonical tan pronto como sea posible en el <head>. Cuando nos encontramos con una designación rel = canonical en el <body>, no se tiene en cuenta.

Esto es un error fácil de corregir. Simplemente revisa que tus enlaces rel = canonical están siempre en el <head> de tu página, y tan pronto como sea posible.

Las designaciones rel = canonical en el <head> son procesados, en el <body> no.

Conclusión

Para crear buenas designaciones rel=canonical :

• Comprueba que la mayor parte del contenido del texto principal de la página duplicada también aparece en la página canónica.
• Comprueba que el rel = canonical sólo se especifica una vez y se encuentra en el <head> de la página.
• Comprueba que el rel = canonical apunta a una URL existente y con buen contenido (es decir, no es un 404, o peor aún, un "soft" 404).
• Evita el uso del rel = canonical en las páginas de destino o categorías con artículos destacados ya que hará que el artículo destacado sea la URL preferida en los resultados de búsqueda.

Y, como siempre, por favor ante cualquier duda, pregunta en nuestro foro de ayuda para webmasters.


Escrito por Allan Scott, Software Engineer, Indexing Team, Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Desde el lanzammiento de la Academia para Webmasters en Inglés en mayo del 2012, sus consejos y contenido educativo han sido vistos más de 1 millón de veces.

La Academia para Webmasters fue creada para guiar a los webmasters en la creación de sitios web,  funcionen bien en los resultados de búsqueda de Google.

La academia para webmasters no es tan solo una buena guía para webmasters principiantes , sino también una lectura recomendada para los usuarios experimentados que deseen aprender más sobre temas avanzados.


Escrito por Giacomo Gnecchi Ruscone, equipo de Calidad de búsqueda. Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Para ayudar a los webmasters a gestionar los propietarios que han sido verificados en sus sitios web en las Herramientas para webmasters de Google, recientemente hemos introducido tres nuevas características:

Vista de los detalles de verificación: Ahora puedes ver los métodos utilizados para verificar a los propietario de tu sitio web. En el apartado "Administrar propietarios de tu sitio", se puede encontrar el nuevo enlace a los detalles verificación.

En estas capturas de pantalla se muestra los detalles de verificación de dos usuarios que han sido verificados utilizando una meta etiqueta y un archivo HTML :

En algunas ocasiones, los detalles de verificación tendrán enlaces a la URL de tu sitio donde se encuentra el elemento utilizado en el proceso de verificación para ayudarte a encontrarlo más rápidamente.

Antes de desautorizar a un propietario se pide como requisito que el método de verificación haya sido eliminado del sitio web: Ahora es necesario eliminar el elemento de verificación del sitio antes de desautorizar a un propietario en las Herramientas para webmasters.
Las Herramientas para webmasters, revisan el método que el propietario utilizó para verificar la propiedad del sitio, y mostrarán un mensaje de error si el elemento de verificación aún no se ha eliminado.
Este es un ejemplo del mensaje de error que se muestra cuando se intenta eliminar a un usuario pero la meta etiqueta aún esta activa en el dominio:

Hemos modificado ligeramente el método de verificación CNAME para que sea más corto y para incluir a un mayor número de proveedores de DNS. Algunos sistemas limitan el número de caracteres que se pueden utilizar en los registros DNS, lo que ha podido causar que algunos usuarios no pudieran utilizar el método de verificación CNAME. Los actuales metodos verificaciones CNAME seguirán siendo válidos, pero ahora hemos hecho que el método de verificación CNAME tenga un menor número de caracteres. Esperamos que estos cambios faciliten los procesos de verificación de las Herramientas para webmasters.

Y como siempre, por favor, si tienes alguna pregunta o comentario, no dudes en pasarte por el foro para webmasters de Google.