Casos de éxito: Reparación de sitios comprometidos


Todos los días se comprometen miles de sitios web. Los sitios comprometidos pueden perjudicar a los usuarios de diferentes formas: proporcionando software malicioso, recopilando información personal o redireccionándoles a sitios que no pretendían visitar. A los webmasters les interesa corregir rápidamente los sitios comprometidos, pero este proceso puede llegar a ser bastante complicado.

Para intentar facilitar el proceso de recuperación de sitios comprometidos a los webmasters, hemos creado los recursos Problemas de seguridad, Ayuda para sitios comprometidos y como siempre puedes visitar nuestro foro. Recientemente hemos hablado con dos webmasters que tuvieron este problema para que nos contaran qué hicieron para arreglar sus sitios. Vamos a compartir sus historias con la esperanza de que puedan ayudar a otros webmasters que hayan sido víctimas de la piratería. También estamos utilizando estas historias y otros comentarios para mejorar nuestra documentación sobre sitios comprometidos y para facilitar a todo el mundo el proceso de solución de problemas.

Caso de éxito n.º 1: sitio web de un restaurante con varias secuencias de comandos inyectadas por hackers

Google envió un mensaje a la cuenta de Herramientas para webmasters del sitio web de un restaurante creado con WordPress, en el que se informaba de que algunos hackers habían modificado su sitio. Para proteger a los usuarios de Google, el sitio se etiquetó como "comprometido" en los resultados de búsqueda de Google. La webmaster del sitio, Sam, analizó el código fuente y detectó que el sitio contenía muchos enlaces desconocidos con términos farmacéuticos, como "viagra" o "cialis". También vio que las etiquetas de metadescripción (en el HTML) de muchas páginas habían añadido contenidos tales como "comprar valtrex en Florida". También encontróetiquetas de división ocultas (también en el HTML) en muchas páginas que enlazaban a diferentes sitios, que Sam no había añadido.

Sam eliminó todo el contenido comprometido que encontró y presentó una solicitud de reconsideración. La solicitud se rechazó mediante un mensaje de Google, en el que se le informaba de que comprobara si había secuencias de comandos desconocidas en alguno de los archivos PHP (o en otros archivos del servidor), y si se habían hecho cambios en el archivo .htaccess. Los hackers acostumbran a añadir secuencias de comandos en estos archivos para modificar los sitios. Estas secuencias de comandos normalmente solo muestran el contenido comprometido a los motores de búsqueda, mientras que lo ocultan al resto de usuarios. Sam comprobó todos los archivos .php y los comparó con las copias limpias que tenía en la copia de seguridad. Detectó que se había añadido contenido nuevo en los archivos footer.php, index.php y functions.php. Cuando reemplazó dichos archivos por las copias de seguridad limpias, ya no encontró más contenido comprometido en el sitio. Presentó otra solicitud de reconsideración yrecibió una respuesta de Google en la que se le notificaba que el sitio estaba limpio.

A pesar de que Sam había limpiado el contenido comprometido del sitio, sabía que tendría que seguir protegiéndolo contra futuros ataques. Por eso siguió los pasos que se describen a continuación:

  • Mantener actualizado el CMS (sistema de gestión de contenido, como WordPress, Joomla, Drupal, etc.) con la versión más reciente. Asegurarse también de que los plugins estén actualizados. 
  • Comprobar que la contraseña de la cuenta utilizada para acceder a las funciones administrativas del CMS sea difícil y única. 
  • Habilitar la verificación en dos pasos para iniciar sesión, si el CMS la admite. (También puede denominarse "autenticación en dos factores" o "autenticación en dos pasos"). Este procedimiento también se recomienda para la cuenta utilizada para la recuperación de la contraseña. La mayoría de los proveedores de correo electrónico, como Google, Microsoft o Yahoo, admiten esta función. 
  • Asegurarse de que los plugins y los temas instalados provienen de una fuente de confianza, ya que, a menudo, los plugins o los temas pirateados pueden contener código que facilita aún más la entrada de los hackers. 

Caso de éxito n.º 2: sitio web profesional con muchas páginas comprometidas difíciles de encontrar

La propietaria de un pequeño negocio, María, que también es la encargada de gestionar su propio sitio web, recibió un mensaje en su cuenta de Herramientas para webmasters en el que se le informaba de que su sitio estaba comprometido. El mensaje contenía el ejemplo de una página agregada por hackers: http://example.com/where-to-buy-cialis-over-the-counter/ María habló con su proveedor de alojamiento, que analizó el código fuente de la página principal, en la que no encontró ninguna palabra clave propia del sector farmacéutico. Cuando el proveedor de alojamiento visitó la página http://example.com/where-to-buy-cialis-over-the-counter/ recibió una página de error. María también compró un servicio de análisis de software malicioso, pero no le sirvió para encontrar ningún contenido de este tipo en el sitio.

