Scraping de ofertas de empleo: títulos, reposts y cierre

El scraping de ofertas de empleo se convierte en un problema de modelo de datos cuando más de una bolsa publica el mismo puesto. Títulos iguales no identifican un empleo, una URL nueva no prueba una vacante nueva y una fila que deja de aparecer no prueba que la empresa la cerrara. BotBrowser proporciona entradas de navegador documentadas y basadas en perfiles para una observación autorizada; no suministra datos de empleo, no inicia sesión por ti ni concede acceso a una bolsa. Elige una fuente permitida, conserva los campos brutos junto a cualquier normalización y mantén explícitas cada ocurrencia y cada resultado de observación.

Resumen

• Conserva las cadenas brutas de título, empresa y ubicación junto a los valores normalizados, con una versión de la regla.
• Clavea cada registro por la ocurrencia de publicación de la fuente. Un repost necesita evidencia de continuidad antes de reemplazar la ocurrencia anterior.
• Trata datePosted, validThrough y el momento de observación como hechos distintos con significados distintos.
• Una actualización fallida es un incidente. La ausencia de una lista limitada es una ausencia, no prueba de que una vacante se cerrara.
• Prefiere un feed oficial o una exportación aprobada cuando exista. El vocabulario y la elegibilidad de datos estructurados no autorizan la recolección.

Contenido

• Separar los tres problemas de normalización
• Conservar campos brutos y versiones de mapeo
• Decidir cuándo un repost es otra ocurrencia
• Detectar el cierre sin inventarlo
• Usar un esquema de ingesta mínimo
• Elegir una fuente aprobada antes que una ruta de navegador
• Conclusión práctica

Separar los tres problemas de normalización

Los datos de empleo entre bolsas necesitan tres decisiones distintas, y fusionarlas en un solo paso de limpieza pierde la evidencia que se necesitará después.

Título. «Senior Engineer», «Sr. Engineer, Platform» y «Engineer III» pueden describir una antigüedad comparable o ámbitos distintos. Normaliza un campo separado para un propósito declarado, como una familia de roles amplia, y conserva el título de la fuente. No sobrescribas el título con la etiqueta normalizada.

Ubicación. «Remote», «Remote, US», «New York, NY (Hybrid)» y un nombre de ciudad en un campo de texto libre responden a preguntas distintas. Conserva el texto bruto, luego registra los campos que la fuente sí proporciona: país, región, ciudad, alcance remoto y modalidad. Un país ausente no autoriza a inferirlo del idioma del navegador o de la región del proxy.

Empresa. Una marca, una entidad legal, una agencia de colocación y una etiqueta de empresa específica de la bolsa no son intercambiables. Conserva la etiqueta de la fuente y cualquier referencia de organización que proporcione. Nombres similares pueden pertenecer a entidades distintas, y una empresa puede publicar por varios canales.

Registra las tres decisiones de mapeo como campos separados, como title_family, location_parts y employer_ref, cada uno con su versión de regla. Un único campo cleaned_title o city oculta qué parte se suministró y cuál se infirió. Mantén las cadenas brutas junto a esos campos y un estado desconocido explícito cuando la fuente no responde la pregunta. Así una comparación posterior se puede revisar sin reconstruir la respuesta original.

El contrato de campos de empleo establece cómo una bolsa expone campos y observaciones. Este pipeline comienza después de ese contrato y añade un registro entre bolsas con la fuente, el campo original y la versión de regla de cada valor mapeado.

Conservar campos brutos y versiones de mapeo

La normalización es una decisión de la aplicación, así que el registro debe mostrar tanto la entrada como la regla que la aplicó. El vocabulario JobPosting de schema.org describe una publicación de una vacante y define campos como datePosted como la fecha de publicación de un anuncio en línea. Proporciona significados para comparar, no una regla de extracción para cada bolsa.

Campo del registro	Conservar	Límite
Fuente	Identidad de la bolsa o feed y alcance del conjunto	Valores iguales de fuentes distintas no son automáticamente la misma publicación
Clave de publicación	Identificador definido por el proveedor cuando se suministra	Una URL o un título no son automáticamente una clave estable
Título bruto	Cadena exacta de la fuente dentro de la retención permitida	No lo sustituyas por una etiqueta normalizada
Ubicación bruta	Texto exacto y partes estructuradas suministradas	No infieras un país ausente desde la configuración regional o el proxy
Etiqueta de empresa	Texto de empresa u organización de la fuente	Marca, entidad legal y agencia siguen siendo distintas salvo evidencia
Campos normalizados	Valor, identificador de regla y versión de mapeo	Un cambio de mapeo inicia otra interpretación, no una reescritura silenciosa
Publicación y expiración	datePosted y validThrough de la fuente cuando existan	Ninguno establece la fecha real de cobertura del puesto ni un cierre confirmado
Observación	Momento de recolección, estado de la fuente y resultado de aceptación	El momento de recolección no es publicación, expiración ni transacción

