BLOGG

Att hantera duplicate content

Mer eller mindre alla SEO-projekt jag har jobbat med under mina +10 år har innefattat utmaningar med “duplicate content”. Alltså att innehåll på webbplatsen kan nås med fler än en webbadress. Ibland kan duplicate content ställa till med en del bekymmer, även om det sällan är ett jättestort problem. Vi har tagit fram en lathund som kan användas som en guide för att välja rätt åtgärd vid duplicate content. Om du inte vill läsa hela inlägget kan du istället ladda ned lathunden här: Handling Duplicate Content – The Cheat Sheet.

Vad är duplicate content?

Kortfattat handlar det alltså om att ett visst innehåll kan nås med mer än en webbadress. Vissa av dessa fall är väldigt enkla och uppenbara för de som har jobbat med SEO ett tag. Till exempel kan man ofta nå en webbplats såväl med “www” som utan “www”. Till exempel: http://example.com och http://www.example.com. Detta åtgärdas genom att alla förfrågningar (requests) till webbadresser utan “www” pekas om med en 301 redirect till samma webbadress med “www”.

Andra vanligt förekommande fall av duplicate content:

  • Produktlistor som kan sorteras på olika sätt, och där vald sortering syns i webbadressen
  • Utvecklings- och testmiljöer där hela webbplatsen kan nås på exempelvis en annan subdomän (dev.example.com)
  • Produkter som finns under flera olika produktkategorier och där kategorin man kommer från syns i webbadressen för produkten

Hur löser man problemen?

Det finns många olika sätt att lösa problem med duplicate content, och det är inte alltid helt lätt att se vilken lösning som är den bästa. Några vanliga lösningar är:

  • Stoppa sökmotorer från att spindla av innehållet via robots.txt
  • Hindra sökmotorer från att indexera innehållet via meta taggar (<meta name=”robots” content=”noindex,nofollow”>)
  • Använda rel=”canonical” taggen för att instruera sökmotorerna om att en webbadress har samma innehåll som en annan webbadress
  • Blockera såväl användare som sökmotorer från vissa sidor med lösenordsskydd
  • Serverbaserad ompekning via så kallad 301 Permanent Redirect

I denna post hade jag inte tänkt berätta exakt hur dessa olika lösningar implementeras, utan istället koncentrera mig på vilken av lösningarna man bör välja beroende på de förutsättningar som råder.

En väldigt viktig aspekt som man måste ha koll på är att om man blockerar sökmotorer från att spindla av en webbadress med robots.txt, så kommer sökmotorerna inte att kunna se eventuella meta-taggar som används på de sidor som blockerats. Och bara för att sökmotorerna blockeras från att indexera en webbadress så innebär det inte att de inte kan komma att lista webbadressen i sina sökresultat. Om en sida som har blockerats i robots.txt får länkar från andra webbplatser än din egen, så kallade externa länkar, finns dett en överhängande risk (chans?) att, till exempel Google, väljer att lista sidan i sitt resultat, men att de, istället för att visa din meta beskrivning eller textutdrag från din sida i samband med listningen, informeras användaren om att innehållet på sidan inte kunde läsas av på grund av inställningar i robots.txt.

Detta betyder att om du verkligen inte vill att en viss sida ska kunna listas bland sökresultaten så måste du antingen låta sökmotorerna spindla av sidan och använda meta taggar för att instruera sökmotorerna om att sidan inte ska indexeras, eller lösenordsskydda tillgången till sidan, vilket sällan är användbart om dina vanliga besökare ska kunna tillgå sidan på ett bra sätt.

Robots.txt

Personligen är jag inte speciellt förtjust i användningen av robots.txt. Främst på grund av att man helt öppet, för vem som helst, listar vilka kataloger eller webbadresser på webbplatsen som kan tänkas innehåll känslig information som man inte vill att sökmotorerna ska spindla av. Dessutom har erfarenhet visat att sökmotorerna inte alltid följer instruktionerna i robots.txt fullt ut. Allra helst ifall man använder så kallade wildcards eller andra mer avancerade instruktioner för att matcha webbadresser som inte ska spindlas av.

Det finns dock ett väldigt tydligt fall när robots.txt är helt rätt att använda. Och det är i de fall där du har en väldigt stor webbplats med väldigt många webbadresser (kanske miljontals) och den “crawl budget” som sökmotorerna ger din webbplats inte räcker till. Kortfattat kan man säga att sökmotorerna använder alldeles för mycket av sina resurser att spindla av onödigt innehåll istället för att fokusera på det som är viktigt. I detta fall är robots.txt ett väldigt bra alternativ för att instruera sökmotorerna om vilka webbadresser som inte är intressanta för dem att lägga några resurser på.

Läs mer om robots.txt här: http://www.robotstxt.org/robotstxt.html

 

Meta Robots

Meta robots taggen är den lösning du ska använda ifall du verkligen vill se till att sidor som dina besökare måste kunna tillgå, inte ska dyka upp i sökmotorernas resultat. Var dock väldigt noga med att inte felaktigt exkludera sidor som är viktiga för att de rankar bra på sökfraser som dina potentiella kunder använder när de letar efter det du har att erbjuda.

En annan sak att ta i beaktning är ifall de sidor som du ska exkludera med meta robots kan tänkas få externa länkar till sig. Om så är fallet kan man använda “noindex,follow” för att sökmotorerna ska följa de länkar som finns på sidan vidare, både för att hitta till mer innehåll på din webbplats och för att sprida eventuellt länkvärde vidare till dessa sidor. I dessa fall brukar jag personligen hellre välja att använda rel canonical.

Läs mer om meta robots här: http://www.robotstxt.org/meta.html

Rel canonical (<link rel=”canonical” href=”http://www.example.com/the-canonical-url” />)

I de fall där du har sidor på webbplatsen som dina besökare måste kunna tillgå via olika webbadresser trots att innehållet är detsamma, och du vet att det kan komma att skapas externa länkar till innehållet är rel canonical ofta den enklaste lösningen. Dock är det viktigt att komma ihåg att rel canonical tolkas som en rekommendation av sökmotorerna och att det finns många fall där sökmotorerna väljer att inte följa den rekommendationen.

Läs mer om rel canonical här: https://support.google.com/webmasters/answer/139066?hl=sv

Blockera med lösenordsskydd

Ifall de sidor som du inte vill att sökmotorerna ska lista i sina sökresultat är sådana sidor som dina besökare inte heller behöver kunna tillgå så är blockering via lösenordsskydd ofta väldigt enkelt och effektivt. Vanligt förekommande fall för detta är när man har speglingar av webbplatsen på flera olika subdomäner eller domäner för test- eller utvecklingssyfte.

Läs mer om http autentisering för Apache via htpasswd här: http://httpd.apache.org/docs/2.2/programs/htpasswd.html

301 redirect

För innehåll som har bytt webbadress är 301 redirect den allra bästa lösningen. Kortfattat instruerar du sökmotorerna och besökarnas webbläsare att innehållet som tidigare funnits på denna webbadress nu har flyttat till en annan webbadress istället. Och eventuellt länkvärde som den gamla webbadressen har överförs till den nya. När man bygger om sin webbplats, och under förutsättning att webbadresserna förändras, är detta en av de mest kritiska och viktigaste delarna att komma ihåg ifall man vill undvika att få ett rejält tapp i ranking och organisk söktrafik i samband med lansering.

Men åhhhhhh, det här är ju så himla krångligt!

Ja, det kan bli lite krångligt att veta vilken lösning man ska välja, och för att underlätta har vi tagit fram ett lite “cheat sheet”. En lathund som du kan använda när du vill ta reda på vilken lösning som bör användas. Se lathunden som en guide, och det kan absolut finnas fall är guiden inte är helt fulltäckande, men den bör trots allt ge en hel del hjälp på vägen. Lathunden är på engelska.

Ladda ned “Handling Duplicate Content – The Cheat Sheet“.

Leave a Reply

You must be logged in to post a comment.


Behöver du hjälp?

Är ni intresserade av att veta hur Firstly kan hjälpa till med er SEO-strategi?

Kontakta oss