Teknisk SEO-sjekkliste: Den ultimate listen for å forbedre nettstedet ditt

Teknisk SEO-sjekkliste

Gjennomsøking og indeksering

Det første du må se på under den tekniske revisjonen er hvordan nettstedet ditt indekseres og gjennomsøkes av søkemotorer. Tross alt, hvis sidene på nettstedet ditt ikke kan gjennomsøkes, vil de ikke bli indeksert (med få unntak). Som en konsekvens vil sidene som ikke er representert i indeksen ikke delta i rangeringen.

Gå gjennom sideindekseringsrapporten i Google Search Console

Den mest nøyaktige og pålitelige måten å analysere indekseringen av nettstedet ditt på er å analysere sideindekseringsrapporten i Google Search Console.

Se på rapporten for indekserte sider, og sjekk hvilke sider som er i indeksen. Se om det finnes sider med filtrerings- eller sorteringsalternativer, om det finnes testsider eller andre sider du ikke vil indeksere.

Se også på sider som er ekskludert.

Ikke alle statuser i rapporten Ekskluderte sider er et problem. Du bør ikke fokusere oppmerksomheten på alle ekskluderte sider, men bare på de der Googles oppførsel ikke samsvarer med intensjonene dine.

I tabellen nedenfor kan du se statusene som har en tendens til å kreve oppmerksomhet og dypere analyse:

Status	Hva det betyr	Hva du bør gjøre
Feil ved omdirigering	Google kunne ikke følge nettadressen på grunn av omdirigeringsproblemer.	Reduser antall omdirigeringer (til 1-2). Unngå uendelige og sirkulære omdirigeringer.- Sørg for at den endelige URL-en returnerer 200 OK og ikke er blokkert i robots.txt/noindex.
Serverfeil	Serveren returnerte en 5xx-feil.	Sjekk serverlogger. Sørg for at nettstedet ikke er overbelastet.- Fiks interne feil, spesielt hvis de gjentar seg.
Oppdaget – ikke indeksert	Google vet om siden, men har ikke gjennomsøkt den ennå. Indikerer problemer med gjennomsøkingsbudsjettet.	Kontroller at siden er i områdekartet. Legg til interne lenker til den. Optimaliser gjennomsøkingsbudsjettet.
Gjennomsøkt – ikke indeksert	Google besøkte siden, men valgte å ikke indeksere den. Indikerer vanligvis lav sidekvalitet.	Forbedre kvaliteten og unikheten til innholdet. Sørg for at siden ikke har duplikater. Legg til interne lenker til den.
Dupliser uten brukervalgt kanonisk	Google anser siden som en duplikat, men du har ikke spesifisert en kanonisk.	Kontroller sideparene og angi nødvendig kanonisk eller vurder områdestrukturen på nytt.
Dupliser, Google valgte en annen kanonisk enn bruker	Google ignorerte den angitte kanoniske artikkelen.	Det kan være mange grunner; Du må undersøke sidedataene nøye og velge den mest hensiktsmessige strategien (noindex, omdirigering, fjerning, robots.txt, endringer i nettstedsstruktur og intern lenking).
Myk 404	Siden ser «tom» eller «ikke funnet» ut, men returnerer statusen 200 OK.	Returner 404 eller 410. Lag en omdirigering. Forbedre innholdet. Blokker fra indeksering.

De andre statusene signaliserer sannsynligvis ingen problemer. Disse rapportene er imidlertid også verdt å gjennomgå for å sikre at sidene ikke har blitt fjernet, omdirigert, kanonisert eller blokkert fra indeksering ved en feiltakelse.

