msgbartop
Blog de noticias sobre google.
msgbarbottom

21 Abr 18 La infraestructura de clave pública de Symantec deja de ser de confianza: medidas que deben tomar los operadores de sitios web

Hace un tiempo ya anunciamos que Chrome dejará de confiar en la autoridad de certificación Symantec, incluidas marcas de su propiedad como Thawte, VeriSign, Equifax, GeoTrust y RapidSSL. En esta entrada describimos cómo pueden saber los operadores de sitios web si esta medida les afecta de alguna manera y, en tal caso, qué deben hacer y de cuánto tiempo disponen para hacerlo. Si no se cambian estos certificados, los sitios web podrían dejar de funcionar en nuevas versiones de los navegadores principales, incluido Chrome.


Chrome 66

Si tu sitio web utiliza un certificado SSL/TLS de Symantec expedido antes del 1 de junio del 2016, dejará de funcionar a partir de la versión Chrome 66, por lo que puede que tus usuarios ya se estén viendo afectados.

Si no sabes seguro qué certificado utiliza tu sitio web, puedes comprobar en Chrome Canary si estos cambios te afectan. Si al conectarte a tu sitio web aparece un error de certificado o una advertencia de DevTools como la que se muestra a continuación, debes cambiar de certificado. Puedes conseguir otro de cualquier autoridad de certificación de confianza, como Digicert, que hace poco adquirió la parte de CA de Symantec.

Ejemplo de error de certificado que es posible que vean los usuarios de Chrome 66 si sigues utilizando un certificado antiguo SSL/TLS de Symantec expedido antes del 1 de junio del 2016. 

Mensaje de DevTools que se mostrará si tienes que cambiar tu certificado antes del lanzamiento de Chrome 66.

Chrome 66 ya se ha publicado en los canales para desarrolladores y en Chrome Canary, lo que significa que los usuarios de esos canales de Chrome ya se están viendo afectados en los sitios web que tienen ese certificado. Si no se cambian los certificados antes del 15 de marzo del 2018, los usuarios de Chrome Beta también comenzarán a tener problemas. En el caso de que tu sitio web ya devuelva un error en Chrome Canary, te recomendamos encarecidamente que cambies tu certificado lo antes posible.


Chrome 70

A partir de la versión Chrome 70, todos los certificados SSL/TLS de Symantec dejarán de funcionar, por lo que se mostrará un error de certificado como el que se ha indicado antes. Para comprobar si tu certificado se verá afectado, accede hoy mismo a tu sitio web desde Chrome y abre DevTools; aparecerá un mensaje en el que se te indica si hace falta que lo cambies.
Mensaje que verás en DevTools si tienes que cambiar tu certificado antes de que se publique Chrome 70.

Si ves este mensaje en DevTools, te recomendamos encarecidamente que cambies de certificado lo antes posible. De lo contrario, los usuarios comenzarán a ver errores de certificado en tu sitio web a partir del 20 de julio del 2018. La primera versión beta de Chrome 70 se publicará aproximadamente el 13 de septiembre del 2018.


Plazos previstos de los lanzamientos de Chrome

La siguiente tabla muestra los lanzamientos previstos de la versión de Canary, de la versión beta y de la versión estable de Chrome 66 y 70. La versión de Canary será la primera en la que algunos usuarios podrán encontrarse con este error, que irá alcanzando a más usuarios con los posteriores lanzamientos de la versión beta y, finalmente, de la versión estable. Recomendamos encarecidamente que los operadores de sitios web hagan los cambios necesarios en sus sitios web antes del lanzamiento de la versión de Canary de Chrome 66 y 70 o, como muy tarde, antes de las fechas de lanzamiento de la versión beta correspondiente.
Lanzamiento
Primera versión de Canary
Primera versión beta
Versión estable
Chrome 66
20 de enero del 2018
15 de marzo del 2018 aprox.
17 de abril del 2018 aprox.
Chrome 70
20 de julio del 2018 aprox.
13 de septiembre del 2018 aprox.
16 de octubre del 2018 aprox.


