Entradas

Etiqueta Standout | Marcado para artículos destacados

Google Standout

Si tu blog, web, empresa o agencia de noticias lanza una buena crónica, o publica un ejemplo extraordinario de periodismo, puedes indicarlo usando la etiqueta standout. A la hora de considerar si usar o no la etiqueta en tu propio artículo, considera si el artículo reúne los siguientes requisitos:

  • Tu artículo es una fuente original de la crónica o historia contada
  • Tu organización (o tú!) invirtió recursos significativos a la hora de producir o crear el artículo
  • El artículo merece reconocimiento especial
  • No has usado standout en tus propios artículos más de 7 veces en la última semana natural

Además recomendamos citar artículos standout (destacados) de otros publicantes si tu propia publicación arranca de o complementa esa/s muestra/s de periodismo destacado. Cuando consideres usar la etiqueta standout para citar el trabajo de otros, ten en cuenta los siguientes criterios:

  • El artículo de publicante era la fuente original de la historia que estás tratando
  • La fuente original invirtió recursos significativos a la hora de producir el artículo
  • Te resulta evidente que el artículo original merece reconocimiento especial

Nota de adaptación: es decir, que sigas los mismos criterios que te dictan usar o no la etiqueta standout en tus artículos a la hora de evaluar las fuentes a las que quieres citar como destacadas.

Si una publicación bebe de múltiples fuentes de trabajo destacado puedes usar la etiqueta standout múltiples veces en la cabecera del artículo. Así mismo, citar artículos destacados de otros publicantes no se rige por el límite de 7 auto-referencias por semana natural.

¿Cómo se usa la etiqueta Standout?

Puedes etiquetar un artículo como detacado usando un elemento o un Metatag en la sección <HEAD> del documento. Por ejemplo si quisieras remarcar una historia o gran noticia exclusiva, digamos que de un periódico, deberías añadir el siguiente código en la página de tu hipotética noticia, historia, crónica o lo que fuera:

<head>
...
<link rel="standout" href="https://www.seofreelance.es/google-compra-edata"/>
</head>

Alternativamente puedes usar el metatag:

<head>
...
<meta name="standout" content="https://www.seofreelance.es/google-compra-edata"/>
</head>

Cuando la URL indicada en el valor de href apunta a la propia URL del documento, interpretaremos (Google) la etiqueta como una auto-referencia. Cuando la URL del href apunte a un artículo en una página externa, interpretaremos (Google) la etiqueta standout como una mención externa, es decir que estarás haciendo referencia a una fuente destacada externa.

Si abusas de Standout: el abuso de la etiqueta Standout puede provocar que dicha etiqueta sea ignorada unilateralmente (por Google) para todo el sitio infractor o incluso que el sitio sea rechazado por Google News.

Este artículo es la adaptación original al español del documento emitido por Google en inglés

Google Hummingbird | Análisis detallado de búsqueda semántica y su papel en el algoritmo Colibrí

Google Hummingbird o "Colibrí" es el nombre del último y gran cambio en su algoritmo de búsqueda

Traducción y adaptación al Español del original en Inglés por Joydeep Bhattacharya 30 de octubre 2013

Google ha puesto en marcha la búsqueda semántica en su algoritmo principal por la reciente introducción de Hummingbird. Este es un cambio extraordinario y uno de los más grandes tras Caffeine. Muchos webmasters y comerciantes de Internet todavía sienten cierta confusión respecto a esta nueva tecnología. En este post, voy a tratar de aclarar esta confusión explicando la búsqueda semántica y cómo Google implementa la semántica para predecir la intención buscadores con el fin de mostrar los resultados o devolver respuestas basadas en ellos.

¿Qué es la semántica ?

Semántica implica la búsqueda de la relación entre palabras, frases, símbolos y el significado que conllevan. Implica además el estudio de la lingüística, la sintaxis, la etimología, la comunicación, la semiótica, etc.

La búsqueda semántica