Status	Hva det betyr	Hva du trenger å vite
Alternativ side med riktig kanonisk kode	Google anerkjente korrekt kanonikken du spesifiserte.	Alt fungerer som forventet. Ingen handling kreves. Sørg for at du har spesifisert ønsket kanonisk.
URL-adresse blokkert av robots.txt	Google kan ikke gjennomsøke siden.	Sjekk robots.txt filen. Tillat tilgang hvis du vil at den skal indekseres.
URL-adresse merket «noindex»	Siden har noindex-direktivet.	Sørg for at noindex-taggen er angitt med vilje. Hvis siden er viktig, fjerner du denne taggen.
Ikke funnet (404)	Siden eksisterer ikke.	Hvis dette er viktig, gjenopprett siden. Hvis siden slettes permanent, må du sørge for at det ikke er noen interne lenker til den.
Blokkert på grunn av uautorisert forespørsel (401)/ Blokkert på grunn av tilgang forbudt (403)	Siden er blokkert av autorisasjon eller forbudt.	Tillat tilgang hvis siden skal indekseres.
Side med omdirigering	Siden omdirigerer til en annen.	Sjekk om omdirigeringen er tiltenkt og riktig.
URL blokkert på grunn av andre 4xx-problemer	Siden er utilgjengelig på grunn av en annen 4xx-feil enn 404 (f.eks. 403, 401, 410 osv.).	Sjekk HTTP-statuskoden manuelt. Fiks tilgangsinnstillinger. Angi riktige statuskoder eller omdirigeringer. Gi tilgang til Googlebot om nødvendig.

I Googles brukerstøtte finner du en omfattende beskrivelse av siderapporten, inkludert eksempler på problemer og en detaljert forklaring av hver status.

Screaming Frog kan også hjelpe med å analysere sider som er indeksert eller ekskludert fra indeksen. For å gjøre dette må du koble til Google Search Console API før du starter gjennomsøkingen av nettstedet.
For å koble til, gå til Konfigurasjon -> API-tilgang -> Google Search Console. Klikk på Logg på med Google og følg instruksjonene.

Når du er koblet til, aktiverer du URL-inspeksjon, og du kan også aktivere alternativet for å ignorere indekseringsinspeksjon for URL-adresser som ikke kan indekseres.

Du vil da kunne se og sammenligne statusen til hver side i henhold til Search Console (slik Google ser den) og dens faktiske status som bestemt under gjennomsøkingsprosessen.

Vær oppmerksom på at bare 2000 nettadresser per dag er tilgjengelige for hvert nettsted, så denne metoden er mer egnet for små nettsteder.

Sjekk hva som står i sitemap.xml

Sitemap.xml er en XML-fil som gir søkemotorsøkeroboter en liste over sider på et nettsted, samt (valgfritt) informasjon om siste endringsdato, oppdateringsfrekvens og anbefalt kravlesøkprioritet.

Det er vanligvis plassert ved roten av nettstedet, for eksempel: https://example.com/sitemap.xml. Sitemap.xml hjelper søkemotorer med å finne nye eller oppdaterte sider raskere. I tillegg er inkluderingen av en side i denne filen et av signalene for å bestemme den kanoniske versjonen av en side, om enn en svak en.

sitemap.xml filen er spesielt nyttig for:

• nye nettsteder med få eksterne lenker;
• store nettsteder med mange sider;
• nettsteder med mye medieinnhold;
• nyhetssider som oppdateres ofte.

Sitemap.xml bør inneholde alle sidene du vil indeksere.

Du kan bruke den samme Screaming Frog eller andre crawlere for å analysere sidene som er inkludert i Sitemap.xml. I Screaming Frog kan sitemap.xml skannes separat i listemodus, eller den kan inkluderes i en vanlig nettstedsskanning. For å gjøre dette, i Konfigurasjon -> Spider -> Crawl, aktiver XML-nettstedskartskanning og legg til de absolutte nettadressene til nettstedskartene du vil gjennomsøke.

Det anbefales ikke å bruke ulike nettjenester for å generere et nettstedskart, da de kanskje bare genererer et statisk nettstedskart som ikke oppdateres automatisk. Det optimale alternativet er å generere sitemap.xml ved hjelp av plugins for CMS som nettstedet kjører på, eller å skrive et tilpasset skript som genererer nettstedskartet i henhold til spesifiserte forhold og automatisk oppdaterer det når det gjøres endringer på nettstedet.

Når du genererer sitemap.xml, sørg for at filen din er i samsvar med sitemap.xml protokollen. Du kan bruke ulike online validatorer til dette, for eksempel https://www.xml-sitemaps.com/validate-xml-sitemap.html.

Er det nødvendig å inkludere alle taggene som er oppført i protokollen? Ikke alltid. For eksempel vurderer Google bare taggene <loc> og <lastmod>. Pass på at datoen i <lastmod>-taggen er nøyaktig. Hvis det er forsøk på å manipulere den, kan Google ignorere denne taggen.

Sørg for at det ikke er noen feil i robots.txt

