Google Jobs Spain: Guía para Publicar Ofertas en España

Publicas una vacante para Senior Backend, abres el ATS al día siguiente y ves volumen. Mucho volumen. Pero entre los CVs no aparece el perfil que te resuelve una migración compleja, te diseña un sistema distribuido o te levanta un pipeline serio de datos.

‍

Ese problema no suele venir de falta de demanda. Suele venir de mala distribución de la oferta y de una descripción pensada para RR. HH. generalista, no para talento técnico senior. Si quieres competir en google jobs spain, no basta con subir la vacante a un portal y esperar. Tienes que hacer que Google la entienda, la muestre bien y la ponga delante de la gente correcta.

‍

Por qué tus ofertas de empleo no atraen al talento que buscas

‍

Lanzas una vacante para Staff Engineer o Senior Data Engineer, entra tráfico, llegan candidaturas y el problema sigue intacto. El perfil que necesitas no aparece. En España lo veo cada semana con CTOs que compiten por el mismo talento en Madrid, Barcelona, Valencia o remoto nacional: la oferta existe, pero no transmite nivel, contexto ni condiciones suficientes para que un senior quiera dedicarle dos minutos.

‍

El fallo suele empezar mucho antes de la entrevista. Muchas empresas siguen publicando roles técnicos como si bastara con cubrir un hueco en organigrama. Usan títulos genéricos, esconden el rango salarial, meten el stack en un bloque final y obligan al candidato a descifrar si el reto merece la pena. Con perfiles junior todavía puedes generar volumen. Con perfiles senior, esa ambigüedad filtra en tu contra.

‍

En tech, la primera criba la hace el candidato.

‍

Quien ya está bien colocado compara muy rápido: alcance real del puesto, deuda técnica, autonomía, equipo, modalidad, banda y capacidad de influencia. Si compites contra grandes tecnológicas o contra startups extranjeras contratando en remoto desde España, una oferta opaca queda fuera de juego antes del clic. No necesitas copiar sus salarios para ser competitivo, pero sí explicar muy bien por qué merece la pena hablar contigo.

‍

El bloqueo no está solo en la compensación

‍

Muchos equipos se centran en la banda salarial y descuidan otro punto que pesa igual o más en la parte alta del mercado: la confianza. Un Senior Backend, un DevOps con experiencia en entornos críticos o un ML Engineer no responde bien a una oferta que parece escrita por plantilla. Si la vacante no deja claro qué problema técnico va a resolver, con qué stack trabajará, quién toma decisiones y qué margen tendrá para mejorar arquitectura o procesos, la interpretación suele ser mala.

‍

También hay un factor local que las agencias generalistas suelen ignorar. En España, publicar mal una vacante no solo reduce conversión. También te mete en zonas incómodas de cumplimiento si la modalidad remota no está bien delimitada, si la ubicación induce a error o si las condiciones básicas quedan demasiado difusas para el candidato. En hiring tech, atraer bien y publicar bien van juntos.

‍

Qué suele funcionar mejor con talento técnico senior

‍

Las ofertas que traen conversaciones útiles comparten varios rasgos:

• Título reconocible en mercado. “Senior Platform Engineer”, “Backend Engineer Go”, “Engineering Manager”.
• Alcance técnico concreto. Migración, escalado, plataforma interna, datos, producto, seguridad.
• Stack visible desde arriba. Sin obligar al candidato a leer media página.
• Modalidad y ubicación precisas. Remoto en España, híbrido en Barcelona, presencial en Madrid.
• Rango salarial o marco de compensación claro. Si no publicas cifra, al menos acota expectativas con honestidad.
• Proceso de aplicación corto y móvil-friendly. Cada campo extra reduce candidatos buenos.

‍

Una página como Trabaja Con Nosotros sirve para revisar algo básico pero muy útil: acceso claro, jerarquía simple y una entrada directa a las vacantes. No resuelve por sí sola el hiring técnico, pero evita varios errores de presentación que siguen costando entrevistas de calidad.

