Técnico

Datos de backlinks por uso: lo que aprendimos en producción

Lo que aprendimos al traer datos de backlinks por solicitud en producción: la cobertura es un ajuste, cada llamada necesita un cliente con topes y un rechazo no es un resultado vacío.

Jose Antonio Mijares · · 8 min de lectura

Datos de backlinks por uso: lo que aprendimos en producción

Actualizado en septiembre de 2026. Este artículo cuenta lo que aprendimos al traer datos de backlinks de una API en producción, pagando por uso, y cómo decidir si ese modelo o una herramienta de suscripción te conviene más.

Los datos de backlinks por uso funcionan bien cuando estás armando un pipeline: pagas por solicitud, las filas llegan a tu propia base de datos y puedes atribuir el costo a cada proyecto. Pero no traen los controles que una herramienta de suscripción te da de regalo. Tú tienes que decidir cuánto de cada perfil vas a descargar, poner un tope a tu propio gasto y distinguir una solicitud rechazada de una vacía. Si fallas en eso, tus números cambian por razones que no tienen nada que ver con los enlaces.

Ezeo obtiene los datos de backlinks de la API de Backlinks de DataForSEO, que se cobra por solicitud. Las solicitudes pasan por un flujo de n8n, y mantenemos una ruta directa a la misma API como alternativa. Una sincronización semanal actualiza el perfil de cada proyecto: dominios de referencia, anchors, enlaces nuevos y perdidos, y las filas de backlinks en sí.

Toda solicitud al proveedor, por cualquiera de las dos rutas, pasa por un único cliente compartido en nuestro código. Ese cliente registra el costo de cada solicitud, aplica un tope diario de solicitudes y un tope mensual en dólares, y se niega a enviar en cuanto se alcanza alguno de los dos.

Esa es toda la arquitectura. Las lecciones están en los detalles.

Lección 1: la cobertura es un ajuste que elegiste, aunque no lo hayas querido

Una API de backlinks devuelve los resultados por páginas. Cuántas páginas pides determina cuánto de un perfil guardas. Esa decisión es fácil de tomar sin querer y difícil de notar después.

Lo medimos. Nuestra ruta por flujo descargaba una página de 1,000 filas por perfil. La ruta directa pagina hasta 10 páginas de 1,000 hasta que el proveedor ya no tiene nada más que devolver. Para sitios pequeños las dos son iguales, porque el perfil completo cabe en una página. Para los perfiles más grandes que monitoreamos, la ruta directa guardó cerca de 2.2 veces más backlinks.

Lo descubrimos de la manera menos planeada. Cuando el hosting del flujo tuvo una caída, la ruta directa se encargó de la sincronización semanal de todos los proyectos. En un perfil, el conteo de backlinks guardados pasó de 2,194 a 4,875. El aumento fue exactamente el número de filas que insertó la descarga más completa. No habían aparecido enlaces nuevos en la web esa semana. Fue un cambio de cobertura, no un crecimiento de enlaces.

Si le hubiéramos reportado ese salto a un cliente como progreso, habría sido falso, y nada en la gráfica habría avisado a nadie.

Qué hacemos al respecto

  • Registrar la cobertura junto al conteo. Guarda cuántas páginas se descargaron y si el barrido llegó al final del perfil. Un conteo sin eso es un número sin denominador.
  • Marcar los cambios de ruta en la línea de tiempo. Cualquier cambio de fuente, ruta o límite de páginas es una anotación en la gráfica, para que un salto repentino tenga una causa visible.
  • Comparar peras con peras. Antes de cambiar de ruta para siempre, corre las dos durante un ciclo completo y compara el número de filas por proyecto. Para nosotros, esa prueba es la decisión.

La regla general: cuando cambia tu fuente de datos, un salto en una métrica no es un resultado hasta que hayas descartado la cobertura.

Diagrama: la ruta por flujo descargaba una página de 1,000 filas, la ruta directa hasta diez páginas, y los backlinks guardados de un perfil subieron de 2,194 a 4,875 sin enlaces nuevos: un cambio de cobertura.

Lección 2: pon todas las llamadas al proveedor detrás de un solo cliente

