Schema offerte di lavoro: validarlo e capire se funziona

Hai aggiunto il markup JobPosting alle pagine delle offerte di lavoro e Google Search Console segnala lo stato come "Valido", ma questo non dice se l'annuncio genera davvero candidature. La validazione tecnica e la prova che il risultato arricchito porta traffico reale sono due domande diverse, e la seconda è quella più difficile da rispondere perché il traffico proveniente da Google per il lavoro è tra i più difficili da isolare negli strumenti di analisi che usi ogni giorno.

In questo articolo vediamo prima come leggere il rapporto dedicato in Search Console e cosa significano gli errori e gli avvisi più frequenti per lo schema delle offerte di lavoro, poi affrontiamo il problema più concreto: capire se quelle impression si traducono in candidature reali, quando lo strumento di analytics che usi non è stato pensato per distinguere quel tipo di traffico dal resto della ricerca organica.

Il rapporto dedicato in Search Console

Google Search Console ha una sezione specifica per i risultati arricchiti delle offerte di lavoro, separata dal rapporto generico sui dati strutturati. La trovi sotto la voce Miglioramenti, oppure cercando "Offerte di lavoro" nel menu laterale: mostra il numero di pagine valide, quelle con avvisi e quelle con errori, e viene aggiornato ogni volta che Google riesegue la scansione delle pagine interessate.

Una pagina "Valida" ha superato tutti i controlli obbligatori sul markup: significa che lo schema può essere idoneo per comparire nell'esperienza Google dedicata al lavoro, non che comparirà per forza. L'idoneità tecnica è una condizione necessaria, non sufficiente: servono anche criteri di policy che il rapporto sui dati strutturati non verifica direttamente, come una sola offerta per pagina e un contenuto coerente con quanto dichiarato nel markup.

Le pagine "Valide con avvisi" restano comunque idonee, ma con dati incompleti: un avviso non blocca la comparsa, segnala solo che alcuni campi consigliati mancano e che Google mostrerà l'annuncio con meno informazioni a corredo, per esempio senza una fascia salariale indicata.

Gli errori che bloccano davvero l'idoneità

I campi obbligatori per JobPosting sono pochi, ma la loro assenza è la causa più comune di errore bloccante: title, description, datePosted, hiringOrganization e jobLocation, oppure applicantLocationRequirements per le posizioni interamente da remoto. Se anche uno solo di questi campi manca o è vuoto, Search Console classifica l'intera pagina come non valida e la esclude dall'idoneità, non solo il singolo campo mancante.

Un errore meno ovvio riguarda i valori fuori formato. employmentType deve usare uno dei valori enumerati da Google, come FULL_TIME o PART_TIME, e non una stringa libera scritta a mano come "Tempo pieno". Vale lo stesso per datePosted e validThrough, che devono seguire il formato ISO 8601: una data scritta in un formato locale diverso, senza che un parser la converta correttamente prima della pubblicazione, viene scartata silenziosamente, e il campo risulta mancante agli occhi di Google anche se è visibile leggendo il codice sorgente della pagina.

• title, description, datePosted, hiringOrganization, jobLocation, oppure applicantLocationRequirements per il remoto: campi obbligatori
• employmentType: deve usare un valore enumerato, non testo libero
• datePosted e validThrough: devono essere in un formato di data valido secondo ISO 8601

Gli avvisi che non bloccano ma penalizzano la resa

baseSalary è il caso più frequente: non è un campo obbligatorio, ma la sua assenza genera un avviso e riduce la competitività dell'annuncio nei risultati, dove Google tende a privilegiare le inserzioni con fascia salariale visibile rispetto a quelle che non la mostrano. Quando il dato esiste ma viene gestito con riserva, per esempio perché negoziato individualmente, vale la pena valutare comunque un intervallo indicativo piuttosto che ometterlo del tutto.

Un secondo avviso comune riguarda la posizione geografica. Per un annuncio ibrido o parzialmente da remoto, indicare solo il paese senza una città genera un avviso di posizione troppo generica, e questo riduce la probabilità che l'offerta compaia per ricerche locali specifiche, anche quando l'azienda ha effettivamente una sede in quella città.