La búsqueda semántica consiste en el estudio y la aplicación de la semántica en la tecnología de búsqueda con el fin de averiguar la verdadera intención que se oculta tras la consulta de búsqueda del usuario y la presentación de las respuestas o un conjunto de resultados que se relaciona estrechamente con lo que el usuario está buscando. Tiene en cuenta la importancia del contexto e identifica una relación adecuada entre los términos utilizados en la consulta de búsqueda antes de presentar los resultados de la búsqueda final.

¿De dónde se aplica ?

Los motores de búsqueda utilizan la semántica para devolver resultados relevantes a la consulta. Consultas ambiguas (aquellas consultas que tienen más de un significado) se descomponen y se procesan a través de un conjunto de palabras predefinidas que ayudan a los motores de comprender el contexto real de la consulta. El uso de la semántica se aplica en las consultas relacionadas con la investigación en que el usuario está buscando respuestas en lugar de navegar a una página web específica. Google aplica la semántica en su Knowledge Graph.

Page Rank y la Relevance Score dos factores básicos para la clasificación de documentos

Google aplica dos factores básicos para juzgar la importancia y relevancia de cualquier página web antes de clasificarlos. Estos factores son el Page Rank ( para medir la popularidad mediante el análisis de la relación con el entorno de los vínculos) y la relevancia (mediante el análisis del uso de palabras clave o buscar términos de consulta utilizados en la página web). Sin embargo, esta forma de clasificación de documentos no ayuda a encontrar esas páginas que pueden ser de interés para la intención de los investigadores (léase “usuarios”) ya que el factor de popularidad puede reducir la clasificación de documentos semánticamente pertinentes. Esta es la razón por la que Google utiliza la semántica para identificar y priorizar los rankings de páginas que tienen contenido semánticamente relevante y no sólo basándose en contar las palabras clave y enlaces entrantes para el análisis de cualquier página web.

Procesar una consulta en un entorno semántico

En la figura siguiente se describen los pasos a seguir en el proceso de la consulta por parte de Google. La consulta de búsqueda que recibe Google se analiza para identificar uno o más miembros (primer y segundo términos de búsqueda). En este proceso consigue identificar sinónimos u otros términos de sustitución. Los sinónimos son conocidos como sinónimos candidatos y aún se descomponen y se procesan como sinónimos calificados. Entonces un motor de relación se utiliza para identificar la relación entre los miembros sobre la base de sus respectivos dominios. Aquí un dominio simplemente es una categoría central de palabras similares (los conocidos como keyword clusters). En primer término de búsqueda queda identificado por el primer dominio que es una categoría semántica que tiene una colección de entidades predefinidas. Del mismo modo, el segundo término queda identificado por un segundo dominio que contiene también una base de datos de entidades similares. Esto ayuda a Google a relacionar los términos con las identidades que resulten más cercanas (un punto fundamental a tener en cuenta aquí es que Google sólo encontrará y relacionará palabras en la consulta con los ya presentes en su base de datos , que es la gráfica del conocimiento o Knowledge Graph, por lo tanto, algunas consultas, aunque semánticamente similares podrían no aparecer). Una búsqueda separada queda a cargo de un motor de consulta con relación de coincidencia de dominio (no confundir con el dominio de la palabra con el “nombre de dominio”, aquí “dominio” significa “categoría”) y el resultado final queda mostrado después de que se identifica una consulta semántica (el motor de búsqueda puede pluralizar o reformular la consulta si es necesario). Por lo tanto, en palabras simples, una consulta compleja introducida por el usuario se descompone y se simplifica con la participación de varios procesos en búsqueda semántica. A partir de entonces , las páginas web de interés se identifican y se muestran como un conjunto final de resultados.

Muchos SEOs y Marketeers en Internet a menudo pierden la parte crucial de la identificación de las consultas relacionadas semánticamente al hacer investigación de palabras clave, porque la consulta principal se descompone en consulta semántica antes de ser procesado por Google. Por lo tanto, aumenta la probabilidad de clasificación cuando el contenido de la página web está escrito teniendo en mente las variantes semánticas que contemplan todas las entidades que coincidan con dominios específicos (Nota de traducción/aclaración: usar familias de significado cercano, transversalidad, en vez de repeticiones verticales de keywords).

Colibrí y la semántica

