Google: Los secretos salen a la luz

La Gran G, Google

Contenido del Post

Comparte el Post en Tus Redes Sociales

Google, si estás leyendo esto, es demasiado tarde 😉 .

Ok. Cruje los nudillos. Vayamos al grano. Se ha filtrado documentación interna de la API Content Warehouse de Google Search. Los microservicios internos de Google parecen reflejar lo que ofrece Google Cloud Platform y la versión interna de la documentación para el obsoleto Document AI Warehouse se publicó accidentalmente de forma pública en un repositorio de código para la biblioteca de clientes. La documentación de este código también fue capturada por un servicio externo de documentación automatizada. 

Según el historial de cambios, este error en el repositorio de código se corrigió el 7 de mayo, pero la documentación automatizada sigue activa. En un esfuerzo por limitar la responsabilidad potencial, no la enlazaré aquí, pero debido a que todo el código en ese repositorio fue publicado bajo la licencia Apache 2.0, a cualquiera que lo encontrara se le concedió un amplio conjunto de derechos, incluyendo la capacidad de usarlo, modificarlo y distribuirlo de todos modos.

AD 4nXcw r4BX9LqQSLUocijDY4beMKZBan1TEozjNLpoQEARgpvDdgsF3d USGK0x0HupXIdVBRNxqMOKBEBjKBzAZcwpa0eGimlhVmA0Z1IKkat1tCFJOiciEGdYBUGWfygabz1jy7kUbFzYvjZbK21P eGGBu?key=KBOuX93Bu5VNsHs9sB47Cg

He revisado los documentos de referencia de la API y los he contextualizado con otras filtraciones anteriores de Google y con el testimonio antimonopolio del Departamento de Justicia. Estoy combinando esto con la investigación exhaustiva de patentes y libros blancos realizada para mi próximo libro, The Science of SEO (La ciencia del SEO). Aunque no hay detalles sobre las funciones de puntuación de Google en la documentación que he revisado, hay una gran cantidad de información sobre los datos almacenados para el contenido, los enlaces y las interacciones de los usuarios. También hay diversos grados de descripciones (desde decepcionantemente escasas hasta sorprendentemente reveladoras) de las características que se manipulan y almacenan.

Estaríamos tentados de llamarlos “factores de clasificación”, pero sería impreciso. Muchos de ellos, incluso la mayoría, son factores de clasificación, pero muchos no lo son. Lo que voy a hacer aquí es contextualizar algunos de los sistemas y características de clasificación más interesantes (al menos, los que he podido encontrar en las primeras horas de revisión de esta filtración masiva) basándome en mi extensa investigación y en cosas que Google nos ha contado o mentido a lo largo de los años.

“Mentir” es duro, pero es la única palabra precisa que se puede usar aquí. Aunque no culpo necesariamente a los representantes públicos de Google por proteger su información privada, sí discrepo de sus esfuerzos por desacreditar activamente a personas del mundo del marketing, la tecnología y el periodismo que han presentado descubrimientos reproducibles. Mi consejo a los futuros Googlers que hablen de estos temas: A veces es mejor decir simplemente “no podemos hablar de eso”. Tu credibilidad importa, y cuando salen a la luz filtraciones como esta y testimonios como el del juicio del DOJ, resulta imposible confiar en tus futuras declaraciones.

Advertencias sobre el artículo

Creo que todos sabemos que la gente se esforzará por desacreditar mis conclusiones y análisis de esta filtración. Algunos se preguntarán por qué importa y dirán “pero eso ya lo sabíamos”. Así que quitemos las advertencias de en medio antes de pasar a lo bueno.

  • Tiempo y contexto limitados – Con el fin de semana festivo, sólo he podido dedicar unas 12 horas a concentrarme a fondo en todo esto. Estoy increíblemente agradecido a algunas partes anónimas que fueron de gran ayuda al compartir sus conocimientos conmigo para ayudarme a ponerme al día rápidamente. Además, al igual que con la filtración de Yandex que cubrí el año pasado, no tengo una imagen completa. Mientras que en el caso de Yandex teníamos el código fuente para analizar y ninguna de las ideas que había detrás, en este caso tenemos algunas de las ideas que hay detrás de miles de funciones y módulos, pero no el código fuente. Tendrás que perdonarme por compartir esto de una manera menos estructurada de lo que lo haré en unas semanas después de haberme sentado con el material por más tiempo.
  • No hay funciones de puntuación – No sabemos cómo se ponderan las características en las distintas funciones de puntuación posteriores. No sabemos si se utiliza todo lo disponible.  Sabemos que algunas características están obsoletas. A menos que se indique explícitamente, no sabemos cómo se utilizan las cosas. No sabemos dónde ocurre cada cosa en el proceso. Tenemos una serie de sistemas de clasificación con nombre que se ajustan vagamente a cómo Google los ha explicado, cómo los SEO han observado las clasificaciones en la naturaleza, y cómo las solicitudes de patentes y la literatura IR explica. En última instancia, gracias a esta filtración, ahora tenemos una imagen más clara de lo que se está considerando que puede informar a lo que nos centramos en contra de ignorar en SEO de cara al futuro.
  • Probablemente el primero de varios posts – Este post será mi puñalada inicial de lo que he revisado. Es posible que publique entradas posteriores a medida que continúe profundizando en los detalles. Sospecho que este artículo dará lugar a que la comunidad SEO se apresure a analizar estos documentos y, colectivamente, estaremos descubriendo y recontextualizando cosas durante los próximos meses.
  • Esta parece ser la información actual – Lo mejor que puedo decir, esta fuga representa la arquitectura actual, activa de Google Search Content Storage a partir de marzo de 2024. (Que una persona de relaciones públicas de Google diga que me equivoco. En realidad, vamos a saltarnos la canción y el baile). Según el historial de confirmaciones, el código relacionado se publicó el 27 de marzo de 2024 y no se eliminó hasta el 7 de mayo de 2024.
A screenshot of the repository commits with visual proof that the information was committed on May 7th 2024.
  • Correlación no es causalidad – Vale, esta no es realmente aplicable aquí, pero quería asegurarme de que cubría todas las bases.

HAY 14.000 FUNCIONES DE CLASIFICACIÓN DE GOOGLE Y MÁS EN LOS DOCUMENTOS

Hay 2.596 módulos representados en la documentación de la API con 14.014 atributos (características) que tienen este aspecto:

