Cómo automatizar un portal de empleo con el CMS de Webflow y Make

Una bolsa de trabajo es un problema de contenido con fecha de entrega. Los nuevos puestos llegan desde un sistema de seguimiento de candidatos, una hoja de cálculo o un feed de socios, y cada uno de ellos deja de ser válido en una fecha que alguien debe recordar. Hacerlo a mano funciona hasta que tienes una docena de puestos, y entonces, sin hacer ruido, deja de funcionar.

El CMS de Webflow te ofrece las plantillas, el filtrado y las URL. Make te proporciona el flujo de trabajo programado que mantiene la colección al día.

Lo que decide si la bolsa de trabajo genera tráfico, en lugar de simplemente existir, son los datos estructurados adjuntos a cada anuncio y la disciplina de retirar los listados cuando se cierran.

¿Qué necesitas para automatizar una bolsa de trabajo en Webflow?

Un sitio en Webflow con una colección de empleos, un token de API de datos con acceso de escritura, una cuenta de Make y una fuente de puestos. El diseño de la colección importa más que la automatización, porque determina qué marcado podrás generar después.

La lista completa:

• Un sitio en Webflow con una colección de empleos y una plantilla de página de colección
• Un token de la API de datos de Webflow con acceso de escritura al CMS.
• Una cuenta de Make. El plan que necesitas depende de la frecuencia con la que se ejecute el escenario y de cuántas operaciones consuma cada ejecución, así que consulta los límites de operaciones actuales en la página de precios de Make
• Una fuente de puestos: un sistema de seguimiento de candidatos con API, una hoja compartida o un feed de socios

Una vez que todo esto está listo, el éxito de la bolsa depende del marcado que emita cada anuncio y de retirar los listados en cuanto se cierran. Aquí te explicamos cómo.

Cómo encajan Webflow y Make en una bolsa de trabajo

Make consulta o recibe tu fuente, transforma cada puesto y lo escribe en el CMS de Webflow, donde el contenido aterriza como borrador antes de convertirse en un anuncio publicado.

Dos detalles en ese diagrama hacen el trabajo pesado. Que el contenido llegue como borrador te da un punto de revisión entre un feed externo y una página pública. Y la caja de procesamiento existe porque una integración que ignora los límites de velocidad y los errores parecerá funcionar durante las pruebas, cuando mueves tres puestos, pero se vendrá abajo en la primera importación real.

Los datos estructurados que la mayoría de las bolsas de trabajo en Webflow hacen mal

Una bolsa de trabajo sin marcado JobPosting es invisible para la experiencia de búsqueda de empleo en Google. Esto no es un detalle estético de SEO en una bolsa de trabajo; es la diferencia entre los listados que pueden aparecer y los que no.

Google admite un conjunto definido de propiedades JobPosting, basadas en el tipo de schema.org. Estas cinco son obligatorias, y cada una conlleva una trampa que vale la pena conocer antes de modelar la colección:

Una excepción a esa lista: para un puesto que es totalmente remoto, Google indica usar jobLocationType, y jobLocation no es necesario cuando applicantLocationRequirements está presente. Un tablón que incluya puestos remotos debe tener ambos modelados desde el principio.

Aquí tienes un listado completo en JSON-LD, que vinculas a los campos del CMS en la plantilla de tu página de colección para que cada anuncio genere el suyo propio:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "JobPosting",
  "title": "Senior Product Designer",
  "description": "<p>We are hiring a senior product designer to own...</p>",
  "identifier": {
    "@type": "PropertyValue",
    "name": "Acme",
    "value": "ACME-1042"
  },
  "datePosted": "2026-08-04",
  "validThrough": "2026-09-30T00:00",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "Acme",
    "sameAs": "https://www.example.com",
    "logo": "https://www.example.com/images/logo.png"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "1 Example Street",
      "addressLocality": "Manchester",
      "addressRegion": "England",
      "postalCode": "M1 1AA",
      "addressCountry": "GB"
    }
  }
}
</script>

Incluye validThrough aunque no sea obligatorio, porque es lo que hace posible la caducidad automática. Y la caducidad, como veremos en la siguiente sección, no es opcional.

Los empleos caducados son una obligación, no una cuestión de orden

