Metehan Yeşilyurt SEO experto:»Desvela las 9 fases del algoritmo de Google Discover»

Hoy os dejamos un artículo SEO que debes leer. Metehan Yeşilyurt SEO experto:»Desvela las 9 fases del algoritmo de Google Discover» Indispensable para entender como funcia uno de los algoritmos que más guerra nos dan a los SEO.

Metehan Yeşilyurt  realizó una investigación excelente en Google Discover. Si te interesa el tráfico de Discover, deberías leer los enlaces al final.

Para una infografía de alta resolución: https://lnkd.in/e-nXmVgv 

𝟗 𝐭𝐡𝐢𝐧𝐠𝐬 𝐈 𝐥𝐞𝐚𝐫𝐧𝐞𝐝 𝐚𝐛𝐨𝐮𝐭 𝐆𝐨𝐨𝐠𝐥𝐞 𝐃𝐢𝐬𝐜𝐨𝐯𝐞𝐫 (𝐟𝐫𝐨𝐦 𝐌𝐞𝐭𝐞𝐡𝐚𝐧’𝐬 𝐒𝐃𝐊 𝐭𝐞𝐥𝐞𝐦𝐞𝐭𝐫𝐲 𝐫𝐞𝐬𝐞𝐚𝐫𝐜𝐡)

𝟏. 𝐃𝐢𝐬𝐜𝐨𝐯𝐞𝐫 𝐡𝐚𝐬 𝐚 𝐛𝐢𝐧𝐚𝐫𝐲 “𝐜𝐨𝐥𝐥𝐞𝐜𝐭𝐢𝐨𝐧 𝐠𝐚𝐭𝐞”

Antes de cualquier coincidencia o clasificación de intereses, hay un interruptor de encendido/apagado: si la colección está oculta, estás fuera. Ningún título que diga «esfuérzate más» solucionará eso.

𝟐. 𝐎𝐆 𝐭𝐚𝐠𝐬 𝐚𝐫𝐞 𝐧𝐨𝐭 “𝐬𝐨𝐜𝐢𝐚𝐥 𝐦𝐞𝐭𝐚”, 𝐭𝐡𝐞𝐲’𝐫𝐞 𝐟𝐞𝐞𝐝 𝐦𝐞𝐭𝐚

El SDK analiza un conjunto estricto de etiquetas. Si tu imagen o título OG se rompe, tu tarjeta Discover puede romperse con él.

¿Tienes og:title? Prueba con el título de Twitter y luego con el título HTML.¿No tienes og:image? Prueba con la URL segura, la imagen de Twitter y más.Esto es «lógica de renderizado», no teoría SEO.

3. Clasificación de contenido

Clasifica el contenido en actualizado o contenido evergreeen

𝟒.𝐄𝐧𝐭𝐢𝐭𝐢𝐞𝐬 𝐚𝐫𝐞 𝐭𝐡𝐞 𝐦𝐚𝐭𝐜𝐡𝐦𝐚𝐤𝐞𝐫

se asigna a los ID del Gráfico de Conocimiento y luego se relaciona con el gráfico de intereses del usuario. Por eso los titulares vagos tienen problemas: no le dan al sistema nada con qué comparar.

𝟓. 𝐑𝐚𝐧𝐤𝐢𝐧𝐠 𝐢𝐬 𝐩𝐂𝐓𝐑, 𝐛𝐮𝐭 𝐭𝐡𝐞 𝐦𝐨𝐝𝐞𝐥 𝐢𝐬 𝐬𝐞𝐫𝐯𝐞𝐫-𝐬𝐢𝐝𝐞

El cliente puede dar pistas sobre las señales (frescura, calidad de la imagen, participación histórica), pero la puntuación real ocurre del lado de Google.

𝟔. 𝐅𝐫𝐞𝐬𝐡𝐧𝐞𝐬𝐬 𝐡𝐚𝐬 𝐛𝐮𝐜𝐤𝐞𝐭𝐬, 𝐢𝐭’𝐬 𝐧𝐨𝐭 𝐣𝐮𝐬𝐭 “𝐟𝐞𝐞𝐥𝐬 𝐟𝐫𝐞𝐬𝐡”

Hay ventanas de tiempo explícitas. Después de la primera semana, estás luchando contra el deterioro a menos que tu contenido se trate como perenne.