Hummingbird es un cambio en el algoritmo de búsqueda que utiliza varios factores que ayuda a iniciar la conversación con el buscador y proporciona respuestas reales a las consultas en lugar de devolver documentos que corresponden a la palabra clave. Este es el sueño del Googler Amit Singhal ( vicepresidente senior y director de Búsqueda de Google), que quería construir un motor de búsqueda en plan Star Trek que devuelve respuestas directas a los usuarios para que Google puede ser utilizado como un asistente personal en lugar de un motor de búsqueda. En sus palabras, el destino de la búsqueda es llegar a ser el equipamiento de Star Trek, un asistente perfecto al tu lado. Hummingbird tiene que ver con la conversación y las consultas long tail suelen participar en la conversación. Además, durante la conversación que incluya una o más entidades y aquí es donde Knowledge Graph y la semántica entran. El punto crucial es que Google ha adaptado su algoritmo de búsqueda para manejar consultas complejas y conversacionales introducidas por el usuario. Se ha utilizado la semántica y el Graph para llegar a un conocimiento mucho más profundo de lo que se ha utilizado en el pasado. Como he mencionado antes, no hay que clasificar Hummingbird como factor de clasificación, es un cambio para mejor comprensión de una consulta de búsqueda. Las señales de clasificación documental siguen siendo los mismos Panda , Penguin , etc, que son todos partes del algoritmo principal, que ahora es el colibrí. Factores como la Autoridad de dominio, Page Rank, popularidad social, la relevancia global de contenido, Tf -IDF Score (del inglés Term frequency – Inverse document frequency en relación, no sudes, mira en Wikipedia), la edad del dominio, Google Authorship, uso de MetaData etc todo contribuye a la clasificación de un documento específico. Pero, sin duda podemos utilizar este nuevo modelo para adaptar nuestro contenido existente adaptado a la forma en que una consulta resulta analizada e identificada.

Como se muestra en el siguiente ejemplo, una consulta de conversación como ¿Cuántos años tiene Justin Bieber? devuelve una respuesta directa junto a un gráfico del Conocimiento. En este caso, Justin Bieber es una entidad que Google ha identificado con la ayuda del gráfico de Conocimiento (Knowledge Graph) y predijo con exactitud la respuesta para la consulta del usuario.

Consulta basada en preguntas conversacionales en vez de cadenas de texto específicas

Consulta semántica conversacional, el usuario pregunta en vez de proponer una cadena de texto como consulta.

Hummingbird tiene en cuenta la semántica e identifica la relación entre las consultas de búsqueda que tienen la ayuda de Knowledge Graph antes de presentar los resultados de la búsqueda. Un buen punto a destacar aquí es que la semántica no es nueva para Google y el gigantesco motor de búsqueda ha estado utilizando la semántica por un tiempo bastante largo, pero faltaba una base de datos detallada de la relación de Entidades que podrían ayudar a facilitar la identificación de las entidades. Después de la introducción de la gráfica de conocimiento el 16 de Mayo 2012, Google ya pudo decir que había añadido esa base de datos de Entidades que podría resolver rápidamente el problema de encontrar relación entre las entidades. Por lo tanto, Hummingbird basado en el Knowledge Graph es el nuevo modelo semántico de Google.

 

Prerender, usabilidad y velocidad de carga como factores SEO

SEO WPO Prerender Google Developers

Prerender y Prefetching precargan tus páginas para mejorar la UX

El Lunes 25 de Junio Google nos ofrecía una nueva perspectiva y renovada información sobre una llamativa y muy poco extendida técnica de mejora en usabilidad y velocidad de carga desde su blog para webmasters, en este artículo de Google se profundiza y se revisa el concepto primigenio de prefetching, compartido con Mozilla, aunque de la idea original se ha derivado una técnica que Google comparte con el mundo y que se basa más en sus propias capacidades técnicas e infraestructurales y planes estratégicos que en acuerdos comunes con W3C u otras entidades que ejercen influencia en el desarrollo de Internet y la www.

Como todo, el prerenderizado tiene cosas buenas y cosas malas, es recomendable leer con atención antes de ponerse manos a la obra.