La guía de Google es inusualmente directa aquí: los empleos que ya no aceptan solicitudes deben marcarse como caducados, y "no tomar medidas a tiempo con los empleos caducados puede resultar en una acción manual". Una acción manual es una decisión de revisión humana que puede eliminar tus anuncios de los resultados de búsqueda de empleo, en lugar de un simple ajuste algorítmico de clasificación.

Tienes tres formas aceptables de caducar un anuncio: dejar que validThrough pase a ser una fecha pasada, eliminar la página para que devuelva un error 404 o 410, o eliminar los datos estructurados JobPosting de la misma. Cualquiera de estas opciones es válida. Dejar un puesto cubierto activo con marcado válido no lo es.

Este es el argumento más sólido para automatizar el tablón en lugar de mantenerlo a mano. El problema del mantenimiento manual no es una página desordenada, sino una decisión de revisión contra tu sitio provocada por ese único puesto que nadie recordó eliminar.

5 pasos para automatizar anuncios de empleo con Webflow y Make

La estructura consiste en una colección modelada según el esquema, un escenario de importación que realiza inserciones o actualizaciones (upserts) y un segundo escenario que gestiona la caducidad. El ID externo es el campo que hace que las ejecuciones repetidas sean seguras.

1. Modela la colección según el esquema

Diseña los campos de la colección para que coincidan con las propiedades que vas a publicar, en lugar de diseñarlos según el aspecto de la lista y adaptar el marcado después. Como mínimo, necesitas el título del puesto, una descripción en texto enriquecido, el tipo de empleo, la fecha de publicación, la fecha de validez y el empleador.

Añade un campo adicional que no tenga nada que ver con la página: un ID externo que contenga el identificador del sistema de origen para el puesto. Ese campo es el que permite al escenario saber si un puesto ya existe. Inclúyelo también en el slug, por la razón explicada en el paso 3. Terminarás este paso con una colección cuyos campos se asignan uno a uno al marcado que pretendes emitir.

2. Crea el escenario de importación

En Make, crea un escenario con tu fuente como activador y, a continuación, un módulo de Webflow para escribir el elemento. Asigna los campos explícitamente en lugar de pasarlo todo directamente, y recuerda que las claves de Webflow son los slugs de campo de tu colección, por lo que "Valid Through" es .fieldDatavalid-through

La carga útil del elemento tiene este aspecto:

{
  "isArchived": false,
  "isDraft": false,
  "fieldData": {
    "name": "Senior Product Designer",
    "slug": "senior-product-designer-acme-1042",
    "description": "<p>We are hiring a senior product designer to own...</p>",
    "employment-type": "FULL_TIME",
    "date-posted": "2026-08-04",
    "valid-through": "2026-09-30",
    "external-id": "ACME-1042"
  }
}

Configura el escenario para que se ejecute según un programa en lugar de forma continua. Los feeds de empleo no cambian minuto a minuto, y cada ejecución consume operaciones, independientemente de si algo ha cambiado o no. Una primera ejecución exitosa crea elementos que puedes ver en la colección, aunque todavía sin publicar.

3. Haz que la ejecución sea repetible

Antes de crear nada, busca en la colección un elemento que contenga ese ID externo. Si lo encuentras, actualízalo; si no, créalo. Sin esa búsqueda, la segunda ejecución duplicará todos los puestos vacantes, y lo hará de forma silenciosa.

Una advertencia que condiciona el diseño: el endpoint de elementos de lista filtra por slug o ID exactos y por fechas de creación y actualización, pero no por un campo arbitrario. No puedes consultar tu campo de ID externo directamente. La solución práctica es construir el slug a partir del ID externo, como en , y filtrar por . La alternativa es paginar la colección y hacer la coincidencia dentro de Make, lo cual cuesta una operación por página.nameslugsenior-product-designer-acme-1042slug

Ejecuta el escenario dos veces con la misma fuente. Una implementación correcta deja el recuento de elementos sin cambios en la segunda ejecución.

4. Respeta el límite de velocidad

La API de datos de Webflow impone un límite de solicitudes por minuto que varía según el plan del sitio. Una primera importación de cien puestos es exactamente la carga de trabajo que alcanza ese límite.

Añade un retraso entre iteraciones y gestiona el error 429 reintentando en el intervalo indicado en el encabezado en lugar de descartar el elemento. El cuadro de gestión de errores en el diagrama se gana su lugar aquí: un escenario que falla a mitad de una importación e informa de éxito te deja con un tablero parcial y sin una lista de lo que falta. Una importación bien hecha termina más despacio y completa, en lugar de rápida y parcial.Retry-After