𝟕. 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 𝐢𝐬 𝐚 𝐥𝐢𝐯𝐞 𝐬𝐭𝐫𝐞𝐚𝐦, 𝐧𝐨𝐭 𝐚 𝐬𝐭𝐚𝐭𝐢𝐜𝐚 𝐥𝐢𝐬𝐭

Entre la transmisión, la sincronización en segundo plano, el envío de balizas y el almacenamiento en caché, su tarjeta puede aparecer, moverse o desaparecer sin una «actualización».

𝟖. 𝐔𝐬𝐞𝐫 𝐟𝐞𝐞𝐝𝐛𝐚𝐜𝐢𝐨 𝐞𝐬 𝐚𝐥𝐢𝐬𝐭𝐨 𝐝𝐞 𝐟𝐢𝐫𝐬𝐭𝐭𝐨 𝐜𝐥𝐚𝐬𝐭𝐨𝐬 𝐬𝐢𝐠𝐧𝐚𝐥𝐞𝐬 𝐝𝐞 𝐥𝐚𝐬 𝐜𝐨𝐦𝐩𝐚𝐫𝐚 ….

Los despidos, los seguidores, los guardados y el tiempo de interacción alimentan el ciclo. Discover aprende constantemente lo que cada usuario quiere y lo que no.

𝟗. 𝐓𝐡𝐢𝐬 𝐦𝐞𝐚𝐧𝐬 “𝐃𝐢𝐬𝐜𝐨𝐯𝐞𝐫 𝐝𝐫𝐨𝐩𝐬” 𝐧𝐞𝐞𝐝 𝐚 𝐧𝐞𝐰 𝐝𝐢𝐚𝐠𝐧𝐨𝐬𝐢𝐬

No todas las caídas son “clasificación”. A veces es:

• un problema de renderizado (OG/imagen)

• un problema de puerta/filtro (colección)

• o volatilidad normal del experimento

El gráfico a continuación es mi intenta de hacer que este pipeline sea visual para los editores, basado en el análisis de Metehan. Puedes leer los artículos completos en:> https://lnkd.in/eXzuwNw9 > https://lnkd.in/ebhtTS3n > https://lnkd.in/e_tvr8H5

pero lo dejamos aquí traducido para que como buen SEO puedas sacar las conclusiones para tu medio

Google Discover ofrece contenido a cientos de millones de usuarios a diario, pero su funcionamiento interno sigue siendo en gran medida opaco. La mayoría de las recomendaciones de SEO sobre Discover provienen de la propia documentación de Google o de observaciones puntuales de los editores. En esta publicación, quiero compartir una perspectiva diferente: lo que podemos aprender al examinar la telemetría observable, las convenciones de nomenclatura de eventos y el estado del cliente de la aplicación de Google.

Todo lo descrito a continuación refleja lo que el código del lado del cliente revela en un momento específico y ha sacado Metehan Yeşilyurt. Esto es Google. Pueden cambiar cualquiera de estos sistemas (señales de clasificación, etapas del pipeline, contadores de telemetría y marcadores de características) en el servidor en cualquier momento, sin necesidad de actualizar al cliente. Lo que lee aquí es una instantánea, no un modelo definitivo. Considérelo como una perspectiva de cómo funcionan estos sistemas hoy, no como una garantía de cómo funcionarán mañana.

Cuando algo es una inferencia en lugar de una observación directa, lo digo. Necesitaba manejar una gran cantidad de datos y eliminé muchas partes.

Piense en esto como leer la etiqueta nutricional de un alimento envasado. No se puede ver la fábrica, pero la etiqueta revela bastante información sobre su contenido.

El canal de contenido#

El flujo de contenido de Discover  https://metehan.ai/blog/google-discover-architecture/#the-content-pipeline se puede asignar a varias etapas observables, cada una de las cuales deja rastros de telemetría distintos:

1. Ingesta de contenido: Google rastrea e indexa el contenido. La extracción de entidades asigna MIDs del Gráfico de Conocimiento ( /m/xxxxx) o ( /g/xxxxx) a los temas reconocidos.
2. Análisis de datos estructurados y Open Graph: El analizador del lado del cliente extrae los metadatos de la página con un orden de prioridad definido: primero se verifica JSON-LD de Schema.org , luego las etiquetas Open Graph, luego las etiquetas de Twitter Card y finalmente las metaetiquetas HTML genéricas. Esta es una cadena de respaldo codificada, no una preferencia. Si JSON-LD contiene el campo, nunca se accede a las etiquetas OG para ese campo.
3. Clasificación de contenido: el contenido se asigna a tipos de clúster y se clasifica para la jerarquía de feeds.
4. Filtrado de contenido : El sistema opera con dos niveles de filtrado independientes: filter_collection_status(nivel de editor/dominio) y filter_entity_status(nivel de URL única). Estos se registran como métricas de streaming específicas de Discover en /client_streamz/android_gsa/discover/app_content/.
5. Coincidencia de intereses del usuario: los MID de entidades de contenido se comparan con el perfil de intereses del usuario a través del sistema de personalización NAIADES (subtipos verificados a continuación).
6. Clasificación (del lado del servidor): La clasificación se realiza del lado del servidor. El código del lado del cliente revela qué datos se empaquetan y se envían al servidor, pero los modelos de clasificación reales no son observables desde el cliente.
7. Ensamblaje de feeds: el contenido se organiza y se envía al dispositivo a través de transmisión gRPC, sincronización de WorkManager en segundo plano, envío de balizas o caché.
8. Bucle de retroalimentación: Las interacciones del usuario (descartes, seguimientos, guardados) retroalimentan la personalización. El contenido descartado se elimina permanentemente.

Lo destacable aquí es el orden . El filtro a nivel de colección se ejecuta antes de la coincidencia de intereses y la clasificación. Esto significa que un editor bloqueado a nivel de colección ni siquiera llega a la etapa de clasificación, independientemente de la relevancia de su contenido para un usuario.

Datos estructurados y Open Graph: qué analiza realmente el código#

Los editores a menudo se preguntan qué metaetiquetas utiliza realmente Discover. La clase analizadora descompilada ( dkpg.java, autodenominada SchemaOrg{parsedMetatags, jsonLdScripts}) revela las etiquetas exactas y su orden de prioridad.

El hallazgo crítico: Los datos estructurados JSON-LD de Schema.org se verifican primero para el título, el autor y la editorial, no para las etiquetas Open Graph. Las etiquetas OG son la alternativa. Esto está codificado en la lógica de la cadena de respaldo.

Cadenas de respaldo verificadas (desde java files)#

Título:

1. Datos estructurados de Schema.org ( TEXT_TYPE_TITLE)
2. og:title(vía propertyatributo)
3. twitter:title(vía nameatributo)
4. title(atributo genérico name)

Autor:

1. Datos estructurados de Schema.org ( TEXT_TYPE_AUTHOR)
2. author(vía nameatributo)

Editor:

1. Datos estructurados de Schema.org ( TEXT_TYPE_PUBLISHER)
2. og:site_name(vía propertyatributo)

Imagen:

1. og:image(vía propertyatributo)
2. twitter:image(vía nameatributo)
3. og:image:secure_url(vía propertyatributo)
4. twitter:image:src(vía nameatributo)
5. image(atributo genérico name)

Idioma:

1. Detección del idioma principal (basada en la ejecución)
2. og:locale(vía propertyatributo)
3. inLanguage(JSON-LD de Schema.org)
4. Respaldo codificado de forma rígida "en"(condicional en la bandera de configuración del servidor)

Clasificación de muros de pago (de dkri.java:173-176, dkqd.java)#

El sistema verifica el estado del muro de pago en este orden exacto:

1. Primero: isAccessibleForFree(Schema.org JSON-LD booleano) — valor predeterminado truesi está ausente
2. Entonces: article:content_tierlos valores reconocidos son exactamente tres cadenas:
   • "free"el valor predeterminado esperado
   • "metered"contabilizado como de pago
   • "locked"contabilizado como de pago

article:content_tierSi se encuentran varios valores en la misma página, el código registra una advertencia "More than one content tier found"(código de evento 38468). Use solo un valor.

Bloqueo de metaetiquetas (desde dkri.java:304-416)#

Dos metaetiquetas detienen el proceso por completo con una excepción ( dkma):

• nopagereadalouddesencadenantesDISALLOWED_FOR_READOUT
• notranslatedesencadenantesDISALLOWED_FOR_TRANSLATION

Cuando se detecta como metaetiqueta, el sistema genera un error y detiene el procesamiento de esa página. Si su CMS o plugin de traducción la inyecta notranslatecomo metaetiqueta, es posible que su contenido no entre en este proceso de análisis.

Reescritura de JSON/OG en acción#

Ahora veamos en Discover a continuación.

Y este es el enlace de la imagen: https://www.donanimhaber.com/images/images/haber/202436/src_340x1912xtaalas-yapay-zek-ciplerinde-devrim-yaratabilir.jpg