Anche l'assenza di un identificativo univoco per ogni offerta, il campo identifier, produce un avviso. Senza un identificativo stabile e distinto per ciascuna posizione, Google fatica a distinguere un annuncio aggiornato da uno duplicato, e questo può portare a un consolidamento non voluto di più posizioni realmente diverse sotto un'unica scheda nei risultati.

validThrough e il ciclo di vita dell'annuncio

Google tratta ogni JobPosting come un contenuto con una scadenza intrinseca. Se validThrough è nel passato, oppure se il campo manca del tutto e Google stima autonomamente che l'annuncio sia scaduto, la scheda viene rimossa dall'esperienza dedicata al lavoro anche se la pagina resta online e indicizzata normalmente nella ricerca organica generale. È una delle cause più comuni dietro la sensazione che "l'annuncio sia sparito da Google mentre la pagina è ancora lì": sono due sistemi distinti, con regole di idoneità diverse tra loro.

Il problema opposto è altrettanto frequente: posizioni chiuse da settimane che restano tecnicamente valide perché nessuno ha aggiornato validThrough o rimosso la pagina corrispondente. Search Console non segnala questa situazione come un errore, perché dal punto di vista sintattico lo schema resta corretto; ma un volume crescente di offerte scadute e ancora "valide" è il tipo di rumore che rende più difficile, nel tempo, distinguere quali pagine stanno davvero generando idoneità utile rispetto a quelle che occupano solo spazio nel rapporto.

Ripubblicare lo stesso annuncio con un nuovo datePosted per aggirare la scadenza, senza che la posizione sia realmente riaperta, è un comportamento che rientra nelle indicazioni sui contenuti ingannevoli: la data dichiarata deve riflettere una pubblicazione reale, non un semplice refresh cosmetico pensato per restare visibili più a lungo.

Perché il traffico da Google Jobs si nasconde negli strumenti di analisi

Qui inizia la parte più difficile del problema. L'esperienza Google dedicata al lavoro non è un canale a sé nei rapporti standard di analisi del traffico: quando una persona clicca da quell'esperienza verso la pagina dell'offerta, l'evento arriva quasi sempre classificato come normale traffico organico di ricerca, indistinguibile da un click ottenuto tramite un risultato di ricerca tradizionale sulla stessa identica URL. Non esiste un canale predefinito riconoscibile da isolare a valle.

La conseguenza pratica è che una pagina di offerta di lavoro può ricevere traffico sia dal risultato di ricerca classico sia dall'esperienza dedicata al lavoro, e i due si sommano nello stesso rigo di dati senza che lo strumento di analisi distingua l'origine specifica. Un aumento delle impression o dei click nel rapporto di Search Console dedicato alle offerte di lavoro non produce automaticamente un incremento visibile e separato nelle sessioni organiche della stessa pagina, perché il conteggio delle sessioni a valle non è segmentato per tipo di comparsa nei risultati.

Su dispositivo mobile la situazione si complica ulteriormente. Alcuni click che partono dall'esperienza dedicata al lavoro avvengono all'interno di superfici integrate, e possono non trasmettere in modo completo le informazioni di provenienza della ricerca: la sessione arriva quindi lato server classificata come traffico diretto, invece che come ricerca organica. Un aumento del traffico diretto verso le pagine delle offerte, senza una causa esterna nota che lo spieghi, è spesso il sintomo di questo fenomeno più che una prova diretta e definitiva.

Come isolare comunque il segnale utile

Il punto di partenza resta Search Console, non lo strumento di analisi generico del sito: il rapporto sui risultati arricchiti per le offerte di lavoro mostra impression e click filtrati specificamente per quel tipo di comparsa nei risultati. Nel rapporto generale sul Rendimento, il filtro sull'aspetto nella ricerca, impostato sulla voce relativa agli elenchi di lavoro, isola le query e le pagine che hanno effettivamente generato quella visualizzazione specifica, separandole dal resto del traffico organico registrato sulla stessa URL.

Confrontare l'andamento di quel filtro nelle settimane precedenti e successive all'implementazione dello schema è il test più affidabile a disposizione: se le impression segmentate per quella comparsa specifica crescono in modo coerente con il numero di offerte effettivamente pubblicate, lo schema sta facendo il suo lavoro, anche quando lo strumento di analisi generico del sito non lo conferma in modo diretto.