Para obtener más información sobre el lanzamiento de una versión concreta de Chrome, consulta el calendario de desarrollo de Chromium, que se actualizará en caso de que cambie alguna fecha.

Para cubrir las necesidades de algunas empresas, junto con el lanzamiento de Chrome 66, Chrome también implementará una política de empresa que permitirá seguir confiando en la infraestructura de clave pública (PKI) antigua de Symantec. A partir del 1 de enero del 2019, esta política dejará de estar disponible, por lo que todos los usuarios dejarán de confiar en la PKI antigua de Symantec automáticamente.


Mención especial: Chrome 65

Tal y como anunciamos anteriormente, ya se ha dejado de confiar en los certificados SSL/TLS de las PKI antiguas de Symantec expedidos después del 1 de diciembre del 2017. Esta medida no afecta a la mayoría de los operadores de sitios web, ya que para obtener este tipo de certificados hace falta suscribir un contrato especial con DigiCert. En Chrome 65 y versiones posteriores, se mostrará un error y se bloqueará la solicitud cuando se acceda a sitios web con este tipo de certificados. Si quieres que no se den este tipo de errores, comprueba que estos certificados solo se usan en dispositivos antiguos y no en navegadores como Chrome.



Publicado por Devon O’Brien, Ryan Sleevi y Emily Stark, del equipo de Seguridad de Chrome


Source: Google Webmasters

18 Abr 18 La velocidad de las páginas en el posicionamiento de las búsquedas móviles

Varios estudios demuestran que la velocidad es un factor muy importante, ya que los usuarios quieren encontrar respuestas a sus preguntas tan rápido como sea posible. Aunque la velocidad lleva siendo un criterio de posicionamiento desde hace tiempo, solo se usaba en las búsquedas en ordenadores. Hoy anunciamos que, a partir de julio del 2018, la velocidad de las páginas también se tendrá en cuenta a la hora de posicionar resultados en las búsquedas móviles.
Este cambio, que llamamos “actualización de velocidad”, solo afectará a las páginas más lentas y a un pequeño porcentaje de las consultas. Se aplicarán los mismos criterios a todas las páginas, independientemente de la tecnología con la que se hayan diseñado. La intención con la que se hace una consulta de búsqueda seguirá siendo un factor muy importante, así que una página lenta podrá tener una buena posición en los resultados si ofrece contenido pertinente y de calidad.
Animamos a que los programadores tengan en cuenta el modo en que el rendimiento afecta a la experiencia de usuario de sus páginas y a que consulten las diferentes métricas de experiencia de usuario. No hay ninguna herramienta que indique directamente si este nuevo factor afecta a páginas concretas, pero aquí tienes algunos recursos con los que evaluar el rendimiento de tus páginas:
  • Informe Experiencia de Usuario de Chrome: se trata de un conjunto de datos público en el que se facilita información sobre métricas de experiencia de usuario clave de sitios web populares. Estos datos se basan en la experiencia real de usuarios de Chrome.
  • Lighthouse: se trata de una herramienta automatizada que forma parte de las herramientas para desarrolladores de Chrome y con la que puedes medir la calidad (rendimiento, accesibilidad y más) de las páginas web.
  • PageSpeed Insights: se trata de una herramienta que evalúa los datos del rendimiento de una página en el informe Experiencia de Usuario de Chrome y que recomienda cambios para optimizar el rendimiento.

Como siempre, si tienes alguna pregunta o alguna sugerencia, puedes hacerlas en nuestros foros para webmasters.
Publicado por Zhiheng Wang y Doantam Phan


Source: Google Webmasters

16 Abr 18 Implementación de la indexación centrada en los móviles