Este enlace JPG se coloca solo en las etiquetas og:image y twitter:image, no en schema.org (¿Está comprobado? No, la otra imagen tiene 1400x788px de ancho en la etiqueta schema, es Google, puedes decidirlo).

Filtrado de contenido: la arquitectura de dos niveles#

El filtrado de contenido de Discover opera en múltiples niveles, cada uno rastreado por su propia métrica streamz específica de Discover, las identificadas se encuentran a continuación:

• Nivel de colección ( /client_streamz/android_gsa/discover/app_content/filter_collection_status): bloquea el contenido de un editor o dominio. Parametrizado por reason.
• Nivel de entidad ( /client_streamz/android_gsa/discover/app_content/filter_entity_status): bloquea una única URL. Parametrizado por reason.

Cuando un usuario selecciona «No mostrar contenido de [Editorial]» en el menú de tarjetas, se activa el filtro a nivel de colección. Un solo artículo que genera suficientes comentarios negativos puede suprimir una publicación completa. Esta acción se aplica a todo el contenido de ese dominio, no solo al artículo que la activó. El algoritmo de supresión puede ampliar el filtro a nivel de editorial.

Advertencia importante: Estos son contadores de telemetría del lado del cliente. Confirman la existencia y el seguimiento de los mecanismos de filtrado, pero los umbrales exactos del servidor, los mecanismos de recuperación y cómo los valores de «razón» se asignan a las acciones del usuario no son observables desde el cliente. Google puede cambiar estas configuraciones en cualquier momento sin necesidad de actualizar el cliente.

Lápida de contenido (de bska.java)#

El contenido descartado se registra permanentemente con un tombstonedcampo booleano en el objeto de estado del contenido. El estado del contenido también registra stallState( lastKnownStateINSERTO/ELIMINADO/DESCONOCIDO) y purged, creando un registro completo del ciclo de vida. El contenido descartado no reaparece.

El sistema de personalización NAIADES (desde fiqc.java)#

El código revela un sistema de personalización llamado NAIADES con múltiples subtipos de contenido, todos confirmados como valores de enumeración:

WPAS(Señal de artículos de editores web) probablemente corresponde al registro en el Centro de editores de Google Noticias, lo que significa que el contenido de los editores registrados recibe una clasificación distinta en el proceso de personalización. RECALL_BOOSTEsto puede sugerir una mayor prioridad de recuperación del grupo de candidatos, lo que mejora el contenido durante la recuperación, antes de la clasificación. (No podemos ver la configuración del servidor, por favor, preste atención).

Advertencia: Estos son nombres de enumeración en un sistema de clasificación de subtipos de contenido. Confirman la existencia de las categorías, pero la importancia de cada subtipo en la clasificación es una decisión del servidor que no podemos observar.

Supresión y experimentos contrafácticos#

Discover ejecuta experimentos contrafácticos. El código confirma:

• SHOW_SKIPPED_DUE_TO_COUNTERFACTUAL(de fevu.java, valor de enumeración 16) — contenido retenido para pruebas A/B
• VISIBILITY_REPRESSED_COUNTERFACTUAL(de eyxv.java) — un estado de registro de elementos visuales utilizado en toda la aplicación de Google (no específico de Discover) que marca los elementos suprimidos deliberadamente para la medición del experimento
• background_refresh_rug_pull_count(de bupa.java, bajo /client_streamz/android_gsa/discover/) un contador específico de Discover que rastrea casos en los que el contenido se envió al feed y luego se eliminó durante una actualización en segundo plano. 100% verificado

El contador de «retiradas de alfombra» es especialmente destacable. Registra los casos en los que se envió contenido al feed y luego se eliminó retroactivamente. Esto significa que Discover puede retirar contenido que ya estaba en el feed, no solo filtrarlo antes de mostrarlo.

El sistema Beacon Push#

La mayor parte del contenido de Discover llega mediante solicitudes de feed basadas en pull, pero también existe un canal push. El sistema Beacon permite que los servidores de Google envíen contenido de forma proactiva al dispositivo del usuario.

A partir del código descompilado ( bqmt.java), Beacon actualmente maneja exactamente dos tipos de contenido :

• Resultados deportivos ( SportsScoreAmbientDataDocument) ordinal 0
• Resumen de inversiones/finanzas ( InvestmentRecapAmbientDataDocument) ordinal 1
• Cualquier otra cosa se desencadena "Unsupported BeaconContent type: %s"y se rechaza.

