Et nettsted kan ha et vakkert design, en grønn sirkel i SEO-pluginen og likevel miste folk før hovedinnholdet i det hele tatt er lastet inn. Google kan også indeksere en annen URL enn den du forventer. Eller en bestilling kan fungere, mens målingen sender den inn to ganger.
Derfor starter jeg ikke en teknisk revisjon med å jage en poengsum på hundre i én enkelt test. Først leter jeg etter feil som hindrer forretning, indeksering eller bruk av nettstedet. Først deretter finpusser jeg detaljene.
1. Kontroller at viktige URL-er returnerer riktig status
Gå gjennom de viktigste tjenestesidene, artikler som får trafikk, kontaktsiden og konverteringsløpet. En viktig side bør returnere 200. Innhold som er flyttet permanent, bør ha én direkte 301-viderekobling. En fjernet side bør ikke i stillhet ende på forsiden.
Jeg kontrollerer også HTTP og HTTPS, www- og ikke-www-varianter, avsluttende skråstreker og parametere. Resultatet bør være én kanonisk URL. Google beskriver en viderekobling som et sterkt signal for kanonisering og anbefaler å kombinere den med en konsekvent canonical og sitemap i dokumentasjonen om kanoniske URL-er.
2. Kontroller indekseringen fra den faktiske sidens perspektiv
Robots.txt, meta robots, canonical og sitemap må fungere sammen. En vanlig feil er å indeksere en side som ikke har noe i søk å gjøre, samtidig som viktig innhold blokkeres. Bruk URL Inspection i Search Console på flere representative URL-er. Der ser du hva Google vet om siden, og du kan teste liveversjonen.
- Er den kanoniske URL-en den du ønsker?
- Er siden tilgjengelig uten innlogging eller blokkering?
- Inneholder sitemap-en bare indekserbare 200 URL-er?
- Unngår interne lenker viderekoblinger?
- Finnes det viktige sider uten interne lenker?
Google har en oversikt over disse områdene i sin dokumentasjon om crawling og indeksering.
3. Mål hastighet på mennesker, ikke bare i laboratoriet
PageSpeed Insights og Lighthouse er nyttige diagnoseverktøy. Men en laboratorietest er ikke det samme som opplevelsen til virkelige besøkende. De gjeldende Core Web Vitals er LCP, INP og CLS; feltdata bygger på virkelige enheter og forbindelser. Den offisielle dokumentasjonen for Web Vitals forklarer oversikten og forskjellen mellom felt- og laboratoriedata.
Jeg ville lest prioriteringene slik:
- LCP: når hovedinnholdet vises.
- INP: hvor raskt siden reagerer på bruk.
- CLS: om elementer hopper mens siden lastes inn.
- TTFB og nettverk: om noe i det hele tatt begynner å skje raskt.
Google sier også uttrykkelig at en god poengsum ikke garanterer topplasseringer. Den samlede brukervennligheten er viktigere enn å jage ett enkelt tall. Se dokumentasjonen om sideopplevelse.
4. Finn den egentlige årsaken til treg lasting
I waterfall-visningen og DevTools ser jeg etter lang server-tid, blokkerende CSS og JavaScript, for store bilder, skrifter, gjentatte forespørsler og tredjeparter. Den gamle regelen om å «slå sammen alle filer» gjelder ikke lenger overalt. Med moderne protokoller kan mengden ubrukt kode og blokkering av hovedtråden ha større betydning.
- Last inn hovedbildet i riktig størrelse og et moderne format.
- Angi bildedimensjoner slik at innholdet ikke flytter på seg.
- Innhold under den første visningen kan bruke innebygd lazy loading.
- Last bare inn nødvendige skriftvekter og tegnsett.
- Last inn markedsføringsskript asynkront og bare der de har en funksjon.
- Komprimer tekstressurser og sett lang cache for versjonerte filer.
En tredjepart koster ikke bare millisekunder. Hver piksel, chat-widget og heatmap skaper mer operasjonelt ansvar og dataansvar. Hvis ingen bruker rapporten, bør du fjerne skriptet.
5. Gå gjennom nettstedet som en kunde med tastatur og mobiltelefon
På mobil går du gjennom navigasjonen, skjemaet, cookie-dialogen og bestillingen. Forstørr teksten, slå av bilder og bruk tastatur. Overskrifter bør danne en forståelig struktur, et skjema trenger etiketter, og en feilmelding må si hva som skal rettes.
Hver side bør ha én hovedoppgave. Det betyr ikke én knapp for enhver pris, men et tydelig hierarki. Du finner flere praktiske punkter i den grunnleggende UX-sjekklisten.
6. Rett opp ressurs- og JavaScript-feil
En 404-feil for et bilde, en skrift eller et skript er ikke kosmetisk. Den kan ødelegge utseende, måling eller funksjonalitet. Kontroller feil i nettleserkonsollen, mislykkede nettverksforespørsler og gjentatte 5xx-svar på serveren. Test kritiske løp etter hver utrulling.
7. Bruk strukturerte data bare for innhold som er sant
Schema er ikke en måte å tvinge frem stjernevurderinger på. Det er en maskinlesbar beskrivelse av det som faktisk finnes på siden. Bruk en støttet type og test den i Rich Results Test. Google lister aktuelle støttede formater og testverktøy i sin dokumentasjon om strukturerte data.
8. Målingen må ikke ødelegge nettstedet den skal måle
Last inn GA4, annonseplattformer og andre skript på en ikke-blokkerende måte. Gi hendelser navn etter beslutninger, ikke etter hvert klikk. Kontroller duplikater, samtykke og om noen faktisk bruker dataene. Finn et praktisk grunnlag i artiklene om Google Tag Manager og Google Analytics 4.
9. Penger og risiko avgjør rekkefølgen på rettingene
- En ødelagt bestilling, et skjema eller en innlogging.
- En viktig side som ikke er tilgjengelig eller kan indekseres.
- Et sikkerhetsproblem og utdaterte komponenter.
- Store problemer med mobil brukervennlighet og Core Web Vitals.
- Målefeil som fører til dårlige beslutninger.
- Først deretter mindre poengsummer og kosmetiske problemer.
Teknisk SEO er startstreken. Det vinner ikke løpet alene, men et ødelagt nettsted kan tape før startskuddet går. Hvis du trenger å gjøre tekniske funn om til forretningsprioriteringer, kan du beskrive nettstedet og beslutningen du står overfor.