‍

Si tu equipo todavía publica vacantes sin criterio común, conviene ordenar esa base antes de tocar la parte de visibilidad en Google. Esta guía sobre cómo publicar una oferta de empleo te ayuda a corregir estructura, mensaje y expectativa antes de llevar la oferta a un canal donde cada detalle pesa.

‍

El Mecanismo de Google for Jobs que Debes Entender

‍

Google for Jobs no es un portal de empleo al uso. No funciona como InfoJobs, LinkedIn Jobs o Wellfound. Es una capa de agregación y presentación dentro del propio buscador. Eso cambia por completo la estrategia.

Cuando Google detecta una URL de empleo bien estructurada, puede mostrarla en sus resultados enriquecidos. Ahí entran en juego el título, la empresa, la ubicación, el tipo de trabajo y, si lo haces bien, el salario. No estás compitiendo solo por SEO clásico. Estás compitiendo por ser elegible y entendible para un formato específico de búsqueda de empleo.

‍

Google premia estructura, no creatividad vacía

‍

Muchos equipos intentan “diferenciarse” con títulos originales como “Ninja del dato” o “Arquitecto del futuro cloud”. Eso no ayuda. Google necesita semántica clara. Y el candidato técnico también.

‍

Lo que mejor funciona es esto:

• Título estándar del mercado. “DevOps Engineer”, “ML Engineer”, “Senior Frontend React”.
• Ubicación clara. Madrid, Barcelona, remoto en España, híbrido.
• Descripción legible. Sin bloques eternos y sin marketing corporativo.
• Campos estructurados que confirmen lo anterior a nivel máquina.

‍

Google no adivina. Interpreta. Si tu vacante está mal etiquetada o mezclada con contenido irrelevante, no la va a tratar como una oportunidad de empleo sólida.

‍

Por qué esto importa más en hiring tech

‍

En hiring técnico, la calidad del clic importa más que el volumen. Prefiero una vacante con menos tráfico y mejor intención que una avalancha de candidaturas irrelevantes.

‍

Google usa su propio ecosistema para contratar en España. En 2026 tenía 14 vacantes técnicas directas listadas, según las ofertas de Google Espagne en Glassdoor. La señal es clara. Si el propio Google usa este tipo de visibilidad para captar talento, no tiene sentido que una empresa tech siga dependiendo solo de portales saturados.

‍

Cómo descubre Google tus ofertas

‍

Google suele llegar a tus vacantes por tres vías:

1. Rastreo normal del sitio. Si la URL es pública, indexable y está bien enlazada.
2. Integración vía ATS. Algunos sistemas ya exponen la información de forma compatible.
3. Sitemaps específicos. Muy útiles cuando tienes careers site propio o desarrollo custom.

‍

El mayor error aquí no es técnico. Es operativo. El equipo publica una oferta, la cierra internamente, pero deja la URL viva sin actualizar. O la URL cambia cada vez que se edita el puesto. O el ATS genera páginas pobres, lentas y con contenido duplicado. Todo eso debilita la presencia en google jobs spain.

‍

Qué decide el clic

‍

Antes del clic, el candidato evalúa tres cosas:

• Si el puesto coincide con lo que busca
• Si la empresa parece seria
• Si merece la pena entrar en el proceso

‍

Por eso el snippet enriquecido importa tanto. Un logo reconocible, un cargo bien nombrado y una ubicación coherente reducen fricción. Si además aparece salario, mejoras todavía más la calidad del tráfico, porque filtras a quien busca roles senior reales y espantas a quien entra por curiosidad.

‍

Guía Práctica del Marcado Schema JobPosting

‍

Publicas una vacante para un Staff Backend Engineer en Madrid, el hiring manager necesita entrevistas esta semana y el equipo de People ya está empujando sourcing porque no entra pipeline cualificado. Revisas la página. El puesto aparece como “IC4 Platform”, no deja claro si admite remoto desde España y el salario solo vive en un PDF interno. Google puede rastrear esa URL, sí. Entenderla bien es otra cosa.

