Sitemap of Indexing API? Zo krijg je vacatures sneller in Google for Jobs

"Kunnen we een XML-feed naar Google sturen?" is een veelgestelde vraag bij nieuwe jobboard- en careersite-implementaties. Het antwoord is nee, en dat is verwarrend. Bij Indeed en de meeste jobboards lever je juist wél een feed aan, dus waarom hier niet? Omdat Google for Jobs geen jobboard is, maar een onderdeel van de zoekmachine: het wordt gevuld door te crawlen, niet door aanlevering.

Er is geen vacaturefeed naar Google

Bij een jobboard als Indeed lever je een XML-bestand aan en neemt het jobboard je vacatures over op zijn eigen platform. Google for Jobs is geen jobboard in die zin. Het is een laag bovenop de gewone zoekresultaten, en die laag wordt gevuld door te crawlen, net als de rest van je site.

Google haalt dus alles van je eigen pagina's. Daarvoor gebruikt het JobPosting-markup: structured data die Google vertelt dat je pagina een vacature is. Die markup moet op dezelfde pagina staan als de vacaturetekst die de kandidaat leest, en daar leest Google hem ook. Welke velden verplicht zijn, staat in de Google JobPosting-documentatie. Een apart bestand met al je vacatures bestaat in dit model niet. Dat heeft ook een prettige kant: er is maar één waarheid, jouw website.

Wat je wel kunt beïnvloeden is wanneer die vacaturepagina's gecrawld worden. Daar zijn twee kanalen voor, met elk een eigen rol.

Het verschil in gewone taal

Kanaal één: de XML-sitemap

Een sitemap is een simpel XML-bestand dat alleen vertelt op welke URL een vacature te vinden is, terwijl een feed naar Indeed de volledige vacaturetekst meestuurt.

Er zijn wel voorwaarden. De belangrijkste is lastmod: die moet zo nauwkeurig mogelijk zijn en de echte laatste wijziging weergeven. Het crawlbudget is beperkt, en onjuiste tijden leiden tot onnodig hercrawlen van pagina's die niet veranderd zijn. Google leest de hele sitemap in en hercrawlt de pagina's waarvan de lastmod recenter is dan de vorige crawl.

Wat telt als een echte wijziging voor lastmod? Een aangepaste vacaturetekst, een nieuw salaris, een verlengde sluitingsdatum. Wat niet telt: een nieuwe datum in de footer, een andere banner, een hergegenereerde pagina met identieke inhoud. Een sitemap die bij elke deploy alle datums op vandaag zet, traint Google om je lastmod te negeren, en dan ben je het kanaal kwijt waar je juist op wilde sturen.

Verder gelden dezelfde regels als bij de markup zelf: zoekresultaat- en lijstpagina's horen niet in de sitemap, en elke opgenomen URL moet de canonieke pagina van die vacature zijn. Een sitemap vol filterpagina's kost crawlbudget en levert niets op.

Kanaal twee: de Indexing API

De Indexing API kent twee signalen: URL_UPDATED en URL_DELETED. Technisch is het niet ingewikkeld: je maakt een service-account aan in Google Cloud, voegt dat account als eigenaar toe in Search Console, en stuurt per vacature een POST naar het publish-endpoint:

https://indexing.googleapis.com/v3/urlNotifications:publish

Lastiger wordt het als het systeem waarop je vacaturesite draait niet goed bijhoudt wanneer een wijziging plaatsvindt. Dan weet je ook niet wanneer je moet aanbellen.

Het gebruik van de API is gratis. De standaardquota is 200 publish-requests per dag per project, bedoeld voor onboarding en testen. Wil je meer, dan vraag je goedkeuring aan via een formulier. Google kan die quota op basis van documentkwaliteit verhogen of juist verlagen, dus slechte vacaturepagina's kunnen je letterlijk je quota kosten.

Let ook op de reikwijdte: de API mag uitsluitend gebruikt worden voor pagina's met JobPosting- of BroadcastEvent-markup. Misbruik, zoals meerdere accounts opzetten om quota te omzeilen, kan tot intrekking van de toegang leiden.

Wat Google zelf aanraadt

Voor vacature-URL's raadt Google de Indexing API aan boven sitemaps, omdat Googlebot dan sneller langskomt. Tegelijk adviseren ze om daarnaast gewoon een sitemap in te dienen voor de dekking van je hele site.

Het is dus geen keuze tussen de twee. Je hebt ze allebei nodig, met verschillende rollen: de sitemap voor dekking, de API voor snelheid.

Die rolverdeling is logisch. Vacatures zijn de kortstlevende content op je site: een gemiddelde vacature staat drie tot zes weken live. Wachten op de reguliere crawlcyclus betekent dat een vacature soms pas na een week meedraait, en dan is een flink deel van de looptijd al weg. Voor je gewone pagina's maakt een week niets uit, en daar volstaat de sitemap.

Wat de API niet doet

Google accepteert je submission, geeft een 200 terug en zet de URL in de wachtrij. Dat is alles wat die 200 betekent. Validatie gebeurt pas bij het crawlen, en de status-endpoint vertelt alleen wanneer Google je melding ontving, niet of de pagina geïndexeerd is.

Sneller crawlen repareert bovendien geen inhoudelijke problemen. Een dunne beschrijving blijft een dunne beschrijving, en een dubbele vacature blijft een duplicaat. Staat je vacature na een geslaagde submission nog steeds niet in Google for Jobs, kijk dan naar de acht oorzaken uit het vorige hoofdstuk.

Verlopen vacatures: het onderschatte deel

Voor het verwijderen van vacatures geldt hetzelfde advies als voor publiceren: gebruik de Indexing API met URL_DELETED, in plaats van de URL stilletjes uit de sitemap te halen. Een URL die uit de sitemap verdwijnt, blijft in de index staan tot Google er toevallig langskomt.

Dit is waar de meeste vacaturesites steken laten vallen. Nieuwe plaatsingen automatiseren ze wel, maar het opruimen niet. Het resultaat is een index vol verlopen vacatures, en dat is precies het patroon dat tot een manual action kan leiden.

Wat bouw je in de praktijk?

De volgorde voor een vacaturesite ziet er zo uit:

1. Een sitemap, altijd, met een correcte lastmod per vacature.
2. De Indexing API erbij zodra je meer dan een handvol vacatures per week publiceert.
3. De quota-aanvraag vóór je de 200 per dag raakt, niet erna. De doorlooptijd is dagen tot weken, en tot die tijd blijven je submissions steken op het plafond.
4. Een dagelijkse expiry-job die voor elke verlopen vacature een URL_DELETED pusht. Koppel hem aan dezelfde bron als je sitemap, zodat sitemap en API altijd hetzelfde zeggen.

Wie deze vier op orde heeft, heeft het crawlgedeelte afgedekt. Daarna is het aan de content zelf, en daarvoor is er de Google for Jobs-checklist.