SEO-revisionsagentfærdighed

seo-audit — Grundlæggende SEO-revision

En letvægts SEO-agent-færdighed designet til hurtige, standard side-enkelt-side SEO-revisioner. Drevet af OpenClaw. Velegnet til førstegangssidekontrol eller når en hurtig vurdering er nødvendig uden fuld teknisk dybde.

Hvornår skal denne færdighed bruges

Brug seo-audit når:

• Brugeren siger: "revider denne side", "tjek SEO", "analyser min URL", "hurtig SEO-tjek", "hvad er der galt med min side"
• Der ikke anmodes om specifik dybde — dette er standardindgangspunktet
• Brugeren har brug for en hurtig, læsevenlig opsummering snarere end en omfattende teknisk gennemgang

Hvis brugeren ønsker mere dybde, opgrader til seo-audit-full:

Tip: For dybe tekniske revisioner, avanceret on-page SEO eller fulde rapporter, brug færdigheden seo-audit-full.

Forventet input

Hvis kun en URL leveres og ingen kildekode eller crawlerdata er tilgængelige, angiv tydeligt:

Begrænsning: Denne revision er kun baseret på synligt sideindhold og offentligt tilgængelige signaler. Kildekode, GSC-data, crawl-logfiler og ydeevnemålinger er ikke tilgængelige for denne revision.

Output

Producer en Grundlæggende SEO-revisionsrapport ved at udfylde skabelonen på assets/report-template.html, og gem den derefter til en fil — udskriv aldrig rå HTML til terminalen.

Filnavngivning: reports/<hostname>-<slug>-audit.html

https://example.com/blog/best-tools → reports/example-com-blog-best-tools-audit.html
https://example.com/                → reports/example-com-audit.html

Efter gemning, fortæl brugeren:

✅ Rapport gemt → reports/example-com-audit.html
   Åbn den nu? (ja / nej)

Hvis ja → kør: open reports/example-com-audit.html

Skabelonpladsholdere — udfyld hver uafhængigt:

Scripts

Kør disse scripts, før du skriver nogen resultater. De udsender struktureret JSON — brug JSON direkte som bevis; hent ikke de samme URL'er manuelt igen.

Afhængigheder: pip install requests (html-parsing bruger Python stdlib)

# Trin 1: webstedsniveau-kontroller (robots.txt + sitemap.xml)
python scripts/check-site.py https://example.com

# Trin 2: sideniveau-kontroller (H1, titel, metabeskrivelse, kanonisk)
python scripts/check-page.py https://example.com
# Med primært søgeord (anbefales — aktiverer H1-søgeords tilstedeværelseskontrol)
python scripts/check-page.py https://example.com --keyword "løbesko"

# Valgfrit: hent rå side-HTML til yderligere inspektion
python scripts/fetch-page.py https://example.com --output page.html

# Trin 3: JSON-LD-skema-validering
python scripts/check-schema.py https://example.com
# Eller fra tidligere hentet HTML (undgår redundant hentning):
python scripts/check-schema.py --file page.html

Hvert script afslutter med kode 0 (alle bestået/advaret) eller 1 (nogen fejl/fejl).

STRENGT OMFANG — tilføj ikke nogen kontrol, der ikke er anført nedenfor. Ingen undtagelser.

Tilladte webstedsniveau-kontroller (i {{site_checks_html}}):

• robots.txt · sitemap.xml · 404-håndtering · URL-kanonisering · i18n / hreflang

Tilladte E-E-A-T-kontroller (i {{eeat_checks_html}}):

• Om os · Kontakt · Privatlivspolitik · Tjenestevilkår · Medier/Partnere (kun hvis til stede)

Tilladte sideniveau-kontroller (i {{page_checks_html}}), output i præcis denne rækkefølge: URL-snegle · Title-tag · Metabeskrivelse · H1-tag · Kanonisk tag · Billedalternativtekst · Ordantal · Søgeordsplacering · Overskriftsstruktur · Interne links · Skema (JSON-LD)

Logik for billedalternativtekst:

• Parse <img>-tags fra statisk HTML
• Bestået: alle billeder har ikke-tom alt (dekorative billeder med alt="" er OK)
• Advarsel: ethvert indholdsbillede mangler alt-attribut
• Ubekræftet (status-info): 0 billeder fundet i statisk HTML → sandsynligvis JS-gengivet, kan ikke verificere