Hoy anunciamos que, después de un año y medio de pruebas minuciosas, hemos empezado a migrar los sitios web que siguen las prácticas recomendadas de indexación centrada en los móviles.
Resumamos antes la situación: nuestros sistemas de rastreo, indexación y clasificación suelen analizar la versión para ordenadores del contenido de las páginas, lo que puede ocasionar problemas a los usuarios de dispositivos móviles si la versión para móviles es muy distinta. La indexación centrada en los móviles toma esta última versión al indexar y clasificar las páginas para que los usuarios, que usan principalmente dispositivos móviles, encuentren más fácilmente lo que están buscando.
Seguimos teniendo un único índice desde el que publicar resultados de búsqueda; no hemos creado ningún índice centrado en los móviles. Tradicionalmente, indexábamos la versión para ordenadores de las páginas web, pero ahora iremos usando cada vez más el contenido de sus versiones para móviles.
Notificamos a los sitios web que se están pasando a la indexación centrada en los móviles en Search Console. Los propietarios de estos sitios web notarán que el robot de Google para smartphones rastrea sus páginas con más frecuencia. Además, mostraremos la versión para móviles de su contenido tanto en los resultados de búsqueda como en las páginas almacenadas en la caché de Google.
Para obtener más información sobre cómo determinamos el contenido para móviles de un sitio web, consulta nuestra documentación para desarrolladores. En ella se explica cómo se preparan los sitios web con un diseño web adaptable o publicación dinámica para usarse en la indexación centrada en los móviles. En los sitios web que tengan tanto páginas AMP como páginas que no son AMP, indexaremos la versión para móviles de las páginas que no sean AMP.
No te preocupes si tu sitio web no forma parte de esta primera fase; solo se cambia el modo de obtener contenido, no el de clasificarlo. La indexación centrada en los móviles no influye de ningún modo en el posicionamiento: se usan los mismos criterios en todas las páginas, se hayan indexado con el método nuevo o no, independientemente de si son para móviles u ordenadores. De hecho, seguirás estando en nuestro índice aunque solo tengas contenido para ordenadores.
Dicho esto, seguimos animando a los webmasters a que optimicen su contenido para móviles. Evaluamos todo el contenido incluido en nuestro índice, sea del tipo que sea, para determinar su nivel de optimización para móviles. Desde el año 2015, esta medida facilita que el contenido optimizado para móviles mejore su posicionamiento en las búsquedas hechas desde dispositivos móviles. En la misma línea, hace poco anunciamos que, a partir de julio de 2018, el contenido que tarde en cargarse puede bajar posiciones en los resultados de búsqueda tanto en ordenadores como en móviles.
En resumen:
●    La indexación móvil se implementa cada vez en más sitios web. Este método no mejora el posicionamiento del contenido ni está relacionado con nuestra evaluación sobre si el contenido está optimizado para móviles.
●    Seguimos recomendando que tengas contenido optimizado para móviles si quieres mejorar el posicionamiento de tu sitio web en los resultados de búsqueda móviles.
●    Seguimos recomendando que tengas contenido que se cargue rápidamente si quieres mejorar el posicionamiento de tu sitio web en los resultados de búsqueda tanto en ordenadores como en móviles.
●    Como siempre, se tienen en cuenta muchos factores a la hora de posicionar los sitios web. Es posible que mostremos contenido que no esté optimizado para móviles o que tarde en cargarse si muchos otros factores indican que es el contenido más pertinente.
Continuaremos supervisando y evaluando este cambio con detenimiento. Si tienes alguna pregunta, no dudes en pasarte por nuestro foro para webmasters o nuestros eventos públicos.
Publicado por Fan Zhang, ingeniero de software


Source: Google Webmasters

05 Feb 18 Nueva categoría de auditoría de SEO en la extensión de Chrome Lighthouse

Hoy tenemos el placer de anunciar que añadimos otro tipo de auditoría a la extensión de Chrome Lighthouse: la auditoría de SEO.

Lighthouse es una herramienta automatizada de código abierto que permite llevar a cabo auditorías para mejorar la calidad de las páginas web. Con ella, los programadores pueden auditar varios indicadores, como el rendimiento, la accesibilidad o la compatibilidad de aplicaciones web progresivas, y así mejorar la calidad de sus sitios web. Como su propio icono indica, Lighthouse evita que tu sitio web se vaya a pique.

