Google abre el UGC Fresh Data Program: foros y redes aprobadas le envían sus posts y contadores sin pasar por el rastreo

Si te gusta mi contenido, dile a Google que te lo muestre antes:

Google documentó el 8 de octubre de 2026 el UGC Fresh Data Program, una tubería de ingesta por la que las plataformas de contenido de usuario aprobadas le envían sus posts y sus contadores de interacción directamente, al margen del rastreo y de la Indexing API. Exige URLs estables, contenido público atribuido a un creador con perfil público, OAuth 2.0, JSON-LD con interactionStatistic y envíos «en minutos». Se solicita por formulario, Google responde en 6-8 semanas y no garantiza que el contenido aparezca en los resultados.

Una tubería de ingesta aparte del rastreo y de la Indexing API

Google publicó el 8 de octubre de 2026 la página «About the UGC Fresh Data Program» en la documentación de Search Central, y la anotó en el changelog como única entrada del día. Según Google, es «an initiative designed to help platforms display fresh, high quality, and authentic user-generated content (UGC) across various features on Search». Las plataformas aprobadas pueden usar una tubería de ingesta dedicada para enviarle contenido y señales de interacción, de forma que, en palabras de la página, el contenido fresco se procese y se actualice rápido en el buscador.

Lo que lo separa de las vías conocidas lo dice la propia documentación. Es «a specialized pipeline designed exclusively for trending UGC content», independiente de la Indexing API y del rastreo orgánico tradicional del contenido web general. Y una frase va aparte, en su propia nota: «This program doesn't guarantee that content will appear in Search». Google define el UGC como cualquier material digital alojado y distribuido por una plataforma o un agregador, pero creado por completo por usuarios independientes y no por la plataforma.

Barry Schwartz lo resume en Search Engine Roundtable como una API con la que sitios de contenido de usuario, y pone el ejemplo de Reddit, pueden empujar su contenido a Google más rápido, sin esperar al rastreo. La documentación no nombra a ninguna plataforma, ni las que ya participan ni las que podrían hacerlo, y tampoco dice desde cuándo existe el programa, solo desde cuándo está documentado.

Los seis requisitos: URLs estables, perfil público y marcado con interactionStatistic

Google dice que la participación está limitada a plataformas que cumplan «specific content quality and volume guidelines», y lista seis criterios. El primero es el foco del contenido: la plataforma tiene que alojar principalmente UGC, publicaciones sociales o debates de foro, y ese contenido tiene que estar en páginas dedicadas con URLs estables, no en perfiles ni en feeds. El segundo, volumen y audiencia, es una frase sin cifras: «un alto volumen de contenido de usuario y una base de usuarios significativa».

Captura de la sección Eligibility criteria de la documentación de Google del UGC Fresh Data Program, con los seis requisitos: content focus, volume and audience, content accessibility, technical readiness, content health and moderation y content freshness
Los seis criterios de elegibilidad tal y como los publica Google en Search Central. Fuente: Google, vía Search Engine Roundtable.

El tercero es la accesibilidad. El contenido tiene que estar en páginas públicas accesibles para Googlebot y para los usuarios, lo que deja fuera a lo que exige login o está tras un muro de pago, y además todo el UGC tiene que poder atribuirse a un creador con perfil público. El cuarto es el técnico: la plataforma tiene que poder implementar autenticación OAuth 2.0 y construir cargas JSON-LD «estrictamente validadas», y tiene que usar ya, o estar lista para usar, marcado schema.org en sus URLs. El ejemplo que da Google es SocialMediaPosting o DiscussionForumPosting con los subcampos de interactionStatistic, es decir, los contadores de interacción.

El quinto pide moderación activa, con un mecanismo para que los usuarios denuncien contenido, y nada de contenido ilegal. El sexto es el que marca el ritmo del programa: el contenido enviado tiene que ser lo más fresco posible, «ideally sent within minutes», y la plataforma tiene que poder enviar actualizaciones periódicas de los contadores de interacción en las 72 horas siguientes a la creación. La especificación del payload no es pública: «compartiremos documentos para desarrolladores con más detalles una vez aceptados en el programa».