Screenshot of API Documentation with the following text: GoogleApi.ContentWarehouse.V1.Model.CompressedQualitySignals A message containing per doc signals that are compressed and included in Mustang and TeraGoogle. For TeraGoogle, this message is included in perdocdata which means it can be used in preliminary scoring. CAREFUL: For TeraGoogle, this data resides in very limited serving memory (Flash storage) for a huge number of documents. Next id: 43 Attributes * ugcDiscussionEffortScore (type: integer(), default: nil) - UGC page quality signals. (Times 1000 and floored) * productReviewPPromotePage (type: integer(), default: nil) - * experimentalQstarDeltaSignal (type: number(), default: nil) - This field is not propagated to shards. It is meant to be populated at serving time using one of the versions present in the experimental_nsr_team_wsj_data field above (using the ExperimentalNsrTeamDataOverridesParams option to populate it; see http://source/search? ExperimentalNsrTeamDataOverridesParams%20file:ascorer.proto). The purpose of this field is to be read by an experimental Q* component, in order to quickly run LEs with new delta components. See go/oDayLEs for details. * productReviewPDemoteSite (type: integer(), default: nil) - Product review demotion/promotion, confidences. (Times 1000 and floored) * experimentalQstarSiteSignal (type: number(), default: nil) - This field is not propagated to shards. It is meant to be populated at serving time using one of the versions present in the experimental_nsr_team_wsj_data field above (using the ExperimentalNsrTeamDataOverridesParams option to populate it; see http://source/search? ExperimentalNsrTeamDataOverridesParams%20file:ascorer.proto). The purpose of this field is to be read by an experimental Q* component, in order to quickly run LEs with new site components. See go/oDayLEs for details. * exactMatchDomainDemotion (type: integer(), default: nil) - Page quality signals converted from fields in proto QualityBoost in quality/q2/proto/quality-boost.proto. To save indexing space, we convert (cut off)

Los módulos están relacionados con componentes de YouTube, Assistant, Books, búsqueda de vídeos, enlaces, documentos web, infraestructura de rastreo, un sistema de calendario interno y la API People. Al igual que Yandex, los sistemas de Google funcionan en un repositorio monolítico (o “monorepo”) y las máquinas operan en un entorno compartido. Esto significa que todo el código se almacena en un único lugar y que cualquier máquina de la red puede formar parte de cualquiera de los sistemas de Google.

The image titled "Shared Environment" is a block diagram illustrating various components and their arrangement within a shared environment. The diagram is divided into multiple layers, each representing different types of applications and system services. Here are the details: Top Layer: random app #2 (cyan background) cpu intensive job (cyan background) random app (cyan background) random MapReduce #1 (cyan background) Bigtable tablet server (cyan background) Middle Layer: various other system services (blue background) Bottom Layer: file system chunkserver (blue background) scheduling system (blue background) Base Layer: Linux (blue background) The entire diagram is bordered by a dotted line, indicating the shared environment. The Google logo is present at the bottom-right corner of the image.

La documentación filtrada describe cada módulo de la API y los desglosa en resúmenes, tipos, funciones y atributos. La mayor parte de lo que estamos viendo son las definiciones de propiedades para varios búferes de protocolo (o protobufs) a los que se accede a través de los sistemas de clasificación para generar SERPs (Search Engine Result Pages – lo que Google muestra a los buscadores después de realizar una consulta).

The image is a flowchart illustrating the process of using Protocol Buffers (PB) for data serialization. The flowchart consists of four main steps, each represented by a block with arrows indicating the direction of the process flow: Create .proto file to define data structure Output: .proto file Generate code using the protoc compiler Input: .proto file Output: .java, .py, .cc, or other source files Compile PB code with your project code Input: .java, .py, .cc, or other source files Output: Compiled classes Use PB classes to serialize, share, & deserialize data Input: Compiled classes Each block is connected by arrows labeled with "Input" and "Output" to show the dependencies between steps. The flowchart visually explains how to go from defining data structures in a .proto file to using the compiled classes for data serialization and deserialization in a project.

Por desgracia, muchos de los resúmenes hacen referencia a enlaces Go, que son URL de la intranet corporativa de Google, que ofrecen detalles adicionales sobre distintos aspectos del sistema. Sin las credenciales de Google adecuadas para acceder y ver estas páginas (lo que casi con toda seguridad requeriría ser un Googler actual del equipo de Búsqueda), nos vemos abandonados a nuestra suerte para interpretarlas.

LOS DOCUMENTOS DE LA API REVELAN ALGUNAS MENTIRAS NOTABLES DE GOOGLE

Los portavoces de Google han hecho todo lo posible para desorientarnos y engañarnos sobre diversos aspectos del funcionamiento de sus sistemas, en un esfuerzo por controlar nuestro comportamiento como SEO. No voy a llegar al extremo de llamarlo “ingeniería social” debido a la historia cargada de ese término. En su lugar, lo llamaremos “gaslighting”. Las declaraciones públicas de Google probablemente no son esfuerzos intencionados para mentir, sino más bien para engañar a los spammers potenciales (y a muchos SEOs legítimos también) para despistarnos sobre cómo impactar en los resultados de búsqueda.

A continuación, presento afirmaciones de empleados de Google junto con hechos de la documentación con comentarios limitados para que puedas juzgar por ti mismo.

“No tenemos nada parecido a la autoridad de dominio”

Los portavoces de Google han dicho en numerosas ocasiones que no utilizan la “autoridad de dominio”. Siempre he supuesto que se trataba de una mentira por omisión y ofuscación. 

Al decir que no utilizan la autoridad de dominio, podrían estar diciendo específicamente que no utilizan la métrica de Moz llamada “Domain Authority” (obviamente ). También podrían estar diciendo que no miden la autoridad o importancia de un tema específico (o dominio) en relación con un sitio web. Esta confusión semántica les permite no responder nunca directamente a la pregunta de si calculan o utilizan métricas de autoridad para todo el sitio. 

Gary Ilyes, analista del equipo de búsqueda de Google que se dedica a publicar información para ayudar a los creadores de sitios web, ha repetido esta afirmación en numerosas ocasiones.

The image is a screenshot of a Twitter conversation. The conversation involves three tweets and appears to discuss the impact of backlinks on domain authority. The text of the tweets is as follows: Tweet by //Andrew Rodgers (@AndyNRodgers) on October 27, 2016: "@JohnMu Would a backlink to a jpg URL have the same impact in the algorithm as a static URL? @methode" Engagement: 1 like, 2 retweets Tweet by //Andrew Rodgers (@AndyNRodgers) on October 27, 2016 (reply to the first tweet): "Not sure I understand. For overall domain authority would a backlink to a jpg URL be as impactful as to a webpage URL?" Engagement: 1 like Tweet by Gary Illyes (@methode) on October 27, 2016 (reply to Andrew Rodgers): "we don't really have 'overall domain authority'. A text link with anchor text is better though" Timestamp: 8:34 AM · Oct 27, 2016 from Kebayoran Lama, Indonesia The image also includes profile pictures and names of the participants in the conversation.

Y Gary no está solo. John Mueller, un “defensor de las búsquedas que coordina las relaciones de búsqueda de Google” declaró en este vídeo “no tenemos puntuación de autoridad del sitio web”. 

En realidad, como parte de las Señales de Calidad Comprimidas que se almacenan por documento, Google tiene una característica que computan llamada “siteAuthority”. 

The image contains a snippet of technical documentation describing the attribute "siteAuthority." Title: siteAuthority Type: integer(), default: nil Description: site_authority: converted from quality_nsr.SiteAuthority, applied in Qstar.

No sabemos específicamente cómo se calcula esta medida o cómo se utiliza en las funciones de puntuación posteriores, pero ahora sabemos definitivamente que existe y que se utiliza en el sistema de clasificación Q*. Resulta que Google sí tiene una autoridad de dominio global. Los Googlers afirman que “la tenemos, pero no la utilizamos”, o “no entiendes lo que significa”, o… espera, he dicho “comentarios limitados”, ¿no? Sigamos.

“No utilizamos los clics para la clasificación”

Acabemos con esto de una vez por todas.

El testimonio de Pandu Nayak en el juicio antimonopolio del DOJ reveló recientemente la existencia de los sistemas de clasificación Glue y NavBoost. NavBoost es un sistema que emplea medidas basadas en los clics para mejorar, degradar o reforzar una clasificación en la búsqueda web. Nayak indicó que Navboost existe desde 2005 e históricamente utilizaba 18 meses consecutivos de datos de clics. El sistema se actualizó recientemente para utilizar 13 meses de datos y se centra en los resultados de búsqueda web, mientras que un sistema llamado Glue se asocia con otros resultados de búsqueda universales. Pero, incluso antes de esa revelación, disponíamos de varias patentes (incluida la de 2007 sobre Time Based Ranking) que indican específicamente cómo pueden utilizarse los registros de clics para cambiar los resultados. 

También sabemos que los clics como medida del éxito es una práctica recomendada en la recuperación de información. Sabemos que Google ha pasado a utilizar algoritmos basados en el aprendizaje automático y que el aprendizaje automático requiere variables de respuesta para perfeccionar su rendimiento. A pesar de esta asombrosa evidencia, todavía hay confusión en la comunidad SEO debido a la mala dirección de los portavoces de Google y la publicación vergonzosamente cómplice de artículos en todo el mundo del marketing de búsqueda que repiten acríticamente las declaraciones públicas de Google.

Gary Ilyes ha abordado esta cuestión de la medición de clics muchas veces. En una ocasión reforzó lo que el ingeniero de Google Search Paul Haahr compartió en su charla de SMX West de 2016 sobre experimentos en vivo, diciendo que “utilizar los clics directamente en los rankings sería un error”.

The image is a screenshot of a text excerpt from an interview or article discussing Google's Quality Update and the role of clicks in assessing quality. The text is as follows: DS: Last month, we had the Quality Update. How is Google assessing the quality? How do clicks factor in? GI: We use clicks in different ways. The main things that we use clicks for evaluation and experimentation. There are many, many people who are trying to induce noise in clicks. Rand Fishkin, for example, is experimenting with clicks. Using clicks directly in ranking would be a mistake. In personalized results, if you search for apple, we would most likely serve you a disambiguation box. We have to figure out if you mean the company or the food. Then, we’d look at the click you made. A portion of the text, specifically "Using clicks directly in ranking would be a mistake," is highlighted in yellow.

Más tarde, utilizó su plataforma para menospreciar a Rand Fishkin (fundador y CEO de Moz, y un veterano en SEO) diciendo que “el tiempo de permanencia, el CTR, cualquiera que sea la nueva teoría de Fishkin, son generalmente basura inventada”.

The image is a screenshot of a Reddit post by Gary Illyes, identified by the username "garyillyes," responding to a user named Lyndon. The post is part of a thread with 36 upvotes, an award, and 24 more replies. The text of the post is as follows: garyillyes OP • 5y ago Hey Lyndon! I'll answer this quickly because I'm waiting for a plane and I'm bored (I'm supposed to answer questions tomorrow). RankBrain is a PR-sexy machine learning ranking component that uses historical search data to predict what would a user most likely click on for a previously unseen query. It is a really cool piece of engineering that saved our butts countless times whenever traditional algos were like, e.g. "oh look a 'not' in the query string! let's ignore the hell out of it!", but it's generally just relying on (sometimes) months old data about what happened on the results page itself, not on the landing page. Dwell time, CTR, whatever Fishkin's new theory is, those are generally made up crap. Search is much more simple than people think. The portion of the text, "Dwell time, CTR, whatever Fishkin's new theory is, those are generally made up crap. Search is much more simple than people think," is highlighted in yellow.

En realidad, Navboost dispone de un módulo específico dedicado por completo a las señales de clic. 

El resumen de ese módulo lo define como “señales de clics e impresiones para Craps”, uno de los sistemas de clasificación. Como vemos a continuación, se consideran como métricas los clics malos, los clics buenos, los últimos clics más largos, los clics no aplastados y los últimos clics más largos no aplastados. Según la patente de Google “Scoring local search results based on location prominence”, “Squashing is a function that prevents one large signal from dominating the others”. En otras palabras, los sistemas normalizan los datos de clics para garantizar que no haya una manipulación descontrolada basada en la señal de clics. Los responsables de Google argumentan que los sistemas que aparecen en patentes y libros blancos no son necesariamente los que están en producción, pero NavBoost sería un sinsentido construirlo e incluirlo si no fuera una parte fundamental de los sistemas de recuperación de información de Google.