A continuación os ofrezco la traducción EN > es-ES del artículo original, si vas a jugar con prerender y necesitas los datos te invito a seguir leyendo (debería decir “recomiendo”!)…

Guía para desarrolladores web sobre prerenderizado en Chrome

El prerenderizado es una característica experimental en Chrome desde su versión 13 en adelante,
esta característica puede seguir las sugerencias del autor de la página para acelerar la experiencia de navegación de los usuarios.
El autor del sitio incluye un elemento en HTML que instruye a Chrome para recopilar y renderizar una página adicional antes de que el usuario se traslade efectivamente a ella.

Como desarrollador web puedes estar interesado en lanzar el prerender o no, mucho más frecuentemente tendrás interés
en detectar si tu sitio está siendo prerenderizado.

Un vistazo a prefetching y prerender

Debido a que la Web es un sistema distribuído, puede darse un lapso entre el clic del usuario sobre un enlace y la carga efectiva de la página.

Este problema se hace especialmente notable en sitios que incluyen JavaScript, plugins y otros materiales referenciados como multimedia u hojas de estilo.

En algunos casos es posible saber donde es probable que el usuario haga el siguiente clic, por ejemplo cuando un usuario está leyendo un artículo multi-página es probable que haga clic en el enlace de “Siguiente página”.

En estos casos, estaría bien que el navegador pudiera comenzar a cargar la página ANTES incluso de que el usuario hiciera el clic, de forma que cuando haga el clic la página esté ya en camino o lista para ser leída. Este es el objetivo principal detrás del prefetching y el prerender. El concepto de prefetching está incluido en el estandar de HTML5.

El prefetching es una característica actualmente implementada en Firefox (saber más sobre Firefox y prefetching).
Permite a los autores web incluir un tag en el HTML que instruye al navegador para comenzar a recoger una URL dada. Cuando encuentra el tag, el navegador recoge el recurso de mayor nivel en dicha URL (a menudo una página HTML).
De todas formas el prefetching a menudo no conduce a mejoras en velocidad de carga que sean notadas por el usuario porque la mayor parte del contenido está en subrecursos como Javascript, CSS y ficheros multimedia. A la vez en algunos casos los subrecursos no son siquiera parte del HTML tal como los proporciona el servidor, siendo insertados vía scripts solamente cuando la página se carga.

El prerenderizado extiende el concepto de prefetching. En vez de limitarse a descargar el recursos principal, hace todo el trabajo necesario para mostrar la página al usuario sin llegar a mostrarla hasta que el usuario hace el clic. El prerenderizado se comporta similarmente al hipotético caso de un “medio clic” sobre un enlace de una página (abriéndola de fondo en una pestaña) y luego se pasara a esa pestaña. Aún así, con el prerender esa “pestaña de fondo” está totalmente oculta para el usuario y cuando este hace clic, sus contenidos se transfieren de forma inadvertida a la misma pestaña a la vista del usuario. Desde el punto de vista del usuario, la página simplemente se carga mucho más rápido que antes.

Los desarrolladores web pueden lanzar el prerenderizado como se describe a continuación. Comenzando en Chrome 17, Chrome mismo iniciará el prerenderizado en algunos casos, basándose en la interacción del usuario con la barra de direcciones.

Iniciando el prerenderizado

Decidir si usas o no usas prerenderizado

El prerenderizado es una funcionalidad avanzada en fase experimental, por lo que iniciarla en un momento poco adecuado puede derivar en la degradación de la experiencia de usuario, incluyendo un aumento de consumo de ancho de banda, mayor lentitud cargando otros enlaces y contenidos ligeramente obsoletos. Deberías considerar iniciar el prerenderizado solamente si tienes muy claro que enlace visitará el usuario a continuación. Por ejemplo, prerender podría ser potencialmente una buena idea para un enlace “Siguiente página” en un artículo. Ofrecer señales para prerendering será típicamente no apropiado para una inmensa mayoría de los casos.

Sintaxis para iniciar el prerenderizado

El prerenderizado en Chrome es iniciado por una etiqueta en HTML, similarmente a como se inicia el prefetching en Firefox. (Ten en cuenta de todos modos que a diferencia de Firefox los métodos de inicio mediante meta-http y cabeceras HTTP no son soportados de momento.)