⛔ HÅRD REGEL — Output KUN de kontrolrækker, der er defineret i report-template.html. Hvis en kontrol ikke er på de tilladte lister ovenfor, output den IKKE — ikke engang hvis du finder problemer. Ingen undtagelser. Ingen "bonus"-kontroller. Ingen improvisation. Skabelonen er den eneste sandhedskilde. Behandl den som en streng whitelist.

Stadig FORBUDT (hører til seo-audit-full): OG-tags · Twitter Card · Sociale tags · Sidevægt · Core Web Vitals · Robots Meta

Sådan bruges JSON-output:

• Kortlæg hvert felts status → pass / warn / fail / error direkte til rapportens kontroltabel
• Brug hvert felts detail-streng som udgangspunkt for evidenslinjen i resultaterne
• Modsig ikke script-output, medmindre du har yderligere observerbare beviser
• Adskil kontrolgrupper med <div class="subsection-label">Label</div> inde i {{site_checks_html}}: Crawlability · URL-kanonisering · i18n / hreflang · Skema (JSON-LD) og <div class="subsection-label">E-E-A-T-tillidssider</div> før {{eeat_checks_html}}

LLM-gennemgang — obligatorisk når llm_review_required: true:

Scriptet markerer felter, der kræver semantisk eller kvalitetsmæssig vurdering, som det ikke kan udføre. Efterlad aldrig llm_review_required: true uløst — foretag altid en eksplicit vurdering.

H1 — udløses når keyword_match == "partial":

h1_text : (fra h1.values[0])
keyword : (det --keyword, der blev sendt til scriptet)

Vurder: Dækker denne H1 semantisk søgeordets søgeintention?
  - Overvej synonymer, naturlige varianter, emnedækning
  - ja → nedgrader til "pass", bemærk varianten
  - nej  → behold "warn" eller opgrader til "fail", forklar kløften

Title — udløses når keyword_match == "partial" ELLER keyword_position != "start":

title   : (fra title.value)
keyword : (det --keyword, der blev sendt)

Vurder:
  1. Dækker titlen semantisk søgeordets søgeintention?
  2. Er titlen grammatisk korrekt og naturligt læsevenlig?
  3. Søgeordsplacering — anvend forskellige standarder efter sidetype:
     - Hjemmeside   : Brand + kerneord er korrekt (f.eks. "Acme | AI Workflow Automation")
                    Flag ikke brand-først som et problem.
     - Indre sider: Kerneord bør stå først (f.eks. "AI Workflow Automation til teams — Acme")
                    Flag hvis søgeord er begravet midt i titlen uden god grund.

VIGTIGT — flag IKKE disse som negative:
  - Årstal (f.eks. "2026") → signalerer friskhed, øger CTR — behandl som positivt medmindre
    siden er eksplicit stedsegrønt indhold, hvor datering ville skade levetiden.
  - Tal (f.eks. "5 bedste", "Top 10", "3 trin") → sætter klare forventninger,
    overgår konsekvent ikke-numeriske titler i CTR — behandl altid som et plus.
  - Specifikke kvalifikatorer ("Open-Source", "Selv-hosted", "Gratis") → indsnævrer intention
    og tiltrækker klik af højere kvalitet — straf ikke.

URL-snegle — udløses når keyword_match != "full" eller is_homepage == false:

slug    : (fra url_slug.slug)
keyword : (det --keyword, der blev sendt)

Vurder:
  1. Indeholder sneglen det primære søgeord eller en naturlig variant?
  2. Er stihierarkiet logisk? (/kategori/søgeord er ideelt)
  3. Er den kortfattet og menneskeligt læsevenlig?
  Hjemmeside (is_homepage: true): spring over — ingen vurdering nødvendig.

Metabeskrivelse — udløses altid når indhold er til stede:

meta_description : (fra meta_description.value)
keyword          : (det --keyword, der blev sendt)

Vurder alle fire:
  1. Fuldstændig(e) sætning(er)? (1-2 sætninger, ingen fragmenter)
  2. Nævner et konkret resultat — ikke vagt fyld?
     God: "Reducer designtid med 60 % med AI-drevne skabeloner"
     Dårlig:  "Det bedste værktøj til alle dine designbehov"
  3. Søgeord eller naturligt synonym brugt én gang — ikke proppet?
  4. Mere specifik end hvad en typisk konkurrent ville skrive?

VIGTIGT — flag IKKE disse som negative:
  - Årstal (f.eks. "2026") → signalerer friskhed, forbedrer CTR for tidsfølsomme forespørgsler.
    Bemærk kun året, hvis siden er eksplicit stedsegrønt indhold, hvor datering skader.
  - Tal (f.eks. "5 bedste", "3 trin") → konkret specificitet, stærkt CTR-signal.
  - Afsluttende "og mere." → mindre stilbemærkning højst, aldrig en Advarsel eller Fejl.

Anbefalet arbejdsgang

Følg disse trin i rækkefølge:

1. Bekræft omfang — bekræft, at dette er en grundlæggende revision; bemærk eventuelle manglende data

2. Udled primært søgeord — hent siden med fetch-page.py, og bestem derefter det primære søgeord:

   • Hvis brugeren eksplicit har angivet et søgeord → brug det direkte
   • Hvis ikke → læs sidens H1, titel og første afsnit, og udled derefter den enkelt mest sandsynlige målsøgeordsfrase (hvad ville en søgende skrive for at finde denne side?)
   • Angiv det udledte søgeord eksplicit, før du kører kontroller:

     "Udledt primært søgeord: open source claude alternativer"

3. Kør check-site.py — parse JSON-output for robots, sitemap, 404-håndtering og URL-kanonisering

   404-kontrol: hent <origin>/this-page-definitely-does-not-exist-seo-audit-check

   • Returnerer 404 → Bestået · Returnerer 200 (blød 404) → Fejl · Returnerer 301 til hjemmeside → Advarsel

   URL-kanoniseringskontroller (hver er en separat underkontrol):

   • HTTP→HTTPS: hent http://<host> — skal 301 til https://. Returnerer 200 → Fejl.
   • www-konsistens: hent både https://www.<host> og https://<host> — den ene skal 301 til den anden. Begge returnerer 200 → Advarsel.
   • Slut-skråstreg: sammenlign den faktisk serverede URL med det kanoniske tag på siden. Uoverensstemmelse → Advarsel.
   • Kanonisk match: kanonisk tag-href skal nøjagtigt matche den endelige URL efter alle omdirigeringer. Uoverensstemmelse → Advarsel.

4. E-E-A-T-infrastrukturkontrol — for hver tillidsside nedenfor, kontroller to lag:

   • Lag 1 — Eksisterer: hent URL'en, kontroller HTTP-status (200 = eksisterer, 404/omdirigering = mangler)
   • Lag 2 — Tilgængelig: hent hjemmeside-HTML, kontroller om sidefod eller nav indeholder et link til denne side

   Side	Påkrævet
   Om os	Ja
   Kontakt	Ja
   Privatlivspolitik	Ja
   Tjenestevilkår	Ja
   Medier / Partnere	Nej — inkluder kun hvis til stede

   Statusregler:

   • Side mangler (ikke-200) → Fejl
   • Side findes, men er ikke linket i sidefod/nav → Advarsel
   • Side findes og er linket i sidefod/nav → Bestået
   • Valgfri side mangler → spring over, inkluder ikke række

5. Kør check-page.py --keyword "<udledt_søgeord>" — parse JSON-output for H1, titel, metabeskrivelse, kanonisk og URL-snegle

6. i18n / hreflang-kontrol — kør kun, hvis siden indeholder hreflang-tags eller <html lang> antyder flersproget:

   • Spring helt over (I/R) hvis ingen hreflang-tags findes, og webstedet ser ud til at være enkeltsproget
   • Hvis hreflang-tags er til stede, kontroller:
     • Gensidig symmetri: hver URL, der refereres til, skal linke tilbage til alle andre varianter — ethvert brudt link = Fejl
     • Sprogkoder: skal være gyldige BCP 47 (f.eks. zh-CN ikke zh, en-US ikke en-us) — forkert kode = Advarsel
     • x-default: bør være til stede for sprogvælger- eller fallback-sider — mangler = Advarsel
     • html[lang]-attribut: skal matche sidens primære hreflang — uoverensstemmelse = Advarsel
     • URL-struktur: anbefalet mønster — standardsprog (normalt en) ved roden uden præfiks, andre sprog under understier (/zh/, /es/).
       • /side (en) + /zh/side + /es/side → Bestået
       • /en/side + /zh/side → Advarsel (en-præfiks er overflødigt, spilder crawl-dybde)
       • Flag kun, hvis mønsteret er klart inkonsistent, eller en er unødvendigt præfikseret

7. Kør check-schema.py — parse JSON-output for skematyper og feltvalidering

   python scripts/check-schema.py https://example.com
   # Eller fra tidligere hentet HTML:
   python scripts/check-schema.py --file page.html
   

   Scriptet udtrækker JSON-LD-blokke, validerer @type og påkrævede felter i henhold til Schema.org-spec. llm_review_required: true er altid indstillet — bekræft, at inferred_page_type matcher det faktiske sideindhold.

   Sidetype → forventet @type-reference:

   Sidetype	Forventet @type	Min. påkrævede felter
   Hjemmeside	WebSite + Organization	name, url, logo
   Blog / Artikel	Article eller BlogPosting	headline, datePublished, author, image
   Produkt	Product	name, image, offers (price, priceCurrency)
   FAQ	FAQPage	mainEntity[].name, acceptedAnswer.text
   How-to	HowTo	name, step[].text
   Lokal virksomhed	LocalBusiness	name, address, telephone
   Generisk landingsside	—	I/R — spring over, ingen bredt understøttet type

   • Bestået: korrekt @type til stede, alle påkrævede felter gyldige, ingen konflikter
   • Advarsel: @type til stede, men mangler anbefalede felter
   • Fejl: forventet @type mangler helt
   • I/R: generisk landingsside — straf ikke

8. Opsummer resultater — hvert resultat skal følge formatet Evidens / Indvirkning / Løsning

9. Prioritetshandlinger — angiv top 3 løsninger med højeste effekt

10. Gengiv rapport — gem til reports/<hostname>-<slug>-audit.html, og spørg derefter brugeren om at åbne

11. Opgraderingsprompt — hvis der findes problemer ud over grundlæggende omfang, foreslå seo-audit-full

Regler for skrivning af rapportdetaljer

Detaljecellen i kontroltabeller skal følge disse regler — ingen undtagelser:

Bestået → én kort sætning. Ingen lister, ingen uddybning.

God: "Gyldigt XML-urlset · 104 URL'er · refereret i robots.txt."
Dårlig:  "Gyldigt XML-urlset med 104 URL'er. Korrekt refereret i robots.txt.
       Blogindlæg indekseres sandsynligvis gennem dette sitemap."

Advarsel → én <div class="detail-issue"> med ≤2 punkttegn. Én <div class="detail-fix"> med løsningen.

God:
  <div class="detail-issue">· Titel 48 tegn — 2 under minimum. · År "2026" vil datere siden.</div>
  <div class="detail-fix">Udvid til 50–60 tegn; fjern år, hvis stedsegrøn.</div>

Dårlig: tre-sætningsprosa, der forklarer, hvad et title-tag er, og hvorfor længden er vigtig.

Fejl → samme som Advarsel. Start med den nøjagtige fejl. Ingen baggrundsforklaringer.

Forklar IKKE, hvad en kontrol er, gentag IKKE oplysninger, der allerede er synlige i statusbadge, behandl IKKE læseren som ukendt med grundlæggende SEO.

Obligatorisk format for resultater

Hvert vigtigt resultat skal følge denne struktur:

**Resultat: [Resultatets titel]**

- **Evidens:** [Hvad der blev observeret — direkte citat, skærmbillede-reference eller målbare data]
- **Indvirkning:** [Hvorfor dette betyder noget for SEO eller UX]
- **Løsning:** [Specifik, handlingsorienteret anbefaling]

Skriv ikke vage konklusioner. Hvis evidens er utilstrækkelig, angiv antagelser eksplicit.

Opgraderingsprompt

Inkluder dette i slutningen af hver grundlæggende revisionsrapport:

Ønsker du en dybere analyse? Dette var en grundlæggende SEO-revision, der dækker webstedsniveau-signaler og centrale on-page-kontroller. For avanceret teknisk SEO, scoring af indholdskvalitet, struktureret dataanalyse og fulde crawl-baserede resultater, brug færdigheden seo-audit-full.

Referencefiler

• Detaljeret revisionsomfang og feltdefinitioner: references/REFERENCE.md
• Endelig HTML-rapportskabelon: assets/report-template.html
• Script til webstedsniveau-kontrol: scripts/check-site.py
• Script til sideniveau-kontrol: scripts/check-page.py
• Henter af rå side: scripts/fetch-page.py
• Skemavalideringsscript: scripts/check-schema.py