Google elimina el formulario de aprobación de su API de indexación: Límites, cuotas y nueva operativa técnica

El fin del formulario manual: Google altera el acceso a su Indexing API sin aclarar las solicitudes pendientes

El ecosistema técnico de búsqueda experimentó un giro imprevisto el 16 de octubre, cuando Google retiró de manera discreta el formulario web y las instrucciones con las que los desarrolladores solicitaban aprobación para utilizar su Indexing API. Hasta esa fecha, cualquier empresa que gestionara portales de empleo o emisiones de vídeo en directo debía completar una solicitud formal para pasar de un entorno de pruebas a un entorno productivo de mayor capacidad. El historial de cambios oficial de Google justificó la modificación alegando una actualización para reflejar los límites vigentes y eliminar un formulario obsoleto. Sin embargo, la compañía no especificó si la validación humana previa ha dejado de ser obligatoria o si los proyectos existentes pueden operar directamente bajo la cuota inicial predeterminada.

Este movimiento responde a un cuello de botella que llevaba meses acumulando fricción en el sector. Durante el último año, cientos de plataformas de empleo esperaron meses sin recibir respuesta alguna sobre el estado de sus expedientes. Mientras tanto, sus ofertas de trabajo perdían relevancia temporal frente a competidores con acceso prioritario. Al borrar las referencias que catalogaban la cuota por defecto como exclusiva para pruebas, la documentación abre una zona gris: los límites técnicos siguen existiendo, pero la vía oficial para negociar extensiones de volumen ha desaparecido de la interfaz pública de soporte.

Para entender la magnitud del cambio en la arquitectura de distribución, el siguiente esquema resume el embudo por el que transitan los datos desde la publicación de un contenido hasta su inclusión en el índice:

El impacto no se distribuye de manera uniforme. Los sitios pequeños y medianos que publican menos de dos centenares de ofertas diarias ganan claridad operativa inmediata al prescindir de una burocracia que no respondía. Por el contrario, los grandes agregadores de empleo que publican miles de vacantes cada jornada se encuentran con un muro de contención estricto que les impide escalar la ingesta automatizada mediante este canal directo.

200 peticiones diarias por proyecto: Comparativa de cuotas técnicas frente a sitemaps tradicionales

La documentación oficial mantiene las restricciones numéricas asociadas a cada proyecto dentro de Google Cloud Console. El límite de publicación estándar continúa fijado en 200 peticiones por día, una cifra que engloba tanto las altas y actualizaciones de contenido (URL_UPDATED) como las solicitudes de retirada de URLs caducadas (URL_DELETED). Este contador se reinicia puntualmente a medianoche, según el huso horario del Pacífico (PT).

En el plano de la tasa de transferencia inmediata, la API restringe el tráfico a 180 peticiones de metadatos por minuto y un techo global de 380 peticiones por minuto distribuidas entre todos sus puntos de enlace (endpoints). El ámbito de aplicación legal sigue estrictamente acotado por las directrices contra el abuso: el motor únicamente admite páginas que contengan datos estructurados de tipo JobPosting o eventos en directo bajo BroadcastEvent encapsulados en un objeto VideoObject.

A continuación, se detalla el comportamiento técnico y los márgenes de operación de cada vía de comunicación con el rastreador:

La diferencia de velocidad es el factor determinante. Un archivo sitemap tradicional requiere que el robot de Google descubra el archivo, interprete las marcas de modificación temporal (lastmod) y programe el rastreo según su presupuesto de rastreo asignado al dominio. En contraposición, la Indexing API actúa como una notificación directa en cola que activa la visita del robot casi en tiempo real, lo que resulta crítico para ofertas de trabajo con ventanas de postulación inferiores a 48 horas.

Fricción operativa en portales de empleo: Costes ocultos, retrasos y gobernanza de datos

La desaparición del canal de aprobación transforma la operativa técnica de los equipos de ingeniería y marketing de contenidos. Lejos de ser un simple cambio de interfaz, impone tres restricciones inmediatas en el funcionamiento diario de cualquier plataforma que gestione vacantes de empleo o transmisiones audiovisuales.

