Har du en hosted løsning til enten din webshop eller din hjemmeside? Så kan du risikere at blive ramt af duplicate content, selvom du sikrer dig på din egen side efter alle kunstens regler.
Duplicate content er jo dette, at det samme indhold kan tilgås på flere forskellige webadresser, enten på din egen hjemmeside, eller fordi nogen simpelthen kopierer din tekst. At det er et problem viser den seneste polemik omkring Nordjyske og Confit de Canard, hvor en dansk blogger mistede sin gode placering, fordi medievirksomheden Nordjyske ikke helt havde styr på sine leverandører af indhold, og heller ikke mente at det var nødvendigt at undersøge hvorvidt leveret materiale nu var unikt. Det betød at bloggerens site helt forsvandt fra søgningen “confit de canard”, og Nordjyske fik placeringen istedet, da domænet har mere trust end bloggerens.
Alle med et hosted CMS eller webshop er potentielt i fare
Men du behøver nu ikke være udsat for tyvagtige kokke eller søvnige redaktører for at blive ramt af duplicate content – frit oversat til duplikeret indhold. Du kan nemlig være så uheldig at din leverandør af hjemmeside eller webshop snorksover i timen, og skaber en tro kopi af din hjemmeside på et ofte mere anerkendt domæne end dit.
Det forholder sig nemlig sådan, at de rigtig mange leverandører “bygger” hjemmesiden på et udviklingsdomæne, altså et domæne som ikke har noget med dit domæne at gøre. Her har man så typisk placeret din hjemmeside i en mappe eller i et subdomæne, så man ikke viser et halvfærdigt website til dem der forvilder sig ind på din hjemmeside. Det er i og for sig også godt nok – men: Hvis googlebot uhindret får lov til at crawle siderne på dit udviklingssite, vil indholdet blive indekseret her. Når så din side udgives, kender Google allerede indholdet, for det har søgerobotten jo allerede indekseret på et helt andet domæne, og så bliver din hjemmeside puttet i det såkaldte supplerende indeks, som er Google’s skraldespand for skrammelindhold.
Sådan sikrer man sig mod indeksering af udviklingssites
Hvordan kan man så undgå at ens tekster bliver fundet på et udviklingssite? Mange mener jo, at så længe der ikke bliver linket til indholdet er den hellige gral velforvaret. Desværre forholder det sig ikke sådan. Der kan opstå fejl, eller folk kan helt bevidst linke til udviklingssite, enten fordi de er uvidende om risikoen ved det, eller bevidst forsøger at skade dig.
Derfor skal man altid sikre sig på en eller flere måder. Umiddelbart er der tre mulige løsninger:
- Sørg for at få fjernet udviklingssitet når dit website går i luften – Det forhindrer dog ikke duplicate content hvis udviklingssitet er indekseret.
- Tilføj en særlig meta-tag til dit website, som fortæller google at den ikke skal indeksere indholdet.
- Upload en robots.txt fil til din hjemmeside, indeholdende information til Google og andre søgemaskiner om hvorvidt dit indhold skal indekseres.
Hvordan tjekker man om man er i fare for at blive ramt?
Lad os antage at dit udviklingssite er beliggende på dinside.udviklingsdomæne.dk – Så laver du en søgning på Google således:
Hvis du nu får resultater på denne søgning, kan det være tegn på, at udbyderen ikke har sikret sig mod duplicate content. Et praktisk eksempel: Dansk leverandør har ikke sikret deres udviklingsdomæne mod indeksering. Hvis man kigger i kildekoden på et af de sites der vises i resultatlisten ser man at der står følgende:
<meta name="robots" content="ALL" />
Her burde i stedet have stået
<meta name="robots" content="noindex" />
Hvis man tænker: “Nå, men mon ikke de så har brugt en robotsfil på deres udviklingsdomæne”, så kan man roligt tænke om igen. Den kan nemlig heller ikke findes. Så det eneste, der afholder denne udbyders kunder fra, at få indekseret deres indhold som duplicate content er, at det trods alt kræver et link for at Google skal finde den.
Tør du løbe an på, at der ikke er nogen, der finder på at linke til din udviklingsside?
13 kommentarer
Der kan ikke råbes højt nok om dette problem. Har været nødt til at gøre to kunder opmærksomme på det i løbet af den sidste måned, hvoraf den ene er en af Danmarks 5 største offentlige websider.
Jeg støtter ethvert opråb om det problem – er selv nærmest ved at give op. Måske kan du huske, jeg bitchede over det i 2008: http://www.thomas-rosenstand.dk/danske-cms-leverandoerer
Er det så blevet bedre siden dengang? Nej – ikke det fjerneste. Måske endda værre. Måske burde vi SEO’ere sende rødvin til CMS husene i Danmark, der i den grad sikrer vores overbookning langt ud i fremtiden?
Det er skræmmende at så mange danske webleverandører stadig lader deres udviklingsdomæner indeksere. Vi har banket dem oven i hovedet i flere år nu, og lige meget hjælper det.
Personligt har jeg opgivet at tale dem til fornuft, men gør altid kunden opmærksom på det, og råder dem til at tage kontakt til udbyderen, og påtale problemet.
God påske 🙂
Rigtig godt blog inlæg
Er glad for vi ikke har dette problem mere, har lige haft Thomas Rosenstand til at kigge industribasen igennem for DC fornylig og fået rettet det der var.
Tak for en god blog iøvrigt
Jeg kender godt problemet. Jeg har SEO optimeret et Flash site, der røg direkte til tops efter jeg havde gjort nogle få ting. Jeg anbefalede dog at få lavet et site i HTML, men betalingen blev presset så langt ned at jeg ikke ville være med og de fandt en anden leverandør. Den blev lavet i Umbraco, men af uvisse årsager skulle der både være en kopi af sitet på det ene og det andet domæne – udover på webbureauets. På trods af at Umbraco ellers ser ud til at være godt er det lykkedes bureauet at få brudt næsten enhver grundregel i forhold til Google.
Forstår dog ikke helt problemet med “hosted”. Et site er jo for det meste “hosted” – men det er bestemt ikke ensbetydende med “duplicate content”. Men du må mene at der er en kopi på en af webbureauets servere. Den burde jo kun være der for at demonstrere produktet før den bliver sat på den rigtige side.
Fik vist ikke lige tilføjet at de simpelthen røg til helt bunds i Google efter et “professionelt SEO webbureau” leverede varen.
Tip: lav et login på test og udviklings site 🙂
Rigtig god ide – Så er man også sikker på ikke at glemme noget, hvis det er fast rutine, eller måske endda automatisk bliver lavet ved oprettelse af nyt site på testserveren.
Hej alle sammen.
Nu kan jeg så konstatere, at vi er blevet brugt som eksempel her i indlægget og vil dermed takke for et spark i r….
Vi har selvfølgelig valgt at bruge det konstruktivt og har holdt fælles brainstorm omkring problemet. Det er lidt et problem bare at skære hele udviklingsdomænet væk da nogle kunder faktisk ønsker dette bevaret. Men vi har fundet en løsning som vil tilgodese alles behov.
Vi går derfor straks igang med en opdatering, som rulles ud til alle vores eksisterende løsninger ultimo maj 2011.
Godt at høre at I reagerer hurtigt på det…
Vi har som standard et udviklingsdomæne på alle vores webhoteller. Men vi har nok ikke været gode nok til at oplyse om problemet. For det ER stort. Se blot vores ene webserver:
http://www.google.dk/search?sourceid=chrome&ie=UTF-8&q=site%3Awinweb01.abusiness.dk
Når man selv udvikler softwaren der hostes er det relativt nemt at finde en løsning på problemet. Men hos os kan det jo være vidt forskelliget hvad kunderne rent faktisk lægger op og vælger at hoste. Og det er lige så forskelligt hvor lang tid kunderne har behov for udviklingsdomænet – og ligesom Ultimizes kunder er der også nogle som gerne vil beholde det efter endt udvikling.
Men kva denne artikel, vil vi sørge for at lægge en strategi, så vi kan få oplyst og hjulpet vores kunder af med problemet.
Lige et spørgsmål. Når nu et udviklingsdomæne er blevet indekseret, er det mest rigtige vel at lave 301 redirects til siderne på det rigtige domæne, ikke?
Mht allerede indekserede sites: Jo, en 301 redirect vil løse problemet – over tid! Det er ikke noget quick-fix, og kræver tålmodighed.
Jeg har lige skrevet et indlæg om netop at undgå duplicate content ved udviklings site, og endnu mere vigtig, undgå at indstillinger lægges live, så live sitet måske risikerer ikke at blive indekseret, se det her: http://timmy.dk/din-udviklings-side-skal-ikke-indekseres/