Posicionamiento en buscadores

Engaging users through high quality AMP pages

Google herramientas para webmaster - Jue, 16/11/2017 - 18:05

To improve our users' experience with AMP results, we are making changes to how we enforce our policy on content parity with AMP. Starting Feb 1, 2018, the policy requires that the AMP page content be comparable to the (original) canonical page content. AMP is not a ranking signal and there is no change in terms of the ranking policy with respect to AMP.

The open source accelerated mobile pages project (AMP) launched in 2015 and has seen tremendous growth with over 25M domains having implemented the AMP format. This rapid progress comes with a sense of responsibility of ensuring that our users continue to have a great content consumption experience that ultimately leads to more engagement with publisher content.

In some cases, webmasters publish two versions of their content: a canonical page that is not based on AMP and an AMP page. In the ideal scenario, both these pages have equivalent content leading the user to get the same content but with a faster and smoother experience via AMP.  However, in some cases the content on the AMP page does not match the content on its original (canonical) page.

In a small number of cases, AMP pages are used as teaser pages which create a particularly bad user experience since they only contain minimal content. In these instances, users have to click twice to get to the real content. Below is an example of how this may look like: a brief text of the main article and then asking the user to click to visit another page to complete reading the article.

AMP was introduced to dramatically improve the performance of the web and deliver a fast, consistent content consumption experience. In keeping with this goal, we'll be enforcing the requirement of close parity between AMP and canonical page, for pages that wish to be shown in Google Search as AMPs.

Where we find that an AMP page doesn't contain the same critical content as its non-AMP equivalent, we will direct our users to the non-AMP page. This does not affect Search ranking. However, these pages will not be considered for Search features that require AMP, such as the Top Stories carousel with AMP. Additionally, we will notify the webmaster via Search console as a manual action message and give the publisher the opportunity to fix the issue before its AMP page can be served again. The AMP open source website has several helpful guides to help produce fast, beautiful and high-performing AMP pages.

We hope this change encourages webmasters to maintain content parity between the canonical and AMP equivalent. This will lead to better experience on your site and ultimately happier users.


Posted by Ashish Mehta, Product Manager

Make your site's complete jobs information accessible to job seekers

Google herramientas para webmaster - Mié, 15/11/2017 - 13:00

In June, we announced a new experience that put the convenience of Search into the hands of job seekers. Today, we are taking the next step in improving the job search experience on Google by adding a feature that shows estimated salary information from the web alongside job postings, as well as adding new UI features for users.

Salary information has been one of the most requested additions from job seekers. This helps people evaluate whether a job is a good fit, and is an opportunity for sites with estimated salary information to:

  • Increase brand awareness: Estimated salary information shows a representative logo from the estimated salary provider.
  • Get more referral traffic: Users can click through directly to salary estimate pages when salary information surfaces in job search results.

If your site provides salary estimates, you can take advantage of these changes in the following ways:

Specify actual salary information

Actual salary refers to the base salary information that is provided by the employer. If your site publishes job listings, you can add JobPosting structured data and populate the baseSalary property to be eligible for inclusion in job search results.

This salary information will be made available in both the list and the detail views.

Provide estimated salary information

In cases where employers don’t provide actual salary, job seekers may see estimated salaries sourced from multiple partners for the same or similar occupation. If your site provides salary estimate information, you can add Occupation structured data to be eligible for inclusion in job search results.  

Include exact location information

We've heard from users that having accurate, street-level location information helps them to focus on opportunities that work best for them. Sites that publish job listings can do this can do this by using the jobLocation property in JobPosting structured data.

Validate your structured data

To double-check the structured data on your pages, we'll be updating the Structured Data Testing Tool and the Search Console reports in the near future. In the meantime, you can monitor the performance of your job postings in Search Analytics. Stay tuned!

Since launching this summer, we’ve seen over 60% growth in number of companies with jobs showing on Google and connected tens of millions of people to new job opportunities. We are excited to help users find jobs with salaries that meet their needs, and to route them to your site for more information. We invite sites that provide salary estimates to mark up their salary pages using the Occupation structured data. Should you have any questions regarding the use of structured data on your site, feel free to drop by our webmaster help forums.


Posted by Nick Zakrasek, Product Manager

Enabling more high quality content for users

Google herramientas para webmaster - Lun, 02/10/2017 - 06:09

In Google’s mission to organize the world's information, we want to guide Google users to the highest quality content, the principle exemplified in our quality rater guidelines. Professional publishers provide the lion’s share of quality content that benefits users and we want to encourage their success.

