Un sito web di lavoro pubblica centinaia, a volte migliaia di offerte a settimana. Ogni annuncio ha la sua pagina, con una vita breve: da pochi giorni a poche settimane prima di essere occupata o rimossa. Senza una mappa del sito strutturata, una parte significativa di queste pagine rimane invisibile ai motori di ricerca, e quindi ai candidati.
Indexing API e sitemap: il duo raccomandato da Google per le offerte di lavoro
I concorrenti parlano molto della sitemap XML come strumento universale. Su un sito di lavoro, questo approccio non è più sufficiente. Google raccomanda di utilizzare l’Indexing API per le pagine contenenti un markup JobPosting, al fine di attivare un crawl rapido non appena un’offerta viene pubblicata, modificata o chiusa.
La sitemap gioca quindi un ruolo di rete di sicurezza. Garantisce che tutti gli URL delle offerte rimangano accessibili ai robot, anche se la chiamata API fallisce o se una pagina è stata dimenticata. L’Indexing API gestisce la reattività, la sitemap assicura la copertura globale.
In pratica, quando un reclutatore pubblica un’offerta su un sito di lavoro, l’API invia un segnale immediato a Google. Il motore esplora la pagina in pochi minuti invece di attendere il prossimo passaggio del suo robot. Per un candidato, questo significa vedere l’offerta in Google Jobs molto prima. Puoi consultare la sitemap di pleinemploi.net per osservare la struttura di una mappa del sito orientata alle offerte di lavoro.
Sitemap ed idoneità Google Jobs: un URL unico per offerta

Molti siti di lavoro creano involontariamente dei duplicati. La stessa offerta appare sotto più URL (filtri, parametri di sessione, versioni mobili distinte). Questa situazione impedisce a Google di determinare quale pagina indicizzare.
Un’offerta deve corrispondere a una sola pagina dedicata, pubblica e canonica. Questo URL è quello che figura nella sitemap. Non porta una direttiva noindex, non è bloccato dal robots.txt e non reindirizza a un’altra pagina.
Questa costrizione architettonica ha un impatto diretto sulla navigazione del sito. Quando un candidato clicca su un risultato in Google Jobs, arriva sulla pagina giusta, con il contenuto corretto. I percorsi di candidatura rimangono coerenti e il tasso di rimbalzo diminuisce.
Un errore comune: lasciare nella sitemap offerte scadute che rimandano a una pagina “Questa offerta non è più disponibile”. Google rileva questa incoerenza e penalizza l’affidabilità percepita della sitemap. È meglio rimuovere rapidamente questi URL o restituire un codice HTTP 410 (Gone).
Sincronizzare il campo lastmod con il ciclo di vita delle offerte
La sitemap XML contiene per ogni URL un campo opzionale chiamato lastmod. Indica la data dell’ultima modifica della pagina. Su un sito vetrina, questo campo cambia raramente. Su un sito di lavoro, dovrebbe riflettere ogni aggiornamento reale di un annuncio.
Perché questa precisione è così importante? Perché Google utilizza lastmod per dare priorità alle pagine da ricrawlare. Se tutte le offerte mostrano la stessa data, il motore non ha alcun segnale per distinguere quelle che sono cambiate. Deve controllare tutto, il che rallenta l’intero processo.
Un sito di lavoro ben configurato aggiorna lastmod in tre casi specifici:
- Quando il contenuto dell’offerta viene modificato (stipendio, luogo, descrizione del lavoro).
- Quando l’offerta passa dallo stato “aperta” a “occupata” o “chiusa”, il che attiva la rimozione della pagina dalla sitemap o il suo aggiornamento.
- Quando il markup strutturato JobPosting viene corretto o arricchito, ad esempio per aggiungere una modalità di lavoro (lavoro da remoto, ibrido).
Un lastmod affidabile accelera la considerazione dei cambiamenti da parte di Google. Al contrario, un lastmod artificiale (aggiornato quotidianamente senza modifiche reali) degrada la fiducia del motore nell’intera sitemap.
Sitemap HTML e navigazione del candidato: oltre il file XML

La sitemap XML è destinata ai robot. La sitemap HTML, invece, è destinata agli utenti. Su un sito di lavoro, una mappa del sito accessibile dal piè di pagina può orientare i candidati verso le categorie principali: mestieri, regioni, tipi di contratto.
Questa pagina svolge un ruolo di collegamento interno. Distribuisce autorità verso le pagine di categorie profonde che la navigazione principale non mette sempre in evidenza. Un candidato che cerca offerte in un settore di nicchia può accedervi senza passare per la ricerca a faccette.
Per il SEO, la sitemap HTML completa la XML senza sostituirla. Rafforza la struttura del sito creando percorsi di accesso aggiuntivi verso le pagine strategiche. I motori di ricerca seguono questi link interni e scoprono pagine che il crawl classico potrebbe aver perso.
Il trucco da evitare: elencare migliaia di offerte individuali nella sitemap HTML. Questa pagina diventerebbe illeggibile e perderebbe ogni utilità. È meglio limitarsi alle categorie, alle pagine di risultati filtrati e alle landing page tematiche.
Errori tecnici che sabotano la sitemap di un sito di lavoro
Alcuni errori si ripetono frequentemente sui job board e passano inosservati per mesi.
- Includere nella sitemap URL che restituiscono un codice 404 o 301. Google finisce per ignorare il file se il tasso di errore è troppo elevato.
- Superare il limite di 50.000 URL per file sitemap senza utilizzare un indice di sitemap per organizzare i file.
- Dimenticare di dichiarare la sitemap nel robots.txt o in Google Search Console, il che ritarda la sua considerazione.
- Mischiare pagine indicizzabili e pagine bloccate da noindex nella stessa sitemap, il che invia segnali contraddittori ai motori.
Su un sito di lavoro ad alto volume, automatizzare la generazione della sitemap è l’unica opzione praticabile. La sincronizzazione con il database delle offerte deve essere quotidiana, se non in tempo reale per i siti più attivi.
Una sitemap ben mantenuta non garantisce da sola un buon SEO. Rimane un leva tecnica tra le altre. Ma su un sito di lavoro dove i contenuti cambiano ogni giorno, è il primo segnale che riceve Google per capire cosa è nuovo, cosa è cambiato e cosa non esiste più.



