De fleste hjemmesider har lidt schema. Et Organization-snippet på forsiden, måske noget Article-markup på bloggen – kopieret fra en guide, skrevet i hånden og glemt igen. Det virker, men det fortæller ikke maskinerne ret meget. De får løsrevne faktakort, ikke en sammenhængende beskrivelse af, hvem der står bag, hvad de laver, og hvordan det hele hænger sammen.

Blackbook.dk er bygget anderledes. Hele sitet er ét knowledge graph: en person, en virksomhed, et brand, ydelser, cases, billeder, videoer og artikler – alle som entiteter med faste adresser, der peger på hinanden. Da artiklen blev skrevet i november 2026, bar de 300 sider i sitemap'et tilsammen omkring 37.000 schema-noder fordelt på 39 typer og 740 entiteter med eget @id. Ikke én af dem er skrevet i hånden.

Her er, hvordan det virker – og hvad vi har lært undervejs.

Ét datalag, tre output

Alt indhold på sitet ligger én gang, som struktureret data i Sanity CMS. En case er ikke en side; den er et dokument med typede relationer til ydelser, fagområder, roller og billeder. Fra det samme datalag genereres tre ting: den visuelle side, schema-grafen og den AI-agent, der svarer på spørgsmål i chatten.

Det er hele hemmeligheden. Når schema genereres fra de samme data som siden, kan de to aldrig komme ud af trit. Retter vi en titel, en beskrivelse eller en ydelse på en case, er grafen opdateret ved næste build. Der findes ingen schema-fil, som nogen skal huske at vedligeholde.

Sammenlign det med den typiske løsning: et SEO-plugin, der genererer standard-markup ud fra sidens titel og beskrivelse. Det giver et minimum, men plugin'et kender ikke forskel på en case og en artikel, ved ikke hvem der lavede hvad, og kan ikke se relationerne mellem indholdet. Et knowledge graph kræver en indholdsmodel, der allerede kender relationerne. Schema er bare den måde, man udtrykker dem på.

@id er rygraden

Den vigtigste byggesten i et knowledge graph er ikke typerne – det er identiteterne. I schema.org-sprog hedder det @id: en fast URI, der siger ”det her er præcis den her ting”. Når to noder bærer samme @id, ved en maskine, at de beskriver den samme entitet – også selvom de står på hver sin side.

Blackbook har tre faste ankre: personen, organisationen og websitet. De ligger som konstanter i koden, med en kommentar om, at de aldrig må ændres:

// ─── Stable @id URIs — never change these ───
export const PERSON_ID = `${SITE_URL}/#person-jeppe`
export const ORG_ID    = `${SITE_URL}/#organization`
export const SITE_ID   = `${SITE_URL}/#website`

Alt andet refererer til dem i stedet for at gentage dem. En case skriver ikke ”lavet af Jeppe Sloth Carlsen, Senior Product Designer, København …” – den peger bare på personens @id. Personen er beskrevet ét sted, og alle andre noder peger derhen. Det er forskellen på en stak visitkort og et netværk.

Sådan ser en case ud i grafen, forenklet:

{
  "@type": "CreativeWork",
  "@id": "https://www.blackbook.dk/portfolio/<case>/#work",
  "creator":   { "@id": "https://www.blackbook.dk/#person-jeppe" },
  "publisher": { "@id": "https://www.blackbook.dk/#organization" },
  "isPartOf":  { "@id": "https://www.blackbook.dk/#website" },
  "about": [
    { "@type": "Thing", "@id": "https://www.blackbook.dk/services/ux-product-design/#service" }
  ]
}

Læg mærke til about. Casen peger ikke på et løst emne, men på det samme @id, som ydelsessiden bruger til sin Service-node. Dermed er casen og ydelsen forbundet i selve grafen – ikke kun via et link i HTML'en.

Hver side bærer hele identiteten

Kernen – person, organisation, website og brand – ligger på alle sider via det fælles layout. Uanset hvor en crawler lander, møder den den samme identitet med de samme ankre. Oven på det lægger hver sidetype sine egne noder: En case tilføjer værket, billederne og videoerne. En ydelsesside tilføjer Service og Offer. About-siden tilføjer erfaring, roller og priser. Medianen lå på omkring 100 noder pr. side; About-siden var den tungeste med over 400.

Det lyder af meget, men det er ikke pynt. Hver node svarer på et konkret spørgsmål, som en søgemaskine eller en sprogmodel ellers skulle gætte sig til: Hvem lavede det her? Hvornår? For hvem? Hvilken disciplin hører det under? Må billedet genbruges?

Hvad grafen beskriver

Personen. Navn, titel, sprog, erfaring og kompetencer via knowsAbout – og erhverv kodet efter den officielle O*NET-SOC-standard, så ”Senior Product Designer” ikke bare er en tekststreng, men en genkendt stillingskategori.

Organisationen. Blackbook er både Organization og LocalBusiness: adresse, koordinater, åbningstider, kontaktpunkt på dansk og engelsk, stiftelsesår og grundlægger – som et @id, selvfølgelig.

Ydelserne. Hver ydelse er en Service-node med fast @id, samlet i et OfferCatalog under organisationen. Det er dem, casene peger på.

Værkerne. Hver case er et CreativeWork med skaber, udgiver, år, emner og billeder. Billederne er ImageObjects med kreditering, copyright og licens, så Google kan vise dem som licensérbare i billedsøgningen.

Indholdet og strukturen. Artikler, videoer, brødkrummer, lister og hovednavigation er beskrevet, så maskinerne kan se sitets opbygning – ikke kun de enkelte sider.

sameAs: identitet på tværs af nettet

Et knowledge graph på eget domæne er stærkt, men det er stadig en påstand. sameAs gør det til en forankring. Person- og organisationsnoderne linker til de profiler, der beskriver de samme entiteter andre steder: LinkedIn, Behance, Dribbble, Vimeo, YouTube, GitHub og bureau-directories. Budskabet er: Den person, der er beskrevet her, er den samme som den, der er beskrevet dér.

Vi har været bevidste om, hvad grafen skal styrke: Blackbook og Jeppe – personen, virksomheden, brandet og kompetencerne. Kunderne optræder på casene som den organisation, arbejdet blev lavet for. De er kontekst, ikke omdrejningspunkt.

Ærlig herkomst

Et af de mere usædvanlige valg i grafen handler om ophavsret. En del af casene i porteføljen er lavet, mens Jeppe var ansat andre steder. Blackbook viser arbejdet, men har ikke produceret det – og så må grafen heller ikke påstå det. Den slags cases får derfor ingen copyrightHolder. I stedet krediteres den organisation, der producerede arbejdet, via producer. Priser følger samme regel: En pris vundet for arbejde hos en arbejdsgiver hører til personen, ikke til virksomheden.

Det er en lille detalje, men den er vigtig. Et knowledge graph er kun noget værd, hvis maskinerne kan stole på det. Overdriver man ét sted, undergraver man det hele.

Ét værk, to sprog

Sitet findes på dansk og engelsk, og det er en klassisk fælde for schema. Får den danske og den engelske version af en case hver sit @id, ser maskinerne to forskellige værker. Derfor bruger alle værker, ydelser og artikler et sprogneutralt @id baseret på den danske slug, mens url og mainEntityOfPage peger på den lokaliserede side. Resultatet er én entitet med to sproglige repræsentationer, der smelter sammen i grafen i stedet for at konkurrere.

Hvorfor det betyder mere for AI end for Google

Google bruger kun en brøkdel af schema.org til rich results – brødkrummer, videoer, billedlicenser og lignende. Resten bliver læst, men belønnes ikke synligt. Derfor stopper de fleste ved det, Google viser frem.

Sprogmodeller arbejder anderledes. Når en AI-crawler læser en side, er struktureret data den hurtigste vej til entydige fakta – hvem, hvad, hvor og hvornår – uden at skulle tolke layout og marketingsprog. Et sammenhængende knowledge graph giver modellen et kort over hele virksomheden, uanset hvilken side den starter på.

Det kan vi se i trafikken. AI-crawlerne fra de store sprogmodeller besøger sitet hver dag, og de nøjes ikke med forsiden – de går systematisk gennem cases, ydelser og artikler. Hver af de sider fortæller den samme, konsistente historie om, hvem Blackbook er, og hvad Blackbook laver.

Grafen er derfor ét lag i en større strategi. Sammen med llms.txt og markdown-versioner af alle sider er det det, vi kalder LLMO: at gøre et website læsbart for de modeller, der i stigende grad svarer på spørgsmålet ”hvem skal vi vælge?”.

Det har vi lært

Typer er ikke målet. Det er fristende at tælle typer. Men ti typer, der ikke hænger sammen, er mindre værd end fem, der gør. Spørg ikke ”hvilke typer mangler vi?”, men ”hvilket spørgsmål kan en maskine endnu ikke besvare om os?”.

Vægt er en reel omkostning. Struktureret data er HTML, og HTML skal hentes. Da ydelsesoversigten voksede, lå hver ydelsestekst to gange – i Service-beskrivelsen og i en FAQ-blok. Vi fjernede FAQ-blokken, fordi Google ikke længere viser FAQ-resultater for almindelige sites, og beholdt beskrivelserne. Skær det væk, der ikke bærer information – aldrig det, der gør.

Rich text skal være ren tekst. Indhold fra et CMS er ofte formateret tekst med blokke og markeringer. Ryger det direkte ind i schema, får maskinerne objekter i stedet for sætninger. Alle beskrivelser bliver konverteret til ren tekst, før de lægges i grafen.

Ingen løse ender. Hver reference til et @id skal pege på en node, der faktisk findes. En reference ud i ingenting er værre end ingen reference – den lover en sammenhæng, der ikke er der.

Se grafen selv

Du kan se Blackbooks graf med det samme. Indsæt en vilkårlig side i Schema Markup Validator på validator.schema.org, eller hent den fra terminalen:

curl -s https://www.blackbook.dk/ \
  | grep -o '<script type="application/ld+json">[^<]*</script>' \
  | sed 's/<[^>]*>//g' \
  | jq -c '."@graph"[]? | {"@type", "@id"}'

Første linje i svaret er personen, derefter organisationen, websitet og brandet – de samme fire ankre, som alt andet på sitet peger på.

Vil du vide, hvor læsbar din egen side er for AI, kan du køre den gennem vores gratis scan. Og vil du have et knowledge graph bygget ind i dit eget site, kan du læse mere om schema som ydelse.