The image contains technical documentation describing several attributes related to clicks. Each attribute is detailed with its type and default value. The text is as follows: badClicks Type: float(), default: nil clicks (type: float(), default: nil) - goodClicks Type: float(), default: nil impressions (type: float(), default: nil) - lastLongestClicks Type: float(), default: nil unicornClicks (type: float(), default: nil) - The subset of clicks that are associated with an event from a Unicorn user. unsquashedClicks Type: float(), default: nil This is not being populated for the current format - instead, two instances of CrapsClickSignals (squashed/unsquashed) are used. We are migrating to the new format where this field will be populated. unsquashedImpressions Type: float(), default: nil This is not being populated for the current format - instead, two instances of CrapsClickSignals (squashed/unsquashed) are used. We are migrating to the new format where this field will be populated. unsquashedLastLongestClicks Type: float(), default: nil This is not being populated for the current format - instead, two instances of CrapsClickSignals (squashed/unsquashed) are used. We are migrating to the new format where this field will be populated.

Muchas de estas mismas medidas basadas en los clics se encuentran también en otro módulo relacionado con las señales de indexación. Una de las medidas es la fecha del “último buen clic” en un documento determinado. Esto sugiere que el deterioro del contenido (o la pérdida de tráfico a lo largo del tiempo) también es una función de una página de clasificación que no genera la cantidad de clics esperada para su posición en la SERP. 

Además, la documentación representa a los usuarios como votantes y sus clics se almacenan como sus votos. El sistema cuenta el número de clics erróneos y segmenta los datos por país y dispositivo.

También almacenan qué resultado tuvo el clic más largo durante la sesión. Por tanto, no basta con realizar la búsqueda y hacer clic en el resultado, los usuarios también tienen que pasar un tiempo significativo en la página. Los clics largos son una medida del éxito de una sesión de búsqueda, al igual que el tiempo de permanencia, pero en esta documentación no existe una función específica denominada “tiempo de permanencia”. No obstante, los clics prolongados son efectivamente medidas de lo mismo, lo que contradice las declaraciones de Google al respecto.

Varias fuentes han indicado que NavBoost es “ya una de las señales de clasificación más potentes de Google”. La documentación filtrada especifica “Navboost” por su nombre 84 veces, con cinco módulos que incluyen Navboost en el título. También hay pruebas de que contemplan su puntuación a nivel de subdominio, dominio raíz y URL, lo que indica intrínsecamente que tratan de forma diferente los distintos niveles de un sitio. No voy a entrar en la discusión subdominio vs. sudominio, pero más adelante hablaremos de cómo los datos del sistema también han informado al algoritmo Panda.

Así que, sí, Google no menciona “CTR” o “tiempo de permanencia” con esas palabras exactas en esta documentación, pero se incluye el espíritu de lo que Rand demostró: clics en los resultados de búsqueda y medidas de una sesión de búsqueda satisfactoria. Las pruebas son bastante definitivas, no cabe duda de que Google utiliza los clics y el comportamiento posterior al clic como parte de sus algoritmos de clasificación.

“No hay Sandbox”

Los portavoces de Google han sido categóricos al afirmar que no existe un sandbox al que se segreguen los sitios web en función de su antigüedad o de la falta de señales de confianza. En un tuit ahora eliminado, John Muller respondió a una pregunta sobre cuánto tiempo se tarda en ser elegible para clasificar indicando que “No hay sandbox”.

The image is a screenshot of a Twitter exchange between two users discussing the concept of the Google sandbox for new websites. The text of the tweets is as follows: Tweet by Vijay Kumar (@VijayKumarIM) on August 19: "That's great to hear from you... Usually how long does it take to relieve from Google sandbox for new website?" Engagement: 1 like Reply by John (@JohnMu) on August 19: "There is no sandbox." Timestamp: 10:48 AM · 19 Aug 2019 Engagement: 7 likes, 3 retweets The reply is highlighted by the user's profile picture and verification checkmark, indicating it is a response from a verified account.

En el módulo PerDocData, la documentación indica un atributo llamado hostAge que se utiliza específicamente “para sandbox spam fresco en tiempo de servicio”.

Resulta que hay una caja de arena después de todo. ¿Quién lo sabía? Ah, sí, Rand lo sabía.

“No utilizamos nada de Chrome para el Ranking”

Anteriormente se había citado a Matt Cutts diciendo que Google no utiliza los datos de Chrome como parte de la búsqueda orgánica. Más recientemente, John Mueller reforzó esta idea. 

The image contains a snippet of technical documentation describing an attribute related to Chrome views. The text is as follows: chromeInTotal (type: number(), default: nil) - Site-level Chrome views. This attribute is described as being of type number() with a default value of nil, and it pertains to site-level views in Chrome.

Uno de los módulos relacionados con las puntuaciones de calidad de las páginas presenta una medida a nivel de sitio de las visitas desde Chrome. Otro módulo que parece estar relacionado con la generación de sitelinks también tiene un atributo relacionado con Chrome.

The image is a slide titled "Realtime Boost Signal" with a link to (go/realtime-boost). The content of the slide includes information on the sources and uses of real-time boost signals, as well as graphs illustrating query trends. Here are the details: Title: Realtime Boost Signal (go/realtime-boost) Spikes and Correlations on Content Creation Location (S2), Entities, Salient Terms, NGrams... Sources: Freshdocs-instant Chrome Visits (soon) (highlighted in yellow) Instant Navboost (soon) Not restricted by Twitter contract Run in Query Rewriter: Can be used anywhere: Freshbox, Stream... Graphs: Top Right Graph: Titled "Twitter Hemlock Query Trend" with a red line indicating "Noise level (median + 1IQR)" and a spike indicated by an arrow labeled "Spike." Bottom Right Graph: Titled "Query [Dilma]" with the caption "Spike 5 mins after impeachment process announced." It shows a spike in the score time series for the term "Dilma." At the bottom, the slide has a note saying "No birds were hurt in the making of Realtime Boost signal," and the Google logo is displayed in the bottom left corner.

Una presentación interna filtrada de mayo de 2016 sobre el sistema RealTime Boost también indica que los datos de Chrome iban a llegar a las búsquedas. Es decir, ya me entiendes.

Los portavoces de Google tienen buenas intenciones, pero ¿podemos fiarnos de ellos?

La respuesta rápida es que no cuando te acercas demasiado a la salsa secreta.

No albergo mala voluntad contra las personas que he citado aquí. Estoy seguro de que todos ellos hacen todo lo posible por ofrecer apoyo y valor a la comunidad dentro de los límites permitidos. Sin embargo, estos documentos dejan claro que debemos seguir tomando lo que dicen como una aportación y nuestra comunidad debe seguir experimentando para ver qué funciona.

ARQUITECTURA DE LOS SISTEMAS DE CLASIFICACIÓN DE GOOGLE

Conceptualmente, puedes pensar en “el algoritmo de Google” como una sola cosa, una ecuación gigante con una serie de factores de clasificación ponderados. En realidad, se trata de una serie de microservicios en los que muchas funciones se procesan previamente y se ponen a disposición en tiempo de ejecución para componer la SERP. Según los distintos sistemas a los que se hace referencia en la documentación, puede haber más de cien sistemas de clasificación diferentes. Suponiendo que estos no sean todos los sistemas, quizás cada uno de los sistemas por separado represente una “señal de clasificación” y quizás así es como Google llega a las 200 señales de clasificación de las que habla a menudo.

En la charla de Jeff Dean “Building Software Systems at Google and Lessons Learned”, mencionó que las primeras iteraciones de Google enviaban cada consulta a 1.000 máquinas para que la procesaran y respondieran en menos de 250 milisegundos. También hizo un diagrama de una versión anterior de la abstracción de la arquitectura del sistema. Este diagrama ilustra que Super Root es el cerebro de la Búsqueda de Google que envía las consultas y lo une todo al final. 

The image is a flowchart titled "2007: Universal Search," which illustrates the components and process flow of Google's Universal Search system from 2007. The diagram includes various elements connected by arrows indicating the direction of data flow. Here are the details: Title: 2007: Universal Search Flowchart Components: Query (text at the top indicating the input query) Frontend Web Server (red box) Arrow from Query to Frontend Web Server Super root (blue box) Arrow from Frontend Web Server to Super root Arrow from Cache servers to Super root Ad System (blue box) Arrow from Frontend Web Server to Ad System Arrow from Ad System to Frontend Web Server Indexing Service (blue bar at the bottom) Search Categories (all green triangles): Images Local News Web (largest triangle) Video Blogs Books Connections: Arrows from Super root to each of the search categories (Images, Local, News, Web, Video, Blogs, Books) Google Logo is displayed in the bottom right corner of the image.

El distinguido ingeniero de investigación Marc Najork, en su reciente presentación sobre la recuperación de información generativa, mostró un modelo abstracto de la búsqueda de Google con su sistema RAG (también conocido como Search Generative Experience/AI Overviews). Este diagrama ilustra una serie de diferentes almacenes de datos y servidores que procesan las distintas capas de un resultado.