Incremento de costes de desarrollo y priorización algorítmica (OPEX)

Al no existir la posibilidad de solicitar cuotas extendidas de 5.000 o 10.000 peticiones diarias mediante un formulario, las empresas se ven obligadas a programar capas de lógica intermedias. Un portal que publica 1.200 ofertas nuevas al día ya no puede lanzar un evento de API por cada registro insertado en su base de datos.

Esto exige diseñar un motor de priorización interna que decida qué 200 vacantes justifican el consumo del cupo directo y cuáles deben relegarse al sitemap tradicional. Esta clasificación suele basarse en el valor comercial del cliente que contrata el anuncio, la urgencia de contratación o el volumen de búsqueda estimado. El desarrollo, mantenimiento y monitorización de estos filtros eleva las horas de ingeniería dedicadas a tareas que antes se resolvían mediante una ampliación de cuota en la consola de Google. Para coordinar estas alertas y disparadores de actualización sin saturar los entornos internos, herramientas de orquestación como Make permiten gestionar colas condicionales antes de enviar las llamadas a la API de Google.

Retrasos de visibilidad en ofertas con alta rotación (Lead Time)

El tiempo que transcurre entre la publicación de un empleo en la base de datos y su aparición en los resultados enriquecidos de búsqueda define la tasa de conversión de los candidatos. En sectores de alta rotación laboral, como la hostelería, la logística o la atención médica de emergencia, las primeras 24 horas concentran más del 60% de las solicitudes válidas.

Si una oferta queda fuera del cupo diario de 200 llamadas y depende de la lectura pasiva de un sitemap XML, el retraso de indexación puede extenderse de 24 a 72 horas. Para cuando el robot de búsqueda procesa la URL, la vacante puede estar cubierta o a punto de expirar, lo que reduce drásticamente el retorno de inversión de las empresas que pagan por destacar sus ofertas en la plataforma.

Riesgos de penalización por políticas antispam y uso de cuentas múltiples

La documentación actualizada insiste de forma explícita en que las directrices contra el spam se aplican con rigor absoluto sobre la API. Google advierte específicamente contra el intento de eludir los límites mediante la creación de múltiples proyectos en Google Cloud vinculados a un mismo dominio o empresa.

Cualquier organización que intente sortear la barrera de las 200 peticiones fragmentando su tráfico entre varias cuentas de servicio se expone a la revocación completa de credenciales o, en casos graves, a la desindexación manual del dominio en Google Search Console. La gobernanza técnica exige un control estricto sobre los tokens de acceso y una auditoría periódica de las llamadas para evitar patrones que los algoritmos de seguridad identifiquen como tráfico automatizado abusivo.

Estrategias de contingencia: Arquitectura híbrida para absorber la escasez de cupo

Ante la imposibilidad de solicitar aumentos de volumen por los canales habituales, las plataformas líderes están adaptando su infraestructura para maximizar la eficiencia de cada llamada y transferir el excedente a canales secundarios altamente optimizados. La solución no radica en abandonar la API, sino en utilizarla como una herramienta quirúrgica combinada con una jerarquía de sitemaps segmentados.

La guía oficial de optimización para empleo de Google, revisada a principios de septiembre, continúa recomendando la Indexing API por encima de los sitemaps para las URLs individuales de ofertas de trabajo, reservando el sitemap para la cobertura global del sitio web. Esta dualidad valida la adopción de una arquitectura de dos velocidades:

Esta estructura exige implementar tres buenas prácticas de ingeniería en el servidor de aplicaciones:

• Sitemaps XML particionados por fecha de publicación: En lugar de mantener un archivo único masivo de 50.000 URLs, los portales dividen sus índices en bloques diarios o por horas que contienen únicamente las altas más recientes. Al notificar a los motores de búsqueda mediante un ping a este archivo ligero, los rastreadores procesan las novedades con una latencia significativamente menor que en un sitemap monolítico.
• Microformato riguroso y validación de código limpio: Para evitar que peticiones de la API se desperdicien en URLs con errores sintácticos, las llamadas deben someterse a un validador local de esquemas antes de su transmisión. Si una oferta carece de campos obligatorios como datePosted, validThrough o hiringOrganization, el sistema descarta la llamada a la API y la envía a cola de corrección interna.
• Gestión activa de eliminaciones por lotes: Dado que las bajas (URL_DELETED) consumen parte de la cuota diaria de 200 peticiones, las vacantes expiradas no críticas deben gestionarse a través del código de estado HTTP (devolviendo 404 Not Found o 410 Gone) y retirarse silenciosamente del sitemap, reservando la API de borrado únicamente para ofertas que deban desaparecer del índice por imperativo legal o errores de confidencialidad.

