Et website kan have et flot design, en grøn cirkel i sit SEO-plugin og stadig miste folk, før hovedindholdet overhovedet er indlæst. Eller Google kan indeksere en anden URL end den, du forventer. Eller en ordre kan fungere, mens målingen sender den to gange.
Derfor starter jeg ikke en teknisk audit med at jagte en score på et hundrede i en enkelt test. Først leder jeg efter fejl, der forhindrer forretning, indeksering eller brug af websitet. Først derefter finpudser jeg de små detaljer.
1. Kontrollér, at vigtige URL'er returnerer den korrekte status
Gennemgå de vigtigste servicesider, artikler, der modtager trafik, kontaktsiden og konverteringsforløbet. En vigtig side bør returnere 200. Indhold, der er flyttet permanent, bør have én direkte 301-omdirigering. En fjernet side bør ikke stille og roligt ende på forsiden.
Jeg tjekker også HTTP og HTTPS, www- og ikke-www-varianter, afsluttende skråstreger og parametre. Resultatet bør være én kanonisk URL. Google beskriver en omdirigering som et stærkt signal om kanonisering og anbefaler at kombinere den med en konsekvent canonical og sitemap i sin dokumentation om kanoniske URL'er.
2. Kontrollér indeksering fra den virkelige sides perspektiv
Robots.txt, meta robots, canonical og sitemap skal fungere sammen. En almindelig fejl er at indeksere en side, der ikke har nogen plads i søgningen, mens vigtigt indhold blokeres. Brug URL-inspektion i Search Console på flere repræsentative URL'er. Den viser, hvad Google ved om siden, og lader dig teste liveversionen.
- Er den kanoniske URL den, du ønsker?
- Er siden tilgængelig uden login eller blokering?
- Indeholder sitemappet kun indekserbare 200 URL'er?
- Undgår interne links omdirigeringer?
- Er vigtige sider forældreløse?
Google har et overblik over disse områder i sin dokumentation om crawling og indeksering.
3. Mål hastighed på mennesker, ikke kun i laboratoriet
PageSpeed Insights og Lighthouse er nyttige diagnoseværktøjer. Men en laboratorietest er ikke det samme som virkelige besøgendes oplevelse. De aktuelle Core Web Vitals er LCP, INP og CLS; feltdata bygger på virkelige enheder og forbindelser. Den officielle dokumentation om Web Vitals forklarer overblikket og forskellen mellem felt- og laboratoriedata.
Jeg ville læse prioriteterne sådan:
- LCP: hvornår hovedindholdet vises.
- INP: hvor hurtigt siden reagerer på brug.
- CLS: om elementer hopper under indlæsningen.
- TTFB og netværk: om der overhovedet begynder at ske noget hurtigt.
Google siger også udtrykkeligt, at en god score ikke garanterer topplaceringer. Den samlede brugervenlighed betyder mere end at jagte et enkelt tal. Se dokumentationen om page experience.
4. Find den egentlige årsag til indlæsningen
I waterfall-visningen og DevTools leder jeg efter lang servertid, blokerende CSS og JavaScript, for store billeder, skrifttyper, gentagne forespørgsler og tredjeparter. Den gamle regel om at "kombinere alle filer" gælder ikke længere universelt. Med moderne protokoller kan mængden af ubrugt kode og blokering af hovedtråden betyde mere.
- Indlæs hovedbilledet i en passende størrelse og et moderne format.
- Angiv billeddimensioner, så de ikke flytter indholdet.
- Indhold under den første visning kan bruge native lazy loading.
- Indlæs kun de nødvendige skrifttykkelser og tegnsæt.
- Indlæs marketingscripts asynkront og kun dér, hvor de har et formål.
- Komprimér tekstressourcer, og angiv lang cache for versionsstyrede filer.
En tredjepart koster ikke kun millisekunder. Hver pixel, chatwidget og heatmap skaber yderligere drifts- og dataansvar. Hvis ingen bruger rapporten, så fjern scriptet.
5. Gennemgå websitet som kunde med tastatur og mobiltelefon
På mobilen skal du gennemgå navigation, formular, cookiedialog og ordre. Forstør teksten, deaktivér billeder, og brug et tastatur. Overskrifter bør danne en forståelig struktur, en formular har brug for labels, og en fejlmeddelelse skal sige, hvad der skal rettes.
Hver side bør have én hovedopgave. Det betyder ikke én knap for enhver pris, men et klart hierarki. Find flere praktiske punkter i den grundlæggende UX-tjekliste.
6. Ret ressource- og JavaScript-fejl
En 404 for et billede, en skrifttype eller et script er ikke kosmetisk. Det kan ødelægge udseende, måling eller funktionalitet. Tjek fejl i browserkonsollen, mislykkede netværksforespørgsler og gentagne 5xx-svar på serveren. Test kritiske forløb efter hver deployment.
7. Brug kun strukturerede data til sandfærdigt indhold
Schema er ikke en måde at tvinge stjernebedømmelser frem på. Det er en maskinlæsbar beskrivelse af det, der faktisk findes på siden. Brug en understøttet type, og test den i Rich Results Test. Google oplister aktuelle understøttede formater og testværktøjer i sin dokumentation om strukturerede data.
8. Målingen må ikke ødelægge det website, den skal måle
Indlæs GA4, annonceplatforme og andre scripts på en ikke-blokerende måde. Navngiv events efter beslutninger, ikke efter hvert klik. Kontrollér dubletter, samtykke og om nogen faktisk bruger dataene. Find et praktisk fundament i artiklerne om Google Tag Manager og Google Analytics 4.
9. Penge og risiko afgør rækkefølgen af rettelserne
- En ordre, formular eller login, der ikke fungerer.
- En vigtig side, der ikke er tilgængelig eller kan indekseres.
- Et sikkerhedsproblem og forældede komponenter.
- Store problemer med mobil brugervenlighed og Core Web Vitals.
- Målefejl, der fører til dårlige beslutninger.
- Først derefter mindre scores og kosmetiske problemer.
Teknisk SEO er startlinjen. Det vinder ikke løbet alene, men et ødelagt website kan tabe det, før startskuddet lyder. Hvis du har brug for at omsætte tekniske fund til forretningsprioriteter, kan du beskrive websitet og den beslutning, du står over for.