Puedes iniciar el prerenderizado insertando un elemento link con su atributo rel en valor “prerender”, por ejemplo:
<link rel="prerender" href="https://www.seofreelance.es/blog/"/>
Cuando Chrome encuentra el elemento considerará prerenderizar la página enlazada. Esto sucedería durante el parseado de la página, o posteriormente si el elemento link se inserta dinámicamente en el documento vía JavaScript.

Usamos la rel ‘prerender’ en vez de ‘prefetch’ para denotar que se trata de una implementación experimental y asegurar que los usuarios de prefetch no disparan accidentalmente prerender sin entender como difiere respecto las implementaciones actuales de prefetch. Recuerda que la etiqueta es solamente una pista para indicar a Chrome que tal vez le interesaría prerenderizar algo — no garantiza que el prerenderizado suceda.

Algunas razones por las cuales el prerenderizado podría no suceder

Nota: Lista no exhaustiva, última actualización (del original publicado en Google en inglés) 13 de Junio de 2011.

  • El usuario emplea una versión de Chorme en la que el prerenderizado no está activado por defecto
  • El usuario ha deshabilitado el prerenderizado desmarcando la opción de configuración “Predict network actions to improve page load performance” (“Predecir acciones de red para mejorar el rendimiento de carga de páginas”)
  • Otra página está ya siendo prerenderizada. Chrome solamente hace prerender como máximo de una URL por instancia de Chrome (no una instancia por pestaña). Este limite podría cambiar en el futuro en algunos casos.
  • Hay múltiples directivas prerender en la página, situación indefinida sobre que directiva se acepta o ignora que dependerá de la secuencia en que dichas directivas son encontradas
  • Chrome encontró otra directiva prerender en los últimos 500 ms.
  • El usuario está navegando en una ventana de incógnito
  • El prerender es abortado en base a una situación causada por la página receptora. (Ver “Situaciones en las cuales el prerenderizado es abortado”).

Ver la sección “Debugging the Prerender” para más ayuda en el análisis de sucesos de prerenderizado en una instancia dada.
Para prevenir la presentación al usuario de contenido obsoleto, las páginas prerenderizadas con éxito serán purgadas (“expulsadas” en el texto original en inglés) tras 30 segundos si el usuario no ha hecho aún clic sobre el enlace a la página prerenderizada. Este limite puyede cambiar en el futuro. Las páginas que son prerenderizadas no aparecerán en el Histórico de navegación del usuario a menos que el usuario visite efectivamente la página. Aún así, los recursos cacheables de una página efectivamente prerenderizada y no visitada pueden permanecer en la caché, los cambios que los sitios prerenderizados hagan a las cookies persistirán.

A pesar de que el prerenderizado ha sido cuidadosamente diseñado con la seguridad en mente y a pesar de que Chrome abortará el prerenderizado en escenarios donde se detecte un sitio malicioso, existen escenarios de abuso, del mismo modo que existen en tecnologías establecidas como iframes.

Detectar cuando tu sitio está siendo prerenderizado

Incluso si no lanzas el prerender proactivamente, sigue siendo posible que otro sitio instruya a Chrome para prerenderizar tu sitio. Si tu página está siendo prerenderizada, esta podría (o no) ser mostrada al usuario (dependiendo de si el usuario hace el clic efectivo o no). En la inmensa mayoría de casos no tendrías que hacer nada especial para manejar el hecho del prerenderizado de tu página -simplemente debería funcionar.

