Categoría: Posicionamiento Online

  • IA y buscadores: las búsquedas van a cambiar, y mucho

    IA y buscadores: las búsquedas van a cambiar, y mucho

    2023 comenzaba como una OLA vertiginosa sucesión de eventos y noticias sobre el LLM de OpenAI: ChatGPT. Esta herramienta basada en IA nos fascinó. Ha sido de esas cosas que marcan un antes y un después, y que a muchos nos ha ilusionado cual regalo bajo el árbol de navidad. A quienes ejercemos una profesión digital nos ha traído posibilidades tan atractivas como las de agilizar procesos de trabajo y abaratar ciertas acciones: desde la generación de código de programación hasta la creación de estructuras de contenidos y textos. Pero evadiendo esta visión marcadamente profesional, poniéndome los zapatos del ciudadano promedio, la llegada de esta tecnología es una pasada básicamente porque nos entiende (o al menos lo parece). Se acabó conversar con “máquinas tontas”, ahora parece que hay una persona (con educación y formación básica) detrás de cada interacción, ofreciendo respuestas coherentes y fundamentadas en buena parte de los casos. 

    Hasta la fecha, cuando nos situamos tras la pantalla con una pregunta en mente, hemos tenido opciones más o menos limitadas para encontrar respuesta a nuestras preguntas: redes sociales, foros y unos motores de búsqueda cada vez más inteligentes, capaces de localizar información concreta como resultados de nuestras consultas. Sin embargo, no siempre ofrecen respuestas lo suficientemente contextualizadas a nuestras consultas. Con aliados como ChatGPT se abrió una puerta que los motores de búsqueda estaban deseando cruzar desde hace tiempo: estas IAs hacen posible ofrecer respuestas con un alto grado de personalización. Es la oportunidad perfecta para ofrecer lo que el usuario quiere en la propia SERP, reteniendo más tráfico y durante más tiempo en el propio buscador.

    Nuevas posibilidades, nuevos buscadores

    Los grandes no iban a dejar pasar esta oportunidad. Microsoft dió el primer golpe integrando la tecnología de OpenAI en su buscador Bing. Fue una implantación casi inmediata tras el hype inicial generado por ChatGPT. De forma un poco rezagada, Google comenzó a dar las primeras pinceladas sobre cómo iba a integrar la IA en sus distintos servicios, destacando en especial Google Bard, algo así como la competencia directa de ChatGPT. A raíz de esto, Google presentó lo que denominó SGE (Search Generative Experience), una forma de integrar la IA generativa en las búsquedas realizadas en el gigante de Mountain View. Esto puede y va a suponer un cambio importante en cómo los usuarios vamos a interactuar con los buscadores:

    • Con el uso de la IA, los motores de búsqueda podrán responder a consultas que hasta ahora no podían, o al menos no con la misma eficacia. Los resultados van a ir más allá del índice del buscador, y lo que no se encuentre en este índice, lo generarán con la ayuda de la IA.
    • Para el usuario es algo genial: el buscador ahora puede responder de forma personalizada y acorde al contexto de la consulta (ya sea aportado deliberadamente por el usuario, o basado en búsquedas previas e incluso en datos de navegación).

    Y por supuesto, también apunta a que va a suponer cambios drásticos para los propietarios de webs y los profesionales orientados a la adquisición de tráfico orgánico:

    • Es bastante probable que los resultados de búsqueda generados por IA sean tan certeros que el usuario acabe su búsqueda sin acceder a ninguna web, quedando el tráfico relegado al propio buscador. Esto es algo que ya ha pasado con anterioridad, como por ejemplo, cuando buscadores como Google comenzaron a devolver “Direct Answers”, ofreciendo respuestas al usuario sin necesidad de navegar hacia una nueva página.
    • La forma de buscar de los usuarios va a cambiar. Tanto en el flujo de uso del propio buscador como en cuanto a la forma de escribir/redactar las consultas. A continuación entraré a argumentar este punto en detalle.

    SGE y la forma de buscar de los usuarios

    Entroncando con el punto anterior, es este precisamente el propósito que me ha llevado a escribir este artículo. No sólo va a cambiar el flujo de acciones o “journey” durante la búsqueda, sino también las propias consultas. 

    Las funcionalidades y capacidades de los buscadores han condicionado en buena parte cómo buscamos en ellos. No hay mejor ejemplo que los albores de los buscadores, cuando su capacidad de comprensión era casi nula y su sistema de búsqueda se basaba en la mera presencia de términos concretos (hablando de forma simplista). De esta forma, cuando queríamos encontrar cierta información, como por ejemplo, los principales puntos turísticos de Marbella, acorde al primitivo funcionamiento del buscador, lo común era realizar búsquedas empleando un lenguaje muy sencillo, carente de artículos e incluso verbos. Por ejemplo: “turismo Marbella” o “guía viaje Marbella”. 

    Sin embargo y por fortuna, los motores de búsqueda han ido evolucionando. Gracias a la integración de mecanismos diversos y tecnologías como NLP, son capaces de comprender cada vez mejor las búsquedas del usuario (véase el revolucionario Google BERT allá por 2019), de manera que en la actualidad podríamos buscar “Cuáles son los principales puntos turísticos de Marbella” y Google es capaz de devolvernos resultados acordes a la búsqueda aunque no contengan expresamente los términos empleados en la consulta.

    A la idea que quiero llegar es la siguiente: desde que comenzamos a usarlos, hemos aprendido a buscar según los buscadores nos han permitido hacerlo, adaptándonos a sus limitaciones y comprendiendo de qué forma funcionan mejor para nosotros. La irrupción de estas IAs capaces de conversar y comprendernos en buen grado, van a traer consigo un consiguiente cambio en la forma en la que nos vamos a dirigir a los buscadores. En la medida que los buscadores sean capaces de conversar de forma natural gracias a la IA, nos acostumbraremos a hablarles de tal forma. Pasaremos entonces del primitivo “guia viaje marbella” a “¿Qué puedo ver en Marbella durante septiembre en familia?”, y pasaremos a usar unas consultas más complejas y naturales por una simple razón: porque el buscador nos entiende y es capaz de respondernos de forma coherente.

    Abro un pequeño paréntesis: las búsquedas por voz

    Es curioso y digno de mención el caso de los asistentes y búsquedas por voz, que si bien parecían llamadas a “revolucionar el SEO” y la forma de buscar (Fernando Muñoz ya habló de ello), no ha sido tal, y eso que precisamente ofrecen una buena oportunidad para que los usuarios empleen un lenguaje natural. ¿Por qué no ha corrido mejor fortuna?, básicamente porque detrás de estas consultas y asistentes de voz subyacían motores de búsqueda con ciertas limitaciones. Ahora la IA abre una nueva etapa para las búsquedas por voz y los asistentes de voz, pues van a brindarnos sistemas capaces de conversar con una presumible naturalidad. Aunque esto es harina de otro costal que merece un análisis propio.

    Términos long tail: presente y futuro

    Tras este paréntesis, es momento de retomar el concepto de términos long tail. Cuando nos referimos a estos, hacemos referencia a términos de búsqueda compuestos habitualmente por un conjunto más o menos extenso de palabras. Suelen ser consultas más detalladas y que cuentan con un volumen de búsqueda relativamente bajo. Por ejemplo “Donde puedo encontrar un Pikachu en Pokemon Go”. Si bien este tipo de consultas son menos habituales que los términos genéricos (por ejemplo, “Pikachu Pokemon Go”), cuando los usuarios empecemos a familiarizarnos con los nuevos buscadores basados en IA y se transforme nuestra manera de buscar, las tornas pueden invertirse, pasando el long tail a dominar las búsquedas. 

    ¿Por qué un usuario va a buscar “Guía Marbella” cuando ahora puede obtener respuesta a una consulta mucho más específica y contextualizada? Si el long tail siempre ha brindado una oportunidad brillante para captar tráfico, ahora va a jugar un papel más destacado aún, una oportunidad de comprender al usuario y brindarle información más relevante para sus búsquedas.

    Ante esta nueva generación de buscadores y los consecuentes (hipotéticamente hablando) cambios en las búsquedas de los usuarios, se pone de relevancia la necesidad de conocer mejor a nuestros usuarios y sus intenciones de búsqueda. Más que nunca, la intención es la prioridad por encima de trabajar los contenidos pensando en incluir keywords sin ton ni son. Pero eso, amigo/a SEO, ya lo sabías perfectamente.

    Como cierre de esta SEO-reflexión, he de reconocer que todo lo anterior se basa en una apreciación meramente personal -para mí es lógico- pero desgraciadamente carezco de datos que fundamenten mi análisis. Sin cifras esto no es más que una corazonada, para bien o para mal, ver envejecer este tipo de artículos es precioso.

  • Marcador para visualizar los encabezados de la web sobre el propio diseño

    Marcador para visualizar los encabezados de la web sobre el propio diseño

    Dentro de las actividades habituales de un consultor SEO está la de analizar un sinfín de URLs. Durante el análisis de una URL, una de las acciones más básicas es la de revisar los encabezados (<h1>…<h6>) que contiene, su organización y jerarquía, en pro de evaluar si se cumplen las mejores práxis en cuanto a los estándares HTML y la semántica de la página.

    Para conocer qué encabezados se emplean en una URL existen multitud de plugins, que si bien nos dan directamente el listado de encabezados, no nos indican en qué parte de la página se ubican, por ejemplo:

    Encabezados extraídos con el plugin Detailed SEO extension
    Encabezados extraídos con el plugin Detailed SEO extension

    Sin embargo, para conocer dónde están ubicados estos encabezados no nos queda más remedio que ir visualizando la página en paralelo y rebuscar los textos que ha extraído la extensión en cuestión.

    ¿A que molaría poder ver qué encabezados hay y su tipo, directamente sobre el diseño de la página? Algo así:

    Ejemplo del resultado de ejecutar el marcador para visualizar encabezados

    Particularmente, me resultaría muy cómodo poder revisar los encabezados de una URL de forma tan visual y rápida. Ante esta necesidad, con la ayuda de ChatGPT, me he dispuesto y preparado una función JavaScript que puede ser ejecutada desde un marcador de tu navegador, sin necesidad de instalar nada más. Al ejecutarla obtendremos un resultado como el de la imagen superior.

    ¿Cómo funciona?

    1. Vamos al administrador de marcadores de nuestro navegador (Ctrl + Mayus + O en Google Chrome/Windows) para añadir un nuevo marcador.
    2. Al añadir el marcador completamos los siguientes campos:
    Creación del marcador con la función JavaScript en Google Chrome

    En el campo «Nombre» incluiremos el nombre de nuestro marcador, tal y como aparecerá en la barra de marcadores del navegador. En este caso he optado por llamarlo «Ver encabezados».

    En el campo «URL» es donde ocurre la magia. Debemos incorporar el siguiente código JavaScript:

    javascript:(function() {  var estilo = document.createElement('style');  estilo.innerHTML = 'h1:before { content: "H1 "; font-weight: bold; color:red!important; } h2:before, h3:before, h4:before, h5:before, h6:before { font-weight: bold; color:red!important; } h2:before { content: "H2 "; } h3:before { content: "H3 "; } h4:before { content: "H4 "; } h5:before { content: "H5 "; } h6:before { content: "H6 "; }';  document.head.appendChild(estilo);})();
    

    Guardamos el marcador y ya podemos usarlo, símplemente navegando hacia la URL que quedamos analizar y pulsando sobre el marcador de nuestro navegador:

    Ejemplo del marcador creado en Chrome

    ¡Y se obra el milagro!

    Resultado tras ejecutar el script para visualizar los encabezados de la página

    Parece una tontería, pero algo tan simple me ha resultado bastante útil en múltiples ocasiones y por eso me he tomado el tiempo de compartirlo. Estoy seguro de que a más de uno/a le servirá también, no sólo para los SEO, sino también para quienes trabajan codo con codo con ellos en el diseño de una web.

    ¡Un saludo!

  • Aprender SEO: reflexiones y consejos para empezar

    Aprender SEO: reflexiones y consejos para empezar

    Actualizado el 5 de julio de 2024

    Como algunos sabréis, además de consultor SEO en Grupo Raíz Digital, también he sido profesor en Edix (ahora extinta, y que ha acabado diluida entre UNIR FP y Qualentum, ambas entidades del Grupo Proeduca). Al igual que cuando comencé en 2020 mi aventura como profesor ayudando a quienes quieren aprender SEO, siempre que me despido de los alumnos lo hago con esperanza de que -al menos una pequeña parte de lo visto en la asignatura- les sea útil en su carrera como futuros profesionales de los motores de búsqueda.

    También soy consciente de que mi asignatura no es la más romántica ni sencilla para quienes aún desconocem el SEO técnico, que muchos/as desconectan cuando llevan un rato escuchando «HTML«, «JavaScript«, «Renderizado«, «Crawleo«. Comprendo que para quienes están aprendiendo SEO puede ser muy estimulante o muy frustrante, pues cada alumno tiene un punto de partida y preferencias. Por eso suelo insistir MUCHÍSIMO en lo siguiente:

    • Preguntad, no os quedéis con dudas, por «ridículas» que parezcan.
    • El SEO, especialmente el técnico, requiere de un proceso de asimilación de conceptos que no siempre es rápido.
    • Gran parte de vuestra destreza y conocimientos vendrán de la experiencia. Probad cosas y experimentadlo en primera persona; es la mejor profesora, y no exagero.
    • Razonad, usad el pensamiento crítico. Existe mucha literatura sobre SEO, pero no existe una fórmula exacta, en SEO todo DEPENDE. Lo más importante es saber cuándo y por qué usar cada recurso.

    No es que lo recomiende como docente, es algo que recomiendo como eterno aprendiz. ¡Ay, el eterno aprendiz!, esa es otra cualidad indispensable de todo profesional SEO (y de todo profesional que se precie sin importar su profesión).

    En cada convocatoria he puesto mi grano de arena, explico las cosas como lo haría a mi hermano al que tantos SEOrmones le cuento y «sufre» (quizás las comillas sobran). Siempre con expectativas de que la mayoría de alumnos/as sepan aprovecharlo en su camino, algo que confieso, siempre me genera incertidumbre, y que imagino, es algo que acompaña a la docencia.

    Aprender SEO desde cero: luces y sombras

    Antes de continuar me gustaría remarcar que voy a seguir la línea del inicio del post: esto es una opinión meramente personal y no pretende ser una valoración absoluta sobre el tema.

    En más de una ocasión me han preguntado cuál es la mejor forma de aprender SEO, qué máster sobre esta temática es el mejor y si verdaderamente compensa la inversión que se realiza en este tipo de formaciones. Y son preguntas muy naturales, pues para bien y para mal, la oferta formativa de SEO ha ido creciendo vertiginósamente. Para bien porque se ha puesto al alcance de todos y para mal porque cualquiera puede montar un curso online y vanagloriarse de un conocimiento que realmente no es tal (o que no justifica el precio que en más de una ocasión pide).

    Si todo esto no fuera poco, quienes ya han decidido adentrarse en el SEO se encuentran con un clásico escollo, el de los contundentes usuarios de foros y redes sociales afirmando:

    «Buah, pasa de másters y cursos, puedes aprender SEO gratis con un par de blogs y dos canales de YouTube«

    ¡Por supuestísimo que es posible!, pero no reparamos en que no todo el mundo es buen autodidacta ni dispone del tiempo o conocimiento para cribar todo un mar de información que hay en la red.

    • ¿Quién nos asegura que estamos ante una fuente de información adecuada?
    • ¿Quién nos aclara las dudas del ejemplo que se expone?
    • ¿Quién nos «obliga» a realizar una serie de actividades prácticas para afianzar los conocimientos?

    Todo esto recae únicamente en las manos del buen autodidacta, que vuelvo a repetir, no es una virtud en manos de todos. Ese es justamente el precio de un máster SEO:

    • Profesores profesionales suelen ofrecer fuentes oficiales y contrastadas, separando la paja del grano
    • Profesores profesionales aclaran tus dudas y contextualizan sus ejemplos
    • Profesores profesionales plantean actividades y ponen a prueba tus habilidades

    Dicho esto, en la vida hay dos cosas muy valiosas: tiempo y dinero. Si tienes tiempo y no dinero para aprender SEO, hacerlo por tu cuenta es la mejor opción, y viceversa. Si tienes tiempo y dinero ¡ve a por todas!

    Lo que yo haría si comenzara a estudiar SEO ahora

    Opciones de pago

    Dentro de la formación pagada, de los cursos y másters de SEO que considero mejor estructuradas y con un claustro de profesores muy competente (insisto, opinión 100% personal) , recomendaría:

    • Kschool (Link al máster). Existen versión tanto presencial como en streaming. Muy completo para mi gusto, de hecho, yo he sido alumno de Kschool y estoy muy contento con la formación recibida, contenidos, clases y su claustro de profesores. Además, no sólo toca SEO, también aborda SEM. A nivel empleabilidad es bastante reconocido en el sector. ¿La pega? No es barato.
    • Webpositer Academy (Link al máster). También cuenta con formación online y presencial. Este no lo conozco de primera mano, pues no he cursado ninguna formación en Webpositer, pero sobre el papel y viendo los docentes, me parece una formación muy completa. En cuanto al precio, tiene varias modalidades, en función a la cuál varía. Ya te adelanto que tampoco es barato.

    Como lo que mejor conozco es Kschool, es el que más puedo recomendar, pero insisto, ambos cuentan con buenos profesores y programas formativos interesantes. Y aunque el precio es elevado, si quieres trabajar en SEO, es una buena inversión.

    Opciones gratuitas (o casi)

    Ahora, como sé que el dinero no cae del cielo, si quieres iniciarte en el SEO de forma gratuita, mi recomendación es:

    Libros SEO que merecen la pena

    Léete un buen libro que te ayude a sentar las bases y a relacionar conceptos. Mis preferidos son*:

    * LLevan enlace de afiliación de Amazon.

    Indaga en los puntos abordados en estos libros

    A partir de eso, comienza a indagar sobre los distintos puntos/secciones que se tratan en estos libros,  ayudándote demedios online como:

    Además de esto, dentro de la documentación de Google puedes encontrar mil explicaciones sobre SEO: 

    Otros sitios para ir más allá (con un enfoque más amplio) en los que indagar son:

    Mantente actualizado, el SEO cambia a diario

    Estar al día del sector es fundamental, y para ello te recomiendo:

    Perfiles de profesionales que puedes seguir para estar al día

    Espero que te sea de ayuda y te animes a aprender SEO. Me he centrado en aspectos fundamentales, pero esto no es todo el SEO que existe ni todas las opciones formativas disponibles (falta el SEO en Medios, el SEO de nichos, la parte de Blackhat, etc.). Pero al menos con esto, curiosidad y fuerza de voluntad, puedes aprender mucho e ir dando tus primeros pasos. ¡Ánimo!

  • Google presenta la nueva directiva para meta robots: «indexifembedded»

    Google presenta la nueva directiva para meta robots: «indexifembedded»

    El pasado 21 de enero de 2022 Google presentó una nueva directiva para la meta etiqueta <meta name=»robots»>: «indexifembedded». A continuación, explicaremos para qué sirve y y cómo no, vamos a plantear una serie de pruebas para verla en funcionamiento.

    ¿Para qué sirve «indexifembedded»?

    La nueva directiva «indexifembedded» nos ayuda a controlar la indexación del contenido de aquellas URLs que a su vez, son embebidas (incrustadas) en otras URLs mediante las etiquetas HTML <iframe> y similares, como <object>.

    ¿Cuántas veces hemos incrustado contenido de terceros en nuestras URL? Seguro que muchas, como por ejemplo: vídeos de YouTube, canciones de Spotify o podcasts de otras plataformas similares:

    <iframe width="560" height="315" src="https://www.youtube.com/embed/YVcBPyb-e6I" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

    Si bien en ese caso «nos da igual» la indexación de la URL de Youtube (o de otro tercero), ¿qué pasaría si el contenido que insertamos vía <iframe> es de una URL sobre la que deseamos controlar la indexación? Pensemos en el siguiente supuesto:

    • Tenemos la siguiente web: www.provincias-de-espana.com
    • Esta web está formada por 1 URL para cada provincia de España, donde aparece información correspondiente a la misma: noticias del día, efemérides e información meteorológica. Por ejemplo: www.provincias-de-espana.com/provincia/madrid/
    • Las efemérides e información meteorológica que se muestran en cada URL de provincia se lleva a cabo mediante el uso de un widget, el cuál se incrusta con la etiqueta <iframe>. A su vez, la información que aporta el widget se obtiene de la URL: www.provincias-de-espana.com/api/widget/madrid.html
    • En este caso, las URLs que nos interesa posicionar son las URLs de provincias (www.provincias-de-espana.com/provincia/madrid/), pues son las que cuentan con un contenido más completo y relevante. Sin embargo, ¿qué pasa con las URLs de los widgets que sólo contienen información de efemérides y clima?, ¿no sería una URL con thin content o contenido pobre? Ante este supuesto, para evitar tener indexadas URLs pobres en contenido, normalmente estas suelen definirse como «noindex».

    Aquí es donde entra en juego la nueva directiva «indexifembedded». Hasta la fecha, si nuestras URLs de widgets (www.provincias-de-espana.com/api/widget/madrid.html) estaban definidas como «noindex», cuando Google rastreaba las URLs de provincias y procesaba su contenido para indexarlo, no tenía en cuenta el contenido presente en el <iframe>.

    Con la aparición de esta nueva directiva, Google nos permite indicar en la URL incrustada (www.provincias-de-espana.com/api/widget/madrid.html), que dicha URL, pese a no ser indexable sí queremos que su contenido sea tenido en cuenta de cara a la indexación de aquellas URLs en las que se incrusta el widget mediante un <iframe>, es decir, siguiendo el ejemplo: nos permite indicar que el contenido de la URL del widget incrustada en el <iframe> sea tenido en cuenta de cara a la indexación de las URLs de provincia (www.provincias-de-espana.com/provincia/madrid/).

    De esta forma conseguimos 2 cosas:

    • Que el contenido de las efemérides y el clima sea tenido en cuenta en la indexación de las URLs de provincias.
    • Que las URLs de widgets no se indexen.

    ¿Cuál es la sintaxis de la directiva «indexifembedded»?

    La sintaxis es similar a la que se emplea en la conocida meta robots. No obstante, para usar esta directiva es imprescindible (obligatorio) que se use en combinación con la directiva «noindex»:

    <meta name="robots" content="indexifembedded, noindex">

    ¡Hora de probar!

    Ahora toca probar si lo que he explicado anteriormente sobre «indexifembedded» es cierto o si estoy errando en mi afirmación. Para ello, voy a incrustar 2 URLs mediante el uso de <iframe>. De estas URLs, una llevará noindex y otra noindex+indexifembedded. En cada una incluiré un «palabrajo» que no posicione actualmente e intentaré ver si esta URL (la que lees) acaba posicionando para uno, ambos o ninguno de los «palabrajos».

    Este término debería posicionar en esta URL. La URL del iframe contiene indexifembedded.

    Este término NO debería posicionar en esta URL. La URL del iframe NO tiene el indexifembedded.

    Conclusiones de las pruebas de uso de la etiqueta «indexifembedded»

    Actualizado el 25/01/2022

    Los resultados del experimento han llegado antes de lo esperado, prácticamente en las primeras 24h (lo cual es de agradecer teniendo en cuenta lo poco que rastrea Google Bot este blog).

    Efectivamente, la hipótesis planteada unos párrafos más arriba se ha cumplido. Al buscar los «palabros» contenidos en cada uno de los dos iframes, Google nos devuelve el siguiente resultado:

    Término procedente del iframe 1 que sí usa la directiva indexifembedded.
    Término procedente del iframe 1, el cuál contiene la etiqueta meta robots noindex+indexifembedded.
    Término procedente del iframe 2 que NO usa la directiva indexifembedded.
    Término procedente del iframe 2, el cuál conteiene sólo la etiquete meta robots noindex.

    ¡Pues ya lo sabemos! Esto funciona acorde a lo esperado. Pero oye, que no se te olvide: esta nueva directiva es soportada únicamente por Google (de momento). De cara a otros motores de búsqueda como Bing, Yandex, Baidu, etc. no tendrá ningún efecto.

    ¡Nos vemos en el próximo experimento!

  • 7 Herramientas para probar y comparar el HTML renderizado de una web

    7 Herramientas para probar y comparar el HTML renderizado de una web

    Uno de los aspectos que tenemos que tener presentes en un proyecto SEO es cómo los bots “ven” la web. Aunque esto no se puede conocer con total exactitud, sí que existen una serie de herramientas que pueden ayudarnos a hacernos una idea de ello y actuar en consecuencia.

    Sólo lo que el bot ‘ve’ puede posicionar.

    Conocer cómo un bot ve nuestra web es importante por varios motivos:

    1. El contenido que los bots “ven” es el que puede posicionar, y en este punto, cuando hablo de contenido me refiero al contenido de una URL en su forma más pura: el código HTML.

    El código HTML es examinado por los bots en varias ocasiones y de varias formas: analizan el HTML sin renderizar y también lo analizan una vez se ha renderizado:

    Para quien no lo sepa, el HTML sin renderizar es aquel que se recibe del servidor sin procesar CSS o JavaScript. Por el contrario, el código HTML renderizado es aquel que resulta tras el procesado de CSS y JavaScript por parte del navegador o bot. En este último, es posible que se incluyan o eliminen contenidos y/o enlaces presentes en el HTML sin renderizar.

    Conociendo lo anterior y de forma muy resumida, Google analiza una URL y su código de de forma similar a: 

    • El bot obtiene el HTML de la URL (sin renderizar), para explorar su contenido y enlaces. (Añade los enlaces descubiertos a la cola de crawleo)
    • La URL es indexada (1ª ola de indexación)
    • Los bots obtienen los recursos CSS y JS necesarios para renderizar la web.
    • Con estos recursos, el sistema renderiza la web. Los bots examinan el código HTML renderizado, su contenido y enlaces. (Los nuevos enlaces descubiertos se añaden a la cola de crawleo)
    • Considerando el contenido de la URL renderizada, esta se vuelve a indexar. (2ª ola de indexación)

    Descubre el proceso en detalle en la documentación oficial de JavaScript y SEO de Google (merece la pena).

    Dependiendo del código y de cómo este resulte tras su posterior renderizado, el bot “verá” un contenido u otro, y por supuesto, esto afecta a la forma en que la URL se posiciona.

    1. Nos ayuda a ver cómo se procesa el contenido y apariencia de nuestra página, lo cual nos puede servir para priorizar la carga de los recursos y contenidos más relevantes en la página (algo clave tanto respecto a WPO -Web Page Optimization-, como para UX -experiencia del usuario-)

    ¿Cómo saber qué ‘ven’ los Bots en nuestras URLs?

    Para lograr conocer lo más fielmente posible cómo los bots “ven” el contenido de nuestras URLs, tanto antes como después del renderizado, podemos servirnos de una serie de herramientas que vamos a listar a continuación:

    1. Inspector de elementos del navegador
    2. Extensión de Chrome “View Rendered Source”
    3. Technical SEO Fetch & Render
    4. Inspector de URL en Google Search Console
    5. Mobile Friendly Test de Google
    6. Screaming Frog
    7. Fetch and render basado en Puppeter de Natzir Turrado

    #1. Inspector de elementos del navegador

    La primera y más habitual de las herramientas para comprobar y comparar el código HTML pre y post renderizado de una web, es la conocida herramienta “Inspeccionar” o “Herramientas para desarrolladores” presentes de forma nativa en los principales navegadores.

    Tomando de referencia a Google Chrome (por ser uno de los navegadores más usados), podemos acceder a esta herramienta pulsando “F12” o la combinación de teclas “Ctrl + Shift + I”:

    Pestaña "Elements" (renderizado) en las herramientas de desarrollo de Google Chrome.
    Pestaña «Elements» (renderizado) en las herramientas de desarrollo de Google Chrome.

    Pero vamos al grano, ¿dónde veo el código fuente sin renderizar y el código fuente renderizado? Para ello basta con alternar entre la pestaña “Sources” y “Elements”:

    • Desde la pestaña “Elements podemos observar el código renderizado (tal y como lo ha renderizado nuestro navegador, que puede variar respecto a cómo lo renderiza GoogleBot, sobre todo si usamos un navegador distinto a Google Chrome).
    • Desde la pestaña “Sourcespodremos encontrar el código HTML sin renderizar, tal y como lo obtiene el navegador antes de procesarlo:
    Pestaña "Source" en las herramientas de desarrollo de Google Chrome.
    Pestaña «Source» en las herramientas de desarrollo de Google Chrome.

    Este sistema tiene un “pequeño” inconveniente. Si queremos comparar las diferencias entre el código renderizado y sin renderizar, debemos copiar ambos y hacerlo empleando una herramienta externa como un editor de código enriquecido (por ejemplo, Sublime Text) o herramientas online como DiffCheker. Es una forma sencilla y que apenas requiere recursos, pero debemos tener en cuenta sus limitaciones.

    #2. Extensión de Chrome “View Rendered Source”

    La extensión View Rendered Source para Google Chrome simplifica aún más el método anterior. Esta extensión nos da lo que queremos de una forma directa y sin floritura: compara y resalta las diferencias entre el código HTML sin renderizar y el código renderizado:

    Página de la extensión "View rendered source" en Chrome Store.
    Página de la extensión «View rendered source» en Chrome Store.

    Una vez lo hemos instalado en nuestro navegador, basta con dirigirnos a la URL que queremos analizar y pulsar sobre el icono que se muestra en la barra de extensiones del navegador:

    Icono de la extensión de Chrome "View rendered source"
    Icono de la extensión de Chrome «View rendered source»

    Automáticamente, la extensión nos dirige a una nueva pestaña en el navegador donde se muestran el código sin renderizar, el código renderizado y la comparación del mismo (indicando en verde y rojo qué código se ha incluido o eliminado en el código renderizado respecto al código sin renderizar).

    Comparación de código renderizado y sin renderizar en la extensión de Chrome "View rendered source".
    Comparación de código renderizado y sin renderizar en la extensión de Chrome «View rendered source».

    Sin duda, es una de las alternativas más sencilla y rápidas para analizar el código de nuestra web en sus distintos estados, sin embargo, el HTML renderizado que nos ofrece la extensión no tiene por qué coincidir con la versión renderizada del código que interpretan los Bots de Google (u otros).

    #3. Technical SEO Fetch & Render

    En lo particular, me parecen una auténtica pasada las herramientas de Technicalseo.com (de Max Prin), tanto por su variedad como por las funcionalidades que ofrecen. Entre estas herramientas está la denominada “Fetch & Render”, la cual analiza una URL dada ofreciéndonos información del código sin renderizar y del código renderizado. 

    Hasta aquí todo normal, pero lo realmente interesante son las distintas opciones que permite configurar como:

    • Simular el Bot que explora la URL (permite seleccionar entre una lista de Bots predefinida)
    • Obedecer o no al archivo Robots.txt. Así podemos conocer si alguna directiva del fichero Robots.txt está bloqueando el acceso a algún recursos necesario para el renderizado de la web.
    • Definir un tiempo de renderizado. Se estima en 5 segundos el tiempo que Google ocupa en renderizar el contenido de una web. Con esta función podemos simular distintos tiempos de renderizado en una URL y determinar cómo afecta al código de la misma..
    Confguración de parámetros para el renderizado en la heramienta Fetch and Render de Technicalseo.com
    Confguración de parámetros para el renderizado en la heramienta Fetch and Render de Technicalseo.com

    Como resultado, esta herramienta ofrece 2 pestañas:

    • HTML response: es el código sin renderizar y las cabeceras de respuestas que ofrece el servidor de la URL analizada.
    • Rendered Page: es el código de la URL tras el renderizado.

    Además, también ofrece información sobre los tiempos de respuesta y renderizado de la URL, así como una pequeña captura de pantalla que simula el resultado visual de la URL renderizada:

    Resultado del código en la herramienta Fetch and Render de Technicalseo.com
    Resultado del código en la herramienta Fetch and Render de Technicalseo.com

    Sin embargo, no todo el monte es orégano. Fetch and Render nos ofrece tanto el código renderizado como sin renderizar, pero no lo compara ni resalta las diferencias entre ambos, por lo que nuevamente tendremos que recurrir a una herramienta externa como Sublime Text u otros editores de código.

    La parte positiva es que nos permite simular el renderizado como GoogleBot y su versión móvil. También como Bing. De esta forma podemos hacernos una idea más aproximada de cómo estos están “viendo” nuestra URL.

    #4. Inspector de URL en Google Search Console

    Esta herramienta es de las más fieles en cuanto a conocer cómo Google renderiza nuestra URL. Sin embargo, sólo podremos usarla si tenemos acceso al proyecto en Google Search Console (así que podemos descartar si nuestro propósito es observar cómo se comporta una URL de la competencia*).

    Basta con incluir la URL en el buscador de Google Search Console:

    Campo para inroducir la URL a analizar en Google Search Console.
    Campo para inroducir la URL a analizar en Google Search Console.

    Una vez analizada, podremos ver el código HTML renderizado desde el apartado “Ver página rastreada”, seleccionado en la barra lateral derecha la pestaña “HTML”:

    Resultado de la inspección de URL en Google Search Console.
    Resultado de la inspección de URL en Google Search Console.

    Eso sí, para comparar el código renderizado y sin renderizar, nuevamente tendremos que recurrir a alguna herramienta externa que nos permita hacer Diff

    *Realmente sí podemos usar esta herramienta para observar cómo Google renderiza una URL de la competencia, aunque de forma indirecta. Para ello debemos:

    • Crear una redirección desde una URL de un proyecto que tengamos en Google Search Console hacia la URL de la competencia que queramos analizar.
    • Inspeccionar la URL sobre la que hemos aplicado la redirección.

    #5. Mobile Friendly Test de Google

    Actualizado en diciembre de 2023: Google retiró esta herramienta el 1 de diciembre de 2023. En su lugar, recomienda emplear Lighthouse, aunque dicha herramienta no nos servirá para estimar cómo GoogleBot ve nuestra URL.

    El propósito original de esta herramienta no es analizar el código sin renderizar y renderizado; como su nombre indica, Mobile Friendly Test es una herramienta de Google diseñada para comprobar si el código de una URL está optimizado para dispositivos móviles. Sin embargo, una vez analizamos la URL, esta herramienta nos ofrece también información del código HTML renderizado:

    Resultado de la herramienta Mobile Friendly Test de Google.
    Resultado de la herramienta Mobile Friendly Test de Google.

    ¿También hay que comparar el código a mano? En efecto, compañero. La parte positiva es que esta herramienta nos da una idea muy aproximada de cómo Google está viendo el código renderizado de nuestra página (y más concretamente, de cómo lo está viendo con su Bot móvil).

    #6. Screaming Frog

    Esta herramienta es la navaja suiza de todo profesional del SEO, y por supuesto, para conocer el código de nuestras URLs (sin renderizar y tras el renderizado). Para ello debemos configurar los distintos apartados:

    1. Configuration → User-Agent. Aquí recomiendo seleccionar Googlebot o GoogleBot Mobile.
    2. Configuration → Spider → Extraction → HTML → Marca “Store HTML” y “Store Rendered HTML”
    Configuración de Screaming Frog para almacenar el código sin renderizar y renderizado de las URLs analizadas.
    Configuración de Screaming Frog para almacenar el código sin renderizar y renderizado de las URLs analizadas.
    1. Configuration → Spider → Rendering → JavaScript. Aquí recomiendo establecer los siguientes parámetros:
      • Ajax timeout: 5 secs. 
      • Windows size: Googlebot (Acorde al User Agent elegido) 
    Configuración de parámetros de renderizado en Screaming Frog.
    Configuración de parámetros de renderizado en Screaming Frog.

    Una vez configurado, si queremos comprobar una serie de URLs (no toda la web), lo más recomendable es escoger “Mode → List”. Una vez introducidas y crawleadas las distintas URLs, podemos encontrar el resultado desde la pestaña inferior “View Source”: los distintos códigos y la posibilidad de resaltar las diferencias entre ambos.

    Resultado y comparación del código sin renderiar y renderizado en Screaming Frog.
    Resultado y comparación del código sin renderiar y renderizado en Screaming Frog.

    ¿Qué completo y útil, verdad? Pues sí, y es que yo estoy Scream’in love.

    #7. Fetch and render basado en Puppeter de Natzir Turrado

    Y no puede faltar a nuestra lista de herramientas la que publicó Natzir Turrado en Twitter.

    Esta herramienta tendremos que utilizarla desde Google Colab (Natzir compartió el acceso a su proyecto en Colab para que lo copiemos y usemos libremente). De entrada, es algo más compleja de usar, sobre todo si no has usado Colab ni estás familiarizado con el código, sin embargo, es bastante fácil:

    1. Ejecutamos el código del primer bloque (pulsa sobre el play y espera a que finalice el proceso):
    Paso 1. Instalación del entorno en Google Colab.
    Paso 1. Instalación del entorno en Google Colab.
    1. En el bloque de código inferior podemos configurar los distintos parámetros y URL a analizar. Una vez los hayamos modificado, volvemos a pulsar el “play” para guardar los cambios.
    Paso 2. Configuración de parámetros.
    Paso 2. Configuración de parámetros.
    1. Por último, en el siguiente bloque sólo nos queda ejecutar el script que hemos editado antes (volvemos a pulsar el play)
    Paso 3. Ejecución del código en Colab.
    Paso 3. Ejecución del código en Colab.
    1. Justo debajo aparecerá el código HTML renderizado:
    Resultado del renderizado HTML
    Resultado del renderizado HTML
    1. También podremos ver el resultado visual del renderizado desde los recursos del proyecto de Colab:
    Aspecto visual del renderizado
    Aspecto visual del renderizado

    ¿Tiene buena pinta, verdad? La única pega es que también tendremos que comparar el código “a pelo”. ¡Pero oye, está más que bien! Este método también obedece las directivas Robots.txt y hace la comprobación de la URL según la última versión de Chromium, lo cual es de agradecer, sobre todo si tenemos en cuenta que desde hace algún tiempo, GoogleBot es «evergreen». ¿Qué quiere decir esto?, pues que cuando el Bot de Google crawlee nuestra página lo hará simulando la última versión de Chromium y en consecuencia, así renderizará.

    ¡Si es que tenemos una comunidad SEO super colaboradora en España!

    Seguro que hay algunas herramientas más que se me han quedado en el tintero, pero al menos estas sirven para hacer un análisis del código de tu web de una forma simple y -salvo en el caso de Screaming Frog- totalmente gratuita. ¡Espero que os sean de ayuda en vuestro camino por mejorar y aprender SEO!

  • ImportFromWeb: una alternativa a ImportXml para scrapear webs con Google SpreadSheets

    ImportFromWeb: una alternativa a ImportXml para scrapear webs con Google SpreadSheets

    Si has scrapeado alguna web con ImportXml, la extensión ImportFromWeb te va a gustar y mucho. En este post analizo lo mejor y peor de ambas alternativas.

    En la profesión de SEO, quien más y quien menos acaba necesitando scrapear contenidos de una web: a veces de webs propias, otras veces de la competencia. Para llevar a cabo esta tarea existen muchas herramientas, aunque entre los recursos más habituales se encuentran programas como Screaming Frog y su fabulosa función Custom Extraction, extensiones para el navegador como Scraper o soluciones tan de andar por casa como las que atañen a este post: la función de Google SpreadSheets ImportXML.

    Una de las grandes ventajas de la función ImportXML es su sencillez y que nos permite scrapear contenido directamente en una hoja de cálculo, y para más goce, este contenido se actualiza periódicamente de forma automática (aproximadamente cada hora). Pero como todo, tiene sus limitaciones y eso es justo lo que me ha llevado a descubrir ImportFromWeb.

    Si bien la ventaja de ImportXML es su sencillez de uso, a veces también puede ser su punto débil. Cuestiones como la extracción de contenidos generados mediante JavaScript en el renderizado de la página quédan fuera de su alcance. Es aquí donde ImportFromWeb empieza a lucir.

    ¿Por qué ImportFromWeb es una seria alternativa a ImportXML?

    El motivo por el que llegué hasta ImportFromWeb fue porque ImportXML no lograba extraer información de algunas expresiones XPATH . Pese a que estas mismas expresiones sí funcionaba en Screaming Frog y Scraper, ImportXML no devolvía ningún valor (#N/A).

    Tras barajar posibilidades como: un bloqueo por parte de la web objetivo, que el contenido se estuviera generando por JavaScript o fallos en el propio funcionamiento de la fórmula, acabé encontrando ImportFromWeb. Después de instalarlo en Google SpreadSheet, probé la expresión XPATH en cuestión y funcionaba a la perfección. Misterios de la vida.

    Con sólo trastear unos minutos ya me quedó claro por qué es una gran alternativa a ImportXML:

    • Permite scrapear contenido del JavaScript renderizado. Así es. Si bien ImportXML sólo permite scrapear aquel contenido presente en el HTML source, ImportFromWeb nos permite extraer el contenido generado por JavaScript.
    • Permite configurar la geolocalización. De esta forma podemos scrapear el contenido de una web cargándola con una configuración de localización específica.
    • Permite usar expresiones regulares para extraer o reemplazar parte del contenido extraído. Esto puede sernos muy útil para limpiar la información scrapeada.

    Además de éstas, ImportFromWeb incorpora otras funciones que puedes ver en la web del desarrollador.

    Instalando ImportFromWeb

    Lo mejor que puedes hacer es probarlo por ti mismo. Su instalación es realmente sencilla. Sólo tienes que hacer lo siguiente:

    • Accede a tu hoja de cálculo de Google SpreadSheet
    • En la barra de herramientas, pulsa la opción «Complementos -> Descargar complementos»
    Instalar ImportFromWeb
    • En el buscador, escribe «ImportFromWeb» (Obvio)
    Instalar ImportFromWeb
    • Instala la extensión y otórgale los permiso necesarios según te lo vaya solicitando.
    Instalar ImportFromWeb
    • Una vez instalada encontrarás una barra lateral a la derecha donde podrás manejar algunos parámetros de la extensión, refrescar los datos y acceder a la información de tu cuenta:
    Sidebar opciones de ImportFromWeb
    Side bar de opciones de ImportFromWeb
    • Ahora ya puedes empezar a «jugar». ¡Manos a la obra!

    ¿Cómo funciona ImportFromWeb?

    Para explicar cómo funciona tomaremos como referencia nuestra querida función ImportXML, pues para un uso básico funcionan de forma idéntica. Si bien la fórmula ImportXML tiene la siguiente sintaxis:

    =importXml(URL, XPATH)

    La sintaxis de la extensión ImportFromWeb es idéntica:

    =ImportFromWeb(URL, XPATH)

    De forma predeterminada, los resultados de estas fórmulas será exactamente el mismo. Eso sí, hay algunas cosas que debemos tener en cuenta:

    • Una vez extraidos los datos, ImportXML los autorefresca periódicamente, sin embargo ImportFromWeb requiere accionar manualmente el refresco de estos datos. Una ventaja o un inconveniente, depende de tus objetivos.
    • Para refrescar el contenido extraido por ImportFromWeb, basta con ir a «Complementos -> ImportFromWeb | Easy Web Scraping -> Spreadsheet – Update content«
    Refrescar los datos importados en nuestra hoja de calcula mediante ImportFromWeb.
    Refrescar los datos importados en nuestra hoja de calcula mediante ImportFromWeb.

    Scrapear contenido generado por JavaScript

    Para habilitar la extracción de contenido generado vía JavaScript es necesario especificar una serie de parámetros adicionales en la fórmula base. Para ello debemos hacer lo siguiente:

    1. En una celda (Por ejemplo A1), definimos la URL a scrapear.
    2. En otra celda (Por ejemplo A3), definimos la expresión XPATH.
    3. A continuación, en otra celda (Por ejemplo A2), definimos el parámetro: «jsRendering«. En la celda colindante a su derecha (B2), definimos su valor, en este caso «TRUE».
    4. La formula definida sería similar a:

    =ImportFromWeb(A1; A2; A3:B3)

    A modo de ejemplo, vamos scrapear la hora de la web de «Antena 3 Noticias», la cual se genera por JavaScript en tiempo real. La fórmula sería la siguiente:

    Ejemplo de fórmula de ImportFromWeb
    Ejemplo de fórmula de ImportFromWeb

    En ocasiones, puede que los datos generado vía JavaScript no se obtengan de forma inmediata. Esto dependerá del tipo de página que estemos scrapeando. Puede ser que estos datos tarden en generarse y en consecuencia tardemos en extraerlos. Si esto sucede, ImportFromWeb nos indicará que debemos esperar unos instantes y refrescar la solicitud de la fórmula:

    • Para ello dirígete a «Complementos -> ImportFromWeb | Easy Web Scraping -> Spreadsheet – Refresh Pending Requests» (Paciencia. Si no sale, vuelve a insistir en unos instantes.)
    Refrescar solicitud de scrapeo con renderizado de JavaScript habilitado.
    Refrescar solicitud de scrapeo con renderizado de JavaScript habilitado.

    Sintaxis y otros parámetros de la función

    Otros parámetros como el de geolocalización se especifican de forma muy similar. Puedes encontrar toda la información muy bien explicada en la documentación oficial de ImportFromWeb.

    Puntos débiles de ImportFromWeb

    No todo iba a ser color rosa. Este complemento tiene sus limitaciones que dependiendo de nuestras necesidades pueden ser mayores o menores:

    • Hay que refrescar manualmente los datos scrapeados. Como ya hemos mencionado, nos tocará solicitar el refresco de los datos scrapeados. A falta de comprobarlo, quizás una Macro programada desde App Scripts nos ayude a solventar esta limitación.
    • Hay límite de solicitudes para la fórmula. En concreto 2000 diarias. A los SEOs no nos gustan los límites, pero 2000 consultas diarias deberían ser suficientes.

    Actualizado a 19/08/2021: aunque en un inicio esta extensión era gratuita, desde hace ya varios meses ImportFromWeb ha pasado a ser de pago enteramente. El límite de 2000 consultas diarias no está vigente ya, pues ahora hay varios planes de pago que parten de los 11 USD mensuales (150 consultas diarias).

    Por lo general y a falta de un mayor uso, ImportFromWeb me parece todo un descubrimiento para las pequeñas (y no tan pequeñas) tareas en el día a día de un SEO. Seguramente ImportXML siga siendo mi ojito derecho por su sencillez y por estar implementado de forma nativa en Google Spreadsheets, pero no me cabe duda que desde este momento los iré alternando en mi trabajo cotidiano. ¡Nunca viene mal tener una alternativa a lo que tanto nos gusta! ¿Qué os parece? Si ya lo habéis probado no dudéis en comentar vuestra experiencia.

  • Experimento SEO con enlaces

    Experimento SEO con enlaces

    Hace unos meses hice un pequeño experimento SEO con enlaces internos en esta web: quería conocer qué enlaces puede seguir nuestro todopoderoso Google. Aunque ya hace tiempo desde las primeras pruebas (mayo 2019), no quiero sacar conclusiones equivocadas, por lo que quiero hacer nuevas pruebas en este mismo post de mi blog.

    ¿En qué consistió el primer experimento?

    Este primer experimento pretendía probar distintas formas de enlazar y comprobar si Google era capaz de seguir dicho enlace. Para ello se generó una nueva URL (enlazada en el footer de esta web, sin forzar el rastreo desde Google Search Console), en la cual se encuentran 4 enlaces generados con distintas técnicas, cada cual apuntando a una URL nueva, creada expresamente para cada enlace:

    1. Primer enlace

    El primer enlace se genera mediante una función jQuery, que actúa sobre una etiqueta <span> con la clase «clica» y que también cuenta con un atributo de datos HTML «data-» que contiene un fragmento de texto con el que la función genera la URL de destino:

    Etiqueta HTML

    <span class="clica" data-datac="/parte-1-historia.html">Parte 1 de la historia</span>

    Función jQuery

    $('.clica').click(function() {
            var d = $(this).data('datac');     
             location.href="https://comunycaos.com"+d;
    } );

    2. Segundo enlace

    El segundo enlace funciona mediante una etiqueta <span> con un evento onclick donde se especifica integramente la URL de destino:

    <span class="clica-2" onclick="location.href='https://comunycaos.com/parte2-historia.html'">Parte 2 de la historia</span>

    3. Tercer enlace

    El tercer enlace funciona exactamente igual que el segundo enlace, sólo que se emplea una etiqueta <button> en lugar de una etiqueta <span>. Nuevamente se incluye un evento onclick donde se especifica integramente la URL de destino:

    <button class="clica-3" id="tercero" onclick="location.href='https : / / c o m u n y c a o s . c o m / p a r t e 3 - h i s t o r i a . h t m l'">Parte 3 de la historia</button>

    4. Cuarto enlace (y último del experimento)

    El cuarto enlace se construye con una etiqueta <span> que dispone de un evento onclick, el cual ejecuta una función JavaScript que construye la URL de destino. Esta función fue situada en la zona inferior del código de la página.

    Al hacer la llamada a la función, se pasa una cadena de texto como variable, en concreto un fragmento de la URL de destino:

    Etiqueta HTML

    <span class="clica-4" id="cuarto" onclick="enl('no-hay-cuarta')">Parte 4 de la historia</span>

    Función JavaScript

    function enl(x){
    	location.href="https://comunycaos.com/"+x+".html";
    }

    Hasta este punto, ¿cuáles han sido los resultados del experimento?

    Tras aproximadamente 3 semanas, revisar Google Search Console y analizar los logs del servidor con Screaming Frog Log File Analyser puedo decir lo siguiente:

    • Google ha rastreado en varias ocasiones la URL que contenía los distintos enlaces.
    • De las URLs enlazadas en este experimento, Google sólo ha descubierto la del segundo enlace: (https://comunycaos.com/parte2-historia.html).
    • El resto de URLs enlazadas en los enlaces 1, 3 y 4 ni siquiera han sido visitadas por el bot de Google.

    ¡Ojo!, no saquemos conclusiones antes de tiempo

    Antes de sacar conclusiones no debemos perder de vista uno de los hallazgos resultantes del analisis de Google Search Console y SF File Log Analyser:

    • Google pasa muy poco por esta web. Y es que más que «Crawl Budget» tengo «K.O. budget». Esto es, Google no gasta mucho tiempo en esta web por su escaso número de URLs y frecuencia de actualización de la misma, lo que puede ser un factor importante a la hora de divagar sobre si Google examinó la URL del experimento con más o menos exhaustividad.
    • Además de lo anterior, la URL del experimento era «joven», con escaso contenido y relevancia.

    Toca reflexionar: ¿qué creo que ha pasado?

    En vista de que el segundo enlace (<span> con onclick) funciona de forma similar al tercer enlace (<button> con onclick), salvo por el tipo de etiqueta HTML, ¿por qué Google sólo ha examinado la URL del segundo enlace?

    Si bien sabemos, Google puede rastrear una URL por su mera presencia en el código, sin necesidad de que esté enlazada de alguna forma. En este caso, las URLs del enlace 2 y 3 aparecen integramente en el código.

    Teniendo en cuenta esto, también forcé a explorar la URL del experimento desde GSC en diversas ocasiones para comprobar si Google lograba rastrear las URLs enlazadas, aunque sin éxito.

    ¿Y qué pasa con los enlaces 1 y 4?

    Por otra parte, esperaba y comprendo que las URLs de los enlaces 1 y 4 no hayan sido rastreadas. Estos enlaces emplean funciones jQuery y JavaScript y no contienen la URL de forma explícita, sino fragmentos de la URL que es construida mediante las funciones que se detallan en este artículo. Salvo que Google simulase la acción del click, difícilmente podría alcanzar la URL de destino.

    Después del primer round, ¿ahora qué?

    A día 9 de agosto de 2019, mi teoría es que la escasa relevancia de la web y la URL del experimento han sido causa de que Google no se haya esmerado mucho en explorar el contenido de la misma.

    Nueva hipótesis: más relevancia, más atención al contenido.

    Ahora pienso probar estos enlaces en otra URL con mayor fuerza, lo cual -posiblemente- haga que Google encuentre al menos la URL del tercer enlace, o esa es mi teoría. ¡El tiempo y Google dirán! Os mantendré informados actualizando esta entrada.

    Actualización (10/09/2019): ¡Sin novedad en el frente!

    Tras un mes es momento de analizar los hallazgos encontrados. Google sigue sin seguir ni explorar la URL del evento onclick del tercer enlace analizado en este post. Todos los detalles y conclusiones los explico a continuación.

    Nueva revisión del experimento

    Re-Experimentando

    Para revisar si se trataba de un problema de relevancia de la URL original del experimento, seleccioné una de las URLs más relevantes de esta web (WordPress Multisite para SEO) e introduje –como en el experimento original– un «pseudo enlace» creado con una etiqueta <button> que emplea un evento onClick=»location.href=’https://comunycaos.com/parte3-historia.html’», tal que así:

    <button style="border: 0px;background-color: #ffffff;" id="tercero" onclick="location.href='https://comunycaos.com/parte3-historia.html'">Parte 3 de la historia</button>

    Para curarme en salud y evitar que Google pudiese leer la URL del experimento tras escribirla en el post donde explico el experimento, añadí espacios en blanco entre cada letra de la URL que aparecía escrita en dicho post.

    Un mes después… ¡A revisar se ha dicho!

    Tras un mes desde que comenzara el re-experimento (desde el 9 de agosto al 9 de septiembre de 2019), comencé a analizar los datos de Google Search Console, los datos que arrojaba el comando «site:comunycaos.com» y los logs del servidor de la web. De todo esto he podido concluir lo siguiente:

    • En Google Search Console no hay rastro de la URL definida en el pseudo-enlace. Es decir: «https://comunycaos.com/parte3-historia.html»
    • El comando «site:comunycaos.com» tampoco daba señales de vida de la URL.
    • Los Logs analizados con Screaming Frog Log File Analyzer no mostraban ni un solo «toque» a dicha URL por parte de Bots, ni GoogleBot, ni BingBot, ni nada que se le parezca.
    • Los logs analizados muestran que sí se han rastreado de forma periódica las URL del experimento original y la URL de mayor relevancia empleada para la revisión del experimento, ergo, sige sin «tocar a la puerta» de la URL definida en el onclick del <button> definido para el experimento.

    In-conclusiones y nueva hipótesis

    Después de analizar por enésima vez los logs y comprobar que Google sigue revisitando las URLs que contienen los enlaces de los experimentos, sin llegar a rastrear dichas URLs, la teoría de «falta de relevancia» la dejaré en la reserva.

    Por otro lado, tampoco me aventuro a afirmar que Google lee los eventos onclick en algunas etiquetas HTML como <div> o <span>, pero no de <button>.

    Hola, Google, ¿me lees?

    Mi nueva hipótesis es que Google va a leer la URL de este mismo post. Para ello, nada más publicar esta revisión forzaré la exploración de la misma, para que Google se ponga las pilas cuanto antes. ¿Encontrará por fin Google la URL https://comunycaos.com/parte3-historia.html? ¡Hagan sus apuestas!

    Actualización tras las últimas pruebas (21 de octubre de 2019)

    En todo el tiempo transcurrido tras esta revisión del experimento y pese a las sucesivas hipótesis que fueron surgiendo, puedo decir que:

    • Según logs del servidor, ningún bot de Google ha pasado a visitar la URL «parte3-hstoria.html»
    • Como se esperaba, tampoco han sido detectadas las demás URLs: «parte4-historia.html» y «parte1-historia..html».
    • En este periodo, pese a haber sido descubierta, explorada e indexada, la URL «parte2-historia.html» tampoco ha sido revisitada por los bots de Google. Es más, para más júbilo de este experimento, en estre transcuros la URL «parte2-historia.html» ha desaparecido del índice de Google y ahora aparece en GSC como «URL rastreada actualmente sin indexar»:
    URL rastreada actualmente sin indexar del experimento SEO con enlaces
    URL rastreada actualmente sin indexar del experimento.

    Quizás, como ya apuntaba en los inicios del experimento, la clave sea el volumen y popularidad del sitio. Seguramente en una web cuyo contenido se renueva de manera frecuente y mejor posicionada, obtenga unos resultados bastante diferentes a los que yo he obtenido con este experimento.

    ¡2ª Actualización ¿in?esperada! (4/12/2019)

    ¡Sorpresa, sorpresa…! Apenas una semana después de dar por zanjado el experimento y de esbozar ms in-conclusiones, el día 3 de noviembre sonó la campana:

    Log de la visitilla – descubrimiento que ha hecho GoogleBot de la URL del experimieto «parte3-historia.html»

    Pues sí, como pude comprobar mediante un comando «site:comunycaos.com» al inicio de diciembre, Google había explorado por primera vez la URL «parte3-historia.html» (publicada allá por el mes de mayo). Tras analizar el log del servidor y revisar la caché de la URL indexada, se confirmó: GoogleBot Mobile había visitado la URL por fin.

    ¿Cómo la encontró? Buena pregunta. Puedo imaginar que la tuviera previamente «fichada» y en cola para ser explorada, pues el log del 3 de noviembre muestra que el bot de Google sólo accedió a:

    • https://comunycaos.com/
    • https://comunycaos.com/amp/
    • https://comunycaos.com/parte3-historia.html
    • Adicionalmente, también accedión a ficheros .css y .js
    Logs correspondientes a GoogleBot Mobile el 3 de noviembre.

    Sea como fuere, este experimento ha dado tantos giros que resulta imposible saber si Google detectó la URL por haberla leído del código del enlace <span> con evento onclick, o símplemente la localizó por el hecho de estar presente como texto plano en las páginas de seguimiento del experimento. En cualquier caso, puedo descartar que dicha URL fuera enlazada (<a>) en este sitio o web externos.

    En resumen, que aquí tenemos en Google Search Console el resultado mencionado:

    Informe de cobertura de Google Search Console con la URL «parte3-historia.html» indexada.

    Sólo espero que os haya resultado interesante y os despierte la curiosidad. Si tienes alguna duda o aportación no dudes en darme un toque por Twitter.

  • WordPress Multisite para SEO: el camino corto no siempre es el mejor.

    WordPress Multisite para SEO: el camino corto no siempre es el mejor.

    WordPress Multisite es una de las soluciones para trabajar en varias webs de forma simultánea con facilidad, pero, ¿es la mejor opción para el SEO?


    Esta vez toca reflexionar sobre el uso de WordPress Multisite como estrategia para posicionamiento SEO, más bien sobre cómo no han de hacerse las cosas, basado en mi experiencia personal.

    Punto de partida: ¿Para qué proyecto se empleó WordPress Multisite?

    Recientemente, uno de los proyectos que se me planteó, requería la implantación de nada más y nada menos que 12 páginas webs, cada cual con distinto domino. Todas ellas orientadas al sector turístico/vacacional. Se trataban de páginas, que por su tipología y contenidos serían bastante similares entre sí, por ejemplo:

    Casa rural Zamora, Casa rural Córdoba, Casa rural Gerona, etc.

    Es decir, pese a que cada una de ellas cuenta con un contenido propio, la estructura de contenidos y arquitectura de la web iba a ser similar entre ambas. Por ello, la idea era crear la base / plantilla para la primera web, y posteriormente replicarlo con las demás, simplemente ajustando los contenidos de cada una.

    Esta situación nos planteaba el siguiente escenario:

    • Crear las 12 webs en WordPress de forma independiente.
    • Crear un WordPress Multisite para las 12 webs.
    • Crear las 12 webs sin CMS, usando plantillas HTML+CSS+JS, puesto que el proyecto no requería de programación backend.

    Llegado el momento de elegir y con el reloj en mi contra, opté por configurar estas web empleando un WordPress Multisite, puesto que a priori, me facilitaría el trabajo: pensaba usar Site Origin, un Page Builde para WordPress que me permitiría exportar e importar la estética entre las 12 webs.

    Punto dos: hora de instalar y configurar WordPress Multisite

    Hasta la fecha había instalado y configurado 1001 sitios con WordPress, desde webs sencillas hasta webs con funcionalidades bastante específicas. Ahora tocaba aprender a instalar un multisitio de WordPress, así que me até la manta a la cabeza y me puse manos a la obra.

    Para ello seguí las instrucciones que encontré en el blog de Empiezapori, el cual explicaba las cosas de una forma suficientemente clara como para instalar WordPress Multisite con éxito. El tutorial en concreto podéis verlos en el siguiente enlace al artículo

    Tras estos pasos ya estaba configurado el WordPress Multisite para el nuevo proyecto. El siguiente paso era comenzar a construir los sitios webs y optimizarlos para el posicionamiento SEO.

    Punto tres: construyendo y configurando cada sitio.

    Una vez instalado nuestro WordPress Multisite y todos los plugins que necesitaba para construir y optimizar cada sitio, el siguiente paso fue trabajar el diseño y contenidos del primer website. Tras realizar la primera web al completo, se replicó la estética y estructura entre los 12 sitios que conformaban esta estrategia SEO.

    Esta parte del proceso fue coser y contar, gracias al page builder Site Origin. Este constructor visual de páginas para WordPress cuenta con opciones para la exportación e importación de páginas y resulta muy intuitivo de utilizar. No obstante, hubiera preferido usar el constructor de páginas Elementor, unos de los page builders más populares de WordPress. Desafortunadamente, por limitaciones técnicas del hosting, esto no fue posible hasta meses después, aunque esa es otra historia.

    Punto cuatro: indexación y alta de cada sitio en Google Search Console.

    Una vez elaborados los contenidos de cada sitio web, se hizo lo propio: se crearon los sitemaps para cada uno y dimos de alta las diversas versiones del sitio en Google Search Console.

    En este punto del proceso no se encontraron dificultades, es más, los sitemaps no son grandes y se indexaron al vuelo por parte de Google.

    También se dieron de alta las webs en Bing Webmaster Tools, realizándose el mismo procedimiento: envío de sitemaps e indexación sin mayor problema.

    Punto quinto: ¿Cómo ha resultado la experiencia con WordPress Multisite?

    La elección de WordPress Multisitio para realizar la estrategia de posicionamiento SEO que se había planteado, ha traído consigo los siguientes aspectos destacables:

    Pros de WordPress Multisite para la estrategia SEO

    • Construcción de múltiples sitios de forma rápida.
    • Uso de un único hosting.
    • Actualización simultánea de componentes y themes de WordPress.

    Contras de WordPress Multisite en posicionamiento SEO

    • Tiempo de carga elevado derivado de la configuración del multisite.
    • Todos los sitios del multisite comparten la misma IP, pues se encuentran en el mismo hosting. Esto plantea una problemática, sobre todo en cuanto a acciones de linkbuilding / PBN (Private Blog Network o Red Privada de Blogs). (Os dejo la explicación sobre el concepto de PBN aquí).
    • Incompatibilidad de algunos plugins, por ejemplo, plugins para WPO y cacheado de WordPress.

    A esta serie de pros y contras podemos añadir que:

    Los sitios contaban con tiempos de carga muy elevados, pese a usar plantillas de carga rápida y reducir los elementos de mayor peso en la web, como lo eran las imágenes de alta resolución.

    Contar con la misma IP y similitud en su estructura fue considerado como un factor de baja calidad por parte de Google, pese a no tratarse de contenido duplicado ni “thin content (contenido pobre o escaso).

    A pesar de que se emplearon dominios “EDM” (Exact Domain Match), es decir, el dominio es la propia keyword a posicionar, esto no ayudó a posicionarlos de forma exitosa.

    Muchos de los websites no han aparecido en el top 100 de Google, pese a las correcciones realizadas para mejorar la calidad del sitio ni las estrategias de linkbuilding externo realizadas.

    Pero ¡hubo sorpresa!, pues aunque la estrategia no tuvo buen resultado en Google, Bing, el buscador de Microsoft, brindó mejores resultados, situando estas webs en primera página de resultados de búsqueda.

    En cualquier caso, no tengo reparo en afirmar que se trata de un proyecto que no ha resultado exitoso a nivel de posicionamiento SEO. Como profesional dedicamos al SEO, sé que no todo el monte es orégano, pero es un proyecto que no ha dado los resultados esperados.

    Punto sexto: con perspectiva, ¿qué cosas cambiaría?

    Son muchas cosas las que cambiaría de este proyecto de cara a mejorar el posicionamiento del mismo, y que debido a la falta de tiempo y recursos no he podido comprobar personalmente:

    Al resultar webs sencillas e informativas, lo ideal sería emplear sitios basados en HTML estático, empleado sus correspondientes hojas de estilo y librerías javascript. Al fin y al cabo, decantarnos por un sitio más sencillo a nivel técnico habría eliminado la necesidad de una BBDD, mejorado el tiempo de carga. Además, replicar la estética y estructura de cada web habría resultado igualmente sencillo.

    Emplear un hosting con distinta IP para cada web. De esta forma, a ojos de buscadores como Google, las diversas webs de este proyecto mantendrían una aparente independencia entre ellas, evitando parecer una PBN de baja calidad, algo bastante penalizado por los buscadores.

    En general, estos son los principales puntos que cambiaría tras mi experiencia con WordPress Multisite, que considero no ha sido la mejor opción para este proyecto en cuestión. No obstante, son muchos otros los factores que también cambiaría en esta estrategia, aunque no guardan relación con lo que he explicado en esta entrada del blog.

    Para concluir: entonces, ¿es malo usar WordPress Multisite?

    En absoluto, WordPress Multisite es una opción muy solvente para algunos supuestos o proyectos en los que se necesitan varios websites, por ejemplo:

    • Un multisite de WordPress, donde existe una web principal destinada a información corporativa y otra específicamente para la función de blog. Por ejemplo: miempresa.com. En dicho multisite, se configurarían nuevos sitios destinados al blog de dicha empresa, por ejemplo: blog.miempresa.com, miempresa.com/blog o miempresablog.com.
    • Un Multisite de WordPress destinado a abarcar versiones internacionales o multi-idioma de una web. Por ejemplo: el Multisite de WordPress contempla la web en español de la empresa “es.miempresa.com” su versión para Reino Unido “uk.miempresa.com”.

    Ambos supuestos responden a casos habituales y lógicos del uso de WordPress Multisite. Cuando se trata de un proyecto que emplea una gran cantidad de webs es mejor comenzar a pensar en otras soluciones, sobre todo si queremos orientar nuestro proyecto al posicionamiento SEO, donde cada web es un mundo.

    Espero que esta experiencia sea también la vuestra y os sirva para no tropezar en las mismas piedras que yo.

    ¡Nos leemos en la próxima entrada!

Comun&caos, comunicación y marketing online, de forma ordenada
Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. En concreto las cookies de Wordpress y Google Analytics. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.