Tjekliste til JavaScript- og headless-SEO ved lancering

Et headless CMS adskiller redigering af indhold fra den oplevelse, besøgende får leveret. Det giver fleksibilitet, men betyder også, at redaktører, frontendudviklere og drift har ansvar for forskellige dele af søgerejsen. Før en lancering skal I aftale, hvad en crawler og en besøgende skal modtage. En flot forside er ikke tilstrækkelig dokumentation for, at alle produkt-, artikel- og sprogskabeloner fungerer.

Lav en repræsentativ oversigt over lanceringen

Notér de skabeloner og URL-forløb, som ændringen berører. Medtag en almindelig side, et tomt resultat, en utilgængelig vare, en viderestillet adresse og hvert vigtigt sprog. Vælg både sider fra navigationen og adresser, som åbnes direkte. Angiv indholdsansvarlig, teknisk ansvarlig og forventet resultat for hvert eksempel. En lille acceptoversigt gør det lettere at opdage mangler end en tilfældig gennemklikning til sidst.

Sammenlign serversvaret med den renderede side

Undersøg både den returnerede HTML og siden efter kørsel af JavaScript. Kontrollér, om hovedindhold, titel, canonical og vigtige links findes og stemmer overens. Google skelner mellem crawling, rendering og indeksering; en korrekt visning i browseren dokumenterer ikke alle tre trin. Serverrendering eller prærendering kan mindske afhængigheden af klientkode, men det faktiske resultat skal stadig kontrolleres. Headless-arkitektur er ikke i sig selv et kvalitetsstempel.

Kontrollér opdagelse og URL-adfærd hver for sig

En menu, der reagerer på klik, er ikke nødvendigvis et link, søgemaskiner kan følge. Gennemgå centrale destinationer for almindelige links med en brugbar href. Kontrollér, at direkte forespørgsler viser korrekt indhold, manglende ressourcer giver passende fejlstatus, og redirects fører til den tilsigtede erstatning. Vurder indekseringsregler sammen med canonical-valg. Et sitemap hjælper med opdagelse, men hverken sitemaptilmelding eller et korrekt serversvar garanterer indeksering.

Dokumentér fejl, så andre kan genskabe dem

Gem adresse, versionsnummer, tidspunkt, forventet resultat og observeret resultat for hvert problem. Notér blokerede filer, fejlede indholdskald og forskelle mellem et nyt besøg og navigation inde på websitet. Medtag ikke adgangskoder eller personlige kundeoplysninger. Udvikleren skal kunne genskabe problemet ud fra overdragelsen. Aftal, om fejlen stopper lanceringen eller får en konkret frist til opfølgning, og hvem der har ansvaret for beslutningen.

Godkend lanceringen og gentag de afgørende kontroller

Gennemgå åbne fund med den lanceringsansvarlige, og aftal hvornår en tilbagerulning er relevant. Gentag stikprøven på produktion efter udgivelsen; en godkendt testversion dokumenterer ikke produktionsopsætningen. Kontrollér de faktiske robotsregler, indekseringsdirektiver, redirects og det væsentlige indhold. Brug URL-inspektion i Search Console med godkendt adgang, når det er relevant. Følg fejl efter ny crawling, og behandl ikke enhver trafikændring som øjeblikkeligt bevis på en lanceringsfejl.

Tjekliste til overdragelsen

Angiv version, berørte skabeloner og ansvarlige kontrollanter.
Sammenlign HTML-svar, renderet indhold og vigtige links.
Kontrollér direkte besøg, manglende adresser, canonicals og redirects.
Fordel dokumenterede fund og beslutninger om lanceringsstop.
Gentag stikprøven på produktion, og aftal opfølgning.

Tænkt eksempel

Hypotetisk eksempel: En webshop udskifter sin kategorifrontend. Navigationen fungerer under et almindeligt besøg, men en direkte åbnet kategori viser en tom ramme efter et fejlet indholdskald. Teamet dokumenterer kaldet, retter direkte indlæsning og gentager stikprøven på produktion. En bestået kontrol dokumenterer rettelsen; den lover ikke en bestemt placering i søgeresultaterne.

Relaterede ydelser og vejledninger

Primære kilder

Gennemgået 1. november 2026. Arbejdsgangen og de tænkte eksempler er Gaveks redaktionelle vejledning; eksterne kilder understøtter de tekniske principper. Aftal konkret adgang, implementering, dataomkostninger og leverancer i projektets omfang.