Den robots.txt filen er det første stedet en søkerobot ser før den gjennomsøker et nettsted. Den bestemmer hvilke deler av nettstedet som kan eller ikke kan gjennomsøkes, og som et resultat hvilke sider som skal indekseres av søkemotorer. Den skal alltid være plassert på https://example.com/robots.txt.

Denne filen er et verktøy for å administrere gjennomsøking (ikke indeksering!) av nettstedet. Noen sider, selv om de er blokkert i robots.txt, kan fortsatt indekseres (vanligvis hvis det er interne eller eksterne lenker til dem). Slike sider (indeksert til tross for at de er blokkert i robots.txt) kan sees i Google Search Console i rapporten «Indeksert, men blokkert av robots.txt».

Her er hva du bør være sikker på å sjekke angående den robots.txt filen som en del av en teknisk SEO-revisjon:

1. Filens tilgjengelighet

Filen skal være tilgjengelig på https://example.com/robots.txt og gi en 200 OK svarstatus. Fravær, nedlastingsfeil eller omdirigeringer (301, 302, 403, 404) kan hindre søkemotorer i å forstå nettstedets gjennomsøkingsregler riktig.

1. Syntaks og korrekthet

Kontroller at filstrukturen følger standarden. Eksempel på en grunnleggende mal:

• Bruker-agent: *
• Ikke tillat: /admin/
• Tillat: /offentlig/
• Nettstedskart: https://example.com/sitemap.xml

1. Ikke tillat og tillat direktiver

Sjekk at viktige sider ikke blir forbudt ved et uhell, f.eks.:

• Hjem (/)
• Produktkort (/produkt/)
• Blogg eller artikler (/blogg/, /artikler/)

En vanlig feil er å blokkere bilder, stiler og skript når du blokkerer administrative mapper. I et slikt tilfelle bør det spesifiseres at selv om den administrative mappen er blokkert, bør noen typer filer være åpne for skanning. Dette skjer ofte på WordPress-nettsteder når mappen med alt brukerinnhold, Disallow: /wp-content er blokkert.

I dette tilfellet kan bare filer av et bestemt format åpnes for skanning:

• Tillate: /wp-innhold/opplastinger/*.css
• Tillate: /wp-innhold/opplastinger/*.js
• Tillate: /wp-innhold/opplastinger/*.jpeg

Hvis du vil validere robots.txt og teste direktivene du legger til, kan du bruke dette verktøyet.

1. Sjekk kompatibilitet med andre direktiver

Feil oppstår ofte når robots.txt er i konflikt med:

• metakode <metanavn=»roboter» content=»noindex»>
• Kanonisk

For eksempel, hvis en side er åpen i robots.txt, men blokkert via noindex, vil den bli gjennomsøkt, men vil ikke komme inn i indeksen. Dette er akseptabelt, men det er viktig at det gjøres med vilje.

Et vanlig problem er også når det er andre instruksjoner for roboter i kildekoden og en samtidig blokkering av siden i robots.txt. Søkemotorroboter skanner ikke sider som er blokkert i robots.txt. De ser ikke kodene som er spesifisert i koden, for eksempel kanonisering. Det vil si at en slik kanonisk rett og slett ikke vil bli gjort rede for.

Sjekk din interne kobling

En av hovedoppgavene til en teknisk revisjon er å sikre at nettstedets interne kobling fungerer som den skal. Dette betyr at alle interne lenker må føre til ekte, eksisterende sider som er åpne for indeksering, returnere en 200 OK-statuskode, ikke inneholde omdirigeringer, og, viktigst av alt, ikke peke til sider med 4xx/5xx-feil. Ved første øyekast kan dette virke som en mindre detalj, men i praksis kan til og med feil interne lenker påvirke negativt:

• Effektiviteten av gjennomsøking av nettsteder av søkemotorer,
• Fordelingen av intern SEO-vekt (PageRank),
• Brukeropplevelse.

Det første trinnet i analysen er å sjekke alle interne lenker for feil. Det er spesielt viktig å identifisere ødelagte koblinger som fører til sider med 404, 410 eller andre feil (for eksempel 403, 500).
Nedenfor er en tabell med hovedtyper av feil som kan oppstå i interne lenker, deres betydning og anbefalte handlinger for å fikse dem.

Feiltype	Hva det betyr	Hva du skal gjøre
404	Finner ikke siden	Fjern lenken eller erstatt den med en fungerende lenke
403	Tilgang forbudt	Sjekk tilgangsinnstillingene
301/302	Omdirigere	Oppdater koblingen til den endelige URL-adressen
5xx	Serverfeil	Sjekk serveren eller CMS

 

Det er også viktig å analysere dybden i sidehierarkiet, noe som betyr å finne ut på hvilket nivå og hvor mange klikk unna hjemmesiden nøkkelinnholdet befinner seg. Det er å foretrekke at viktige sider ikke er dypere enn det tredje nivået – dette øker tilgjengeligheten for både søkemotorer og brukere.
Et av nøkkelelementene i analysen er å identifisere «foreldreløse» sider – de som ikke har noen interne lenker som peker til dem. Selv om disse sidene er inkludert i nettstedskartet, gjør mangelen på interne lenker dem mindre tilgjengelige.
I tillegg er det viktig å analysere ankertekster – ordene og uttrykkene som inneholder lenker. De bør være relevante og meningsfulle, ettersom ankertekster hjelper søkemotorer med å forstå konteksten til lenken.

Analysere gjennomsøkingsstatistikken

Analyse av gjennomsøkingsstatistikk er en måte å forstå hvordan Googlebot samhandler med et nettsted: hvilke sider som gjennomsøkes, hvor ofte og hvordan dette påvirker SEO. Disse dataene er tilgjengelige i Google Search Console → Innstillinger → gjennomsøkingsstatistikk. I tabellen nedenfor kan du se de vanligste problemene du kan finne ut i denne rapporten:

Problem	Hva du bør se etter i rapporten	Mulige årsaker
Kraftig reduksjon i kryping	Færre gjennomsøkinger per dag	Tilgjengelighetsproblemer, feil innstillinger i robots.txt, blokkeringer, 5xx-feil
Mange 4xx- og 5xx-feil	Feil i URL-adresser	Slettede sider, ødelagte lenker, serverproblemer
Økt responstid	>1 sekund – et advarselsskilt	Hostingproblemer, serveroverbelastning
Mange 3xx omdirigeringer	Viderekoblinger i stedet for direkte nettadresser	Feil omdirigeringer, omdirigeringskjeder, et stort antall interne lenker med omdirigeringer
CSS/JS ikke gjennomsøkt	De mangler i statistikken	Blokkert av robots.txt

 

I tillegg kan serverlogger analyseres. De lar deg se de faktiske forespørslene fra søkeroboter (ikke bare Googlebot, men også Bingbot, YandexBot og andre), i stedet for bare aggregerte data fra Google Search Console.
Dette er en avansert, «rå» diagnostisk metode som krever betydelig tid. For å visualisere dataene kan du bruke åpen kildekode-verktøy som GoAccess eller Screaming Frog Log File Analyser.

Implementere strukturerte data

Strukturerte data er et spesielt markeringsformat på en nettside som hjelper søkemotorer med å forstå innholdet på siden mer nøyaktig og dypere. Det fungerer som et «hint» for Google og andre søkemotorer om hva som er på siden – en artikkel, produkt, oppskrift, anmeldelse, video osv. Selv om det ikke er et offisielt rangeringssignal, påvirker det indirekte rangeringen ved å forbedre hvordan søkemotorer forstår siden.

Hovedstandarden eller protokollen som brukes for strukturerte data på nettsteder er Schema.org. Det finnes andre protokoller, for eksempel OpenGraph, men den brukes til sosiale nettverk.
Schema.org er et samarbeidsprosjekt mellom Google, Microsoft, Yahoo og Yandex, opprettet for å utvikle og vedlikeholde en enhetlig standard for strukturerte data på nettet.
Schema.org inkluderer hundrevis av enhetstyper, med de mest brukte oppført i tabellen nedenfor:

Kategorienhet	(@type)	Formål
Innhold og sider	Artikkel	En artikkel eller et nyhetsinnhold
	Blogginnlegg	Et blogginnlegg
	Nyhetsartikkel	En nyhetsartikkel for Google Nyheter
	VANLIGE SPØRSMÅLPage	En side med ofte stilte spørsmål (FAQ)
	Slik gjør du det	En trinn-for-trinn-guide
	Nettside	Generell informasjon om en nettside
Produkter og tilbud	Produkt	produkt Beskrivelse
	Tilby	Pristilbud
	Samlet tilbud	Prisklasse for et produkt fra forskjellige selgere
Anmeldelser og vurderinger	Anmeldelse	En anmeldelse av et produkt eller en tjeneste
	Vurdering	En numerisk vurdering (ofte i en anmeldelse)
	Samlet vurdering	Gjennomsnittlig vurdering basert på flere anmeldelser
Organisasjoner og mennesker	Organisasjon	En beskrivelse av en bedrift eller merkevare
	Lokal virksomhet	En lokal bedrift med kontaktinformasjon og tidsplan
	Person	En person (f.eks. artikkelforfatter, foredragsholder osv.)
Hendelser	Begivenhet	Et arrangement på eller utenfor nettet
Navigasjon og struktur	Brødsmuler Liste	Brødsmuler navigasjon
	SiteNavigationElement	Elementer i hovedmenyen
Multimedia	VideoObjekt	Video med metadata (for videosnutter)
	Bilde-objekt	Bilde med beskrivelse
Utdanning og jobber	Kurs	Et nettbasert kurs eller opplæringsprogram
	Stillingsannonser	Ledige stillinger (for Google for jobber)

Det anbefales å implementere strukturerte data i JSON-LD-formatet. Denne blokken plasseres i <hodet> eller <kroppen> av HTML-dokumentet, men den vises ikke for brukeren – den leses av søkeroboter. Alle store søkemotorer, som Google, Bing og Yahoo, støtter dette formatet. Et eksempel på JSON-LD-kode er vist nedenfor:

<script type=»application/ld+json»>

{

«@context»: «https://schema.org»,

«@type»: «Artikkel»,

«headline»: «Hva er JSON-LD?»,

«forfatter»: {

«@type»: «Person»,

«navn»: «John Smith»

},

«datoPublisert»: «2025-12-01»

}

</skript>

Når du implementerer strukturerte data, følg den Schema.org protokollen og bruk validatoren til å kontrollere riktigheten av de implementerte mikrodatatypene. Noen typer strukturerte data fra Schema.org-protokollen kan også hjelpe deg med å vise rike tekstutdrag i Googles søkeresultater.

Vær oppmerksom på at Googles krav til strukturerte data for detaljerte tekstutdrag avviker noe fra Schema.org standarden. Ofte må flere felt spesifiseres enn det Schema.org protokollen krever. Så hvis du ønsker å oppnå en Rich Snippet, følg Googles retningslinjer for strukturerte data. Du kan kontrollere riktigheten av mikrodataimplementeringen ved hjelp av validatoren for rik snutt.

Det finnes også mange mikrodatageneratorer, men de kan bare lage statisk kode som ikke vil bli oppdatert med innholdsendringer på siden. Å sikre at informasjonen i mikrodataene samsvarer med det som er synlig for brukerne på siden, er en del av Googles krav til strukturerte data. Hvis retningslinjene for strukturerte data brytes, kan siden miste alle detaljerte utdrag og i noen tilfeller bli utsatt for manuelle sanksjoner. Sørg derfor for at mikrodataene dine er automatisk generert og automatisk oppdatert.

Innhold

Som en del av en teknisk SEO-revisjon er det viktig å evaluere de grunnleggende innholdsegenskapene: fra strukturen til overskrifter og metakoder til tilstedeværelsen av alt-attributter for bilder og potensielle dupliserte sider. Disse elementene påvirker direkte både indeksering og hvordan søkemotorer oppfatter nettstedet.

Test nettstedet ditt for fullstendige duplikater

Fullstendige duplikater oppstår når identisk innhold er tilgjengelig via forskjellige nettadresser på nettstedet. Duplikater kan skade nettstedets rangering fullstendig.
De vanligste typene fullstendige duplikater er:

• Tilgjengelighet via både HTTP og HTTPS
• Tilgjengelighet med og uten WWW
• Tilgjengelighet med eller uten etterfølgende skråstrek
• Tilgjengelighet for URL-adresser med store og små bokstaver
• Siden er tilgjengelig med filtyper som .html, .htm, .php, .aspx og uten dem
• Parametere som ikke endrer sideinnholdet, for eksempel UTM-koder
• Identisk innhold under forskjellige nettadresser. Et produkt er for eksempel oppført i to kategorier, tilgjengelig via to forskjellige nettadresser. Eller produktsiden som er tilgjengelig med og uten kategorien i URL-en.
• Testversjoner av nettstedet (DEV-domene som brukes til utvikling).

For å finne sideduplikater relatert til nettadressevarianter, test nettadressene manuelt og sjekk tjenerens svarkode for disse nettadressevariantene. Du kan bruke et hvilket som helst verktøy til å sjekke serverens svarkoder, for eksempel https://httpstatus.io/. Skriv inn URL-variantene og sjekk tilgjengeligheten deres.

For å fikse problemer med variasjoner i HTTP/HTTPS, www/without-www, med/uten skråstrek, store/små bokstaver og tilgjengeligheten til sider med utvidelser som .html, .htm, .php, .aspx og uten dem, er det nødvendig å sette opp en 301-omdirigering til den foretrukne versjonen.

Når det blir funnet duplikater på grunn av tilgjengeligheten av identisk innhold ved å legge til eller fjerne deler av nettadressen (for eksempel er et produkt tilgjengelig i to kategorier), er det best å revurdere nettadressestrukturen og nettstedsstrukturen. For UTM og andre parametere kan kanonisering også være en løsning. Det er imidlertid viktig å merke seg at Google behandler den kanoniske taggen som en anbefaling, og den endelige avgjørelsen om hvilken URL du skal velge forblir hos Google.

Hvis en testversjon av nettstedet finnes i Google-indeksen, bør den blokkeres fra indeksering, og en forespørsel om fjerning bør sendes gjennom Google Search Console.

Løse delvise sideduplikater

Delvise sideduplikater oppstår når to eller flere sider på nettstedet inneholder svært likt, men ikke helt identisk innhold. De vanligste typene delvise duplikater er:

• Sortere sider
• Filtrere sider
• Pagineringssider
• Sider med lignende produkter (f.eks. produkter er bare forskjellige etter farge)
• Flere versjoner av nettstedet på samme språk, men for forskjellige regioner (f.eks. tre engelske nettsteder for USA, Storbritannia og Australia).

Selvfølgelig er hvert nettsted unikt, og under en teknisk revisjon kan du identifisere andre tilfeller av duplisert innhold som krever spesifikke løsninger. Eksemplene ovenfor er imidlertid de vanligste.

Delvise duplikater blir vanligvis funnet under gjennomsøkingsprosessen av forskjellige søkeroboter. De vil ha repeterende parametere og kan ha samme tittel og H1 som hovedkategorisidene.
For å eliminere delvise duplikater kan du ikke sette opp en omdirigering, da disse sidene er nødvendige for nettstedets funksjonalitet. Nedenfor vil vi diskutere metoder for å håndtere delvise duplikater.

Sortere og filtrere sider

Disse sidene kan blokkeres fra å gjennomsøkes i robots.txt filen, men dette kan ignoreres av Google, spesielt hvis linker peker til disse sidene. Dette vil bidra til å bevare gjennomsøkingsbudsjettet.
Du kan også blokkere dem via <meta name=»robots» content=»noindex, nofollow» />-direktivet, som vil forhindre at disse sidene indekseres, men ikke vil fortelle Google at de ikke skal gjennomsøkes.
Den beste fremgangsmåten i dette tilfellet er å bruke JavaScript til å oppdatere innholdet på siden når brukeren bruker sortering eller filtre, uten å generere flere URL-adresser og koblinger til filtrering eller sortering av sider.

Produktvarianter tilgjengelig på forskjellige nettadresser

Ideelt sett bør alle produktvarianter kombineres på én side, der brukeren kan velge ønsket farge eller størrelse uten å endre URL-en, ved hjelp av JavaScript. Men hvis en egen side brukes for hver variant, bør en kanonisk lenke til hovedproduktsiden spesifiseres. Men som nevnt tidligere kan Google ignorere det kanoniske settet av brukeren.

Pagineringssider

Pagineringssider bør ikke blokkeres fra indeksering. Slik sikrer du at Google anser den første siden i kategorien som den viktigste:

• Inkluder bare den første siden i den sitemap.xml filen.
• Legg til en kobling til hovedkategorisiden på alle pagineringssider.
• Legg til sidetall i tittelen og H1 på pagineringssidene. For eksempel «Hvite skjorter – side 2.»

Sider som er tilgjengelige på ett språk, men for forskjellige regioner

I dette tilfellet må Hreflang-attributter brukes. De brukes til å fortelle søkemotorer hvilket språk og regional versjon av en nettside de skal vise til brukere basert på deres språkpreferanser og plassering.
Det er flere måter å implementere Hreflang-attributter på:

• I HTTP-hoder
• Via tagger i <head>-delen
• Via tagger i sitemap.xml

Den enkleste metoden å implementere er gjennom tagger i delen <hode>.

Det er reglene som hreflang-attributter implementert via tagger i <head>-delen skal oppfylle:

• • Attributtet skal ha følgende format: <link rel=»alternate» hreflang=»lang_code_country_code» href=»url-of-page» />
  • Språk- og landskoder skal være gyldige. For å velge gyldig kode for hver språkmutasjon, se denne siden.

• Hver språkversjon må liste seg selv så vel som alle andre språkversjoner i sine hreflang-attributter. Det betyr at hver side må ha samme antall hreflang-attributter

• Lenker i hreflang-attributter bør være absolutte og indekserbare.

Et eksempel på en kode:

<link rel=»alternate» href=»https://example.com/en-us/page» hreflang=»en-us» />

<link rel=»alternate» href=»https://example.com/en-gb/page» hreflang=»no-no» />

<link rel=»alternate» href=»https://example.com/en-us/page» hreflang=»x-default» />

Sjekk titler, h1, h2s og beskrivelser for duplikater

Selv om titler, beskrivelser og H1-H6-overskrifter er relatert til SEO på siden, kan analysen av dem i en teknisk revisjon være nyttig for å oppdage duplikater.

Å analyseredem, kan du bruke hvilken som helst crawler som samler inn disse taggene.

Når dupliserte titler, H1-H6-tagger og beskrivelser blir funnet, analyserer du sidedataene og identifiserer årsaken til dupliseringen. Dette kan skyldes tilgjengeligheten til nettstedet via både HTTP og HTTPS, duplisering av hovedkategorikodene på filtersider, eller rett og slett en menneskelig feil der disse taggene ble feil utfylt.

Optimaliser alt-attributter for bilder

Alt-attributter er et HTML-attributt som brukes i <img>-taggen slik: <img src=»image.jpg» alt=» Beskrivelse av bilde»>. Hovedformålet er å gi en tekstbeskrivelse av bildeinnholdet. Denne teksten vises hvis bildet ikke lastes inn og leses høyt av skjermlesere for å hjelpe synshemmede brukere. Riktig, beskrivende alt-tekst kan hjelpe bildene dine med å rangere i bildesøk og forbedre sidens generelle relevans.

Hvis du har et nettsted med mye visuelt innhold, er optimalisering av alt-attributter et viktigere skritt enn for klassiske nettsteder som er avhengige av tekstinnhold.

Mange crawlere som Screaming Frog, Ahrefs, SemRush, etc. analyserer alt-attributter, og der kan du få data om manglende eller tomme alt-attributter.

Du kan lese mer om opprettelse av beskrivende alt-attributter i offisielle Google-dokumenter.

Nettstedets hastighet, mobil og brukervennlighet

Bruk HTTPs-protokollen

Bruk av den sikre HTTPS-protokollen er avgjørende for å sikre sikkerheten ved dataoverføring mellom brukeren og serveren. Det øker ikke bare brukernes tillit, men har også en positiv innvirkning på SEO. For å se etter HTTPS, se ganske enkelt på nettleserens adresselinje – et hengelåsikon skal vises.
For en detaljert analyse kan du bruke SSL Labs-tjenesten, som vil gi en fullstendig rapport om statusen til SSL-sertifikatet og identifisere potensielle problemer.

Det er også viktig å sikre at det ikke er noe blandet innhold – HTTP-ressurser på HTTPS-sider. For denne analysen kan du bruke HTTPS-rapporten i Google Search Console, som viser nettadresser med både HTTP og HTTPS.

Kilde: Search Console av vår klient

Forbedre Core Web Vitals

Core Web Vitals er et sett med beregninger foreslått av Google for å vurdere kvaliteten på brukeropplevelsen på et nettsted. Disse målingene fokuserer på lastehastighet, interaktivitet og visuell stabilitet for innhold på siden. De inkluderer tre nøkkelindikatorer:

Metrisk	beskrivelse	Optimal verdi
Største innholdsrike maling (LCP)	Måler lastetiden til det største synlige elementet på siden (f.eks. bilde eller tekst).	Mindre enn 2,5 sekunder
Første inngangsforsinkelse (FID)	Måler tiden det tar for siden å svare på den første brukerinteraksjonen (f.eks. ved å klikke på en knapp eller lenke).	Mindre enn 100 millisekunder
Kumulativ layoutforskyvning (CLS)	Vurderer den visuelle stabiliteten til siden, det vil si hvor mye elementer som beveger seg under sideinnlasting.	Mindre enn 0,1

 

Dataene som ble samlet inn fra ekte brukere, kan sees i Search Console-rapporten «Core Web Vitals» (aggregerte data) eller i PageSpeed Insights (for enkelttester). Mens du jobber med Core Web Vitals, husk at du må definere problemene som har stor innflytelse på CWV-beregningene. Når du for eksempel optimaliserer LCP, må du definere hvilke av de 4 aspektene (TTFB, Lastforsinkelse, Lastetid eller Gjengivelsesforsinkelse) som bidrar mest til den høye LCP-poengsummen.

I eksemplet nedenfor er det synlig at vi ikke trenger å fokusere på optimalisering av TTFB eller lastetid. I stedet kan vi bruke all vår energi på å forbedre Load Delay og deretter Render Delay.

Kilde: https://pagespeed.web.dev/ – test av nike.com nettsted (bare for eksempel). Domenet er uskarpt

Sørg for at nettstedet ditt er mobilvennlig

Mobilvennlighet har blitt en avgjørende faktor siden 2018 da Google gikk over til en mobil-først-indekseringstilnærming . Dette betyr at Google nå først og fremst bruker mobilversjonen av et nettsted for rangering og indeksering, i stedet for desktopversjonen.

I Google Search Console kan du teste sidene dine ved å klikke på «Test Live URL» i URL-inspeksjonsverktøyet og se hvordan Googlebot-Mobile ser det.

Komprimere bilder

Bildeoptimalisering rettet mot å komprimere dem uten å miste kvalitet bidrar til å fremskynde lastingen av nettstedet, spesielt hvis det er mye grafisk innhold på sidene.

Nettbaserte verktøy som TinyPNG eller Squoosh kan brukes til å komprimere bilder. Det er også verdt å sjekke om moderne bildeformater, som WebP, brukes, da de kan redusere filstørrelsen betydelig.

Bruk CDN for internasjonale nettsteder

Å bruke et CDN er fornuftig hvis nettstedet ditt betjener et bredt spekter av geografisk fjerne regioner.

Et CDN (Content Delivery Network) distribuerer nettstedets innhold på tvers av servere som er plassert nærmere brukerne, noe som reduserer ventetiden under innlasting. Du kan se etter CDN-bruk ved å undersøke HTTP-forespørselshoder i nettleserens utviklerverktøy (Nettverk-fanen), der referanser til CDN-leverandøren, for eksempel Cloudflare eller Akamai, kan vises. Det finnes også nettbaserte verktøy for testing av CDN. CDN-konfigurasjon gjøres vanligvis gjennom vertspanelet eller CMS.

Bruk bufring
Bufring lar nettlesere og proxy-servere lagre kopier av ressurser, redusere serverbelastningen og øke hastigheten på lasting ved påfølgende besøk. Du kan sjekke caching-riktigheten i nettleserens utviklerverktøy – i Nettverk-delen, se på Cache-Control-, Expires- og ETag-overskriftene. Google PageSpeed Insights gir også anbefalinger for caching. Det er viktig at statiske ressurser (bilder, skript, stiler) har riktige caching-innstillinger, og serveren bør ha de tilsvarende reglene konfigurert (f.eks. i .htaccess- eller nginx-konfigurasjon). For å sjekke caching kan du bruke nettjenester som GiftOfSpeed.

Konklusjon

En teknisk revisjon av et nettsted er ikke en engangsprosedyre, men en pågående prosess som krever regelmessig oppmerksomhet til de tekniske faktorene som kan påvirke ytelsen og synligheten. Siden hvert nettsted er unikt, vil det spesifikke fokuset og hyppigheten av kontroller variere. Denne sjekklisten for en teknisk SEO-revisjon vil hjelpe deg med å sikre at du ikke har glemt noe viktig.