De 8 vigtigste tekniske SEO-ændringer du bør holde øje med

Teknisk SEO bliver ofte samlet i én score. Det er bekvemt, men en score kan skjule, hvad der faktisk ændrede sig. Hvis en side begynder at redirecte, får en ny canonical eller ikke længere kan indekseres, er det mere nyttigt at se det konkrete signal end blot et tal, der gik op eller ned.

Tekniske observationer kræver samtidig forsigtighed. En værdi kan være utilgængelig på grund af timeout, blokering eller en ændret datakilde. Og selv et korrekt observeret signal fortæller ikke automatisk, om ændringen var tilsigtet eller hvilken effekt den fik.

Her er otte områder, der kan indgå i en dokumenteret sammenligning. De supplerer hovedguiden om SEO-rapportering og artiklen om en troværdig SEO-baseline.

1. Statuskoder og redirects

En sides HTTP-status fortæller, hvordan serveren besvarede forespørgslen. En 200-status viser typisk, at ressourcen blev leveret. En 301 eller 308 angiver en permanent redirect, mens 404 fortæller, at ressourcen ikke blev fundet.

Ved en ændring bør rapporten vise den oprindelige URL, statuskoden og den endelige URL efter eventuelle redirect-hop. En redirect kan være planlagt oprydning, men den kan også sende brugere og crawlere til en irrelevant side eller indgå i en lang kæde.

En enkelt mislykket forespørgsel er ikke altid bevis for en varig statusændring. Tidspunkt, fejltype og eventuelle genforsøg er vigtige dele af dokumentationen.

2. Canonical

Et canonical-link angiver den URL, som siden peger på som sin foretrukne version. En ændring kan være vigtig, fordi den påvirker, hvordan du beskriver forholdet mellem dublerede eller nært beslægtede sider.

Dokumentationen bør vise den gamle og nye canonical-værdi samt om URL'en er intern, ekstern, selvrefererende eller ugyldig. Den bør ikke konkludere, at søgemaskinen nødvendigvis følger signalet; canonical er et signal, ikke en ordre.

Hvis feltet mangler i en måling på grund af en hente- eller parserfejl, må det ikke rapporteres som en bekræftet fjernelse.

3. Robots-meta og X-Robots-Tag

Robots-direktiver kan findes i HTML eller HTTP-headers. De kan blandt andet bede crawlere om ikke at indeksere en side eller ikke at følge links.

En rapport bør samle de relevante direktiver og vise deres kilde. Et nyt noindex-signal på en vigtig side kræver ofte hurtig afklaring, men det kan være helt tilsigtet på en takkeside eller intern søgeresultatside.

Det er vigtigt at skelne mellem robots-meta på siden og regler i robots.txt. De har forskellige funktioner og bør ikke samles til én uklar “robots-score”.

4. Robots.txt og sitemap

Robots.txt kan vejlede crawlere om, hvilke områder de må hente. Et XML-sitemap kan hjælpe med at opdage vigtige URL'er. Ingen af delene garanterer indeksering.

Overvågning kan vise, om filerne findes, om deres placering ændrer sig, eller om et kendt sitemap får et andet sæt URL'er. Sammenligningen skal dog tage højde for, at flere sitemaps kan være opdelt efter indholdstype, og at store filer kan ændre rækkefølge uden en meningsfuld ændring.

En crawler kan også opdage sider via interne links. “Ikke i sitemap” betyder derfor ikke automatisk “usynlig”, og “i sitemap” betyder ikke automatisk “indekseret”.

5. Strukturerede data

Strukturerede data beskriver indhold i et maskinlæsbart format, ofte JSON-LD. En rapport kan observere, at en type eller egenskab blev tilføjet, fjernet eller ændret.

Det kræver mere end en tekstsammenligning. Rækkefølgen af felter kan ændre sig uden at betydningen gør det. Data bør parses og normaliseres, før to versioner sammenlignes.

Selv gyldig markup garanterer ikke en bestemt visning i søgeresultaterne. Rapporten kan dokumentere den offentlige kode og eventuelle valideringsfund, ikke søgemaskinens fremtidige valg.

6. HTTP-headers og HTTPS

Headers kan vise cache-regler, indholdstype, sikkerhedssignaler og andre tekniske forhold. HTTPS og certifikatets gyldighed er grundlæggende for en sikker offentlig forbindelse.

En ændret header er ikke altid et SEO-problem. Nogle headers tilhører sikkerhed eller drift og skal vurderes i deres rette sammenhæng. Dokumentationen bør vise den konkrete værdi og undgå at oversætte enhver teknisk forskel til en rangeringseffekt.

Hvis en side både findes på HTTP og HTTPS, er redirects og canonical-signaler relevante at se i sammenhæng.

7. Mobil og renderet indhold

Indhold kan blive leveret forskelligt afhængigt af viewport, JavaScript eller brugeragent. En simpel HTML-hentning ser ikke nødvendigvis det samme som en fuldt renderet browser.

Rapporten bør fortælle, hvilken metode den bruger. Hvis et element ikke findes i den valgte observation, betyder det ikke altid, at ingen bruger eller crawler kan se det. Omvendt bør kritisk indhold ikke antages at være tilgængeligt, blot fordi det findes i en intern datakilde.

Metodeændringer mellem scanninger skal versioneres, så forskellen ikke fejlagtigt tilskrives websitet.

8. Ydelsesmålinger

PageSpeed- og Core Web Vitals-data kan beskrive bestemte lab- eller feltobservationer. Labdata er en kontrolleret test på et tidspunkt. Feltdata er aggregerede observationer fra virkelige brugere, når der er tilstrækkeligt datagrundlag.

Ydelsesmålinger varierer og bør ikke behandles som uforanderlige sandheder. Rapporten skal vise kilde, måletype og tidspunkt. Manglende feltdata må markeres som utilgængelige frem for at blive simuleret.

En ændret måling kan pege på noget, der bør undersøges. Den beviser ikke alene, hvilken kodeændring der skabte forskellen eller hvilken forretningseffekt den fik.

Se signalerne i sammenhæng

Tekniske ændringer påvirker ofte hinanden. En slettet side kan redirecte til en ny URL, som bruger en anden canonical og har nye interne links. Hvis rapporten viser hvert signal isoleret uden siden og tidslinjen, bliver historien vanskelig at forstå.

En praktisk rapport grupperer derfor fund efter berørt side eller ændringsforløb. Den bevarer stadig de enkelte før- og efterværdier, så læseren kan kontrollere detaljen.

Indholdsændringer behandles særskilt i guiden om indhold og metadata. WordPress-specifikke kilder behandles i WordPress og SEO-dokumentation.

Spørgsmål til et teknisk fund

Når en rapport viser en teknisk ændring, så spørg:

1. Hvilken URL og hvilken konkret værdi ændrede sig?
2. Kom observationen fra et offentligt svar, en integration eller en ekstern måling?
3. Var dataen tilgængelig ved begge tidspunkter?
4. Er ændringen tilsigtet, og hvem kan forklare beslutningen?
5. Er der relaterede ændringer på andre signaler eller sider?
6. Hvad skal kontrolleres ved næste måling?

Dokumentation før dom

Tekniske signaler er værdifulde, fordi de ofte kan måles præcist. Men præcisionen i et felt må ikke forveksles med sikkerhed om intention eller effekt. Vis status, kilde, før og efter. Tilføj derefter den faglige vurdering som et separat lag.

Valido kombinerer eksplicitte kilder i en versioneret scanmodel og markerer utilgængelig data i stedet for at opfinde den. Se hvordan Valido tjekker for ændringer.