Cómo se solicita: un formulario, entre 6 y 8 semanas de espera y documentación solo si te aceptan

La solicitud es un formulario de Google al que se llega desde la documentación. Google avisa de que enviarlo no garantiza la participación y de que responderá en un plazo de 6 a 8 semanas; solo las plataformas seleccionadas reciben la documentación técnica y las instrucciones de integración. Según PPC Land, que ha revisado el formulario, tiene ocho campos y siete son obligatorios: nombre de la empresa, dominio del servicio, diez URLs de ejemplo con contenido de usuario, usuarios activos mensuales, fecha de lanzamiento, el email del propietario de la propiedad en Search Console y un email de contacto. El único opcional son los comentarios.

El texto del formulario es más crudo que el de la documentación. Dice que la solicitud «is merely an expression of interest, and Google has no obligation to incorporate your content in our features», y que el mecanismo permite a Google conocer el contenido pero «we never guarantee serving as that is determined entirely by ranking algorithms». Es decir, el programa toca la velocidad con la que Google se entera, no el ranking. PPC Land señala además una inconsistencia: la documentación y el changelog hablan del «UGC Fresh Data Program» y la introducción del formulario lo llama «Google User Generated Content (UGC) Data Program», sin el «Fresh».

Lo que la documentación no dice: superficies, umbrales, informes y tiempos de proceso

Hay cuatro huecos que ni la página ni el formulario cierran. La documentación dice que el contenido se muestra «across various features on Search» y el formulario habla de «Google Search and other surfaces», pero ninguno de los dos nombra qué funciones ni qué otras superficies. Los umbrales de «alto volumen» y «base de usuarios significativa» no llevan número, aunque el formulario pida los usuarios activos mensuales. No se menciona ningún informe en Search Console para ver qué se ha enviado ni en qué estado está. Y el «en minutos» aplica solo al envío: Google no da ningún plazo para procesar lo que recibe.

Tampoco se sabe si las plataformas admitidas tendrán alguna ventaja en las respuestas de IA. La página no menciona AI Overviews ni AI Mode. Lo único que dice sobre dónde acaba el contenido es esa referencia genérica a funciones del buscador, y los criterios están pensados para dueños de plataformas, no para marcas ni para creadores. Una marca que publica en una plataforma admitida no solicita nada por su cuenta, y un medio cuyo contenido es sobre todo editorial no cumple el primer criterio tal y como está escrito.

De DiscussionForumPosting a la ingesta directa: por qué el marcado de foros importa ahora

Hasta ahora había dos formas de que una página llegara a Google. La normal es el rastreo (descubrimiento, fetch de Googlebot e indexación), y la otra es la Indexing API, que según su propia documentación solo sirve para páginas con JobPosting o con BroadcastEvent dentro de un VideoObject, con una cuota inicial de 200 peticiones. Sobre los tiempos del rastreo, lo más reciente son las cifras que Gary Illyes enseñó en Barcelona el 2 de octubre, unas 20 horas para descubrir una URL nueva, que salen de un recap de un asistente y que el propio Illyes matizó después como «un ejercicio» para ver si el público conectaba con los números. El programa nuevo es una tercera vía, para otro tipo de página y con otro reloj.

El marcado que Google pide como requisito tiene recorrido. DiscussionForumPosting y ProfilePage entraron en la documentación en noviembre de 2023, ligados a la función «Discussions and forums» de los resultados. El 24 de marzo de 2026 el changelog añadió más propiedades para foros y páginas de preguntas, con una justificación que ahora se lee distinto: «para dar más claridad sobre la estructura de los hilos de comentarios a los sistemas de ingesta de Google». Y el 24 de septiembre de este año Google añadió la propiedad creator y amplió los tipos de interactionStatistic admitidos en VideoObject. Que cada pieza tenga que atribuirse a un creador con perfil público encaja además con lo que Google añadió la semana pasada a su guía de contenido útil, que cuento en Google amplía su guía de contenido útil con el contenido principal, los criterios de los raters y un aviso contra los autores inventados.