5. Automatiza la caducidad

Ejecuta un segundo escenario, más sencillo, con una frecuencia diaria. Este enumera los puestos de trabajo publicados, comprueba la fecha de validez de cada uno frente a la fecha actual y despublica o archiva todo lo que haya caducado. Los puestos que desaparecen del feed de origen reciben el mismo tratamiento.

Este es el escenario que te protege de la acción manual, así que diséñalo al mismo tiempo que la importación, en lugar de esperar a que aparezca el primer anuncio obsoleto. Si quieres que la caducidad ocurra en el momento en que se cierra un puesto en lugar de en la siguiente ejecución diaria, un webhook de cambio de elemento de colección puede activar el trabajo posterior cuando se actualiza un elemento, ya que el evento de creación solo se dispara al crear. Sabrás que este paso funciona cuando un puesto cuya fecha ha pasado desaparezca del tablero en vivo sin que nadie lo toque.

¿Qué hace que un tablón de anuncios automatizado falle? Consejos para solucionar problemas

Cuatro fallos cubren casi todo: un marcado que no cumple los requisitos, una importación sin memoria, un límite de velocidad alcanzado a mitad de la ejecución y fechas en el formato incorrecto.

Los anuncios no aparecen en Google Jobs

Causa: una propiedad obligatoria que falta, una descripción que es un resumen en lugar del texto completo, o un sin componentes de dirección reales, incluido .jobLocationaddressCountry

Solución: prueba la página renderizada en lugar de la plantilla, ya que el marcado solo se completa una vez que se vinculan los valores del CMS. Corrige la propiedad que falla y vuelve a probar la URL en vivo.

Cada ejecución crea duplicados

Causa: no hay búsqueda de ID externo, por lo que el escenario no tiene memoria y crea en lugar de actualizar.

Solución: añade el campo, codifícalo en el slug y busca antes de escribir. Limpia los duplicados existentes una vez; después, la actualización (upsert) se mantendrá en cada ejecución posterior. Detecta esto durante las pruebas ejecutando el escenario dos veces con la misma fuente, ya que una prueba de una sola pasada nunca lo revelará y el problema se acumulará diariamente en una ejecución programada.

La importación se detiene a mitad de camino

Causa: casi siempre es el límite de velocidad, alcanzado durante una primera importación grande.

Solución: añade un retraso entre iteraciones y reintenta en el Retry-After intervalo en lugar de descartar el elemento. Deja que la ejecución tarde más en lugar de fallar. Vale la pena configurar esto antes de tu primera gran importación y no después, porque la ejecución que descubre el límite es también la que deja el tablero medio lleno.

Las fechas llegan en el formato incorrecto

Causa: los datos estructurados requieren ISO 8601, y un sistema de origen que exporta una cadena de fecha localizada produce un marcado que se valida como texto pero falla como fecha.

Solución: convierte el formato en el escenario antes de escribir. Vale la pena comprobar esto explícitamente, ya que es un fallo silencioso en lugar de uno evidente y el listado parece correcto para un lector humano.

Qué puedes construir a continuación con Make y Webflow

Una vez que los roles fluyen y caducan por sí solos, el tablero se convierte en una base sobre la cual construir: alertas cuando aparece un rol que coincide con criterios guardados, un formulario de solicitud que escribe de vuelta en el sistema de seguimiento de candidatos o una fuente para agregadores.

La misma estructura de importación y actualización (upsert) se aplica a cualquier fuente de contenido externa. Nuestra guía de Notion a Webflow lo construye mediante código en lugar de un escenario visual, incluyendo el mapeo de ID que hace que las ejecuciones repetidas sean seguras. Para los detalles de conexión y lo que cubren los módulos, consulta la integración de Webflow y Make. Si prefieres publicar directamente en el sitio en vivo, los endpoints de elementos en vivo existen para ello, aunque el estado de borrador más un paso de revisión es la opción predeterminada más segura para contenido que no escribiste tú.

Para una personalización más profunda más allá de lo que maneja Make, la documentación para desarrolladores de Webflow cubre la API del CMS, los webhooks y los límites de velocidad al completo.