Teknisk SEO

Teknisk SEO handler om de forhold, der afgør, om Google kan komme ind på siden og arbejde med den. En god tekst hjælper ikke meget, hvis siden er markeret med noindex, peger på en forkert canonical eller kun kan findes gennem en formular, som en crawler ikke bruger.

Det betyder ikke, at alle tekniske advarsler er alvorlige. SEO-værktøjer kan finde tusindvis af “problemer”, fordi de er bygget til at finde noget. Opgaven er at skelne mellem det, der faktisk spærrer for synlighed, og det, der mest gør rapporten rød.

For en mindre virksomhed er teknisk SEO derfor et prioriteringsarbejde. Først skal de vigtigste sider kunne crawles og indekseres. Derefter ser man på dubletter, redirects, mobilproblemer, hastighed og den interne struktur.

Den første kontrol er enkel: Findes de vigtigste sider i Google, og viser Google Search Console fejl? En søgning med site: kan give et hurtigt fingerpeg, men Search Console er bedre til at vise, om Google har besøgt en konkret URL og hvorfor den eventuelt ikke er indekseret.

1. Adgang: Blokerer robots.txt eller serveren en vigtig mappe?
2. Indeksering: Har siden noindex, forkert canonical eller en statuskode, der ikke er 200?
3. URL’er: Går gamle adresser gennem fornuftige 301-redirects, eller ender de i kæder og 404-fejl?
4. Opdagelse: Findes siden i et opdateret sitemap og i den interne navigation?
5. Oplevelse: Fungerer siden på mobil, og er de vigtigste Core Web Vitals nogenlunde sunde?

Hvis én af de første tre fejler, har den normalt højere prioritet end små forbedringer i kode eller billedkomprimering. Det er forskellen på teknisk SEO og teknisk perfektionisme.

En virksomhed får en ny WordPress-side. De gamle adresser hed eksempelvis /service-vinduer.html, mens de nye hedder /udskiftning-af-vinduer/. Designet ser fint ud, men ingen har lavet redirects. Google og gamle links rammer derfor 404-sider, og den historik de gamle URL’er havde opbygget, bliver ikke sendt videre.

Samtidig er noindex-indstillingen fra testmiljøet stadig aktiv på den nye side. Det er en lille afkrydsning med stor virkning. Resultatet er, at siden er online for mennesker, men fortæller søgemaskiner, at den ikke skal med i resultatet.

Det er netop derfor en relancering ikke kun handler om at flytte design. På en ny hjemmeside bør der være en teknisk lanceringsliste med redirects, canonical, sitemap, analyse, formularer og indeksering. Det tager kortere tid at kontrollere før lancering end at reparere faldet bagefter.

Et crawler-værktøj kan blandt andet advare om lange titler, manglende beskrivelser, store billeder, omdirigeringer, tynde sider og overskrifter i forkert rækkefølge. Det er nyttigt, men antallet af fejl er ikke et mål i sig selv.

Hvis en webshop har 8.000 produktvarianter, kan én skabelonfejl skabe 8.000 advarsler. Det betyder ikke nødvendigvis 8.000 individuelle opgaver. Omvendt kan en enkelt fejlagtig regel i robots.txt blokere hele produktkataloget. Prioriteten bør følge effekt og rækkevidde, ikke antallet af røde linjer.

Vi ville normalt sortere fundene sådan:

• blokeringer og fejl på sider, der skal skabe salg eller henvendelser
• systematiske problemer i skabeloner
• problemer, der giver brugerne en dårlig oplevelse
• oprydning i gamle og overflødige URL’er
• små kosmetiske advarsler til sidst

Nogle ting kan løses i et SEO-plugin. Titler, metabeskrivelser og simple redirects er ofte ligetil. Andre problemer ligger i temaet, serveren, JavaScript eller den måde data bliver hentet på. Hvis produkter kun vises efter et script er kørt, eller hvis filterfunktioner skaber tusindvis af URL’er, kræver det mere end en indstilling.

Det er også her samarbejdet mellem SEO og udvikling betyder noget. En udvikler kan lave en teknisk korrekt løsning, som skaber unødvendige URL’er. En SEO-konsulent kan foreslå en ændring, der gør systemet langsommere eller sværere at vedligeholde. Den bedste løsning kommer, når begge ser på den samme forretning og samme brugerrejse.

Teknisk SEO skal i sidste ende gøre siden nem at finde, stabil at bruge og enkel at vedligeholde. Når webudvikling og SEO bliver tænkt sammen, bliver færre problemer skubbet videre til en dyr oprydning senere.

Tekniske SEO-rapporter bliver hurtigt lange, fordi de tæller hver URL som et separat problem. Hundrede sider med samme fejl er dog ofte ét problem i en skabelon. Det er derfor bedre at lede efter årsagen end at rette side for side.

Vi ville normalt begynde med tre spørgsmål: Er vigtige sider overhovedet indekseret? Sender gamle URL’er brugeren korrekt videre med en 301-redirect? Og peger sitemap, canonical og interne links på de samme foretrukne adresser? Hvis svaret er ja, kan man gå videre til hastighed, markup og mindre oprydning.

Tag også en backup og notér udgangspunktet, før større ændringer sættes i gang. En teknisk “optimering” kan skabe nye fejl, hvis caching, JavaScript eller URL-struktur ændres uden test. På en WordPress-side bør man kontrollere både frontend, redigering og formularer efter indgrebet. På en WooCommerce-webshop skal kurv, checkout og betaling testes særskilt. Det er kedeligt arbejde, men langt billigere end at opdage en uge senere, at kunderne ikke kunne gennemføre et køb.