La documentación de Google sobre JobPosting describe datos estructurados que pueden hacer que una publicación sea elegible para una experiencia de búsqueda de empleo, y enumera campos de ejemplo como identifier, datePosted, validThrough, employmentType, hiringOrganization y jobLocation. La elegibilidad no garantiza exactitud, permiso de acceso ni un marcado idéntico entre bolsas. Usa el vocabulario para nombrar campos y mapea solo lo que la fuente aprobada devuelve realmente.

Versiona la regla de mapeo. Si «Senior» pasa de un grupo de familia de roles a otro, un registro antiguo no debe parecer que siempre usó la nueva regla. Una serie normalizada se puede reconstruir desde valores brutos y una regla registrada; sobrescribir los campos brutos destruye esa capacidad. Retén solo lo que permita el acuerdo de la fuente y mantén los valores brutos dentro del mismo límite de retención aprobado que el registro normalizado.

Esto importa sobre todo cuando dos bolsas describen el mismo rol con formatos distintos. Una puede proporcionar ciudad y país estructurados, otra puede poner ambos en un solo campo de texto y una tercera puede omitir el país mientras nombra un área metropolitana. Una comparación normalizada puede seguir siendo útil, pero necesita una regla que diga qué se infirió y qué se suministró. Registra la ruta del campo de origen o la ubicación de la respuesta para cada valor mapeado, para que un revisor vea si el país vino de un campo del proveedor o de una suposición de la aplicación. Cuando la fuente no proporciona país y el mapeo necesita uno, el valor normalizado debe seguir siendo desconocido. No sustituyas la configuración regional del navegador, la región del proxy ni el idioma de la interfaz. Describen el entorno de observación, no el empleo.

La normalización de empresas necesita una trazabilidad similar. Una bolsa puede etiquetar la misma organización con un nombre visible, un nombre legal o una agencia de reclutamiento. Un identificador de organización proporcionado por la fuente es evidencia más fuerte que una coincidencia de nombre, pero sigue limitado a esa fuente. Registra la etiqueta, el identificador y la regla que conectó dos registros. Mantén visible una relación de baja confianza en lugar de colapsarla en una sola fila de empresa. Eso preserva la capacidad de comparar recuentos por fuente y de retirar una coincidencia cuando nueva evidencia muestre dos organizaciones distintas.

Los campos normalizados también deben llevar una confianza o estado de resolución cuando el mapeo no puede ser decisivo. Una etiqueta de familia de roles puede ser mapped, una ubicación partial y una empresa unresolved. Estos estados son más útiles que una cadena vacía, porque distinguen «no suministrado» de «aún no interpretado». Mantén los mismos estados en exportaciones e informes para que un analista posterior no trate en silencio un valor sin resolver como limpio.

Decidir cuándo un repost es otra ocurrencia

Una bolsa puede volver a publicar un rol con una URL nueva, un identificador interno nuevo o un título modificado. Ninguno de esos cambios prueba por sí solo una vacante nueva, y ninguno prueba continuidad. Mantén la ocurrencia separada salvo que la fuente aprobada establezca una relación.

Observación construida	Evidencia de la fuente	Relación aceptada
Misma clave, título revisado	Clave de publicación sin cambios; la fuente suministra la actualización	Misma ocurrencia con una revisión de campo observada
URL nueva, misma empresa y título visibles	URL cambiada; sin campo de continuidad de la fuente	Relación sin resolver; conservar como ocurrencia separada hasta tener evidencia
Clave nueva, la fuente marca un reemplazo	La fuente relaciona explícitamente la publicación nueva con la anterior	Ocurrencia relacionada; conservar ambas claves y la relación
Mismo título y ciudad en otra bolsa	Fuente distinta y sin clave compartida	Ocurrencia de otra fuente; no fusionar por título y lugar

La tabla es construida, no un comportamiento medido de una bolsa. El modelo de anuncios inmobiliarios aplica la misma disciplina: una ocurrencia de anuncio, el inmueble físico y una oferta son distintos. Para empleos, una ocurrencia de publicación, el rol de la empresa y la candidatura de una persona también son distintos.

Usa una clave limitada a la fuente cuando exista y registra por qué se aceptó una coincidencia o se dejó sin resolver. La coincidencia difusa de título, empresa y ubicación puede proponer un par candidato, pero una propuesta no prueba continuidad. Conserva ambas claves y la etiqueta de relación. Cuando un paso de deduplicación fusiona registros, registra la regla y la evidencia para que una auditoría posterior pueda separar dos vacantes realmente distintas que compartían título.