The ecosystem is sustained via two main sources of revenue: ads and subscriptions, with the latter requiring a delicate balance to be effective in Search. Typically subscription content is hidden behind paywalls, so that users who don’t have a subscription don’t have access. Our evaluations have shown that users who are not familiar with the high quality content behind a paywall often turn to other sites offering free content. It is difficult to justify a subscription if one doesn't already know how valuable the content is, and in fact, our experiments have shown that a portion of users shy away from subscription sites. Therefore, it is essential that sites provide some amount of free sampling of their content so that users can learn how valuable their content is.

The First Click Free (FCF) policy for both Google web search and News was designed to address this issue. It offers promotion and discovery opportunities for publishers with subscription content, while giving Google users an opportunity to discover that content. Over the past year, we have worked with publishers to investigate the effects of FCF on user satisfaction and on the sustainability of the publishing ecosystem. We found that while FCF is a reasonable sampling model, publishers are in a better position to determine what specific sampling strategy works best for them. Therefore, we are removing FCF as a requirement for Search, and we encourage publishers to experiment with different free sampling schemes, as long as they stay within the updated webmaster guidelines. We call this Flexible Sampling.

One of the original motivations for FCF is to address the issues surrounding cloaking, where the content served to Googlebot is different from the content served to users. Spammers often seek to game search engines by showing interesting content to the search engine, say healthy food recipes, but then showing users an offer for diet pills. This “bait and switch” scheme creates a bad user experience since users do not get the content they expected. Sites with paywalls are strongly encouraged to apply the new structured data to their pages, because without it, the paywall may be interpreted as a form of cloaking, and the pages would then be removed from search results.

Based on our investigations, we have created detailed best practices for implementing flexible sampling. There are two types of sampling we advise: metering, which provides users with a quota of free articles to consume, after which paywalls will start appearing; and lead-in, which offers a portion of an article’s content without it being shown in full.

For metering, we think that monthly (rather than daily) metering provides more flexibility and a safer environment for testing. The user impact of changing from one integer value to the next is less significant at, say, 10 monthly samples than at 3 daily samples. All publishers and their audiences are different, so there is no single value for optimal free sampling across publishers. However, we recommend that publishers start by providing 10 free clicks per month to Google search users in order to preserve a good user experience for new potential subscribers. Publishers should then experiment to optimize the tradeoff between discovery and conversion that works best for their businesses.

Lead-in is generally implemented as truncated content, such as the first few sentences or 50-100 words of the article. Lead-in allows users a taste of how valuable the content may be. Compared to a page with completely blocked content, lead-in clearly provides more utility and added value to users.

We are excited by this change as it allows the growth of the premium content ecosystem, which ultimately benefits users. We look forward to the prospect of serving users more high quality content!


Posted by Cody Kwok, Principal Engineer

Cómo pasar de las URL para móviles a un sitio web adaptable

Blog oficial de Google para Webmasters - Vie, 15/09/2017 - 17:05
Como resultado de la creciente conversión de muchos sitios web a un diseño web adaptable, a muchos webmasters les surgen dudas sobre la migración de las URL independientes para móviles al uso de un diseño web adaptable. A continuación te presentamos algunas recomendaciones para pasar de URL independientes para móviles a una URL adaptable, de modo que tus sitios web tengan más posibilidades de ofrecer un buen rendimiento en los resultados de búsqueda de Google.

Conversión a sitios web adaptables compatible con el robot de GoogleCuando tengas listo tu sitio web adaptable, la conversión es algo que podrás hacer con simplemente un poco de previsión. Teniendo en cuenta que las URLs serán las mismas que las de la versión para ordenadores, lo único que tienes que hacer es configurar redireccionamientos 301 de las URL para móviles a las del diseño web adaptable.Estos son los pasos detallados:

  1. Prepara tu sitio web adaptable.
  1. Configura redireccionamientos 301 en las URL para móviles antiguas para que apunten a las versiones adaptables (las páginas nuevas). Estos redireccionamientos se deben llevar a cabo por separado para cada URL para móviles apuntando a las URL adaptables.
  1. Quita toda la configuración específica de URL para móviles que tenga tu sitio web, como los redireccionamientos condicionales o un encabezado HTTP variable.
  2. Te recomendamos que configures enlaces rel=canonical en las URL adaptables que apunten a sí mismos (URL canónicas que hacen referencia a sí mismas).

Si actualmente utilizas la publicación dinámica y quieres cambiar al diseño adaptable, no es necesario que añadas ni cambies ningún redireccionamiento.

Algunas ventajas de la conversión al diseño web adaptableLa conversión a un sitio web adaptable debería terminar simplificando considerablemente el mantenimiento y la generación de informes. Además de no necesitar gestionar URL independientes para todas las páginas, te resultará también mucho más fácil adoptar prácticas y tecnologías como hreflang para la internacionalización o AMP para datos de velocidad estructurados para funciones de búsqueda avanzadas, entre otros.