The image is a diagram titled "Architecture of a retrieval-augmented GQA system," presented by Google DeepMind. The diagram outlines the components and workflow of a retrieval-augmented generative question-answering system. The structure is divided into two main sections: off-line/crawl-time and on-line/query-time. Title: Architecture of a retrieval-augmented GQA system Components and Workflow: Content (cloud icon on the left side) Crawler (box connected to Content) Off-line / Crawl-time (top left section): LM Trainer (box connected to Crawler and Corpus Builder) Language Model (box connected to LM Trainer and Corpus) Corpus Builder (box connected to Crawler and Corpus) Document Embedder (box connected to Crawler and Vector DB) Index Builder (box connected to Crawler and Inverted Index) Central Components: Corpus (connected to Corpus Builder and Language Model) Vector DB (connected to Document Embedder) Inverted Index (connected to Index Builder) On-line / Query-time (top right section): LM Generator (box connected to Corpus Server and Search Front End) Corpus Server (connected to Corpus and LM Generator) Embedding Server (connected to Vector DB and Search Front End) Index Server (connected to Inverted Index and Search Front End) Search Front End (box in the center right, connected to Corpus Server, Embedding Server, and Index Server) Users (cloud icon on the right side, connected to Search Front End) Arrows and Connections: Arrows indicate data flow and connections between components, linking Content to the Crawler, and subsequently to other components in the system. Arrows from the Crawler feed into the LM Trainer, Corpus Builder, Document Embedder, and Index Builder, which then connect to their respective components. Central components (Corpus, Vector DB, Inverted Index) connect to their on-line/query-time counterparts (Corpus Server, Embedding Server, Index Server). The Search Front End aggregates data from the on-line components and provides results to Users. Notes: Labels such as "1" and "2" next to the arrows from the Search Front End indicate steps or actions in the query process. The diagram shows the separation of processes and components between off-line/crawl-time and on-line/query-time to manage data retrieval and question answering efficiently.

El informante de Google, Zach Vorhies, filtró esta diapositiva que muestra las relaciones de diferentes sistemas dentro de Google por sus nombres internos. En la documentación se hace referencia a varios de ellos.

The image is a diagram titled "a sample of ML across the company" and shows how machine learning (ML) is integrated into various Google and Alphabet products. The diagram illustrates connections between different ML teams and products, with circle size proportional to the number of connections. Title: a sample of ML across the company Subtitle: Machine learning is core to a wide range of Google products and Alphabet companies. Components: ML Teams (green circles): Sibyl Drishti Brain Laser SAFT Alphabet companies (red circles): [X] Chauffeur Life Sciences Google products (yellow circles): Nest Search Indexing Android Speech Geo Play Music, Movies, Books, Games Image Search G+ GDN Context Ads YouTube Search Translate Email Inbox Play Apps Product Ads GMob Mobile Ads Google TV Security Google Now WebAnswers Genie Connections: Lines connect various ML teams to multiple Google products and Alphabet companies, indicating collaboration or integration of machine learning technologies. For example, the "Brain" ML team connects to numerous products such as Nest, Search Indexing, Android Speech, Geo, YouTube, and Translate, among others. The "Laser" team connects to products like Google TV, Security, Google Now, and Play Apps. Legend: Green circles: ML team Red circles: Alphabet companies Yellow circles: Google products Circle size is proportional to the number of connections Logo and Disclaimer: Google logo at the bottom left corner "Confidential & Proprietary" note at the bottom right corner This diagram visually represents the extensive integration of machine learning across various products and services within Google and its parent company Alphabet.

Utilizando estos tres modelos de alto nivel, podemos empezar a pensar en cómo algunos de estos componentes juegan juntos. Por lo que puedo deducir de la documentación, parece que esta API se basa en Spanner de Google. Spanner es una arquitectura que básicamente permite una escalabilidad infinita de almacenamiento de contenidos y computación, al tiempo que trata una serie de ordenadores conectados en red globalmente como uno solo. 

Hay que admitir que es algo difícil entender la relación entre todo a partir de la documentación, pero el currículum de Paul Haahr ofrece una valiosa perspectiva de lo que hacen algunos de los sistemas de clasificación mencionados. Destacaré los que conozco por su nombre y los segmentaré según su función.

Rastreo

  • Trawler – El sistema de rastreo web. Dispone de una cola de rastreo, mantiene las tasas de rastreo y comprende la frecuencia con la que cambian las páginas.

Indexación

  • Alexandria – El núcleo del sistema de indexación.
  • SegIndexer – Sistema que coloca los documentos en niveles dentro del índice.
  • TeraGoogle – Sistema de indexación secundario para documentos que viven en el disco a largo plazo.

Renderización

  • HtmlrenderWebkitHeadless – Sistema de renderizado para páginas JavaScript. Curiosamente, su nombre se debe a Webkit y no a Chromium. En la documentación se menciona Chromium, por lo que es probable que Google utilizara WebKit en un principio y cambiara a Headless Chrome en cuanto llegó.

Procesamiento

  • LinkExtractor – Extrae enlaces de las páginas.
  • WebMirror – Sistema para gestionar la canonicalización y la duplicación.

Clasificación

  • Mustang – El sistema primario de puntuación, clasificación y servicio.
    • Ascorer – El algoritmo primario de clasificación que clasifica las páginas antes de cualquier ajuste de re-clasificación. 
  • NavBoost – Sistema de re-ranking basado en los registros de clics del comportamiento de los usuarios.
  • FreshnessTwiddler – Sistema de reordenación de documentos basado en la frescura.
  • WebChooserScorer – Define los nombres de las características utilizadas en la puntuación de fragmentos.

Servidor

  • Google Web Server – GWS es el servidor con el que interactúa el frontend de Google. Recibe las cargas útiles de datos para mostrarlas al usuario.
  • SuperRoot: es el cerebro de la Búsqueda de Google que envía mensajes a los servidores de Google y gestiona el sistema de postprocesamiento para la reclasificación y la presentación de resultados.
  • SnippetBrain – El sistema que genera snippets para los resultados.
  • Glue – El sistema para reunir resultados universales utilizando el comportamiento del usuario.
  • Cookbook – Sistema de generación de señales. Hay indicios de que los valores se crean en tiempo de ejecución.

Como ya he dicho, hay muchos más sistemas descritos en estos documentos, pero no está del todo claro lo que hacen. Por ejemplo, SAFT y Drishti del diagrama anterior también están representados en estos documentos, pero sus funciones no están claras.

¿QUÉ SON LOS TWIDDLERS (¿DESORIENTADORES?)?

Hay poca información en línea sobre los Twiddlers en general, así que creo que merece la pena explicarlos aquí para que podamos contextualizar mejor los distintos sistemas Boost que encontramos en los documentos. 

Los Twiddlers son funciones de re-clasificación que se ejecutan después del algoritmo primario de búsqueda Ascorer. Funcionan de forma similar a como lo hacen los filtros y las acciones en WordPress, donde lo que se muestra se ajusta justo antes de ser presentado al usuario. Los Twiddlers pueden ajustar la puntuación de recuperación de información de un documento o cambiar la clasificación de un documento. Muchos de los experimentos en vivo y los sistemas con nombre que conocemos se implementan de esta manera. Como demuestra este Xoogler, son bastante importantes en diversos sistemas de Google:

The image is a screenshot of a tweet from Deedy (@deedydas), dated September 27, 2023. The tweet describes an experience where Deedy made a change to the API definition of "superroot," a service that powers Google Search. The change disabled "twiddlers," which inadvertently affected YouTube search, causing it to go down for a couple of hours. The tweet is a response to another tweet from Aveta (@Aliafonzy43), dated September 23, 2023, asking for stories from senior engineers about significant production issues. Text on the image: Deedy (@deedydas) "One time I made a change to the API definition of superroot, the service that powers Google Search, to disable "twiddlers", without realizing all of Youtube search depended on it and I brought down Youtube search for a couple hours." Aveta (@Aliafonzy43) "I would love to hear stories from senior+ engineers who pushed fuck ups to prod to know I’m not crazy for feeling some type of way to be told my code quality is poor due to code pushed to prod that I quickly fixed when I found the issues. Just wanna know if this is something" Additional details: The tweet from Deedy has 29.6K views as of the time the screenshot was taken. Deedy's tweet is timestamped: 3:22 AM · Sep 27, 2023. Aveta's tweet is timestamped: Sep 23, 2023. Deedy's profile picture and verification checkmark are visible in the screenshot.

Los Twiddlers pueden ofrecer restricciones de categoría, lo que significa que se puede promover la diversidad limitando específicamente el tipo de resultados. Por ejemplo, el autor puede decidir permitir sólo 3 entradas de blog en una SERP determinada. Esto puede aclarar cuándo la clasificación es una causa perdida basada en el formato de su página.

Cuando Google dice que algo como Panda no formaba parte del algoritmo principal, probablemente significa que se lanzó como un Twiddler como un cálculo de mejora o degradación del reranking y más tarde se trasladó a la función de puntuación principal. Piense que es similar a la diferencia entre la renderización del lado del servidor y del lado del cliente. 

Presumiblemente, cualquiera de las funciones con el sufijo Boost opera utilizando el marco Twiddler. Éstos son algunos de los Boosts identificados en la documentación:

  • NavBoost
  • QualityBoost
  • RealTimeBoost
  • WebImageBoost

Por sus convenciones de nomenclatura, todos son bastante autoexplicativos. 

También hay un documento interno sobre Twiddlers que he revisado que habla de esto con más detalle, pero este post suena como si el autor hubiera visto el mismo documento que yo.

REVELACIONES CLAVE QUE PUEDEN INFLUIR EN SU FORMA DE HACER SEO

