Service schema LocalBusiness: wat moet er echt in je structured data?

In het kort

Service schema en LocalBusiness-schema worden vaak door elkaar gebruikt, maar dekken iets anders af. Schema.org omschrijft Service als een dienst die een organisatie aanbiedt, zoals een bezorgdienst of drukwerk, met kernvelden als provider, serviceType, areaServed en hasOfferCatalog. Schema.org definieert LocalBusiness juist als een specifiek fysiek bedrijf of filiaal, zoals een restaurant, bankfiliaal of medische praktijk. Voor een dienstpagina met één fysieke vestiging combineer je meestal beide: LocalBusiness voor de locatie, Service voor wat je daar levert.

Belangrijkste punten

• LocalBusiness vereist minimaal naam en adres: Google accepteert alleen markup met deze velden voor local business rich results.
• Elke vestiging krijgt eigen markup: heb je meerdere locaties, dan definieer je elke fysieke vestiging apart als LocalBusiness-type, aldus Google.
• Service beschrijft het aanbod, niet de plek: gebruik serviceType en areaServed om aan te geven wat je levert en waar, los van je vestigingsadres.
• Reviews zijn geen verplichting: aggregateRating binnen LocalBusiness wordt alleen aangeraden voor sites die zelf recensies over andere lokale bedrijven verzamelen, niet voor elk bedrijf met eigen klantbeoordelingen (Google).
• Rich results zijn nooit gegarandeerd: Google bevestigt expliciet dat correcte structured data geen garantie geeft op een visuele weergave in zoekresultaten.

Waarom laadt Google mijn dienstpagina niet als bedrijfsvestiging?