Un secondo segnale indiretto utile è la frequenza con cui Googlebot esegue nuovamente la scansione delle pagine di offerta, visibile nei log del server. Google tende a ricrawlare più spesso le pagine con un JobPosting valido rispetto a contenuti statici equivalenti, proprio perché deve verificare con una certa regolarità che l'annuncio sia ancora aperto. Un calo improvviso nella frequenza di scansione su quelle specifiche URL, in assenza di altre cause note, è spesso un indizio che l'idoneità è stata persa prima ancora che il rapporto di Search Console venga aggiornato di conseguenza.

Dove è tecnicamente possibile, isolare il pattern di URL delle pagine di offerta in un segmento o in una vista dedicata dello strumento di analisi, anche solo tramite un filtro sul percorso della pagina, permette quantomeno di osservare l'andamento aggregato di quella famiglia di pagine nel tempo, pur senza poter separare al loro interno il click arrivato dall'esperienza dedicata al lavoro da quello arrivato da un risultato di ricerca classico sulla stessa URL.

Schema valido ma zero idoneità: cosa controllare prima

Quando lo stato in Search Console è "Valido" ma il rapporto sulle offerte di lavoro mostra zero pagine idonee, oppure un numero che non cresce nonostante nuove pubblicazioni, la causa quasi sempre non è nello schema in sé. Il primo controllo riguarda la policy sul numero di offerte per pagina: una sola JobPosting per pagina è richiesta esplicitamente, e una pagina che elenca più posizioni sotto un unico markup, o che ripete lo stesso schema su una pagina di categoria, non viene mai considerata idonea, indipendentemente da quanto sia corretta la sintassi.

Il secondo controllo riguarda la distinzione tra datore di lavoro diretto e aggregatore di offerte. I siti che pubblicano posizioni per conto di terzi, come bacheche di lavoro o portali che aggregano annunci da più fonti, devono rispettare con particolare attenzione le linee guida sui contenuti delle offerte, per esempio indicare in hiringOrganization l'azienda che assume davvero ed evitare annunci duplicati o scaduti: le violazioni possono rendere le pagine non idonee anche con uno schema formalmente corretto.

Il terzo controllo riguarda la copertura geografica e linguistica: l'esperienza Google dedicata al lavoro non è disponibile con la stessa profondità in tutti i mercati, e un dominio che pubblica offerte per un paese dove la funzione non è pienamente attiva può avere uno schema perfettamente valido senza generare mai impression in quella superficie specifica, semplicemente perché quella superficie non esiste ancora per quel mercato nella forma attesa.

Infine vale la pena escludere la causa più banale di tutte: un noindex introdotto per errore dopo l'implementazione dello schema, oppure un blocco nel file robots.txt aggiunto in un secondo momento, che rende irrilevante la correttezza del markup perché la pagina non viene più nemmeno presa in considerazione per l'indicizzazione a monte.

Il test dei risultati rich e il rapporto di Search Console non dicono la stessa cosa

Lo strumento di test dei risultati multimediali rich verifica una singola URL nel momento in cui viene interrogato: conferma che il markup è sintatticamente corretto e simula come Google lo interpreterebbe, ma non garantisce affatto che quella pagina risulti idonea nell'indice reale, perché non tiene conto della policy applicabile, della cronologia di scansione né di segnali valutati a livello dell'intero dominio.

Il rapporto in Search Console, al contrario, riflette lo stato reale delle pagine già scansionate e indicizzate da Google: è più lento ad aggiornarsi, può richiedere diversi giorni dopo una modifica, ma resta l'unica fonte che racconta cosa Google ha effettivamente registrato, non cosa accadrebbe in teoria interrogando una singola pagina. Usare solo lo strumento di test rapido per "confermare" che lo schema funziona è un errore comune: dice che il codice è sintatticamente valido, non che l'annuncio è realmente in circolazione nei risultati.

La sequenza corretta è testare prima con lo strumento rapido, per intercettare eventuali errori di sintassi prima della pubblicazione, e poi monitorare il rapporto di Search Console nei giorni successivi per ottenere la conferma reale, senza aspettarsi che i due numeri coincidano esattamente nello stesso momento del ciclo di pubblicazione.