JSON-LD der matcher siden — ellers er det et script, I håber på

Structured data er et løfte til to parter: crawlen, der gerne vil forstå siden uden at gætte, og den quality-rater (menneske eller system), der tjekker om I snyder. Løftet holder, når FAQ-markup matcher de spørgsmål, I faktisk viser, når Article har den forfatter og dato, siden viser, når Organization har det navn og CVR, footeren har. Det rådner, når I håber på stjerner, FAQ-udtræk eller et knowledge panel ved at beskrive noget, brugeren ikke kan se.

Teams gør det, fordi et plugin eller et bureau-slide sagde 'tænd schema, så får I rich results'. Det første test-værktøj bliver grønt. Det bliver vanen. Tre måneder senere har forsiden LocalBusiness, Product, FAQPage og Review i ét script, og ingen af delene står som indhold. Google viser ikke stjernerne. Engang imellem viser Search Console 'either/or' eller 'non-critical issues'. I retter en advarsel. I rører ikke sandheden.

Skaden er ikke kun manglende rich results. Markup, der overdriver, er et signal I har bedt om at blive behandlet som det. Et Review I selv skrev. Et AggregateRating uden kilder. En FAQ, der kun eksisterer i JSON. En pris I puttede i Product, I ikke viser — og som vi i øvrigt ikke putter på et marketing-site. I har fortalt en maskine noget, I ikke vil stå ved på siden. Det er det modsatte af SEO. Det er at bede om at jeres ærlige sider også bliver mødt med skepsis.

Vi skriver det, fordi 'vi har JSON-LD' er blevet et tjek, I sætter ved go-live. Et ærligt setup er kedeligt: ét @type der passer til siden, felter I kan pege på, og ingen noder I tændte 'for en sikkerheds skyld'. Uden den vane har I et script fra pluginet. I har ikke structured data.

JSON-LD er et script af typen `application/ld+json`, der beskriver siden med schema.org-typer. Det er ikke en hemmelig ranking-faktor, I kan tænde. Det er en etiket på det, I allerede har skrevet. WebSite og Organization på et site, der har et navn og en forside. Article på et indlæg med forfatter og dato. Service på en ydelse, I beskriver. FAQPage på en side, der viser spørgsmål og svar. BreadcrumbList på det spor, brugeren kan se. Hver type er et job. Ikke en hylde, I tømmer ned i `<head>`.

Det er ikke det samme som Open Graph. og Twitter-tags. De er deling: titel, beskrivelse, billede, når nogen poster URL'en. JSON-LD er betydning: hvad er det her for en slags side, hvem udgiver den, hvilke spørgsmål står der. I kan have ærlig OG uden JSON-LD. I kan have JSON-LD der modsiger OG og H1. Crawlen og messenger-unfurlen vælger så. I har ikke valgt. Skriv H1 og meta først. Skriv JSON-LD som et spejl, ikke som et andet udkast.

Det er heller ikke det samme som en sitemap eller en canonical. Sitemap'et er listen over URL'er, I gerne vil have crawlet. Canonical er hvilken variant der er foretrukket. JSON-LD siger hvad den foretrukne side betyder. At lime Organization på alle URL'er og glemme Article på indlægget, er at sige at hver side er firmaet. At lime FAQPage på alle URL'er er at sige at hver side er et spørgsmål-svar. Begge dele er løgne, hvis siden er et marketing-afsnit uden den blok.

Og det er ikke 'Yoast / RankMath / et React-komponent der dumper hele grafen'. Et plugin kan være et værktøj, hvis I slukker det, I ikke har indhold til. Et komponent kan være et værktøj, hvis det læser den samme dictionary som siden renderer. Det, der typisk går galt, er et dump: alle typer, tomme felter, en adresse I ikke vil være LocalBusiness på, og et review I aldrig fik. Inventaret er det script, I deployer, og den HTML, det spejler. Alt andet er et håb, I har sat hos en vendor.

Den første fejl er at tænde typer, siden ikke er. LocalBusiness på et site, der sælger nationalt og internationalt — I har en dansk adresse, I er ikke en butik med åbningstider som det primære. Product på en ydelse uden et synligt produkt, uden tilbud, uden det I må vise som pris. Review og AggregateRating I selv skrev, 'så vi kan få stjerner'. Hver forkert type er et sted, et test-værktøj kan blive grønt, og en rater kan sige nej. Vælg den type, I kan forsvare i et møde, hvor nogen åbner siden ved siden af scriptet.

Den anden fejl er felter, der ikke står på siden. En `description` der er et andet udkast end leadet. En `author` der ikke er navngivet. En `datePublished` I satte til i dag på et gammelt indlæg, hver gang I deployer. Et `telephone` i Organization, I ikke viser. Google har gentaget: markup skal matche synligt indhold. Det er ikke en guideline, I kan 'tage senere'. Det er hele jobbet. Hvis feltet er sandt, så vis det. Hvis I ikke vil vise det, så lad være at markere det.

Den tredje fejl er at lime den samme graf på alle sider. Forside, ydelse, indlæg, 404 — samme Organization + FAQ + WebSite i ét klumpet script. Organization og WebSite kan høre til på forsiden og i et site-wide blok, I holder ærligt. FAQ hører til der, FAQ'en er. Article hører til på artiklen. En 404 med Article er en løgn. Fejlsider-indlægget er chrome. Her er at lade scriptet følge skabelonen, ikke at lade layoutet være et dump.

Den fjerde fejl er at jagte rich results som målet. Stjerner, FAQ-udtræk, sitelinks searchbox. Nogle af dem er indskrænket, udfaset eller givet til sider, der allerede har tillid. I kontrollerer markup. I kontrollerer ikke udtrækket. Et ærligt Article med forfatter, dato og et billede, siden viser, slår et Review I opfandt. Hvis I vil have FAQ-udtræk, så skriv FAQ'en som indhold først. Scriptet kommer bagefter. SEO-indlægget om hastighed er LCP. Den her er at nægte at lade et håb om SERP-pynt styre hvad I putter i `<head>`.

Forsiden er det job, der oftest får hele kataloget. Den er firmaet og sitet: Organization med legalName, adresse I vil stå ved, sameAs til de profiler I faktisk ejer, WebSite med det navn I bruger. Den er ikke LocalBusiness, medmindre det lokale sted er produktet. Den er ikke FAQPage, medmindre forsiden viser spørgsmålene. Den er ikke Product. Et ærligt site-wide blok slår et dump, I kopierede fra et theme.

Artiklen er det job, der oftest glemmer forfatter og dato, eller sætter dem i scriptet og skjuler dem i UI. BlogPosting / Article med headline = H1, datePublished = den dato, I viser, author = den byline, I viser, image = det hero, I viser. Opdater dateModified når I faktisk redigerer, ikke når I deployer. Et indlæg uden synlig dato skal ikke have en dato i JSON-LD, I håber på i SERP'en.

Ydelsen er det job, der oftest bliver Product med Offer, fordi nogen ville have pris-markup. En ydelse er Service: navn, beskrivelse, provider der peger på Organization. Area served, hvis I mener det. Ikke et prisfelt, I ikke viser — og som I på det her site ikke skal vise. Et Offer uden synlig pris er en løgn. Et Offer med en pris, I ikke vil forsvare i et opkald, er værre. Skriv hvad I laver. Marker det. Lad prisen blive i samtalen.

FAQ'en er det job, der oftest bliver et skjult array. FAQPage er rigtigt, når siden viser spørgsmål og svar som indhold — ikke som accordion I har `display:none` på, og ikke som H2'er I aldrig stillede som spørgsmål. Fire til seks rigtige spørgsmål slår tyve tynde. JSON-LD'en er det samme array, blokken renderer. Hvis I fjerner blokken, fjerner I noden. Search Console-udtræk er en bonus, I ikke styrer. Den synlige FAQ er jobbet.