Tres líneas de defensa técnica para blindar la visibilidad de ofertas y directos

La retirada de la interfaz de aprobación obliga a los responsables de tecnología y directores de marketing a revisar sus dependencias de indexación. Para mitigar los riesgos derivados de esta opacidad técnica y garantizar que el inventario mantenga su tracción orgánica, las organizaciones deben desplegar tres niveles de defensa en sus sistemas.

Primera línea: Auditoría inmediata de credenciales y consumo en Google Cloud Console

El primer paso operativo consiste en revisar el panel de control de Google API Console para cada proyecto en activo. Es imprescindible confirmar que el contador de consumo no esté sufriendo rechazos de peticiones con errores HTTP 429 Too Many Requests.

Los equipos deben verificar que las 200 llamadas diarias se estén consumiendo exclusivamente en contenidos que cumplan los requisitos de JobPosting o BroadcastEvent. Si el proyecto enviaba URLs de artículos de blog, fichas de producto o páginas de aterrizaje comerciales en un intento de acelerar su rastreo, estas llamadas deben erradicarse de inmediato del código fuente. Además de suponer una infracción directa de las directrices que puede derivar en la revocación del acceso, representan un consumo inútil de una cuota extremadamente escasa.

Segunda línea: Reingeniería de sitemaps XML y calibración de etiquetas temporales

Dado que el sitemap se convierte en el canal principal para absorber todo el volumen que supere las 200 URLs diarias, su arquitectura debe optimizarse al milímetro. La marca temporal lastmod no puede generarse de forma estática con la fecha del día; debe reflejar con precisión matemática el instante exacto de la última modificación en la base de datos (formato W3C Datetime).

Asimismo, se deben separar las ofertas activas de las caducadas en archivos sitemap distintos. Mantener URLs inactivas en el índice principal obliga al robot a gastar recursos de rastreo en páginas sin valor, lo que retrasa el descubrimiento de las nuevas oportunidades de empleo. La implementación de cabeceras HTTP de compresión (gzip) en los sitemaps y una respuesta de servidor inferior a 150 milisegundos aseguran que el rastreador procese el mayor número posible de páginas por segundo cuando visite el dominio.

Tercera línea: Protocolo de contingencia para ampliaciones de cuota corporativas

A pesar de la desaparición del formulario estándar, las grandes plataformas que gestionan volúmenes industriales deben mantener una vigilancia activa sobre los anuncios oficiales de Google. En caso de requerir un cupo superior justificado por el impacto en el servicio a los usuarios, la vía de escalamiento pasa por:

• Monitorización automatizada del registro de cambios: Establecer un rastreo periódico sobre la página de cuotas de la API de indexación para detectar cualquier nuevo mecanismo de contacto o proceso de acreditación para grandes cuentas en cuanto sea publicado.
• Interacción documentada a través de canales de soporte empresarial: Aquellas organizaciones que cuenten con contratos de soporte corporativo en Google Cloud Platform deben abrir incidencias técnicas justificadas a través de su gestor de cuenta asignado, aportando registros de volumen, cumplimiento de esquemas de datos y métricas de error.
• Pruebas de diversificación con IndexNow: Aunque Google no participa en la iniciativa IndexNow (respaldada por Microsoft Bing, Yandex y Naver), los portales deben implementar este protocolo abierto en paralelo. IndexNow permite enviar miles de URLs diarias sin fricciones de aprobación, asegurando visibilidad y tráfico cualificado en motores alternativos mientras se estabiliza la gobernanza del ecosistema de Google.