El marcado JobPosting corrige justo ese problema. No sirve solo para que Google detecte que hay una oferta. Sirve para que clasifique bien seniority, ubicación, modalidad y compensación. En hiring tech en España, esa diferencia cambia la calidad del tráfico. Y cambia algo más importante para un CTO. Cuánto tiempo pierde el equipo entrevistando candidatos que nunca iban a aceptar la banda ni el modelo de trabajo.

‍

Si tu equipo ya usa JSON-LD en otras partes del sitio, la implementación no es compleja. La dificultad real está en decidir qué datos publicar, cómo mantenerlos actualizados y cómo reflejar restricciones reales sin meterte en mensajes ambiguos o riesgos legales.

‍

Campos que conviene resolver bien desde el primer día

‍

Empieza por lo que Google y el candidato necesitan para interpretar la vacante con precisión:

• title. Usa el nombre que el mercado busca. “Senior Data Engineer” o “Frontend Engineer React” funcionan mejor que títulos internos o creativos.
• description. Describe alcance, stack, contexto del producto, responsabilidades y requisitos. Sin copiar texto de employer branding.
• hiringOrganization. Nombre coherente con la marca empleadora y logo accesible.
• datePosted y validThrough. Mantén fechas reales. Una vacante expirada erosiona confianza y contamina el funnel.
• employmentType. Define si es indefinido, temporal, tiempo completo o contrato.
• jobLocation. En España importa mucho. Madrid, Barcelona y Valencia no convierten igual. Tampoco convierten igual un rol onsite y uno híbrido.

‍

Hasta aquí cubres elegibilidad básica. Para perfiles tech senior, hay tres campos que suelen separar una vacante útil de una vacante genérica.

‍

baseSalary mejora el filtrado antes de la primera llamada

‍

En España, ocultar salario en roles técnicos senior suele llenar el pipeline de candidatos desalineados. El problema no es solo el volumen. Es la fricción posterior. Si compites contra multinacionales, scaleups con equity o remoto internacional, el candidato experimentado necesita calibrar si merece la pena entrar en proceso.

‍

Por eso baseSalary pesa tanto. Si puedes publicar rango, publícalo. Si tu política no permite cifra exacta, usa una banda razonable. Lo importante es que sea coherente con el nivel real del puesto, con la ciudad y con el mercado que estás atacando.

‍

En búsquedas de backend, data, security o infra, la transparencia salarial reduce entrevistas perdidas. También te obliga a ordenar algo interno. Si el hiring manager pide senioridad alta y la banda sigue anclada en mercado medio, el problema no está en Schema. Está en la estrategia de contratación.

‍

Regla práctica: en perfiles escasos, una banda salarial clara suele mejorar la calidad de candidatura más que una lista larga de perks.

‍

jobLocationType no puede contradecir el texto de la oferta

‍

Muchos equipos escriben “remote friendly” en la descripción y luego dejan el marcado como si el puesto fuera presencial. Ese desajuste genera dos problemas. El candidato entra con una expectativa incorrecta. Google recibe señales menos claras sobre la modalidad real.

‍

Si el puesto es híbrido, márcalo como híbrido. Si es remoto, indícalo de forma estructurada. Si exige presencia parcial en Madrid por coordinación con producto o por acceso a sistemas, dilo sin rodeos.

‍

Los perfiles senior agradecen esa precisión. En España, además, evita conversaciones absurdas al final del proceso.

‍

applicantLocationRequirements evita promesas vagas sobre remoto

‍

Este campo ayuda mucho cuando el rol admite trabajo remoto, pero solo desde España. Es una situación habitual por contrato laboral, cotización, política de nómina, seguridad o cobertura legal de la entidad empleadora.

‍

Poner “remoto” sin ese límite atrae candidatos desde cualquier país. Luego llega el descarte y daña la percepción de la empresa. En hiring técnico, la reputación se deteriora rápido. Sobre todo en nichos pequeños donde los candidatos comparten experiencias entre ellos.