Con una suscripción, un error no puede costarte más que la suscripción. Con el pago por uso, un ciclo de reintentos o un programador que se dispara dos veces puede gastar dinero de verdad antes de que alguien lo vea. La solución es estructural. Toda solicitud a un proveedor de pago pasa por un solo cliente, y ese cliente hace tres cosas:

  1. Registra el costo de cada solicitud, etiquetado con el proyecto y la función que la pidió. Así obtienes el costo por proyecto y por función sin adivinar.
  2. Aplica un tope diario de solicitudes que rechaza las solicitudes una vez alcanzado.
  3. Aplica un tope mensual en dólares, medido sobre el mes calendario en curso.

Como nada puede llegar al proveedor sin pasar por ese cliente, los topes sí se cumplen. Una segunda ruta de código "temporal" que llame a la API directamente es la forma en que los topes dejan de significar algo, así que tenemos una prueba que verifica que no exista ninguna.

El registro también responde la pregunta con la que empieza toda conversación de finanzas. Como ejemplo medido: un barrido directo completo de un perfil pequeño de backlinks costó $0.026844 en una sola ejecución y escribió 7 filas nuevas. Es una ejecución en un sitio pequeño, no un promedio ni un precio en el que debas basar tu planeación. Los perfiles grandes, la paginación más profunda y las sincronizaciones más frecuentes cambian la cifra. Lo importante es que podemos leer el número real de cualquier ejecución, porque el cliente lo registró.

Diagrama: la ruta por flujo, la ruta directa y cualquier otra función envían las solicitudes de pago por un solo cliente compartido que registra el costo y aplica un tope diario y uno mensual antes de llegar al proveedor.

Lección 3: un rechazo es una falla, no "sin datos"

Las APIs como esta suelen responder con una respuesta HTTP exitosa que lleva dentro un error a nivel de tarea. Si tu código solo revisa el estado HTTP y luego lee el arreglo de resultados, una solicitud rechazada se ve exactamente igual que un perfil sin backlinks.

Aprendimos esta lección en otra parte de Ezeo, y salió cara. Una solicitud con un parámetro inválido fue rechazada por el proveedor en cada escaneo. El código leyó la falta de resultados como "no se encontraron menciones", cada escaneo reportó éxito y meses de datos de menciones nunca se recopilaron. El error estuvo registrado todo el tiempo. Registrar una falla no es lo mismo que detectarla.

Por eso nuestra ruta de backlinks desempaca el estado de la tarea en cada respuesta. Un rechazo se convierte en una sincronización fallida con el mensaje del propio proveedor adjunto. Un resultado vacío solo se registra como vacío cuando el proveedor dijo que la solicitud tuvo éxito y no devolvió nada.

Diagrama: una respuesta con estado HTTP OK puede contener una tarea rechazada; si solo lees el estado, se registran cero backlinks, y si desempacas el estado de la tarea, se registra una sincronización fallida.

Lección 4: detente tras fallas repetidas y avisa a una persona

Una sincronización que falla una y otra vez y sigue reintentando quema dinero en la ruta de pago y esconde la caída detrás de un flujo de errores que nadie lee. Las sincronizaciones de Ezeo se apagan solas tras 5 fallas consecutivas y avisan a un administrador. Una persona decide cuándo volver a encenderla, después de revisar por qué falló.

Cinco es un ajuste nuestro, no un estándar de la industria. Elige tu propio número, pero elige uno, y haz que el apagado se note.

Flujo: cinco fallas consecutivas apagan la sincronización y avisan a un administrador, y una persona decide cuándo volver a encenderla.

Lección 5: una segunda ruta ayuda, siempre que sepas qué cambia

Mantener una ruta directa junto al flujo fue lo que mantuvo activas las sincronizaciones de backlinks cuando el hosting del flujo estaba caído. Eso vale la pena. También es justo como descubrimos la brecha de cobertura de la Lección 1: el respaldo no era una copia de la ruta principal, porque descargaba más.

Si manejas dos rutas, escribe en qué se diferencian, en campos y en cobertura, y haz que la decisión de cuál corre primero sea un ajuste explícito que puedas cambiar y revertir. Un respaldo silencioso que cambia tus números es un incidente de calidad de datos esperando a que alguien lo note.

Cuándo gana el pago por uso a una herramienta de suscripción, y cuándo no