Con esta nueva auditoría de Lighthouse, los programadores y webmasters pueden comprobar aspectos básicos de SEO en cualquier página web, lo que les permite identificar las áreas que pueden mejorarse. Lighthouse se ejecuta de forma local en tu navegador Chrome, por lo que puedes realizar auditorías de SEO en páginas en construcción, activas y publicadas e, incluso, en páginas que requieren autenticación.

Prácticas recomendadas de SEO a tu alcance

Actualmente, en la lista de auditorías de SEO no se incluyen todos los indicadores, ni tampoco se garantiza que la página web que se audita esté optimizada para la búsqueda web de Google o de otros motores de búsqueda. Esta lista está pensada para validar y mostrar los aspectos básicos de SEO que deberían aplicarse correctamente en todos los sitios web. Además, se ofrecen consejos e instrucciones que pueden resultar útiles a programadores y profesionales de SEO de cualquier nivel. De cara al futuro, esperamos añadir cada vez más auditorías completas y consejos útiles. Si se te ocurre alguna auditoría que te gustaría que incluyéramos, háznoslo saber.

¿Cómo se utiliza?

Actualmente puedes ejecutar estas auditorías de dos formas distintas.

Con la extensión de Chrome Lighthouse:

  1. Instala la extensión de Chrome Lighthouse.
  2. Haz clic en el icono de Lighthouse de la barra de extensiones. 
  3. En el menú Options (Opciones), marca “SEO” y haz clic en OK (Aceptar). A continuación, selecciona Generate report (Generar informe).

Ejecutar auditorías de SEO en la extensión Lighthouse
Con las herramientas para desarrolladores de Chrome de Chrome Canary

  1. Abre las herramientas para desarrolladores de Chrome. 
  2. Accede a Audits (Auditorías).
  3. Haz clic en Perform an audit (Realizar una auditoría).
  4. Maca la casilla de “SEO” y haz clic en Run Audit (Ejecutar auditoría).

Ejecuta auditorías de SEO en Chrome Canary

Actualmente, en la extensión de Chrome Lighthouse solo se incluye un conjunto inicial de auditorías de SEO que tenemos previsto ampliar y mejorar más adelante. Una vez que sepamos con certeza que funcionan, las auditorías pasarán a estar disponibles de manera predeterminada en la versión estable de las herramientas para desarrolladores de Chrome.

Esperamos que esta nueva función te resulte útil tanto en tus proyectos actuales como en los futuros. Si no conocías estos consejos básicos de SEO y te interesa saber más del tema, consulta nuestra guía SEO para principiantes. Déjanos tu opinión en la sección de comentarios, en GitHub o en nuestro foro para webmasters.

¡Que tengas una buena auditoría!

Escrito por Valentyn, especialista en atención a webmasters.


Source: Google Webmasters

05 Feb 18 #NoHacked 3.0: Corregir ataques habituales


Hasta ahora, en #NoHacked hemos compartido algunos consejos para detectar y prevenir ataques. Dado que ya eres capaz de detectarlos, queremos darte a conocer algunos de los métodos que los hackers utilizan con más frecuencia, así como darte instrucciones para poder enfrentarte a ellos.

Corregir ataques con palabras clave y enlaces encubiertos        

#nohacked2017_11_Twitter.png
Los ataques con palabras clave y enlaces encubiertos crean automáticamente varias páginas con frases, enlaces e imágenes sin sentido. A veces, estas páginas contienen elementos de plantilla básicos del sitio web original, por lo que, a primera vista, parece que las páginas pertenecen al sitio web hasta que se lee el contenido. En este tipo de ataque, los hackers suelen utilizar técnicas de encubrimiento para esconder el contenido malicioso y hacer que la página insertada parezca parte del sitio web original o una página con el error 404. Enlace a la guía completa.

Corregir ataques de texto autogenerado

#nohacked2017_12_Twitter.png
Los ataques de texto autogenerado crean automáticamente muchas páginas con frases sin sentido y llenas de palabras clave. Los hackers, de esta forma, buscan que las páginas pirateadas aparezcan en los resultados de la Búsqueda de Google. Después, cuando un usuario intenta visitarlas, se le redirige a una página sin relación alguna, como por ejemplo un sitio web con contenido pornográfico. Enlace a la guía completa.