Como siempre, si necesitas más ayuda, puedes publicar una pregunta en el foro para webmasters.


Escrito por Cherry Prommawin (Relaciones con webmasters). Publicado por Joan Ortiz, equipo de calidad de búsqueda.

How to move from m-dot URLs to responsive site

Google herramientas para webmaster - Jue, 14/09/2017 - 23:32

With more sites moving towards responsive web design, many webmasters have questions about migrating from separate mobile URLs, also frequently known as "m-dot URLs", to using responsive web design. Here are some recommendations on how to move from separate urls to one responsive URL in a way that gives your sites the best chance of performing well on Google's search results.

Moving to responsive sites in a Googlebot-friendly way

Once you have your responsive site ready, moving is something you can definitely do with just a bit of forethought. Considering your URLs stay the same for desktop version, all you have to do is to configure 301 redirects from the mobile URLs to the responsive web URLs.

Here are the detailed steps:

  1. Get your responsive site ready
  2. Configure 301 redirects on the old mobile URLs to point to the responsive versions (the new pages). These redirects need to be done on a per-URL basis, individually from each mobile URLs to the responsive URLs.
  3. Remove any mobile-URL specific configuration your site might have, such as conditional redirects or a vary HTTP header.
  4. As a good practice, setup rel=canonical on the responsive URLs pointing to themselves (self-referential canonicals).

If you're currently using dynamic serving and want to move to responsive design, you don't need to add or change any redirects.

Some benefits for moving to responsive web design

Moving to a responsive site should make maintenance and reporting much easier for you down the road. Aside from no longer needing to manage separate URLs for all pages, it will also make it much easier to adopt practices and technologies such as hreflang for internationalization, AMP for speed, structured data for advanced search features and more.

As always, if you need more help you can ask a question in our webmaster forum.

Posted by Cherry Prommawin, Webmaster Relations .blogimg img { width: 100%; border: 0; margin: 0; padding: 10px 0 10px 0; }

Los próximos pasos para lograr una conexión más segura

Blog oficial de Google para Webmasters - Mar, 29/08/2017 - 09:44
En enero, dimos los primeros pasos (entrada en Inglés) para mejorar cómo se indica la seguridad de las conexiones de las páginas HTTP en Chrome. Actualmente, las páginas HTTP solo se marcan como no seguras si contienen campos de contraseña o de tarjeta de crédito. Sin embargo, a partir de octubre del 2017, también se marcarán como no seguras en otras dos situaciones: cuando deban introducirse datos y cuando se visiten en modo incógnito.Nuestro objetivo de etiquetar todos los sitios web HTTP como no seguros según unos criterios cada vez más amplios se va cumpliendo de forma gradual. Desde que aplicamos el cambio en Chrome 56, se han reducido en un 23% las visitas a páginas HTTP con campos de contraseña o de tarjeta de crédito en ordenadores. Pero estamos listos para dar un paso más.Las contraseñas y las tarjetas de crédito no son los únicos datos que deben ser privados. Ningún usuario de la red debería poder acceder a la información que se introduce en un sitio web, por lo que, a partir de la versión 62 de Chrome, se mostrará la advertencia No es seguro cuando se introduzcan datos en sitios web HTTP.
Es probable que los usuarios que naveguen usando el modo incógnito de Chrome crean tener un nivel de privacidad superior. Sin embargo, la navegación HTTP no protege los datos, por lo que en la versión 62 también se marcarán como no seguras las páginas HTTP que se visiten en modo incógnito.


Nuestra intención es mostrar la advertencia “No es seguro” en todas las páginas HTTP, se use el modo incógnito o no. A medida que publiquemos versiones nuevas, iremos actualizando la información. No obstante, te recomendamos que utilices HTTPS cuanto antes, ya que implementarlo es más fácil y más barato que nunca y, además, proporciona el mejor rendimiento posible en la Web, así como funciones nuevas que usan datos confidenciales, por lo que no deberían utilizarse con HTTP. Para empezar, consulta nuestras guías de configuración.





Escrito por Emily Schechter, del equipo de Seguridad de Chrome. Publicado por Joan Ortiz, equipo de Calidad de Búsqueda.

Introducing Our New International Webmaster Blogs!

Google herramientas para webmaster - Mié, 23/08/2017 - 22:02

Join us in welcoming the latest additions to the Webmasters community:

नमस्ते Webmasters in Hindi!

Добро Пожаловать Webmasters in Russian!

Hoşgeldiniz Webmasters in Turkish!

สวัสดีค่ะ Webmasters in Thai!

xin chào Webmasters in Vietnamese!