Si necesitas saber si tu sitio está siendo prerenderizado (por ejemplo no quieres que una galería de imágenes se ponga a rotarhasta que el usuario en verdad está viendo la página con dicha galería, la API experimental de Visibilidad de Página (originalmente “experimental Page Visibility API“) proporciona una vía conveniente para detectar esos casos y reaccionar apropiadamente.

Nota: Chrome no pasa ninguna cabecera distinguible cuando el prerenderizado ocurre. Dado que la mayoría de prerenders convierte los prerenderizados en vistas de página reales, la API de Visibilidad de Página es el único modo de discriminar correctamente los prerenderizados. Cuando una página es mostrada al usuario, Chrome no manda nuevas peticiones, aunque podrías crear un script que use la API de Visibilidad de Página para lanzar una nueva petición.

Si tu sitio incluye scripts de terceros para analítica o publicidad, en muchos casos no deberías tener que hacer modificaciones a tu sitio -dichos terceros modificarán simplemente el script que proporcionan para hacer uso de la API de Visibilidad de Página. Deberías contactar con estas terceras partes directamente para saber si sus scripts soportan prerender. Puedes probar como se comporta tu página al ser prerenderizada usando este sencillo ejemplo.

Situaciones en las que el prerendering es abortado

Mientras prerenderiza un sitio web, Chrome puede en algunos casos encontrarse en una situación que potencialmente podría desembocar en un comportamiento susceptible de ser visualizado por el usuario, lo cual es incorrecto. En dichos casos el prerender será abortado de forma opaca al usuario.

Algunos de estos casos incluyen:

Nota: Lista no exhaustiva. Última actualización 11/10/2011.

  • La URL inicia una descarga
  • HTML Audio o Video en le página
  • Peticiones POST, PUT y DELETE XML HTTP
  • Autentificación HTTP
  • Páginas HTTPS
  • Páginas que provocan alertas de malware
  • Creación de ventanas/popup
  • Se detecta utilización de alta resolución
  • “Herramientas del Desarrollador” está abierto

Plugins como Flash no serán inicializados hasta que el usuario visite efectivamente la página prerenderizada que los contiene.

Depurar el prerendering

El Prerendering está diseñado para ser cuasi invisible para el usuario casual – los sitios que prerenderizan simplemente cargan más rápido en algunos casos. Chrome decidirá o bien no iniciar o bien abortar un prerender por determinadas razones, lo que significa que para los desarrolladores puede ser difícil a veces discernir si sucedió el prerenderizado en un caso específico.

– La siguiente sección explica como determinar si se usó prerendering en una página –

Tienes la opción de deshabilitar la característica de Chrome 17+ que puede iniciar el prerendering basándose en la interacción del usuario con la barra de direcciones.
Para deshabilitar este tipo de prerenderizado, arranca Chrome con la marca de línea de comandos --prerender-from-omnibox=disabled (Command-line flag en el original)

Comprobar si se usa prerendering en una página

La velocidad de carga de una página por sí misma no es necesariamente un indicador a prueba de tontos de si sucedió el prerender o no. Para chequear si hay prerenderizado para una página dada:

  1. Abre el Gestor de Tareas de Chrome
  2. Carga la página que incluye la señal para prerenderizar
  3. Busca una nueva línea que comienza con “Prerender: ” que muestra un icono especial. Si ves una línea tal, se está haciendo prerendering para esa página

screenshot of Chrome's Task Manager

Comenzando con Chrome 14 la pestaña de tráfico interno (net-internals tab en el original) incluye más información detallada sobre prerendering. Puedes ir a dicha pestaña copiando y pegando esta URL en la barra de direcciones de Chrome: chrome://net-internals/#prerender

Asegurar que prerender está habilitado en Chrome

Prerender se encuentra habilitado para muchos usuarios de Chrome 13 por defecto. Aún así, hay casos por los que prerender pueda estar deshabilitado. Si los pasos para comprobar si se usa prerendering en una página muestran que el prerendering está ocurriendo, entonces tienes habilitado el prerender. La antes mencionada página de test te alertará si tienes deshabilitado el prerender.

Para asegurar con certeza que el prerendering está habilitado:

  1. Mira en la configuración de Chrome y asegúrate que “Predict network actions to improve page load performance” está marcado (lo está por defecto)
  2. Inicia Chorme con la marca de línea de comando --prerender=enabled

Saber más sobre Prerender

Puedes participar en el grupo de debate sobre prerender

 NOTA: Última actualización del original, 30 de Marzo, 2012. 

Page Visibility API

SEO negativo: se acercan tiempos oscuros

SEO Negativo

SEO negativo: un círculo vicioso que causará la involución del SEO

“…Peor es constatar que hablar de SEO Negativo es una consecuencia lógica y previsible tratando el link building en Los Tiempos del Pingüino”

Han pasado unos días tras el Clinic SEO, de nuevo en el Espai Jove La Fontana de Barcelona he tenido la oportunidad después de meses enterrado en trabajo de reecontrarme con algunos de mis amigos, conocidos y colegas SEO de Barcelona y otros lugares.

Comenzaré este artículo confesando, muy a mi pesar, que llegué a Fontana preocupado y me marché preocupado, callándome un último turno de micro por no alargar la sesión y por eso me veo ahora haciendo terapia de blog. Pero es que a mi parecer era demasiado tema para unos minutos…

Ya llevamos semanas oyendo ecos transatlánticos, dos simples palabras: Negative SEO. Y durante el evento “SEO negativo” sonó en vivo y en directo, en charlas informales, en pequeños corros susurrantes, vibrando a través de los altavoces y lo peor viene ahora:
Malo haber oído a todo volumen el silencio del SEO Negativo entre líneas y palabras no pronunciadas.
Peor es constatar que hablar de SEO Negativo es una consecuencia lógica y previsible tratando el link building en Los Tiempos del Pingüino…

Muchos y muchas coincidimos entre grititos y exclamaciones en que Google Penguin ha causado caídas pronunciadas en SERP a nivel de palabras clave aisladas: mientras que unas suben, bajan o fluctúan de forma habitual y razonable, otras caen del orden de 30 a 50 posiciones de una tacada. Algunos estamos de acuerdo en que más que una sobreoptimización, el problema que tiró a tus keywords de la moto fue probablemente algún enlace mal digerido, de esos que se repiten por la noche.

¿Qué pasa con Google? Lo pone cada vez más dificil y hacer lo que se nos pide por boca de Matt Cutts puede llegar a ser de todo menos una ayuda. Hasta hace unos meses la comunidad SEO se conjuraba en momentos de incertidumbre mediante el mantra “Correlation is not causation” pero en estos momentos se puede percibir un alto grado de confusión, prisa y riesgo potencial ya que la correlación es cada vez más difícil de observar en un mar de variables en cambio permanente.

¿Sabes qué pasa conforme un ambiente se va haciendo hostil para las formas de vida que lo habitan?

Que interviene la selección natural (lo siento creacionistas ;-) y la biodiversidad es lo primero que cae, se reduce el número de especies distintas y permanecen aquellas que a)depredan a las demás o b)tienen mayor capacidad de adaptación.