Corregir ataques con palabras clave en japonés        

#nohacked2017_13_Twitter.png
Los ataques con palabras clave en japonés normalmente crean páginas con texto en japonés en el sitio web, en directorios con nombres generados de forma aleatoria. Estas páginas obtienen ingresos mediante enlaces afiliados a tiendas que venden productos de marca de imitación y que después se muestran en la Búsqueda de Google. A veces, las cuentas de los hackers se añaden a Search Console como propietarios de los sitios web. Enlace a la guía completa.

Por último, una vez que hayas limpiado tu sitio web y solucionado el problema, presenta una solicitud de reconsideración para que nuestros equipos revisen el sitio web.

#nohacked2017_14_Twitter.png
Si tienes alguna pregunta, puedes publicar tus preguntas en nuestros foros de ayuda para webmasters


Source: Google Webmasters

01 Feb 18 #NoHacked 3.0: Consejos de prevención



En la entrada anterior de la campaña #NoHacked hablamos sobre cómo detectar ataques y por qué puedes ser objetivo de uno. En esta, en cambio, ofrecemos recomendaciones sobre la prevención.

#nohacked2017_8_Twitter.png
Formas más habituales en las que los spammers piratean sitios web
Para proteger de ataques tu sitio web, es fundamental que entiendas cómo se ha pirateado. A continuación, te mostramos las formas que más utilizan los spammers para atacar sitios web.

#nohacked2017_9_Twitter.png
Investiga las fuentes: ten cuidado con los temas o complementos premium gratuitos.
Es probable que hayas oído hablar de complementos premium gratuitos. Si alguna vez encuentras un sitio web que ofrece este tipo de complementos de manera gratuita, ten cuidado. La mayoría de los hackers utilizan como cebo un complemento popular, al que añaden puertas traseras o software malicioso que les permitan acceder a tu sitio web. Obtén más información sobre un caso similar en el blog de Sucuri (en inglés).
Incluso los complementos y temas originales y de buena calidad pueden ser peligrosos si cumplen alguna de las siguientes condiciones:
   – No se actualizan cuando hay una nueva versión disponible.
   – Su programador no los actualiza y se quedan anticuados con el tiempo.
En cualquier caso, para evitar que los hackers accedan a tu sitio web, es de vital importancia que todo el software sea moderno y esté actualizado.

#nohacked2017_10_Twitter.png
Red zombi en WordPress
Una red zombi o botnet (en inglés) es una agrupación de máquinas, dispositivos o sitios web que se encuentran bajo el control de un tercero, que a menudo los utiliza para cometer actos maliciosos, como crear campañas de spam o usar software de clics automáticos o ataques distribuidos de denegación de servicio (DDoS). Es complicado detectar si tu sitio web se ha visto afectado por una red zombi, puesto que normalmente no se producen cambios concretos en él. Sin embargo, si el sitio web está en una red zombi, su reputación, recursos y datos están en peligro. Para obtener más información sobre las redes zombi y saber cómo detectarlas y cómo pueden afectar a tu sitio web, consulta el artículo sobre redes zombi en WordPress y Joomla (en inglés).

Como de costumbre, puedes recibir ayuda si publicas las preguntas que tengas en nuestros foros de ayuda para webmasters


Source: Google Webmasters

29 Ene 18 #NoHacked 3.0: ¿Cómo puedo saber si han pirateado mi sitio web?



Este mes de Enero #NoHacked vuelve a estar en nuestros canales de G+ y Twitter. #NoHacked es nuestra campaña en redes sociales para sensibilizar a los usuarios sobre los ataques de piratería y ofrecerles consejos para que sus sitios web estén protegidos. En esta ocasión, queremos que puedas leer en español el contenido de la campaña #NoHacked que publiquemos en este blog.

#nohacked2017_2_Twitter.png