Una etiqueta de relación debe ser lo bastante estable para sobrevivir a una actualización posterior. Registra si la relación es same_occurrence, related_occurrence o unknown, y guarda la evidencia: una clave compartida, un campo de reemplazo explícito o una referencia canónica de la fuente. No derives la etiqueta solo del título normalizado actual. Un título puede cambiar dentro de una publicación, mientras que un título igual puede acompañar una apertura nueva. La relación describe continuidad de la fuente, no similitud textual.

Cuando una bolsa suministra tanto un identificador de publicación como uno de empleo, mantenlos en campos separados. El identificador de publicación puede cambiar en un repost mientras el de empleo permanece, o al revés según el modelo de la fuente. Registrar solo uno pierde la distinción que necesita la decisión de deduplicación. Si la fuente no proporciona ninguno, conserva la URL y el momento de observación como evidencia, pero marca la ocurrencia como provisional. Los registros provisionales siguen siendo útiles para un análisis limitado; no deben fusionarse en un rol canónico permanente sin más evidencia.

Guarda la referencia de la fuente junto a la clave, en lugar de reemplazarla. Las URL pueden cambiar por parámetros de seguimiento, prefijos de idioma o una migración de la bolsa, y una URL antigua puede redirigir después. Conserva la referencia realmente observada y una forma normalizada de comparación por separado. Una redirección puede mostrar una relación que merece investigación, pero no prueba por sí sola que el destino sea la misma publicación. Trátalo como una pregunta a la fuente, no como una regla de cadena de URL.

Detectar el cierre sin inventarlo

La guía de expiración de Google indica que las publicaciones que ya no aceptan candidaturas deben expirar, y nombra formas de hacerlo: poblar validThrough en el pasado, retirar la página con un 404 o 410, o eliminar los datos estructurados JobPosting. Eso describe una obligación del publicador ante una experiencia de búsqueda. Un recolector que observa una tarjeta ausente o una respuesta cambiada no ha observado necesariamente ninguno de esos eventos.

Evento construido tras la base	Observación	Interpretación aceptada
Actualización de campo aceptada	Misma clave de fuente; la fuente suministra título o ubicación revisados	Revisión observada; sin afirmación de nueva empresa o vacante
Repost con URL nueva	Referencia nueva; sin evidencia de continuidad	Ocurrencia separada con relación sin resolver
La actualización falla	Ningún registro aceptado de la fuente	Incidente de recolección; no borrar el valor aceptado anterior
Tarjeta ausente en una lista limitada	Ventana de lista válida; objetivo no observado	Ausencia limitada; el cierre sigue sin establecerse

datePosted describe la publicación de un anuncio en línea, validThrough describe un límite de validez y el momento de observación registra cuándo miró la aplicación. Un validThrough pasado puede sostener una etiqueta de expiración si se conoce el significado de la fuente, pero no muestra cuándo se cubrió el puesto. Una fila ausente en una lista puede sostener «no observado en esta ventana», no «cerrado». Una página de desafío, un timeout o un rechazo del analizador son un incidente, no un resultado vacío exitoso.

Un ejemplo propio puede reproducir las cuatro filas sin recolectar una bolsa real. Exige una revisión aceptada, una ocurrencia de repost separada, un incidente de actualización y una ausencia limitada. Rechaza cualquier salida que convierta las cuatro en cierres. Esto comprueba la lógica de clasificación de la aplicación; no mide la cadencia de actualización de una bolsa concreta ni prueba que una vacante esté abierta.

La detección de cierre también necesita un límite temporal. Una publicación puede desaparecer de un resultado porque la ventana de consulta se movió, la lista se truncó o la bolsa cambió su orden. Registra el alcance de la consulta o feed, el rango de páginas solicitado y el momento de observación. Si el recolector solo miró la primera página, la ausencia de esa página no es ausencia de la bolsa. Si una lista cambió de orden entre observaciones, un elemento ausente puede ser un artefacto de paginación. Mantén estos resultados separados de un estado de expiración suministrado por la fuente.

El estado propio de la fuente tiene prioridad sobre una inferencia de la aplicación. Si la fuente aprobada devuelve un estado explícito de cerrado o expirado, regístralo con el nombre del campo y el momento de observación. Si devuelve una respuesta de retirada, regístrala separada de una lista vacía exitosa. Si no devuelve nada utilizable por un desafío, timeout o cuerpo malformado, registra un incidente. La aplicación puede producir entonces una vista de ciclo de vida que diga «expirado confirmado por la fuente», «no observado en esta ventana» o «desconocido», en lugar de reducir toda desaparición a una etiqueta de cierre.