Vayamos a lo que realmente has venido a buscar. ¿Qué está haciendo Google que no sabíamos o de lo que no estábamos seguros y cómo puede afectar a mis esfuerzos de SEO? 

Nota rápida antes de continuar. Siempre es mi objetivo exponer la industria SEO a nuevos conceptos. No es mi objetivo para darle una receta sobre cómo utilizarlo para su caso de uso específico. Si eso es lo que quiere, debe contratar iPullRank para su SEO. De lo contrario, siempre hay más que suficiente para que usted pueda extrapolar y desarrollar sus propios casos de uso.

Cómo funciona Panda

Cuando se lanzó Panda hubo mucha confusión. ¿Es aprendizaje automático? ¿Utiliza señales de usuario? ¿Por qué necesitamos una actualización para recuperarnos? ¿Es en todo el sitio? ¿Por qué he perdido tráfico en un determinado subdirectorio?

Panda se lanzó bajo la dirección de Amit Singhal. Singhal estaba decididamente en contra del aprendizaje automático debido a su limitada observabilidad. De hecho, hay una serie de patentes centradas en la calidad de los sitios para Panda, pero en la que quiero centrarme es en la no descriptiva “Clasificación de los resultados de búsqueda”. La patente aclara que Panda es mucho más simple de lo que pensábamos. Se trata en gran medida de construir un modificador de puntuación basado en señales distribuidas relacionadas con el comportamiento de los usuarios y los enlaces externos. Ese modificador puede aplicarse a nivel de dominio, subdominio o subdirectorio. 

“El sistema genera un factor de modificación para el grupo de recursos a partir del recuento de enlaces independientes y del recuento de consultas de referencia (paso 306). Por ejemplo, el factor de modificación puede ser una relación entre el número de enlaces independientes para el grupo y el número de consultas de referencia para el grupo. Es decir, el factor de modificación (M) puede expresarse como:
M=IL/RQ,
donde IL es el número de enlaces independientes contados para el grupo de recursos y RQ es el número de consultas de referencia contadas para el grupo de recursos”.

Los enlaces independientes son básicamente lo que consideramos dominios raíz de enlace, pero las consultas de referencia son un poco más complicadas. Así es como se definen en la patente:

“Una consulta de referencia para un grupo particular de recursos puede ser una consulta de búsqueda previamente enviada que ha sido categorizada como referida a un recurso en el grupo particular de recursos. La categorización de una consulta de búsqueda particular previamente enviada como referida a un recurso en el grupo particular de recursos puede incluir: determinar que la consulta de búsqueda particular previamente enviada incluye uno o más términos que han sido determinados para referirse al recurso en el grupo particular de recursos.”

Ahora que tenemos acceso a esta documentación, está claro que las consultas de referencia son consultas de NavBoost.

The image is a snippet of technical documentation titled "GoogleApi.ContentWarehouse.V1.Model.RepositoryWebrefQueryIndices." The documentation describes the identification and attributes of a set of NavBoost queries in the CompositeDoc. These queries were typically collapsed by WebRef into a single query and treated by the annotator as equivalent. All contain the same mentions at the same offsets. Title: GoogleApi.ContentWarehouse.V1.Model.RepositoryWebrefQueryIndices Description: Identifies a set of NavBoost queries in the CompositeDoc. Typically, these queries were collapsed by WebRef into a single query and they were treated by the annotator as equivalent. They all contain the same mentions (at the same offsets). Attributes: featuresIndex (type: list(integer()), default: nil) - The set of indices in the NavBoostQuery::features() array that belong to the collapsed features. queriesIndex (type: integer(), default: nil) - The index of the query in NavBoostDocument::queries() array.

Esto sugiere que las actualizaciones de Panda eran simplemente actualizaciones de la ventana móvil de consultas, de forma similar a como funcionan los cálculos de Core Web Vitals. También podría significar que las actualizaciones del gráfico de enlaces no se procesaban en tiempo real para Panda.

No es por polemizar, pero otra patente de Panda, la puntuación de calidad del sitio, también contempla una puntuación que es una relación entre las consultas de referencia y las selecciones o clics del usuario.

La conclusión es que es necesario conseguir más clics con éxito utilizando un conjunto más amplio de consultas y obtener más diversidad de enlaces si se quiere seguir clasificando. Conceptualmente, tiene sentido porque una pieza muy fuerte de contenido hará eso. Centrarse en dirigir más tráfico cualificado hacia una mejor experiencia de usuario enviará señales a Google de que su página merece clasificarse. Deberías centrarte en lo mismo para recuperarte de la Actualización de Contenido Útil.

Los autores son una característica explícita

Se ha escrito mucho sobre E-E-A-T. Muchos SEO son incrédulos debido a lo nebuloso que es puntuar la experiencia y la autoridad. También he destacado anteriormente lo poco que el marcado de autor está realmente en la web. Antes de conocer las incrustaciones vectoriales, no creía que la autoría fuera una señal suficientemente viable a escala web.

The image is a presentation slide titled "How When Authorship Markup Tops out at 3%?" It contains several bar graphs that show the usage of different types of markup by year. Each graph represents a different type of markup, and there are arrows highlighting specific data points. The slide is numbered 94 at the bottom left corner. Title: How When Authorship Markup Tops out at 3%? Graphs: RDFa usage by year Data for years: 2012, 2017 Highlighted data point: foaf (0.31%) Other data points include: foaf , content, sioc , dcterms , etc. Microdata usage by year Data for years: 2012, 2017 Highlighted data point: schema.org/author (1.5%) Other data points include: schema.org/name, schema.org/url, schema.org/description, etc. Twitter meta tag usage by year Data for years: 2012, 2017 Highlighted data point: twitter (20%) Other data points include: twitter , twitter , twitter , etc. JSON-LD usage by year Data for years: 2012, 2017 Highlighted data point: schema.org/author (1.1%) Other data points include: WebSite, Organization, WebPage, Article, BreadcrumbList, etc. Dublin Core usage by year Data for years: 2012, 2017 Highlighted data point: dc.creator (0.06%) Other data points include: dc.title, dc.subject, dc.description, dc.publisher, etc. Each graph shows the percent of pages using the specific markup in each year. Red arrows point to particular data points to emphasize their significance. The usage percentages are provided along the x-axis of each graph.

No obstante, Google almacena explícitamente los autores asociados a un documento como texto:

The image contains a snippet of technical documentation describing an attribute related to document authorship. The text is as follows: author Type: list(String,t), default: nil Description: Document author(s). This attribute specifies the type as a list of strings with a default value of nil, indicating that it can contain multiple author names for a document.

También buscan determinar si una entidad de la página es también el autor de la misma.

The image contains a snippet of technical documentation describing the attribute "isAuthor." The text is as follows: isAuthor Type: boolean(), default: nil Description: True if the entity is the author of the document. This was mainly developed and tuned for news articles (e.g., /m/02x27qn on "www.vogue.com/article/flint-town-netflix") but is also populated for other content (e.g., scientific articles). Important: the semantics of this field may change in the future or it might be removed and replaced with a different API. If you want to use this field, please reach out to ke-authors@ first. This attribute is a boolean indicating whether the entity is the author of the document. It was primarily designed for news articles but can also be used for other types of content.

Esto, combinado con el mapeo exhaustivo de entidades e incrustaciones que se muestra en estos documentos, deja bastante claro que existe una medición exhaustiva de los autores.

Demostraciones

Hay una serie de degradaciones algorítmicas comentadas en la documentación. Las descripciones son limitadas, pero vale la pena mencionarlas. Ya hemos hablado de Panda, pero el resto de degradaciones que he encontrado son:

  • Anchor Mismatch – Cuando el enlace no coincide con el sitio de destino al que enlaza, el enlace es degradado en los cálculos. Como he dicho antes, Google busca relevancia en ambos lados de un enlace.
  • Descenso de la SERP: señal que indica un descenso basado en factores observados en la SERP, lo que sugiere una posible insatisfacción del usuario con la página, medida probablemente por los clics.
  • Nav Demotion – Presumiblemente, se trata de una degradación aplicada a páginas que muestran malas prácticas de navegación o problemas de experiencia de usuario.
  • Descenso de dominios de coincidencia exacta – A finales de 2012, Matt Cutts anunció que los dominios de coincidencia exacta no recibirían tanto valor como lo hacían históricamente. Existe una función específica para su degradación.
  • Product Review Demotion – No hay información específica sobre esto, pero está listado como una degradación y probablemente relacionado con la reciente actualización de 2023 de las revisiones de productos. 
  • Degradación de ubicación: se indica que las páginas “globales” y “superglobales” pueden degradarse. Esto sugiere que Google intenta asociar páginas con una ubicación y clasificarlas en consecuencia.
  • Descensos de porno – Este es bastante obvio.
  • Otras degradaciones de enlaces: lo veremos en la siguiente sección.

Todas estas degradaciones potenciales pueden informar una estrategia, pero se reduce a hacer un contenido estelar con una fuerte experiencia de usuario y la construcción de una marca, si somos honestos.

Los enlaces siguen siendo importantes

No he visto ninguna prueba que refute las recientes afirmaciones de que los enlaces se consideran menos importantes. Una vez más, es probable que esto se deba a las propias funciones de puntuación y no a la forma en que se almacena la información. Dicho esto, se ha puesto mucho cuidado en extraer y diseñar características para comprender en profundidad el gráfico de enlaces. 