Entonces acudió a las Herramientas para webmasters y utilizó la herramienta Explorar como Google para acceder a la URL de ejemplo que Google le había proporcionado (http://example.com/where-to-buy-cialis-over-the-counter/), pero tampoco le devolvió ningún contenido. Confundida, presentó una solicitud de reconsideración y recibió un mensaje de rechazo en el que se le aconsejaba que hiciera dos cosas:

1)- Verificar la versión sin www del sitio, ya que a menudo los hackers intentan ocultar el contenido en carpetas que pueden pasar ​por alto a los webmasters.

Aunque puede parecer que http://example.com/ http://example.com/ son el mismo sitio, en realidad Google los trata como sitios distintos. http://example.com/ se considera el "dominio raíz", mientras que http://example.com/se denomina "subdominio". María había verificado http://example.com/ pero no http://example.com/, lo cual fue determinante, porque los hackers habían agregado páginas sin www, como http://example.com/where-to-buy-cialis-over-the-counter/. Al verificar http://example.com/, María pudo ver correctamente el contenido comprometido en la URL proporcionada con la herramienta Explorar como Google de las Herramientas para webmasters.

2)- Revisar el archivo .htaccess por si contenía nuevas reglas.

María habló con su proveedor de alojamiento, que le explicó cómo acceder al archivo .htaccess. Enseguida se dio cuenta de que en el archivo .htaccess había contenido extraño que ella no había añadido:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
RewriteRule ^([^/]*)/$ /main.php?p=$1 [L]
</IfModule>

El hacker había insertado la regla mod_rewrite anterior para redireccionar a todos los usuarios procedentes de determinados motores de búsqueda y rastreadores de motores de búsqueda a main.php, que generaba todo el contenido comprometido. Estas reglas también pueden redireccionar a los usuarios que accedan al sitio desde un dispositivo móvil. Ese mismo día también vio, con un escaneo de software malicioso reciente, que había contenido sospechoso en el archivo main.php. Además, también encontró a un usuario desconocido en el área de usuarios del FTP de su software de desarrollo de sitios web.


María eliminó el archivo main.php, el archivo .htaccess y al usuario desconocido del área de usuarios del FTP, y su sitio dejó de estar comprometido.

Pasos para evitar que se vuelva a comprometer el sitio
  • No utilizar el FTP para transferir archivos a los servidores. El FTP no cifra todo el tráfico, incluidas las contraseñas. En cambio, el SFTP lo cifra todo, incluida la contraseña, como protección contra los intrusos que examinan el tráfico de red. 
  • Comprobar los permisos de los archivos confidenciales, como .htaccess. El proveedor de alojamiento puede ofrecer ayuda para ello. El archivo .htaccess se puede utilizar para mejorar y proteger el sitio, pero los hackers maliciosos también pueden utilizarlo si consiguen acceder a él. 
  • Estar atentos y buscar usuarios nuevos y desconocidos en el panel de administración, o en cualquier otro lugar en el que los usuarios puedan modificar el sitio. 
Esperamos que tu sitio nunca se vea comprometido, pero si esto sucede, tenemos muchos recursos para webmasters en nuestra página de Ayuda para sitios comprometidos. Si necesitas más ayuda o quieres compartir tus propios consejos, puedes escribir en nuestro Foro de ayuda para webmasters. Si escribes en el foro o envías una solicitud de reconsideración para tu sitio, incluye la etiqueta #NoHacked..

Posted by Julian Prentice and Yuan Niu, Search Quality Team.Publicado por Javier Pérez equipo de calidad de búsqueda.

martes, 24 de marzo de 2015

Desarrollar tu sitio web es fácil con "Web Components" y JSON-LD


JSON-LD es un formato de datos basado en JSON que puedes utilizar para implementar datos estructurados que describan el contenido de tu sitio a Google y a otros motores de búsqueda. Por ejemplo, si tienes una lista de eventos, cafeterías, personas o de otras cosas, puedes incluir estos datos en tus páginas de forma estructurada utilizando el vocabulario de schema.org insertado en las páginas web como un fragmento JSON-LD. Gracias a los datos estructurados, Google puede comprender mejor tus páginas y destacar su contenido en elementos de búsqueda como, por ejemplo, eventos de Gráfico de conocimiento y fragmentos enriquecidos.