Beacon tiene sus propias métricas (desde bupa.java):

/client_streamz/android_gsa/discover/beacon/incoming_sports_notifications_count
/client_streamz/android_gsa/discover/beacon/donated_sports_documents_count
/client_streamz/android_gsa/discover/beacon/dropped_sports_notifications_count
/client_streamz/android_gsa/discover/beacon/appsearch_cleared_count

El contenido deportivo cuenta con más de 10 tipos de notificaciones dedicadas (desde fkld.java): SPORTS_AWARENESS_NOTIF, SPORTS_GAME_CRICKET_MILESTONE_NOTIF, SPORTS_BREAKING_NEWS_NOTIF, SPORTS_LIVE_ACTIVITY_NOTIF, SPORTS_PREGAME_ANALYSIS_AIM_NOTIF, SPORTS_LEAGUE_INSIGHTS_AIM_NOTIF, SPORTS_STANDINGS_NOTIF, y más. Las noticias generales de última hora solo tienen una: BREAKING_NEWS_NOTIF. La inversión estructural en infraestructura de notificaciones deportivas es significativamente mayor. Es posible que comparta una infraestructura muy similar con Google Noticias. // Esta sección parece dinámica, por lo que puede cambiar en cualquier momento.

Intervalos de frescura#

El código contiene una lógica de clasificación basada en el tiempo (de bemp.java:215):

days < 1  → "0_DAYS"
days < 8  → "1_TO_7_DAYS"
days < 15 → "8_TO_14_DAYS"
days < 31 → "15_TO_30_DAYS"
days < 61 → "31_TO_60_DAYS"
days >= 61 → "TAIL"

Corrección importante: En el código descompilado, esta lógica de clasificación aparece en un contexto de configuración de gestos ( GestureSettingsPreferenceFragment), no en una clase específica de Discover. Los nombres de los depósitos y los intervalos de tiempo se confirman como cadenas exactas, pero su conexión directa con la puntuación de frescura del contenido de Discover no se puede verificar únicamente desde el cliente. El patrón de clasificación es coherente con la forma en que Google suele gestionar la antigüedad del contenido, pero no puedo demostrar que estos depósitos específicos se utilicen para la clasificación del feed de Discover.

13 tipos de clústeres#

Cada tarjeta del feed de Discover pertenece a un clúster. Se pueden observar los siguientes nombres de tipo de clúster:

• neoncluster el grupo de contenido principal
• geotargetingstories historias basadas en la ubicación
• deeptrendsy deeptrendsfable narrativas de temas de tendencia
• freshvideoscontenido de vídeo reciente
• mustntmiss contenido prioritario/de lectura obligada
• newsstoriesheadlinesnoticias de última hora
• homestackTarjetas de widgets (clima, resultados deportivos)
• garamondrelatedarticlegroupinggrupos de artículos relacionados
• trendingugc contenido de tendencia generado por el usuario
• signinlure indicaciones de inicio de sesión
• iospromo promoción multiplataforma
• moonstone un clúster con nombre de código interno

mustntmisssugiere que hay una cola prioritaria de contenido que el sistema considera esencial mostrar. garamondrelatedarticlegroupingIndica que el sistema puede crear agrupaciones de artículos relacionados (combinando artículos separados bajo un encabezado de tema compartido).

Entrega de feeds en tiempo real#

Discover no se limita a obtener una lista estática de tarjetas. El código revela una arquitectura de conexión gRPC persistente con puntos finales de servicio distintos (verificado desde [Aquí falta información ehdf.java]):

• google.internal.discover.discofeed.feedrenderer.v1.DiscoverFeedRenderer alimentación estándar con QueryInteractiveFeedyQueryNextPage
• google.internal.discover.discofeed.streamingfeedrenderer.v1.DiscoverStreamingFeedRenderer variante de streaming conQueryStreamingFeed
• google.internal.discover.discofeed.actions.v1.DiscoverActions UploadActionsyBackgroundUploadActions
• google.internal.discover.discofeed.reactions.v1.DiscoverReactions ListReactions
• google.internal.discover.discofeed.recommendations.v1.StoryRecommendations
• google.internal.discover.discofeed.homestack.v1.DiscoverHomestackFeedRenderer

Lo que esto significa para los editores: su contenido no espera a que el usuario lo actualice. El renderizador del feed de streaming mantiene una conexión en vivo. El servidor puede inyectar nuevas tarjetas, reordenar las existentes o eliminar contenido obsoleto a mitad de la sesión. El feed es una transmisión en vivo, no una instantánea.

