msgbartop
Blog de noticias sobre google.
msgbarbottom

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

28 Nov 17 Fomentar la interacción de los usuarios con páginas AMP de gran calidad

Estamos cambiando el modo de aplicar nuestras políticas sobre la equivalencia de contenido en AMP para mejorar la experiencia de los usuarios con este tipo de resultados. A partir del 1 de febrero del 2018, en las políticas se exigirá que el contenido de las páginas AMP sea equiparable al contenido de sus páginas canónicas (originales). No hemos modificado la política de posicionamiento con respecto a AMP, que no se considera un indicador de posicionamiento. En el 2015, se hizo público el proyecto de código abierto Accelerated Mobile Pages (AMP) y, desde entonces, su crecimiento ha sido espectacular: el formato AMP se ha implementado en más de 25 millones de dominios. Con este progreso tan rápido también viene la responsabilidad de asegurarse de que los usuarios sigan disfrutando del contenido de una manera óptima, lo que, al fin y al cabo, genera una mayor interacción con el contenido de editores. A veces, los webmasters publican dos versiones de su contenido: una página canónica que no se basa en AMP y una página AMP. Lo ideal sería que ambas fueran equivalentes; así, los usuarios podrían acceder al mismo contenido, con la única diferencia que la experiencia de la versión AMP sería más rápida y fluida. No obstante, en algunos casos el contenido de las páginas AMP no es el mismo que el de sus páginas originales (canónicas). En contadas ocasiones, en las páginas AMP se muestra solo un fragmento del contenido real, lo que genera una pésima experiencia de usuario, puesto que hay muy poco contenido y los usuarios tienen que hacer clic dos veces para acceder a lo que buscan. A continuación, tienes un ejemplo de lo que acabamos de comentar: se ofrece un breve fragmento del artículo principal y, posteriormente, se pide a los usuarios que hagan clic en un enlace para acceder a otra página donde está el artículo entero. La tecnología AMP se ha diseñado con el objetivo de mejorar el rendimiento de la Web y ofrecer una experiencia de consumo de contenido rápida y coherente. Por tanto, pronto empezaremos a exigir que, para que las páginas AMP aparezcan como tales en la Búsqueda de Google, tanto estas como sus páginas canónicas tengan un contenido muy similar. Si en una página AMP no se incluye el mismo contenido importante que en su equivalente que no es AMP, dirigiremos los usuarios a esta última. Este cambio no afecta al posicionamiento en los resultados de la Búsqueda. No obstante, no se incluirán estas páginas en las funciones de la Búsqueda que requieren AMP, como el carrusel Noticias destacadas de AMP. Además, enviaremos a los webmasters en cuestión un mensaje de acción manual en Search Console, y ofreceremos a los editores la oportunidad de solucionar el problema para que sus páginas AMP puedan volver a publicarse. En el sitio web del proyecto de código abierto de AMP se incluyen guías útiles para aprender a diseñar páginas AMP rápidas, atractivas y eficaces. Esperamos que este cambio anime a los webmasters a ofrecer el mismo contenido en páginas canónicas y sus equivalentes AMP. De este modo, conseguirán una mejor experiencia en su sitio web, lo que, a su vez, mejorará la satisfacción de sus usuarios. Escrito por Ashish Mehta, director de producto. Publicado por Joan Ortiz, equipo de calidad de búsqueda.


Source: Google Webmasters

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

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 Google
Cuando 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.
moving to rwd-04.png
  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.
moving to rwd-05.png
  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 adaptable
La 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.


Source: Google Webmasters

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

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.


Source: Google Webmasters