‍

El JSON-LD mínimo que sí usaría

‍

Este ejemplo cubre lo que suelo pedir a equipos que necesitan salir bien en Google for Jobs sin esperar una reimplementación completa del careers site.

{"@context": "https://schema.org","@type": "JobPosting","title": "Senior Backend Engineer Python","description": "Buscamos un Senior Backend Engineer para diseñar y mantener servicios escalables en Python. Trabajarás con arquitectura distribuida, APIs, PostgreSQL, mensajería y despliegues en cloud. Responsabilidades: diseño técnico, desarrollo, revisión de código, observabilidad y colaboración con producto y plataforma. Requisitos: experiencia sólida en backend, Python, SQL, diseño de sistemas y entornos de producción.","identifier": {"@type": "PropertyValue","name": "Nombre de tu empresa","value": "SBE-PY-2026-01"},"datePosted": "2026-03-20","validThrough": "2026-04-20T23:59","employmentType": "FULL_TIME","hiringOrganization": {"@type": "Organization","name": "Nombre de tu empresa","sameAs": "https://www.tuempresa.com","logo": "https://www.tuempresa.com/logo.png"},"jobLocationType": "HYBRID","jobLocation": {"@type": "Place","address": {"@type": "PostalAddress","addressLocality": "Madrid","addressRegion": "Comunidad de Madrid","addressCountry": "ES"}},"applicantLocationRequirements": {"@type": "Country","name": "Spain"},"baseSalary": {"@type": "MonetaryAmount","currency": "EUR","value": {"@type": "QuantitativeValue","minValue": 70000,"maxValue": 90000,"unitText": "YEAR"}},"directApply": true}

‍

Errores habituales que deterioran visibilidad y conversión

‍

El fallo raro es técnico. El fallo frecuente es operativo. La vacante existe, pero los datos que la describen no coinciden con la realidad del proceso.

‍

Veo estos problemas una y otra vez en empresas tech que contratan bien por referral, pero mal en canales orgánicos:

• Títulos internos como “IC4 Backend Platform” o “Developer III”.
• Descripciones pobres que hablan de cultura y perks, pero no del trabajo real.
• validThrough caducado mientras la oferta sigue publicada.
• Duplicados de URL por cambios del ATS o por versiones en varios idiomas mal canonizadas.
• Salario visible solo en texto libre y ausente en baseSalary.
• Ubicación incompleta cuando el puesto admite remoto dentro de España o híbrido por sedes.
• directApply marcado como true aunque el candidato acaba en formularios largos, redirecciones o pasos extra.

‍

Ese último punto importa más de lo que parece. Si prometes aplicación directa y luego envías al candidato a un flujo pesado, sube el abandono. En perfiles senior, mucho más.

‍

Cómo redactar description para atraer al perfil correcto

‍

La descripción tiene que ayudar a Google a clasificar la vacante y al candidato a decidir si merece una conversación. No hace falta escribir más. Hace falta escribir mejor.

‍

Una buena description deja claras estas capas:

1. Qué problema resuelve el rol
2. Qué stack y entorno va a tocar
3. Qué nivel de autonomía y ownership exige
4. Qué experiencia mínima tiene sentido
5. Qué condiciones del proceso o del puesto son relevantes

‍

En un rol de MLOps, por ejemplo, conviene hablar de despliegue de modelos, observabilidad, pipelines, versionado, coste de infraestructura, integración con producto y responsabilidad sobre producción. “Buscamos talento apasionado por la IA” no filtra a nadie.

‍

Tampoco conviene inflar requisitos. Si pides senior, define senior por contexto de responsabilidad, no por una lista arbitraria de años. En España, muchos candidatos potentes descartan ofertas que parecen redactadas por plantilla legal y no por el equipo técnico.

‍

Qué priorizar si solo puedes arreglar una parte esta semana

‍

