Robots.txt kontra robots meta tag

Skal du bruge robots.txt til at rette op på hjemmesidesnedkernes fejl eller hvad nu formålet med at bede søgemaskinerne undlade at indeksere dit indhold måtte være – eller skal du bruge “Robots Meta Tag”? Forvirringen er total, og i takt med at flere og flere velmenende giver “gode råd” om søgemaskineoptimering, stiger forvirringen blot endnu mere. Derfor har jeg besluttet at give mit beskedne bud på, hvordan du kan bruge disse muligheder. Men først skal vi lige have én ting helt og aldeles på plads.

Det er 100 gange bedre at undgå fejl end at lappe på dem

– men er skaden først sket, er det stadig bedre at gøre NOGET fremfor ingenting. Sådan lidt som hvis du arbejder med en skarp kniv. Det er bedst at undgå at skære sig, men smutter kniven og skærer dig, er det bedre at sætte et plaster på end at bløde ihjel.

Der kan være masser af andre grunde til at ønske at blokere søgemaskinernes adgang til visse dele af sin hjemmeside end lige fejlopbygning, der resultater i duplicate content. I denne artikel tager jeg dog udelukkende udgangspunkt i problemstillinger med duplicate content, der ikke lader sig rette med mere hensigtsmæssige metoder. Læs det lige igen – så er vi helt sikre på, at vi er enige om, at alt i denne artikel handler om symptombehandling og ikke om helbredelse.

Jeg tillader mg at tage udgangspunkt i, at du kender til problematikkerne med duplicate content. Gør du ikke det, kan du lære det hele i SEO-LEX 😉

Den socialdemokratiske model har skylden!

Den overskrift kræver nok lidt forklaring – men faktisk er det, jeg kalder for den socialdemokratiske model skyld i, at vi overhovedet skal bøvle mellem robots.txt og Robots Meta Tag. Forklaring: Masser af udbydere af shopsystemer og CMS anlægger den grundlæggende socialdemokratiske opfattelse, at kan alt ikke blive lige godt, skal alt i hvert fald være lige ringe. Adskillige shopsystemer giver ikke deres brugere muligheden for at benytte et “noindex” i headeren til en given URL, og deres forklaring er (i flere tilfælde), at det er ikke alle deres kunder, der kan finde ud af at bruge den løsning. Altså: Kan alle ikke finde ud af det, skal ingen have muligheden. Det er det, jeg mener med den socialdemokratiske model 😉

Når vi så sidder og arbejder med for eksempel en shop, der er bygget i et system, der latent genererer duplicate content, og vi ikke har nogen mulighed for at benytte hverken unikke Robots Meta pr. URL eller sætte en korrekt canonical URL, sidder vi med kun to muligheder:

  1. Ignorere problemet og sige “Insha Google” (lægge det i Googles hænder) eller
  2. Blokere de ikke korrekte URLs med robots.txt

Nogle gange har vi endda ikke engang adgang til at arbejde med robots.txt, og så er der bare ikke andet at gøre end at presse leverandøren af systemet til at gøre sit arbejde ordentligt.

Hvad er forskellen på at bruge robots.txt og Robots Meta?

Kort fortalt betyder en blokering med robots,txt, at søgemaskinerne ikke crawler den pågældende URL. Men det betyder IKKE, at de ikke kan finde på at liste dem alligevel, hvis de synes, det er en god ide. I så fald er det blot selve URL’en, der fremgår i søgeresultatet – det kan ikke være andet, for søgemaskinen har ikke crawlet indholdet. Måske husker du den lidt testosteron prægede forklaring fra 2007 på crawling, indeksering og ranking?

Altså: En URL kan sagtens være med i f.eks. Googles indeks, selvom den er blokeret med robots.txt. Den bliver så blot ikke crawlet, og som følge heraf kan det tekstmæssige indhold på siden heller ikke generere duplicate content.

Du kan se et eksempel på en URL fra vores bd-store.dk, der er blokeret med robots.txt, men som alligevel er med i Googles indeks. Hvorfor vi ikke har benyttet Robots Meta Tag i stedet? Fordi DanDomain bruger den socialdemokratiske model 😉

Som du kan se, er der ingen description med.

Bruger du til gengæld Robots Meta Tag, får du langt flere muligheder og en større effekt. Lad os se lidt på det tag nok engang. Og husk nu lige, at det er helt og aldeles overflødigt, hvis du gerne vil have søgemaskinerne til at indeksere indholdet på en side og følge evt. links på siden.

Det levner os reelt med tre mulige kombinationer:

  1. <META NAME=”ROBOTS” CONTENT=”NOINDEX, FOLLOW”>
    Her siger vi til søgemaskinerne, at de ikke skal indeksere indholdet på den pågældende side, men at de skal følge de links, de møder under deres crawl af siden. Det er praktisk i mange tilfælde, hvor du gerne vil have linkværdi ud af en side, selvom den ikke skal indekseres. For eksempel hvis du har en 404 fejlside som denne: https://www.concept-i.dk/404
  2. <META NAME=”ROBOTS” CONTENT=”INDEX, NOFOLLOW”>
    Her siger vi til søgemaskinerne, at de skal indeksere det indhold, der er på siden – men at de ikke skal tillægge de links, de finder på siden under deres crawl nogen værdi. Det kunne være f.eks. betalte links, som du ikke vil have bank af søgemaskinerne for.
  3. <META NAME=”ROBOTS” CONTENT=”NOINDEX, NOFOLLOW”>
    Her siger vi til søgemaskinerne, at de ikke skal gøre noget som helst – de skal simpelthen holde snuden væk. Og det gør de så.

Hvilken er bedst – robots.txt eller Robots Meta?

Igen: Husk nu, at vi i denne artikel alene forholder os til at sætte plaster på, når det ER gået galt – og at vi ikke har andre muligheder end de to. Den bedste løsning vil så altid være at benytte Robots Meta Tag, for så er du fri for at risikere at din “dårlige” URL alligevel dukker op i indeks. Og du kan få værdi ud af dine links på siden alligevel – det kan du ikke med robots.txt, for som du husker, crawler robotten slet ikke en URL, der er blokeret med robots.txt. Og når den ikke crawler den, kan den heller ikke finde links på den.

Skal vi lige opsummere? Det bedste er at undgå duplicate content – men på mange platforme er det ikke i skrivende stund en reel mulighed. Det næstbedste er så at kunne implementere et canonical URL tag – men hold tungen lige i munden! Det skal implementeres rigtigt – ellers er det mere skade end gavn. Det tredjebedste er at benytte Robots Meta Tag – og som rosinen i pølseenden er så robots.txt, der desværre er den eneste mulighed for tage affære på alt for mange platforme.

Jeg håber, det gav lidt afklaring? Og lad mig slutte med at vise en video med Matt Cutts fra Google, der forklarer det meget godt:

 

Rosenstand out!

Få et opkald fra Thomas Rosenstand - Så er du på vej til den ultimative SEO løsning!

Invalid Email
Invalid Number