"Web Components" son un conjunto de tecnologías que se utilizan para definir widgets de interfaz de usuario reutilizables y personalizados, así como el comportamiento de los mismos. Todos los desarrolladores web pueden crear un "Web Component". Se empieza por definir una plantilla para una parte diferenciada de la interfaz de usuario, que puedes importar a otras páginas en las que quieras utilizar el "Web Component". Se utiliza un "Custom Element" para definir el comportamiento del "Web Component". Al agrupar la visualización y la lógica de parte de la interfaz de usuario en el "Web Component", puedes compartir y volver a usar el conjunto en otras páginas y con otros desarrolladores. Esto simplifica el desarrollo web.

"Web Components" y JSON-LD se complementan a la perfección. El "Custom Element"funciona como capa de presentación y JSON-LD como la capa de datos que utilizan los "Custom Elements" y los motores de búsqueda. Esto significa que puedes crear "Custom Elements" para todo tipo de schema.org, como schema.org/Event y schema.org/LocalBusiness.

La arquitectura sería parecida a lo que se indica a continuación. Los datos estructurados (por ejemplo, las ubicaciones de las tiendas de tu cadena) se almacenan en tu base de datos. Los datos se insertan en tu página web en forma de fragmento JSON-LD, de esta manera está disponible para que el "Custom Element" lo muestre a un usuario, o para que el robot de Google lo recupere en la indexación de Google.

Puedes obtener más información para empezar a crear tus "Custom Elements" en:


Posted by Ewa Gasperowicz, Developer Programs Engineer, Mano Marks, Developer Advocate, Pierre Far, Webmaster Trends Analyst. Publicado por Javier Pérez equipo de calidad de búsqueda.


Desbloquear recursos con Herramientas para webmasters


Los webmasters suelen utilizar imágenes enlazadas, CSS y archivos JavaScript en las páginas web para que tengan un buen aspecto y sean funcionales. Si estos recursos tienen el rastreo bloqueado, el robot de Google no puede utilizarlos cuando procesa esas páginas en la búsqueda. Ahora Herramientas para webmasters de Google incluye el informe Recursos bloqueados, que te ayudará a encontrar y resolver estos tipos de problemas.


Este informe empieza con los nombres de los hosts de los cuales tu sitio está usando recursos bloqueados como JavaScript, CSS e imágenes. Si haces clic en las filas, se te proporcionará la lista de recursos bloqueados y las páginas en las que están insertados, y se te guiará por los pasos para diagnosticar y resolver cómo rastreamos e indexamos el contenido de las páginas.



Una actualización de Exploración y procesamiento muestra por qué son importantes los recursos bloqueados. Cuando solicitas que se explore y procese una URL, ahora se muestran capturas de pantalla procesadas como el robot de Google y como un usuario normal. Así se reconocen más fácilmente los problemas que influyen de manera significativa en el motivo por el que el robot de Google ve las páginas de manera diferente.



Herramientas para webmasters intenta mostrarte solo los hosts en los que puedes intervenir, por lo que, en este momento, no mostramos hosts utilizados por muchos sitios (como servicios de análisis populares). Como puede llevar tiempo actualizar todos los archivos robots.txt (aunque no suela ser por motivos técnicos), recomendamos empezar por los recursos que tengan un mayor impacto visual al estar bloqueados. En el artículo de nuestro Centro de ayuda hay más información sobre los pasos a seguir.



Esperamos que esta nueva función te ayude a detectar y desbloquear los recursos que utiliza tu sitio web. Si tienes cualquier pregunta, no dudes en pasarte por el foro de ayuda para webmasters.



Publicado por John Mueller, Analista de Tendencias para Webmasters, Google Switzerland, Publicado por Javier Pérez equipo de calidad de búsqueda

miércoles, 18 de marzo de 2015

Ayudar a los usuarios a rellenar formularios online


En muchos sitios web se utilizan formularios para alcanzar objetivos importantes, como completar una transacción en una tienda online o registrarse en un sitio de noticias.
Para muchos usuarios, rellenar formularios online implica tener que introducir de forma repetitiva información común, como su nombre, su correo electrónico, su número de teléfono o su dirección en distintos sitios de la Web. Además de resultar aburrida, esta tarea se presta a cometer errores, lo que puede provocar que muchos usuarios abandonen definitivamente el flujo. Actualmente, los usuarios tienden a utilizar más sus dispositivos móviles que sus portátiles u ordenadores para navegar por Internet, por lo que resulta crucial disponer de formularios que se puedan rellenar de manera rápida y sencilla. 

Hace tres años, anunciamos que íbamos a proporcionar compatibilidad con el nuevo atributo “Autocompletar” de Chrome, cuya finalidad es facilitar y agilizar la forma de rellenar formularios. Actualmente, Chrome es totalmente compatible con el atributo "Autocompletar" para los campos de formularios, siguiendo las especificaciones vigentes del estándar WHATWG de HTML. De esta forma, los webmasters y los desarrolladores web pueden etiquetar campos de elementos de entrada con tipos de datos comunes, como "name" o "street-address", sin tener que cambiar la interfaz de usuario ni el backend. Muchos webmasters han aumentado la velocidad con la que se rellenan los formularios de sus sitios marcando los formularios con este atributo.

Por ejemplo, un campo de dirección de correo electrónico de un formulario marcado de modo que permita la función de completado automático tendría el siguiente aspecto (puedes ver el formulario de ejemplo completo):

<input type="email" name="customerEmail" autocomplete="email"/>

captureexample.jpg


Es muy importante que los usuarios puedan consultar sitios web de forma rápida y fácil desde sus dispositivos móviles. Esperamos que, en el futuro, podamos ver muchos formularios marcados con el atributo “Autocompletar”. Para obtener más información, puedes consultar nuestras especificaciones sobre Entradas de etiquetas y de nombres en Web Fundamentals. Como siempre, si tienes alguna duda, no dudes en publicarla en nuestros foros de ayuda para webmasters.

Escrito por Mathieu Perreault, Chrome Software Engineer, and Zineb Ait Bahajji, Webmaster Trends Analyst, Publicado por Javier Pérez equipo de calidad de búsqueda

martes, 17 de marzo de 2015

Nuevas directrices de calidad para las páginas puerta


El equipo de Calidad de búsqueda de Google no deja de buscar nuevas formas de minimizar el impacto del spam web en los usuarios, y esto incluye las páginas puerta.

Desde hace tiempo, estamos convencidos de que las páginas puerta, creadas con el único objetivo de atraer los motores de búsqueda, pueden perjudicar la calidad de la experiencia de búsqueda del usuario.

Este es el caso, por ejemplo, de las búsquedas con las que se obtiene una lista cuyos resultados dirigen todos al mismo sitio. Si un usuario hace clic en un resultado y no le gusta, y después prueba con el resultado siguiente de la página de resultados de búsqueda y vuelve al mismo sitio que rechazó, es muy probable que se sienta frustrado.

Con el tiempo, hemos observado que los sitios tienden a maximizar su “huella de búsqueda”, sin por ello añadir un valor único y claro. Estas campañas de páginas puerta se manifiestan como las páginas de un sitio, como una serie de dominios o bien como una combinación de ambos elementos. Para mejorar la calidad de los resultados de búsqueda de nuestros usuarios, pronto lanzaremos un ajuste de clasificación con el que se abordarán mejor estos tipos de páginas. Este cambio repercutirá de forma significativa en los sitios con campañas de páginas puerta de amplio alcance y bien establecidas.

Para que los webmasters comprendan mejor nuestras directrices de calidad, hemos añadido una serie de ejemplos claros y hemos actualizado la definición de páginas puerta.

A continuación, presentamos una serie de preguntas que deben plantearse para determinar si una página se puede considerar página puerta:

  • ¿Su objetivo es optimizar para los motores de búsqueda y canalizar a los visitantes a la parte del sitio que realmente se puede usar o que es verdaderamente pertinente? ¿O es una parte integrante de la experiencia de usuario del sitio?
  • ¿La página se ha diseñado para que aparezca cuando se buscan términos genéricos, pero el contenido es muy específico?
  • ¿Duplica la página agregaciones útiles de elementos (ubicaciones, productos, etc.) que ya existen en el sitio, con el objetivo de capturar más tráfico de búsqueda?
  • ¿La página se ha creado con el único objetivo de atraer tráfico de afiliados y enviar usuarios sin crear un verdadero valor único en el contenido o en la funcionalidad?
  • ¿Se encuentra esta página en una “isla”? ¿Es difícil o imposible navegar por ella desde otras partes del sitio? ¿Se han creado los enlaces a esta página desde otras páginas del sitio o de la red de sitios solo para los motores de búsqueda?

Si tienes alguna pregunta o comentario sobre las páginas puerta, visita los foros del Centro para webmasters.