El nivel de indexación influye en el valor de los enlaces

Una métrica denominada sourceType que muestra una relación poco clara entre el lugar en el que se indexa una página y su valor. Para que te hagas una idea, el índice de Google está estratificado en niveles en los que el contenido más importante, que se actualiza con regularidad y al que se accede, se almacena en memoria flash. El contenido menos importante se almacena en unidades de estado sólido y el contenido que se actualiza de forma irregular se almacena en discos duros estándar.

AD 4nXdwdNF3MsYwk6wH6U MeJaUEjMhGIGZeFA POWxkSFwxCfDiNFMiyzO dQggw0mOqPNaJgCkxFpGCAdZPcXS1LNt2gKJbvak Kw6UIcSjfyg3pL9olPJSUF16sQWk5j9YMPic8EPX0Sij3rGKXb2XJELLf1?key=KBOuX93Bu5VNsHs9sB47Cg

Efectivamente, esto viene a decir que cuanto más alto es el nivel, más valioso es el enlace. Las páginas que se consideran “frescas” también se consideran de alta calidad. Basta con decir que usted quiere que sus enlaces provengan de páginas que sean frescas o que aparezcan en el nivel superior. Esto explica en parte por qué obtener rankings de páginas de alto ranking y de páginas de noticias produce un mejor rendimiento en el ranking. Mira, ¡acabo de hacer que las relaciones públicas digitales vuelvan a estar de moda!

Señales de velocidad de spam de enlaces

Hay toda una serie de métricas sobre la identificación de picos de spam anchor text. Tomando nota de la función phraseAnchorSpamDays, Google tiene efectivamente la capacidad de medir la velocidad de enlace de spam.

The image is a snippet of technical documentation titled "IndexingDocjoinerAnchorPhraseSpamInfo." It describes various attributes used to identify spikes of spammy anchor phrases. Anchors created during the spike are tagged with LINK_SPAM_PHRASE_SPIKE. Title: IndexingDocjoinerAnchorPhraseSpamInfo Description: Following signals identify spikes of spammy anchor phrases. Anchors created during the spike are tagged with LINK_SPAM_PHRASE_SPIKE. Attributes: phraseAnchorSpamCount Type: number(), default: nil Description: How many spam phrases found in the anchors among unique domains. phraseAnchorSpamDays Type: number(), default: nil Description: Over how many days 80% of these phrases were discovered. phraseAnchorSpamDemoted Type: integer(), default: nil Description: Total number of demoted anchors. phraseAnchorSpamEnd Type: integer(), default: nil Description: Time when anchor spam spike ended with padding. phraseAnchorSpamFraq Type: number(), default: nil Description: Spam phrases fraction of all anchors of the document. This documentation provides details on how to monitor and manage spammy anchor phrases within the indexing system.

Esto podría utilizarse fácilmente para identificar cuándo un sitio está haciendo spam y para anular un ataque de SEO negativo. Para aquellos que son escépticos acerca de esto último, Google puede utilizar estos datos para comparar una línea de base de descubrimiento de enlaces contra una tendencia actual y simplemente no contar esos enlaces en cualquier dirección.

Google sólo utiliza los últimos 20 cambios de una URL determinada al analizar los enlaces.

Ya he hablado anteriormente de cómo el sistema de archivos de Google es capaz de almacenar versiones de páginas a lo largo del tiempo de forma similar a Wayback Machine. Según tengo entendido, Google guarda para siempre lo que ha indexado. Esta es una de las razones por las que no se puede simplemente redirigir una página a un objetivo irrelevante y esperar que el link equity fluya.

The image shows a flowchart representing the stages of processing an HTML content event, specifically focusing on extracting and handling domain names and content. Start: The process begins with an input labeled "Content_HTML_event." First Stage: Three HTML documents are processed, each labeled "...." These documents are shown with arrows pointing left to right, indicating sequential processing times 𝑡 5 t 5 ​ , 𝑡 6 t 6 ​ , and 𝑡 3 t 3 ​ . Second Stage: The next step involves extracting the domain name from the HTML content. This stage has an arrow pointing downwards to a box labeled "cnn.com," corresponding to the domain name extraction at time 𝑡 3 t 3 ​ . Third Stage: The flow continues with an arrow pointing to the right to another box labeled "CNN," extracted at time 𝑡 9 t 9 ​ . Fourth Stage: The final stage shows the extracted text "CNN.com," with an arrow pointing to it from the top, indicating the process completion at time 𝑡 8 t 8 ​ . The image illustrates how HTML content is parsed in stages to extract specific domain-related information and content, with each step timestamped for clarity.

Los docs refuerzan esta idea dando a entender que guardan todos los cambios que han visto para la página.

The image contains a snippet of technical documentation titled "CrawlerChangerateUrlHistory." It describes various attributes related to tracking the history of URL changes in a crawler system. The text is as follows: CrawlerChangerateUrlHistory change Type: list(GoogleApi.ContentWarehouse.V1.Model.CrawlerChangerateUrlChange.t), default: nil Description: All the changes we've seen for this URL. latestVersion Type: GoogleApi.ContentWarehouse.V1.Model.CrawlerChangerateUrlVersion.t, default: nil Description: The latest version we've seen. url Type: String.t, default: nil Description: This field is only set in 'url_history' column of Union repository to avoid having to read CompositeDocs. This documentation provides information on how to track and manage the history of URL changes, including all changes, the latest version seen, and the URL itself.

Cuando sacan datos a la superficie para compararlos recuperando DocInfo, sólo tienen en cuenta las 20 últimas versiones de la página. 

The image contains a snippet of technical documentation describing the attribute "urlHistory." The text is as follows: urlHistory Type: GoogleApi.ContentWarehouse.V1.Model.CrawlerChangerateUrlHistory.t, default: nil Description: Url change history for this doc (see crawler/changerate/changerate.proto for details). Note if a doc has more than 20 changes, we only keep the last 20 changes here to avoid adding too much data in its docjoin. This documentation provides information on tracking the URL change history for a document, including a note that only the last 20 changes are kept to manage data size effectively.

Esto debería darte una idea de cuántas veces tienes que cambiar las páginas y hacer que se indexen para hacer “borrón y cuenta nueva” en Google.

El PageRank de la página de inicio se tiene en cuenta para todas las páginas

Cada documento tiene asociado su PageRank de página de inicio (la versión Nearest Seed). Es probable que se utilice como proxy para las páginas nuevas hasta que obtengan su propio PageRank.

The image contains a snippet of technical documentation describing the attribute "homepagePagerankNs." The text is as follows: homepagePagerankNs (type: integer(), default: nil) - The page-rank of the homepage of the site. Copied from the cdoc.doc().pagerank_ns() of the homepage. This attribute specifies the page-rank of the homepage of a site and is an integer with a default value of nil. The value is copied from the pagerank_ns() field of the homepage's cdoc.doc().

Es probable que esto y siteAuthority se utilicen como proxies para nuevas páginas hasta que tengan su propio PageRank calculado.

Página principal de Confianza

Google decide cómo valorar un enlace en función de cuánto confía en la página de inicio.

The image contains a snippet of technical documentation describing the attribute "homePageInfo." The text is as follows: homePageInfo (type: integer(), default: nil) - Information about if the source page is a home page. It can be one of the enum values defined in PerDocData::HomePageInfo (NOT_HOMEPAGE, NOT_TRUSTED, PARTIALLY_TRUSTED, and FULLY_TRUSTED). This attribute specifies whether the source page is a homepage and includes information about the trust level of the homepage. The possible enum values are NOT_HOMEPAGE, NOT_TRUSTED, PARTIALLY_TRUSTED, and FULLY_TRUSTED. The type is an integer with a default value of nil.

Como siempre, deberías centrarte en la calidad y relevancia de tus enlaces en lugar de en el volumen.

El tamaño de letra de los términos y enlaces es importante

Cuando empecé a hacer SEO en 2006, una de las cosas que hacíamos era poner en negrita y subrayar el texto o agrandar ciertos pasajes para que parecieran más importantes. En los últimos 5 años he visto a gente decir que todavía merece la pena hacerlo. Yo era escéptico, pero ahora veo que Google hace un seguimiento del tamaño medio ponderado de la fuente de los términos en los documentos.

The image contains a snippet of technical documentation describing the attribute "avgTermWeight." The text is as follows: avgTermWeight Type: integer(), default: nil Description: The average weighted font size of a term in the doc body. This attribute specifies the average weighted font size of a term within the document body. The type is an integer with a default value of nil.

Están haciendo lo mismo con el texto ancla de los enlaces.

The image contains a snippet of technical documentation describing the attribute "fontsize." The text is as follows: fontsize Type: integer(), default: nil experimental (type: boolean(), default: nil) - If true, the anchor is for experimental purposes and should not be used in serving. This attribute specifies the font size and includes a sub-attribute "experimental," which is a boolean with a default value of nil. If "experimental" is true, the anchor is for experimental purposes and should not be used in serving.

Penguin elimina los enlaces internos

En muchos de los módulos relacionados con el anclaje, la idea de “local” significa el mismo sitio. Este droppedLocalAnchorCount sugiere que algunos enlaces internos no se contabilizan. 

No he visto ni una sola mención a Disavow

Aunque los datos de desautorización podrían almacenarse en otro lugar, no se encuentran específicamente en esta API. Lo encuentro específicamente porque los datos de los calificadores de calidad son directamente accesibles aquí. Esto sugiere que los datos de desautorización están desvinculados de los sistemas de clasificación principales.