¿En qué acaba esto? Puede acabar con la interrupción de la cadena trófica y en una lenta agonía de las especies. De todas ellas.

Como otros SEO profesionales llevo luchando contra una fama injusta desde que empecé a hacer SEO allá por 2002, la fama creada por la tribu de los vendehumo, los timadores 1.0 y otros parásitos por el estilo. A pesar de hacer las cosas bien esa pelea contínua para pagar deudas que no he contraído no ha cedido hasta apenas unos 2 años atrás… Ahora me temo que los próximos 2 años van a traer una nueva pelea, esta vez contra los deconstructores SEO, que podría ser un neologismo educado para “gente con amplios conocimientos SEO que acepta encargos de ataque, sabotaje y guerrilla contra competidores legitimos a los que el contratante no puede vencer por las buenas“.

Esta es la conclusión a la que llego, la hostilidad creciente del ecosistema Google va a radicalizar la adaptación de la profesión SEO, ya sabemos por experiencia que tras Florida en 2005 aparecieron los auténticos Black Hat y toda suerte de grados intermedios.

Ahora puede resultar más barato derribar a tu oponente que trepar más alto que este, por lo que aquellos con menos escrúpulos podrán contratar a aquellos con menor ética profesional para conseguir tan bajo fin.

¿Cómo? ¿Me has llamado ingenuo? Bueno, hay personas tan honestas que a veces parecen niños, como yo admiro eso me tomaré lo de ingenuo como un cumplido.

Cierto es que para defenderse en un escenario de SEO Negativo hay que saber atacar, pero siempre desde un punto de vista constructivo y proactivo

Usa tus conocimientos negativos para construir

Usa tus conocimientos negativos para construir