¿Por qué se piratean los sitios web? Los hackers tienen varios motivos, y también disponen de diferentes métodos para alcanzar su objetivo, por lo que no siempre resulta sencillo detectar los ataques. A continuación te ofrecemos algunos consejos para facilitarte la tarea de detectar sitios web pirateados.

#nohacked2017_1_Twitter.png

1. Primera pregunta: han hackeado mi sitio?
Si has recibido una alerta de seguridad, sea de Google u otra fuente, empieza por leer nuestra guía “¿Cómo puedo saber si han pirateado mi sitio web?”. En ella se describen los pasos básicos que debes seguir para identificar las señales que indican que se ha vulnerado la seguridad de tu sitio web.

#nohacked2017_3_Twitter.png

2. Entender la alerta de la Búsqueda de Google: 
En Google, nos enfrentamos a los ataques de piratería de varias formas. Las herramientas de análisis detectan software malicioso con frecuencia; sin embargo, es posible que algunos ataques que utilicen prácticas fraudulentas pasen desapercibidos. Por este motivo es posible que, aunque Navegación Segura no identifique ningún software malicioso, tu sitio web sí se haya pirateado y se esté utilizando para distribuir spam.

  • El mensaje “Este sitio puede haber sido comprometido” indica que es posible que se haya pirateado tu sitio web para mostrar spam; lo que significa, básicamente, que publica anuncios de manera gratuita.
  • El mensaje “Este sitio puede dañar tu ordenador“, que puede aparecer bajo la URL de un sitio web, indica que creemos que el sitio web que estás a punto de visitar puede permitir que se instale software malicioso en tu ordenador.
  • Si se muestra una pantalla roja y grande antes de acceder a tu sitio web, puede indicar cualquiera de los siguientes problemas:
    • El mensaje “El sitio al que vas a acceder contiene software malicioso” indica que Google ha detectado que tu sitio web distribuye software malicioso
    • El mensaje “El sitio al que vas a acceder contiene programas dañinos” indica que Google ha detectado que tu sitio web distribuye software no deseado
#nohacked2017_4_Twitter.png

3. Publicidad maliciosa frente a piratería:

Se considera que hay publicidad maliciosa en un sitio web si se carga un anuncio malicioso. Es posible que, a primera vista, parezca que se haya pirateado el sitio web, quizá porque se redirige a los usuarios a otros lugares; sin embargo, solo se trata de un anuncio con mal comportamiento.

#nohacked2017_5_Twitter.png

4. Redireccionamientos abiertos: comprueba si tu sitio web ha habilitado los redireccionamientos abiertos.
Es posible que los hackers quieran aprovecharse de un buen sitio web para enmascarar sus URL. Para conseguirlo, a veces utilizan redireccionamientos abiertos, lo que les permite redirigir a los usuarios a la URL que quieran mediante tu sitio web. Obtén más información aquí. (en inglés).

#nohacked2017_6_Twitter.png

5. Comprobación móvil: visualiza tu sitio web desde un navegador móvil en modo incógnito y comprueba que no haya redes publicitarias para móviles maliciosas.
En algunas ocasiones, el contenido malicioso, como anuncios u otros elementos de terceros, redirigen a los usuarios móviles a otras ubicaciones sin que lo sepan. Este comportamiento puede eludir los sistemas de detección con facilidad, puesto que solo es visible en determinados navegadores. Comprueba que tu sitio web muestre el mismo contenido tanto en su versión para móviles como en la de ordenadores.

#nohacked2017_7_Twitter.png

6. Utiliza Search Console y recibe notificaciones:
Search Console es una plataforma que Google utiliza para comunicarte cuestiones relacionadas con tu sitio web. También incluye muchas herramientas que pueden ayudarte a mejorarlo y gestionarlo. Te recomendamos que verifiques tu sitio web en Search Console, aunque no seas uno de sus programadores principales. Si Google detecta algún error grave en él, te lo notificaremos mediante las alertas y los mensajes de Search Console.

******

Si después de revisar los puntos anteriores no puedes encontrar indicios de que se haya pirateado tu sitio web, puedes pedir una segunda revisión a un experto de seguridad o en nuestros foros de ayuda para webmasters.