Si hay poco tiempo, corrige primero lo que afecta de verdad a matching y filtrado:

• title con naming de mercado
• description concreta, técnica y sin relleno
• jobLocation y jobLocationType consistentes con la realidad
• baseSalary con rango si es posible
• datePosted y validThrough actualizados
• applicantLocationRequirements cuando el remoto tenga límites geográficos reales
• directApply solo si el flujo de candidatura lo justifica

‍

Con eso ya mejoras la interpretación de la vacante y reduces ruido en entrada. Para una empresa que compite por senior engineers en España, ese efecto vale más que cualquier retoque cosmético del careers site.

‍

Automatiza la Publicación con tu ATS y Sitemaps

‍

El marcado manual sirve para validar una primera vacante. Para operar de verdad, no. Si tu equipo contrata varios perfiles al mes o recicla openings con frecuencia, necesitas un sistema que publique, actualice y retire ofertas sin depender de alguien editando JSON a mano.

La decisión práctica suele caer en dos caminos. ATS con salida bien resuelta o careers site propio con sitemap y schema controlado por tu equipo. No hay una opción universalmente mejor. Hay una mejor para tu stack y tu ritmo de contratación.

‍

Opción uno con ATS

‍

Si usas herramientas como Greenhouse, Lever o Personio, lo primero que miraría no es la marca. Miraría cómo renderizan la página de la vacante, qué control te dejan sobre structured data y si las URLs son estables.

‍

Las ventajas del ATS son obvias:

• Centraliza publicación y pipeline
• Reduce errores humanos
• Permite cerrar vacantes y reflejarlo de forma consistente
• Facilita a People y Hiring Managers trabajar sobre el mismo flujo

Pero tiene límites claros.

• Menos control sobre markup fino
• Diseños genéricos
• Dependencia del proveedor para ciertos cambios
• Páginas lentas o pobres si la implementación es floja

‍

Si tu ATS ya expone páginas limpias, indexables y bien estructuradas, no compliques la arquitectura. A veces la solución correcta es aceptar un pequeño límite de personalización a cambio de consistencia operativa.

‍

Opción dos con careers site propio

‍

Esta opción suele encajar mejor en scaleups con equipo web sólido o producto con recursos de frontend y SEO técnico. Construyes tu página de empleo en tu dominio, controlas el HTML, el JSON-LD, la canonical y la experiencia de aplicación.

‍

Lo bueno:

• Control total del contenido
• Mejor employer branding
• Integración más limpia con analítica
• Capacidad de adaptar cada vacante al tipo de perfil

‍

Lo malo también cuenta:

• Más mantenimiento
• Más coordinación entre RR. HH., ingeniería y marketing
• Mayor riesgo de que algo deje de actualizarse si nadie es dueño del proceso

‍

El sitemap no es glamour. Es disciplina

‍

Si tienes desarrollo a medida, crea un sitemap específico para vacantes. No hace falta complicarlo con lógica innecesaria. Lo importante es que incluya solo ofertas activas, con sus URLs finales, y que se actualice cuando abres o cierras posiciones.

‍

Un sitemap bien mantenido ayuda en tres frentes:

1. Descubrimiento rápido de nuevas vacantes.
2. Retirada ordenada de URLs caducadas.
3. Menos dependencia de enlazado manual interno.

‍

Si una vacante deja de existir, retírala de verdad. No la conviertas en una página huérfana con un “esta posición ya no está disponible” y nada más.

‍

Qué elegir según tu situación

‍

No hace falta teorizar demasiado. La decisión suele salir de estas condiciones.

‍

Elige ATS si

• Contratas de forma continua pero sin equipo técnico dedicado a careers
• Tu prioridad es velocidad operativa
• Quieres que Talent Acquisition publique sin tickets de desarrollo
• Tu marca empleadora aún no necesita una experiencia muy diferenciada

‍

Elige site propio si

• Contratas perfiles complejos y compites por talento senior
• Necesitas controlar SEO, schema y contenido a detalle
• Tu equipo quiere medir mejor qué openings atraen a qué tipo de candidato
• Tu marca técnica ya forma parte de la decisión del candidato