Een monteursbedrijf plaatst een pagina online met daarop adres, openingstijden en een lijst diensten, maar in de zoekresultaten verschijnt geen bedrijfskaart, geen sterrenbeoordeling, niets. De tekst staat er, maar de machine leest hem niet als bedrijfsgegevens. Dat is het verschil tussen content voor mensen en gestructureerde gegevens voor machines (dienstpagina's die de vragen van kopers beantwoorden).

Het probleem zit zelden in de inhoud van de pagina. Het zit in de afwezigheid, of de verkeerde toepassing, van schema-markup. Zonder JSON-LD of microdata ziet Google alleen platte tekst: het systeem moet dan raden of "Hoofdstraat 12, Utrecht" een adres is, een voetnoot, of toevallig in een alinea staat. Met structured data wordt die aanname overbodig, want je vertelt expliciet welk veld welk gegeven bevat.

Het verschil tussen een visitekaartje en een menukaart

Denk aan LocalBusiness als het visitekaartje van je bedrijf: naam, adres, telefoonnummer, openingstijden. Service is de menukaart: wat bied je aan, voor wie, in welk gebied. Een pagina die alleen LocalBusiness-markup heeft, vertelt zoekmachines waar je zit, maar niet wat je doet. Een pagina die alleen Service-markup heeft, vertelt wat je levert, maar niet waar een klant moet zijn. Voor de meeste dienstverlenende bedrijven met een fysieke locatie heb je allebei nodig.

Wat gebeurt er als je het verkeerde type kiest?

Kies je LocalBusiness voor een dienst die je puur online of op afstand levert, dan impliceer je een fysieke bezoeklocatie die er niet is. Omgekeerd: gebruik je alleen Service voor een winkel of praktijk met een vaste vestiging, dan mis je de kans op een bedrijfskaart met kaartweergave, openingstijden en routebeschrijving. Beide keuzes kosten zichtbaarheid die er met de juiste markup wel had kunnen zijn.

Welk schema past bij jouw type dienstverlening?

De keuze tussen Service, LocalBusiness of een combinatie hangt af van hoe je dienst wordt afgenomen.

Alleen LocalBusiness past bij bedrijven waar de locatie zelf het product is: een restaurant, een fitnessstudio, een winkel. De klant komt naar jou toe en de ervaring gebeurt ter plekke.

Alleen Service past bij dienstverleners zonder vaste bezoeklocatie of met een dienst die overal geleverd wordt: een freelance copywriter, een landelijke schoonmaakdienst, een IT-consultant die op afstand werkt. Hier is areaServed belangrijker dan een adres.

Service genest in LocalBusiness past bij het grootste deel van de MKB-dienstverleners: een installatiebedrijf met een vestiging én een werkgebied, een notariskantoor, een fysiotherapiepraktijk die ook aan-huis-behandelingen aanbiedt. Je definieert dan de vestiging als LocalBusiness en voegt via de property makesOffer of hasOfferCatalog de specifieke diensten toe als Service-objecten.

Praktijkvoorbeeld van de velden die je nodig hebt

Voor een loodgietersbedrijf met één vestiging en een werkgebied van drie gemeenten ziet een minimale, correcte set eruit als:

• @type: LocalBusiness of een specifieker subtype zoals Plumber
• name, address, telephone, openingHours
• areaServed met de gemeenten waar geleverd wordt
• hasOfferCatalog met daarin een of meer Service-objecten, elk met eigen serviceType

Deze structuur geeft zoekmachines én AI-assistenten een compleet en eenduidig beeld: wie je bent, waar je zit, en wat je precies doet.

Zo pak je het aan:

• Bepaal eerst of je dienst gebonden is aan een fysieke locatie of overal geleverd wordt
• Kies LocalBusiness (of een specifiek subtype) als de locatie relevant is voor de klant
• Voeg Service-objecten toe via hasOfferCatalog voor elke afzonderlijke dienst
• Vul altijd naam en adres in, dat is de harde eis van Google voor rich results
• Test de markup met de Rich Results Test voordat je live gaat

Hoe ziet correcte markup eruit voor een bedrijf met meerdere vestigingen?

Stel je een regionale fysiotherapiepraktijk voor met drie vestigingen in verschillende steden. Elke locatie heeft eigen openingstijden, een eigen team en deels overlappende, deels unieke diensten.

Praktijkvoorbeeld: een hypothetisch dienstverlenend MKB-bedrijf met meerdere vestigingen

Stel dat zo'n praktijk één generieke LocalBusiness-markup gebruikt voor alle drie de vestigingen, met het hoofdkantoor-adres. Zoekmachines krijgen dan een vervuild signaal: welke vestiging hoort bij welke zoekopdracht van een klant in de buurt? Na het opsplitsen naar drie losse LocalBusiness-objecten, elk met eigen adres, telefoonnummer en openingstijden, en elk met de eigen Service-objecten voor het lokale aanbod, zagen vergelijkbare bedrijven in de praktijk een merkbare verbetering in hoe vaak de juiste vestiging werd getoond bij lokale zoekopdrachten. Exacte cijfers verschillen per situatie en branche, maar het principe dat Google voorschrijft, elke vestiging apart definiëren, is de structurele oorzaak van dat verschil.

De les hier is niet technisch maar organisatorisch: wie structured data behandelt als iets dat je één keer instelt voor het hele bedrijf, mist precies het voordeel dat het zou moeten opleveren.

Wat levert correcte Service- en LocalBusiness-markup concreet op?

Het voordeel van correcte markup zit op twee niveaus. Ten eerste de klassieke rich results: bedrijfskaarten, openingstijden, routebeschrijvingen direct in de zoekresultaten. Google is hier duidelijk over: structured data is een voorwaarde, geen garantie. Zelfs met perfecte markup kan een rich result uitblijven, simpelweg omdat Google kiest wat het toont.

Ten tweede, en dat weegt inmiddels minstens zo zwaar, is de leesbaarheid voor AI-assistenten. Wanneer iemand aan ChatGPT of Perplexity vraagt "welke loodgieter in Utrecht doet spoedreparaties", valt een antwoord sneller op structured data terug dan op losse zinnen in een alinea. Een Service-object met een duidelijke serviceType en areaServed is voor een taalmodel net zo bruikbaar als voor een zoekmachine, vaak zelfs makkelijker te parsen dan vrije tekst.

Dat deze aanpak relevanter wordt, blijkt ook uit hoe snel bedrijven AI omarmen in marketing en verkoop. Volgens CBS gebruikte in 2025 één op de zes Nederlandse bedrijven AI, een verdubbeling ten opzichte van twee jaar eerder, met marketing en verkoop als meest genoemde toepassing. Bedrijven die hun dienstpagina's nu al machine-leesbaar maken, bereiden zich voor op een zoekomgeving waarin niet alleen Google, maar ook AI-assistenten hun belangrijkste aanbeveling baseren op gestructureerde, goed gelabelde gegevens.

Welke fouten zie je het vaakst in bestaande markup?

Drie patronen komen steeds terug bij een audit van bestaande structured data.

Reviews toevoegen zonder eigen recensies te verzamelen

Bedrijven voegen aggregateRating toe aan hun LocalBusiness-markup, ook als ze zelf geen reviewsysteem hebben. Google is daar expliciet over: deze property is alleen aanbevolen voor sites die daadwerkelijk recensies over andere lokale bedrijven verzamelen, niet als algemene beoordeling van je eigen bedrijf zonder onderliggend systeem.

Eén generiek adres voor meerdere vestigingen

Zoals in het voorbeeld hierboven: bij meerdere locaties is één gedeeld LocalBusiness-object een veelgemaakte fout. Het resultaat is dat geen enkele vestiging optimaal scoort voor lokale zoekopdrachten, omdat de signalen vermengd raken.

Service-informatie alleen in platte tekst, niet in markup

De dienstpagina somt diensten netjes op voor de lezer, maar die informatie staat nergens als Service-object in de code. Voor een mens is het duidelijk, voor een zoekmachine of AI-assistent oninterpreteerbaar als gestructureerd gegeven.

Wie deze drie punten oplost, heeft in de praktijk al het grootste deel van de technische basis op orde. De rest is onderhoud: markup actueel houden bij wijzigingen in openingstijden, adres of aanbod.

Veelgestelde vragen

Wat is het verschil tussen Service schema en LocalBusiness schema?

LocalBusiness beschrijft een fysieke vestiging met adres en openingstijden, Service beschrijft wat een organisatie aanbiedt, zoals een dienst of behandeling. Een dienstverlener met een vaste locatie combineert vaak beide: LocalBusiness voor de vestiging, Service genest via hasOfferCatalog voor het aanbod.

Moet elke pagina van mijn website LocalBusiness-markup hebben?

Nee, alleen pagina's die een specifieke fysieke vestiging beschrijven hebben LocalBusiness-markup nodig. Diensten zonder vaste bezoeklocatie gebruik je beter puur als Service-object met areaServed.

Is een adres verplicht in LocalBusiness-markup?

Ja, volgens Google is een naam en adres de minimale eis om in aanmerking te komen voor local business rich results. Zonder deze velden wordt de markup niet als geldig beschouwd voor die functionaliteit.

Garandeert correcte markup een rich result in Google?

Nee. Google geeft expliciet aan geen garantie te bieden dat structured-data-features daadwerkelijk in de zoekresultaten verschijnen, ook niet bij technisch correcte implementatie. Markup verhoogt de kans, maar is geen zekerheid.

Hoe helpt Launchmind bij het opzetten van Service- en LocalBusiness-markup?

Alex, de AI-collega van Launchmind, verbetert dienstpagina's met direct antwoord, prijsindicatie, werkwijze, bewijs en vragen uit je eigen klantcontact, plus de gestructureerde gegevens die Google en AI-assistenten lezen. Na jouw akkoord zet Alex de pagina met één klik live op je eigen site, inclusief de juiste Service- en LocalBusiness-markup voor jouw situatie.

Conclusie

Service- en LocalBusiness-schema zijn geen technische bijzaak, ze bepalen of Google en AI-assistenten je dienstpagina correct kunnen interpreteren als bedrijfsvestiging, als aanbod, of als beide. De regel is simpel: LocalBusiness voor waar je zit, Service voor wat je doet, en bij meerdere vestigingen elk apart definiëren. Wie dat nalaat, laat rich results en AI-zichtbaarheid liggen die met relatief kleine aanpassingen binnen bereik liggen.

Meer over wat er inhoudelijk op zo'n pagina moet staan lees je in wat hoort er op een dienstpagina die wel converteert. Wil je niet zelf in de code duiken, maar wel zeker weten dat je dienstpagina's technisch en inhoudelijk op orde zijn? Boek een gratis adviesgesprek en bekijk hoe Alex dienstpagina's met de juiste structured data voor je opzet en publiceert.

Over het bedrijf

Launchmind is de AI-collega die elke dag SEO-content schrijft, controleert en publiceert op je eigen blog, in 8 talen, en zichzelf bijstuurt op echte Search Console-data. Alex verbetert ook dienstpagina's met direct antwoord, prijsindicatie, werkwijze, bewijs en de gestructureerde gegevens die Google en AI-assistenten lezen, voor marketingmanagers, ondernemers en CMO's van MKB- en scale-upbedrijven.