Schema markup lyder teknisk, og det er nok også derfor, mange lader det ligge. Det forstår jeg godt. Når man sidder med ansvar for en B2B-hjemmeside, er der allerede rigeligt at holde styr på. Design, tekster, intern forankring, opdateringer og den daglige drift fylder mere end noget, der ligner kode.
I mit arbejde ser jeg tit, at schema markup enten bliver overvurderet eller glemt helt. Begge dele skaber unødig usikkerhed. Det hjælper derfor at se det nøgternt. Schema markup er ikke magi. Det er heller ikke ligegyldigt. Det er et struktureret lag data, som kan hjælpe Google og andre systemer med at forstå, hvad jeres hjemmeside handler om. Og på en B2B-hjemmeside giver nogle typer klart mere mening end andre.
Hvad schema markup er på en WordPress-hjemmeside
Schema markup er strukturerede data. Altså oplysninger på jeres hjemmeside, som er skrevet på en måde, maskiner lettere kan læse. Det ændrer ikke det visuelle udtryk på hjemmesiden. Det ligger bagved og beskriver indholdet mere præcist.
Hvis en almindelig tekst siger, at I er en virksomhed i Silkeborg, der leverer en bestemt ydelse, kan schema markup markere, at det faktisk er en organization, og at den konkrete tekst handler om en service. Det gør indholdet tydeligere for søgemaskiner.
På en WordPress-hjemmeside bliver schema markup som regel lagt ind via et plugin, et tema eller tilpasset kode, ofte som JSON-LD. Selve teknikken er mindre vigtig end beslutningen bag. Spørgsmålet er ikke, om I kan få schema markup på hjemmesiden. Spørgsmålet er, hvilken markup der giver mening, og hvad der bare skaber støj.
Hvad Google bruger structured data til, og hvad det ikke lover
Google bruger structured data til at forstå indhold og i nogle tilfælde vise rich results i søgeresultaterne. Det kan være ekstra oplysninger om en organisation, anmeldelser eller andre elementer, der gør et søgeresultat mere informativt. Men her er det vigtigt at holde fast i noget helt grundlæggende.
Vidste du? Rich results er de udvidede søgeresultater, du nogle gange ser i Google med ekstra oplysninger som stjerneratings eller spørgsmål og svar. De kræver korrekt schema markup, men Google bestemmer selv, om de bliver vist.
Korrekt schema markup er ikke en garanti for synlighed. Google skriver selv, at korrekt markerede strukturerede data ikke garanterer, at de bliver vist som rich results. Der er altså forskel på at være berettiget og faktisk blive vist. Den forskel er vigtig, fordi den fjerner en del af den usikkerhed, jeg ellers møder.
Google har også generelle retningslinjer for structured data. Hvis man bryder dem, kan man få en manual action, som fjerner muligheden for rich results. Det påvirker ikke den almindelige web-søgning direkte, men det er stadig noget, man bør undgå. Derfor er min holdning ret enkel. Schema markup skal være ordentligt, sandt og stabilt. Ikke pynt.
Schema markup skal være ordentligt, sandt og stabilt. Ikke pynt.
Når jeg forklarer det til marketingansvarlige, plejer jeg at skære det helt ind til benet:
- Det hjælper Google med at forstå: hvem I er, og hvad en given hjemmeside handler om
- Det kan gøre jer berettigede til rich results: men Google bestemmer selv, om de vises
- Det skal matche det synlige indhold: ellers skaber I risiko og rod
Hvilke schema-typer der giver mening på B2B-hjemmesider
Når man ser på B2B-hjemmesider i WordPress, er der fire typer, som næsten altid kommer op i samtalen. De er bare ikke lige relevante.
Forskellen ser sådan ud:
| Schema-type | Hvad den beskriver | Hvor den giver mening | Min vurdering for B2B |
|---|---|---|---|
| Organization | Virksomheden som organisation | Forside, kontakt, om os, globalt på hjemmesiden | Ja, det er et godt grundlag |
| Service | En konkret ydelse | Servicesider og ydelsessider | Ja, meget relevant |
| FAQPage | Spørgsmål og svar | FAQ-sektioner med rigtige spørgsmål og svar | Sjældent værd at prioritere for almindelige B2B-hjemmesider |
| Review | Anmeldelser og ratings | Sider med reelle, synlige anmeldelser | Kun hvis data er ægte og gennemarbejdet |
Organization schema til virksomhedsoplysninger
Organization er efter min mening den mest oplagte schema-type for en B2B-hjemmeside. Schema.org beskriver den som en type for en organisation, blandt andet virksomheder. Det er en enkel og stabil måde at fortælle, hvem I er.
Det giver især mening, fordi mange B2B-hjemmesider har et klart behov for at fremstå professionelle og troværdige. Når jeres virksomhedsoplysninger er struktureret ordentligt, fjerner det tvivl. Ikke for mennesker direkte, men for systemerne omkring jeres indhold.
Det vigtige er ikke at fylde alt ind, bare fordi felterne findes. Schema.org nævner blandt andet properties som legalName, legalAddress, taxID og slogan. Det betyder ikke, at I skal bruge dem alle. Brug det, der er relevant, og som passer med det, I faktisk viser offentligt på hjemmesiden.
Et godt udgangspunkt er dette:
- Virksomhedsnavn: jeres normale navn, og legalName hvis det er relevant at skelne
- Adresse og kontakt: kun det, der står tydeligt på hjemmesiden
- Virksomhedsoplysninger: kun data I kan stå inde for, og som holdes opdateret
Jeg vil langt hellere se en enkel og korrekt Organization-markering end en stor model fyldt med halvaktuelle oplysninger. Det er mere stabilt, og det er lettere at vedligeholde i WordPress.
Service schema til ydelsessider
Service er den schema-type, jeg oftest savner på B2B-hjemmesider. Ikke fordi den løser alt, men fordi den passer godt til den måde mange virksomheder bygger deres hjemmeside på. I sælger ikke produkter fra en hylde. I leverer ydelser. Derfor giver det mening at beskrive dem som netop services.
Schema.org peger på properties som areaServed, audience og availableChannel. Det er nyttigt på B2B-hjemmesider, fordi en ydelse sjældent er generisk. Måske leverer I kun i Danmark. Måske kun til industrivirksomheder, rådgivere eller offentlige organisationer. Måske foregår kontakten via telefon, møder eller e-mail. Den slags gør en serviceside mere præcis.
Jeg mener, at Service fungerer bedst, når hver vigtig ydelse har sin egen hjemmeside med sin egen tekst. Hvis alt ligger samlet på én lang oversigtsside, bliver markeringen hurtigt upræcis. En god serviceside har et tydeligt fokus, og schema markup skal følge den struktur, ikke prøve at kompensere for manglende afklaring.
Det er også her, WordPress kan være både en hjælp og en faldgrube. Hvis jeres hjemmeside er bygget ordentligt op med særskilte servicesider, er Service schema ligetil. Hvis indholdet er rodet, bliver schema markup det også. Strukturerede data kan ikke redde en uklar informationsarkitektur.
FAQPage schema og hvorfor det sjældent er værd at bruge
FAQPage var tidligere noget mange talte om, fordi det kunne føre til FAQ rich results i Google. Det billede har ændret sig. Google har meldt ud, at FAQ rich results i Search kun er aktuelle for velkendte, autoritative government- og health-sites.
Det betyder helt konkret, at FAQPage sjældent er et godt valg for en almindelig B2B-virksomhed, hvis målet er synlighed i Google Search. Det er en vigtig afklaring, fordi mange WordPress-plugins stadig gør det meget let at tilføje FAQ-markup, og så kan man få indtryk af, at det er en standardting, man bare bør aktivere.
Hvis I alligevel bruger FAQPage, skal det gøres korrekt. Google kræver mindst ét gyldigt Question item, og hvert spørgsmål skal have både spørgsmål og svar. Men jeg vil være ærlig her. For de fleste B2B-hjemmesider er det ikke dér, jeg ville lægge energien.
Jeg siger ikke, at spørgsmål og svar er en dårlig idé. Tværtimod. En god FAQ på hjemmesiden kan være meget værd for jeres besøgende. Jeg siger bare, at FAQPage schema i Google-sammenhæng sjældent flytter noget for jer. Og det er rart at vide, så I ikke bruger tid på noget, der ikke giver ro eller klarhed.
Review schema på B2B-hjemmesider kræver ekstra omtanke
Review schema kan være relevant, men det kræver mere disciplin end mange tror. Schema.org giver mulighed for at knytte review og aggregateRating til både Organization og Service. Google har samtidig ekstra guidelines for review snippets på organization og local business.
Det betyder i praksis, at man skal være meget varsom. Anmeldelserne skal være reelle. De skal være synlige på hjemmesiden. De skal handle om den konkrete enhed, der bliver markeret. Man skal ikke opfinde ratings, samle lidt løse kundecitater og kalde det aggregateRating. Det er den sikre vej til unødigt rod.
Google skriver også, at et review for entity A kan ligge på entity A’s eget website, enten direkte i structured data eller via en indlejret tredjeparts-widget. Det er relevant, hvis I allerede viser troværdige anmeldelser på hjemmesiden. Så kan review markup i nogle tilfælde være meningsfuldt. Men kun hvis grundlaget er ordentligt.
Min holdning er klar. Hvis I er i tvivl om kvaliteten af jeres review-data, så lad være. Review schema er ikke stedet, hvor man skal være kreativ. Det skal være præcist, dokumenterbart og synligt for den besøgende.
Sådan arbejder jeg med schema markup i WordPress
Når schema markup skal ind på en WordPress-hjemmeside, starter jeg ikke med et plugin. Jeg starter med strukturen. Hvad er jeres vigtigste virksomhedsinformation? Hvilke ydelser har deres egne hjemmesider? Er der anmeldelser, som faktisk er egnede til markup? Først derefter giver værktøjet mening.
Det vigtigste i WordPress er at vælge én ansvarlig kilde til jeres schema markup. Jeg ser alt for mange løsninger, hvor temaet laver lidt, et SEO-plugin laver lidt mere, og så har nogen lagt ekstra kode ind oveni. Resultatet er dubletter og modstridende data. Det skaber ikke tryghed. Det skaber støj. Det billede går igen hos WP Assistance, der i tekniske WordPress-gennemgange ofte finder schema fra både tema, plugin og håndskrevet kode i konflikt.
I mit arbejde går jeg efter det enkle og stabile setup:
- Én kilde til markup: tema, plugin eller tilpasset kode, ikke tre løsninger på én gang
- Tæt kobling til indholdet: det markerede skal også stå tydeligt på hjemmesiden
- Fokus på de vigtige typer: Organization og Service først, Review med omtanke, FAQPage sjældent
Det er også værd at tage stilling til vedligeholdelsen. Schema markup er ikke færdigt, bare fordi det er lagt ind én gang. Hvis I ændrer adresse, virksomhedsnavn, serviceområder eller anmeldelsesgrundlag, skal markup følge med. Ellers mister den værdi og begynder at skabe usikkerhed.
Fejl jeg ser igen og igen med schema markup i WordPress
Den mest almindelige fejl er, at der kommer for meget markup på hjemmesiden. Ikke fordi nogen vil snyde, men fordi WordPress gør det let at installere endnu et plugin. Pludselig har forsiden tre forskellige Organization-markeringer og en FAQPage, ingen har bedt om.
Den næste fejl er, at schema markup ikke matcher det synlige indhold. Hvis en serviceside er vag, men koden er meget specifik, hænger tingene ikke sammen. Det samme gælder reviews. Hvis der står en rating i koden, men den ikke findes synligt på hjemmesiden, er det et dårligt setup.
Jeg ser også mange B2B-hjemmesider, hvor FAQPage er lagt ind som standard på alle spørgsmål og svar, selv om der ikke er nogen realistisk gevinst i Google Search. Det er et godt eksempel på noget, der føles som grundighed, men som i virkeligheden bare giver mere at holde øje med.
De klassiske fejl ser sådan ud:
- Dubleret Organization-markup
- Service schema på sider, der ikke beskriver en reel ydelse
- FAQPage til almindelige virksomhedssider uden klar grund
- Review eller aggregateRating uden synlige, dokumenterede anmeldelser
Hvad du skal kigge efter, når du vurderer jeres nuværende schema markup
Hvis du skal vurdere jeres nuværende WordPress-hjemmeside, ville jeg starte helt enkelt. Har I en klar Organization-markering, som passer til jeres offentlige virksomhedsoplysninger? Har jeres vigtigste ydelser egne hjemmesider, hvor Service schema giver mening? Hvis ja, er I allerede godt på vej.
Derefter ville jeg stille de lidt mere kritiske spørgsmål. Har I FAQPage, selv om I er en almindelig B2B-virksomhed? Har I review-data, som I faktisk kan dokumentere og vise synligt? Er markup samlet ét sted, eller kommer den fra flere systemer på én gang? De spørgsmål fjerner meget tvivl.
Det, jeg har lært, er ret enkelt. Den bedste schema markup til en B2B-hjemmeside er sjældent den mest omfattende. Det er den mest præcise. For de fleste virksomheder betyder det et stabilt Organization-setup, gennemarbejdet Service markup på de rigtige hjemmesider og en bevidst beslutning om at lade FAQPage og Review vente, hvis grundlaget ikke er stærkt nok. Så står I med en løsning, der er tydelig, professionel og langt lettere at have ro med.