‍

El peor escenario posible

‍

El peor escenario no es usar ATS. Tampoco es usar una web propia. El peor escenario es el híbrido desordenado. Vacantes duplicadas entre ATS y careers site, títulos distintos, URLs distintas y estados distintos.

‍

Ahí Google recibe señales mezcladas y el candidato también. Si vas a operar en google jobs spain, decide un origen de verdad. Un solo lugar manda. Todo lo demás debe sincronizarse con eso.

‍

Optimización SEO y Legal para el Mercado Español

‍

Una oferta técnicamente indexable puede seguir siendo mediocre. La razón suele estar en el contenido. En hiring tech, la mayoría de las vacantes fallan por lenguaje impreciso, ubicación mal definida o por esquivar detalles contractuales que el candidato quiere ver antes de hablar con nadie.

El título manda más de lo que parece

‍

Si buscas un DevOps con experiencia real en AWS, no publiques “Experto en Cloud”. Si necesitas un backend con Java y sistemas de alta concurrencia, dilo. Google interpreta mejor títulos concretos. El candidato técnico también.

‍

Estos pares ilustran bien la diferencia:

• Mejor: Senior DevOps Engineer AWS
• Peor: Especialista en infraestructura
• Mejor: Machine Learning Engineer NLP
• Peor: Ingeniero de IA
• Mejor: Data Engineer Spark y Python
• Peor: Perfil de datos

‍

El título correcto no limita. Filtra. Y en contratación técnica, filtrar bien es una ventaja.

‍

La descripción debe sonar a trabajo real

‍

Las mejores ofertas enseñan contexto. Qué equipo es, qué sistemas toca, qué responsabilidad tendrá la persona y con quién trabajará. Las peores mezclan frases de employer branding con listas de adjetivos.

‍

Haz esto:

• Define el alcance. ¿Servicio crítico? ¿Plataforma interna? ¿Producto B2B?
• Nombra stack y herramientas. Python, Go, Kubernetes, GCP, Kafka, Terraform.
• Explica seniority por expectativas, no por etiquetas vacías.
• Aclara modalidad. Presencial, híbrido, remoto dentro de España.

‍

No hagas esto:

• Hablar de “entorno joven y dinámico”
• Ocultar si hay guardias
• No decir quién toma decisiones técnicas
• Pedir de todo y ofrecer una descripción genérica

‍

Un ingeniero senior no aplica por adjetivos. Aplica por contexto, nivel de reto y condiciones claras.

‍

Remoto, híbrido y geografía real

‍

El campo jobLocationType importa mucho porque la geografía ya no se interpreta como antes. El auge del trabajo remoto en España, con profesionales tech moviéndose a zonas de menor coste, ha hecho que la flexibilidad pese más en la decisión. Además, el 41% de los directivos españoles reportan dificultades para encontrar talento cualificado, según el análisis sobre trabajo remoto tech y movilidad en España. Si puedes contratar en más lugares, dilo bien y estructúralo bien.

‍

La mala práctica habitual es publicar “Madrid” por costumbre, aunque el equipo acepte remoto nacional. Eso te recorta alcance sin necesidad. La buena práctica es distinguir con claridad entre:

• Remoto en España
• Híbrido en Madrid o Barcelona
• Presencial con días fijos
• Remoto con viajes puntuales

‍

Lo legal también afecta a la conversión

‍

En España, las ofertas ambiguas generan desconfianza. No solo por normativa. También porque el talento técnico está cansado de descubrir condiciones relevantes en la tercera entrevista.

‍

Conviene dejar claro desde el principio:

• Tipo de contrato
• Modalidad de trabajo
• Rango salarial si tu política lo permite
• Requisitos formales reales, no inflados
• Elegibilidad para trabajar en España cuando aplique

‍