Source: Google Webmasters

14 Dic 17 Nueva versión de la Guía SEO para principiantes

Existe una gran cantidad de recursos disponibles para crear sitios web atractivos. Los propietarios de sitios web suelen preguntarnos por nuestras prácticas recomendadas para adaptar de manera óptima sus sitios a los motores de búsqueda. Antes, los recursos que ofrecíamos a los usuarios que no estaban familiarizados con este tema eran nuestra Guía SEO para principiantes y la Academia para webmasters. Hoy, para seguir ayudando a los webmasters a crear sitios web modernos y adaptados a los motores de búsqueda, anunciamos la publicación de la nueva versión de la Guía SEO para principiantes.
 
En la versión anterior de esta guía, se describen las prácticas recomendadas para que los motores de búsqueda puedan rastrear, indexar y entender más fácilmente el contenido de sitios web. En la Academia para webmasters, por su parte, los webmasters pueden encontrar la información y las herramientas necesarias para crear sitios web que puedan aparecer en la Búsqueda de Google. Dado que ambos recursos comparten parte del contenido y algunos objetivos y, además, no ofrecen toda la información que nos gustaría sobre cómo crear sitios web seguros y fáciles de usar, la Academia para webmasters dejará de estar disponible y retiraremos el archivo PDF de la versión antigua de la Guía SEO para principiantes. 
 
 
La Guía SEO para principiantes actualizada sustituirá tanto a su versión antigua como a la Academia para webmasters. Esta nueva versión renueva el contenido de la anterior y añade secciones que tratan de por qué es necesaria la optimización en buscadores, cómo añadir etiquetas de datos estructurados y cómo diseñar sitios web optimizados para móviles.
Esta nueva guía está disponible a partir de hoy en nueve idiomas (alemán, español, francés, inglés, italiano, japonés, portugués, ruso y turco) y pronto se publicará en 16 idiomas más.
Consulta la nueva Guía SEO para principiantes y danos tu opinión. 
Si tienes alguna pregunta, no dudes en formularla en nuestros foros de ayuda para webmasters.
 
<!– @page { margin: 0.79in } p { margin-bottom: 0.1in; direction: ltr; font-size: 12pt; line-height: 120%; text-align: left; widows: 2; orphans: 2 } a:link { so-language: zxx } –>
Escrito por Abhas Tripathi y publicado por Joan Ortiz, equipo de Calidad de Búsqueda.

<!– @page { margin: 0.79in } p { margin-bottom: 0.1in; direction: ltr; font-size: 12pt; line-height: 120%; text-align: left; widows: 2; orphans: 2 } a:link { so-language: zxx } –> <!– @page { margin: 0.79in } p { margin-bottom: 0.1in; direction: ltr; font-size: 12pt; line-height: 120%; text-align: left; widows: 2; orphans: 2 } a:link { so-language: zxx } –>


Source: Google Webmasters

04 Dic 17 Renderizar páginas de rastreo con AJAX


El esquema de rastreo con AJAX se diseñó con el objetivo de que el robot de Google pudiera acceder a las páginas web basadas en JavaScript. Como hemos anunciado anteriormente, tenemos previsto desactivarlo. Con el tiempo, los ingenieros de Google han mejorado de forma significativa cómo se renderiza JavaScript para que el robot de Google pueda rastrearlo. Gracias a estos avances, a partir del segundo trimestre del 2018 Google se encargará de renderizar estas páginas, en lugar de que tengan que hacerlo los sitios web. En resumen, dejaremos de usar el esquema de rastreo con AJAX.
El esquema de rastreo con AJAX admite páginas que contienen “#!” en la URL o bien una metaetiqueta “fragment” y, a continuación, los rastrea incluyendo “?_escaped_fragment_=” en la URL. Esa versión con caracteres de escape, creada por el sitio web, tiene que ser una versión completa o equivalente de la página.
Con este cambio, el robot de Google renderizará la URL que contiene #! directamente, por lo que no será necesario que el propietario del sitio web proporcione una versión renderizada de la página. Estas URL se seguirán incluyendo en los resultados de búsqueda.
Esperamos que la mayoría de los sitios web que se rastrean con AJAX no experimenten cambios importantes con esta actualización. Los webmasters pueden comprobar sus páginas siguiendo las instrucciones a continuación. Enviaremos notificaciones a los sitios web que detectemos que pueden tener problemas.
Si tu sitio web usa URLs que contienen #! o metaetiquetas “fragment”, te recomendamos que hagas lo siguiente:
● Verifica la propiedad del sitio web en Google Search Console para acceder a sus herramientas y para que Google te pueda enviar notificaciones sobre los problemas que encuentre.