We will be sharing webmaster-related updates in our current and new blogs to make sure you have a place to follow the latest launches, updates and changes in Search in your languages! We will share links to relevant Help resources, educational content and events as they become available.

Just a reminder, here are some of the resources that we have available in multiple languages:

  • Google.com/webmasters - documentation, support channels, tools (including a link to Search Console) and learning materials.
  • Help Center - tips and tutorials on using Search Console, answers to frequently asked questions and step-by-step guides.
  • Help forum - ask your questions and get advice from the Webmaster community
  • YouTube Channel - recordings of Hangouts on Air in different languages are on our
  • G+ community - another place we announce and share our Hangouts On Air

Testing tools:

Some other valuable resources (English-only):

If you have webmaster-specific questions, check our event calendar for the next hangout session or live event! Alternatively, you can post your questions to one of the local help forum, where our talented Product Experts from the TC program will try to answer your questions. Our Experts are product enthusiasts who have earned the distinction of "Top Contributor," or "Rising Star," by sharing their knowledge on the Google Help Forums.

If you have suggestions, please let us know in the comments below. We look forward to working with you in your language!

.blogimg img { width: 100%; border: 0; margin: 0; padding: 0 0 10px 0; }

La nueva Search Console - Un vistazo sobre dos nuevas prestaciones experimentales

Blog oficial de Google para Webmasters - Lun, 21/08/2017 - 20:48

Search Console se lanzó de forma oficial ahora hace más de 10 años. Hoy incluye más de 25 herramientas e informes cubriendo AMP, datos estructurados y herramientas de pruebas en tiempo real, todo ello diseñado para ayudar a mejorar el rendimiento de tu sitio.

Ahora hemos decidido embarcarnos en una revisión de considerable envergadura para mejorar Search Console. Esto es lo que esperamos obtener con estos cambios:

  • Información más accionable - Vamos a agrupar los errores que identifiquemos en base a lo que pensemos que es su causa común, y así ayudarte a identificar las soluciones que debes implementar. Organizaremos estos errores en “tareas” que tienen un estado para ayudarte a saber si el problema está todavía presente o si Google ha detectado la solución que hayas implementado. También podrás seguir el progreso de las páginas afectadas.


  • Mejor soporte para tu organización - Después de hablar con numerosas organizaciones, hemos aprendido que normalmente hay múltiples personas involucradas en implementar, diagnosticar y arreglar los problemas de los sitios web. Por ésta razón vamos a introducir una funcionalidad para compartir que te permite escoger una tarea y compartirla con el resto del grupo.


  • Comunicación más rápida entre tú y Google - Hemos creado un mecanismo que te permite iterar de forma rápida sobre los cambios que implementes, de forma que no tengas que esperar a que Google vuelva a rastrear tu sitio para que después te diga que el problema no está arreglado. Vamos a proporcionar una funcionalidad de “prueba en el momento” que provocará un rastreo automático una vez que veamos que todo funciona bien. Del mismo modo, la herramienta de pruebas incluirá fragmentos de código y una vista previa - para que puedas ver de forma rápida dónde está el problema, confirmar que está arreglado y comprobar cómo se verán las páginas en la búsqueda.


Durante las semanas siguientes, vamos a lanzar does funcionalidades BETA de la nueva Search Console para un reducido grupo de usuarios: el “Index Coverage Report” y el “AMP fixing flow”.



1. “Inex Coverage Report”Este informe muestra el número de páginas indexadas en tu sitio, información sobre porqué algunas de ellas no se pudieron indexar, así como ejemplos de páginas y consejos sobre cómo solucionar problemas de indexación. También incorpora la opción de subir un sitemap y la posibilidad de filtrar los datos de cobertura de índice usando sitemaps que hayas subido.Aquí tienes una vista previa del “Index Coverage Report”:


2. El nuevo “AMP fixing flow”La nueva experiencia para arreglar problemas con AMP comienza con el informe de AMP. Este informe muestra las incidencias que están afectando tu sitio, agrupadas por el error que las causa. De forma que puedes investigar con más profundidad para obtener más detalles sobre el error en cuestión, incluyendo ejemplos de páginas afectadas. Una vez arreglado el error, haz click en un botón para verificar si ya está solucionado y mandar a Google rastrear de nuevo las páginas afectadas por la incidencia. Google te notificará del progreso del rastreo, y actualizará el informe a medida que tus cambios sean validados.



A medida que empecemos a experimentar con estas nuevas funcionalidades, algunos usuarios verán este nuevo diseño a lo largo de las próxima semanas.
Escrito por John Mueller y el equipo de Search Console. Publicado por Joan Ortiz, equipo de calidad de búsqueda.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer