Mere end halvdelen af alle WordPress-sider har en fejl i deres robots.txt-fil - det er ikke et løst skøn, men en observation der gentager sig i tekniske SEO-audits igen og igen. Fejlen er sjældent bevidst sabotage. Den opstår fordi ejeren troede, de beskyttede noget, men i virkeligheden blokerede de noget kritisk. Denne guide giver dig den præcise viden du skal bruge for at undgå det.
Hvad robots.txt styrer - og hvad den ikke gør
Den hyppigste misforståelse om robots.txt er, at den kontrollerer indeksering. Det gør den ikke. Robots.txt styrer crawling - altså om Googlebot og andre crawlere overhovedet må besøge og hente indholdet på en given URL.
Indeksering - om en side vises i søgeresultaterne - er noget andet og styres primært af noindex-direktivet i meta-tags eller HTTP-headers. Det betyder, at en side du har blokeret i robots.txt sagtens kan dukke op i Googles søgeresultater, hvis andre sider linker til den. Google ved siden eksisterer, selvom botten ikke har fået lov at crawle den. Den vil blot mangle indhold og titel.
Denne distinktion er afgørende. Hvis du vil forhindre en side i at blive indekseret, bruger du noindex. Hvis du vil spare crawl-budget og undgå at botten spilder tid på irrelevante URL'er, bruger du robots.txt. De to mekanismer løser forskellige problemer og bør ikke forveksles.
Standard WordPress robots.txt - og hvor du finder den
WordPress genererer automatisk en virtuel robots.txt-fil, som ikke eksisterer som en fysisk fil på serveren. Du finder den på dinside.dk/robots.txt. Standardindholdet ser typisk sådan ud:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://dinside.dk/sitemap_index.xmlHvis du har installeret et SEO-plugin som Signocore SEO, overtager det styringen af robots.txt og lader dig redigere indholdet direkte fra WordPress-dashboardet. Ønsker du fuld kontrol, kan du også oprette en fysisk robots.txt-fil i roddirektoriet på din server - denne vil altid have forrang over den WordPress-genererede version.
For at tjekke hvad din aktuelle robots.txt indeholder, besøger du blot /robots.txt-adressen på din installation. Du kan også bruge Google Search Consoles robots.txt-tester til at simulere, hvad en specifik crawler ser.
De vigtigste direktiver forklaret
En robots.txt-fil er opbygget af blokke, hvor hver blok starter med en User-agent-linje efterfulgt af en eller flere instruktioner. Her er de direktiver du skal kende:
User-agent
Angiver hvilken crawler reglen gælder for. Stjernen (*) er et wildcard der gælder alle crawlere. Du kan også skrive specifikke bots:
User-agent: *
Disallow: /intern/
User-agent: Googlebot
Allow: /intern/offentlig/Disallow og Allow
Disallow fortæller crawleren, at den ikke må hente den angivne sti. Allow giver eksplicit tilladelse og bruges typisk til at åbne en understi, som ellers ville være blokeret af en bredere Disallow-regel. Mere specifikke regler vinder over generelle - det er vigtigt at forstå, når du kombinerer de to direktiver.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpHer er hele /wp-admin/ blokeret, men admin-ajax.php er åbnet igen, fordi visse WordPress-funktioner bruger den endpoint til AJAX-kald på frontend.
Crawl-delay
Crawl-delay beder crawleren om at vente et bestemt antal sekunder mellem hvert request. Google ignorerer dette direktiv, men andre crawlere som Bing respekterer det. Brug det med forsigtighed - en for høj værdi kan forsinke indeksering på andre søgemaskiner unødigt.
User-agent: Bingbot
Crawl-delay: 2Sitemap
Du kan angive placeringen af dit XML sitemap direkte i robots.txt. Dette er god praksis, da det sikrer at crawlere nemt finder din sitemapfil uanset om de er blevet sendt via Google Search Console:
Sitemap: https://dinside.dk/sitemap_index.xmlHvad du bør blokere på WordPress
En velovervejet robots.txt-fil blokerer de stier, der ikke tilfører søgemæssig værdi og unødigt bruger dit crawl-budget. På de fleste WordPress-sider drejer det sig om følgende:
/wp-admin/ - Administrationspanelet skal aldrig crawles. Undtagelsen er
admin-ajax.php, som WordPress bruger til dynamiske frontend-kald.Stagingsider og testmiljøer - Hvis dit stagingmiljø kører på et subdomæne eller en understi, bør det være blokeret. Endnu bedre: kombinér med en
noindexHTTP-header på selve serveren, så siden heller ikke kan indekseres selvom botten finder den via et link.Interne søgeresultats-URL'er - WordPress-søgning genererer URL'er som
/?s=søgeord. Disse sider har sjældent selvstændig SEO-værdi og skaber tyndt indhold, som Google ikke belønner.Duplikat-paths - Parameterbaserede URL'er som
?replytocom=,?print=eller paginerede arkiver du ikke ønsker crawlet, kan med fordel blokeres for at reducere støj.
Et praktisk eksempel på en velstruktureret WordPress robots.txt:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /search/
Disallow: /?s=
Disallow: /wp-includes/
Disallow: /trackback/
Disallow: /comments/feed/
Sitemap: https://dinside.dk/sitemap_index.xmlHvad du aldrig må blokere
Her opstår de alvorlige fejl. Mange WordPress-ejere blokerer ressourcer i et forsøg på at skjule kildekoden eller "beskytte" designet - med det resultat at Google ikke kan rendere siderne korrekt.
Google renderer sider ligesom en browser. Hvis Googlebot ikke kan hente CSS-filer, JavaScript eller billeder, ser den ikke siden som dine brugere gør. Det påvirker direkte, hvordan siden evalueres i forhold til Core Web Vitals og indholdskvalitet. En side Google ikke kan rendere, er en side Google ikke kan forstå.
Aldrig bloker disse stier:
/wp-content/themes/ - Indeholder dit temas CSS og JavaScript. Blokerer du dette, ser Google en ustylede HTML-skelet.
/wp-content/plugins/ - Mange plugins leverer frontend-ressourcer som scripts og stylesheets. Blokering kan ødelægge rendering fuldstændigt.
/wp-content/uploads/ - Her ligger dine billeder. Blokerer du mappen, kan Google ikke se billedindhold, og du mister potentiel billedsøge-trafik.
/wp-includes/ - Indeholder WordPress core JavaScript-filer som jQuery. Mange sider blokerer denne fejlagtigt i troen om, at det er et internt systembibliotek uden frontend-relevans.
Hvis du er i tvivl om en given ressource er blokeret, kan du bruge Google Search Consoles URL-inspektionsværktøj. Det viser præcist, hvad Googlebot ser - og advarer, hvis ressourcer er blokeret.
Forholdet mellem robots.txt, meta robots og kanoniske URL'er
Robots.txt, meta robots-tags og kanoniske URL'er arbejder på tre forskellige niveauer, og de bør ikke bruges som substitutter for hinanden.
Robots.txt opererer på crawl-niveau og afgør om botten overhovedet henter siden. Meta robots-tagget - typisk <meta name="robots" content="noindex"> - opererer på indekseringsniveau og afgør om siden gemmes i Googles indeks. Den kanoniske URL fortæller Google, hvilken version af en side der er den foretrukne, og hjælper med at konsolidere linkjuice ved duplikatindhold.
En kritisk faldgrube: Hvis du blokerer en side i robots.txt, kan Google aldrig læse dens meta robots-tag. Det betyder, at et noindex-tag på en blokeret side er fuldstændig virkningsløst. Googles officielle anbefaling er klar - brug ikke robots.txt til at forhindre indeksering. Brug noindex.
Kombinationen der virker korrekt ser sådan ud: Lad Google crawle siden (ingen Disallow), men sæt noindex i meta-tagget. Så kan Google læse og respektere din instruktion om ikke at indeksere siden. Se også vores artikel om crawl-effektivitet og logfilanalyse for at forstå, hvordan crawl-budget fordeles på tværs af din side.
Generering og validering via Signocore SEO
Signocore SEO giver dig direkte kontrol over robots.txt fra WordPress-dashboardet uden at skulle redigere filer manuelt via FTP eller SSH. Under SEO-indstillingerne finder du en dedikeret robots.txt-editor, der viser den aktuelle fil og lader dig tilføje, redigere og validere direktiver i realtid.
Pluginnet advarer automatisk, hvis du forsøger at tilføje regler der potentielt blokerer kritiske ressourcer - en sikkerhedsmekanisme der forhindrer den klassiske fejl med utilsigtet blokering. Det integrerer desuden din sitemapplacering direkte i robots.txt, så den altid er opdateret når dit sitemap regenereres.
Til validering anbefales en kombination af Signocore SEOs indbyggede kontrol og Google Search Consoles robots.txt-tester, der simulerer specifikke crawler-forespørgsler mod din aktuelle fil. Du kan læse mere om Signocore SEOs funktioner i annonceringsartiklen om skiftet fra Swift SEO og i oversigten over det rigtige WordPress SEO-plugin.
Vil du have et udgangspunkt til en typisk WordPress-installation, er her en komplet skabelon der dækker de mest almindelige behov:
# Robots.txt genereret via Signocore SEO
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /trackback/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /author/
Disallow: /tag/
Disallow: /page/
# Tillad vigtige ressourcer eksplicit
Allow: /wp-content/uploads/
Allow: /wp-content/themes/
Allow: /wp-content/plugins/
Sitemap: https://dinside.dk/sitemap_index.xmlBemærk at blokeringen af /author/, /tag/ og /page/ er et valg der afhænger af din indholdsstrategi. Har du forfatterprofiler eller taksonomisider med reel redaktionel værdi, bør de ikke blokeres. Gennemgå altid din robots.txt i kontekst af din specifikke sidearkitektur - en generisk skabelon er et startpunkt, ikke en endelig løsning.
Robots.txt er en af de mindste filer på din server og en af de mest konsekvensfulde. En enkelt forkert linje kan koste dig indekseringen af hundredvis af sider. Behandl den med den respekt den fortjener.