Cuando los bandos contendientes ignoran las capacidades del oponente o se enfrentan por primera vez a técnicas nuevas y desconocidas, se tiende al inmovilismo por desconocimiento. Eso no interesa a nadie.

La guerra de trincheras se caracteriza por el inmovilismo y el desgaste no productivo

La guerra de trincheras se caracteriza por el inmovilismo y el desgaste no productivo

La batalla deja terreno quemado y yermo allá por donde pasa, no le interesa a nadie un escenario de SEO Negativo que complicaría aún más el trabajo honesto, ya difícil de por sí.

La batalla deja terreno quemado y yermo allá por donde pasa

La batalla deja terreno quemado y yermo allá por donde pasa

Creo sinceramente que el trabajo SEO serio comporta una componente de responsabilidad social.
¡Ayúdame y ayúdate evitando que este post sea una predicción acertada!

Si algún día digo -“Yo ya lo dije” no será con una sonrisa.

Aquí os dejo más material sobre link building en tiempos de Google Penguin en mi blog alternativo.

Videos SEO

Google compra Nest Labs ¿Asalto a la Internet de las Cosas?

Google compra Nest Labs

En Estados Unidos la cobertura de los movimientos de Google Inc. son seguidos con atención, el último de ellos, la adquisición de Nest Labs ha dejado la sorpresa pintada en la cara de l@s expertos en temas de economía y vigilancia de compañías que cotizan en NASDAQ

¿Por qué querría Google adquirir Nest Labs?

Nest Labs es una pequeña empresa especializada en soluciones de domótica, desde los círculos más interdisciplinarios se especula sobre la posibilidad del asalto de Google a la Internet of Things (IoT)

Google compra Nest Labs

Google compra Nest Labs

Aquí os dejo unas muestras de la cobertura mediática en EEUU, lleva anuncio al inicio…


http://on.wsj.com/1d07SI7


http://on.wsj.com/1d0r2xr


http://on.wsj.com/1dn8Eji

Desde los interesados, encontramos esto: Nest, Google and You

Penalización Google pese a enlaces Nofollow

¿Los enlaces Nofollow pueden suponer una penalización por parte de Google?

[youtube=http://www.youtube.com/watch?v=QSEqypgIJME&w=580&h=300]

Transcripción resumida del video

“Los enlaces nofollow normalmente no pueden hacerle daño a su sitio, así que a bote pronto ya queda adelantada la respuesta. Dicho esto, permítanme mencionar un caso poco habitual y un tanto extremo que podría suponer una acción por nuestra parte: si comienzas a dejar comentarios indiscriminadamente por todos los blogs d​​el mundo, exagerando, incluso si dichos vínculos fueran nofollow , si realmente te pones pesado y la gente comienza a enfadarse por tu actividad y comienzan a aparecer spam reports contra ti, podemos tomar algunas medidas manuales contra spam.”

“Recuerdo que durante mucho tiempo en TechCrunch, a la que alguien escribía algo, había un tipo (de nick anon.tc) que se presentaba y hacía comentarios sin sentido, estaba claro que estaba tratando de atraer tráfico de las personas que leían los artículo hacia lo que fuera que estuviera promoviendo. Así que incluso si esos vínculos son nofollow , si vemos acciones lo suficientemente masivas como para consideralo engañoso o manipulador, nos reservamos el derecho a tomar medidas”.

Una vez escuchado y entendido, el mensaje es básicamente el siguiente:

Si no detectamos actividad masiva y/o potencialmente anómala y fraudulenta, no sufrirás una penalización Google

El mejor remedio es la prevención en forma de perfil de enlaces sano.

Videos SEO | Penguin 2.0

Penguin 2.0 ¿Tormenta de Verano o Invierno Nuclear?

Video SEO de los que marcan época, literalmente, bastantes webs quejumbrosas pueden florecer y algún que otro campeón caer de su pedestal. Según Matt no habrá debacle, pero eso ya se dijo antes ¿Verdad?

[youtube=http://www.youtube.com/watch?feature=player_embedded&v=xQmQeKU25zg&w=640&h=385]

 

Pingüinos en Verano: llega Penguin 2.0