● Haz pruebas con la herramienta Explorar como Google de Search Console. Compara los resultados de la URL que contiene #! y la URL con caracteres de escape para ver las diferencias. Repite este proceso con cualquier parte del sitio web que sea notablemente distinta. Consulta nuestra documentación para desarrolladores para obtener más información sobre las API admitidas y, si es necesario, consulta nuestra guía de depuración.

● Con la función para inspeccionar elementos de Chrome, comprueba que los enlaces utilizan elementos HTML <a> e incluyen rel=nofollow donde corresponde (por ejemplo, en contenido generado por usuarios).

● Con la función para inspeccionar elementos de Chrome, comprueba el título de la página y la metaetiqueta “description”, si hay metaetiquetas “robot” y otros metadatos. Comprueba también que los datos estructurados estén disponibles en la página renderizada.

● Si el contenido debe indexarse en la búsqueda, el contenido creado con Flash, Silverlight u otras tecnologías basadas en complementos debe convertirse a JavaScript o HTML “normal”.
Esperamos que este cambio facilite el proceso para rastrear tu sitio web y evite en la medida de lo posible que tengas que renderizar páginas. Si tienes cualquier pregunta o comentario, no dudes en consultar nuestros foros de ayuda para webmasters o unirte a nuestro grupo de trabajo de sitios web de JavaScript.
Escrito por John Mueller, Google Suiza, publicado por Joan Ortiz, equipo de calidad de búsqueda.


Source: Google Webmasters

28 Nov 17 Recordatorio sobre el marcado de eventos

Últimamente hemos recibido comentarios de usuarios que afirman haber visto elementos que no son eventos, como cupones, en los resultados de búsqueda en que aparecen fragmentos de eventos.

Esta situación confunde mucho a los usuarios y, además, infringe nuestras directrices, a las que hemos añadido más información sobre el tema. En concreto, ¿cuál es el problema?

Hemos observado que muchos editores de sitios web que ofrecen cupones describen sus ofertas con el marcado de eventos. Aunque usar un cupón de descuento puede ser algo muy especial, no por eso hay que considerar los cupones como si fueran eventos o saleEvents. Cuando se describe algo que no es un evento con el marcado de eventos, se crea una mala experiencia de usuario, porque se mostrará un resultado enriquecido de algo que sucederá en un momento determinado, aunque no haya ningún evento real.

A continuación se muestran algunos ejemplos que ilustran el problema: Dado que en estos casos se generan experiencias de usuario engañosas, es posible que realicemos acciones manuales para corregirlas. Si tu sitio web se ve afectado por alguna de estas medidas, se mostrará una notificación en tu cuenta de Search Console. Si realizamos una acción manual en tu sitio web, es posible que no se utilice el marcado de datos estructurados de todo el sitio web en los resultados de búsqueda.

Si bien en esta entrada del blog destacamos específicamente el caso de los cupones, esta información también se aplica a cualquier otro elemento que no sea un evento y que esté marcado como tal; en realidad, se aplica al hecho de etiquetar elementos con un tipo de marcado que no sea el adecuado.

Para obtener más información, consulta la documentación para desarrolladores o, si tienes más preguntas, visita nuestro foro para webmasters.


Escrito por Sven Naumann, del equipo de Confianza y seguridad de la Búsqueda


Source: Google Webmasters