Hvis borgeren møder en langsom kommuneside med “Ikke sikker”-advarsel, et formularflow der hakker, eller et login der fejler, er tilliden væk længe før designet får en chance.
I denne artikel får du et praktisk, teknisk funderet overblik over, hvorfor offentlige hjemmesiders synlighed i Google og borgernes oplevelse af troværdighed hænger tættere sammen end mange digitale projekter tager højde for. Vi går fra de vigtigste rankingsignaler (HTTPS, Core Web Vitals, strukturerede data) til konkrete fejltyper, der typisk opstår i kommunale webløsninger, og slutter med en prioriteret tjekliste, som webredaktører og digitale ansvarlige kan bruge i hverdagen.
Du får også en tidlig definition: Teknisk SEO er de tekniske forhold, der gør en hjemmeside let at crawle, forstå og rangere for søgemaskiner (fx sikker forbindelse, hastighed, mobilvenlighed og strukturerede data). Det betyder noget, fordi Google i stigende grad belønner sider, der er hurtige, stabile og sikre — og fordi de samme signaler ofte er præcis dem, borgere ubevidst bruger til at vurdere, om en offentlig løsning er til at stole på.
Digitalisering i kommuner: Når UX vinder budgettet, men fundamentet taber
De seneste år har mange kommuner investeret markant i selvbetjening, nye designlinjer, bedre informationsarkitektur og mere sammenhængende borgerrejser. Det er fornuftigt: en god brugeroplevelse kan reducere henvendelser, forkorte sagsgange og øge tilfredsheden. Problemet opstår, når “digitalt løft” bliver lig med det, der kan ses på skærmen, mens det tekniske fundament under løsningen ikke bliver opgraderet i samme tempo.
I praksis ser jeg ofte, at kommunale sites og subsites lever på en blanding af historiske platforme, leverandørskift, microsites til kampagner, tredjepartsformularer og integrationer til fagsystemer. Hvert led kan introducere teknisk gæld: langsomme scripts, uensartet caching, forældede TLS-konfigurationer, manglende redirects, duplikeret indhold eller skæve skabeloner, der gør strukturerede data svære at implementere. Resultatet er ikke kun lavere performance-scorer, men også en mere skrøbelig digital tilstedeværelse, hvor både stabil ranking og borgernes tillid bliver påvirket.
Hvorfor Google forbinder sikkerhed og kvalitet med synlighed
Google forsøger grundlæggende at rangere det, der giver brugeren den bedste oplevelse og det mest pålidelige svar. Derfor er det ikke overraskende, at tekniske kvalitetsmål fylder mere: de kan måles, sammenlignes og korrelerer med brugeradfærd (bounce, pogo-sticking, tid på siden). Når en side er langsom, ustabil eller usikker, stiger friktionen — og det kan slå igennem i både engagement og synlighed.
Det er vigtigt at forstå, at tekniske SEO-parametre sjældent er “én magisk knap”. De fungerer som et sæt af tillidssignaler: sikker forbindelse (HTTPS), stabile rendering-forhold (Core Web Vitals), korrekt indeksering (robots, canonicals), og tydelig semantik (strukturerede data). For offentlige institutioner er det ekstra kritisk, fordi borgerne forventer høj troværdighed, og fordi hjemmesiden ofte er indgangen til persondata, NemID/MitID-relaterede flows, tidsbestilling og ansøgninger.
Core Web Vitals i offentlige løsninger: Hastighed, stabilitet og input-respons
Core Web Vitals er Googles standardiserede målinger for oplevet performance. De er ikke kun “nice to have”; de er et fælles sprog mellem udvikling, design og SEO, som gør det muligt at prioritere forbedringer med målbar effekt.
De tre målinger, der typisk driller kommunale sites
De tre mest centrale metrics er LCP, INP og CLS. I kommunale miljøer ser jeg især udfordringer her:
- LCP (Largest Contentful Paint): Store hero-billeder, tunge PDF-preview-komponenter eller langsomme CMS-skabeloner gør, at hovedindholdet loader sent. Hvis borgeren først kan “se” siden efter flere sekunder, opleves løsningen som sløv — også selv om den teknisk set virker.
- INP (Interaction to Next Paint): Tredjeparts scripts (cookie-løsninger, analytics, chat, formular-widgets) kan blokere hovedtråden. Det ses især på mobile enheder, hvor CPU er svagere, og hvor INP hurtigt bliver dårlig, når der er meget JavaScript.
- CLS (Cumulative Layout Shift): Layout der hopper, når fonts, bannere eller dynamiske elementer indlæses. Det er en klassiker på sider med mange moduler, nyhedslister eller embeds fra eksterne systemer.
Hvad man realistisk kan gøre uden at “starte forfra”
Det kræver sjældent et total redesign at flytte nålen. Typiske high-impact tiltag i offentlige løsninger er at komprimere og korrekt dimensionere billeder, sikre caching og CDN for statiske assets, reducere antallet af tredjeparts scripts, og gennemgå skabeloner for render-blocking CSS/JS. Ofte kan man vinde meget ved at standardisere moduler i CMS’et, så redaktører ikke uforvarende skaber tunge sider med fem forskellige komponenttyper, der alle loader egne biblioteker.
Et praktisk pejlemærke: Hvis en kommunes forside eller centrale servicesider konsekvent scorer lavt i PageSpeed Insights på mobil, vil det næsten altid kunne mærkes på både brugeroplevelse og organisk performance — især på informationssøgninger, hvor borgeren sammenligner flere kilder hurtigt.
HTTPS, certifikater og sikre forbindelser som SEO- og tillidsfaktor
HTTPS er i dag en hygiejnefaktor, men det er også et konkret rankingsignal. For offentlige sites handler det ikke kun om “at have et certifikat”, men om at implementere sikker transport korrekt: TLS-konfiguration, HSTS, redirect-strategi, mixed content og certifikatfornyelse.
Typiske fejl: Det ser sikkert ud, men er det ikke
Jeg ser især disse fejl i offentlige opsætninger:
- Mixed content: Siden kører på HTTPS, men loader billeder, scripts eller iframes via HTTP. Det kan give browseradvarsler, blokering af ressourcer og en mere ustabil rendering.
- Forkerte redirects: http → https sker ikke konsekvent, eller der findes parallelle versioner (med/uden www, gamle subdomæner). Det skaber duplikeringsproblemer og spilder crawl-budget.
- Ujævn certifikatstyring: Microsites eller underdomæner bliver glemt, certifikater udløber, eller kæden er fejlkonfigureret. Selv korte udfald kan påvirke både borgertillid og indeksering.
- Forældede TLS-indstillinger: Svage protokoller/ciphers kan udløse sikkerhedsadvarsler og gøre løsningen mere sårbar.
“Hvad koster det?” er et relevant spørgsmål. Selve certifikatet kan i mange tilfælde være lavpris eller gratis, men den reelle omkostning ligger i governance: drift, overvågning, automatiseret fornyelse, test af redirects, og koordinering på tværs af leverandører og subdomæner. Det er typisk her, kommuner taber point — ikke fordi de ikke vil, men fordi ansvaret er uklart.
Når det tekniske fundament svigter: Hvad der sker i praksis
Tekniske fejl rammer sjældent isoleret. De skaber en kædereaktion mellem SEO, drift og borgeroplevelse. Et par scenarier, der går igen i offentlige webløsninger:
- Formular- eller selvbetjeningsflow går ned: Borgeren ender i telefonkø, og kommunen mister både effektivisering og tillid. Samtidig kan Google registrere øget pogo-sticking, hvis brugere hurtigt forlader siden.
- Langsomhed ved spidsbelastning: Fx ved skolestart, pladsanvisning, valg eller frister. Hvis servere, caching eller integrationer ikke skalerer, falder performance netop når behovet er størst.
- Indekseringskaos efter relancering: Manglende 301-redirects, ændrede URL-strukturer uden plan, eller canonical-fejl kan koste synlighed i måneder. Det rammer især sider med mange longtail-søgninger (åbningstider, affaldsordninger, byggetilladelser, pas).
- PDF-afhængighed: Når centrale informationer ligger i tunge PDF’er, bliver mobiloplevelsen dårligere, og indholdet bliver sværere at forstå for søgemaskiner. Det kan også påvirke tilgængelighed.
Det er her, perspektivet på cyberrobusthed i kommuner bliver relevant i en SEO-sammenhæng: Hvis platformen ikke er robust over for angreb, driftsforstyrrelser og fejlkonfigurationer, kan selv den bedste UX-strategi ikke levere stabil synlighed eller vedvarende tillid.
Strukturerede data og indholdssignaler: Så Google forstår kommunens information
Kommunale hjemmesider rummer ofte information, som Google gerne vil præsentere præcist: åbningstider, kontaktoplysninger, lokationer, arrangementer, nyheder, politiske dagsordener og servicebeskrivelser. Uden strukturerede data og konsekvent semantik bliver det sværere for søgemaskiner at udlede, hvad der er hvad — og det kan koste både klikrate og synlighed.
Hvor strukturerede data typisk giver mest værdi i det offentlige
Det handler ikke om at “markere alt”, men om at vælge de områder med størst effekt:
- Organisation og kontakt: Tydelig afsender, adresse, telefon, åbningstider og afdelinger giver bedre forståelse og kan støtte videnspaneler.
- Lokationer og borgerservicepunkter: Ensartet data på tværs af sider mindsker forvirring og øger chancen for korrekte visninger.
- Events: Borgermøder, høringer og arrangementer kan blive mere synlige, hvis de beskrives struktureret og konsekvent.
- FAQ-indhold: Når spørgsmål og svar er reelle og opdaterede, kan det forbedre match på longtail-søgninger og reducere telefoniske henvendelser.
Faldgruben: Markup uden governance
En klassisk fejl er at implementere strukturerede data én gang og derefter lade det drive. Når redaktører ændrer skabeloner, flytter moduler eller kopierer sider, bliver markup forældet eller inkonsistent. Det kan give fejl i Search Console og i værste fald gøre signalet støjende. Løsningen er at gøre strukturerede data til en del af release-processen: test i staging, validering efter deploy og faste ejerskaber.
Sikkerhed som en del af den digitale brugeroplevelse (ikke et separat spor)
Offentlige hjemmesider er ikke e-handel, men de er ofte høj-tillids-miljøer, hvor borgere forventer samme sikkerhedsniveau som netbank. Derfor bør sikkerhed tænkes som en del af UX: tydelige domæner, konsistente login-flows, korrekt cookie-håndtering, og en oplevelse uden advarsler eller “mærkelige” redirects.
Det er også her, mange projekter fejler organisatorisk: UX-teamet måler på gennemførte flows, mens IT/drift måler på oppetid og patching, og redaktionen måler på publicering. Men Google og borgeren oplever det som én samlet løsning. Når der fx ligger store tredjeparts scripts på sider med selvbetjening, kan det både skade INP og øge angrebsfladen. Når der bruges mange subdomæner og eksterne leverandør-URLs, bliver det sværere for borgere at vurdere, om de stadig er “hos kommunen”. Og når der ikke er styr på headers, redirects og certifikatfornyelse, er det pludselig browseren, der kommunikerer med borgeren — ikke kommunen.
Prioriteringsguide: Hvad webredaktører og digitale ansvarlige bør gøre nu
Det vigtigste er at prioritere det, der både forbedrer brugeroplevelse, SEO og robust drift. Her er en praktisk rækkefølge, der typisk giver hurtigst effekt i kommunale miljøer:
- Få styr på HTTPS end-to-end: Tjek redirects, mixed content, certifikatstyring på alle subdomæner og eksterne embeds. Sæt overvågning på udløb og fejl.
- Mål Core Web Vitals på de vigtigste sider: Start med top-20 landingssider fra organisk trafik og de vigtigste selvbetjeningsindgange. Brug både lab-data (PageSpeed) og feltdata (CrUX/Search Console), hvis tilgængeligt.
- Skær ned på tredjeparts scripts: Lav en “script-inventarliste”. Fjern det, der ikke bruges. Udskyd det, der ikke er kritisk. Det er ofte den billigste vej til bedre INP.
- Standardisér skabeloner og moduler i CMS: Gør det svært at lave tunge sider. Indfør redaktionelle retningslinjer for billeder, embeds og PDF-brug.
- Implementér strukturerede data, hvor det giver mening: Organisation, kontakt, lokationer, events og FAQ er typisk høj værdi. Valider og sæt ejerskab.
- Planlæg relanceringer som SEO-migreringer: URL-mapping, 301-plan, canonical-strategi, Search Console-tjek og monitorering de første 4–8 uger efter launch.
- Gør robusthed til et KPI: Ikke kun oppetid, men også fejlrate på kritiske flows, responstid ved spidsbelastning og tid til at lukke sikkerhedshuller.
“Hvordan kommer vi i gang uden ekstra budget?” er et spørgsmål jeg ofte får. Svaret er at starte med måling og oprydning: en script-audit, billedoptimering, caching og redirect-hygiejne kan ofte gennemføres inden for eksisterende rammer, hvis der er klare ejere og en fast release-rytme. De større investeringer (platform, hosting, større refaktorering) kan derefter begrundes med data: fald i performance, højere fejlrate, eller tab af organisk synlighed på centrale serviceområder.