Escrito por Brian White, Google web spam team, Publicado por Javier Pérez equipo de calidad de búsqueda

Encontrar más resultados de búsqueda optimizados para móviles


Nuestro objetivo es ofrecer a los usuarios las respuestas más relevantes a sus consultas con la mayor celeridad posible. A medida que crece el número de usuarios que utilizan dispositivos móviles para acceder a Internet, nuestros algoritmos deben adaptarse a estos patrones de uso. Anteriormente, realizamos actualizaciones para garantizar que los sitios estuviesen configurados correctamente y visibles en los dispositivos modernos. Además, también permitimos a los usuarios encontrar páginas web optimizadas para móviles fácilmente.

Más sitios web optimizados para móviles en los resultados de búsqueda 

A partir del 21 de abril, ampliaremos el uso de la optimización para móviles como señal del ranking. Este cambio afectará a las búsquedas para móviles en los idiomas de todo el mundo y tendrá un impacto notable en los resultados de búsqueda. Como consecuencia, los usuarios podrán encontrar más resultados de alta calidad pertinentes para sus consultas y optimizados para su dispositivo.

Si eres webmaster, puedes prepararte para este cambio utilizando las herramientas siguientes, que te permitirán saber cómo ve tus páginas el robot de Google:

Más contenido relevante para aplicaciones en los resultados de la búsqueda

A partir de hoy, vamos a empezar a utilizar la información de aplicaciones indexadas como un factor en el ranking para usuarios que han iniciado la sesión en Google y tienen esas aplicaciones instaladas. 
Como resultado, es posible que ahora aparezca contenido de las aplicaciones indexadas de manera más prominente en la búsqueda. Para saber cómo implementar la indexación de aplicaciones, que nos permite recopilar esta información en los resultados de búsqueda, echa un vistazo a nuestra guía paso a paso en el sitio web para desarrolladores.


Para obtener ayuda sobre cómo crear un sitio optimizado para móviles, consulta nuestra guía para sitios optimizados para móviles. Si tienes alguna pregunta, siempre estamos a tu disposición en el Foro de ayuda para webmasters.



Escrito por Takaki Makino y Doantam Phan, Búsqueda de Google, Publicado por Javier Pérez equipo de calidad de búsqueda

martes, 3 de marzo de 2015

Rastrear e indexar páginas con adaptación a la configuración regional


Las páginas con adaptación a la configuración regional cambian el contenido para reflejar el idioma del usuario o la ubicación geográfica detectada. Puesto que, de manera predeterminada, Googlebot solicita páginas sin definir un encabezado de solicitud HTTP "Accept-Language" y utiliza direcciones IP que parece que están ubicadas en los EE. UU., no todas las variantes del contenido de las páginas con adaptación a la configuración regional se pueden indexar completamente.

Hoy presentamos nuevas configuraciones de rastreo con detección de configuración regional para Googlebot para páginas que detectamos que pueden adaptar el contenido que publican en función del idioma de la solicitud y la ubicación detectada.
Se trata de las siguientes:

  • Rastreo distribuido geográficamente, en que Googlebot empezaría a utilizar direcciones IP que parezca que procedan de fuera de los EE. UU., además de las direcciones IP actuales que parezca que procedan de los EE. UU. que Googlebot utiliza actualmente. 
  • Rastreo que depende del idioma, en que Googlebot empezaría a rastrear con un encabezado HTTP "Accept-Language" en la solicitud.

Puesto que estas nuevas configuraciones de rastreo están activadas automáticamente para las páginas que detectamos que tienen adaptación a la configuración regional, es posible que notes cambios en la manera como rastreamos y mostramos tu sitio en los resultados de búsqueda de Google sin que hayas alterado la configuración del servidor o tu CMS.

Ten en cuenta que estas nuevas configuraciones no cambian nuestra recomendación de usar URL independientes con anotaciones rel=alternate hreflang para cada configuración regional. Seguimos admitiendo y recomendamos usar URL independientes porque siguen siendo la mejor manera de que los usuarios interaccionen con tu contenido y lo compartan, y también para optimizar la indexación y lograr una mejor clasificación de todas las variantes de tu contenido.

Como siempre, si tienes preguntas o comentarios, háznoslos llegar en el Foro de ayuda de internacionalización para webmasters.



Escrito por Qin Yin, Software Engineer Search Infrastructure, y Pierre Far, Webmaster Trends Analyst, Publicado por Javier Pérez equipo de calidad de búsqueda 



miércoles, 28 de enero de 2015