Strukturerte sidedata

fakta om en side, skrevet for maskiner

Hva det er

Strukturerte sidedata, ofte bare kalt strukturerte data, er det å gjenta det en side sier i løpende tekst som typede utsagn i et vokabular utgivere og programmer er enige om, slik at søkemotorer og annen programvare kan lese opplysningene uten å måtte tolke oppsettet. En bedrifts kontaktside sier i en setning hvor kontoret ligger. De strukturerte dataene sier det samme en gang til, som en PostalAddress med gate, postnummer og land, så et program som leser siden, slipper å gjette hvilket av ordene som er stedsnavnet.

Vokabularet er som regel schema.org, som Googles dokumentasjon oppgir som det de fleste strukturerte dataene for søket deres bruker. Google, Microsoft, Yahoo og Yandex grunnla det, og siden april 2015 har en fellesskapsgruppe i W3C vært hovedforumet. Det definerer typer, f.eks. Organization, Person, Service, Review eller DefinedTerm, og egenskapene hver av dem kan bære, f.eks. name, address, author eller price.

Utsagnene kan skrives i tre syntakser. Microdata og RDFa legger attributter på de synlige HTML-elementene selv. JSON-LD holder utsagnene for seg, som en blokk med JSON i et script-element av typen application/ld+json, og er en W3C-anbefaling i versjon 1.1, publisert 16. juli 2020. Google godtar alle tre på lik linje og anbefaler JSON-LD som den enkleste å vedlikeholde i stor skala.

<script type="application/ld+json">
    {
        "@context": "https://schema.org",
        "@type": "Organization",
        "@id": "https://example.com/#organization",
        "name": "Example Ltd",
        "url": "https://example.com/"
    }
</script>

Linjen som betyr mest i den blokken, er @id. JSON-LD bruker den til å identifisere en node, og en node som mangler en slik, er en blank node, som ingenting utenfor dens egen blokk kan peke på. Med en identifikator kan en hvilken som helst annen blokk på en hvilken som helst annen side skrive "publisher": {"@id": "https://example.com/#organization"}, det spesifikasjonen kaller en nodereferanse: en peker til en ting som er beskrevet et annet sted, i stedet for en ny beskrivelse av den. Det er identifikatorene som gjør en spredt samling blokker til én graf.

Nabobegrepet er metadata. Tittelen, beskrivelsen og Open Graph-taggene i hodet på en side beskriver siden som et dokument, mens strukturerte data beskriver tingene siden handler om: selskapet bak den, personen som skrev den, tjenesten den tilbyr, eller ordet den definerer.

Hvorfor det er viktig

Beslutningen gjelder hvor mye som skal sies, og det ærlige svaret er som regel mindre enn vokabularet tillater, men komplett. Syntaksen hindrer ikke en utgiver i å fylle ut hver egenskap schema.org tilbyr. Googles egne råd peker motsatt vei: oppgi heller færre av de anbefalte egenskapene, komplette og korrekte, enn alle mulige med mangelfulle eller gale data, og merk aldri opp noe en leser ikke kan se på siden, selv når det er sant.

Grunnen er at hver opplysning som merkes opp, er en ekstra kopi av noe siden allerede sier, og en ekstra kopi kan gli bort fra originalen. En pris som er rettet i den synlige tabellen og glemt i JSON-en, en vurdering bare maskiner får se, en adresse skrevet litt annerledes på hver side: hver av dem får siden til å si én ting til mennesker og en annen til programmer. Kostnaden ved strukturerte data ligger mindre i å skrive dem enn i å holde dem sanne, så de nyttige spørsmålene er hvilke utsagn siden kan stå inne for, og om de kommer fra den samme kilden som den synlige teksten.

Det man får igjen, er lesbarhet. En søkemotor eller en agent som kan slå sammen hundre omtaler til ett selskap, vet mer enn en som leser hundre navn uten sammenheng. Sider som følger retningslinjene, kan bli kvalifisert for utvidede resultater (rich results), oppføringer med ekstra detaljer i søket, men kvalifisering garanterer ingen av dem. Det som endrer seg, er hvor godt en maskin forstår hva siden handler om.

Slik ser det ut i praksis

Kolofonen forplikter nettstedet til å merke opp bare det som er sant og synlig på siden, og historien til de strukturerte dataene her viser hvorfor den setningen trengte å bli skrevet ned.

Før omleggingen gjentok 963 blokker selskapet 1 671 ganger, uten en stabil identifikator noe sted, så den som leste dataene, hadde ikke grunnlag for å behandle organisasjonen på én side som organisasjonen på en annen. Grafen hviler nå på tre identifikatorer laget fra nettstedets origin, for organisasjonen, nettstedet og grunnleggeren, og hver annen blokk viser til dem med @id i stedet for å beskrive dem på nytt. Identifikatorene er de samme på hvert språk: en kommentar i malen forklarer at en egen dansk identifikator ville erklære en organisasjon nummer to med det samme organisasjonsnummeret. Seksten typer er i bruk, og lister navngir elementene sine bare med URL, fordi det å skrive ut de 107 oppføringene på porteføljeindeksen ville ha gjort den komprimerte siden 52 % tyngre.

Flere opplysninger hentes fra den samme kilden som den synlige siden. Prisene på tjenestene kommer fra den samme datafilen som prisene på skjermen, så en maskin og en leser får oppgitt den samme satsen. Perioden et arbeid dekker, kommer fra den partialen som skriver setningen om den. Brødsmulestiene følger stien leseren ser, og posisjonene i lister følger rekkefølgen på skjermen, aldri en rangering som bare publiseres for maskiner. Sidens egen node bruker den samme adressen som den kanoniske lenken, så oppmerkingen og hodet fremmer én og samme påstand.

Det som er utelatt, er like bevisst som utsagnene. Selskapets egne beskrivelser av sitt eget arbeid merkes ikke opp som omtaler, fordi det ville dikte opp en forfatter for selskapets egne ord. Anbefalinger fra navngitte personer merkes opp, men uten karakter, siden ingen har gitt en. Hver side i ordlisten, denne også, bærer en DefinedTerm der beskrivelsen er den én linje lange forklaringen som står i listen, så definisjonen en maskin leser, er den samme som leseren ser.

En sjekk over det bygde nettstedet slår fast at hver blokk kan parses, at hver identifikator løses opp, og at hver URL grafen nevner, faktisk ble bygget, så en graf som peker på en side som ikke finnes, stopper kvalitetsporten. Den samme kolofonen lister Schema Markup Validator for å lese dataene og Googles Rich Results Test for å se hva én søkemotor gjør med dem.

Hvor det går galt

Utvidede resultater som uteblir selv om hver validator godkjenner. Oppmerkingen er gyldig JSON-LD og bruker ekte schema.org-typer, men siden vises fortsatt som et vanlig treff. Dataene beskriver ting en leser ikke kan se, f.eks. en vurdering ingen har gitt, spørsmål som er skjult på siden, eller en pris som avviker fra den på skjermen, og Google advarer om at oppmerking som bryter retningslinjene, kan gjøre en side ukvalifisert, hvor ren syntaksen enn er. Merk bare opp det siden viser, og lag begge deler fra én kilde, så de ikke kan skilles.

Hundrevis av blokker om ett selskap, og ingenting som binder dem sammen. Hver side gjentar navnet, logoen og adressen til organisasjonen, av og til med små forskjeller, og å rette én detalj betyr å finne alle sammen. Nodene er anonyme, eller hver side og hvert språk lager sin egen identifikator for den samme enheten. Gi hver virkelig ting én @id bygget fra en stabil URL med et fragment, beskriv den én gang, og vis til den overalt ellers.

En malendring som ødelegger oppmerkingen på hver side samtidig. Et feilplassert anførselstegn, et komma for mye på slutten eller en tom verdi gjør hver blokk ugyldig, og de som leser dataene, kan ikke bruke noe av dem. Googles veiledning advarer om at maler kan ødelegge oppmerking etter at den er satt i produksjon. JSON-en ble satt sammen som tekst, med verdier limt inn mellom krøllparenteser, så et manglende felt etterlater en tom streng eller en ødelagt struktur. Bygg utsagnet som en datastruktur og serialiser det, slik malene på dette nettstedet gjør med jsonify i Hugo, utelat egenskaper som mangler verdi, i stedet for å sende dem ut tomme, og pars hver blokk i det bygde resultatet.

En graf som navngir sider som mangler. Adressene i oppmerkingen fører til en 404, en testvert eller en speilet kopi. De ble skrevet inn for hånd eller bygget etter en annen regel enn lenkene og den kanoniske adressen. Utled hver URL i oppmerkingen fra den samme funksjonen som lager sidens kanoniske adresse, og sjekk at hver av dem faktisk ble bygget.

Les mer

Ordliste