¿Qué significa esto para los editores o SEO de lo smedios#

Permítanme aclarar qué es y qué no es este análisis. Se trata de un conjunto de observaciones sobre cómo se instrumentan los sistemas del lado del cliente de la aplicación de Google. No se trata de ingeniería inversa de los algoritmos de clasificación del lado del servidor, que permanecen en los servidores de Google y no son directamente observables.

Dicho esto, surgen algunas observaciones prácticas:

• JSON-LD de Schema.org tiene prioridad sobre las etiquetas OG. El analizador analiza primero los datos estructurados para identificar el título, el autor y la editorial. Las etiquetas OG son la alternativa. Si solo implementa og:tags sin marcado JSON-LD, se basa en la segunda opción.
• Las imágenes son esenciales. La cadena de imágenes de respaldo tiene cinco niveles de profundidad: el sistema se esfuerza por encontrar una imagen. Usa imágenes de al menos 1200 píxeles de ancho para que la tarjeta de héroe sea válida.
• og:titleSe empaqueta y se envía a los servidores de Google como parte de la carga útil ContentMetadata. Es plausible que se trate de una entrada de clasificación directa, pero no se ha confirmado únicamente mediante la observación del lado del cliente. En cualquier caso, forma parte de los datos que fundamentan las decisiones del lado del servidor.
• El bloqueo a nivel de colección se registra como una métrica independiente. El filter_collection_statuscontador confirma la existencia de este mecanismo a nivel de editor/dominio. Sin embargo, solo podemos observar el contador de telemetría, no los umbrales del servidor ni los mecanismos de recuperación. Google puede modificarlos en cualquier momento.
• El registro en el Centro de Publicaciones genera una señal distintiva. El WPASsubtipo (Señal de Artículos de Publicaciones Web) implica que las publicaciones registradas reciben un tratamiento de clasificación diferente en el sistema de personalización NAIADES.
• article:content_tierImporta. El analizador reconoce explícitamente free, meteredy locked. Use solo un valor; varios valores activan una advertencia.
• notranslateLas nopagereadaloudmetaetiquetas pueden detener el proceso de análisis. Si tu CMS las inyecta, debes realizar experimentos y filtrar el tráfico de Discover.
• Los despidos de usuarios son permanentes. El contenido se elimina y no vuelve a aparecer.
• Los editores deportivos tienen una ventaja estructural en el flujo de notificaciones push. Más de 10 tipos de notificaciones dedicados frente a uno para noticias generales de última hora. El cliente confirma que no podemos ver la configuración del servidor.

MIS correcciones y advertencias#

Durante la verificación de datos, varios elementos requirieron corrección:

Nota metodológica#

Todos los hallazgos de Metehan Yeşilyurt  han generado este análisis se derivan de la descompilación de 87,498 clases de Google App en 13 archivos DEX. De estas, el 95.5% estaban ofuscadas bajo un paquete p000/sin archivo de mapeo de ProGuard disponible.

La desofuscación se realizó mediante análisis de literales de cadena, rastreo de jerarquía de clases, extracción de endpoints de gRPC y reconstrucción de grafos mediante inyección de dependencias de Hilt. Cuando los hallazgos se confirman mediante coincidencias exactas de cadenas en el código fuente descompilado, se etiquetan como verificados. Cuando los hallazgos son inferencias basadas en convenciones de nomenclatura o proximidad de código, se indica.

No se accedió a los sistemas del servidor. Los modelos de clasificación del servidor, la asignación de experimentos y las etapas del pipeline pueden cambiar independientemente del cliente. Lo que podemos observar es la instrumentación; las preguntas que formula el sistema y las respuestas que registra, que revelan la arquitectura incluso cuando los parámetros cambian por debajo.

Infografía Metehan Yeşilyurt SEO experto:»Desvela las 9 fases del algoritmo de Google Discover»

Infografía Metehan Yeşilyurt SEO experto:»Desvela las 9 fases del algoritmo de Google Discover»

 

Fuentes

https://metehan.ai/blog/google-discover-architecture/

https://metehanai.substack.com/p/i-read-google-discovers-sdk-so-you

https://www.linkedin.com/posts/metehanyesilyurt_everyone-talks-about-google-discover-like-activity-7432098726967529472-rGSB/

. Leer artículo completo en Frikipandi Metehan Yeşilyurt SEO experto:»Desvela las 9 fases del algoritmo de Google Discover».