Los registros históricos deben conservar la evidencia disponible en ese momento. Un contrato de fuente posterior puede añadir un campo de estado, pero eso no convierte retroactivamente una ausencia antigua en un cierre. Mantén juntos el resultado de observación y la versión del esquema de la fuente. Cuando el esquema cambie, inicia una serie de interpretación nueva o reconcilia los registros antiguos explícitamente. Es la misma disciplina que se usa para los campos normalizados: un cambio de regla no debe parecer un cambio del mundo.

Usar un esquema de ingesta mínimo

Un registro pequeño mantiene revisables las decisiones:

source_namespace, source_posting_key, raw_title, raw_location,
raw_employer_label, employer_ref, normalized_title, normalized_location,
normalization_rule_version, date_posted, valid_through,
query_scope, page_range, source_schema_version,
observed_at, observation_outcome, relation_to_prior_occurrence

El esquema es un registro de aplicación, no un formato obligatorio de bolsa. Un campo ausente queda nulo o desconocido en vez de recibir un valor supuesto. Mantén el resultado de la respuesta de la fuente separado del ciclo de vida interpretado. Si dos observaciones comparten clave de ocurrencia, se pueden comparar sus revisiones; si no, la relación sigue sin resolver hasta que la fuente aporte evidencia.

El límite de acceso a bolsas de empleo separa las páginas públicas de ofertas de los datos autenticados de candidatos. Un esquema de ingesta no cambia ese límite. Los perfiles de candidatos, candidaturas y mensajes quedan fuera del alcance aunque una sesión de navegador pudiera alcanzarlos. Prefiere un feed oficial o una exportación aprobada cuando exista, y detente donde falte permiso o evidencia necesaria.

Elegir una fuente aprobada antes que una ruta de navegador

RFC 9309 afirma que las reglas de robots no son una forma de autorización de acceso. Una página pública que permite rastreo puede no permitir construir un conjunto de datos de mercado o redistribuir ofertas. Los términos aplicables de la bolsa y un acuerdo real de datos deciden qué se puede recolectar y retener. No trates una respuesta exitosa del navegador como permiso.

La documentación de BotBrowser sobre zona horaria, configuración regional e idioma describe entradas de idioma, zona horaria y configuración regional del navegador con detección automática y anulaciones manuales. Esos ajustes pueden mantener explícito un entorno de observación autorizado; las anulaciones manuales requieren una licencia ENT Tier1. No establecen la ubicación de un empleo, el país de una empresa ni el significado del texto de ubicación de una bolsa.

La referencia de configuración de perfiles documenta paquetes de perfil configurables, cuyo paquete debe coincidir con la versión principal, prioridad de configuración y disponibilidad de campos. Un perfil puede hacer reproducibles las entradas declaradas del navegador; no puede iniciar sesión, conceder una licencia de datos ni garantizar que una bolsa devuelva las mismas ofertas entre ejecuciones. Registra el perfil y las condiciones de observación junto a los registros aceptados, y mantén el acuerdo de la fuente como autoridad para acceso y retención.

Preguntas frecuentes

¿Se pueden fusionar los títulos idénticos de dos bolsas en un solo empleo?

Solo con evidencia de la fuente de que describen la misma publicación o rol. El texto igual es un candidato para revisión, no una prueba. Conserva cada ocurrencia de fuente y una relación sin resolver explícita hasta establecer continuidad.

¿Una publicación que desapareció de una lista significa que el empleo se cerró?

No. Una lista limitada puede omitir una publicación por muchas razones, y una actualización fallida no es un resultado vacío. Registra la ausencia y exige evidencia de la fuente, como un estado de expiración o una respuesta de retirada, antes de asignar un cierre.

¿Debe usarse datePosted como momento de recolección?

No. Es la fecha de publicación de un anuncio en línea. Mantén el momento de observación del recolector y datePosted y validThrough de la fuente como campos separados con significados propios.

¿BotBrowser suministra ofertas de empleo o permiso para recolectarlas?

No. Proporciona entradas de configuración documentadas del navegador. No suministra datos de empleo, no inicia sesión, no concede acceso ni establece los términos de una bolsa; usa una fuente aprobada y retén solo lo que el acuerdo permita.

Fuentes

• schema.org JobPosting
• Datos estructurados JobPosting de Google
• RFC 9309
• BotBrowser: zona horaria, configuración regional e idioma
• Configuración de perfiles de BotBrowser

Conclusión práctica

Construye un registro de empleo permitido alrededor de ocurrencias de publicación limitadas a la fuente. Conserva valores brutos y normalizados con una versión de mapeo, separa los reposts hasta que la fuente establezca continuidad y trata publicación, expiración y momento de observación como hechos distintos. Clasifica actualizaciones fallidas y ausencias limitadas sin inventar cierres. Las entradas del navegador pueden hacer reproducible una observación autorizada; la fuente aprobada y su acuerdo determinan qué datos están disponibles, qué significan y qué historial puede retenerse.