27 kommentarer til “Robots.txt kontra robots meta tag”

  1. John Nielsen

    Tak for en, som altid, velformuleret forklaring, der bringer nogle af de lidt indviklede SEO-begreber ned i øjenhøjde med brugerne. Med den seneste debat om robots txt/metatags og det hos nogle halvblinde gætteri om Google Bot’s ageren, var det tiltrængt.

    Du har ret i, at der sidder mange gør-det-selv SEO eksperter og ivrigt deler ud af deres opfattelse af den korrekte teknik. Jeg er personligt glad for at have fundet en lille håndfuld, hvis råd og vejledning jeg tør bruge på min virksomheds hjemmesider.

    Tak, Hr Rosenstand!. 🙂

    Dbh.
    John Nielsen

  2. Tak for en god artikel.
    Jeg kunne godt lide socialdemokrat analogien 🙂

    Du skriver, at hvis man ikke kan undgå duplicate content, så er canonical URL tag det bedste og derefter Robots Meta Tag. Betyder det så at Google er begyndt at tage canonical URL tagget mere seriøst?

    Jeg har tidligere foreslået canonical URL tag som en løsning til personer med ovenstående problemer (via Amino), men har så fået at vide af SEO eksperterne, at det kun holder i teorien. I praksis så ignorerer google ofte canonical URL tagget. Er der sket en ændring på det?

    1. Hej Erik
      Det er min og efterhånden manges erfaring, at et korrekt implementeret canonical tag respekteres af især Google. Men det ER stadig et plaster og ikke en løsning.

  3. Det er vel nærmere den liberalistiske model, som er årsag til problemet her:

    Af ren egoisme og med tanke på egen profit har hjemmesidesnedkeren valgt at være ligeglad med andre, når de alligevel ikke kan se fejlene han laver. 😉

  4. @ Thomas
    Dejligt at Google endelig er ved at tage canonical tag til sig. Og tillykke med fødselsdagen 😉

  5. Søren Romlund

    Jamen dog. synges jeg læste et eller andet sted der var nogle der sagde tillykke til dig i går.
    men nå, så tillykke med i dag 😉

    men iflg. det danske vejr så har du været artig i år. 🙂

    Mvh
    Romlund

  6. Søren Romlund

    Jamen det er jo epic!
    Så har du helt jo sikkert fortjent en is lagkage med daim på toppen! 🙂

    mvh
    Romlund

  7. Alle ovenstående løsninger er plastre på overordnede fejl. Det er vel mere eller mindre, det du skriver.

    Hvad er så bedste løsning på sites med f.eks. 500 produkter, samt både søgning og kategorier. Et produkt passer måske i flere kategorier, og det kan også gå igen i mange forskellige søgninger. Hvis man intet gør, så må der komme problemer med dublicate content. Hvilken løsning vil du foreslå?
    Man kan ikke lave 301 redirects, da en søgning på ipod samt en søgning på apple trods alt er 2 forskellige sider med forskelligt indhold. Men ipod produkter går sandsynligvis igen i begge søgninger og skaber dublicate content. Skal man så lave en side med alle produkter, og så et canonical tag til denne side, fra alle søgninger? Eller er det bedre intet at gøre? (eller en tredie løsning?)

    Hvis en bruger søger på ipods på google, så vil den mest relevante side (for det omtalte site) jo være enten en kategori med ipods eller en søgning på ipods. Men har man brugt et canonical tag, der peger på en side med alle produkter, så har man vel fortalt søgemskinerne at dette er den korrekte side at indeksere, og altså ikke den aktuelle søgning.

    Jeg håber at du forstår min problematik, og at du har et super svar 🙂

  8. Næ – for ofte vil det pågældende produkt jo blot være en lille del af et søgeresultat, der også indeholder masser af andre produkter, og det er jo ikke duplicate content. Selve produktets side skal naturligvis være én og samme URL på tværs af kategorier – det skal et shopsystem kunne.

    Var det det, du mente?

  9. Ikke alt indholdet vil være ens, men noget af indholdet vil være ens. Er det ikke noget problem?

    F.eks.
    Søgning1 viser produkt 1,2,3,4
    Søgning2 viser produkt 3,4,5,6
    Søgning3 viser produkt 1,3,4,6

    Der er dermed en del sammenfald imellem søgningerne, og dermed en del ens indhold.

    Jeg snakker altså ikke selve produktets side, men selve søgningerne vil indholde rigtig meget ens indhold.

  10. De skal ikke indekseres fordi alle resultater vil fremgå via andre veje, som f.eks. kategorier?
    Men hvad så med kategorier. Er det vigtigt at et resultat/produkt kun kommer i én kategori, og altså ikke i flere kategorier, som selvom produktet måske passer på flere kategorier?

    1. En god grund kunne være denne sætning fra Googles retningslinjer 😉 “Brug robots.txt til at forhindre gennemgang af søgeresultatsider eller andre automatisk genererede sider, der ikke rummer megen værdi for brugere, der kommer fra søgemaskiner.”

      Du viser vel ikke den fulde produkttekst i dine kategorier? Hvis du ikke gør, er der jo ingen risiko for DC. For eksempel er denne side en kategori – men med yderst begrænset tekst til hvert produkt: http://www.bd-store.dk/shop/clip-on-off-39c1.html

  11. Indtil nu har jeg spurgt generelt. Både fordi jeg gerne vil have generel viden, men også fordi der måske er andre der læser med, og dermed kan få glæde af de guldkorn du kommer med 🙂

    Jeg vil dog blive lidt mere specifik nu. Jeg tænker på et site som konkurrenceSiden.dk
    Søgning via dropdown bokse:
    http://www.konkurrencesiden.dk/soeg.asp?select=0&select2=3&select3=0&select4=Rejser
    Tekstsøgning:
    http://www.konkurrencesiden.dk/tekstsoeg.asp?soegeord=ipod

    Det er en guide til div. konkurrencer. Der er en specifik side til hver konkurrence, men der er stort set lige så meget tekst til hver konkurrence i søgningen, som på selve konkurrencens egen side. 9/10 finder konkurrencer via dropdown, og 1/10 via tekstsøgning (aner ikke om det har betydning for den bedste løsning). Hvilken løsning/plaster vil du foreslå?

    Skal jeg stoppe indeksering af søgning, beholde indeksering af kategorier (dropdown), men uden canonical, og så lave noget mere tekst på konkurrencernes egne specifikke sider? Eller skal der helt andre metoder i brug?

    1. Hej Erik
      Jeg vil ikke sige noget mere specifikt uden at have sat mig grundigt ind i dit site – det er et tricky område. Og det kniber med tiden lige nu. Men Uden at have analyseret dit site: Hvorfo rikke bare korte teksterne i søgeresultaterne dramatisk ned, så sådan en side mere får karakter af en kategoriside på f.eks. en blog? Hvis du gør det, er risikoen for DC mindre.

  12. ok, det er helt iorden.

    Teksten i søgeresultaterne og kategorierne er allerede meget kort, og hvis den formindskes, så daler brugervenligheden drastisk, så det ønsker jeg ikke. Og hovedformålet er ikke at få brugeren ind på selve produksiden, hvilket det jo er for en blog. Brugerne skal gerne kunne gå direkte videre fra søgningen og over til selve konkurrencerne, som ligger på eksterne sites. Derfor giver det ikke mening, bare at have en forkortet tekst, som i en blog kategoriside.

    Jeg tror istedet at jeg må igang med at forfatte noget mere tekst på de specifikke konkurrencebeskrivleser, så burde risikoen for DC også falde.

    Du skal have tak for den tid du har brugt 🙂

  13. Hej Thomas,
    Jeg synes at det giver mening at bruge de forskellige noindex og nofollow metatag-kombinationer, men kan man ikke helt lade være med at bruge “index, follow”, da det vel er søgemaskinernes default? I mine øjne er den optimale løsning at bruge begge tilgange og definere sitewide regler for indexering i robots.txt, men køre sidespecifikke regler i meta tags. Hvad siger du?

    1. Hej Pål

      Jo – det er ganske enkelt overflødigt at benytte det tag, hvis det står til follow/index. Fuldstændigt som det er overflødigt at benytte robots.txt, hvis der ikke er nogen disallow i den.

      Du kan fint kombinere med både tags og robots.txt, når bare tungen holdes præcist 0 grader i munden og fokuseret 🙂

Skriv en kommentar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *