Det finnes en behagelig myte i webutvikling: bygg et raskt, moderne nettsted, så ordner SEO-en seg selv.
Det gjør den ikke.
Et skreddersydd nettsted gir deg et stort forsprang — ren HTML, raske sider, ingen plugin-ballast. Men søkemotorer trenger fortsatt de riktige signalene for å forstå, stole på og rangere det du har bygget. Mangler disse signalene, kan et virkelig godt nettsted forbli usynlig.
Dette er det tekniske SEO-laget vi bygger inn i hvert prosjekt. Her er den praktiske guiden — delene som faktisk utgjør en forskjell, og noen feller som fanger selv velbygde nettsteder.
Hvorfor et raskt nettsted likevel trenger et teknisk SEO-lag
Når du bygger på et rammeverk som Next.js, går mye rett av seg selv: semantisk markup, rask innlasting, mobilvennlige layouter. Det er grunnmuren søkemotorene belønner.
Men «raskt og rent» er ikke det samme som «forstått». En crawler som lander på siden din, må svare på spørsmål: Hva slags virksomhet er dette? Hvem skrev denne artikkelen? Hvor sitter denne siden i strukturen? Er innholdet verdt å vise? Ingenting av dette skjer automatisk — du må si det, eksplisitt, på et språk maskinen leser.
Det språket består mest av strukturerte data, sitemaps og Core Web Vitals — pluss noen innholdssignaler. Slik håndterer vi hvert punkt.
Strukturerte data: den største gevinsten de fleste hopper over
Strukturerte data (JSON-LD) er en liten, maskinlesbar kodeblokk som beskriver siden din. Det er dette som gir rike resultater — stjernerangeringene, FAQ-nedtrekkene, brødsmulestier og kunnskapspanel-detaljene du ser i Google.
De fleste skreddersydde nettsteder leverer lite eller ingenting av dette. Det er den største og enkleste gevinsten som ligger på bordet.
Hva som faktisk betyr noe
Du trenger ikke hver schema-type. Fokuser på dem som passer til reelle sidetyper:
- Organization — én blokk, på hele nettstedet. Navn, logo, kontaktpunkt, sosiale profiler og områdene du betjener. Slik bygger Google en enhet for virksomheten din.
- WebSite — erklærer nettstedet og språket/språkene.
- Article / BlogPosting — på hvert innlegg: overskrift, forfatter, publiserings- og endringsdato, bilde. Dette er det som gjør artikler kvalifisert for rik visning i det hele tatt.
- BreadcrumbList — sidens hierarki (Hjem › Blogg › Dette innlegget). Google viser det i resultatene i stedet for en naken URL.
- FAQPage — hvis en side faktisk svarer på spørsmål, kan dette gi utvidbare resultater.
To detaljer det er verdt å gjøre riktig: pek logo-en i Organization mot en raster-PNG, ikke et SVG-favicon (Googles retningslinjer er tydelige her), og sørg for at sameAs-URL-ene faktisk stemmer med de aktive profilene dine. Et avvik svekker stille enheten Google bygger for deg.
Sitemapet som returnerer 200 — og likevel «ikke kan hentes»
Dette er den mest subtile fellen på listen, og den fanger velbygde nettsteder — så den fortjener detaljene.
Se for deg et sitemap som gjør alt riktig: det returnerer 200 OK, leverer gyldig XML, laster på under 200 ms, har et gyldig sertifikat og er ikke blokkert av robots. Fra alle vinkler du kan teste, virker det. Og Search Console rapporterer likevel «Kunne ikke hentes.»
Den vanlige årsaken er hvordan det leveres, ikke hva som er i det. Et sitemap generert av en dynamisk app-rute kan komme tilbake med rammeverk-spesifikke caching- og innholdsforhandlings-headere som Googles sitemap-henter — en annen mekanisme enn den vanlige crawleren — ikke aksepterer. En live URL-inspeksjon kan til og med vise «Sidehenting: Vellykket», noe som får det til å se ut som en feil i Search Console.
Løsningen er å levere sitemapet som en ren statisk fil generert ved bygg — identisk innhold, rene headere. Det validerer umiddelbart. Og hvis en bestemt URL har samlet opp en «kunne ikke hentes»-historikk i Search Console, publiser samme innhold på en ny URL og pek robots.txt dit.
Lærdommen: hvis et sitemap «ikke kan hentes», men fungerer overalt du tester, mistenk hvordan det leveres, ikke hva som er i det.
Core Web Vitals og vekten av ett enkelt bilde
Innlastingshastighet er en rangeringsfaktor, og det handler mest om bytes. På de fleste nettsteder er det tyngste elementet ett enkelt hovedbilde.
Her er fellen: et detaljrikt skjermbilde på 2430px kan veie 879 KB i kilden, og selv etter et rammeverks automatiske optimalisering ligger den største leverte varianten på rundt 188 KB. På en side som bare viser det på ~1215px, er den oppløsningen ren sløsing. Skaler kilden ned til 1150px, og hver levert variant faller til rundt 52 KB — et kutt på 70 % — uten synlig tap. «Optimalisert ved levering» hjelper ikke hvis kilden er tre ganger større enn nødvendig.
Mens du er i gang, gi hvert bakgrunns- og dekorbilde eksplisitte width- og height-verdier. Manglende dimensjoner er en hovedårsak til layout-forskyvning — det irriterende hoppet mens en side laster — som Core Web Vitals straffer direkte.
Innholdssignaler: lesbarhet og overskrifter
To mykere signaler runder av det tekniske laget.
Lesbarhet. Automatiske verktøy flagger tekst som leser på et «vanskelig» nivå. Ofte er setningene greie — det er ordforrådet som er tett med formelle, flerstavelsesord. Å bytte «benytte» med «bruke», «i henhold til» med «under», og dele opp noen lange setninger løfter skåren uten å forenkle noe bort. Klarere tekst er bedre for lesere og maskiner.
Overskrifter. En myte verdt å avlive: flere <h2> på en side er ikke et problem. Noen verktøy flagger det, men det er korrekt HTML — hver side med mer enn én seksjon bør ha mer enn én <h2>. Det som betyr noe er en logisk rekkefølge: én <h1>, seksjoner som <h2>, underpunkter som <h3>. Ikke hopp over nivåer, og ikke slå sammen ekte seksjoner bare for å tilfredsstille et verktøy.
Brødsmuler: schema og den synlige stien
Brødsmuler gjør to jobber. BreadcrumbList-schemaet lar Google vise stien i resultatene. Den synlige brødsmulen hjelper brukere og forsterker hierarkiet. Gjør begge deler, og hold URL-ene kanoniske — en brødsmule som peker mot en videresendende URL er en liten, unødvendig sløsing.
Sjekklisten
Hvis du går gjennom et skreddersydd nettsted, her er kortversjonen:
- Organization + WebSite JSON-LD, på hele nettstedet, med raster-logo og korrekte
sameAs. - Article-schema på innlegg, med
datePublished,dateModified, forfatter og bilde. - BreadcrumbList-schema — pluss en synlig sti — på nøstede sider.
- Sitemap levert som en statisk fil; hver interne lenke peker mot kanoniske (ikke-videresendende) URL-er.
- hreflang / canonical korrekt på hver lokaliserte side.
- Bilder: kilde ikke større enn nødvendig, eksplisitte
width/height, moderne formater. - Metadata: unike titler under ~60 tegn, beskrivelser under ~155.
- Overskrifter: én
<h1>, logisk<h2>/<h3>-struktur. - Robots + indeksering: bekreft at viktige sider er indekserbare og at videresendinger løser seg rent.
En skreddersydd bygging får deg nesten helt fram — men den siste milen med teknisk SEO er det som gjør et raskt nettsted synlig. Ingenting av det er glamorøst. Alt av det bygger seg opp.
Det er arbeidet vi bygger inn i prosjekter og kjører som frittstående gjennomganger. Hvis ditt skreddersydde nettsted stille underpresterer i søk, la oss ta en prat — en teknisk gjennomgang avdekker som regel en håndfull fikser med uforholdsmessig stor effekt.