Si contratas talento internacional o perfiles junior que llegan desde estudios superiores, puede ser útil enlazar recursos claros sobre autorización laboral. Por ejemplo, esta guía sobre el permiso de estudiante autoriza a trabajar en España ayuda a resolver una duda frecuente sin convertir la oferta en un texto legalista.

‍

Y si estás diseñando posiciones de entrada o fórmulas vinculadas a formación, conviene revisar bien los requisitos del contrato en prácticas antes de publicar algo que luego no puedas sostener.

‍

Qué tono usar en una oferta tech en España

‍

Mi recomendación es simple. Escribe como hablaría un Engineering Manager competente. Claro, específico y sin maquillaje.

‍

Un marco útil para revisar tu copy

• Precisión técnica. ¿El stack está bien nombrado?
• Verdad operativa. ¿La modalidad y el proceso reflejan la realidad?
• Señales de seriedad. ¿Hay salario, contrato o al menos criterios concretos?
• Legibilidad. ¿Se entiende en móvil y en menos de dos minutos?

‍

Si una vacante no pasa ese filtro, no la arregla ningún schema.

‍

Mide el Éxito y Tu Checklist Operativo Final

‍

Si publicas en google jobs spain y no miras resultados, estás operando a ciegas. Lo mínimo es revisar cómo Google interpreta tus ofertas y qué vacantes generan impresiones, clics y errores de elegibilidad. Para eso, Google Search Console debería estar en la rutina del equipo que gestiona careers.

‍

No hace falta montar un sistema complejo desde el primer día. Empieza por observar tres cosas: si Google detecta los datos estructurados, si hay errores en páginas concretas y si ciertas vacantes reciben visibilidad mientras otras no. Cuando una oferta no despega, el problema suele estar en el título, en la estructura del contenido o en la calidad de la URL.

‍

Qué revisar cada vez que publicas

‍

Las ofertas de Google en España suelen exigir como mínimo “Bachelor’s degree o experiencia práctica equivalente” y “2 años de experiencia en desarrollo de software”, según las vacantes publicadas en Google Careers para España. El aprendizaje útil aquí no es copiar a Google. Es ser igual de específico.

‍

Checklist operativo

‍

• Título correcto. Usa naming de mercado. Nada de títulos internos ni creativos.
• Descripción útil. Explica contexto, stack, responsabilidades y requisitos reales.
• Schema presente. Verifica JobPosting en producción, no solo en staging.
• Salario estructurado. Si puedes publicarlo, inclúyelo en baseSalary.
• Ubicación bien definida. Presencial, híbrido o remoto reflejados también en el markup.
• Fechas vigentes. Revisa publicación y caducidad.
• URL única y estable. Sin duplicados entre ATS, subdominios y careers site.
• Aplicación directa. Menos fricción, mejor. Especialmente en móvil.
• Estado de la vacante. Si está cerrada, retírala o redirígela con criterio.
• Search Console revisado. Corrige errores antes de publicar nuevas posiciones.

‍

Qué métrica sí importa

‍

No me obsesionaría con el volumen bruto de candidaturas. Prefiero medir señales de calidad:

• ¿Llegan perfiles del seniority correcto?
• ¿La gente entiende el rol antes de la primera llamada?
• ¿Baja el porcentaje de entrevistas desperdiciadas?
• ¿Mejora la relación entre clic y candidatura válida?

‍

Para equipos que también contratan perfiles analíticos o de datos, esta lectura de qué es business intelligence puede ayudar a ordenar mejor qué métricas seguir y cómo separar señal de ruido.

‍

Publicar bien una oferta técnica no es una tarea administrativa. Es una decisión de distribución, de producto y de posicionamiento en mercado. Si lo tratas como un trámite, atraerás candidatos como si fuera un trámite.

‍

Si necesitas ayuda para contratar ingenieros, perfiles de IA, datos, cloud o ciberseguridad en España sin perder semanas filtrando ruido, Kulturo trabaja con CTOs y founders que quieren procesos de hiring técnicos, rápidos y bien calibrados.