Esto es criterio editorial de haber operado los dos tipos de esquema, no un modelo de costos. No citamos precios de terceros que no podemos sustentar ni mantener al día. Cambian, varían según el plan, y la comparación real depende de tu volumen.

El pago por uso suele ganar cuando

  • Estás construyendo un producto o un pipeline. Necesitas filas crudas en tu propia base de datos, cruzadas con datos de rankings, tráfico y contenido, no un panel al que alguien entra.
  • Atiendes muchos proyectos con un calendario. El cobro por solicitud más el registro de costos por proyecto te dice cuánto te cuesta atender a cada cliente.
  • Tu uso es irregular. Una actualización semanal y un análisis profundo ocasional cuestan lo que cuestan, sin cuotas por usuario en los meses tranquilos.
  • Tienes tiempo de ingeniería para construir los controles de las Lecciones 2 a 4. Sin ellos, una mala semana puede costar más de lo que ahorra el modelo.

Una herramienta de suscripción suele ganar cuando

  • Quienes consumen los datos son personas, no código. Un analista que explora los enlaces de un competidor quiere una buena interfaz, filtros y exportaciones, que es la mayor parte de lo que compra una suscripción.
  • Necesitas el historial del proveedor. Las gráficas históricas largas y las vistas de "perdidos desde" se construyen sobre años de rastreo propio del proveedor. Reconstruirlas con tus propias descargas semanales empieza desde el día en que arrancas.
  • No tienes a nadie que mantenga un pipeline. Los flujos se rompen, las APIs cambian, los hosts se caen. Alguien tiene que hacerse cargo de eso.
  • Quieres la definición de la métrica de alguien más. La puntuación de autoridad de una herramienta de suscripción es, al menos, consistente dentro de esa herramienta. Tus propios conteos son tan consistentes como lo sea tu cobertura.

Muchos equipos terminan con las dos: una API para los números que alimentan los reportes y una licencia de suscripción para quienes hacen investigación. Es una respuesta razonable.

  • ¿Sabes cuántas páginas por perfil descarga cada ruta, y eso se guarda con cada conteo?
  • ¿Cada solicitud de pago pasa por un solo cliente que registra el costo y aplica un tope diario y uno mensual?
  • ¿Tu código lee el estado a nivel de tarea del proveedor, de modo que un rechazo se registre como falla?
  • ¿Las sincronizaciones se detienen y avisan a una persona tras un número fijo de fallas consecutivas?
  • Si tienes una ruta de respaldo, ¿ya comparaste su cobertura con la principal durante un ciclo completo?
  • ¿Los cambios de ruta están anotados en todas las gráficas que muestran un conteo de backlinks?
  • ¿Puedes leer el costo real de cualquier ejecución en tus propios registros?

Si alguna respuesta es no, corrígela antes de mostrarle a alguien una tendencia de backlinks.

Lista de verificación con siete preguntas de sí o no que conviene responder antes de confiar en los datos de backlinks de una API.

Los enlaces siguen importando para la búsqueda, y varios motores de respuesta con IA se apoyan en índices de búsqueda construidos sobre la misma web. Nuestro artículo sobre cómo trabajan juntos el SEO tradicional y el GEO explica por qué, y nuestra explicación de qué es el GEO cubre el lado de los motores de respuesta. Sea cual sea el modelo con el que compres los datos, las lecciones de arriba son las que hacen confiables los números.

Qué cambió en la actualización de septiembre de 2026: Quitamos los precios de suscripciones de terceros que no pudimos sustentar, corregimos la afirmación de que la calidad de los datos es idéntica sin importar cómo los descargues (la cobertura guardada difirió en cerca de 2.2 veces) y corregimos el umbral de desactivación automática a 5 fallas consecutivas. Quitamos los detalles de caché y de calendario que no coincidían con cómo opera el sistema.

Etiquetas:BacklinksIntegración de APICalidad de datosControl de costosTécnico

Frequently asked questions

Jose Antonio Mijares

Written by

Jose Antonio Mijares

Experto en SEO y GEO | Fundador de Ezeo

¿Te fue útil este artículo? Compártelo con tu red.

Share:

¿Quieres ver tus propios números?

Crea tu cuenta, agrega tu sitio y mira lo que Google y los motores de IA dicen de ti. 7 días gratis.

Empieza

Related articles