The image shows a search interface with a query for "disavow" entered in the search bar. Below the search bar, the following message is displayed: Autocompletion results for "disavow" Sorry, we couldn't find anything for disavow. The search bar is highlighted with a purple border, and there is a settings icon next to it on the right. The message indicates that there were no autocompletion results or search results found for the term "disavow."

Mi suposición a largo plazo ha sido que disavow ha sido un esfuerzo de ingeniería de características de origen popular para entrenar a los clasificadores de spam de Google. El hecho de que los datos no estén “en línea” sugiere que esto puede ser cierto.

Podría seguir hablando de enlaces y de características como IndyRank, PageRankNS, etc., pero basta con decir que Google tiene el análisis de enlaces muy marcado y gran parte de lo que están haciendo no se aproxima a nuestros índices de enlaces. Es un buen momento para reconsiderar sus programas de construcción de enlaces basándose en todo lo que acaba de leer.

Los documentos se truncan

Google cuenta el número de tokens y la relación entre el total de palabras del cuerpo y el número de tokens únicos. Los documentos indican que existe un número máximo de tokens que se pueden tener en cuenta para un documento en concreto en el sistema Mustang, lo que refuerza la idea de que los autores deben seguir poniendo su contenido más importante al principio.

The image contains a snippet of technical documentation describing the attribute "numTokens." The text is as follows: numTokens Type: integer(), default: nil Description: The number of tokens, tags, and punctuations in the tokenized contents. This is an approximation of the number of tokens, tags, and punctuations we end up with in Mustang, but is inexact since we drop some tokens in Mustang and also truncate docs at a max cap. This attribute specifies the number of tokens, tags, and punctuations in the tokenized contents, providing an approximate count as some tokens are dropped and documents may be truncated in Mustang. The type is an integer with a default value of nil.

Los contenidos breves se puntúan por su originalidad

La OriginalContentScore sugiere que los contenidos breves se puntúan por su originalidad. Esta es probablemente la razón por la que el contenido escaso no siempre está en función de la longitud.

The image contains a snippet of technical documentation describing the attribute "OriginalContentScore." The text is as follows: OriginalContentScore Type: integer(), default: nil Description: The original content score is represented as a 7-bits, going from 0 to 127. Only pages with little content have this field. The actual original content score ranges from 0 to 512. It is encoded with quality_q2::OriginalContentUtil::EncodeOriginalContentScore(). To decode the value, use quality_q2::OriginalContentUtil::DecodeOriginalContentScore(). This attribute specifies the original content score of a page, represented as a 7-bit value ranging from 0 to 127, though the actual score ranges from 0 to 512. Only pages with little content have this field. Encoding and decoding of the score are handled by specific utility functions: EncodeOriginalContentScore() and DecodeOriginalContentScore(). The type is an integer with a default value of nil.

A la inversa, también existe una puntuación de relleno de palabras clave. 

Los títulos de las páginas siguen midiéndose en función de las consultas

La documentación indica que existe un titlematchScore. La descripción sugiere que Google sigue valorando la adecuación del título de la página a la consulta. 

The image displays a section from a technical documentation page. It includes the following elements and text: GoogleApi.ContentWarehouse.V1.Model.QualityNsrNsr Data NOTE: When adding a new field to be propagated to Raffia check if NsrPatternSignalSpec needs to be updated. Next ID: 63 Attributes ugcScore (type: number(), default: nil) - spambrainLavcScores (type: list(GoogleApi.ContentWarehouse.V1.Model.QualityNsrVersionedFloatSignal.t), default: nil) - titlematchScore (type: number(), default: nil) - Titlematch score of the site, a signal that tells how well titles are matching user queries.

Colocar sus palabras clave objetivo en primer lugar sigue siendo la jugada.

No hay medidas de recuento de caracteres

A su favor, Gary Ilyes ha dicho que los SEO se inventaron todo el recuento de caracteres óptimos para los metadatos. No hay ninguna métrica en este conjunto de datos que cuente la longitud de los títulos de las páginas o de los fragmentos. La única medida de recuento de caracteres que he encontrado en la documentación es el snippetPrefixCharCount que parece estar configurado para determinar lo que se puede utilizar como parte del snippet.

The image displays a section from a technical documentation page. It includes the following elements and text: snippetPrefixCharCount Type: integer(), default: nil Character counts of snippet prefix, if any. E.g. section heading, list summary, byline date.

Esto refuerza lo que hemos comprobado muchas veces: los títulos de página largos no son óptimos para generar clics, pero sí para mejorar la clasificación.

Las fechas son muy importantes

Google está muy centrado en los resultados frescos y los documentos ilustran sus numerosos intentos de asociar fechas a las páginas.

  • bylineDate – Es la fecha establecida explícitamente en la página.
The image displays a section from a technical documentation page. It includes the following elements and text: bylineDate Type: String.t, default: nil Document's byline date, if available: this is the date that will be shown in the snippets in web search results. It is stored as the number of seconds since epoch. See segindexer/compositedoc.proto
  • syntacticDate – Es una fecha extraída de la URL o en el título.
The image displays a section from a technical documentation page. It includes the following elements and text: syntacticDate Type: String.t, default: nil Document's syntactic date (e.g. date explicitly mentioned in the URL of the document or in the document title). It is stored as the number of seconds since epoch. See quality/timebased/syntacticdate/proto/syntactic-date.proto
  • emanticDate – Es la fecha derivada del contenido de la página.
The image displays a section from a technical documentation page. It includes the following elements and text: semanticDate Type: integer(), default: nil SemanticDate, estimated date of the content of a document based on the contents of the document (via parsing), anchors and related documents. Date is encoded as a 32-bits UNIX date (1970 Jan 1 epoch). Confidence is encoded using a SemanticDate specific format. For details of encoding, please refer to quality/freshness/docclassifier/semanticdate/public/semantic_date.proto

Lo mejor es especificar una fecha y ser coherente con ella en los datos estructurados, los títulos de página y los sitemaps XML. Poner fechas en su URL que entren en conflicto con las fechas en otros lugares de la página probablemente producirá un menor rendimiento del contenido.

La información de registro del dominio se almacena sobre las páginas

Ha sido una teoría conspirativa durante mucho tiempo que el estatus de Google como registrador alimenta el algoritmo. Podemos actualizar a un hecho conspirativo. Almacenan la información de registro más reciente a nivel de documento compuesto.

The image displays a section from a technical documentation page. It includes the following elements and text: RegistrationInfo Domain registration information for the document. NEXT ID TO USE: 3 createdDate Type: integer(), default: nil This is the number of days since January 1st, 1995 that this domain was last created. This should always fit in 15 bits. expiredDate Type: integer(), default: nil This is the number of days since January 1st, 1995 that this domain last expired. This should always fit in 15 bits. Jan 1st, 1995 was chosen by the history project as a special epoch date. Both the registration info dates and the linkage dates are measured in days since this epoch.

Como se ha comentado anteriormente, es probable que esto se utilice para informar sobre el aislamiento de nuevos contenidos. También puede utilizarse para bloquear un dominio previamente registrado que ha cambiado de propietario. Sospecho que el peso de esto se ha incrementado recientemente con la introducción de la política de spam de abuso de dominios expirados

Los sitios centrados en el vídeo reciben un trato diferente.

Si más del 50% de las páginas del sitio contienen vídeo, se considera que el sitio está centrado en el vídeo y recibirá un tratamiento diferente.

The image displays a section from a technical documentation page. It includes the following elements and text: isVideoFocusedSite Type: boolean(), default: nil Bit to determine whether the site has mostly video content, but is not hosted on any known video-hosting domains. Site is considered to be video-focused, if it has > 50% of the URLs with watch pages (with smoothing prior). ariane/4045246

Tu dinero, tu vida tiene una puntuación específica

La documentación indica que Google dispone de clasificadores que generan puntuaciones para YMYL Health y para YMYL News.

The image displays a section from a technical documentation page. It includes the following elements and text: ymylNewsScore Type: integer(), default: nil Stores scores of YMYL news classifier as defined at go/ymyl-classifier-dd. To use this field, you MUST join g/pq-classifiers-announce and add your use case at http://shortn/_nfg9oAldou.

También hacen una predicción de las “consultas marginales” o las que no se han visto antes para determinar si son YMYL o no.

The image displays a section from a technical documentation page. It includes the following elements and text: encodedChardXlqYmylPrediction Type: integer(), default: nil An encoding of the Chard XLQ-YMYL prediction in [0,1].

Por último, YMYL se basa en el nivel de trozos, lo que sugiere que todo el sistema se basa en incrustaciones.

The image displays a section from a technical documentation page. It includes the following elements and text: QualityNsrPQDataSubchunkData Data used to compute delta_subchunk_adjustment (i.e., the subchunks looked up, with their confidences and weights). This data is not propagated to ascorer. confidence Type: number(), default: nil Confidence associated with the chunk. deltaNsr Type: number(), default: nil Subchunk delta in nsr. pageWeight Type: number(), default: nil Weight with which this document belongs to this subchunk (greater than 0). type (highlighted in yellow) Type: String.t, default: nil Type of this chunk. Eg, ymyl_health, d2v, etc.

Existen documentos de referencia

No hay ninguna indicación de lo que esto significa, pero la descripción menciona “documentos etiquetados por humanos” frente a “anotaciones etiquetadas automáticamente”. Me pregunto si esto es una función de las calificaciones de calidad, pero Google dice que las calificaciones de calidad no afectan a las clasificaciones. Así que puede que nunca lo sepamos. 

The image displays a section from a technical documentation page. It includes the following elements and text: golden Type: boolean(), default: nil Flag for indicating that the document is a gold-standard document. This can be used for putting additional weight on human-labeled documents in contrast to automatically labeled annotations.

Los site embeddings se utilizan para medir la actualidad de una página.

Hablaré de las incrustaciones con más detalle en un post posterior, pero vale la pena señalar que Google está vectorizando específicamente páginas y sitios y comparando las incrustaciones de la página con las incrustaciones del sitio para ver lo fuera de tema que está la página.

The image displays a section from a technical documentation page. It includes the following elements and text: QualityAuthorityTopicEmbeddingsVersionedItem Proto populated into shards and copied to superroot. Message storing a versioned TopicEmbeddings scores. This is copied from TopicEmbeddings in docjoins. pageEmbedding Type: String.t, default: nil siteEmbedding (type: String.t, default: nil) - Compressed site/page embeddings. siteFocusScore Type: number(), default: nil Number denoting how much a site is focused on one topic. siteRadius Type: number(), default: nil The measure of how far page_embeddings deviate from the site_embedding. versionId Type: integer(), default: nil

La puntuación siteFocusScore refleja el grado en que el sitio se ciñe a un único tema. El radio del sitio mide hasta qué punto la página se sale del tema central basándose en los vectores site2vec generados para el sitio.

Google podría estar quemando páginas web pequeñas a propósito

Google tiene una bandera específica que indica si un sitio es un “pequeño sitio personal”. No existe una definición de este tipo de sitios, pero basándonos en todo lo que sabemos, no les resultaría difícil añadir un Twiddler que potenciara este tipo de sitios o uno que los degradara.

The image displays a section from a technical documentation page. It includes the following elements and text: smallPersonalSite Type: number(), default: nil Score of small personal site promotion go/promoting-personal-blogs-v1

Teniendo en cuenta la reacción y las pequeñas empresas que se han visto perjudicadas por la Actualización de Contenido Útil, es de extrañar que utilicen esta función para hacer algo al respecto.

MIS PREGUNTAS ABIERTAS

Podría seguir, y lo haré, pero es hora de un intermedio. Mientras tanto, sospecho que es inevitable que otros se metan en esta filtración y saquen sus propias conclusiones. De momento, tengo algunas preguntas abiertas que me encantaría que todos nos planteáramos.

¿Es la actualización de contenidos útiles conocida como Baby Panda?

Hay dos referencias a algo llamado “baby panda” en las Señales de Calidad Comprimidas. Baby Panda es un Twiddler que consiste en un ajuste posterior a la clasificación inicial.

The image displays a section from a technical documentation page. It includes the following elements and text: babyPandaDemotion Type: integer(), default: nil baby_panda_demotion: converted from QualityBoost.rendered.boost.

Se menciona que funciona sobre Panda, pero no hay más información en la documentación.

The image displays a section from a technical documentation page. It includes the following elements and text: babyPandaV2Demotion Type: integer(), default: nil New BabyPanda demotion, applied on top of Panda. This is meant to replace |baby_panda_demotion|.

Creo que en general estamos de acuerdo en que la Actualización de Contenido Útil tiene muchos de los mismos comportamientos de Panda. Si se construye sobre un sistema que utiliza consultas de referencia, enlaces y clics esas son las cosas en las que tendrás que centrarte después de mejorar tu contenido.

¿NRS significa Recuperación Semántica Neuronal?

Hay un montón de referencias a módulos y atributos con NSR como parte de la convención de nomenclatura. Muchos de ellos están relacionados con fragmentos de sitios e incrustaciones. Google ya ha hablado anteriormente de “Neural Matching” como uno de los principales objetivos de mejora. Mi conjetura es que NSR significa Neural Semantic Retrieval (recuperación semántica neuronal) y que todas estas funciones están relacionadas con la búsqueda semántica. Sin embargo, en algunos casos mencionan junto a un “site rank”.

Me encantaría que algún Googler rebelde se dirigiera a go/NSR y me enviara un “tienes razón” desde una dirección de correo electrónico anónima o algo así. 

MIS RECOMENDACIONES

Como he dicho, no tengo recetas para ti. Sin embargo, tengo algunos consejos estratégicos.

  1. Envía una disculpa a Rand Fishkin – Desde mi keynote “Todo sobre lo que Google nos mintió” en PubCon, he estado en una campaña para limpiar el nombre de Rand en lo que se refiere a NavBoost. Rand hizo un trabajo ingrato tratando de ayudar a nuestra industria a elevarse durante años. Recibió muchas críticas por parte de Google y del SEO. A veces no hacía las cosas bien, pero su corazón siempre estaba en el lugar correcto y se esforzaba por hacer que lo que hacemos sea respetado y simplemente mejor. En concreto, no se equivocó en las conclusiones de sus experimentos de clics, en sus repetidos intentos de demostrar la existencia de un Google Sandbox, en sus estudios de casos que demuestran que Google clasifica los subdominios de forma diferente y en su creencia, largamente cuestionada, de que Google emplea señales de autoridad en todo el sitio. También hay que darle las gracias por este análisis, ya que fue él quien compartió la documentación conmigo. Ahora es un buen momento para que muchos de vosotros le mostréis vuestro cariño en Threads.
  2. Haz un gran contenido y promociónalo bien – Estoy bromeando, pero también hablo en serio. Google ha seguido dando ese consejo y nosotros lo rechazamos como no procesable. Para algunos SEO está fuera de su control. Después de revisar estas características que dan a Google sus ventajas, es bastante obvio que hacer mejor contenido y promoverlo a audiencias con las que resuene producirá el mejor impacto en esas medidas. Las medidas de las características de los enlaces y el contenido sin duda te llevarán bastante lejos, pero si realmente quieres ganar en Google a largo plazo, vas a tener que hacer cosas que sigan mereciendo clasificar.
  3. Traer de vuelta los estudios de correlación – Ahora tenemos una comprensión mucho mejor de muchas de las características que Google está utilizando para construir clasificaciones. A través de una combinación de datos de flujo de clics y extracción de características, podemos replicar más de lo que podíamos antes. Creo que ha llegado el momento de recuperar los estudios de correlación verticales específicos.
  4. Prueba y aprende – Deberías haber visto suficientes gráficos de visibilidad y tráfico con ejes Y para saber que no puedes confiar en nada de lo que leas o escuches en SEO. Esta filtración es otro indicio de que debe tomar las entradas y experimentar con ellas para ver qué funcionará para su sitio web. No basta con mirar las reseñas anecdóticas de las cosas y asumir que así es como funciona Google. Si su organización no tiene un plan de experimentación para SEO, ahora es un buen momento para empezar uno.

SABEMOS LO QUE HACEMOS

Una cosa importante que todos podemos sacar de esto es: Los SEO saben lo que hacen. Después de años de que nos digan que estamos equivocados es bueno ver detrás de la cortina y descubrir que hemos tenido razón todo el tiempo. Y, aunque hay matices interesantes de cómo funciona Google en estos documentos, no hay nada que vaya a hacer que cambie drásticamente el rumbo de mi estrategia SEO. 

Para aquellos que profundizan, estos documentos servirán principalmente para validar lo que los SEOs experimentados han defendido durante mucho tiempo. Entender a su público, identificar lo que quieren, hacer lo mejor posible que se alinee con eso, hacerlo técnicamente accesible, y promoverlo hasta que se clasifique.

A todos los SEO que no estén seguros de lo que hacen: sigan probando, sigan aprendiendo y sigan haciendo crecer sus negocios. Google no puede hacer lo que hace sin nosotros.

DESCARGAR LAS CLASIFICACIONES

Bueno, alguien va a descargar y organizar todas las características en una hoja de cálculo para ti. También podría ser yo. Sólo nos queda un mes en el trimestre y quiero conseguir nuestros MQL de todos modos. 

Hazte con tu copia de la lista de características de la clasificación.

ACABAMOS DE EMPEZAR

Lo que siempre me ha gustado del SEO es que es un rompecabezas en constante evolución. Y aunque ayudar a las marcas a ganar miles de millones de dólares con nuestros esfuerzos es divertido, hay algo muy satisfactorio en alimentar mi curiosidad con todas las pesquisas relacionadas con descifrar cómo funciona Google. Ha sido una gran alegría poder ver por fin detrás del telón.

Esto es todo lo que tengo por ahora, pero ¡hacedme saber lo que encontráis! Cualquiera que quiera compartir algo conmigo puede hacerlo. Soy muy fácil de encontrar.

Palabras de DesignSEO

Este artículo ha sido traducido directamente por DesignSEO Group desde IpullRank, el artículo original de Mike King, es el siguiente que puedes consultar aquí.

Si encuentras un error háznoslo saber para corregir.

Agradecemos a Mike King que es el fundador y CEO de iPullRank. Profundamente técnico y altamente creativo, Mike ha ayudado a generar más de 2.000 millones de dólares en ingresos para sus clientes. Rapero y hombre de agencia en recuperación.  Un tremendo artículo que traemos al español para que los SEO del mundo de LATAM tomen más riesgos para mejorar su batalla contra La Gran G.

Otros Recomendamos
Otros Recomendados de Lectura